Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 05C16D02 for ; Fri, 22 Dec 2017 00:31:03 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pf0-f171.google.com (mail-pf0-f171.google.com [209.85.192.171]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3C058439 for ; Fri, 22 Dec 2017 00:31:01 +0000 (UTC) Received: by mail-pf0-f171.google.com with SMTP id c204so14632347pfc.13 for ; Thu, 21 Dec 2017 16:31:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=friedenbach-org.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=5uwO0ICPri5hHMuVarFOBtZu/SgLZDAUAlIej5JN6bA=; b=wyAinqZ8THRMmqVZkXF1nLu3pbqcUeZw2ntEU5joVFH6cILhR4yxA1cLvco63XLYLw cnOy2BruqUPB4y8vfl9RxqxGy0o0hqWtnRTtv38zkCAgdlSKrtrDkcushg/j1nVIVarc E50HeuEFEEhxBT8PRin8MOidti0bb6BkjIF+JZy+plkYjZ5v7V1X9o04JJo8BzPGlUSD lJqV+iLfEgNgp5jprQqmsP2pxjrq1Zy4nwRzv3h+EKht7d9Xb5UlEeikaLIrTkHoFPem 8frcI8lnJR34QwmzBNwBeH8kn//UoQVeqIqAGNnhx8vIpvixyGkkiFQkRMfaelpTidO+ lfuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=5uwO0ICPri5hHMuVarFOBtZu/SgLZDAUAlIej5JN6bA=; b=FXOwsigi45JE05mpzFe5us3nHJbqenFSkXkOBSk34GLrM0X3F24fi3fWOj4c9we0Yd c/eVGY7CGB5EoR5l1ACJFL29JLQQ/VUT1jGKL05ZIgiAYvVx8ZyJdOzkmbRB6ogpK9VB EHoRV7MIzWM+qM4+pmJkQihejvwJ6AFJAUGhpqboKlnmzfzDEpAED2zD02BV5CKUPTjA r0iz4br4C6bP1bSlgaJduTGIfkC1T5nGGnx1AWFPiGytVUiLy2p5vXLlgF9wP08RtB+Q padSszuVEERVmDK7dwxrkxWPCMkGtR5Q72j+vLVz1m78l2QVA8ELlGLmz5CiJnOPS+yy 0gnA== X-Gm-Message-State: AKGB3mLCrliIDw42dyl+pzuWHpoEGS/0GnlUX7XGGVCOCTEFvwTZ0yKr VvIpBBzKYNFOENtaXKypDo0PKQ== X-Google-Smtp-Source: ACJfBout+eqeiEP8ptWSClqdFrUGk/vDElsH9iX7YCPIUFFqiUyH5uW71uqELvVKWCAxlhukwpqgtQ== X-Received: by 10.101.85.197 with SMTP id k5mr4798001pgs.17.1513902660310; Thu, 21 Dec 2017 16:31:00 -0800 (PST) Received: from [10.0.0.3] (c-73-170-162-66.hsd1.ca.comcast.net. [73.170.162.66]) by smtp.gmail.com with ESMTPSA id g7sm1211319pgo.83.2017.12.21.16.30.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Dec 2017 16:30:59 -0800 (PST) From: Mark Friedenbach Content-Type: multipart/alternative; boundary="Apple-Mail=_ABBCBD24-257C-48A4-A387-3C7819B2C073" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 21 Dec 2017 16:30:52 -0800 References: To: Paul Iverson , Bitcoin Protocol Discussion In-Reply-To: Message-Id: <9EB76B68-E8AC-4BE8-8279-BA18033CBF9F@friedenbach.org> X-Mailer: Apple Mail (2.3445.5.20) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,URIBL_RED autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Total fees have almost crossed the block reward X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 00:31:03 -0000 --Apple-Mail=_ABBCBD24-257C-48A4-A387-3C7819B2C073 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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: >=20 > 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! >=20 > 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? =20 >=20 > 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. =20 >=20 > Paul. >=20 >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 >=20 > 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 = >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail=_ABBCBD24-257C-48A4-A387-3C7819B2C073 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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 = <bitcoin-dev@lists.linuxfoundation.org> 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 <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

_______________________________________________
bitcoin-dev = mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= br class=3D"">

= --Apple-Mail=_ABBCBD24-257C-48A4-A387-3C7819B2C073--