Topic: CoinJoin: Bitcoin privacy for the real world - page 34. (Read 294649 times)

What about adding this into server based clients with matching via the server? (Electrum, Blockchain.info, Mycelium...)

I've realised that bitprivacy owes a lot to the original CoinJoin concept, and updated the github page appropriately.

When/if I get time I'll work on making it "just work".

Can't MIT licensed wallets be relicensed under the AGPL?

The AGPL says that the user is allowed to access the source code; even while interacting with a remote server.

The remote server should not be directly connected to a live wallet anyway.

This is explained in the CoinWitness post, it's as secure as you wish to make it. It's also offtopic. Please stay on-topic and if you want to talk about that please post in that thread.

After further thought off-chain transactions with CoinWitness is insecure, i.e. bringing off-chain transaction back on to the blockchain at par is insecure. How can we be sure there wasn't a double-spend?

This is analogous to trying to operate multiple blockchains with a fixed value between them.

If coins are allowed to be moved between blockchains at par (no market exchange variance) and the blockchains don't exchange coins at par with any blockchains that don't adhere, the problem remains that 50% attacking the blockchain with the lowest PoW difficulty will infect with ill effects the blockchains with higher PoW difficulty.

Precisely, the political debate is moot. Because the technology is economically superior and demands this solution, it is inevitable. In fact, I would not be surprised to see a successful CoinJoin functionality implemented in an alternate client before the end of the year, e.g. as coderrr's coin selection patch was. And this will only be Gen 0 for anonymising tools ...

The modern State needs to abandon their utopian panopticon matrix ambitions and go back to doing proportional policing relevant to a free society, for many reasons too numerous to mention.

Besides, this is a Development & Technical section ... suffice it to say, CoinJoin and other anonymising tools are inevitable ... just like Judgement Day.

Please keep posts on-topic. I'm going to start splitting non-coinjoin discussions out of this thread.

And even there may be a solution to this 51% attack that enables the miners spending the coins. We keep a merkel hash of these signatures forever, so the spenders (or bitarchive.org ... does it exist?) can keep copies of the signatures and later prove if the miners have cheated. This would serve for rebuilding the blockchain manually, because with a 51% attack, the Bitcoin world is fubar anyway.

They can't even be distinguished. Short of a complete lockdown (and a total failure of the system) there is no way to block the activity or even reliably measure how much of it is going on.

I don't think this actually presents much concern to authorities— they manage to survive in a world where cash and other asset transfers leaves few records already.  When tax authorities question you to make sure you're paying your taxes, they'll ask to see your books same way it works with anything else... and nothing in this thread will protect someone there, at least in the US the responsibility is on the taxpayer to show they paid their taxes.  But in any case, the political debate is moot... just due to the technological inevitability of this: I've tried to think of a way to prevent it, and I cannot.

I sold bitcoins today to a forex trader, and we had a long discussion about Bitcoin and the effects it could have on global finance.

At one point in the conversation I brought up CoinJoin and what it makes possible and his immediate reaction was, "That will have to be stopped."

I replied, "What is the US government going to do; tell Chinese, European, and Russian bitcoin miners what transactions they are and are not allowed to include in blocks?"

When I said that his eyes widened and his facial expressions had "Oh, shit" written all over it.

I rather enjoyed that part of the conversation.

I think maybe I am the one teaching you Bitcoin 101 here... (yes I know you are a Bitcoin core dev and all due respect is accorded to you)


I don't know why you mention Sybil attacks, since miner reputation is irrelevant.

The attacker must have 51% of the difficulty to be dishonest in order to cheat against the others who respect the protocol. Miners have an incentive to ignore what does not match the group signature proof, because other miners will ignore them, and they would waste effort doing PoW on a fork that the majority rejects.

That is basic Bitcoin 101 stuff. I think you are conflating the need to verify the transaction chain with my point. The transaction chain must be verified, because it is the way to make sure a more recent spend did not occur.


The miner(s) can not steal anything unless they have 51% of the difficulty as explained above.

Admittedly this is worse than now, where a 51% attack can't spend other people's coins. But if you have a 51% attack, then you've got big problems any way. And as soon as a few coins are misspent, everyone will realize the network is compromised. Just keep the group signature proof in the blockchain long enough for the participants to file a public claim in the media. So lets say 1000 blocks?


Apology I did not make it clear that I wasn't disputing your point about hard fork.


I am saying that N participants (inputs) can make M signatures for outputs, where M >= N. If the total BTC of outputs != total BTC of inputs, then the N participants don't sign their inputs. Reset and try again.

When they don't match, that is a DoS, someone is trying to cheat. I explained upthread how to use divide-n-conquer to isolate the malicious participant(s).

Got it now?

I pushed the beginnings of a framework for a CoinJoin implementation using RSA blinded signature operations. It's written in Python and under the MIT license:

https://github.com/maaku/coinjoin

