From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YqRsX-0007NM-93 for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 19:54:41 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of bitpay.com designates 209.85.218.48 as permitted sender) client-ip=209.85.218.48; envelope-from=jgarzik@bitpay.com; helo=mail-oi0-f48.google.com; Received: from mail-oi0-f48.google.com ([209.85.218.48]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YqRsW-0006EC-0N for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 19:54:41 +0000 Received: by oign205 with SMTP id n205so42365796oig.2 for ; Thu, 07 May 2015 12:54:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=rfZ6jmNeLp0BwK9wizRD+mNEV8WWA2qxFGW21B+VYH4=; b=MuGtbcbUiEOYDqSgcrnMeYy65jsTQJSPgZsPnb6xTsu8H7faApE3NTTcPx1GgSsVsR 1f0vj09Bf7pjlorY5GEzhUpdGI+VKcdvtlnxRGT1gYw+ulj/FhllrfE4gPxzDc86gco+ hpcgC0uMWTTBokC6+oQ7lLSon6ijs59+0e+IlTPxw8kn9ld5TP560kWeqVQkeIWbymCi VbT/onCbe0jOFp8U+BKLBncLxzuK7nNdwAranqwEXqKapZJDWjuA8ZzuC4QrwUOjWnlW ruRn3jlMC4kFFB4LTaNkc4D1plflRR98xLQDLdrCgtI49geOMhdY/tpIBtb5y3YCGVds Rtuw== X-Gm-Message-State: ALoCoQk+hCz8SI2OyOe74r0XvA3DUOnJNPufKkYC2wHfvo4GtN9/SmKhv8N29XpppkqQxTtIFmqt X-Received: by 10.182.87.36 with SMTP id u4mr259224obz.50.1431028474566; Thu, 07 May 2015 12:54:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.108.149 with HTTP; Thu, 7 May 2015 12:54:13 -0700 (PDT) In-Reply-To: <554BBDA2.7040508@gmail.com> References: <554A91BE.6060105@bluematt.me> <554BA032.4040405@bluematt.me> <554BBDA2.7040508@gmail.com> From: Jeff Garzik Date: Thu, 7 May 2015 15:54:13 -0400 Message-ID: To: Alan Reiner Content-Type: multipart/alternative; boundary=089e013d0ddce3ec7905158347ca X-Spam-Score: -0.7 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.1 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1YqRsW-0006EC-0N Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Block Size Increase X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 19:54:41 -0000 --089e013d0ddce3ec7905158347ca Content-Type: text/plain; charset=UTF-8 On Thu, May 7, 2015 at 3:31 PM, Alan Reiner wrote: > (1) Blocks are essentially nearing "full" now. And by "full" he means > that the reliability of the network (from the average user perspective) is > about to be impacted in a very negative way > Er, to be economically precise, "full" just means fees are no longer zero. Bitcoin behaves as it always has. It is no longer basically free to dump spam into the blockchain, as it is today. In the short term, blocks are bursty, with some on 1 minute intervals, some with 60 minute intervals. This does not change with larger blocks. > (2) Leveraging fee pressure at 1MB to solve the problem is actually really > a bad idea. It's really bad while Bitcoin is still growing, and relying on > fee pressure at 1 MB severely impacts attractiveness and adoption potential > of Bitcoin (due to high fees and unreliability). But more importantly, it > ignores the fact that for a 7 tps is pathetic for a global transaction > system. It is a couple orders of magnitude too low for any meaningful > commercial activity to occur. If we continue with a cap of 7 tps forever, > Bitcoin *will* fail. Or at best, it will fail to be useful for the vast > majority of the world (which probably leads to failure). We shouldn't be > talking about fee pressure until we hit 700 tps, which is probably still > too low. > [...] 1) Agree that 7 tps is too low 2) Where do you want to go? Should bitcoin scale up to handle all the world's coffees? This is hugely unrealistic. 700 tps is 100MB blocks, 14.4 GB/day -- just for a single feed. If you include relaying to multiple nodes, plus serving 500 million SPV clients en grosse, who has the capacity to run such a node? By the time we get to fee pressure, in your scenario, our network node count is tiny and highly centralized. 3) In RE "fee pressure" -- Do you see the moral hazard to a software-run system? It is an intentional, human decision to flood the market with supply, thereby altering the economics, forcing fees to remain low in the hopes of achieving adoption. I'm pro-bitcoin and obviously want to see bitcoin adoption - but I don't want to sacrifice every decentralized principle and become a central banker in order to get there. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ --089e013d0ddce3ec7905158347ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, May 7, 2015 at 3:31 PM, Alan Reiner <etotheipi@gmail.com> wrote:
=20 =20 =20
(1) Blocks are essentially nearing "full" now.=C2=A0 And by &= quot;full" he means that the reliability of the network (from the average user perspective) is about to be impacted in a very negative way

Er, to be economically precise, "full&q= uot; just means fees are no longer zero.=C2=A0 Bitcoin behaves as it always= has.=C2=A0 It is no longer basically free to dump spam into the blockchain= , as it is today.

In the short term, blocks are bursty, with some on= 1 minute intervals, some with 60 minute intervals.=C2=A0 This does not cha= nge with larger blocks.

=C2=A0
=20 (2) Leveraging fee pressure at 1MB to solve the problem is actually really a bad idea.=C2=A0 It's really bad while Bitcoin is still gro= wing, and relying on fee pressure at 1 MB severely impacts attractiveness and adoption potential of Bitcoin (due to high fees and unreliability).=C2=A0 But more importantly, it ignores the fact that fo= r a 7 tps is pathetic for a global transaction system.=C2=A0 It is a coup= le orders of magnitude too low for any meaningful commercial activity to occur.=C2=A0 If we continue with a cap of 7 tps forever, Bitcoin = will fail.=C2=A0 Or at best, it will fail to be useful for the vast majority of the world (which probably leads to failure).=C2=A0 We shouldn't = be talking about fee pressure until we hit 700 tps, which is probably still too low.=C2=A0
=C2=A0[...]

1) Agree that 7 tps is too low

2) Where do you wa= nt to go?=C2=A0 Should bitcoin scale up to handle all the world's coffe= es?=C2=A0

This is hugely unrealistic.=C2=A0 7= 00 tps is 100MB blocks, 14.4 GB/day -- just for a single feed.=C2=A0 If you= include relaying to multiple nodes, plus serving 500 million SPV clients e= n grosse, who has the capacity to run such a node?=C2=A0 By the time we get= to fee pressure, in your scenario, our network node count is tiny and high= ly centralized.

3) In RE "fee pressure" -- Do you se= e the moral hazard to a software-run system?=C2=A0 It is an intentional, hu= man decision to flood the market with supply, thereby altering the economic= s, forcing fees to remain low in the hopes of achieving adoption.=C2=A0 I&#= 39;m pro-bitcoin and obviously want to see bitcoin adoption - but I don'= ;t want to sacrifice every decentralized principle and become a central ban= ker in order to get there.

--
Jeff Garzik
Bitcoin core developer and open source evangel= ist
BitPay, Inc. =C2=A0 =C2=A0 =C2=A0https://bitpay.com/
--089e013d0ddce3ec7905158347ca--