Andy Parkins [ARCHIVE] on Nostr: 📅 Original date posted:2011-11-23 🗒️ Summary of this message: A miner can ...

📅 Original date posted:2011-11-23
🗒️ Summary of this message: A miner can cheat the timestamp by hashing the block for two more minutes than others, but it risks rejection by peers. The network clock is not part of the protocol.
📝 Original message: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 at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111123/aa9881ec/attachment.sig>;