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.ri...@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. >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
