Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148

From: Jacob Eliosoff <jacob.eliosoff@gmail•com>
To: "Jorge Timón" <jtimon@jtimon•cc>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148
Date: Tue, 30 May 2017 16:10:04 -0400	[thread overview]
Message-ID: <CAAUaCyj2Syv-YHiAQGWoeOqvP7_wG_FFQg0630X9Ut0Y_qE3dw@mail.gmail.com> (raw)
In-Reply-To: <CABm2gDpet31gEcBY6NTxEG+xA4rvg8_c79L+J=mJySGbf7Ydbg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4920 bytes --]

I'd like to know this too.  Is it just that a 4MB blockmaxweight would
theoretically allow ~4MB blocks (if ~all witness data), which is too big?
Or is there a more subtle reason we still need blockmaxsize after a HF?

On May 30, 2017 9:28 AM, "Jorge Timón 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
timing.
>
> 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
blocks
>> 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 right
>> 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-size
>> HF
>> improvements).
>>
>> I have left Author blank, as I do not intend to personally champion this.
>> 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>
>>
>> ==Abstract==
>>
>> Legacy Bitcoin transactions are given the witness discount, and a block
>> size
>> limit of 2 MB is imposed.
>>
>> ==Copyright==
>>
>> This BIP is licensed under the BSD 2-clause license.
>>
>> ==Specification==
>>
>> 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 other
>> 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.
>>
>> ===Deployment===
>>
>> This BIP is deployed by flag day, in the block where the median-past time
>> surpasses 1543503872 (2018 Nov 29 at 15:04:32 UTC).
>>
>> It is assumed that when this flag day has been reached, Segwit has been
>> activated via BIP141 and/or BIP148.
>>
>> ==Motivation==
>>
>> FIXME
>>
>> ==Rationale==
>>
>> FIXME
>>
>> ==Backwards compatibility==
>>
>> This is a hardfork, and as such not backward compatible.
>> It should not be deployed without consent of the entire Bitcoin
community.
>> Activation is scheduled for 18 months from the creation date of this BIP,
>> intended to give 6 months to establish consensus, and 12 months for
>> deployment.
>>
>> ==Reference implementation==
>>
>> 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

[-- Attachment #2: Type: text/html, Size: 7253 bytes --]