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 <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.

Okay, so this is the latest CSFS draft. I still had in mind the O'Connor's FS'17
paper where it was <signature> <message> <pubkey> with sig-first as a stack order,
as example. Fwiw, what matters is that you can freely sign a <message>, 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 <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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/b9a11745-4e5e-45f7-8036-f27b8d401ff5n%40googlegroups.com.