Bitcoin Forum
May 24, 2017, 03:47:09 PM *
News: Latest stable version of Bitcoin Core: 0.14.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 [18] 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 »
  Print  
Author Topic: CoinJoin: Bitcoin privacy for the real world  (Read 250074 times)
Sarchar
Member
**
Offline Offline

Activity: 88


View Profile
December 28, 2013, 09:06:39 AM
 #341

Would this strategy work?

Take N>3 coin joiners wishing to mix their coins and give them an order: A to B to C to D to E and back to A, forming a circle.

A is responsible for creating the first transaction. We proceed in rounds, each person receives the transaction from the person before them and forwards it to the next guy, where E returns it to A to form a circle.

Each person, upon receiving the transaction does the following:

If the received transaction is completely signed, then either forward the transaction onto the next guy or broadcast it to the bitcoin network. Forward randomly so the next in line can't figure out who signed last.

Otherwise, randomly add unspent inputs (from the blockchain utxo set) to the transaction and then add some random outputs. The inputs and outputs don't need to be owned by the person adding them, but eventually you need to include your final inputs and outputs. Next, select a few inputs added in a previous round and remove them (in the first round there will be nothing to remove). Do the same for outputs. Don't remove inputs or outputs that others added because they will assume you're trying to cheat and leave.  In a later round, say 2 or 3, optionally sign one of your real inputs. If a successive person changes the tx again, you'll have to resign in another, later round.

Continue rounds until all fake inputs and outputs have been removed and the remaining inputs have been signed.

The obvious downsides include having to resign multiple times, the potential for lots of rounds, and not scaling well to large values of N. Any other thoughts?

POLONIEX TRADING SIGNALS
+50% Profit and more via TELEGRAM
ALTCOINTRADER.CO
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1495640829
Hero Member
*
Offline Offline

Posts: 1495640829

View Profile Personal Message (Offline)

Ignore
1495640829
Reply with quote  #2

1495640829
Report to moderator
1495640829
Hero Member
*
Offline Offline

Posts: 1495640829

View Profile Personal Message (Offline)

Ignore
1495640829
Reply with quote  #2

1495640829
Report to moderator
1495640829
Hero Member
*
Offline Offline

Posts: 1495640829

View Profile Personal Message (Offline)

Ignore
1495640829
Reply with quote  #2

1495640829
Report to moderator
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2184



View Profile
December 28, 2013, 04:04:59 PM
 #342

If the parties immediately before and after you in the loop are conspiring (or sibyls) then they can always tell which inputs/outputs you added, so this is less private than some of the schemes proposed, in which N-2 malicious parties in an N way join cannot tell the 2 honest parties apart, for all N>2 (assuming you have underlying anonymous communication).

Your protocol sounds somewhat similar to a reencryption mix, except a reencryption mix doesn't need the chaff because the values are encrypted. A problem with using them for CJ is that protocols to prove faithful operation (e.g. to catch a party trying to break it) are computation and bandwidth intensive. One of their upsides (also— somewhat the case for yours) is that they are not so dependent on an underlying anonymity network (also the case for a MPC sort).

I think another potential issue in your protocol is that someone can just keep changing inputs/outputs forever to jam it, and you can't tell who is doing it (well, not anymore than you can tell who is who absent a jammer).

Bitcoin will not be compromised
NewLiberty
Legendary
*
Offline Offline

Activity: 1148


Gresham's Lawyer


View Profile WWW
December 28, 2013, 04:47:14 PM
 #343

For those willing to futz around with raw transactions, I have a simple centralized coinjoiner available here:

https://www.wpsoftware.net/coinjoin/

Basically, once you submit a transaction this opens a 15-minute window for others to submit a transaction. After the 15 minutes are up, the transactions are merged and everybody signs the merged transaction. Once all the signatures are received, the joiner submits the transaction.

Thanks very much to my testers, in particular gmaxwell and midnightmagic, for their excellent suggestions and bug-finding.
Brought forward

FREE MONEY1 Bitcoin for Silver and Gold NewLibertyDollar.com and now BITCOIN SPECIE (silver 1 ozt) shows value by QR
Bulk premiums as low as .0012 BTC "BETTER, MORE COLLECTIBLE, AND CHEAPER THAN SILVER EAGLES" 1Free of Government
Sarchar
Member
**
Offline Offline

Activity: 88


View Profile
December 28, 2013, 04:48:08 PM
 #344

If the parties immediately before and after you in the loop are conspiring (or sibyls) then they can always tell which inputs/outputs you added, so this is less private than some of the schemes proposed, in which N-2 malicious parties in an N way join cannot tell the 2 honest parties apart, for all N>2 (assuming you have underlying anonymous communication).

I considered this, but there's the extra advantage that nobody knows for sure if a single entity in the loop is indeed a single entity.  Consider a figure 8, where node C is at the apex, and when he receives the transaction, it's passed around a similar set of other nodes and returning back to C, he forwards it on in the other loop.  You'd have to control a large number of nodes in such a network to be able to produce any real association.

Quote
Your protocol sounds somewhat similar to a reencryption mix, except a reencryption mix doesn't need the chaff because the values are encrypted. A problem with using them for CJ is that protocols to prove faithful operation (e.g. to catch a party trying to break it) are computation and bandwidth intensive. One of their upsides (also— somewhat the case for yours) is that they are not so dependent on an underlying anonymity network (also the case for a MPC sort).

Do you have any more information on how a reencryption mix works w.r.t. CoinJoin?

Quote
I think another potential issue in your protocol is that someone can just keep changing inputs/outputs forever to jam it, and you can't tell who is doing it (well, not anymore than you can tell who is who absent a jammer).

True - it's especially problematic as N goes larger.  Worst case, you have to assume everyone in the group is against you.  Limit yourself to a low number of rounds and try other peers if the # of rounds is exceeded.  You could theoretically build a list of trusted peers where previous successful CJs have been executed, too.  All this is just workaround for a fundamental problem, though.
Patel
Legendary
*
Offline Offline

Activity: 1258



View Profile WWW
January 04, 2014, 01:50:43 AM
 #345

Have any Bitcoin core developers said anything about adding CoinJoin into the protocol?

Bump for this thread because it is important for Bitcoin
maaku
Legendary
*
expert
Offline Offline

Activity: 905


View Profile
January 04, 2014, 05:45:30 AM
 #346

Have any Bitcoin core developers said anything about adding CoinJoin into the protocol?

Bump for this thread because it is important for Bitcoin

You don't need to add it to the protocol, CoinJoin operates just fine at a strictly higher level. But I suppose you mean adding support to the reference wallet for CoinJoin transactions? I would not be surprised to see that happen, but someone needs to write the code first.

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2184



View Profile
January 04, 2014, 05:50:37 AM
 #347

Have any Bitcoin core developers said anything about adding CoinJoin into the protocol?
Bump for this thread because it is important for Bitcoin
It doesn't need to be added to the protocol, thats part of the point.

If instead you mean the integrated Bitcoin-qt wallet, Wumpus and I have both commented that we'd like to see it there. I'd like to see more external implementation done first.  Inside the wallet is good for getting users, but it's not good for protocol R&D.

Bitcoin will not be compromised
BurtW
Legendary
*
Offline Offline

Activity: 1960

All paid signature campaigns should be banned.


View Profile WWW
January 04, 2014, 08:33:59 AM
 #348

Bitcoin has been very good to me over these last few years.  I would hate to see it killed by these various validation proposals.

As of this posting the bounty pool at: https://blockchain.info/address/3M8XGFBKwkf7miBzpkU3x2DoWwAVrD1mhk contains a bit over 31 BTC.

In order to stand behind my signature below and support this effort I offer the following matching donation (inspired by Theymos):

I will donate 5 BTC as soon as the total in the fund goes over 36 BTC.
Done.

Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


View Profile
January 04, 2014, 07:42:57 PM
 #349

Fantastic BurtW!

BurtW
Legendary
*
Offline Offline

Activity: 1960

All paid signature campaigns should be banned.


View Profile WWW
January 04, 2014, 08:16:45 PM
 #350

$34K should get this done (I hope).

Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
Voodah
Full Member
***
Offline Offline

Activity: 238



View Profile
January 05, 2014, 12:46:28 AM
 #351

Is Blockchain.info's Shared Send part of their closed source stuff?

Is it implemented along these guidelines?
ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
January 05, 2014, 11:07:50 AM
 #352

Is Blockchain.info's Shared Send part of their closed source stuff?

Is it implemented along these guidelines?
I join the question.

BurtW
Legendary
*
Offline Offline

Activity: 1960

All paid signature campaigns should be banned.


View Profile WWW
January 05, 2014, 03:43:23 PM
 #353

As far as I can tell from the posts up thread the blockchain.info Shared Send system is a basic implementation of the centralized version of the proposal.

You can use it without a blockchain.info wallet, and read all about it here:  

https://blockchain.info/wallet/send-shared

From the FAQ on that page:

Quote
How does it work?
Coins send with shared send will be matched up with another user. When a match is found your coins will be swapped breaking the transaction chain from your own wallet. Coins will be swapped with multiple users making the chain even harder to follow.

I found this very interesting (also from the same FAQ):

Quote
How can you guarantee that the transaction chain will be broken?
There is no guess work involved, each shared transaction analyzes up to 50,000 outputs or 250 levels deep in the blockchain to ensure the coins sent to the destination address are 100% untainted with the original coins.

The source code for taint analysis calculations can be found on the Blockchain Github Project

Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
Rassah
Legendary
*
Offline Offline

Activity: 1680


Director of Bitcoin100


View Profile
January 06, 2014, 12:51:46 AM
 #354

As far as I can tell from the posts up thread the blockchain.info Shared Send system is a basic implementation of the centralized version of the proposal.

It's actually a plain mixing service that was implemented a long time ago, way before CoinJoin was proposed. They have a separate CoinJoin style transaction option that does use CoinJoin, but as far as I know, requires you to use a blockchain.info wallet, since CoinJoin has special nonstandard transactions. Fees are different, too, with 0.5% for Send-Shared, and a standard 0.0001BTC transaction fee for CoinJoin (with multiple mixes suggested, each one costing an extra 0.0001BTC)

BurtW
Legendary
*
Offline Offline

Activity: 1960

All paid signature campaigns should be banned.


View Profile WWW
January 06, 2014, 12:54:11 AM
 #355

As far as I can tell from the posts up thread the blockchain.info Shared Send system is a basic implementation of the centralized version of the proposal.

It's actually a plain mixing service that was implemented a long time ago, way before CoinJoin was proposed. They have a separate CoinJoin style transaction option that does use CoinJoin, but as far as I know, requires you to use a blockchain.info wallet, since CoinJoin has special nonstandard transactions. Fees are different, too, with 0.5% for Send-Shared, and a standard 0.0001BTC transaction fee for CoinJoin (with multiple mixes suggested, each one costing an extra 0.0001BTC)
Thanks for the info.  I did not realize the two were different.

Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
andytoshi
Full Member
***
Offline Offline

Activity: 167

-


View Profile
January 07, 2014, 12:33:14 AM
 #356


since CoinJoin has special nonstandard transactions.
Coinjoin does not need nonstandard transactions, nor should it use them -- it is NP-hard to determine whether an ordinary bitcoin transaction might be a coinjoin.
Voodah
Full Member
***
Offline Offline

Activity: 238



View Profile
January 07, 2014, 07:19:58 AM
 #357

As far as I can tell from the posts up thread the blockchain.info Shared Send system is a basic implementation of the centralized version of the proposal.

It's actually a plain mixing service that was implemented a long time ago, way before CoinJoin was proposed. They have a separate CoinJoin style transaction option that does use CoinJoin, but as far as I know, requires you to use a blockchain.info wallet, since CoinJoin has special nonstandard transactions. Fees are different, too, with 0.5% for Send-Shared, and a standard 0.0001BTC transaction fee for CoinJoin (with multiple mixes suggested, each one costing an extra 0.0001BTC)

Interesting, and yes, fees.

Their Shared Coin has a per repetition fee as well.
Rassah
Legendary
*
Offline Offline

Activity: 1680


Director of Bitcoin100


View Profile
January 07, 2014, 03:33:44 PM
 #358

Their Shared Coin has a per repetition fee as well.

The 0.5% fee is the fee they charge for the service. The Shared Coin fee is a transaction fee that goes to the miners.

prezbo
Sr. Member
****
Offline Offline

Activity: 430


View Profile
January 18, 2014, 08:07:38 AM
 #359

When there are two outputs to the same address with the same value (for example, two people want to donate 1 btc each to wikileaks), what prevents the service owner from swapping one of them with their own address?
maaku
Legendary
*
expert
Offline Offline

Activity: 905


View Profile
January 18, 2014, 09:31:28 AM
 #360

You would never sign it.

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 [18] 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 »
  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!