{"type":"rich","version":"1.0","author_name":"npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","author_url":"https://nostr.ae/npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-06-16\n📝 Original message:Hi alicexbt,\n\n\nThanks for taking time to review the pull request,\n\n\n\u003e 1)If something relies on a policy which can be changed without breaking\nconsensus rules, how is it secure in any case with or without full rbf?\n\n\nYour Lightning node software relies on far more software and hardware\ncomponents than the transaction-relay p2p network. One could list the\noperating system on which is running your Lightning process or the compiler\ntoolchain turning out your Lightning source code in a binary artifact. Some\nweird kernel's memory mapping change could allow access to your channel\nfunding keys, _without_ breaking the Bitcoin consensus rules [0]. Moreover,\nyour Lightning node is also relying on the existence of a global Internet\nallowing your HTLC transaction to flow from your physical host to the crowd\nof transactions confirming in the blockchain. Due to this \"protocol\nassumption\" your channel balance would be vulnerable to any change in your\nISP routing policy, e.g refusing to accept your IPV4 traffic by a\nsudden desiderata\nto impose an IPV6 supremacy. Still _without_ breaking the Bitcoin consensus\nrules. Of course, the odds of your ISP operator adopting this behavior are\nreally low, mostly because your operator has to bind to social and economic\nconstraints to stay in business.\n\n\nAnd I believe this imperative to stay in business is certainly not absent\nin the incentives of the Bitcoin node operators. You're free to run any\npolicy on your node, especially one hardening the safety of your\noperations beyond\nthe default one. However, if you start to a transaction-relay\nnon-compatible with miner incentives, you won't have an efficient view of\nthe blockspace demand, and from then won't be able to offer compelling\nfeerates to execute your business transactions to satisfy your client\nneeds. Or you won't consolidate your wallet UTXOs at times of low-demand.\nIndeed, a sane visibility of the mempools might not be critical now for your\nBitcoin operations, but this is not likely to become true with miner's\ncoinbase reward lowering with time and the system security relying on a\nfruitful fee market.\n\n\nSo assuming there is a significant number of economically rational entities\nrunning p2p nodes, I think it's a reasonable assumption for Lightning\ndevelopers that a policy maximizing miner's income and economic nodes\noperations\nwill be widely run on the p2p network, and therefore lay its security model\non that. When there is a gap between the economically optimal policy\n(full-rbf) and the effectively deployed one (optin), and this gap constitutes\na flaw for exploitation, I believe it's better to fix it.\n\n\nIf you have a different mode of thinking w.r.t how we should design\nprotocol in a trust-minimized, open, adversarial environment such as\nBitcoin, I'm curious to listen to it.\n\n\n\u003e If I write a python script that expects user to enter char 'a' or 'b' but\nuser can enter 'c' and there is no code to handle exceptions or other\nchars, will it be secure?\n\n\nOf course not. If you deliver any critical software, you should attach a\nsolid manual explaining all the corner cases and rough edges. Even better\nwould be to enshrine the manual directly in your software API to minimize\nthe footgunish behaviors. E.g, with any ECC library, forbidding to reuse\nnonces. If your user still ignores or misread the manual and provides an\ninsecure input, there is not that much you can do.\n\n\nBy analogy, I believe that's the same with Lightning. One recommendation of\nthe deployment manual would be to be always connected to a full-rbf\ntransaction-relay topology. Defaulting to this rule and your node exposes\nfar more surface of attacks. Assuming the manual has been well-written (big\nassumption!), I don't think the system designer would be to blame.\n\n\nThat said, one issue to confess with current Lightning is our lack of\nunderstanding of what should be figured out in the LN user manual for safe\noperations. I would say that's an active area of research [1] [2] [3]\n\n\n\u003e 2)full-rbf is not default in the 2 open pull requests, so this experiment\nstill relies on users changing RBF policies manually. If majority of nodes\nuse default opt-in policy, how would this affect vulnerable projects?\n\n\nIf we define the goal as ensuring there is a significant number of\ntransaction-relay routes between the L2s nodes requiring full-rbf and the\nset of miners supporting this policy, and the set of miners is populated\nenough, there is no need to convince the majority of nodes operators to\nswitch to full-rbf.\n\n\nBeyond landing the 'full-rbf' pull request, in pursuit of a partial\nfull-rbf deployment, I'm thinking of reaching out to Lightning vendors to\nrecommend running LN nodes operators run their full-node with the setting\nenabled. And also to few mining pool operators to advocate the potential\nincrease in their income.\n\n\nGiven there are like 17000 public LN nodes, if half of them adopt full-rbf\nit should give already a good number of full-rbf transaction-relay routes\nacross the p2p network graph. When we're there, we can measure and think\nmore about how to tune the full-rbf sub-topology.\n\n\n\u003e 2-3% transactions are replaced with opt-in RBF, if someone did not\nreplace earlier why would they do it with full RBF?\n\n\nBecause it's breaking the reliability and security of their use-cases.\nUse-cases which didn't exist a few years ago. The mempool DoS vector is\ndescribed here [4]. To the best of my understanding, it might affect a\nbunch of use-cases, such as dual-funded channels, on-chain DLCs, p2p\ncoinjoins, batched submarine swaps out. With the attack described, the\nhonest set of users might not have visibility of the network mempools that\nthere is a malicious, low-cost, opt-out double-spend preventing the\npropagation of their multi-party transaction. With the existence of a\nfull-rbf transaction-relay topology, the multi-party transaction is able to\nreplace the optout.\n\n\nNone of those use-cases were deployed a few years ago, and the\nunderstanding of the interactions with the mempool policy is still nascent\namong their operators. However, if we assume that layering is a way to grow the\nBitcoin ecosystem, as I do, it is reasonable to expect they will constitute\na notable share of the Bitcoin transaction traffic during the next decade.\n\n\n\u003e I am not opposed to full-rbf; rather, I am opposed to the notion that\nfull-rbf will solve all problems\n\n\nI wished we had a magic Silver Bullet (tm) solving all the Bitcoin\nproblems...\n\n\nI'm only advocating a partial full-rbf deployment to solve a real precise\nsecurity issue affecting multi-party funded transactions. That said,\nfull-rbf is far from solving the known set of problems affecting the L2s\ndue to interactions with network mempools. E,g, see package relay\nmotivation [5]\n\n\n\u003e I would suggest users to try Bitcoin Knots instead which already has an\noption to disable all RBF policies if required, opt-in and full RBF policy.\n\n\nSelecting a full-node to underpin any serious Bitcoin infrastructure or\nsecure a significant stack of coins should be submitted to a fully-fledged\ndecision-making process. Many factors are likely to matter such as the\nlevel of activity of the contributor community, the chain of trust w.r.t\ndependencies, the security incident track records, the quality of the\ndocumentation, the exhaustivity and robustness of the set of features, ...\n\n\nThis process might take tens of hours, to be duplicated by the number of\nnode operators who would have to do the full-node vending switch. If you\nconsider the cognitive cost at the level of the Bitcoin ecosystem, it's far\nless costly to implement and review a few lines of codes in Bitcoin Core.\n\n\n\u003e Developers should provide basic RBF policy options rather than attempting\nto define what constitutes a good policy and removing the ability to\ndisable something when necessary.\n\n\nOf course, this statement assumes there is a clear line between the\ndevelopers and the users. Developers are also Bitcoin users, and they're\nmodifying the software to suit their use-case needs. And that's exactly the\npurpose of the 'full-rbf' PR I'm proposing, aiming to propose a \"good\"\npolicy for a Lightning node, without actually seeking to change the\ndefault. If they're parties interested in implementing more RBF policy\noptions in Bitcoin Core, I think they're free to propose such changes and\ninvest the engineering effort to do so. If you're interested in advancing\nthe state of policy options in Bitcoin Core, there are a lot of interesting\nresources available and communities to encourage you in the learning\nprocess to contribute to the codebase [6].\n\n\nAntoine\n\n\n[0] https://dirtycow.ninja\n\n[1] https://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md\n\n[2] https://arxiv.org/pdf/2006.01418.pdf\n\n[3] https://arxiv.org/pdf/2006.08513.pdf\n\n[4]\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html\n\n[5]\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020493.html\n\n[6] https://www.summerofbitcoin.org\n\n\nLe jeu. 16 juin 2022 à 00:15, alicexbt \u003calicexbt at protonmail.com\u003e a écrit :\n\n\u003e Hi Antoine,\n\u003e\n\u003e\n\u003e Thanks for opening the pull request to add support for full-rbf in Bitcoin\n\u003e Core. I have a disagreements with the approach and questions.\n\u003e\n\u003e Recent discussions among LN devs have brought back on the surface concerns\n\u003e about the security of multi-party funded transactions (coinjoins,\n\u003e dual-funded LN channels, on-chain DLCs, ...). It turns out there is a\n\u003e low-fruit, naive DoS vector playable against the funding flow of any such\n\u003e construction due to the lack of existent full-rbf transaction-relay\n\u003e topology on today's p2p network [0] [1].\n\u003e\n\u003e\n\u003e 1)If something relies on a policy which can be changed without breaking\n\u003e consensus rules, how is it secure in any case with or without full rbf? If\n\u003e I write a python script that expects user to enter char 'a' or 'b' but user\n\u003e can enter 'c' and there is no code to handle exceptions or other chars,\n\u003e will it be secure?\n\u003e\n\u003e 2)full-rbf is not default in the 2 open pull requests, so this experiment\n\u003e still relies on users changing RBF policies manually. If majority of nodes\n\u003e use default opt-in policy, how would this affect vulnerable projects?\n\u003e\n\u003e If you're a mining operator looking to increase your income, you might be\n\u003e interested to experiment with full-rbf as a policy.\n\u003e\n\u003e\n\u003e Miners can only increase their income if users replace transactions. 2-3%\n\u003e transactions are replaced with opt-in RBF, if someone did not replace\n\u003e earlier why would they do it now even with full RBF? Or even if we add some\n\u003e users in it who could not signal for some reasons, do you think it would be\n\u003e anything above 5%?\n\u003e\n\u003e If you're a Bitcoin user or business and you don't like full-rbf, please\n\u003e express an opinion on how it might affect your software/operations. I'm\n\u003e always interested to learn more about mempool and transaction-relay\n\u003e interactions with upper-layers and applications and to listen to feedback\n\u003e in those areas, and I guess a lot of other Bitcoin researchers/devs too. I\n\u003e know there have been a lot of concerns about full-rbf in the past, however\n\u003e I believe the Bitcoin ecosystem has matured a lot since then.\n\u003e\n\u003e\n\u003e I am not opposed to full-rbf; rather, I am opposed to the notion that\n\u003e full-rbf will solve all problems and the lack of basic options in Bitcoin\n\u003e Core to employ/disable different RBF policies. There is also a speculation\n\u003e about making full RBF default in an year which isn't relevant to discuss at\n\u003e this point without trying different RBF policies.\n\u003e\n\u003e I would suggest users to try Bitcoin Knots instead which already has an\n\u003e option to disable all RBF policies if required, opt-in and full RBF policy.\n\u003e This can also be done using GUI if not familiar with config option\n\u003e mempoolreplacement​.\n\u003e\n\u003e The rationale in PR #16171 was insufficient to justify removing it in the\n\u003e first place, had 2 NACKs and was reopened to merge it. Why bother with a\n\u003e few lines of code that may allow someone disable it if required in local\n\u003e mempool since it's only useful when a big percentage of miners utilize it\n\u003e and essentially underused according to the PR author? Developers should\n\u003e provide basic RBF policy options rather than attempting to define what\n\u003e constitutes a good policy and removing the ability to disable something\n\u003e when necessary.\n\u003e\n\u003e\n\u003e /dev/fd0\n\u003e\n\u003e Sent with Proton Mail \u003chttps://proton.me/\u003e secure email.\n\u003e\n\u003e ------- Original Message -------\n\u003e On Tuesday, June 14th, 2022 at 5:55 AM, Antoine Riard via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e Hi list,\n\u003e\n\u003e Recent discussions among LN devs have brought back on the surface concerns\n\u003e about the security of multi-party funded transactions (coinjoins,\n\u003e dual-funded LN channels, on-chain DLCs, ...). It turns out there is a\n\u003e low-fruit, naive DoS vector playable against the funding flow of any such\n\u003e construction due to the lack of existent full-rbf transaction-relay\n\u003e topology on today's p2p network [0] [1]. While it does not consist in a\n\u003e direct loss of funds, if exploited well I think it's annoying enough to\n\u003e inflict significant timevalue loss or fee-bumping waste\n\u003e to the future providers or distributed swarm of users doing multi-party\n\u003e funded transactions. Of course, it can be fixed one layer above by\n\u003e introducing either fidelity bonds or a reliable centralized coordinator,\n\u003e though at the price of an overhead per-participant ressources cost and loss\n\u003e in system openness [1].\n\u003e\n\u003e For that reason, I believe it would be beneficial to the flourishing of\n\u003e multi-party funded transactions to fix the Dos vector by seeing a subset of\n\u003e the network running full-rbf and enabling propagation of honest multi-party\n\u003e transactions to the interested miners, replacing potential non-signaling\n\u003e double-spend from a malicious counterparty. Moving towards that direction,\n\u003e I've submitted a small patch against Bitcoin Core enabling it to turn on\n\u003e full-rbf as a policy, still under review [3]. The default setting stays\n\u003e **false**, i.e keeping opt-in RBF as a default replacement policy. I've\n\u003e started to run the patch on a public node at 146.190.224.15.\n\u003e\n\u003e If you're a node operator curious to play with full-rbf, feel free to\n\u003e connect to this node or spawn up a toy, public node yourself. There is a\n\u003e ##uafrbf libera chat if you would like information on the settings or\n\u003e looking for full-rbf friends (though that step could be automated in the\n\u003e future by setting up a dedicated network bit and reserving a few outbound\n\u003e slots for them).\n\u003e\n\u003e If you're a mining operator looking to increase your income, you might be\n\u003e interested to experiment with full-rbf as a policy. Indeed, in the future I\n\u003e believe the multi-party transactions issuers who need full-rbf to secure\n\u003e their funding flow should connect by default to full-rbf peers. One can\n\u003e conjecture that their transactions are likely to be more compelling in\n\u003e their feerate as their liquidity needs are higher than the simple\n\u003e transaction. For today, I think we have really few standards and bitcoin\n\u003e softwares relying on multi-party funded transactions [4].\n\u003e\n\u003e If you're a Bitcoin user or business and you don't like full-rbf, please\n\u003e express an opinion on how it might affect your software/operations. I'm\n\u003e always interested to learn more about mempool and transaction-relay\n\u003e interactions with upper-layers and applications and to listen to feedback\n\u003e in those areas, and I guess a lot of other Bitcoin researchers/devs too. I\n\u003e know there have been a lot of concerns about full-rbf in the past, however\n\u003e I believe the Bitcoin ecosystem has matured a lot since then.\n\u003e\n\u003e Any mistakes or missing context is my own.\n\u003e\n\u003e Cheers,\n\u003e Antoine\n\u003e\n\u003e [0] For more info about replace-by-fee, see\n\u003e https://bitcoinops.org/en/topics/replace-by-fee/\n\u003e\n\u003e [1] For more details about the DoS vector, see\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html\n\u003e\n\u003e [2] E.g I think it does not affect the Lightning Pool service, as there is\n\u003e a preliminary step where the participant funds are locked first in a 2-of-2\n\u003e with the coordinator before being committed in the multi-party batch\n\u003e transaction.\n\u003e\n\u003e [3] https://github.com/bitcoin/bitcoin/pull/25353\n\u003e\n\u003e [4] E.g DLCs :\n\u003e https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transactions.md\n\u003e ; Lightning dual-funded channel :\n\u003e https://github.com/lightning/bolts/pull/851\n\u003e\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220617/6775746f/attachment-0001.html\u003e"}