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.