MIME-Version: 1.0
In-Reply-To: <CAJowKgJK9zBkVAM1NyOsjU04gvwV3zGnk+1ebfpt6rnbiKy6Og@mail.gmail.com>
References: <201705232023.40588.luke@dashjr.org>
	<CAJowKgJK9zBkVAM1NyOsjU04gvwV3zGnk+1ebfpt6rnbiKy6Og@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Tue, 30 May 2017 15:27:58 +0200
Message-ID: <CABm2gDpet31gEcBY6NTxEG+xA4rvg8_c79L+J=mJySGbf7Ydbg@mail.gmail.com>
To: Erik Aronesty <erik@q32.com>
Content-Type: text/plain; charset="UTF-8"
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148
Precedence: list

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
>