📅 Original date posted:2016-02-09
📝 Original message:I believe i've seen Luke say this several times before, but there are
several more things that the majority of the devs agree should be in
bitcoin.
I would suggest to compile that list for your stage 3, so that you can have
an hardfork that fixes most of those things, and there should be some
repository with those changes deployed.
2016-02-09 14:16 GMT+00:00 jl2012--- via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> I would like to present a 2-3 year roadmap to a better header format and
> bigger block size
>
> Objectives:
>
> 1. Multistage rule changes to make sure everyone will have enough time to
> upgrade
> 2. Make mining easier, without breaking existing mining hardware and the
> Stratum protocol
> 3. Make future hardfork less disruptive (with Luke-Jr's proposal)
>
> Stage 1 is Segregated Witness (BIP141), which will not break any existing
> full or light nodes. This may happen in Q2-Q3 2016
>
> Stage 2 is fixes that will break existing full nodes, but not light nodes:
> a. Increase the MAX_BLOCK_SIZE (the exact value is not suggested in this
> roadmap), potentially change the witness discount
> b. Anti-DoS rules for the O(n^2) validation of non-segwit scripts
> c. (optional) Move segwit's commitments to the header Merkle tree. This is
> optional at this stage as it will be fixed in Stage 3 anyway
> This may happen in Q1-Q2 2017
>
> Stage 3 is fixes that will break all existing full nodes and light nodes:
> a. Full nodes upgraded to Stage 2 will not need to upgrade again, as the
> rules and activation logic should be included already
> b. Change the header format to Luke-Jr's proposal, and move all commitments
> (tx, witness, etc) to the new structure. All existing mining hardware with
> Stratum protocol should work.
> c. Reclaiming unused bits in header for mining. All existing mining chips
> should still work. Newly designed chips should be ready for the new rule.
> d. Fix the time warp attack
> This may happen in 2018 to 2019
>
> Pros:
> a. Light nodes (usually less tech-savvy users) will have longer time to
> upgrade
> b. The stage 2 is opt-in for full nodes.
> c. The stage 3 is opt-in for light nodes.
>
> Cons:
> a. The stage 2 is not opt-in for light nodes. They will blindly follow the
> longest chain which they might actually don't want to
> b. Non-upgraded full nodes will follow the old chain at Stage 2, which is
> likely to have lower value.
> c. Non-upgraded light nodes will follow the old chain at Stage 3, which is
> likely to have lower value. (However, this is not a concern as no one
> should
> be mining on the old chain at that time)
>
> -------------------------------
> An alternative roadmap would be:
>
> Stage 2 is fixes that will break existing full nodes and light nodes.
> However, they will not follow the minority chain
> a. Increase the MAX_BLOCK_SIZE, potentially change the witness discount
> b. Anti-DoS rules for the O(n^2) validation of non-segwit scripts
> c. Change the header format to Luke-Jr's proposal, and move all commitments
> (tx, witness, etc) to the new structure.
> This may happen in mid 2017 or later
>
> Stage 3 is fixes that will break all existing full nodes and light nodes.
> a. Full nodes and light nodes upgraded to Stage 2 will not need to upgrade
> again, as the rules and activation logic should be included already
> b. Reclaiming unused bits in header for mining. All existing mining chips
> should still work.
> c. Fix the time warp attack
> This may happen in 2018 to 2019
>
> Pros:
> a. The stage 2 and 3 are opt-in for everyone
> b. Even failing to upgrade, full nodes and light nodes won't follow the
> minority chain at stage 2
>
> Cons:
> a. Non-upgraded full/light nodes will follow the old chain at Stage 3,
> which
> is likely to have lower value. (However, this is not a concern as no one
> should be mining on the old chain at that time)
> b. It takes longer to implement stage 2 to give enough time for light node
> users to upgrade
>
> -------------------------------
>
> In terms of safety, the second proposal is better. In terms of disruption,
> the first proposal is less disruptive
>
> I would also like to emphasize that it is miners' responsibility, not the
> devs', to confirm that the supermajority of the community accept changes in
> Stage 2 and 3.
>
> Reference:
> Matt Corallo's proposal:
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012403.
> html
> Luke-Jr's proposal:
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012377.
> html
>
>
>
>
>
> _______________________________________________
> 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/20160209/8baa5e97/attachment-0001.html>;
Ricardo Filipe [ARCHIVE] /
npub14f…hksaj
2023-06-07 17:49:02
in reply to nevent1q…800g
Author Public Key
npub14fwd2yh320mh4ge46ute8ukdyx2kjxy2ak4a05prjwrtzlmh9rvq8hksajSeen on
wss://relay.noswhere.comPublished at
2023-06-07 17:49:02Event JSON
{
"id": "e0b181f5de047dda7c4050bf8978e3674adb1f9a313915edfa9117a77f17391d",
"pubkey": "aa5cd512f153f77aa335d71793f2cd219569188aedabd7d0239386b17f7728d8",
"created_at": 1686160142,
"kind": 1,
"tags": [
[
"e",
"869e2a0a3ffc6930e3a7215c092a59e1a7fe633ff747428c2e40cb2fadb4766c",
"",
"root"
],
[
"e",
"ad6bf3f132447f0f7c7d984eaa7c5a3b1a16c554c54efad1ad80a0706964c923",
"",
"reply"
],
[
"p",
"b61e2e7ccbf4abd7f49715c62f4ac7a93cbdd5ead0316279c5f5fe9b18dd0aaa"
]
],
"content": "📅 Original date posted:2016-02-09\n📝 Original message:I believe i've seen Luke say this several times before, but there are\nseveral more things that the majority of the devs agree should be in\nbitcoin.\nI would suggest to compile that list for your stage 3, so that you can have\nan hardfork that fixes most of those things, and there should be some\nrepository with those changes deployed.\n\n2016-02-09 14:16 GMT+00:00 jl2012--- via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e:\n\n\u003e I would like to present a 2-3 year roadmap to a better header format and\n\u003e bigger block size\n\u003e\n\u003e Objectives:\n\u003e\n\u003e 1. Multistage rule changes to make sure everyone will have enough time to\n\u003e upgrade\n\u003e 2. Make mining easier, without breaking existing mining hardware and the\n\u003e Stratum protocol\n\u003e 3. Make future hardfork less disruptive (with Luke-Jr's proposal)\n\u003e\n\u003e Stage 1 is Segregated Witness (BIP141), which will not break any existing\n\u003e full or light nodes. This may happen in Q2-Q3 2016\n\u003e\n\u003e Stage 2 is fixes that will break existing full nodes, but not light nodes:\n\u003e a. Increase the MAX_BLOCK_SIZE (the exact value is not suggested in this\n\u003e roadmap), potentially change the witness discount\n\u003e b. Anti-DoS rules for the O(n^2) validation of non-segwit scripts\n\u003e c. (optional) Move segwit's commitments to the header Merkle tree. This is\n\u003e optional at this stage as it will be fixed in Stage 3 anyway\n\u003e This may happen in Q1-Q2 2017\n\u003e\n\u003e Stage 3 is fixes that will break all existing full nodes and light nodes:\n\u003e a. Full nodes upgraded to Stage 2 will not need to upgrade again, as the\n\u003e rules and activation logic should be included already\n\u003e b. Change the header format to Luke-Jr's proposal, and move all commitments\n\u003e (tx, witness, etc) to the new structure. All existing mining hardware with\n\u003e Stratum protocol should work.\n\u003e c. Reclaiming unused bits in header for mining. All existing mining chips\n\u003e should still work. Newly designed chips should be ready for the new rule.\n\u003e d. Fix the time warp attack\n\u003e This may happen in 2018 to 2019\n\u003e\n\u003e Pros:\n\u003e a. Light nodes (usually less tech-savvy users) will have longer time to\n\u003e upgrade\n\u003e b. The stage 2 is opt-in for full nodes.\n\u003e c. The stage 3 is opt-in for light nodes.\n\u003e\n\u003e Cons:\n\u003e a. The stage 2 is not opt-in for light nodes. They will blindly follow the\n\u003e longest chain which they might actually don't want to\n\u003e b. Non-upgraded full nodes will follow the old chain at Stage 2, which is\n\u003e likely to have lower value.\n\u003e c. Non-upgraded light nodes will follow the old chain at Stage 3, which is\n\u003e likely to have lower value. (However, this is not a concern as no one\n\u003e should\n\u003e be mining on the old chain at that time)\n\u003e\n\u003e -------------------------------\n\u003e An alternative roadmap would be:\n\u003e\n\u003e Stage 2 is fixes that will break existing full nodes and light nodes.\n\u003e However, they will not follow the minority chain\n\u003e a. Increase the MAX_BLOCK_SIZE, potentially change the witness discount\n\u003e b. Anti-DoS rules for the O(n^2) validation of non-segwit scripts\n\u003e c. Change the header format to Luke-Jr's proposal, and move all commitments\n\u003e (tx, witness, etc) to the new structure.\n\u003e This may happen in mid 2017 or later\n\u003e\n\u003e Stage 3 is fixes that will break all existing full nodes and light nodes.\n\u003e a. Full nodes and light nodes upgraded to Stage 2 will not need to upgrade\n\u003e again, as the rules and activation logic should be included already\n\u003e b. Reclaiming unused bits in header for mining. All existing mining chips\n\u003e should still work.\n\u003e c. Fix the time warp attack\n\u003e This may happen in 2018 to 2019\n\u003e\n\u003e Pros:\n\u003e a. The stage 2 and 3 are opt-in for everyone\n\u003e b. Even failing to upgrade, full nodes and light nodes won't follow the\n\u003e minority chain at stage 2\n\u003e\n\u003e Cons:\n\u003e a. Non-upgraded full/light nodes will follow the old chain at Stage 3,\n\u003e which\n\u003e is likely to have lower value. (However, this is not a concern as no one\n\u003e should be mining on the old chain at that time)\n\u003e b. It takes longer to implement stage 2 to give enough time for light node\n\u003e users to upgrade\n\u003e\n\u003e -------------------------------\n\u003e\n\u003e In terms of safety, the second proposal is better. In terms of disruption,\n\u003e the first proposal is less disruptive\n\u003e\n\u003e I would also like to emphasize that it is miners' responsibility, not the\n\u003e devs', to confirm that the supermajority of the community accept changes in\n\u003e Stage 2 and 3.\n\u003e\n\u003e Reference:\n\u003e Matt Corallo's proposal:\n\u003e\n\u003e http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012403.\n\u003e html\n\u003e Luke-Jr's proposal:\n\u003e\n\u003e http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012377.\n\u003e html\n\u003e\n\u003e\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-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160209/8baa5e97/attachment-0001.html\u003e",
"sig": "2b380ce430867fcf967c23663a0b0168c4505a41c72093e203120e72b59242eceaaf38a53f49c7ef3d689a5eb3f270b71c08bfe80fdf2a1abdd5f97070bc2556"
}