> 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 a écrit : > Russel O'Connor recently opined > > 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 >> >