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