Topic: Can Armory multisig lockbox have more than one funding address? (Read 371 times)

With the encoding used (not sure what it's called anymore), uncompressed keys start with 0x04. Compressing the key means to only carry the X value (first 32) bytes, with an extra leading byte to signify parity and compression (in this case, 0x02 and 0x03). This works because since Y is squared, both positive and negative values of X fit a solution.

While the X value remains the same, parity shenanigans can change the canonical order of the keys, since it is the header byte.

Thanks for the explanation.

In retrospect (always 20-20), I was sniffing close to  the section of the code that turned out to be the issue, in the file /ui/MultiSigDialog.py, which is why I asked you for a confirmation of the file in a previous post.

What made me look closer, however, wasn't any coding expertise unfortunately, (I was having a hard time just getting my head around what I was reading), but these two lines that hinted on fragile code  :

https://github.com/goatpig/BitcoinArmory/blame/testing/ui/MultiSigDialogs.py#L2983

and
https://github.com/goatpig/BitcoinArmory/blame/testing/ui/MultiSigDialogs.py#L2991

But eventually I got derailed by what you commented as unrelated.

I would'nt have guessed that compressing keys changes their order (which is critical for signing a lockbox spending transaction).

Good to hear.

FYI, issue was related to key ordering. Armory orders keys in order to recreate the same multisig script under all circumstances. Legacy Armory MS scripts use uncompressed keys, but all things segwit have to use compressed keys. When compressing the keys, the order may change, and Armory was coded to tie keys to signatures by index (expecting the order to always be enforced). The fix was to assign signatures to their actual keys instead.

Oddly enough, I never ran into that issue when I tested SW lockboxes. For what it's worth, the chance of hitting this bug (compressed keys having a different order than their uncompressed counterparts) is of 25% with 2-of-2 and ~50% chance with 2-of-3.

The end result after the fix is that with SW lockboxes, the key order in script may not necessarily match the order as presented in the GUI (which follows the uncompressed key order always).

goatpig, I think you nailed it!
I could not replicate any of the bugs I've detailed.
I've tested all the paths that led to the two bugs I reported and all ended up working fine with the current state of the testing branch, using the setup on testnet.


I  was also able to (finally!) unlock the mainnet lockbox.

I still have your testing coins. If there's anything else that you'd like me to test/verify - I'd be glad to.

Thanks again for your help

That's unrelated. Try the current state of testing and let me know.

goatpig,
The bug we are running into looks a lot like the problem reported on bitcoin github titled "signrawtransaction unable to sign p2sh-segwit multisig transaction"
here: https://github.com/bitcoin/bitcoin/issues/12418

I think sipa's answers, including the code fix he provides towards the end,  may give a clue to where in Armory code the bug is and how to fix it.
Maybe the solution should be the 'Ugly Workaround' provided in the github issue above?

Could you please point me to the Armory code file where Armory signs multisigs? Perhaps I'll be able to lend a hand there.

Hope this helps.

I'll look into it this weekend and report back.

This is a continuation of my previous post, and documents other bugs found while poking the unlockable lockbox, under the same setup.

Path to second bug:

• Fund lockbox non-segwit address with amount M.
• Fund lockbox segwit address with amount N, N>M.
• Attempting to spend from lockbox an amount less then M works as expected.
  
• Attempting to spend from lockbox an amount > M but less then N, results in the signer bug described earlier.
• Now the new finding: Attempting to spend from the lockbox amount > N, results in 'Signer Type Mismatch' error message box, and no way to go forward

So the lockbox will release only funds that amount to the funds sent to the non-segwit address, fail on the signer bug for amounts that require using funds from the lockbox' segwit address and generate a new bug 'Signer Type Mismatch' error message for amounts that require funds from both the segwit and non-segwit address.

Hope this helps.

I was able to replicate the signing bug that prevents unlocking funds from a lockbox on testnet, fresh wallets.

I described the bug in detail on a previous post,
so I'll just sum up here the environment and a path to replicate the bug.

Environment I used included the following ingredients:

• linux mint 19
• Armory, testing branch compiled from source
• Bitcoin 0.16.2, running separately on testnet
• 3 Armory wallets:, "Primary Wallet", "X Wallet", "Y Wallet"
• a 2 of 2 lockbox "TestBox" created using public keys from "X Wallet" and "Y Wallet"

Path to replicate the bug that I've used:

• Fund Primary Wallet with test coins
• Open Lockbox dialog, copy funding address, Segwit checkbox cleared
• Fund the lockbox from the Primary wallet to the above address, wait for confirmations.
• Empty the lockbox back to the Primary Wallet, using X Wallet and Y Wallet to sign. There should be no problems.
• Open Lockbox dialog, Check Segwit checkbox, copy the address.
• Fund the lockbox from the Primary Wallet, to the lockbox segwit address. Wait for confirmations
• Attempt to empty the lockbox back to the Primary Wallet, and the bug will be manifested. It is impossible to unlock funds from the lockbox

This proof strongly suggests that users should not use lockboxes with segwit checked, as Armory will not be able to release funds from the lockbox.

Sent. You can keep them for further testing.

goatpig, my test setup is about a day from completing sync on testnet3.
I cannot seem to find a working faucet.

Could you please send some test coins to the following address:

I'll send them back after the test.

First of, thanks again for looking into this. Much appreciated.


Sorry, no - I've never tested it with a fresh lockbox. The lockbox worked fine for over a year and the issue is a relatively fresh discovery.


I've never tried anything on testnet, but I'll certainly put the time and energy to do that now. I'll post a funding address when I figure out how to setup the needed environment.


I've had plenty of lockboxes usage (still do), but this one is the only one that got this behavior, and the only one involving segwit as a second funding address (due to an oversight, actually. I had the 'Segwit' checkbox checked by mistake). Took me a while to single that out, but causality-wise, I think it is highly probable that it is tied to the segwit address. You writing that you did not test for that scenario only raises that probability. But we'll know soon enough once I learn how to setup and run testnet environment.

Of course I'll share all findings.

But if I won't be able to reproduce it, I would very much appreciate your help going through the steps with the lockbox I've sent.
You will get stuck in the signature collection phase, not the broadcasting phase, it can be seen with any offline signer that imports the two parties keys I've sent, so I cannot possibly see how that risks any funds. I've made the video using the testing branch built in a unix env that didn't even have a bitcoin node build.

That's my offline signing key for Armory releases, I don't use that for emails. I'm not going to send you the proper key to email. Read further.


That was rhetorical. I do not feel comfortable touching user funds. To make things clear, I don't want to touch your coins, so I'm going to explore other alleys to fix this bug first.

When I reviewed your bug reports prior to the recent commits to the testing branch, you seemed to imply the lockbox signature mismatch issue could happen in any lockbox (I think you claimed to have produce it with a fresh lockbox). Therefor, I have a couple assignments for you:

1) Can you create fresh lockboxes that display this bug using the current state of the testing branch? Please do this on the testnet. If you need testnet coins, post your address here, I'll send you some.

