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.
Topic: Can Armory multisig lockbox have more than one funding address? (Read 389 times)
September 27, 2018, 01:48:02 AM
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
:
and
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).
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
:Code:
# Not sure if we really need this...
https://github.com/goatpig/BitcoinArmory/blame/testing/ui/MultiSigDialogs.py#L2983and
Code:
# This is complex, for sure.
# The outermost loop goes over all inputs and outputs
# Then goes over all N public keys
https://github.com/goatpig/BitcoinArmory/blame/testing/ui/MultiSigDialogs.py#L2991# The outermost loop goes over all inputs and outputs
# Then goes over all N public keys
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).
September 26, 2018, 04:33:02 PM
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).
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).
September 26, 2018, 03:27:55 PM
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
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
September 26, 2018, 11:27:18 AM
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.
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.
That's unrelated. Try the current state of testing and let me know.
September 23, 2018, 12:25:42 PM
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.
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.
September 22, 2018, 03:55:05 AM
I'll look into it this weekend and report back.
September 21, 2018, 02:08:26 PM
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:
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.
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.
September 21, 2018, 01:01:24 PM
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:
Path to replicate the bug that I've used:
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
September 17, 2018, 02:06:55 AM
Sent. You can keep them for further testing.
September 17, 2018, 01:31:35 AM
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.
I cannot seem to find a working faucet.
Could you please send some test coins to the following address:
Code:
2N7Ci1mXhFiJBaGGdKQibngJ2cyq2vKCFks
I'll send them back after the test.
September 15, 2018, 10:26:05 AM
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.
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.
Quote
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).
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.
Quote
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.
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.
Quote
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.
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.
Quote
3) If you manage to reproduce this on testnet lockboxes, I would like to see those.
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.
September 15, 2018, 05:34:21 AM
Quote
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
(Public key taken from https://github.com/goatpig/BitcoinArmory/blob/master/PublicKeys/goatpig-signing-key.asc
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.
Quote
Otherwise I'll have to look at the lockbox directly.
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.
September 14, 2018, 05:08:03 AM
goatpig, here's the message with the spending info:
Code:
-----BEGIN PGP MESSAGE-----
hQEMA6T8kZ6FxZW6AQgAoAh5DBCE9cgKg7AZ8VAmCF+KhyS+v1+HOMFp7uiGLyIo
QZayJ/tFiavYHTUthC5Z/DTP/RMMWmo2uvx+0DyberRT3m037Z8rq7kgjGComp06
CdxsDbEd9+nGIowmOGx8f8NoACFLR/bM9TFvSpdXFfuNUjwnuw/I+mZ4gAyLff0D
s2uH9wliHJOgWY9faX2oqPg9eJlSATdKZgHTwzmBWya6vP16vxSpjFA7GyvBMV0S
VSomJIGxnvcvZJeH/gAW7jEkj9YJRYOLSkxeXVBK/6DJOPua8YmjLPqp3uytzZO2
C9nv1FY+HB6rIlnhK3nt4URRc7nis5+Mm16kI1rRz9LAMgF86vSg4nY6BeMXSI8I
yvSXSCDaQG+/cnUHN897WQ7EJ3dz6SpctnxE0Og12pxRgy0oSxde0fhJpw0gOv/5
feDkmFUaq9kAibS/lLDETs7ivwgTH/njjy/zL+FCqhgK1ioZ6O67uRlfPUKVgMfT
h+iSq1ye6hXJJEa2i+djCij748jfMa9iSIX5VIp7DRaFZ6P3VjMdkuQrDjyWOt6p
PJ/LVMHcm+7S0qDsauzNA02NVtyN3A1xUefsJo1Me93mBWST9uU0FtAPpnr264TB
9I9C1eYxZYdJdBPeCLO6WsZoIUPYyDLkzs7Wc7AcInOEooV2
=0NqD
-----END PGP MESSAGE-----
September 14, 2018, 04:33:47 AM
Quote
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.
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:
Code:
043b66e3485c4598016ce0efd5dc76a010e513e6f81c212c1337214c31deff606519e3126d7a5148472fd308d68705f6c27b8154550c06702039f142ef6cfbdce3
045f54869961bdc18e61a916a14edc8abecdca9933c269b197874173f34faa4583ef13d07d521d1f8d0dbb627c9f3d8d69b18b9e82cfe52809788d9711327eb3ca
- The resulting lockbox and its generated funding addresses (the second being the segwit) are:
Code:
=====LOCKBOX-zehSFwBp===========================================
AQAAAPm+tNneKj1ZAAAAAAROJkMxAAICTwEAAAD5vrTZQQQ7ZuNIXEWYAWzg79Xc
dqAQ5RPm+BwhLBM3IUwx3v9gZRnjEm16UUhHL9MI1ocF9sJ7gVRVDAZwIDnxQu9s
+9zjAUMAAABPAQAAAPm+tNlBBF9UhplhvcGOYakWoU7cir7Nypkzwmmxl4dBc/NP
qkWD7xPQfVIdH40Nu2J8nz2NabGLnoLP5SgJeI2XETJ+s8oBTgAAAA==
================================================================
32xhZESpnLHGqCW24Suy5aH1ysouTmoFXf
324XvFLqfjvseFVcdzr3Y1GgNAiCMGQFwf
- If you follow the trail of these addresses on the blockchain, 32x was funded, then emptied, then 324 was funded and currently holds funds:
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:
September 13, 2018, 02:29:18 AM
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
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.[/]
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.
September 12, 2018, 12:32:57 PM
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
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.[/]
September 12, 2018, 07:02:58 AM
You should try with the current state of testing, the lockbox GUI stuff is fixed in there.
September 11, 2018, 01:30:06 AM
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!
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:
Code:
=====LOCKBOX-zehSFwBp===========================================
AQAAAPm+tNneKj1ZAAAAAAROJkMxAAICTwEAAAD5vrTZQQQ7ZuNIXEWYAWzg79Xc
dqAQ5RPm+BwhLBM3IUwx3v9gZRnjEm16UUhHL9MI1ocF9sJ7gVRVDAZwIDnxQu9s
+9zjAUMAAABPAQAAAPm+tNlBBF9UhplhvcGOYakWoU7cir7Nypkzwmmxl4dBc/NP
qkWD7xPQfVIdH40Nu2J8nz2NabGLnoLP5SgJeI2XETJ+s8oBTgAAAA==
================================================================
When first created, it generates the following funding address:
Code:
32xhZESpnLHGqCW24Suy5aH1ysouTmoFXf
However this address:
Code:
324XvFLqfjvseFVcdzr3Y1GgNAiCMGQFwf
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:
Code:
f24550eaec58ed47b6db186f6f8e7a70b4dce5fc50668d174a0f063ac9a30ecb
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:
Code:
File "ui\TxFrames.pyc", line 897, in createTxAndBroadcast
File "ui\TxFrames.pyc", line 772, in validateInputsGetUSTX
File "ui\TxFrames.pyc", line 1048, in determineChangeScript
AttributeError: 'MultiSigLockbox' object has no attribute 'getChangeScript'
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:
Code:
createmultisig 2 "[\"043b66e3485c4598016ce0efd5dc76a010e513e6f81c212c1337214c31deff606519e3126d7a5148472fd308d68705f6c27b8154550c06702039f142ef6cfbdce3\",\"045f54869961bdc18e61a916a14edc8abecdca9933c269b197874173f34faa4583ef13d07d521d1f8d0dbb627c9f3d8d69b18b9e82cfe52809788d9711327eb3ca\"]"
with the following funding address (32x) and redeem script:
Code:
{
"address": "32xhZESpnLHGqCW24Suy5aH1ysouTmoFXf",
"redeemScript": "5241043b66e3485c4598016ce0efd5dc76a010e513e6f81c212c1337214c31deff606519e3126d7a5148472fd308d68705f6c27b8154550c06702039f142ef6cfbdce341045f54869961bdc18e61a916a14edc8abecdca9933c269b197874173f34faa4583ef13d07d521d1f8d0dbb627c9f3d8d69b18b9e82cfe52809788d9711327eb3ca52ae"
}
b. Next, I got the data for the last funding transaction of the lockbox using:
Code:
getrawtransaction f24550eaec58ed47b6db186f6f8e7a70b4dce5fc50668d174a0f063ac9a30ecb 1
This generated the data from the blockchain:
Code:
{
"txid": "f24550eaec58ed47b6db186f6f8e7a70b4dce5fc50668d174a0f063ac9a30ecb",
"hash": "b2726bfdd3f0dd145ec48e7851ecf8deb08d66727db5664549242e9fb5579ea6",
"version": 1,
"size": 216,
"vsize": 134,
"locktime": 503335,
"vin": [
{
"txid": "b014d31f214acb421c86c1cb1181b04dea8629b0ca769d96071cac3e9e6a7f8e",
"vout": 0,
"scriptSig": {
"asm": "00145b95f1f9c9959114541b8f586972d44a54cdd581",
"hex": "1600145b95f1f9c9959114541b8f586972d44a54cdd581"
},
"txinwitness": [
"3045022100f9e8dbea1e192b0e118839b3b3ff8b44595db1a4257455dff15dcbd9ca009a36022003affcec437c3a9e4b237f52591057aa2b02b563b97cc4d69c5c29964bb646fc01",
"02cab285794aa129801d1156fb09171bdd67d604a2820ccc0ca110213b23717d8f"
],
"sequence": 4294967293
}
],
"vout": [
{
"value": 1.44737527,
"n": 0,
"scriptPubKey": {
"asm": "OP_HASH160 0411c60ff8322e9f91c10dd02d0f1ad9a7cc591a OP_EQUAL",
"hex": "a9140411c60ff8322e9f91c10dd02d0f1ad9a7cc591a87",
"reqSigs": 1,
"type": "scripthash",
"addresses": [
"324XvFLqfjvseFVcdzr3Y1GgNAiCMGQFwf"
]
}
}
],
"hex": "010000000001018e7f6a9e3eac1c07969d76cab02986ea4db08111cbc1861c42cb4a211fd314b000000000171600145b95f1f9c9959114541b8f586972d44a54cdd581fdffffff01f784a0080000000017a9140411c60ff8322e9f91c10dd02d0f1ad9a7cc591a8702483045022100f9e8dbea1e192b0e118839b3b3ff8b44595db1a4257455dff15dcbd9ca009a36022003affcec437c3a9e4b237f52591057aa2b02b563b97cc4d69c5c29964bb646fc012102cab285794aa129801d1156fb09171bdd67d604a2820ccc0ca110213b23717d8f27ae0700",
"blockhash": "00000000000000000061f5cc49d2fece4f2905f91429facfdeaa0b7ef5a08823",
"confirmations": 37509,
"time": 1515501955,
"blocktime": 1515501955
}
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:
Code:
createrawtransaction "[{\"txid\”:\”f24550eaec58ed47b6db186f6f8e7a70b4dce5fc50668d174a0f063ac9a30ecb\",\"vout\”:1,\"scriptPubKey\”:\”a9140411c60ff8322e9f91c10dd02d0f1ad9a7cc591a87\",\"redeemScript\”:\”5241043b66e3485c4598016ce0efd5dc76a010e513e6f81c212c1337214c31deff606519e3126d7a5148472fd308d68705f6c27b8154550c06702039f142ef6cfbdce341045f54869961bdc18e61a916a14edc8abecdca9933c269b197874173f34faa4583ef13d07d521d1f8d0dbb627c9f3d8d69b18b9e82cfe52809788d9711327eb3ca52ae\"}]" "{\“3JacffNfngThdBdCDMjVEz3axNz31WNKr7\”:144731000}"
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!
September 10, 2018, 08:09:21 PM
The redeem scripts on chain will reveal these are one and the same however, i.e. when you spent from both variants, the txin will carry data that will link the addresses together.
That's good to know
September 10, 2018, 07:06:04 PM
Technically you can't. The multisig script is built from the addresses your provide it. As these don't change per lockbox, neither does the address. However, currently you can get the P2SH legacy multisig and the P2SH P2WPKH segwit variation address for each lockbox. It's a trick that yields 2 different addresses. The redeem scripts on chain will reveal these are one and the same however, i.e. when you spent from both variants, the txin will carry data that will link the addresses together.
September 10, 2018, 01:01:18 PM
Can I generate more than one funding address to an Armory lockbox?
Jump to: