Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 99C82C000E for ; Sat, 26 Jun 2021 19:00:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 71A7C4037A for ; Sat, 26 Jun 2021 19:00:19 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKHgv35mZFR5 for ; Sat, 26 Jun 2021 19:00:16 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by smtp4.osuosl.org (Postfix) with ESMTPS id 968E94036D for ; Sat, 26 Jun 2021 19:00:16 +0000 (UTC) Received: from mail-io1-f49.google.com (mail-io1-f49.google.com [209.85.166.49]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 15QJ0EgU030572 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sat, 26 Jun 2021 15:00:14 -0400 Received: by mail-io1-f49.google.com with SMTP id a6so16809438ioe.0 for ; Sat, 26 Jun 2021 12:00:14 -0700 (PDT) X-Gm-Message-State: AOAM531egv6ZLheJg9TqLp0RIBsw2TVAYUISpcnDjj9DiaMCPLGg5zZv +TvS4fTEctH/fmaNPGznbs59GS8dG5z61cJBrZw= X-Google-Smtp-Source: ABdhPJzF0aJZKz84JTclWqLznIyifh40L6HTrtRRAMUQex7RrNfYK6xYKW8fdzGyrzO70pGZtX6zVIbJZ/8nnsajYPg= X-Received: by 2002:a05:6602:737:: with SMTP id g23mr2228874iox.49.1624734014104; Sat, 26 Jun 2021 12:00:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeremy Date: Sat, 26 Jun 2021 12:00:02 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Billy Tetrud , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000c3ec8405c5afddc7" Subject: Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2021 19:00:19 -0000 --000000000000c3ec8405c5afddc7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 star= t > to spend instantly [0]. I believe that's an interesting usage > > I agree those are interesting and useful cases. I suppose I should clarif= y > that when I asked if bitcoin should continue supporting 0-conf > transactions, I meant: should we make design decisions based on whether i= t > 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). Fideli= ty > 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 > wrote: > >> > Do we as a community want to support 0-conf payments in any way at thi= s >> > 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 fundin= g >> 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 incomin= g >> txn, though at least this is what Blockstream Green or Electrum are doin= g. >> >> > 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 lo= t >> 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 =C3=A0 20:58, Billy Tetrud = a >> =C3=A9crit : >> >>> 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 b= e >>> 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 wea= k >>> defense, and at worst it's simply a false sense of security that is lik= ely >>> 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 confirmatio= n, >>> and most recipients should wait for 6 confirmations" ? I think unless w= e >>> pressure software to be very explicit about what counts as finality, us= ers >>> 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 r= ush. >>> But I suppose it would depend on how often 0-conf is used in the bitcoi= n >>> 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 p= hase >>>> a year from now. >>>> >>>> Even if this replacement policy has been deemed as highly controversia= l >>>> a few years ago, ongoing and anticipated changes in the Bitcoin ecosys= tem >>>> 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-part= y >>>> 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 atta= cker >>>> 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 beco= me >>>> 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 the= re 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, simpl= y >>>> broadcasting a double-spend with a feerate equivalent to the honest >>>> transaction. However, it tightens the attack scenario to a scorched ea= rth >>>> approach, where the attacker has to commit equivalent fee-bumping rese= rve >>>> 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, wher= e >>>> an attacker exploits network topology or divergence in mempools polici= es to >>>> partition network mempools in different subsets. From then a wide rang= e 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 rel= ies >>>> on block confirmation, though other fee estimators designs deployed ac= ross >>>> 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, deploym= ent >>>> of second-layer >>>> protocols, heavily relying on sanity of a local mempool for >>>> fee-estimation and robust propagation of their time-sensitive transact= ions >>>> might lead to reconsider this position. Acknowledging this, RBF opt-ou= t 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 deser= ve >>>> 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 qual= ity >>>> 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 su= bset, >>>> announce txA' to the >>>> merchant. TxA' propagation will be encumbered by the privacy-preservin= g >>>> inventory timers (`OUTBOUND_INVENTORY_BROADCAST_INTERVAL`), of which a= n >>>> 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 f= rom >>>> 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 resour= ces >>>> (bandwidth, connection slots, ...), it does procure a security advanta= ge 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. Expe= cted >>>> deployment of package-relay as a p2p mechanism/mempool policy in Bitco= in >>>> 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 ha= s >>>> 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 t= here >>>> but I foresee those trust-minimized, decentralized solutions being ado= pted >>>> by the LN ecosystem to patch the risks when you enter in a channel/HTL= C >>>> 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 transact= ion >>>> 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 upcomin= g >>>> interests of fancy L2s to flourish is a good conversation to have. I t= hink. >>>> >>>> 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 h= as 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 fol= ks as >>>> we can. >>>> >>>> Cheers, >>>> Antoine >>>> >>>> [0] >>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003= 033.html >>>> >>>> [1] See scenario 3 : >>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/00= 2758.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 > --000000000000c3ec8405c5afddc7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If the parties trust each other, rbf is still opt-in. Jus= t don't do it?

On Sat, Jun 26, 2021, 9:30 AM Billy Tetrud via bitcoin-de= v <bitcoin-dev@= lists.linuxfoundation.org> wrote:
>=C2=A0 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 c= larify that when I asked if bitcoin should continue supporting 0-conf trans= actions, 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 th= ink 0-conf transactions=C2=A0can be useful in situations where there is som= e level of trust (either direct trust between the interacting parties, or d= isperse trust that most people won't try to double spend, perhaps becau= se the transaction is small or their identity is tied to it). Fidelity bond= s sound like an interesting way to mitigate=C2=A0sybil attacks in a reputat= ion system.

On Thu, Jun 24, 2021 at 5:23 PM Antoine Riard <an= toine.riard@gmail.com> wrote:
> Do we as a community want to sup= port 0-conf payments in any way at this
> point? It seems rather sill= y to make software design decisions to
> accommodate 0-conf payments = when there are better mechanisms for fast
> payments (ie lightning).<= br>
Well, we have zero-conf LN channels ? Actually, Lightning channel fu= nding transactions should be buried under a few blocks, though few services= providers are offering zero-conf channels, where you can start to spend in= stantly [0]. I believe that's an interesting usage, though IMHO as ment= ioned we can explore different security models to make 0-conf safe (reputat= ion/fidelity-bond).

> One question I have is: how does software g= enerally inform the user about
0-conf payment detection?

Yes gene= rally it's something like an "Unconfirmed" annotation on inco= ming txn, though at least this is what Blockstream Green or Electrum are do= ing.

> But I
suppose it would depend on how often 0-conf is us= ed in the bitcoin
ecosystem at this point, which I don't have any da= ta 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 questi= on, a lot of 0-confs service providers are going to be reluctant to share t= he information, for a really good reason you will learn a subset of their b= usiness volumes.

I'll see if I can come up with some Fermi estim= ation on this front.

[0] https://www.bitrefill.= com/thor-turbo-channels/

Le=C2=A0mer. 16 juin 2021 =C3=A0=C2=A020:58= , Billy Tetrud <billy.tetrud@gmail.com> a =C3=A9crit=C2=A0:
= Russel O'Connor rec= ently opined that RBF should=C2=A0be standard treatment of all transact= ions, rather than as a transaction opt-in/out. I agree with that. Any confi= guration in a transaction that has not been committed into a block yet simp= ly can't be relied upon. Miners also have a clear incentive to ignore R= BF 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=C2=A0lead to theft events.=C2=A0

Do we as a community want to support 0-conf payments in any way at = this point? It seems rather silly=C2=A0to make software design decisions to= accommodate=C2=A00-conf payments when there are better mechanisms for fast= payments (ie lightning).=C2=A0

One question I hav= e is: how does software generally inform the user about 0-conf payment dete= ction? Does software generally tell the user something along the lines of &= quot;This payment has not been finalized yet. All recipients should wait un= til 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 c= ourse 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.=C2=A0

On Tue, Jun 15, 2021 at 10:0= 0 AM Antoine Riard via bitcoin-dev <bitcoin-dev@lists= .linuxfoundation.org> wrote:
Hi,

I'm writing to pro= pose 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 rele= ase is 22.0, aimed for August 1st, assuming agreement is reached, this poli= cy change would enter into deployment phase a year from now.

Even i= f this replacement policy has been deemed as highly controversial a few yea= rs ago, ongoing and anticipated changes in the Bitcoin ecosystem are motiva= ting this proposal.

# RBF opt-out as a DoS Vector against Multi-Part= y Funded Transactions

As explained in "On Mempool Funny Games a= gainst Multi-Party Funded Transactions'', 2nd issue [0], an attacke= r can easily DoS a multi-party funded transactions by propagating an RBF op= t-out double-spend of its contributed input before the honest transaction i= s broadcasted by the protocol orchester. DoSes are qualified in the sense o= f either an attacker wasting timevalue of victim's inputs or forcing ex= haustion of the fee-bumping =C2=A0reserve.

This affects a series of = Bitcoin protocols such as Coinjoin, onchain DLCs and dual-funded LN channel= s. As those protocols are still in the early phase of deployment, it doesn&= #39;t seem to have been executed in the wild for now.=C2=A0 That said, cons= idering 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 ma= ture phase. At that point, it should become economically rational for liqui= dity service providers to launch those DoS attacks against their competitor= s 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 affec= ted 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 funde= d transactions can still be interfered with by an attacker, simply broadcas= ting a double-spend with a feerate equivalent to the honest transaction. Ho= wever, it tightens the attack scenario to a scorched earth approach, where = the attacker has to commit equivalent fee-bumping reserve to maintain the p= inning and might lose the "competing" fees to miners.

# RB= F 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 i= n different subsets. From then a wide range of attacks can be envisioned su= ch as package pinning [1], artificial congestion to provoke LN channels clo= sure or manipulation of fee-estimator's feerate (the Core's one wou= ldn't be affected as it relies on block confirmation, though other fee = estimators designs deployed across the ecosystem are likely going to be aff= ected).

Traditionally, mempools partitions have been gauged as a spo= ntaneous outcome of a distributed systems like Bitcoin p2p network and I= 9;m not aware it has been studied in-depth for adversarial purposes. Though= , deployment of second-layer
protocols, heavily relying on sanity of a l= ocal mempool for fee-estimation and robust propagation of their time-sensit= ive transactions might lead to reconsider this position. Acknowledging this= , RBF opt-out is a low-cost partitioning tool, of which the existence nulli= fies most of potential progresses to mitigate malicious partitioning.

To resume, opt-in RBF doesn't suit well deployment of robust seco= nd-layers protocol, even if those issues are still early and deserve more r= esearch. At the same time, I believe a meaningful subset of the ecosystem = =C2=A0are 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 h= arming their quality of services and should be
weighed carefully. On the= other hand, it would be great to nudge them towards more secure handling o= f their 0-confs flows [3]

Let's examine what could be deployed e= cosystem-wise as enhancements to the 0-confs security model.

# Proac= tive security models : Double-spend Monitoring/Receiver-side Fee-Topping wi= th 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 f= ew full-nodes with well-spread connection graphs and unlinkable between the= m, to avoid being identified then maliciously partitioned from the rest of = the network.

I believe this tactic is already deployed by few Bitcoi= n services, and even one can throw flame at it because it over consumes net= work resources (bandwidth, connection slots, ...), it does procure a securi= ty advantage to the ones doing it.

One further improvement on top of= this protection could be to react after the double-spend detection by atta= ching a CPFP to the merchant transaction, with a higher package feerate tha= n the double-spend. Expected deployment of package-relay as a p2p mechanism= /mempool policy in Bitcoin Core should enable it to do so.

# Reactiv= e security models : EconomicReputation-based Compensations

Another a= pproach could be to react after the fact if a double-spend has been qualifi= ed. If the sender is already known to the service provider, the service acc= ount can be slashed.=C2=A0 If the sender is a low-trusted counterparty to t= he merchant, "side-trust" models could be relied on. For e.g a LN= pubkey with a stacked reputation from your autopilot, LSATs, stake certifi= cates, a HTLC-as-a-fidelity-bond, ... The space is quite wide there but I f= oresee 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 tool= s could be considered to enhance 0-confs security ?

To co= nclude, let's avoid replaying the contentious threads of a few years ag= o. What this new thread highlights is the fact that a transaction relay/mem= pool acceptance policy might be beneficial to some class of already-deploye= d
Bitcoin applications while being detrimental to newer ones. How do we= preserve the current interests of 0-confs users while enabling upcoming in= terests 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 so= unds 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-o= n by Bitcoin users, if we do so let sets a precedent satisfying as many fol= ks as we can.

Cheers,
Antoine

[0] https://lists.linuxfoundation.org/pipermail/= lightning-dev/2021-May/003033.html

[1] See scenario 3 : https://lists.linuxfoundatio= n.org/pipermail/lightning-dev/2020-June/002758.html

[2] https://github.com/bitcoin/bitcoin/pull= /10823#issuecomment-466485121

[3] And the LN ecosystem doe= s 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.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--000000000000c3ec8405c5afddc7--