Coordination privacy while maintaining DoS protection - WabiSabi

[MaxHillebrand]

IIRC [forgive me if I butcher this], joinmarket coordinates the CoinJoins in such a way, that a maker provides all inputs and outputs to the taker under the same IRC identity. The taker can verify that for each maker, the sum of inputs is larger than the sum of outputs. Thus if this maker fails to sign, it cannot be because his output was not included, but it is DoS instead. The downside is of course, that the taker can link the inputs and outputs of each maker.

This can be improved by adding a blinded CoinJoin coordination protocol. The original Chaumian Blind Signatures protocol only provides DoS protection for outputs of equal sats value. Thus non-equal change outputs must be attributed to the input registration identity.

This can be further improved by keyed verified anonymous credentials and Petterson commitments, aka WabiSabi. Now every input is presented to the coordinator with a new identity, and every output with a separate identity. However, outputs can only be added, if the coordinator previously verified the registration of a larger input value and issued a credential. This is a verification of honest output registration, and thus if one user fails to sign the transaction, it can be considered a refusal to sign an honest transaction. Thus any non-signing input can be banned in the following round, upholding DoS attribution, while still having a fully private input / output registration.

Pro

• The taker does not know input|input input|output output|output linkage of any maker
• Much higher privacy guarentees for every maker, leading to higher supply of maker liquidity. [maybe at reduced taker liquidity]
• Credentials can be re-issued to other users [internal eCash transfer] Thus making a payment "inside" the CoinJoin. [Receiver doesn't know input of sender; sender doesn't know output of receiver.]

Con

• More signing and verification compute for both maker and taker
• More Tor circuits [can be pre-established] / IRC users
• Heavy crypto, hard to implement, hard to review, additional crypto assumptions

This could be a minimal drop in replacement of only the coordination communication. The transaction structure / amount organization does not have to be changed. However, subset sum can potentially link the change amount to an input cluster, thus any blockchain observer [including the taker] can learn of the link, thus making the private coordination less valuable.

A potential next improvement would be, for the makers and taker to decompose their change output into standard denominations, so to break the on-chain link of those. Since the change amount will be unique to each maker, there might not be enough anonset in each of those denominations.

Standard amounts are low-hamming-weight denominations, those into which any arbitrary input amount can be efficiently decomposed: powers of 2; powers of 3; 1,2,5 series; and sums of those.

A more different conceptual approach would be for the taker to no longer define a single equal denomination for the round, but instead a range of standard denominations. The taker chooses the makers and asks them to provide their inputs, then each of them decompose their input value into standard denomination outputs, based on the other users' input [and output] values. [This can be knapsack, or even a brute force search picking the most optimal] The benefit of this is a substantial block-space savings.

Moving away from the "naive" single equal denomination CoinJoin is of course a big undertaking.

But in any case, adding coordination blinding has stand-alone benefits which would be useful already in today's amount organization. Yet if in the future we want to change the on-chain amounts, the protocol is flexible and general enough to satisfy those use-cases.

IF joinmarket should add coordination blinding, I'd argue WabiSabi is a good choice.

[chris-belcher]

Pro: The taker does not know input|input input|output output|output linkage of any maker

This isn't achieved, because the taker chooses which makers are involved in the coinjoin, so the evil taker could choose just a single maker and figure out its inputs/outputs by elimination. Or if the maker is coded to have a rule "dont sign a 2-party coinjoin" then the evil taker could choose the victim maker plus 3 other makers which are actually controlled by the evil taker, and then also find the victim maker's input/outputs by elimination.

[MaxHillebrand]

That is an interesting nuance, yes.

However, if there is a 1 maker 1 taker CoinJoin, then the maker knows this, and he can calculate that there was no change in privacy against the taker [though a slight improvement against outside observers] If there is only a 2 peer coinjoin, then just get rid of all the crypto, plaintext saves compute and bandwidth. Notice that in this case, the taker has no privacy against the maker either.

I guess the sybil threat vector is always existent, and is reduced with fidelity bonds. [does the maker check the fidelity bond of other makers? or does only the taker check this?]

[chris-belcher]

Fidelity bonds are unrelated to this, they protect again a sybil attacker who runs many makers and which targets a taker. The attack I'm talking about is where the attacker runs a taker and other makers.

[MaxHillebrand]

What if a maker would only participate in rounds with other makers who have long fidelity bonds, would that help?

[chris-belcher]

I guess, it might do, it depends on the design details.

One issue is that then the taker's inputs/outputs are revealed because they're the only ones who don't have an associated fidelity bond, or if they do then it means that now a fidelity bond is required to be a taker, which is bad too.

All this would be for what?

It seems like the maker's privacy from the taker is not a very big problem, these days I think a bigger problem is transaction surveillance companies who mostly do passive attacks like analysing the blockchain, and JoinMarket works by having makers and takers together cooperate to resist that. They don't pretend to be takers in order to try to unmix makers, and there's lots of reasons why not.