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

[etotheipi]

Armory Multi-Signature "Lockboxes" with Simulfunding
Testing Bounty - 0.03 BTC per bug (up to 1.5 BTC)  


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

Check out our Lockbox tutorials:   https://bitcoinarmory.com/using-lockboxes/







EDIT:  Thanks to SimonBelmond for sending us a link to this intro Armory multi-sig intro video:  http://vimeo.com/96983886
EDIT²:  We actually redesigned the interface/dashboard, so his video doesn't show what the latest version looks like, though the process is the same

I am pleased to announce that Armory has finally completed the design and initial testing of "multi-signature lockboxes" in Armory.  This is the first truly generic, fully-decentralized multi-signature interface available for any cryptocurrency.  Armory is innovating multi-sig the same way it innovated offline wallets -- taking a concept that is inherently complex, and making it about as simple as it can be.  It is still an advanced tool, but makes available features that haven't existed before!

Not only that, but the interface works seamlessly with hot or cold wallets, alike!   To understand how powerful this is, consider that you could independently setup 7 different laptops in five vaults around the world, and a signature is required from physically visiting each one, in order to move any of the money.   Yet you can receive money to it and track its balances safely from an online computer (just like a watching-only wallet, it only has public keys).    Or you can setup a 2-of-2 with hot Armory wallets and simply improve your security for the funds held by you and your spouse.  Or somewhere in between.  Really, the flexibility is astounding, and this solution is the "manual transmission" version that requires no third-party services.  It could be executed by any number of anonymous parties using nothing but email or pastebin.  

The interface enables the following operations (and all work as expected with offline/watch-only wallets):

• Create Lockbox:
  
  • Participants:  Provide Public Keys
  • Organizer: Collect Keys, Define Lockbox, Distribute
  • Participants: Import LOCKBOX definition
• Deposit into lockbox (regular):  
  
  • Use regular send-BTC interface
• Deposit (simulfunding, for certain contract types):
  
  • Participants: Create Promissory Notes
  • Organizer:  Merge Notes to Create Simulfunding Tx
  • Participants: Review and Sign Simulfunding Tx
• Spend:  
  
  • Organizer: Create Proposed Spend
  • Participants: Review and Sign
  • Organizer: Collect Signatures & Broadcast

This process uses no centralized servers or third-party services!  Instead, it provides you with chunks of ASCII-armored text which can be circulated to participants via email (inline) and/or saved to USB key to be taken to offline computers to retrieve signatures.  In the future, Armory Technologies, Inc, will be providing servers to facilitate the data exchanges and simplify the process, though we wanted to make sure that a [usable!] truly decentralized solution was available at all times  [Plus, all automated solutions will just build off the manual solution]


Caveats:

• This does not use BIP32 determinstic key chains!  A lockbox is like a single multi-sig address.  If you do not spend the full amount, change is sent back to the same lockbox.  With regular addresses, this is a privacy concern.  With lockboxes, the privacy issues are mostly unavoidable:  the vast majority of transactions on the network still single-sig, thus a multi-sig change address would be obvious even if a new multisig address was created to receive the change.  By the time this matters, Armory will have the BIP-32 linked wallet stuff in place.
• All message formats changed, including those used for regular offline transactions (which are a special case of multisig: 1-of-1).  If you upgrade your online system that creates offline transactions, you would have to update your offline computer to be able to read and sign these new transaction messages.

Other notes:
The best way to do testing is to run a couple instances of Armory at the same time.  All Armory instances on the same computer can share a single Bitcoin-Core instance, but must have separate --datadir=  settings.  Additionally, you will have to set a random --interport to avoid Armory detecting the already-open instance and aborting.  For instance, I do testing with 3 Armory instances, I run them as follows:

[/list]

Code:

python ArmoryQt.py --debug --testnet --datadir=~/.armorytest1 --interport=9913
python ArmoryQt.py --debug --testnet --datadir=~/.armorytest2 --interport=9914
python ArmoryQt.py --debug --testnet --datadir=~/.armorytest3 --interport=9915

The datadir paths must exist before running the above!  If you corrupt your databases by accidentally running on the same datadir with different interports, use the --rebuild option to fix it.  It only takes a few minute on testnet.


And now for the pretty pictures:

Collect public keys from participants to create a lockbox:


Manage multiple lockboxes:



Collect signatures from all devices/parties:


Each user selects a source wallet and destination lockbox to create a promissory note.  Then the organizer merges them into a funding transaction to be signed by all funders


Once the promissory notes are collected, the parties have to sign.  This works identically to spend-from-lockbox (it's the same dialog).  Note that it only shows you the net value difference for each wallet, even though each "funder" is providing both inputs and change.  Armory figures it out.


As you can see, the final transaction has three different input wallets, and change back to those wallets as well.  

[1713905635]

1713905635

[1713905635]

1713905635

[1713905635]

1713905635

[1713905635]

1713905635

[1713905635]

1713905635

[etotheipi]

Reserved!

[gbmracing]

In your 3-of-4 wallet, the pie charts have 3 slices and in the 2-of-3 wallets, the pie charts only have 2 slices.  It seems like the pie slices are off?

I also think you should enable some integrated mobile/email notification system so the recipients get the block instantly.  Secure message maybe?  And in the same way, they should be able to sign and broadcast back to you without copy/pasting anything or any USB.  All self contained in the client.

[piotr_n]

You can use Armory's "lockbox" interface to store coins with 5-of-5 protection, using five cold laptops stored in different vaults around the world.  Each laptop generates its wallet completely independently, offline, and without any knowledge of the other laptops.  The public keys are then combined to create a lockbox where savings can be held.  Transactions that spend money from this lockbox require a visit to all five vaults to boot each laptop to review and sign.  

Or just use it with two regular online computers.  Or somewhere in between.  Use your imagination to meet your security, redundancy and convenience preferences!

From start to finish, there are no single points of failure.  

Not to be rude, but if you hadn't been boasting so much, I would not have pointed out that my software has had such a  feature built in and working for like months already.
Though, tbh, with much less cool name and no fancy GUI
But at the other hand I believe I managed to explain how to use it in a slightly simpler way: http://www.assets-otc.com/gocoin/manual/multisig

[etotheipi]

Not to be rude, but if you hadn't been boasting so much, I would not have pointed out that my software has had such a  feature built in and working for like months already.
Though, tbh, with much less cool name and no fancy GUI
But at the other hand I believe I managed to explain how to use it in a slightly simpler way: http://www.assets-otc.com/gocoin/manual/multisig

It is precisely the "fancy GUI" which is what makes our implementation exciting.  Both cold storage and multisig have existed in low-level tools for quite some time, but most of them require an extremely high level of sophisitication by the user in order to run terminal/interpretter commands, manually collecting input transaction hashes, etc.   Just like with cold storage, creating an interface that hides all the unnecessary details and is usable by non-Bitcoin-experts is quite challenging.  Especially when you assume that any or all devices could be offline and some may be providing multiple signatures (Armory's multi-wallet interface helps make this a smooth experience).

Admittedly, I did not realize that gocoin had these multisig features available.  And if I had known, I would've played with it and provided feedback.  And I wouldn't have boasted so loudly about the "only generic, fully-decentralized interface for multi-signature transactions."  But I do think that what we just released provides a level of multi-sig usability unmatched by any other existing tools out there.  I'll have to make a demo video...

Either way, we really need testers!  And we're paying!  So anyone reading this, I just upped the bounty to 0.03 BTC per bug.  Rig a few instances to run at the same time (or just use multiple wallets), and find some bugs.

[piotr_n]

I personally prefer no GUI, because it gives me a better impression of security and makes the choice of the host environment far more flexible.
But I see where you're coming from; most people these days prefer mouses over keyboards and if they can operate it using only a mouse, they are usually willing to pay for it a few times more.
On a related topic, I heard Bill Gates once said that, according to their research, if a product had a letter X or V in its name, they could sell it for 20% more

Anyway, this specific feature seems very hard to be made user-friendly and secured at the same time.
I spent a lot of time trying to simplify the process, but I agree that it still isn't something that Gavin's granny could handle.
I will be looking forward though to see how other people approached the problem.
Sorry that I have no time to check it out and test a bit in Armory, but I will gladly watch the video, because from description in OP the process doesn't look much simpler than mine.
In fact it seems quite the same. The only difference I see is that you have a central point that collects the signatures from all the parties, whilst in my case people come to add signatures one after another and the last one to sign can just broadcast the transaction out.

[etotheipi]

I spent a lot of time trying to simplify the process, but I agree that it still isn't something that Gavin's granny could handle.

I have no illusions about anyone's grandmother executing this process.  Nor doing regular offline transactions.  But there is a large class of users for whom this is the first usable solution without having to understand tx structure, UTXOs, change outputs, etc.  

The only difference I see is that you have a central point that collects the signatures from all the parties, whilst in my case people come to add signatures one after another and the last one to sign can just broadcast the transaction out.

There is no central authority -- it's fully decentralized.  One person/device prepares the transaction, and whichever device adds/imports the last signature can broadcast it.  It is passed around as ASCII-armored blocks of text that can be emailed, and/or copied to USB to take to offline devices.  We would like to add a central server that would help users pass the data around, further improving the usability for those who want it... but the decentralized solution would always be available.

P.S. -- This is what people pass around to collect sigs (either inline in emails, or save to file):

=====TXSIGCOLLECT-4ogNaap7======================================================
AQAAAAsRCQcAAAAAAf1OAgEAAAALEQkHX/rr6vit6h6hFEtrSevRUWb0ev79VNLukkIjNUNoZj8AAAAA
/QABAQAAAAEGOwaI7hG2eALnVRhP5U9htkL5nR7pkmuhA++lkvmwjgAAAACLSDBFAiALPCTF3jPh238+
0TRiv7078ukWSykh5etoOC92mgHUtgIhANoaevyjicUcXZrBG4B05MCe0b6Ao4oQF1MWratKk51XAUE E
ziXsxcDUeorfEALx23AQ7/850SCxb/a+ZxbqIQ48ExhQgyCnQRF8ljIqOHz+5p7nJrWdfhVy2vtwICfz
vFbMff////8CQHh9AQAAAAAXqRTllz72+r9S3h22NtdNbPS0W/TqhofAcCc0AAAAABl2qRRJvTihhk4j
NbkfeRLljm0F7x58aYisAAAAAIdSQQRaVaMnjUAAEwZ8WtKXeCYt1UlDBNmX3woLIHwh2+sDB8xs5nqY
6iygkHrJZMSUJncnX/g29PgFrv9Sco2BZKh/QQSTtOSfxz3CHvwktSKnps0SiTZwzoLBqyuju1BawtJn
5FvVUfOSJGjflmvJVB8A3Kk6IIbdW14wv8/YpL4yZpfsUq4ISHVla2pwcEwA/////wJBBFpVoyeNQAAT
Bnxa0pd4Ji3VSUME2ZffCgsgfCHb6wMHzGzmepjqLKCQeslkxJQmdydf+Db0+AWu/1JyjYFkqH8AAEEE
k7Tkn8c9wh78JLUip6bNEok2cM6Cwasro7tQWsLSZ+Rb1VHzkiRo35ZryVQfANypOiCG3VteML/P2KS+
MmaX7AAAATQBAAAACxEJBxl2qRTAJVPUOGJ3S2BllgR6HNc32I8NloisMFF9AQAAAAAAAAROT05FAAA A
================================================================================

[Abdussamad]

Armory could so use an HCI person. Multiple headlines screaming for attention, large blocks of text and an interface with so much going on.

[escrow.ms]

My OS: Windows 8.1
I'm using Regular Installation version.

There's no testnet blockchain torrent available in Testnet Armory? I have to sync bitcoin client normally (it sucks with slow net.)
Meanwhile Testnet armory is offline even when bitcoind is running in background.

[etotheipi]

Armory could so use an HCI person. Multiple headlines screaming for attention, large blocks of text and an interface with so much going on.

I have wanted to get someone in here to not only give us some guidance on the interface stuff, but perhaps create some Qt themes for us which would standardize the buttons, headlines, fonts, styles, etc.  I feel like I'm good at making interfaces extremely functional, but I'm all over the place in terms of presented information quantity and style. 

Feel free to make specific recommendations for any of the existing dialogs, and if it's good I'll implement it give you a bounty for it.

Meanwhile Testnet armory is offline even when bitcoind is running in background.

Make sure you disable "Let Armory run Bitcoin Core in the background" from File->Settings.  If it's still offline, it usually tells you why.

[escrow.ms]

Make sure you disable "Let Armory run Bitcoin Core in the background" from File->Settings.  If it's still offline, it usually tells you why.

My armory is offline and Multisig feature doesn't lets me create Promissory Notes. (So technically we need to sync blockchain first right?)
https://i.imgur.com/3Qb8IIU.png

You can use Armory's "lockbox" interface to store coins with 5-of-5 protection, using five cold laptops stored in different vaults around the world.  Each laptop generates its wallet completely independently, offline, and without any knowledge of the other laptops.  The public keys are then combined to create a lockbox where savings can be held.  Transactions that spend money from this lockbox require a visit to all five vaults to boot each laptop to review and sign.

 

(Well Actually After reading this, I thought users will be able to create Promissory Notes in offline Armory. Or maybe I didn't understood process properly.)

[etotheipi]

My armory is offline and Multisig feature doesn't lets me create Promissory Notes. (So technically we need to sync blockchain first right?)

You can't create a promissory note if you don't know your balance/UTXO-set.  The note is a list of all the inputs and a change output that you will be contributing to the simulfunding transaction.  You must pull the input list (UTXOs) from the blockchain.

I would say skip simulfunding for now.  I think that simulfunding might be moved a bit further back in the interface until we get a synchronization server to assist with it.  It definitely works, but it's an awful lot of steps for each of the parties to execute and I'm not sure many users will have the patience for it.  I still want it to be available as-is, but I'll find a way to make it less prominent since I think most users will be using lockboxes for personal savings which doesn't require simulfunding -- it might just confuse them.

[escrow.ms]

Alright, I am waiting for QT to sync, after that i'll try to test it.
By the way, Let's say I am using it for personal savings. I made a new lockbox and added some funds in it using one of my armory wallet. Now what I need to backup to access my lockbox in future? Just my wallet or I have to export lockbox and keep that data safe too somewhere?

Actually I asked this question because it doesn't shows any warning to keep file safe in case of hardware failure etc.

[etotheipi]

Alright, I am waiting for QT to sync, after that i'll try to test it.
By the way, Let's say I am using it for personal savings. I made a new lockbox and added some funds in it using one of my armory wallet. Now what I need to backup to access my lockbox in future? Just my wallet or I have to export lockbox and keep that data safe too somewhere?

Actually I asked this question because it doesn't shows any warning to keep file safe in case of hardware failure etc.

Great question (and worth a bounty).  We should at least add a note about that in the interface.  As long as the relevant wallets are backed up in the regular way, the coins will be recoverable -- though it will be much easier if you backup the LOCKBOX block.  When we do the new wallets, we had planned to put that information into a separate file that could be backed up regularly, such as in Dropbox or similar service.  Rather, you will have the option to store a separate file to hold multisig info and tx/addr comments, with optional encryption (and the data will be stored in both the main wallet and the separate file).

However, this is minor because all the devices must have the lockbox definition, so if you lose it on one system, you can re-export-import it.  Or if it's multiple parties, anyone can give it to you to reimport.  As long as you have the same wallets as before (probably restored from paper), everything will be back to normal.

[rarebitproject]

There is no central authority -- it's fully decentralized.  One person/device prepares the transaction, and whichever device adds/imports the last signature can broadcast it.  It is passed around as ASCII-armored blocks of text that can be emailed, and/or copied to USB to take to offline devices.  We would like to add a central server that would help users pass the data around, further improving the usability for those who want it... but the decentralized solution would always be available.

P.S. -- This is what people pass around to collect sigs (either inline in emails, or save to file):

=====TXSIGCOLLECT-4ogNaap7======================================================
AQAAAAsRCQcAAAAAAf1OAgEAAAALEQkHX/rr6vit6h6hFEtrSevRUWb0ev79VNLukkIjNUNoZj8AAAAA
/QABAQAAAAEGOwaI7hG2eALnVRhP5U9htkL5nR7pkmuhA++lkvmwjgAAAACLSDBFAiALPCTF3jPh238+
0TRiv7078ukWSykh5etoOC92mgHUtgIhANoaevyjicUcXZrBG4B05MCe0b6Ao4oQF1MWratKk51XAUE E
ziXsxcDUeorfEALx23AQ7/850SCxb/a+ZxbqIQ48ExhQgyCnQRF8ljIqOHz+5p7nJrWdfhVy2vtwICfz
vFbMff////8CQHh9AQAAAAAXqRTllz72+r9S3h22NtdNbPS0W/TqhofAcCc0AAAAABl2qRRJvTihhk4j
NbkfeRLljm0F7x58aYisAAAAAIdSQQRaVaMnjUAAEwZ8WtKXeCYt1UlDBNmX3woLIHwh2+sDB8xs5nqY
6iygkHrJZMSUJncnX/g29PgFrv9Sco2BZKh/QQSTtOSfxz3CHvwktSKnps0SiTZwzoLBqyuju1BawtJn
5FvVUfOSJGjflmvJVB8A3Kk6IIbdW14wv8/YpL4yZpfsUq4ISHVla2pwcEwA/////wJBBFpVoyeNQAAT
Bnxa0pd4Ji3VSUME2ZffCgsgfCHb6wMHzGzmepjqLKCQeslkxJQmdydf+Db0+AWu/1JyjYFkqH8AAEEE
k7Tkn8c9wh78JLUip6bNEok2cM6Cwasro7tQWsLSZ+Rb1VHzkiRo35ZryVQfANypOiCG3VteML/P2KS+
MmaX7AAAATQBAAAACxEJBxl2qRTAJVPUOGJ3S2BllgR6HNc32I8NloisMFF9AQAAAAAAAAROT05FAAA A
================================================================================

A standard text format for "sig codes" that can be sent between users is what multisig needs.

Can this become a BIP?  Something like this can become a standard that all the wallets and other services can support.

But, ...

Would it be better to use JSON clear text, so the user can see what tx/out/etc the sig refers to?  Otherwise, users will get several sigcodes mixed up and go crazy.

[etotheipi]

A standard text format for "sig codes" that can be sent between users is what multisig needs.

Can this become a BIP?  Something like this can become a standard that all the wallets and other services can support.

But, ...

Would it be better to use JSON clear text, so the user can see what tx/out/etc the sig refers to?  Otherwise, users will get several sigcodes mixed up and go crazy.

There is very little infrastructure right now requiring interoperability.  Turning this into a BIP before we've even fully spec'd out the design space would simply slow down our ability to innovate these kinds of features.  I'm not against interoperability, but I tried it with BIP 10 when I was doing offline transactions, and everyone on the mailing list was kind of like "meh, none of us are doing offline transactions, you're on your own" (I don't remember exactly what was said, but it certainly didn't go anywhere -- I tried twice).  

The one exception to this is BitPay with Cosign.  I actually talked to RXC from BitPay and he basically said the same thing -- we're happy to do our own things at the moment get all the kinks worked out with our own users, and then create a BIP and both/all commit to it later.

[SimonBelmond]

This cool video should be linked in the top 1 or 2 posts as well (might have missed it when skimming through):

http://vimeo.com/96983886

Edit: And this is the reddit discussion: http://www.reddit.com/r/Bitcoin/comments/26ya9a/armory_multisig_demonstration/

[LOL]

I can "Delete private keys only, make watching-only," without entering in password for that wallet. Selecting the option to print a paper backup does not function, and makes the "Delete" button nonfunctional.

Restoring a watch only wallet via paper backup just temporarily removes the wallet from the UI. Closing and reopening brings it back as a watch only  wallet once again. Watch only wallet has to be deleted for restoration of that wallet with a paper backup.

Please request details if that would be helpful.

[Corelianer]

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.

[SimonBelmond]

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.