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 1Z5j3D-0004SI-Hr for bitcoin-development@lists.sourceforge.net; Thu, 18 Jun 2015 23:16:51 +0000 X-ACL-Warn: Received: from homie.mail.dreamhost.com ([208.97.132.208] helo=homiemail-a7.g.dreamhost.com) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Z5j3B-00038e-Or for bitcoin-development@lists.sourceforge.net; Thu, 18 Jun 2015 23:16:51 +0000 Received: from homiemail-a7.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTP id 3E5C925C074 for ; Thu, 18 Jun 2015 16:16:44 -0700 (PDT) Received: from [10.9.1.135] (unknown [89.238.129.18]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jrn@jrn.me.uk) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTPSA id 8EA8E25C072 for ; Thu, 18 Jun 2015 16:16:43 -0700 (PDT) Message-ID: <5583515E.9080304@jrn.me.uk> Date: Fri, 19 Jun 2015 00:16:46 +0100 From: Ross Nicoll User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: <55828737.6000007@riseup.net> <55831CAB.2080303@jrn.me.uk> <1867667.WXWC1C9quc@crushinator> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040102080406070502080008" X-Spam-Score: 0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [208.97.132.208 listed in list.dnswl.org] 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.5 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Z5j3B-00038e-Or Subject: Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers 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, 18 Jun 2015 23:16:51 -0000 This is a multi-part message in MIME format. --------------040102080406070502080008 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I'm struggling to illustrate how incredibly low 7 transactions per second is, not just for a payment network, but even just for a clearance network (i.e. to balance transactions between institutions and/or chains). As an example, the Clearing House Interbank Payments System (CHIPS) is a US-only, inter-bank only clearance network, which handled about 3.5 transactions per second (average) in 2014 (https://www.theclearinghouse.org/~/media/tch/pay%20co/chips/reports%20and%20guides/chips%20volume%20through%20may%202015.pdf?la=en). While it seems likely the US population of 300 million makes more transactions individually than many other countries, and therefore we can't simply multiply that by 20 to estimate what a global clearance network might require, hopefully it's clear that if Bitcoin is to scale globally, it needs substantially more transaction throughput even if main chain transactions become something for banks and the super rich. I don't know how much more, but I can't look at the 8MB reportedly backed by a number of mining pools and say it's clearly insufficient, at least. I should emphasise that I don't think we need to jump straight to 8MB (or otherwise), if a scaling protocol can be decided upon that would be ideal, but we should be planning ahead while it's still relatively easy to make these changes. Ross On 18/06/2015 23:33, Mark Friedenbach wrote: > On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik > wrote: > > > The whole point is getting out in front of the need, to prevent > significant negative impact to users when blocks are consistently > full. > > To do that, you need to (a) plan forward, in order to (b) set a > hard fork date in the future. > > > Or alternatively, fix the reasons why users would have negative > experiences with full blocks, chiefly: > > * Get safe forms of replace-by-fee and child-pays-for-parent > finished and in 0.12. > * Develop cross-platform libraries for managing micropayment > channels, and get wallet authors to adopt > * Use fidelity bonds, solvency proofs, and other tricks to minimize > the risk of already deployed off-chain solutions as an interim measure > until: > * Deploy soft-fork changes for truly scalable solutions like > Lightning Network. > > Not raising the block size limit does not mean doing nothing to solve > the problem. > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development --------------040102080406070502080008 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'm struggling to illustrate how incredibly low 7 transactions per second is, not just for a payment network, but even just for a clearance network (i.e. to balance transactions between institutions and/or chains). As an example, the Clearing House Interbank Payments System (CHIPS) is a US-only, inter-bank only clearance network, which handled about 3.5 transactions per second (average) in 2014 (https://www.theclearinghouse.org/~/media/= tch/pay%20co/chips/reports%20and%20guides/chips%20volume%20through%20may%= 202015.pdf?la=3Den).

While it seems likely the US population of 300 million makes more transactions individually than many other countries, and therefore we can't simply multiply that by 20 to estimate what a global clearance network might require, hopefully it's clear that if Bitcoin is to scale globally, it needs substantially more transaction throughput even if main chain transactions become something for banks and the super rich. I don't know how much more, but I can't look at the 8MB reportedly backed by a number of mining pools and say it's clearly insufficient, at least.

I should emphasise that I don't think we need to jump straight to 8MB (or otherwise), if a scaling protocol can be decided upon that would be ideal, but we should be planning ahead while it's still relatively easy to make these changes.

Ross

On 18/06/2015 23:33, Mark Friedenbach wrote:
On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik <jgarzik@= bitpay.com> wrote:

The whole point is getting out in front of the need, to prevent significant negative impact to users when blocks are consistently full.

To do that, you need to (a) plan forward, in order to (b) set a hard fork date in the future.

Or alternatively, fix the reasons why users would have negative experiences with full blocks, chiefly:

=A0 * Get safe forms of replace-by-fee and child-pays-for-parent finished and in 0.12.
=A0 * Develop cross-platform libraries for managing micropayment channels, and get wallet authors to adopt
=A0 * Use fidelity bonds, solvency proofs, and other tricks to minimize the risk of already deployed off-chain solutions as an interim measure until:
=A0 * Deploy soft-fork changes for truly scalable solutions like Lightning Network.

Not raising the block size limit does not mean doing nothing to solve the problem.



----------------------------------------------------=
--------------------------



_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/l=
istinfo/bitcoin-development

--------------040102080406070502080008--