From: Antoine Riard <antoine.riard@gmail•com>
To: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
"lightning-dev\\\\@lists.linuxfoundation.org"
<lightning-dev@lists•linuxfoundation.org>
Cc: security@ariard•me
Subject: Re: [bitcoin-dev] On solving pinning, replacement cycling and mempool issues for bitcoin second-layers
Date: Wed, 15 Nov 2023 18:14:28 +0000 [thread overview]
Message-ID: <CALZpt+EYjMhS1HsyZfKNXkQkfoUg2zU9OBSC=v7am5eR_rtJew@mail.gmail.com> (raw)
In-Reply-To: <CALZpt+HwmacQ9VFu+SfmKms363ZU1xYZe+9o8TsoemTVQLprLg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5397 bytes --]
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.html
Le dim. 22 oct. 2023 à 03:27, Antoine Riard <antoine.riard@gmail•com> a
écrit :
> 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.
>
[-- Attachment #2: Type: text/html, Size: 6476 bytes --]
prev parent reply other threads:[~2023-11-15 18:14 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-22 2:27 Antoine Riard
2023-11-15 18:14 ` Antoine Riard [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALZpt+EYjMhS1HsyZfKNXkQkfoUg2zU9OBSC=v7am5eR_rtJew@mail.gmail.com' \
--to=antoine.riard@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lightning-dev@lists$(echo .)linuxfoundation.org \
--cc=security@ariard$(echo .)me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox