📅 Original date posted:2015-12-08
📝 Original message:I am leaning towards supporting a can kick proposal. Features I think are desirable for this can kick:
0. Block size limit around 2 to 4 MB. Maybe 3 MB? Based on my testnet data, I think 3 MB should be pretty safe.
1. Hard fork with a consensus mechanisms similar to BIP101
2. Approximately 1 or 2 month delay before activation to allow for miners to upgrade their infrastructure.
3. Some form of validation cost metric. BIP101's validation cost metric would be the minimum strictness that I would support, but it would be nice if there were a good UTXO growth metric too. (I do not know enough about the different options to evaluate them right now.)
I will be working on a few improvements to block propagation (especially from China) over the next few months, like blocktorrent and stratum-based GFW penetration. I hope to have these working within a few months. Depending on how those efforts and others (e.g. IBLTs) go, we can look at increasing the block size further, and possibly enacting a long-term scaling roadmap like BIP101.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151208/75222ee6/attachment.sig>;
Jonathan Toomim [ARCHIVE] /
npub1pl…yj0hj
2023-06-07 17:45:53
in reply to nevent1q…unkp
Author Public Key
npub1pl6kcz00s7wgn6syh73dta0qm9sqpmtw4adv8rnm2w9fmynkw45sayj0hjPublished at
2023-06-07 17:45:53Event JSON
{
"id": "88eecbb4a7efb40248ac089f972340f441fce82b28d0f1001f804219af97e1d1",
"pubkey": "0ff56c09ef879c89ea04bfa2d5f5e0d96000ed6eaf5ac38e7b538a9d92767569",
"created_at": 1686159953,
"kind": 1,
"tags": [
[
"e",
"e31544c117c5dfa42d256a8263370e459dcacad96a18dd70a3072c9936b2aea0",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2015-12-08\n📝 Original message:I am leaning towards supporting a can kick proposal. Features I think are desirable for this can kick:\n\n0. Block size limit around 2 to 4 MB. Maybe 3 MB? Based on my testnet data, I think 3 MB should be pretty safe.\n1. Hard fork with a consensus mechanisms similar to BIP101\n2. Approximately 1 or 2 month delay before activation to allow for miners to upgrade their infrastructure.\n3. Some form of validation cost metric. BIP101's validation cost metric would be the minimum strictness that I would support, but it would be nice if there were a good UTXO growth metric too. (I do not know enough about the different options to evaluate them right now.)\n\nI will be working on a few improvements to block propagation (especially from China) over the next few months, like blocktorrent and stratum-based GFW penetration. I hope to have these working within a few months. Depending on how those efforts and others (e.g. IBLTs) go, we can look at increasing the block size further, and possibly enacting a long-term scaling roadmap like BIP101.\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 496 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151208/75222ee6/attachment.sig\u003e",
"sig": "3debe362e5dc21823015bb63719193fb05b37a3f466314ccb6bce470bb3d7559eef27899ab8c4c1e585246aec153b85c7103f3f17fc4c906f1f085d9ab2d3e2e"
}