 Show Posts
|
|
Pages: [1] 2 3 4 »
|
|
If he restores the same environment that created the wallet, and enters the seed that's written in his book and he's getting a different xpub, it's very likely he extended the seed with a passphrase.
|
|
|
|
Try the following: - Try to restore the deleted apk on the signer android using this toolset: https://www.easeus.com/android-data-recovery/recover-deleted-apk-files-android.html. If successful, try entering the seed again. If the resulting xpub is again different, chances are the seed is wrong, skip to the third point.
- Go to https://download.electrum.org/, search for the wallet version that you used to create the seed (based on date), download, install, create a new wallet from your known seed and compare the xpub.
- Another verctor: seeds can have an additional secret passphrase that is added to the seed words Electrum generates. Think hard if you used such an additional passphrase (it isn't supposed to be written anywhere) and if so, if you possibly misspelled it (capitals, spaces)
If you are able to restore everything - congrats! However, look into a more robust operating system for the signer. Android is a toy OS compared to Linux, Windows, MacOS. |
|
|
|
Continuing poking Armory multisig, this post documents a bug in Armory's Simulfund promissory note feature. Tested on: - latest state of testing branch, compiled from source on linux mint 19
- 0.96.4 on windows 10
To recreate: - Under MultiSig menu, click simulfund Promissory Note
- In the Create Simulfunding Promissory Note dialog, enter needed fields: Source of Funding, amount, fee, funding destination address:
- Click continue, and the bug is manifested: nothing happens and the log file has the following error
(ERROR) Traceback (most recent call last):
File "/home/testuser/BitcoinArmory/ui/MultiSigDialogs.py", line 3518, in doContinue
pubKeys = {utxoScrAddr: aobj.binPublicKey65.toBinStr()}
AttributeError: 'NoneType' object has no attribute 'binPublicKey65'
Traceback (most recent call last):
File "/home/testuser/BitcoinArmory/ui/MultiSigDialogs.py", line 3518, in doContinue
pubKeys = {utxoScrAddr: aobj.binPublicKey65.toBinStr()}
AttributeError: 'NoneType' object has no attribute 'binPublicKey65'
Though I may be completely wrong, looking at the MultiSigDialogs.py around the break line, it reminds me a lot of the previous bug, because here too there's a failed attempt to go over a range of pubkeys. |
|
|
|
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  : # Not sure if we really need this...
and # This is complex, for sure.
# 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). |
|
|
|
This is a minor GUI bug: Armory lockbox cannot be deleted from GUI. To replicate: - Create any lockbox if one is not already created
- Click Lockboxes (Multi-Sig) button
- Under Manage Multi-Sig Lockboxes dialog, right-click a lockbox and choose 'Delete Lockbox' - lockbox is not deleted
armorylog.txt has this error: File "ui\MultiSigDialogs.pyc", line 1501, in showLboxContextMenu
File "ArmoryQt.py", line 4851, in getDisplayStringForScript
File "armoryengine\UserAddressUtils.pyc", line 206, in getDisplayStringForScript
File "armoryengine\ArmoryUtils.pyc", line 1656, in scrAddr_to_addrStr
BadAddressError: Invalid ScrAddress
Tested on: - Current state of testing branch, compiled from source on linux mint (19)
- 0.96.4, Windows 10
To circumvent: open file multisigs.txt and manually delete the relevant lockbox. |
|
|
|
|
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
|
|
|
|
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/12418I 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. |
|
|
|
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. |
|
|
|
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: 2N7Ci1mXhFiJBaGGdKQibngJ2cyq2vKCFks I'll send them back after the test. |
|
|
|
First of, thanks again for looking into this. Much appreciated. 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. 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. 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. 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. |
|
|
|
goatpig, here's the message with the spending info: -----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-----
|
|
|
|
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:
043b66e3485c4598016ce0efd5dc76a010e513e6f81c212c1337214c31deff606519e3126d7a5148472fd308d68705f6c27b8154550c06702039f142ef6cfbdce3
045f54869961bdc18e61a916a14edc8abecdca9933c269b197874173f34faa4583ef13d07d521d1f8d0dbb627c9f3d8d69b18b9e82cfe52809788d9711327eb3ca
- The resulting lockbox and its generated funding addresses (the second being the segwit) are:
=====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:
blockchain addresses: https://www.blockchain.com/btc/address/32xhZESpnLHGqCW24Suy5aH1ysouTmoFXfhttps://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 |
|
|
|
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.[/]
|
|
|
|
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: =====LOCKBOX-zehSFwBp===========================================
AQAAAPm+tNneKj1ZAAAAAAROJkMxAAICTwEAAAD5vrTZQQQ7ZuNIXEWYAWzg79Xc
dqAQ5RPm+BwhLBM3IUwx3v9gZRnjEm16UUhHL9MI1ocF9sJ7gVRVDAZwIDnxQu9s
+9zjAUMAAABPAQAAAPm+tNlBBF9UhplhvcGOYakWoU7cir7Nypkzwmmxl4dBc/NP
qkWD7xPQfVIdH40Nu2J8nz2NabGLnoLP5SgJeI2XETJ+s8oBTgAAAA==
================================================================
When first created, it generates the following funding address: 32xhZESpnLHGqCW24Suy5aH1ysouTmoFXf
Lets call it 32x for short However this address: 324XvFLqfjvseFVcdzr3Y1GgNAiCMGQFwf
(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: f24550eaec58ed47b6db186f6f8e7a70b4dce5fc50668d174a0f063ac9a30ecb
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: 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: createmultisig 2 "[\"043b66e3485c4598016ce0efd5dc76a010e513e6f81c212c1337214c31deff606519e3126d7a5148472fd308d68705f6c27b8154550c06702039f142ef6cfbdce3\",\"045f54869961bdc18e61a916a14edc8abecdca9933c269b197874173f34faa4583ef13d07d521d1f8d0dbb627c9f3d8d69b18b9e82cfe52809788d9711327eb3ca\"]"
with the following funding address (32x) and redeem script: {
"address": "32xhZESpnLHGqCW24Suy5aH1ysouTmoFXf",
"redeemScript": "5241043b66e3485c4598016ce0efd5dc76a010e513e6f81c212c1337214c31deff606519e3126d7a5148472fd308d68705f6c27b8154550c06702039f142ef6cfbdce341045f54869961bdc18e61a916a14edc8abecdca9933c269b197874173f34faa4583ef13d07d521d1f8d0dbb627c9f3d8d69b18b9e82cfe52809788d9711327eb3ca52ae"
}
b. Next, I got the data for the last funding transaction of the lockbox using: getrawtransaction f24550eaec58ed47b6db186f6f8e7a70b4dce5fc50668d174a0f063ac9a30ecb 1
This generated the data from the blockchain: {
"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: 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! |
|
|
|
|
Can I generate more than one funding address to an Armory lockbox?
|
|
|
|
|
Anyone else seen this bug in multisig signing, in Armory 0.96.3, 0.96.3.991, 0.96.3.992?
|
|
|
|
|
Goatpig, have you looked into this bug? It results in funds being in a lockbox which cannot be released.
Any help would be appreciated!
|
|
|
|
Testing Armory lockbox 2 of 2 (party N and and party C below) and offline signers, I saw the following bug: After N clicks Review and Sign:  (link: https://imgur.com/Y4PTN2S) So far all is well. Clicking on the green keyhole, N enters his password, Armory unlocks the wallet, but then it marks C as signed:  (link: https://imgur.com/wLe13qT) The end result is that the funds cannot be unlocked from the lockbox as C can sign, but N signer doesn't unlock N, it can only unlock C... This was tested with 0.96.3.99, 0.96.3.991, 0.96.3.992. 0.96.4 does not create a Spending Tx (see previous bug report). There is no error in the signer armorylog. OS is Windows 10. Edit |
|
|
|
When creating a spending Tx from a lockbox (either to a segwit or non-segwit address) after pressing 'Continue', Armory fails with the following error in armorylog.txt: 2018-05-17 21:47:08 (ERROR) -- Traceback (most recent call last):
File "ui\TxFrames.pyc", line 933, in createTxAndBroadcast
File "ui\TxFrames.pyc", line 1605, in updateUserComments
AttributeError: 'NoneType' object has no attribute 'setComment'
OS is Windows 10 |
|
|
|
|
