<div dir="ltr">&gt; BTW I changed one of my OTS calendars to issue fee-bumping txs without the<br>&gt; opt-in RBF flag set as an experiment. I also made sure txs would propagate to<br>&gt; the above node. As of right now, it&#39;s up to 32 replacements (once per block),<br>&gt; without any of them mined; the calendars use the strategy of starting at the<br>&gt; minimum possible fee, and bumping the fee up every time a new block arrives<br>&gt; without the tx getting mined. So that&#39;s evidence we don&#39;t have much full-rbf<br>&gt; hash power at this moment.<br>&gt; <br>&gt; 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&#39;s interesting. I&#39;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&#39;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 &lt;<a href="mailto:pete@petertodd.org">pete@petertodd.org</a>&gt; 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>
&gt; For that reason, I believe it would be beneficial to the flourishing of<br>
&gt; multi-party funded transactions to fix the Dos vector by seeing a subset of<br>
&gt; the network running full-rbf and enabling propagation of honest multi-party<br>
&gt; transactions to the interested miners, replacing potential non-signaling<br>
&gt; double-spend from a malicious counterparty. Moving towards that direction,<br>
&gt; I&#39;ve submitted a small patch against Bitcoin Core enabling it to turn on<br>
&gt; full-rbf as a policy, still under review [3]. The default setting stays<br>
&gt; **false**, i.e keeping opt-in RBF as a default replacement policy. I&#39;ve<br>
&gt; 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&#39;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&#39;s evidence we don&#39;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> &#39;peter&#39;[:-1]@<a href="http://petertodd.org" rel="noreferrer" target="_blank">petertodd.org</a><br>
</blockquote></div>