> 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.

Philosophically, I think we're better off arguing code patches free from a political framework and rather reasoning from scientific or engineering principles. If a change is adopted it should be in the name of making the whole system better, making the new situation a win-win game.

That said, and more pragmatically, now that the full-rbf patch is merged in Core there is the pedagogical work of explaining the fee upsides of turning on full-rbf setting to enough miners. AFAIK, we don't have public, broadcast-all communication channels between developers and mining operators to exchange on software upgrades (e.g Stratum V2). I think I'm left with the process of reaching out to miner one by one. 

Le jeu. 23 juin 2022 à 20:13, Peter Todd <pete@petertodd.org> a écrit :
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