Hi AJ, > 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. I think your reasoning point out exactly what is the "unknown" part of such tx-withholding risk in bitcoin, and what Gleb never formalized further in the bitmex blog or his email on costless bribes to miner, as far as I know. Namely "If you have that level of trust anyway", which I'm understanding that we're putting here in the shoes of the attacker to evaluate a tx-withhold attacks _cost_. Generally, when we evaluate a threat model (e.g for internet DDoS) we'll have few notions like a goal (e.g DoS a Minecraft server), knowledge (e.g know-how on do to the most efficient DDoS) and capabilities (e.g number of botnet available to reach a DoS threshold), all 3 elements combined in an attack scenario. Here, if we reason by analogy to mount a tx-withholding attack as an attacker, we'll have a goal, i.e censor a LN commitment-tx, a knowledge, i.e txid of the commitment transaction to be withheld and inner know-how of the LN protocol and about capabilities i.e DLC oracles available and what can be paid as bribing on-chain fees (to simplify, let's say on-chain fees == off-chain fees). Now, in this tx-withholding attack, we can consider that the attacker capabilities are constituted, among others, of the number of trusted oracles available to release DLC payment signing the equivalent of a "proof-of-target-UTXO-mining" for a tx-withholding "bribing" contract. And that's where your remark on "If you have that level of trust anyway" is pertinent, I think as this underscores the _accumulation cost_ for an attacker to build _trust_ in the given DLC oracles that will be used for a tx-withhold attack. Accumulation or acquisition cost of a Sybil node is a metric considered in the litterature about Sybil attacks. Now, and this where is the crux of my interrogation, by extending the expressivity of bitcoin script and removing the necessity to use an off-chain twist, are we slashing the _accumulation_ cost for a tx-withholding attack ? An attacker could from now on just rely on the "blockchain-as-a-judge" paradigm, which is the one explained in the LN paper iirc and attacks become far more practical. If you have another methodology to evaluate such tx-censorship risk, I'm of course curious...The bitmex blog post have also a recension of the literature in Ethereum analyzing HTLC-attacks, among fews. > It's 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. Okay, so this is the latest CSFS draft. I still had in mind the O'Connor's FS'17 paper where it was with sig-first as a stack order, as example. Fwiw, what matters is that you can freely sign a , which is not iself the implicit signature digest, though exact code matters to analyze opcode composability, of course. Best, Antoine OTS hash: 2e731833f7408e21832605e904e5db0cb21d29a453fbb1cd232eb6c766441f2a Le vendredi 7 mars 2025 à 21:27:01 UTC, Anthony Towns a écrit : > 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 > > It's 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 bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/b9a11745-4e5e-45f7-8036-f27b8d401ff5n%40googlegroups.com.