Pages:
Author

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

full member
Activity: 226
Merit: 100
Hi all,

We are rewarding bug contributors with the following Bounties (0.03 Btc per bounty):

LOL - 1
PRab - 4
PodBayDoors - 1
SimonBelmond - 1
Searinox - 2
TimS - 1

(Note that this does not include Helgabutters who's bounties are being handled separately)

If you think that you are owed a bounty that is not included in this list, please let us know and reference the post with the bug.

For those on this list please post a public address for us to send your reward.

Thanks for everyone's contribution to this project. We really appreciate it and so do all of the Bitcoin Armory users.

As I have previously donated to Armory anyway, these 0.03 can be used to fund the next bug-bounty round. THX for everything you guys are providing! By the way, my offer here is still valid for anyone interessted: https://bitcointalksearch.org/topic/m.7606568
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
For those on this list please post a public address for us to send your reward.

Actually, please PM with address since most people don't want it to be public.  Also, I have a few addresses that have already been given to me through email or PM, I'll pass them to you.
full member
Activity: 123
Merit: 100
Hi all,

We are rewarding bug contributors with the following Bounties (0.03 Btc per bounty):

LOL - 1
PRab - 4
PodBayDoors - 1
SimonBelmond - 1
Searinox - 2
TimS - 1

(Note that this does not include Helgabutters who's bounties are being handled separately)

If you think that you are owed a bounty that is not included in this list, please let us know and reference the post with the bug.

For those on this list please post a public address for us to send your reward.

Thanks for everyone's contribution to this project. We really appreciate it and so do all of the Bitcoin Armory users.
newbie
Activity: 43
Merit: 0
If you are owed bounties and haven't sent me your payment address, please PM me.  I should get around to paying those out today (Weds) or Thurs.

Hope all is well. I was just wondering if there was any more update to when the bounties will be sent out.
hero member
Activity: 784
Merit: 500
Finally!  Released 0.92 but had some hiccups in the release process, so just put out 0.92.1.  Update with the secure downloader, or grab them from here:

  Armory 0.92.1 for Windows XP, Vista, 7, 8+ (32- and 64-bit)
  Armory 0.92.1 for MacOSX 10.7+ (64bit)
  Armory 0.92.1 for Ubuntu 12.04+ (32bit)
  Armory 0.92.1 for Ubuntu 12.04+ (64bit)
  Armory 0.92.1 for RaspberryPi  (armhf)

  Armory 0.92.1 Offline Bundle for Ubuntu 12.04 exact (32bit)
  Armory 0.92.1 Offline Bundle for Ubuntu 12.04 exact (64bit)
  Armory 0.92.1 Offline Bundle for RaspberryPi  (armhf)

  Armory 0.92.1: Signed hashes of all installers


If you are owed bounties and haven't sent me your payment address, please PM me.  I should get around to paying those out today (Weds) or Thurs.

Thanks to everyone who helped test the new version! 

Awesome, thanks!
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
Finally!  Released 0.92 but had some hiccups in the release process, so just put out 0.92.1.  Update with the secure downloader, or grab them from here:

  Armory 0.92.1 for Windows XP, Vista, 7, 8+ (32- and 64-bit)
  Armory 0.92.1 for MacOSX 10.7+ (64bit)
  Armory 0.92.1 for Ubuntu 12.04+ (32bit)
  Armory 0.92.1 for Ubuntu 12.04+ (64bit)
  Armory 0.92.1 for RaspberryPi  (armhf)

  Armory 0.92.1 Offline Bundle for Ubuntu 12.04 exact (32bit)
  Armory 0.92.1 Offline Bundle for Ubuntu 12.04 exact (64bit)
  Armory 0.92.1 Offline Bundle for RaspberryPi  (armhf)

  Armory 0.92.1: Signed hashes of all installers


If you are owed bounties and haven't sent me your payment address, please PM me.  I should get around to paying those out today (Weds) or Thurs.

Thanks to everyone who helped test the new version! 
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
Also, do the users need to sign one transaction at a time or can they sign multiple transactions at the same time?

One at a time, although I can imagine a scenario where armoryd could be used to rapidly sign transactions.

Quote
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?

No. Classic double spend scenario. One of the transactions would be rejected. It wouldn't matter since the other version went through.


Creating new transactions to sign before signing and broadcasting earlier ones is likely to lead to the later ones trying to spend the same coins and being invalidated.  Per lockbox, you can only have one outstanding transaction at a time and know that it will be valid when you sign it.  If we had coin control for lockboxes, it would be possible to do a few sequentially.

A transaction specifies what coins are being spent and where they are going.  Multiple copies of the same transaction are spending the same coins, thus if you try to broadcast a second copy (regardless of whether it's the same signatures or different), it will be rejected as a double-spend. 
sr. member
Activity: 255
Merit: 250
Senior Developer - Armory
Also, do the users need to sign one transaction at a time or can they sign multiple transactions at the same time?

One at a time, although I can imagine a scenario where armoryd could be used to rapidly sign transactions.

Quote
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?

No. Classic double spend scenario. One of the transactions would be rejected. It wouldn't matter since the other version went through.
sr. member
Activity: 255
Merit: 250
Senior Developer - Armory
We had actually planned to turn 0.91.99.11 into 0.92 today, but we have some non-code-related things to do before we officially release it.  Unless any critical bugs are found, we will simply be releasing 0.91.99.11 + polishing as 0.92 early next week.   Therefore, I believe the only difference between .11 and the official release is the ugly version number that will be displayed on the main screen Smiley

Yep. ~97-98% of the code changes are in armoryd, and even the tiny bits that aren't really won't affect a huge majority of people out there. People should upgrade to 0.92 when it comes out, especially if they wish to use armoryd, but 0.91.99.11 is close enough, short of somebody contacting us in the next day or two with a catastrophic bug report.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
Also, if I'm allowed to be particularly anal, there's a small line / bar on the left side of that box list that, if it were in Excel, would suggest that there's a collapsed / shrunk column. It in no way affects functionality as far as I can tell but I figured you may want to know.

That is in fact a collapsed column that I only found out about recently.

If you go to the Filter List Box below the table in the Transaction tab, and select "Custom Filter", you will get a column that allows you to hide or display ledger entries for selected rows.

That's interesting, and curiously enabling that and clicking to view / unview removes the blue hue on the title bar, but the small sliver remains. In any event, it's not a big deal.

Would you, dear devs, say that 0.91.99.11 is RC worthy for 0.92? i.e. is it safe enough to replace the previous version I have running on my main machine?

We had actually planned to turn 0.91.99.11 into 0.92 today, but we have some non-code-related things to do before we officially release it.  Unless any critical bugs are found, we will simply be releasing 0.91.99.11 + polishing as 0.92 early next week.   Therefore, I believe the only difference between .11 and the official release is the ugly version number that will be displayed on the main screen Smiley
sr. member
Activity: 246
Merit: 250
My spoon is too big!
Also, if I'm allowed to be particularly anal, there's a small line / bar on the left side of that box list that, if it were in Excel, would suggest that there's a collapsed / shrunk column. It in no way affects functionality as far as I can tell but I figured you may want to know.

That is in fact a collapsed column that I only found out about recently.

If you go to the Filter List Box below the table in the Transaction tab, and select "Custom Filter", you will get a column that allows you to hide or display ledger entries for selected rows.

That's interesting, and curiously enabling that and clicking to view / unview removes the blue hue on the title bar, but the small sliver remains. In any event, it's not a big deal.

Would you, dear devs, say that 0.91.99.11 is RC worthy for 0.92? i.e. is it safe enough to replace the previous version I have running on my main machine?
full member
Activity: 123
Merit: 100
Also, if I'm allowed to be particularly anal, there's a small line / bar on the left side of that box list that, if it were in Excel, would suggest that there's a collapsed / shrunk column. It in no way affects functionality as far as I can tell but I figured you may want to know.

That is in fact a collapsed column that I only found out about recently.

If you go to the Filter List Box below the table in the Transaction tab, and select "Custom Filter", you will get a column that allows you to hide or display ledger entries for selected rows.
sr. member
Activity: 255
Merit: 250
Senior Developer - Armory
I found something that one might consider a bug though it's just aesthetics. Mac client 0.91.99.9 running on 10.9.4.

Thanks. We are aware of that bug. The code we're using in that particular section is still a little shaky. We'll figure something out eventually but definitely not for 0.92. (At this point, the code's basically frozen except for crashes and other showstoppers.)
sr. member
Activity: 246
Merit: 250
My spoon is too big!
I found something that one might consider a bug though it's just aesthetics. Mac client 0.91.99.9 running on 10.9.4.

When I start the client, the wallet list is fine:


If I click on a wallet in the list, however, to perhaps just select it or double click for more functionality, the title bar of the list turns blue and it doesn't change back unless I quit and restart the client. Also, if I'm allowed to be particularly anal, there's a small line / bar on the left side of that box list that, if it were in Excel, would suggest that there's a collapsed / shrunk column. It in no way affects functionality as far as I can tell but I figured you may want to know.
sr. member
Activity: 246
Merit: 250
My spoon is too big!
    Got it. Thanks, guys. Much appreciated.

    By the way - in the OP you have a dangling
Code:
"[/list]"
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
Apologies if this has been answered elsewhere but I have a question about lockboxes. I understand how to set them up but I'm curious about backup strategies for them.

Your answer is here. Basically, all you truly need are for the private keys to be backed up (e.g., paper backups), although you can back up the lockbox definition and save yourself some setup time. As long as there are enough signing parties, you're good. If there's corruption, the keys will have to be restored.

Thanks for the prompt response. I actually just happened upon the answer (and have the same link in my clipboard to paste here actually). What about a case where the lockbox definition is lost on the organizing machine and neither / none of the others imported the definition? Is there a way, without the definition, to restore the lockbox? Let's assume the cases of you know the public keys / addresses that were originally used to create the lockbox, you know one key that was used to create the lockbox, and the rare case that you can't remember which key was used to create the lockbox (but maybe you know which wallet was used).

I hope my question here isn't too ignorant. Smiley

Ultimately, the list of the public keys is all that matters.  If know what public keys were used, you can recreate the lockbox.  If you just know what wallets were used, you'll eventually figure it out, though it might take a script to do.  Nonetheless you'll get your coins back.  But this should be mostly irrelevant we assume that not all your devices are losing it or getting destroyed, or you might have bigger problems.  As long as one of them still has the definition, you just export-import.

Or backup the multisigs.txt file to save yourself some time.  We just haven't made an option for it because we didn't feel it was necessary (though we'll have some automatic backup features with the new wallets, for saving address/tx labels and lockbox definitions)
sr. member
Activity: 255
Merit: 250
Senior Developer - Armory
Thanks for the prompt response. I actually just happened upon the answer (and have the same link in my clipboard to paste here actually). What about a case where the lockbox definition is lost on the organizing machine and neither / none of the others imported the definition? Is there a way, without the definition, to restore the lockbox? Let's assume the cases of you know the public keys / addresses that were originally used to create the lockbox, you know one key that was used to create the lockbox, and the rare case that you can't remember which key was used to create the lockbox (but maybe you know which wallet was used).

Know all keys: Just create another lockbox that uses the keys. That's all you need to do.
Know only some of the keys: Uses the ones you do know and keep trying to build with the others. For example, let's say you know that a wallet with 20 addresses in it was used, but you don't know which address was used. You'll have to cycle through the addresses until you find a lockbox that works.
Know no keys: You're out of luck unless you know the wallets used and are willing to try hundreds, thousands, or possibly even millions of address combinations. (3 wallets with 100 addresses each = 100 x 100 x 100 = 1,000,000 possible combinations.)
sr. member
Activity: 246
Merit: 250
My spoon is too big!
Apologies if this has been answered elsewhere but I have a question about lockboxes. I understand how to set them up but I'm curious about backup strategies for them.

Your answer is here. Basically, all you truly need are for the private keys to be backed up (e.g., paper backups), although you can back up the lockbox definition and save yourself some setup time. As long as there are enough signing parties, you're good. If there's corruption, the keys will have to be restored.

Thanks for the prompt response. I actually just happened upon the answer (and have the same link in my clipboard to paste here actually). What about a case where the lockbox definition is lost on the organizing machine and neither / none of the others imported the definition? Is there a way, without the definition, to restore the lockbox? Let's assume the cases of you know the public keys / addresses that were originally used to create the lockbox, you know one key that was used to create the lockbox, and the rare case that you can't remember which key was used to create the lockbox (but maybe you know which wallet was used).

I hope my question here isn't too ignorant. Smiley
sr. member
Activity: 255
Merit: 250
Senior Developer - Armory
Apologies if this has been answered elsewhere but I have a question about lockboxes. I understand how to set them up but I'm curious about backup strategies for them.

Your answer is here. Basically, all you truly need are for the private keys to be backed up (e.g., paper backups), although you can back up the lockbox definition and save yourself some setup time. As long as there are enough signing parties, you're good. If there's corruption, the keys will have to be restored.
sr. member
Activity: 246
Merit: 250
My spoon is too big!
Apologies if this has been answered elsewhere but I have a question about lockboxes. I understand how to set them up but I'm curious about backup strategies for them. Say you set up a lockbox on one machine and you gather the public keys from elsewhere. Then the host / organizer machine crashes and there isn't a backup of the data on the machine. With the deterministic nature of regular wallets, this can be addressed with a paper / offsite backup of the deterministic keys. How do you back up the lockbox though or make it so another machine can spend from that multisig address if the organizing / original machine ends up becoming corrupt in some way?
Pages:
Jump to: