On Wed, Nov 23, 2011 at 2:13 PM, Andy Parkins
<andyparkins@gmail.com> wrote:
On 2011 November 23 Wednesday, Christian Decker wrote:
> The current block generation with a fixed difficulty was chosen because it
> it clear when to adjust and to what target difficulty it has to be
> adjusted. If we were to use synchronized time windows and select the
> hardest block it gets incredibly complicated as synchronization is not
> possible in distributed systems. Even the smallest drift would allow for
> forks in the chain all over the place. Furthermore the delay in propagation
> will also cause forks.
>
> If 1/2 of the network see one block as the hardest, and for the rest of the
> network it came too late then we'll have a fork that stays with us quite a
> while.
>
> The block chain is described as a timestamp server in the paper, but it is
> more of a proof-of-existence before, as the contained timestamp cannot be
> trusted anyway.
These are reasonable objections. My counter is this:
Let's view block difficulty as a measure of time, not time itself. The
timestamp is merely a convenience for the block. You cannot fake the
computing power needed for a particular difficulty; so the hardest chain
always wins (note: hardest chain).
If I am a miner, I have two choices:
(a) try to replace the top block on the current hardest chain
(b) try to append to the current hardest chain
Either of these is acceptable; but in case (a) I have to generate a more
difficult block to replace it; in case (b), at the start of the window, any
difficulty is acceptable (however, I'm competing with other miners, so _any_
difficulty won't beat them).
The rule then is that you're trying to win the one block reward that is
available every 10 minutes; and your peers will be rejecting blocks with
timestamps that are lies.
Perhaps an example...
- I (a node), download the blockchain
- The blockchain has N potential heads. Each of those heads has a time, t
and a sum_of_difficulty.
- The next block reward is going to go to the highest difficulty with
t < timestamp < (t + T) _and_ verified timestamp (i.e. not received more
than, say 5 minutes, from its claimed timestamp).
- I can choose any head to start generating from, but given that it's the
highest difficulty chain that's going to win the next reward (not the
highest difficulty block), I will surely pick the most difficult?
- A rogue miner then issues a block with a fake timestamp; it actually
generated at (t + T + 5) but claims (t + 5). Should I start using
that block as my new head? Obviously not, because my peers might decide
that it is a lie and reject it because it was received too late, making my
work useless. It is in my interest to pick a head that is honest.
Resolving forks is easy:
- 50 coins every ten minutes only
- most difficult chain wins
I'm certainly not saying it's a simple change. There are certainly areas I
haven't thought about, and could be game-overs; but I do like the idea of
there being no target difficulty, and instead the blocks are issued at a fixed
ten minute rate (or rather the rewards are).
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development