Bitcoin Forum
December 09, 2016, 09:47:24 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Second key for Bitcoin wallets  (Read 1079 times)
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
January 10, 2011, 11:45:31 PM
 #1

I would like to formally propose the idea that the Bitcoin protocol and software be modified to allow the following (or perhaps someone can explain how the following can be done within the existing framework and the transactions still be considered valid):

- Encumber a bitcoin address with a more than one private key (given a signed transaction request by the first key).
- Remove or change the encumbrance (given a signed transaction by all controlling private keys).
- Allow the encumbrance to declare which keys are needed to sign future transactions (e.g. "both keys", or "either key", or perhaps " keyA AND (keyB OR keyC)", where keyA was the original address key).

WHY?

BIG 1. This kind of logic is vital for any scheme that allows Bitcoins to be persisted within tangible objects with embedded private keys, without having to trust that the person who made the object could later steal the bitcoins because he probably knows the private key.  The ability to confidently trade Bitcoins in tangible form is something that would really advance the objectives of Bitcoin within society.

Significant secondary benefits:
2. The possibility of creating trustee-based arrangements that mitigate the risks of: a) theft or loss of wallet.dat b) the failure of a smart card that contained bitcoins
3. All of the benefits that already lead people to open checking accounts that require two signatures

It is my understanding that this might remotely be possible... or at least, that it might be possible within the "operation" syntax used by Bitcoin but may not necessarily constitute a transaction that will be accepted as valid.  Looking for feedback.

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481320044
Hero Member
*
Offline Offline

Posts: 1481320044

View Profile Personal Message (Offline)

Ignore
1481320044
Reply with quote  #2

1481320044
Report to moderator
1481320044
Hero Member
*
Offline Offline

Posts: 1481320044

View Profile Personal Message (Offline)

Ignore
1481320044
Reply with quote  #2

1481320044
Report to moderator
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
January 11, 2011, 06:30:31 AM
 #2

Digging into the source code and trying to understand this scripting scheme, I'm convinced that this is all already possible without modification.  If I understand it right, encumbering bitcoins with two private keys would look like this.

OP_DUP OP_HASH160 key1 OP_EQUALVERIFY OP_CHECKSIG OP_VERIFY OP_DUP OP_HASH160 key2 OP_EQUALVERIFY OP_CHECKSIG

And that "a and (b or c)" logic could be achieved with the "if" conditional operator.

Given the presence of a OP_CHECKMULTISIG, someone has obviously thought of this first.  It's just not visible in the client, but present in the architecture.


Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2506


View Profile
January 11, 2011, 07:27:55 AM
 #3

OP_DUP OP_HASH160 key1 OP_EQUALVERIFY OP_CHECKSIG OP_VERIFY OP_DUP OP_HASH160 key2 OP_EQUALVERIFY OP_CHECKSIG

That will work. The keys in your example would actually be key hashes. You can use OP_CHECKSIGVERIFY for the first OP_CHECKSIG to make it a byte smaller.

The scriptSig would look like:
<sig2> <key2> <sig1> <key1>

If you can use full public keys in the scriptPubKey instead of hashes, it becomes even more compact:

scriptSig: <sig2> <sig1>
scriptPubKey: 2 <key1> <key2> 2 OP_CHECKMULTISIG

With OP_CHECKMULTISIG, you can also change the first 2 in the scriptPubKey to a 1 in order to require either key1 or key2 to sign. And you can specify up to 20 public keys with a single OP_CHECKMULTISIG.

Your "keyA AND (keyB OR keyC)" is as simple as this (assuming you can use the full public keys):
1 <keyB> <keyC> 2 OP_CHECKMULTISIGVERIFY <keyA> OP_CHECKSIG

Even when using key hashes, you can use stack ops to manipulate the stack into a format that can work with OP_CHECKMULTISIG, but I don't think that's better in this case. Too bad Script has no loops.

This is all filtered by IsStandard in the current version, but you can probably get new versions to accept it if you create something that uses it.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
January 11, 2011, 03:37:31 PM
 #4

OP_DUP OP_HASH160 key1 OP_EQUALVERIFY OP_CHECKSIG OP_VERIFY OP_DUP OP_HASH160 key2 OP_EQUALVERIFY OP_CHECKSIG

That will work. ...
This is all filtered by IsStandard in the current version, but you can probably get new versions to accept it if you create something that uses it.

Judging by the source code, it looks like such a change (update IsStandard) will be very trivial to make when the time comes.

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
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!