> 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