path: root/8c/15e723eaec227ab0873d15a7090b15936c5fb5

Return-Path: <antoine.riard@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 48C37C0032;
 Wed, 15 Nov 2023 18:14:42 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 15F1F60E44;
 Wed, 15 Nov 2023 18:14:42 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 15F1F60E44
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20230601 header.b=IcAFnE4R
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id XzeuKHSwVO32; Wed, 15 Nov 2023 18:14:40 +0000 (UTC)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com
 [IPv6:2607:f8b0:4864:20::d36])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 7C74060AEE;
 Wed, 15 Nov 2023 18:14:40 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 7C74060AEE
Received: by mail-io1-xd36.google.com with SMTP id
 ca18e2360f4ac-7a67f447bf0so280391139f.2; 
 Wed, 15 Nov 2023 10:14:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1700072079; x=1700676879;
 darn=lists.linuxfoundation.org; 
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=XycwYjxHcXJBAqA3nODYCrgbfKeIDw0dDHZ0CI7DMA0=;
 b=IcAFnE4RAizl1K8Jaaj6vkcU1XPmJBv7bXFnis1jNlb88fRcWwOO138NgDmiRAxwM9
 ZoU03B2e/r4ymJ6rGV9+5tvkEOTla1jtprzPvpR+5iYDvKaaIlJXI1pdSYEIs9zClpyA
 H7ryxeT1xrsAESMKVL9y7zkxrBYe6vjDZrIV/ESy+2kqCERp8CigBTuiTmV9OihjwWK/
 xHvr4ULMF03diGuutkGHBwZE98KP7yvOj9uigUEKQK0R5ORz1ZBRdpx3h+H3QKHLbZHB
 o73LCICcn0/LhJTdUhWehgIJ0Jvr/l8XG1kVx0v0sZKqlqr1lqYB/jr8mT4aeabIDHEr
 vc9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1700072079; x=1700676879;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=XycwYjxHcXJBAqA3nODYCrgbfKeIDw0dDHZ0CI7DMA0=;
 b=ve2O/VKR1YSsjuk4J2CuaRHVPnj8oVZa8OLljcRsp0uKVEGR2iFgmUu1mUJ1EaDjuR
 0Jj6W4bXUwqR9YxwKADKmiek2fd+NNk7OgePydmfLn6DHsD3QhgwP5RiECnwplfntQef
 KrvzPRBmsGv7xtMkXQq0maGAs8VuKurOlTjfDglHfLAvUcVTgg3Yjgs6/qaM2CdO+KMh
 7hHkWimgtxC9HBZvBaa8cBo0ImZ3c/e309ioyHWKDyI7U1kGLZ2sAf1rCTt0oEzCFFDN
 EWfeF/9Jh0TeQuqd8BuR8yCdpP48gUF/o7mkAhngQdkQ2pSDpyu4CNge16dUZlBHowWz
 eMYQ==
X-Gm-Message-State: AOJu0YyJsPwZXXb51N2OzVkYmVaNM7gSA9E2UgkD+eOzzU8KTD87vMOx
 0dW4lLZGe0BP8FQcc7IJrZo2MI5pTAHJjnYAaYmoGvkOUQtthQ==
X-Google-Smtp-Source: AGHT+IGzFJNfdZWc1hw03hIB5JOLm+HKh/8rTNYUmQNWmQiHj93l3jopyA7oqT2Nger6bVvvA8eROUPmo3IRrqAx+f0=
X-Received: by 2002:a05:6602:107:b0:7a9:96aa:e01b with SMTP id
 s7-20020a056602010700b007a996aae01bmr14236801iot.20.1700072079168; Wed, 15
 Nov 2023 10:14:39 -0800 (PST)
