[bitcoin-dev] Bitcoin Contracting Primitives WG 1st Meeting, Tuesday 15 Nov. 18:00 UTC
Hi list, After I have been asked offline the exact date when those meetings were actually starting, I'm proposing Tuesday 15th November at 18:00 UTC, i.e 2 weeks from now. Thinking about a monthly frequency for now (from my experience attending dlcspecs/lighnting specs meetings/core dev meetings in the past, weekly sounds too much, biweekly/monthly sounds better though dunno yet good frequency). If there is an incompatibility with another public engineering meeting in the Bitcoin space, let it know. We can talk about a better schedule during the 1st session [0]. Communication venue is #bitcoin-contracting-primitives-wg on Libera Chat [1]. Feel free to lurk already and ask questions. No consistent agenda beyond listening to every attendee their expectations, ideas, subjects of interests they would like to see happening with this new covenants/contracting primitives R process. If you have been working on a contracting protocols/side-chains/rollups/other use-cases that could benefit from extended Bitcoin contracting primitives, feel free to open an issue there: https://github.com/ariard/bitcoin-contracting-primitives-wg/issues Let it know if you have more questions or feedback. Cheers, Antoine [0] It would be great to have a schedule inclusive of most timezones we can, 18:00 UTC might be too early for Asian and Oceanic ones. Later, we start to be exclusive towards contributors in Eastern Europe. [1] There have been more voices suggesting jitsi/audio-based meetings rather than IRC. It's a cool format too, though coming with trade-offs. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] On mempool policy consistency
On Mon, Oct 31, 2022 at 06:21:08PM +0100, yancy via bitcoin-dev wrote: > > Protocol Devs, > > After reading through this email thread and BIP125, I'm curious if non-rbf > nodes will relay full-rbf transactions and vice versa. That is to say, if > only one non-rbf node exists on the network, however, every other node > implements full-rbf, will the transaction still be propagated? IE can we > always guarantee a path through the network for either transaction type no > matter what the combination of network policies are? 1) There are nodes that signal full-rbf, and preferentially peer to each other, thus ensuring good transaction propagation. The most recent patch to implement this is: https://github.com/bitcoin/bitcoin/pull/25600 There's enough peers running full-rbf that the last time I started up a new node on a fresh IP address, it happened to have a peer relaying full-rbf replacements to it. And of course, if people want full-rbf to work more reliably, it's very easy to just run some nodes with a large number of outgoing peers. Changing the hard-coded 8 outgoing peers to, say, 800, isn't very hard. 2) There's nothing special about a "full-rbf transaction" other than the fact that it's replacing a previously broadcast transaction that didn't signal replacement. There is not consensus over the mempool, so in certain cases non-full-rbf nodes will in fact broadcast replacements when they didn't happen to receive the "first" transaction first. The latter makes testing full-rbf a bit problematic, as if you don't take special measures to ensure good propagation a small % of the time the "replacement" transaction will in fact be the one that gets gets mined. > > Does fullrbf offer any benefits other than breaking zeroconf > > business practices? If so, what are they? > > I think AJ mentioned this earlier, but adding more configuration options > always increases code complexity, and with that, there is likely more > unforeseen bugs. However, there is a section of network participants that > rely on both types of transaction policy, so from my limited view-point, it > seems worth accommodating if possible. Since all the machinery to do replacemnt already exists, adding a full-rbf config flag is particularly trivial. It requires just a single line in the mempool code. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] On mempool policy consistency
Protocol Devs, After reading through this email thread and BIP125, I'm curious if non-rbf nodes will relay full-rbf transactions and vice versa. That is to say, if only one non-rbf node exists on the network, however, every other node implements full-rbf, will the transaction still be propagated? IE can we always guarantee a path through the network for either transaction type no matter what the combination of network policies are? Does fullrbf offer any benefits other than breaking zeroconf business practices? If so, what are they? I think AJ mentioned this earlier, but adding more configuration options always increases code complexity, and with that, there is likely more unforeseen bugs. However, there is a section of network participants that rely on both types of transaction policy, so from my limited view-point, it seems worth accommodating if possible. Cheers, -Yancy On 2022-10-31 17:25, Greg Sanders via bitcoin-dev wrote: Thanks for your full thoughts Suhas, The idea of V3 is that we're currently leaving fees on the table by allowing use-cases to be pinned, not that we like Lightning and we think miners should stop being profit maximizing somehow to enable safer/better layer 2 systems. If someone wants to bump fees for V3 transactions(or replace them!), there's a much simpler "API" to do so than in legacy policy land. The fact that it disallows more idiotic ways to add more total fees means wallets "shouldn't do that". If it ends up that V3 is disallowing too many "natural" ways to fee bump, that's a strike against the V3 idea and should be discussed. For 0-conf services we have potential thieves who are willing to *out-bid themselves* to have funds come back to themselves. It's not a "legitimate" use-case, but a rational one. I have mostly come around to not pushing for fullrbf due to the issues you mentioned, except taking away the option. Removing a quite-likely-incentive-compatible option from the software just encourages miners to adopt an additional patch if they ever deem it necessary to increase their revenue, even if that revenue is from hurting 0-conf businesses. Maybe putting/leaving in a default-false flag for disabling these "carve outs" is the least bad option. V3 usage patterns shouldn't crumble if a large majority of miners opt out, but 0-conf use cases crumble after a small percentage of adoption. To recap my thoughts: 1) I have put away my fullrbf hats, I will not advocate anyone running it as I think it doesn't really do anything useful for users who aren't trying to double-spend merchants. 2) Forcing miners to honor fees left on the table with respect to 0-conf, or forcing them to run a custom patchset to go around it, is a step backwards. Greg On Mon, Oct 31, 2022 at 11:03 AM Suhas Daftuar via bitcoin-dev wrote: AJ, Thanks for the thoughtful post. I think your observations about how we view mempool policy in the Bitcoin Core project, and how that seems to be changing in the discussions around `-mempoolfullrbf`, are on-point and provide a helpful baseline for considering future policy changes. For a long time I viewed fullrbf as an eventuality and I considered myself to be philosophically supportive of the idea. However, after giving this issue some thought in the past few weeks, I am reversing my thinking on this. Concretely, I will argue that we should continue to maintain a relay policy where replacements are rejected for transactions that don't opt-in to RBF (as described in BIP 125), and moreover, that we should remove the `-mempoolfullrbf` flag from Bitcoin Core's latest release candidate and not plan to release software with that flag, unless (or until) circumstances change on the network, which I'll discuss below. This is, of course, a nuanced topic, and among the considerations is a philosophy of how to think about the relay policy and configuration options that we make available in Bitcoin Core (a consideration that is perhaps unique to that project, but I think relevant for this mailing list). I'll start with some technical issues regarding the benefits of enabling fullrbf on the network. In the current BIP 125 regime, every time a transaction is created, a choice is made whether to subject the transaction to BIP 125's RBF rules or not (based on the sequence values of the inputs). So given that users can already opt-in to RBF, the benefit of a "fullrbf" network policy would be if, somehow, RBF users were still denied the benefits of RBF due to the existence of other transactions that don't opt-in. Along those lines, Antoine Riard brought up[1] a DoS vector that is available to someone who wants to interfere with multi-party funded transactions, and suggested that fullrbf would eliminate the problem. After exploring that question again in this thread (thanks to Greg Sanders for clarifying this to me), I understand that the issue is around ensuring that a multiparty (coinjoin-type) protocol is able to make eventual
Re: [bitcoin-dev] On mempool policy consistency
Thanks for your full thoughts Suhas, The idea of V3 is that we're currently leaving fees on the table by allowing use-cases to be pinned, not that we like Lightning and we think miners should stop being profit maximizing somehow to enable safer/better layer 2 systems. If someone wants to bump fees for V3 transactions(or replace them!), there's a much simpler "API" to do so than in legacy policy land. The fact that it disallows more idiotic ways to add more total fees means wallets "shouldn't do that". If it ends up that V3 is disallowing too many "natural" ways to fee bump, that's a strike against the V3 idea and should be discussed. For 0-conf services we have potential thieves who are willing to *out-bid themselves* to have funds come back to themselves. It's not a "legitimate" use-case, but a rational one. I have mostly come around to not pushing for fullrbf due to the issues you mentioned, except taking away the option. Removing a quite-likely-incentive-compatible option from the software just encourages miners to adopt an additional patch if they ever deem it necessary to increase their revenue, even if that revenue is from hurting 0-conf businesses. Maybe putting/leaving in a default-false flag for disabling these "carve outs" is the least bad option. V3 usage patterns shouldn't crumble if a large majority of miners opt out, but 0-conf use cases crumble after a small percentage of adoption. To recap my thoughts: 1) I have put away my fullrbf hats, I will not advocate anyone running it as I think it doesn't really do anything useful for users who aren't trying to double-spend merchants. 2) Forcing miners to honor fees left on the table with respect to 0-conf, or forcing them to run a custom patchset to go around it, is a step backwards. Greg On Mon, Oct 31, 2022 at 11:03 AM Suhas Daftuar via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > AJ, > > Thanks for the thoughtful post. I think your observations about how we > view mempool policy in the Bitcoin Core project, and how that seems to be > changing in the discussions around `-mempoolfullrbf`, are on-point and > provide a helpful baseline for considering future policy changes. > > For a long time I viewed fullrbf as an eventuality and I considered myself > to be philosophically supportive of the idea. However, after giving this > issue some thought in the past few weeks, I am reversing my thinking on > this. Concretely, I will argue that we should continue to maintain a relay > policy where replacements are rejected for transactions that don't opt-in > to RBF (as described in BIP 125), and moreover, that we should remove the > `-mempoolfullrbf` flag from Bitcoin Core’s latest release candidate and not > plan to release software with that flag, unless (or until) circumstances > change on the network, which I'll discuss below. > > This is, of course, a nuanced topic, and among the considerations is a > philosophy of how to think about the relay policy and configuration options > that we make available in Bitcoin Core (a consideration that is perhaps > unique to that project, but I think relevant for this mailing list). > > I'll start with some technical issues regarding the benefits of enabling > fullrbf on the network. In the current BIP 125 regime, every time a > transaction is created, a choice is made whether to subject the transaction > to BIP 125’s RBF rules or not (based on the sequence values of the > inputs). So given that users can already opt-in to RBF, the benefit of a > “fullrbf” network policy would be if, somehow, RBF users were still denied > the benefits of RBF due to the existence of other transactions that don’t > opt-in. > > Along those lines, Antoine Riard brought up[1] a DoS vector that is > available to someone who wants to interfere with multi-party funded > transactions, and suggested that fullrbf would eliminate the problem. > After exploring that question again in this thread (thanks to Greg Sanders > for clarifying this to me), I understand that the issue is around ensuring > that a multiparty (coinjoin-type) protocol is able to make eventual > progress, by having a candidate multiparty transaction either eventually > confirm or become conflicted with something that has been confirmed, in > which case the double-spend information could be used to start a new > coinjoin round with fewer participants. The concern Antoine and Greg have > brought up is that non-rbf transactions can persist in the mempool > ~indefinitely (at a low feerate and not subject to replacement) and > interfere with progress being made in a coinjoin protocol. > > However, it seems to me that similar problems exist for such a protocol > even in a fullrbf world, as we understand that term today. I mentioned the > ability for rbf “pinning” to interfere with relay of the multiparty > transaction (even if the conflicting transaction signals for RBF – a set of > large but low feerate conflicting transactions can persist in the
Re: [bitcoin-dev] On mempool policy consistency
AJ, Thanks for the thoughtful post. I think your observations about how we view mempool policy in the Bitcoin Core project, and how that seems to be changing in the discussions around `-mempoolfullrbf`, are on-point and provide a helpful baseline for considering future policy changes. For a long time I viewed fullrbf as an eventuality and I considered myself to be philosophically supportive of the idea. However, after giving this issue some thought in the past few weeks, I am reversing my thinking on this. Concretely, I will argue that we should continue to maintain a relay policy where replacements are rejected for transactions that don't opt-in to RBF (as described in BIP 125), and moreover, that we should remove the `-mempoolfullrbf` flag from Bitcoin Core’s latest release candidate and not plan to release software with that flag, unless (or until) circumstances change on the network, which I'll discuss below. This is, of course, a nuanced topic, and among the considerations is a philosophy of how to think about the relay policy and configuration options that we make available in Bitcoin Core (a consideration that is perhaps unique to that project, but I think relevant for this mailing list). I'll start with some technical issues regarding the benefits of enabling fullrbf on the network. In the current BIP 125 regime, every time a transaction is created, a choice is made whether to subject the transaction to BIP 125’s RBF rules or not (based on the sequence values of the inputs). So given that users can already opt-in to RBF, the benefit of a “fullrbf” network policy would be if, somehow, RBF users were still denied the benefits of RBF due to the existence of other transactions that don’t opt-in. Along those lines, Antoine Riard brought up[1] a DoS vector that is available to someone who wants to interfere with multi-party funded transactions, and suggested that fullrbf would eliminate the problem. After exploring that question again in this thread (thanks to Greg Sanders for clarifying this to me), I understand that the issue is around ensuring that a multiparty (coinjoin-type) protocol is able to make eventual progress, by having a candidate multiparty transaction either eventually confirm or become conflicted with something that has been confirmed, in which case the double-spend information could be used to start a new coinjoin round with fewer participants. The concern Antoine and Greg have brought up is that non-rbf transactions can persist in the mempool ~indefinitely (at a low feerate and not subject to replacement) and interfere with progress being made in a coinjoin protocol. However, it seems to me that similar problems exist for such a protocol even in a fullrbf world, as we understand that term today. I mentioned the ability for rbf “pinning” to interfere with relay of the multiparty transaction (even if the conflicting transaction signals for RBF – a set of large but low feerate conflicting transactions can persist in the mempool and make it difficult for the coinjoin transaction from confirming, at least without attaching a very large fee); and as Greg mentioned in a followup, the BIP 125 rule to only permit 100 transactions to be removed from the mempool at a time during a replacement can also be used to pin a coinjoin protocol in the same way as a non-rbf transaction today. It seems to me that what these multiparty protocols actually need is some sort of "maximal rbf" network policy: a way to guarantee that a transaction which should be desirable for a miner to mine would always get to a miner and considered for inclusion in a block, no matter what the state of node’s mempools on the network. While that sounds like a reasonable thing to want on its face (and worth working on), it's not how opt-in RBF works today, nor is it how transaction relay has ever conceptually worked. We have not, thus far, been able to come up with a total ordering on transaction desirability. Moreover, due to all the DoS issues that exist with transaction relay, there are plenty of seemingly legitimate ways to construct transactions that would not relay well on the network. Relay has only ever been a best-efforts concept, where we carve out a small subset of the entire transaction universe for which we try to optimize propagation. The idea behind this approach is that if every use case we can come up with has some way to achieve its goals using transactions that should (eventually) be able to relay, then users wouldn’t have much demand for transactions that would deviate from the supported policies, and we therefore shouldn’t need to worry too much about incentive compatibility concerns when it comes to transaction types that wouldn’t relay at all, even if they are high feerate. (And when those situations arise where the standard transactions do not accommodate some needed use case, developers typically work to define a policy that is compatible with our anti-DoS goals to support such use
