Why not simply remove the (redundant after sw activation) 1 mb sizelimit check and increasing the weight limit without changing thediscount or having 2 limits?

On Wed, May 24, 2017 at 1:07 AM, Erik Aronesty via bitcoin-dev

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/RAMgrowth, of which bandwidth seems the most constraining.- ErikOn Tue, May 23, 2017 at 4:23 PM, Luke Dashjr via bitcoin-dev

In light of some recent discussions, I wrote up this BIP for a real 2 MBblocksize hardfork following Segwit BIP148 activation. This is not part of anyagreement I am party to, nor anything of that sort. Just something tothrowout there as a possible (and realistic) option.Note that I cannot recommend this to be adopted, since frankly 1 MB blocksreally are still too large, and this blunt-style hardfork quite risky evenwith consensus. But if the community wishes to adopt (by unanimousconsensus)a 2 MB block size hardfork, this is probably the best way to do it rightnow.The only possible way to improve on this IMO would be to integrate it intoMMHF/"spoonnet" style hardfork (and/or add other unrelated-to-block-sizeHFimprovements).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 uptotake on that role. Motivation and Rationale are blank because I do notpersonally think there is any legitimate rationale for such a hardfork atthistime; if someone adopts this BIP, they should complete these sections. (Icanpush 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 hardforkAuthor: FIXMEComments-Summary: No comments yet.Comments-URI: ?Status: DraftType: Standards TrackCreated: 2017-05-22License: BSD-2-Clause</pre>==Abstract==Legacy Bitcoin transactions are given the witness discount, and a blocksizelimit 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.all witness data, including both scriptSig (used by pre-segwit inputs) andsegwit witness data, is measured as 1 weight-unit (WU), while all otherdatain the block is measured as 4 WU.The witness commitment in the generation transaction is no longerrequired,and instead the txid merkle root in the block header is replaced with ahash1. 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 1MB.===Deployment===This BIP is deployed by flag day, in the block where the median-past timesurpasses 1543503872 (2018 Nov 29 at 15:04:32 UTC).It is assumed that when this flag day has been reached, Segwit has beenactivated 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 fordeployment.==Reference implementation==FIXME_______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

I'd like to know this too. Is it just that a 4MB blockmaxweight wouldtheoretically 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?

Why not simply remove the (redundant after sw activation) 1 mb sizelimit check and increasing the weight limit without changing thediscount or having 2 limits?

On Wed, May 24, 2017 at 1:07 AM, Erik Aronesty via bitcoin-dev

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.- ErikOn Tue, May 23, 2017 at 4:23 PM, Luke Dashjr via bitcoin-dev

In light of some recent discussions, I wrote up this BIP for a real 2 MBblocksize hardfork following Segwit BIP148 activation. This is not part of anyagreement I am party to, nor anything of that sort. Just something tothrowout there as a possible (and realistic) option.Note that I cannot recommend this to be adopted, since frankly 1 MB blocksreally are still too large, and this blunt-style hardfork quite risky evenwith consensus. But if the community wishes to adopt (by unanimousconsensus)a 2 MB block size hardfork, this is probably the best way to do it rightnow.The only possible way to improve on this IMO would be to integrate it intoMMHF/"spoonnet" style hardfork (and/or add other unrelated-to-block-sizeHFimprovements).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 uptotake on that role. Motivation and Rationale are blank because I do notpersonally think there is any legitimate rationale for such a hardfork atthistime; if someone adopts this BIP, they should complete these sections. (Icanpush 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 hardforkAuthor: FIXMEComments-Summary: No comments yet.Comments-URI: ?Status: DraftType: Standards TrackCreated: 2017-05-22License: BSD-2-Clause</pre>==Abstract==Legacy Bitcoin transactions are given the witness discount, and a blocksizelimit 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.all witness data, including both scriptSig (used by pre-segwit inputs) andsegwit witness data, is measured as 1 weight-unit (WU), while all otherdatain the block is measured as 4 WU.The witness commitment in the generation transaction is no longerrequired,and instead the txid merkle root in the block header is replaced with ahash1. 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 1MB.===Deployment===This BIP is deployed by flag day, in the block where the median-past timesurpasses 1543503872 (2018 Nov 29 at 15:04:32 UTC).It is assumed that when this flag day has been reached, Segwit has beenactivated 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 fordeployment.==Reference implementation==FIXME_______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

The 1MB classic block size is not redundant after segwit activation.Segwit prevents the quadratic hashing problems, but only for segwitoutputs. The 1MB classic block size prevents quadratic hashingproblems from being any worse than they are today.

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/RAMgrowth, of which bandwidth seems the most constraining.- ErikOn Tue, May 23, 2017 at 4:23 PM, Luke Dashjr via bitcoin-dev

In light of some recent discussions, I wrote up this BIP for a real 2 MBblocksize hardfork following Segwit BIP148 activation. This is not part of anyagreement I am party to, nor anything of that sort. Just something tothrowout there as a possible (and realistic) option.Note that I cannot recommend this to be adopted, since frankly 1 MB blocksreally are still too large, and this blunt-style hardfork quite risky evenwith consensus. But if the community wishes to adopt (by unanimousconsensus)a 2 MB block size hardfork, this is probably the best way to do it rightnow.The only possible way to improve on this IMO would be to integrate it intoMMHF/"spoonnet" style hardfork (and/or add other unrelated-to-block-sizeHFimprovements).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 uptotake on that role. Motivation and Rationale are blank because I do notpersonally think there is any legitimate rationale for such a hardfork atthistime; if someone adopts this BIP, they should complete these sections. (Icanpush 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 hardforkAuthor: FIXMEComments-Summary: No comments yet.Comments-URI: ?Status: DraftType: Standards TrackCreated: 2017-05-22License: BSD-2-Clause</pre>==Abstract==Legacy Bitcoin transactions are given the witness discount, and a blocksizelimit 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.all witness data, including both scriptSig (used by pre-segwit inputs) andsegwit witness data, is measured as 1 weight-unit (WU), while all otherdatain the block is measured as 4 WU.The witness commitment in the generation transaction is no longerrequired,and instead the txid merkle root in the block header is replaced with ahash1. 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 1MB.===Deployment===This BIP is deployed by flag day, in the block where the median-past timesurpasses 1543503872 (2018 Nov 29 at 15:04:32 UTC).It is assumed that when this flag day has been reached, Segwit has beenactivated 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 fordeployment.==Reference implementation==FIXME_______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

would have failed before due to excessive non-witness data.If I understood it correctly when I was explained, if I remembercorrectly, that last check is really just an optimization or aprotection against DoS invalid blocks. If the size without any witnessdata is bigger than 1/4 the max_weight, then the max_weight check iscertain to fail as well without having to look at any witness data atthat validation stage (assuming the failure is due to excessivenon-witness data).

I think you are not referring to the 1 mb size limit but to relatedone for sigops:

I believe the situation is similar in checking before knowing anythingabout 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 (andWITNESS_SCALE_FACTOR is used for the optimization case).

So what I would do in a hardfork after segwit activation would be tosimply equal MAX_BLOCK_BASE_SIZE=MAX_BLOCK_WEIGHT/WITNESS_SCALE_FACTORfor size1, and increase MAX_BLOCK_WEIGHT and MAX_BLOCK_ SIGOPS_COSTproportionally for size4 and sigops4 respectively (well, the sigopsconst for sigops1 as well).

If I understood segwit correctly, I believe that even though it is notactivated yet, you could remove both the size1 and sigops1 checks andyour node would still not accept invalid blocks by pre-bip141 rules,your node would just spend more time on invalid blocks due tocurrently excessive size/sigops, because it would only realize at alater validation stage. Sorry for the redundancy about the validationstage.

But it is not unlikely that I'm missing something. If I am wrong aboutthis I am spreading misinformation about segwit in several channels,so I'm very interested in corrections to my statements in this mail.

Post by Mark Friedenbach via bitcoin-devThe 1MB classic block size is not redundant after segwit activation.Segwit prevents the quadratic hashing problems, but only for segwitoutputs. The 1MB classic block size prevents quadratic hashingproblems from being any worse than they are today.MarkOn Tue, May 30, 2017 at 6:27 AM, Jorge Timón via bitcoin-dev

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/RAMgrowth, of which bandwidth seems the most constraining.- ErikOn Tue, May 23, 2017 at 4:23 PM, Luke Dashjr via bitcoin-dev

In light of some recent discussions, I wrote up this BIP for a real 2 MBblocksize hardfork following Segwit BIP148 activation. This is not part of anyagreement I am party to, nor anything of that sort. Just something tothrowout there as a possible (and realistic) option.Note that I cannot recommend this to be adopted, since frankly 1 MB blocksreally are still too large, and this blunt-style hardfork quite risky evenwith consensus. But if the community wishes to adopt (by unanimousconsensus)a 2 MB block size hardfork, this is probably the best way to do it rightnow.The only possible way to improve on this IMO would be to integrate it intoMMHF/"spoonnet" style hardfork (and/or add other unrelated-to-block-sizeHFimprovements).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 uptotake on that role. Motivation and Rationale are blank because I do notpersonally think there is any legitimate rationale for such a hardfork atthistime; if someone adopts this BIP, they should complete these sections. (Icanpush 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 hardforkAuthor: FIXMEComments-Summary: No comments yet.Comments-URI: ?Status: DraftType: Standards TrackCreated: 2017-05-22License: BSD-2-Clause</pre>==Abstract==Legacy Bitcoin transactions are given the witness discount, and a blocksizelimit 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.all witness data, including both scriptSig (used by pre-segwit inputs) andsegwit witness data, is measured as 1 weight-unit (WU), while all otherdatain the block is measured as 4 WU.The witness commitment in the generation transaction is no longerrequired,and instead the txid merkle root in the block header is replaced with ahash1. 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 1MB.===Deployment===This BIP is deployed by flag day, in the block where the median-past timesurpasses 1543503872 (2018 Nov 29 at 15:04:32 UTC).It is assumed that when this flag day has been reached, Segwit has beenactivated 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 fordeployment.==Reference implementation==FIXME_______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

That would invalidate any pre-signed transactions that are currently outthere. 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 thefuture.

While we're at it, I suggest also specifying a minimum transaction size aswell. The raw minimum possible is 60 bytes, but any sane output would need atleast a hash, so I'd say make the minimum be 8 (60 + 160-bit hash) bytes?

Maybe there's some hole in Jorge's logic and scrapping blockmaxsize hasquadratic hashing risks, and maybe James' 10KB is too ambitious; but evenif so, a simple 1MB tx size limit would clearly do the trick. The broaderpoint is that quadratic hashing is not a compelling reason to keepblockmaxsize post-HF: does someone have a better one?

On May 30, 2017 9:46 PM, "Jean-Paul Kogelman via bitcoin-dev" <

Post by Jean-Paul Kogelman via bitcoin-devThat would invalidate any pre-signed transactions that are currently outthere. You can't just change the rules out from under people.On May 30, 2017, at 4:50 PM, James MacWhyte via 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 arearguments to be made for various maximum sizes... Maybe the limitcould be set to 1mb initially, and at a distant future blockheight(years?) automatically drop to 500kb or 100kb? That would giveanyone with existing systems or pre-signed transactions several yearsto adjust to the change. Notification could (?possibly?) be done witha non-default parameter that must be changed to continue to use 100kb- <1mb transactions, so no one running modern software could claimthey were not informed when that future date hits.

I don't see any real advantages to continuing to support transactionslarger 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

Maybe there's some hole in Jorge's logic and scrapping blockmaxsize hasquadratic hashing risks, and maybe James' 10KB is too ambitious; but even ifso, a simple 1MB tx size limit would clearly do the trick. The broaderpoint is that quadratic hashing is not a compelling reason to keepblockmaxsize post-HF: does someone have a better one?On May 30, 2017 9:46 PM, "Jean-Paul Kogelman via bitcoin-dev"

Post by Jean-Paul Kogelman via bitcoin-devThat would invalidate any pre-signed transactions that are currently outthere. You can't just change the rules out from under people.On May 30, 2017, at 4:50 PM, James MacWhyte via bitcoin-dev

The problem with >100kb transactions isn't that there are a lot ofalready-signed transactions out there, or even that there are good usecases for them, but that such transactions and use cases could exist, andthere is no way of disallowing them without possibly costing someone a lotof 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 themwithout a very good reason. Just require that any block containing anoutsized transaction be mined at a greater difficulty â quadraticallygreater. Such a block is more expensive *for the block's miner*, not justfor the other miners, or for other nodes. Anyone who really, really needsto use a 400kb transaction can pay a miner to mine it.

Quadratic hashing isn't risky when it is inherently limited by acorresponding reduction in the rate at which the "bad" blocks can begenerated. That said, there's nothing I can see which is actually goodabout large, expensive to validate transactions, and so >1MB transactionsshould remain invalid, as they are today.

quadratic hashing risks, and maybe James' 10KB is too ambitious; but evenif so, a simple 1MB tx size limit would clearly do the trick. The broaderpoint is that quadratic hashing is not a compelling reason to keepblockmaxsize post-HF: does someone have a better one?I think this is exactly the right direction to head. There arearguments to be made for various maximum sizes... Maybe the limitcould be set to 1mb initially, and at a distant future blockheight(years?) automatically drop to 500kb or 100kb? That would giveanyone with existing systems or pre-signed transactions several yearsto adjust to the change. Notification could (?possibly?) be done witha non-default parameter that must be changed to continue to use 100kb- <1mb transactions, so no one running modern software could claimthey were not informed when that future date hits.I don't see any real advantages to continuing to support transactionslarger 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

Post by Jacob Eliosoff via bitcoin-devso, a simple 1MB tx size limit would clearly do the trick. The broaderpoint is that quadratic hashing is not a compelling reason to keepblockmaxsize post-HF: does someone have a better one?On May 30, 2017 9:46 PM, "Jean-Paul Kogelman via bitcoin-dev"

Post by Jean-Paul Kogelman via bitcoin-devThat would invalidate any pre-signed transactions that are currently outthere. You can't just change the rules out from under people.On May 30, 2017, at 4:50 PM, James MacWhyte via bitcoin-dev