path: root/de/60197e1d7b5bf7a1ff9004a42635f342a22f4e

Delivery-date: Mon, 10 Mar 2025 15:39:54 -0700
Received: from mail-yb1-f188.google.com ([209.85.219.188])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC3PT7FYWAMRBL6UXW7AMGQENZRSDEI@googlegroups.com>)
	id 1trlmr-0005gu-Af
	for bitcoindev@gnusha.org; Mon, 10 Mar 2025 15:39:54 -0700
Received: by mail-yb1-f188.google.com with SMTP id 3f1490d57ef6-e5789a8458esf6906407276.2
        for <bitcoindev@gnusha.org>; Mon, 10 Mar 2025 15:39:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1741646387; x=1742251187; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=pJ2TzIxCOT/Zvaxjc+emJzVItlj9xTFSBXA3BGVRDfQ=;
        b=swpiZOO2XbT6fRJRGnOcVhoTh7szBPD3JAZFNcKrXpdHu8xSG+2NW2i+BGp9Cjn2XD
         mWr0sV1N79F2tAPc49SV70GWmhxbi5P5e67gg0sj1Csm6TIm+K+tjwbxKaMqHYQGGV4w
         HhMsvdIusVdI0mKWzrMMnn3cmSmWPXdy8LwfqqPQUqzzkOgIv9v2jig3tZ8pCdTIHhfp
         Uv5kzX3o23SMAc+5/wt5zh5iAiQ9sMLF5M0RuTqK9lwaeyF7UlYD7187R3yBDieBSEQN
         hWtQhggCbIuciRh49i5zrKYi+EdaUb1+xc3pkiP2+vPQm+rCxWYv9nkv8zfcFydPVYqO
         F6Lw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1741646387; x=1742251187; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=pJ2TzIxCOT/Zvaxjc+emJzVItlj9xTFSBXA3BGVRDfQ=;
        b=NVpfcn2M7zY3Qqc13K6Txlb/JrtDb0GWfvc0c2wS47tsBDBF0T5nLHOjrHr8OFuyGX
         eFnpR1wxKW+UAvM2FRzpLEq+g/iAhzdUxknQXjezPqinlYrBy+crWQrEHfLeRmzUa8KE
         gqgPUNC0oSxDqsbFDgMPeY7fm8QTU0pyAoGLePg36zzdRRcAmtUGVb3So2qbxbw+0WEi
         SQSCgNB5IctmlwHBYpj/3rps70si5+y1c3sl1fbTBxFilSYf3PubV68duxxeuNrD3mCu
         TvH0oJv/MCdeujVCnJTcHqJgootIZ96Abq1+dOrMotIdWdnshC2CA3r8DXR9Dslg9idB
         TpMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1741646387; x=1742251187;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=pJ2TzIxCOT/Zvaxjc+emJzVItlj9xTFSBXA3BGVRDfQ=;
        b=kZRhChVFLLlpY0L+AjLoWxMjAWimrCU4FtL3xW8Tt8Kj2oQ6b95u8RLTlSZ+WPbz36
         naXQ7/4XYb874xOL7Bk2XBHYHEVEKiMrBRG+3L1FTk0GxfiDG2FmnXTkmA/haZq6DJpx
         oRDGlytt1EZMWpz3ovWxcS74t7CkULOOqJxmVKTt+oxzgGPjsHLzbvI1hmbCpMSsBRG7
         o0p5gYeTni4qFmu8J8j9BiI8F9ic3yPZe0A4jfiKacXFjC+XlDRj/8FstU03URPd3m20
         Czbh5P7DGxqxyws0WdL8Ymprk6GyJy0xm0sQ64Qv8IyQL23ZrFtUELr65WjXyGKMjtEr
         aW8Q==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCUn7u04f5wkVy/BIOIRFDexy6Ir0LxYGxw+JkU/HiAO7kVQz8W75D/Q0PtxPVCBI6IZzHRNzZ+DOmha@gnusha.org
X-Gm-Message-State: AOJu0Yw6t8NloSgeSyjBXoKKw/pGakKCpKW5FqbDSH0cBAVVwbAATIXH
	T7zu+dZhlTXoxSPcz9WGMrQXqbSPcfDK2efe+mhCMVMATWINIP8J
X-Google-Smtp-Source: AGHT+IHxaD2yM9hdY+r5E/aFvKaywWbowHLt1h3xZCtnf2nipr0t8lRYoldJh1LYrTAPesPzIOBjig==
X-Received: by 2002:a05:6902:1706:b0:e60:8da5:1195 with SMTP id 3f1490d57ef6-e635c2fdb0dmr23880574276.49.1741646387132;
        Mon, 10 Mar 2025 15:39:47 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVHD6IN5pHBeZBoc0mgaQeuLXoAcAgGMSQMHu9L9wRrzag==
Received: by 2002:a25:6d89:0:b0:e63:4a11:a984 with SMTP id 3f1490d57ef6-e634a11a9d1ls324723276.0.-pod-prod-02-us;
 Mon, 10 Mar 2025 15:39:42 -0700 (PDT)
X-Received: by 2002:a05:690c:6f8d:b0:6ef:8dd0:fff9 with SMTP id 00721157ae682-6ff091abc2cmr22713557b3.8.1741646382654;
        Mon, 10 Mar 2025 15:39:42 -0700 (PDT)
Received: by 2002:a05:690c:b87:b0:6fb:b341:b6f6 with SMTP id 00721157ae682-6fda2c0e805ms7b3;
        Mon, 10 Mar 2025 15:36:40 -0700 (PDT)
X-Received: by 2002:a05:690c:46c9:b0:6fd:41d5:de11 with SMTP id 00721157ae682-6febf3836e2mr208772947b3.23.1741646199766;
        Mon, 10 Mar 2025 15:36:39 -0700 (PDT)
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"
X-Original-Sender: antoine.riard@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

------=_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--