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

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

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.

If chain difficulty were summed correctly (sum(log(difficulty)), I guess), 
then time makes not the slightest difference anyway.  You can issue blocks at 
any time with any difficulty, and the "hardest" chain always wins.  The block 
period can be anything, and it is only the block reward that makes it 
necessary to pick a particular period for block issuing (even that could be 
worked around I guess with a variable reward, but why bother?).

(2) For the network clock; see util.cpp:GetAdjustedTime().

(3) Current clients do have an incentive: more time.  The more time they get, 
the more hashes they can try.  The current client already checks the 
timestamp:

  main.cpp:CBlock::CheckBlock()

    // Check timestamp
    if (GetBlockTime() > GetAdjustedTime() + 2 * 60 * 60)
        return error("CheckBlock() : block timestamp too far in the future");

My suggestion only requires that the two hour window be reduced; and a lower 
limit to be added.  Also: while the miners have an incentive to lie about the 
time, the nodes they broadcast to have an incentive to reject mistimed blocks, 
so you won't gain much by lying to your peers since your block won't be 
accepted -- the incentive is therefore removed.

Note: my system also prevents an attack that is possible with current bitcoin: 
recalculating the entire chain.  Let's say Visa want to take over bitcoin.  
They buy enough computing power to significantly beat the current bitcoin 
network; then they start recalculating the entire block chain; since early 
blocks were low difficulty, it's not that hard to do.  Once they overtake the 
real chain, they have effectively undone all previous transactions.  (I'm not 
suggesting this is likely; and it's actually mitigated by the hard-coded block 
hashes).  The point is that blocks are only generatable for the time when the 
rest of the network is willing to add them to the chain.



Andy

-- 
Dr Andy Parkins
andyparkins@gmail.com

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

  parent reply	other threads:[~2011-11-23 12:54 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 [this message]
2011-11-23 15:10         ` Jorge Timón
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=201111231254.41426.andyparkins@gmail.com \
    --to=andyparkins@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=timon.elviejo@gmail.com \
    /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