Bitcoin Forum
November 03, 2024, 01:18:44 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
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 36 37 38 »
  Print  
Author Topic: CoinJoin: Bitcoin privacy for the real world  (Read 294643 times)
Cryddit
Legendary
*
Offline Offline

Activity: 924
Merit: 1132


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

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 (OP)
Moderator
Legendary
*
expert
Offline Offline

Activity: 4270
Merit: 8805



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

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

Activity: 3430
Merit: 3080



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

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 (OP)
Moderator
Legendary
*
expert
Offline Offline

Activity: 4270
Merit: 8805



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

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

Activity: 279
Merit: 250


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

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: 1722
Merit: 1217



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

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

Activity: 279
Merit: 250


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

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: 2646
Merit: 1137

All paid signature campaigns should be banned.


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

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: 1232
Merit: 1104


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

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: 3430
Merit: 3080



View Profile
November 22, 2013, 02:36:57 PM
 #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.

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: 1722
Merit: 1217



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

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

Activity: 924
Merit: 1132


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

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: 3920
Merit: 2349


Eadem mutata resurgo


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

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 (OP)
Moderator
Legendary
*
expert
Offline Offline

Activity: 4270
Merit: 8805



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

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

Activity: 3920
Merit: 2349


Eadem mutata resurgo


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

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

Activity: 924
Merit: 1132


View Profile
November 23, 2013, 08:35:26 AM
 #296

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 (OP)
Moderator
Legendary
*
expert
Offline Offline

Activity: 4270
Merit: 8805



View Profile WWW
November 23, 2013, 11:33:21 PM
 #297

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

Activity: 2
Merit: 0


View Profile
November 26, 2013, 02:23:11 AM
 #298

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
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1000


View Profile
November 26, 2013, 08:35:05 AM
 #299

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.

https://tlsnotary.org/ Fraud proofing decentralized fiat-Bitcoin trading.
andytoshi
Full Member
***
Offline Offline

Activity: 179
Merit: 151

-


View Profile
December 11, 2013, 05:19:14 AM
 #300

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.
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 36 37 38 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!