On Wed, Mar 05, 2025 at 02:46:08PM -0800, Antoine Riard wrote: > > I don't believe the existence of a construction like this poses any > > problems in practice, however if there is going to be a push to activate > > BIP 119 in parallel with features that directly undermine its claimed > > motivation, then it would presumably be sensible to at least update > > the BIP text to describe a motivation that would actually be achieved by > > deployment. > I do... > https://gnusha.org/pi/bitcoindev/f594c2f8-d712-48e4-a010-778dd4d0cadb@Spark/ > https://blog.bitmex.com/txwithhold-smart-contracts/
I don't believe being able to pay for censorship on-chain is any more threatening than being able to pay for censorship off-chain. The bitmex blog post there relies on having a trusted oracle to release DLC payments if the target tx wasn't mined. If you have that level of trust anyway, then just putting funds in escrow, having miners register bolt12 invoices with the oracle, and having the oracle make the payments when it's satisfied blocks are sufficiently confirmed has a pretty similar risk profile. > With OP_CHECKSIGFROMSTACK, which is iirc <signature> <pubkey> <message> It's <signature> <message> <pubkey> with pubkey at the top of the stack. https://github.com/bitcoin/bips/blob/master/bip-0348.md The same is also true of both Elements' CSFS and Bitcoin-Cash's CHECKDATASIG. Cheers, aj -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/Z8tiNcjdsRKvekp4%40erisian.com.au.
