<div dir="ltr"><div><div>In a fee-dominated future, replace-by-fee is not an opt-in feature. When you create a transaction, the wallet presents a range of fees that it expects you might pay. It then signs copies of the transaction with spaced fees from this interval and broadcasts the lowest fee first. In the user interface, the transaction is shown with its transacted amount and the approved fee range. All of the inputs used are placed on hold until the transaction gets a confirmation. As time goes by and it looks like the transaction is not getting accepted, successively higher fee versions are released. You can opt-out and send a no-fee or base-fee-only transaction, but that should not be the default.<br><br></div>On the receiving end, local policy controls how much fee should be spent trying to obtain confirmations before alerting the user, if there are fees available in the hot wallet to do this. The receiving wallet then adds its own fees via a spend if it thinks insufficient fees were provided to get a confirmation. Again, this should all be automated so long as there is a hot wallet on the receiving end.<br><br></div><div>Is this more complicated than now, where blocks are not full and clients generally don't have to worry about their transactions eventually confirming? Yes, it is significantly more complicated. But such complication is unavoidable. It is a simple fact that the block size cannot increase so much as to cover every single use by every single person in the world, so there is no getting around the reality that we will have to transition into an economy where at least one side has to pay up for a transaction to get confirmation, at all. We are going to have to deal with this issue whether it is now at 1MB or later at 20MB. And frankly, it'll be much easier to do now.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 8, 2015 at 4:15 PM, Aaron Voisine <span dir="ltr"><<a href="mailto:voisine@gmail.com" target="_blank">voisine@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">That's fair, and we've implemented child-pays-for-parent for spending unconfirmed inputs in breadwallet. But what should the behavior be when those options aren't understood/implemented/used?<div><br></div><div>My argument is that the less risky, more conservative default fallback behavior should be either non-propagation or delayed confirmation, which is generally what we have now, until we hit the block size limit. We still have lots of safe, non-controversial, easy to experiment with options to add fee pressure, causing users to economize on block space without resorting to dropping transactions after a prolonged delay.</div><div class="gmail_extra"><span class=""><br><div><div><div dir="ltr"><div><div dir="ltr"><div>Aaron Voisine</div><div>co-founder and CEO<br><a href="http://breadwallet.com" target="_blank">breadwallet.com</a></div></div></div></div></div></div>
<br></span><div><div class="h5"><div class="gmail_quote">On Fri, May 8, 2015 at 3:45 PM, Mark Friedenbach <span dir="ltr"><<a href="mailto:mark@friedenbach.org" target="_blank">mark@friedenbach.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span>On Fri, May 8, 2015 at 3:43 PM, Aaron Voisine <span dir="ltr"><<a href="mailto:voisine@gmail.com" target="_blank">voisine@gmail.com</a>></span> wrote:<br></span><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">This is a clever way to tie block size to fees.<div><br></div><div>I would just like to point out though that it still fundamentally is using hard block size limits to enforce scarcity. Transactions with below market fees will hang in limbo for days and fail, instead of failing immediately by not propagating, or seeing degraded, long confirmation times followed by eventual success.</div></div></blockquote><div><br></div></span><div>There are already solutions to this which are waiting to be deployed as default policy to bitcoind, and need to be implemented in other clients: replace-by-fee and child-pays-for-parent. <br></div></div></div></div>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>