|
|
|
|
|
|
by MCRed
3773 days ago
|
|
|
Consider that much of the opposition to Core comes from the perception that Blockstream, which employs many of the core developers, is usurping it to be a high-fee, low-transaction network so that they can incentivize (and profit from) the use of their lighting network. That's why the opposition is called "classic" not "bitcoin democracy". Their position is they are getting back to what bitcoin should have been. And bitcoin originally had larger than 2mb blocks. The 1mb block limit was a short term solution to a problem that existed back then... that was never lifted. |
|
|
> After simulating the creation of blocks up to 32 MB in size, we have arrived at some interesting conclusions:
- a 32 MB block, when filled with simple P2PKH transactions, can hold approximately 167,000 transactions, which, assuming a block is mined every 10 minutes, translates to approximately 270 tps
- a single machine acting as a full node takes approximately 10 minutes to verify and process a 32 MB block, meaning that a 32 MB block size is near the maximum one could expect to handle with 1 machine acting as a full node
- a CPU profile of the time spent processing a 32 MB block by a full node is dominated by ECDSA signature verification, meaning that with the current infrastructure and computer hardware, scaling above 300 tps would require a clustered full node where ECDSA signature checking is load balanced across multiple machines.
In addition:
> Aside from the obvious network and storage constraints of running a full Bitcoin node at large block sizes, it appears the Bitcoin network is capable of handling a substantially higher transaction volume than it does currently. The CPU time being dominated by ECDSA signature checks at high transaction rates suggests a clustered full node architecture could process credit-card-like transaction rates by using a load balancing / offload approach to ECDSA signature checking, e.g. a full node with a 10 machine cluster would top out at >2,000 tps.
> The resources and know-how required to run a clustered node like this may impose a significant centralizing force on Bitcoin. Backpressure against the centralization of Bitcoin may well drive alternative solutions to having all transactions on-chain. Alternatively, it may end up that Bitcoin adoption grows slowly enough that the computing power of a single node grows quickly enough to avoid requiring a clustered full node architecture.
Under Gavin Andresen's original plan, the 32MB limit could've been crossed in Jan 2018 when the size doubled to 40MB. Importantly, Gavin has since dropped the idea for a block size of 2MB. Hence you really can't claim that your own preferred plan for block size won't result in "a high-fee, low-transaction network". It's 2MB - that's a very far cry from VISA and it's only 0.4MB more than the scaling roadmap - that's a difference of at worst 3 tps out of VISA's 56,000.
Unless your intent is to quite literally put 100% of Bitcoin full nodes in datacenters, it's as clear as day that raising and re-raising block size ad infinitum doesn't work, as it usurps control of full nodes from individuals. It effectively turns Bitcoin into an enterprise database only accessible to the rest of us through garbage proprietary SaaS platforms. Clearly this isn't a benefit and we should be pulling out every possible stop to avoid it from happening. Look, if your vision for Bitcoin is that it should be like Parse.com for credit cards, I'm sorry but we're just going to have to agree to disagree.