Topic: The classic roadmap (Read 338 times)
Well considering that most of their roadmap consist on copy-pasting Core's dev team code and then changing a couple of things up that are always a big tradeoff against decentralization and privacy, I understand that anyone paying attention and putting things in context is going to be disappointed with Classic.
I am not supporter at all of Classic and to their bitcoin blockchain split propose. But i think empty blocks is not a problem to bitcoin network because then we will have and lower orphan blocks.
I started to read the classic roadmap, but I turned off early on when I read this -
I'm pretty set against classic, but I thought I should read the roadmap in case I am wrong. However, on reading this, I got the impression that they wanted 2Mb blocks, but then they want faster validation and confirmation, so they are encouraging miners to produce empty or low density blocks. This seems to be completely contrary to what is needed to help Bitcoin grow.
Please tell me why I am wrong (if I am wrong).
Quote
Technical TODO for scaling up
Implement parallel validation of blocks. Currently Core does block validation one block at a time (the cs_main lock is held during validation). Allowing blocks to be validated in parallel means a slower-to-validate block is more likely to lose the "block race" to a faster-to-validate block.
Implement "headers-first" mining. As soon as a valid 80-byte block header that extends the most-work chain is received, relay the header (via a new p2p network message) and allow mining an empty block on top of it, for up to 20 seconds. When it is fully validated, mine a normal block. If a faster-to-validate block that extends the most-work chain is received and validated first (see parallel validation, above), mine on top of the faster-to-validate block. If full block data has not been received within a reasonable number of seconds (e.g. 30 seconds), fall back to mining on the last fully-validated block.
Implement parallel validation of blocks. Currently Core does block validation one block at a time (the cs_main lock is held during validation). Allowing blocks to be validated in parallel means a slower-to-validate block is more likely to lose the "block race" to a faster-to-validate block.
Implement "headers-first" mining. As soon as a valid 80-byte block header that extends the most-work chain is received, relay the header (via a new p2p network message) and allow mining an empty block on top of it, for up to 20 seconds. When it is fully validated, mine a normal block. If a faster-to-validate block that extends the most-work chain is received and validated first (see parallel validation, above), mine on top of the faster-to-validate block. If full block data has not been received within a reasonable number of seconds (e.g. 30 seconds), fall back to mining on the last fully-validated block.
I'm pretty set against classic, but I thought I should read the roadmap in case I am wrong. However, on reading this, I got the impression that they wanted 2Mb blocks, but then they want faster validation and confirmation, so they are encouraging miners to produce empty or low density blocks. This seems to be completely contrary to what is needed to help Bitcoin grow.
Please tell me why I am wrong (if I am wrong).
Jump to: