{"type":"rich","version":"1.0","author_name":"npub1c3j2v4ws7hf9sj2xkr4dale0z4htw7lup37qeh2wxll4pcvlg03qe2aw73","author_url":"https://nostr.ae/npub1c3j2v4ws7hf9sj2xkr4dale0z4htw7lup37qeh2wxll4pcvlg03qe2aw73","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-10-12\n📝 Original message:Hello Pieter,\n\nThanks for taking the time to comment! I'll answer inline.\n\nOn Wed, Oct 12, 2022 at 2:51 PM Pieter Wuille \u003cbitcoin-dev at wuille.net\u003e\nwrote:\n\u003e I certainly recognize that adding the flag is a likely step towards, over\n\u003e time, the full RBF policy becoming more widely adopted on the network.\nThat is\n\u003e presumably the reason why people are in favor of having the flag, even\ndefault\n\u003e off - including me. I believe that policy's adoption is inevitable\neventually,\n\u003e but the speed at which that is achieved is certainly a function of\n\u003e availability and adopted of software which provides the option.\n\nAs stated in the original posting, I believe too that a full-RBF network is\nnot\nonly inevitable but also desirable. Miner incentives will eventually win,\nso we\nshould address them before they fully kick in (ie. before transaction fees\nbecome a meaningful portion of the block reward).\n\n\u003e So I have a hard time imagining how it would change anything\n*immediately* on\n\u003e the network at large (without things like default on and/or preferential\n\u003e peering, ...), but I still believe it's an important step.\n\nNotice that I'm not saying this changes anything immediately on the network\nat\nlarge. In fact, it is unlikely that the opt-in flag alone would be enough to\nmigrate the network at large to full-RBF.\n\nThere's a real possibility that, after deployment of the opt-in flag,\neither no\nmeaningful hashing power adopts it or no connected component of\ntransaction-relaying nodes adopts it. If that's the case, the deployment\nwon't\nhelp nodes participating in multi-party funded transactions protect against\nthe\nclass of attacks described in [1] (which was, as I understand, the original\nintention of #25353).\n\nIf that's not the case, it means that at least some meaningful hashing power\nadopted it and that there exist some connected components of\ntransaction-relaying nodes that adopted it. This is certainly far from\nhaving\nwide adoption of full-RBF in the network at large. However, once we reach\nthat\nminimal level of adoption in the mining and relaying layers, any node on a\nfull-RBF connected component can send an on-chain payment to an application\nand\nthen get a replacement mined. That is, applications that accept incoming\non-chain payments from untrusted parties can be immediately exposed to\nfull-RBF\ntransaction replacements, even if they didn't opt into full-RBF in their\nnodes.\n\nIn an adversarial setting, such as the one for zero-conf applications (as\ndefined in the original posting), this increases the risk of an attack\nsubstantially, making the entire strategy moot.\n\n\u003e In my view, it is just what I said: a step towards getting full RBF on the\n\u003e network, by allowing experimentation and socializing the notion that\n\u003e developers believe it is time.\n\nThose are worthy goals. I believe we can design a deployment strategy for\nfull-RBF that takes them into account and, at the same time, gives a clear\ntimeline for any affected application to adapt.\n\nThis could be one such proposal:\n\n1. We activate opt-in full-RBF on testnet now.\n2. We commit now (in the code) to a block height in the future at which\nopt-out\n   full-RBF will activate on mainnet.\n\nThe first point will allow for experimentation and give a testing ground to\nall\naffected applications. The second point socializes the notion that\ndevelopers\nbelieve it is time, giving a clear message and timeline for anyone affected\nto\nadapt. It also has the benefit that many more nodes will have upgraded by\nthe\ntime we reach the activation block height, making the transition to a\nfull-RBF\nnetwork much more predictable and easy to reason about.\n\nThere's an argument to be made that the miner incentive incompatibility\nproblem\nof a non-full-RBF network gets measurably worse at the time of the next\nhalving.\nTo fix this, we could choose any block height before that, giving a clear\nand\npredictable transition timeline.\n\n[1]\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html\n\nOn Wed, Oct 12, 2022 at 1:11 PM Pieter Wuille \u003cbitcoin-dev at wuille.net\u003e\nwrote:\n\n\u003e On Wednesday, October 12th, 2022 at 1:42 AM, Anthony Towns \u003c\n\u003e aj at erisian.com.au\u003e wrote:\n\u003e\n\u003e \u003e On Tue, Oct 11, 2022 at 04:18:10PM +0000, Pieter Wuille via bitcoin-dev\n\u003e wrote:\n\u003e \u003e\n\u003e \u003e \u003e On Friday, October 7th, 2022 at 5:37 PM, Dario Sneidermanis via\n\u003e bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:\n\u003e \u003e \u003e\n\u003e \u003e \u003e \u003e Thanks for the fast answer! It seems I missed the link to the PR,\n\u003e sorry for the\n\u003e \u003e \u003e \u003e confusion. I'm referring to the opt-in flag for full-RBF from #25353\n\u003e \u003e \u003e \u003e (https://github.com/bitcoin/bitcoin/pull/25353).\n\u003e \u003e \u003e \u003e It is not clear to me why you believe the merging of this particular\n\u003e pull request poses an immediate risk to you.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e Did you see the rest of Dario's reply, bottom-posted after the quoted\n\u003e \u003e text? Namely:\n\u003e\n\u003e Oh, my mail client for some reason chose to hide all that. Dario, I'm\n\u003e sorry for missing this; I see now that you were certainly aware of what the\n\u003e PR under consideration did.\n\u003e\n\u003e Further comments inline.\n\u003e\n\u003e \u003e On Fri, Oct 07, 2022 at 06:37:38PM -0300, Dario Sneidermanis via\n\u003e\n\u003e \u003e \u003e The question then is whether an opt-in flag for full-RBF will have\n\u003e enough\n\u003e \u003e \u003e adoption to get us from 1 to 2. If it isn't, then #25353 won't meet its\n\u003e \u003e \u003e objective of allowing nodes participating in multi-party funding\n\u003e protocols\n\u003e \u003e \u003e to assume that they can rely on full-RBF. If it is, then zero-conf\n\u003e applications\n\u003e \u003e \u003e will be at severe risk (per the logic in the initial email).\n\u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e That logic seems reasonably sound to me:\n\u003e \u003e\n\u003e \u003e - if adding the option does nothing, then there's no point adding it,\n\u003e \u003e and no harm in restricting it to test nets only\n\u003e \u003e\n\u003e \u003e - if adding the option does do something, then businesses using zero-conf\n\u003e \u003e need to react immediately, or will go from approximately zero risk of\n\u003e \u003e losing funds, to substantial risk\n\u003e \u003e\n\u003e \u003e (I guess having the option today may allow you to manually switch your\n\u003e \u003e node over to supporting fullrbf in future when the majority of the\n\u003e network\n\u003e \u003e supports it, without needing to do an additional upgrade in the meantime;\n\u003e \u003e but that seems like a pretty weak benefit)\n\u003e\n\u003e I certainly recognize that adding the flag is a likely step towards, over\n\u003e time, the full RBF policy becoming more widely adopted on the network. That\n\u003e is presumably the reason why people are in favor of having the flag, even\n\u003e default off - including me. I believe that policy's adoption is inevitable\n\u003e eventually, but the speed at which that is achieved is certainly a function\n\u003e of availability and adopted of software which provides the option.\n\u003e\n\u003e That said, I think it's a bit of a jump to conclude that the only two\n\u003e options are that either the existence of the flag either has no effect at\n\u003e all, or poses an immediate threat to those relying on its absence. In my\n\u003e view, it is just what I said: a step towards getting full RBF on the\n\u003e network, by allowing experimentation and socializing the notion that\n\u003e developers believe it is time. So I have a hard time imagining how it would\n\u003e change anything *immediately* on the network at large (without things like\n\u003e default on and/or preferential peering, ...), but I still believe it's an\n\u003e important step.\n\u003e\n\u003e Cheers,\n\u003e\n\u003e --\n\u003e Pieter\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221012/5280640b/attachment-0001.html\u003e"}