<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 8, 2018 at 1:34 PM, Peter Todd <span dir="ltr">&lt;<a href="mailto:pete@petertodd.org" target="_blank">pete@petertodd.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Mar 08, 2018 at 10:39:46AM -0500, Russell O&#39;Connor wrote:<br>
&gt; On Thu, Mar 1, 2018 at 10:11 AM, Peter Todd &lt;<a href="mailto:pete@petertodd.org">pete@petertodd.org</a>&gt; wrote:<br>
</span><span class="">&gt; &gt; I mean, I think in general solving this problem is probably not possible.<br>
&gt; &gt; Basically, the fundamental problem is someone else has consumed network<br>
&gt; &gt; bandwidth that should be paid for with fees. What you&#39;re trying to do is<br>
&gt; &gt; replace a transaction without paying those fees, which is identical to<br>
&gt; &gt; what an<br>
&gt; &gt; attacker is trying to do, and thus any such scheme will be as vulnerable to<br>
&gt; &gt; attack as not having that protection in the first place.<br>
&gt; &gt;<br>
&gt; &gt; ...which does give you an out: maybe the attack isn&#39;t important enough to<br>
&gt; &gt; matter. :)<br>
&gt; &gt;<br>
&gt;<br>
&gt; Thanks, that makes sense.<br>
&gt;<br>
&gt; I still think it is worthwhile pursuing this proposed change in RBF policy<br>
&gt; as it would seem that the current policy is problematic in practice today<br>
&gt; where participants are just performing normal transactions and are not<br>
&gt; trying to attack each other.<br>
<br>
</span>But that&#39;s not a good argument: whether or not normal users are trying to<br>
attack each other has nothing to do with whether or not you&#39;re opening up an<br>
attack by relaxing anti-DoS protections.<br></blockquote><div><br></div><div>I&#39;m not suggesting removing the anti-DoS protections.  I&#39;m suggesting that replaced transaction require a fee increase of at least the min-fee-rate times the size of all the transactions being ejected (in addition to the other proposed requirements).<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Equally, how often are normal users who aren&#39;t attacking each other creating<br>
issues anyway? You can always have your wallet code just skip use of RBF<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
replacements in the event that someone does spend an unconfirmed output that<br>
you sent them; how often does this actually happen in practice?</blockquote><div><br><div>Just ask rhavar.  It happens regularly.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"></blockquote></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Not many wallets let you spend unconfirmed outputs that you didn&#39;t create.<br></blockquote><div><br></div><div>The problem is with institutional wallets sweeping incoming payments.  It seems that in practice they are happy to sweep unconfirmed outputs.<br><br></div><div>Setting all of the above aside for a moment.  We need to understand that rational miners are going to prefer to transactions with higher package fee rates regardless of whatever your personal preferred RBF policy is.  If we do not bring the RBF policy to alignment with what is economically rational, then miners are going to change their own policies anyways, probably all in slightly different ways.  It behooves everyone to develop a reasonable standard RBF policy, that is still robust against possible DoS vectors, and aligns with miner incentives, so that all participants know what behaviour they can reasonably expect.  It is simply a bonus that this change in RBF policy also partially mitigates the problem of pinned transactions.<br></div></div></div></div>