Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 944D23C8 for ; Fri, 31 Jul 2015 14:29:23 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from heron.directrouter.co.uk (heron.directrouter.co.uk [89.145.69.228]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2FD1E11E for ; Fri, 31 Jul 2015 14:29:22 +0000 (UTC) Received: from 50-76-32-109-ip-static.hfc.comcastbusiness.net ([50.76.32.109]:49591 helo=[10.0.7.215]) by heron.directrouter.co.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from ) id 1ZLBJH-0005KE-Gz; Fri, 31 Jul 2015 14:29:19 +0000 Content-Type: multipart/alternative; boundary=Apple-Mail-EF77BA8D-028E-4364-BDD2-6EBB3BBF83D7 Mime-Version: 1.0 (1.0) From: Dave X-Mailer: iPhone Mail (12H143) In-Reply-To: Date: Fri, 31 Jul 2015 07:29:14 -0700 Content-Transfer-Encoding: 7bit Message-Id: <8FAC5D92-4541-4E3A-8911-90CECA96D174@hashingit.com> References: To: Un Ix X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - heron.directrouter.co.uk X-AntiAbuse: Original Domain - lists.linuxfoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hashingit.com X-Get-Message-Sender-Via: heron.directrouter.co.uk: authenticated_id: dave@hashingit.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, MIME_QP_LONG_LINE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] =?utf-8?q?R=C4=83spuns=3A_Personal_opinion_on_the_f?= =?utf-8?q?ee_market_from_a_worried_local_trader=E2=80=8F?= X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 14:29:23 -0000 --Apple-Mail-EF77BA8D-028E-4364-BDD2-6EBB3BBF83D7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 31 Jul 2015, at 06:59, Un Ix via bitcoin-dev wrote: >=20 > +1 on the comments below by Thomas.=20 >=20 > "Fee market" is not a binary option, either on or off. Like all markets i= t exists in varying degrees over time and with more or less influence on the= process of which it is part of. As it stands now, and likely for another d= ecade at least, the fee per tx constitutes a very, very weak market signal f= or the miners since it makes up less than 0.5% of the rewards paid for minin= g a full block. This is the normal and expected scenario, aimed at driving u= se of Bitcoin as widely and cheaply as possible so that network effects will= cement Bitcoin for the future, for all users. >=20 > As a comparison, how many people would have taken up using email if there h= ad been a per-message fee and hourly sending limits with only the highest-fe= e messages being delivered? And how would it look if the email protocol deve= lopers imposing fees & hourly sending limits were pushing hard for use of an= other email-delivery protocol on top of the existing one? >=20 How would email have looked if it required 300 MW of power to support it for= "free" for 10 years? In practice email was never free- it was paid for by the payments users made= to ISPs. ISPs paid for email and network infrastructure from that. The equivalent analogy here would be to drop fees completely and pay a speci= fic miner to mine all of your transactions as a monthly subscription (which o= f course doesn't work in a non-permission-based network). Miners have real (huge) costs - they will be in a lot of pain with reward ha= lving if a few model does not replace that. That in turn poses a huge risk o= f smaller miners shutting down, which in turn centralises things even more. I= would argue that the lack of pool diversity and thus lack of block makers i= s already the single biggest risk for a decentralised system; avoiding the i= ssue of fees just accelerates this.= --Apple-Mail-EF77BA8D-028E-4364-BDD2-6EBB3BBF83D7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 31 Jul 2015, at 06:5= 9, Un Ix via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

=
+1 on the comments below by Thomas.

"Fee market" is= not a=20 binary option, either on or off.  Like all markets it exists in varying= =20 degrees over time and with more or less influence on the process of which it= is=20 part of.  As it stands now, and likely for another decade at least, the= =20 fee per tx constitutes a very, very weak market signal for the miners since i= t=20 makes up less than 0.5% of the rewards paid for mining a full block. This is= the normal and expected scenario, aimed at driving use of Bitcoin=20 as widely and cheaply as possible so that network effects will cement=20 Bitcoin for the future, for all users.

As a comparison, how many peop= le would have taken up using email if there had been a per-message fee and hourly=20 sending limits with only the highest-fee messages being delivered? And=20 how would it look if the email protocol developers imposing fees=20 & hourly sending limits were pushing hard for use of another email-deliv= ery protocol on top of the existing one?

<= /blockquote>
H= ow would email have looked if it required 300 MW of power to support it for "= free" for 10 years?

In practice email was never free- it was paid for by t= he payments users made to ISPs. ISPs paid for email and network infrastructu= re from that.

The equivalent analogy here would be to drop fees completel= y and pay a specific miner to mine all of your transactions as a monthly sub= scription (which of course doesn't work in a non-permission-based network).<= /span>
<= br>
Miners have real (huge) costs - they will be in a lot of pain with reward= halving if a few model does not replace that. That in turn poses a huge ris= k of smaller miners shutting down, which in turn centralises things even mor= e. I would argue that the lack of pool diversity and thus lack of block make= rs is already the single biggest risk for a decentralised system; avoiding t= he issue of fees just accelerates this.
= --Apple-Mail-EF77BA8D-028E-4364-BDD2-6EBB3BBF83D7--