Skip to main content
shift focus to "surprise invalidation"
Source Link

The key point of the Bitcoin design is to create a system that provides a reliable transaction record without any central coordination or arbiter. Instead, Bitcoin is a distributed system where a consensus is reached using a "consensus algorithm" that can be repeatedly evaluated by every node on the network.

As Bitcoin is operating today, the target of a "block period" is well-defined and agreed upon by all nodes. A node can verify whether a certain block is a valid solution using just knowledge from the chain (i.e. the target difficulty) without relying on any clock.

In the system you propose, you can't decide whether you have seen "the best block of the 10-minute timespan" by just looking at the block. This means you don't know whether that block is a valid block without knowing all other candidates. Furthermore, as Murch already pointed how: How doThe consequence is that a block you agree whetherconsidered valid might become invalid when a late entry (eblock with a lower hash appears.g This is something that can not happen according to the current scheme, and it has dramatic consequences. arrives atToday, a block that is considered valid can safely be mined upon, as the work required to outrun the valid block is expected to be around the same as continuing on that block. In your nodescheme, it takes just the work of finding a better block to make the previously accepted solution .03 seconds afterinvalid and you destroy the 10-minute window closed) was generated in time or not?work based on that now invalid block "for free".

So when you start mining on a block, you need to be confident that you know a valid solution, and that this solution will stay valid. The usual solutionapproach to the shortcomings I just describedchallenge would be a central arbiter that collects candidates and decides which block to pick, or submitting every candidate block to a trustworthy timestamping service and the time on the timestamp determines whether the block was generated in timefixes this decision for good. As I already stated in the introduction, anything relying on a central trustworthy service (arbiter, timestamping service) doesn't meet the primary goal of Bitcoin.

The key point of the Bitcoin design is to create a system that provides a reliable transaction record without any central coordination or arbiter. Instead, Bitcoin is a distributed system where a consensus is reached using a "consensus algorithm" that can be repeatedly evaluated by every node on the network.

As Bitcoin is operating today, the target of a "block period" is well-defined and agreed upon by all nodes. A node can verify whether a certain block is a valid solution using just knowledge from the chain (i.e. the target difficulty) without relying on any clock.

In the system you propose, you can't decide whether you have seen "the best block of the 10-minute timespan" by just looking at the block. This means you don't know whether that block is a valid block without knowing all other candidates. Furthermore, as Murch already pointed how: How do you agree whether a late entry (e.g. arrives at your node .03 seconds after the 10-minute window closed) was generated in time or not? The usual solution to the shortcomings I just described would be a central arbiter that collects candidates and decides which block to pick, or submitting every candidate block to a trustworthy timestamping service and the time on the timestamp determines whether the block was generated in time. As I already stated in the introduction, anything relying on a central trustworthy service (arbiter, timestamping service) doesn't meet the primary goal of Bitcoin.

The key point of the Bitcoin design is to create a system that provides a reliable transaction record without any central coordination or arbiter. Instead, Bitcoin is a distributed system where a consensus is reached using a "consensus algorithm" that can be repeatedly evaluated by every node on the network.

As Bitcoin is operating today, the target of a "block period" is well-defined and agreed upon by all nodes. A node can verify whether a certain block is a valid solution using just knowledge from the chain (i.e. the target difficulty) without relying on any clock.

In the system you propose, you can't decide whether you have seen "the best block of the 10-minute timespan" by just looking at the block. This means you don't know whether that block is a valid block without knowing all other candidates. The consequence is that a block you considered valid might become invalid when a block with a lower hash appears. This is something that can not happen according to the current scheme, and it has dramatic consequences. Today, a block that is considered valid can safely be mined upon, as the work required to outrun the valid block is expected to be around the same as continuing on that block. In your scheme, it takes just the work of finding a better block to make the previously accepted solution invalid and you destroy the work based on that now invalid block "for free".

So when you start mining on a block, you need to be confident that you know a valid solution, and that this solution will stay valid. The usual approach to the challenge would be a central arbiter that collects candidates and decides which block to pick and fixes this decision for good. As I already stated in the introduction, anything relying on a central trustworthy service doesn't meet the primary goal of Bitcoin.

Source Link

The key point of the Bitcoin design is to create a system that provides a reliable transaction record without any central coordination or arbiter. Instead, Bitcoin is a distributed system where a consensus is reached using a "consensus algorithm" that can be repeatedly evaluated by every node on the network.

As Bitcoin is operating today, the target of a "block period" is well-defined and agreed upon by all nodes. A node can verify whether a certain block is a valid solution using just knowledge from the chain (i.e. the target difficulty) without relying on any clock.

In the system you propose, you can't decide whether you have seen "the best block of the 10-minute timespan" by just looking at the block. This means you don't know whether that block is a valid block without knowing all other candidates. Furthermore, as Murch already pointed how: How do you agree whether a late entry (e.g. arrives at your node .03 seconds after the 10-minute window closed) was generated in time or not? The usual solution to the shortcomings I just described would be a central arbiter that collects candidates and decides which block to pick, or submitting every candidate block to a trustworthy timestamping service and the time on the timestamp determines whether the block was generated in time. As I already stated in the introduction, anything relying on a central trustworthy service (arbiter, timestamping service) doesn't meet the primary goal of Bitcoin.