Delivery-date: Mon, 10 Mar 2025 15:39:54 -0700
Sender: bitcoindev@googlegroups.com
Date: Mon, 10 Mar 2025 15:36:39 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <b9a11745-4e5e-45f7-8036-f27b8d401ff5n@googlegroups.com>
In-Reply-To: <Z8tiNcjdsRKvekp4@erisian.com.au>
References: <Z8eUQCfCWjdivIzn@erisian.com.au>
 <A1uNlgzWNUB3L_ITCAGDB85UhNdcF4GX6zZhkaEFHPmLmQivzXnY7stFGtG8iR_8cmVCxiWklqO9VEN6SqDyO6fMEuN3gJDnDEOIN-60sDE=@protonmail.com>
 <6a9d4eea-51bd-45d8-b839-4ac3cefdbb7en@googlegroups.com>
 <Z8tiNcjdsRKvekp4@erisian.com.au>
Subject: Re: [bitcoindev] "Recursive covenant" with CTV and CSFS
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_2186_356374430.1741646199306"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_2186_356374430.1741646199306
Content-Type: multipart/alternative; 
	boundary="----=_Part_2187_822098122.1741646199306"

------=_Part_2187_822098122.1741646199306
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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.
>=20
> 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=
=20
the
bitmex blog or his email on costless bribes to miner, as far as I know.=20
Namely
"If you have that level of trust anyway", which I'm understanding that we'r=
e
putting here in the shoes of the attacker to evaluate a tx-withhold attacks=
=20
_cost_.

