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

[etotheipi]

Looks like one of my testnet wallets is producing invalid transactions with the latest version (0.91.99.11-beta). Every time I try to send bitcoind disconnects then reconnects and gives the log message "2014-07-20 00:36:46 ERROR: AcceptToMemoryPool : inputs already spent". I was doing some rapid spending/receiving before I did the upgrade, but everything was already confirmed before I shutdown armory to do the upgrade. I'm guessing that doing a "Rescan Database" will clear it up, but I'll hold off doing that in case you guys need some other log/trace data.

Strange... if you can still replicate the error can you go back to .9 and test if it's oding the same thing?  I don't think anything changed between .9 and .11 that would've induced that kind of error.

[1715624897]

1715624897

[1715624897]

1715624897

[PRab]

Strange... if you can still replicate the error can you go back to .9 and test if it's oding the same thing?  I don't think anything changed between .9 and .11 that would've induced that kind of error.

Rolled back to .9 and still have the same (broken) behavior. I wonder why I didn't see this before...

Edit:
I can send you the wallet if you like (its testnet).

[fran2k]

Final Testing Version before 0.92 (0.91.99.11-beta)
This will be the released version of 0.92 unless important/dangerous bugs are found (gotta stop polishing and just release it at some point).  Plan to rename this to 0.92 on Tues or Weds.

Installers for version 0.92 (pre-release 0.91.99.11-beta):
  Armory 0.91.99.11-beta for Windows XP, Vista, 7, 8+ 32- and 64-bit
  Armory 0.91.99.11-beta for MacOSX 10.7+ 64bit
  Armory 0.91.99.11-beta for Ubuntu 12.04+ 32bit
  Armory 0.91.99.11-beta for Ubuntu 12.04+ 64bit
  Armory 0.91.99.11-beta for RaspberryPi (armhf)


Offline Bundles:
  Armory 0.91.99.11-beta Offline Bundle for Ubuntu 12.04 32bit
  Armory 0.91.99.11-beta Offline Bundle for Ubuntu 12.04 64bit
  Armory 0.91.99.11-beta Offline Bundle for RaspbianPi (armhf)

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


Honestly, not a lot has changed from the .9 testing version except:

