diff options
| author | Jorge Timón <jtimon@jtimon.cc> | 2017-05-31 00:26:20 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-05-30 22:26:23 +0000 |
| commit | b329f4cdd92451b753e5cbf13acd9afe6e950c35 (patch) | |
| tree | 23c1971ef92fde27a8005d4377bd29b727fd6a06 | |
| parent | e0309e2985c48f41c81aeab882ec97b80e88d372 (diff) | |
| download | pi-bitcoindev-b329f4cdd92451b753e5cbf13acd9afe6e950c35.tar.gz pi-bitcoindev-b329f4cdd92451b753e5cbf13acd9afe6e950c35.zip | |
Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148
| -rw-r--r-- | 0a/d0e45ca76d234ef5cec5647c3560cb6d19def7 | 303 |
1 files changed, 303 insertions, 0 deletions
diff --git a/0a/d0e45ca76d234ef5cec5647c3560cb6d19def7 b/0a/d0e45ca76d234ef5cec5647c3560cb6d19def7 new file mode 100644 index 000000000..595e8a30f --- /dev/null +++ b/0a/d0e45ca76d234ef5cec5647c3560cb6d19def7 @@ -0,0 +1,303 @@ +Return-Path: <jtimon@jtimon.cc> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id C190EBC4 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 30 May 2017 22:26:22 +0000 (UTC) +Received: by mail-ua0-f174.google.com with SMTP id y4so60062390uay.2 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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: <CAOG=w-uei5-c-Mpp_R6RrN29NTrSV+gpNd79FC3cB6QPG65sEw@mail.gmail.com> +References: <201705232023.40588.luke@dashjr.org> + <CAJowKgJK9zBkVAM1NyOsjU04gvwV3zGnk+1ebfpt6rnbiKy6Og@mail.gmail.com> + <CABm2gDpet31gEcBY6NTxEG+xA4rvg8_c79L+J=mJySGbf7Ydbg@mail.gmail.com> + <CAOG=w-uei5-c-Mpp_R6RrN29NTrSV+gpNd79FC3cB6QPG65sEw@mail.gmail.com> +From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc> +Date: Wed, 31 May 2017 00:26:20 +0200 +Message-ID: <CABm2gDr2YwHZ_=Ky4BX-zVL2YcUSk_DB=Vn9iCdDvvbsHx3h+A@mail.gmail.com> +To: Mark Friedenbach <mark@friedenbach.org> +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 <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <mark@friedenbach.org> 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 +> <bitcoin-dev@lists.linuxfoundation.org> 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 +>> <bitcoin-dev@lists.linuxfoundation.org> 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 +>>> <bitcoin-dev@lists.linuxfoundation.org> 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.) +>>>> +>>>> <pre> +>>>> 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 +>>>> </pre> +>>>> +>>>> =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 + |