📅 Original date posted:2017-05-30
📝 Original message: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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170530/060fafbb/attachment.html>;
Jacob Eliosoff [ARCHIVE] /
npub1ml…4yf8d
2023-06-07 18:01:48
in reply to nevent1q…8qpe
Author Public Key
npub1mlpmsc5sm93tw2fp2dhhuwmxcqm59wz6hjg5g3afq5rucfll3f9sh4yf8dPublished at
2023-06-07 18:01:48Event JSON
{
"id": "09b9d4397cea5287f3b939993d4b0386d12a656c6cb128d5df70086637058eb8",
"pubkey": "dfc3b86290d962b72921536f7e3b66c03742b85abc914447a90507cc27ff8a4b",
"created_at": 1686160908,
"kind": 1,
"tags": [
[
"e",
"73fcf5be84fca4568a5398ecee91a18c841c9abc02915b258aa02af58b0a4b4a",
"",
"root"
],
[
"e",
"7d6b58646a319163c2b89a9f7f3ba702a3d24c5df922c52102296e7910bd389c",
"",
"reply"
],
[
"p",
"498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84"
]
],
"content": "📅 Original date posted:2017-05-30\n📝 Original message:I'd like to know this too. Is it just that a 4MB blockmaxweight would\ntheoretically allow ~4MB blocks (if ~all witness data), which is too big?\nOr is there a more subtle reason we still need blockmaxsize after a HF?\n\n\nOn May 30, 2017 9:28 AM, \"Jorge Timón via bitcoin-dev\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\nWhy not simply remove the (redundant after sw activation) 1 mb size\nlimit check and increasing the weight limit without changing the\ndiscount or having 2 limits?\n\n\nOn Wed, May 24, 2017 at 1:07 AM, Erik Aronesty via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e Personally, I would prefer if a 2MB lock-in that uses BIP103 for the\ntiming.\n\u003e\n\u003e I think up to 20% per year can be absorbed by averages in\nbandwidth/CPU/RAM\n\u003e growth, of which bandwidth seems the most constraining.\n\u003e\n\u003e - Erik\n\u003e\n\u003e\n\u003e On Tue, May 23, 2017 at 4:23 PM, Luke Dashjr via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e In light of some recent discussions, I wrote up this BIP for a real 2 MB\n\u003e\u003e block\n\u003e\u003e size hardfork following Segwit BIP148 activation. This is not part of any\n\u003e\u003e agreement I am party to, nor anything of that sort. Just something to\n\u003e\u003e throw\n\u003e\u003e out there as a possible (and realistic) option.\n\u003e\u003e\n\u003e\u003e Note that I cannot recommend this to be adopted, since frankly 1 MB\nblocks\n\u003e\u003e really are still too large, and this blunt-style hardfork quite risky\neven\n\u003e\u003e with consensus. But if the community wishes to adopt (by unanimous\n\u003e\u003e consensus)\n\u003e\u003e a 2 MB block size hardfork, this is probably the best way to do it right\n\u003e\u003e now.\n\u003e\u003e The only possible way to improve on this IMO would be to integrate it\ninto\n\u003e\u003e MMHF/\"spoonnet\" style hardfork (and/or add other unrelated-to-block-size\n\u003e\u003e HF\n\u003e\u003e improvements).\n\u003e\u003e\n\u003e\u003e I have left Author blank, as I do not intend to personally champion this.\n\u003e\u003e Before it may be assigned a BIP number, someone else will need to step up\n\u003e\u003e to\n\u003e\u003e take on that role. Motivation and Rationale are blank because I do not\n\u003e\u003e personally think there is any legitimate rationale for such a hardfork at\n\u003e\u003e this\n\u003e\u003e time; if someone adopts this BIP, they should complete these sections. (I\n\u003e\u003e can\n\u003e\u003e push a git branch with the BIP text if someone wants to fork it.)\n\u003e\u003e\n\u003e\u003e \u003cpre\u003e\n\u003e\u003e BIP: ?\n\u003e\u003e Layer: Consensus (hard fork)\n\u003e\u003e Title: Post-segwit 2 MB block size hardfork\n\u003e\u003e Author: FIXME\n\u003e\u003e Comments-Summary: No comments yet.\n\u003e\u003e Comments-URI: ?\n\u003e\u003e Status: Draft\n\u003e\u003e Type: Standards Track\n\u003e\u003e Created: 2017-05-22\n\u003e\u003e License: BSD-2-Clause\n\u003e\u003e \u003c/pre\u003e\n\u003e\u003e\n\u003e\u003e ==Abstract==\n\u003e\u003e\n\u003e\u003e Legacy Bitcoin transactions are given the witness discount, and a block\n\u003e\u003e size\n\u003e\u003e limit of 2 MB is imposed.\n\u003e\u003e\n\u003e\u003e ==Copyright==\n\u003e\u003e\n\u003e\u003e This BIP is licensed under the BSD 2-clause license.\n\u003e\u003e\n\u003e\u003e ==Specification==\n\u003e\u003e\n\u003e\u003e Upon activation, a block size limit of 2000000 bytes is enforced.\n\u003e\u003e The block weight limit remains at 4000000 WU.\n\u003e\u003e\n\u003e\u003e The calculation of block weight is modified:\n\u003e\u003e all witness data, including both scriptSig (used by pre-segwit inputs)\nand\n\u003e\u003e segwit witness data, is measured as 1 weight-unit (WU), while all other\n\u003e\u003e data\n\u003e\u003e in the block is measured as 4 WU.\n\u003e\u003e\n\u003e\u003e The witness commitment in the generation transaction is no longer\n\u003e\u003e required,\n\u003e\u003e and instead the txid merkle root in the block header is replaced with a\n\u003e\u003e hash\n\u003e\u003e of:\n\u003e\u003e\n\u003e\u003e 1. The witness reserved value.\n\u003e\u003e 2. The witness merkle root hash.\n\u003e\u003e 3. The transaction ID merkle root hash.\n\u003e\u003e\n\u003e\u003e The maximum size of a transaction stripped of witness data is limited to\n1\n\u003e\u003e MB.\n\u003e\u003e\n\u003e\u003e ===Deployment===\n\u003e\u003e\n\u003e\u003e This BIP is deployed by flag day, in the block where the median-past time\n\u003e\u003e surpasses 1543503872 (2018 Nov 29 at 15:04:32 UTC).\n\u003e\u003e\n\u003e\u003e It is assumed that when this flag day has been reached, Segwit has been\n\u003e\u003e activated via BIP141 and/or BIP148.\n\u003e\u003e\n\u003e\u003e ==Motivation==\n\u003e\u003e\n\u003e\u003e FIXME\n\u003e\u003e\n\u003e\u003e ==Rationale==\n\u003e\u003e\n\u003e\u003e FIXME\n\u003e\u003e\n\u003e\u003e ==Backwards compatibility==\n\u003e\u003e\n\u003e\u003e This is a hardfork, and as such not backward compatible.\n\u003e\u003e It should not be deployed without consent of the entire Bitcoin\ncommunity.\n\u003e\u003e Activation is scheduled for 18 months from the creation date of this BIP,\n\u003e\u003e intended to give 6 months to establish consensus, and 12 months for\n\u003e\u003e deployment.\n\u003e\u003e\n\u003e\u003e ==Reference implementation==\n\u003e\u003e\n\u003e\u003e FIXME\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n_______________________________________________\nbitcoin-dev mailing list\nbitcoin-dev at lists.linuxfoundation.org\nhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170530/060fafbb/attachment.html\u003e",
"sig": "0e7d5ad67a4b9af12d624c2393bdd5db392b0a2aead4ed3c78c9754795a84084c370867b7306283c88584145f978b3da689f18b1168845ba2a1f3dc1dee68d17"
}