Published on: 2017-09-02T21:13:57+00:00
Cserveny Tamas has expressed concern about the exponential growth in Bitcoin transactions and the resulting increase in waiting times and fees. He believes that increasing the block size from 1MB to 4MB and eventually 40MB is necessary to address this issue. However, Tom Zander disagrees and argues that successful products will always push the limits of technology. He cites examples like YouTube and Netflix as proof of this. In a discussion on the Bitcoin-dev mailing list, Tamas suggests that the only way to scale with increasing traffic and lower fees is by either increasing the block size or reducing complexity, although the latter may compromise security. Another member of the discussion disagrees with the idea that reducing complexity would be less secure as long as confirmation is adjusted accordingly. They argue that increasing the number of confirmations can make it just as secure. They also suggest that considering the average hash rate over 60 blocks instead of 6 can actually enhance security.The discussion centers around the scalability issues of the Bitcoin network. The current system is described as single-threaded, where one block being found renders other blocks worthless. To scale with increasing traffic, the options are increasing the block size or reducing complexity, which is seen as less secure. One potential solution proposed is splitting the chain, effectively increasing the block size without the added hashing and validation overhead. This approach could keep the block size at 1-2mb for a longer period of time, with new partitions being added on a schedule. However, more specific details are needed to fully evaluate its effectiveness compared to other systems like IOTA.A response to a statement suggesting that the current Bitcoin chain is single-threaded argues that this is not true since the introduction of xthin/compactblocks. These technologies have removed the bottleneck, allowing for continuous parallel validation of transactions. However, it is pointed out that the original statement may refer to the entire distributed system behaving as a single-threaded computation, similar to how IOTA operates. The benefits of this approach are difficult to assess without more specific details. It is also mentioned that distributing the task of validating transactions versus reducing difficulty could be advantageous, and the Lightning network may offer instant validation with smaller fees.Another message thread clarifies that the current Bitcoin chain is not single-threaded due to the introduction of xthin/compactblocks. These technologies enable continuous parallel validation of transactions. However, it is noted that the original statement might refer to the behavior of the entire distributed system, which is closer to what IOTA uses. More information is needed to evaluate the benefits of this approach.In another discussion on the Bitcoin-dev mailing list, Tamas raises concerns about miners adding capacity to the network, arguing that it only increases their share of block rewards without improving transaction speed. However, it is pointed out that increasing block size does increase the throughput speed of transactions and does not affect the block reward. Tamas also suggests that raising fees in the future due to decreasing block rewards would be inevitable, but this has not been observed. Additionally, Tamas claims that the current chain is effectively single-threaded, a claim refuted by Tom Zander. With the introduction of xthin/compactblocks, the network bottleneck has been eliminated, allowing for continuous parallel validation of transactions. Zander provides further insights on his blog and vlog channels.The writer considers various options for scaling the blockchain. One problem is that adding more miners only increases their share of block rewards without improving transaction speed. The current chain is described as single-threaded, so horizontal scaling could be a viable solution if the problem can be partitioned. The number of partitions would start low but could increase over time. Two alternatives for partitioning keys are mentioned: ordering on inputs or ordering on transaction IDs. Both methods would impact block rewards and complexity, which would need adjustment. The activation of partitions could be done gradually according to a schedule. Creating new partitions would be easy, but closing them might be more complex in the case of transaction-partitioned transactions. The writer acknowledges that there are pros and cons to both partition keys and seeks opinions on the matter.
Updated on: 2023-08-01T21:43:37.629456+00:00