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 <
bitcoin-dev@lists.linuxfoundation.org> 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
> <bitcoin-dev@lists.linuxfoundation.org> 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
>