Bitcoin Forum
April 23, 2014, 09:15:37 AM *
News: Due to the OpenSSL heartbleed bug, changing your forum password is recommended.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Two-person cold storage using the raw transactions API  (Read 1190 times)
Gavin Andresen
Hero Member
*****
qt
Offline Offline

Activity: 1330


Chief Scientist


View Profile WWW

Ignore
July 24, 2012, 02:54:47 PM
 #1

There's a prettier version of this here: https://gist.github.com/3161162

Goal:
Multi-person 'cold storage' wallet, using the upcoming 0.7-release 'raw transactions' JSON-RPC api (geek's multisig):

Setup:
Alice generate a public/private keypair. She prints them out and stores them somplace physically secure offsite as a backup. She secures the private key in a way she can easily access.

Bob does the same, then Alice and Bob exchange public keys and both form a 2-of-2 multisig address using addmultisigaddress and verify that it's the same for both of them.

0.1 BTC are sent to the multisig address, then Alice and Bob follow the spend procedure to make sure it works properly. If it does, the multisig address is fully funded as the secure 'cold' wallet. Public keys, multisig address, and funding/spending Transaction IDs and amounts are kept in a spreadsheet accessible to Bob and Alice (and potentially anybody else interested in auditing; Google Docs or DropBox or any other document-sharing solution works).

To detect security breaches, Alice and Bob should send a token amount of bitcoin (say 1 BTC) to the public keys that they are using, and should never spend those coins. Both addresses should be monitored by both Alice and Bob, and if they see coins being spent they should assume that the corresponding private key has been compromised and transfer the multisignature coins to a new, secure multisig address with fresh keys generated on devices that have not been compromised.

Spend:
Alice selects enough unspent transactions to withdraw the amount she wants and cover fees. She updates the Google Doc document and marks the funding transactions as 'PENDING SPEND'.

She calls createrawtransaction with those inputs and one or two outputs:
  • Output to the address where the withdrawal is going
  • Change output, back to the multisig address
She calls signrawtransaction, passing in her private key, and then send the half-signed transaction to Bob (via email or any other method).

Bob calls decoderawtransaction and checks with Alice to make sure the transaction is OK (Bob and Alice either communicate in advance via phone or Bob calls Alice to verify the transaction details).

Assuming all is OK, Bob calls signrawtransaction and then sendrawtransaction to broadcast to the network. He marks the PENDING SPEND inputs in the shared spreadsheet 'SPENT', and adds the change output (if any) to the spreadsheet as a new potential input for future spends.

Variations/notes:
Depending on the level of security felt to be necessary, securing the private keys might involve encrypting them with pgp and a passhprase and storing them encrypted on the computer or in the cloud. Or storing them in a LastPass secure note. Or storing them on a passphrase-protected IronKey USB stick. Alice and Bob don't necessarily have to follow the same procedure for securing their private keys.

If Alice or Bob suffer any sort of security breach or some period of time goes by (1 year?), they should generate new keys and a new address and send all funds to the new address.

If Alice and Bob do this more than twice, a little front-end tool that automated much of the process would be a worthwhile investment; that tool could be a prototype for adding complete multisig support to Bitcoin-Qt. Then again, it might just be easier to add support to Bitcoin-Qt in the first place.

Extending this so any two of (Alice,Bob,Carol) can authorize a transaction out of the wallet is straightforward, and would prevent loss of funds if any one of them completely lost access to their private key. Or if even more security is needed then requiring all three authorize withdrawals is also straightforward.

Sending the change back into the same multisig address is somewhat bad for both security (the public keys associated with the address are revealed at the first spend transaction) and privacy. This can also easily be extended to use two (or more) Hierarchical Deterministic Keys (see BIP 32), with a new multisig address generated for any change on every withdrawal.

Alice and Bob might be one person, of course, using two different computers.

Will I see you in Amsterdam?
  http://bitcoin2014.com/
1398244537
Hero Member
*
Offline Offline

Posts: 1398244537

View Profile Personal Message (Offline)

Ignore
1398244537
Reply with quote  #2

1398244537
Report to moderator
Buy a Blade, Get a 5-Chip Free!
Start Mining with GAWMiners.com
24/7 Live Phone & Tech Support
Free Hosting & Electricity for 1 Year!

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1398244537
Hero Member
*
Offline Offline

Posts: 1398244537

View Profile Personal Message (Offline)

Ignore
1398244537
Reply with quote  #2

1398244537
Report to moderator
1398244537
Hero Member
*
Offline Offline

Posts: 1398244537

View Profile Personal Message (Offline)

Ignore
1398244537
Reply with quote  #2

1398244537
Report to moderator
ben-abuya
Sr. Member
****
Offline Offline

Activity: 323



View Profile WWW

Ignore
July 24, 2012, 05:06:30 PM
 #2

Awesome! This is a huge step forward for Bitcoin security, and I really think it will open the door for the safe storage of millions and billions of dollars of Bitcoin value, as well as the use of Bitcoin for partnerships and companies. And those are just the obvious applications.

http://lamassubtc.com/
Lamassu Bitcoin Ventures
cjp
Full Member
***
Offline Offline

Activity: 165



View Profile

Ignore
July 24, 2012, 06:00:54 PM
 #3

What does this mean? Does it only mean that client version 0.7 will have M-of-N signing functionality through its API? Or did I miss something?

Don't understand me wrong: I think that will be a big improvement, but I suspect I'm missing something, since you wrote such a long post about it.

Donate to:
1KNgGhVJx4yKupWicMenyg6SLoS68nA6S8
jancsika
Member
**
Offline Offline

Activity: 81


View Profile

Ignore
July 24, 2012, 06:42:50 PM
 #4

To detect security breaches, Alice and Bob should send a token amount of bitcoin (say 1 BTC) to the public keys that they are using, and should never spend those coins. Both addresses should be monitored by both Alice and Bob, and if they see coins being spent they should assume that the corresponding private key has been compromised and transfer the multisignature coins to a new, secure multisig address with fresh keys generated on devices that have not been compromised.

Unless I'm a rat after the big block of cheese, in which case I'm probably smart enough to pass up the small piece sitting on the rat-trap while making my way to the fridge.
Gavin Andresen
Hero Member
*****
qt
Offline Offline

Activity: 1330


Chief Scientist


View Profile WWW

Ignore
July 24, 2012, 06:57:24 PM
 #5

Unless I'm a rat after the big block of cheese, in which case I'm probably smart enough to pass up the small piece sitting on the rat-trap while making my way to the fridge.
Yes, but if Bob and Alice keep the 2-of-2 multisig address secret, then you, the rat, will have no idea that they key you managed to steal is one of the two keys needed to open the fridge.

That's why I say that sending the change back into the same multisig address every time is somewhat bad for security...

What does this mean? Does it only mean that client version 0.7 will have M-of-N signing functionality through its API?
Yes, that was announced before (see the thread about the raw transactions api).

Will I see you in Amsterdam?
  http://bitcoin2014.com/
apetersson
Hero Member
*****
Online Online

Activity: 633


mycelium.com


View Profile WWW

Ignore
July 24, 2012, 07:01:32 PM
 #6

i am currently also develping BIP11 support for BitcoinJ as a followup from the Berlin Hackathon:

http://code.google.com/r/andreaspeterssonat-hackathon/source/checkout

Gavin, are you referring to BIP16 with this text?
elena.m
Newbie
*
Offline Offline

Activity: 24



View Profile

Ignore
July 24, 2012, 07:02:43 PM
 #7

To detect security breaches, Alice and Bob should send a token amount of bitcoin (say 1 BTC) to the public keys that they are using, and should never spend those coins. Both addresses should be monitored by both Alice and Bob, and if they see coins being spent they should assume that the corresponding private key has been compromised and transfer the multisignature coins to a new, secure multisig address with fresh keys generated on devices that have not been compromised.

This is awesome and will be extremely helpful. And if it ever gets a usable UI, it'll make escrow a lot easier. Great work!

I am available for hire. (https://bitcointalk.org/index.php?topic=93064.0)
PGP: 4BE75914
Gavin Andresen
Hero Member
*****
qt
Offline Offline

Activity: 1330


Chief Scientist


View Profile WWW

Ignore
July 24, 2012, 07:10:34 PM
 #8

i am currently also develping BIP11 support for BitcoinJ as a followup from the Berlin Hackathon:

http://code.google.com/r/andreaspeterssonat-hackathon/source/checkout

Gavin, are you referring to BIP16 with this text?

Yes-- bitcoind creates BIP16 multisig transactions (using BIP13 addresses). Because a BIP16 transaction doesn't reveal public keys until the first spend, if an attacker has only one of the public keys (and the multisig address has been funded but never spent) they won't be able to figure out that the key is helping to protect a large multisig-protected balance.

Will I see you in Amsterdam?
  http://bitcoin2014.com/
cbeast
Donator
Hero Member
*
Offline Offline

Activity: 1064

Bitcoin, Decorporated stockholder since 2011.


View Profile

Ignore
July 24, 2012, 09:24:13 PM
 #9

This is a practical use.  It would be useful for bond creation, especially if there were 2 or preferably several more involved to keep each other honest. Physical bonds would also be secured with one or more secured seals. Businesses on GLBSE could use this for posting dividends.

*posted via Margaritas on the beach.

Any significantly advanced cryptocurrency is indistinguishable from Ponzi Tulips.
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!