Ok guys, I did not could not wait till full implementation and released bounty now...
Each of the people from this list received 10 BTC
- Luke Dashjr
- Nils Schneider
- Amir Taaki
- Pieter Wuille
- Gregory Maxwell
I want to thanks these people for participating in this BIP... All you guys rock and we owe you a lot for making Bitcoin better...
Special thanks goes to Luke for standing his grounds...
And of course I want to tell that Gavin Andersen continue to lead us into the bright future and I will continue my donation for him...
My personal sympathy goes to Stefan Thomas (justmoon) for simply INCREDIBLE work he has done porting Bitcoin to NodeJS...
I will start to split my donation between Stefan and Gavin from now...
Topic: [PAID][Bounty] BIP 0011 (Read 4010 times)
1. Guys, please make sure we are not breaking anything with this...
2. I lost track of all this "stack & signature" stuff a while ago... So if there is Jack, Peter and Sanda (3rd party). Sandra can NOT pull money out of escrow alone.. she needs one of the guys to co-sign.
2. I lost track of all this "stack & signature" stuff a while ago... So if there is Jack, Peter and Sanda (3rd party). Sandra can NOT pull money out of escrow alone.. she needs one of the guys to co-sign.
It wouldn't be much of a "multi-signature required" transaction if one party can pull out the money alone.
I'm assuming the OP_CHECKMULTISIG works (with the extra stack-pop), and if so, everything else will fall into place -- if the tx is accepted by the network, it will be tough to get it wrong (unless you plug in a 1 instead of a 2 for a 2-of-3 tx...). I got some GUI development to do, and testing my multi-sig construction methods on the testnet... but otherwise, I'm not far off. I got all the other pieces in place.
1. Guys, please make sure we are not breaking anything with this...
2. I lost track of all this "stack & signature" stuff a while ago... So if there is Jack, Peter and Sanda (3rd party). Sandra can NOT pull money out of escrow alone.. she needs one of the guys to co-sign.
2. I lost track of all this "stack & signature" stuff a while ago... So if there is Jack, Peter and Sanda (3rd party). Sandra can NOT pull money out of escrow alone.. she needs one of the guys to co-sign.
And I wasn't clear, because I'm just thinking out loud: I meant take two big 256-bit random numbers (call them n1 and n2) and then produce three keypairs, where the private keys are n1, n2, and n1*n2. Thinking a little further, a 2-of-2 with that key arrangement gives a kind of "a and b OR c" ...
I guess I don't fully understand yet (who's creating the big numbers? who is multiplying them?)... but I concede to the next paragraph and can save the details for an IRC discussion (or you can point me to some logs where you've already had this discussion--I'm very interested).Anyway, my point was that with some cleverness I think lots of things become possible with just what is proposed with BIP 11, and I'd like to give people time to explore what can be done and figure out how to make this stuff easy to use before thinking about even more complicated transaction types.
This is a good point, as I never realized before that there was more to M-of-N transactions than the obvious uses. Unfortunately, the possibilities are limited to the ECDSA math tricks, not a generic scripting language like OP_EVAL... 
BIP 12 says: "If there are any OP_EVALs in the deserialized script they are also executed, but recursion is limited to a depth of 2."
I waffled on whether to propose any recursion at all, but I think just a touch of recursion will be safe and very useful.
And I wasn't clear, because I'm just thinking out loud: I meant take two big 256-bit random numbers (call them n1 and n2) and then produce three keypairs, where the private keys are n1, n2, and n1*n2. Thinking a little further, a 2-of-2 with that key arrangement gives a kind of "a and b OR c" ... but if c knows both n1 and n2 then the n1*n2 is redundant....
Anyway, my point was that with some cleverness I think lots of things become possible with just what is proposed with BIP 11, and I'd like to give people time to explore what can be done and figure out how to make this stuff easy to use before thinking about even more complicated transaction types.
I waffled on whether to propose any recursion at all, but I think just a touch of recursion will be safe and very useful.
And I wasn't clear, because I'm just thinking out loud: I meant take two big 256-bit random numbers (call them n1 and n2) and then produce three keypairs, where the private keys are n1, n2, and n1*n2. Thinking a little further, a 2-of-2 with that key arrangement gives a kind of "a and b OR c" ... but if c knows both n1 and n2 then the n1*n2 is redundant....
Anyway, my point was that with some cleverness I think lots of things become possible with just what is proposed with BIP 11, and I'd like to give people time to explore what can be done and figure out how to make this stuff easy to use before thinking about even more complicated transaction types.
Okay, take 2: I responded before I had thought this through:
You are saying "product of private keys" which I interpretted to mean what is used in Diffie-Hellman shared-secret process: I have private key a and public key a*G. You have private key b and public key b*G. If we have each other's public keys, we can both produce: a*b*G, which is a point on the secp256k1 curve that only you and I can calculate. That point could be used to create a new private key, and that is converted to an address to be included in a TxOut script. Then a signature for that address can be produced by me or you.
That is the only way to "multiply" private keys without actually handing the other person your private key, which I don't think is ever a good idea. I'll think a little more about how it would be possible to get an A-and-B address transparently into 20-bytes.
You are saying "product of private keys" which I interpretted to mean what is used in Diffie-Hellman shared-secret process: I have private key a and public key a*G. You have private key b and public key b*G. If we have each other's public keys, we can both produce: a*b*G, which is a point on the secp256k1 curve that only you and I can calculate. That point could be used to create a new private key, and that is converted to an address to be included in a TxOut script. Then a signature for that address can be produced by me or you.
That is the only way to "multiply" private keys without actually handing the other person your private key, which I don't think is ever a good idea. I'll think a little more about how it would be possible to get an A-and-B address transparently into 20-bytes.
Ack, please don't tell me we're allowing recursion in OP_EVAL? Or at least, unbounded recursion...? I'm envisioning someone finding a bug in OP_EVAL which causes every node on the network to hit the recursion limit on their system and crash the moment the tx hits the network...
Your C address would be a "diffie-hellman shared-secret" private key, which can be produced by either A or B (using their own private key and the others' public key). I presume you mean, calculate the public key for that private key and make that address C? Then technically, a transaction that ONLY includes C can be spent by A or B, IF they have each others' public key and know about it.
Therefore, making a C-or-D transaction using the C just described and third party D, would be one way to make an (A-and-B)-or-D transaction that fits into OP_CHECKMULTISIG protocol. It will just require A and B to exchange/notify each other of public keys, and an extra step to produce the shared private key before signing the tx.
EDIT: Ack, I botched the conclusion here... C-or-D would be the same as A-or-B-or-D.... clearly not what we wanted...
Quote
Just thinking off the top of my head: what interesting things could you do if you create 3 keys, where the private key for the third is the product of the first and second? If you make them a 2-of-3-to-redeem, is that the same as an (a and b) OR c transaction?
Your C address would be a "diffie-hellman shared-secret" private key, which can be produced by either A or B (using their own private key and the others' public key). I presume you mean, calculate the public key for that private key and make that address C? Then technically, a transaction that ONLY includes C can be spent by A or B, IF they have each others' public key and know about it.
EDIT: Ack, I botched the conclusion here... C-or-D would be the same as A-or-B-or-D.... clearly not what we wanted...
Also, these are the only multi-sig transactions that will become standard? What about (A-and-B)-or-C tx types? And the only options for (M,N) are {(1,2), (2,2), (1,3), (2,3), (3,3)}? Are 1-of-1 transactions (as silly as they would be) considered "standard"?
(A-and-B)-or-C will wait for another BIP; there are some nifty (and generalizable) ways of doing that by using OP_EVAL recursively that have the added benefit of keeping never-used public keys out of the blockchain.
(1,1) is silly but standard according to BIP 11. It is just a slightly larger version of the standard
I think (1,2)....(3,3) combined with all the things that can be done with deterministic keys or "I only have part of the private key" or other tricks will enable plenty of innovative solutions.
Just thinking off the top of my head: what interesting things could you do if you create 3 keys, where the private key for the third is the product of the first and second? If you make them a 2-of-3-to-redeem, is that the same as an (a and b) OR c transaction?
Is the BIP on github the most up-to-date one for 0011?
I think the version on the bitcoin wiki ( https://en.bitcoin.it/wiki/BIP_0011 ) is a little more up-to-date, but you should check with genjix, he's the BIP-meister.Pull request for BIPS 11 12 and 13 is here: https://github.com/bitcoin/bitcoin/pull/669
Unless I hear objections, I'll probably pull it tomorrow.
Just for clarification to make sure there's no confusion: the upcoming changes for supporting multi-sig transaction as "standard" in the network will have one-and-only-one form--the form that uses public keys only, and OP_CHECKMULTISIG. As such, an 2-of-3 transaction might look like the following:
TxOuts will look like:
Code:
2 PubKey1 PubKey2 PubKey3 3 OP_CHECKMULTISIG
And the associated TxIn scripts will look like:
Code:
OP_0 Sig1 Sig3
Then, when the scripting engine reaches the OP_CHECKMULTISIG symbol, the stack will look like (for the 2-of-3 tx):
Code:
OP_0 Sig1 Sig3 2 PubKey1 PubKey2 PubKey3 3
Also, these are the only multi-sig transactions that will become standard? What about (A-and-B)-or-C tx types? And the only options for (M,N) are {(1,2), (2,2), (1,3), (2,3), (3,3)}? Are 1-of-1 transactions (as silly as they would be) considered "standard"?
Is the BIP on github the most up-to-date one for 0011?
I think the version on the bitcoin wiki ( https://en.bitcoin.it/wiki/BIP_0011 ) is a little more up-to-date, but you should check with genjix, he's the BIP-meister.Pull request for BIPS 11 12 and 13 is here: https://github.com/bitcoin/bitcoin/pull/669
Unless I hear objections, I'll probably pull it tomorrow.
+1 This idea is fantastic. I would love to see this in a future version of Bitcoin.
If this gets implemented, the next step is definitely adding it to the GUI somehow. Make it very easy for lay users to make use of the functionality.
If this gets implemented, the next step is definitely adding it to the GUI somehow. Make it very easy for lay users to make use of the functionality.
Well yea, without this option in the GUI it's pretty useless for the average user
I think it's one of the key features that people will like about bitcoin.
Is the BIP on github the most up-to-date one for 0011?
What I need to know is if the OP_CHECKMULTISIG tx-type is going to end up as the standard multi-sig tx type? Is this going to be the only standard way to do multi-sig transactions (besides OP_EVAL)? I need to start writing code to identify and construct "standard" multi-sig transactions. It would help to know how many/what variations I can count on seeing.
I am actually making tremendous progress on a usable client, and using BIP 0010 I believe I can get a multi-sig support integrated fairly easily. I think I have a shot at the bounty! I just have to neglect my girlfriend a little bit more...
What I need to know is if the OP_CHECKMULTISIG tx-type is going to end up as the standard multi-sig tx type? Is this going to be the only standard way to do multi-sig transactions (besides OP_EVAL)? I need to start writing code to identify and construct "standard" multi-sig transactions. It would help to know how many/what variations I can count on seeing.
I am actually making tremendous progress on a usable client, and using BIP 0010 I believe I can get a multi-sig support integrated fairly easily. I think I have a shot at the bounty!
+1 This idea is fantastic. I would love to see this in a future version of Bitcoin.
If this gets implemented, the next step is definitely adding it to the GUI somehow. Make it very easy for lay users to make use of the functionality.
If this gets implemented, the next step is definitely adding it to the GUI somehow. Make it very easy for lay users to make use of the functionality.
The ability to have three party escrow would be so cool!
Would the majority of the miners have to upgarde to a BIP 0011 compatible version of the Bitcoin server before we could use this functionality ?
Yes.I'm testing patches against the last two versions of Bitcoin (0.3.23 and 0.4.1) for BIPs 11 and 12 right now to make it as easy as possible for miners to support them. Review or help testing is very welcome:
https://github.com/gavinandresen/bitcoin-git/tree/v0.3.23_op_eval
https://github.com/gavinandresen/bitcoin-git/tree/v0.4.1_op_eval
I think this is a very important feature!
Hope we can welcome it soon
Hope we can welcome it soon
I'd like to see M of N transactions too.
Would the majority of the miners have to upgarde to a BIP 0011 compatible version of the Bitcoin server before we could use this functionality ?
Would the majority of the miners have to upgarde to a BIP 0011 compatible version of the Bitcoin server before we could use this functionality ?
i send him 1 bitcoin,
Not exactly, you put money in the box that must be unlocked by 2 keys simultaneously out of 3 keys in existence (your friend, you and arbiter - each one have a key that opens the box ).
it's taken out of my wallet and sent into the blockchain.
My friend can now see i have sent the money and signs for it but can't use it yet.
When i receive my beer i give it another signature that unlocks the coins for my friend to use.
Assuming that neither one of the parties can just 'redeem' the money in case of a conflict.
Am i getting this right or am i totally off here?
My friend can now see i have sent the money and signs for it but can't use it yet.
When i receive my beer i give it another signature that unlocks the coins for my friend to use.
Assuming that neither one of the parties can just 'redeem' the money in case of a conflict.
Am i getting this right or am i totally off here?
Right here... in short if you and your friend find it problematic to unlock it together both of you try to unlock it by asking arbiter to cooperate in unlocking it. And you better have honest arbiter for honest verdict who will receive money - you or your friend
Wait im not sure if i understand this right.
So i want to buy beer from a friend, i send him 1 bitcoin, it's taken out of my wallet and sent into the blockchain.
My friend can now see i have sent the money and signs for it but can't use it yet.
When i receive my beer i give it another signature that unlocks the coins for my friend to use.
Assuming that neither one of the parties can just 'redeem' the money in case of a conflict.
Am i getting this right or am i totally off here?
So i want to buy beer from a friend, i send him 1 bitcoin, it's taken out of my wallet and sent into the blockchain.
My friend can now see i have sent the money and signs for it but can't use it yet.
When i receive my beer i give it another signature that unlocks the coins for my friend to use.
Assuming that neither one of the parties can just 'redeem' the money in case of a conflict.
Am i getting this right or am i totally off here?
$250
Jump to: