Damus
jb55 · 105w
brainstorming opcodes that could enable non-interactive collaborative transactions. imagine if anyone could batch a bunch of mempool transactions together for coinjoins. with op_txhash you commit to y...
waxwing profile picture
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.

611โค๏ธ10๐Ÿค™8๐Ÿš€3โšก1๐Ÿ‘€1๐Ÿ‘1
jb55 · 105w
Wow this is great, thanks! I have some research to catch up on ๐Ÿง
Maria2000 · 105w
I'm a non techy user, but i'm excited to see you devs talking about this, lets go!
joe · 105w
We're lucky to have you on our side.
techfeudalist · 105w
Please explain how covenants help solve scalability. Iโ€™m wondering how these proposals address the uncertainty of fees. It seems to me that restricting payments to a particular address assumes that the transaction can be actually made or that fees are negligible. With fees growing, would it be...
waxwing · 105w
In case people were curious about SNICKER but it wasn't easily discoverable: https://gist.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79
nostrich · 105w
"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" These are the only changes that are required. Make it work as sound money. The rest goes off-chain