CoinSwap: Transaction graph disjoint trustless trading

[Vortex20000]

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

You realize this is a bit of a necrothread.

[1714778443]

1714778443

[1714778443]

1714778443

[1714778443]

1714778443

[1714778443]

1714778443

[RD965]

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

You realize this is a bit of a necrothread.

What do you mean?

[topman21]

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

Thanks.

[ShadowOfHarbringer]

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

[ABISprotocol]

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

Thanks.

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

I've updated the mixer to work independently of Electrum mainline now. As long as you have the latest version you can now simply drop the mixer.py file into your plugins folder and it will be available and can be enabled. It no longer needs a separate fork or Electrum version.
The standalone mixer plugin file is now:
https://github.com/tkhaew/electrum/blob/mixer_plugin/plugins/mixer.py
The default folder where this is can be dropped (on my Ubuntu system anyway) is:
/usr/local/lib/python2.7/dist-packages/Electrum-1.9.5-py2.7.egg/electrum_plugins/
( though the version number could be different )

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:

As part of a new open source implementation project, I've written a research paper presenting a new, complentary protocol to increase anonymity to Bitcoin.
The preliminary paper is the first of two papers describing the algorithmic underpinnings of the project, building on ideas from this forum (CoinJoin, CoinSwap, CoinShuffle, and atomic transfers)
The new algorithm, called Byzantine Cycle Mode, extends the application of Bitcoin mixing primitives (CoinJoin, etc) to large numbers of players mixing unequal inputs. I use an analogy to how encryption modes such as CTR and CBC extend the application of block ciphers (AES, 3DES) to large inputs of non whole block sizes.
Abstract:

We present a new distributed algorithm, called Byzantine Cycle Mode (BCM), that mixes bitcoins of different sizes. Most known decentralized, riskless Bitcoin mixing algorithms (CoinShuffle, CoinShift, DarkWallet’s CoinJoin) either require the numbers of bitcoin being mixed to be equal or their anonymity strongly depends on it. Some also do not scale easily to large number of players. BCM relaxes these constraints by transforming large instances with unequal bitcoin amounts into smaller sub-instances on equal amounts — allowing players to mix using the known algorithms while preserving their degree of semantic security.

Appreciate feedback.

(...)

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:

A viable trust still persist in the use of Zerocash so i suggest you check it out.

I don't really understand this post.

Are you saying that the initial release requires an element of trust at launch?

(...)

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

[gmaxwell]

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 <P> OP_CHECKSIGVERIFY

[monsterer]

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 <P> OP_CHECKSIGVERIFY

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.

[gmaxwell]

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.

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.

[monsterer]

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.

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.

[gmaxwell]

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

[monsterer]

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

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

[OROBTC]

...

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.

[waxwing]

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.