[ANN] Armory Multi-Sig with Simulfunding [BOUNTY 0.03 per bug]

[neha]

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.

[CircusPeanut]

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.

[neha]

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?

[CircusPeanut]

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.

[etotheipi]

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

[SimonBelmond]

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.  



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."
"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://bitcointalk.org/index.php?topic=607046.msg7594421#msg7594421

old version 0.91.99.7 on Win7 x64 SP1  

Edit:stuff, typos

[etotheipi]

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

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)

[SimonBelmond]

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=
================================================================

[PRab]

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...)

[CircusPeanut]

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

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.

[etotheipi]

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.

[teste]

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.

[CircusPeanut]

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.

[etotheipi]

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.

[CircusPeanut]

#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!

[teste]

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.

[CircusPeanut]

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 installed the windows download from this thread, and ran it from the windows start menu. Am still unable to reproduce the bug.

[teste]

Im using Armory offline and the button (collect sigs and broadcast) say (must be online to broadcast). But  I can click on the button.

Different of:

The button (create spending Tx) say I must be online to spend. But because Im in offline mode, the button is INACTIVE.

[PRab]

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

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.

Yes the lockbox is testnet.
This lockbox was created by the first publicly available version of armory that supported lockboxes. I have been the same lockbox ever since.
It could be related to zero-confirm because I'm testing quickly, but there is an error in the middle of the log related to a missing folder. I am more suspicious of that. I know how you feel about unreproducible bugs. Programming is my day job.

I will be away from my main computer for a few days so will be unable to run any more test. Sorry

[etotheipi]

Im using Armory offline and the button (collect sigs and broadcast) say (must be online to broadcast). But  I can click on the button.

Different of:

The button (create spending Tx) say I must be online to spend. But because Im in offline mode, the button is INACTIVE.

I actually have a comment in the code explicitly discussing this:

https://github.com/etotheipi/BitcoinArmory/blob/devel/ui/MultiSigDialogs.py#L1101

Code:

                  #    The 'MergeSigs' button is the only one that kinda makes 
                  #    sense to not work offline, but there may be isolated 
                  #    cases where the user would merge without intending to 
                  #    broadcast.  Having it disabled in offline mode would
                  #    make them go mad.  So I'm going to explicitly make sure
                  #    that just that button is always enabled, even though
                  #    it might look like a bug.

The gist of it is:  the button is still potentially useful in offline mode, but only for collecting and merging signatures.  Broadcasting requires being online, but I couldn't separate out that functionality.  Obviously it's not entirely clear and does actually look like a bug... hmm