Bitcoin Forum
December 11, 2017, 02:18:47 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [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 269345 times)
Cryddit
Legendary
*
Offline Offline

Activity: 840


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

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

Posts: 1513001927

View Profile Personal Message (Offline)

Ignore
1513001927
Reply with quote  #2

1513001927
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2366



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

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.

Bitcoin will not be compromised
onetimeuser
Newbie
*
Offline Offline

Activity: 2


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

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: 798


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

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: 170

-


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

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

Activity: 1302



View Profile
December 11, 2013, 05:29:22 AM
 #306

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.

Interesting approach.  This has some very nice advantages.  For example, we could add a flag to sendtoaddress that makes it return the unsigned tx hex.  Thus we take advantage of the coin selector built into the node, etc.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
dserrano5
Legendary
*
Offline Offline

Activity: 1848



View Profile
December 11, 2013, 08:53:59 AM
 #307

CoinJoin needs to be nicely implemented in Bitcoin-Qt before any of these ridiculous blacklist proposals take off. So for the next 30 days, I will match donations to the CoinJoin bounty fund (3M8XGFBKwkf7miBzpkU3x2DoWwAVrD1mhk), up to a maximum of 5 BTC.

Way to go!

I'm upping my offer from 0.50 to 0.75 but please tell Pieter to sign his pubkey in the second message of this thread.

Ah, it took some time but he has finally signed it Smiley.

wumpus
Hero Member
*****
qt
Offline Offline

Activity: 812

No Maps for These Territories


View Profile
December 11, 2013, 10:03:55 AM
 #308

Interesting approach.  This has some very nice advantages.  For example, we could add a flag to sendtoaddress that makes it return the unsigned tx hex.  Thus we take advantage of the coin selector built into the node, etc.
It'd also need to mark the inputs as spent so that further transactions don't double-spend.
This could be done using `lockunspent` but these are not saved when bitcoind is restarted.

Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
andytoshi
Full Member
***
Offline Offline

Activity: 170

-


View Profile
December 11, 2013, 04:14:56 PM
 #309

Interesting approach.  This has some very nice advantages.  For example, we could add a flag to sendtoaddress that makes it return the unsigned tx hex.  Thus we take advantage of the coin selector built into the node, etc.
It'd also need to mark the inputs as spent so that further transactions don't double-spend.
This could be done using `lockunspent` but these are not saved when bitcoind is restarted.


If anyone knows how to make JSON-RPC calls through Rust (or C), I'd be able to (a) do my own 'sendtoaddress' equivalent, and (b) check for double-spends, excessive fees, negative fees, etc, and flag these as errors.

Right now I only check things intrinsic to the transactions -- for merge-unsigned, I ensure there are no duplicate inputs; for merge-signed, I ensure that all transactions are identical modulo scriptSigs.

It's not terribly important to do lockunspent -- if somebody double-spends, the coinjoin will be invalid. Presumably they wanted to do the coinjoin, so they've just screwed themselves. So any double-spend blocking is purely a usability feature.
genjix
Legendary
*
expert
Offline Offline

Activity: 1232


View Profile
December 12, 2013, 12:07:56 AM
 #310

https://medium.com/p/7f95a386692f

last paragraph
Rassah
Legendary
*
Offline Offline

Activity: 1680


Director of Bitcoin100


View Profile
December 12, 2013, 07:51:26 AM
 #311

Hey, um, stupid question, and I'm just too drowsy to wrap my head around it, but if I use CounJoin on blockchain.info, where I have one input and one output, and sent 5 BTC through, with 5 BTC coming out on the other end, isn't it still fairly easy to track my 5 BTC,simply because that's the amount that went in and came out?

dserrano5
Legendary
*
Offline Offline

Activity: 1848



View Profile
December 12, 2013, 08:31:00 AM
 #312

if I use CounJoin on blockchain.info, where I have one input and one output

If you only have one input, you're not joining any coins. The point is mixing unspent outputs from several people/addresses so external observers can't figure out where each output has gone.

Rassah
Legendary
*
Offline Offline

Activity: 1680


Director of Bitcoin100


View Profile
December 12, 2013, 07:30:46 PM
 #313

if I use CounJoin on blockchain.info, where I have one input and one output

If you only have one input, you're not joining any coins. The point is mixing unspent outputs from several people/addresses so external observers can't figure out where each output has gone.

I understand, but if we have 3 people, I put in 5BTC, someone else puts in 2BTC, and the third person puts in 3.5BTC, the coins all get broken up into random amounts and go through two stage mix, in the end, we still have 5BTC, 2BTC, and 3.5BTC, just in new addresses. Isn't that fairly easy to track? I know I'm missing something... What is it?

Carlton Banks
Legendary
*
Offline Offline

Activity: 1848



View Profile
December 12, 2013, 08:43:58 PM
 #314

if I use CounJoin on blockchain.info, where I have one input and one output

If you only have one input, you're not joining any coins. The point is mixing unspent outputs from several people/addresses so external observers can't figure out where each output has gone.

I understand, but if we have 3 people, I put in 5BTC, someone else puts in 2BTC, and the third person puts in 3.5BTC, the coins all get broken up into random amounts and go through two stage mix, in the end, we still have 5BTC, 2BTC, and 3.5BTC, just in new addresses. Isn't that fairly easy to track? I know I'm missing something... What is it?

The possibility that you could get 5 BTC sent to more than one address. Also, you could use the system to pay people too. So, you get your 5 BTC sent to 4 adddresess that belong to you, and the small fraction you are paying to someone else goes to their address. To the outside observer, do all 5 addresses belong to the original holder? Do they all belong to someone receiving a total of 5 BTC from the original holder? Or somewhere inbetween? Impossible to tell, and so analysing the transaction leaves you with lots of questions and no answers.

Vires in numeris
maaku
Legendary
*
expert
Offline Offline

Activity: 905


View Profile
December 12, 2013, 08:50:22 PM
 #315

I understand, but if we have 3 people, I put in 5BTC, someone else puts in 2BTC, and the third person puts in 3.5BTC, the coins all get broken up into random amounts and go through two stage mix, in the end, we still have 5BTC, 2BTC, and 3.5BTC, just in new addresses. Isn't that fairly easy to track? I know I'm missing something... What is it?

You don't re-assemble them into the original amounts. Why would you want to do that?

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

Activity: 1680


Director of Bitcoin100


View Profile
December 12, 2013, 08:54:44 PM
 #316

I understand, but if we have 3 people, I put in 5BTC, someone else puts in 2BTC, and the third person puts in 3.5BTC, the coins all get broken up into random amounts and go through two stage mix, in the end, we still have 5BTC, 2BTC, and 3.5BTC, just in new addresses. Isn't that fairly easy to track? I know I'm missing something... What is it?

You don't re-assemble them into the original amounts. Why would you want to do that?

That's what Blockchain.info does. You send from a single address, you give it an amount and a destination address, and it goes through 2+ CoinJoin steps, split up into random amounts from your source address, then after all the steps gets recombined into the amount you sent (minus transaction fee) into your destination address. Basically, it's as if your amount is exploded into random chunks, and then recombined into the same amount. Unless multiple steps involve multiple different coinjoiners, and much of what you get isn't tied to your own bitcoin at all, I'm not sure it's secure.

maaku
Legendary
*
expert
Offline Offline

Activity: 905


View Profile
December 12, 2013, 08:56:31 PM
 #317

Then that's what bc.i does. That's not the protocol described in this thread.

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

Activity: 1848



View Profile
December 12, 2013, 09:28:45 PM
 #318

So yes, blockchain.info has an implementation of CoinJoin, that doesn't do anything much useful. Unless it's configurable to do the job differently, of course.

Vires in numeris
piuk
Hero Member
*****
expert
Offline Offline

Activity: 910



View Profile WWW
December 13, 2013, 12:24:04 AM
 #319

That's what Blockchain.info does. You send from a single address, you give it an amount and a destination address, and it goes through 2+ CoinJoin steps, split up into random amounts from your source address, then after all the steps gets recombined into the amount you sent (minus transaction fee) into your destination address. Basically, it's as if your amount is exploded into random chunks, and then recombined into the same amount. Unless multiple steps involve multiple different coinjoiners, and much of what you get isn't tied to your own bitcoin at all, I'm not sure it's secure.

Assuming you use a single input of the exact size then it will be recombined into the same output value. But the client will deliberately select more inputs than necessary in order to make determining the input value more difficult. The server will also add multiple outputs of the same size as your inputs.

Even if you are restricting outputs to power of two sizes, as in the original coinjoin proposal, the same issue is still a problem. Address A sends 2 * 0.1 BTC + 1 * 1 BTC outputs then Address BTC receives 2 * 0.1 BTC + 1 * 1 BTC soon after it is easy to connect the dots.

Mixing in the background rather than on demand is probably the best way to solve this.

justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
December 13, 2013, 02:25:16 AM
 #320

I don't see how CoinJoin can possibly ever be effective in a situation of address reuse.

Is Blockchain.info ever going to stop doing that?
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!