Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BBE44267 for ; Thu, 30 Jul 2015 12:50:47 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f181.google.com (mail-io0-f181.google.com [209.85.223.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E827510A for ; Thu, 30 Jul 2015 12:50:46 +0000 (UTC) Received: by ioea135 with SMTP id a135so52348443ioe.1 for ; Thu, 30 Jul 2015 05:50:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3C12qYpyOJ9t2AG4NRZZH9lMJ6o9OVXLU5mSeRFMN78=; b=dAgzy5K4hJHNmVG5tNRx9T2cQmSc9zzIbyNsxkFS3zY3JeEXnYAQ468x1YspNkeJVs o2FHf2KhZV08gVD1mx6U3UUkTIMjYkUFnCCsBkpC0tuhBVR6gRBlk0ujycuGY8/Ox1lM XnN3C5AuNIocmW2fNlneQJohr9JPORhSvhBboTOUhTzDGtR3ZpoLBZ/Adoy0x9LVVDxN RU3a15EwxwiwjXSHrnvGB4/lajCqaQgg8Du+XIWfEZYJIKNaLqBnFzEXloDtZ40zCAJv QGmypr2oZd/mfxyF3VLCDbPzI74J/vKWcTLtQqtPy6fBJ29mGrSDEOE3MP6TpkSyzdnf OQ1Q== MIME-Version: 1.0 X-Received: by 10.107.9.137 with SMTP id 9mr10418117ioj.50.1438260646463; Thu, 30 Jul 2015 05:50:46 -0700 (PDT) Received: by 10.36.77.201 with HTTP; Thu, 30 Jul 2015 05:50:46 -0700 (PDT) In-Reply-To: References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com> <37D282C2-EF9C-4B8B-91E8-7D613B381824@phauna.org> <55B94FAD.7040205@mail.bihthai.net> <74767203-7F7A-4848-9923-DE1DE60A28B4@gmail.com> Date: Thu, 30 Jul 2015 14:50:46 +0200 Message-ID: From: Pieter Wuille To: Gavin Content-Type: multipart/alternative; boundary=001a113f8f14ed5033051c17263f X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW 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] Why Satoshi's temporary anti-spam measure isn't temporary 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: Thu, 30 Jul 2015 12:50:47 -0000 --001a113f8f14ed5033051c17263f Content-Type: text/plain; charset=UTF-8 On Thu, Jul 30, 2015 at 2:29 PM, Gavin via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > > On Jul 30, 2015, at 4:21 AM, Eric Lombrozo wrote: > > > > and a number of the people most intimately familiar with the inner > workings of the system (some of whom are in this thread) think that given > what we now today about the Bitcoin network, increasing block size > externalizes costs in dangerous ways. Remember that total cost includes not > just equipment costs but also things like block propagation latency and > specifically identified security risks. Some of these security risks were > only appreciated relatively recently and were completely unknown in 2009. > > I would like (and have been asking) those people to take the time to > quantify those costs and write up those risks in a careful way. > > I believe the costs and risks of 8MB blocks are minimal, and that the > benefits of supporting more transaction FAR outweigh those costs and risks, > but it is hard to have a rational conversation about that when even simple > questions like 'what is s reasonable cost to run a full node' are met with > silence. > I think the benefit of an 8 MB over a 1 MB in terms of utility is marginal (even assuming miners actually produce 8 MB blocks). There are very few use cases that Bitcoin on-chain can support with a small extra factor. I think the market will grow to adapt to whatever is offered anyway. Bitcoin's advantage over other systems does not lie in scalability. Well-designed centralized systems can trivially compete with Bitcoin's on-chain transactions in terms of cost, speed, reliability, convenience, and scale. Its power lies in transparency, lack of need for trust in network peers, miners, and those who influence or control the system. Wanting to increase the scale of the system is in conflict with all of those. Attempting to buy time with a fast increase is not wanting to face that reality, and treating the system as something whose scale trumps all other concerns. A long term scalability plan should aim on decreasing the need for trust required in off-chain systems, rather than increasing the need for trust in Bitcoin. Making controversial changes to the network, and not wanting to face the reality that block chain space is a finite resource - whether enforced by a consensus rule or by miner's capacity to process transactions - is a huge treat to Bitcoin's usefulness in the long term. I think the risks of trying to make a controversial change to the network FAR outweighs the benefits of a small constant factor that "kicks the can down the road". Let's scale the block size gradually over time, according to technological growth. -- Pieter --001a113f8f14ed5033051c17263f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jul 30, 2015 at 2:29 PM, Gavin via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wro= te:

> On Jul 30, 2015, at 4:21 AM, Eric Lombrozo wrote:
>
> and a number of the people most intimately familiar with the inner wor= kings of the system (some of whom are in this thread) think that given what= we now today about the Bitcoin network, increasing block size externalizes= costs in dangerous ways. Remember that total cost includes not just equipm= ent costs but also things like block propagation latency and specifically i= dentified security risks. Some of these security risks were only appreciate= d relatively recently and were completely unknown in 2009.

I would like (and have been asking) those people to take the time to= quantify those costs and write up those risks in a careful way.

I believe the costs and risks of 8MB blocks are minimal, and that the benef= its of supporting more transaction FAR outweigh those costs and risks, but = it is hard to have a rational conversation about that when even simple ques= tions like 'what is s reasonable cost to run a full node' are met w= ith silence.

I think the benefit of an 8 MB = over a 1 MB in terms of utility is marginal (even assuming miners actually = produce 8 MB blocks). There are very few use cases that Bitcoin on-chain ca= n support with a small extra factor. I think the market will grow to adapt = to whatever is offered anyway.

Bitcoin's advantage over other sy= stems does not lie in scalability.=20 Well-designed centralized systems can trivially compete with Bitcoin's= =20 on-chain transactions in terms of cost, speed, reliability, convenience, and scale. Its power lies in transparency, lack of need for trust in=20 network peers, miners, and those who influence or control the system.=20 Wanting to increase the scale of the system is in conflict with all of=20 those. Attempting to buy time with a fast increase is not wanting to=20 face that reality, and treating the system as something whose scale=20 trumps all other concerns. A long term scalability plan should aim on=20 decreasing the need for trust required in off-chain systems, rather than increasing the need for trust in Bitcoin.

Making controversial changes to the network, and not wanting to fac= e the reality that block chain space is a finite resource - whether enforce= d by a consensus rule or by miner's capacity to process transactions - = is a huge treat to Bitcoin's usefulness in the long term.

=
I think the risks of trying to make a controvers= ial change to the network FAR outweighs the benefits of a small constant fa= ctor that "kicks the can down the road".

Let's scale the block size gradually over time, accord= ing to technological growth.

--
Pieter

--001a113f8f14ed5033051c17263f--