Topic: Escrow without third parties - page 2. (Read 3120 times)
If the third party service is too expensive, perhaps a TOR based automated service can be created that arbitrates with a coin flip.
Emulating 2-3 multisig with DAA is easy too. You don't need to use OP_CHECKMULTISIG
Suppose the parties are A, B and C. Suppose any two of them can decide if the money should go to one of them.
1) A chooses a random Ak, B chooses a random Bk, C chooses a random Ck.
2) A does:
- ABpub=Ak*BPub and sends a ZNP of that operation to B and C.
- ACpub=Ak*CPub and sends a ZNP of that operation to B and C.
3) B does:
- BCpub=Bk*CPub and sends a ZNP of that op to A and C.
- BApub=Ak*APub and sends a ZNP of that op to A and C.
4) C does:
CBpub=Ck*BPub and sends a ZNP of that op to A and B.
CApub=Ck*APub and sends a ZNP of that op to A and B.
5) A creates the transaction with the script:
scriptPubKey:
OP_CHECKSIG OP_IF OP_1 OP_VERIFY OP_ENDIF
OP_CHECKSIG OP_IF OP_1 OP_VERIFY OP_ENDIF
OP_CHECKSIG OP_IF OP_1 OP_VERIFY OP_ENDIF
OP_CHECKSIG OP_IF OP_1 OP_VERIFY OP_ENDIF
OP_CHECKSIG OP_IF OP_1 OP_VERIFY OP_ENDIF
OP_CHECKSIG OP_IF OP_1 OP_VERIFY OP_ENDIF
5) Then for any party X and Y
- If X and Y wants to pay the money to Y, X privately send Xk to Y, and Y can get the money.
- If X and Y wants to pay the money to X,Y privately send Yk to X, and X can get the money.
As etotheipi posted while I was typing, math possibilities are endless and any secret sharing scheme can be implemented. Obviously if you think this is high-order math and it's too complicated, then don't use it. Although generally after is implemented, it's completely transparent to the user.
Suppose the parties are A, B and C. Suppose any two of them can decide if the money should go to one of them.
1) A chooses a random Ak, B chooses a random Bk, C chooses a random Ck.
2) A does:
- ABpub=Ak*BPub and sends a ZNP of that operation to B and C.
- ACpub=Ak*CPub and sends a ZNP of that operation to B and C.
3) B does:
- BCpub=Bk*CPub and sends a ZNP of that op to A and C.
- BApub=Ak*APub and sends a ZNP of that op to A and C.
4) C does:
CBpub=Ck*BPub and sends a ZNP of that op to A and B.
CApub=Ck*APub and sends a ZNP of that op to A and B.
5) A creates the transaction with the script:
scriptPubKey:
5) Then for any party X and Y
- If X and Y wants to pay the money to Y, X privately send Xk to Y, and Y can get the money.
- If X and Y wants to pay the money to X,Y privately send Yk to X, and X can get the money.
As etotheipi posted while I was typing, math possibilities are endless and any secret sharing scheme can be implemented. Obviously if you think this is high-order math and it's too complicated, then don't use it. Although generally after is implemented, it's completely transparent to the user.
If a vendor is trusted and rated, then perhaps a down payment can be made with the rest locked in a 2-of-3 transaction. Three keys are created, one by the seller, one by the buyer, and one by an automated third party service. If the two parties are satisfied with their own resolution, then the private keys can go to whomever it belongs, if they cannot, then the third party is activated. I do not think a pure 2 party escrow can be created without the risk of tying up funds indefinitely. There is no sense in that.
There is sense in that for small transactions where the cost of third-party arbitration might be more than the transaction itself. Or if the transaction is especially sensitive and the parties do not wish to compromise their privacy. Yes, the risk of permanent coin loss is not preferable, but I don't think it means that such contracts should never be used.
There is a lot of value in the ability of the Bitcoin network to serve as an escrow service. And the risk of the coins being totally lost is a huge incentive for the parties to complete the transaction agreeably (especially when you include risk deposits as I recommended, if it was feasible). Sure, one party could die or have a HDD failure, but such events would be rare compared to the volume of other transactions that would benefit tremendously from it. I can't think of anything that is more in the spirit of Bitcoin, than having the network itself serve as a replacement for third-party escrow services.
Interesting, exactly the same functionality can be done with DAA:
...
No need for 2-of-2 multi-signature.
Maybe the two tools could be used together to do more advanced contracts!
...
No need for 2-of-2 multi-signature.
Maybe the two tools could be used together to do more advanced contracts!
The point of multi-signature transactions in the Bitcoin network was so that you don't need any fancy math to achieve M-of-N transaction types. I totally appreciate that such mathematical solutions exist, but it scope is extremely limited without getting insane (Mike Hearn has previously referenced papers on ECDSA thresholding schemes).
One of the biggest limitations of these mathematical solutions is that at the end, someone ends up with the full private key for the funds. This means that if an agreement is made to split the money, one party has to trust the other to send them their share. Alternatively, with BIP16/multi-sig, one party simply creates the transaction they would like to see spent (which can be any distribution of the encumbered funds) and then the other party only needs to sign and broadcast if they agree.
If a vendor is trusted and rated, then perhaps a down payment can be made with the rest locked in a 2-of-3 transaction. Three keys are created, one by the seller, one by the buyer, and one by an automated third party service. If the two parties are satisfied with their own resolution, then the private keys can go to whomever it belongs, if they cannot, then the third party is activated. I do not think a pure 2 party escrow can be created without the risk of tying up funds indefinitely. There is no sense in that.
Just for reference (I can't tell how much of this you know already)
(1) Multi-signature transactions do exactly the same thing.
--Buyer (A) commits X funds to a 2-of-2 multi-signature transaction including himself and the seller (B)
--B sends the goods.
--If product is good - A signs transaction moving 2-of-2 funds to B, send to B which signs and broadcasts
--If produce is bad/returned - B signs transaction moving 2-of-2 fund sto A, sends to A which signs and broadcasts
--If can't agree, funds are locked indefinitely
(1) Multi-signature transactions do exactly the same thing.
--Buyer (A) commits X funds to a 2-of-2 multi-signature transaction including himself and the seller (B)
--B sends the goods.
--If product is good - A signs transaction moving 2-of-2 funds to B, send to B which signs and broadcasts
--If produce is bad/returned - B signs transaction moving 2-of-2 fund sto A, sends to A which signs and broadcasts
--If can't agree, funds are locked indefinitely
Interesting, exactly the same functionality can be done with DAA:
--Buyer (A) commits X funds to a k*Bpub and publish the transaction, and sends the ZNP to B.
--B sends the goods.
--If product is good - A sends k to B
--If produce is bad/returned - B chooses a random z, sends X coins to z*Apub and the sends the ZNP to A. A sends k to B. B sends z to A.
--If can't agree, funds are locked indefinitely
No need for 2-of-2 multi-signature.
Maybe the two tools could be used together to do more advanced contracts!
If Q = k * Bpub, what is the relationship between Qpriv and Bpriv then? Or how is B going to learn Qpriv?
QPriv = k*Bpriv
B learns Qpriv when A sends k to B.
I think in practice most escrow situations will want to involve a dispute mediator, once the infrastructure for that exists.
Just for reference (I can't tell how much of this you know already)
(1) Multi-signature transactions do exactly the same thing.
--Buyer (A) commits X funds to a 2-of-2 multi-signature transaction including himself and the seller (B)
--B sends the goods.
--If product is good - A signs transaction moving 2-of-2 funds to B, send to B which signs and broadcasts
--If produce is bad/returned - B signs transaction moving 2-of-2 fund sto A, sends to A which signs and broadcasts
--If can't agree, funds are locked indefinitely
(2) There's a lot of issues with this setup, such as A being too lazy to sign the goods are received, or B scamming A into putting funds into a 2-of-2 transaction and then disappearing, or holding the funds ransom (A won't get any money back unless they sign a transaction to give B half of it). There's been lots of discussions about it. Of course, I will link to my own thread about it.
I apologize if your intent was simply to share the mathematical tricks you can do to achieve the same thing without multi-sig enabled on the network. I find it very interesting, myself. But M-of-N transactions are currently enabled on the network using BIP 16, which provides the same functionality (and actually more, because the math gets a lot more complicated and fuzzier if you try to include more parties).
(1) Multi-signature transactions do exactly the same thing.
--Buyer (A) commits X funds to a 2-of-2 multi-signature transaction including himself and the seller (B)
--B sends the goods.
--If product is good - A signs transaction moving 2-of-2 funds to B, send to B which signs and broadcasts
--If produce is bad/returned - B signs transaction moving 2-of-2 fund sto A, sends to A which signs and broadcasts
--If can't agree, funds are locked indefinitely
(2) There's a lot of issues with this setup, such as A being too lazy to sign the goods are received, or B scamming A into putting funds into a 2-of-2 transaction and then disappearing, or holding the funds ransom (A won't get any money back unless they sign a transaction to give B half of it). There's been lots of discussions about it. Of course, I will link to my own thread about it.
I apologize if your intent was simply to share the mathematical tricks you can do to achieve the same thing without multi-sig enabled on the network. I find it very interesting, myself. But M-of-N transactions are currently enabled on the network using BIP 16, which provides the same functionality (and actually more, because the math gets a lot more complicated and fuzzier if you try to include more parties).
One of the uses of DAA (Destination Address Anonymization) is to create an p2p escrow without the need for third parties.
Suppose A wants to send X coins to B, and B in return must send Y virtual goods of some kind. B public address is Bpub
First A commits to sending X coins by choosing a random k and sending the money to the address Q=k*Bpub.
Then A creates a simple ZNP (zero knowledge proof) that Q is indeed the encryption of Bpub under a known k.
This can be done with the cut-and-choose method and the Fiat-Shamir heuristic to create a non-interactive proof.
(if you want more information of this method please ask me, it's very simple and a standard practice)
Then B knows that A has committed to the payment (A cannot get the money back and B cannot take it, so the money is blocked).
B sends the virtual goods to A. A releases the money by sending the value k to B.
Suppose A wants to send X coins to B, and B in return must send Y virtual goods of some kind. B public address is Bpub
First A commits to sending X coins by choosing a random k and sending the money to the address Q=k*Bpub.
Then A creates a simple ZNP (zero knowledge proof) that Q is indeed the encryption of Bpub under a known k.
This can be done with the cut-and-choose method and the Fiat-Shamir heuristic to create a non-interactive proof.
(if you want more information of this method please ask me, it's very simple and a standard practice)
Then B knows that A has committed to the payment (A cannot get the money back and B cannot take it, so the money is blocked).
B sends the virtual goods to A. A releases the money by sending the value k to B.
If Q = k * Bpub, what is the relationship between Qpriv and Bpriv then? Or how is B going to learn Qpriv?
One of the uses of DAA (Destination Address Anonymization) is to create an p2p escrow without the need for third parties.
Suppose A wants to send X coins to B, and B in return must send Y virtual goods of some kind. B public address is Bpub
First A commits to sending X coins by choosing a random k and sending the money to the address Q=k*Bpub.
Then A creates a simple ZNP (zero knowledge proof) that Q is indeed the encryption of Bpub under a known k.
This can be done with the cut-and-choose method and the Fiat-Shamir heuristic to create a non-interactive proof.
(if you want more information of this method please ask me, it's very simple and a standard practice)
Then B knows that A has committed to the payment (A cannot get the money back and B cannot take it, so the money is blocked).
B sends the virtual goods to A. A releases the money by sending the value k to B.
I know this is not the only way to do an escrow in Bitcoin (and maybe not the best way), but is a new useful way.
Best regards, Sergio.
Suppose A wants to send X coins to B, and B in return must send Y virtual goods of some kind. B public address is Bpub
First A commits to sending X coins by choosing a random k and sending the money to the address Q=k*Bpub.
Then A creates a simple ZNP (zero knowledge proof) that Q is indeed the encryption of Bpub under a known k.
This can be done with the cut-and-choose method and the Fiat-Shamir heuristic to create a non-interactive proof.
(if you want more information of this method please ask me, it's very simple and a standard practice)
Then B knows that A has committed to the payment (A cannot get the money back and B cannot take it, so the money is blocked).
B sends the virtual goods to A. A releases the money by sending the value k to B.
I know this is not the only way to do an escrow in Bitcoin (and maybe not the best way), but is a new useful way.
Best regards, Sergio.
Jump to: