> 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 Le lun. 20 juin 2022 à 19:49, Peter Todd <p...@petertodd.org> a écrit : > 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 >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
