馃搮 Original date posted:2017-04-01
馃摑 Original message:On Sat, Apr 1, 2017 at 3:15 PM, Natanael <natanael.l at gmail.com> wrote:
>
>
> Den 1 apr. 2017 14:33 skrev "Jorge Tim贸n via bitcoin-dev"
> <bitcoin-dev at lists.linuxfoundation.org>:
>
> Segwit replaces the 1 mb size limit with a weight limit of 4 mb.
>
>
> That would make it a hardfork, not a softfork, if done exactly as you say.
>
> Segwit only separates out signature data. The 1 MB limit remains, but would
> now only cover the contents of the transaction scripts. With segwit that
> means we have two (2) size limits, not one. This is important to remember.
> Even with segwit + MAST for large complex scripts, there's still going to be
> a very low limit to the total number of possible transactions per block. And
> not all transactions will get the same space savings.
No, because of the way the weight is calculated, it is impossible to
create a block that old nodes would perceive as bigger than 1 mb
without also violating the weight limit.
After segwit activation, nodes supporting segwit don't need to
validate the 1 mb size limit anymore as long as they validate the
weight limit. The weight is also the only notion of cost miners need
to consider when comparing txs by feerate (fee per cost, before segwit
tx_fee/tx_size, post-segwit tx_fee/tx_weight).
This is important to remember, because having 2 separated limits or
costs would make block creation and relay policies much harder to
implement.
Therefore a hardfork after segwit can just increase the weight limit
and completely forget about the pre-segwit 1 mb size limit.
Jorge Tim贸n [ARCHIVE] /
npub1fx鈥l2d8
2023-06-07 17:58:49
in reply to nevent1q鈥sjk
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8Published at
2023-06-07 17:58:49Event JSON
{
"id": "e1ff2ae08b4a7e790c8a051a4f99b94be5cecef2183b586ce529847287302439",
"pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84",
"created_at": 1686160729,
"kind": 1,
"tags": [
[
"e",
"7011ea91d13433b27ca999be38e11becd970479a19a12ca22f4ebc2ec0d1700f",
"",
"root"
],
[
"e",
"fc25c1625969c5962db24d88a5db10d1c180239f94af0cdea132f5e80d989ddc",
"",
"reply"
],
[
"p",
"f14f3c71a4e63a12c842e4a50471263ada4b6cfde093fcb6588693a726b9b018"
]
],
"content": "馃搮 Original date posted:2017-04-01\n馃摑 Original message:On Sat, Apr 1, 2017 at 3:15 PM, Natanael \u003cnatanael.l at gmail.com\u003e wrote:\n\u003e\n\u003e\n\u003e Den 1 apr. 2017 14:33 skrev \"Jorge Tim贸n via bitcoin-dev\"\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e:\n\u003e\n\u003e Segwit replaces the 1 mb size limit with a weight limit of 4 mb.\n\u003e\n\u003e\n\u003e That would make it a hardfork, not a softfork, if done exactly as you say.\n\u003e\n\u003e Segwit only separates out signature data. The 1 MB limit remains, but would\n\u003e now only cover the contents of the transaction scripts. With segwit that\n\u003e means we have two (2) size limits, not one. This is important to remember.\n\u003e Even with segwit + MAST for large complex scripts, there's still going to be\n\u003e a very low limit to the total number of possible transactions per block. And\n\u003e not all transactions will get the same space savings.\n\nNo, because of the way the weight is calculated, it is impossible to\ncreate a block that old nodes would perceive as bigger than 1 mb\nwithout also violating the weight limit.\nAfter segwit activation, nodes supporting segwit don't need to\nvalidate the 1 mb size limit anymore as long as they validate the\nweight limit. The weight is also the only notion of cost miners need\nto consider when comparing txs by feerate (fee per cost, before segwit\ntx_fee/tx_size, post-segwit tx_fee/tx_weight).\nThis is important to remember, because having 2 separated limits or\ncosts would make block creation and relay policies much harder to\nimplement.\n\nTherefore a hardfork after segwit can just increase the weight limit\nand completely forget about the pre-segwit 1 mb size limit.",
"sig": "3282be066f311522627c7589ab67b1ad8660d6ea628a4c14a8fc3bbf0abbe31307c119e3d5dc75a652ef7a5f9c6b5c097185096d9ed827e40801226a69c90481"
}