Bitcoin Forum
September 23, 2017, 11:05:29 AM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2] 3 »  All
  Print  
Author Topic: CoinSwap: Transaction graph disjoint trustless trading  (Read 33421 times)
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2296



View Profile
November 30, 2013, 07:35:53 PM
 #21

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.

Bitcoin will not be compromised
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1506164729
Hero Member
*
Offline Offline

Posts: 1506164729

View Profile Personal Message (Offline)

Ignore
1506164729
Reply with quote  #2

1506164729
Report to moderator
1506164729
Hero Member
*
Offline Offline

Posts: 1506164729

View Profile Personal Message (Offline)

Ignore
1506164729
Reply with quote  #2

1506164729
Report to moderator
jtimon
Legendary
*
Offline Offline

Activity: 1372


View Profile WWW
November 30, 2013, 07:39:08 PM
 #22

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

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2296



View Profile
November 30, 2013, 07:41:41 PM
 #23

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.

Bitcoin will not be compromised
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2296



View Profile
December 04, 2013, 02:39:52 PM
 #24

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.

Bitcoin will not be compromised
oakpacific
Hero Member
*****
Offline Offline

Activity: 798


View Profile
March 06, 2014, 11:34:15 AM
 #25

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.

https://tlsnotary.org/ Fraud proofing decentralized fiat-Bitcoin trading.
ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
March 06, 2014, 02:52:53 PM
 #26

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
Legendary
*
Offline Offline

Activity: 2380



View Profile
March 06, 2014, 10:32:33 PM
 #27

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
Newbie
*
Offline Offline

Activity: 5


View Profile
March 24, 2014, 11:18:28 PM
 #28

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
Moderator
Legendary
*
qt
Offline Offline

Activity: 2296



View Profile
March 24, 2014, 11:36:53 PM
 #29

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?

Bitcoin will not be compromised
quannabe
Newbie
*
Offline Offline

Activity: 5


View Profile
March 25, 2014, 07:58:28 PM
 #30

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
Moderator
Legendary
*
qt
Offline Offline

Activity: 2296



View Profile
March 25, 2014, 10:19:41 PM
 #31

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.

Bitcoin will not be compromised
quannabe
Newbie
*
Offline Offline

Activity: 5


View Profile
March 25, 2014, 10:42:40 PM
 #32

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 Smiley
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2296



View Profile
March 25, 2014, 11:14:06 PM
 #33

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)

Bitcoin will not be compromised
quannabe
Newbie
*
Offline Offline

Activity: 5


View Profile
April 01, 2014, 10:55:41 PM
 #34

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
Sr. Member
****
Offline Offline

Activity: 261


View Profile
June 28, 2014, 05:11:24 PM
 #35

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
Legendary
*
Offline Offline

Activity: 1848


Ian Knowles - CIYAM Lead Developer


View Profile WWW
June 28, 2014, 05:14:50 PM
 #36

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)

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
stonecoldpat
Newbie
*
Offline Offline

Activity: 2


View Profile
July 03, 2014, 12:48:28 PM
 #37

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
Hero Member
*****
Offline Offline

Activity: 798


View Profile
July 03, 2014, 09:47:27 PM
 #38

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.

https://tlsnotary.org/ Fraud proofing decentralized fiat-Bitcoin trading.
stonecoldpat
Newbie
*
Offline Offline

Activity: 2


View Profile
July 04, 2014, 09:55:57 AM
 #39

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
Sr. Member
****
Offline Offline

Activity: 476


View Profile
October 15, 2014, 07:45:39 AM
 #40

So does this thread have anything to do with coinswap.net exchange?
Pages: « 1 [2] 3 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!