From: Paul Iverson <piverson1024@gmail.com>
To: Gregory Maxwell <greg@xiph.org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Total fees have almost crossed the block reward
Date: Thu, 21 Dec 2017 15:35:28 -0800 [thread overview]
Message-ID: <CAAeo5+gYrr=KaqrLibmAoUWG4F_EdR5SQTE9U6-jsYYVT23kTQ@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgQSNdzuiPS3AZ_TjQ2OvkhYJ3ZJUBo7ovP6_O2snuwEMg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4135 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 5673 bytes --]
next prev parent reply other threads:[~2017-12-21 23:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-21 21:30 [bitcoin-dev] Total fees have almost crossed the block reward Melvin Carvalho
2017-12-21 22:02 ` Jameson Lopp
2017-12-21 22:18 ` Jim Rogers
2017-12-21 23:15 ` Michel 'ic' Luczak
2017-12-21 22:44 ` Gregory Maxwell
2017-12-21 23:35 ` Paul Iverson [this message]
2017-12-22 0:30 ` Mark Friedenbach
2017-12-22 1:15 ` Gregory Maxwell
2018-02-12 17:23 ` Melvin Carvalho
2018-02-12 17:47 ` rhavar
2018-02-12 18:12 ` Peter Todd
2018-02-12 19:41 ` Christian Decker
2018-02-13 19:03 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAeo5+gYrr=KaqrLibmAoUWG4F_EdR5SQTE9U6-jsYYVT23kTQ@mail.gmail.com' \
--to=piverson1024@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=greg@xiph.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox