Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RTBfz-00007b-NH for bitcoin-development@lists.sourceforge.net; Wed, 23 Nov 2011 12:11:43 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.161.47 as permitted sender) client-ip=209.85.161.47; envelope-from=decker.christian@gmail.com; helo=mail-fx0-f47.google.com; Received: from mail-fx0-f47.google.com ([209.85.161.47]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1RTBfy-0000eW-DW for bitcoin-development@lists.sourceforge.net; Wed, 23 Nov 2011 12:11:43 +0000 Received: by faat2 with SMTP id t2so2315950faa.34 for ; Wed, 23 Nov 2011 04:11:36 -0800 (PST) Received: by 10.181.12.111 with SMTP id ep15mr10333202wid.10.1322050296111; Wed, 23 Nov 2011 04:11:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.197.141 with HTTP; Wed, 23 Nov 2011 04:10:55 -0800 (PST) In-Reply-To: References: <201111231035.48690.andyparkins@gmail.com> <201111231130.58785.andyparkins@gmail.com> From: Christian Decker Date: Wed, 23 Nov 2011 13:10:55 +0100 Message-ID: To: =?ISO-8859-1?Q?Jorge_Tim=F3n?= Content-Type: multipart/alternative; boundary=f46d0435bffc46640704b265d297 X-Spam-Score: 0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (decker.christian[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 2.5 FREEMAIL_REPLY From and body contain different freemails -1.2 AWL AWL: From: address is in the auto white-list X-Headers-End: 1RTBfy-0000eW-DW Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Addressing rapid changes in mining power X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 12:11:43 -0000 --f46d0435bffc46640704b265d297 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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=F3n > 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 : > > On 2011 November 23 Wednesday, Jorge Tim=F3n wrote: > >> 2011/11/23, Andy Parkins : > >> > 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 ba= nd > > are > > rejected. > > > > > > Andy > > -- > > Dr Andy Parkins > > andyparkins@gmail.com > > > > > -- > Jorge Tim=F3n > > > -------------------------------------------------------------------------= ----- > 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 > --f46d0435bffc46640704b265d297 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable First of all I do agree that a method for adjusting the difficulty in a hug= e 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 distri= buted systems. Even the smallest drift would allow for forks in the chain a= ll over the place. Furthermore the delay in propagation will also cause for= ks.

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 i= n the paper, but it is more of a proof-of-existence before, as the containe= d timestamp cannot be trusted anyway.

Regards,
Chris

2011/11/23 Jorge Ti= m=F3n <timo= n.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 <andyp= arkins@gmail.com>:
> On 2011 November 23 Wednesday, Jorge Tim=F3n wr= ote:
>> 2011/11/23, Andy Parkins <andyparkins@gmail.com>:
>> > Let's abandon the idea of a target difficulty. =A0Instead= , every node just
>> >
>> =A0> generates the most difficulty block it can. =A0Simultaneou= sly, every node
>> =A0> is listening for "the most difficult block generated = before time T";
>> =A0> with T being
>> =A0> 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 ag= ainst
> the node's own clock and averaged network clock. =A0Blocks out of = that band
> are
> rejected.
>
>
> Andy
> --
> Dr Andy Parkins
> andyparkins@gmail.com
>


--
Jorge Tim=F3n

---------------------------------------------------------------------------= ---
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-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--f46d0435bffc46640704b265d297--