From: Antoine Riard <antoine.riard@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] "Recursive covenant" with CTV and CSFS
Date: Mon, 10 Mar 2025 15:36:39 -0700 (PDT) [thread overview]
Message-ID: <b9a11745-4e5e-45f7-8036-f27b8d401ff5n@googlegroups.com> (raw)
In-Reply-To: <Z8tiNcjdsRKvekp4@erisian.com.au>
[-- Attachment #1.1: Type: text/plain, Size: 5597 bytes --]
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.
[-- Attachment #1.2: Type: text/html, Size: 7440 bytes --]
next prev parent reply other threads:[~2025-03-10 22:39 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-05 0:01 Anthony Towns
2025-03-05 6:14 ` Olaoluwa Osuntokun
2025-03-05 16:14 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-03-06 17:17 ` Greg Sanders
2025-03-06 18:36 ` 'moonsettler' via Bitcoin Development Mailing List
2025-03-06 21:26 ` Antoine Riard
2025-03-07 21:36 ` Anthony Towns
2025-03-07 21:01 ` Anthony Towns
2025-03-08 15:55 ` James O'Beirne
2025-03-05 17:53 ` 'moonsettler' via Bitcoin Development Mailing List
2025-03-05 22:46 ` Antoine Riard
2025-03-07 21:16 ` Anthony Towns
2025-03-10 22:36 ` Antoine Riard [this message]
2025-03-10 5:14 ` Nadav Ivgi
2025-03-12 3:48 ` Anthony Towns
2025-03-12 10:02 ` Nadav Ivgi
2025-03-12 16:15 ` Nadav Ivgi
2025-03-14 3:20 ` Anthony Towns
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b9a11745-4e5e-45f7-8036-f27b8d401ff5n@googlegroups.com \
--to=antoine.riard@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox