path: root/fb/f74af33bb504a949e0c4ef028ef2ab211c0267

Return-Path: <antoine.riard@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1D083C0032;
 Sun, 22 Oct 2023 02:27:51 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 001E38516A;
 Sun, 22 Oct 2023 02:27:50 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 001E38516A
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20230601 header.b=j/Z5lDqk
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 smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id J70CrYD1_LVt; Sun, 22 Oct 2023 02:27:49 +0000 (UTC)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com
 [IPv6:2607:f8b0:4864:20::d2b])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 90DAE8515C;
 Sun, 22 Oct 2023 02:27:49 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 90DAE8515C
Received: by mail-io1-xd2b.google.com with SMTP id
 ca18e2360f4ac-7a66a7fc2d4so82385639f.0; 
 Sat, 21 Oct 2023 19:27:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1697941668; x=1698546468;
 darn=lists.linuxfoundation.org; 
 h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject
 :date:message-id:reply-to;
 bh=CSJOYDZdkrsAE0zrwrPL80c4oP2leOiQPYH4VZyZyd4=;
 b=j/Z5lDqkTbnYkbcyMLZVueI8pdsfxYx8cxTjcrPpRz8TiKWK7PgjWOE4Mjnt1p9BbP
 1BjRZMT0Hp24yvw/67VTwxgjVtuCd1YehTs6dZygBL9BkbgPDECxrAsB40ct1T24ZOIY
 No6etc1pUhHH4fQQZpRCBDv7icG1Yy5t68iG2pFXf7FGUlzaZD9LvarnLKj7ZOrhOE4D
 KqJSykOsw7eVjgpOKWPCko2UmtRAOyPnENm2JH7xKllxjY6Smdw17PcApOg8bG/IqInL
 KHTuu1hKsLcDiNw5KhDQJxKSTMYkdfWFQd4AAUd1udEUHg3SU811LfF5qyMg6GMyqdzc
 jYVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1697941668; x=1698546468;
 h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=CSJOYDZdkrsAE0zrwrPL80c4oP2leOiQPYH4VZyZyd4=;
 b=oFtqr85dDasKPYcQ3NUOxk7CdVvPGI9Jy9BsfToPhOeW9zqJoGMXPWyFKLiakc4IFN
 rW6IABhCbIOnP678heTsB09katE35Gq712yETsp4P4jnXUxuL88rqz5K8igpItSKdWJg
 Ima9k7rUW3zdpFvcHBR6bHpackI6CGzRTXYvgsWKK+JMc/CXGjkjQ4Nvh4xxLdwtsumT
 TIKTFXz5d00t6ROwhBupVPlM2IB/hiHYES17unhs68cJawN6iyxrGXcgRxfRS7AIEgwG
 qHk5WnKFUDUq9ZT6bSXOgB5jcCoL0PtZRCzac+tVTlEnLpNS+CZ8AS5BQvcToE2QxTNs
 9TTQ==
X-Gm-Message-State: AOJu0Ywzzbe1SWAncxbsh/YcHidwEkyDqwS8obyVE3ChYiOHtGQDQW3n
 Y5Oc7CR0esVIgDh+JTI5k3Mdl5+j8Sg0UbXIC66QjLMkhYKYgOY0
X-Google-Smtp-Source: AGHT+IHoe8ZsLRjNPNJFkb48iGiqhi4irp302HpNCTNGOM1nHDDVo8dRG5szSzogwFa+bEeMf3tk4+7PT4GjmTfH+pA=
X-Received: by 2002:a05:6602:1588:b0:787:1d0a:ce81 with SMTP id
 e8-20020a056602158800b007871d0ace81mr7871355iow.13.1697941668279; Sat, 21 Oct
 2023 19:27:48 -0700 (PDT)
MIME-Version: 1.0
From: Antoine Riard <antoine.riard@gmail.com>
Date: Sun, 22 Oct 2023 03:27:37 +0100
Message-ID: <CALZpt+HwmacQ9VFu+SfmKms363ZU1xYZe+9o8TsoemTVQLprLg@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="000000000000fcb8ca060844d95b"
X-Mailman-Approved-At: Sun, 22 Oct 2023 09:07:58 +0000
Cc: security@ariard.me
Subject: [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: Sun, 22 Oct 2023 02:27:51 -0000

--000000000000fcb8ca060844d95b
Content-Type: text/plain; charset="UTF-8"

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 fix
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 practical
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 pace
(and I might probe a bit of Elichai Turkel time to verify the maths of all
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 value
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 currently
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/002569.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.

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

<div dir=3D"ltr">Hi,<div><br></div><div>I think if Gleb Naumenko and myself=
 allocate our research time=C2=A0on this issue, we should (hopefully) be ab=
le to come with a strong sustainable fix to the lightning network, both sys=
tematically=C2=A0solving pinnings and replacement cycling attacks (and mayb=
e other=C2=A0mempools issues=C2=A0or things related like massive force-clos=
ure beyond available blockspace can absorb before pre-signed transactions t=
imelocks expiration as mentioned in the original=C2=A0paper).</div><div><br=
></div><div>I have not yet probed Gleb&#39;s mind on this, though we both s=
tudied those cross-layer issues together as early as 2019 / 2020, and I thi=
nk we have built an intuitive=C2=A0understanding of the problem-space, with=
 both practical experience=C2=A0of bitcoin core and rust-lightning codebase=
s and landmark research in this area [0] [1]. If Gleb isn&#39;t too busy wi=
th Erlay in core, I&#39;m sure he&#39;ll be enthusiastic to contribute rese=
arch time at his own pace (and I might probe a bit of Elichai Turkel time t=
o verify the maths of all sustainable lightning fixes we might propose and =
the risks models). All soft commitments and assuming=C2=A0the interest of t=
he bitcoin community.</div><div><br></div><div>One good advantage of long-t=
erm sustainable fixes, it should (optimistically yet to be demonstrated) lo=
wer the fee-bumping reserve value and number of UTXOs lightning users (and =
maybe bandwidth) have to lock continuously to use this worldwide 24 / 7 pay=
ment system.</div><div><br></div><div>Reopened the issue on coordinated sec=
urity issues handling in the LN ecosystem:</div><div><a href=3D"https://git=
hub.com/lightning/bolts/pull/772">https://github.com/lightning/bolts/pull/7=
72</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 leas=
t I&#39;ll stay around for a few months making transitions with the younger=
 generation of LN devs.</div><div><br></div><div>For transparency, I don&#3=
9;t have any strong solution design yet at all, neither code, conceptual dr=
aft 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 currently have. Overall, this will take reasona=
ble time (e.g package relay design discussions have been started in 2018 an=
d 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 of=
 the Bitcoin and Lightning development protocols community.</div><div><br><=
/div><div>[0] <a href=3D"https://lists.linuxfoundation.org/pipermail/lightn=
ing-dev/2020-February/002569.html">https://lists.linuxfoundation.org/piperm=
ail/lightning-dev/2020-February/002569.html</a></div><div>[1] <a href=3D"ht=
tps://arxiv.org/pdf/2006.01418.pdf">https://arxiv.org/pdf/2006.01418.pdf</a=
></div><div><br></div><div>&quot;They who face calamity without wincing, an=
d who offer the most energetic resistance, these, be they States or individ=
uals, are the truest heroes&quot;. - Thucydides.</div></div>

--000000000000fcb8ca060844d95b--