Pages:
Author

Topic: [ANN] Armory Multi-Sig with Simulfunding [BOUNTY 0.03 per bug] - page 5. (Read 16304 times)

sr. member
Activity: 312
Merit: 250
2- I don't understand why is possible to edit a created lockbox.

Already got you covered on this:

  • If you edit the lockbox metadata, nothing changes, it just updates the meta data and everything is the same.
  • If you edit M, N or any of the public keys, it gives you the warning below


Code:
               You originally loaded lockbox (%s) but the edits you made
               have caused it to become a new/different lockbox (%s).
               Changing the M-value, N-value, or any of the public keys
               will result in a new lockbox, unrelated to the original.
               
               *If you click "Ok" a new lockbox will be created* instead
               of replacing the original.  If you do not need the original,
               you can go the lockbox browser and manually remove it.

Thanks.
full member
Activity: 123
Merit: 100
#2 good point. It seems like it would only be a good idea to modify an empty lockbox. Maybe we shouldn't allow a lockbox with funds deposited to be modified. I think that would make funds deposited inaccessible without recreating the original configuration. I will have to try this.


I should have tried it before commenting.

Alan has brilliantly kept the original lockbox if you modify it to be a different lockbox!
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
2- I don't understand why is possible to edit a created lockbox.

Already got you covered on this:

  • If you edit the lockbox metadata, nothing changes, it just updates the meta data and everything is the same.
  • If you edit M, N or any of the public keys, it gives you the warning below


Code:
               You originally loaded lockbox (%s) but the edits you made
               have caused it to become a new/different lockbox (%s).
               Changing the M-value, N-value, or any of the public keys
               will result in a new lockbox, unrelated to the original.
               
               *If you click "Ok" a new lockbox will be created* instead
               of replacing the original.  If you do not need the original,
               you can go the lockbox browser and manually remove it.
full member
Activity: 123
Merit: 100
Hi,

1- What is the reason of have 1 of 2 (m-of-n)?
2- I don't understand why is possible to edit a created lockbox.

Sorry if the questions doesn't make sense.


#1 is a good model for a joint account. Especially married people.

#2 good point. It seems like it would only be a good idea to modify an empty lockbox. Maybe we shouldn't allow a lockbox with funds deposited to be modified. I think that would make funds deposited inaccessible without recreating the original configuration. I will have to try this.
sr. member
Activity: 312
Merit: 250
Hi,

1- What is the reason of have 1 of 2 (m-of-n)?
2- I don't understand why is possible to edit a created lockbox.

Sorry if the questions doesn't make sense.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
There does continue to be an error related to print statements in Windows.  I believe that once Armory passes through py2exe, that stdout no longer exists and therefore any print/pprint statements will fail with "Bad File Descriptor".  CircusPeanut:  I assume you are trying to reproduce from python-executed code, correct?  Try running from the installed version and/or rebuilding from the MSVS project and using the .exe. 

I thought I had removed all the print statements.  They are never necessary, usually just left over debugging artifacts that should be harmless.  After all, there should always be a stdout, right?  I will go over it again and make sure there are no remnants left.
full member
Activity: 123
Merit: 100
Downloaded the 0.91.99.8-beta and there is still a some sort of glitch with sending multiple times from a lockbox.

1st broadcast - success.
2nd broadcast - no response to button push.
3rd broadcast (still same screen as 2nd) - success.
.
.
.

I tried to reproduce this bug, and failed.

I assumed it something to do with zero conf change, but I was able to spend that change fine. I'm still not sure how that is not a problem, but I was able to do it.

This is testnet right, I assume that this address is testnet: mwoDMoqU8j87....

And the amounts are too big for main net unless you are stupid or wealthy or both Smiley

How old are those lockboxes?

If you pulled from previous version of the Armory repo and used an older version to create those lockboxes maybe your problem is caused by lockbox incompatibility. They did change a bit from the first time Alan let people try out lockboxes.

I mention these tries in case they spark any ideas on how to reproduce this bug.  Please let me know if you think of anything. Sometimes it is the strangest things that makes the difference on reproducing a bug.

It's rare that I can fix what I can't reproduce, and even then it's hard to trust the fix.
member
Activity: 98
Merit: 10
Downloaded the 0.91.99.8-beta and there is still a some sort of glitch with sending multiple times from a lockbox.

1st broadcast - success.
2nd broadcast - no response to button push.
3rd broadcast (still same screen as 2nd) - success.

2014-06-30 17:39 (INFO) -- ArmoryQt.py:5533 - Switching Armory state text to Mgmt:User, State:OnlineFull1
2014-06-30 17:39 (INFO) -- ArmoryQt.py:5475 - Switching Armory functional mode to "Online"
2014-06-30 17:39 (INFO) -- ArmoryQt.py:5533 - Switching Armory state text to Mgmt:User, State:OnlineFull2
2014-06-30 17:40 (INFO) -- TxFrames.pyc:682 - Change address behavior: Feedback
2014-06-30 17:41 (INFO) -- (PPRINT from ArmoryQt.py:3751)

  01000000 01672b62 9e210d2f bdcc234c 2cb7eef6 12e93654 a3f2f78f 8976029b
  3250bdbd 68000000 00fda701 00483045 022100b9 5a4aed80 d26fe1ad e77f4ca3
  b3f0bfe5 5d546da2 6125d64b 813751b0 4b2c6202 2041c1f6 a61eb946 65d38b5e
  acd34dfb 0a54cb9f 8281c9da 17af20bb 59a7d3be be014830 45022100 b95a4aed
  80d26fe1 ade77f4c a3b3f0bf e55d546d a26125d6 4b813751 b04b2c62 022041c1
  f6a61eb9 4665d38b 5eacd34d fb0a54cb 9f8281c9 da17af20 bb59a7d3 bebe0148
  30450221 00b95a4a ed80d26f e1ade77f 4ca3b3f0 bfe55d54 6da26125 d64b8137
  51b04b2c 62022041 c1f6a61e b94665d3 8b5eacd3 4dfb0a54 cb9f8281 c9da17af
  20bb59a7 d3bebe01 4cc95241 049cdf7d c590734d ff3fbf3c 6a3ef086 a31a5371
  a444370f dc4a9661 019648e1 072fcb05 948223ce d0265671 ce46a079 2bfc9c22
  89c64c45 7c5449b5 ec419e02 7641049c df7dc590 734dff3f bf3c6a3e f086a31a
  5371a444 370fdc4a 96610196 48e1072f cb059482 23ced026 5671ce46 a0792bfc
  9c2289c6 4c457c54 49b5ec41 9e027641 049cdf7d c590734d ff3fbf3c 6a3ef086
  a31a5371 a444370f dc4a9661 019648e1 072fcb05 948223ce d0265671 ce46a079
  2bfc9c22 89c64c45 7c5449b5 ec419e02 7653aeff ffffff02 e0a69d21 00000000
  17a914fa d89dde6d 08c5b2d3 d04ab80d 29b6b64c e7cc9187 00a3e111 00000000
  1976a914 1430e7f7 bf01c7a2 69453743 96d8d0cd 96e5eb05 88ac0000 0000
2014-06-30 17:41 (INFO) -- (PPRINT from ArmoryQt.py:3752)
Transaction:
   TxHash:    b2a0a275adbce9ebe20660f985d8ef821465e50dcdb9e5ea878a9a803d4cb012 (BE)
   Version:   1
   nInputs:   1
   nOutputs:  2
   LockTime:  0
   Inputs:
      PyTxIn:
         PrevTxHash: 68bdbd50329b0276898ff7f2a35436e912f6eeb72c4c23ccbd2f0d219e622b67 (BE)
         TxOutIndex: 0
         Script:     (00483045022100b95a4aed80d26fe1ade77f4ca3b3f0bfe55d546da26125d64b)
         Sender:     2NG7aR2ovqtsi7Xn6VLxGKUSpkVAjGooub8
         Seq:        4294967295
   Outputs:
      TxOut:
         Value:   563980000 (5.6398)
         Script:  OP_HASH160 (2NG7aR2ovqtsi7Xn6VLxGKUSpkVAjGooub8) OP_EQUAL
      TxOut:
         Value:   300000000 (3.0)
         Script:  OP_DUP OP_HASH160 (mhMiPwvKT8rGU9ehL2mxa1HqiYcb6GV9r8) OP_EQUALVERIFY OP_CHECKSIG

