Peter Todd [ARCHIVE] on Nostr: đź“… Original date posted:2022-08-04 đź“ť Original message:On Thu, Aug 04, 2022 at ...
đź“… Original date posted:2022-08-04
đź“ť Original message:On Thu, Aug 04, 2022 at 02:54:54PM +0000, Michael Folkson via bitcoin-dev wrote:
> A short history of RBF and BIP125
>
> The history of BIP125 is as far as I’m aware this. RBF rules were merged into Bitcoin Core in November 2015 [0]. Following that merge David Harding and Peter Todd drafted a BIP (BIP125 [1]) outlining the RBF rules that had been implemented in Bitcoin Core. The rationales for the rules in the BIP was a bit lacking (in my opinion) but recall this is 2015 (7 years ago!) when L2 protocols were in their infancy. Certainly the research on the security of L2 protocols has come a long way since and we have a much better idea of some of the possible attacks on L2 protocols that to some extent are impacted by policy rules.
>
> In addition it was discovered [2] in May 2021 that the Bitcoin Core implementation of the RBF rules had never matched the RBF rules outlined in BIP125. Clearly this isn’t ideal but mistakes happen and will continue to happen. I certainly do not intend any criticism whatsoever to any of the individuals involved. Thankfully this discrepancy doesn’t seem to have resulted in any loss of funds or disruption. However, cross checking a specification with an implementation presumably led to the discovery and allowed for a post mortem on why the implementation didn’t match the specification.
>
> There seems to be two views on what to do next given that the RBF rules need to be updated. One is to ditch the idea of a specification for RBF rules and just document them in the Core repo instead. The other is to have a new specification for the RBF rules in Core and attempt to correct the mistakes made with BIP125 by having a BIP that does correctly outline the RBF rules implemented in Core and includes detailed rationales for why those RBF rules have been implemented.
>
> Should anyone care about where things are documented?
They really shouldn't.
The nature of L2 punishment protocols is that transaction relay schemes are
additive security: every different way that a punishment tx could get broadcast
and mined is a different way that the punishment scheme could succeed. We
should be thinking about how to add diversity and robustness to this in the
form of different schemes, rather than trying to specify exactly how we expect
these txs to be broadcast. In particular, you have to accept that different
schemes will exist, and an adversary could use those schems.
For the near-term, an important part of this is to get package relay and
package replacements implemented, to avoid edge-cases in multiple-tx schemes.
It'd also be good to specify something entirely different, like a hashcase
based broadcast scheme.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220804/20f1b1fa/attachment.sig>;
đź“ť Original message:On Thu, Aug 04, 2022 at 02:54:54PM +0000, Michael Folkson via bitcoin-dev wrote:
> A short history of RBF and BIP125
>
> The history of BIP125 is as far as I’m aware this. RBF rules were merged into Bitcoin Core in November 2015 [0]. Following that merge David Harding and Peter Todd drafted a BIP (BIP125 [1]) outlining the RBF rules that had been implemented in Bitcoin Core. The rationales for the rules in the BIP was a bit lacking (in my opinion) but recall this is 2015 (7 years ago!) when L2 protocols were in their infancy. Certainly the research on the security of L2 protocols has come a long way since and we have a much better idea of some of the possible attacks on L2 protocols that to some extent are impacted by policy rules.
>
> In addition it was discovered [2] in May 2021 that the Bitcoin Core implementation of the RBF rules had never matched the RBF rules outlined in BIP125. Clearly this isn’t ideal but mistakes happen and will continue to happen. I certainly do not intend any criticism whatsoever to any of the individuals involved. Thankfully this discrepancy doesn’t seem to have resulted in any loss of funds or disruption. However, cross checking a specification with an implementation presumably led to the discovery and allowed for a post mortem on why the implementation didn’t match the specification.
>
> There seems to be two views on what to do next given that the RBF rules need to be updated. One is to ditch the idea of a specification for RBF rules and just document them in the Core repo instead. The other is to have a new specification for the RBF rules in Core and attempt to correct the mistakes made with BIP125 by having a BIP that does correctly outline the RBF rules implemented in Core and includes detailed rationales for why those RBF rules have been implemented.
>
> Should anyone care about where things are documented?
They really shouldn't.
The nature of L2 punishment protocols is that transaction relay schemes are
additive security: every different way that a punishment tx could get broadcast
and mined is a different way that the punishment scheme could succeed. We
should be thinking about how to add diversity and robustness to this in the
form of different schemes, rather than trying to specify exactly how we expect
these txs to be broadcast. In particular, you have to accept that different
schemes will exist, and an adversary could use those schems.
For the near-term, an important part of this is to get package relay and
package replacements implemented, to avoid edge-cases in multiple-tx schemes.
It'd also be good to specify something entirely different, like a hashcase
based broadcast scheme.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220804/20f1b1fa/attachment.sig>;