2 of 3 and 2 of 2 anonymity set

[AdamISZ]

In cooperative case we have paths (wallet)-> p2sh 2 of 2 -> (other wallet). This "hides" in the anonymity set of all 2 of 2 addresses (with huge caveat of timing and amount correlation, set that aside for now).

However, the anonymity set of all multisig p2sh, in particular 2 of 3 + 2 of 2, is much bigger, and there is no reason to use it, since the third key can just be a dummy NUMS key (thus ensuring that neither party can get hold of a majority themselves). 3 of 3 could also be included of course.

Rough plan:

• Gather data on statistical distribution of 2/2, 2/3, others.
• Add configuration to use one or other or, default, follow stat. distn above.
• Change the CoinSwapTX01 template object to allow configuration of number of keys
• Create routines to inject NUMS keys
• Change CoinSwapPublicParameters to allow this
• Pay careful attention to key ordering; make it lexicographical for maximum flexibility and hiding (i.e. I believe a lot of code uses lexicographical ordering already and it's simplest)
• Change CoinSwapTX01 signing code to handle it properly.

Note that I believe it's pointless to modify CoinSwapTX23 code, since they by nature immediately expose the coinswap behaviour in the backout case. It may not hurt though, will review.

This is not added to testnet milestone, but first mainnet milestone, I think it is quite a necessary feature and worth doing, although it'll take a bit of work.

[chris-belcher]

If NUMS numbers are used that anyone can calculate, then someone could scan the entire blockchain looking for these NUMS numbers (unless I've misunderstood) and from there figure out which transactions are coinswaps. We don't want that.

An alternative way might be that Alice and Carol each produce 16 random bytes which are concat'd together to make 32 bytes of random pubkey which neither side knows the privkey for.

[AdamISZ]

Yes the general NUMS approach is no good unless it's somehow parametrized so that it's distinct for each case. Thanks for that correction.

In multisig redeem, you publish the N pubkeys and as I recall, the algorithm goes through each one in sequence and attempts to verify the signature. I had an experience in which someone else had provided an invalid pubkey (in a 2 of 3 setup), and even though we weren't redeeming from that pubkey, nevertheless it didn't pass Isstandard checks (I think), as of something like nov 2015 it was no longer allowed to have invalid pubkeys.

The above can be checked but if it's true we can't make nonsense pubkeys. We could just add pubkeys from each side (aG + bG = P), then both sides are defended as long as they don't share a/b. No I don't think that works, this is almost certainly the ECDH setup that we want: A=aG, B=bG, alice passes A, carol passes B, both sides then have shared pubkey abG which is known to be a valid pubkey but neither side possesses its private key.

[AdamISZ]

Otoh maybe your "16 bytes each" approach is fine; one could just increment the value +1 until it became a valid pubkey (if it wasn't already; you have a ~ 50% chance that a random 32 byte val is a pubkey). Tbh just want to choose whatever method is the least trouble to code and doesn't require any thinking to be secure.