Generally, when we evaluate a threat model (e.g for internet DDoS) we'll=20
have
few notions like a goal (e.g DoS a Minecraft server), knowledge (e.g=20
know-how
on do to the most efficient DDoS) and capabilities (e.g number of botnet=20
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=20
attacker,
we'll have a goal, i.e censor a LN commitment-tx, a knowledge, i.e txid of=
=20
the
commitment transaction to be withheld and inner know-how of the LN protocol=
=20
and
about capabilities i.e DLC oracles available and what can be paid as bribin=
g
on-chain fees (to simplify, let's say on-chain fees =3D=3D off-chain fees).

Now, in this tx-withholding attack, we can consider that the attacker=20
capabilities
are constituted, among others, of the number of trusted oracles available=
=20
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=20
attacker
to build _trust_ in the given DLC oracles that will be used for a=20
tx-withhold
attack. Accumulation or acquisition cost of a Sybil node is a metric=20
considered
in the litterature about Sybil attacks.

Now, and this where is the crux of my interrogation, by extending the=20
expressivity
of bitcoin script and removing the necessity to use an off-chain twist, are=
=20
we
slashing the _accumulation_ cost for a tx-withholding attack ? An attacker=
=20
could
from now on just rely on the "blockchain-as-a-judge" paradigm, which is the=
=20
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=20
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=20
CHECKDATASIG.

Okay, so this is the latest CSFS draft. I still had in mind the O'Connor's=
=20
FS'17
paper where it was <signature> <message> <pubkey> with sig-first as a stack=
=20
order,
as example. Fwiw, what matters is that you can freely sign a <message>,=20
which is
not iself the implicit signature digest, though exact code matters to=20
analyze=20
opcode composability, of course.

Best,
Antoine
OTS hash: 2e731833f7408e21832605e904e5db0cb21d29a453fbb1cd232eb6c766441f2a

Le vendredi 7 mars 2025 =C3=A0 21:27:01 UTC, Anthony Towns a =C3=A9crit :

> 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=
=20
> > > problems in practice, however if there is going to be a push to=20
> activate=20
> > > BIP 119 in parallel with features that directly undermine its claimed=
=20
> > > motivation, then it would presumably be sensible to at least update=
=20
> > > the BIP text to describe a motivation that would actually be achieved=
=20
> by=20
> > > deployment.=20
> > I do...
> >=20
> https://gnusha.org/pi/bitcoindev/f594c2f8-d712-48e4-a010-778dd4d0cadb@Spa=
rk/
> > 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=20
> CHECKDATASIG.
>
> Cheers,
> aj
>

--=20
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 e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
b9a11745-4e5e-45f7-8036-f27b8d401ff5n%40googlegroups.com.

------=_Part_2187_822098122.1741646199306
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi AJ,<br /><br />&gt; I don't believe being able to pay for censorship on-=
chain is any more<br />&gt; threatening than being able to pay for censorsh=
ip off-chain.<br />&gt; <br />&gt; The bitmex blog post there relies on hav=
ing a trusted oracle to release<br />&gt; DLC payments if the target tx was=
n't mined. If you have that level of<br />&gt; trust anyway, then just putt=
ing funds in escrow, having miners register<br />&gt; bolt12 invoices with =
the oracle, and having the oracle make the payments<br />&gt; when it's sat=
isfied blocks are sufficiently confirmed has a pretty<br />&gt; similar ris=
k profile.<br /><br />I think your reasoning point out exactly what is the =
"unknown" part of such<br />tx-withholding risk in bitcoin, and what Gleb n=
ever formalized further in the<br />bitmex blog or his email on costless br=
ibes to miner, as far as I know. Namely<br />"If you have that level of tru=
st anyway", which I'm understanding that we're<br />putting here in the sho=
es of the attacker to evaluate a tx-withhold attacks _cost_.<br /><br />Gen=
erally, when we evaluate a threat model (e.g for internet DDoS) we'll have<=
br />few notions like a goal (e.g DoS a Minecraft server), knowledge (e.g k=
now-how<br />on do to the most efficient DDoS) and capabilities (e.g number=
 of botnet available<br />to reach a DoS threshold), all 3 elements combine=
d in an attack scenario.<br /><br />Here, if we reason by analogy to mount =
a tx-withholding attack as an attacker,<br />we'll have a goal, i.e censor =
a LN commitment-tx, a knowledge, i.e txid of the<br />commitment transactio=
n to be withheld and inner know-how of the LN protocol and<br />about capab=
ilities i.e DLC oracles available and what can be paid as bribing<br />on-c=
hain fees (to simplify, let's say on-chain fees =3D=3D off-chain fees).<br =
/><br />Now, in this tx-withholding attack, we can consider that the attack=
er capabilities<br />are constituted, among others, of the number of truste=
d oracles available to release<br />DLC payment signing the equivalent of a=
 "proof-of-target-UTXO-mining" for a<br />tx-withholding "bribing" contract=
.<br /><br />And that's where your remark on "If you have that level of tru=
st anyway" is<br />pertinent, I think as this underscores the _accumulation=
 cost_ for an attacker<br />to build _trust_ in the given DLC oracles that =
will be used for a tx-withhold<br />attack. Accumulation or acquisition cos=
t of a Sybil node is a metric considered<br />in the litterature about Sybi=
l attacks.<br /><br />Now, and this where is the crux of my interrogation, =
by extending the expressivity<br />of bitcoin script and removing the neces=
sity to use an off-chain twist, are we<br />slashing the _accumulation_ cos=
t for a tx-withholding attack ? An attacker could<br />from now on just rel=
y on the "blockchain-as-a-judge" paradigm, which is the one<br />explained =
in the LN paper iirc and attacks become far more practical.<br /><br />If y=
ou have another methodology to evaluate such tx-censorship risk, I'm of<br =
/>course curious...The bitmex blog post have also a recension of the litera=
ture<br />in Ethereum analyzing HTLC-attacks, among fews.<br /><br />&gt; I=
t's &lt;signature&gt; &lt;message&gt; &lt;pubkey&gt; with pubkey at the top=
 of the stack.<br />https://github.com/bitcoin/bips/blob/master/bip-0348.md=
<br /><br />&gt; The same is also true of both Elements' CSFS and Bitcoin-C=
ash's CHECKDATASIG.<br /><br />Okay, so this is the latest CSFS draft. I st=
ill had in mind the O'Connor's FS'17<br />paper where it was &lt;signature&=
gt; &lt;message&gt; &lt;pubkey&gt; with sig-first as a stack order,<br />as=
 example. Fwiw, what matters is that you can freely sign a &lt;message&gt;,=
 which is<br />not iself the implicit signature digest, though exact code m=
atters to analyze <br />opcode composability, of course.<br /><br />Best,<b=
r />Antoine<br />OTS hash: 2e731833f7408e21832605e904e5db0cb21d29a453fbb1cd=
232eb6c766441f2a<br /><br /><div class=3D"gmail_quote"><div dir=3D"auto" cl=
ass=3D"gmail_attr">Le vendredi 7 mars 2025 =C3=A0 21:27:01 UTC, Anthony Tow=
ns a =C3=A9crit=C2=A0:<br/></div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-le=
ft: 1ex;">On Wed, Mar 05, 2025 at 02:46:08PM -0800, Antoine Riard wrote:
<br>&gt; &gt; I don&#39;t believe the existence of a construction like this=
 poses any=20
<br>&gt; &gt; problems in practice, however if there is going to be a push =
to activate=20
<br>&gt; &gt; BIP 119 in parallel with features that directly undermine its=
 claimed=20
<br>&gt; &gt; motivation, then it would presumably be sensible to at least =
update=20
<br>&gt; &gt; the BIP text to describe a motivation that would actually be =
achieved by=20
<br>&gt; &gt; deployment.=20
<br>&gt; I do...
<br>&gt; <a href=3D"https://gnusha.org/pi/bitcoindev/f594c2f8-d712-48e4-a01=
0-778dd4d0cadb@Spark/" target=3D"_blank" rel=3D"nofollow" data-saferedirect=
url=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://gnusha.org/pi/bit=
coindev/f594c2f8-d712-48e4-a010-778dd4d0cadb@Spark/&amp;source=3Dgmail&amp;=
ust=3D1741732469476000&amp;usg=3DAOvVaw0CFkhlQcIiEIB-Eg38bNJj">https://gnus=
ha.org/pi/bitcoindev/f594c2f8-d712-48e4-a010-778dd4d0cadb@Spark/</a>
<br>&gt; <a href=3D"https://blog.bitmex.com/txwithhold-smart-contracts/" ta=
rget=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google=
.com/url?hl=3Dfr&amp;q=3Dhttps://blog.bitmex.com/txwithhold-smart-contracts=
/&amp;source=3Dgmail&amp;ust=3D1741732469476000&amp;usg=3DAOvVaw3Ek3yDMLKC_=
Fd_VDrE6WDt">https://blog.bitmex.com/txwithhold-smart-contracts/</a>
<br>
<br>I don&#39;t believe being able to pay for censorship on-chain is any mo=
re
<br>threatening than being able to pay for censorship off-chain.
<br>
<br>The bitmex blog post there relies on having a trusted oracle to release
<br>DLC payments if the target tx wasn&#39;t mined. If you have that level =
of
<br>trust anyway, then just putting funds in escrow, having miners register
<br>bolt12 invoices with the oracle, and having the oracle make the payment=
s
<br>when it&#39;s satisfied blocks are sufficiently confirmed has a pretty
<br>similar risk profile.
<br>
<br>&gt; With OP_CHECKSIGFROMSTACK, which is iirc &lt;signature&gt; &lt;pub=
key&gt; &lt;message&gt;
<br>
<br>It&#39;s &lt;signature&gt; &lt;message&gt; &lt;pubkey&gt; with pubkey a=
t the top of the stack.
<br><a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0348.md" tar=
get=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.=
com/url?hl=3Dfr&amp;q=3Dhttps://github.com/bitcoin/bips/blob/master/bip-034=
8.md&amp;source=3Dgmail&amp;ust=3D1741732469476000&amp;usg=3DAOvVaw2-6DFCgD=
W5XiE1jaPwsN7_">https://github.com/bitcoin/bips/blob/master/bip-0348.md</a>
<br>
<br>The same is also true of both Elements&#39; CSFS and Bitcoin-Cash&#39;s=
 CHECKDATASIG.
<br>
<br>Cheers,
<br>aj
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/b9a11745-4e5e-45f7-8036-f27b8d401ff5n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/b9a11745-4e5e-45f7-8036-f27b8d401ff5n%40googlegroups.com</a>.<br />

------=_Part_2187_822098122.1741646199306--

------=_Part_2186_356374430.1741646199306--