[Bitcoin-development] Addressing rapid changes in mining power

[Bitcoin-development] Addressing rapid changes in mining power

[Andy Parkins]

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

Hello,

One problem with Bitcoin is that if large numbers of miners suddenly switch 
off, the network takes a long time to adapt (since the adaption time is a 
function of blocks generated, and the block generation rate has changed).  The 
same problem exists in the other direction, but an increased generation rate 
for a little while doesn't really do any harm.

I had this idea as a way of completely normalising the block generation rate, 
regardless of network power.  I hesitate to offer it, as I get shouted down a 
lot, but what the hell...

Let's imagine that the whole network shares a clock (which it does already).  
Let's abandon the idea of a target difficulty.  Instead, every node just 
generates the most difficulty block it can.  Simultaneously, every node is 
listening for "the most difficult block generated before time T"; with T being 
picked to be the block generation rate (10 minutes).

Every node is therefore generating blocks and comparing not against some 
moving average determined target, but rather against the most difficult 
recently received block.  If the generated block is harder than the received 
block, then it gets broadcast.

Clearly, early on in the block, the traffic would be high, but that could be 
limited with a bit of intelligence -- there's no point broadcasting your best 
blocks in minute 0 of the current block... you know everyone will beat it, as 
it was so easy.  So the rule would be broadcasts only start at T/2 plus a 
little randomisation.  There wouldn't be that many because someone will have 
generated a pretty good block by chance in the first half, and that will 
quickly stop anybody else from bothering to broadcast their easier block.  
There is no advantage to broadcasting a lesser block, so there is no incentive 
to cheat.

As always: the most difficult chain wins; and blocks with out-of-bounds times 
are rejected regardless of difficulty.  Everyone therefore has an incentive to 
base their next block on the block with highest difficulty from the previous 
period.

The block period is now guaranteed to be 10 minutes (or in fact, whatever 
period you like, there is no danger at all in changing it to 2 minutes); and 
there is no change of block generation rate with network power.  Changes in 
network power merely adjust the average difficulty of the best block per 
period.  The cost is higher network traffic, because there are block 
broadcasts that don't necessarily make it to the end.  However, there's no 
need to broadcast the full block, only the header.  If that block turns out to 
be the winner, then the other nodes will request the full block at the end of 
the period, and will check it's valid.  If it's not then the next highest on 
the list will be requested.  So again, 

I recognise that this is a pretty large change to make; and so don't really 
expect it to happen.  Perhaps one day though... when all the wishlist items go 
into one huge protocol overhaul.



Andy
-- 
Dr Andy Parkins
andyparkins@gmail.com

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

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

[Jorge Timón]

2011/11/23, Andy Parkins <andyparkins@gmail.com>:
> Let's abandon the idea of a target difficulty.  Instead, every node just
 > generates the most difficulty block it can.  Simultaneously, every node is
 > listening for "the most difficult block generated before time T"; with T
 > being
 > picked to be the block generation rate (10 minutes).

A miner could try to obtain more difficulty out of time and cheat its
reported datetime (T).

Jorge Timón

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

[Andy Parkins]

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

On 2011 November 23 Wednesday, Jorge Timón wrote:
> 2011/11/23, Andy Parkins <andyparkins@gmail.com>:
> > Let's abandon the idea of a target difficulty.  Instead, every node just
> > 
>  > generates the most difficulty block it can.  Simultaneously, every node
>  > is listening for "the most difficult block generated before time T";
>  > with T being
>  > picked to be the block generation rate (10 minutes).
> 
> A miner could try to obtain more difficulty out of time and cheat its
> reported datetime (T).

Just as with the current system.

The defence is that on receipt of a block, its timestamp is checked against 
the node's own clock and averaged network clock.  Blocks out of that band are 
rejected.


Andy
-- 
Dr Andy Parkins
andyparkins@gmail.com

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

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

[Jorge Timón]

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?



2011/11/23, Andy Parkins <andyparkins@gmail.com>:
> On 2011 November 23 Wednesday, Jorge Timón wrote:
>> 2011/11/23, Andy Parkins <andyparkins@gmail.com>:
>> > Let's abandon the idea of a target difficulty.  Instead, every node just
>> >
>>  > generates the most difficulty block it can.  Simultaneously, every node
>>  > is listening for "the most difficult block generated before time T";
>>  > with T being
>>  > picked to be the block generation rate (10 minutes).
>>
>> A miner could try to obtain more difficulty out of time and cheat its
>> reported datetime (T).
>
> Just as with the current system.
>
> The defence is that on receipt of a block, its timestamp is checked against
> the node's own clock and averaged network clock.  Blocks out of that band
> are
> rejected.
>
>
> Andy
> --
> Dr Andy Parkins
> andyparkins@gmail.com
>


-- 
Jorge Timón

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

[Christian Decker]

[-- Attachment #1: Type: text/plain, Size: 2884 bytes --]

First of all I do agree that a method for adjusting the difficulty in a
huge power drop is needed (I don't see it so much in power rises).

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.

Regards,
Chris

2011/11/23 Jorge Timón <timon.elviejo@gmail.com>

> 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?
>
>
>
> 2011/11/23, Andy Parkins <andyparkins@gmail.com>:
> > On 2011 November 23 Wednesday, Jorge Timón wrote:
> >> 2011/11/23, Andy Parkins <andyparkins@gmail.com>:
> >> > Let's abandon the idea of a target difficulty.  Instead, every node
> just
> >> >
> >>  > generates the most difficulty block it can.  Simultaneously, every
> node
> >>  > is listening for "the most difficult block generated before time T";
> >>  > with T being
> >>  > picked to be the block generation rate (10 minutes).
> >>
> >> A miner could try to obtain more difficulty out of time and cheat its
> >> reported datetime (T).
> >
> > Just as with the current system.
> >
> > The defence is that on receipt of a block, its timestamp is checked
> against
> > the node's own clock and averaged network clock.  Blocks out of that band
> > are
> > rejected.
> >
> >
> > Andy
> > --
> > Dr Andy Parkins
> > andyparkins@gmail.com
> >
>
>
> --
> Jorge Timón
>
>
> ------------------------------------------------------------------------------
> 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
>

[-- Attachment #2: Type: text/html, Size: 3828 bytes --]

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

[Andy Parkins]

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

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


Andy

-- 
Dr Andy Parkins
andyparkins@gmail.com

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

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

[Christian Decker]

[-- Attachment #1: Type: text/plain, Size: 4700 bytes --]

Just brainstorming here, no idea if this would work:

   - Pick any old block
   - Create a chain fork by creating simpler blocks on top of your chosen
   one
   - The chain will not be accepted by others
   - At some point you might find an incredibly hard block that makes your
   forked chain the hardest one in the network
   - Suddenly all your blocks are valid and you force people to switch to
   your forked chain

If this is possible it would allow you to revoke all transactions and claim
all the mined coins since you forked. My point is that the notion of
hardest chain is not so simple.

The difficulty of invalidating a chain is dramatically reduced with your
time window approach, by not requiring a given difficulty, and relying on
synchronized time windows.

Regards,
Chris

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).
>
>
> Andy
>
> --
> Dr Andy Parkins
> andyparkins@gmail.com
>
>
> ------------------------------------------------------------------------------
> 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
>
>

[-- Attachment #2: Type: text/html, Size: 5660 bytes --]

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

[Gavin Andresen]

On Wed, Nov 23, 2011 at 9:38 AM, Christian Decker
<decker.christian@gmail.com> wrote:
> At some point you might find an incredibly hard block that makes your forked
> chain the hardest one in the network

Seems to me that's the real problem with any "hardest block found in X
minutes" scheme.

If I get lucky and find a really extremely hard block then I have an
incentive to keep it secret and build a couple more blocks on top of
it, then announce them all at the same time.

If the rest of the network rejects my longer chain because I didn't
announce the extremely hard block in a timely fashion... then how
could the network ever recover from a real network split?  A network
split/rejoin will look exactly the same.

Bitcoin as-is doesn't have the "I got lucky and found an extremely
hard block" problem because the difficulty TARGET is used to compute
chain difficulty, not the actual hashes found.


---

PS: I proposed a different method for dealing with large hash power
drops for the testnet on the Forums yesterday, and am testing it
today.

-- 
--
Gavin Andresen

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

[Alan Reiner]

[-- Attachment #1: Type: text/plain, Size: 1981 bytes --]

I can substantiate Gavin's point quite powerfully: a couple months ago I 
did a search for the "hardest" block in the network and found a *very 
**impressive* one:

https://bitcointalk.org/index.php?topic=29675.0

That block has a difficulty of **36 billion** when the network had a 
difficulty of **1.5 million**, which is 24,000 times harder than the 
target.  If we were going by the /actual /hardest chain instead 
target-based-hardest chain, /then this block produced in July would 
might still represent the longest chain!/

Yes, that means that whichever miner produced this block, could've held 
onto it for 2-4 months without doing anything else, and then broadcast 
it to fork the blockchain from a block produced months ago.  That's not 
theoretical, that's real data in the blockchain and it would be a disaster.

-Alan



On 11/23/2011 10:09 AM, Gavin Andresen wrote:
> On Wed, Nov 23, 2011 at 9:38 AM, Christian Decker
> <decker.christian@gmail.com>  wrote:
>> At some point you might find an incredibly hard block that makes your forked
>> chain the hardest one in the network
> Seems to me that's the real problem with any "hardest block found in X
> minutes" scheme.
>
> If I get lucky and find a really extremely hard block then I have an
> incentive to keep it secret and build a couple more blocks on top of
> it, then announce them all at the same time.
>
> If the rest of the network rejects my longer chain because I didn't
> announce the extremely hard block in a timely fashion... then how
> could the network ever recover from a real network split?  A network
> split/rejoin will look exactly the same.
>
> Bitcoin as-is doesn't have the "I got lucky and found an extremely
> hard block" problem because the difficulty TARGET is used to compute
> chain difficulty, not the actual hashes found.
>
>
> ---
>
> PS: I proposed a different method for dealing with large hash power
> drops for the testnet on the Forums yesterday, and am testing it
> today.
>


[-- Attachment #2: Type: text/html, Size: 2759 bytes --]

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

[Andy Parkins]

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

On 2011 November 23 Wednesday, Gavin Andresen wrote:

> Bitcoin as-is doesn't have the "I got lucky and found an extremely
> hard block" problem because the difficulty TARGET is used to compute
> chain difficulty, not the actual hashes found.

Good points.  I don't think I have a response to that one.

I saw the "I got lucky" result as a benefit, as it made it harder to fork the 
chain.  We got an advantage from the luck.

I'll have to abandon this suggestion.  It's not going to work.

Thanks for the feedback everyone.



Andy

-- 
Dr Andy Parkins
andyparkins@gmail.com

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

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

[Joel Joonatan Kaartinen]

On Wed, 2011-11-23 at 15:39 +0000, Andy Parkins wrote:
> On 2011 November 23 Wednesday, Gavin Andresen wrote:
> 
> > Bitcoin as-is doesn't have the "I got lucky and found an extremely
> > hard block" problem because the difficulty TARGET is used to compute
> > chain difficulty, not the actual hashes found.
> 
> Good points.  I don't think I have a response to that one.

If there's an upper bound on the difficulty a block is accepted to have
(even if it would've passed with significantly higher difficulty), that
could solve this issue. For example, take the median (or average) of the
past 2016 blocks and don't value any new block for more than maybe 4
times as difficult as that. 

> I saw the "I got lucky" result as a benefit, as it made it harder to fork the 
> chain.  We got an advantage from the luck.
> 
> I'll have to abandon this suggestion.  It's not going to work.
> 
> Thanks for the feedback everyone.

Don't be so hasty with that :)

- Joel

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

[Andy Parkins]

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

On 2011 November 23 Wednesday, Christian Decker wrote:
> Just brainstorming here, no idea if this would work:
> 
>    - Pick any old block
>    - Create a chain fork by creating simpler blocks on top of your chosen
>    one
>    - The chain will not be accepted by others
>    - At some point you might find an incredibly hard block that makes your
>    forked chain the hardest one in the network
>    - Suddenly all your blocks are valid and you force people to switch to
>    your forked chain
> 
> If this is possible it would allow you to revoke all transactions and claim
> all the mined coins since you forked. My point is that the notion of
> hardest chain is not so simple.

The above is a problem in either system (mine or current).  If I can make a 
"hardest chain", then I have indeed reverted all the existing transactions. 

Look at CBlock::AddToBlockIndex(), 

    if (pindexNew->bnChainWork > bnBestChainWork)
        if (!SetBestChain(txdb, pindexNew))
            return false;

If the received block has higher total chain work than the current best chain 
work; then the new block becomes the head of the best chain.  The chain work 
being calculated like this (I've abbreviated for the email):

  pindexNew->bnChainWork = pprev->bnChainWork + pindexNew->GetBlockWork()

I'm not entirely convinced that this method of totalling chain work is the 
best (it's a sum of exponentials I think); but that's a different issue.

> The difficulty of invalidating a chain is dramatically reduced with your
> time window approach, by not requiring a given difficulty, and relying on
> synchronized time windows.

I don't see that it is reduced; it is the same.  Hashes are hashes.  A given 
difficulty isn't required, but a higher difficulty beats a lower difficulty.  
So whatever the hashing power of the network at that moment, it's used.  That 
makes the chain more secure, not less.



Andy

-- 
Dr Andy Parkins
andyparkins@gmail.com

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

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

[Andy Parkins]

[-- 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 --]

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

[Jorge Timón]

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

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

[Andy Parkins]

[-- 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 --]

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

[Jorge Timón]

But the protocol must have a deterministic way to determine if a block
must be accepted or rejected.
I don't know what NTP is, but if you can have a perfect distributed
clock your proposal may work.

2011/11/23, Andy Parkins <andyparkins@gmail.com>:
> 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
>


-- 
Jorge Timón