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. > On Dec 21, 2017, at 3:35 PM, Paul Iverson via bitcoin-dev wrote: > > 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! > > 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? > > 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. > > Paul. > > > On Thu, Dec 21, 2017 at 2:44 PM, Gregory Maxwell via bitcoin-dev > wrote: > Personally, I'm pulling out the champaign that market behaviour is > indeed producing activity levels that can pay for security without > inflation, and also producing fee paying backlogs needed to stabilize > consensus progress as the subsidy declines. > > I'd also personally prefer to pay lower fees-- current levels even > challenge my old comparison with wire transfer costs-- but we should > look most strongly at difficult to forge market signals rather than > just claims-- segwit usage gives us a pretty good indicator since most > users would get a 50-70% fee reduction without even considering the > second order effects from increased capacity. > > As Jameson Lopp notes, more can be done for education though-- perhaps > that market signal isn't efficient yet. But we should get it there. > > But even independently of segwit we can also look at other inefficient > transaction styles: uncompressed keys, unconfirmed chaining instead of > send many batching, fee overpayment, etc... and the message there is > similar. > > I've also seen some evidence that a portion of the current high rate > congestion is contrived traffic. To the extent that it's true there > also should be some relief there soon as the funding for that runs > out, in addition to expected traffic patterns, difficulty changes, > etc. > > > On Thu, Dec 21, 2017 at 9:30 PM, Melvin Carvalho via bitcoin-dev > > wrote: > > I asked adam back at hcpp how the block chain would be secured in the long > > term, once the reward goes away. The base idea has always been that fees > > would replace the block reward. > > > > At that time fees were approximately 10% of the block reward, but have now > > reached 45%, with 50% potentially being crossed soon > > > > https://fork.lol/reward/feepct > > > > While this bodes well for the long term security of the coin, I think there > > is some legitimate concern that the fee per tx is prohibitive for some use > > cases, at this point in the adoption curve. > > > > Observations of segwit adoption show around 10% at this point > > > > http://segwit.party/charts/ > > > > Watching the mempool shows that the congestion is at a peak, though it's > > quite possible this will come down over the long weekend. I wonder if this > > is of concern to some. > > > > https://dedi.jochen-hoenicke.de/queue/more/#24h > > > > I thought these data points may be of interest and are mainly FYI. Though > > if further discussion is deemed appropriate, it would be interesting to hear > > thoughts. > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev