Bitcoin Forum
June 13, 2021, 04:21:45 PM *
News: Latest Bitcoin Core release: 0.21.1 [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 293622 times)
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1001



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

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.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
1623601305
Hero Member
*
Offline Offline

Posts: 1623601305

View Profile Personal Message (Offline)

Ignore
1623601305
Reply with quote  #2

1623601305
Report to moderator
1623601305
Hero Member
*
Offline Offline

Posts: 1623601305

View Profile Personal Message (Offline)

Ignore
1623601305
Reply with quote  #2

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

Posts: 1623601305

View Profile Personal Message (Offline)

Ignore
1623601305
Reply with quote  #2

1623601305
Report to moderator
1623601305
Hero Member
*
Offline Offline

Posts: 1623601305

View Profile Personal Message (Offline)

Ignore
1623601305
Reply with quote  #2

1623601305
Report to moderator
1623601305
Hero Member
*
Offline Offline

Posts: 1623601305

View Profile Personal Message (Offline)

Ignore
1623601305
Reply with quote  #2

1623601305
Report to moderator
dserrano5
Legendary
*
Offline Offline

Activity: 1960
Merit: 1026



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

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
Merit: 1000

No Maps for These Territories


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

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: 178
Merit: 142

-


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

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
Merit: 1039


View Profile
December 12, 2013, 12:07:56 AM
Last edit: December 12, 2013, 12:48:38 AM by genjix
 #305

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

last paragraph
Rassah
Legendary
*
Offline Offline

Activity: 1680
Merit: 1033



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

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: 1960
Merit: 1026



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

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
Merit: 1033



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

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: 3108
Merit: 2479



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

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
Merit: 1003


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

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
Merit: 1033



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

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
Merit: 1003


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

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: 3108
Merit: 2479



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

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
Merit: 1001



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

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
Merit: 1006



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

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

Activity: 1680
Merit: 1033



View Profile WWW
December 13, 2013, 06:57:04 AM
 #316

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?

I think they already have. Their default bitcoin transactions send change to new addresses, as does their CoinJoin.

I'm only using blockchain.info's coinjoin it to offload and split up my larger bitcoin purchases into cold storage. Hopefully it was sufficient enough for the last few deposits I made.

justusranvier
Legendary
*
Offline Offline

Activity: 1400
Merit: 1006



View Profile
December 13, 2013, 08:19:02 AM
 #317

Their default bitcoin transactions send change to new addresses, as does their CoinJoin.
When did that happen? That's a major change that deserves a large announcement. Are they using BIP32 to derive the new addresses?
TierNolan
Legendary
*
Offline Offline

Activity: 1232
Merit: 1006


View Profile
December 13, 2013, 11:44:22 AM
 #318

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 need to agree on a common amount.

Inputs (5, 2, 3.5)
Outputs
2
2
2
3 (your change)
1.5 (change for the 3.5 BTC guy)

You get one of the 2 BTC coins and your 3 BTC change coin.  Your software would need to remember that the 3 BTC change coin was not mixed, but the 2BTC one was.

In fact, you could split your 3 coin into two 1.5 BTC coins, so it would be slightly mixed.  You would get 2 of the 3 1.5 BTC outputs.

If there was only 2 into the mix, there would generally be two inputs and three outputs, so the guy who paid more gets (unmixed) change.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
phillipsjk
Legendary
*
Offline Offline

Activity: 1008
Merit: 1000

Let the chips fall where they may.


View Profile WWW
December 15, 2013, 09:32:15 PM
 #319

I got into a argument with somebody on IRC in #bitcoin over the suitability of coinjoin transactions for annoymised verifiable e-voting. justanotheruser's argument was that he could always verify that his choice got a "vote". My argument was that since the voters don't share their votes with each other, it is possible to mis-allocate votes without detection (as long as you are not too greedy).

This has implications for "normal" coinjoin transactions as well:
If:
  • There are more than two participants
  • Two or more participants try to send coins to the same address without directly communicating with each other. (This includes trying to send mining fees)
Then:
  • It is possible for a bad actor to misdirect some of those funds for their own purposes.
  • For the attack to work,  the original output must have at least as much funds as any one participant sent.

This works because non-communicating participants can only ever check that their own outputs look correct. One way to mitigate this is to phase out address reuse: which has not yet happened in practice.

James' OpenPGP public key fingerprint: EB14 9E5B F80C 1F2D 3EBE  0A2F B3DE 81FF 7B9D 5160
gmaxwell
Moderator
Legendary
*
expert
Online Online

Activity: 3444
Merit: 5243



View Profile
December 15, 2013, 09:40:32 PM
 #320

Excellent point!

As you note one workaround is don't reuse addresses— always good advice and here it doesn't have to be "phased out" in general but just by participants— but it's always better to be secure even if software is used dumbly.

I can suggest a trivial protocol addition that solves this without making the CJ transactions distinguishable or degrading privacy, but my solutions have some overhead. I'm curious if anyone can come up with a better way of doing it that doesn't have the overhead.

The general idea is that the merging party can just make a list (blindly) mapping their inputs to outputs, give the list to all players, and commit to the list so that all players know they got the same list.

Here is how it works:

The merging party makes a list with an entry for each output in the transaction. The entries have a nonce provided by each user either when they provide their input (or submitted their blindsigned tokens if blind signed tokens are in use). When they ask the users to sign they give the users the list and the users check and see that they are the credited party for every output they think they should be. Because they are just nonces they don't deanonymize users.

But to prevent the merging party from giving a different list to each user they must commit to it. I have two way to accomplish that:

The first is that we could require that a particular index in the outputs pay to an address which commits to the list: The merging party computes a new public key as an existing pubkey plus the H(list)*G, like a pay to contract, and a previously designated output pays to the resulting address. Given the list and original public key, everyone can check that that output commits to the same list. (And if two different users are given different lists, their signatures will not be merge-able since they would have signed different outputs).

(This designed output could belong to the merger or players could volunteer to have their output address placed in the designated position and to instead receive their payment at a pay-to-commit address. This is a little lame though, because it requires that there be at least one player that will tolerate receiving coins at a non-deterministic key.)

The second way to commit that I've come up with is to add an additional round to the protocol where you make a dummy transaction modified so that it won't ever be valid, e.g. using the list hash as an addition vin. Everyone signs this transaction and then only once they've seen this commitment signed by all the inputs will they sign the real transaction.

Needing an extra communications round or a non-deterministic output is kinda weak. Can better be done?
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!