So far it's a storage layer for the various objects and message involved in the protocol, some simple primitives for the blinding operations, and a few utilities for pulling outputs from JSON-RPC. I'm working on more primitives that I will probably add next week, including tools for creating messages at various stages, and eventually getting this running over BitMessage.

Patches welcome.

This is oftopic, I was trying to avoid the Bitcoin 101 in this thread.

The security model of Bitcoin is that nodes do not trust the network. The network is anonymous parties and could be chalk full of sybils, so we consider it malicious at all times.  We verify _everything_ for ourselves that can be— the one thing that cannot be is transaction ordering.  Because everything is verified the potential for gain in sybil attacking or lying about the ordering is small.  Under what you're suggesting miners could steal arbitrary coins from third parties at the expense of mining a few blocks (whatever depth you require to permit hiding the proof). This isn't the security model we've adopted, and it's one that might unhinge the economic alignment of miners.

As to why it would be a forking change— you want the Bitcoin network to allow the spending of coin based not on the current signature types allowed but on a new ring type.  These transactions would look like theft to the existing network and so they can't be supported without a hardfork to relax the rules.

A ring signature specifies N keys and then provides a signature which could have been provided by any of the N. I may have been misunderstanding what you were suggesting but it sounded like you were saying that a transaction would be signed by a ring signature over its inputs.  This means that without your consent I could take a coin of mine, and a coin of yours, and write a transaction paying to two addresses of mine, and provide a ring signature ... and steal your coin.

If instead you mean that it would also require the individual scalar signatures. Then there is never any reason to have the ring signature in the blockchain, the participants could just perform it externally and sign conditionally on it passing.

If there exists a secure proof (the group signature, plus the spend transactions signed by all participants) that total of inputs match the total of outputs and all peers have agreed on this by accepting the block, then we don't need to keep that proof around in the blockchain. We can just keep the spend transactions to a key and spends from that key to the outputs. This would be a special key that the miner can not spend any other way than to providing the matching secure proof. If you disagree, please kindly explain why and not just assert I am wrong without any explanation. I assume you are correct, but I need to see why? Thank you in advance for helping me to understand.


Yes, but I am explaining how I am thinking we can use the miner to help out in a special way as I have described upthread.


How so? The participants sign to a special key that can't be spent any other way (blockchain will forbid it).


Upthread, I described a divide-n-conquer strategy for identifying the adversarial DoS participant.

I just pulled up the first thing on Google, not sure if it is applicable, Anonymous signcryption in ring signature scheme
over elliptic curve cryptosystem

Thanks for the reply.

No, thats incorrect. Putting ring signatures in transactions would require a hard fork, and under our current security model would require storing the large signature.

Moreover, ring signatures would not be useful in the blockchain. Adam suggested (uh thanks for pointing to that, I missed that post!) using a ring signature for exactly the same purpose that I suggested blind signing: it would be a mechanism external to the blockchain that participants would communicate the set of outputs to each other without identifying the source.  If someone were to try to do what you're suggesting it would enable any of the participants in the transaction to steal the coins. This is exactly the opposite of what we want.

As an aside would you mind adding a link particular ECC ring signature scheme that you're looking at? A reasonably efficient ECC ring signature scheme would be useful to have, and might result in a faster and more compact implementation than the blinded signature approach (esp with many participants). Though I'm not sure how to prevent DOS attacks in such a scheme, since if you get too many outputs you can't tell which party was the cheater, though perhaps some ring signature system would in the event of failure have a way to deanonymize the users so they could determine who produced the extra output.

So if my understanding is correct, a ring signature is comprised of the N public keys and N + 1 large random values (N + 3 for ECDSA), for each signer so (N + 1)^2 plus the N public keys total if each participant is only sending to one output. In practice, they will send to more than one output to hide correlation of input and output amounts.

Yet if my thinking is correct, these large signatures don't need to be stored in the blockchain permanently. This signature only needs to be shown as evidence to all near-term PoW peers for what goes permanently into the blockchain, which are spends for each input to a special public key (which can't spend any other way) which has "spends" corresponding to each output in the signature. So it appears this would require a soft-fork of Bitcoin, because the participants can't send to a normal public key.

Can anyone comment on whether my understanding is correct or not?

Upthread earlier today I proposed a fee for not completing the transaction. I guess you are not proposing that because of timeouts when the participant can't complete but not due to malice?

Thus you propose PoW an a resource cost, hoping this will rate limit.

Hmm. But the rate limiting has to be severe enough that the adversary can't basically shut down transactions (if all are going to be mixed by default which is what I want) entirely, so I am thinking there needs to be a much more severe cost on the adversary.

All costs that fall on the adversary will also fall on the honest participants, but asymmetrically because the adversary will always incur the cost and the participant will only incur it on network timeout.


Send all inputs to one key first.

That has two weaknesses:

1. All transactions must be the same amount.

2. The participants have to be trusted to produce uniformly distributed keys. I think this means it isn't secure?

My prior 4 posts in this thread today before you wrote yours. Ignoring the one about high-latency mix-nets.

Not copied, my own ramblings. Which thread?