Topic: CoinSwap: Transaction graph disjoint trustless trading (Read 36511 times)

I was looking into this a few weeks back and there seemed to be a flaw in the original setup as proposed in the OP here. After some time I came up with this:

https://gist.github.com/AdamISZ/350bb4038834019eb0c06ec69446aec9

(It links at the top to a (apologies, poorly formatted) schematic; the last part of which has a diagram which may be a useful aid to understanding).

Would appreciate thoughts, a couple of people looked at it, so far comments included possibly replacing CLTV with CSV.

...

There is a new Bitfury white paper out (published today, Aug. 23, 2016) that references this thread:

http://www.coindesk.com/bitfury-research-seeks-shine-light-bitcoin-mixing-methods/

It is all way above my head, but may be of interest to the community.

Understood. I wasn't aware of the specifics of your design.

There are no funds at that 'location'.  No funds are ever sent the revealed key P, funds are sent the the key P+Recipient_Pubkey, which only the recipient knows the private key for (and only after the private key for P is revealed).
 

If the private key is revealed to the recipient on receipt of the transaction, by the time the transaction is confirmed, the sender could already have removed the funds at that location via another transaction.

uh. Your response isn't making any sense to me. I think you've misunderstood the protocol, but I am not sure where-- nothing about the above exists to prevent double spending, the transactions are all confirmed before further action is taken. Please reread and if you still hold the same view write out a sequence diagram that shows your attack so I can understand it.

I don't think this will work - I was looking into private key reveal schemes in order to try and counteract the problems with double spending in a proof of burn consensus scheme.

The problem is that the payer can simply construct another transaction in which they send the funds of that private key somewhere else, and then use one of the many techniques to make sure this double spending transaction gets confirmed first.

Here is a private atomic swap that doesn't need the multiphase "CoinSwap" transform, as I've come to call the generic protocol here that makes smart contracts private by hiding them from the blockchain.


B computes nonce x and  P = xG, P2 = P + H(P)G

B sends P to A

B pays to   if() {Apub+P2 CHECKSIG} else {CLTV Bpub CHECKSIG}

A pays  to   if() {Bpub2 CHECKSIG P2 FORCEDDISCLOSURECHECKSIG} else {CLTV Apub2}

What is a FORCEDDISCLOSURECHECKSIG? it's a signature construct that forces you to sign in such a way as to disclose the private key.

I am aware of two ways to get this construct in unmodified (no disabled opcodes) Bitcoin today.

One of them is: OP_SIZE 57 OP_LESSTHANOREQUAL OP_VERIFY

OP_CHECKSIGVERIFY

I agree with prior commenters ~ having both [CoinSwap and Coinjoin) available (in wallet, I think) would be good.  With support gradually being added in different wallets and cryptosystems for stealth send, what is available in combination will be significant.

[Note: I am aware that Stealth transaction technology (https://sx.dyne.org/stealth.html), a strong privacy development, has been incorporated into Vertcoin (https://vertcoin.org/) and Shadowcoin (http://www.shadowcoin.co/), with the latter coin type also incorporating an implementation of zk-snarks, which provides anonymity.  Stealth send is also becoming available for Electrum (https://github.com/spesmilo/electrum/pull/817) ~ beyond that, I'm not sure where stealth is actually supported, but if you know of more examples by all means please add them here.]

If not directly in wallet, then one could design a plugin (am thinking of the Electrum mixer plugin example, here, though Electrum also has greenaddress and coinapult plugins you could examine):


Regarding the details of 'byzantine cycle mode,' after reading the description and paper, it is my sense that it will also serve tremendously useful for implementation of trans-identical proposals which incorporate 'facet-based' and/or multisignature-oriented anonymous-option identity-related implementations.  Repeating part of the original post below:


My (very generalized) feedback statement is that this is an excellent idea, thus I've linked to the discussion and paper in my Trans-Identical post at the Unsystem forum, which I originally created to simply to discuss possible 'trans-identical' possibilities, but which I now also see as being a launchpad to help defeat the Windhover regulation principle (the pro-regulatory element of Windhover). ~ The idea of tying regulation to decentralized identity is anathema to everything that we should stand for in this community, and just as CoinValidation was defeated by digital fire (in that case, by CoinJoin), so now must we also support and develop technology to defeat the Windhover regulation principle.

The Unsystem forum post I refer to is here:
https://forum.unsystem.net/t/interoperability-and-trans-identical-identity-decentralization-proposals-thoughts-for-review/333/4?u=abisprotocol

I also wanted to address the question that arose relating to Zerocash, here:


It was my understanding that the concerns regarding element of trust needed to launch zerocash were being planned to be ameliorated via some sort of multiparty mechanism, so that there would not actually be a single party that someone would have to trust somehow to kickstart zerocash.  I'm not sure if I have the right twitter thread on it, but I believe this was related to it:
This one alludes to a multiparty computation protocol (yes, he's a zerocash dev)
https://twitter.com/matthew_d_green/status/448856221765095426
And this one refers to the multiparty computation protocol being developed for the setup itself, as I alluded to above:
https://twitter.com/matthew_d_green/status/472208415867928576

Note ~ I am not on the Zerocash team or affiliated with it but I am in full support of their proposals.  They have been subjected to tremendous scrutiny.  It's my understanding that zerocash is going open source (like zerocoin/libzerocoin already is though that's different), but I don't know when that will happen with zerocash, so ask the devs or keep checking their website (http://zerocash-project.org/).

So which is better lol?. Coinswap or coinjoin?.

Thanks.

What do you mean?

You realize this is a bit of a necrothread.

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

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.

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.

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

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.

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

Thanks!