The electrum plugin would work by having a sidecar daemon that the plugin sends transaction information to and obtains an unsigned coinjoin transaction. The files are electrum-plugin-daemon.py and electrum-plugin.py, although that branch is probably quite stale.

IMHO, 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.

IMHO, 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.

Interesting. What is the effective 'compression' of doing several individual TX versus a single CoinJoin containing the same TXs?

IMHO, 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.

Interesting. What is the effective 'compression' of doing several individual TX versus a single CoinJoin containing the same TXs?

There's a fair proportion of header/data for single output -> pair of outputs, but mamadmankan is only identifying the first steps in the line of thinking that led to stuff like SegWit and Lightning.

The bounty fund will pay out as funds are available according to the signers best judgment for completed work proposed in this thread that furthers the goal of making improved transaction privacy a practical reality for Bitcoin users.

If JoinMarket did not qualify, and CoinShuffle (or ShuffleCoin?) did not also qualify, what would do it? Does it have to be completely decentralized? Can it be something that relies on a "super-node" or even a third party website, bot or api? (Someone collects possible transactions and makes everyone sign it once a day or once an hour or something.)

How do you define "practical reality for Bitcoin users"?

Did I miss any other attempts at implementing this aside from CoinShuffle and JoinMarket?

The bounty fund will pay out as funds are available according to the signers best judgment for completed work proposed in this thread that furthers the goal of making improved transaction privacy a practical reality for Bitcoin users.

If JoinMarket did not qualify, and CoinShuffle (or ShuffleCoin?) did not also qualify, what would do it? Does it have to be completely decentralized? Can it be something that relies on a "super-node" or even a third party website, bot or api? (Someone collects possible transactions and makes everyone sign it once a day or once an hour or something.)

How do you define "practical reality for Bitcoin users"?

Did I miss any other attempts at implementing this aside from CoinShuffle and JoinMarket?

Coinshuffle is really an enhancement protocol on top of any coinjoin implementation, it's not a coinjoin implementation itself. There hasn't as yet been an implementation using it (correct me if I'm wrong), so from that point of view the question doesn't apply to coinshuffle, although Mycelium are currently working on one.

I have a question: When I am doing a transaction and I send my signed tx to the network. Could someone else take that transaction and add a additional signed input to the tx. So this would mean that my tx gets coinjoined without my approval, would that be accepted by the network?

I have a question: When I am doing a transaction and I send my signed tx to the network. Could someone else take that transaction and add a additional signed input to the tx. So this would mean that my tx gets coinjoined without my approval, would that be accepted by the network?

Greets

From what I understand, that is not possible; or not practical. You'll have to coinjoin your transactions first before sending it to the network.

It may be possible with the replace-with-fee thingie, but if the first transaction gets confirmed, then the second one won't work anymore as it will be a double-spend.

For CoinJoin to work, people need to join their signed tx first. The only way I see this working is some sort of third-party that does the joining, or some app that does it for everyone involved, at the same time, or waiting within a set time.

I think what's happening is people meet up and then agree to do a CoinJoin, either in chat or through some app or website, the third-party not being able to steal any coins in the process.

Effective coinjoin that doesn't create metadata patterns of its own is hard.

If you want the capital-S Solution, the Zerocoin protocol is down the hall - but it wasn't, and won't be, implemented in Bitcoin because the cryptographic accumulator comes with ridiculous compute-time overhead for verifying spends.

If you want a lowercase-s Solution, Dash has its mixing masternodes; some node operator posts a big bond to the block chain to get to be trusted for pooling, and then people run their transactions through a dozen different masternodes that cant see what each other are doing to get them thoroughly mixed before they go on to the block chain. This doesn't suck, but it's also not ideal; those masternodes are "trusted" in the sense that if they cooperate they can de-anonymize transactions.

But coinjoin, in the absence of mixing services (aka masternodes) to join transactions between arbitrary people who've never heard of each other, creates exactly the kind of metadata it seeks to avoid. People analyze the block chain and coinjoined transactions attract attention because they are anomalous in terms of how their inputs and outputs are connected to other tx. When the chain is analyzed further, the snoops can identify which actors know each other and cooperated together to create the coinjoin.

But coinjoin, in the absence of mixing services (aka masternodes) to join transactions between arbitrary people who've never heard of each other, ...

That's the thing. The only missing element is a decentralized version of this. Mixing services that do CoinJoin can exist, I'm just wondering if that qualifies for the bounty here.

The few CoinJoin transactions that exist now can be analyzed, but when the volume and frequency of such transactions get big enough and often enough, it's practically impossible to analyze, especially if all actors are anonymous ...

All that people really need to give up is a little inconvenience, because they have to run their coins through such "masternodes", it's not automatic.

Normal people can send their CoinJoin transactions and their coins to some "masternode" while they sleep. A few hundred people to a few thousand people do this and in 8 hours to a day later you don't know who owns what coins. If this is done daily or with other mixers, every day, every month, the whole year ... do we achieve our goal then?

When you have XAB mod G, (where X and G are public) you can find B if you know A, or you can find A if you know B, but you can't find AB, or A, or even B, unless you know the factors of G.

So you can multiply the exponent by a couple of factors and produce a new accumulator - and nobody can tell what the factors were. But later you can undo it, because you know what the factors were. And you can do this even if a dozen other people have since added or removed values to the accumulator, in any order.

In a lot of ways, what the people forming a coinjoin are doing is passing around an accumulator. None of them knows what the others are putting in, but each is able to check the final accumulator and make sure their own input is part of it (ie, their values are still factors of the exponent). And then if they break it down in a different order, at no time does it acquire the same value as it had at any previous state or one easily related to such - but it returns to the same initial state when everybody's value has been taken out of it.

That's sort of a truncated version of what Zerocoin does - but if you work out the details, you might be able to do it without that horrible zero-knowledge signature of knowledge proof. People would only have to verify steps and final result of a single join per block.

The way things are now, snoops looking at the block chain can mostly tell which transactions were made by the same people as other transactions. If they identify a single thing as belonging to a particular person (which is usually easy, because among other things they listen on the network to get the IP addresses where tx originate) then they can generally walk it back and identify every other transaction that person has ever made from that wallet.

People generally don't think this is okay. Even if they're not crooks they don't necessarily want everybody else to know when and where they bought a dirty magazine and some hand lotion - or, you know, bondage gear or any number of other things that are just plain private.

So they look for a way to mix up transactions; store txOuts in the block chain somehow where snoops can't tell which belongs to whom. When a hundred people do a coinjoin, you take a bunch of different transactions, and make them into one giant transaction, with maybe hundreds of different txIns and txOuts - and now the snoops can't tell any more which of the txOuts belongs to whom. If you then open a new wallet and put the txOuts from the coinjoin into it and no txOuts from your old wallet, they'll never be able to link the purchases you made (or payments you received) before the coinjoin with the ones after it. At most they'll be able to tell such-and-such a purchase group of purchases after the coinjoin was made by one of the hundred people who participated in this coinjoin transaction.

But it's dastardly hard to do this in such a way that when you're exchanging messages to set up the coinjoin, you don't give the eavesdropping snoops enough information to suss out which txOuts from the coinjoin belong to whom. Especially since everybody has to be able to verify that the transactions are correct.

So what you try to do is things like Diffie-Hellman key exchange, where you can have two people (or in this case way more than two) find a secret value together (in diffie-hellman a key; in coinjoin a whole transaction) without giving snoops any clues.

This is made harder by the difference between the two use cases. In Diffie-Hellman the parties don't care much what the value winds up being; only that they agree on what it is and nobody who's been listening to them can suss it out. But with coinjoin you care a whole lot about exactly what the value is, because the value you're trying to agree on has to be a valid transaction that does what you want it to do.

So we need things more complicated than just hashes and bit commitments and signatures; we need things like cryptographic accumulators and commutative encryption, which are sort of esoteric and usually really compute expensive.

Somebody figured out a way to do it with a compound-exponential accumulator under a modulus (called the ZeroCoin protocol) but it's ridiculously compute-intensive; it would mean everybody has to spend five minutes or so just checking correctness after each block, and people with 'weak' machines couldn't check those tx at all. I've been wondering about a way to do it using single-exponential accumulators and bit commitments.

Note: An 'accumulator' is a keyed transformation such that

A ==> Encrypt with key1, key2, key3, etc, in any order ==> Decrypt with key1, key2, key3, etc in any order ==> A.

You could use something like that to show that you have one of the keys that went into creating it, without revealing which. That is, assuming you manage to not reveal the key that went into creating it when you encrypt it the first time. Which, if you don't, makes the transaction hard to check....

Is there a difference between a CoinJoin transaction and a regular bitcoin transaction that has many inputs and many outputs? What I mean is, for example, I have a large wallet with 10 different and unconnected unspent bitcoins, in 10 separate addresses. Then since I am the owner of that wallet, I can do a transaction and use those 10 as inputs to a transaction that pays out or sends out bitcoins to 20 different addresses.

What I'm wondering is if there is a fundamental difference between that, and a CoinJoin transaction with 9 other people.

Yes, I've read and re-read the original post and this entire thread, I'm just seeking clarification if I am understanding this correctly.

Is there a difference between a CoinJoin transaction and a regular bitcoin transaction that has many inputs and many outputs? What I mean is, for example, I have a large wallet with 10 different and unconnected unspent bitcoins, in 10 separate addresses. Then since I am the owner of that wallet, I can do a transaction and use those 10 as inputs to a transaction that pays out or sends out bitcoins to 20 different addresses.

What I'm wondering is if there is a fundamental difference between that, and a CoinJoin transaction with 9 other people.

Yes, I've read and re-read the original post and this entire thread, I'm just seeking clarification if I am understanding this correctly.

There's no difference other than that with a coinjoin the inputs are owned by different people whereas with the transaction you made all the inputs were owned by you.

Before coinjoin, you could look at a transaction and be pretty certain that all its inputs were owned by the same wallet. People would use this information to cluster addresses into groups.

After coinjoin that assumption is no longer valid. Multiple parties can cooperate to sign a single transaction where they each own some of the inputs. This makes clustering by ownership harder to do.

Here's an early example:

It looks like gmaxwell owns both input addresses, but he doesn't. He only owns the smaller one.

Is there a difference between a CoinJoin transaction and a regular bitcoin transaction that has many inputs and many outputs? What I mean is, for example, I have a large wallet with 10 different and unconnected unspent bitcoins, in 10 separate addresses. Then since I am the owner of that wallet, I can do a transaction and use those 10 as inputs to a transaction that pays out or sends out bitcoins to 20 different addresses.

What I'm wondering is if there is a fundamental difference between that, and a CoinJoin transaction with 9 other people.

In terms of the bytes that appear in the transaction itself, there is no difference.

The difference is all in what the snoops can infer from the bytes. When you make that transaction you described, the snoops would look at the block chain and say,

Oh, these twenty new addresses were all funded by the same transaction. Therefore all the funding came from the same source (because almost always it's a single source sending money). And since this doesn't look like a purchase (purchases typically have one large output and one much smaller "change" output) it must have been a logistical or bookkeeping movement of coins. So we're going to assume that now all twenty of these new addresses are owned by the same person.

Later on, they'll confirm it if, say, one of those 20 outputs gets spent, and you get a millibitcoin of change, and then later that millibitcoin of change gets spent in the same transaction as another of those 20 outputs, or as change from another of those 20 outputs - they go, Aha, look! This new evidence means that what we thought about the addresses being owned by the same person, is now confirmed! These two txOuts were owned by the same person, and now we can link all the purchases that were made with both of them!

Now consider what happens with a coinjoin. Alice is buying an Anvil, Bob is buying a Book. Carol is buying a Coat, Dave is buying a duck, and so on.... Maybe Zebulon is buying a Zebra, who knows. They do a coinjoin transaction, and there's an output to the blacksmith shop and an output to the bookstore, and an output to the clothier, and also outputs to Alice, Bob, Dave, Carol, and everybody else - and the outputs are all kinds of different sizes instead of just being clearly "payment" and "change."

Superficially, it looks like the same transaction. Some number of inputs, some number of outputs. But the snoops looking at it say, "Oh, all these inputs must have come from the same person, and it doesn't look like a regular purchase, so we'll assume all the outputs are going to the same person too...." except this time they're wrong. They'll pretty quickly figure out (because the way merchants combine the money that they get paid is very obvious) which outputs went to merchants and how much each merchant got. They may be able to backtrace a lot of the unconnected txIns to figure out who owned them before the transaction. But they will never figure out who it was that bought the duck, who it was that bought the book, and who it was that bought the zebra. The best they'll be able to say is, "one of these people whose coins went into the transaction."

And by the same token, even after they figure out which outputs were paid to merchants, they won't know which of those people now have the other outputs, until or unless those other people spend them along with txOuts they can link to that person. Again, best they'll be able to say is "one of these people whose coins went into the transaction."

But this requires that Alice, and Bob, and Carol, and Dave, etc have a way to set up the coinjoin that Eve can't figure out. Even if Eve is one of the people putting coins into the coinjoin and getting coins out, she shouldn't be getting information about what other people are putting in and getting out.

But it's dastardly hard to do this in such a way that when you're exchanging messages to set up the coinjoin, you don't give the eavesdropping snoops enough information to suss out which txOuts from the coinjoin belong to whom. Especially since everybody has to be able to verify that the transactions are correct.

So what you try to do is things like Diffie-Hellman key exchange, where you can have two people (or in this case way more than two) find a secret value together (in diffie-hellman a key; in coinjoin a whole transaction) without giving snoops any clues.

I realise this doesn't fully speak to what you're musing on in that post, but thought it might add to the discussion:

In Joinmarket we use E2E encryption authenticated to the bitcoin pubkeys that the different parties use as inputs to prevent MITM. This prevents a non-participant from learning the linkages.

As to preventing counterparties knowing the linkages, that's discussed in the first post(s) here. There are several ways to do it. The simplest is to have a server that's trusted, obviously suboptimal. You can add blind signing with network-level anonymisation to cut the connection between the proposal and the signing. To achieve the same effect you can use Coinshuffle. But, these two approaches don't address the Sybil problem - if all your counterparties are the same person, they learn the linkages by elimination.

Joinmarket allows one of the participants to act as the central coordinator - called the taker - and so only the taker gets the full defence against others knowing linkages - and so pays for that privilege (albeit in practice the payment is ultra-small). the other participants still get the defence against outside parties knowing the linkage due to the E2E encryption. And the Sybil problem remains; while we have some ideas about making it harder (see e.g. here: https://gist.github.com/AdamISZ/9cbba5e9408d23813ca8 , although there are other ideas/things to be said), we haven't implemented it.

The network level snooping: as where tx broadcasts originate - can be addressed with Tor to some extent. We also have things like randomising which participant broadcasts the transaction (a feature that belcher recently added). But as you mention there's also the issue of where you source the data to verify inputs (e.g. if you use a centralised blockchain API it's decidedly suboptimal).

On the topic of whether a coinjoin is discoverable/watermarkable let's say, I'd say a couple of things: if coinjoins follow an identifiable pattern, it certainly doesn't mean that they're useless; the main effect that a coinjoin output (i.e. equal sized output) is fundamentally indistinguishable from its neighbour coinjoin outputs is still true. That's the main effect we're looking for. The only conceivable negative is that the inputs to such a transaction are marked "This wallet closure is suspicious"; although I think any good "Bitcoin citizen" should prefer to use coinjoins where it's practical, since this is a currency and it's intended to be fungible. I've tried to make most of my recent retail payments with coinjoins.

Wallet closure analysis *is* damaged (severely) by use of coinjoins and that's the intention. Trying to make them invisible (i.e. not have properties distinct from non-coinjoins) seems like a high bar to set, and a moving target. I know Kristov Atlas has been looking into how transaction structures could be standardized to facilitate this; it seems like a hard goal to reach, but worth looking into.