CoinSwap: Transaction graph disjoint trustless trading

[gmaxwell]

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.

[1713582440]

1713582440

[1713582440]

1713582440

[1713582440]

1713582440

[1713582440]

1713582440

[jtimon]

Oh, yeah...not even bob...sorry.
Time to re-read with new eyes. I guess my preferred use case blinded me.

[gmaxwell]

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.

[gmaxwell]

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.

[oakpacific]

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.

[ShadowOfHarbringer]

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...

[marcus_of_augustus]

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?

[quannabe]

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?

[gmaxwell]

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?

[quannabe]

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?

[gmaxwell]

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.

[quannabe]

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

[gmaxwell]

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)

[quannabe]

Alice can't collect TX_3's output without making X public (as TX_3 requires X to be in the signature).

Ahh, I neglected to consider that X would be made public if TX_3 was spent.

Thanks!

[ratty]

Just bumping this real quick. This might actually become a thing if coinvalidation takes off. Trade tainted coins for clean ones. Ideally coinvalidation will just fade away like a fart, but in case it doesn't, coinswap!

I came up with the idea, on reddit, then someone pointed out this thread here where it was already done.

[CIYAM]

I read about the "atomic cross chain transfer" stuff quite a long time ago but I have yet to ever see *one single tx* using it.

Is there a reason why not one single "atomic cross chain transfer" has ever been done?

(sorry if this is a little OT - but I think it is related)

[stonecoldpat]

Hoping I don't point something out that is already known - but this protocol would be vulnerable if Bob and Carol were the same person. It's vulnerable in the sense that Bob could trace the transactions from Alice which defeats the purpose of the protocol. It might be worth highlighting how important it is to trust the identity of Carol.

[oakpacific]

Hoping I don't point something out that is already known - but this protocol would be vulnerable if Bob and Carol were the same person. It's vulnerable in the sense that Bob could trace the transactions from Alice which defeats the purpose of the protocol. It might be worth highlighting how important it is to trust the identity of Carol.

I have a proposal above  to link several intermediaries together, so in essence it becomes some sort of a Tor-like network, you can only compromise Alice/Bob's privacy when you control all the three relaying nodes.

[stonecoldpat]

Hoping I don't point something out that is already known - but this protocol would be vulnerable if Bob and Carol were the same person. It's vulnerable in the sense that Bob could trace the transactions from Alice which defeats the purpose of the protocol. It might be worth highlighting how important it is to trust the identity of Carol.

I have a proposal above  to link several intermediaries together, so in essence it becomes some sort of a Tor-like network, you can only compromise Alice/Bob's privacy when you control all the three relaying nodes.

Do you mean that you would do CoinSwap with 3 different people to send your fund to Bob?

So Alice sends escrow to node1, node1 sends escrow to node2, node 2 sends escrow to node 3, node 3 sends escrow to Bob?

This would make it more difficult for Eve, but it still has that fundamental problem of trusting an intermediary not to spill the beans doesn't it? Which CoinJoin manages to avoid from what I remember.

[RD965]

So does this thread have anything to do with coinswap.net exchange?