<div dir="ltr">> BTW I changed one of my OTS calendars to issue fee-bumping txs without the<br>> opt-in RBF flag set as an experiment. I also made sure txs would propagate to<br>> the above node. As of right now, it's up to 32 replacements (once per block),<br>> without any of them mined; the calendars use the strategy of starting at the<br>> minimum possible fee, and bumping the fee up every time a new block arrives<br>> without the tx getting mined. So that's evidence we don't have much full-rbf<br>> hash power at this moment.<br>> <br>> You can see the current status at: <a href="https://alice.btc.calendar.opentimestamps.org/">https://alice.btc.calendar.opentimestamps.org/</a><br><br>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...)<br><br>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.<br><br>Antoine<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 20 juin 2022 à 19:49, Peter Todd <<a href="mailto:pete@petertodd.org">pete@petertodd.org</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Jun 13, 2022 at 08:25:11PM -0400, Antoine Riard via bitcoin-dev wrote:<br> > For that reason, I believe it would be beneficial to the flourishing of<br> > multi-party funded transactions to fix the Dos vector by seeing a subset of<br> > the network running full-rbf and enabling propagation of honest multi-party<br> > transactions to the interested miners, replacing potential non-signaling<br> > double-spend from a malicious counterparty. Moving towards that direction,<br> > I've submitted a small patch against Bitcoin Core enabling it to turn on<br> > full-rbf as a policy, still under review [3]. The default setting stays<br> > **false**, i.e keeping opt-in RBF as a default replacement policy. I've<br> > started to run the patch on a public node at 146.190.224.15.<br> <br> BTW I changed one of my OTS calendars to issue fee-bumping txs without the<br> opt-in RBF flag set as an experiment. I also made sure txs would propagate to<br> the above node. As of right now, it's up to 32 replacements (once per block),<br> without any of them mined; the calendars use the strategy of starting at the<br> minimum possible fee, and bumping the fee up every time a new block arrives<br> without the tx getting mined. So that's evidence we don't have much full-rbf<br> hash power at this moment.<br> <br> You can see the current status at: <a href="https://alice.btc.calendar.opentimestamps.org/" rel="noreferrer" target="_blank">https://alice.btc.calendar.opentimestamps.org/</a><br> <br> -- <br> <a href="https://petertodd.org" rel="noreferrer" target="_blank">https://petertodd.org</a> 'peter'[:-1]@<a href="http://petertodd.org" rel="noreferrer" target="_blank">petertodd.org</a><br> </blockquote></div>