Bitcoin Forum
November 18, 2017, 11:03:39 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 [3]  All
  Print  
Author Topic: CoinSwap: Transaction graph disjoint trustless trading  (Read 34967 times)
Vortex20000
Hero Member
*****
Offline Offline

Activity: 504

sucker got hacked and screwed --Toad


View Profile WWW
October 15, 2014, 07:56:23 AM
 #41

So does this thread have anything to do with coinswap.net exchange?
You realize this is a bit of a necrothread.

1511003019
Hero Member
*
Offline Offline

Posts: 1511003019

View Profile Personal Message (Offline)

Ignore
1511003019
Reply with quote  #2

1511003019
Report to moderator
1511003019
Hero Member
*
Offline Offline

Posts: 1511003019

View Profile Personal Message (Offline)

Ignore
1511003019
Reply with quote  #2

1511003019
Report to moderator
A blockchain platform for effective freelancing
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511003019
Hero Member
*
Offline Offline

Posts: 1511003019

View Profile Personal Message (Offline)

Ignore
1511003019
Reply with quote  #2

1511003019
Report to moderator
1511003019
Hero Member
*
Offline Offline

Posts: 1511003019

View Profile Personal Message (Offline)

Ignore
1511003019
Reply with quote  #2

1511003019
Report to moderator
RD965
Hero Member
*****
Offline Offline

Activity: 490


View Profile
October 15, 2014, 08:11:03 AM
 #42

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

Activity: 840



View Profile
October 19, 2014, 07:52:10 AM
 #43

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

Thanks.
ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
October 19, 2014, 11:07:59 AM
 #44

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

ABISprotocol
Sr. Member
****
Offline Offline

Activity: 277

ABISprotocol on Gist


View Profile WWW
October 23, 2014, 02:44:55 AM
 #45

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

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


ABISprotocol (Github/Gist)
http://abis.io
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2338



View Profile
November 26, 2015, 06:02:56 AM
 #46

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

Bitcoin will not be compromised
monsterer
Legendary
*
Offline Offline

Activity: 1008


View Profile
November 26, 2015, 09:41:14 AM
 #47

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

Activity: 2338



View Profile
November 27, 2015, 05:23:30 PM
 #48

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.

Bitcoin will not be compromised
monsterer
Legendary
*
Offline Offline

Activity: 1008


View Profile
November 29, 2015, 10:31:35 PM
 #49

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

Activity: 2338



View Profile
November 30, 2015, 09:23:43 AM
 #50

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

Bitcoin will not be compromised
monsterer
Legendary
*
Offline Offline

Activity: 1008


View Profile
December 01, 2015, 11:25:41 AM
 #51

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

Activity: 1316



View Profile
August 24, 2016, 01:30:42 AM
 #52

...

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

Activity: 469


View Profile
April 15, 2017, 03:48:46 PM
 #53

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.

PGP fingerprint 4668 9728 A9F6 4B39 1FA8 71B7 B3AE 09F1 E9A3 197A (use email to contact)
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!