Thanks Mike
Good to hear that there is already some activity around this. I will take a look at bitcoinj.
Cheers
Topic: Multi Sig Transaction Service (Read 1013 times)
FYI: Someone actually is working on implementing the oracle system at the moment. They seem to be making reasonable progress, so hopefully if they stick with it we might have a working system, at least on testnet, within the next few months. They're using bitcoinj and so far at least it seems the documentation is good enough that they don't really need my help. Once that's done we'd need to whitelist scriptPubKeys with OP_DROP in them in the IsStandard() checks, but that conversation will be much easier to have once there's a working use case for them.
I've been beefing up the support for interesting transaction types in bitcoinj lately so if you want to experiment with these ideas, it's a good place to start. You can ask questions on the mailing list:
https://code.google.com/p/bitcoinj/
https://groups.google.com/forum/#!forum/bitcoinj
I've been beefing up the support for interesting transaction types in bitcoinj lately so if you want to experiment with these ideas, it's a good place to start. You can ask questions on the mailing list:
https://code.google.com/p/bitcoinj/
https://groups.google.com/forum/#!forum/bitcoinj
I suspect that the maintenance hassle is just too extreme for any "regular" user to want to use this service, when the M-of-N solution is so comparable and so much easier.
Sure, for people who tend to churn through 100% of their savings regularly (ie. they don't have much savings), this type of service would be useless. I'm more thinking about someone who has a large sum, say $5M or something, stashed away, and they might have $500k in their own accounts for their spending. The pre-signed transaction ensures that their windfall can be passed down. They wouldnt be touching this money and spending it every day. Also you could break the $5M into $1M chunks so that if you had to break one of them, it only invalidates one of the transactions. For the $500k wallet, you could use an M-of-N strategy so that the coins don't get burnt if you die. In my opinion it's weaker security, but I guess that's debateable.
Also I'm thinking long term. Like, in the future if bitcoin is mainstream, everything is going to have to be really easy to use. Hiding away files in safe deposit boxes and having agreements with lawyers is going to be too complex. Potentially a multi-sig type of service, with an easy web interface and appropriate wallet support, could make it really easy for people to manage.
I appreciate your thoughts as I hadn't yet thought about the fact that there might be simple, offline ways like M-of-N that could work better in some cases.
I still am really keen to know what's going on with custom script/contract stuff and if it's going to actually happen at some point. Maybe my idea is no good but theres got to be other good uses for them.
I just wanted to make the point that if you are holding $5 million, you want a solution that leads to 100% chance of recovery. The M-of-N solution is exactly that. Do it once. Ever. No shenanigans. No maintenance. No chance of failure. But what you are proposing leaves room for things to go wrong. No matter how diligent you are, it's going to get annoying to do anything with your funds, even once a year, if you have to revisit safe-deposit boxes, redistribute transactions to your will, or whatever. You'll take shortcuts, you'll be in a hurry and say you'll deal with it tomorrow. For periods of time, only 0/5, or maybe 3/5 of your money will actually be recoverable if something bad were to happen to you. In a way, it kind of defeats the purpose.
I appreciate you are keeping an open mind. As you can tell, I've spent a lot of time thinking about these things
And I've also spent a lot of time dealing with users who didn't bother to even make a single-sheet backup and then lost all their coins when they forgot their passphrase. And people who chose to backup their Bitcoin-Qt wallet and then didn't realize they had to re-backup, or were too lazy to do so. And they can't backup securely, because they have to do it often. That's why deterministic wallets are so valuable -- anything that requires regular maintenance is going to fail. Even if you think you can do it yourself, and that you'll do it right--others won't. And even you, in all your diligence to do it right, may screw that up because you're in a hurry and don't have time to stop by the bank today to replace the inheritance transaction in your safe deposit box. Etc. But one thing is for sure: you make paper backups, you secure them hardc0re, once. And you never have to worry about it again.Okay. I've beaten this dead horse enough. You get my point
I'm happy to walk through thought experiments with you about this, but I'm doubtful anything is going to beat the combined convenience and security of a 2-of-3, 2-of-4, 3-of-4 or 3-of-5 backup.I suspect that the maintenance hassle is just too extreme for any "regular" user to want to use this service, when the M-of-N solution is so comparable and so much easier.
Sure, for people who tend to churn through 100% of their savings regularly (ie. they don't have much savings), this type of service would be useless. I'm more thinking about someone who has a large sum, say $5M or something, stashed away, and they might have $500k in their own accounts for their spending. The pre-signed transaction ensures that their windfall can be passed down. They wouldnt be touching this money and spending it every day. Also you could break the $5M into $1M chunks so that if you had to break one of them, it only invalidates one of the transactions. For the $500k wallet, you could use an M-of-N strategy so that the coins don't get burnt if you die. In my opinion it's weaker security, but I guess that's debateable.
Also I'm thinking long term. Like, in the future if bitcoin is mainstream, everything is going to have to be really easy to use. Hiding away files in safe deposit boxes and having agreements with lawyers is going to be too complex. Potentially a multi-sig type of service, with an easy web interface and appropriate wallet support, could make it really easy for people to manage.
I appreciate your thoughts as I hadn't yet thought about the fact that there might be simple, offline ways like M-of-N that could work better in some cases.
I still am really keen to know what's going on with custom script/contract stuff and if it's going to actually happen at some point. Maybe my idea is no good but theres got to be other good uses for them.
I appreciate that M-of-N backups is useful, but I don't think it's the solution I'm looking for. As I said, this allows full access to private keys which allows them to sign *any* transaction. I want to pre-sign transactions only to addresses I want to give an inheritence to. This is actually a simplified version of the example here: https://en.bitcoin.it/wiki/Contracts#Example_4:_Using_external_state
I'm aware that I would have to sign new transactions if I receive new outputs (eg. change from spending). That would all need to be part of the workflow for this service. If you obtain new unspent outputs, then you pre-sign some new transactions for the new outputs. The general idea though would be that you use it if you have some savings, perhaps split up into many smaller spendable outputs, each with a pre-signed transaction, so that you could spend some and the others would still be inheritable.
There are lots of issues like the one you mentioned, that need to be carefully considered when implementing this type of service, but the general idea is that bitcoin is supposed to support advanced transaction types and I would like to start making use of them.
I'm aware that I would have to sign new transactions if I receive new outputs (eg. change from spending). That would all need to be part of the workflow for this service. If you obtain new unspent outputs, then you pre-sign some new transactions for the new outputs. The general idea though would be that you use it if you have some savings, perhaps split up into many smaller spendable outputs, each with a pre-signed transaction, so that you could spend some and the others would still be inheritable.
There are lots of issues like the one you mentioned, that need to be carefully considered when implementing this type of service, but the general idea is that bitcoin is supposed to support advanced transaction types and I would like to start making use of them.
I believe that what you are proposing is completely unsustainable. You can't reissue, re-distribute, and re-secure all these different transactions after every single incoming and outgoing transaction. It's going to make your workflow terribly inconvenient, that will lead to taking shortcuts, probably missing coins, etc. How fantastic would that be if you had a heart attack when you were trying to fix whatever mess just happened and all your existing transactions are invalid, etc. Now, your family will spend days digging through old transactions, and trying to figure out what the heck happened, and in the end no one gets your coins. Ever.
There is most definitely a place for multi-sig transactions, but you can't do with them what you want. The M-of-N solution is designed for this, and it has the security that you want. If you want to split your coins between multiple family members, make multiple wallets. Make 2-of-3 for each. Give the respective family member one piece, and put 1 fragment of each in your safe deposit box. That way, whoever eventually gets access to your safe deposit box can't take the coins, except for the single family member that already has a piece.
This is done exactly once, and never has to be done again. It is pretty much like writing a will. Every time your deposit a check, do you go back to your lawyer and remake your will to say "My family now gets $3,406.74" instead of "$2,722.11"? No, you leave your "bank account" to them, and they get whatever's in there. You can leave each person a different bank account. Using the M-of-N solution with different wallets is like setting beneficiaries of each bank account.
If you try it your way, keep us posted. I'd be thoroughly impressed if you succeeded, but I've wrong before
However, I suspect that the maintenance hassle is just too extreme for any "regular" user to want to use this service, when the M-of-N solution is so comparable and so much easier.
I appreciate that M-of-N backups is useful, but I don't think it's the solution I'm looking for. As I said, this allows full access to private keys which allows them to sign *any* transaction. I want to pre-sign transactions only to addresses I want to give an inheritence to. This is actually a simplified version of the example here: https://en.bitcoin.it/wiki/Contracts#Example_4:_Using_external_state
I'm aware that I would have to sign new transactions if I receive new outputs (eg. change from spending). That would all need to be part of the workflow for this service. If you obtain new unspent outputs, then you pre-sign some new transactions for the new outputs. The general idea though would be that you use it if you have some savings, perhaps split up into many smaller spendable outputs, each with a pre-signed transaction, so that you could spend some and the others would still be inheritable.
There are lots of issues like the one you mentioned, that need to be carefully considered when implementing this type of service, but the general idea is that bitcoin is supposed to support advanced transaction types and I would like to start making use of them.
I'm aware that I would have to sign new transactions if I receive new outputs (eg. change from spending). That would all need to be part of the workflow for this service. If you obtain new unspent outputs, then you pre-sign some new transactions for the new outputs. The general idea though would be that you use it if you have some savings, perhaps split up into many smaller spendable outputs, each with a pre-signed transaction, so that you could spend some and the others would still be inheritable.
There are lots of issues like the one you mentioned, that need to be carefully considered when implementing this type of service, but the general idea is that bitcoin is supposed to support advanced transaction types and I would like to start making use of them.
Also, there is no way to pre-sign a transaction like you suggested, unless you plan to never touch your money again. If you make a single transaction after you have pre-signed the "inheritance" transaction, that inheritance transaction will become invalid, and you will have to reissue it. This makes it very sensitive to failure (something happens before you've had a chance to reissue and re-distribute it).
The solution is the M-of-N backups. Even if you did a 7-of-30 backup, someone who has only 6 pieces might as well have 0. They have no brute-force advantage over someone who has 0 pieces (except of course, they only need one more piece). That's the nice thing about Shamir's Secret Sharing: you have 0% access until you have 100%. Giving your family one piece gives them nothing, except for requiring them to find one less piece than anyone else (which they will, when they get to your safe-deposit box).
The solution is the M-of-N backups. Even if you did a 7-of-30 backup, someone who has only 6 pieces might as well have 0. They have no brute-force advantage over someone who has 0 pieces (except of course, they only need one more piece). That's the nice thing about Shamir's Secret Sharing: you have 0% access until you have 100%. Giving your family one piece gives them nothing, except for requiring them to find one less piece than anyone else (which they will, when they get to your safe-deposit box).
Just to echo TierNolan,
I'm working on the M-of-N shared secret stuff now. It is exactly what you want. And if you have a little bit of command-line patience, you can use it right now, and I have promised to support it forever (I have multiple wallets personally backed up with the current utility). You can read about it here.
The fact that it is is "split" is what prevents "attacks of opportunity", such as someone breaking into your house and stealing your jewelry box which happened to contain your paper backup. Or a bank employee with too much access rooting safe-deposit boxes for jewelry and finding your backup. In the M-of-N case, they would have to target you to compromise your wallet.
Thank you for promoting responsible Bitcoin savings practices. I've always pushed people against brainwallets for exactly the reasons you describe.
I'm working on the M-of-N shared secret stuff now. It is exactly what you want. And if you have a little bit of command-line patience, you can use it right now, and I have promised to support it forever (I have multiple wallets personally backed up with the current utility). You can read about it here.
The fact that it is is "split" is what prevents "attacks of opportunity", such as someone breaking into your house and stealing your jewelry box which happened to contain your paper backup. Or a bank employee with too much access rooting safe-deposit boxes for jewelry and finding your backup. In the M-of-N case, they would have to target you to compromise your wallet.
Thank you for promoting responsible Bitcoin savings practices. I've always pushed people against brainwallets for exactly the reasons you describe.
Thanks TierNolan. Thats a good suggestion for how I could structure something now given the limitations around multi sig transactions.
However, what I would like to be able to do is never give anyone access to my private keys, ever. I also don't want to allow my coins to be spent to arbitrary addresses, which would be possible when giving out full access to my private keys. Instead I want to be able to pre-sign a transaction to a given address (say, a family member) that requires additional signatures to be valid. Eg, one signature form me, one signature from the person who I'm sending it to, and one signature from an oracle service which will only sign the transaction if a given condition is 'true'. I want these multiple signatures to be verified by the bitcoin protocol and block chain.
Furthermore I would like to be able to make this into a simple service that others could make use of. So in that sense I would like to have a simple workflow for users to be able to make use of this. I want the solution to be zero-trust or as low trust as possible, so that the oracle service can't steal your coins, and also can be regularly tested to see if they sign transactions (to prevent against them holding you random). I think just starting one service like this would get things started and then others might spring up as well. It just seems to be a missing feature of the bitcoin ecosystem that is theoretically possible but just not implemented yet.
However, what I would like to be able to do is never give anyone access to my private keys, ever. I also don't want to allow my coins to be spent to arbitrary addresses, which would be possible when giving out full access to my private keys. Instead I want to be able to pre-sign a transaction to a given address (say, a family member) that requires additional signatures to be valid. Eg, one signature form me, one signature from the person who I'm sending it to, and one signature from an oracle service which will only sign the transaction if a given condition is 'true'. I want these multiple signatures to be verified by the bitcoin protocol and block chain.
Furthermore I would like to be able to make this into a simple service that others could make use of. So in that sense I would like to have a simple workflow for users to be able to make use of this. I want the solution to be zero-trust or as low trust as possible, so that the oracle service can't steal your coins, and also can be regularly tested to see if they sign transactions (to prevent against them holding you random). I think just starting one service like this would get things started and then others might spring up as well. It just seems to be a missing feature of the bitcoin ecosystem that is theoretically possible but just not implemented yet.
You should look into Armory.
It has a deterministic wallet system. There is one number on it that defines your wallet. All private and public keys are derived from that key. This means it doesn't have to generate and store new keys.
This single code can be used to spend all your bitcoins, so it has to be guarded carefully.
There is also an advanced feature where you can split the code into multiple sub-keys and implement a voting system for release. This is called an N of M shared secret scheme. I think it might be command line at the moment.
Basically, it creates M secrets that encode your private/root key.
If you have N-1 of those secrets, they might as well be random numbers. However, when you add the Nth one, they can be combined to give the root private key.
You might create a 3 of 5 secret and give one to each of 3 family members and 2 to your lawyer, with instructions not to open the envelope unless you are dead.
All 3 family members or one member plus the lawyer would be able to unlock the private key. Once they have that, they can spend all the coins. The instructions to the lawyer would have to include getting technical support, as once the key is known by anyone, they have full rights to the private key.
It has a deterministic wallet system. There is one number on it that defines your wallet. All private and public keys are derived from that key. This means it doesn't have to generate and store new keys.
This single code can be used to spend all your bitcoins, so it has to be guarded carefully.
There is also an advanced feature where you can split the code into multiple sub-keys and implement a voting system for release. This is called an N of M shared secret scheme. I think it might be command line at the moment.
Basically, it creates M secrets that encode your private/root key.
If you have N-1 of those secrets, they might as well be random numbers. However, when you add the Nth one, they can be combined to give the root private key.
You might create a 3 of 5 secret and give one to each of 3 family members and 2 to your lawyer, with instructions not to open the envelope unless you are dead.
All 3 family members or one member plus the lawyer would be able to unlock the private key. Once they have that, they can spend all the coins. The instructions to the lawyer would have to include getting technical support, as once the key is known by anyone, they have full rights to the private key.
Hi all,
One of the concerns I have about using bitcoin as a store of value is that I have no plan in place for if I were to get hit by a bus. In this event, no one would inherit my coins because they are secured in such a way that no one would be able to access them. If I were to put in place some kind of backup plan, like giving a family member a copy of wallet and writing down the passphrase for them, then this would by far be the weakest link in my security strategy. Basically I don't know of any good way to set up a "bitcoin will".
I have read about bitcoin's Script language and the possibilities that this provides for an enormous number of different types of creative transactions. (https://en.bitcoin.it/wiki/Contracts). I also watched a youtube video of Mike Hearn giving a talk at the 2012 conference discussing these advanced transaction types. It sounds like these contracts could be used to set up a will without compromising private key security. However, as far as I can tell, there are no services available to do this kind of thing.
If there really are no projects underway to do multi-sig transactions, then I'd be interested in starting one. I was hoping I could get some pointers here on how this could be done and where I could get started.
Questions:
- Are there any projects underway to provide an "Oracle" type of service, or even a simple "Dead Man's Switch" type of service (eg. if I don't log in for X days, sign a transaction).
- From my research it seems that transactions with non-standard scripts will not be forwarded by peers running the reference client, but they are considered valid if in a block. What is the process for discussing new script types to allow multi-sig transactions to propogate through the network?
- To create multi-signature transactions, could I do this through the raw transaction RPC API? Does it allow custom scripts?
- What approach would be best for having my service provide the user with a signed transaction, and then allowing them to add their own signature and send it to the network? Would the current reference client support that? (even if it's some external script using rpc api?)
I read that testnet does allow non-standard scripts to propogate through the network, so I could get started on there. But first I'd love to hear advice / pointers about how I could build the transactions and how to write the multi sig verification script (which would need to include some kind of identifier for my oracle / dead-man service to know which user account the transaction is referring to).
Thanks very much.
One of the concerns I have about using bitcoin as a store of value is that I have no plan in place for if I were to get hit by a bus. In this event, no one would inherit my coins because they are secured in such a way that no one would be able to access them. If I were to put in place some kind of backup plan, like giving a family member a copy of wallet and writing down the passphrase for them, then this would by far be the weakest link in my security strategy. Basically I don't know of any good way to set up a "bitcoin will".
I have read about bitcoin's Script language and the possibilities that this provides for an enormous number of different types of creative transactions. (https://en.bitcoin.it/wiki/Contracts). I also watched a youtube video of Mike Hearn giving a talk at the 2012 conference discussing these advanced transaction types. It sounds like these contracts could be used to set up a will without compromising private key security. However, as far as I can tell, there are no services available to do this kind of thing.
If there really are no projects underway to do multi-sig transactions, then I'd be interested in starting one. I was hoping I could get some pointers here on how this could be done and where I could get started.
Questions:
- Are there any projects underway to provide an "Oracle" type of service, or even a simple "Dead Man's Switch" type of service (eg. if I don't log in for X days, sign a transaction).
- From my research it seems that transactions with non-standard scripts will not be forwarded by peers running the reference client, but they are considered valid if in a block. What is the process for discussing new script types to allow multi-sig transactions to propogate through the network?
- To create multi-signature transactions, could I do this through the raw transaction RPC API? Does it allow custom scripts?
- What approach would be best for having my service provide the user with a signed transaction, and then allowing them to add their own signature and send it to the network? Would the current reference client support that? (even if it's some external script using rpc api?)
I read that testnet does allow non-standard scripts to propogate through the network, so I could get started on there. But first I'd love to hear advice / pointers about how I could build the transactions and how to write the multi sig verification script (which would need to include some kind of identifier for my oracle / dead-man service to know which user account the transaction is referring to).
Thanks very much.
Jump to: