<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Every transaction is replace-by-fee capable already. Opt-in replace by fee as specified in BIP 125 is a fiction that held sway only while the income from fees or fee replacement was so much smaller than subsidy.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 21, 2017, at 3:35 PM, Paul Iverson via bitcoin-dev <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" class="">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I agree with Greg. What is happening is a cause for celebration: it is the manifestation of our long-desired fee market in action. That people are willing to pay upwards of $100 per transaction shows the huge demand to transact on the world's most secure ledger. This is what success looks like, folks!<div class=""><br class=""></div><div class="">Now that BTC is being phased out as a means of payment nearly everywhere (e.g., Steam dropping BTC as a payment option) (to be replaced with the more-suitable LN when ready), I'd propose that we address the stuck transaction issue by making replace-by-fee (RBF) ubiquitous. Why not make every transaction RBF by default, and then encourage via outreach and education other wallet developers to do the same? </div><div class=""><br class=""></div><div class="">The frustration with BTC today is less so the high-fees (people realize on-chain transactions in a secure decentralized ledger are necessarily costly) but by the feeling of helplessness when their transaction is stuck. Being able to easily bump a transaction's fee for users who are in a hurry would go a long way to improving the user experience. </div><div class=""><div class=""><br class=""></div><div class="">Paul.</div><div class=""><br class=""></div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Dec 21, 2017 at 2:44 PM, Gregory Maxwell via bitcoin-dev <span dir="ltr" class=""><<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank" class="">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Personally, I'm pulling out the champaign that market behaviour is<br class="">
indeed producing activity levels that can pay for security without<br class="">
inflation, and also producing fee paying backlogs needed to stabilize<br class="">
consensus progress as the subsidy declines.<br class="">
<br class="">
I'd also personally prefer to pay lower fees-- current levels even<br class="">
challenge my old comparison with wire transfer costs-- but we should<br class="">
look most strongly at difficult to forge market signals rather than<br class="">
just claims-- segwit usage gives us a pretty good indicator since most<br class="">
users would get a 50-70% fee reduction without even considering the<br class="">
second order effects from increased capacity.<br class="">
<br class="">
As Jameson Lopp notes, more can be done for education though-- perhaps<br class="">
that market signal isn't efficient yet. But we should get it there.<br class="">
<br class="">
But even independently of segwit we can also look at other inefficient<br class="">
transaction styles: uncompressed keys, unconfirmed chaining instead of<br class="">
send many batching, fee overpayment, etc... and the message there is<br class="">
similar.<br class="">
<br class="">
I've also seen some evidence that a portion of the current high rate<br class="">
congestion is contrived traffic. To the extent that it's true there<br class="">
also should be some relief there soon as the funding for that runs<br class="">
out, in addition to expected traffic patterns, difficulty changes,<br class="">
etc.<br class="">
<div class="HOEnZb"><div class="h5"><br class="">
<br class="">
On Thu, Dec 21, 2017 at 9:30 PM, Melvin Carvalho via bitcoin-dev<br class="">
<<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" class="">bitcoin-dev@lists.<wbr class="">linuxfoundation.org</a>> wrote:<br class="">
> I asked adam back at hcpp how the block chain would be secured in the long<br class="">
> term, once the reward goes away. The base idea has always been that fees<br class="">
> would replace the block reward.<br class="">
><br class="">
> At that time fees were approximately 10% of the block reward, but have now<br class="">
> reached 45%, with 50% potentially being crossed soon<br class="">
><br class="">
> <a href="https://fork.lol/reward/feepct" rel="noreferrer" target="_blank" class="">https://fork.lol/reward/feepct</a><br class="">
><br class="">
> While this bodes well for the long term security of the coin, I think there<br class="">
> is some legitimate concern that the fee per tx is prohibitive for some use<br class="">
> cases, at this point in the adoption curve.<br class="">
><br class="">
> Observations of segwit adoption show around 10% at this point<br class="">
><br class="">
> <a href="http://segwit.party/charts/" rel="noreferrer" target="_blank" class="">http://segwit.party/charts/</a><br class="">
><br class="">
> Watching the mempool shows that the congestion is at a peak, though it's<br class="">
> quite possible this will come down over the long weekend. I wonder if this<br class="">
> is of concern to some.<br class="">
><br class="">
> <a href="https://dedi.jochen-hoenicke.de/queue/more/#24h" rel="noreferrer" target="_blank" class="">https://dedi.jochen-hoenicke.<wbr class="">de/queue/more/#24h</a><br class="">
><br class="">
> I thought these data points may be of interest and are mainly FYI. Though<br class="">
> if further discussion is deemed appropriate, it would be interesting to hear<br class="">
> thoughts.<br class="">
><br class="">
</div></div><div class="HOEnZb"><div class="h5">> ______________________________<wbr class="">_________________<br class="">
> bitcoin-dev mailing list<br class="">
> <a href="mailto:bitcoin-dev@lists.linuxfoundation.org" class="">bitcoin-dev@lists.<wbr class="">linuxfoundation.org</a><br class="">
> <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank" class="">https://lists.linuxfoundation.<wbr class="">org/mailman/listinfo/bitcoin-<wbr class="">dev</a><br class="">
><br class="">
______________________________<wbr class="">_________________<br class="">
bitcoin-dev mailing list<br class="">
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" class="">bitcoin-dev@lists.<wbr class="">linuxfoundation.org</a><br class="">
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank" class="">https://lists.linuxfoundation.<wbr class="">org/mailman/listinfo/bitcoin-<wbr class="">dev</a><br class="">
</div></div></blockquote></div><br class=""></div>
_______________________________________________<br class="">bitcoin-dev mailing list<br class=""><a href="mailto:bitcoin-dev@lists.linuxfoundation.org" class="">bitcoin-dev@lists.linuxfoundation.org</a><br class="">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<br class=""></div></blockquote></div><br class=""></body></html>