{"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-21\n📝 Original message:HI alicexbt,\n\n\u003e Lets consider there are 2 users with name Bob (normal LN user) and Carol\n(attacker running LN node) which I will use in this email for examples. In\nthis case Bob and Carol can manage security of their OS and it is not\naffected by others using vulnerable systems or OS.\n\nYes, I believe my argument was the set of components making the security of\nyour LN node is far beyond Bitcoin softwares. Of course, you might review\nby yourself the millions lines of code entering in the trusted computing\nbase (OS, bootloader, BIOS, device firmwares, essential utilities, ...) on\nwhich your cryptocurrency software stack lays out, and as such exercise an\nextended span of control on your personal computation. Though, while I hope\nwe'll have more LN node operators doing so, I'm not sure it's realistic to\nexpect it will be the behavior standard among them..\n\n\u003e The odds are low as you said, this can be managed by Bob and Carol\nbecause they can use a better ISP. Others using ISP with some issues may\nnot affect their LN usage.\n\nSure, though as I would like to underscore being dependent on a Bitcoin\nnode policy and being dependent on a ISP internet traffic routing policy\ncould be analyzed as logically equivalent, all things are equal. That said,\nif your personal risk aversion is too high for the Lightning security\nmodel, once it's well-understood there is a strong reliance on a\ncensorship-resistant tx-relay network back to economically-rational miners,\nyou're free to not use it and satisfy yourself with the Bitcoin base layer.\n\n\u003e Bob might use full-rbf as its suggested by LN developers for secure LN\nusage and better for miners. Carol could use a different RBF policy for\nsome nodes and mining. In this case Bob may get affected at some point\nbecause of Carol's choice to use a different RBF policy which was not true\nabove.\n\nIndeed, your secure LN usage is going to be dependent of the number of p2p\nnetwork nodes running an economically-rational policy like full-rbf. That\nsaid, I think it's reasonable to assume that the players of the Bitcoin\ngame are economically-rational, and as such incentived to pick up a policy\nsuch as full-rbf. I know the term \"economically-rational\" is poorly defined\nhere, and I think it could be interesting for any academic with an economic\nbackground to study the incentives of Bitcoin actors.\n\n\u003e Allowing users to create different mempool policies is great. My thought\nprocess is to code for happy path, where X policy is expected for\nreplacement and edge cases where Y policy or no policy would be used. Users\ncan try out different policies and even act as attackers. This is also true\nfor other things in mempool, 'spkreuse=conflict' prevents address reuse in\nthe mempool when using knots. If I assume that address reuse is always\nrelayed, this could become a problem if some users and miners adopt this\nsetting in their mempool.\n\nAgree, I'm all in for people to experiment with mempool policies. Though at\nthe end it's a software engineering resource question. If users are\ninterested in more features, they're always free to implement themselves.\nReally, the binary distinction developers-vs-users doesn't make sense and\nif we would like Bitcoin to be successful in the long-term, we should\npromote high degree of software literacy among bitcoiners.\n\n\u003e This makes sense and I would be interested to follow two things once\nfull-rbf is available in a bitcoin core release: 1. Percentage of\ntransaction getting replaced 2. Miners profit (Fee for replaced Tx - Fee\nfor original Tx)\n\nYes, I would be interested too to have those metrics once full-rbf is\navailable in a bitcoin core release. I think that's something every\nfull-rbf curious node operator could observe on its own with a few more\nloggers, at least for the first metric.\n\n\u003e Can you explain how p2p coinjoin is affected with mempool DoS vector with\nsome examples? What is considered a p2p coinjoin? Joinmarket or\n[Stonewall][1]?\n\nI don't remember the Joinmarket code right now and I don't know the ins and\nouts of Samourai coinjoin as I'm not sure the code is open source. Though\nlet's say for a p2p coinjoin as one you can build once you have implemented\nLN's interactive construction protocol [0].\n\n[0] https://github.com/lightning/bolts/pull/851\n\nHere the DoS attack situation :\n- Alice, Bob and Caroll would like to coinjoin 3 inputs to 3 outputs\n- Each of the input is singly controlled by one party, e.g Alice owns input\nA, Bob owns input B, ...\n- Alice, Bob and Caroll exchanges a PSBT to build a multi-party funded\ntransaction (the coinjoin_tx)\n- Alice is elected as the multi-party transaction broadcaster once the\nsignatures have been exchanged\n- The block feerate is around 10sat/vb\n- One of the transaction input signals opt-in RBF, the transaction is\nattached a compelling feerate 10sat/vb\n- Caroll broadcasts a double-spend of her own input C, the double-spend is\nattached with a low-fee (1sat/vb) and it does _not_ signal opt-in RBF\n- Alice broadcasts the multi-party transaction, it is rejected by the\nnetwork mempools because Alice double-spend is already present\n- Two alternatives are offered to the coinjoin participants :\n\nAlternative A)\n- They estimate the multi-party feerate as not high enough\n- They fee-bump at 20sat/vb\n- Caroll double-spend one of the input of her malicious double-spend to\neject it from the network mempools\n- The multi-party transaction is confirmed at a block feerare far above\nwhat was necessary\n- Alice, Bob, Caroll have loss fee-bumping value without compensation\n- Note, even if Caroll is attacker and assuming the fee-bumping burden is\nfairly spread among participants, the economic loss inflicted is asymmetric\n\nAlternative B)\n- They wait until some time-out\n- They double-spend their own inputs, Alice double-spend utxo A, Bob\ndouble-spend utxo B\n- They wasted the timevalue of their inputs for the time-out delay\n- Note, even if Caroll is attacker and loss some timevalue too, the\neconomic loss inflicted is asymmetric\n\nLet me know if you see any error or wrong in this DoS scenario exposure. I\nbelieve it's fairly simple to execute\nfor a medium-skilled attacker.\n\nAntoine\n\nLe ven. 17 juin 2022 à 00:54, alicexbt \u003calicexbt at protonmail.com\u003e a écrit :\n\n\u003e Hi Antoine,\n\u003e\n\u003e\n\u003e One could list the operating system on which is running your Lightning\n\u003e process or the compiler toolchain turning out your Lightning source code\n\u003e in a binary artifact. Some weird kernel's memory mapping change could allow\n\u003e access to your channel funding keys, _without_ breaking the Bitcoin\n\u003e consensus rules [0].\n\u003e\n\u003e\n\u003e Lets consider there are 2 users with name Bob (normal LN user) and Carol\n\u003e (attacker running LN node) which I will use in this email for examples. In\n\u003e this case Bob and Carol can manage security of their OS and it is not\n\u003e affected by others using vulnerable systems or OS.\n\u003e\n\u003e Moreover, your Lightning node is also relying on the existence of a\n\u003e global Internet allowing your HTLC transaction to flow from your physical\n\u003e host to the crowd of transactions confirming in the blockchain. Due to\n\u003e this \"protocol assumption\" your channel balance would be vulnerable to\n\u003e any change in your ISP routing policy, e.g refusing to accept your IPV4\n\u003e traffic by a sudden desiderata to impose an IPV6 supremacy. Still\n\u003e _without_ breaking the Bitcoin consensus rules. Of course, the odds of your\n\u003e ISP operator adopting this behavior are really low, mostly because your\n\u003e operator has to bind to social and economic constraints to stay in\n\u003e business.\n\u003e\n\u003e\n\u003e The odds are low as you said, this can be managed by Bob and Carol because\n\u003e they can use a better ISP. Others using ISP with some issues may not affect\n\u003e their LN usage.\n\u003e\n\u003e And I believe this imperative to stay in business is certainly not absent\n\u003e in the incentives of the Bitcoin node operators. You're free to run any\n\u003e policy on your node, especially one hardening the safety of your operations\n\u003e  beyond the default one. However, if you start to a transaction-relay\n\u003e non-compatible with miner incentives, you won't have an efficient view of\n\u003e the blockspace demand, and from then won't be able to offer compelling\n\u003e feerates to execute your business transactions to satisfy your client\n\u003e needs. Or you won't consolidate your wallet UTXOs at times of low-demand.\n\u003e Indeed, a sane visibility of the mempools might not be critical now for your\n\u003e Bitcoin operations, but this is not likely to become true with miner's\n\u003e coinbase reward lowering with time and the system security relying on a\n\u003e fruitful fee market.\n\u003e\n\u003e\n\u003e Bob might use full-rbf as its suggested by LN developers for secure LN\n\u003e usage and better for miners. Carol could use a different RBF policy for\n\u003e some nodes and mining. In this case Bob may get affected at some point\n\u003e because of Carol's choice to use a different RBF policy which was not true\n\u003e above.\n\u003e\n\u003e\n\u003e So assuming there is a significant number of economically rational\n\u003e entities running p2p nodes, I think it's a reasonable assumption for\n\u003e Lightning developers that a policy maximizing miner's income and economic\n\u003e nodes operations will be widely run on the p2p network, and therefore lay\n\u003e its security model on that. When there is a gap between the economically\n\u003e optimal policy (full-rbf) and the effectively deployed one (optin), and\n\u003e this gap constitutes a flaw for exploitation, I believe it's better to\n\u003e fix it.\n\u003e\n\u003e\n\u003e Agree with the assumption there is nothing wrong in experimenting with a\n\u003e new RBF policy (non-default) if that helps some users and projects.\n\u003e\n\u003e If you have a different mode of thinking w.r.t how we should design\n\u003e protocol in a trust-minimized, open, adversarial environment such as\n\u003e Bitcoin, I'm curious to listen to it.\n\u003e\n\u003e\n\u003e Allowing users to create different mempool policies is great. My thought\n\u003e process is to code for happy path, where X policy is expected for\n\u003e replacement and edge cases where Y policy or no policy would be used. Users\n\u003e can try out different policies and even act as attackers. This is also true\n\u003e for other things in mempool, 'spkreuse=conflict' prevents address reuse in\n\u003e the mempool when using knots. If I assume that address reuse is always\n\u003e relayed, this could become a problem if some users and miners adopt this\n\u003e setting in their mempool.\n\u003e\n\u003e Of course not. If you deliver any critical software, you should attach a\n\u003e solid manual explaining all the corner cases and rough edges. Even better\n\u003e would be to enshrine the manual directly in your software API to minimize\n\u003e the footgunish behaviors. E.g, with any ECC library, forbidding to reuse\n\u003e nonces. If your user still ignores or misread the manual and provides an\n\u003e insecure input, there is not that much you can do.\n\u003e\n\u003e\n\u003e Agree with the documentation as it helps users.\n\u003e\n\u003e Given there are like 17000 public LN nodes, if half of them adopt full-rbf\n\u003e it should give already a good number of full-rbf transaction-relay routes\n\u003e across the p2p network graph. When we're there, we can measure and think\n\u003e more about how to tune the full-rbf sub-topology.\n\u003e\n\u003e\n\u003e Sounds good.\n\u003e\n\u003e Because it's breaking the reliability and security of their use-cases.\n\u003e Use-cases which didn't exist a few years ago. The mempool DoS vector is\n\u003e described here [4]. To the best of my understanding, it might affect a\n\u003e bunch of use-cases, such as dual-funded channels, on-chain DLCs, p2p\n\u003e coinjoins, batched submarine swaps out. With the attack described, the\n\u003e honest set of users might not have visibility of the network mempools\n\u003e that there is a malicious, low-cost, opt-out double-spend preventing the\n\u003e propagation of their multi-party transaction. With the existence of a\n\u003e full-rbf transaction-relay topology, the multi-party transaction is able\n\u003e to replace the optout.\n\u003e\n\u003e\n\u003e This makes sense and I would be interested to follow two things once\n\u003e full-rbf is available in a bitcoin core release: 1. Percentage of\n\u003e transaction getting replaced 2. Miners profit (Fee for replaced Tx - Fee\n\u003e for original Tx)\n\u003e\n\u003e Can you explain how p2p coinjoin is affected with mempool DoS vector with\n\u003e some examples? What is considered a p2p coinjoin? Joinmarket or\n\u003e [Stonewall][1]?\n\u003e\n\u003e Selecting a full-node to underpin any serious Bitcoin infrastructure or\n\u003e secure a significant stack of coins should be submitted to a\n\u003e fully-fledged decision-making process. Many factors are likely to matter such\n\u003e as the level of activity of the contributor community, the chain of trust\n\u003e w.r.t dependencies, the security incident track records, the quality of\n\u003e the documentation, the exhaustivity and robustness of the set of features,\n\u003e ...\n\u003e\n\u003e\n\u003e I agree that contributor community and documentation could be improved in\n\u003e Knots.\n\u003e\n\u003e Developers are also Bitcoin users, and they're modifying the software to\n\u003e suit their use-case needs. And that's exactly the purpose of the\n\u003e 'full-rbf' PR I'm proposing, aiming to propose a \"good\" policy for a\n\u003e Lightning node, without actually seeking to change the default.\n\u003e\n\u003e\n\u003e I like that default still remains opt-in and cool with different policies\n\u003e being tried out if that helps some users.\n\u003e\n\u003e  If they're parties interested in implementing more RBF policy options in\n\u003e Bitcoin Core, I think they're free to propose such changes and invest the\n\u003e engineering effort to do so. If you're interested in advancing the state of\n\u003e  policy options in Bitcoin Core, there are a lot of interesting resources available\n\u003e and communities to encourage you in the learning process to contribute to\n\u003e the codebase [6].\n\u003e\n\u003e\n\u003e Thanks for sharing the link. I would love to see 5 RBF policies available\n\u003e to use in bitcoin core. I have already tried experimenting with a few on\n\u003e regtest and will try to open pull request if there are enough people\n\u003e interested to test it on other chains (testnet3, signet, mainnet)\n\u003e\n\u003e\n\u003e [1]: https://docs.samourai.io/spend-tools\n\u003e\n\u003e\n\u003e /dev/fd0\n\u003e\n\u003e\n\u003e Sent with Proton Mail \u003chttps://proton.me/\u003e secure email.\n\u003e\n\u003e ------- Original Message -------\n\u003e On Friday, June 17th, 2022 at 7:04 AM, Antoine Riard \u003c\n\u003e antoine.riard at gmail.com\u003e wrote:\n\u003e\n\u003e Hi alicexbt,\n\u003e\n\u003e\n\u003e Thanks for taking time to review the pull request,\n\u003e\n\u003e\n\u003e \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?\n\u003e\n\u003e\n\u003e Your Lightning node software relies on far more software and hardware\n\u003e components than the transaction-relay p2p network. One could list the\n\u003e operating system on which is running your Lightning process or the compiler\n\u003e toolchain turning out your Lightning source code in a binary artifact.\n\u003e Some weird kernel's memory mapping change could allow access to your\n\u003e channel funding keys, _without_ breaking the Bitcoin consensus rules [0].\n\u003e Moreover, your Lightning node is also relying on the existence of a\n\u003e global Internet allowing your HTLC transaction to flow from your physical\n\u003e host to the crowd of transactions confirming in the blockchain. Due to\n\u003e this \"protocol assumption\" your channel balance would be vulnerable to\n\u003e any change in your ISP routing policy, e.g refusing to accept your IPV4\n\u003e traffic by a sudden desiderata to impose an IPV6 supremacy. Still\n\u003e _without_ breaking the Bitcoin consensus rules. Of course, the odds of your\n\u003e ISP operator adopting this behavior are really low, mostly because your\n\u003e operator has to bind to social and economic constraints to stay in\n\u003e business.\n\u003e\n\u003e\n\u003e And I believe this imperative to stay in business is certainly not absent\n\u003e in the incentives of the Bitcoin node operators. You're free to run any\n\u003e policy on your node, especially one hardening the safety of your operations beyond\n\u003e the default one. However, if you start to a transaction-relay\n\u003e non-compatible with miner incentives, you won't have an efficient view of\n\u003e the blockspace demand, and from then won't be able to offer compelling\n\u003e feerates to execute your business transactions to satisfy your client\n\u003e needs. Or you won't consolidate your wallet UTXOs at times of low-demand.\n\u003e Indeed, a sane visibility of the mempools might not be critical now for your\n\u003e Bitcoin operations, but this is not likely to become true with miner's\n\u003e coinbase reward lowering with time and the system security relying on a\n\u003e fruitful fee market.\n\u003e\n\u003e\n\u003e So assuming there is a significant number of economically rational\n\u003e entities running p2p nodes, I think it's a reasonable assumption for\n\u003e Lightning developers that a policy maximizing miner's income and economic\n\u003e nodes operations will be widely run on the p2p network, and therefore lay\n\u003e its security model on that. When there is a gap between the economically\n\u003e optimal policy (full-rbf) and the effectively deployed one (optin), and\n\u003e this gap constitutes a flaw for exploitation, I believe it's better to\n\u003e fix it.\n\u003e\n\u003e\n\u003e If you have a different mode of thinking w.r.t how we should design\n\u003e protocol in a trust-minimized, open, adversarial environment such as\n\u003e Bitcoin, I'm curious to listen to it.\n\u003e\n\u003e\n\u003e \u003e If I write a python script that expects user to enter char 'a' or 'b'\n\u003e but user can enter 'c' and there is no code to handle exceptions or other\n\u003e chars, will it be secure?\n\u003e\n\u003e\n\u003e Of course not. If you deliver any critical software, you should attach a\n\u003e solid manual explaining all the corner cases and rough edges. Even better\n\u003e would be to enshrine the manual directly in your software API to minimize\n\u003e the footgunish behaviors. E.g, with any ECC library, forbidding to reuse\n\u003e nonces. If your user still ignores or misread the manual and provides an\n\u003e insecure input, there is not that much you can do.\n\u003e\n\u003e\n\u003e By analogy, I believe that's the same with Lightning. One recommendation\n\u003e of the deployment manual would be to be always connected to a full-rbf\n\u003e transaction-relay topology. Defaulting to this rule and your node exposes\n\u003e far more surface of attacks. Assuming the manual has been well-written (big\n\u003e assumption!), I don't think the system designer would be to blame.\n\u003e\n\u003e\n\u003e That said, one issue to confess with current Lightning is our lack of\n\u003e understanding of what should be figured out in the LN user manual for\n\u003e safe operations. I would say that's an active area of research [1] [2] [3]\n\u003e\n\u003e\n\u003e \u003e 2)full-rbf is not default in the 2 open pull requests, so this\n\u003e experiment still relies on users changing RBF policies manually. If\n\u003e majority of nodes use default opt-in policy, how would this affect\n\u003e vulnerable projects?\n\u003e\n\u003e\n\u003e If we define the goal as ensuring there is a significant number of\n\u003e transaction-relay routes between the L2s nodes requiring full-rbf and the\n\u003e set of miners supporting this policy, and the set of miners is populated\n\u003e enough, there is no need to convince the majority of nodes operators to\n\u003e switch to full-rbf.\n\u003e\n\u003e\n\u003e Beyond landing the 'full-rbf' pull request, in pursuit of a partial\n\u003e full-rbf deployment, I'm thinking of reaching out to Lightning vendors to\n\u003e recommend running LN nodes operators run their full-node with the setting\n\u003e enabled. And also to few mining pool operators to advocate the potential\n\u003e increase in their income.\n\u003e\n\u003e\n\u003e Given there are like 17000 public LN nodes, if half of them adopt full-rbf\n\u003e it should give already a good number of full-rbf transaction-relay routes\n\u003e across the p2p network graph. When we're there, we can measure and think\n\u003e more about how to tune the full-rbf sub-topology.\n\u003e\n\u003e\n\u003e \u003e 2-3% transactions are replaced with opt-in RBF, if someone did not\n\u003e replace earlier why would they do it with full RBF?\n\u003e\n\u003e\n\u003e Because it's breaking the reliability and security of their use-cases.\n\u003e Use-cases which didn't exist a few years ago. The mempool DoS vector is\n\u003e described here [4]. To the best of my understanding, it might affect a\n\u003e bunch of use-cases, such as dual-funded channels, on-chain DLCs, p2p\n\u003e coinjoins, batched submarine swaps out. With the attack described, the\n\u003e honest set of users might not have visibility of the network mempools\n\u003e that there is a malicious, low-cost, opt-out double-spend preventing the\n\u003e propagation of their multi-party transaction. With the existence of a\n\u003e full-rbf transaction-relay topology, the multi-party transaction is able\n\u003e to replace the optout.\n\u003e\n\u003e\n\u003e None of those use-cases were deployed a few years ago, and the\n\u003e understanding of the interactions with the mempool policy is still\n\u003e nascent among their operators. However, if we assume that layering is a way\n\u003e to grow the Bitcoin ecosystem, as I do, it is reasonable to expect they\n\u003e will constitute a notable share of the Bitcoin transaction traffic during\n\u003e the next decade.\n\u003e\n\u003e\n\u003e \u003e I am not opposed to full-rbf; rather, I am opposed to the notion that\n\u003e full-rbf will solve all problems\n\u003e\n\u003e\n\u003e I wished we had a magic Silver Bullet (tm) solving all the Bitcoin\n\u003e problems...\n\u003e\n\u003e\n\u003e I'm only advocating a partial full-rbf deployment to solve a real precise\n\u003e security issue affecting multi-party funded transactions. That said,\n\u003e full-rbf is far from solving the known set of problems affecting the L2s\n\u003e due to interactions with network mempools. E,g, see package relay\n\u003e motivation [5]\n\u003e\n\u003e\n\u003e \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\n\u003e\n\u003e Selecting a full-node to underpin any serious Bitcoin infrastructure or\n\u003e secure a significant stack of coins should be submitted to a\n\u003e fully-fledged decision-making process. Many factors are likely to matter\n\u003e such as the level of activity of the contributor community, the chain of\n\u003e trust w.r.t dependencies, the security incident track records, the\n\u003e quality of the documentation, the exhaustivity and robustness of the set of\n\u003e features, ...\n\u003e\n\u003e\n\u003e This process might take tens of hours, to be duplicated by the number of\n\u003e node operators who would have to do the full-node vending switch. If you\n\u003e consider the cognitive cost at the level of the Bitcoin ecosystem, it's\n\u003e far less costly to implement and review a few lines of codes in Bitcoin\n\u003e Core.\n\u003e\n\u003e\n\u003e \u003e Developers should provide basic RBF policy options rather than\n\u003e attempting to define what constitutes a good policy and removing the\n\u003e ability to disable something when necessary.\n\u003e\n\u003e\n\u003e Of course, this statement assumes there is a clear line between the\n\u003e developers and the users. Developers are also Bitcoin users, and they're\n\u003e modifying the software to suit their use-case needs. And that's exactly the\n\u003e purpose of the 'full-rbf' PR I'm proposing, aiming to propose a \"good\"\n\u003e policy for a Lightning node, without actually seeking to change the\n\u003e default. If they're parties interested in implementing more RBF policy\n\u003e options in Bitcoin Core, I think they're free to propose such changes and\n\u003e invest the engineering effort to do so. If you're interested in advancing\n\u003e the state of policy options in Bitcoin Core, there are a lot of\n\u003e interesting resources available and communities to encourage you in the\n\u003e learning process to contribute to the codebase [6].\n\u003e\n\u003e\n\u003e Antoine\n\u003e\n\u003e\n\u003e [0] https://dirtycow.ninja\n\u003e\n\u003e [1]\n\u003e https://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md\n\u003e\n\u003e [2] https://arxiv.org/pdf/2006.01418.pdf\n\u003e\n\u003e [3] https://arxiv.org/pdf/2006.08513.pdf\n\u003e\n\u003e [4]\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html\n\u003e\n\u003e [5]\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020493.html\n\u003e\n\u003e [6] https://www.summerofbitcoin.org\n\u003e\n\u003e\n\u003e Le jeu. 16 juin 2022 à 00:15, alicexbt \u003calicexbt at protonmail.com\u003e a écrit :\n\u003e\n\u003e\u003e Hi Antoine,\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Thanks for opening the pull request to add support for full-rbf in\n\u003e\u003e Bitcoin Core. I have a disagreements with the approach and questions.\n\u003e\u003e\n\u003e\u003e Recent discussions among LN devs have brought back on the surface\n\u003e\u003e concerns about the security of multi-party funded transactions (coinjoins,\n\u003e\u003e dual-funded LN channels, on-chain DLCs, ...). It turns out there is a\n\u003e\u003e low-fruit, naive DoS vector playable against the funding flow of any such\n\u003e\u003e construction due to the lack of existent full-rbf transaction-relay\n\u003e\u003e topology on today's p2p network [0] [1].\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e 1)If something relies on a policy which can be changed without breaking\n\u003e\u003e consensus rules, how is it secure in any case with or without full rbf? If\n\u003e\u003e I write a python script that expects user to enter char 'a' or 'b' but user\n\u003e\u003e can enter 'c' and there is no code to handle exceptions or other chars,\n\u003e\u003e will it be secure?\n\u003e\u003e\n\u003e\u003e 2)full-rbf is not default in the 2 open pull requests, so this experiment\n\u003e\u003e still relies on users changing RBF policies manually. If majority of nodes\n\u003e\u003e use default opt-in policy, how would this affect vulnerable projects?\n\u003e\u003e\n\u003e\u003e If you're a mining operator looking to increase your income, you might be\n\u003e\u003e interested to experiment with full-rbf as a policy.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Miners can only increase their income if users replace transactions. 2-3%\n\u003e\u003e transactions are replaced with opt-in RBF, if someone did not replace\n\u003e\u003e earlier why would they do it now even with full RBF? Or even if we add some\n\u003e\u003e users in it who could not signal for some reasons, do you think it would be\n\u003e\u003e anything above 5%?\n\u003e\u003e\n\u003e\u003e If you're a Bitcoin user or business and you don't like full-rbf, please\n\u003e\u003e express an opinion on how it might affect your software/operations. I'm\n\u003e\u003e always interested to learn more about mempool and transaction-relay\n\u003e\u003e interactions with upper-layers and applications and to listen to feedback\n\u003e\u003e in those areas, and I guess a lot of other Bitcoin researchers/devs too. I\n\u003e\u003e know there have been a lot of concerns about full-rbf in the past, however\n\u003e\u003e I believe the Bitcoin ecosystem has matured a lot since then.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e I am not opposed to full-rbf; rather, I am opposed to the notion that\n\u003e\u003e full-rbf will solve all problems and the lack of basic options in Bitcoin\n\u003e\u003e Core to employ/disable different RBF policies. There is also a speculation\n\u003e\u003e about making full RBF default in an year which isn't relevant to discuss at\n\u003e\u003e this point without trying different RBF policies.\n\u003e\u003e\n\u003e\u003e I would suggest users to try Bitcoin Knots instead which already has an\n\u003e\u003e option to disable all RBF policies if required, opt-in and full RBF policy.\n\u003e\u003e This can also be done using GUI if not familiar with config option\n\u003e\u003e mempoolreplacement​.\n\u003e\u003e\n\u003e\u003e The rationale in PR #16171 was insufficient to justify removing it in the\n\u003e\u003e first place, had 2 NACKs and was reopened to merge it. Why bother with a\n\u003e\u003e few lines of code that may allow someone disable it if required in local\n\u003e\u003e mempool since it's only useful when a big percentage of miners utilize it\n\u003e\u003e and essentially underused according to the PR author? Developers should\n\u003e\u003e provide basic RBF policy options rather than attempting to define what\n\u003e\u003e constitutes a good policy and removing the ability to disable something\n\u003e\u003e when necessary.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e /dev/fd0\n\u003e\u003e\n\u003e\u003e Sent with Proton Mail \u003chttps://proton.me/\u003e secure email.\n\u003e\u003e\n\u003e\u003e ------- Original Message -------\n\u003e\u003e On Tuesday, June 14th, 2022 at 5:55 AM, Antoine Riard via bitcoin-dev \u003c\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e Hi list,\n\u003e\u003e\n\u003e\u003e Recent discussions among LN devs have brought back on the surface\n\u003e\u003e concerns about the security of multi-party funded transactions (coinjoins,\n\u003e\u003e dual-funded LN channels, on-chain DLCs, ...). It turns out there is a\n\u003e\u003e low-fruit, naive DoS vector playable against the funding flow of any such\n\u003e\u003e construction due to the lack of existent full-rbf transaction-relay\n\u003e\u003e topology on today's p2p network [0] [1]. While it does not consist in a\n\u003e\u003e direct loss of funds, if exploited well I think it's annoying enough to\n\u003e\u003e inflict significant timevalue loss or fee-bumping waste\n\u003e\u003e to the future providers or distributed swarm of users doing multi-party\n\u003e\u003e funded transactions. Of course, it can be fixed one layer above by\n\u003e\u003e introducing either fidelity bonds or a reliable centralized coordinator,\n\u003e\u003e though at the price of an overhead per-participant ressources cost and loss\n\u003e\u003e in system openness [1].\n\u003e\u003e\n\u003e\u003e For that reason, I believe it would be beneficial to the flourishing of\n\u003e\u003e multi-party funded transactions to fix the Dos vector by seeing a subset of\n\u003e\u003e the network running full-rbf and enabling propagation of honest multi-party\n\u003e\u003e transactions to the interested miners, replacing potential non-signaling\n\u003e\u003e double-spend from a malicious counterparty. Moving towards that direction,\n\u003e\u003e I've submitted a small patch against Bitcoin Core enabling it to turn on\n\u003e\u003e full-rbf as a policy, still under review [3]. The default setting stays\n\u003e\u003e **false**, i.e keeping opt-in RBF as a default replacement policy. I've\n\u003e\u003e started to run the patch on a public node at 146.190.224.15.\n\u003e\u003e\n\u003e\u003e If you're a node operator curious to play with full-rbf, feel free to\n\u003e\u003e connect to this node or spawn up a toy, public node yourself. There is a\n\u003e\u003e ##uafrbf libera chat if you would like information on the settings or\n\u003e\u003e looking for full-rbf friends (though that step could be automated in the\n\u003e\u003e future by setting up a dedicated network bit and reserving a few outbound\n\u003e\u003e slots for them).\n\u003e\u003e\n\u003e\u003e If you're a mining operator looking to increase your income, you might be\n\u003e\u003e interested to experiment with full-rbf as a policy. Indeed, in the future I\n\u003e\u003e believe the multi-party transactions issuers who need full-rbf to secure\n\u003e\u003e their funding flow should connect by default to full-rbf peers. One can\n\u003e\u003e conjecture that their transactions are likely to be more compelling in\n\u003e\u003e their feerate as their liquidity needs are higher than the simple\n\u003e\u003e transaction. For today, I think we have really few standards and bitcoin\n\u003e\u003e softwares relying on multi-party funded transactions [4].\n\u003e\u003e\n\u003e\u003e If you're a Bitcoin user or business and you don't like full-rbf, please\n\u003e\u003e express an opinion on how it might affect your software/operations. I'm\n\u003e\u003e always interested to learn more about mempool and transaction-relay\n\u003e\u003e interactions with upper-layers and applications and to listen to feedback\n\u003e\u003e in those areas, and I guess a lot of other Bitcoin researchers/devs too. I\n\u003e\u003e know there have been a lot of concerns about full-rbf in the past, however\n\u003e\u003e I believe the Bitcoin ecosystem has matured a lot since then.\n\u003e\u003e\n\u003e\u003e Any mistakes or missing context is my own.\n\u003e\u003e\n\u003e\u003e Cheers,\n\u003e\u003e Antoine\n\u003e\u003e\n\u003e\u003e [0] For more info about replace-by-fee, see\n\u003e\u003e https://bitcoinops.org/en/topics/replace-by-fee/\n\u003e\u003e\n\u003e\u003e [1] For more details about the DoS vector, see\n\u003e\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html\n\u003e\u003e\n\u003e\u003e [2] E.g I think it does not affect the Lightning Pool service, as there\n\u003e\u003e is a preliminary step where the participant funds are locked first in a\n\u003e\u003e 2-of-2 with the coordinator before being committed in the multi-party batch\n\u003e\u003e transaction.\n\u003e\u003e\n\u003e\u003e [3] https://github.com/bitcoin/bitcoin/pull/25353\n\u003e\u003e\n\u003e\u003e [4] E.g DLCs :\n\u003e\u003e https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transactions.md\n\u003e\u003e ; Lightning dual-funded channel :\n\u003e\u003e https://github.com/lightning/bolts/pull/851\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220621/721b7e8e/attachment-0001.html\u003e"}