Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
Hello David, Thanks for the fast answer! It seems I missed the link to the PR, sorry for the confusion. I'm referring to the opt-in flag for full-RBF from #25353 (https://github.com/bitcoin/bitcoin/pull/25353). On Fri, Oct 7, 2022 at 2:21 PM David A. Harding wrote: > On 2022-10-07 06:20, Dario Sneidermanis via bitcoin-dev wrote: > > Hello list, > > > > I'm Dario, from Muun wallet [...] we've been reviewing the latest > > bitcoin core release > > candidate [...] we understood we had at least a year from the initial > > opt-in deployment until opt-out was deployed, giving us enough time to > > adapt > > Muun to the new policies. However, when reviewing the 24.0 release > > candidate > > just a few days ago, we realized that zero-conf apps (like Muun) must > > *immediately turn off* their zero-conf features. > > Hi Dario, > > I'm wondering if there's been some confusion. There are two RBF-related > items in the current release notes draft:[1] > > 1. "A new mempoolfullrbf option has been added, which enables the > mempool to accept transaction replacement without enforcing BIP125 > replaceability signaling. (#25353)" > > 2. "The -walletrbf startup option will now default to true. The wallet > will now default to opt-in RBF on transactions that it creates. > (#25610)" > > The first item (from PR #25353) does allow a transaction without a > BIP125 signal to be replaced, but this configuration option is set to > disabled by default.[2] There have been software forks of Bitcoin Core > since at least 2015 which have allowed replacement of non-signaling > transactions, so this option just makes that behavior a little bit more > accessible to users of Bitcoin Core. The "activation" of full-RBF after deployment works in a pretty interesting way: 1. If no miner is running full-RBF or there aren't easily accessible connected components of nodes running full-RBF connected to the miners, then full-RBF is mostly ineffective since replacements aren't relayed and/or mined. 2. There's a middle ground where *some* connected components of full-RBF nodes can relay and mine replacements, where some full-RBF nodes will be able to replace via full-RBF and some won't (depending on their peers). 3. With high enough adoption, the relay graph has enough density of full-RBF nodes that almost all full-RBF nodes can replace transactions via full-RBF. While there have been forks of Bitcoin Core (like Bitcoin Knots) running full-RBF for a while, today most nodes (by far) are running Bitcoin Core. So, Bitcoin Core adding an opt-in flag (ie. off by default) makes it easier to be picked up by most node operators. Making the flag opt-out (ie. on by default) would make it easier still. We are dealing with a gradient going from hard enough that we are still in 1, to easy enough that we get to 3. The question then is whether an opt-in flag for full-RBF will have enough adoption to get us from 1 to 2. If it isn't, then #25353 won't meet its objective of allowing nodes participating in multi-party funding protocols to assume that they can rely on full-RBF. If it is, then zero-conf applications will be at severe risk (per the logic in the initial email). ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
On Friday 07 October 2022 16:20:49 Dario Sneidermanis via bitcoin-dev wrote: > At the time, we understood we had at least a year from the initial opt-in > deployment until opt-out was deployed, giving us enough time to adapt Muun > to the new policies. Policies are a per-node decision, and cannot be relied on in general. Full RBF has been the default in Bitcoin Knots for years, and de facto viable for use on the network even longer. > However, when reviewing the 24.0 release candidate just > a few days ago, we realized that zero-conf apps (like Muun) must > *immediately turn off* their zero-conf features. RBF deals with UNconfirmed transactions, not zero-confirmed (Lightning). > I understand this wasn't the intention when designing the opt-in deployment > mechanism. Given this new information, do you see a path where we can delay > the opt-in deployment and find a safer way to deploy full-RBF? Full RBF has been available for users on an opt-in basis since at least 2013, long before BIP 125 was even conceived of. > We call zero-conf applications to entities that accept on-chain payments > from > *untrusted parties* and will sometimes deliver the paid-for product or > service > without waiting for the transaction to be included in a block. This is unsafe period. RBF does not make it any less unsafe. > All of these applications are receiving incoming on-chain transactions for > which > they don't control the inputs, and performing a risk analysis to decide > whether > they are ok with accepting the payment without confirmation. This is nothing but a false sense of security. Luke ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
David, Dario, The only other effort I'm aware of is https://github.com/bitcoin/bitcoin/pull/25600 , which as you can see, has no consensus yet, isn't in 24.0, so at earliest would be 25.0, even if somehow immediate resolution to the discussions were found. Cheers, Greg On Fri, Oct 7, 2022 at 1:21 PM David A. Harding via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On 2022-10-07 06:20, Dario Sneidermanis via bitcoin-dev wrote: > > Hello list, > > > > I'm Dario, from Muun wallet [...] we've been reviewing the latest > > bitcoin core release > > candidate [...] we understood we had at least a year from the initial > > opt-in deployment until opt-out was deployed, giving us enough time to > > adapt > > Muun to the new policies. However, when reviewing the 24.0 release > > candidate > > just a few days ago, we realized that zero-conf apps (like Muun) must > > *immediately turn off* their zero-conf features. > > Hi Dario, > > I'm wondering if there's been some confusion. There are two RBF-related > items in the current release notes draft:[1] > > 1. "A new mempoolfullrbf option has been added, which enables the > mempool to accept transaction replacement without enforcing BIP125 > replaceability signaling. (#25353)" > > 2. "The -walletrbf startup option will now default to true. The wallet > will now default to opt-in RBF on transactions that it creates. > (#25610)" > > The first item (from PR #25353) does allow a transaction without a > BIP125 signal to be replaced, but this configuration option is set to > disabled by default.[2] There have been software forks of Bitcoin Core > since at least 2015 which have allowed replacement of non-signaling > transactions, so this option just makes that behavior a little bit more > accessible to users of Bitcoin Core. Some developers have announced > their intention to propose enabling this option by default in a future > release, which I think is the behavior you're concerned about, but > that's not planned for the release of 24.0 to the best of my knowledge. > > The second item (from PR #25610) only affects Bitcoin Core's wallet, and > in particular transactions created with it through the RPC interface. > Those transactions will now default to signaling BIP125 replacability. > This option has been default false for many years for the RPC, but for > the GUI it's been default true since Bitcoin Core 0.16, released in > early 2018[3]. It's no different than another popular wallet beginning > to signal BIP125 support by default. > > In short, I don't think anything in Bitcoin Core 24.0 RC1 significantly > changes the current situation related to transaction replacability. All > it does is give Bitcoin Core RPC users by default the same settings long > used for GUI users and introduce an option that those who object to > non-signalled RBF will later be able to use to disable their relay of > non-signalled replacements. > > Does the above information resolve your concerns? > > Thanks, > > -Dave > > [1] > > https://github.com/bitcoin-core/bitcoin-devwiki/wiki/24.0-Release-Notes-draft > > [2] $ bin/bitcoind -help | grep -A3 mempoolfullrbf >-mempoolfullrbf > Accept transaction replace-by-fee without requiring > replaceability > signaling (default: 0) > > [3] > > https://bitcoincore.org/en/2018/02/26/release-0.16.0/#replace-by-fee-by-default-in-gui > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
On 2022-10-07 06:20, Dario Sneidermanis via bitcoin-dev wrote: Hello list, I'm Dario, from Muun wallet [...] we've been reviewing the latest bitcoin core release candidate [...] we understood we had at least a year from the initial opt-in deployment until opt-out was deployed, giving us enough time to adapt Muun to the new policies. However, when reviewing the 24.0 release candidate just a few days ago, we realized that zero-conf apps (like Muun) must *immediately turn off* their zero-conf features. Hi Dario, I'm wondering if there's been some confusion. There are two RBF-related items in the current release notes draft:[1] 1. "A new mempoolfullrbf option has been added, which enables the mempool to accept transaction replacement without enforcing BIP125 replaceability signaling. (#25353)" 2. "The -walletrbf startup option will now default to true. The wallet will now default to opt-in RBF on transactions that it creates. (#25610)" The first item (from PR #25353) does allow a transaction without a BIP125 signal to be replaced, but this configuration option is set to disabled by default.[2] There have been software forks of Bitcoin Core since at least 2015 which have allowed replacement of non-signaling transactions, so this option just makes that behavior a little bit more accessible to users of Bitcoin Core. Some developers have announced their intention to propose enabling this option by default in a future release, which I think is the behavior you're concerned about, but that's not planned for the release of 24.0 to the best of my knowledge. The second item (from PR #25610) only affects Bitcoin Core's wallet, and in particular transactions created with it through the RPC interface. Those transactions will now default to signaling BIP125 replacability. This option has been default false for many years for the RPC, but for the GUI it's been default true since Bitcoin Core 0.16, released in early 2018[3]. It's no different than another popular wallet beginning to signal BIP125 support by default. In short, I don't think anything in Bitcoin Core 24.0 RC1 significantly changes the current situation related to transaction replacability. All it does is give Bitcoin Core RPC users by default the same settings long used for GUI users and introduce an option that those who object to non-signalled RBF will later be able to use to disable their relay of non-signalled replacements. Does the above information resolve your concerns? Thanks, -Dave [1] https://github.com/bitcoin-core/bitcoin-devwiki/wiki/24.0-Release-Notes-draft [2] $ bin/bitcoind -help | grep -A3 mempoolfullrbf -mempoolfullrbf Accept transaction replace-by-fee without requiring replaceability signaling (default: 0) [3] https://bitcoincore.org/en/2018/02/26/release-0.16.0/#replace-by-fee-by-default-in-gui ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
Hello list, I'm Dario, from Muun wallet, a mobile non-custodial bitcoin wallet. For the past few days we've been reviewing the latest bitcoin core release candidate, and we found some troubling facts related to the opt-in full-RBF deployment. We first learned about the opt-in full-RBF proposal last June when it was announced on the mailing list. Closing the gap between the protocol's relay policies and the miner incentives is inevitable, so it was a welcomed addition. Furthermore, allowing transaction replacements that remove the opt-in RBF flag was deeply problematic. At the time, we understood we had at least a year from the initial opt-in deployment until opt-out was deployed, giving us enough time to adapt Muun to the new policies. However, when reviewing the 24.0 release candidate just a few days ago, we realized that zero-conf apps (like Muun) must *immediately turn off* their zero-conf features. I understand this wasn't the intention when designing the opt-in deployment mechanism. Given this new information, do you see a path where we can delay the opt-in deployment and find a safer way to deploy full-RBF? It'd be great for this deployment to be a success so that we can continue fixing the remaining relay policy problems, such as package relay and the RBF rules. Maybe we could go straight to an opt-out deployment locked by code at a certain height in the future to give time to everyone and, at the same time, avoid a huge mempool divergence event? Below is our analysis of how zero-conf apps break with opt-in full-RBF. I hope it helps. Cheers, Dario # How do zero-conf apps work While the workings and trade-offs of zero-conf applications might be known by many in this list, it's useful to define precisely how they work to understand how they break. We call zero-conf applications to entities that accept on-chain payments from *untrusted parties* and will sometimes deliver the paid-for product or service without waiting for the transaction to be included in a block. Some examples of zero-conf apps: - Muun's submarine swaps for outgoing lightning payments - Bitrefill's on-chain payments for gift cards and phone top-ups - Many bitcoin ATMs' on-chain deposits for selling bitcoin for cash (at least the two biggest bitcoin ATM manufacturers support this: Genesis Coin and General Byte) All of these applications are receiving incoming on-chain transactions for which they don't control the inputs, and performing a risk analysis to decide whether they are ok with accepting the payment without confirmation. In practice, this works because once the bitcoin P2P network has fully propagated a non-RBF transaction, you need the collaboration of a miner to replace it, which isn't easy to get today. Even though many of the biggest miners offer off-band transaction broadcasting services, they currently won't process conflicting transactions. Roughly, the risk analysis goes like this: 1. if an incoming transaction is RBF (direct or inherited) --> too risky, wait for 1 conf (or more) since it can be replaced at any time 2. if the payment is for an amount greater than X --> too risky, wait for 1 conf (or more), since the amount is worthy of a sophisticated attacker 3. wait for full(ish) propagation of the incoming transaction 4. if there's no double-spend attempt --> accept 0-conf As with any other risk analysis, there's always a false-negative detection rate, leading to an expected loss, which the zero-conf app should be willing to bear. Notice that the expected loss is tunable via the amount X in the above analysis. # Why are zero-conf apps not protected with an opt-in deployment Full-RBF adoption works on three different layers: - The transaction application layer - The transaction relaying layer - The transaction mining layer If an application wants to replace with full-RBF an *outgoing* transaction, it will need: - An upgraded node that opted into full-RBF, from which it can broadcast the replacement transaction - A connected component of upgraded nodes that opted into full-RBF, that can relay the replacement transaction - A miner in that connected component with an upgraded node that opted into full-RBF, that can mine the replacement transaction However, an application cannot control whether a replacement to an *incoming* transaction is relayed via full-RBF. As soon as a single application can generate replacements easily via full-RBF, all other applications have to assume that any incoming transaction from an untrusted party might be replaced via full-RBF. That is, for the application layer this is a forced upgrade. As soon as an unsophisticated attacker can use opt-in full-RBF, the risk analysis performed by zero-conf applications stops working because the transactions to analyze are all incoming transactions from untrusted parties. Since some wallets already implement cancel functionality for opt-in RBF transactions, enabling the same functionality for every
Re: [bitcoin-dev] On a new community process to specify covenants
Hi all, Following up my September's mail on the setting of a new decentralized, open and neutral community process dedicated to covenants R, a.k.a "Bitcoin Contracting Primitives WG", few updates. After collecting feedback on the adequate communication channel, a low access bar and pseudonymous participation sounds to be recurring criterias. As such, I would like to propose using IRC on Libera Chat. Opened the following chan: #bitcoin-contracting-primitives-wg If there are still strong likes for another communication channel, we can still consider it. For the 1st meeting date, I was thinking about the second week of November starting the 7th. About the day and time, we have the following list of Bitcoin open-source meetings happening across the ecosystem: - Bitcoin Core general developer meeting Thursday 19:00 UTC - Bitcoin Core wallet developer meeting Friday 19:00 UTC (every second week) - Bitcoin Core PR review club Wednesday 17:00 UTC - Lightning developer meeting Monday 20:00 UTC (bi-weekly, modulo weird Australian timezones details that I don't understand) - Core Lightning developer meeting Monday 20:00 UTC (every second week) - LDK developer meeting Monday 17:00 UTC (every second week) - LND PR review club Thursday 17:00 UTC (every second week) - LDK PR review club Tuesday 18:00 UTC (every second week) - DLC specs meeting Tuesday 19:00 CST (monthly) - LSP specs meeting Wednesday 10:00 UTC (every second week) This is a best effort to collect all the open-source engineering meetings across the ecosystem, though we might have more, feel free to point out the ones I'm forgetting. Minding all those meetings happenings and all the time zones, the usual times slots fitting most of the people are probably the ones between 16:00 UTC and 21:00 UTC. Looking forward to collecting what would be a good time slot for the happening of Bitcoin Contracting primitives WG. For the meeting frequency, I think we can start with a monthly frequency, then in function of the pace and sustained interest move to bi-weekly. No agenda, we'll see how things are evolving unconf style. In the process to collect and document all the known contracting protocol use-cases at: https://github.com/ariard/bitcoin-contracting-primitives-wg So far I've bookmarked the following list: - vaults - payment pools - channel factories - drivechains - eltoo channels - decentralized mining pools - scalable stateful contracts (e.g DLCs) - congestion control redux - non-interactive channels setups - state channels Though we're likely to see more emerge with time, feel free to point to the ones I'm forgetting. Recently, during a panel at a Bitcoin conference, I've been asked why such a primitives working group rather than a specialized WG on the use-case I'm mostly interested in (i.e payment pools). From my experience, the contracting primitives or covenant you're designing is more likely to be a function of the use-case properties you've in mind (e.g economic efficiency or flexibility), however it might not generalize well to the other contracting use-cases envisioned by a lot of other folks. One wishful thinking of setting up this R effort could yield one common contracting primitives toolchain servicing all the known use-cases. Though this is only wishful thinking and we'll see what happens, in fine Bitcoin development is kinda like jazz music, loosely structured, you launch the first few notes and then you listen to what the other musicians keep going on. Still open to more feedback on what the ideal Bitcoin contracting primitives WG would look like. Cheers, Antoine Le mer. 20 juil. 2022 à 16:42, Antoine Riard a écrit : > Hi, > > Discussions on covenants have been prolific and intense on this mailing > list and within the wider Bitcoin technical circles, I believe however > without succeeding to reach consensus on any new set of contracting > primitives satisfying the requirements of known covenant-enabled use-cases. > I think that's a fact to deplore as covenants would not only offer vast > extensions of the capabilities of Bitcoin as a system, i.e enabling new > types of multi-party contract protocols. But also empowering Bitcoin on its > fundamental value propositions of store of value (e.g by making vaults more > flexible) and payment system (e.g by making realistic channel > factories/payment pools). > > If we retain as a covenant definition, a spending constraint restricting > the transaction to which the spent UTXO can be spent, and enabling to > program contracts/protocols at the transaction-level instead of the > script-level, the list of Script primitives proposed during the last years > has grown large : ANYPREVOUT [0], CHECKSIGFROMSTACK [1], > CHECK_TEMPLATE_VERIFY [2], TAPROOT_LEAF_UPDATE_VERIFY [3], TXHASH [4], > PUSHTXDATA [5], CAT [6], EVICT [7], Grafroot delegation [8], SIGHASH_GROUP > [9], MERKLEBRANCHVERIFY [10] and more than I can't remember. Of course, all > the listed primitives are at different states of
Re: [bitcoin-dev] Packaged Transaction Relay
On Wed, Oct 05, 2022 at 09:32:29PM -0700, Eric Voskuil via bitcoin-dev wrote: > Protocol cannot be defined on an ad-hoc basis as a "courtesy" BIPs are a courtesy in the first place. There's no central authority to enforce some particular way of doing things. > - and it's not exactly a courtesy to keep yourself from getting dropped by > peers. It is not clear to me why such a comment would be accepted instead of > specifying this properly. If you think that the version restriction should be part of the BIP, why not do a pull request? The BIP is still marked as "Draft". > I doubt that anyone who's worked with it is terribly fond of Bitcoin's P2P > protocol versioning. I've spent some time on a proposal to update it, though > it hasn't been a priority. If anyone is interested in collaborating on it > please contact me directly. Bottlenecking a proposal on someone who doesn't see it as a priority doesn't seem smart? Here's what I think makes sense: https://github.com/ajtowns/bips/blob/202210-p2pfeatures/bip-p2pfeatures.mediawiki Cheers, aj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