2014-06-30 17:41 (INFO) -- ArmoryQt.py:3754 - Sending Tx, 12b04c3d809a8a87eae5b9cd0de5651482efd885f96006e2ebe9bcad75a2a0b2
2014-06-30 17:41 (INFO) -- Networking.pyc:278 - sendTx called...
2014-06-30 17:41 (INFO) -- ArmoryQt.py:3756 - Transaction sent to Satoshi client...!
2014-06-30 17:41 (INFO) -- ArmoryQt.py:6858 - Bitcoins Received!
Amount:  3 BTC
Recipient:  Wallet "Primary Wallet" (2QidxBjZ8)
2014-06-30 17:41 (INFO) -- TxFrames.pyc:682 - Change address behavior: Feedback
2014-06-30 17:41 (ERROR) -- Traceback (most recent call last):
  File "ui\MultiSigDialogs.pyc", line 2967, in doBroadcast
  File "armoryengine\Transaction.pyc", line 810, in pprintHex
IOError: [Errno 9] Bad file descriptor

2014-06-30 17:41 (INFO) -- (PPRINT from ArmoryQt.py:3751)

  01000000 0112b04c 3d809a8a 87eae5b9 cd0de565 1482efd8 85f96006 e2ebe9bc
  ad75a2a0 b2000000 00fda401 00473044 0220095a e27ac269 6bc3941c 4b309459
  e05d2e68 7f063e0f 161b993b 117209a9 5af80220 1346f9f2 81182b77 81db27b5
  bb791dad 50d7be6a 724982ae dd0ca4f3 92d18b24 01473044 0220095a e27ac269
  6bc3941c 4b309459 e05d2e68 7f063e0f 161b993b 117209a9 5af80220 1346f9f2
  81182b77 81db27b5 bb791dad 50d7be6a 724982ae dd0ca4f3 92d18b24 01473044
  0220095a e27ac269 6bc3941c 4b309459 e05d2e68 7f063e0f 161b993b 117209a9
  5af80220 1346f9f2 81182b77 81db27b5 bb791dad 50d7be6a 724982ae dd0ca4f3
  92d18b24 014cc952 41049cdf 7dc59073 4dff3fbf 3c6a3ef0 86a31a53 71a44437
  0fdc4a96 61019648 e1072fcb 05948223 ced02656 71ce46a0 792bfc9c 2289c64c
  457c5449 b5ec419e 02764104 9cdf7dc5 90734dff 3fbf3c6a 3ef086a3 1a5371a4
  44370fdc 4a966101 9648e107 2fcb0594 8223ced0 265671ce 46a0792b fc9c2289
  c64c457c 5449b5ec 419e0276 41049cdf 7dc59073 4dff3fbf 3c6a3ef0 86a31a53
  71a44437 0fdc4a96 61019648 e1072fcb 05948223 ced02656 71ce46a0 792bfc9c
  2289c64c 457c5449 b5ec419e 027653ae ffffffff 0250cdb6 12000000 0017a914
  fad89dde 6d08c5b2 d3d04ab8 0d29b6b6 4ce7cc91 8780b2e6 0e000000 001976a9
  14b2953e 4affec23 597a79ca 0b374949 f6e77b5d 8d88ac00 000000
2014-06-30 17:41 (INFO) -- (PPRINT from ArmoryQt.py:3752)
Transaction:
   TxHash:    8cdf93d8c2429bce748ed8dc929db25f543492774c04a0771d36b3c0dd6d0aeb (BE)
   Version:   1
   nInputs:   1
   nOutputs:  2
   LockTime:  0
   Inputs:
      PyTxIn:
         PrevTxHash: b2a0a275adbce9ebe20660f985d8ef821465e50dcdb9e5ea878a9a803d4cb012 (BE)
         TxOutIndex: 0
         Script:     (004730440220095ae27ac2696bc3941c4b309459e05d2e687f063e0f161b993b)
         Sender:     2NG7aR2ovqtsi7Xn6VLxGKUSpkVAjGooub8
         Seq:        4294967295
   Outputs:
      TxOut:
         Value:   313970000 (3.1397)
         Script:  OP_HASH160 (2NG7aR2ovqtsi7Xn6VLxGKUSpkVAjGooub8) OP_EQUAL
      TxOut:
         Value:   250000000 (2.5)
         Script:  OP_DUP OP_HASH160 (mwoDMoqU8j871Ezi8WE4UAQBQrRKgAdmXq) OP_EQUALVERIFY OP_CHECKSIG

