* [bitcoin-dev] On solving pinning, replacement cycling and mempool issues for bitcoin second-layers
@ 2023-10-22 2:27 Antoine Riard
2023-11-15 18:14 ` Antoine Riard
0 siblings, 1 reply; 2+ messages in thread
From: Antoine Riard @ 2023-10-22 2:27 UTC (permalink / raw)
To: Bitcoin Protocol Discussion, lightning-dev\\@lists.linuxfoundation.org
Cc: security
[-- Attachment #1: Type: text/plain, Size: 2574 bytes --]
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: 3097 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [bitcoin-dev] On solving pinning, replacement cycling and mempool issues for bitcoin second-layers
2023-10-22 2:27 [bitcoin-dev] On solving pinning, replacement cycling and mempool issues for bitcoin second-layers Antoine Riard
@ 2023-11-15 18:14 ` Antoine Riard
0 siblings, 0 replies; 2+ messages in thread
From: Antoine Riard @ 2023-11-15 18:14 UTC (permalink / raw)
To: Bitcoin Protocol Discussion, lightning-dev\\@lists.linuxfoundation.org
Cc: security
[-- 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 --]
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2023-11-15 18:14 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-10-22 2:27 [bitcoin-dev] On solving pinning, replacement cycling and mempool issues for bitcoin second-layers Antoine Riard
2023-11-15 18:14 ` Antoine Riard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox