Jorge Tim贸n [ARCHIVE] on Nostr: 馃搮 Original date posted:2017-05-30 馃摑 Original message:My understanding is that ...
馃搮 Original date posted:2017-05-30
馃摑 Original message: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 [size4]
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 [size1]
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=MAX_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 at friedenbach.org> wrote:
> 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: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 [size4]
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 [size1]
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=MAX_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 at friedenbach.org> wrote:
> 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