Re: [Bitcoin-development] Addressing rapid changes in mining power

[Andy Parkins <andyparkins@gmail.com>]

[-- Attachment #1: Type: Text/Plain, Size: 2329 bytes --]

On 2011 November 23 Wednesday, Jorge Timón wrote:

> Well, I meant "the probability of  your block being the hardest".
> What a miner can do is hash the block (cheating the timestamp) for 2
> more minutes than the rest of the people and then send it to the other
> nodes. Nodes cannot possibly know when did you hashed the block only
> by looking at their clock when they receive it, because there's also
> network latency.

True enough; but then the same is true for everyone else.  If the window is 2 
minutes after the stated time, then everyone _can_ wait until the end of that 
window.  However, they risk their block being rejected by their peers, and 
their efforts are wasted.  In fact, it can be guaranteed by making the accept 
window zero.  There is then no reason to carry on computing after the reward 
window closes, since you know your peers will reject it.

> > (2) For the network clock; see util.cpp:GetAdjustedTime().
> 
> 1) This is part of the satoshi client but not the protocol. A miner
> can rewrite this part of the code and there won't be anything in the
> chain that contradicts the protocol.

Well yes.  What does that matter?  It's only a way of calculating an average 
time.  The node can use any clock it wants, as long as the block time is 
verified by the peers.

> 2) I haven't read the code but I'm pretty sure that's not a perfect
> decentralized clock.

It definitely isn't.  NTP is mentioned in the source as an alternative.

> I will be more specific. Where's the network clock in the chain (in
> the protocol)?

It's nothing to do with the protocol; it's an individual miner choosing 
whether to accept or reject a block based on the timestamp it claims, and the 
current time as the miner sees it.  For the sake of compatibility, the clients 
currently choose to use a community clock as "current", as established from 
the time they receive from peers in the "version" message (it actually holds 
offsets between them, which is pretty bad, as a long-connected client will 
drift).  They don't have to, but if miners aren't using time that approximates 
what their peers are using, under my system, their blocks would be rejected: 
so an incentive to use that "community clock" exists.



Andy

-- 
Dr Andy Parkins
andyparkins@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]