2014-06-30 17:41 (INFO) -- ArmoryQt.py:3754 - Sending Tx, eb0a6dddc0b3361d77a0044c779234545fb29d92dcd88e74ce9b42c2d893df8c
2014-06-30 17:41 (INFO) -- Networking.pyc:278 - sendTx called...
2014-06-30 17:41 (INFO) -- ArmoryQt.py:3756 - Transaction sent to Satoshi client...!
2014-06-30 17:41 (INFO) -- ArmoryQt.py:6858 - Bitcoins Sent!
Amount:  3.0001 BTC
From:    Lockbox 2-of-3 "Lockbox 2 of 3" (YaGTwqNK)
To:      Wallet: "Primary Wallet" (mhMiPwvKT8rG...)
2014-06-30 17:41 (INFO) -- ArmoryQt.py:6858 - Bitcoins Received!
Amount:  2.5 BTC
Recipient:  Wallet "Third Wallet" (3C8N8sMzN)
2014-06-30 17:41 (INFO) -- ArmoryQt.py:6858 - Bitcoins Sent!
Amount:  2.5001 BTC
From:    Lockbox 2-of-3 "Lockbox 2 of 3" (YaGTwqNK)
To:      Wallet: "Third Wallet" (mwoDMoqU8j871E...)
full member
Activity: 226
Merit: 100
Oh! I have to edit my post above. Simulfund to normal addresses works like a charm. Let's try this, Hope this is fun!

I provide a promissory note to donate 0.1 BTC to Armory in case 9 others will sign such a note as well. I also volunteer to merge, will sign as well if someone else does.

Good Night to all!

SimonBelmond


=====PROMISSORY-BXawafsM========================================
AQAAAPm+tNk0AQAAAPm+tNkZdqkU/jlZ2yUPJHrXJPKvVDnKMui+PbGIrICWmAAA
AAAAAAAETk9ORQAAADQBAAAA+b602Rl2qRQr06rLV1tKFjqiCqIbmKi2S5SieYis
oFJXAQAAAAAAAAROT05FAAAAECcAAAAAAAAB/csCAQAAAPm+tNmtl2qQvnz+VwOB
Z/7r6iXqJqK5XZocYa0YQc57zVPlUwAAAAD9SAIBAAAAA7z9A4cXL7lfm6phJ3IH
11Sy475b5lN4jdXVLjygfP5oAQAAAItIMEUCIQCP+/tm7ZuJWqJ3dtkyk1HygXiz
HUyF2/vM2vLy+BJZrQIgaPoWGSL87KrVQjxxLs1HE0cwOb24sYHuPFeXYA7R0BYB
QQSgU2UmdsQ4WVcBAFhnXZ5bq8CWt+1TM1EKNx+FUSJ87fUVyWSOLWRvfApIVxlF
b3gy+XXlVahaX7WvRZoUcPVa/////+rpt/i7q4eULcwWx8RgP63nCFDmEgoeRiW2
R87wupK0AAAAAItIMEUCIBoz9hb4rPr9NOC3BQDRviAWABpMF/3+JogB56wXTEfv
AiEArD2/Pd4GobYuRdym1g5SGY/QEzjTBWNZ4Z4qRuTuVAwBQQSgU2UmdsQ4WVcB
AFhnXZ5bq8CWt+1TM1EKNx+FUSJ87fUVyWSOLWRvfApIVxlFb3gy+XXlVahaX7Wv
RZoUcPVa/////4gkcX6AzyyLAvVHm17w+lTsqz+Maq+Mubwn6ZIryVItAAAAAItI
MEUCIHwS3GvPi2Ca7SZtjzFt5nhRjGu9+WyV+1lbz9sUBNEGAiEA3cKVHcMs6oEo
0M4NLaSazPr5Ny09tHhF5jP/RbO/sNQBQQSgU2UmdsQ4WVcBAFhnXZ5bq8CWt+1T
M1EKNx+FUSJ87fUVyWSOLWRvfApIVxlFb3gy+XXlVahaX7WvRZoUcPVa/////wEw
EPABAAAAABl2qRQJVnTA871Z1djsUHlQLsnjYjbFFYisAAAAAAAIQlhhd2Fmc00A
/////wFBBE3p1mnv57raAbJtPdkCsoY1qu327aN+OsnmwkmxQ7DQ5CF0jg78C6wc
xiDTAwv+AD8b/aikZ6/Eqj/bTigjAXAAAERTaW1vbkJlbG1vbmQgd2lsbCBtZXJn
ZSBhbmQgc2lnbiBpZiAxMCBvZiB0aGVzZSB3aWxsIGJlIHBvc3RlZCBoZXJlIQA=
================================================================
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
Please add one of your many awesome Question marks with tool tip. No need for a Manual with armory. These things explain almost everything and you learn a lot about the Bitcoin protocol and more.

