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 your output which creates a link, so you can’t use stacking. maybe its not possible, but fun to think about. Has anyone thought about this? nostr:npub1vadcfln4ugt2h9ruwsuwu5vu5am4xaka7pw6m7axy79aqyhp6u5q9knuu7 nostr:npub1klkk3vrzme455yh9rl2jshq7rc8dpegj3ndf82c3ks2sk40dxt7qulx3vt i’m a complete noob in this area 😅
Discussion
Mmhmm…🤔
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.
Wow this is great, thanks! I have some research to catch up on 🧐
I'm a non techy user, but i'm excited to see you devs talking about this, lets go!
We're lucky to have you on our side.
Protect nostr:npub1vadcfln4ugt2h9ruwsuwu5vu5am4xaka7pw6m7axy79aqyhp6u5q9knuu7 at all costs
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 possible for the payment to be uneconomical? And even if the payment is made, the actual amount received may be less than expected?
Think from the other direction: covenants are useful not just to restrict your own spending, but mainly because you can prove to a counterparty that you cannot spend it any other way. This removes a layer of trust, that currently we can only solve with multisigs, but with that comes a bunch of interactivity requirements.
In case people were curious about SNICKER but it wasn't easily discoverable:
https://gist.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79
Was this BIP ever part of a PR in the github.com/bitcoin/bips repo? Probably would be assigned a number in no time if it were today
coinjoin coordination over nostr relays somehow would be super cool. Also terrifying
There is such a project. https://joinstr.xyz/ ... though i haven't kept up to date with exactly how it's evolving.
Trying to complete the electrum plugin: https://gitlab.com/1440000bytes/joinstr/-/merge_requests/2