• Proper sorting of simultaneous ledger entries now (should've done that like 2 years ago)
• Offline message format upgrade warning when you attempt to create and unsigned transaction from the "Send Bitcoins" dialog (matching the one when you click "Offline Transactions" from the main window)
• Strips extraneous signatures from transactions just before broadcast -- it will carry the extra sigs around with it so you can see who has signed, but the extras are removed when you hit "Broadcast".

Great, I´m testing.

[Muhammed Zakir]

I watched the video. The whole process looks complicated at the moment to me.

I would expect that if I am in a group of people signing a multisign transaction, that the signature-process is happening in the tool.
At the moment it looks like that I have to send the partly-signed transaction with a file over to the next person via E-mail or another messaging system.
From a technical standpoint I undstand that the transaction needs to be signed by all required parties first, before it can be broadcasted.
On the otherhand would it be very hand if the partly signed transaction would automatically show up on the other person's wallet waiting for approval.

Like: "1 Transaction waiting for approval" type of messaging system.

I think DarkWallet will eventually have a P2P connection between parties to sign. However, many Armory users will have their keys in an offline system anyway, so they need some kind of transfer like that. Remember, Armory is targeted to the highest security aware users.

Would there be a way to actally embed transactions in the Blockchain which are not yet valid as they are only signed by one party? So for three signatures three times the miners fee would have to be payed, but who cares. would be awesome to use the already in place network for this. I guess the answer is no, but maybe someone knows for sure.

DarkWallet has a lot of features but still I don't think it has better security than Armory.

Thanks! It is good! So the miners fee is directly proportional to signatures, right? I think this is best wallet for providing escrow services.
Kindly,
      MZ

[etotheipi]

So... is version 0.92 bug-free or are people not testing anymore?    I'll take this as a good sign for the upcoming release!

Also, any Mac users please chime in -- we're anxious to find out if Mac stability improved with .9 and .11.  doug_armory found some patches that supposedly improved stability noticeably, but no one has yet commented on it.  I will assume no news is good news

[Searinox]

So... is version 0.92 bug-free or are people not testing anymore?    I'll take this as a good sign for the upcoming release!

Also, any Mac users please chime in -- we're anxious to find out if Mac stability improved with .9 and .11.  doug_armory found some patches that supposedly improved stability noticeably, but no one has yet commented on it.  I will assume no news is good news

Windows 7: Armory pops up in front despite having the option to start minimized to tray checked. And it's quite very annoying. The issue persists with version 0.91.99.11.

[doug_armory]

Also, any Mac users please chime in -- we're anxious to find out if Mac stability improved with .9 and .11.  doug_armory found some patches that supposedly improved stability noticeably, but no one has yet commented on it.  I will assume no news is good news

I haven't heard much personally. I've seen a couple of bug reports regarding crashes. One person says they're using the "latest" Armory but hasn't confirmed which exact version they're using (i.e., I don't know if they're using a patched version). Another person was using 0.91.99.8 and said that upgrading to 0.91.99.11 fixed their particular crash issues. Again, I'm not promising anyone any magic bullets, but anecdotal evidence seems to suggest that the OS X build is reasonably stable at this point.

[etotheipi]

So... is version 0.92 bug-free or are people not testing anymore?    I'll take this as a good sign for the upcoming release!

Also, any Mac users please chime in -- we're anxious to find out if Mac stability improved with .9 and .11.  doug_armory found some patches that supposedly improved stability noticeably, but no one has yet commented on it.  I will assume no news is good news

Windows 7: Armory pops up in front despite having the option to start minimized to tray checked. And it's quite very annoying. The issue persists with version 0.91.99.11.

I cannot replicate this.  I have tested in both Linux and Windows, and the option works for me.  Please try renaming your ArmorySettings.txt file (in C:\Users\<user>\AppData\Roaming\Armory), and then start Armory again -- it will be like new, asking you to agree to the EULA, etc.  Try setting the option again in the menu and then restart.  Tell me if it works.

[Searinox]

So... is version 0.92 bug-free or are people not testing anymore?    I'll take this as a good sign for the upcoming release!

Also, any Mac users please chime in -- we're anxious to find out if Mac stability improved with .9 and .11.  doug_armory found some patches that supposedly improved stability noticeably, but no one has yet commented on it.  I will assume no news is good news

Windows 7: Armory pops up in front despite having the option to start minimized to tray checked. And it's quite very annoying. The issue persists with version 0.91.99.11.

I cannot replicate this.  I have tested in both Linux and Windows, and the option works for me.  Please try renaming your ArmorySettings.txt file (in C:\Users\<user>\AppData\Roaming\Armory), and then start Armory again -- it will be like new, asking you to agree to the EULA, etc.  Try setting the option again in the menu and then restart.  Tell me if it works.

I moved the ENTIRE Armory directory away and let it create a fresh one as if it never ran before. It may be an issue with the Expert UI or something of my particular mix of settings. I am linking a paste of my ArmorySettings.txt, try using these and see if the issue is replicated. http://pastebin.com/Qf2Rb0ZG

[KrakenTrader]

just downloading 0.92 version
 I am keen to try how multisig function works, to be used for escrow service.
When it works as described, I'd consider it as one of the best ways to do escrow.

[drips]

Bug 1:

Replicate:

• make a new transaction, up until the Confirm Transaction screen
• close the confirm screen

Wallet is now completely non-responsive to all button clicks, must be force quit due to the close buttons not working.


Bug 2:

If all internet connectivity is disabled in the settings, outgoing connections are still made regardless.

https://i.imgur.com/QYarjSV.jpg

https://i.imgur.com/dCkurUO.jpg


Bug 3:

https://i.imgur.com/tmTaMul.jpg

Replicate:

• make a transaction
• tick "use existing change address"

Text is squashed, if the window is made bigger the radio buttons don't work properly.

[etotheipi]

About bug 2:  this is intentional.  You can only 100% disable it using --skip-announce-check from the command-line when starting Armory.  We wanted to make it possible to fully disable it, but not too easy either.  The reasoning is that in the case of a major network event (such as a hardfork), it is critical for us to be able to communicate with users (always offline-signed, of course!), to let them know how to deal with it.   A hard-fork can leave open a period of non-consensus that a resourceful attacker could exploit to reverse a transaction. 

This is communicated to you through the settings window, further down where you select the notification levels.  Only critical security notifications will be retrieved from the server at the highest level, but you can fully disable it with the command-line option.

[CircusPeanut]

Bug 1:

Replicate:

• make a new transaction, up until the Confirm Transaction screen
• close the confirm screen

Wallet is now completely non-responsive to all button clicks, must be force quit due to the close buttons not working.

Bug 3:

Replicate:

• make a transaction
• tick "use existing change address"

Text is squashed, if the window is made bigger the radio buttons don't work properly.

What's your version? I have seen bug #1 and #3 in the past, and I believe they are fixed now. I am unable to reproduce them with 0.91.99.11.

[doug_armory]

Bug 1:

Replicate:

• make a new transaction, up until the Confirm Transaction screen
• close the confirm screen

Wallet is now completely non-responsive to all button clicks, must be force quit due to the close buttons not working.

Bug 3:

Replicate:

• make a transaction
• tick "use existing change address"

Text is squashed, if the window is made bigger the radio buttons don't work properly.

What's your version? I have seen bug #1 and #3 in the past, and I believe they are fixed now. I am unable to reproduce them with 0.91.99.11.

Same here. Just tested on OS X, which appears to be what the OP is using. Everything works fine.

[PRab]

I got curious and ran "Rescan Databases" on my testnet wallet that said that the inputs were already spent and it resolved the issue. At least if it comes up again, there is an easy way to recover.

[redphlegm]

So... is version 0.92 bug-free or are people not testing anymore?    I'll take this as a good sign for the upcoming release!

Also, any Mac users please chime in -- we're anxious to find out if Mac stability improved with .9 and .11.  doug_armory found some patches that supposedly improved stability noticeably, but no one has yet commented on it.  I will assume no news is good news

Startup & loading on my mac (Mavericks with latest updates) is significantly improved. I can't speak to stability though because it wasn't my main machine and I don't make many transactions on that machine. I'm sort of waiting on the "final" version though before I replace what I have on my main machine.

[redphlegm]

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?

[doug_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.

[redphlegm]

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.

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