public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

* [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
@ 2022-06-14  0:25 Antoine Riard
  2022-06-15  2:27 ` Peter Todd
                   ` (3 more replies)
  0 siblings, 4 replies; 27+ messages in thread
From: Antoine Riard @ 2022-06-14  0:25 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 3706 bytes --]

Hi list,

Recent discussions among LN devs have brought back on the surface concerns
about the security of multi-party funded transactions (coinjoins,
dual-funded LN channels, on-chain DLCs, ...). It turns out there is a
low-fruit, naive DoS vector playable against the funding flow of any such
construction due to the lack of existent full-rbf transaction-relay
topology on today's p2p network [0] [1]. While it does not consist in a
direct loss of funds, if exploited well I think it's annoying enough to
inflict significant timevalue loss or fee-bumping waste
to the future providers or distributed swarm of users doing multi-party
funded transactions. Of course, it can be fixed one layer above by
introducing either fidelity bonds or a reliable centralized coordinator,
though at the price of an overhead per-participant ressources cost and loss
in system openness [1].

For that reason, I believe it would be beneficial to the flourishing of
multi-party funded transactions to fix the Dos vector by seeing a subset of
the network running full-rbf and enabling propagation of honest multi-party
transactions to the interested miners, replacing potential non-signaling
double-spend from a malicious counterparty. Moving towards that direction,
I've submitted a small patch against Bitcoin Core enabling it to turn on
full-rbf as a policy, still under review [3]. The default setting stays
**false**, i.e keeping opt-in RBF as a default replacement policy. I've
started to run the patch on a public node at 146.190.224.15.

If you're a node operator curious to play with full-rbf, feel free to
connect to this node or spawn up a toy, public node yourself. There is a
##uafrbf libera chat if you would like information on the settings or
looking for full-rbf friends (though that step could be automated in the
future by setting up a dedicated network bit and reserving a few outbound
slots for them).

If you're a mining operator looking to increase your income, you might be
interested to experiment with full-rbf as a policy. Indeed, in the future I
believe the multi-party transactions issuers who need full-rbf to secure
their funding flow should connect by default to full-rbf peers. One can
conjecture that their transactions are likely to be more compelling in
their feerate as their liquidity needs are higher than the simple
transaction. For today, I think we have really few standards and bitcoin
softwares relying on multi-party funded transactions [4].

If you're a Bitcoin user or business and you don't like full-rbf, please
express an opinion on how it might affect your software/operations. I'm
always interested to learn more about mempool and transaction-relay
interactions with upper-layers and applications and to listen to feedback
in those areas, and I guess a lot of other Bitcoin researchers/devs too. I
know there have been a lot of concerns about full-rbf in the past, however
I believe the Bitcoin ecosystem has matured a lot since then.

Any mistakes or missing context is my own.

Cheers,
Antoine

[0] For more info about replace-by-fee, see
https://bitcoinops.org/en/topics/replace-by-fee/

[1] For more details about the DoS vector, see
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html

[2] E.g I think it does not affect the Lightning Pool service, as there is
a preliminary step where the participant funds are locked first in a 2-of-2
with the coordinator before being committed in the multi-party batch
transaction.

[3] https://github.com/bitcoin/bitcoin/pull/25353

[4] E.g DLCs :
https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transactions.md
; Lightning dual-funded channel :
https://github.com/lightning/bolts/pull/851

