Subject: Re: [bitcoindev] "Recursive covenant" with CTV and CSFS

From: Antoine Riard <[email-masked]>
Date: Mon, 10 Mar 2025 15:36:39 -0700 (PDT)

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 [email-masked].
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/b9a11745-4e5e-45f7-8036-f27b8d401ff5n%40googlegroups.com.