Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2022-06-16 📝 Original message:Hi alicexbt, Thanks for ...
📅 Original date posted:2022-06-16
📝 Original message: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 at 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 at 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220617/6775746f/attachment-0001.html>;
📝 Original message: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 at 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 at 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220617/6775746f/attachment-0001.html>;