[-- Attachment #2: Type: text/html, Size: 4212 bytes --]

^ permalink raw reply	[flat|nested] 27+ messages in thread

• * Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
    2022-06-14  0:25 [bitcoin-dev] Playing with full-rbf peers for fun and L2s security Antoine Riard
  @ 2022-06-15  2:27 ` Peter Todd
    2022-06-15  2:53   ` Luke Dashjr
    2022-06-16  0:16 ` alicexbt
                     ` (2 subsequent siblings)
    3 siblings, 1 reply; 27+ messages in thread
  From: Peter Todd @ 2022-06-15  2:27 UTC (permalink / raw)
    To: Antoine Riard, Bitcoin Protocol Discussion
  
  [-- Attachment #1: Type: text/plain, Size: 899 bytes --]
  
  On Mon, Jun 13, 2022 at 08:25:11PM -0400, Antoine Riard via bitcoin-dev wrote:
  > If you're a node operator curious to play with full-rbf, feel free to
  > connect to this node or spawn up a toy, public node yourself. There is a
  > ##uafrbf libera chat if you would like information on the settings or
  > looking for full-rbf friends (though that step could be automated in the
  > future by setting up a dedicated network bit and reserving a few outbound
  > slots for them).
  
  I previously maintained a Bitcoin Core fork that did just that, using nServices
  bit 26:
  
  https://github.com/petertodd/bitcoin/commit/1cc1a46a633535c42394380b656d681258a111ac
  
  IIRC I was using the code written to prefer segwit peers; I have no idea if a
  similar approach is still easy to implement as I haven't worked on the Bitcoin
  Core codebase for years.
  
  -- 
  https://petertodd.org 'peter'[:-1]@petertodd.org
  
  [-- Attachment #2: signature.asc --]
  [-- Type: application/pgp-signature, Size: 488 bytes --]
  
  ^ permalink raw reply	[flat|nested] 27+ messages in thread

• • * Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
      2022-06-15  2:27 ` Peter Todd
    @ 2022-06-15  2:53   ` Luke Dashjr
      2022-06-15  3:18     ` Peter Todd
      0 siblings, 1 reply; 27+ messages in thread
    From: Luke Dashjr @ 2022-06-15  2:53 UTC (permalink / raw)
      To: bitcoin-dev, Peter Todd
    
    Bitcoin Knots still uses this service bit, FWIW (though due to a bug in some 
    older versions, it wasn't signalled by default). There are probably at least 
    100 nodes with full RBF already.
    
    On Wednesday 15 June 2022 02:27:20 Peter Todd via bitcoin-dev wrote:
    > On Mon, Jun 13, 2022 at 08:25:11PM -0400, Antoine Riard via bitcoin-dev 
    wrote:
    > > If you're a node operator curious to play with full-rbf, feel free to
    > > connect to this node or spawn up a toy, public node yourself. There is a
    > > ##uafrbf libera chat if you would like information on the settings or
    > > looking for full-rbf friends (though that step could be automated in the
    > > future by setting up a dedicated network bit and reserving a few outbound
    > > slots for them).
    >
    > I previously maintained a Bitcoin Core fork that did just that, using
    > nServices bit 26:
    >
    > https://github.com/petertodd/bitcoin/commit/1cc1a46a633535c42394380b656d681
    >258a111ac
    >
    > IIRC I was using the code written to prefer segwit peers; I have no idea if
    > a similar approach is still easy to implement as I haven't worked on the
    > Bitcoin Core codebase for years.
    
    
    
    ^ permalink raw reply	[flat|nested] 27+ messages in thread

  • • * Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
        2022-06-15  2:53   ` Luke Dashjr
      @ 2022-06-15  3:18     ` Peter Todd
        0 siblings, 0 replies; 27+ messages in thread
      From: Peter Todd @ 2022-06-15  3:18 UTC (permalink / raw)
        To: Luke Dashjr; +Cc: bitcoin-dev
      
      [-- Attachment #1: Type: text/plain, Size: 644 bytes --]
      
      On Wed, Jun 15, 2022 at 02:53:58AM +0000, Luke Dashjr wrote:
      > Bitcoin Knots still uses this service bit, FWIW (though due to a bug in some 
      > older versions, it wasn't signalled by default). There are probably at least 
      > 100 nodes with full RBF already.
      
      Right. However it looks like you do not add NODE_REPLACE_BY_FEE to the list
      returned by GetDesirableServiceFlags, so those nodes won't preferentially peer
      with each other.
      
      Also, if NODE_REPLACE_BY_FEE is added to the desirable service flags, it
      ideally needs to be supported by the DNS seeds too. Currently it is not.
      
      -- 
      https://petertodd.org 'peter'[:-1]@petertodd.org
      
      [-- Attachment #2: signature.asc --]
      [-- Type: application/pgp-signature, Size: 488 bytes --]
      
      ^ permalink raw reply	[flat|nested] 27+ messages in thread

• * Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
    2022-06-14  0:25 [bitcoin-dev] Playing with full-rbf peers for fun and L2s security Antoine Riard
    2022-06-15  2:27 ` Peter Todd
  @ 2022-06-16  0:16 ` alicexbt
    2022-06-16  1:02   ` Greg Sanders
         [not found] ` <gmDNbfrrvaZL4akV2DFwCuKrls9SScQjqxeRoEorEiYlv24dPt1j583iOtcB2lFrxZc59N3kp7T9KIM4ycl4QOmGBfDOUmO-BVHsttvtvDc=@protonmail.com>
    2022-06-20 23:49 ` Peter Todd
    3 siblings, 1 reply; 27+ messages in thread
  From: alicexbt @ 2022-06-16  0:16 UTC (permalink / raw)
    To: Antoine Riard; +Cc: Bitcoin Protocol Discussion
  
  [-- Attachment #1: Type: text/plain, Size: 7102 bytes --]
  
  Hi Antoine,
  
  Thanks for opening the pull request to add support for full-rbf in Bitcoin Core. I have a few disagreements with the approach and questions.
  
  > Recent discussions among LN devs have brought back on the surface concerns about the security of multi-party funded transactions (coinjoins, dual-funded LN channels, on-chain DLCs, ...). It turns out there is a low-fruit, naive DoS vector playable against the funding flow of any such construction due to the lack of existent full-rbf transaction-relay topology on today's p2p network [0] [1].
  
  1)If something relies on a policy which can be changed without breaking consensus rules, how is it secure in any case with or without full rbf? If I write a python script that expects user to enter char 'a' or 'b' but user can enter 'c' and there is no code to handle exceptions or other chars, will it be secure?
  
  2)full-rbf is not default in the 2 open pull requests, so this experiment still relies on users changing RBF policies manually. If majority of nodes use default opt-in policy, how would this affect vulnerable projects?
  
  > If you're a mining operator looking to increase your income, you might be interested to experiment with full-rbf as a policy.
  
  Miners can only increase their income if users replace transactions. 2-3% transactions are replaced with opt-in RBF, if someone did not replace earlier why would they do it with full RBF? Or even if we add some users in it who could not signal for some reasons, do you think it would be anything above 5%?
  
  > If you're a Bitcoin user or business and you don't like full-rbf, please express an opinion on how it might affect your software/operations. I'm always interested to learn more about mempool and transaction-relay interactions with upper-layers and applications and to listen to feedback in those areas, and I guess a lot of other Bitcoin researchers/devs too. I know there have been a lot of concerns about full-rbf in the past, however I believe the Bitcoin ecosystem has matured a lot since then.
  
  I am not opposed to full-rbf; rather, I am opposed to the notion that full-rbf will solve all problems and the lack of basic options in Bitcoin Core to employ/disable different RBF policies. There is also a speculation about making full RBF default in an year which isn't relevant to discuss at this point without trying different RBF policies.
  
  I would suggest users to try Bitcoin Knots instead which already has an option to disable all RBF policies if required, opt-in and full RBF policy. This can also be done using GUI if not familiar with config optionmempoolreplacement​.
  
  The rationale in PR #16171 was insufficient to justify removing it in the first place, had 2 NACKs and was reopened to merge it. Why bother with a few lines of code that may allow someone disable it if required in local mempool since it's only useful when a big percentage of miners utilize it and essentially underused according to the PR author? Developers should provide basic RBF policy options rather than attempting to define what constitutes a good policy and removing the ability to disable something when necessary.
  
  /dev/fd0
  
  Sent with [Proton Mail](https://proton.me/) secure email.
  
  ------- Original Message -------
  On Tuesday, June 14th, 2022 at 5:55 AM, Antoine Riard via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
  
  > Hi list,
  >
  > Recent discussions among LN devs have brought back on the surface concerns about the security of multi-party funded transactions (coinjoins, dual-funded LN channels, on-chain DLCs, ...). It turns out there is a low-fruit, naive DoS vector playable against the funding flow of any such construction due to the lack of existent full-rbf transaction-relay topology on today's p2p network [0] [1]. While it does not consist in a direct loss of funds, if exploited well I think it's annoying enough to inflict significant timevalue loss or fee-bumping waste
  > to the future providers or distributed swarm of users doing multi-party funded transactions. Of course, it can be fixed one layer above by introducing either fidelity bonds or a reliable centralized coordinator, though at the price of an overhead per-participant ressources cost and loss in system openness [1].
  >
  > For that reason, I believe it would be beneficial to the flourishing of multi-party funded transactions to fix the Dos vector by seeing a subset of the network running full-rbf and enabling propagation of honest multi-party transactions to the interested miners, replacing potential non-signaling double-spend from a malicious counterparty. Moving towards that direction, I've submitted a small patch against Bitcoin Core enabling it to turn on full-rbf as a policy, still under review [3]. The default setting stays **false**, i.e keeping opt-in RBF as a default replacement policy. I've started to run the patch on a public node at 146.190.224.15.
  >
  > If you're a node operator curious to play with full-rbf, feel free to connect to this node or spawn up a toy, public node yourself. There is a ##uafrbf libera chat if you would like information on the settings or looking for full-rbf friends (though that step could be automated in the future by setting up a dedicated network bit and reserving a few outbound slots for them).
  >
  > If you're a mining operator looking to increase your income, you might be interested to experiment with full-rbf as a policy. Indeed, in the future I believe the multi-party transactions issuers who need full-rbf to secure their funding flow should connect by default to full-rbf peers. One can conjecture that their transactions are likely to be more compelling in their feerate as their liquidity needs are higher than the simple transaction. For today, I think we have really few standards and bitcoin softwares relying on multi-party funded transactions [4].
  >
  > If you're a Bitcoin user or business and you don't like full-rbf, please express an opinion on how it might affect your software/operations. I'm always interested to learn more about mempool and transaction-relay interactions with upper-layers and applications and to listen to feedback in those areas, and I guess a lot of other Bitcoin researchers/devs too. I know there have been a lot of concerns about full-rbf in the past, however I believe the Bitcoin ecosystem has matured a lot since then.
  >
  > Any mistakes or missing context is my own.
  >
  > Cheers,
  > Antoine
  >
  > [0] For more info about replace-by-fee, see https://bitcoinops.org/en/topics/replace-by-fee/
  >
  > [1] For more details about the DoS vector, see https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
  >
  > [2] E.g I think it does not affect the Lightning Pool service, as there is a preliminary step where the participant funds are locked first in a 2-of-2 with the coordinator before being committed in the multi-party batch transaction.
  >
  > [3] https://github.com/bitcoin/bitcoin/pull/25353
  >
  > [4] E.g DLCs : https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transactions.md ; Lightning dual-funded channel : https://github.com/lightning/bolts/pull/851
  
  [-- Attachment #2: Type: text/html, Size: 10556 bytes --]
  
  ^ permalink raw reply	[flat|nested] 27+ messages in thread

• • * Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
      2022-06-16  0:16 ` alicexbt
    @ 2022-06-16  1:02   ` Greg Sanders
      2022-06-16  1:45     ` alicexbt
      0 siblings, 1 reply; 27+ messages in thread
    From: Greg Sanders @ 2022-06-16  1:02 UTC (permalink / raw)
      To: alicexbt, Bitcoin Protocol Discussion
    
    [-- Attachment #1: Type: text/plain, Size: 9275 bytes --]
    
    > If something relies on a policy which can be changed without breaking
    consensus rules, how is it secure in any case with or without full rbf?
    
    The security of LN and other related systems are something like: "given
    proper fees offered, can a transaction be mined within N blocks?" You're
    simply not allowed to out-bid your attacker in certain circumstances due to
    today's miner incentive-incompatible relay policies.
    
    There is also a time-value dimension to this with other simpler systems
    where your funds can be locked up for potentially weeks for similar reasons.
    
    >  ... arguments about how many people RBF being sufficient or not ...
    
    The idea that we should only build robust systems after the broken ones are
    attacked is not a serious argument.
    
    > I am not opposed to full-rbf; rather, I am opposed to the notion that
    full-rbf will solve all problems
    
    This is a strawman.
    
    Full-RBF is a simple, obvious, incentive-compatible step to getting closer
    to more robust layer two systems. Fixing the rest of the holes is for
    future proposals which are a bit more involved and definitely less mature.
    
    >  would suggest users to try Bitcoin Knots instead
    > Developers should provide basic RBF policy options rather than attempting
    to define what constitutes a good policy and removing the ability to
    disable something when necessary.
    
    If Knots has these knobs, just use Knots rather than lobby all
    implementations to have miner incentive incompatible knobs?
    
    Cheers,
    Greg
    
    On Wed, Jun 15, 2022 at 8:27 PM alicexbt via bitcoin-dev <
    bitcoin-dev@lists•linuxfoundation.org> wrote:
    
    > Hi Antoine,
    >
    >
    > Thanks for opening the pull request to add support for full-rbf in Bitcoin
    > Core. I have a few disagreements with the approach and questions.
    >
    > Recent discussions among LN devs have brought back on the surface concerns
    > about the security of multi-party funded transactions (coinjoins,
    > dual-funded LN channels, on-chain DLCs, ...). It turns out there is a
    > low-fruit, naive DoS vector playable against the funding flow of any such
    > construction due to the lack of existent full-rbf transaction-relay
    > topology on today's p2p network [0] [1].
    >
    >
    > 1)If something relies on a policy which can be changed without breaking
    > consensus rules, how is it secure in any case with or without full rbf? If
    > I write a python script that expects user to enter char 'a' or 'b' but user
    > can enter 'c' and there is no code to handle exceptions or other chars,
    > will it be secure?
    >
    > 2)full-rbf is not default in the 2 open pull requests, so this experiment
    > still relies on users changing RBF policies manually. If majority of nodes
    > use default opt-in policy, how would this affect vulnerable projects?
    >
    > If you're a mining operator looking to increase your income, you might be
    > interested to experiment with full-rbf as a policy.
    >
    >
    > Miners can only increase their income if users replace transactions. 2-3%
    > transactions are replaced with opt-in RBF, if someone did not replace
    > earlier why would they do it with full RBF? Or even if we add some users in
    > it who could not signal for some reasons, do you think it would be anything
    > above 5%?
    >
    > If you're a Bitcoin user or business and you don't like full-rbf, please
    > express an opinion on how it might affect your software/operations. I'm
    > always interested to learn more about mempool and transaction-relay
    > interactions with upper-layers and applications and to listen to feedback
    > in those areas, and I guess a lot of other Bitcoin researchers/devs too. I
    > know there have been a lot of concerns about full-rbf in the past, however
    > I believe the Bitcoin ecosystem has matured a lot since then.
    >
    >
    > I am not opposed to full-rbf; rather, I am opposed to the notion that
    > full-rbf will solve all problems and the lack of basic options in Bitcoin
    > Core to employ/disable different RBF policies. There is also a speculation
    > about making full RBF default in an year which isn't relevant to discuss at
    > this point without trying different RBF policies.
    >
    > I would suggest users to try Bitcoin Knots instead which already has an
    > option to disable all RBF policies if required, opt-in and full RBF policy.
    > This can also be done using GUI if not familiar with config option
    > mempoolreplacement​.
    >
    > The rationale in PR #16171 was insufficient to justify removing it in the
    > first place, had 2 NACKs and was reopened to merge it. Why bother with a
    > few lines of code that may allow someone disable it if required in local
    > mempool since it's only useful when a big percentage of miners utilize it
    > and essentially underused according to the PR author? Developers should
    > provide basic RBF policy options rather than attempting to define what
    > constitutes a good policy and removing the ability to disable something
    > when necessary.
    >
    >
    > /dev/fd0
    >
    > Sent with Proton Mail <https://proton.me/> secure email.
    >
    > ------- Original Message -------
    > On Tuesday, June 14th, 2022 at 5:55 AM, Antoine Riard via bitcoin-dev <
    > bitcoin-dev@lists•linuxfoundation.org> wrote:
    >
    > Hi list,
    >
    > Recent discussions among LN devs have brought back on the surface concerns
    > about the security of multi-party funded transactions (coinjoins,
    > dual-funded LN channels, on-chain DLCs, ...). It turns out there is a
    > low-fruit, naive DoS vector playable against the funding flow of any such
    > construction due to the lack of existent full-rbf transaction-relay
    > topology on today's p2p network [0] [1]. While it does not consist in a
    > direct loss of funds, if exploited well I think it's annoying enough to
    > inflict significant timevalue loss or fee-bumping waste
    > to the future providers or distributed swarm of users doing multi-party
    > funded transactions. Of course, it can be fixed one layer above by
    > introducing either fidelity bonds or a reliable centralized coordinator,
    > though at the price of an overhead per-participant ressources cost and loss
    > in system openness [1].
    >
    > For that reason, I believe it would be beneficial to the flourishing of
    > multi-party funded transactions to fix the Dos vector by seeing a subset of
    > the network running full-rbf and enabling propagation of honest multi-party
    > transactions to the interested miners, replacing potential non-signaling
    > double-spend from a malicious counterparty. Moving towards that direction,
    > I've submitted a small patch against Bitcoin Core enabling it to turn on
    > full-rbf as a policy, still under review [3]. The default setting stays
    > **false**, i.e keeping opt-in RBF as a default replacement policy. I've
    > started to run the patch on a public node at 146.190.224.15.
    >
    > If you're a node operator curious to play with full-rbf, feel free to
    > connect to this node or spawn up a toy, public node yourself. There is a
    > ##uafrbf libera chat if you would like information on the settings or
    > looking for full-rbf friends (though that step could be automated in the
    > future by setting up a dedicated network bit and reserving a few outbound
    > slots for them).
    >
    > If you're a mining operator looking to increase your income, you might be
    > interested to experiment with full-rbf as a policy. Indeed, in the future I
    > believe the multi-party transactions issuers who need full-rbf to secure
    > their funding flow should connect by default to full-rbf peers. One can
    > conjecture that their transactions are likely to be more compelling in
    > their feerate as their liquidity needs are higher than the simple
    > transaction. For today, I think we have really few standards and bitcoin
    > softwares relying on multi-party funded transactions [4].
    >
    > If you're a Bitcoin user or business and you don't like full-rbf, please
    > express an opinion on how it might affect your software/operations. I'm
    > always interested to learn more about mempool and transaction-relay
    > interactions with upper-layers and applications and to listen to feedback
    > in those areas, and I guess a lot of other Bitcoin researchers/devs too. I
    > know there have been a lot of concerns about full-rbf in the past, however
    > I believe the Bitcoin ecosystem has matured a lot since then.
    >
    > Any mistakes or missing context is my own.
    >
    > Cheers,
    > Antoine
    >
    > [0] For more info about replace-by-fee, see
    > https://bitcoinops.org/en/topics/replace-by-fee/
    >
    > [1] For more details about the DoS vector, see
    > https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
    >
    > [2] E.g I think it does not affect the Lightning Pool service, as there is
    > a preliminary step where the participant funds are locked first in a 2-of-2
    > with the coordinator before being committed in the multi-party batch
    > transaction.
    >
    > [3] https://github.com/bitcoin/bitcoin/pull/25353
    >
    > [4] E.g DLCs :
    > https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transactions.md
    > ; Lightning dual-funded channel :
    > https://github.com/lightning/bolts/pull/851
    >
    >
    > _______________________________________________
    > bitcoin-dev mailing list
    > bitcoin-dev@lists•linuxfoundation.org
    > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
    >
    
    [-- Attachment #2: Type: text/html, Size: 14140 bytes --]
    
    ^ permalink raw reply	[flat|nested] 27+ messages in thread

  • • * Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
        2022-06-16  1:02   ` Greg Sanders
      @ 2022-06-16  1:45     ` alicexbt
        2022-06-16  5:43       ` linuxfoundation.cndm1
        2022-06-16 13:24       ` Greg Sanders
        0 siblings, 2 replies; 27+ messages in thread
      From: alicexbt @ 2022-06-16  1:45 UTC (permalink / raw)
        To: Greg Sanders; +Cc: Bitcoin Protocol Discussion
      
      [-- Attachment #1: Type: text/plain, Size: 11206 bytes --]
      
      Hi Greg,
      
      > The security of LN and other related systems are something like: "given proper fees offered, can a transaction be mined within N blocks?" You're simply not allowed to out-bid your attacker in certain circumstances due to today's miner incentive-incompatible relay policies.
      
      It is not possible to guarantee that a transaction will be mined within N blocks irrespective of fees. It is vulnerable if a project's security relies on it,and should fix it by changing the security assumptions. Miners can try full-rbf or other policy without core so I won't consider opt-in as incentive-incompatible.
      
      >> ... arguments about how many people RBF being sufficient or not ...
      >
      > The idea that we should only build robust systems after the broken ones are attacked is not a serious argument.
      
      Its true and was even mentioned in PR #16171 that a policy is only useful if enough nodes and miners follow it. We should build robust systems but I don't think this change will help in doing it.
      
      > This is a strawman.
      >
      > Full-RBF is a simple, obvious, incentive-compatible step to getting closer to more robust layer two systems.Fixing the rest of the holes is for future proposals which are a bit more involved and definitely less mature.
      
      I do not have issues with multiple RBF policies being tried out and full-rbf being one of them. My disagreements are with rationale, lack of basic options in Bitcoin Core to employ/disable different RBF policies and a few arguments made in support for full-rbf. Whether it appears strawman or offtopic on github, there should be a place to share these disagreements.
      
      > If Knots has these knobs, just use Knots rather than lobby all implementations to have miner incentive incompatible knobs?
      
      Everyone can share options that would help users in the bitcoin implementation used by 90% nodes. I don't think this is reserved only for a few developers. I would personally use Knots and others are free to try the suggestion or continue using Bitcoin Core.
      
      /dev/fd0
      
      Sent with [Proton Mail](https://proton.me/) secure email.
      
      ------- Original Message -------
      On Thursday, June 16th, 2022 at 6:32 AM, Greg Sanders <gsanders87@gmail•com> wrote:
      
      >> If something relies on a policy which can be changed without breaking consensus rules, how is it secure in any case with or without full rbf?
      >
      > The security of LN and other related systems are something like: "given proper fees offered, can a transaction be mined within N blocks?" You're simply not allowed to out-bid your attacker in certain circumstances due to today's miner incentive-incompatible relay policies.
      >
      > There is also a time-value dimension to this with other simpler systems where your funds can be locked up for potentially weeks for similar reasons.
      >
      >> ... arguments about how many people RBF being sufficient or not ...
      >
      > The idea that we should only build robust systems after the broken ones are attacked is not a serious argument.
      >
      >> I am not opposed to full-rbf; rather, I am opposed to the notion that full-rbf will solve all problems
      >
      > This is a strawman.
      >
      > Full-RBF is a simple, obvious, incentive-compatible step to getting closer to more robust layer two systems. Fixing the rest of the holes is for future proposals which are a bit more involved and definitely less mature.
      >
      >> would suggest users to try Bitcoin Knots instead
      >> Developers should provide basic RBF policy options rather than attempting to define what constitutes a good policy and removing the ability to disable something when necessary.
      >
      > If Knots has these knobs, just use Knots rather than lobby all implementations to have miner incentive incompatible knobs?
      >
      > Cheers,
      > Greg
      >
      > On Wed, Jun 15, 2022 at 8:27 PM alicexbt via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
      >
      >> Hi Antoine,
      >>
      >> Thanks for opening the pull request to add support for full-rbf in Bitcoin Core. I have a few disagreements with the approach and questions.
      >>
      >>> Recent discussions among LN devs have brought back on the surface concerns about the security of multi-party funded transactions (coinjoins, dual-funded LN channels, on-chain DLCs, ...). It turns out there is a low-fruit, naive DoS vector playable against the funding flow of any such construction due to the lack of existent full-rbf transaction-relay topology on today's p2p network [0] [1].
      >>
      >> 1)If something relies on a policy which can be changed without breaking consensus rules, how is it secure in any case with or without full rbf? If I write a python script that expects user to enter char 'a' or 'b' but user can enter 'c' and there is no code to handle exceptions or other chars, will it be secure?
      >>
      >> 2)full-rbf is not default in the 2 open pull requests, so this experiment still relies on users changing RBF policies manually. If majority of nodes use default opt-in policy, how would this affect vulnerable projects?
      >>
      >>> If you're a mining operator looking to increase your income, you might be interested to experiment with full-rbf as a policy.
      >>
      >> Miners can only increase their income if users replace transactions. 2-3% transactions are replaced with opt-in RBF, if someone did not replace earlier why would they do it with full RBF? Or even if we add some users in it who could not signal for some reasons, do you think it would be anything above 5%?
      >>
      >>> If you're a Bitcoin user or business and you don't like full-rbf, please express an opinion on how it might affect your software/operations. I'm always interested to learn more about mempool and transaction-relay interactions with upper-layers and applications and to listen to feedback in those areas, and I guess a lot of other Bitcoin researchers/devs too. I know there have been a lot of concerns about full-rbf in the past, however I believe the Bitcoin ecosystem has matured a lot since then.
      >>
      >> I am not opposed to full-rbf; rather, I am opposed to the notion that full-rbf will solve all problems and the lack of basic options in Bitcoin Core to employ/disable different RBF policies. There is also a speculation about making full RBF default in an year which isn't relevant to discuss at this point without trying different RBF policies.
      >>
      >> I would suggest users to try Bitcoin Knots instead which already has an option to disable all RBF policies if required, opt-in and full RBF policy. This can also be done using GUI if not familiar with config optionmempoolreplacement​.
      >>
      >> The rationale in PR #16171 was insufficient to justify removing it in the first place, had 2 NACKs and was reopened to merge it. Why bother with a few lines of code that may allow someone disable it if required in local mempool since it's only useful when a big percentage of miners utilize it and essentially underused according to the PR author? Developers should provide basic RBF policy options rather than attempting to define what constitutes a good policy and removing the ability to disable something when necessary.
      >>
      >> /dev/fd0
      >>
      >> Sent with [Proton Mail](https://proton.me/) secure email.
      >>
      >> ------- Original Message -------
      >> On Tuesday, June 14th, 2022 at 5:55 AM, Antoine Riard via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
      >>
      >>> Hi list,
      >>>
      >>> Recent discussions among LN devs have brought back on the surface concerns about the security of multi-party funded transactions (coinjoins, dual-funded LN channels, on-chain DLCs, ...). It turns out there is a low-fruit, naive DoS vector playable against the funding flow of any such construction due to the lack of existent full-rbf transaction-relay topology on today's p2p network [0] [1]. While it does not consist in a direct loss of funds, if exploited well I think it's annoying enough to inflict significant timevalue loss or fee-bumping waste
      >>> to the future providers or distributed swarm of users doing multi-party funded transactions. Of course, it can be fixed one layer above by introducing either fidelity bonds or a reliable centralized coordinator, though at the price of an overhead per-participant ressources cost and loss in system openness [1].
      >>>
      >>> For that reason, I believe it would be beneficial to the flourishing of multi-party funded transactions to fix the Dos vector by seeing a subset of the network running full-rbf and enabling propagation of honest multi-party transactions to the interested miners, replacing potential non-signaling double-spend from a malicious counterparty. Moving towards that direction, I've submitted a small patch against Bitcoin Core enabling it to turn on full-rbf as a policy, still under review [3]. The default setting stays **false**, i.e keeping opt-in RBF as a default replacement policy. I've started to run the patch on a public node at 146.190.224.15.
      >>>
      >>> If you're a node operator curious to play with full-rbf, feel free to connect to this node or spawn up a toy, public node yourself. There is a ##uafrbf libera chat if you would like information on the settings or looking for full-rbf friends (though that step could be automated in the future by setting up a dedicated network bit and reserving a few outbound slots for them).
      >>>
      >>> If you're a mining operator looking to increase your income, you might be interested to experiment with full-rbf as a policy. Indeed, in the future I believe the multi-party transactions issuers who need full-rbf to secure their funding flow should connect by default to full-rbf peers. One can conjecture that their transactions are likely to be more compelling in their feerate as their liquidity needs are higher than the simple transaction. For today, I think we have really few standards and bitcoin softwares relying on multi-party funded transactions [4].
      >>>
      >>> If you're a Bitcoin user or business and you don't like full-rbf, please express an opinion on how it might affect your software/operations. I'm always interested to learn more about mempool and transaction-relay interactions with upper-layers and applications and to listen to feedback in those areas, and I guess a lot of other Bitcoin researchers/devs too. I know there have been a lot of concerns about full-rbf in the past, however I believe the Bitcoin ecosystem has matured a lot since then.
      >>>
      >>> Any mistakes or missing context is my own.
      >>>
      >>> Cheers,
      >>> Antoine
      >>>
      >>> [0] For more info about replace-by-fee, see https://bitcoinops.org/en/topics/replace-by-fee/
      >>>
      >>> [1] For more details about the DoS vector, see https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
      >>>
      >>> [2] E.g I think it does not affect the Lightning Pool service, as there is a preliminary step where the participant funds are locked first in a 2-of-2 with the coordinator before being committed in the multi-party batch transaction.
      >>>
      >>> [3] https://github.com/bitcoin/bitcoin/pull/25353
      >>>
      >>> [4] E.g DLCs : https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transactions.md ; Lightning dual-funded channel : https://github.com/lightning/bolts/pull/851
      >>
      >> _______________________________________________
      >> bitcoin-dev mailing list
      >> bitcoin-dev@lists•linuxfoundation.org
      >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
      
      [-- Attachment #2: Type: text/html, Size: 19537 bytes --]
      
      ^ permalink raw reply	[flat|nested] 27+ messages in thread

    • • * Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
          2022-06-16  1:45     ` alicexbt
        @ 2022-06-16  5:43       ` linuxfoundation.cndm1
          2022-06-16 12:47         ` alicexbt
          2022-06-16 13:24       ` Greg Sanders
          1 sibling, 1 reply; 27+ messages in thread
        From: linuxfoundation.cndm1 @ 2022-06-16  5:43 UTC (permalink / raw)
          To: Bitcoin Protocol Discussion
        
        alicexbt wrote:
        > I do not have issues with multiple RBF policies being tried out and full-rbf being one of them. My disagreements are with rationale, lack of basic options in Bitcoin Core to employ/disable different RBF policies and a few arguments made in support for full-rbf. Whether it appears strawman or offtopic on github, there should be a place to share these disagreements.
        
        Bitcoin Core is open source software, where developers open pull
        requests to try to get them merged after review. If you see a "lack of
        basic options" and no one has opened a pull request for it, it may be
        for two reasons. First, it could be that it just doesn't make sense,
        so no one sees a point in implementing it. Secondly, it may be that it
        isn't on anyone's list of priorities. In the second case, you are
        welcome to share your preference once. Moreover, no one is holding you
        back to implement it yourself and suggest a pull request. However,
        repeatedly demanding others to do it for you is not helpful in open
        source software development.
        
        cndm1
        
        
        
        ^ permalink raw reply	[flat|nested] 27+ messages in thread

      • • * Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
            2022-06-16  5:43       ` linuxfoundation.cndm1
          @ 2022-06-16 12:47         ` alicexbt
            0 siblings, 0 replies; 27+ messages in thread
          From: alicexbt @ 2022-06-16 12:47 UTC (permalink / raw)
            To: linuxfoundation.cndm1; +Cc: Bitcoin Protocol Discussion
          
          Hi cndm1,
          
          > If you see a "lack of basic options" and no one has opened a pull request for it, it may be for two reasons.
          
          The basic option to disable all RBF policies in a node's mempool if required was removed in [PR #16171][1]. No one has opened a pull request to revert this because most of the maintainers and a few reviewers agreed with this change. It wasn't required, PR had weak rationale, 2 NACKS and was reopened to merge because some reviewers/maintainers believe its a policy that cannot be maintained. One of the reviewers who NACKed it already maintains the config option to disable all RBF policies in Bitcoin Knots which is a derivative of Bitcoin Core.
          
          > However, repeatedly demanding others to do it for you is not helpful in open source software development.
          
          I am not demanding anyone to add a few lines of code and open a pull request. I am _reviewing_ a pull request in an open source project and sharing my feedback. Even Antoine and Luke agreed to add it if other reviewers have no issues or I can do it. This option in context with another being added for a new RBF policy was being discussed in [PR #25353][2] and my earlier emails in this thread.
          
          Other 'basic options' will be easier to accommodate with `-mempoolreplacement` used in [PR #25373] which is unlikely to be merged.
          
          [1]: https://github.com/bitcoin/bitcoin/pull/16171
          [2]: https://github.com/bitcoin/bitcoin/pull/25353
          [3]: https://github.com/bitcoin/bitcoin/pull/25373
          
          
          /dev/fd0
          
          Sent with Proton Mail secure email.
          
          ------- Original Message -------
          On Thursday, June 16th, 2022 at 11:13 AM, linuxfoundation.cndm1--- via bitcoin-dev bitcoin-dev@lists•linuxfoundation.org wrote:
          
          
          
          > alicexbt wrote:
          >
          > > I do not have issues with multiple RBF policies being tried out and full-rbf being one of them. My disagreements are with rationale, lack of basic options in Bitcoin Core to employ/disable different RBF policies and a few arguments made in support for full-rbf. Whether it appears strawman or offtopic on github, there should be a place to share these disagreements.
          >
          > Bitcoin Core is open source software, where developers open pull
          > requests to try to get them merged after review. If you see a "lack of
          > basic options" and no one has opened a pull request for it, it may be
          > for two reasons. First, it could be that it just doesn't make sense,
          > so no one sees a point in implementing it. Secondly, it may be that it
          > isn't on anyone's list of priorities. In the second case, you are
          > welcome to share your preference once. Moreover, no one is holding you
          > back to implement it yourself and suggest a pull request. However,
          > repeatedly demanding others to do it for you is not helpful in open
          > source software development.
          >
          > cndm1
          >
          > _______________________________________________
          > bitcoin-dev mailing list
          > bitcoin-dev@lists•linuxfoundation.org
          > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
          
          
          ^ permalink raw reply	[flat|nested] 27+ messages in thread

      • * Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
          2022-06-16  1:45     ` alicexbt
          2022-06-16  5:43       ` linuxfoundation.cndm1
        @ 2022-06-16 13:24       ` Greg Sanders
          1 sibling, 0 replies; 27+ messages in thread
        From: Greg Sanders @ 2022-06-16 13:24 UTC (permalink / raw)
          To: alicexbt; +Cc: Bitcoin Protocol Discussion
        
        [-- Attachment #1: Type: text/plain, Size: 12297 bytes --]
        
        > It is not possible to guarantee that a transaction will be mined within N
        blocks irrespective of fees. It is vulnerable if a project's security
        relies on it, and should fix it by changing the security assumptions.
        
        It's not possible to guarantee that any funds can be moved ever. But we
        still build an entire system assuming we can via an interesting mix of
        cryptography and incentives.
        
        On Wed, Jun 15, 2022 at 9:45 PM alicexbt <alicexbt@protonmail•com> wrote:
        
        > Hi Greg,
        >
        >
        > The security of LN and other related systems are something like: "given
        > proper fees offered, can a transaction be mined within N blocks?" You're
        > simply not allowed to out-bid your attacker in certain circumstances due to
        > today's miner incentive-incompatible relay policies.
        >
        >
        > It is not possible to guarantee that a transaction will be mined within N
        > blocks irrespective of fees. It is vulnerable if a project's security
        > relies on it, and should fix it by changing the security assumptions.
        > Miners can try full-rbf or other policy without core so I won't consider
        > opt-in as incentive-incompatible.
        >
        > > ... arguments about how many people RBF being sufficient or not ...
        >
        > The idea that we should only build robust systems after the broken ones
        > are attacked is not a serious argument.
        >
        >
        > Its true and was even mentioned in PR #16171 that a policy is only useful
        > if enough nodes and miners follow it. We should build robust systems but I
        > don't think this change will help in doing it.
        >
        > This is a strawman.
        >
        > Full-RBF is a simple, obvious, incentive-compatible step to getting closer
        > to more robust layer two systems. Fixing the rest of the holes is for
        > future proposals which are a bit more involved and definitely less mature.
        >
        >
        > I do not have issues with multiple RBF policies being tried out and
        > full-rbf being one of them. My disagreements are with rationale, lack of
        > basic options in Bitcoin Core to employ/disable different RBF policies
        > and a few arguments made in support for full-rbf. Whether it appears
        > strawman or offtopic on github, there should be a place to share these
        > disagreements.
        >
        > If Knots has these knobs, just use Knots rather than lobby all
        > implementations to have miner incentive incompatible knobs?
        >
        >
        > Everyone can share options that would help users in the bitcoin
        > implementation used by 90% nodes. I don't think this is reserved only for a
        > few developers. I would personally use Knots and others are free to try the
        > suggestion or continue using Bitcoin Core.
        >
        > /dev/fd0
        >
        >
        > Sent with Proton Mail <https://proton.me/> secure email.
        >
        > ------- Original Message -------
        > On Thursday, June 16th, 2022 at 6:32 AM, Greg Sanders <
        > gsanders87@gmail•com> wrote:
        >
        > > If something relies on a policy which can be changed without breaking
        > consensus rules, how is it secure in any case with or without full rbf?
        >
        > The security of LN and other related systems are something like: "given
        > proper fees offered, can a transaction be mined within N blocks?" You're
        > simply not allowed to out-bid your attacker in certain circumstances due to
        > today's miner incentive-incompatible relay policies.
        >
        > There is also a time-value dimension to this with other simpler systems
        > where your funds can be locked up for potentially weeks for similar reasons.
        >
        > > ... arguments about how many people RBF being sufficient or not ...
        >
        > The idea that we should only build robust systems after the broken ones
        > are attacked is not a serious argument.
        >
        > > I am not opposed to full-rbf; rather, I am opposed to the notion that
        > full-rbf will solve all problems
        >
        > This is a strawman.
        >
        > Full-RBF is a simple, obvious, incentive-compatible step to getting closer
        > to more robust layer two systems. Fixing the rest of the holes is for
        > future proposals which are a bit more involved and definitely less mature.
        >
        > > would suggest users to try Bitcoin Knots instead
        > > Developers should provide basic RBF policy options rather than
        > attempting to define what constitutes a good policy and removing the
        > ability to disable something when necessary.
        >
        > If Knots has these knobs, just use Knots rather than lobby all
        > implementations to have miner incentive incompatible knobs?
        >
        > Cheers,
        > Greg
        >
        > On Wed, Jun 15, 2022 at 8:27 PM alicexbt via bitcoin-dev <
        > bitcoin-dev@lists•linuxfoundation.org> wrote:
        >
        >> Hi Antoine,
        >>
        >>
        >> Thanks for opening the pull request to add support for full-rbf in
        >> Bitcoin Core. I have a few disagreements with the approach and questions.
        >>
        >> Recent discussions among LN devs have brought back on the surface
        >> concerns about the security of multi-party funded transactions (coinjoins,
        >> dual-funded LN channels, on-chain DLCs, ...). It turns out there is a
        >> low-fruit, naive DoS vector playable against the funding flow of any such
        >> construction due to the lack of existent full-rbf transaction-relay
        >> topology on today's p2p network [0] [1].
        >>
        >>
        >> 1)If something relies on a policy which can be changed without breaking
        >> consensus rules, how is it secure in any case with or without full rbf? If
        >> I write a python script that expects user to enter char 'a' or 'b' but user
        >> can enter 'c' and there is no code to handle exceptions or other chars,
        >> will it be secure?
        >>
        >> 2)full-rbf is not default in the 2 open pull requests, so this experiment
        >> still relies on users changing RBF policies manually. If majority of nodes
        >> use default opt-in policy, how would this affect vulnerable projects?
        >>
        >> If you're a mining operator looking to increase your income, you might be
        >> interested to experiment with full-rbf as a policy.
        >>
        >>
        >> Miners can only increase their income if users replace transactions. 2-3%
        >> transactions are replaced with opt-in RBF, if someone did not replace
        >> earlier why would they do it with full RBF? Or even if we add some users in
        >> it who could not signal for some reasons, do you think it would be anything
        >> above 5%?
        >>
        >> If you're a Bitcoin user or business and you don't like full-rbf, please
        >> express an opinion on how it might affect your software/operations. I'm
        >> always interested to learn more about mempool and transaction-relay
        >> interactions with upper-layers and applications and to listen to feedback
        >> in those areas, and I guess a lot of other Bitcoin researchers/devs too. I
        >> know there have been a lot of concerns about full-rbf in the past, however
        >> I believe the Bitcoin ecosystem has matured a lot since then.
        >>
        >>
        >> I am not opposed to full-rbf; rather, I am opposed to the notion that
        >> full-rbf will solve all problems and the lack of basic options in Bitcoin
        >> Core to employ/disable different RBF policies. There is also a speculation
        >> about making full RBF default in an year which isn't relevant to discuss at
        >> this point without trying different RBF policies.
        >>
        >> I would suggest users to try Bitcoin Knots instead which already has an
        >> option to disable all RBF policies if required, opt-in and full RBF policy.
        >> This can also be done using GUI if not familiar with config option
        >> mempoolreplacement​.
        >>
        >> The rationale in PR #16171 was insufficient to justify removing it in the
        >> first place, had 2 NACKs and was reopened to merge it. Why bother with a
        >> few lines of code that may allow someone disable it if required in local
        >> mempool since it's only useful when a big percentage of miners utilize it
        >> and essentially underused according to the PR author? Developers should
        >> provide basic RBF policy options rather than attempting to define what
        >> constitutes a good policy and removing the ability to disable something
        >> when necessary.
        >>
        >>
        >> /dev/fd0
        >>
        >> Sent with Proton Mail <https://proton.me/> secure email.
        >>
        >> ------- Original Message -------
        >> On Tuesday, June 14th, 2022 at 5:55 AM, Antoine Riard via bitcoin-dev <
        >> bitcoin-dev@lists•linuxfoundation.org> wrote:
        >>
        >> Hi list,
        >>
        >> Recent discussions among LN devs have brought back on the surface
        >> concerns about the security of multi-party funded transactions (coinjoins,
        >> dual-funded LN channels, on-chain DLCs, ...). It turns out there is a
        >> low-fruit, naive DoS vector playable against the funding flow of any such
        >> construction due to the lack of existent full-rbf transaction-relay
        >> topology on today's p2p network [0] [1]. While it does not consist in a
        >> direct loss of funds, if exploited well I think it's annoying enough to
        >> inflict significant timevalue loss or fee-bumping waste
        >> to the future providers or distributed swarm of users doing multi-party
        >> funded transactions. Of course, it can be fixed one layer above by
        >> introducing either fidelity bonds or a reliable centralized coordinator,
        >> though at the price of an overhead per-participant ressources cost and loss
        >> in system openness [1].
        >>
        >> For that reason, I believe it would be beneficial to the flourishing of
        >> multi-party funded transactions to fix the Dos vector by seeing a subset of
        >> the network running full-rbf and enabling propagation of honest multi-party
        >> transactions to the interested miners, replacing potential non-signaling
        >> double-spend from a malicious counterparty. Moving towards that direction,
        >> I've submitted a small patch against Bitcoin Core enabling it to turn on
        >> full-rbf as a policy, still under review [3]. The default setting stays
        >> **false**, i.e keeping opt-in RBF as a default replacement policy. I've
        >> started to run the patch on a public node at 146.190.224.15.
        >>
        >> If you're a node operator curious to play with full-rbf, feel free to
        >> connect to this node or spawn up a toy, public node yourself. There is a
        >> ##uafrbf libera chat if you would like information on the settings or
        >> looking for full-rbf friends (though that step could be automated in the
        >> future by setting up a dedicated network bit and reserving a few outbound
        >> slots for them).
        >>
        >> If you're a mining operator looking to increase your income, you might be
        >> interested to experiment with full-rbf as a policy. Indeed, in the future I
        >> believe the multi-party transactions issuers who need full-rbf to secure
        >> their funding flow should connect by default to full-rbf peers. One can
        >> conjecture that their transactions are likely to be more compelling in
        >> their feerate as their liquidity needs are higher than the simple
        >> transaction. For today, I think we have really few standards and bitcoin
        >> softwares relying on multi-party funded transactions [4].
        >>
        >> If you're a Bitcoin user or business and you don't like full-rbf, please
        >> express an opinion on how it might affect your software/operations. I'm
        >> always interested to learn more about mempool and transaction-relay
        >> interactions with upper-layers and applications and to listen to feedback
        >> in those areas, and I guess a lot of other Bitcoin researchers/devs too. I
        >> know there have been a lot of concerns about full-rbf in the past, however
        >> I believe the Bitcoin ecosystem has matured a lot since then.
        >>
        >> Any mistakes or missing context is my own.
        >>
        >> Cheers,
        >> Antoine
        >>
        >> [0] For more info about replace-by-fee, see
        >> https://bitcoinops.org/en/topics/replace-by-fee/
        >>
        >> [1] For more details about the DoS vector, see
        >> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
        >>
        >> [2] E.g I think it does not affect the Lightning Pool service, as there
        >> is a preliminary step where the participant funds are locked first in a
        >> 2-of-2 with the coordinator before being committed in the multi-party batch
        >> transaction.
        >>
        >> [3] https://github.com/bitcoin/bitcoin/pull/25353
        >>
        >> [4] E.g DLCs :
        >> https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transactions.md
        >> ; Lightning dual-funded channel :
        >> https://github.com/lightning/bolts/pull/851
        >>
        >>
        >> _______________________________________________
        >> bitcoin-dev mailing list
        >> bitcoin-dev@lists•linuxfoundation.org
        >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
        >>
        >
        >
        
        [-- Attachment #2: Type: text/html, Size: 20468 bytes --]
        
        ^ permalink raw reply	[flat|nested] 27+ messages in thread

• [parent not found: <gmDNbfrrvaZL4akV2DFwCuKrls9SScQjqxeRoEorEiYlv24dPt1j583iOtcB2lFrxZc59N3kp7T9KIM4ycl4QOmGBfDOUmO-BVHsttvtvDc=@protonmail.com>]

• • * Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
           [not found] ` <gmDNbfrrvaZL4akV2DFwCuKrls9SScQjqxeRoEorEiYlv24dPt1j583iOtcB2lFrxZc59N3kp7T9KIM4ycl4QOmGBfDOUmO-BVHsttvtvDc=@protonmail.com>
    @ 2022-06-17  1:34   ` Antoine Riard
      2022-06-17  4:54     ` alicexbt
      0 siblings, 1 reply; 27+ messages in thread
    From: Antoine Riard @ 2022-06-17  1:34 UTC (permalink / raw)
      To: alicexbt; +Cc: Bitcoin Protocol Discussion
    
    [-- Attachment #1: Type: text/plain, Size: 16742 bytes --]
    
    Hi alicexbt,
    
    
    Thanks for taking time to review the pull request,
    
    
    > 1)If something relies on a policy which can be changed without breaking
    consensus rules, how is it secure in any case with or without full rbf?
    
    
    Your Lightning node software relies on far more software and hardware
    components than the transaction-relay p2p network. One could list the
    operating system on which is running your Lightning process or the compiler
    toolchain turning out your Lightning source code in a binary artifact. Some
    weird kernel's memory mapping change could allow access to your channel
    funding keys, _without_ breaking the Bitcoin consensus rules [0]. Moreover,
    your Lightning node is also relying on the existence of a global Internet
    allowing your HTLC transaction to flow from your physical host to the crowd
    of transactions confirming in the blockchain. Due to this "protocol
    assumption" your channel balance would be vulnerable to any change in your
    ISP routing policy, e.g refusing to accept your IPV4 traffic by a
    sudden desiderata
    to impose an IPV6 supremacy. Still _without_ breaking the Bitcoin consensus
    rules. Of course, the odds of your ISP operator adopting this behavior are
    really low, mostly because your operator has to bind to social and economic
    constraints to stay in business.
    
    
    And I believe this imperative to stay in business is certainly not absent
    in the incentives of the Bitcoin node operators. You're free to run any
    policy on your node, especially one hardening the safety of your
    operations beyond
    the default one. However, if you start to a transaction-relay
    non-compatible with miner incentives, you won't have an efficient view of
    the blockspace demand, and from then won't be able to offer compelling
    feerates to execute your business transactions to satisfy your client
    needs. Or you won't consolidate your wallet UTXOs at times of low-demand.
    Indeed, a sane visibility of the mempools might not be critical now for your
    Bitcoin operations, but this is not likely to become true with miner's
    coinbase reward lowering with time and the system security relying on a
    fruitful fee market.
    
    
    So assuming there is a significant number of economically rational entities
    running p2p nodes, I think it's a reasonable assumption for Lightning
    developers that a policy maximizing miner's income and economic nodes
    operations
    will be widely run on the p2p network, and therefore lay its security model
    on that. When there is a gap between the economically optimal policy
    (full-rbf) and the effectively deployed one (optin), and this gap constitutes
    a flaw for exploitation, I believe it's better to fix it.
    
    
    If you have a different mode of thinking w.r.t how we should design
    protocol in a trust-minimized, open, adversarial environment such as
    Bitcoin, I'm curious to listen to it.
    
    
    > If I write a python script that expects user to enter char 'a' or 'b' but
    user can enter 'c' and there is no code to handle exceptions or other
    chars, will it be secure?
    
    
    Of course not. If you deliver any critical software, you should attach a
    solid manual explaining all the corner cases and rough edges. Even better
    would be to enshrine the manual directly in your software API to minimize
    the footgunish behaviors. E.g, with any ECC library, forbidding to reuse
    nonces. If your user still ignores or misread the manual and provides an
    insecure input, there is not that much you can do.
    
    
    By analogy, I believe that's the same with Lightning. One recommendation of
    the deployment manual would be to be always connected to a full-rbf
    transaction-relay topology. Defaulting to this rule and your node exposes
    far more surface of attacks. Assuming the manual has been well-written (big
    assumption!), I don't think the system designer would be to blame.
    
    
    That said, one issue to confess with current Lightning is our lack of
    understanding of what should be figured out in the LN user manual for safe
    operations. I would say that's an active area of research [1] [2] [3]
    
    
    > 2)full-rbf is not default in the 2 open pull requests, so this experiment
    still relies on users changing RBF policies manually. If majority of nodes
    use default opt-in policy, how would this affect vulnerable projects?
    
    
    If we define the goal as ensuring there is a significant number of
    transaction-relay routes between the L2s nodes requiring full-rbf and the
    set of miners supporting this policy, and the set of miners is populated
    enough, there is no need to convince the majority of nodes operators to
    switch to full-rbf.
    
    
    Beyond landing the 'full-rbf' pull request, in pursuit of a partial
    full-rbf deployment, I'm thinking of reaching out to Lightning vendors to
    recommend running LN nodes operators run their full-node with the setting
    enabled. And also to few mining pool operators to advocate the potential
    increase in their income.
    
    
    Given there are like 17000 public LN nodes, if half of them adopt full-rbf
    it should give already a good number of full-rbf transaction-relay routes
    across the p2p network graph. When we're there, we can measure and think
    more about how to tune the full-rbf sub-topology.
    
    
    > 2-3% transactions are replaced with opt-in RBF, if someone did not
    replace earlier why would they do it with full RBF?
    
    
    Because it's breaking the reliability and security of their use-cases.
    Use-cases which didn't exist a few years ago. The mempool DoS vector is
    described here [4]. To the best of my understanding, it might affect a
    bunch of use-cases, such as dual-funded channels, on-chain DLCs, p2p
    coinjoins, batched submarine swaps out. With the attack described, the
    honest set of users might not have visibility of the network mempools that
    there is a malicious, low-cost, opt-out double-spend preventing the
    propagation of their multi-party transaction. With the existence of a
    full-rbf transaction-relay topology, the multi-party transaction is able to
    replace the optout.
    
    
    None of those use-cases were deployed a few years ago, and the
    understanding of the interactions with the mempool policy is still nascent
    among their operators. However, if we assume that layering is a way to grow the
    Bitcoin ecosystem, as I do, it is reasonable to expect they will constitute
    a notable share of the Bitcoin transaction traffic during the next decade.
    
    
    > I am not opposed to full-rbf; rather, I am opposed to the notion that
    full-rbf will solve all problems
    
    
    I wished we had a magic Silver Bullet (tm) solving all the Bitcoin
    problems...
    
    
    I'm only advocating a partial full-rbf deployment to solve a real precise
    security issue affecting multi-party funded transactions. That said,
    full-rbf is far from solving the known set of problems affecting the L2s
    due to interactions with network mempools. E,g, see package relay
    motivation [5]
    
    
    > I would suggest users to try Bitcoin Knots instead which already has an
    option to disable all RBF policies if required, opt-in and full RBF policy.
    
    
    Selecting a full-node to underpin any serious Bitcoin infrastructure or
    secure a significant stack of coins should be submitted to a fully-fledged
    decision-making process. Many factors are likely to matter such as the
    level of activity of the contributor community, the chain of trust w.r.t
    dependencies, the security incident track records, the quality of the
    documentation, the exhaustivity and robustness of the set of features, ...
    
    
    This process might take tens of hours, to be duplicated by the number of
    node operators who would have to do the full-node vending switch. If you
    consider the cognitive cost at the level of the Bitcoin ecosystem, it's far
    less costly to implement and review a few lines of codes in Bitcoin Core.
    
    
    > Developers should provide basic RBF policy options rather than attempting
    to define what constitutes a good policy and removing the ability to
    disable something when necessary.
    
    
    Of course, this statement assumes there is a clear line between the
    developers and the users. Developers are also Bitcoin users, and they're
    modifying the software to suit their use-case needs. And that's exactly the
    purpose of the 'full-rbf' PR I'm proposing, aiming to propose a "good"
    policy for a Lightning node, without actually seeking to change the
    default. If they're parties interested in implementing more RBF policy
    options in Bitcoin Core, I think they're free to propose such changes and
    invest the engineering effort to do so. If you're interested in advancing
    the state of policy options in Bitcoin Core, there are a lot of interesting
    resources available and communities to encourage you in the learning
    process to contribute to the codebase [6].
    
    
    Antoine
    
    
    [0] https://dirtycow.ninja
    
    [1] https://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md
    
    [2] https://arxiv.org/pdf/2006.01418.pdf
    
    [3] https://arxiv.org/pdf/2006.08513.pdf
    
    [4]
    https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
    
    [5]
    https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020493.html
    
    [6] https://www.summerofbitcoin.org
    
    
    Le jeu. 16 juin 2022 à 00:15, alicexbt <alicexbt@protonmail•com> a écrit :
    
    > Hi Antoine,
    >
    >
    > Thanks for opening the pull request to add support for full-rbf in Bitcoin
    > Core. I have a disagreements with the approach and questions.
    >
    > Recent discussions among LN devs have brought back on the surface concerns
    > about the security of multi-party funded transactions (coinjoins,
    > dual-funded LN channels, on-chain DLCs, ...). It turns out there is a
    > low-fruit, naive DoS vector playable against the funding flow of any such
    > construction due to the lack of existent full-rbf transaction-relay
    > topology on today's p2p network [0] [1].
    >
    >
    > 1)If something relies on a policy which can be changed without breaking
    > consensus rules, how is it secure in any case with or without full rbf? If
    > I write a python script that expects user to enter char 'a' or 'b' but user
    > can enter 'c' and there is no code to handle exceptions or other chars,
    > will it be secure?
    >
    > 2)full-rbf is not default in the 2 open pull requests, so this experiment
    > still relies on users changing RBF policies manually. If majority of nodes
    > use default opt-in policy, how would this affect vulnerable projects?
    >
    > If you're a mining operator looking to increase your income, you might be
    > interested to experiment with full-rbf as a policy.
    >
    >
    > Miners can only increase their income if users replace transactions. 2-3%
    > transactions are replaced with opt-in RBF, if someone did not replace
    > earlier why would they do it now even with full RBF? Or even if we add some
    > users in it who could not signal for some reasons, do you think it would be
    > anything above 5%?
    >
    > If you're a Bitcoin user or business and you don't like full-rbf, please
    > express an opinion on how it might affect your software/operations. I'm
    > always interested to learn more about mempool and transaction-relay
    > interactions with upper-layers and applications and to listen to feedback
    > in those areas, and I guess a lot of other Bitcoin researchers/devs too. I
    > know there have been a lot of concerns about full-rbf in the past, however
    > I believe the Bitcoin ecosystem has matured a lot since then.
    >
    >
    > I am not opposed to full-rbf; rather, I am opposed to the notion that
    > full-rbf will solve all problems and the lack of basic options in Bitcoin
    > Core to employ/disable different RBF policies. There is also a speculation
    > about making full RBF default in an year which isn't relevant to discuss at
    > this point without trying different RBF policies.
    >
    > I would suggest users to try Bitcoin Knots instead which already has an
    > option to disable all RBF policies if required, opt-in and full RBF policy.
    > This can also be done using GUI if not familiar with config option
    > mempoolreplacement​.
    >
    > The rationale in PR #16171 was insufficient to justify removing it in the
    > first place, had 2 NACKs and was reopened to merge it. Why bother with a
    > few lines of code that may allow someone disable it if required in local
    > mempool since it's only useful when a big percentage of miners utilize it
    > and essentially underused according to the PR author? Developers should
    > provide basic RBF policy options rather than attempting to define what
    > constitutes a good policy and removing the ability to disable something
    > when necessary.
    >
    >
    > /dev/fd0
    >
    > Sent with Proton Mail <https://proton.me/> secure email.
    >
    > ------- Original Message -------
    > On Tuesday, June 14th, 2022 at 5:55 AM, Antoine Riard via bitcoin-dev <
    > bitcoin-dev@lists•linuxfoundation.org> wrote:
    >
    > Hi list,
    >
    > Recent discussions among LN devs have brought back on the surface concerns
    > about the security of multi-party funded transactions (coinjoins,
    > dual-funded LN channels, on-chain DLCs, ...). It turns out there is a
    > low-fruit, naive DoS vector playable against the funding flow of any such
    > construction due to the lack of existent full-rbf transaction-relay
    > topology on today's p2p network [0] [1]. While it does not consist in a
    > direct loss of funds, if exploited well I think it's annoying enough to
    > inflict significant timevalue loss or fee-bumping waste
    > to the future providers or distributed swarm of users doing multi-party
    > funded transactions. Of course, it can be fixed one layer above by
    > introducing either fidelity bonds or a reliable centralized coordinator,
    > though at the price of an overhead per-participant ressources cost and loss
    > in system openness [1].
    >
    > For that reason, I believe it would be beneficial to the flourishing of
    > multi-party funded transactions to fix the Dos vector by seeing a subset of
    > the network running full-rbf and enabling propagation of honest multi-party
    > transactions to the interested miners, replacing potential non-signaling
    > double-spend from a malicious counterparty. Moving towards that direction,
    > I've submitted a small patch against Bitcoin Core enabling it to turn on
    > full-rbf as a policy, still under review [3]. The default setting stays
    > **false**, i.e keeping opt-in RBF as a default replacement policy. I've
    > started to run the patch on a public node at 146.190.224.15.
    >
    > If you're a node operator curious to play with full-rbf, feel free to
    > connect to this node or spawn up a toy, public node yourself. There is a
    > ##uafrbf libera chat if you would like information on the settings or
    > looking for full-rbf friends (though that step could be automated in the
    > future by setting up a dedicated network bit and reserving a few outbound
    > slots for them).
    >
    > If you're a mining operator looking to increase your income, you might be
    > interested to experiment with full-rbf as a policy. Indeed, in the future I
    > believe the multi-party transactions issuers who need full-rbf to secure
    > their funding flow should connect by default to full-rbf peers. One can
    > conjecture that their transactions are likely to be more compelling in
    > their feerate as their liquidity needs are higher than the simple
    > transaction. For today, I think we have really few standards and bitcoin
    > softwares relying on multi-party funded transactions [4].
    >
    > If you're a Bitcoin user or business and you don't like full-rbf, please
    > express an opinion on how it might affect your software/operations. I'm
    > always interested to learn more about mempool and transaction-relay
    > interactions with upper-layers and applications and to listen to feedback
    > in those areas, and I guess a lot of other Bitcoin researchers/devs too. I
    > know there have been a lot of concerns about full-rbf in the past, however
    > I believe the Bitcoin ecosystem has matured a lot since then.
    >
    > Any mistakes or missing context is my own.
    >
    > Cheers,
    > Antoine
    >
    > [0] For more info about replace-by-fee, see
    > https://bitcoinops.org/en/topics/replace-by-fee/
    >
    > [1] For more details about the DoS vector, see
    > https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
    >
    > [2] E.g I think it does not affect the Lightning Pool service, as there is
    > a preliminary step where the participant funds are locked first in a 2-of-2
    > with the coordinator before being committed in the multi-party batch
    > transaction.
    >
    > [3] https://github.com/bitcoin/bitcoin/pull/25353
    >
    > [4] E.g DLCs :
    > https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transactions.md
    > ; Lightning dual-funded channel :
    > https://github.com/lightning/bolts/pull/851
    >
    >
    >
    
    [-- Attachment #2: Type: text/html, Size: 36323 bytes --]
    
    ^ permalink raw reply	[flat|nested] 27+ messages in thread

  • • * Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
        2022-06-17  1:34   ` Antoine Riard
      @ 2022-06-17  4:54     ` alicexbt
        2022-06-19 10:42       ` Peter Todd
        2022-06-21 23:43       ` Antoine Riard
        0 siblings, 2 replies; 27+ messages in thread
      From: alicexbt @ 2022-06-17  4:54 UTC (permalink / raw)
        To: Antoine Riard; +Cc: Bitcoin Protocol Discussion
      
      [-- Attachment #1: Type: text/plain, Size: 23844 bytes --]
      
      Hi Antoine,
      
      > One could list the operating system on which is running your Lightning process or the compiler toolchain turning outyour Lightning source code in a binary artifact. Some weird kernel's memory mapping change could allow access toyour channel funding keys, _without_ breaking the Bitcoin consensus rules [0].
      
      Lets consider there are 2 users with name Bob (normal LN user) and Carol (attacker running LN node) which I will use in this email for examples. In this case Bob and Carol can manage security of their OS and it is not affected by others using vulnerable systems or OS.
      
      > Moreover, your Lightning node is alsorelying on the existence of a global Internet allowing your HTLC transaction to flow from your physical hostto the crowd of transactions confirming in the blockchain. Due to this "protocol assumption" your channel balancewould be vulnerable to any change in your ISP routing policy, e.g refusing to accept your IPV4 traffic by a suddendesiderata to impose an IPV6 supremacy. Still _without_ breaking the Bitcoin consensus rules. Of course, the odds ofyour ISP operator adopting this behavior are really low, mostly because your operator has to bind to social andeconomic constraints to stay in business.
      
      The odds are low as you said, this can be managed by Bob and Carol because they can use a better ISP. Others using ISP with some issues may not affect their LN usage.
      
      > And I believe this imperative to stay in business is certainly not absent in the incentives of the Bitcoin nodeoperators. You're free to run any policy on your node, especially one hardening the safety of your operationsbeyond the default one. However, if you start to a transaction-relay non-compatible with miner incentives, youwon't have an efficient view of the blockspace demand, and from then won't be able to offer compelling feeratesto execute your business transactions to satisfy your client needs. Or you won't consolidate yourwallet UTXOs attimesof low-demand. Indeed, a sane visibility of the mempools might not be critical now foryour Bitcoin operations, but this is not likely to become true with miner's coinbase reward lowering with timeand the system securityrelyingon a fruitful fee market.
      
      Bob might use full-rbf as its suggested by LN developers for secure LN usage and better for miners. Carol could use a different RBF policy for some nodes and mining. In this case Bob may get affected at some point because of Carol's choice to use a different RBF policy which was not true above.
      
      > So assuming there is a significant number of economically rational entities running p2p nodes, I think it's areasonable assumption for Lightning developers that a policy maximizing miner's income and economic nodesoperations will be widely run on the p2p network, and therefore lay its security model on that. When there is agap between the economically optimal policy (full-rbf) and the effectively deployed one (optin), and this gapconstitutes a flaw for exploitation, I believe it's better to fix it.
      
      Agree with the assumption there is nothing wrong in experimenting with a new RBF policy (non-default) if that helps some users and projects.
      
      > If you have a different mode of thinking w.r.t how we should design protocol in a trust-minimized, open,adversarialenvironment such as Bitcoin, I'm curious to listen to it.
      
      Allowing users to create different mempool policies is great. My thought process is to code for happy path, where X policy is expected for replacement and edge cases where Y policy or no policy would be used. Users can try out different policies and even act as attackers. This is also true for other things in mempool, 'spkreuse=conflict' prevents address reuse in the mempool when using knots. If I assume that address reuse is always relayed, this could become a problem if some users and miners adopt this setting in their mempool.
      
      > Of course not. If you deliver any critical software, you should attach a solid manual explaining all thecorner cases and rough edges. Even better would be to enshrine the manual directly in your software APIto minimize the footgunish behaviors. E.g, with any ECC library, forbidding to reuse nonces. If youruserstill ignores or misread the manual and provides an insecure input, there isnot thatmuch you can do.
      
      Agree with the documentation as it helps users.
      
      > Given there are like 17000 public LN nodes, if half of them adopt full-rbf it should givealready a good number of full-rbf transaction-relay routes across the p2p network graph.When we're there, we can measure and think more about how to tune the full-rbf sub-topology.
      
      Sounds good.
      
      > Because it's breaking the reliability and security of their use-cases. Use-cases which didn't exista few years ago. The mempool DoS vector is described here [4]. To the best of my understanding, it mightaffect a bunch of use-cases, such as dual-funded channels, on-chain DLCs, p2pcoinjoins, batched submarineswaps out. With the attack described, the honest set of users might not have visibility of the networkmempools that there is a malicious, low-cost, opt-out double-spend preventing the propagation of their multi-partytransaction. With the existence of a full-rbf transaction-relay topology, the multi-party transactionis able to replace theoptout.
      
      This makes sense and I would be interested to follow two things once full-rbf is available in a bitcoin core release: 1. Percentage of transaction getting replaced 2. Miners profit (Fee for replaced Tx - Fee for original Tx)
      
      Can you explain how p2p coinjoin is affected with mempool DoS vector with some examples? What is considered a p2p coinjoin? Joinmarket or [Stonewall][1]?
      
      > Selecting a full-node to underpin any serious Bitcoin infrastructure or secure a significant stack of coinsshould be submitted to a fully-fledged decision-making process. Many factors are likely tomattersuch asthe level of activity of the contributor community, the chain of trust w.r.t dependencies, the security incident track records, the quality of the documentation, the exhaustivity and robustness of the set of features, ...
      
      I agree that contributor community and documentation could be improved in Knots.
      
      > Developersare also Bitcoin users, and they're modifying the software to suit their use-case needs. And that's exactlythe purpose of the 'full-rbf' PR I'm proposing, aiming to propose a "good" policy for a Lightning node, without actually seeking to change the default.
      
      I like that default still remains opt-in and cool with different policies being tried out if that helps some users.
      
      > If they'reparties interested in implementing more RBF policy options in Bitcoin Core, I think they're free to propose suchchanges and invest the engineering effort to do so. If you're interested in advancing the state ofpolicy options in Bitcoin Core, there are a lot of interestingresourcesavailable and communities toencourage you in the learning process to contribute to the codebase [6].
      
      Thanks for sharing the link. I would love to see 5 RBF policies available to use in bitcoin core. I have already tried experimenting with a few on regtest and will try to open pull request if there are enough people interested to test it on other chains (testnet3, signet, mainnet)
      
      [1]: https://docs.samourai.io/spend-tools
      
      /dev/fd0
      
      Sent with [Proton Mail](https://proton.me/) secure email.
      
      ------- Original Message -------
      On Friday, June 17th, 2022 at 7:04 AM, Antoine Riard <antoine.riard@gmail•com> wrote:
      
      > Hi alicexbt,
      >
      > Thanks for taking time to review the pull request,
      >
      >> 1)If something relies on a policy which can be changed without breaking consensus rules, how is it secure in any case with or without full rbf?
      >
      > Your Lightning node software relies on far more software and hardware components than the transaction-relay p2p network. One could list the operating system on which is running your Lightning process or the compiler toolchain turning out your Lightning source code in a binary artifact. Some weird kernel's memory mapping change could allow access to your channel funding keys, _without_ breaking the Bitcoin consensus rules [0]. Moreover, your Lightning node is also relying on the existence of a global Internet allowing your HTLC transaction to flow from your physical host to the crowd of transactions confirming in the blockchain. Due to this "protocol assumption" your channel balance would be vulnerable to any change in your ISP routing policy, e.g refusing to accept your IPV4 traffic by a sudden desiderata to impose an IPV6 supremacy. Still _without_ breaking the Bitcoin consensus rules. Of course, the odds of your ISP operator adopting this behavior are really low, mostly because your operator has to bind to social and economic constraints to stay in business.
      >
      > And I believe this imperative to stay in business is certainly not absent in the incentives of the Bitcoin node operators. You're free to run any policy on your node, especially one hardening the safety of your operationsbeyond the default one. However, if you start to a transaction-relay non-compatible with miner incentives, you won't have an efficient view of the blockspace demand, and from then won't be able to offer compelling feerates to execute your business transactions to satisfy your client needs. Or you won't consolidate your wallet UTXOs at times of low-demand. Indeed, a sane visibility of the mempools might not be critical now for your Bitcoin operations, but this is not likely to become true with miner's coinbase reward lowering with time and the system security relying on a fruitful fee market.
      >
      > So assuming there is a significant number of economically rational entities running p2p nodes, I think it's a reasonable assumption for Lightning developers that a policy maximizing miner's income and economic nodes operations will be widely run on the p2p network, and therefore lay its security model on that. When there is a gap between the economically optimal policy (full-rbf) and the effectively deployed one (optin), and this gap constitutes a flaw for exploitation, I believe it's better to fix it.
      >
      > If you have a different mode of thinking w.r.t how we should design protocol in a trust-minimized, open, adversarialenvironment such as Bitcoin, I'm curious to listen to it.
      >
      >> If I write a python script that expects user to enter char 'a' or 'b' but user can enter 'c' and there is no code to handle exceptions or other chars, will it be secure?
      >
      > Of course not. If you deliver any critical software, you should attach a solid manual explaining all the corner cases and rough edges. Even better would be to enshrine the manual directly in your software API to minimize the footgunish behaviors. E.g, with any ECC library, forbidding to reuse nonces. If your user still ignores or misread the manual and provides an insecure input, there is not that much you can do.
      >
      > By analogy, I believe that's the same with Lightning. One recommendation of the deployment manual would be to be always connected to a full-rbf transaction-relay topology. Defaulting to this rule and your node exposes far more surface of attacks. Assuming the manual has been well-written (big assumption!), I don't think the system designer would be to blame.
      >
      > That said, one issue to confess with current Lightning is our lack of understanding of what should be figured out in the LN user manual for safe operations. I would say that's an active area of research [1] [2] [3]
      >
      >> 2)full-rbf is not default in the 2 open pull requests, so this experiment still relies on users changing RBF policies manually. If majority of nodes use default opt-in policy, how would this affect vulnerable projects?
      >
      > If we define the goal as ensuring there is a significant number of transaction-relay routes between the L2s nodes requiring full-rbf and the set of miners supporting this policy, and the set of miners is populated enough, there is no need to convince the majority of nodes operators to switch to full-rbf.
      >
      > Beyond landing the 'full-rbf' pull request, in pursuit of a partial full-rbf deployment, I'm thinking of reaching out to Lightning vendors to recommend running LN nodes operatorsrun their full-node with the setting enabled. And also to few mining pool operators to advocate the potential increase in their income.
      >
      > Given there are like 17000 public LN nodes, if half of them adopt full-rbf it should give already a good number of full-rbf transaction-relay routes across the p2p network graph. When we're there, we can measure and think more about how to tune the full-rbf sub-topology.
      >
      >> 2-3% transactions are replaced with opt-in RBF, if someone did not replace earlier why would they do it with full RBF?
      >
      > Because it's breaking the reliability and security of their use-cases. Use-cases which didn't exist a few years ago. The mempool DoS vector is described here [4]. To the best of my understanding, it might affect a bunch of use-cases, such as dual-funded channels, on-chain DLCs, p2p coinjoins, batched submarine swaps out. With the attack described, the honest set of users might not have visibility of the network mempools that there is a malicious, low-cost, opt-out double-spend preventing the propagation of their multi-party transaction. With the existence of a full-rbf transaction-relay topology, the multi-party transaction is able to replace the optout.
      >
      > None of those use-cases were deployed a few years ago, and the understanding of the interactions with the mempool policy is still nascent among their operators. However, if we assume that layering is a way to grow the Bitcoin ecosystem, as I do, it is reasonable to expect they will constitute a notable share of the Bitcoin transaction traffic during the next decade.
      >
      >> I am not opposed to full-rbf; rather, I am opposed to the notion that full-rbf will solve all problems
      >
      > I wished we had a magic Silver Bullet (tm) solving all the Bitcoin problems...
      >
      > I'm only advocating a partial full-rbf deployment to solve a real precise security issue affecting multi-party funded transactions. That said, full-rbf is far from solving the known set of problems affecting the L2s due to interactions with network mempools. E,g, see package relay motivation [5]
      >
      >> I would suggest users to try Bitcoin Knots instead which already has an option to disable all RBF policies if required, opt-in and full RBF policy.
      >
      > Selecting a full-node to underpin any serious Bitcoin infrastructure or secure a significant stack of coins should be submitted to a fully-fledged decision-making process. Many factors are likely to matter such as the level of activity of the contributor community, the chain of trust w.r.t dependencies, the security incident track records, the quality of the documentation, the exhaustivity and robustness of the set of features, ...
      >
      > This process might take tens of hours, to be duplicated by the number of node operators who would have to do the full-node vending switch. If you consider the cognitive cost at the level of the Bitcoin ecosystem, it's far less costly to implement and review a few lines of codes in Bitcoin Core.
      >
      >> Developers should provide basic RBF policy options rather than attempting to define what constitutes a good policy and removing the ability to disable something when necessary.
      >
      > Of course, this statement assumes there is a clear line between the developers and the users. Developers are also Bitcoin users, and they're modifying the software to suit their use-case needs. And that's exactly the purpose of the 'full-rbf' PR I'm proposing, aiming to propose a "good" policy for a Lightning node, without actually seeking to change the default. If they're parties interested in implementing more RBF policy options in Bitcoin Core, I think they're free to propose such changes and invest the engineering effort to do so. If you're interested in advancing the state of policy options in Bitcoin Core, there are a lot of interesting resources available and communities to encourage you in the learning process to contribute to the codebase [6].
      >
      > Antoine
      >
      > [0] https://dirtycow.ninja
      >
      > [1] https://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md
      >
      > [2] https://arxiv.org/pdf/2006.01418.pdf
      >
      > [3] https://arxiv.org/pdf/2006.08513.pdf
      >
      > [4] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
      >
      > [5] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020493.html
      >
      > [6] https://www.summerofbitcoin.org
      >
      > Le jeu. 16 juin 2022 à 00:15, alicexbt <alicexbt@protonmail•com> a écrit :
      >
      >> Hi Antoine,
      >>
      >> Thanks for opening the pull request to add support for full-rbf in Bitcoin Core. I have a disagreements with the approach and questions.
      >>
      >>> Recent discussions among LN devs have brought back on the surface concerns about the security of multi-party funded transactions (coinjoins, dual-funded LN channels, on-chain DLCs, ...). It turns out there is a low-fruit, naive DoS vector playable against the funding flow of any such construction due to the lack of existent full-rbf transaction-relay topology on today's p2p network [0] [1].
      >>
      >> 1)If something relies on a policy which can be changed without breaking consensus rules, how is it secure in any case with or without full rbf? If I write a python script that expects user to enter char 'a' or 'b' but user can enter 'c' and there is no code to handle exceptions or other chars, will it be secure?
      >>
      >> 2)full-rbf is not default in the 2 open pull requests, so this experiment still relies on users changing RBF policies manually. If majority of nodes use default opt-in policy, how would this affect vulnerable projects?
      >>
      >>> If you're a mining operator looking to increase your income, you might be interested to experiment with full-rbf as a policy.
      >>
      >> Miners can only increase their income if users replace transactions. 2-3% transactions are replaced with opt-in RBF, if someone did not replace earlier why would they do it now even with full RBF? Or even if we add some users in it who could not signal for some reasons, do you think it would be anything above 5%?
      >>
      >>> If you're a Bitcoin user or business and you don't like full-rbf, please express an opinion on how it might affect your software/operations. I'm always interested to learn more about mempool and transaction-relay interactions with upper-layers and applications and to listen to feedback in those areas, and I guess a lot of other Bitcoin researchers/devs too. I know there have been a lot of concerns about full-rbf in the past, however I believe the Bitcoin ecosystem has matured a lot since then.
      >>
      >> I am not opposed to full-rbf; rather, I am opposed to the notion that full-rbf will solve all problems and the lack of basic options in Bitcoin Core to employ/disable different RBF policies. There is also a speculation about making full RBF default in an year which isn't relevant to discuss at this point without trying different RBF policies.
      >>
      >> I would suggest users to try Bitcoin Knots instead which already has an option to disable all RBF policies if required, opt-in and full RBF policy. This can also be done using GUI if not familiar with config option mempoolreplacement​.
      >>
      >> The rationale in PR #16171 was insufficient to justify removing it in the first place, had 2 NACKs and was reopened to merge it. Why bother with a few lines of code that may allow someone disable it if required in local mempool since it's only useful when a big percentage of miners utilize it and essentially underused according to the PR author? Developers should provide basic RBF policy options rather than attempting to define what constitutes a good policy and removing the ability to disable something when necessary.
      >>
      >> /dev/fd0
      >>
      >> Sent with [Proton Mail](https://proton.me/) secure email.
      >>
      >> ------- Original Message -------
      >> On Tuesday, June 14th, 2022 at 5:55 AM, Antoine Riard via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
      >>
      >>> Hi list,
      >>>
      >>> Recent discussions among LN devs have brought back on the surface concerns about the security of multi-party funded transactions (coinjoins, dual-funded LN channels, on-chain DLCs, ...). It turns out there is a low-fruit, naive DoS vector playable against the funding flow of any such construction due to the lack of existent full-rbf transaction-relay topology on today's p2p network [0] [1]. While it does not consist in a direct loss of funds, if exploited well I think it's annoying enough to inflict significant timevalue loss or fee-bumping waste
      >>> to the future providers or distributed swarm of users doing multi-party funded transactions. Of course, it can be fixed one layer above by introducing either fidelity bonds or a reliable centralized coordinator, though at the price of an overhead per-participant ressources cost and loss in system openness [1].
      >>>
      >>> For that reason, I believe it would be beneficial to the flourishing of multi-party funded transactions to fix the Dos vector by seeing a subset of the network running full-rbf and enabling propagation of honest multi-party transactions to the interested miners, replacing potential non-signaling double-spend from a malicious counterparty. Moving towards that direction, I've submitted a small patch against Bitcoin Core enabling it to turn on full-rbf as a policy, still under review [3]. The default setting stays **false**, i.e keeping opt-in RBF as a default replacement policy. I've started to run the patch on a public node at 146.190.224.15.
      >>>
      >>> If you're a node operator curious to play with full-rbf, feel free to connect to this node or spawn up a toy, public node yourself. There is a ##uafrbf libera chat if you would like information on the settings or looking for full-rbf friends (though that step could be automated in the future by setting up a dedicated network bit and reserving a few outbound slots for them).
      >>>
      >>> If you're a mining operator looking to increase your income, you might be interested to experiment with full-rbf as a policy. Indeed, in the future I believe the multi-party transactions issuers who need full-rbf to secure their funding flow should connect by default to full-rbf peers. One can conjecture that their transactions are likely to be more compelling in their feerate as their liquidity needs are higher than the simple transaction. For today, I think we have really few standards and bitcoin softwares relying on multi-party funded transactions [4].
      >>>
      >>> If you're a Bitcoin user or business and you don't like full-rbf, please express an opinion on how it might affect your software/operations. I'm always interested to learn more about mempool and transaction-relay interactions with upper-layers and applications and to listen to feedback in those areas, and I guess a lot of other Bitcoin researchers/devs too. I know there have been a lot of concerns about full-rbf in the past, however I believe the Bitcoin ecosystem has matured a lot since then.
      >>>
      >>> Any mistakes or missing context is my own.
      >>>
      >>> Cheers,
      >>> Antoine
      >>>
      >>> [0] For more info about replace-by-fee, see https://bitcoinops.org/en/topics/replace-by-fee/
      >>>
      >>> [1] For more details about the DoS vector, see https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
      >>>
      >>> [2] E.g I think it does not affect the Lightning Pool service, as there is a preliminary step where the participant funds are locked first in a 2-of-2 with the coordinator before being committed in the multi-party batch transaction.
      >>>
      >>> [3] https://github.com/bitcoin/bitcoin/pull/25353
      >>>
      >>> [4] E.g DLCs : https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transactions.md ; Lightning dual-funded channel : https://github.com/lightning/bolts/pull/851
      
      [-- Attachment #2: Type: text/html, Size: 56291 bytes --]
      
      ^ permalink raw reply	[flat|nested] 27+ messages in thread

    • • * Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
          2022-06-17  4:54     ` alicexbt
        @ 2022-06-19 10:42       ` Peter Todd
          2022-06-21 23:43       ` Antoine Riard
          1 sibling, 0 replies; 27+ messages in thread
        From: Peter Todd @ 2022-06-19 10:42 UTC (permalink / raw)
          To: alicexbt, Bitcoin Protocol Discussion
        
        [-- Attachment #1: Type: text/plain, Size: 1570 bytes --]
        
        On Fri, Jun 17, 2022 at 04:54:11AM +0000, alicexbt via bitcoin-dev wrote:
        > > If they'reparties interested in implementing more RBF policy options in Bitcoin Core, I think they're free to propose suchchanges and invest the engineering effort to do so. If you're interested in advancing the state ofpolicy options in Bitcoin Core, there are a lot of interestingresourcesavailable and communities toencourage you in the learning process to contribute to the codebase [6].
        > 
        > Thanks for sharing the link. I would love to see 5 RBF policies available to use in bitcoin core. I have already tried experimenting with a few on regtest and will try to open pull request if there are enough people interested to test it on other chains (testnet3, signet, mainnet)
        
        I don't think more RBF policies in Bitcoin Core helps much. RBF policies aren't
        very useful in isolation: unless you're getting your txs to other nodes/miners
        via special peering efforts, the only reason to run an uncommon RBF policy is
        to accomodate local software with obsolete expectations about mempool behavior.
        That's why my full-RBF patch advertised a special service bit, and did
        preferential peering with other nodes advertising that service bit.
        
        Bitcoin Core isn't going to do that for every RBF policy. So there's no reason
        we should try to accomodate a bunch of them.
        
        I can understand a -fullrbf flag from a political point of view, in the process
        of enabling full-RBF all the time. But there's no reason to go beyond that.
        
        -- 
        https://petertodd.org 'peter'[:-1]@petertodd.org
        
        [-- Attachment #2: signature.asc --]
        [-- Type: application/pgp-signature, Size: 488 bytes --]
        
        ^ permalink raw reply	[flat|nested] 27+ messages in thread

      • * Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
          2022-06-17  4:54     ` alicexbt
          2022-06-19 10:42       ` Peter Todd
        @ 2022-06-21 23:43       ` Antoine Riard
          2022-06-26 16:40         ` alicexbt
          1 sibling, 1 reply; 27+ messages in thread
        From: Antoine Riard @ 2022-06-21 23:43 UTC (permalink / raw)
          To: alicexbt; +Cc: Bitcoin Protocol Discussion
        
        [-- Attachment #1: Type: text/plain, Size: 31575 bytes --]
        
        HI alicexbt,
        
        > Lets consider there are 2 users with name Bob (normal LN user) and Carol
        (attacker running LN node) which I will use in this email for examples. In
        this case Bob and Carol can manage security of their OS and it is not
        affected by others using vulnerable systems or OS.
        
        Yes, I believe my argument was the set of components making the security of
        your LN node is far beyond Bitcoin softwares. Of course, you might review
        by yourself the millions lines of code entering in the trusted computing
        base (OS, bootloader, BIOS, device firmwares, essential utilities, ...) on
        which your cryptocurrency software stack lays out, and as such exercise an
        extended span of control on your personal computation. Though, while I hope
        we'll have more LN node operators doing so, I'm not sure it's realistic to
        expect it will be the behavior standard among them..
        
        > The odds are low as you said, this can be managed by Bob and Carol
        because they can use a better ISP. Others using ISP with some issues may
        not affect their LN usage.
        
        Sure, though as I would like to underscore being dependent on a Bitcoin
        node policy and being dependent on a ISP internet traffic routing policy
        could be analyzed as logically equivalent, all things are equal. That said,
        if your personal risk aversion is too high for the Lightning security
        model, once it's well-understood there is a strong reliance on a
        censorship-resistant tx-relay network back to economically-rational miners,
        you're free to not use it and satisfy yourself with the Bitcoin base layer.
        
        > Bob might use full-rbf as its suggested by LN developers for secure LN
        usage and better for miners. Carol could use a different RBF policy for
        some nodes and mining. In this case Bob may get affected at some point
        because of Carol's choice to use a different RBF policy which was not true
        above.
        
        Indeed, your secure LN usage is going to be dependent of the number of p2p
        network nodes running an economically-rational policy like full-rbf. That
        said, I think it's reasonable to assume that the players of the Bitcoin
        game are economically-rational, and as such incentived to pick up a policy
        such as full-rbf. I know the term "economically-rational" is poorly defined
        here, and I think it could be interesting for any academic with an economic
        background to study the incentives of Bitcoin actors.
        
        > Allowing users to create different mempool policies is great. My thought
        process is to code for happy path, where X policy is expected for
        replacement and edge cases where Y policy or no policy would be used. Users
        can try out different policies and even act as attackers. This is also true
        for other things in mempool, 'spkreuse=conflict' prevents address reuse in
        the mempool when using knots. If I assume that address reuse is always
        relayed, this could become a problem if some users and miners adopt this
        setting in their mempool.
        
        Agree, I'm all in for people to experiment with mempool policies. Though at
        the end it's a software engineering resource question. If users are
        interested in more features, they're always free to implement themselves.
        Really, the binary distinction developers-vs-users doesn't make sense and
        if we would like Bitcoin to be successful in the long-term, we should
        promote high degree of software literacy among bitcoiners.
        
        > This makes sense and I would be interested to follow two things once
        full-rbf is available in a bitcoin core release: 1. Percentage of
        transaction getting replaced 2. Miners profit (Fee for replaced Tx - Fee
        for original Tx)
        
        Yes, I would be interested too to have those metrics once full-rbf is
        available in a bitcoin core release. I think that's something every
        full-rbf curious node operator could observe on its own with a few more
        loggers, at least for the first metric.
        
        > Can you explain how p2p coinjoin is affected with mempool DoS vector with
        some examples? What is considered a p2p coinjoin? Joinmarket or
        [Stonewall][1]?
        
        I don't remember the Joinmarket code right now and I don't know the ins and
        outs of Samourai coinjoin as I'm not sure the code is open source. Though
        let's say for a p2p coinjoin as one you can build once you have implemented
        LN's interactive construction protocol [0].
        
        [0] https://github.com/lightning/bolts/pull/851
        
        Here the DoS attack situation :
        - Alice, Bob and Caroll would like to coinjoin 3 inputs to 3 outputs
        - Each of the input is singly controlled by one party, e.g Alice owns input
        A, Bob owns input B, ...
        - Alice, Bob and Caroll exchanges a PSBT to build a multi-party funded
        transaction (the coinjoin_tx)
        - Alice is elected as the multi-party transaction broadcaster once the
        signatures have been exchanged
        - The block feerate is around 10sat/vb
        - One of the transaction input signals opt-in RBF, the transaction is
        attached a compelling feerate 10sat/vb
        - Caroll broadcasts a double-spend of her own input C, the double-spend is
        attached with a low-fee (1sat/vb) and it does _not_ signal opt-in RBF
        - Alice broadcasts the multi-party transaction, it is rejected by the
        network mempools because Alice double-spend is already present
        - Two alternatives are offered to the coinjoin participants :
        
        Alternative A)
        - They estimate the multi-party feerate as not high enough
        - They fee-bump at 20sat/vb
        - Caroll double-spend one of the input of her malicious double-spend to
        eject it from the network mempools
        - The multi-party transaction is confirmed at a block feerare far above
        what was necessary
        - Alice, Bob, Caroll have loss fee-bumping value without compensation
        - Note, even if Caroll is attacker and assuming the fee-bumping burden is
        fairly spread among participants, the economic loss inflicted is asymmetric
        
        Alternative B)
        - They wait until some time-out
        - They double-spend their own inputs, Alice double-spend utxo A, Bob
        double-spend utxo B
        - They wasted the timevalue of their inputs for the time-out delay
        - Note, even if Caroll is attacker and loss some timevalue too, the
        economic loss inflicted is asymmetric
        
        Let me know if you see any error or wrong in this DoS scenario exposure. I
        believe it's fairly simple to execute
        for a medium-skilled attacker.
        
        Antoine
        
        Le ven. 17 juin 2022 à 00:54, alicexbt <alicexbt@protonmail•com> a écrit :
        
        > Hi Antoine,
        >
        >
        > One could list the operating system on which is running your Lightning
        > process or the compiler toolchain turning out your Lightning source code
        > in a binary artifact. Some weird kernel's memory mapping change could allow
        > access to your channel funding keys, _without_ breaking the Bitcoin
        > consensus rules [0].
        >
        >
        > Lets consider there are 2 users with name Bob (normal LN user) and Carol
        > (attacker running LN node) which I will use in this email for examples. In
        > this case Bob and Carol can manage security of their OS and it is not
        > affected by others using vulnerable systems or OS.
        >
        > Moreover, your Lightning node is also relying on the existence of a
        > global Internet allowing your HTLC transaction to flow from your physical
        > host to the crowd of transactions confirming in the blockchain. Due to
        > this "protocol assumption" your channel balance would be vulnerable to
        > any change in your ISP routing policy, e.g refusing to accept your IPV4
        > traffic by a sudden desiderata to impose an IPV6 supremacy. Still
        > _without_ breaking the Bitcoin consensus rules. Of course, the odds of your
        > ISP operator adopting this behavior are really low, mostly because your
        > operator has to bind to social and economic constraints to stay in
        > business.
        >
        >
        > The odds are low as you said, this can be managed by Bob and Carol because
        > they can use a better ISP. Others using ISP with some issues may not affect
        > their LN usage.
        >
        > And I believe this imperative to stay in business is certainly not absent
        > in the incentives of the Bitcoin node operators. You're free to run any
        > policy on your node, especially one hardening the safety of your operations
        >  beyond the default one. However, if you start to a transaction-relay
        > non-compatible with miner incentives, you won't have an efficient view of
        > the blockspace demand, and from then won't be able to offer compelling
        > feerates to execute your business transactions to satisfy your client
        > needs. Or you won't consolidate your wallet UTXOs at times of low-demand.
        > Indeed, a sane visibility of the mempools might not be critical now for your
        > Bitcoin operations, but this is not likely to become true with miner's
        > coinbase reward lowering with time and the system security relying on a
        > fruitful fee market.
        >
        >
        > Bob might use full-rbf as its suggested by LN developers for secure LN
        > usage and better for miners. Carol could use a different RBF policy for
        > some nodes and mining. In this case Bob may get affected at some point
        > because of Carol's choice to use a different RBF policy which was not true
        > above.
        >
        >
        > So assuming there is a significant number of economically rational
        > entities running p2p nodes, I think it's a reasonable assumption for
        > Lightning developers that a policy maximizing miner's income and economic
        > nodes operations will be widely run on the p2p network, and therefore lay
        > its security model on that. When there is a gap between the economically
        > optimal policy (full-rbf) and the effectively deployed one (optin), and
        > this gap constitutes a flaw for exploitation, I believe it's better to
        > fix it.
        >
        >
        > Agree with the assumption there is nothing wrong in experimenting with a
        > new RBF policy (non-default) if that helps some users and projects.
        >
        > If you have a different mode of thinking w.r.t how we should design
        > protocol in a trust-minimized, open, adversarial environment such as
        > Bitcoin, I'm curious to listen to it.
        >
        >
        > Allowing users to create different mempool policies is great. My thought
        > process is to code for happy path, where X policy is expected for
        > replacement and edge cases where Y policy or no policy would be used. Users
        > can try out different policies and even act as attackers. This is also true
        > for other things in mempool, 'spkreuse=conflict' prevents address reuse in
        > the mempool when using knots. If I assume that address reuse is always
        > relayed, this could become a problem if some users and miners adopt this
        > setting in their mempool.
        >
        > Of course not. If you deliver any critical software, you should attach a
        > solid manual explaining all the corner cases and rough edges. Even better
        > would be to enshrine the manual directly in your software API to minimize
        > the footgunish behaviors. E.g, with any ECC library, forbidding to reuse
        > nonces. If your user still ignores or misread the manual and provides an
        > insecure input, there is not that much you can do.
        >
        >
        > Agree with the documentation as it helps users.
        >
        > Given there are like 17000 public LN nodes, if half of them adopt full-rbf
        > it should give already a good number of full-rbf transaction-relay routes
        > across the p2p network graph. When we're there, we can measure and think
        > more about how to tune the full-rbf sub-topology.
        >
        >
        > Sounds good.
        >
        > Because it's breaking the reliability and security of their use-cases.
        > Use-cases which didn't exist a few years ago. The mempool DoS vector is
        > described here [4]. To the best of my understanding, it might affect a
        > bunch of use-cases, such as dual-funded channels, on-chain DLCs, p2p
        > coinjoins, batched submarine swaps out. With the attack described, the
        > honest set of users might not have visibility of the network mempools
        > that there is a malicious, low-cost, opt-out double-spend preventing the
        > propagation of their multi-party transaction. With the existence of a
        > full-rbf transaction-relay topology, the multi-party transaction is able
        > to replace the optout.
        >
        >
        > This makes sense and I would be interested to follow two things once
        > full-rbf is available in a bitcoin core release: 1. Percentage of
        > transaction getting replaced 2. Miners profit (Fee for replaced Tx - Fee
        > for original Tx)
        >
        > Can you explain how p2p coinjoin is affected with mempool DoS vector with
        > some examples? What is considered a p2p coinjoin? Joinmarket or
        > [Stonewall][1]?
        >
        > Selecting a full-node to underpin any serious Bitcoin infrastructure or
        > secure a significant stack of coins should be submitted to a
        > fully-fledged decision-making process. Many factors are likely to matter such
        > as the level of activity of the contributor community, the chain of trust
        > w.r.t dependencies, the security incident track records, the quality of
        > the documentation, the exhaustivity and robustness of the set of features,
        > ...
        >
        >
        > I agree that contributor community and documentation could be improved in
        > Knots.
        >
        > Developers are also Bitcoin users, and they're modifying the software to
        > suit their use-case needs. And that's exactly the purpose of the
        > 'full-rbf' PR I'm proposing, aiming to propose a "good" policy for a
        > Lightning node, without actually seeking to change the default.
        >
        >
        > I like that default still remains opt-in and cool with different policies
        > being tried out if that helps some users.
        >
        >  If they're parties interested in implementing more RBF policy options in
        > Bitcoin Core, I think they're free to propose such changes and invest the
        > engineering effort to do so. If you're interested in advancing the state of
        >  policy options in Bitcoin Core, there are a lot of interesting resources available
        > and communities to encourage you in the learning process to contribute to
        > the codebase [6].
        >
        >
        > Thanks for sharing the link. I would love to see 5 RBF policies available
        > to use in bitcoin core. I have already tried experimenting with a few on
        > regtest and will try to open pull request if there are enough people
        > interested to test it on other chains (testnet3, signet, mainnet)
        >
        >
        > [1]: https://docs.samourai.io/spend-tools
        >
        >
        > /dev/fd0
        >
        >
        > Sent with Proton Mail <https://proton.me/> secure email.
        >
        > ------- Original Message -------
        > On Friday, June 17th, 2022 at 7:04 AM, Antoine Riard <
        > antoine.riard@gmail•com> wrote:
        >
        > Hi alicexbt,
        >
        >
        > Thanks for taking time to review the pull request,
        >
        >
        > > 1)If something relies on a policy which can be changed without breaking
        > consensus rules, how is it secure in any case with or without full rbf?
        >
        >
        > Your Lightning node software relies on far more software and hardware
        > components than the transaction-relay p2p network. One could list the
        > operating system on which is running your Lightning process or the compiler
        > toolchain turning out your Lightning source code in a binary artifact.
        > Some weird kernel's memory mapping change could allow access to your
        > channel funding keys, _without_ breaking the Bitcoin consensus rules [0].
        > Moreover, your Lightning node is also relying on the existence of a
        > global Internet allowing your HTLC transaction to flow from your physical
        > host to the crowd of transactions confirming in the blockchain. Due to
        > this "protocol assumption" your channel balance would be vulnerable to
        > any change in your ISP routing policy, e.g refusing to accept your IPV4
        > traffic by a sudden desiderata to impose an IPV6 supremacy. Still
        > _without_ breaking the Bitcoin consensus rules. Of course, the odds of your
        > ISP operator adopting this behavior are really low, mostly because your
        > operator has to bind to social and economic constraints to stay in
        > business.
        >
        >
        > And I believe this imperative to stay in business is certainly not absent
        > in the incentives of the Bitcoin node operators. You're free to run any
        > policy on your node, especially one hardening the safety of your operations beyond
        > the default one. However, if you start to a transaction-relay
        > non-compatible with miner incentives, you won't have an efficient view of
        > the blockspace demand, and from then won't be able to offer compelling
        > feerates to execute your business transactions to satisfy your client
        > needs. Or you won't consolidate your wallet UTXOs at times of low-demand.
        > Indeed, a sane visibility of the mempools might not be critical now for your
        > Bitcoin operations, but this is not likely to become true with miner's
        > coinbase reward lowering with time and the system security relying on a
        > fruitful fee market.
        >
        >
        > So assuming there is a significant number of economically rational
        > entities running p2p nodes, I think it's a reasonable assumption for
        > Lightning developers that a policy maximizing miner's income and economic
        > nodes operations will be widely run on the p2p network, and therefore lay
        > its security model on that. When there is a gap between the economically
        > optimal policy (full-rbf) and the effectively deployed one (optin), and
        > this gap constitutes a flaw for exploitation, I believe it's better to
        > fix it.
        >
        >
        > If you have a different mode of thinking w.r.t how we should design
        > protocol in a trust-minimized, open, adversarial environment such as
        > Bitcoin, I'm curious to listen to it.
        >
        >
        > > If I write a python script that expects user to enter char 'a' or 'b'
        > but user can enter 'c' and there is no code to handle exceptions or other
        > chars, will it be secure?
        >
        >
        > Of course not. If you deliver any critical software, you should attach a
        > solid manual explaining all the corner cases and rough edges. Even better
        > would be to enshrine the manual directly in your software API to minimize
        > the footgunish behaviors. E.g, with any ECC library, forbidding to reuse
        > nonces. If your user still ignores or misread the manual and provides an
        > insecure input, there is not that much you can do.
        >
        >
        > By analogy, I believe that's the same with Lightning. One recommendation
        > of the deployment manual would be to be always connected to a full-rbf
        > transaction-relay topology. Defaulting to this rule and your node exposes
        > far more surface of attacks. Assuming the manual has been well-written (big
        > assumption!), I don't think the system designer would be to blame.
        >
        >
        > That said, one issue to confess with current Lightning is our lack of
        > understanding of what should be figured out in the LN user manual for
        > safe operations. I would say that's an active area of research [1] [2] [3]
        >
        >
        > > 2)full-rbf is not default in the 2 open pull requests, so this
        > experiment still relies on users changing RBF policies manually. If
        > majority of nodes use default opt-in policy, how would this affect
        > vulnerable projects?
        >
        >
        > If we define the goal as ensuring there is a significant number of
        > transaction-relay routes between the L2s nodes requiring full-rbf and the
        > set of miners supporting this policy, and the set of miners is populated
        > enough, there is no need to convince the majority of nodes operators to
        > switch to full-rbf.
        >
        >
        > Beyond landing the 'full-rbf' pull request, in pursuit of a partial
        > full-rbf deployment, I'm thinking of reaching out to Lightning vendors to
        > recommend running LN nodes operators run their full-node with the setting
        > enabled. And also to few mining pool operators to advocate the potential
        > increase in their income.
        >
        >
        > Given there are like 17000 public LN nodes, if half of them adopt full-rbf
        > it should give already a good number of full-rbf transaction-relay routes
        > across the p2p network graph. When we're there, we can measure and think
        > more about how to tune the full-rbf sub-topology.
        >
        >
        > > 2-3% transactions are replaced with opt-in RBF, if someone did not
        > replace earlier why would they do it with full RBF?
        >
        >
        > Because it's breaking the reliability and security of their use-cases.
        > Use-cases which didn't exist a few years ago. The mempool DoS vector is
        > described here [4]. To the best of my understanding, it might affect a
        > bunch of use-cases, such as dual-funded channels, on-chain DLCs, p2p
        > coinjoins, batched submarine swaps out. With the attack described, the
        > honest set of users might not have visibility of the network mempools
        > that there is a malicious, low-cost, opt-out double-spend preventing the
        > propagation of their multi-party transaction. With the existence of a
        > full-rbf transaction-relay topology, the multi-party transaction is able
        > to replace the optout.
        >
        >
        > None of those use-cases were deployed a few years ago, and the
        > understanding of the interactions with the mempool policy is still
        > nascent among their operators. However, if we assume that layering is a way
        > to grow the Bitcoin ecosystem, as I do, it is reasonable to expect they
        > will constitute a notable share of the Bitcoin transaction traffic during
        > the next decade.
        >
        >
        > > I am not opposed to full-rbf; rather, I am opposed to the notion that
        > full-rbf will solve all problems
        >
        >
        > I wished we had a magic Silver Bullet (tm) solving all the Bitcoin
        > problems...
        >
        >
        > I'm only advocating a partial full-rbf deployment to solve a real precise
        > security issue affecting multi-party funded transactions. That said,
        > full-rbf is far from solving the known set of problems affecting the L2s
        > due to interactions with network mempools. E,g, see package relay
        > motivation [5]
        >
        >
        > > I would suggest users to try Bitcoin Knots instead which already has an
        > option to disable all RBF policies if required, opt-in and full RBF policy.
        >
        >
        > Selecting a full-node to underpin any serious Bitcoin infrastructure or
        > secure a significant stack of coins should be submitted to a
        > fully-fledged decision-making process. Many factors are likely to matter
        > such as the level of activity of the contributor community, the chain of
        > trust w.r.t dependencies, the security incident track records, the
        > quality of the documentation, the exhaustivity and robustness of the set of
        > features, ...
        >
        >
        > This process might take tens of hours, to be duplicated by the number of
        > node operators who would have to do the full-node vending switch. If you
        > consider the cognitive cost at the level of the Bitcoin ecosystem, it's
        > far less costly to implement and review a few lines of codes in Bitcoin
        > Core.
        >
        >
        > > Developers should provide basic RBF policy options rather than
        > attempting to define what constitutes a good policy and removing the
        > ability to disable something when necessary.
        >
        >
        > Of course, this statement assumes there is a clear line between the
        > developers and the users. Developers are also Bitcoin users, and they're
        > modifying the software to suit their use-case needs. And that's exactly the
        > purpose of the 'full-rbf' PR I'm proposing, aiming to propose a "good"
        > policy for a Lightning node, without actually seeking to change the
        > default. If they're parties interested in implementing more RBF policy
        > options in Bitcoin Core, I think they're free to propose such changes and
        > invest the engineering effort to do so. If you're interested in advancing
        > the state of policy options in Bitcoin Core, there are a lot of
        > interesting resources available and communities to encourage you in the
        > learning process to contribute to the codebase [6].
        >
        >
        > Antoine
        >
        >
        > [0] https://dirtycow.ninja
        >
        > [1]
        > https://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md
        >
        > [2] https://arxiv.org/pdf/2006.01418.pdf
        >
        > [3] https://arxiv.org/pdf/2006.08513.pdf
        >
        > [4]
        > https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
        >
        > [5]
        > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020493.html
        >
        > [6] https://www.summerofbitcoin.org
        >
        >
        > Le jeu. 16 juin 2022 à 00:15, alicexbt <alicexbt@protonmail•com> a écrit :
        >
        >> Hi Antoine,
        >>
        >>
        >> Thanks for opening the pull request to add support for full-rbf in
        >> Bitcoin Core. I have a disagreements with the approach and questions.
        >>
        >> Recent discussions among LN devs have brought back on the surface
        >> concerns about the security of multi-party funded transactions (coinjoins,
        >> dual-funded LN channels, on-chain DLCs, ...). It turns out there is a
        >> low-fruit, naive DoS vector playable against the funding flow of any such
        >> construction due to the lack of existent full-rbf transaction-relay
        >> topology on today's p2p network [0] [1].
        >>
        >>
        >> 1)If something relies on a policy which can be changed without breaking
        >> consensus rules, how is it secure in any case with or without full rbf? If
        >> I write a python script that expects user to enter char 'a' or 'b' but user
        >> can enter 'c' and there is no code to handle exceptions or other chars,
        >> will it be secure?
        >>
        >> 2)full-rbf is not default in the 2 open pull requests, so this experiment
        >> still relies on users changing RBF policies manually. If majority of nodes
        >> use default opt-in policy, how would this affect vulnerable projects?
        >>
        >> If you're a mining operator looking to increase your income, you might be
        >> interested to experiment with full-rbf as a policy.
        >>
        >>
        >> Miners can only increase their income if users replace transactions. 2-3%
        >> transactions are replaced with opt-in RBF, if someone did not replace
        >> earlier why would they do it now even with full RBF? Or even if we add some
        >> users in it who could not signal for some reasons, do you think it would be
        >> anything above 5%?
        >>
        >> If you're a Bitcoin user or business and you don't like full-rbf, please
        >> express an opinion on how it might affect your software/operations. I'm
        >> always interested to learn more about mempool and transaction-relay
        >> interactions with upper-layers and applications and to listen to feedback
        >> in those areas, and I guess a lot of other Bitcoin researchers/devs too. I
        >> know there have been a lot of concerns about full-rbf in the past, however
        >> I believe the Bitcoin ecosystem has matured a lot since then.
        >>
        >>
        >> I am not opposed to full-rbf; rather, I am opposed to the notion that
        >> full-rbf will solve all problems and the lack of basic options in Bitcoin
        >> Core to employ/disable different RBF policies. There is also a speculation
        >> about making full RBF default in an year which isn't relevant to discuss at
        >> this point without trying different RBF policies.
        >>
        >> I would suggest users to try Bitcoin Knots instead which already has an
        >> option to disable all RBF policies if required, opt-in and full RBF policy.
        >> This can also be done using GUI if not familiar with config option
        >> mempoolreplacement​.
        >>
        >> The rationale in PR #16171 was insufficient to justify removing it in the
        >> first place, had 2 NACKs and was reopened to merge it. Why bother with a
        >> few lines of code that may allow someone disable it if required in local
        >> mempool since it's only useful when a big percentage of miners utilize it
        >> and essentially underused according to the PR author? Developers should
        >> provide basic RBF policy options rather than attempting to define what
        >> constitutes a good policy and removing the ability to disable something
        >> when necessary.
        >>
        >>
        >> /dev/fd0
        >>
        >> Sent with Proton Mail <https://proton.me/> secure email.
        >>
        >> ------- Original Message -------
        >> On Tuesday, June 14th, 2022 at 5:55 AM, Antoine Riard via bitcoin-dev <
        >> bitcoin-dev@lists•linuxfoundation.org> wrote:
        >>
        >> Hi list,
        >>
        >> Recent discussions among LN devs have brought back on the surface
        >> concerns about the security of multi-party funded transactions (coinjoins,
        >> dual-funded LN channels, on-chain DLCs, ...). It turns out there is a
        >> low-fruit, naive DoS vector playable against the funding flow of any such
        >> construction due to the lack of existent full-rbf transaction-relay
        >> topology on today's p2p network [0] [1]. While it does not consist in a
        >> direct loss of funds, if exploited well I think it's annoying enough to
        >> inflict significant timevalue loss or fee-bumping waste
        >> to the future providers or distributed swarm of users doing multi-party
        >> funded transactions. Of course, it can be fixed one layer above by
        >> introducing either fidelity bonds or a reliable centralized coordinator,
        >> though at the price of an overhead per-participant ressources cost and loss
        >> in system openness [1].
        >>
        >> For that reason, I believe it would be beneficial to the flourishing of
        >> multi-party funded transactions to fix the Dos vector by seeing a subset of
        >> the network running full-rbf and enabling propagation of honest multi-party
        >> transactions to the interested miners, replacing potential non-signaling
        >> double-spend from a malicious counterparty. Moving towards that direction,
        >> I've submitted a small patch against Bitcoin Core enabling it to turn on
        >> full-rbf as a policy, still under review [3]. The default setting stays
        >> **false**, i.e keeping opt-in RBF as a default replacement policy. I've
        >> started to run the patch on a public node at 146.190.224.15.
        >>
        >> If you're a node operator curious to play with full-rbf, feel free to
        >> connect to this node or spawn up a toy, public node yourself. There is a
        >> ##uafrbf libera chat if you would like information on the settings or
        >> looking for full-rbf friends (though that step could be automated in the
        >> future by setting up a dedicated network bit and reserving a few outbound
        >> slots for them).
        >>
        >> If you're a mining operator looking to increase your income, you might be
        >> interested to experiment with full-rbf as a policy. Indeed, in the future I
        >> believe the multi-party transactions issuers who need full-rbf to secure
        >> their funding flow should connect by default to full-rbf peers. One can
        >> conjecture that their transactions are likely to be more compelling in
        >> their feerate as their liquidity needs are higher than the simple
        >> transaction. For today, I think we have really few standards and bitcoin
        >> softwares relying on multi-party funded transactions [4].
        >>
        >> If you're a Bitcoin user or business and you don't like full-rbf, please
        >> express an opinion on how it might affect your software/operations. I'm
        >> always interested to learn more about mempool and transaction-relay
        >> interactions with upper-layers and applications and to listen to feedback
        >> in those areas, and I guess a lot of other Bitcoin researchers/devs too. I
        >> know there have been a lot of concerns about full-rbf in the past, however
        >> I believe the Bitcoin ecosystem has matured a lot since then.
        >>
        >> Any mistakes or missing context is my own.
        >>
        >> Cheers,
        >> Antoine
        >>
        >> [0] For more info about replace-by-fee, see
        >> https://bitcoinops.org/en/topics/replace-by-fee/
        >>
        >> [1] For more details about the DoS vector, see
        >> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
        >>
        >> [2] E.g I think it does not affect the Lightning Pool service, as there
        >> is a preliminary step where the participant funds are locked first in a
        >> 2-of-2 with the coordinator before being committed in the multi-party batch
        >> transaction.
        >>
        >> [3] https://github.com/bitcoin/bitcoin/pull/25353
        >>
        >> [4] E.g DLCs :
        >> https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transactions.md
        >> ; Lightning dual-funded channel :
        >> https://github.com/lightning/bolts/pull/851
        >>
        >>
        >>
        >
        
        [-- Attachment #2: Type: text/html, Size: 62260 bytes --]
        
        ^ permalink raw reply	[flat|nested] 27+ messages in thread

      • • * Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
            2022-06-21 23:43       ` Antoine Riard
          @ 2022-06-26 16:40         ` alicexbt
            2022-06-27  0:43           ` Peter Todd
            0 siblings, 1 reply; 27+ messages in thread
          From: alicexbt @ 2022-06-26 16:40 UTC (permalink / raw)
            To: Antoine Riard; +Cc: Bitcoin Protocol Discussion
          
          Hi Antoine,
          
          Thanks for sharing the DoS attack example with alternatives.
          
          > - Caroll broadcasts a double-spend of her own input C, the double-spend is attached with a low-fee (1sat/vb) and it does _not_ signal opt-in RBF
          > - Alice broadcasts the multi-party transaction, it is rejected by the network mempools because Alice double-spend is already present
          
          I think this affects almost all types of coinjoin transaction including coordinator based implementations. I tried a few things and have already reported details for an example DoS attack to one of the team but there is no response yet.
          
          It was fun playing with RBF, DoS and Coinjoin. Affected projects should share their opinion about full-rbf as it seems it might improve things.
          
          Example:
          
          In Wasabi an attacker can broadcast a transaction spending input used in coinjoin after sending signature in the round. This would result in a coinjoin tx which never gets relayed: https://nitter.net/1440000bytes/status/1540727534093905920
          
          /dev/fd0
          
          Sent with Proton Mail secure email.
          
          ------- Original Message -------
          On Tuesday, June 21st, 2022 at 11:43 PM, Antoine Riard <antoine.riard@gmail•com> wrote:
          
          
          > HI alicexbt,
          >
          > > Lets consider there are 2 users with name Bob (normal LN user) and Carol (attacker running LN node) which I will use in this email for examples. In this case Bob and Carol can manage security of their OS and it is not affected by others using vulnerable systems or OS.
          >
          > Yes, I believe my argument was the set of components making the security of your LN node is far beyond Bitcoin softwares. Of course, you might review by yourself the millions lines of code entering in the trusted computing base (OS, bootloader, BIOS, device firmwares, essential utilities, ...) on which your cryptocurrency software stack lays out, and as such exercise an extended span of control on your personal computation. Though, while I hope we'll have more LN node operators doing so, I'm not sure it's realistic to expect it will be the behavior standard among them..
          >
          > > The odds are low as you said, this can be managed by Bob and Carol because they can use a better ISP. Others using ISP with some issues may not affect their LN usage.
          >
          > Sure, though as I would like to underscore being dependent on a Bitcoin node policy and being dependent on a ISP internet traffic routing policy could be analyzed as logically equivalent, all things are equal. That said, if your personal risk aversion is too high for the Lightning security model, once it's well-understood there is a strong reliance on a censorship-resistant tx-relay network back to economically-rational miners, you're free to not use it and satisfy yourself with the Bitcoin base layer.
          >
          > > Bob might use full-rbf as its suggested by LN developers for secure LN usage and better for miners. Carol could use a different RBF policy for some nodes and mining. In this case Bob may get affected at some point because of Carol's choice to use a different RBF policy which was not true above.
          >
          > Indeed, your secure LN usage is going to be dependent of the number of p2p network nodes running an economically-rational policy like full-rbf. That said, I think it's reasonable to assume that the players of the Bitcoin game are economically-rational, and as such incentived to pick up a policy such as full-rbf. I know the term "economically-rational" is poorly defined here, and I think it could be interesting for any academic with an economic background to study the incentives of Bitcoin actors.
          >
          > > Allowing users to create different mempool policies is great. My thought process is to code for happy path, where X policy is expected for replacement and edge cases where Y policy or no policy would be used. Users can try out different policies and even act as attackers. This is also true for other things in mempool, 'spkreuse=conflict' prevents address reuse in the mempool when using knots. If I assume that address reuse is always relayed, this could become a problem if some users and miners adopt this setting in their mempool.
          >
          > Agree, I'm all in for people to experiment with mempool policies. Though at the end it's a software engineering resource question. If users are interested in more features, they're always free to implement themselves. Really, the binary distinction developers-vs-users doesn't make sense and if we would like Bitcoin to be successful in the long-term, we should promote high degree of software literacy among bitcoiners.
          >
          > > This makes sense and I would be interested to follow two things once full-rbf is available in a bitcoin core release: 1. Percentage of transaction getting replaced 2. Miners profit (Fee for replaced Tx - Fee for original Tx)
          >
          > Yes, I would be interested too to have those metrics once full-rbf is available in a bitcoin core release. I think that's something every full-rbf curious node operator could observe on its own with a few more loggers, at least for the first metric.
          >
          > > Can you explain how p2p coinjoin is affected with mempool DoS vector with some examples? What is considered a p2p coinjoin? Joinmarket or [Stonewall][1]?
          >
          > I don't remember the Joinmarket code right now and I don't know the ins and outs of Samourai coinjoin as I'm not sure the code is open source. Though let's say for a p2p coinjoin as one you can build once you have implemented LN's interactive construction protocol [0].
          >
          > [0] https://github.com/lightning/bolts/pull/851
          >
          > Here the DoS attack situation :
          > - Alice, Bob and Caroll would like to coinjoin 3 inputs to 3 outputs
          > - Each of the input is singly controlled by one party, e.g Alice owns input A, Bob owns input B, ...
          > - Alice, Bob and Caroll exchanges a PSBT to build a multi-party funded transaction (the coinjoin_tx)
          > - Alice is elected as the multi-party transaction broadcaster once the signatures have been exchanged
          > - The block feerate is around 10sat/vb
          > - One of the transaction input signals opt-in RBF, the transaction is attached a compelling feerate 10sat/vb
          > - Caroll broadcasts a double-spend of her own input C, the double-spend is attached with a low-fee (1sat/vb) and it does _not_ signal opt-in RBF
          > - Alice broadcasts the multi-party transaction, it is rejected by the network mempools because Alice double-spend is already present
          > - Two alternatives are offered to the coinjoin participants :
          >
          > Alternative A)
          > - They estimate the multi-party feerate as not high enough
          > - They fee-bump at 20sat/vb
          > - Caroll double-spend one of the input of her malicious double-spend to eject it from the network mempools
          > - The multi-party transaction is confirmed at a block feerare far above what was necessary
          > - Alice, Bob, Caroll have loss fee-bumping value without compensation
          > - Note, even if Caroll is attacker and assuming the fee-bumping burden is fairly spread among participants, the economic loss inflicted is asymmetric
          >
          > Alternative B)
          > - They wait until some time-out
          > - They double-spend their own inputs, Alice double-spend utxo A, Bob double-spend utxo B
          > - They wasted the timevalue of their inputs for the time-out delay
          > - Note, even if Caroll is attacker and loss some timevalue too, the economic loss inflicted is asymmetric
          >
          > Let me know if you see any error or wrong in this DoS scenario exposure. I believe it's fairly simple to execute
          > for a medium-skilled attacker.
          >
          > Antoine
          >
          > Le ven. 17 juin 2022 à 00:54, alicexbt <alicexbt@protonmail•com> a écrit :
          >
          > > Hi Antoine,
          > >
          > >
          > >
          > > > One could list the operating system on which is running your Lightning process or the compiler toolchain turning out your Lightning source code in a binary artifact. Some weird kernel's memory mapping change could allow access to your channel funding keys, _without_ breaking the Bitcoin consensus rules [0].
          > >
          > > Lets consider there are 2 users with name Bob (normal LN user) and Carol (attacker running LN node) which I will use in this email for examples. In this case Bob and Carol can manage security of their OS and it is not affected by others using vulnerable systems or OS.
          > >
          > >
          > > > Moreover, your Lightning node is also relying on the existence of a global Internet allowing your HTLC transaction to flow from your physical host to the crowd of transactions confirming in the blockchain. Due to this "protocol assumption" your channel balance would be vulnerable to any change in your ISP routing policy, e.g refusing to accept your IPV4 traffic by a sudden desiderata to impose an IPV6 supremacy. Still _without_ breaking the Bitcoin consensus rules. Of course, the odds of your ISP operator adopting this behavior are really low, mostly because your operator has to bind to social and economic constraints to stay in business.
          > >
          > > The odds are low as you said, this can be managed by Bob and Carol because they can use a better ISP. Others using ISP with some issues may not affect their LN usage.
          > >
          > >
          > > > And I believe this imperative to stay in business is certainly not absent in the incentives of the Bitcoin node operators. You're free to run any policy on your node, especially one hardening the safety of your operations beyond the default one. However, if you start to a transaction-relay non-compatible with miner incentives, you won't have an efficient view of the blockspace demand, and from then won't be able to offer compelling feerates to execute your business transactions to satisfy your client needs. Or you won't consolidate your wallet UTXOs at times of low-demand. Indeed, a sane visibility of the mempools might not be critical now for your Bitcoin operations, but this is not likely to become true with miner's coinbase reward lowering with time and the system security relying on a fruitful fee market.
          > >
          > > Bob might use full-rbf as its suggested by LN developers for secure LN usage and better for miners. Carol could use a different RBF policy for some nodes and mining. In this case Bob may get affected at some point because of Carol's choice to use a different RBF policy which was not true above.
          > >
          > >
          > >
          > > > So assuming there is a significant number of economically rational entities running p2p nodes, I think it's a reasonable assumption for Lightning developers that a policy maximizing miner's income and economic nodes operations will be widely run on the p2p network, and therefore lay its security model on that. When there is a gap between the economically optimal policy (full-rbf) and the effectively deployed one (optin), and this gap constitutes a flaw for exploitation, I believe it's better to fix it.
          > >
          > > Agree with the assumption there is nothing wrong in experimenting with a new RBF policy (non-default) if that helps some users and projects.
          > >
          > >
          > > > If you have a different mode of thinking w.r.t how we should design protocol in a trust-minimized, open, adversarial environment such as Bitcoin, I'm curious to listen to it.
          > >
          > > Allowing users to create different mempool policies is great. My thought process is to code for happy path, where X policy is expected for replacement and edge cases where Y policy or no policy would be used. Users can try out different policies and even act as attackers. This is also true for other things in mempool, 'spkreuse=conflict' prevents address reuse in the mempool when using knots. If I assume that address reuse is always relayed, this could become a problem if some users and miners adopt this setting in their mempool.
          > >
          > >
          > > > Of course not. If you deliver any critical software, you should attach a solid manual explaining all the corner cases and rough edges. Even better would be to enshrine the manual directly in your software API to minimize the footgunish behaviors. E.g, with any ECC library, forbidding to reuse nonces. If your user still ignores or misread the manual and provides an insecure input, there is not that much you can do.
          > >
          > > Agree with the documentation as it helps users.
          > >
          > >
          > > > Given there are like 17000 public LN nodes, if half of them adopt full-rbf it should give already a good number of full-rbf transaction-relay routes across the p2p network graph. When we're there, we can measure and think more about how to tune the full-rbf sub-topology.
          > >
          > > Sounds good.
          > >
          > >
          > > > Because it's breaking the reliability and security of their use-cases. Use-cases which didn't exist a few years ago. The mempool DoS vector is described here [4]. To the best of my understanding, it might affect a bunch of use-cases, such as dual-funded channels, on-chain DLCs, p2p coinjoins, batched submarine swaps out. With the attack described, the honest set of users might not have visibility of the network mempools that there is a malicious, low-cost, opt-out double-spend preventing the propagation of their multi-party transaction. With the existence of a full-rbf transaction-relay topology, the multi-party transaction is able to replace the optout.
          > >
          > > This makes sense and I would be interested to follow two things once full-rbf is available in a bitcoin core release: 1. Percentage of transaction getting replaced 2. Miners profit (Fee for replaced Tx - Fee for original Tx)
          > >
          > >
          > > Can you explain how p2p coinjoin is affected with mempool DoS vector with some examples? What is considered a p2p coinjoin? Joinmarket or [Stonewall][1]?
          > >
          > >
          > > > Selecting a full-node to underpin any serious Bitcoin infrastructure or secure a significant stack of coins should be submitted to a fully-fledged decision-making process. Many factors are likely to matter such as the level of activity of the contributor community, the chain of trust w.r.t dependencies, the security incident track records, the quality of the documentation, the exhaustivity and robustness of the set of features, ...
          > >
          > > I agree that contributor community and documentation could be improved in Knots.
          > >
          > >
          > > > Developers are also Bitcoin users, and they're modifying the software to suit their use-case needs. And that's exactly the purpose of the 'full-rbf' PR I'm proposing, aiming to propose a "good" policy for a Lightning node, without actually seeking to change the default.
          > >
          > > I like that default still remains opt-in and cool with different policies being tried out if that helps some users.
          > >
          > >
          > > > If they're parties interested in implementing more RBF policy options in Bitcoin Core, I think they're free to propose such changes and invest the engineering effort to do so. If you're interested in advancing the state of policy options in Bitcoin Core, there are a lot of interesting resources available and communities to encourage you in the learning process to contribute to the codebase [6].
          > >
          > > Thanks for sharing the link. I would love to see 5 RBF policies available to use in bitcoin core. I have already tried experimenting with a few on regtest and will try to open pull request if there are enough people interested to test it on other chains (testnet3, signet, mainnet)
          > >
          > >
          > > [1]: https://docs.samourai.io/spend-tools
          > >
          > >
          > >
          > >
          > > /dev/fd0
          > >
          > >
          > >
          > > Sent with Proton Mail secure email.
          > >
          > > ------- Original Message -------
          > > On Friday, June 17th, 2022 at 7:04 AM, Antoine Riard <antoine.riard@gmail•com> wrote:
          > >
          > >
          > > > Hi alicexbt,
          > > >
          > > >
          > > >
          > > > Thanks for taking time to review the pull request,
          > > >
          > > >
          > > >
          > > > > 1)If something relies on a policy which can be changed without breaking consensus rules, how is it secure in any case with or without full rbf?
          > > >
          > > >
          > > >
          > > > Your Lightning node software relies on far more software and hardware components than the transaction-relay p2p network. One could list the operating system on which is running your Lightning process or the compiler toolchain turning out your Lightning source code in a binary artifact. Some weird kernel's memory mapping change could allow access to your channel funding keys, _without_ breaking the Bitcoin consensus rules [0]. Moreover, your Lightning node is also relying on the existence of a global Internet allowing your HTLC transaction to flow from your physical host to the crowd of transactions confirming in the blockchain. Due to this "protocol assumption" your channel balance would be vulnerable to any change in your ISP routing policy, e.g refusing to accept your IPV4 traffic by a sudden desiderata to impose an IPV6 supremacy. Still _without_ breaking the Bitcoin consensus rules. Of course, the odds of your ISP operator adopting this behavior are really low, mostly because your operator has to bind to social and economic constraints to stay in business.
          > > >
          > > >
          > > >
          > > > And I believe this imperative to stay in business is certainly not absent in the incentives of the Bitcoin node operators. You're free to run any policy on your node, especially one hardening the safety of your operations beyond the default one. However, if you start to a transaction-relay non-compatible with miner incentives, you won't have an efficient view of the blockspace demand, and from then won't be able to offer compelling feerates to execute your business transactions to satisfy your client needs. Or you won't consolidate your wallet UTXOs at times of low-demand. Indeed, a sane visibility of the mempools might not be critical now for your Bitcoin operations, but this is not likely to become true with miner's coinbase reward lowering with time and the system security relying on a fruitful fee market.
          > > >
          > > >
          > > >
          > > > So assuming there is a significant number of economically rational entities running p2p nodes, I think it's a reasonable assumption for Lightning developers that a policy maximizing miner's income and economic nodes operations will be widely run on the p2p network, and therefore lay its security model on that. When there is a gap between the economically optimal policy (full-rbf) and the effectively deployed one (optin), and this gap constitutes a flaw for exploitation, I believe it's better to fix it.
          > > >
          > > >
          > > >
          > > > If you have a different mode of thinking w.r.t how we should design protocol in a trust-minimized, open, adversarial environment such as Bitcoin, I'm curious to listen to it.
          > > >
          > > >
          > > >
          > > > > If I write a python script that expects user to enter char 'a' or 'b' but user can enter 'c' and there is no code to handle exceptions or other chars, will it be secure?
          > > >
          > > >
          > > >
          > > > Of course not. If you deliver any critical software, you should attach a solid manual explaining all the corner cases and rough edges. Even better would be to enshrine the manual directly in your software API to minimize the footgunish behaviors. E.g, with any ECC library, forbidding to reuse nonces. If your user still ignores or misread the manual and provides an insecure input, there is not that much you can do.
          > > >
          > > >
          > > >
          > > > By analogy, I believe that's the same with Lightning. One recommendation of the deployment manual would be to be always connected to a full-rbf transaction-relay topology. Defaulting to this rule and your node exposes far more surface of attacks. Assuming the manual has been well-written (big assumption!), I don't think the system designer would be to blame.
          > > >
          > > >
          > > >
          > > > That said, one issue to confess with current Lightning is our lack of understanding of what should be figured out in the LN user manual for safe operations. I would say that's an active area of research [1] [2] [3]
          > > >
          > > >
          > > >
          > > > > 2)full-rbf is not default in the 2 open pull requests, so this experiment still relies on users changing RBF policies manually. If majority of nodes use default opt-in policy, how would this affect vulnerable projects?
          > > >
          > > >
          > > >
          > > > If we define the goal as ensuring there is a significant number of transaction-relay routes between the L2s nodes requiring full-rbf and the set of miners supporting this policy, and the set of miners is populated enough, there is no need to convince the majority of nodes operators to switch to full-rbf.
          > > >
          > > >
          > > >
          > > > Beyond landing the 'full-rbf' pull request, in pursuit of a partial full-rbf deployment, I'm thinking of reaching out to Lightning vendors to recommend running LN nodes operators run their full-node with the setting enabled. And also to few mining pool operators to advocate the potential increase in their income.
          > > >
          > > >
          > > >
          > > > Given there are like 17000 public LN nodes, if half of them adopt full-rbf it should give already a good number of full-rbf transaction-relay routes across the p2p network graph. When we're there, we can measure and think more about how to tune the full-rbf sub-topology.
          > > >
          > > >
          > > >
          > > > > 2-3% transactions are replaced with opt-in RBF, if someone did not replace earlier why would they do it with full RBF?
          > > >
          > > >
          > > >
          > > > Because it's breaking the reliability and security of their use-cases. Use-cases which didn't exist a few years ago. The mempool DoS vector is described here [4]. To the best of my understanding, it might affect a bunch of use-cases, such as dual-funded channels, on-chain DLCs, p2p coinjoins, batched submarine swaps out. With the attack described, the honest set of users might not have visibility of the network mempools that there is a malicious, low-cost, opt-out double-spend preventing the propagation of their multi-party transaction. With the existence of a full-rbf transaction-relay topology, the multi-party transaction is able to replace the optout.
          > > >
          > > >
          > > >
          > > > None of those use-cases were deployed a few years ago, and the understanding of the interactions with the mempool policy is still nascent among their operators. However, if we assume that layering is a way to grow the Bitcoin ecosystem, as I do, it is reasonable to expect they will constitute a notable share of the Bitcoin transaction traffic during the next decade.
          > > >
          > > >
          > > >
          > > > > I am not opposed to full-rbf; rather, I am opposed to the notion that full-rbf will solve all problems
          > > >
          > > >
          > > >
          > > > I wished we had a magic Silver Bullet (tm) solving all the Bitcoin problems...
          > > >
          > > >
          > > >
          > > > I'm only advocating a partial full-rbf deployment to solve a real precise security issue affecting multi-party funded transactions. That said, full-rbf is far from solving the known set of problems affecting the L2s due to interactions with network mempools. E,g, see package relay motivation [5]
          > > >
          > > >
          > > >
          > > > > I would suggest users to try Bitcoin Knots instead which already has an option to disable all RBF policies if required, opt-in and full RBF policy.
          > > >
          > > >
          > > >
          > > > Selecting a full-node to underpin any serious Bitcoin infrastructure or secure a significant stack of coins should be submitted to a fully-fledged decision-making process. Many factors are likely to matter such as the level of activity of the contributor community, the chain of trust w.r.t dependencies, the security incident track records, the quality of the documentation, the exhaustivity and robustness of the set of features, ...
          > > >
          > > >
          > > >
          > > > This process might take tens of hours, to be duplicated by the number of node operators who would have to do the full-node vending switch. If you consider the cognitive cost at the level of the Bitcoin ecosystem, it's far less costly to implement and review a few lines of codes in Bitcoin Core.
          > > >
          > > >
          > > >
          > > > > Developers should provide basic RBF policy options rather than attempting to define what constitutes a good policy and removing the ability to disable something when necessary.
          > > >
          > > >
          > > >
          > > > Of course, this statement assumes there is a clear line between the developers and the users. Developers are also Bitcoin users, and they're modifying the software to suit their use-case needs. And that's exactly the purpose of the 'full-rbf' PR I'm proposing, aiming to propose a "good" policy for a Lightning node, without actually seeking to change the default. If they're parties interested in implementing more RBF policy options in Bitcoin Core, I think they're free to propose such changes and invest the engineering effort to do so. If you're interested in advancing the state of policy options in Bitcoin Core, there are a lot of interesting resources available and communities to encourage you in the learning process to contribute to the codebase [6].
          > > >
          > > >
          > > >
          > > > Antoine
          > > >
          > > >
          > > >
          > > > [0] https://dirtycow.ninja
          > > >
          > > > [1] https://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md
          > > >
          > > > [2] https://arxiv.org/pdf/2006.01418.pdf
          > > >
          > > > [3] https://arxiv.org/pdf/2006.08513.pdf
          > > >
          > > > [4] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
          > > >
          > > > [5] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020493.html
          > > >
          > > > [6] https://www.summerofbitcoin.org
          > > >
          > > >
          > > > Le jeu. 16 juin 2022 à 00:15, alicexbt <alicexbt@protonmail•com> a écrit :
          > > >
          > > > > Hi Antoine,
          > > > >
          > > > >
          > > > > Thanks for opening the pull request to add support for full-rbf in Bitcoin Core. I have a disagreements with the approach and questions.
          > > > >
          > > > >
          > > > > > Recent discussions among LN devs have brought back on the surface concerns about the security of multi-party funded transactions (coinjoins, dual-funded LN channels, on-chain DLCs, ...). It turns out there is a low-fruit, naive DoS vector playable against the funding flow of any such construction due to the lack of existent full-rbf transaction-relay topology on today's p2p network [0] [1].
          > > > >
          > > > > 1)If something relies on a policy which can be changed without breaking consensus rules, how is it secure in any case with or without full rbf? If I write a python script that expects user to enter char 'a' or 'b' but user can enter 'c' and there is no code to handle exceptions or other chars, will it be secure?
          > > > >
          > > > > 2)full-rbf is not default in the 2 open pull requests, so this experiment still relies on users changing RBF policies manually. If majority of nodes use default opt-in policy, how would this affect vulnerable projects?
          > > > >
          > > > >
          > > > > > If you're a mining operator looking to increase your income, you might be interested to experiment with full-rbf as a policy.
          > > > >
          > > > > Miners can only increase their income if users replace transactions. 2-3% transactions are replaced with opt-in RBF, if someone did not replace earlier why would they do it now even with full RBF? Or even if we add some users in it who could not signal for some reasons, do you think it would be anything above 5%?
          > > > >
          > > > >
          > > > > > If you're a Bitcoin user or business and you don't like full-rbf, please express an opinion on how it might affect your software/operations. I'm always interested to learn more about mempool and transaction-relay interactions with upper-layers and applications and to listen to feedback in those areas, and I guess a lot of other Bitcoin researchers/devs too. I know there have been a lot of concerns about full-rbf in the past, however I believe the Bitcoin ecosystem has matured a lot since then.
          > > > >
          > > > > I am not opposed to full-rbf; rather, I am opposed to the notion that full-rbf will solve all problems and the lack of basic options in Bitcoin Core to employ/disable different RBF policies. There is also a speculation about making full RBF default in an year which isn't relevant to discuss at this point without trying different RBF policies.
          > > > >
          > > > > I would suggest users to try Bitcoin Knots instead which already has an option to disable all RBF policies if required, opt-in and full RBF policy. This can also be done using GUI if not familiar with config option `mempoolreplacement`.
          > > > >
          > > > > The rationale in PR #16171 was insufficient to justify removing it in the first place, had 2 NACKs and was reopened to merge it. Why bother with a few lines of code that may allow someone disable it if required in local mempool since it's only useful when a big percentage of miners utilize it and essentially underused according to the PR author? Developers should provide basic RBF policy options rather than attempting to define what constitutes a good policy and removing the ability to disable something when necessary.
          > > > >
          > > > >
          > > > > /dev/fd0
          > > > >
          > > > >
          > > > > Sent with Proton Mail secure email.
          > > > >
          > > > > ------- Original Message -------
          > > > > On Tuesday, June 14th, 2022 at 5:55 AM, Antoine Riard via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
          > > > >
          > > > >
          > > > > > Hi list,
          > > > > >
          > > > > > Recent discussions among LN devs have brought back on the surface concerns about the security of multi-party funded transactions (coinjoins, dual-funded LN channels, on-chain DLCs, ...). It turns out there is a low-fruit, naive DoS vector playable against the funding flow of any such construction due to the lack of existent full-rbf transaction-relay topology on today's p2p network [0] [1]. While it does not consist in a direct loss of funds, if exploited well I think it's annoying enough to inflict significant timevalue loss or fee-bumping waste
          > > > > > to the future providers or distributed swarm of users doing multi-party funded transactions. Of course, it can be fixed one layer above by introducing either fidelity bonds or a reliable centralized coordinator, though at the price of an overhead per-participant ressources cost and loss in system openness [1].
          > > > > >
          > > > > > For that reason, I believe it would be beneficial to the flourishing of multi-party funded transactions to fix the Dos vector by seeing a subset of the network running full-rbf and enabling propagation of honest multi-party transactions to the interested miners, replacing potential non-signaling double-spend from a malicious counterparty. Moving towards that direction, I've submitted a small patch against Bitcoin Core enabling it to turn on full-rbf as a policy, still under review [3]. The default setting stays **false**, i.e keeping opt-in RBF as a default replacement policy. I've started to run the patch on a public node at 146.190.224.15.
          > > > > >
          > > > > > If you're a node operator curious to play with full-rbf, feel free to connect to this node or spawn up a toy, public node yourself. There is a ##uafrbf libera chat if you would like information on the settings or looking for full-rbf friends (though that step could be automated in the future by setting up a dedicated network bit and reserving a few outbound slots for them).
          > > > > >
          > > > > > If you're a mining operator looking to increase your income, you might be interested to experiment with full-rbf as a policy. Indeed, in the future I believe the multi-party transactions issuers who need full-rbf to secure their funding flow should connect by default to full-rbf peers. One can conjecture that their transactions are likely to be more compelling in their feerate as their liquidity needs are higher than the simple transaction. For today, I think we have really few standards and bitcoin softwares relying on multi-party funded transactions [4].
          > > > > >
          > > > > > If you're a Bitcoin user or business and you don't like full-rbf, please express an opinion on how it might affect your software/operations. I'm always interested to learn more about mempool and transaction-relay interactions with upper-layers and applications and to listen to feedback in those areas, and I guess a lot of other Bitcoin researchers/devs too. I know there have been a lot of concerns about full-rbf in the past, however I believe the Bitcoin ecosystem has matured a lot since then.
          > > > > >
          > > > > > Any mistakes or missing context is my own.
          > > > > >
          > > > > > Cheers,
          > > > > > Antoine
          > > > > >
          > > > > > [0] For more info about replace-by-fee, see https://bitcoinops.org/en/topics/replace-by-fee/
          > > > > >
          > > > > > [1] For more details about the DoS vector, see https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
          > > > > >
          > > > > > [2] E.g I think it does not affect the Lightning Pool service, as there is a preliminary step where the participant funds are locked first in a 2-of-2 with the coordinator before being committed in the multi-party batch transaction.
          > > > > >
          > > > > > [3] https://github.com/bitcoin/bitcoin/pull/25353
          > > > > >
          > > > > > [4] E.g DLCs : https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transactions.md ; Lightning dual-funded channel : https://github.com/lightning/bolts/pull/851
          
          
          ^ permalink raw reply	[flat|nested] 27+ messages in thread

        • • * Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
              2022-06-26 16:40         ` alicexbt
            @ 2022-06-27  0:43           ` Peter Todd
              2022-06-27 12:03             ` Greg Sanders
              2022-07-05 20:46             ` alicexbt
              0 siblings, 2 replies; 27+ messages in thread
            From: Peter Todd @ 2022-06-27  0:43 UTC (permalink / raw)
              To: alicexbt, Bitcoin Protocol Discussion
            
            [-- Attachment #1: Type: text/plain, Size: 1568 bytes --]
            
            On Sun, Jun 26, 2022 at 04:40:24PM +0000, alicexbt via bitcoin-dev wrote:
            > Hi Antoine,
            > 
            > Thanks for sharing the DoS attack example with alternatives.
            > 
            > > - Caroll broadcasts a double-spend of her own input C, the double-spend is attached with a low-fee (1sat/vb) and it does _not_ signal opt-in RBF
            > > - Alice broadcasts the multi-party transaction, it is rejected by the network mempools because Alice double-spend is already present
            > 
            > I think this affects almost all types of coinjoin transaction including coordinator based implementations. I tried a few things and have already reported details for an example DoS attack to one of the team but there is no response yet.
            > 
            > It was fun playing with RBF, DoS and Coinjoin. Affected projects should share their opinion about full-rbf as it seems it might improve things.
            > 
            > Example:
            > 
            > In Wasabi an attacker can broadcast a transaction spending input used in coinjoin after sending signature in the round. This would result in a coinjoin tx which never gets relayed: https://nitter.net/1440000bytes/status/1540727534093905920
            
            Note that Wasabi already has a DoS attack vector in that a participant can stop
            participating after the first phase of the round, with the result that the
            coinjoin fails. Wasabi mitigates that by punishing participating in future
            rounds. Double-spends only create additional types of DoS attack that need to
            be detected and punished as well - they don't create a fundamentally new
            vulerability.
            
            -- 
            https://petertodd.org 'peter'[:-1]@petertodd.org
            
            [-- Attachment #2: signature.asc --]
            [-- Type: application/pgp-signature, Size: 488 bytes --]
            
            ^ permalink raw reply	[flat|nested] 27+ messages in thread

          • • * Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
                2022-06-27  0:43           ` Peter Todd
              @ 2022-06-27 12:03             ` Greg Sanders
                2022-06-27 13:46               ` Peter Todd
                2022-07-05 20:46             ` alicexbt
                1 sibling, 1 reply; 27+ messages in thread
              From: Greg Sanders @ 2022-06-27 12:03 UTC (permalink / raw)
                To: Peter Todd, Bitcoin Protocol Discussion
              
              [-- Attachment #1: Type: text/plain, Size: 2059 bytes --]
              
              One key difference seems to be that properly punishing someone based on
              mempool behavior seems much more difficult. As we all know there is no "the
              mempool".
              
              
              
              On Sun, Jun 26, 2022, 8:43 PM Peter Todd via bitcoin-dev <
              bitcoin-dev@lists•linuxfoundation.org> wrote:
              
              > On Sun, Jun 26, 2022 at 04:40:24PM +0000, alicexbt via bitcoin-dev wrote:
              > > Hi Antoine,
              > >
              > > Thanks for sharing the DoS attack example with alternatives.
              > >
              > > > - Caroll broadcasts a double-spend of her own input C, the
              > double-spend is attached with a low-fee (1sat/vb) and it does _not_ signal
              > opt-in RBF
              > > > - Alice broadcasts the multi-party transaction, it is rejected by the
              > network mempools because Alice double-spend is already present
              > >
              > > I think this affects almost all types of coinjoin transaction including
              > coordinator based implementations. I tried a few things and have already
              > reported details for an example DoS attack to one of the team but there is
              > no response yet.
              > >
              > > It was fun playing with RBF, DoS and Coinjoin. Affected projects should
              > share their opinion about full-rbf as it seems it might improve things.
              > >
              > > Example:
              > >
              > > In Wasabi an attacker can broadcast a transaction spending input used in
              > coinjoin after sending signature in the round. This would result in a
              > coinjoin tx which never gets relayed:
              > https://nitter.net/1440000bytes/status/1540727534093905920
              >
              > Note that Wasabi already has a DoS attack vector in that a participant can
              > stop
              > participating after the first phase of the round, with the result that the
              > coinjoin fails. Wasabi mitigates that by punishing participating in future
              > rounds. Double-spends only create additional types of DoS attack that need
              > to
              > be detected and punished as well - they don't create a fundamentally new
              > vulerability.
              >
              > --
              > https://petertodd.org 'peter'[:-1]@petertodd.org
              > _______________________________________________
              > bitcoin-dev mailing list
              > bitcoin-dev@lists•linuxfoundation.org
              > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
              >
              
              [-- Attachment #2: Type: text/html, Size: 3106 bytes --]
              
              ^ permalink raw reply	[flat|nested] 27+ messages in thread

            • • * Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
                  2022-06-27 12:03             ` Greg Sanders
                @ 2022-06-27 13:46               ` Peter Todd
                  0 siblings, 0 replies; 27+ messages in thread
                From: Peter Todd @ 2022-06-27 13:46 UTC (permalink / raw)
                  To: Greg Sanders, Bitcoin Protocol Discussion
                
                
                
                On June 27, 2022 8:03:38 AM EDT, Greg Sanders <gsanders87@gmail•com> wrote:
                >One key difference seems to be that properly punishing someone based on
                >mempool behavior seems much more difficult. As we all know there is no "the
                >mempool".
                
                No, that's not relevant here: the DoS condition is the existence of a (mined) double spend for a given txout used in a coin join. That condition is entirely under the control of the wallet, and can be totally avoided by the wallet regardless of mempool behavior.
                
                
                ^ permalink raw reply	[flat|nested] 27+ messages in thread

            • * Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
                2022-06-27  0:43           ` Peter Todd
                2022-06-27 12:03             ` Greg Sanders
              @ 2022-07-05 20:46             ` alicexbt
                2022-07-08 14:53               ` Peter Todd
                1 sibling, 1 reply; 27+ messages in thread
              From: alicexbt @ 2022-07-05 20:46 UTC (permalink / raw)
                To: Peter Todd; +Cc: Bitcoin Protocol Discussion
              
              Hi Peter,
              
              > Note that Wasabi already has a DoS attack vector in that a participant can stop
              > participating after the first phase of the round, with the result that the
              > coinjoin fails. Wasabi mitigates that by punishing participating in future
              > rounds. Double-spends only create additional types of DoS attack that need to
              > be detected and punished as well - they don't create a fundamentally new
              > vulerability.
              
              I agree some DoS vectors are already mitigated however punishment in this case will be difficult because the transaction is broadcasted after signing and before coinjoin tx broadcast.
              
              Inputs are already checked multiple times for double spend during coinjoin round: https://github.com/zkSNACKs/WalletWasabi/pull/6460
              
              If all the inputs in the coinjoin transaction that failed to relay are checked and one or more are found to be spent later, what will be punished and how does this affect the attacker with thousands of UTXOs or normal users?
              
              /dev/fd0
              
              Sent with Proton Mail secure email.
              
              ------- Original Message -------
              On Monday, June 27th, 2022 at 12:43 AM, Peter Todd <pete@petertodd•org> wrote:
              
              
              > On Sun, Jun 26, 2022 at 04:40:24PM +0000, alicexbt via bitcoin-dev wrote:
              >
              > > Hi Antoine,
              > >
              > > Thanks for sharing the DoS attack example with alternatives.
              > >
              > > > - Caroll broadcasts a double-spend of her own input C, the double-spend is attached with a low-fee (1sat/vb) and it does not signal opt-in RBF
              > > > - Alice broadcasts the multi-party transaction, it is rejected by the network mempools because Alice double-spend is already present
              > >
              > > I think this affects almost all types of coinjoin transaction including coordinator based implementations. I tried a few things and have already reported details for an example DoS attack to one of the team but there is no response yet.
              > >
              > > It was fun playing with RBF, DoS and Coinjoin. Affected projects should share their opinion about full-rbf as it seems it might improve things.
              > >
              > > Example:
              > >
              > > In Wasabi an attacker can broadcast a transaction spending input used in coinjoin after sending signature in the round. This would result in a coinjoin tx which never gets relayed: https://nitter.net/1440000bytes/status/1540727534093905920
              >
              >
              > Note that Wasabi already has a DoS attack vector in that a participant can stop
              > participating after the first phase of the round, with the result that the
              > coinjoin fails. Wasabi mitigates that by punishing participating in future
              > rounds. Double-spends only create additional types of DoS attack that need to
              > be detected and punished as well - they don't create a fundamentally new
              > vulerability.
              >
              > --
              > https://petertodd.org 'peter'[:-1]@petertodd.org
              
              
              ^ permalink raw reply	[flat|nested] 27+ messages in thread

            • • * Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
                  2022-07-05 20:46             ` alicexbt
                @ 2022-07-08 14:53               ` Peter Todd
                  2022-07-08 15:09                 ` Greg Sanders
                                                   ` (2 more replies)
                  0 siblings, 3 replies; 27+ messages in thread
                From: Peter Todd @ 2022-07-08 14:53 UTC (permalink / raw)
                  To: alicexbt; +Cc: Bitcoin Protocol Discussion
                
                [-- Attachment #1: Type: text/plain, Size: 1520 bytes --]
                
                On Tue, Jul 05, 2022 at 08:46:51PM +0000, alicexbt wrote:
                > Hi Peter,
                > 
                > > Note that Wasabi already has a DoS attack vector in that a participant can stop
                > > participating after the first phase of the round, with the result that the
                > > coinjoin fails. Wasabi mitigates that by punishing participating in future
                > > rounds. Double-spends only create additional types of DoS attack that need to
                > > be detected and punished as well - they don't create a fundamentally new
                > > vulerability.
                > 
                > I agree some DoS vectors are already mitigated however punishment in this case will be difficult because the transaction is broadcasted after signing and before coinjoin tx broadcast.
                > 
                > Inputs are already checked multiple times for double spend during coinjoin round: https://github.com/zkSNACKs/WalletWasabi/pull/6460
                > 
                > If all the inputs in the coinjoin transaction that failed to relay are checked and one or more are found to be spent later, what will be punished and how does this affect the attacker with thousands of UTXOs or normal users?
                
                Point is, the attacker is thousands of UTXOs can also DoS rounds by simply
                failing to complete the round. In fact, the double-spend DoS attack requires
                more resources, because for a double-spend to be succesful, BTC has to be spent
                on fees.
                
                It's just a fact of life that a motivated attacker can DoS attack Wasabi by
                spending money. That's a design choice that's serving them well so far.
                
                -- 
                https://petertodd.org 'peter'[:-1]@petertodd.org
                
                [-- Attachment #2: signature.asc --]
                [-- Type: application/pgp-signature, Size: 833 bytes --]
                
                ^ permalink raw reply	[flat|nested] 27+ messages in thread

              • • * Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
                    2022-07-08 14:53               ` Peter Todd
                  @ 2022-07-08 15:09                 ` Greg Sanders
                    2022-07-08 19:44                 ` alicexbt
                    2022-07-09 15:06                 ` Antoine Riard
                    2 siblings, 0 replies; 27+ messages in thread
                  From: Greg Sanders @ 2022-07-08 15:09 UTC (permalink / raw)
                    To: Peter Todd, Bitcoin Protocol Discussion
                  
                  [-- Attachment #1: Type: text/plain, Size: 2321 bytes --]
                  
                  The attacker isn't guaranteed to spend *any* funds to disrupt the protocol
                  indefinitely, that's the issue here. In this scenario, her input double
                  spend is at an impractical feerate, and is never included in a block,
                  sitting at the bottom of the mempool.
                  
                  The other users' only practical choice is to double-spend their own input
                  to get their money back(at competitive rates much higher than the
                  attacker), or wait and hope you win a propagation race somewhere.
                  
                  
                  
                  On Fri, Jul 8, 2022 at 10:53 AM Peter Todd via bitcoin-dev <
                  bitcoin-dev@lists•linuxfoundation.org> wrote:
                  
                  > On Tue, Jul 05, 2022 at 08:46:51PM +0000, alicexbt wrote:
                  > > Hi Peter,
                  > >
                  > > > Note that Wasabi already has a DoS attack vector in that a participant
                  > can stop
                  > > > participating after the first phase of the round, with the result that
                  > the
                  > > > coinjoin fails. Wasabi mitigates that by punishing participating in
                  > future
                  > > > rounds. Double-spends only create additional types of DoS attack that
                  > need to
                  > > > be detected and punished as well - they don't create a fundamentally
                  > new
                  > > > vulerability.
                  > >
                  > > I agree some DoS vectors are already mitigated however punishment in
                  > this case will be difficult because the transaction is broadcasted after
                  > signing and before coinjoin tx broadcast.
                  > >
                  > > Inputs are already checked multiple times for double spend during
                  > coinjoin round: https://github.com/zkSNACKs/WalletWasabi/pull/6460
                  > >
                  > > If all the inputs in the coinjoin transaction that failed to relay are
                  > checked and one or more are found to be spent later, what will be punished
                  > and how does this affect the attacker with thousands of UTXOs or normal
                  > users?
                  >
                  > Point is, the attacker is thousands of UTXOs can also DoS rounds by simply
                  > failing to complete the round. In fact, the double-spend DoS attack
                  > requires
                  > more resources, because for a double-spend to be succesful, BTC has to be
                  > spent
                  > on fees.
                  >
                  > It's just a fact of life that a motivated attacker can DoS attack Wasabi by
                  > spending money. That's a design choice that's serving them well so far.
                  >
                  > --
                  > https://petertodd.org 'peter'[:-1]@petertodd.org
                  > _______________________________________________
                  > bitcoin-dev mailing list
                  > bitcoin-dev@lists•linuxfoundation.org
                  > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                  >
                  
                  [-- Attachment #2: Type: text/html, Size: 3269 bytes --]
                  
                  ^ permalink raw reply	[flat|nested] 27+ messages in thread

                • * Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
                    2022-07-08 14:53               ` Peter Todd
                    2022-07-08 15:09                 ` Greg Sanders
                  @ 2022-07-08 19:44                 ` alicexbt
                    2022-07-09 15:06                 ` Antoine Riard
                    2 siblings, 0 replies; 27+ messages in thread
                  From: alicexbt @ 2022-07-08 19:44 UTC (permalink / raw)
                    To: Peter Todd; +Cc: Bitcoin Protocol Discussion
                  
                  Hi Peter,
                  
                  > Point is, the attacker is thousands of UTXOs can also DoS rounds by simply
                  > failing to complete the round. In fact, the double-spend DoS attack requires
                  > more resources, because for a double-spend to be succesful, BTC has to be spent
                  > on fees.
                  >
                  > It's just a fact of life that a motivated attacker can DoS attack Wasabi by
                  > spending money. That's a design choice that's serving them well so far.
                  
                  
                  There are 2 things:
                  
                  1) Based on my understanding, round will not be aborted if a threshold is met for inputs and will continue irrespective of attacker trying different things in the initial phases of round. I need to confirm this by testing although not feeling well today so it can take a few days.
                  
                  2) Points mentioned by Greg Sanders are reasonable: There can be a different 'mempool view' for coordinator, users and attacker. Attacker could use minimum fee rate required for relay and this works differently when there is enough demand for blockspace.
                  
                  Double spend attack requires only one laptop and a few UTXOs. Even if spent in some cases, would pay a few sats per transaction which won't be an issue for governments or competitors that normally perform such attacks.
                  
                  The vulnerability reported is different from the things being discussed and hopefully I will do a public disclosure this month. I observed some interesting things which I wanted to discuss. Full RBF pull request is already merged in bitcoin core and available in bitcoin knots if some users want to experiment.
                  
                  
                  /dev/fd0
                  
                  Sent with Proton Mail secure email.
                  
                  ------- Original Message -------
                  On Friday, July 8th, 2022 at 2:53 PM, Peter Todd <pete@petertodd•org> wrote:
                  
                  
                  > On Tue, Jul 05, 2022 at 08:46:51PM +0000, alicexbt wrote:
                  >
                  > > Hi Peter,
                  > >
                  > > > Note that Wasabi already has a DoS attack vector in that a participant can stop
                  > > > participating after the first phase of the round, with the result that the
                  > > > coinjoin fails. Wasabi mitigates that by punishing participating in future
                  > > > rounds. Double-spends only create additional types of DoS attack that need to
                  > > > be detected and punished as well - they don't create a fundamentally new
                  > > > vulerability.
                  > >
                  > > I agree some DoS vectors are already mitigated however punishment in this case will be difficult because the transaction is broadcasted after signing and before coinjoin tx broadcast.
                  > >
                  > > Inputs are already checked multiple times for double spend during coinjoin round: https://github.com/zkSNACKs/WalletWasabi/pull/6460
                  > >
                  > > If all the inputs in the coinjoin transaction that failed to relay are checked and one or more are found to be spent later, what will be punished and how does this affect the attacker with thousands of UTXOs or normal users?
                  >
                  >
                  > Point is, the attacker is thousands of UTXOs can also DoS rounds by simply
                  > failing to complete the round. In fact, the double-spend DoS attack requires
                  > more resources, because for a double-spend to be succesful, BTC has to be spent
                  > on fees.
                  >
                  > It's just a fact of life that a motivated attacker can DoS attack Wasabi by
                  > spending money. That's a design choice that's serving them well so far.
                  >
                  > --
                  > https://petertodd.org 'peter'[:-1]@petertodd.org
                  
                  
                  ^ permalink raw reply	[flat|nested] 27+ messages in thread

                • * Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
                    2022-07-08 14:53               ` Peter Todd
                    2022-07-08 15:09                 ` Greg Sanders
                    2022-07-08 19:44                 ` alicexbt
                  @ 2022-07-09 15:06                 ` Antoine Riard
                    2 siblings, 0 replies; 27+ messages in thread
                  From: Antoine Riard @ 2022-07-09 15:06 UTC (permalink / raw)
                    To: Peter Todd; +Cc: Bitcoin Protocol Discussion
                  
                  [-- Attachment #1: Type: text/plain, Size: 4680 bytes --]
                  
                  > Point is, the attacker is thousands of UTXOs can also DoS rounds by simply
                  > failing to complete the round. In fact, the double-spend DoS attack
                  requires
                  > more resources, because for a double-spend to be succesful, BTC has to be
                  spent
                  > on fees.
                  
                  I think I agree that effectively a DoS-by-abstention is lower cost than a
                  DoS-by-RBF-otpout, as in the second case the UTXO double-spent must be
                  still acquired. However, I wonder if the second DoS case isn't more
                  economically efficient for the attacker as you can re-use the same UTXO (or
                  the lineage of it) many times as the coinjoin coordinator have a limited
                  visibility (in the very best case) of the network mempools to blame
                  confidently.
                  
                  Acquiring thousands of UTXO, whatever the origin, isn't free. Electricity
                  burns if they have been mined, fiat if they have been acquired through
                  exchange, time and energy if they have been earned as income.
                  
                  > It's just a fact of life that a motivated attacker can DoS attack Wasabi
                  by
                  > spending money. That's a design choice that's serving them well so far.
                  
                  I believe it's hard to make any open, p2p coinjoin services robust against
                  a deep-pocketed attacker practicing that type of DoS attacks. In theory, an
                  attacker could maintain the DoS for long enough to ruin the reputation of
                  the service until it's out of the market. It would be interesting to know
                  if you can design a DoS mitigation (e.g against DoS-by-abstention) offering
                  the advantage to the targeted service after one-round or a fixed number of
                  rounds.
                  
                  > The other users' only practical choice is to double-spend their own input
                  > to get their money back(at competitive rates much higher than the
                  > attacker), or wait and hope you win a propagation race somewhere.
                  
                  Yes, that's of the annoying concern with DoS-by-RBF-optout against
                  DoS-by-abstention, while the latter can be mitigated without assuming a
                  on-chain cost for the participant, the former might be crafted such that
                  on-chain fees must be spent to sanitize the situation, worst in an
                  asymmetric way bounded by the max size of the coinjoin, I think.
                  
                  > Double spend attack requires only one laptop and a few UTXOs. Even if
                  spent in some cases, would pay a few sats per transaction which won't be an
                  issue for governments or competitors that normally perform such attacks.
                  
                  That's an interesting question. Interactive transaction construction
                  protocol being formalized by the BOLT process implied (hopefully) that
                  sooner or later multi-party coinjoin capabilities should be well supported
                  across the ecosystem. From that, we might seen a large-scale p2p market of
                  coinjoin (in the same way we have a HTLC routing market with LN), where a
                  participant can enter into them, without the high cost of installing
                  another wallet. I believe how do we mitigate all those classes of DoS to
                  avoid malicious coinjoin service providers to outlaw competitions that stay
                  open (reminder Minecraft and the Mirai Botnet story).
                  
                  Antoine
                  
                  Le ven. 8 juil. 2022 à 10:53, Peter Todd <pete@petertodd•org> a écrit :
                  
                  > On Tue, Jul 05, 2022 at 08:46:51PM +0000, alicexbt wrote:
                  > > Hi Peter,
                  > >
                  > > > Note that Wasabi already has a DoS attack vector in that a participant
                  > can stop
                  > > > participating after the first phase of the round, with the result that
                  > the
                  > > > coinjoin fails. Wasabi mitigates that by punishing participating in
                  > future
                  > > > rounds. Double-spends only create additional types of DoS attack that
                  > need to
                  > > > be detected and punished as well - they don't create a fundamentally
                  > new
                  > > > vulerability.
                  > >
                  > > I agree some DoS vectors are already mitigated however punishment in
                  > this case will be difficult because the transaction is broadcasted after
                  > signing and before coinjoin tx broadcast.
                  > >
                  > > Inputs are already checked multiple times for double spend during
                  > coinjoin round: https://github.com/zkSNACKs/WalletWasabi/pull/6460
                  > >
                  > > If all the inputs in the coinjoin transaction that failed to relay are
                  > checked and one or more are found to be spent later, what will be punished
                  > and how does this affect the attacker with thousands of UTXOs or normal
                  > users?
                  >
                  > Point is, the attacker is thousands of UTXOs can also DoS rounds by simply
                  > failing to complete the round. In fact, the double-spend DoS attack
                  > requires
                  > more resources, because for a double-spend to be succesful, BTC has to be
                  > spent
                  > on fees.
                  >
                  > It's just a fact of life that a motivated attacker can DoS attack Wasabi by
                  > spending money. That's a design choice that's serving them well so far.
                  >
                  > --
                  > https://petertodd.org 'peter'[:-1]@petertodd.org
                  >
                  
                  [-- Attachment #2: Type: text/html, Size: 5402 bytes --]
                  
                  ^ permalink raw reply	[flat|nested] 27+ messages in thread

• * Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
    2022-06-14  0:25 [bitcoin-dev] Playing with full-rbf peers for fun and L2s security Antoine Riard
                     ` (2 preceding siblings ...)
         [not found] ` <gmDNbfrrvaZL4akV2DFwCuKrls9SScQjqxeRoEorEiYlv24dPt1j583iOtcB2lFrxZc59N3kp7T9KIM4ycl4QOmGBfDOUmO-BVHsttvtvDc=@protonmail.com>
  @ 2022-06-20 23:49 ` Peter Todd
    2022-06-21 23:45   ` Antoine Riard
    3 siblings, 1 reply; 27+ messages in thread
  From: Peter Todd @ 2022-06-20 23:49 UTC (permalink / raw)
    To: Antoine Riard, Bitcoin Protocol Discussion
  
  [-- Attachment #1: Type: text/plain, Size: 1396 bytes --]
  
  On Mon, Jun 13, 2022 at 08:25:11PM -0400, Antoine Riard via bitcoin-dev wrote:
  > For that reason, I believe it would be beneficial to the flourishing of
  > multi-party funded transactions to fix the Dos vector by seeing a subset of
  > the network running full-rbf and enabling propagation of honest multi-party
  > transactions to the interested miners, replacing potential non-signaling
  > double-spend from a malicious counterparty. Moving towards that direction,
  > I've submitted a small patch against Bitcoin Core enabling it to turn on
  > full-rbf as a policy, still under review [3]. The default setting stays
  > **false**, i.e keeping opt-in RBF as a default replacement policy. I've
  > started to run the patch on a public node at 146.190.224.15.
  
  BTW I changed one of my OTS calendars to issue fee-bumping txs without the
  opt-in RBF flag set as an experiment. I also made sure txs would propagate to
  the above node. As of right now, it's up to 32 replacements (once per block),
  without any of them mined; the calendars use the strategy of starting at the
  minimum possible fee, and bumping the fee up every time a new block arrives
  without the tx getting mined. So that's evidence we don't have much full-rbf
  hash power at this moment.
  
  You can see the current status at: https://alice.btc.calendar.opentimestamps.org/
  
  -- 
  https://petertodd.org 'peter'[:-1]@petertodd.org
  
  [-- Attachment #2: signature.asc --]
  [-- Type: application/pgp-signature, Size: 488 bytes --]
  
  ^ permalink raw reply	[flat|nested] 27+ messages in thread

• • * Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
      2022-06-20 23:49 ` Peter Todd
    @ 2022-06-21 23:45   ` Antoine Riard
      2022-06-23 19:13     ` Peter Todd
      0 siblings, 1 reply; 27+ messages in thread
    From: Antoine Riard @ 2022-06-21 23:45 UTC (permalink / raw)
      To: Peter Todd; +Cc: Bitcoin Protocol Discussion
    
    [-- Attachment #1: Type: text/plain, Size: 2826 bytes --]
    
    > BTW I changed one of my OTS calendars to issue fee-bumping txs without the
    > opt-in RBF flag set as an experiment. I also made sure txs would
    propagate to
    > the above node. As of right now, it's up to 32 replacements (once per
    block),
    > without any of them mined; the calendars use the strategy of starting at
    the
    > minimum possible fee, and bumping the fee up every time a new block
    arrives
    > without the tx getting mined. So that's evidence we don't have much
    full-rbf
    > hash power at this moment.
    >
    > You can see the current status at:
    https://alice.btc.calendar.opentimestamps.org/
    
    That's interesting. I'm not sure if we can conclude of the absence of
    full-rbf hash power at this moment, as it could also be a lack of full-rbf
    propagation path towards such potential hash power. I think the day we see
    an opt-out replacement transaction mined, it would constitute a good hint
    of full-rbf hash power (assuming the tx-relay topology stays relatively
    stable across the transaction issuance...)
    
    Anyway, if/when the `fullrbf` patch lands in Bitcoin Core, including
    automatic outbound connections to few `NODE_REPLACE_BY_FEE` peers, I'm
    thinking of reaching out to a few mining node operators to advocate them
    with the new policy setting.
    
    Antoine
    
    Le lun. 20 juin 2022 à 19:49, Peter Todd <pete@petertodd•org> a écrit :
    
    > On Mon, Jun 13, 2022 at 08:25:11PM -0400, Antoine Riard via bitcoin-dev
    > wrote:
    > > For that reason, I believe it would be beneficial to the flourishing of
    > > multi-party funded transactions to fix the Dos vector by seeing a subset
    > of
    > > the network running full-rbf and enabling propagation of honest
    > multi-party
    > > transactions to the interested miners, replacing potential non-signaling
    > > double-spend from a malicious counterparty. Moving towards that
    > direction,
    > > I've submitted a small patch against Bitcoin Core enabling it to turn on
    > > full-rbf as a policy, still under review [3]. The default setting stays
    > > **false**, i.e keeping opt-in RBF as a default replacement policy. I've
    > > started to run the patch on a public node at 146.190.224.15.
    >
    > BTW I changed one of my OTS calendars to issue fee-bumping txs without the
    > opt-in RBF flag set as an experiment. I also made sure txs would propagate
    > to
    > the above node. As of right now, it's up to 32 replacements (once per
    > block),
    > without any of them mined; the calendars use the strategy of starting at
    > the
    > minimum possible fee, and bumping the fee up every time a new block arrives
    > without the tx getting mined. So that's evidence we don't have much
    > full-rbf
    > hash power at this moment.
    >
    > You can see the current status at:
    > https://alice.btc.calendar.opentimestamps.org/
    >
    > --
    > https://petertodd.org 'peter'[:-1]@petertodd.org
    >
    
    [-- Attachment #2: Type: text/html, Size: 3540 bytes --]
    
    ^ permalink raw reply	[flat|nested] 27+ messages in thread

  • • * Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
        2022-06-21 23:45   ` Antoine Riard
      @ 2022-06-23 19:13     ` Peter Todd
        2022-08-24  1:56       ` Antoine Riard
        0 siblings, 1 reply; 27+ messages in thread
      From: Peter Todd @ 2022-06-23 19:13 UTC (permalink / raw)
        To: Antoine Riard; +Cc: Bitcoin Protocol Discussion
      
      [-- Attachment #1: Type: text/plain, Size: 1934 bytes --]
      
      On Tue, Jun 21, 2022 at 07:45:48PM -0400, Antoine Riard wrote:
      > > BTW I changed one of my OTS calendars to issue fee-bumping txs without the
      > > opt-in RBF flag set as an experiment. I also made sure txs would
      > propagate to
      > > the above node. As of right now, it's up to 32 replacements (once per
      > block),
      > > without any of them mined; the calendars use the strategy of starting at
      > the
      > > minimum possible fee, and bumping the fee up every time a new block
      > arrives
      > > without the tx getting mined. So that's evidence we don't have much
      > full-rbf
      > > hash power at this moment.
      > >
      > > You can see the current status at:
      > https://alice.btc.calendar.opentimestamps.org/
      > 
      > That's interesting. I'm not sure if we can conclude of the absence of
      > full-rbf hash power at this moment, as it could also be a lack of full-rbf
      > propagation path towards such potential hash power. I think the day we see
      > an opt-out replacement transaction mined, it would constitute a good hint
      > of full-rbf hash power (assuming the tx-relay topology stays relatively
      > stable across the transaction issuance...)
      
      Fees are relatively low right now, so there could be 1% or so of full-rbf hash
      power and I wouldn't notice with this particular technique as the initial tx
      gets mined within 10-20 blocks; a few years back similar experiments were
      finding a few percentage points of hashing power running full-rbf.
      
      > Anyway, if/when the `fullrbf` patch lands in Bitcoin Core, including
      > automatic outbound connections to few `NODE_REPLACE_BY_FEE` peers, I'm
      > thinking of reaching out to a few mining node operators to advocate them
      > with the new policy setting.
      
      I'd suggest doing that right now, without waiting for the patch to get merged,
      as it improves the politics of getting the patch merged. Miners tend to run
      customized bitcoind's anyway.
      
      -- 
      https://petertodd.org 'peter'[:-1]@petertodd.org
      
      [-- Attachment #2: signature.asc --]
      [-- Type: application/pgp-signature, Size: 488 bytes --]
      
      ^ permalink raw reply	[flat|nested] 27+ messages in thread

    • • * Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
          2022-06-23 19:13     ` Peter Todd
        @ 2022-08-24  1:56       ` Antoine Riard
          0 siblings, 0 replies; 27+ messages in thread
        From: Antoine Riard @ 2022-08-24  1:56 UTC (permalink / raw)
          To: Peter Todd; +Cc: Bitcoin Protocol Discussion
        
        [-- Attachment #1: Type: text/plain, Size: 3022 bytes --]
        
        > I'd suggest doing that right now, without waiting for the patch to get
        merged,
        > as it improves the politics of getting the patch merged. Miners tend to
        run
        > customized bitcoind's anyway.
        
        Philosophically, I think we're better off arguing code patches free from a
        political framework and rather reasoning from scientific or engineering
        principles. If a change is adopted it should be in the name of making the
        whole system better, making the new situation a win-win game.
        
        That said, and more pragmatically, now that the full-rbf patch is merged in
        Core there is the pedagogical work of explaining the fee upsides of turning
        on full-rbf setting to enough miners. AFAIK, we don't have public,
        broadcast-all communication channels between developers and mining
        operators to exchange on software upgrades (e.g Stratum V2). I think I'm
        left with the process of reaching out to miner one by one.
        
        Le jeu. 23 juin 2022 à 20:13, Peter Todd <pete@petertodd•org> a écrit :
        
        > On Tue, Jun 21, 2022 at 07:45:48PM -0400, Antoine Riard wrote:
        > > > BTW I changed one of my OTS calendars to issue fee-bumping txs without
        > the
        > > > opt-in RBF flag set as an experiment. I also made sure txs would
        > > propagate to
        > > > the above node. As of right now, it's up to 32 replacements (once per
        > > block),
        > > > without any of them mined; the calendars use the strategy of starting
        > at
        > > the
        > > > minimum possible fee, and bumping the fee up every time a new block
        > > arrives
        > > > without the tx getting mined. So that's evidence we don't have much
        > > full-rbf
        > > > hash power at this moment.
        > > >
        > > > You can see the current status at:
        > > https://alice.btc.calendar.opentimestamps.org/
        > >
        > > That's interesting. I'm not sure if we can conclude of the absence of
        > > full-rbf hash power at this moment, as it could also be a lack of
        > full-rbf
        > > propagation path towards such potential hash power. I think the day we
        > see
        > > an opt-out replacement transaction mined, it would constitute a good hint
        > > of full-rbf hash power (assuming the tx-relay topology stays relatively
        > > stable across the transaction issuance...)
        >
        > Fees are relatively low right now, so there could be 1% or so of full-rbf
        > hash
        > power and I wouldn't notice with this particular technique as the initial
        > tx
        > gets mined within 10-20 blocks; a few years back similar experiments were
        > finding a few percentage points of hashing power running full-rbf.
        >
        > > Anyway, if/when the `fullrbf` patch lands in Bitcoin Core, including
        > > automatic outbound connections to few `NODE_REPLACE_BY_FEE` peers, I'm
        > > thinking of reaching out to a few mining node operators to advocate them
        > > with the new policy setting.
        >
        > I'd suggest doing that right now, without waiting for the patch to get
        > merged,
        > as it improves the politics of getting the patch merged. Miners tend to run
        > customized bitcoind's anyway.
        >
        > --
        > https://petertodd.org 'peter'[:-1]@petertodd.org
        >
        
        [-- Attachment #2: Type: text/html, Size: 3912 bytes --]
        
        ^ permalink raw reply	[flat|nested] 27+ messages in thread

end of thread, other threads:[~2022-08-24  1:56 UTC | newest]

Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-14  0:25 [bitcoin-dev] Playing with full-rbf peers for fun and L2s security Antoine Riard
2022-06-15  2:27 ` Peter Todd
2022-06-15  2:53   ` Luke Dashjr
2022-06-15  3:18     ` Peter Todd
2022-06-16  0:16 ` alicexbt
2022-06-16  1:02   ` Greg Sanders
2022-06-16  1:45     ` alicexbt
2022-06-16  5:43       ` linuxfoundation.cndm1
2022-06-16 12:47         ` alicexbt
2022-06-16 13:24       ` Greg Sanders
     [not found] ` <gmDNbfrrvaZL4akV2DFwCuKrls9SScQjqxeRoEorEiYlv24dPt1j583iOtcB2lFrxZc59N3kp7T9KIM4ycl4QOmGBfDOUmO-BVHsttvtvDc=@protonmail.com>
2022-06-17  1:34   ` Antoine Riard
2022-06-17  4:54     ` alicexbt
2022-06-19 10:42       ` Peter Todd
2022-06-21 23:43       ` Antoine Riard
2022-06-26 16:40         ` alicexbt
2022-06-27  0:43           ` Peter Todd
2022-06-27 12:03             ` Greg Sanders
2022-06-27 13:46               ` Peter Todd
2022-07-05 20:46             ` alicexbt
2022-07-08 14:53               ` Peter Todd
2022-07-08 15:09                 ` Greg Sanders
2022-07-08 19:44                 ` alicexbt
2022-07-09 15:06                 ` Antoine Riard
2022-06-20 23:49 ` Peter Todd
2022-06-21 23:45   ` Antoine Riard
2022-06-23 19:13     ` Peter Todd
2022-08-24  1:56       ` Antoine Riard

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox