* [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148 @ 2017-05-23 20:23 Luke Dashjr 2017-05-23 23:07 ` Erik Aronesty 0 siblings, 1 reply; 13+ messages in thread From: Luke Dashjr @ 2017-05-23 20:23 UTC (permalink / raw) To: Bitcoin Dev 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148 2017-05-23 20:23 [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148 Luke Dashjr @ 2017-05-23 23:07 ` Erik Aronesty 2017-05-30 13:27 ` Jorge Timón 0 siblings, 1 reply; 13+ messages in thread From: Erik Aronesty @ 2017-05-23 23:07 UTC (permalink / raw) To: Luke Dashjr; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3673 bytes --] 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 > [-- Attachment #2: Type: text/html, Size: 4512 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148 2017-05-23 23:07 ` Erik Aronesty @ 2017-05-30 13:27 ` Jorge Timón 2017-05-30 20:10 ` Jacob Eliosoff 2017-05-30 21:24 ` Mark Friedenbach 0 siblings, 2 replies; 13+ messages in thread From: Jorge Timón @ 2017-05-30 13:27 UTC (permalink / raw) To: Erik Aronesty; +Cc: Bitcoin Dev 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 > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148 2017-05-30 13:27 ` Jorge Timón @ 2017-05-30 20:10 ` Jacob Eliosoff 2017-05-30 21:24 ` Mark Friedenbach 1 sibling, 0 replies; 13+ messages in thread From: Jacob Eliosoff @ 2017-05-30 20:10 UTC (permalink / raw) To: Jorge Timón; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148 2017-05-30 13:27 ` Jorge Timón 2017-05-30 20:10 ` Jacob Eliosoff @ 2017-05-30 21:24 ` Mark Friedenbach 2017-05-30 22:26 ` Jorge Timón 2017-05-30 23:50 ` James MacWhyte 1 sibling, 2 replies; 13+ messages in thread From: Mark Friedenbach @ 2017-05-30 21:24 UTC (permalink / raw) To: Jorge Timón; +Cc: Bitcoin Dev 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@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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148 2017-05-30 21:24 ` Mark Friedenbach @ 2017-05-30 22:26 ` Jorge Timón 2017-05-30 23:50 ` James MacWhyte 1 sibling, 0 replies; 13+ messages in thread From: Jorge Timón @ 2017-05-30 22:26 UTC (permalink / raw) To: Mark Friedenbach; +Cc: Bitcoin Dev 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@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@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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148 2017-05-30 21:24 ` Mark Friedenbach 2017-05-30 22:26 ` Jorge Timón @ 2017-05-30 23:50 ` James MacWhyte 2017-05-31 1:09 ` Jean-Paul Kogelman 2017-05-31 1:22 ` Jorge Timón 1 sibling, 2 replies; 13+ messages in thread From: James MacWhyte @ 2017-05-30 23:50 UTC (permalink / raw) To: Mark Friedenbach, Jorge Timón; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 215 bytes --] > The 1MB classic block size prevents quadratic hashing > problems from being any worse than they are today. > > Add a transaction-size limit of, say, 10kb and the quadratic hashing problem is a non-issue. Donezo. [-- Attachment #2: Type: text/html, Size: 431 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148 2017-05-30 23:50 ` James MacWhyte @ 2017-05-31 1:09 ` Jean-Paul Kogelman 2017-05-31 3:07 ` Jacob Eliosoff 2017-05-31 1:22 ` Jorge Timón 1 sibling, 1 reply; 13+ messages in thread From: Jean-Paul Kogelman @ 2017-05-31 1:09 UTC (permalink / raw) To: James MacWhyte; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 672 bytes --] That would invalidate any pre-signed transactions that are currently out there. You can't just change the rules out from under people. > On May 30, 2017, at 4:50 PM, James MacWhyte via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > > >> The 1MB classic block size prevents quadratic hashing >> problems from being any worse than they are today. >> > > Add a transaction-size limit of, say, 10kb and the quadratic hashing problem is a non-issue. Donezo. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 1371 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148 2017-05-31 1:09 ` Jean-Paul Kogelman @ 2017-05-31 3:07 ` Jacob Eliosoff 2017-06-02 19:40 ` Jared Lee Richardson 0 siblings, 1 reply; 13+ messages in thread From: Jacob Eliosoff @ 2017-05-31 3:07 UTC (permalink / raw) To: Jean-Paul Kogelman; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1313 bytes --] Maybe there's some hole in Jorge's logic and scrapping blockmaxsize has quadratic hashing risks, and maybe James' 10KB is too ambitious; but even if so, a simple 1MB tx size limit would clearly do the trick. The broader point is that quadratic hashing is not a compelling reason to keep blockmaxsize post-HF: does someone have a better one? On May 30, 2017 9:46 PM, "Jean-Paul Kogelman via bitcoin-dev" < bitcoin-dev@lists•linuxfoundation.org> wrote: > That would invalidate any pre-signed transactions that are currently out > there. You can't just change the rules out from under people. > > > On May 30, 2017, at 4:50 PM, James MacWhyte via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > > > >> The 1MB classic block size prevents quadratic hashing >> problems from being any worse than they are today. >> >> > Add a transaction-size limit of, say, 10kb and the quadratic hashing > problem is a non-issue. Donezo. > > _______________________________________________ > 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: 2603 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148 2017-05-31 3:07 ` Jacob Eliosoff @ 2017-06-02 19:40 ` Jared Lee Richardson 2017-06-12 16:27 ` Nathan Cook 0 siblings, 1 reply; 13+ messages in thread From: Jared Lee Richardson @ 2017-06-02 19:40 UTC (permalink / raw) To: Jacob Eliosoff; +Cc: Bitcoin Dev > Maybe there's some hole in Jorge's logic and scrapping blockmaxsize has quadratic hashing risks, and maybe James' 10KB is too ambitious; but even if so, a simple 1MB tx size limit would clearly do the trick. The broader point is that quadratic hashing is not a compelling reason to keep blockmaxsize post-HF: does someone have a better one? I think this is exactly the right direction to head. There are arguments to be made for various maximum sizes... Maybe the limit could be set to 1mb initially, and at a distant future block height(years?) automatically drop to 500kb or 100kb? That would give anyone with existing systems or pre-signed transactions several years to adjust to the change. Notification could (?possibly?) be done with a non-default parameter that must be changed to continue to use 100kb - <1mb transactions, so no one running modern software could claim they were not informed when that future date hits. I don't see any real advantages to continuing to support transactions larger than 100kb excepting the need to update legacy use cases / already signed transactions. On Tue, May 30, 2017 at 8:07 PM, Jacob Eliosoff via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > Maybe there's some hole in Jorge's logic and scrapping blockmaxsize has > quadratic hashing risks, and maybe James' 10KB is too ambitious; but even if > so, a simple 1MB tx size limit would clearly do the trick. The broader > point is that quadratic hashing is not a compelling reason to keep > blockmaxsize post-HF: does someone have a better one? > > > > On May 30, 2017 9:46 PM, "Jean-Paul Kogelman via bitcoin-dev" > <bitcoin-dev@lists•linuxfoundation.org> wrote: >> >> That would invalidate any pre-signed transactions that are currently out >> there. You can't just change the rules out from under people. >> >> >> On May 30, 2017, at 4:50 PM, James MacWhyte via bitcoin-dev >> <bitcoin-dev@lists•linuxfoundation.org> wrote: >> >> >>> >>> The 1MB classic block size prevents quadratic hashing >>> problems from being any worse than they are today. >>> >> >> Add a transaction-size limit of, say, 10kb and the quadratic hashing >> problem is a non-issue. Donezo. >> >> _______________________________________________ >> 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 > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148 2017-06-02 19:40 ` Jared Lee Richardson @ 2017-06-12 16:27 ` Nathan Cook 0 siblings, 0 replies; 13+ messages in thread From: Nathan Cook @ 2017-06-12 16:27 UTC (permalink / raw) To: Jared Lee Richardson; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 4391 bytes --] The problem with >100kb transactions isn't that there are a lot of already-signed transactions out there, or even that there are good use cases for them, but that such transactions and use cases could exist, and there is no way of disallowing them without possibly costing someone a lot of money. Slowly reducing the limit doesn't really solve this problem. I propose to make them hard enough to confirm that no-one will use them without a very good reason. Just require that any block containing an outsized transaction be mined at a greater difficulty – quadratically greater. Such a block is more expensive *for the block's miner*, not just for the other miners, or for other nodes. Anyone who really, really needs to use a 400kb transaction can pay a miner to mine it. Quadratic hashing isn't risky when it is inherently limited by a corresponding reduction in the rate at which the "bad" blocks can be generated. That said, there's nothing I can see which is actually good about large, expensive to validate transactions, and so >1MB transactions should remain invalid, as they are today. Nathan Cook On 2 June 2017 at 22:40, Jared Lee Richardson via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > > Maybe there's some hole in Jorge's logic and scrapping blockmaxsize has > quadratic hashing risks, and maybe James' 10KB is too ambitious; but even > if so, a simple 1MB tx size limit would clearly do the trick. The broader > point is that quadratic hashing is not a compelling reason to keep > blockmaxsize post-HF: does someone have a better one? > > I think this is exactly the right direction to head. There are > arguments to be made for various maximum sizes... Maybe the limit > could be set to 1mb initially, and at a distant future block > height(years?) automatically drop to 500kb or 100kb? That would give > anyone with existing systems or pre-signed transactions several years > to adjust to the change. Notification could (?possibly?) be done with > a non-default parameter that must be changed to continue to use 100kb > - <1mb transactions, so no one running modern software could claim > they were not informed when that future date hits. > > I don't see any real advantages to continuing to support transactions > larger than 100kb excepting the need to update legacy use cases / > already signed transactions. > > On Tue, May 30, 2017 at 8:07 PM, Jacob Eliosoff via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org> wrote: > > Maybe there's some hole in Jorge's logic and scrapping blockmaxsize has > > quadratic hashing risks, and maybe James' 10KB is too ambitious; but > even if > > so, a simple 1MB tx size limit would clearly do the trick. The broader > > point is that quadratic hashing is not a compelling reason to keep > > blockmaxsize post-HF: does someone have a better one? > > > > > > > > On May 30, 2017 9:46 PM, "Jean-Paul Kogelman via bitcoin-dev" > > <bitcoin-dev@lists•linuxfoundation.org> wrote: > >> > >> That would invalidate any pre-signed transactions that are currently out > >> there. You can't just change the rules out from under people. > >> > >> > >> On May 30, 2017, at 4:50 PM, James MacWhyte via bitcoin-dev > >> <bitcoin-dev@lists•linuxfoundation.org> wrote: > >> > >> > >>> > >>> The 1MB classic block size prevents quadratic hashing > >>> problems from being any worse than they are today. > >>> > >> > >> Add a transaction-size limit of, say, 10kb and the quadratic hashing > >> problem is a non-issue. Donezo. > >> > >> _______________________________________________ > >> 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 > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 6501 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148 2017-05-30 23:50 ` James MacWhyte 2017-05-31 1:09 ` Jean-Paul Kogelman @ 2017-05-31 1:22 ` Jorge Timón 2017-05-31 4:14 ` Luke Dashjr 1 sibling, 1 reply; 13+ messages in thread From: Jorge Timón @ 2017-05-31 1:22 UTC (permalink / raw) To: James MacWhyte; +Cc: Bitcoin Dev On Wed, May 31, 2017 at 1:50 AM, James MacWhyte <macwhyte@gmail•com> wrote: > >> >> The 1MB classic block size prevents quadratic hashing >> problems from being any worse than they are today. >> > > Add a transaction-size limit of, say, 10kb and the quadratic hashing problem > is a non-issue. Donezo. Why is it https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1661 not enough at this point? Why the need for a transaction size limit? ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148 2017-05-31 1:22 ` Jorge Timón @ 2017-05-31 4:14 ` Luke Dashjr 0 siblings, 0 replies; 13+ messages in thread From: Luke Dashjr @ 2017-05-31 4:14 UTC (permalink / raw) To: bitcoin-dev, Jorge Timón On Wednesday 31 May 2017 1:22:44 AM Jorge Timón via bitcoin-dev wrote: > Why is it > https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1661 > not enough at this point? > Why the need for a transaction size limit? Because the bottleneck is hashing the transaction, which costs (in CPU time) based on its size. Maybe it would make sense to factor sigops into the limit, though? On Wednesday 31 May 2017 1:09:26 AM Jean-Paul Kogelman via bitcoin-dev wrote: > On May 30, 2017, at 4:50 PM, James MacWhyte wrote: > > Add a transaction-size limit of, say, 10kb and the quadratic hashing > > problem is a non-issue. Donezo. > > That would invalidate any pre-signed transactions that are currently out > there. You can't just change the rules out from under people. Make it 100kB and I think we'd be okay. Those have always been policy- forbidden so there should be no expectation they'd be acceptable in the future. While we're at it, I suggest also specifying a minimum transaction size as well. The raw minimum possible is 60 bytes, but any sane output would need at least a hash, so I'd say make the minimum be 8 (60 + 160-bit hash) bytes? Luke ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2017-06-12 16:27 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-05-23 20:23 [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148 Luke Dashjr 2017-05-23 23:07 ` Erik Aronesty 2017-05-30 13:27 ` Jorge Timón 2017-05-30 20:10 ` Jacob Eliosoff 2017-05-30 21:24 ` Mark Friedenbach 2017-05-30 22:26 ` Jorge Timón 2017-05-30 23:50 ` James MacWhyte 2017-05-31 1:09 ` Jean-Paul Kogelman 2017-05-31 3:07 ` Jacob Eliosoff 2017-06-02 19:40 ` Jared Lee Richardson 2017-06-12 16:27 ` Nathan Cook 2017-05-31 1:22 ` Jorge Timón 2017-05-31 4:14 ` Luke Dashjr
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox