Jeremy [ARCHIVE] on Nostr: 📅 Original date posted:2021-06-26 📝 Original message:If the parties trust each ...
📅 Original date posted:2021-06-26
📝 Original message: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 at 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.riard at 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.tetrud at 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 at 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 at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210626/80352cab/attachment-0001.html>;
📝 Original message: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 at 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.riard at 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.tetrud at 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 at 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 at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210626/80352cab/attachment-0001.html>;