We cannot prevent people from choosing to take an action based on an unconfirmed transaction. Even though it is trivial to have a double-spending transaction confirmed, accepting a 0-conf tx can be rational in many cases. 0-conf can be interpreted as the customer signaling their 'intent to pay', and where there is an established relationship between customer and merchant, or where there merchant is providing a cancelable e-service, signaling intent may be enough. These use cases do not depend on making it difficult for the user to attempt to double-spend the merchant.
Bitcoin is a system designed around a consensus on the blockchain, not the mempool. I am in favor of providing the spender of bitcoins with all possible tools and methods to help them submit their transactions - double-spending or not - to miners for consideration. More than making RBF the default, I would prefer to see nodes forward any transaction conflicting transaction, so long as it has a higher fee. Is there a reason this would be undesirable? Corey On Sat, Jun 26, 2021 at 3:00 PM Jeremy via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > If the parties trust each other, rbf is still opt-in. Just don't do it? > > On Sat, Jun 26, 2021, 9:30 AM Billy Tetrud via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> > services providers are offering zero-conf channels, where you can >> start to spend instantly [0]. I believe that's an interesting usage >> >> I agree those are interesting and useful cases. I suppose I should >> clarify that when I asked if bitcoin should continue supporting 0-conf >> transactions, I meant: should we make design decisions based on whether it >> makes raw 0-conf transactions more or less difficult to double spend on? I >> do think 0-conf transactions can be useful in situations where there is >> some level of trust (either direct trust between the interacting parties, >> or disperse trust that most people won't try to double spend, perhaps >> because the transaction is small or their identity is tied to it). Fidelity >> bonds sound like an interesting way to mitigate sybil attacks in a >> reputation system. >> >> On Thu, Jun 24, 2021 at 5:23 PM Antoine Riard <antoine.ri...@gmail.com> >> wrote: >> >>> > Do we as a community want to support 0-conf payments in any way at this >>> > point? It seems rather silly to make software design decisions to >>> > accommodate 0-conf payments when there are better mechanisms for fast >>> > payments (ie lightning). >>> >>> Well, we have zero-conf LN channels ? Actually, Lightning channel >>> funding transactions should be buried under a few blocks, though few >>> services providers are offering zero-conf channels, where you can start to >>> spend instantly [0]. I believe that's an interesting usage, though IMHO as >>> mentioned we can explore different security models to make 0-conf safe >>> (reputation/fidelity-bond). >>> >>> > One question I have is: how does software generally inform the user >>> about >>> 0-conf payment detection? >>> >>> Yes generally it's something like an "Unconfirmed" annotation on >>> incoming txn, though at least this is what Blockstream Green or Electrum >>> are doing. >>> >>> > But I >>> suppose it would depend on how often 0-conf is used in the bitcoin >>> ecosystem at this point, which I don't have any data on. >>> >>> There are few Bitcoin services well-known to rely on 0-conf. Beyond how >>> much of the Bitcoin traffic is tied to a 0-conf is a hard question, a lot >>> of 0-confs service providers are going to be reluctant to share the >>> information, for a really good reason you will learn a subset of their >>> business volumes. >>> >>> I'll see if I can come up with some Fermi estimation on this front. >>> >>> [0] https://www.bitrefill.com/thor-turbo-channels/ >>> >>> Le mer. 16 juin 2021 à 20:58, Billy Tetrud <billy.tet...@gmail.com> a >>> écrit : >>> >>>> Russel O'Connor recently opined >>>> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019061.html> >>>> that RBF should be standard treatment of all transactions, rather than as a >>>> transaction opt-in/out. I agree with that. Any configuration in a >>>> transaction that has not been committed into a block yet simply can't be >>>> relied upon. Miners also have a clear incentive to ignore RBF rules and >>>> mine anything that passes consensus. At best opting out of RBF is a weak >>>> defense, and at worst it's simply a false sense of security that is likely >>>> to actively lead to theft events. >>>> >>>> Do we as a community want to support 0-conf payments in any way at this >>>> point? It seems rather silly to make software design decisions to >>>> accommodate 0-conf payments when there are better mechanisms for fast >>>> payments (ie lightning). >>>> >>>> One question I have is: how does software generally inform the user >>>> about 0-conf payment detection? Does software generally tell the user >>>> something along the lines of "This payment has not been finalized yet. All >>>> recipients should wait until the transaction has at least 1 confirmation, >>>> and most recipients should wait for 6 confirmations" ? I think unless we >>>> pressure software to be very explicit about what counts as finality, users >>>> will simply continue to do what they've always done. Rolling out this >>>> policy change over the course of a year or two seems fine, no need to rush. >>>> But I suppose it would depend on how often 0-conf is used in the bitcoin >>>> ecosystem at this point, which I don't have any data on. >>>> >>>> On Tue, Jun 15, 2021 at 10:00 AM Antoine Riard via bitcoin-dev < >>>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>>> >>>>> Hi, >>>>> >>>>> I'm writing to propose deprecation of opt-in RBF in favor of full-RBF >>>>> as the Bitcoin Core's default replacement policy in version 24.0. As a >>>>> reminder, the next release is 22.0, aimed for August 1st, assuming >>>>> agreement is reached, this policy change would enter into deployment phase >>>>> a year from now. >>>>> >>>>> Even if this replacement policy has been deemed as highly >>>>> controversial a few years ago, ongoing and anticipated changes in the >>>>> Bitcoin ecosystem are motivating this proposal. >>>>> >>>>> # RBF opt-out as a DoS Vector against Multi-Party Funded Transactions >>>>> >>>>> As explained in "On Mempool Funny Games against Multi-Party Funded >>>>> Transactions'', 2nd issue [0], an attacker can easily DoS a multi-party >>>>> funded transactions by propagating an RBF opt-out double-spend of its >>>>> contributed input before the honest transaction is broadcasted by the >>>>> protocol orchester. DoSes are qualified in the sense of either an attacker >>>>> wasting timevalue of victim's inputs or forcing exhaustion of the >>>>> fee-bumping reserve. >>>>> >>>>> This affects a series of Bitcoin protocols such as Coinjoin, onchain >>>>> DLCs and dual-funded LN channels. As those protocols are still in the >>>>> early >>>>> phase of deployment, it doesn't seem to have been executed in the wild for >>>>> now. That said, considering that dual-funded are more efficient from a >>>>> liquidity standpoint, we can expect them to be widely relied on, once >>>>> Lightning enters in a more mature phase. At that point, it should become >>>>> economically rational for liquidity service providers to launch those DoS >>>>> attacks against their competitors to hijack user traffic. >>>>> >>>>> Beyond that, presence of those DoSes will complicate the design and >>>>> deployment of multi-party Bitcoin protocols such as payment >>>>> pools/multi-party channels. Note, Lightning Pool isn't affected as there >>>>> is >>>>> a preliminary stage where batch participants are locked-in their funds >>>>> within an account witnessScript shared with the orchestrer. >>>>> >>>>> Of course, even assuming full-rbf, propagation of the multi-party >>>>> funded transactions can still be interfered with by an attacker, simply >>>>> broadcasting a double-spend with a feerate equivalent to the honest >>>>> transaction. However, it tightens the attack scenario to a scorched earth >>>>> approach, where the attacker has to commit equivalent fee-bumping reserve >>>>> to maintain the pinning and might lose the "competing" fees to miners. >>>>> >>>>> # RBF opt-out as a Mempools Partitions Vector >>>>> >>>>> A longer-term issue is the risk of mempools malicious partitions, >>>>> where an attacker exploits network topology or divergence in mempools >>>>> policies to partition network mempools in different subsets. From then a >>>>> wide range of attacks can be envisioned such as package pinning [1], >>>>> artificial congestion to provoke LN channels closure or manipulation of >>>>> fee-estimator's feerate (the Core's one wouldn't be affected as it relies >>>>> on block confirmation, though other fee estimators designs deployed across >>>>> the ecosystem are likely going to be affected). >>>>> >>>>> Traditionally, mempools partitions have been gauged as a spontaneous >>>>> outcome of a distributed systems like Bitcoin p2p network and I'm not >>>>> aware >>>>> it has been studied in-depth for adversarial purposes. Though, deployment >>>>> of second-layer >>>>> protocols, heavily relying on sanity of a local mempool for >>>>> fee-estimation and robust propagation of their time-sensitive transactions >>>>> might lead to reconsider this position. Acknowledging this, RBF opt-out is >>>>> a low-cost partitioning tool, of which the existence nullifies most of >>>>> potential progresses to mitigate malicious partitioning. >>>>> >>>>> >>>>> To resume, opt-in RBF doesn't suit well deployment of robust >>>>> second-layers protocol, even if those issues are still early and deserve >>>>> more research. At the same time, I believe a meaningful subset of the >>>>> ecosystem are still relying >>>>> on 0-confs transactions, even if their security is relying on far >>>>> weaker assumptions (opt-in RBF rule is a policy rule, not a consensus one) >>>>> [2] A rapid change of Core's mempool rules would be harming their quality >>>>> of services and should be >>>>> weighed carefully. On the other hand, it would be great to nudge them >>>>> towards more secure handling of their 0-confs flows [3] >>>>> >>>>> Let's examine what could be deployed ecosystem-wise as enhancements to >>>>> the 0-confs security model. >>>>> >>>>> # Proactive security models : Double-spend Monitoring/Receiver-side >>>>> Fee-Topping with Package Relay >>>>> >>>>> From an attacker viewpoint, opt-in RBF isn't a big blocker to >>>>> successful double-spends. Any motivated attacker can modify Core to >>>>> mass-connect to a wide portion of the network, announce txA to this >>>>> subset, >>>>> announce txA' to the >>>>> merchant. TxA' propagation will be encumbered by the >>>>> privacy-preserving inventory timers >>>>> (`OUTBOUND_INVENTORY_BROADCAST_INTERVAL`), of which an attacker has no >>>>> care >>>>> to respect. >>>>> >>>>> To detect a successful double-spend attempt, a Bitcoin service should >>>>> run few full-nodes with well-spread connection graphs and unlinkable >>>>> between them, to avoid being identified then maliciously partitioned from >>>>> the rest of the network. >>>>> >>>>> I believe this tactic is already deployed by few Bitcoin services, and >>>>> even one can throw flame at it because it over consumes network resources >>>>> (bandwidth, connection slots, ...), it does procure a security advantage >>>>> to >>>>> the ones doing it. >>>>> >>>>> One further improvement on top of this protection could be to react >>>>> after the double-spend detection by attaching a CPFP to the merchant >>>>> transaction, with a higher package feerate than the double-spend. Expected >>>>> deployment of package-relay as a p2p mechanism/mempool policy in Bitcoin >>>>> Core should enable it to do so. >>>>> >>>>> # Reactive security models : EconomicReputation-based Compensations >>>>> >>>>> Another approach could be to react after the fact if a double-spend >>>>> has been qualified. If the sender is already known to the service >>>>> provider, >>>>> the service account can be slashed. If the sender is a low-trusted >>>>> counterparty to the merchant, "side-trust" models could be relied on. For >>>>> e.g a LN pubkey with a stacked reputation from your autopilot, LSATs, >>>>> stake >>>>> certificates, a HTLC-as-a-fidelity-bond, ... The space is quite wide there >>>>> but I foresee those trust-minimized, decentralized solutions being adopted >>>>> by the LN ecosystem to patch the risks when you enter in a channel/HTLC >>>>> operation with an anonymous counterparty. >>>>> >>>>> What other cool new tools could be considered to enhance 0-confs >>>>> security ? >>>>> >>>>> To conclude, let's avoid replaying the contentious threads of a few >>>>> years ago. What this new thread highlights is the fact that a transaction >>>>> relay/mempool acceptance policy might be beneficial to some class of >>>>> already-deployed >>>>> Bitcoin applications while being detrimental to newer ones. How do we >>>>> preserve the current interests of 0-confs users while enabling upcoming >>>>> interests of fancy L2s to flourish is a good conversation to have. I >>>>> think. >>>>> >>>>> If there is ecosystem agreement on switching to full-RBF, but 0.24 >>>>> sounds too early, let's defer it to 0.25 or 0.26. I don't think Core has a >>>>> consistent deprecation process w.r.t to policy rules heavily relied-on by >>>>> Bitcoin users, if we do so let sets a precedent satisfying as many folks >>>>> as >>>>> we can. >>>>> >>>>> Cheers, >>>>> Antoine >>>>> >>>>> [0] >>>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html >>>>> >>>>> [1] See scenario 3 : >>>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html >>>>> >>>>> [2] >>>>> https://github.com/bitcoin/bitcoin/pull/10823#issuecomment-466485121 >>>>> >>>>> [3] And the LN ecosystem does have an interest to fix zero-confs >>>>> security, if "turbo-channels"-like become normalized for mobile nodes >>>>> _______________________________________________ >>>>> 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 >> > _______________________________________________ > 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
