{"type":"rich","version":"1.0","author_name":"npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0m","author_url":"https://nostr.ae/npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0m","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-06-15\n📝 Original message:\u003e 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\nThe security of LN and other related systems are something like: \"given\nproper fees offered, can a transaction be mined within N blocks?\" You're\nsimply not allowed to out-bid your attacker in certain circumstances due to\ntoday's miner incentive-incompatible relay policies.\n\nThere is also a time-value dimension to this with other simpler systems\nwhere your funds can be locked up for potentially weeks for similar reasons.\n\n\u003e  ... arguments about how many people RBF being sufficient or not ...\n\nThe idea that we should only build robust systems after the broken ones are\nattacked is not a serious argument.\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\nThis is a strawman.\n\nFull-RBF is a simple, obvious, incentive-compatible step to getting closer\nto more robust layer two systems. Fixing the rest of the holes is for\nfuture proposals which are a bit more involved and definitely less mature.\n\n\u003e  would suggest users to try Bitcoin Knots instead\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\nIf Knots has these knobs, just use Knots rather than lobby all\nimplementations to have miner incentive incompatible knobs?\n\nCheers,\nGreg\n\nOn Wed, Jun 15, 2022 at 8:27 PM alicexbt via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\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 few 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 with full RBF? Or even if we add some users in\n\u003e it who could not signal for some reasons, do you think it would be anything\n\u003e 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\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220615/31d6050c/attachment-0001.html\u003e"}