MIME-Version: 1.0
References: <CALZpt+HwmacQ9VFu+SfmKms363ZU1xYZe+9o8TsoemTVQLprLg@mail.gmail.com>
In-Reply-To: <CALZpt+HwmacQ9VFu+SfmKms363ZU1xYZe+9o8TsoemTVQLprLg@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Wed, 15 Nov 2023 18:14:28 +0000
Message-ID: <CALZpt+EYjMhS1HsyZfKNXkQkfoUg2zU9OBSC=v7am5eR_rtJew@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, 
 "lightning-dev\\\\@lists.linuxfoundation.org"
 <lightning-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000005f198f060a34e0d3"
X-Mailman-Approved-At: Wed, 15 Nov 2023 19:41:32 +0000
Cc: security@ariard.me
Subject: Re: [bitcoin-dev] On solving pinning,
 replacement cycling and mempool issues for bitcoin second-layers
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Nov 2023 18:14:42 -0000

--0000000000005f198f060a34e0d3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi all,

I think any valid consensus-change based solution to the pinning and
replacement cycling issues for Bitcoin L2s should respect the following
properties / requirements (ideally):
- non-interactive with contribution of your off-chain counterparty
- minimize level of fee-bumping reserve and number of UTXO locked
- block any malicious pinning or replacement cycling as long as you can
compete with ongoing fee rates
- do not make the security of low-value lightning payments conditional on a
probabilistic state of local knowledge of historical mempool
- generalize to N > 2 multi-party off-chain construction
- minimize the witness size by using efficient bitcoin script semantics
- do not give an edge to low-hashrate or coalition of low-hashrate miners
to play fees games with Lightning / L2 nodes
- be composable with a solution to massive force-closure of time-sensitive
off-chain states
- not make it worst things like partial or global mempool partitioning [0]

I think this is already a lot. I had some intuitive solutions aiming to
remove package malleability by using something like the annex and
sighash_anyamount semantic, though after musing on Peter Todd's op_expire
proposal, I wonder if there is not another family of solutions that can be
designed using "moon math" cryptos like short-lived proofs and strictly
enforced sequential time windows.

I don't have any strong design at all, and in any case given the complexity
it would be good to have an end-to-end implementation of any solution, at
the very least see it works well for the Lightning case (chatted with Gleb
out-of-band he's too busy with Erlay for now to research more on those
subjects and on my side bored working more on those issues, sadly I don't
know that many bitcoin, lightning and covenant researchers that understand
that well those problems). I still think pinning and replacement attacks
deserve more real-world mainnet experimentation, under usual
ethical guidelines .

Inviting everyone in the Bitcoin research community to research more on
those pinning, replacement cycling and miners incentives misalignment with
second-layers. Please do so, those issues are serious enough if we wish to
have a reliable fee market in a post-subsidy world and a sustainable
decentralized miner ecosystem in the long-term (well...dumb ordinal
transactions might save the day, though open another wormhole of technical
issues).

Best,
Antoine

[0] See The Ugly scenario here
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/018011.ht=
ml

Le dim. 22 oct. 2023 =C3=A0 03:27, Antoine Riard <antoine.riard@gmail.com> =
a
=C3=A9crit :

> Hi,
>
> I think if Gleb Naumenko and myself allocate our research time on this
> issue, we should (hopefully) be able to come with a strong sustainable fi=
x
> to the lightning network, both systematically solving pinnings and
> replacement cycling attacks (and maybe other mempools issues or things
> related like massive force-closure beyond available blockspace can absorb
> before pre-signed transactions timelocks expiration as mentioned in the
> original paper).
>
> I have not yet probed Gleb's mind on this, though we both studied those
> cross-layer issues together as early as 2019 / 2020, and I think we have
> built an intuitive understanding of the problem-space, with both practica=
l
> experience of bitcoin core and rust-lightning codebases and landmark
> research in this area [0] [1]. If Gleb isn't too busy with Erlay in core,
> I'm sure he'll be enthusiastic to contribute research time at his own pac=
e
> (and I might probe a bit of Elichai Turkel time to verify the maths of al=
l
> sustainable lightning fixes we might propose and the risks models). All
> soft commitments and assuming the interest of the bitcoin community.
>
> One good advantage of long-term sustainable fixes, it should
> (optimistically yet to be demonstrated) lower the fee-bumping reserve val=
ue
> and number of UTXOs lightning users (and maybe bandwidth) have to lock
> continuously to use this worldwide 24 / 7 payment system.
>
> Reopened the issue on coordinated security issues handling in the LN
> ecosystem:
> https://github.com/lightning/bolts/pull/772
>
> While I'll stay focused on solving the above problems at the base-layer
> where they're best solved, at least I'll stay around for a few months
> making transitions with the younger generation of LN devs.
>
> For transparency, I don't have any strong solution design yet at all,
> neither code, conceptual draft or paper ready, and game-theory and nodes
> network processing resources changes will have to be weighted very
> carefully, all under the bitcoin open and responsible process we currentl=
y
> have. Overall, this will take reasonable time (e.g package relay design
> discussions have been started in 2018 and we're only now at the hard
> implementation and review phase) to carry on forward.
>
> Looking forward to hearing thoughts of the Bitcoin and Lightning
> development protocols community.
>
> [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/0=
02569.html
> [1] https://arxiv.org/pdf/2006.01418.pdf
>
> "They who face calamity without wincing, and who offer the most energetic
> resistance, these, be they States or individuals, are the truest heroes".=
 -
> Thucydides.
>

--0000000000005f198f060a34e0d3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi all,</div><div><br></div><div>I think any valid co=
nsensus-change based solution to the pinning and replacement cycling issues=
 for Bitcoin L2s should respect the following properties / requirements (id=
eally):</div><div>- non-interactive with contribution of your off-chain cou=
nterparty</div><div>- minimize level of fee-bumping reserve and number of U=
TXO locked</div><div>- block any malicious pinning or replacement cycling a=
s long as you can compete with ongoing fee rates</div><div>- do not make th=
e security of low-value lightning payments conditional on a probabilistic s=
tate of local knowledge of historical mempool</div><div>- generalize to N &=
gt; 2 multi-party off-chain construction</div><div>- minimize the witness s=
ize by using efficient bitcoin script semantics</div><div>- do not give an =
edge to low-hashrate or coalition of low-hashrate miners to play fees games=
 with Lightning / L2 nodes</div><div>- be composable with a solution to mas=
sive force-closure of time-sensitive off-chain states</div><div>- not make =
it worst things like partial or global mempool partitioning [0]</div><div><=
br></div><div>I think this is already a lot. I had some intuitive solutions=
 aiming to remove package malleability by using something like the annex an=
d sighash_anyamount semantic, though after musing on Peter Todd&#39;s op_ex=
pire proposal, I wonder if there is not another family of solutions that ca=
n be designed using &quot;moon math&quot; cryptos like short-lived proofs a=
nd strictly enforced sequential time windows.=C2=A0</div><div><br></div><di=
v>I don&#39;t have any strong design at all, and in any case given the comp=
lexity it would be good to have an end-to-end implementation of any solutio=
n, at the very least see it works well for the Lightning case (chatted with=
 Gleb out-of-band he&#39;s too busy with Erlay for now to research more on =
those subjects and on my side bored working more on those issues, sadly I d=
on&#39;t know that many bitcoin, lightning and covenant researchers that un=
derstand that well those problems). I still think pinning and replacement a=
ttacks deserve more real-world mainnet experimentation, under usual ethical=
=C2=A0guidelines .</div><div><br></div><div>Inviting everyone in the Bitcoi=
n research community to research more on those pinning, replacement cycling=
 and miners incentives misalignment with second-layers. Please do so, those=
 issues are serious enough if we wish to have a reliable fee market in a po=
st-subsidy world and a sustainable decentralized miner ecosystem in the lon=
g-term (well...dumb ordinal transactions might save the day, though open an=
other wormhole of technical issues).</div><div><br></div><div>Best,</div><d=
iv>Antoine</div><div><br></div><div>[0] See The Ugly scenario here=C2=A0<a =
href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/0=
18011.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-Ju=
ne/018011.html</a></div></div><br><div class=3D"gmail_quote"><div dir=3D"lt=
r" class=3D"gmail_attr">Le=C2=A0dim. 22 oct. 2023 =C3=A0=C2=A003:27, Antoin=
e Riard &lt;<a href=3D"mailto:antoine.riard@gmail.com">antoine.riard@gmail.=
com</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:s=
olid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">=
Hi,<div><br></div><div>I think if Gleb Naumenko and myself allocate our res=
earch time=C2=A0on this issue, we should (hopefully) be able to come with a=
 strong sustainable fix to the lightning network, both systematically=C2=A0=
solving pinnings and replacement cycling attacks (and maybe other=C2=A0memp=
ools issues=C2=A0or things related like massive force-closure beyond availa=
ble blockspace can absorb before pre-signed transactions timelocks expirati=
on as mentioned in the original=C2=A0paper).</div><div><br></div><div>I hav=
e not yet probed Gleb&#39;s mind on this, though we both studied those cros=
s-layer issues together as early as 2019 / 2020, and I think we have built =
an intuitive=C2=A0understanding of the problem-space, with both practical e=
xperience=C2=A0of bitcoin core and rust-lightning codebases and landmark re=
search in this area [0] [1]. If Gleb isn&#39;t too busy with Erlay in core,=
 I&#39;m sure he&#39;ll be enthusiastic to contribute research time at his =
own pace (and I might probe a bit of Elichai Turkel time to verify the math=
s of all sustainable lightning fixes we might propose and the risks models)=
. All soft commitments and assuming=C2=A0the interest of the bitcoin commun=
ity.</div><div><br></div><div>One good advantage of long-term sustainable f=
ixes, it should (optimistically yet to be demonstrated) lower the fee-bumpi=
ng reserve value and number of UTXOs lightning users (and maybe bandwidth) =
have to lock continuously to use this worldwide 24 / 7 payment system.</div=
><div><br></div><div>Reopened the issue on coordinated security issues hand=
ling in the LN ecosystem:</div><div><a href=3D"https://github.com/lightning=
/bolts/pull/772" target=3D"_blank">https://github.com/lightning/bolts/pull/=
772</a><br></div><div><br></div><div>While I&#39;ll stay focused on solving=
 the above problems at the base-layer where they&#39;re best solved, at lea=
st I&#39;ll stay around for a few months making transitions with the younge=
r generation of LN devs.</div><div><br></div><div>For transparency, I don&#=
39;t have any strong solution design yet at all, neither code, conceptual d=
raft or paper ready, and game-theory and nodes network processing resources=
 changes will have to be weighted very carefully, all under the bitcoin ope=
n and responsible process we currently have. Overall, this will take reason=
able time (e.g package relay design discussions have been started in 2018 a=
nd we&#39;re only now at the hard implementation and review phase) to carry=
 on forward.</div><div><br></div><div>Looking forward to hearing thoughts o=
f the Bitcoin and Lightning development protocols community.</div><div><br>=
</div><div>[0] <a href=3D"https://lists.linuxfoundation.org/pipermail/light=
ning-dev/2020-February/002569.html" target=3D"_blank">https://lists.linuxfo=
undation.org/pipermail/lightning-dev/2020-February/002569.html</a></div><di=
v>[1] <a href=3D"https://arxiv.org/pdf/2006.01418.pdf" target=3D"_blank">ht=
tps://arxiv.org/pdf/2006.01418.pdf</a></div><div><br></div><div>&quot;They =
who face calamity without wincing, and who offer the most energetic resista=
nce, these, be they States or individuals, are the truest heroes&quot;. - T=
hucydides.</div></div>
</blockquote></div>

--0000000000005f198f060a34e0d3--