waxwing on Nostr: FWIW there have been a number of thoughts over the years in this general area. I came ...

FWIW there have been a number of thoughts over the years in this general area. I came up with SNICKER in 2017, there's a draft BIP on my gist (AdamISZ), not sure why it was never assigned a number. I actually even implemented it in Joinmarket and the code is still there. SNICKER was the simplest way you could do a coinjoin non-interactively (post encrypted proposals, encrypted to an onchain address pubkey; works better with taproot but can work anyway), this way proposer puts the encrypted blob on a bulletin board half-signed and the receiver can decrypt and broadcast it if they choose. Realistically only 2 party so a very limited model but imho still interesting.

Earlier than that people had ideas around SIGHASH_SINGLE|ACP ... but then always gave up on that because of the index/positioning limitations of *SINGLE.

Somewhat later in 2018 a group of us in London brainstormed around ideas like "stuff floats in the mempool and gets coordinated, perhaps with miner involvement" but it hasn't got anywhere yet. In that same meeting we came up with payjoin (well that was my name; others called in P2endpoint, which is a slightly different idea), not actually novel but just tried to pin down more exactly how it could work. that is also in Joinmarket btw, as well as btcpayserver. Nowadays Dan Gould has worked on a different aspect/version of that idea, which is great. But I still like SNICKER's pure non-interactivity.

When it comes to your thoughts around covenants, I agree. I tried to make case in the last Adopting Bitcoin that we need to understand that that extra bit of power in scripting is going to be needed to make actual steps forward in scalability and privacy, in other words it's not because we want evm style smart contracting, it's because we want bitcoin to actually work as money, and that means it needs both scale and privacy, which will come from offchain contracting (though a little onchain contracting, coinjoin style, will imo always be needed too, for larger entities).

So yeah being able to constrain spending destinations as a way to reduce the coordination requirement of a coinjoin is quite a neat thought, i don't remember offhand if anyone has pursued that yet; it's probably not simple!

Lastly I'd say nothingmuch has been having some of the most interesting ideas about coinjoin coordination recently, but not sure if he's active here nowadays.