Coinjoin devs!

I have an idea I’m not confident is even possible, but my brain wont let go until somebody explains that it wouldn’t work.

Biggest vulnerability I see is the need of a transaction coordinator. From my admittedly limited view, the mempool also acts as a transaction coordinator of sorts.

So the general idea is we add a bot to operate in parallel with the mempool to gather transactions flagged for coinjoin, all native and with the censorship resistance the btc network provides. The end goal being every bitcoin node is a de facto coinjoin runner.

I really suck with the code so I’m sure there’s issues all around, but felt compelled to at least note the idea

#bitcoin #devs #asknostr #nodes #runbitcoin #programming

Reply to this note

Please Login to reply.

Discussion

It has definitely been discussed before. Before considering the mempool specifically, just the more fundamental idea of using the blockchain itself as a bulletin board, it solves an otherwise incredibly difficult problem of a neutral/uncensorable publishing platform, which is identified in e.g. the Coinshuffle paper as being a/the essential requirement to make a coinjoin coordination protocol that is guaranteed to succeed.

A certain well known bitcoiner proposed roughly what you're saying in 2018, with specifically miners being coordinators. While I and many others didn't like the idea of miners being in charge of such a thing, the obvious issue is that, ultimately, the miners already are and must always be, the coordinators. Whereas with the general censorship resistance property - that if we are concerned about a set of miners blocking a certain transaction, we can always just wait long enough for an independent miner to do the right thing - here, if we are talking about real-time coordination, then miners are just as bad, if not worse, than other types of coordinator in terms of wielding power.

Whether it's mempool or onchain already, in both cases, there is a big issue I think with cost; if negotiation means publishing txs, the cost per message/advertisement is in general really non-trivial. maybe there's ways to get clever about that. By drawing back from using onchain messages to mempool messages, you do make speed possible, but you give up the finality (messages can be equivocated i guess) and it's costly.

Sorry I'm being really vague but then again the proposal is also not concrete :)