CoinJoin: Bitcoin privacy for the real world

[Cryddit]

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?

[1714772556]

1714772556

[1714772556]

1714772556

[1714772556]

1714772556

[1714772556]

1714772556

[gmaxwell]

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.

[Carlton Banks]

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.

[gmaxwell]

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.

[jedunnigan]

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]

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.

[jedunnigan]

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]

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.

[TierNolan]

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.

[Carlton Banks]

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.

[Anon136]

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

[Cryddit]

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]

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]

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.

[marcus_of_augustus]

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.

[Cryddit]

Actually, I already posted that.  https://bitcointalk.org/index.php?topic=314958.0

Using the Benaloh homomorphic encryption system you can check that txins and txouts are equal without knowing anything about their real values.  If you encrypt two bunches of numbers that add up to equal sums using Benaloh, the ciphertexts of those two bunches when interpreted as numbers have equal modular products. 

Actually making the transactions using that system would require more compute power, on the order of an RSA encryption per txout.  But checking it would require very little extra because modular multiplications are nearly as cheap on modern architectures as additions.

This would mean that tx fees have to be an explicit txout of the transaction, but we're talking about a hard fork anyway if we get that far. 

[gmaxwell]

Using the Benaloh homomorphic encryption system you can check that txins and txouts are equal without knowing anything about their real values.  If you encrypt two bunches of numbers that add up to equal sums using Benaloh, the ciphertexts of those two bunches when interpreted as numbers have equal modular products.

But only if they have the same key. This is offtopic for this thread.

[onetimeuser]

CoinJoin's fund is currently worth approx $24,987.90

This seems like more than enough money to fund development of such a feature. Are there any updates to its progress?

[oakpacific]

Brainstorm: is there anyway to make fee payments anonymous as well? I figure that since on one hand some are concerned whether there will be enough unsuspected users to help them hiding the trail, otoh some are concerned about fees, it would be one stone for two birds if we can give some users the opportunity to have their fees paid by those willing, if they choose to do a Coinjoin transaction.

[andytoshi]

Hey guys,

I have written a tool in Rust to make CoinJoining easier to do -- though it still requires creating and passing raw transactions. (I apologize for the weird language choice, but Rust is awesome. The first time the code compiled it worked correctly, that's just how good the static analysis is with this language.) Having said that, I have only done so much testing, so I encourage you guys to download and play with it:

https://github.com/apoelstra/coinjoin

Be aware that testing is perfectly safe -- no matter how badly my code mangles the transaction, any changes to the outputs will invalidate the signatures, so there is no additional risk of money loss from running the program. (On the other hand, make sure you verify every transaction you sign!)

From the README, there are two steps to using the program:

1. All parties who want to coinjoin create a raw transaction using createrawtransaction. They submit these to one individual, who enters them into CoinJoiner by running

./coinjoin-merge-unsigned

Then just copy/paste the transactions in, one on each line, followed by a blank line. The output will be an unsigned merged transaction.

2. This merged transaction is distributed to the original parties, who each sign it. Then they send these back to the individual running CoinJoiner, who merges them by running

./coinjoin-merge-signed

Then just copy/paste the signed transactions in, one on each line, followed by a blank line. The output will be a merged, signed transaction that is ready to be submitted to the bitcoin network.