ð
Original date posted:2017-05-09
ð Original message:Let n be the non-segwit bytes. Let the seg/noseg ratio be 1.7.
Segwit with 75% discount: (let WITNESS_SCALE_FACTOR=4)
n*WITNESS_SCALE_FACTOR+n*1.7 = 4,000,000
Then n=4,000,000 / 5.7 = 701K
Average block size = 701K*(1+1.7)=1.8 Mbytes
Maximum block size = 4 MBytes
Segwit with 50% discount + 2MB HF: (let WITNESS_SCALE_FACTOR=2)
n*2+n*1.7 = 4,000,000
n = 4,000,000/ 3.7 = 1.08M
Average block size = 1.08M*(1+1.7)=2.9 Mbytes
Maximum block size = 4 MBytes
The capacity of Segwit(50%)+2MbHF is 50% more than Segwit, and the maximum
block size is the same.
On Tue, May 9, 2017 at 3:58 PM, Sergio Demian Lerner <
sergio.d.lerner at gmail.com> wrote:
>
>>
>> You suggested "If the maximum block weight is set to 2.7M, each byte of
>> non-witness block costs 1.7", but these numbers dont work out - setting
>> the discount to 1.7 gets you a maximum block size of 1.7MB (in a soft
>> fork), not 2.7MB.
>
>
> Yes. In a soft-fork is true.
> I was thinking about what a HF could do to optimize the balance, and I
> forgot I was in the context of a SF.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170509/4a3d4465/attachment-0001.html>;
Sergio Demian Lerner [ARCHIVE] /
npub1fvâŠ3vq7f
2023-06-07 18:00:59
in reply to nevent1qâŠ3gy6
Author Public Key
npub1fvuxqdqg7klqqgy3yy8gdxjv4phu92sll5y8zqm2qe5qdrhxymhqf3vq7fPublished at
2023-06-07 18:00:59Event JSON
{
"id": "2f3358b4a24197f529563f9eebd88ac186a2af31f542a8184d0509a1c0539c8f",
"pubkey": "4b38603408f5be002091210e869a4ca86fc2aa1ffd0871036a0668068ee626ee",
"created_at": 1686160859,
"kind": 1,
"tags": [
[
"e",
"4aacc31e765e9e31a3d8eb41d296ff5dc213462528e2e5335cec5ccb80e70465",
"",
"root"
],
[
"e",
"74589f1d76423c094b1532bc2aa384876c083bedc449a4bb58046b02d38d598f",
"",
"reply"
],
[
"p",
"4b38603408f5be002091210e869a4ca86fc2aa1ffd0871036a0668068ee626ee"
]
],
"content": "ð
Original date posted:2017-05-09\nð Original message:Let n be the non-segwit bytes. Let the seg/noseg ratio be 1.7.\n\nSegwit with 75% discount: (let WITNESS_SCALE_FACTOR=4)\nn*WITNESS_SCALE_FACTOR+n*1.7 = 4,000,000\nThen n=4,000,000 / 5.7 = 701K\nAverage block size = 701K*(1+1.7)=1.8 Mbytes\nMaximum block size = 4 MBytes\n\nSegwit with 50% discount + 2MB HF: (let WITNESS_SCALE_FACTOR=2)\nn*2+n*1.7 = 4,000,000\nn = 4,000,000/ 3.7 = 1.08M\nAverage block size = 1.08M*(1+1.7)=2.9 Mbytes\nMaximum block size = 4 MBytes\n\nThe capacity of Segwit(50%)+2MbHF is 50% more than Segwit, and the maximum\nblock size is the same.\n\n\nOn Tue, May 9, 2017 at 3:58 PM, Sergio Demian Lerner \u003c\nsergio.d.lerner at gmail.com\u003e wrote:\n\n\u003e\n\u003e\u003e\n\u003e\u003e You suggested \"If the maximum block weight is set to 2.7M, each byte of\n\u003e\u003e non-witness block costs 1.7\", but these numbers dont work out - setting\n\u003e\u003e the discount to 1.7 gets you a maximum block size of 1.7MB (in a soft\n\u003e\u003e fork), not 2.7MB.\n\u003e\n\u003e\n\u003e Yes. In a soft-fork is true.\n\u003e I was thinking about what a HF could do to optimize the balance, and I\n\u003e forgot I was in the context of a SF.\n\u003e\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170509/4a3d4465/attachment-0001.html\u003e",
"sig": "5de1b0f997a50d4ac889db219c7ca578e4554d581e5c32f763a72b0eb15e84fd8c7181f41225530274a9a83b928fe3465f18a53309b20fc4102695eb5ed53e1a"
}