Yeah, that's one of those things that should be under super-expert feature.  There limited uses for using regular multisig over P2SH, but they do exist (having transparent public keys in the blockchain can assist with automated tools that are tracking multisig addresses they are signers for).  I'll add a (?) thingy

"Cannot be signed by you" However, both watching-only wallets are marked as "mine". Therefore the comment should rather be that the signature cannot be given from this instance of Armory, and then explain the conditions (keys are not here or not your wallet). Whatever, doesn't seem 100% correct. Maybe a "light" green would be good in case you can even cover it with the architecture.

Yeah, I don't use the "is mine" or "belongs to someone else" distinction here.  If we can come up with something clean to say, I'll change it.  Otherwise, I'm sure the user will figure it out Smiley

What about Simulfunding of normal single key addresses? What about if I want to set up a 10 party 0.1 BTC simulfund to give to Armory?

I struggled with simulfunding of regular addresses -- there's no reason the same code can't be used for it, but it didn't fit cleanly into the lockbox dashboard.  So I added a "Multisig" menu to the main window, and you can do arbitrary simulfunding from there.  I want to unify the interface somehow, but not quite sure yet how to do it.  Either way, feel free to try out all the same features from that menu instead.  (by the way, "arbitrary" means arbitrary recipients.  But not arbitrary inputs:  I still haven't found a good way to build into the UI the ability to simulfund with Lockboxes... shouldn't be too hard though)

full member
Activity: 226
Merit: 100
OK. First of all THX again for doing all this work. Simulfunding was a great surprise and is a hell of a feature which I would not have expected when trying out the lock boxes. I had some good and bad investments with Bitcoin so far. However, I have only made good donations.  Grin



Please add one of your many awesome Question marks with tool tip. No need for a Manual with armory. These things explain almost everything and you learn a lot about the Bitcoin protocol and more.



There seems to be a strange line break there and "Untitled." Huh
"Cannot be signed by you" However, both watching-only wallets are marked as "mine". Therefore the comment should rather be that the signature cannot be given from this instance of Armory, and then explain the conditions (keys are not here or not your wallet). Whatever, doesn't seem 100% correct. Maybe a "light" green would be good in case you can even cover it with the architecture.

What about Simulfunding of normal single key addresses? What about if I want to set up a 10 party 0.1 BTC simulfund to give to Armory? Would you have to set up a 1/1 lockbox for that?

Just in case you haven't seen it:
https://bitcointalksearch.org/topic/m.7594421

old version 0.91.99.7 Grin on Win7 x64 SP1  

Edit:stuff, typos
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
Fixed the testnet-startup-fail-in-windows bug, as well as made the regular-funding row four buttons plus your address string.  There was plenty of space, and I tried to used it efficiently, though I agree that it should be painfully obvious how easy it to receive money to the lockbox!

