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 F163089E for ; Tue, 28 Mar 2017 17:33:58 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E6BAE20C for ; Tue, 28 Mar 2017 17:33:57 +0000 (UTC) X-AuditID: 1209190e-42fff70000003f09-eb-58da9e832d63 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id CD.4A.16137.38E9AD85; Tue, 28 Mar 2017 13:33:56 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v2SHXtNN006736 for ; Tue, 28 Mar 2017 13:33:55 -0400 Received: from mail-pg0-f47.google.com (mail-pg0-f47.google.com [74.125.83.47]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v2SHXqFo024968 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 28 Mar 2017 13:33:53 -0400 Received: by mail-pg0-f47.google.com with SMTP id 21so78985330pgg.1 for ; Tue, 28 Mar 2017 10:33:53 -0700 (PDT) X-Gm-Message-State: AFeK/H19sGmIUM7Oc5canR9OxN+x2ndCLdGqiomhU6EZK6Cw+LY7xj5DP7+wLs0LD8c5shD2q0UnE6LeuHrMvw== X-Received: by 10.84.229.79 with SMTP id d15mr21929863pln.49.1490722432020; Tue, 28 Mar 2017 10:33:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.162.101 with HTTP; Tue, 28 Mar 2017 10:33:31 -0700 (PDT) In-Reply-To: References: From: Jeremy Date: Tue, 28 Mar 2017 13:33:31 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Wang Chun <1240902@gmail.com>, Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=94eb2c19ecb404f9c8054bcddd0a X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDKsWRmVeSWpSXmKPExsUixCmqrNsy71aEwaa/0hZNr20dGD1+/5jM GMAYxWWTkpqTWZZapG+XwJXRMSW44HlYxcGNXUwNjL0eXYycHBICJhJ3e5czdzFycQgJtDFJ zDy/mB0kISRwl1Hi+0FriMQHJokdJ98xQyTmM0rc65eH6M6RuPW0nw3CLpZYdm0GE4jNKyAo cXLmExaIeh+J7cvvgdmcAoESf2YfZIIYeodRYvKqy0DNHBxsAnISH36ZgtSwCKhK3H31hxli ZqLE1leLGSFmBkjceboHbL6wgJvEy1MgcQ4OEYF8iS+fpUHCzAKaErcarrND2F4S64/fZ5vA KDwLyUWzkKRmAXUzC6hLrJ8nBBFWk7i97So7hK0tsWzha+YFjKyrGGVTcqt0cxMzc4pTk3WL kxPz8lKLdI31cjNL9FJTSjcxgqNAkm8H46QG70OMAhyMSjy8O/JuRQixJpYVV+YeYpTkYFIS 5f0QBBTiS8pPqcxILM6ILyrNSS0+xCjBwawkwvtrDlCONyWxsiq1KB8mJc3BoiTOK67RGCEk kJ5YkpqdmlqQWgSTleHgUJLgLZ8L1ChYlJqeWpGWmVOCkGbi4AQZzgM03AKkhre4IDG3ODMd In+K0Zija8bON0wcH/oPv2ESYsnLz0uVEucNBLlDAKQ0ozQPbhookXnVBuu/YhQHek6Ytxdk IA8wCcLNewW0iglolbgN2KqSRISUVAOjhmbX3+Rjl3h7ei6dcvgas+mnRsRqsQV1NWn6Vzn6 wrI2NDg/dDr5ulo8pV3QTdRKtsXYbeM65/OGJSY1jBv9pjuse7pi8/c4RhOjUv6upuyozxqb rBOTHDw3Kp98UM0pcebJrU+3t/Z+Z1qU7La9fNvElbrupq6zju871H1J3Vfks5RhjrsSS3FG oqEWc1FxIgCB1VbkPwMAAA== X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED,RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 17:33:59 -0000 --94eb2c19ecb404f9c8054bcddd0a Content-Type: text/plain; charset=UTF-8 I think it's probably safer to have a fork-to-minumum (e.g. minimal coinbase+header) after a certain date than to fork up at a certain date. At least in that case, the default isn't breaking consensus, but you still get the same pressure to fork to a permanent solution. I don't endorse the above proposal, but remarked for the sake of guiding the argument you are making. -- @JeremyRubin On Tue, Mar 28, 2017 at 1:31 PM, Wang Chun via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The basic idea is, let's stop the debate for whether we should upgrade > to 2MB, 8MB or 32MiB. 32MiB is well above any proposals' upper limit, > so any final decision would be a soft fork to this already deployed > release. If by 2020, we still agree 1MB is enough, it can be changed > back to 1MB limit and it would also a soft fork on top of that. > > On Wed, Mar 29, 2017 at 1:23 AM, Alphonse Pace > wrote: > > What meeting are you referring to? Who were the participants? > > > > Removing the limit but relying on the p2p protocol is not really a true > > 32MiB limit, but a limit of whatever transport methods provide. This can > > lead to differing consensus if alternative layers for relaying are used. > > What you seem to be asking for is an unbound block size (or at least > > determined by whatever miners produce). This has the possibility (and > even > > likelihood) of removing many participants from the network, including > many > > small miners. > > > > 32MB in less than 3 years also appears to be far beyond limits of safety > > which are known to exist far sooner, and we cannot expect hardware and > > networking layers to improve by those amounts in that time. > > > > It also seems like it would be much better to wait until SegWit > activates in > > order to truly measure the effects on the network from this increased > > capacity before committing to any additional increases. > > > > -Alphonse > > > > > > > > On Tue, Mar 28, 2017 at 11:59 AM, Wang Chun via bitcoin-dev > > wrote: > >> > >> I've proposed this hard fork approach last year in Hong Kong Consensus > >> but immediately rejected by coredevs at that meeting, after more than > >> one year it seems that lots of people haven't heard of it. So I would > >> post this here again for comment. > >> > >> The basic idea is, as many of us agree, hard fork is risky and should > >> be well prepared. We need a long time to deploy it. > >> > >> Despite spam tx on the network, the block capacity is approaching its > >> limit, and we must think ahead. Shall we code a patch right now, to > >> remove the block size limit of 1MB, but not activate it until far in > >> the future. I would propose to remove the 1MB limit at the next block > >> halving in spring 2020, only limit the block size to 32MiB which is > >> the maximum size the current p2p protocol allows. This patch must be > >> in the immediate next release of Bitcoin Core. > >> > >> With this patch in core's next release, Bitcoin works just as before, > >> no fork will ever occur, until spring 2020. But everyone knows there > >> will be a fork scheduled. Third party services, libraries, wallets and > >> exchanges will have enough time to prepare for it over the next three > >> years. > >> > >> We don't yet have an agreement on how to increase the block size > >> limit. There have been many proposals over the past years, like > >> BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248, BU, and so > >> on. These hard fork proposals, with this patch already in Core's > >> release, they all become soft fork. We'll have enough time to discuss > >> all these proposals and decide which one to go. Take an example, if we > >> choose to fork to only 2MB, since 32MiB already scheduled, reduce it > >> from 32MiB to 2MB will be a soft fork. > >> > >> Anyway, we must code something right now, before it becomes too late. > >> _______________________________________________ > >> bitcoin-dev mailing list > >> bitcoin-dev@lists.linuxfoundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --94eb2c19ecb404f9c8054bcddd0a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think it's proba= bly safer to have a fork-to-minumum (e.g. minimal=20 coinbase+header) after a certain date than to fork up at a certain date. At least in that case, the default isn't breaking consensus, but you= =20 still get the same pressure to fork to a permanent solution.

I don&#= 39;t endorse the above proposal, but remarked for the sake of guiding the a= rgument you are making.


On Tue, Mar 28, 2017 at 1:31 PM, Wang Chun v= ia bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org<= /a>> wrote:
The basic idea is, = let's stop the debate for whether we should upgrade
to 2MB, 8MB or 32MiB. 32MiB is well above any proposals' upper limit, so any final decision would be a soft fork to this already deployed
release. If by 2020, we still agree 1MB is enough, it can be changed
back to 1MB limit and it would also a soft fork on top of that.

On Wed, Mar 29, 2017 at 1:23 AM, Alphonse Pace <alp.bitcoin@gmail.com> wrote:
> What meeting are you referring to?=C2=A0 Who were the participants? >
> Removing the limit but relying on the p2p protocol is not really a tru= e
> 32MiB limit, but a limit of whatever transport methods provide.=C2=A0 = This can
> lead to differing consensus if alternative layers for relaying are use= d.
> What you seem to be asking for is an unbound block size (or at least > determined by whatever miners produce).=C2=A0 This has the possibility= (and even
> likelihood) of removing many participants from the network, including = many
> small miners.
>
> 32MB in less than 3 years also appears to be far beyond limits of safe= ty
> which are known to exist far sooner, and we cannot expect hardware and=
> networking layers to improve by those amounts in that time.
>
> It also seems like it would be much better to wait until SegWit activa= tes in
> order to truly measure the effects on the network from this increased<= br> > capacity before committing to any additional increases.
>
> -Alphonse
>
>
>
> On Tue, Mar 28, 2017 at 11:59 AM, Wang Chun via bitcoin-dev
> <bitcoin-d= ev@lists.linuxfoundation.org> wrote:
>>
>> I've proposed this hard fork approach last year in Hong Kong C= onsensus
>> but immediately rejected by coredevs at that meeting, after more t= han
>> one year it seems that lots of people haven't heard of it. So = I would
>> post this here again for comment.
>>
>> The basic idea is, as many of us agree, hard fork is risky and sho= uld
>> be well prepared. We need a long time to deploy it.
>>
>> Despite spam tx on the network, the block capacity is approaching = its
>> limit, and we must think ahead. Shall we code a patch right now, t= o
>> remove the block size limit of 1MB, but not activate it until far = in
>> the future. I would propose to remove the 1MB limit at the next bl= ock
>> halving in spring 2020, only limit the block size to 32MiB which i= s
>> the maximum size the current p2p protocol allows. This patch must = be
>> in the immediate next release of Bitcoin Core.
>>
>> With this patch in core's next release, Bitcoin works just as = before,
>> no fork will ever occur, until spring 2020. But everyone knows the= re
>> will be a fork scheduled. Third party services, libraries, wallets= and
>> exchanges will have enough time to prepare for it over the next th= ree
>> years.
>>
>> We don't yet have an agreement on how to increase the block si= ze
>> limit. There have been many proposals over the past years, like >> BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248, BU, and = so
>> on. These hard fork proposals, with this patch already in Core'= ;s
>> release, they all become soft fork. We'll have enough time to = discuss
>> all these proposals and decide which one to go. Take an example, i= f we
>> choose to fork to only 2MB, since 32MiB already scheduled, reduce = it
>> from 32MiB to 2MB will be a soft fork.
>>
>> Anyway, we must code something right now, before it becomes too la= te.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-d= ev@lists.linuxfoundation.org
>> https://lists.linuxfoundation= .org/mailman/listinfo/bitcoin-dev
>
>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev

--94eb2c19ecb404f9c8054bcddd0a--