Git Product home page Git Product logo

caravan's People

Contributors

abhishandy avatar afsheenb avatar ayusuf95 avatar bruce1971 avatar bucko13 avatar caldon avatar crabel99 avatar demerzel3 avatar dependabot[bot] avatar destrys avatar dhruvbansal avatar dylan-thompson avatar dylanbathurst avatar empact avatar github-actions[bot] avatar honoka428 avatar howech avatar humanumbrella avatar hwinsby avatar jbrauck-unchained avatar mattoshibtc avatar nickkrauts avatar recursiverich avatar rsbondi avatar sashafklein avatar shadouts avatar steveblackmon avatar waldenraines avatar windsok avatar winsby avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

caravan's Issues

Remove `method` and `client` fields from wallet config.

The method and clients fields in the config are unnecessary, and aren't fixed over time.
A user can change devices, no reason to lock them into a specific device.
And a user may want to switch between public and private nodes.

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Consensus public/private UI misleading

On the "Interact" page, the Consensus box has a switch. When the switch is to the left, the box reads: "Consensus [switch to the left] Public".

Does this mean that I can turn Public on or off, and it's currently off? (This was my first thought.)

Does this mean that I can turn Consensus on or off, and it's currently off?

Does this mean that the choice is Consensus vs Public, and it's currently set to Consensus?

When I click the switch to the right, the label changes to Private. Why would an on/off switch's label change when I toggle it? Not what I expected. I thought I was turning on Public mode.

The UI element is apparently intended to toggle between Public and Private, but that's not how it's presented. I shouldn't have to click and interact with the UI element to discover what it does.

A toggle like this would be better presented as two radio buttons (labeled "Public" and "Private"), or a dropdown with two choices, or at least something that shows the two choices instead of only showing one that appears to be switched off when it's actually the selected mode.

Another alternative would be to always label the switch with "Private", even when it's to the left, and modify the explanation below to explain the current setting. ("Consensus will come from blockstream.info. Enable private to use a bitcoind node.")

The Edit Details button on the create wallet interstitial page shouldn't clear the wallet

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

I would have expected the edit details button on the wallet confirmation page to take me back to the wallet creation page with all of my xpubs still imported. It would be highly annoying to set up 7 different hardware wallets and then have to do them all over because you made a mistake on the last one.

Current Behavior

All of the xpubs are cleared, see gif:

Peek 2020-05-20 15-10

Possible Solution

Don't clear the wallet.

Steps to Reproduce (for bugs)

  1. Import some xpubs or upload a wallet configuration file
  2. Click "Edit Details" button
  3. Notice that your entire wallet has been reset

Environment

  • Where are you running caravan: localhost
  • Operating system: Linux
  • Browser and version: Chrome
[email protected] /home/walden/code/caravan
├── [email protected] 
└─┬ [email protected] 
  └── [email protected] 

npm: 6.14.4 
node: v12.16.2
Linux 5.6.13-arch1-1 #1 SMP PREEMPT Thu, 14 May 2020 06:52:53 +0000 x86_64 GNU/Linux

Bug: page jumps around when clicking on details of address

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

The page shouldn't jump around when you click on one of the tabs after expanding an address.

Current Behavior

When you expand of the address rows the entire page jumps around and it's rather jarring.

See gif:

Peek 2020-04-28 10-52

Possible Solution

Could potentially be fixed by left-aligning the content of the tabs? It seems like the problem is caused by the width of the script tab.

Steps to Reproduce (for bugs)

  1. Setup a funded wallet
  2. Go to address list
  3. Expand an address
  4. Click around on slices
  5. Note how jarring it is

Environment

  • Where are you running caravan: localhost
  • Operating system: Linux
  • Browser and version: Chrome
[email protected] /home/walden/code/caravan
├── [email protected] 
└─┬ [email protected] 
  └── [email protected] 

npm: 6.14.4 
node: v12.16.2
Linux 5.6.13-arch1-1 #1 SMP PREEMPT Thu, 14 May 2020 06:52:53 +0000 x86_64 GNU/Linux

Bug: error when clearing a wallet while it's being loaded

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

No error.

Current Behavior

I get the following error:

Uncaught (in promise) Error: Invalid checksum
    at Object.decode (1.chunk.js:205113)
    at Object.fromBase58 (1.chunk.js:358089)
    at deriveChildPublicKey (1.chunk.js:352822)
    at deriveChildPublicKey (1.chunk.js:352819)
    at _callee3$ (main.chunk.js:23221)
    at tryCatch (1.chunk.js:196343)
    at Generator.invoke [as _invoke] (1.chunk.js:196563)
    at Generator.prototype.<computed> [as next] (1.chunk.js:196396)
    at asyncGeneratorStep (1.chunk.js:195418)
    at _next (1.chunk.js:195440)
    at 1.chunk.js:195447
    at new Promise (<anonymous>)
    at WalletGenerator.<anonymous> (1.chunk.js:195436)
    at WalletGenerator.generateMultisig (main.chunk.js:23246)
    at _callee2$ (main.chunk.js:23186)
    at tryCatch (1.chunk.js:196343)
    at Generator.invoke [as _invoke] (1.chunk.js:196563)
    at Generator.prototype.<computed> [as next] (1.chunk.js:196396)
    at asyncGeneratorStep (1.chunk.js:195418)
    at _next (1.chunk.js:195440)
    at 1.chunk.js:195447
    at new Promise (<anonymous>)
    at WalletGenerator.<anonymous> (1.chunk.js:195436)
    at WalletGenerator.addNode (main.chunk.js:23204)
    at main.chunk.js:23336

Possible Solution

Hide or disable wallet action buttons while wallet is being loaded (see also #106) and/or fix the bug.

Steps to Reproduce (for bugs)

  1. Create a wallet
  2. Clear it before it completes
  3. Note error

Environment

  • Where are you running caravan: localhost
  • Operating system: Linux
  • Browser and version: Chrome
[email protected] /home/walden/code/caravan
├── [email protected] 
└─┬ [email protected] 
  └── [email protected] 

npm: 6.14.4 
node: v12.16.2
Linux 5.6.13-arch1-1 #1 SMP PREEMPT Thu, 14 May 2020 06:52:53 +0000 x86_64 GNU/Linux

Update address type labels to be more informative

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

Show in parenthesis what each address type looks like (“P2SH (3baec….)” and “P2WSH (bech32aje…)” to provide more info for users

Current Behavior

Only shows script type

Possible Solution

show example beginning of an address for each time (possibly match to network type).

Bug: able to upload a wallet configuration json file with duplicate xpubs

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

Error shown to user, file rejected.

Current Behavior

You are able to upload a json file with the duplicate xpubs in it.

Possible Solution

Reject files with duplicate xpubs in them.

Steps to Reproduce (for bugs)

  1. Go to the wallet page
  2. Upload awallet configuration file with three of the same xpubs in it
  3. Note you are able to create a wallet with it

Environment

  • Where are you running caravan: localhost
  • Operating system: Linux
  • Browser and version: Chrome
[email protected] /home/walden/code/caravan
├── [email protected] 
└─┬ [email protected] 
  └── [email protected] 

npm: 6.14.4 
node: v12.16.2
Linux 5.6.13-arch1-1 #1 SMP PREEMPT Thu, 14 May 2020 06:52:53 +0000 x86_64 GNU/Linux

Spend specific UTXO rather than all at once

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

If user has UTXOs with 0.1, 0.7, 0.4, 0.5 BTC each - user should be able to spend 0.1 UTXO without having to spend others back as "change" to self-address

Current Behavior

Unless I'm misunderstanding, currently Caravan requires spending all UTXOs in one txn.

Bug: entering in bip32 path is tedious

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

The validation should not kick you out to the end of the input field while inputting a bip32 path.

Current Behavior

The cursor moves to end of the line as I edit my bip32 path, see the gif:

Peek 2020-05-18 15-46

Possible Solution

Implement validation that does not affect the cursor.

Steps to Reproduce (for bugs)

  1. Get to any of the inputs for bip32 path
  2. Attempt to change one of the midsections of the path
  3. Note that the cursor jumps to the end

Environment

  • Where are you running caravan: localhost
  • Operating system: Linux
  • Browser and version: Chrome
[email protected] /home/walden/code/caravan
├── [email protected] 
└─┬ [email protected] 
  └── [email protected] 

npm: 6.14.4 
node: v12.16.2
Linux 5.6.13-arch1-1 #1 SMP PREEMPT Thu, 14 May 2020 06:52:53 +0000 x86_64 GNU/Linux

Issue signing with Ledger

I have successfully created a redeem script for a 2 of 2 wallet for the bitcoin testnet, P2SH using a Trezor and Ledger.

BIP32 Paths:

  • Public Key 1: m/45'/1'/0'/0
  • Public Key 2: m/45'/1'/0'/0

I can also confirm ownership using both the Trezor and Ledger.

However, when it comes to actually signing a transaction, after trying to confirm the fee and send on the Ledger, it freezes for about 10 secs, then Caravan gives the following error: Failed to sign with Ledger device: U2F DEVICE_INELIGIBLE. Signing with the Trezor works fine.

On the Ledger I get a message "The derivation path is unusual!" before importing the public key or signing.

I have tried on a Mac and Windows PC to no avail.

Bug: able to create a wallet with one xpub and one tpub

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

An error should be shown to the user and the file rejected.

Current Behavior

Error when attempting to derive a public key from an xpub when creating an address:

Uncaught TypeError: Invalid network version
    at Object.fromBase58 (bip32.js:220)
    at deriveChildPublicKey (keys.js:475)
    at deriveChildPublicKey (keys.js:472)
    at ExtendedPublicKeyPublicKeyImporter._this.import (ExtendedPublicKeyPublicKeyImporter.jsx:117)
    at HTMLUnknownElement.callCallback (react-dom.development.js:336)
    at Object.invokeGuardedCallbackDev (react-dom.development.js:385)
    at invokeGuardedCallback (react-dom.development.js:440)
    at invokeGuardedCallbackAndCatchFirstError (react-dom.development.js:454)
    at executeDispatch (react-dom.development.js:584)
    at executeDispatchesInOrder (react-dom.development.js:609)
    at executeDispatchesAndRelease (react-dom.development.js:713)
    at executeDispatchesAndReleaseTopLevel (react-dom.development.js:722)
    at forEachAccumulated (react-dom.development.js:694)
    at runEventsInBatch (react-dom.development.js:739)
    at runExtractedPluginEventsInBatch (react-dom.development.js:880)
    at handleTopLevel (react-dom.development.js:5807)
    at batchedEventUpdates$1 (react-dom.development.js:24368)
    at batchedEventUpdates (react-dom.development.js:1419)
    at dispatchEventForPluginEventSystem (react-dom.development.js:5898)
    at attemptToDispatchEvent (react-dom.development.js:6014)
    at dispatchEvent (react-dom.development.js:5918)
    at unstable_runWithPriority (scheduler.development.js:818)
    at runWithPriority$2 (react-dom.development.js:12130)
    at discreteUpdates$1 (react-dom.development.js:24384)
    at discreteUpdates (react-dom.development.js:1442)
    at dispatchDiscreteEvent (react-dom.development.js:5885)

Possible Solution

Check during upload for this situation.

Steps to Reproduce (for bugs)

  1. Go to create wallet
  2. Export an xpub/tpub
  3. Switch the network
  4. Export another tpub/xpub
  5. Ensure you have one xpub and one tpub
  6. Create the wallet
  7. Note error

Secondary occurrence:

  1. Go to create address page
  2. Select "Derive from Extended Public Key"
  3. Paste in tpub
  4. Note that it was converted to an xpub
  5. Swtich to testnet
  6. Click import Public Key
  7. Note above error

Environment

  • Where are you running caravan: localhost
  • Operating system: Linux
  • Browser and version: Chrome
[email protected] /home/walden/code/caravan
├── [email protected] 
└─┬ [email protected] 
  └── [email protected] 

npm: 6.14.4 
node: v12.16.2
Linux 5.6.13-arch1-1 #1 SMP PREEMPT Thu, 14 May 2020 06:52:53 +0000 x86_64 GNU/Linux

Can't Use Trezor for Testnet Send if Imported with Xpub

Setting up a multi-sig wallet using accessible and remote (inaccessible) hardware devices. Have remote user pull xpub from a Trezor or Ledger that is not accessible to me.

Using the xpub to import public key, the default "m/0" BIP32 path routes to the address stored at the "m/45'/0'/0'/0" BIP32 path on either device.

Clearly any user would desire to test out the setup on testnet before migrating to mainnet. The Trezor input on the spend screen doesn't permit utilizing the "m/45'/0'/0'/0" BIP32 path on testnet (but does allow for Ledger). This seems problematic and am not sure if similar issues are present when attempting to utilize on mainnet.

Bug: no warning that you are unable to sign p2wsh with hermit when creating a new address/wallet

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

We should show a warning when attempting to create a p2wsh address or wallet with hermit as one of the signers or prevent the user from doing so as they cannot sign with hermit.

Current Behavior

You are not prevented from creating an address or wallet. When you go to sign a transaction the signature UI simply isn't shown, there are no error messages:

gscreenshot_2020-05-12-114432
gscreenshot_2020-05-12-114610

Possible Solution

Show a message or prevent the user from creating a p2wsh address or wallet with hermit.

Steps to Reproduce (for bugs)

  1. Create a P2WSH address or wallet with hermit as one of the quorum
  2. Attempt to spend
  3. Note that the UI isn't shown and there is no message about why you can’t sign

Environment

  • Where are you running caravan: localhost
  • Operating system: Linux
  • Browser and version: Chrome
[email protected] /home/walden/code/caravan
├── [email protected] 
└─┬ [email protected] 
  └── [email protected] 

npm: 6.14.4 
node: v12.16.2
Linux 5.6.13-arch1-1 #1 SMP PREEMPT Thu, 14 May 2020 06:52:53 +0000 x86_64 GNU/Linux

Pasting partial signature from PSBT returns invalid json error

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

Paste in a partial signature from a multi-sig psbt to spend a transaction via Caravan.

Current Behavior

I have gotten as far as pasting in individual signature as text to however when I paste in a "partial_signature" from a psbt such as:

031cfd094b7b0606580f43c0fe76406eb26a2b47ac16fe67b2e753e84ebb94cc70 = 304402206143e552e0a90451ab4c7114eac4c85bc0a77894484d0039891867b210964c700220065a230ae7e3bdf1d4ba67f3fdb71a7dca59e05c409f7961cae0115cfee54b5b01

I get an error Invalid JSON.

Steps to Reproduce (for bugs)

  1. step 1 - paste in a witness script to spend
  2. step 2 - paste in an address to receive to
  3. step 3 - convert unsigned raw transaction to a psbt
  4. step 4 - process the psbt which signs it
  5. step 5 - paste in the signature

Environment

  • Where are you running caravan: localhost
  • Operating system: mac
  • Browser and version: safari

npm: 6.5.0-next.0
node: v11.6.0
uname: illegal option -- i
usage: uname [-amnprsv]
ProductName: Mac OS X
ProductVersion: 10.15.4
BuildVersion: 19E242d

Issue: Invalid JSON when entering signature as text (Testnet)

I ran in to an issue the other day trying to spend from my test 2-of-3 multisig testnet address I made with Caravan. I'm getting an error ("Invalid JSON.") when I try to submit one of the signed transactions as text.

Below is the flow for what I'm doing, and resulting in the error. I've tried a lot of different combinations and addresses, no luck with any of them. Seems similar to another issue someone was having, but I wanted to provide much more info.

Overall questions:

  • Am I doing anything wrong, or is this a bug?
  • Is there a better way to be signing transactions? (other than a hardware wallet)

Step 1: Plugged in redeem script Caravan to spend from.
Redeem Script:
5221021b8f2ed15ce1311860387bc77589c160c41e57379a5a70cd73559b2e19d9d97d21038285e1e8d8512fc52dcc295e673f904fbf7d8084be450b11207b7b8aa26b46262103dfcfda3af5ad4bf015793f57fee87a863696e80274bcd2d177c9b3336a46db5553ae

Step 2: Click "Spend" and input transaction details.
I filled out the destination address, along with fees and amount.

Destination address: mzLqXEdcPnBu4i87D9eNem2JbdDNMxF79o
Amount: 0.00999643
Fee Rate (Sats/byte): 2
Estimated Fees: 0.00000357
Inputs Total: 0.01
Outputs Total: 0.01

Step 3: (I assume) the next step is to sign the resulting unsigned transaction given under "Signature 1" after I select the "Enter as Text" method.

Step 3a: Get the unsigned transaction.
Given unsigned transaction:
0100000001328d532a8eb39706d97a0ccf2df85b2ba6190b33e336b79bb46ce44cc31cdea20000000000ffffffff01763f0f00000000001976a914ce8093a1aef54b6daa6f6ec222bfb3df1107570688ac00000000

Step 3b: Sign the above unsigned transaction

I went over to https://inblockchain.it/ to sign/verify the transaction, script, everything. Make sure to change to "Bitcoin (testnet)" in settings tab in the upper right first.

I signed it with the second address in the 2-of-3:
Address: n4W379boy2thkBz8uiG1ZLMDDxxQE5cDD9
Public Key: 038285e1e8d8512fc52dcc295e673f904fbf7d8084be450b11207b7b8aa26b4626
Private Key: Available if needed. It's testnet, after all.

Signed transaction given is:
0100000001328d532a8eb39706d97a0ccf2df85b2ba6190b33e336b79bb46ce44cc31cdea2000000006a47304402203252ec9d42bdd92dbb68322b81809e18146c3ef4bd531b240d7a02067cefecf802207cea6216d05792dda0f067bba06374cbb0cf7fc461e69ae02134364448f4f9a60121038285e1e8d8512fc52dcc295e673f904fbf7d8084be450b11207b7b8aa26b4626ffffffff01763f0f00000000001976a914ce8093a1aef54b6daa6f6ec222bfb3df1107570688ac00000000

Step 4: Verify everything.
I went to the "Verify" tab to double check the amounts and destination address look good, and that it's marked as signed. Confirmed my signing address's public key was one of the 2-of-3 quorum by verifying the redeem script as well. Everything checked out.

Step 5: Go back to Caravan, add this signed transaction as the "Signature" for the "Enter as text" method under "Signature 1".

The issue: The box border turns red and returns an "Invalid JSON." error. Clicking "Add Signature" does nothing.

Troubleshooting steps taken so far:

  • I went back and repeated the steps from 3a to 5 with the other two addresses in the 2-of-3 quorum, thinking it may have something to do with the order in which the signed transaction text was submitted. I got the issue when signing with the other keys as well.
  • I checked for leading/trailing spaces. Looks clean.
  • I verified the signed transaction using the "Verify" tool on the site above and didn't notice any discrepancies, but I'm not the most technical.
  • I verified the redeem script was indeed referencing the addresses/keys I was signing with.

Keep Zpub or Ypub in json config

if I import Zpub it is immediately converted to xpub e.g.:
Zpub6xvDzwpKHczhpJzkkveFAqAsayzq7dC49Rr3R1qP8cGivqrMbUEip1fRbThiDLhtWA9EptBSVvUrKdrwwp7jt4bePNL3b7d9bo9EvgBQB4T
->
xpub68McGNk3RJMNh9T99Yc1vae4XFfg22XTzw9vvxn4zpgZCTezKkXKUmVDkLq4f6B9TQqeTLzChPPFRu24DC8m977mpDpo1tXBAck5Za3Vosz

If I later take the xpub from json and put it to electrum it doesn't work :-(

I'm submitting a Bug report

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

as per slip-0132 https://github.com/satoshilabs/slips/blob/master/slip-0132.md based on script type extended public key should start with
P2SH: xpub
Multi-signature P2WSH in P2SH: Ypub
Multi-signature P2WSH: Zpub

I would want to convert to appropriate type *pub based address type

Current Behavior

Currently regardless of address type extended public key is always converted to xpub.
It shows incorrect error message: "Your extended public key has been converted from Zpub to xpub, this may indicate an invalid network setting, if so correct setting, remove key and try again"

Possible Solution

Steps to Reproduce (for bugs)

  1. go to https://unchained-capital.github.io/caravan/#/wallet
  2. Swtich to P2WSH address type
  3. Extended Public Key 1: "Enter as text"
  4. paste: Zpub6xvDzwpKHczhpJzkkveFAqAsayzq7dC49Rr3R1qP8cGivqrMbUEip1fRbThiDLhtWA9EptBSVvUrKdrwwp7jt4bePNL3b7d9bo9EvgBQB4T

Environment

Add Check Address on Device for Trezor in Script Explorer

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

Under the Confirm Ownership button on Script Explorer, if a Trezor is selected to confirm the ownership of an address, the "confirm on device option" should be enabled by default, as it provides a more trustless confirmation of address ownership than exporting a pubkey.

Current Behavior

Currently "Confirm Ownership" in the Script Explorer exports and checks a pubkey from Trezors

Bug: Images are missing for ledger wallet instructions when signing a transaction

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

Ledger wallet instructions should be displayed.

Current Behavior

See screenshot. The images for the ledger steps are missing when you attempt to sign a transaction:

82fd277c-777a-4fd4-ad66-32c40431bdfb

Possible Solution

This could actually be a problem in unchained-wallets.

Steps to Reproduce (for bugs)

  1. Create a wallet that includes a ledger as one of the xpubs
  2. Create a spend transaction
  3. Attempt to sign with the ledger
  4. Note that images are missing

Environment

  • Where are you running caravan: localhost
  • Operating system: Linux
  • Browser and version: Chrome
[email protected] /home/walden/code/caravan
├── [email protected] 
└─┬ [email protected] 
  └── [email protected] 

npm: 6.14.4 
node: v12.16.2
Linux 5.6.13-arch1-1 #1 SMP PREEMPT Thu, 14 May 2020 06:52:53 +0000 x86_64 GNU/Linux

Feature Request: Add Watch Only Address to bitcoind wallet

When operating in 'interact' mode, while using a private bitcoins node, one has to manually ensure that the multisig address one is spending from has been added to bitcoind's wallet. It would be super convenient if caravan had a mechanism to make the call to add the address in question from the interact page.

Using with Cold Card

Hey --

I emailed @bucko13 about this last week and have been hacking away at a solution to use my 3 Cold Card Hardware Wallets to create a multisig wallet with Caravan but am still running into issues, so I am going to move the conversation to here.

Right now my workflow is as follows:

  1. Export each xpub from path m/48'/1'/0'/2' (I am not sure why we use 2' at the end, but that seems to be what coldcard does natively when creating a multisig on their device).
// I know this is insecure, these are just play cold cards, no real funds
const JB_MASTER_XPUB = "tpubDECB21DPAjBvUtqSCGWHJrbh6nSg9JojqmoMBuS5jGKTFvYJb784Pu5hwq8vSpH6vkk3dZmjA3yR7mGbrs3antkL6BHVHAyjPeeJyAiVARA"; // xfp (9130C3D6)
const DAS_MASTER_XPUB = "tpubDDv6Az73JkvvPQPFdytkRrizpdxWtHTE6gHywCRqPu3nz2YdHDG5AnbzkJWJhtYwEJDR3eENpQQZyUxtFFRRC2K1PEGdwGZJYuji8QcaX4Z"; // xfp (34ECF56B)
const SUNNY_MASTER_XPUB = "tpubDFR1fvmcdWbMMDn6ttHPgHi2Jt92UkcBmzZ8MX6QuoupcDhY7qoKsjSG2MFvN66r2zQbZrdjfS6XtTv8BjED11hUMq3kW2rc3CLTjBZWWFb"; // xfp (4F60D1C9)
  1. Open Caravan and create a new wallet

  2. Use the Derive from extended public key option and paste in the xpubs from Step 1 for each device. Note: I am leaving the BIP32 path at default (m/0). Is this correct?

After doing that, I have my wallet created. And I am able to generate addresses in the Receive tab. I then send test bitcoin to the address displayed (blockstream link).

Now for spending...

  1. I go to the Spend tab and click manual and select the UTXO I just sent myself

  2. I take the Witness Script (WITNESS_SCRIPT) from the Scripts ... menu and copy the address (SCRIPT_PUB_KEY_ADDRESS) and put them into the script below.

  3. I type in the faucet return address I got the test btc from (2NGZrVvZG92qGYqzTLjCAewvPZ7JE8S8VxE) and configure the right amounts with change so that it equals the original UTXOs value.

  4. I click Preview Transaction and take the unsigned transaction and put it in the script below.

import axios from 'axios';
import { Psbt, Transaction, bip32, networks } from 'bitcoinjs-lib';
import {
  blockExplorerAPIURL,
  TESTNET
} from "unchained-bitcoin";

// From Caravan
const UNSIGNED_TRANSACTION = "0100000001e57c0ccb1bccafc93ae5ba88e6b1fadb00ed4d041cf71fa31e3cad1e013388280100000000ffffffff028e1a00000000000017a914ffd0dbb44402d5f8f12d9ba5b484a2c1bb47da4287b80b0000000000002200200f6fecf96fa0472e82b379ea99ec58eb09dfc9c44b23da3e83a0727bc50dee5000000000";
const WITNESS_SCRIPT = "5221025626020fe15c4934e62fdd041499373f64fa576b6ea5adfbe9216a5b61b24e262102a1c872b3added7a69c50678eae4705bbce748911bcacc9e3b6f1272833d5622b2103a8d96b535b9367b3339d4ba0bd79a0a326e910e6c72452b0e7403d61213d9b3353ae"
const SCRIPT_PUB_KEY_ADDRESS = "tb1q48f8tgpfs9zxk07ep3eucks20285rnfskxu0xp3ma29cy5d6s3vs3e6gx5";


// XPub (m/48'/1'/0'/2') from ColdCard
const JB_XPUB = "tpubDECB21DPAjBvUtqSCGWHJrbh6nSg9JojqmoMBuS5jGKTFvYJb784Pu5hwq8vSpH6vkk3dZmjA3yR7mGbrs3antkL6BHVHAyjPeeJyAiVARA"; // xfp (9130C3D6)
const DAS_XPUB = "tpubDDv6Az73JkvvPQPFdytkRrizpdxWtHTE6gHywCRqPu3nz2YdHDG5AnbzkJWJhtYwEJDR3eENpQQZyUxtFFRRC2K1PEGdwGZJYuji8QcaX4Z"; // xfp (34ECF56B)
const SUNNY_XPUB = "tpubDFR1fvmcdWbMMDn6ttHPgHi2Jt92UkcBmzZ8MX6QuoupcDhY7qoKsjSG2MFvN66r2zQbZrdjfS6XtTv8BjED11hUMq3kW2rc3CLTjBZWWFb"; // xfp (4F60D1C9)

const PATH = "m/48'/1'/0'/2'/0/0'";

const main = async () => {
  const tx = Transaction.fromHex(UNSIGNED_TRANSACTION);

  const psbt = new Psbt();
  psbt.setVersion(2);
  psbt.setLocktime(0);

  for (let i = 0; i < tx.ins.length; i++) {
    const txId = tx.ins[i].hash.reverse().toString('hex');
    const txFromBlockstream = await (await axios.get(blockExplorerAPIURL(`/tx/${txId}`, TESTNET))).data;

    const inputUtxo = getUTXOByAddress(txFromBlockstream, SCRIPT_PUB_KEY_ADDRESS);

    const jbHDInterface = bip32.fromBase58(JB_XPUB, networks.testnet);
    const dasHDInterface = bip32.fromBase58(DAS_XPUB, networks.testnet);
    const sunnyHDInterface = bip32.fromBase58(SUNNY_XPUB, networks.testnet);

    psbt.addInput({
      hash: tx.ins[i].hash,
      index: tx.ins[i].index,
      sequence: tx.ins[i].sequence,
      witnessUtxo: {
        script: Buffer.from(
          inputUtxo.scriptpubkey,
          'hex'
        ),
        value: inputUtxo.value
      },
      witnessScript: Buffer.from(WITNESS_SCRIPT, 'hex'),
      bip32Derivation: [
        {
          masterFingerprint: jbHDInterface.fingerprint,
          pubkey: jbHDInterface.derivePath("0/0").publicKey,
          path: PATH,
        },
        {
          masterFingerprint: dasHDInterface.fingerprint,
          pubkey: dasHDInterface.derivePath("0/0").publicKey,
          path: PATH,
        },
        {
          masterFingerprint: sunnyHDInterface.fingerprint,
          pubkey: sunnyHDInterface.derivePath("0/0").publicKey,
          path: PATH,
        }
      ]
      // redeemScript?
    });
  }


  for (let j = 0; j < tx.outs.length; j++) {
    psbt.addOutput({
      redeemScript: tx.outs[j].script,
      script: tx.outs[j].script,
      value: tx.outs[j].value
    });
  }

  return psbt.toBase64();

This returns

cHNidP8BAH4CAAAAASiIMwEerTweox/3HARN7QDb+rHmiLrlOsmvzBvLDHzlAQAAAAD/////Ao4aAAAAAAAAF6kU/9DbtEQC1fjxLZultISiwbtH2kKHuAsAAAAAAAAiACAPb+z5b6BHLoKzeeqZ7FjrCd/JxEsj2j6DoHJ7xQ3uUAAAAAAAAQErECcAAAAAAAAiACCp0nWgKYFEaz/ZDHPMWgp6j0HNMLG48wY76ouCUbqEWQEFaVIhAlYmAg/hXEk05i/dBBSZNz9k+ldrbqWt++khalthsk4mIQKhyHKzrd7XppxQZ46uRwW7znSJEbysyeO28ScoM9ViKyEDqNlrU1uTZ7MznUugvXmgoybpEObHJFKw50A9YSE9mzNTriIGAyIEErL0BQQffuTOA9kTjyEC+eybnl5zNuAf6pdxUq06HLaYsQkwAACAAQAAgAAAAIACAACAAAAAAAAAAIAiBgPZs2BhKxwQyn6qpiv+VcRihe//FftBBqQk8H+YLmaO3BxYoz6GMAAAgAEAAIAAAACAAgAAgAAAAAAAAACAIgYD5COMlBMA/fsBELla1MfIEB6gGi5qERqdqQsCA8I8FFcch8DaOTAAAIABAACAAAAAgAIAAIAAAAAAAAAAgAABABepFP/Q27REAtX48S2bpbSEosG7R9pChwABACIAIA9v7PlvoEcugrN56pnsWOsJ38nESyPaPoOgcnvFDe5QAA==

I then use the output and use signtx command while my ColdCard is plugged in, but I keep getting:

None of the keys involved in this transaction belong to this Coldcard (need 4F60D1C9)

Is there any glaring issue you are seeing to this approach? I feel like I have some sort of disconnect between the way I am constructing HD wallets, etc.

Security warnings about set-value and http-proxy

Security warnings are shown for the packages set-value and http-proxy during install.

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

Installation without security warnings.

Current Behavior

There seem to be two dependencies with security vulnerabilities marked as "high" (whatever that means in JS land).

npm WARN notice [SECURITY] set-value has the following vulnerability: 1 high. Go here for more details: https://www.npmjs.com/advisories?search=set-value&version=2.0.1 - Run `npm i npm@latest -g` to upgrade your npm version, and then `npm audit` to get more info.
npm WARN notice [SECURITY] http-proxy has the following vulnerability: 1 high. Go here for more details: https://www.npmjs.com/advisories?search=http-proxy&version=1.18.1 - Run `npm i npm@latest -g` to upgrade your npm version, and then `npm audit` to get more info.

Possible Solution

Assuming there's a fix upstream upgrading the dependencies might help.

Steps to Reproduce (for bugs)

  1. Fresh Debian 10.4 install
  2. apt install npm
  3. clone caravan repo
  4. npm install

Environment

  • Debian 10.4

  • npm 5.8.0

  • nodejs v10.19.0

  • Where are you running caravan: VM (quite irrelevant)

  • Operating system: Linux (Debian 10.4)

  • Browser and version: N/A

[email protected] /opt/caravan
├── [email protected] 
└─┬ [email protected] 
  └── [email protected] 

npm: 5.8.0 
node: v10.19.0
Linux 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64 GNU/Linux

Remove signature selection dropdown

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

Able to sign without selecting which key you are signing with.

Current Behavior

Currently you can sign on the broadcast transaction page with any valid key but you first have to select which key you want to sign with. Even if you select the other key it still accepts your signature so it seems like we should just remove the select.

In other words, given two signatures "a" and "b", if you select "b" on the broadcast page and sign with "a" then it still accepts the signature. It knows that the signature is actually "a" and only gives me an option to select "b" for the other signature

gscreenshot_2020-05-20-143413

Possible Solution

Remove the key selection dropdown for signatures. We should just allow the user to select the type like they do on the address page:

gscreenshot_2020-05-20-144216

Steps to Reproduce (for bugs)

  1. Create a spend
  2. Go to signing page
  3. Note that you have to select the key to sign

Environment

N/A

Hide wallet tabs while wallet is being loaded

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

The wallet tabs should be disabled when the wallet is loaded.

Peek 2020-04-13 14-46

Current Behavior

The wallet tabs are displayed when the wallet is loading.

Possible Solution

Hide the wallet tabs when the wallet is loading.

Steps to Reproduce (for bugs)

  1. Create/import a wallet
  2. Notice you can click on addresses, receive, and send while importing

Environment

N/A

Bug: uploading a large binary file causes Uncaught DOMException: Failed to execute 'setItem' on 'Storage'

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

Error is shown in the UI.

Current Behavior

I get this when attempting to upload a largish (88MB) file via the import wallet config:

Uncaught DOMException: Failed to execute 'setItem' on 'Storage': Setting the value of 'caravan_config' exceeded the quota.
    at CreateWallet.setConfigJson (https://localhost:3000/caravan/static/js/main.chunk.js:25499:42)
    at FileReader.fileReader.onload (https://localhost:3000/caravan/static/js/main.chunk.js:24996:15)

The error is just shown in the console and doesn't seem to affect anything.

Possible Solution

Check mime type or otherwise attempt to determine if the file is json and/or too large.

Steps to Reproduce (for bugs)

  1. Upload the attached file (or a similar one)
  2. Wait a bit
  3. Note error

Environment

  • Where are you running caravan: localhost
  • Operating system: Linux
  • Browser and version: Chrome
[email protected] /home/walden/code/caravan
├── [email protected] 
└─┬ [email protected] 
  └── [email protected] 

npm: 6.14.4 
node: v12.16.2
Linux 5.6.13-arch1-1 #1 SMP PREEMPT Thu, 14 May 2020 06:52:53 +0000 x86_64 GNU/Linux

Bug: JS error in console when switching from ledger to trezor for signing

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

No error.

Current Behavior

There is an error shown in the console:

Material-UI: the value provided `<1.6.0` to the Tabs component is invalid.
None of the Tabs children have this value.
You can provide one of the following values: One, T. 
    in Tabs (created by WithStyles(ForwardRef(Tabs)))
    in WithStyles(ForwardRef(Tabs)) (at InteractionMessages.jsx:147)
    in InteractionMessages (at HardwareWalletSignatureImporter.jsx:133)
    in HardwareWalletSignatureImporter (at SignatureImporter.jsx:206)
    in SignatureImporter (created by Connect(SignatureImporter))
    in Connect(SignatureImporter) (at ExtendedPublicKeySelector.jsx:73)
    in ExtendedPublicKeySelector (created by Connect(ExtendedPublicKeySelector))
    in Connect(ExtendedPublicKeySelector) (at WalletSign.jsx:111)
    in WalletSign (created by Connect(WalletSign))
    in Connect(WalletSign) (at WalletSpend.jsx:245)
    in WalletSpend (created by Connect(WalletSpend))
    in Connect(WalletSpend) (at WalletControl.jsx:77)
    in WalletControl (created by Connect(WalletControl))
    in Connect(WalletControl) (at WalletGenerator.jsx:381)
    in WalletGenerator (created by Connect(WalletGenerator))
    in Connect(WalletGenerator) (at Wallet/​index.jsx:536)
    in CreateWallet (created by Connect(CreateWallet))
    in Connect(CreateWallet) (created by Route)
    in Route (at App.jsx:27)
    in App (at src/​index.jsx:21)

The error itself doesn't seem to break anything, however.

Possible Solution

Fix error.

Steps to Reproduce (for bugs)

  1. Create wallet with spendable utxos
  2. Create a transaction
  3. Sign with ledger and cause it to fail somehow (unplug it, don't confirm, etc.)
  4. Switch signing to sign with trezor
  5. Note above error

Environment

  • Where are you running caravan: localhost
  • Operating system: Linux
  • Browser and version: Chrome
[email protected] /home/walden/code/caravan
├── [email protected] 
└─┬ [email protected] 
  └── [email protected] 

npm: 6.14.4 
node: v12.16.2
Linux 5.6.13-arch1-1 #1 SMP PREEMPT Thu, 14 May 2020 06:52:53 +0000 x86_64 GNU/Linux

Bug: TypeError: Failed to execute 'readAsText' on 'FileReader': parameter 1 is not of type 'Blob' when uploading invalid wallet configuration

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

No error.

Current Behavior

I get the following when uploading an invalid wallet config and then trying again and cancelling:

Uncaught TypeError: Failed to execute 'readAsText' on 'FileReader': parameter 1 is not of type 'Blob'.
    at CreateWallet._this.handleImport (index.jsx:191)
    at HTMLUnknownElement.callCallback (react-dom.development.js:336)
    at Object.invokeGuardedCallbackDev (react-dom.development.js:385)
    at invokeGuardedCallback (react-dom.development.js:440)
    at invokeGuardedCallbackAndCatchFirstError (react-dom.development.js:454)
    at executeDispatch (react-dom.development.js:584)
    at executeDispatchesInOrder (react-dom.development.js:609)
    at executeDispatchesAndRelease (react-dom.development.js:713)
    at executeDispatchesAndReleaseTopLevel (react-dom.development.js:722)
    at forEachAccumulated (react-dom.development.js:694)
    at runEventsInBatch (react-dom.development.js:739)
    at runExtractedPluginEventsInBatch (react-dom.development.js:880)
    at handleTopLevel (react-dom.development.js:5807)
    at batchedEventUpdates$1 (react-dom.development.js:24368)
    at batchedEventUpdates (react-dom.development.js:1419)
    at dispatchEventForPluginEventSystem (react-dom.development.js:5898)
    at attemptToDispatchEvent (react-dom.development.js:6014)
    at dispatchEvent (react-dom.development.js:5918)

Possible Solution

Rework file upload logic?

Steps to Reproduce (for bugs)

  1. Upload invalid wallet configuration file (invalid json, mainnet tpub mismatch, etc.)
  2. Click upload again but click cancel
  3. Note above error

Environment

  • Where are you running caravan: localhost
  • Operating system: Linux
  • Browser and version: Chrome
[email protected] /home/walden/code/caravan
├── [email protected] 
└─┬ [email protected] 
  └── [email protected] 

npm: 6.14.4 
node: v12.16.2
Linux 5.6.13-arch1-1 #1 SMP PREEMPT Thu, 14 May 2020 06:52:53 +0000 x86_64 GNU/Linux

Hermit Test Suite broken

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

I should be able to run the test suite using hermit as the wallet.

Current Behavior

After clicking 'Begin Test Suite' I see this error:
Screen Shot 2020-05-15 at 2 01 34 PM

Which isn't being handled cleanly.

Steps to Reproduce (for bugs)

  1. Go to the Test Suite
  2. Select 'Hermit'
  3. Enter a version number
  4. Enter a note
  5. Click 'Begin Test Suite'

Environment

  • Where are you running caravan: localhost, running wallet-dev branch
  • Operating system: Mac 10.15.4
  • Browser and version: Chrome 81.0.4044.129

[email protected]
├── [email protected]
└─┬ [email protected]
└── [email protected]

npm: 6.14.4
node: v12.16.3

QR Code for descriptor?

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Current Behavior

Currently, Caravan generates a redeem script. Then puts all the needed information into a convenient text file. However when storing for long term usage (eg. in envelope, geographically distributed), redeem script can be a privacy leak.

Possible Solution

I could be wrong here, but would it be possible to get this information into a QR code instead? So it's less obvious what the information is. Could be something like used here in yeticold:
https://github.com/JWWeatherman/yeticold/blob/master/templates/YCdisplaydescriptor.html

(I could be totally misunderstanding the difference between the two features).

Change isn't included when spending until the wallet is refreshed

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

Change should be counted as part of the wallet total.

Current Behavior

Change isn't counted as part of the total. Requests are made for the next receiving address and a prior receiving address rather than the change address from the transaction.

Change is shown upon refresh of the wallet.

Possible Solution

Count change as part of the total.

Steps to Reproduce (for bugs)

  1. Construct a spend that will result in change
  2. Sign and broadcast transaction
  3. Note that your change isn't included in the total.

Environment

  • Where are you running caravan: any
  • Operating system: any
  • Browser and version: any
[email protected]
├── [email protected] 
└─┬ [email protected] 
  └── [email protected] 

npm: 6.14.4 
node: v12.16.2
Linux 5.6.13-arch1-1 #1 SMP PREEMPT Thu, 14 May 2020 06:52:53 +0000 x86_64 GNU/Linux

Bug: dust limit for bech32 is incorrect (0.00000546 vs 0.00000294)

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

The minimum spend for a bech32 address should be 0.00000294.

Current Behavior

The minimum spend for a bech32 address is set incorrectly as 0.00000546.

Possible Solution

Calculate dust limit based on address type.

Steps to Reproduce (for bugs)

  1. Set up wallet and go to send
  2. Paste in bech32 address
  3. Attempt to send 1 sat over the dust limit for bech32
  4. Note you cannot

Environment

  • Where are you running caravan: localhost
  • Operating system: Linux
  • Browser and version: Chrome
[email protected] /home/walden/code/caravan
├── [email protected] 
└─┬ [email protected] 
  └── [email protected] 

npm: 6.14.4 
node: v12.16.2
Linux 5.6.13-arch1-1 #1 SMP PREEMPT Thu, 14 May 2020 06:52:53 +0000 x86_64 GNU/Linux

Bug: : Output is too small when attempting to send change below the dust limit

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

Should be prevented from advancing to the preview transaction page and an error should be shown.

Current Behavior

Peek 2020-04-28 09-50

Uncaught Error: Output amount is too small.
    at unsignedMultisigTransaction (transactions.js:98)
    at finalizeOutputs (transactionReducer.js:268)
    at transactionReducer.js:489
    at combination (redux.js:458)
    at combination (redux.js:458)
    at rootReducer (index.js:51)
    at p (<anonymous>:1:36402)
    at v (<anonymous>:1:36684)
    at <anonymous>:1:40069
    at Object.dispatch (redux.js:212)
    at e (<anonymous>:1:40553)
    at index.js:11
    at Object.dispatch (index.js:23)
    at dispatch (<anonymous>:1:28545)
    at redux.js:475
    at WalletSpend._this.showPreview (WalletSpend.jsx:103)
    at HTMLUnknownElement.callCallback (react-dom.development.js:336)
    at Object.invokeGuardedCallbackDev (react-dom.development.js:385)
    at invokeGuardedCallback (react-dom.development.js:440)
    at invokeGuardedCallbackAndCatchFirstError (react-dom.development.js:454)
    at executeDispatch (react-dom.development.js:584)
    at executeDispatchesInOrder (react-dom.development.js:609)
    at executeDispatchesAndRelease (react-dom.development.js:713)
    at executeDispatchesAndReleaseTopLevel (react-dom.development.js:722)
    at forEachAccumulated (react-dom.development.js:694)
    at runEventsInBatch (react-dom.development.js:739)
    at runExtractedPluginEventsInBatch (react-dom.development.js:880)
    at handleTopLevel (react-dom.development.js:5807)
    at batchedEventUpdates$1 (react-dom.development.js:24368)
    at batchedEventUpdates (react-dom.development.js:1419)
    at dispatchEventForPluginEventSystem (react-dom.development.js:5898)
    at attemptToDispatchEvent (react-dom.development.js:6014)
    at dispatchEvent (react-dom.development.js:5918)
    at unstable_runWithPriority (scheduler.development.js:818)
    at runWithPriority$2 (react-dom.development.js:12130)
    at discreteUpdates$1 (react-dom.development.js:24384)
    at discreteUpdates (react-dom.development.js:1442)
    at dispatchDiscreteEvent (react-dom.development.js:5885)

Possible Solution

Show error and prevent the user from advancing to the preview transaction page.

Steps to Reproduce (for bugs)

  1. Setup a wallet with a balance
  2. Go to spend page
  3. Enter address and amount less than your balance
  4. Switch to manual mdoe
  5. Edit the change output to be below the dust limit
  6. Increase other output (if applicable)
  7. Click preview transaction
  8. Note error

Environment

  • Where are you running caravan: localhost
  • Operating system: Linux
  • Browser and version: Chrome
[email protected] /home/walden/code/alt-caravan
├── [email protected] 
└─┬ [email protected] 
  └── [email protected] 

npm: 6.14.4 
node: v12.16.2
Linux 5.6.13-arch1-1 #1 SMP PREEMPT Thu, 14 May 2020 06:52:53 +0000 x86_64 GNU/Linux

Javascript error when selecting <Select Extended Public Key> while confirming ownership

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

No error.

Current Behavior

I get the following error when confirming an address if I select an xpub and then select "Select Extended Public Key":

Uncaught TypeError: Cannot read property 'method' of undefined
    at keySelected (ConfirmAddress.jsx:79)
    at ExtendedPublicKeySelector._this.handleKeyChange (ExtendedPublicKeySelector.jsx:177)
    at handleChange (InputBase.js:369)
    at SelectInput.js:203
    at HTMLUnknownElement.callCallback (react-dom.development.js:188)
    at Object.invokeGuardedCallbackDev (react-dom.development.js:237)
    at invokeGuardedCallback (react-dom.development.js:292)
    at invokeGuardedCallbackAndCatchFirstError (react-dom.development.js:306)
    at executeDispatch (react-dom.development.js:389)
    at executeDispatchesInOrder (react-dom.development.js:411)
    at executeDispatchesAndRelease (react-dom.development.js:3278)
    at executeDispatchesAndReleaseTopLevel (react-dom.development.js:3287)
    at forEachAccumulated (react-dom.development.js:3259)
    at runEventsInBatch (react-dom.development.js:3304)
    at runExtractedPluginEventsInBatch (react-dom.development.js:3514)
    at handleTopLevel (react-dom.development.js:3558)
    at batchedEventUpdates$1 (react-dom.development.js:21871)
    at batchedEventUpdates (react-dom.development.js:795)
    at dispatchEventForLegacyPluginEventSystem (react-dom.development.js:3568)
    at attemptToDispatchEvent (react-dom.development.js:4267)
    at dispatchEvent (react-dom.development.js:4189)
    at unstable_runWithPriority (scheduler.development.js:653)
    at runWithPriority$1 (react-dom.development.js:11039)
    at discreteUpdates$1 (react-dom.development.js:21887)
    at discreteUpdates (react-dom.development.js:806)
    at dispatchDiscreteEvent (react-dom.development.js:4168)

Possible Solution

Fix the error.

Steps to Reproduce (for bugs)

  1. Setup a wallet
  2. Go to address list page
  3. Expand an address
  4. Click on Confirm Ownership
  5. Select an xpub
  6. Select "Select Extended Public Key"
  7. Note error

Environment

  • Where are you running caravan: localhost
  • Operating system: Linux
  • Browser and version: Chrome
[email protected] /home/walden/code/caravan
├── [email protected] 
└─┬ [email protected] 
  └── [email protected] 

npm: 6.14.4 
node: v12.16.2
Linux 5.6.13-arch1-1 #1 SMP PREEMPT Thu, 14 May 2020 06:52:53 +0000 x86_64 GNU/Linux

Script explorer confirm ownership is a dead end

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

Should be allowed to get back to address actions.

Current Behavior

Once you confirm the ownership of a multisig address in the script explorer you reach a dead end, you have to reload the page to do anything else. Even if you change the address you still cannot go back to spend from the address without reloading.

Peek 2020-04-28 18-19

Possible Solution

Add a reset or back button that allows you to go back.

Steps to Reproduce (for bugs)

  1. Create or find a redeem script
  2. Go to Script Explorer page
  3. Paste in script
  4. Confirm ownership
  5. Notice you cannot get back to the ability to spend

Environment

  • Where are you running caravan: localhost
  • Operating system: Linux
  • Browser and version: Chrome
[email protected] /home/walden/code/caravan
├── [email protected] 
└─┬ [email protected] 
  └── [email protected] 

npm: 6.14.4 
node: v12.16.2
Linux 5.6.13-arch1-1 #1 SMP PREEMPT Thu, 14 May 2020 06:52:53 +0000 x86_64 GNU/Linux

Feature Request: Complex multi-sig

I'd like to be able to create a wallet where the funds with eg keys A, B, C, and D, where:

  1. Funds can be spent using only key A
  2. Funds can be spent using 2/3 out of B, C, and D.

To do this, I propose extending the Quorum UI element so you can add additional N-of-M options. So you would have something that says:

+    +
2 of 3
-      -
Add Condition

And when "Add Condition" is clicked, it shows another line:

+    +
2 of 3
-      -
+    +
2 of 3
-      -
Add Condition

There would then have to be a corresponding way to decide which public key on the left went to which quorum on the right.

Doesn't make sense to enter xpub via "Derive from extended public key"

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

When creating a new wallet, each extended public key offers a dropdown with choices: Trezor, Ledger, Hermit, Derive from extended public key, or Enter as text.

That fourth option doesn't make any sense. It seems to be a holdover from the single-pubkey days. It offers a field for the xpub and another field for the BIP32 path.

Shouldn't I just use "Enter as text" and choose a BIP32 path later?

Bug: caravan Test Suite detect version does not work for newer ledger firmwares

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

Detect version should work for all hardware wallets.

Current Behavior

I get an error when attempting to detect the version of most ledgers:

TransportError {name: "TransportError", message: "Failed to sign with Ledger device: U2F DEVICE_INELIGIBLE", stack: "Error↵    at new TransportError (https://localhost…calhost:3000/caravan/static/js/1.chunk.js:3359:13", id: "U2F_4", originalError: Error: Sign failed
    at makeError (https://localhost:3000/caravan/static/js/1.chunk.js:350560:15)…}

I tried with the following wallets:

  • Ledger Nano S v1.5.5 (MCU v1.7)
  • Ledger Nano S v1.6.0 (MCU v1.11)
  • Ledger Nano X v1.2.4-1 (MCU 2.8)

The only one that worked was:

  • Ledger Nano S v1.5.5 (MCU v1.7)

gscreenshot_2020-04-29-204055

Possible Solution

Fix the above.

Steps to Reproduce (for bugs)

  1. Go to test suite
  2. Attempt to detect version of ledger
  3. Note error

Environment

  • Where are you running caravan: localhost
  • Operating system: Linux
  • Browser and version: Chrome
[email protected] /home/walden/code/caravan
├── [email protected] 
└─┬ [email protected] 
  └── [email protected] 

npm: 6.14.4 
node: v12.16.2
Linux 5.6.13-arch1-1 #1 SMP PREEMPT Thu, 14 May 2020 06:52:53 +0000 x86_64 GNU/Linux

Open menu links in new tab

On the current deployment of Caravan, if I click on a menu item, it opens in the current tab, which erases any current work being done in the browser.

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

Clicking a menu item ought to open a new tab for a new Caravan environment.

Current Behavior

Clicking a menu item opens the new Caravan page in the same tab.

Possible Solution

Use target="_blank" rel="noopener noreferrer" on menu items.

Steps to Reproduce (for bugs)

  1. Build a wallet.
  2. Look at the current UTXOs.
  3. Click on CreateAddress in the Menu.

Environment

  • Where are you running caravan: unchained-capital.github.io
  • Operating system: Mac
  • Browser and version: Firefox

Bug: possible to construct a transaction with an output equal to an input

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

Should not be able to construct a transaction with an output address equal to an input address.

Current Behavior

It's possible to construct a transaction with an output equal to an input

See also the gif and screenshot:

Peek 2020-04-27 11-00
gscreenshot_2020-04-27-103714

Note that in the gif I don't sign the transaction but it is possible to do so, see https://blockstream.info/testnet/tx/861c1201d3600adc2b17bc4b1cdb0764aaf1c0d891ca581e2080044a2f33e6c1?expand

Possible Solution

Prevent the above and show an error message.

Steps to Reproduce (for bugs)

  1. Setup a funded wallet
  2. Copy an address and note the balance
  3. Paste the address into the output text field
  4. Set the amount to the same amount as the address balance
  5. Click preview transaction
  6. Note that one of your output addresses is the same as one of your input addresses

Environment

  • Where are you running caravan: localhost
  • Operating system: Linux
  • Browser and version: Chrome
[email protected] /home/walden/code/caravan
├── [email protected] 
└─┬ [email protected] 
  └── [email protected] 

npm: 6.14.4 
node: v12.16.2
Linux 5.6.13-arch1-1 #1 SMP PREEMPT Thu, 14 May 2020 06:52:53 +0000 x86_64 GNU/Linux

Bug: ledger images missing in test runner signing tests

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

Images should be shown.

Current Behavior

Now images:

gscreenshot_2020-04-29-203306

Possible Solution

Show the images.

Steps to Reproduce (for bugs)

  1. Go to test runner
  2. Set up ledger device with words
  3. Go to test 25 or so
  4. Start test
  5. Note missing images

Environment

  • Where are you running caravan: localhost
  • Operating system: Linux
  • Browser and version: Chrome
[email protected] /home/walden/code/caravan
├── [email protected] 
└─┬ [email protected] 
  └── [email protected] 

npm: 6.14.4 
node: v12.16.2
Linux 5.6.13-arch1-1 #1 SMP PREEMPT Thu, 14 May 2020 06:52:53 +0000 x86_64 GNU/Linux

Unrestrict device on Wallet confirming and signing pages

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

Should be able to confirm on device and sign with any device type not just the device type the wallet was created with.

Current Behavior

You can only confirm and sign with the device type that you created the wallet with.

Screen Shot 2020-05-19 at 4 30 19 PM

Screen Shot 2020-05-19 at 4 19 13 PM

Possible Solution

Treat this similarly to addresses where you can confirm and sign with any device type.

Steps to Reproduce (for bugs)

N/A

Environment

  • Where are you running caravan: localhost
  • Operating system: Linux
  • Browser and version: Chrome
[email protected] /home/walden/code/caravan
├── [email protected] 
└─┬ [email protected] 
  └── [email protected] 

npm: 6.14.4 
node: v12.16.2
Linux 5.6.13-arch1-1 #1 SMP PREEMPT Thu, 14 May 2020 06:52:53 +0000 x86_64 GNU/Linux

Able to rebroadcast a transaction that is already in the block chain

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

Caravan should not construct transactions that are not able to be broadcast.

Current Behavior

I get these errors depending on the broken state of the spend:

There was an error broadcasting the transaction.: sendrawtransaction RPC error: {"code":-27,"message":"Transaction already in block chain"}
There was an error broadcasting the transaction.: sendrawtransaction RPC error: {"code":-25,"message":"Missing inputs"}

Possible Solution

Check the transaction before it is broadcast to ensure everything is okay?

Steps to Reproduce (for bugs)

  1. Setup a funded wallet
  2. Self spend
  3. Repeat step 2 and hope you see the error

Sorry these steps aren't better, I'm not entirely sure how I caused this.

Environment

  • Where are you running caravan: localhost
  • Operating system: Linux
  • Browser and version: Chrome
[email protected] /home/walden/code/caravan
├── [email protected] 
└─┬ [email protected] 
  └── [email protected] 

npm: 6.14.4 
node: v12.16.2
Linux 5.6.13-arch1-1 #1 SMP PREEMPT Thu, 14 May 2020 06:52:53 +0000 x86_64 GNU/Linux

Bug: TypeError when pointing to a node on the wrong network

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

An error should be displayed and the wallet creation prevented.

Current Behavior

I get the following error when I create a mainnet wallet and point it at a testnet node:

Uncaught (in promise) TypeError: inputs.sort is not a function
    at sortInputs (inputs.js:46)
    at _callee$ (blockchain.js:68)
    at tryCatch (runtime.js:45)
    at Generator.invoke [as _invoke] (runtime.js:274)
    at Generator.prototype.<computed> [as next] (runtime.js:97)
    at asyncGeneratorStep (asyncToGenerator.js:3)
    at _next (asyncToGenerator.js:25)

Possible Solution

Show error and prevent wallet creation.

Steps to Reproduce (for bugs)

  1. Set up a testnet node
  2. Create a mainnet wallet being sure to point the wallet to your node
  3. Click confirm
  4. Note error

Environment

  • Where are you running caravan: localhost
  • Operating system: Linux
  • Browser and version: Chrome
[email protected] /home/walden/code/caravan
├── [email protected] 
└─┬ [email protected] 
  └── [email protected] 

npm: 6.14.4 
node: v12.16.2
Linux 5.6.13-arch1-1 #1 SMP PREEMPT Thu, 14 May 2020 06:52:53 +0000 x86_64 GNU/Linux

Refactor Request: zero-index transaction outputs

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Current Behavior

Transaction outputs are currently one-indexed.
For an example, see deleteOutput intransactionReducer.js.
This is ripe for a bug.

Possible Solution

Transaction Inputs and Outputs should be zero-indexed everywhere.

Bug: cannot sign a bech32 transaction with hermit in caravan

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

Able to sign a bech32 transaction with hermit in caravan.

Current Behavior

I get the following error when attempting to do so:

Unsupported output address type. bech32 addresses are unsupported.

This is likely just a bug with unchained-wallets see unchained-capital/unchained-wallets#20

Possible Solution

Upgrade unchained-wallets after this has been fixed there.

Steps to Reproduce (for bugs)

  1. Create a p2sh wallet or address using hermit as one of the signers
  2. Create a bech32 spend
  3. Attempt to sign with hermit
  4. Note above message

Environment

  • Where are you running caravan: localhost
  • Operating system: Linux
  • Browser and version: Chrome
[email protected] /home/walden/code/caravan
├── [email protected] 
└─┬ [email protected] 
  └── [email protected] 

npm: 6.14.4 
node: v12.16.2
Linux 5.6.13-arch1-1 #1 SMP PREEMPT Thu, 14 May 2020 06:52:53 +0000 x86_64 GNU/Linux

Improve UX of hardware wallet help text

I'm submitting a…

  • Regression (a behavior that used to work and stopped working in a new release)
  • Bug report
  • Feature request
  • Documentation issue or request
  • Support request

Expected Behavior

The import or sign button should be placed below the hardware wallet informational text because it's confusing. It looks like you there is something to do when there really isn't.

Current Behavior

The informational text is shown below the button and it appears like you need to do something.

gscreenshot_2020-05-20-150142
gscreenshot_2020-05-20-150017

Possible Solution

Either move the informational text above the button and/or have it hidden by default.

Steps to Reproduce (for bugs)

N/A

Environment

N/A

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.