If you're currently running any version 0.91+, use the secure downloader within Armory
Help->Update Software (yes, I know the interface is messy -- but it does work if you futz with it enough)

Installers for 0.91.99.8-beta:
  Armory 0.91.99.8-beta for Windows XP, Vista, 7, 8+ 32- and 64-bit
  Armory 0.91.99.8-beta for MacOSX 10.7+ 64bit
  Armory 0.91.99.8-beta for Ubuntu 12.04+ 32bit
  Armory 0.91.99.8-beta for Ubuntu 12.04+ 64bit
  Armory 0.91.99.8-beta for Raspbian (armhf)

Offline Bundles:
  Armory 0.91.99.8-beta Offline Bundle for Ubuntu 12.04 32bit
  Armory 0.91.99.8-beta Offline Bundle for Ubuntu 12.04 64bit
  Armory 0.91.99.8-beta Offline Bundle for Raspbian Raspbian armhf

Signed Hashes:
  Armory 0.91.99.8-beta: Signed hashes of all installers

full member
Activity: 123
Merit: 100
This is the reason I want that transaction creation should be handled by us but signing/verifying be given to a few members of the board. Their only job would be to check if the transactions are correct and then sign. But we want a system in which the other members cannot create transaction.

Also, does each transaction need to be signed or bulk transactions can signed at once?

The signers must all have a copy of the lockbox.

Using the Armory application each transaction can only be signed one at a time.  

With the ArmoryD API you have more options. For instance you can implement an auto signer. This would make your lockbox less secure though.
full member
Activity: 168
Merit: 100
Quote

As an aside, I would be weary of participating in a 2 of 7. Unless there is a trivial amount of money in that lockbox, somebody is placing a lot of trust in the other participants.


This is the reason I want that transaction creation should be handled by us but signing/verifying be given to a few members of the board. Their only job would be to check if the transactions are correct and then sign. But we want a system in which the other members cannot create transaction.

Also, does each transaction need to be signed or bulk transactions can signed at once?
full member
Activity: 123
Merit: 100
Also, do the users need to sign one transaction at a time or can they sign multiple transactions at the same time?

Moreover, if we have a 2 out of 7 pool, then if 1 user signs it and sends the file to the balance 6 users and if 2 out of the 6 open it approximately the same time and sign and broadcast, does it send the money twice from the wallet?

I am sorry if these questions seem too much but we are exploring using armory for our new service that we will launching soon. Thanks in advance.

The money can only be sent once. Only one of the signed transactions will be accepted into the a block first. The bitcoin software will never allow both signer's broadcasted versions of the transaction into the block chain. That would constitute a double spend.

As an aside, I would be weary of participating in a 2 of 7. Unless there is a trivial amount of money in that lockbox, somebody is placing a lot of trust in the other participants.
full member
Activity: 168
Merit: 100
Also, do the users need to sign one transaction at a time or can they sign multiple transactions at the same time?

Moreover, if we have a 2 out of 7 pool, then if 1 user signs it and sends the file to the balance 6 users and if 2 out of the 6 open it approximately the same time and sign and broadcast, does it send the money twice from the wallet?

I am sorry if these questions seem too much but we are exploring using armory for our new service that we will launching soon. Thanks in advance.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
So if we dont share the lockbox, then they cant create a transaction but they can still sign the transaction created by us? Correct?

Heh, kinda.  If you "Use Bare Multisig (no P2SH)", Armory should be able to recognize its own key and be able to sign without the lockbox.  I think.  Testers: try it!

Otherwise, it uses P2SH which is totally opaque and you must have the lockbox in order to even recognize it's relevant to you.
full member
Activity: 168
Merit: 100
So if we dont share the lockbox, then they cant create a transaction but they can still sign the transaction created by us? Correct?

Thanks for the help.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
No, What I mean is can all the members of the multisig group create a new transaction or can it be only made by the initial author?

Anyone can create the transaction as long as they have imported the lockbox.  They don't even have to be a signer.  The lockbox block is basically a watching-only wallet for your multi-sig.
full member
Activity: 168
Merit: 100
No, What I mean is can all the members of the multisig group create a new transaction or can it be only made by the initial author?
Pages:
Jump to: