* [Bitcoin-development] Addressing rapid changes in mining power
@ 2011-11-23 10:35 Andy Parkins
2011-11-23 11:25 ` Jorge Timón
0 siblings, 1 reply; 16+ messages in thread
From: Andy Parkins @ 2011-11-23 10:35 UTC (permalink / raw)
To: bitcoin-development
[-- 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 --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Addressing rapid changes in mining power
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
0 siblings, 1 reply; 16+ messages in thread
From: Jorge Timón @ 2011-11-23 11:25 UTC (permalink / raw)
To: Andy Parkins; +Cc: bitcoin-development
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Addressing rapid changes in mining power
2011-11-23 11:25 ` Jorge Timón
@ 2011-11-23 11:30 ` Andy Parkins
2011-11-23 11:51 ` Jorge Timón
0 siblings, 1 reply; 16+ messages in thread
From: Andy Parkins @ 2011-11-23 11:30 UTC (permalink / raw)
To: Jorge Timón; +Cc: bitcoin-development
[-- 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 --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Addressing rapid changes in mining power
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 12:54 ` Andy Parkins
0 siblings, 2 replies; 16+ messages in thread
From: Jorge Timón @ 2011-11-23 11:51 UTC (permalink / raw)
To: Andy Parkins; +Cc: bitcoin-development
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Addressing rapid changes in mining power
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 12:54 ` Andy Parkins
1 sibling, 1 reply; 16+ messages in thread
From: Christian Decker @ 2011-11-23 12:10 UTC (permalink / raw)
To: Jorge Timón; +Cc: bitcoin-development
[-- 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 --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Addressing rapid changes in mining power
2011-11-23 11:51 ` Jorge Timón
2011-11-23 12:10 ` Christian Decker
@ 2011-11-23 12:54 ` Andy Parkins
2011-11-23 15:10 ` Jorge Timón
1 sibling, 1 reply; 16+ messages in thread
From: Andy Parkins @ 2011-11-23 12:54 UTC (permalink / raw)
To: Jorge Timón; +Cc: bitcoin-development
[-- 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 --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Addressing rapid changes in mining power
2011-11-23 12:10 ` Christian Decker
@ 2011-11-23 13:13 ` Andy Parkins
2011-11-23 14:38 ` Christian Decker
0 siblings, 1 reply; 16+ messages in thread
From: Andy Parkins @ 2011-11-23 13:13 UTC (permalink / raw)
To: bitcoin-development
[-- 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 --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Addressing rapid changes in mining power
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:11 ` Andy Parkins
0 siblings, 2 replies; 16+ messages in thread
From: Christian Decker @ 2011-11-23 14:38 UTC (permalink / raw)
To: Andy Parkins; +Cc: bitcoin-development
[-- 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 --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Addressing rapid changes in mining power
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 15:11 ` Andy Parkins
1 sibling, 2 replies; 16+ messages in thread
From: Gavin Andresen @ 2011-11-23 15:09 UTC (permalink / raw)
To: Christian Decker; +Cc: bitcoin-development
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Addressing rapid changes in mining power
2011-11-23 12:54 ` Andy Parkins
@ 2011-11-23 15:10 ` Jorge Timón
2011-11-23 15:29 ` Andy Parkins
0 siblings, 1 reply; 16+ messages in thread
From: Jorge Timón @ 2011-11-23 15:10 UTC (permalink / raw)
To: Andy Parkins; +Cc: bitcoin-development
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Addressing rapid changes in mining power
2011-11-23 14:38 ` Christian Decker
2011-11-23 15:09 ` Gavin Andresen
@ 2011-11-23 15:11 ` Andy Parkins
1 sibling, 0 replies; 16+ messages in thread
From: Andy Parkins @ 2011-11-23 15:11 UTC (permalink / raw)
To: Christian Decker; +Cc: bitcoin-development
[-- 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 --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Addressing rapid changes in mining power
2011-11-23 15:10 ` Jorge Timón
@ 2011-11-23 15:29 ` Andy Parkins
2011-11-23 15:38 ` Jorge Timón
0 siblings, 1 reply; 16+ messages in thread
From: Andy Parkins @ 2011-11-23 15:29 UTC (permalink / raw)
To: Jorge Timón; +Cc: bitcoin-development
[-- 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 --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Addressing rapid changes in mining power
2011-11-23 15:09 ` Gavin Andresen
@ 2011-11-23 15:35 ` Alan Reiner
2011-11-23 15:39 ` Andy Parkins
1 sibling, 0 replies; 16+ messages in thread
From: Alan Reiner @ 2011-11-23 15:35 UTC (permalink / raw)
To: bitcoin-development
[-- 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 --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Addressing rapid changes in mining power
2011-11-23 15:29 ` Andy Parkins
@ 2011-11-23 15:38 ` Jorge Timón
0 siblings, 0 replies; 16+ messages in thread
From: Jorge Timón @ 2011-11-23 15:38 UTC (permalink / raw)
To: Andy Parkins; +Cc: bitcoin-development
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Addressing rapid changes in mining power
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
1 sibling, 1 reply; 16+ messages in thread
From: Andy Parkins @ 2011-11-23 15:39 UTC (permalink / raw)
To: Gavin Andresen; +Cc: bitcoin-development
[-- 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 --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Addressing rapid changes in mining power
2011-11-23 15:39 ` Andy Parkins
@ 2011-11-23 16:26 ` Joel Joonatan Kaartinen
0 siblings, 0 replies; 16+ messages in thread
From: Joel Joonatan Kaartinen @ 2011-11-23 16:26 UTC (permalink / raw)
To: Andy Parkins; +Cc: bitcoin-development
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
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2011-11-23 16:26 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2011-11-23 15:29 ` Andy Parkins
2011-11-23 15:38 ` Jorge Timón
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox