Mark Friedenbach [ARCHIVE] on Nostr: 📅 Original date posted:2017-05-30 📝 Original message:The 1MB classic block size ...
📅 Original date posted:2017-05-30
📝 Original message: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ón via bitcoin-dev
<bitcoin-dev at 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 at 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 at 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 at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
📝 Original message: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ón via bitcoin-dev
<bitcoin-dev at 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 at 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 at 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 at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev