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"
Cc: security@ariard.me
Subject: Re: [bitcoin-dev] On solving pinning,
 replacement cycling and mempool issues for bitcoin second-layers
Precedence: list

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