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 C190EBC4 for ; Tue, 30 May 2017 22:26:23 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f174.google.com (mail-ua0-f174.google.com [209.85.217.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2145F1FB for ; Tue, 30 May 2017 22:26:22 +0000 (UTC) Received: by mail-ua0-f174.google.com with SMTP id y4so60062390uay.2 for ; Tue, 30 May 2017 15:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jtimon-cc.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=syVB8Fzg9WqlsBdgr06XcjY1GeV2OUZC15wiH9CgWdo=; b=nJxLEitpkjMDBoeMU9LuAe7+n7te8WSwA5VALjlewOqSlx+ytjgb2vlH7gkKs6qdEI GA0Uzn/h86j25lSQ6luq1I1D+SpqGGJqUknmQEt4vGdIhO+Mffq65D9ccJxmpHrr5iLd ULXXGrO0/wOodTM76K6deyx34HoIkeGnEgj5wXYsMueljygTC9olT2+lpmzFgJBN33j7 oe2ZpIZE5JHbwKrFIlZU5ztAgueARaJImS6dGO83TIeiQCllKrRveqoJcuY79+aZLxvZ Uz5uToYeS1lbbyS52BdZNRIDdyxRNkDeZH3ilmumMs3FkGflHCX2LaJloxuOq2/BxQAV AvtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=syVB8Fzg9WqlsBdgr06XcjY1GeV2OUZC15wiH9CgWdo=; b=WyGKpd7T0I8C3jnttYAjulbF5165ZmNzxZCNa3OTKfqAp2hRfpi5Vs//MHFsk4piDa 6gY/XfCJ9HTVY0bDjzRiwwCOW+CqMqW82n8bvBq3ssfoaG7XUbBoI1ltZt1neepoh6gQ QhfnKA6459SaARo95GdWzO+hx3evkaoTKY6k8yOJjjTs13OwYdDq43NB/Sy2xa+QtQHI cUzBuukuvyKPeTefIUo8lqPh2u3Xrn0bA6dB6NwSY3W5nBemh2YKhVUPqLuKYZmJUJV4 jMU5e7vx65uOxifMP54UafPtmGUEXJ2Az10WEcvgvefsMo51aR+mNlZRWzubi1FTKTG4 ZYTg== X-Gm-Message-State: AODbwcCGaDw7I8Q63fkYr7jnDeLwVKLDfIbTOGpbjbJTl0z8YTlRVxmU cHycKDyFptxAt723Q4EHmhNpVGcSYjtg X-Received: by 10.176.78.161 with SMTP id l33mr9630335uah.24.1496183181107; Tue, 30 May 2017 15:26:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.52.213 with HTTP; Tue, 30 May 2017 15:26:20 -0700 (PDT) In-Reply-To: References: <201705232023.40588.luke@dashjr.org> From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Date: Wed, 31 May 2017 00:26:20 +0200 Message-ID: To: Mark Friedenbach Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no 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] Hypothetical 2 MB hardfork to follow BIP148 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, 30 May 2017 22:26:23 -0000 My understanding is that you cannot possibly violate the 1 MB block size rule without also violating the 4 MB weight rule. Regarding size alone, the only check we care about if we accept segwit is: https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L2891 [si= ze4] If that doesn't fail due to excessive non-witness data, then there's no way= that https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L2681 [si= ze1] would have failed before due to excessive non-witness data. If I understood it correctly when I was explained, if I remember correctly, that last check is really just an optimization or a protection against DoS invalid blocks. If the size without any witness data is bigger than 1/4 the max_weight, then the max_weight check is certain to fail as well without having to look at any witness data at that validation stage (assuming the failure is due to excessive non-witness data). I think you are not referring to the 1 mb size limit but to related one for sigops: https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L2704 [sigops1] whose segwit parallel is in: https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1661 [sigops4] I believe the situation is similar in checking before knowing anything about the witness data just in case that's already too much. In fact, here is clearer because MAX_BLOCK_SIGOPS_COST is used for both (and WITNESS_SCALE_FACTOR is used for the optimization case). So what I would do in a hardfork after segwit activation would be to simply equal MAX_BLOCK_BASE_SIZE=3DMAX_BLOCK_WEIGHT/WITNESS_SCALE_FACTOR for size1, and increase MAX_BLOCK_WEIGHT and MAX_BLOCK_ SIGOPS_COST proportionally for size4 and sigops4 respectively (well, the sigops const for sigops1 as well). If I understood segwit correctly, I believe that even though it is not activated yet, you could remove both the size1 and sigops1 checks and your node would still not accept invalid blocks by pre-bip141 rules, your node would just spend more time on invalid blocks due to currently excessive size/sigops, because it would only realize at a later validation stage. Sorry for the redundancy about the validation stage. But it is not unlikely that I'm missing something. If I am wrong about this I am spreading misinformation about segwit in several channels, so I'm very interested in corrections to my statements in this mail. On Tue, May 30, 2017 at 11:24 PM, Mark Friedenbach w= rote: > The 1MB classic block size is not redundant after segwit activation. > Segwit prevents the quadratic hashing problems, but only for segwit > outputs. The 1MB classic block size prevents quadratic hashing > problems from being any worse than they are today. > > Mark > > On Tue, May 30, 2017 at 6:27 AM, Jorge Tim=C3=B3n via bitcoin-dev > wrote: >> Why not simply remove the (redundant after sw activation) 1 mb size >> limit check and increasing the weight limit without changing the >> discount or having 2 limits? >> >> >> On Wed, May 24, 2017 at 1:07 AM, Erik Aronesty via bitcoin-dev >> wrote: >>> Personally, I would prefer if a 2MB lock-in that uses BIP103 for the ti= ming. >>> >>> I think up to 20% per year can be absorbed by averages in bandwidth/CPU= /RAM >>> growth, of which bandwidth seems the most constraining. >>> >>> - Erik >>> >>> >>> On Tue, May 23, 2017 at 4:23 PM, Luke Dashjr via bitcoin-dev >>> wrote: >>>> >>>> In light of some recent discussions, I wrote up this BIP for a real 2 = MB >>>> block >>>> size hardfork following Segwit BIP148 activation. This is not part of = any >>>> agreement I am party to, nor anything of that sort. Just something to >>>> throw >>>> out there as a possible (and realistic) option. >>>> >>>> Note that I cannot recommend this to be adopted, since frankly 1 MB bl= ocks >>>> really are still too large, and this blunt-style hardfork quite risky = even >>>> with consensus. But if the community wishes to adopt (by unanimous >>>> consensus) >>>> a 2 MB block size hardfork, this is probably the best way to do it rig= ht >>>> now. >>>> The only possible way to improve on this IMO would be to integrate it = into >>>> MMHF/"spoonnet" style hardfork (and/or add other unrelated-to-block-si= ze >>>> HF >>>> improvements). >>>> >>>> I have left Author blank, as I do not intend to personally champion th= is. >>>> Before it may be assigned a BIP number, someone else will need to step= up >>>> to >>>> take on that role. Motivation and Rationale are blank because I do not >>>> personally think there is any legitimate rationale for such a hardfork= at >>>> this >>>> time; if someone adopts this BIP, they should complete these sections.= (I >>>> can >>>> push a git branch with the BIP text if someone wants to fork it.) >>>> >>>> 
>>>> BIP: ?
>>>> Layer: Consensus (hard fork)
>>>> Title: Post-segwit 2 MB block size hardfork
>>>> Author: FIXME
>>>> Comments-Summary: No comments yet.
>>>> Comments-URI: ?
>>>> Status: Draft
>>>> Type: Standards Track
>>>> Created: 2017-05-22
>>>> License: BSD-2-Clause
>>>>
>>>> >>>> =3D=3DAbstract=3D=3D >>>> >>>> Legacy Bitcoin transactions are given the witness discount, and a bloc= k >>>> size >>>> limit of 2 MB is imposed. >>>> >>>> =3D=3DCopyright=3D=3D >>>> >>>> This BIP is licensed under the BSD 2-clause license. >>>> >>>> =3D=3DSpecification=3D=3D >>>> >>>> Upon activation, a block size limit of 2000000 bytes is enforced. >>>> The block weight limit remains at 4000000 WU. >>>> >>>> The calculation of block weight is modified: >>>> all witness data, including both scriptSig (used by pre-segwit inputs)= and >>>> segwit witness data, is measured as 1 weight-unit (WU), while all othe= r >>>> data >>>> in the block is measured as 4 WU. >>>> >>>> The witness commitment in the generation transaction is no longer >>>> required, >>>> and instead the txid merkle root in the block header is replaced with = a >>>> hash >>>> of: >>>> >>>> 1. The witness reserved value. >>>> 2. The witness merkle root hash. >>>> 3. The transaction ID merkle root hash. >>>> >>>> The maximum size of a transaction stripped of witness data is limited = to 1 >>>> MB. >>>> >>>> =3D=3D=3DDeployment=3D=3D=3D >>>> >>>> This BIP is deployed by flag day, in the block where the median-past t= ime >>>> surpasses 1543503872 (2018 Nov 29 at 15:04:32 UTC). >>>> >>>> It is assumed that when this flag day has been reached, Segwit has bee= n >>>> activated via BIP141 and/or BIP148. >>>> >>>> =3D=3DMotivation=3D=3D >>>> >>>> FIXME >>>> >>>> =3D=3DRationale=3D=3D >>>> >>>> FIXME >>>> >>>> =3D=3DBackwards compatibility=3D=3D >>>> >>>> This is a hardfork, and as such not backward compatible. >>>> It should not be deployed without consent of the entire Bitcoin commun= ity. >>>> Activation is scheduled for 18 months from the creation date of this B= IP, >>>> intended to give 6 months to establish consensus, and 12 months for >>>> deployment. >>>> >>>> =3D=3DReference implementation=3D=3D >>>> >>>> FIXME >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev