public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Jorge Timón" <timon.elviejo@gmail.com>
To: Andy Parkins <andyparkins@gmail.com>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Addressing rapid changes in mining power
Date: Wed, 23 Nov 2011 16:10:40 +0100	[thread overview]
Message-ID: <CAGQP0AEQukQYB5Bmn-XfK3G0hm0q9r2YDL5W=zy+eBY7Vufb8g@mail.gmail.com> (raw)
In-Reply-To: <201111231254.41426.andyparkins@gmail.com>

2011/11/23, Andy Parkins <andyparkins@gmail.com>:
> On 2011 November 23 Wednesday, Jorge Timón wrote:
>> With the current system, the timestamp can also be cheated, but miners
>> have no direct incentive to do it. With your system, they increase
>> their probability of mining a block by putting a false timestamp.
>> Also, where's the network clock you're talking about? Isn't it the
>> timestamps in the blockchain?
>
> (1) The "probability of mining a block" is old-think.  The probability of
> mining a block is 100% in my system.  Instead, it becomes "the probability
> of
> your block being the hardest" and that requires actual hashing power
> regardless of the timestamp you write on the block.  I could write that my
> block was generated next year; but I can't fake the hashing power it needs
> to
> generate one year's worth of hashes.

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.

> (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.

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

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

-- 
Jorge Timón



  reply	other threads:[~2011-11-23 15:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-23 10:35 [Bitcoin-development] Addressing rapid changes in mining power Andy Parkins
2011-11-23 11:25 ` Jorge Timón
2011-11-23 11:30   ` Andy Parkins
2011-11-23 11:51     ` Jorge Timón
2011-11-23 12:10       ` Christian Decker
2011-11-23 13:13         ` Andy Parkins
2011-11-23 14:38           ` Christian Decker
2011-11-23 15:09             ` Gavin Andresen
2011-11-23 15:35               ` Alan Reiner
2011-11-23 15:39               ` Andy Parkins
2011-11-23 16:26                 ` Joel Joonatan Kaartinen
2011-11-23 15:11             ` Andy Parkins
2011-11-23 12:54       ` Andy Parkins
2011-11-23 15:10         ` Jorge Timón [this message]
2011-11-23 15:29           ` Andy Parkins
2011-11-23 15:38             ` Jorge Timón

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGQP0AEQukQYB5Bmn-XfK3G0hm0q9r2YDL5W=zy+eBY7Vufb8g@mail.gmail.com' \
    --to=timon.elviejo@gmail.com \
    --cc=andyparkins@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox