Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security

[Peter Todd <pete@petertodd.org>]

[-- 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 --]