From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 736364A8 for ; Thu, 30 Jul 2015 16:49:54 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f182.google.com (mail-io0-f182.google.com [209.85.223.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9CE4110A for ; Thu, 30 Jul 2015 16:49:53 +0000 (UTC) Received: by ioii16 with SMTP id i16so59649571ioi.0 for ; Thu, 30 Jul 2015 09:49:53 -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=VjUx52X4e3lM0b11kPwkv4B3uPZbryG4dndVVAE0Jp0=; b=kz/yAWf28mXk5N5atUtse3Jf/V27p5eDUi7fAEjzG3TGCZ22r1jU7/dSkcXpZ/jIVJ 3f1jOwlrr7v+m/zW9M9hmcn60RSwrII3VgC2QhEHs4SVMQqy7eAZ246aaMl1tyzELZ48 mjuX8JfGIsfnWhYK+gt0PP+oHxR3faNp8Y0RM3H/8Ih/GR4QV3hGoU/dJfWfJMhk9Q/V o9y5muKbqBDcUYbJ0xsyPiwqndt7tRUKxGvcunQTg/O8ClSeb2LQ02byKfcOox0+pOPD 3TUsW8TnJ4YiFuVT/Q0x6udm+dR7YFzvFRSugWXSFlSj+WFns6VUobvJLRZLOyaAFUmr Oung== MIME-Version: 1.0 X-Received: by 10.107.9.137 with SMTP id 9mr12486315ioj.50.1438274993030; Thu, 30 Jul 2015 09:49:53 -0700 (PDT) Received: by 10.36.77.201 with HTTP; Thu, 30 Jul 2015 09:49:52 -0700 (PDT) Received: by 10.36.77.201 with HTTP; Thu, 30 Jul 2015 09:49:52 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Jul 2015 18:49:52 +0200 Message-ID: From: Pieter Wuille To: Gavin Andresen Content-Type: multipart/alternative; boundary=001a113f8f140c8ff2051c1a7e84 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] Block size following technological growth 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 16:49:54 -0000 --001a113f8f140c8ff2051c1a7e84 Content-Type: text/plain; charset=UTF-8 On Jul 30, 2015 6:20 PM, "Gavin Andresen" wrote: > > On Thu, Jul 30, 2015 at 10:25 AM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> Some things are not included yet, such as a testnet whose size runs ahead of the main chain, and the inclusion of Gavin's more accurate sigop checking after the hard fork. >> >> Comments? > > > First, THANK YOU for making a concrete proposal! You're welcome. > Specific comments: > > So we'd get to 2MB blocks in the year 2021. I think that is much too conservative, and the most likely effect of being that conservative is that the main blockchain becomes a settlement network, affordable only for large-value transactions. If there is demand for high-value settlements in Bitcoin, and this results in a functioning economy where fees support the security of a transparent network, I think that would be a much better outcome than what we have now. > I don't think your proposal strikes the right balance between centralization of payments (a future where only people running payment hubs, big merchants, exchanges, and wallet providers settle on the blockchain) and centralization of mining. Well, centralization of mining is already terrible. I see no reason why we should encourage making it worse. On the other hand, sure, not every transaction fits on the blockchain. That is already the case, and will remain the case with 2 MB or 8 MB or 100 MB blocks. Some use cases fit, and others won't. We need to accept that, and all previous proposals I've seen don't seem to do that. Maybe the only ones that will fit are large settlements between layer-2 services, and maybe it will be something entirely different. But at least we don't need to compromise the security of the main layer, or promise the ecosystem unrealistic growth of space for on-chain transactions. If Bitcoin needs to support a large scale, it already failed. > I'll comment on using median time generally in Jorge's thread, but why does monotonically increasing matter for max block size? I can't think of a reason why a max block size of X bytes in block N followed by a max size of X-something bytes in block N+1 would cause any problems. I don't think it matters much, but it offers slightly easier transition for the mempool (something Jorge convinced me of), and validation can benefit from a single variable that can be set in a chain to indicate a switchover happened, without needing to recalculate it every time. I assume you're asking this because using raw nTime means you can check what limits a p2p message should obey to by looking at just the first bytes. I don't think this matters: your p2p protocol should deal with whatever limits the system requires anyway. An attacker can take a valid message of far in the chain, change a few bytes, and spam you with it at zero extra effort anyway. -- Pieter --001a113f8f140c8ff2051c1a7e84 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jul 30, 2015 6:20 PM, "Gavin Andresen" <gavinandresen@gmail.com> wrote:
>
> On Thu, Jul 30, 2015 at 10:25 AM, Pieter Wuille via bitcoin-dev <bitcoin-dev@lists.li= nuxfoundation.org> wrote:
>>
>> Some things are not included yet, such as a testnet whose size run= s ahead of the main chain, and the inclusion of Gavin's more accurate s= igop checking after the hard fork.
>>
>> Comments?
>
>
> First, THANK YOU for making a concrete proposal!

You're welcome.

> Specific comments:
>
> So we'd get to 2MB blocks in the year 2021. I think that is much t= oo conservative, and the most likely effect of being that conservative is t= hat the main blockchain becomes a settlement network, affordable only for l= arge-value transactions.

If there is demand for high-value settlements in Bitcoin, an= d this results in a functioning economy where fees support the security of = a transparent network, I think that would be a much better outcome than wha= t we have now.

> I don't think your proposal strikes the right balan= ce between centralization of payments (a future where only people running p= ayment hubs, big merchants, exchanges, and wallet providers settle on the b= lockchain) and centralization of mining.

Well, centralization of mining is already terrible. I see no= reason why we should encourage making it worse. On the other hand, sure, n= ot every transaction fits on the blockchain. That is already the case, and = will remain the case with 2 MB or 8 MB or 100 MB blocks. Some use cases fit= , and others won't. We need to accept that, and all previous proposals = I've seen don't seem to do that.

Maybe the only ones that will fit are large settlements betw= een layer-2 services, and maybe it will be something entirely different. Bu= t at least we don't need to compromise the security of the main layer, = or promise the ecosystem unrealistic growth of space for on-chain transacti= ons.

If Bitcoin needs to support a large scale, it already failed= .

> I'll comment on using median time generally in Jorg= e's thread, but why does monotonically increasing matter for max block = size? I can't think of a reason why a max block size of X bytes in bloc= k N followed by a max size of X-something bytes in block N+1 would cause an= y problems.

I don't think it matters much, but it offers slightly ea= sier transition for the mempool (something Jorge convinced me of), and vali= dation can benefit from a single variable that can be set in a chain to ind= icate a switchover happened, without needing to recalculate it every time.<= /p>

I assume you're asking this because using raw nTime mean= s you can check what limits a p2p message should obey to by looking at just= the first bytes. I don't think this matters: your p2p protocol should = deal with whatever limits the system requires anyway. An attacker can take = a valid message of far in the chain, change a few bytes, and spam you with = it at zero extra effort anyway.

--
Pieter

--001a113f8f140c8ff2051c1a7e84--