2) If yes, is the issue with SegWit lockboxes only? This thread seems to imply that. I do not remember testing specifically for lockboxes back in August, this could be a key factor.

3) If you manage to reproduce this on testnet lockboxes, I would like to see those.

goatpig, here's the message with the spending info:

goatpig, thanks for looking into this, I'll gladly supply any info you need so we can get to the root cause of this:

• The lockbox was created using the following two public keys:

• The resulting lockbox and its generated funding addresses (the second being the segwit) are:

• If you follow the trail of these addresses on the blockchain, 32x was funded, then emptied, then 324 was funded and currently holds funds:

blockchain addresses:
https://www.blockchain.com/btc/address/32xhZESpnLHGqCW24Suy5aH1ysouTmoFXf
https://www.blockchain.com/btc/address/324XvFLqfjvseFVcdzr3Y1GgNAiCMGQFwf

• Finally, to spend the funds, I've used your BitcoinArmory public PGP key to encrypt and sent the needed information to your associated email:

(Public key taken from https://github.com/goatpig/BitcoinArmory/blob/master/PublicKeys/goatpig-signing-key.asc

I have failed to reproduce this issue on my end, can you elaborate on it? Otherwise I'll have to look at the lockbox directly.

The testing branch doesn't solve the signing problem I was describing (problem 2):

I've compiled Armory with the testing branch (Linux mint 19).

I've documented the problem I've described in the following 8 sec video for the lockbox given above, when attempting to sign:

https://anonfiles.com/I9T0seh8b9/ArmoryVideo_mp4

• It is symetrical: it doesn't matter which 'Sign' button is pressed.
• Clicking the same 'Sign' button twice does nothing further.
• There is nothing in the log files.[/]
  

You should try with the current state of testing, the lockbox GUI stuff is fixed in there.

Hi goatpig,

So here's a lockbox with apparently TWO funding addresses, but no way that I found to spend from:

The lockbox is 2 of 2 and is here:


When first created, it generates the following funding address:
Lets call it 32x for short

However this address:
(lets call it 324)
Also belongs to the lockbox, according to Armory GUI.
Proof: When 324 address is loaded as a recipient on the 'Send Bitcoin' dialog, Armory immediately recognizes it as belonging to the lockbox.

Looking at 32x on the blockchain, it went through a few transaction and emptied into 324 eventually, same lockbox.
The last transaction ID (needed for the spending script) is:
Now the plot thickens:

Trying to spend from the lockbox Armory displays different issues (depending on version), two of which I reported in an earlier thread. In what follows I'm referring to version 0.96.3.99. 0.96.4 has a gui bug.

1. Using 0.96.3.99 (991, 992 are identical) - Trying to spend anything less than max spendable and clicking continue - GUI doesn't respond and log has the following error:

2. Using 0.96.3.99 (991, 992 are identical) - Trying to spend the max BTC (checking MAX checkbox), Review and Sign dialog comes up with thw to parties 'Sign' button next to the green keyholes BUT:
When Party1 clicks 'Sign', Party2 gets a green Checkmark and Party1 'Sign' Button is visible. This is symmetric for Party2. The end result is that Armory doesn't create a broadcasting transaction even though both Private keys are present for signing.

3. Trying to do the legwork for Armory using Bitcoin console I was able to:
    a. recreate the lockbox and redeem script - bitcoind gave 32x as the funding address, as expected. Note: since I'm using the latest version, I had to insert: deprecatedrpc=createmultisig in bitcoin.conf in order to create the lockbox from public keys.

The command I used to create the lockbox:

with the following funding address (32x) and redeem script:


   b. Next, I got the data for the last funding transaction of the lockbox using:

This generated the data from the blockchain:

   c. Here's where I got to another deadend: I can't write a valid createrawtransaction command (ANY help would be appreciated):
I used the above data (from vout section):

txid: "f24550eaec58ed47b6db186f6f8e7a70b4dce5fc50668d174a0f063ac9a30ecb"
vout: 1
scriptpubkey(hex):"a9140411c60ff8322e9f91c10dd02d0f1ad9a7cc591a87",
redeemscript: From above
a spending address: “3JacffNfngThdBdCDMjVEz3axNz31WNKr7
and full amount from the lockbox: 144731000

This is what I sent:

But apperantly, bitcoind couldn't parse it:

Error: Error parsing JSON:[{"txid\”:\”f24550eaec58ed47b6db186f6f8e7a70b4dce5fc50668d174a0f063ac9a30ecb","vout\”:1,"scriptPubKey\”:\”a9140411c60ff8322e9f91c10dd02d0f1ad9a7cc591a87","redeemScript\”:\”5241043b66e3485c4598016ce0efd5dc76a010e513e6f81c212c1337214c31deff606519e3126d7a5148472fd308d68705f6c27b8154550c06702039f142ef6cfbdce341045f54869961bdc18e61a916a14edc8abecdca9933c269b197874173f34faa4583ef13d07d521d1f8d0dbb627c9f3d8d69b18b9e82cfe52809788d9711327eb3ca52ae"}]



Any thoughts/comments would be appreciated!

That's good to know