What is to stop Alice from simply not sending Carol X (so Carol can't spend TX_2) announcing TX_3 which spends TX_1, and then announcing the TX_0_Refund as well?
TX_3 is created and announced by Carol. Alice can't collect TX_3's output without making X public (as TX_3 requires X to be in the signature). The TX_0_Refund is nlocked for the future: "TX_0_refund must have a further future locktime than TX_1_refund. Otherwise Bob can delay step (I.) in the protocol until the refunds become valid and then announce TX_3 while Alice announces TX_0_refund in order to try to cause Alice to get refunded while Bob still gets paid." (I believe thats describing what you're thinking about there) 
Topic: CoinSwap: Transaction graph disjoint trustless trading - page 2. (Read 36555 times)
I think my confusion stems from my use case: where Alice and Bob are the same person (2-party with only Alice & Carol) who will calculate the X Value?
Alice does, and it's perfectly fine that alice knows it first. It might help you to try to describe the attack you're feeling might be there in concrete terms.I'm looking at the point where Alice generates X & HX, Alice sends Carol HX. They both then create, sign & exchange TX_2 & TX_3 transactions that spend TX_0 & TX_1 with the common hash lock.
It seems that whomever holds X has an advantage here.
What is to stop Alice from simply not sending Carol X (so Carol can't spend TX_2) announcing TX_3 which spends TX_1, and then announcing the TX_0_Refund as well?
I am sure I am missing something here, I appreciate your patience
I think my confusion stems from my use case: where Alice and Bob are the same person (2-party with only Alice & Carol) who will calculate the X Value?
Alice does, and it's perfectly fine that alice knows it first. It might help you to try to describe the attack you're feeling might be there in concrete terms. So, we have a refund for the TX_0 transaction, but don't announce it. If Carol announces a transaction that spends TX_0, and then announces a refund for TX_1, how does the refund work to prevent cheating? Isn't TX_0 spent at that point?
TX_0's output is a 2-of-2 multisignature output. It can't be spent unilaterally, the other user must sign it too. Does that answer your question?I think my confusion stems from my use case: where Alice and Bob are the same person (2-party with only Alice & Carol) who will calculate the X Value?
Doesn't one of them knowing this value before the other allow someone to cheat?
Or, would a 3rd party need to generate X, calculate and send Alice & Carol HX, and release X after they have exchanged TX_2 & TX_3?
So, we have a refund for the TX_0 transaction, but don't announce it. If Carol announces a transaction that spends TX_0, and then announces a refund for TX_1, how does the refund work to prevent cheating? Isn't TX_0 spent at that point?
TX_0's output is a 2-of-2 multisignature output. It can't be spent unilaterally, the other user must sign it too. Does that answer your question?
I'm sure this is a dumb question, but, I don't fully understand how the refunds work.
So, we have a refund for the TX_0 transaction, but don't announce it. If Carol announces a transaction that spends TX_0, and then announces a refund for TX_1, how does the refund work to prevent cheating? Isn't TX_0 spent at that point?
I think I am missing something re: the time-out redemptions. Do these refund transactions somehow supersede other transactions, even if the other transaction is announced before the refund?
So, we have a refund for the TX_0 transaction, but don't announce it. If Carol announces a transaction that spends TX_0, and then announces a refund for TX_1, how does the refund work to prevent cheating? Isn't TX_0 spent at that point?
I think I am missing something re: the time-out redemptions. Do these refund transactions somehow supersede other transactions, even if the other transaction is announced before the refund?
Would it be possible to extend this idea into a Tor-like mix-cascade payment network? Both Alice and Bob would choose their own CoinSwap 'circuit' to a rendezvous intermediary, each escrow tx is hash-locked to that of the next intermediary, so that Eva would have to compromise at least three intermediaries to know Alice has paid Bob.
Onion TX routing?
Would it be possible to extend this idea into a Tor-like mix-cascade payment network? Both Alice and Bob would choose their own CoinSwap 'circuit' to a rendezvous intermediary, each escrow tx is hash-locked to that of the next intermediary, so that Eva would have to compromise at least three intermediaries to know Alice has paid Bob.
OMG, i think what you described is a serious material for next Bitcoin-level breakthrough...
Would it be possible to extend this idea into a Tor-like mix-cascade payment network? Both Alice and Bob would choose their own CoinSwap 'circuit' to a rendezvous intermediary, each escrow tx is hash-locked to that of the next intermediary, so that Eva would have to compromise at least three intermediaries to know Alice has paid Bob.
A useful point I should have made here is that you can basically apply this same protocol encoding to any script-releasable-escrow in order to keep the release details private.
E.g. something like the zero knoweldge contingent payment protocol could be used in place of the normally-not-announced first release transaction in order to keep private that you were using a ZK-payment.
E.g. something like the zero knoweldge contingent payment protocol could be used in place of the normally-not-announced first release transaction in order to keep private that you were using a ZK-payment.
Oh, yeah...not even bob...sorry.
Time to re-read with new eyes. I guess my preferred use case blinded me.
Well even ignoring the non-even bob part, the classical across chain contracts are trivially traceable by everyone. Time to re-read with new eyes. I guess my preferred use case blinded me.
Oh, yeah...not even bob...sorry.
Time to re-read with new eyes. I guess my preferred use case blinded me.
Time to re-read with new eyes. I guess my preferred use case blinded me.
but I'm not able to see what you gain with coinswap
Motivation:
Alice would like to pay Bob, but doesn't want the whole world (or even Bob) tracing her transactions.
Alice would like to pay Bob, but doesn't want the whole world (or even Bob) tracing her transactions.
CoinSwap doesn't require a third party, Bob can be alice and I noted this in the post. I just thought it was easier to describe using three (or four) parties then trying to make distinct one party operating in multiple roles... an effort to try to simplify some of that complexity you mention.
I just thought it was easier to describe using three (or four) parties then trying to make distinct one party operating in multiple roles... an effort to try to simplify some of that complexity you mention.Actually it would be simpler for me if they were only Alice and Bob.
I'm trying to compare it with the "classical" trading across chain contract but I'm not able to see what you gain with coinswap or having Carol in the middle.
(But seriously, give us a donation addr)
There is an address in my BCT profile, or you can contact me in PM for a unique address.
@gmaxwell
WHERE IS THE DONATION ADDRESS
I WANT TO THROW SOME COINS AT YOU !!!!!!!!11111ONEONE.
----
(But seriously, give us a donation addr)
WHERE IS THE DONATION ADDRESS
I WANT TO THROW SOME COINS AT YOU !!!!!!!!11111ONEONE.
----
(But seriously, give us a donation addr)
Both it and CoinSwap appear to enable two party mixing, with unlinkable transactions, providing an anonymity set of all similar transactions happening concurrently. Both depend on what you call hash locking. Both are complex but the complexity is in different spots: in CoinSwap, it requires a number of rounds and a third party Carol. In the paper, it requires a complex setup, including the cut-and-choose.
A couple points of comparison come to mind:The paper proposal has a probability of cheating related to a security parameter, and requires communications in the setup phase linear in that security parameter (though I'd previously described a cut-and-choose communications optimization that could help).
The paper's proposal has an anonymity set of only all such transactions, as the hash commitments will be made public. In the case where a CoinSwap is successful the transactions just look like 2-of-2 escrows which likely results in a larger anonymity set.
CoinSwap doesn't require a third party, Bob can be alice and I noted this in the post.
I just thought it was easier to describe using three (or four) parties then trying to make distinct one party operating in multiple roles... an effort to try to simplify some of that complexity you mention.Generally I prefer protocols that have complexity moved into the initial setup, but the widened anonymity set achieved here by using all escrow transactions is probably worth losing the ability to front-load the complexity.
This is an interesting proposal. I'm curious to hear any thoughts on how it compares to the protocol in Section 7 of this academic paper: http://crypto.stanford.edu/~xb/fc12/bitcoin.pdf
Both it and CoinSwap appear to enable two party mixing, with unlinkable transactions, providing an anonymity set of all similar transactions happening concurrently. Both depend on what you call hash locking. Both are complex but the complexity is in different spots: in CoinSwap, it requires a number of rounds and a third party Carol. In the paper, it requires a complex setup, including the cut-and-choose.
Both it and CoinSwap appear to enable two party mixing, with unlinkable transactions, providing an anonymity set of all similar transactions happening concurrently. Both depend on what you call hash locking. Both are complex but the complexity is in different spots: in CoinSwap, it requires a number of rounds and a third party Carol. In the paper, it requires a complex setup, including the cut-and-choose.
Possible vector of attack:
If Carol does not give Alice a newly generated public key C each time the protocol is run, then Alice can provide Carol a fake TX_0 TXID (for example, a TXID of
Yep. Privacy requires new keys, but in general any protocol with a blind refund must always use a new key.If Carol does not give Alice a newly generated public key C each time the protocol is run, then Alice can provide Carol a fake TX_0 TXID (for example, a TXID of
Petertodd proposed above that the final releases should be accomplished by handing over the keys, which also is another reason why you want to use fresh keys.
Possible vector of attack:
If Carol does not give Alice a newly generated public key C each time the protocol is run, then Alice can provide Carol a fake TX_0 TXID (for example, a TXID of another transaction that Alice wants to steal from Carol).
Same happens if Bob does not give Carol a newly generated address each time, then Carol can attack Bob.
Also when the protocol reads {A,C} and {C,B} , these C's should be different, so it would be better to call the second key C'.
To avoid another (minor) problem on how to establish secure and authenticated connections between 3 participants it would be preferable that step D is changed so instead that Bob sends HX to Alice, is Carol who sends XH to Alice (received in the previous step). This removes the need that Alice connects to Bob.
If Carol does not give Alice a newly generated public key C each time the protocol is run, then Alice can provide Carol a fake TX_0 TXID (for example, a TXID of another transaction that Alice wants to steal from Carol).
Same happens if Bob does not give Carol a newly generated address each time, then Carol can attack Bob.
Also when the protocol reads {A,C} and {C,B} , these C's should be different, so it would be better to call the second key C'.
To avoid another (minor) problem on how to establish secure and authenticated connections between 3 participants it would be preferable that step D is changed so instead that Bob sends HX to Alice, is Carol who sends XH to Alice (received in the previous step). This removes the need that Alice connects to Bob.
Jump to: