Bitcoin Forum
August 20, 2017, 01:26:33 PM *
News: Latest stable version of Bitcoin Core: 0.14.2  [Torrent].
 
   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 257256 times)
Michael_S
Sr. Member
****
Offline Offline

Activity: 278


Bitcoin-Note-and-Voucher-Printing-Empowerer


View Profile
November 18, 2013, 10:01:42 PM
 #281

For disadvantage (2):
Apparently the only way around is to split-up the amount to be cleaned into smaller quantities and serialize the procedure. E.g. if I want to clean 100 BTC, I serialize it into 100 times 1 BTC, i.e. I will not send out the (n+1)th BTC to the mixer before I have received the nth BTC back. So my risk of fraud gets reduced to 1 BTC. The price I pay is the increased Tx fees, so I can half these fees by accepting twice the risk by selecting 2 BTC increments for the mixing procedure instead of 1 BTC.
gmaxwell's  "CoinSwap" introduces a framework that enables "secure" mixing in the sense that the mixer can't run with your coins. I believe CoinSwap is better for dedicated mixing than splitting funds into smaller quantities because it does not just spread the risk, it brings it down to just about zero. Additionally, the Tx fees are lower.
Thanks, I will have a look at CoinSwap...

[...]
Now I had a look at CoinSwap. Nice! I was not aware of a concept like these "hash-locked" transactions.

I am wondering whether it is possible to combine the CoinSwap and CoinJoin concepts. Idea (Ex. N=3 again):

Traditional CoinJoin:
   ConJoin Transaction: inputs = (1Ain, 1Bin, 1Cin), outputs = (1Aout, 1Bout, 1Cout).

New "CoinJoinSwap":
   ConJoin Transaction 1: inputs = (1Ain, 1Bin, 1Cin), outputs = (1Xout, 1Yout, 1Zout).
   ConJoin Transaction 2: inputs = (1Xin, 1Yin, 1Zin), outputs = (1Aout, 1Bout, 1Cout).
So here 6 participants are involved, namely Persons A, B, C, X, Y, Z.

Contrary to normal CoinJoin, taint is really removed instead of just "hidden".

A CoinSwap-like protocol would have to be defined to make sure that no funds can be embezzled (via hash-locked techniques?), and that no connections between the two CJ transactions can be made from the outside observer. And hopefully, it can be done in a way that there's not a "single-point-of privacy-leak" like in CoinSwap where "Carol can tell about Alice".

I am stopping here, because I did not understand CoinSwap to the last detail yet, but I have the feeling that such combined mechanism could be possible and trying to inspire...

1503235593
Hero Member
*
Offline Offline

Posts: 1503235593

View Profile Personal Message (Offline)

Ignore
1503235593
Reply with quote  #2

1503235593
Report to moderator
1503235593
Hero Member
*
Offline Offline

Posts: 1503235593

View Profile Personal Message (Offline)

Ignore
1503235593
Reply with quote  #2

1503235593
Report to moderator
1503235593
Hero Member
*
Offline Offline

Posts: 1503235593

View Profile Personal Message (Offline)

Ignore
1503235593
Reply with quote  #2

1503235593
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1503235593
Hero Member
*
Offline Offline

Posts: 1503235593

View Profile Personal Message (Offline)

Ignore
1503235593
Reply with quote  #2

1503235593
Report to moderator
maaku
Legendary
*
expert
Offline Offline

Activity: 905


View Profile
November 18, 2013, 10:22:43 PM
 #282

Michael, your examples indicate bad coin control and insufficient anonymity sets, not in inherent unknown weakness in CoinJoin.

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

Activity: 1848



View Profile
November 19, 2013, 08:31:54 AM
 #283

Furthermore, remember that in CoinJoin all outputs have the same size. So in this case one output is 1.5 BTC to 1Friend, so the other two outputs (going to new addresses of Person A himself) each have 1.5 BTC too. So the sum of all inputs must be at least 4.5 BTC. So Person A must have at lest 4.5 BTC in his wallet although he just wants to transfer 1.5 BTC to 1Friend.

Good point. However outputs don't have to be the same value but could be among a set of values. And with the advent of HD wallets, I could ask my friend for an extended pubkey so I could generate as many addresses of them as I wanted, and I would set up the outputs of the CJ accordingly. For example if the outputs must be powers of two between 2^16 and 2^32 satoshis, I could roughly fit 1.5 BTC into that. (2^27 + 2^23 + 2^22 + 2^21 + 2^20) / 1e8 = 1.49946368.

Cryddit
Legendary
*
Offline Offline

Activity: 840


View Profile
November 19, 2013, 04:27:40 PM
 #284

I appreciate the thought here with coinjoin, but the fact remains that people need to actually use it, and then people need to actually pay (transaction fees) for it. 

Honestly, I don't think they will.  If the manager of a sandwich shop spends 1/10 of 1% of his receipts on coinjoin transactions, he's going to get fired.  If you ask naive user Joe whether he's willing to spend an extra fifty cents for some abstract thing like privacy on a legitimate $500 transaction, he's going to say no because he doesn't care enough in the immediate case. 

If you want privacy, then you need to fix the protocol so that *EVERY* transaction is a mix, and people *DON'T* have to pay extra for mixing.

My thought on this is that the clients need to prefer producing outputs in "standard" coin sizes (to separate output addresses) such as [1 | 2.5 | 5] * 10^N - for ALL outputs including change - and that whenever possible *both* sides of a transaction need to be providing inputs that add up to at least twice the amount of money that's actually required to change hands. 

'Coz honestly, it doesn't matter how good your coinjoin design is if people still have to pay tx fees to use it, because they won't.



Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1106


View Profile
November 19, 2013, 05:40:24 PM
 #285

I appreciate the thought here with coinjoin, but the fact remains that people need to actually use it, and then people need to actually pay (transaction fees) for it. 

CoinJoin transactions are slightly smaller than non-CoinJoin because all parties can share the same transaction header, and thus are actually cheaper than the alternative.

Cryddit
Legendary
*
Offline Offline

Activity: 840


View Profile
November 19, 2013, 05:47:46 PM
 #286

Yes, but as far as I can see the coinjoin is still a separate transaction with separate fees. 

Joe Blow buys a sandwich.  Why would joe blow, or the sandwich shop, then also pay to do coinjoin transactions?
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2268



View Profile
November 19, 2013, 05:57:12 PM
 #287

Yes, but as far as I can see the coinjoin is still a separate transaction with separate fees.  
Joe can pay for his sandwich directly— this is one option, but not a requirement. Please review the initial post, this is covered in detail.

Bitcoin will not be compromised
Carlton Banks
Legendary
*
Offline Offline

Activity: 1736



View Profile
November 19, 2013, 08:25:57 PM
 #288

It seems to me that you can cut down the chances of a CoinJoin being participated in by snoopy spying agencies by choosing low numbers of participants and doing numerous/frequent CoinJoins (and accepting the increased fees you pay as a cost of keeping your holdings private).

And when I say low numbers of participants, it also seems there is an option to choose to CoinJoin entirely with inputs and outputs of addresses that only belong to you. How could someone analysing the blockchain prove they were not trying to disentangle the identities of what would in effect be a spoofed CoinJoin? I'm not sure that they could.

Vires in numeris
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2268



View Profile
November 20, 2013, 05:31:50 PM
 #289

And when I say low numbers of participants, it also seems there is an option to choose to CoinJoin entirely with inputs and outputs of addresses that only belong to you. How could someone analysing the blockchain prove they were not trying to disentangle the identities of what would in effect be a spoofed CoinJoin? I'm not sure that they could.
Normal transactions do this all the time (ignoring creating faux-anonymous output values), but today people assume common use means common ownership.  Part of the advantage of CoinJoin is that if widely used it breaks the ability to assume that, recovering some privacy for everyone.

Bitcoin will not be compromised
jedunnigan
Sr. Member
****
Offline Offline

Activity: 280


View Profile
November 22, 2013, 03:05:43 AM
 #290

I just realized CoinJoin is actually an effective scaling tool; no longer would we have to increase the block size to handle more tx/s. Just bundle them in CoinJoin txs.
Anon136
Legendary
*
Offline Offline

Activity: 1232



View Profile
November 22, 2013, 05:39:05 AM
 #291

I just realized CoinJoin is actually an effective scaling tool; no longer would we have to increase the block size to handle more tx/s. Just bundle them in CoinJoin txs.

it only helps a little bit because it only saves the need to store some of the transaction headers. As far as the information inside of the body is concerned, you still have just as many inputs and outputs, its just as much data to be stored on the blockchain.

Rep Thread: https://bitcointalk.org/index.php?topic=381041
If one can not confer upon another a right which he does not himself first possess, by what means does the state derive the right to engage in behaviors from which the public is prohibited? Is there any process, procedure or ritual through which an immoral action can be legitimately transformed into a moral one with out changing the character of the action itself?
jedunnigan
Sr. Member
****
Offline Offline

Activity: 280


View Profile
November 22, 2013, 06:40:48 AM
 #292

I just realized CoinJoin is actually an effective scaling tool; no longer would we have to increase the block size to handle more tx/s. Just bundle them in CoinJoin txs.

it only helps a little bit because it only saves the need to store some of the transaction headers. As far as the information inside of the body is concerned, you still have just as many inputs and outputs, its just as much data to be stored on the blockchain.
Ah true.

Someone debunk this idea: SwapJoin

I know you can only add up to [I think] 10 sigs in a multi sig transaction, but could you build the escrow transactions in the CoinSwap protocol with CoinJoin properties? Or is that a gross misunderstanding of how it works.
BurtW
Legendary
*
Offline Offline

Activity: 2002

All paid signature campaigns should be banned.


View Profile WWW
November 22, 2013, 08:19:38 AM
 #293

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.


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

Activity: 1120


View Profile
November 22, 2013, 12:05:04 PM
 #294

it only helps a little bit because it only saves the need to store some of the transaction headers. As far as the information inside of the body is concerned, you still have just as many inputs and outputs, its just as much data to be stored on the blockchain.

It could help if it covered time too.

If A pays B and then B pays C, then the 2 transactions could be combined to give A pays C. 

A pays C could have higher fee per kB than A pays B and B pays C, so it is worth it for a mining pool to combine them.

This could happen if the transaction pool started becoming a queue.  At the moment, transactions mostly get into the chain.

If transactions stayed unconfirmed for a while, then you could end up with more opportunities to collapse the transactions.  So, a longer queue makes the blockchain more efficient.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
Carlton Banks
Legendary
*
Offline Offline

Activity: 1736



View Profile
November 22, 2013, 02:36:57 PM
 #295

I just realized CoinJoin is actually an effective scaling tool; no longer would we have to increase the block size to handle more tx/s. Just bundle them in CoinJoin txs.

It could be used as a load balancing device for a system with a fixed block size limit. CoinJoins happen automatically to help compress more transactions into the available block space. This could provide a good argument against a scheme with a continuously variable block size, or to a scheme with no limit at all (although I don't think anyone has yet made any serious proposal for the latter)

It also illustrates that CoinJoin really is just that, joining inputs and outputs into single transactions, regardless of the utility you're seeking from doing so.

Vires in numeris
Anon136
Legendary
*
Offline Offline

Activity: 1232



View Profile
November 22, 2013, 06:33:31 PM
 #296

it only helps a little bit because it only saves the need to store some of the transaction headers. As far as the information inside of the body is concerned, you still have just as many inputs and outputs, its just as much data to be stored on the blockchain.

It could help if it covered time too.

If A pays B and then B pays C, then the 2 transactions could be combined to give A pays C. 

A pays C could have higher fee per kB than A pays B and B pays C, so it is worth it for a mining pool to combine them.

This could happen if the transaction pool started becoming a queue.  At the moment, transactions mostly get into the chain.

If transactions stayed unconfirmed for a while, then you could end up with more opportunities to collapse the transactions.  So, a longer queue makes the blockchain more efficient.

thats very clever tier

Rep Thread: https://bitcointalk.org/index.php?topic=381041
If one can not confer upon another a right which he does not himself first possess, by what means does the state derive the right to engage in behaviors from which the public is prohibited? Is there any process, procedure or ritual through which an immoral action can be legitimately transformed into a moral one with out changing the character of the action itself?
Cryddit
Legendary
*
Offline Offline

Activity: 840


View Profile
November 22, 2013, 06:39:45 PM
 #297

A thought occurred to me this morning.  Why are the blocks structured in such a way that you can tell in the first place which txins and txouts go with which transactions?  By the time the block is found most peers have already seen the transactions that the block is composed of.  We need a list of transactions, a list of txins, and a list of txouts.  There's no need to give information in the block about which txins and txouts go with which transactions.

Those who have seen the transactions already know. So they can still check everything they've seen in the block.  And the block structure doesn't need to make it easy to reconstruct the individual transactions. After the fact people can still check validity by treating a block the same way they treat a transaction now.

That makes coinjoin completely superfluous. And free.  And the default for all transactions.


Of course it's a hard fork. But it's worth it.
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2352



View Profile
November 22, 2013, 06:48:44 PM
 #298

A thought occurred to me this morning.  Why are the blocks structured in such a way that you can tell in the first place which txins and txouts go with which transactions?  By the time the block is found most peers have already seen the transactions that the block is composed of.  We need a list of transactions, a list of txins, and a list of txouts.  There's no need to give information in the block about which txins and txouts go with which transactions.

Those who have seen the transactions already know. So they can still check everything they've seen in the block.  And the block structure doesn't need to make it easy to reconstruct the individual transactions. After the fact people can still check validity by treating a block the same way they treat a transaction now.

That makes coinjoin completely superfluous. And free.  And the default for all transactions.


Of course it's a hard fork. But it's worth it.

I've often wondered about variations along this line myself ... and also if some kind of homomorphic encryption might used to conceal tx details completely and yet still have verifiable blocks ?

gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2268



View Profile
November 22, 2013, 07:31:47 PM
 #299

I've often wondered about variations along this line myself ... and also if some kind of homomorphic encryption might used to conceal tx details completely and yet still have verifiable blocks ?
Adam had a whole thread on encrypted transactions. Though without compact zero knoweldge proofs (like the stuff I discussed in the coinwitness thread) it's hard to make them not super brittle and inefficient, because anyone you pay has to receive and validate the whole decrypted history of a coin, since it can't be validated without the history.

If you had a zero knowledge proof that the transaction was valid (e.g. that all the outputs and inputs added up) which the network checked then you could accept the coin without re-verifying the history and, importantly, without revealing the history to the recipients. The trick is finding a system for zero knoweldge proofs which is powerful enough to prove the right things but fast and low bandwidth enough to actually use which doesn't have annoying limitations like requiring a trusted initialization.

Bitcoin will not be compromised
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2352



View Profile
November 23, 2013, 05:51:31 AM
 #300

I've often wondered about variations along this line myself ... and also if some kind of homomorphic encryption might used to conceal tx details completely and yet still have verifiable blocks ?
Adam had a whole thread on encrypted transactions. Though without compact zero knowledge proofs (like the stuff I discussed in the coinwitness thread) it's hard to make them not super brittle and inefficient, because anyone you pay has to receive and validate the whole decrypted history of a coin, since it can't be validated without the history.

If you had a zero knowledge proof that the transaction was valid (e.g. that all the outputs and inputs added up) which the network checked then you could accept the coin without re-verifying the history and, importantly, without revealing the history to the recipients. The trick is finding a system for zero knowledge proofs which is powerful enough to prove the right things but fast and low bandwidth enough to actually use which doesn't have annoying limitations like requiring a trusted initialization.

Thanks ... guess we'll keep searching for that trick.

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!