waxwing's avatar
waxwing 2 weeks ago
Nothing about the two transactions shown is strange. The first is 2 in 2 out, the second is 1 in, 2 out; normal payments [1]. If you examine their witness you'll see they're like 90% of other taproot transactions, just keypath, no scripts involved. But in fact, this is a bet. Two parties flipped a fair coin for the winnings (a small chunk of the input funds). Not literally; they used cryptography to get an exactly 50% chance of winning without having to trust the other. They were both running signet nodes (in fact I had one on my laptop at home and another on a VPS), and used decoy packets in BIP324 (bitcoin p2p encrypted transport) to communicate, so no one could even know the negotiation was happening (side note: this idea feels like it should be useful in many other contexts, and it's surprisingly easy to set up, with a very simple patch to your bitcoind). So we have a fair bet inside a coinjoin; you could think of it as a randomized payjoin if you like, but, the transfer of funds is not for some goods and services but, just a wager, and it's perfectly fair because of a cryptographic trick that was discussed on delving [2] though it's changed from what was written there. Payments inside coinjoins break subset sum analysis; this is just another kind of payment. Amongst other virtues of such a system is that it creates economic activity between peers without middlemen which is vital to Bitcoin's general pseudonymity. The implementation is at . The repo is currently 95% AI-written so not very readable (still not *unreadable*, but, y'know how it is) but I have a paper that I've nearly finished that is human written and human readable for those interested in the mechanics. [1] In fact those familiar with details of payjoins *will* see something specific about the 1st transaction that makes it like a payjoin. But it isn't hard to remove that, and anyway, it's only a watermark for 'this is a payjoin', not for what it *actually* is... [2]

Replies (8)

waxwing's avatar
waxwing 2 weeks ago
Yes. Guess there's positive and negative here. Traffic shaping etc. vs spam traffic. Does Core have ddos defense against general encrypted noise... just dropping decoys is most of it I guess, but ..?
So, what if JM makers "gambled" their change? Maybe chunks of it? Just a random idea: Could the probabilities be adjusted so that if maker A that "has" 1M sats change and maker B that "has" 3M sats, instead get proportional chances (¼ and ¾ respectively) to win 4M sats? Maybe they're willing to play this game for a expected value of 0 but a positive expected value of privacy gain. I guess it doesn't work with more than 2 participants, but if it did, I'm sure many JM takers would be willing to gamble their change, for either a 10x that makes it worth it to deal with it (toxic change), or just lose it.
waxwing's avatar
waxwing 2 weeks ago
Right. I briefly mention in Section 8 of the paper I just posted, rhat it's likely there are tricks to be played with n party coinjoin here, but indeed N>2 versions are way harder (collusion). Perhaps embed 2 party negot. inside.
waxwing's avatar
waxwing 2 weeks ago
So iow yeah i agree with you. The dusty change thing connects in with lightning probabilistic payments ideas, i guess. I.e. similar motivation.