path: root/a5/32a4d66932a58f4c4d2d6d44f397cdb0a09137

Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <decker.christian@gmail.com>) id 1RTDzH-0003jw-Po
	for bitcoin-development@lists.sourceforge.net;
	Wed, 23 Nov 2011 14:39:47 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.160.175 as permitted sender)
	client-ip=209.85.160.175;
	envelope-from=decker.christian@gmail.com;
	helo=mail-gy0-f175.google.com; 
Received: from mail-gy0-f175.google.com ([209.85.160.175])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1RTDzC-0000jc-8E
	for bitcoin-development@lists.sourceforge.net;
	Wed, 23 Nov 2011 14:39:47 +0000
Received: by ghy10 with SMTP id 10so1875662ghy.34
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 23 Nov 2011 06:39:36 -0800 (PST)
Received: by 10.152.105.132 with SMTP id gm4mr14498257lab.39.1322059176141;
	Wed, 23 Nov 2011 06:39:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.20.134 with HTTP; Wed, 23 Nov 2011 06:38:55 -0800 (PST)
In-Reply-To: <201111231313.12534.andyparkins@gmail.com>
References: <201111231035.48690.andyparkins@gmail.com>
	<CAGQP0AEZ9CUNd9ERyMsx741bqjLptY4pPRU6EmxQcD7kR8bdbw@mail.gmail.com>
	<CALxbBHVEvCqun0aX_9awGhW39h5cx0jLPx2ptoesBcmKGO-_Dw@mail.gmail.com>
	<201111231313.12534.andyparkins@gmail.com>
From: Christian Decker <decker.christian@gmail.com>
Date: Wed, 23 Nov 2011 15:38:55 +0100
Message-ID: <CALxbBHW2KGv=sEvYqpGGsy8jjJ3+yE02BegwPhjGapuT9z7v_Q@mail.gmail.com>
To: Andy Parkins <andyparkins@gmail.com>
Content-Type: multipart/alternative; boundary=f46d040715f590e1e104b267e3d1
X-Spam-Score: 1.3 (+)
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
	-0.6 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1RTDzC-0000jc-8E
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 23 Nov 2011 14:39:47 -0000

--f46d040715f590e1e104b267e3d1
Content-Type: text/plain; charset=ISO-8859-1

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

--f46d040715f590e1e104b267e3d1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Just brainstorming here, no idea if this would work:<br><ul><li>Pick any ol=
d block</li><li>Create a chain fork by creating simpler blocks on top of yo=
ur chosen one</li><li>The chain will not be accepted by others</li><li>At s=
ome point you might find an incredibly hard block that makes your forked ch=
ain the hardest one in the network</li>

<li>Suddenly all your blocks are valid and you force people to switch to yo=
ur forked chain</li></ul>If this is possible it would allow you to revoke a=
ll transactions and claim all the mined coins since you forked. My point is=
 that the notion of hardest chain is not so simple.<br>

<br>The difficulty of invalidating a chain is dramatically reduced with you=
r time window approach, by not requiring a given difficulty, and relying on=
 synchronized time windows.<br><br>Regards,<br>Chris<br><br><div class=3D"g=
mail_quote">

On Wed, Nov 23, 2011 at 2:13 PM, Andy Parkins <span dir=3D"ltr">&lt;<a href=
=3D"mailto:andyparkins@gmail.com">andyparkins@gmail.com</a>&gt;</span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex;">

<div class=3D"im">On 2011 November 23 Wednesday, Christian Decker wrote:<br=
>
<br>
&gt; The current block generation with a fixed difficulty was chosen becaus=
e it<br>
&gt; it clear when to adjust and to what target difficulty it has to be<br>
&gt; adjusted. If we were to use synchronized time windows and select the<b=
r>
&gt; hardest block it gets incredibly complicated as synchronization is not=
<br>
&gt; possible in distributed systems. Even the smallest drift would allow f=
or<br>
&gt; forks in the chain all over the place. Furthermore the delay in propag=
ation<br>
&gt; will also cause forks.<br>
&gt;<br>
&gt; If 1/2 of the network see one block as the hardest, and for the rest o=
f the<br>
&gt; network it came too late then we&#39;ll have a fork that stays with us=
 quite a<br>
&gt; while.<br>
&gt;<br>
&gt; The block chain is described as a timestamp server in the paper, but i=
t is<br>
&gt; more of a proof-of-existence before, as the contained timestamp cannot=
 be<br>
&gt; trusted anyway.<br>
<br>
</div>These are reasonable objections. =A0My counter is this:<br>
<br>
Let&#39;s view block difficulty as a measure of time, not time itself. =A0T=
he<br>
timestamp is merely a convenience for the block. =A0You cannot fake the<br>
computing power needed for a particular difficulty; so the hardest chain<br=
>
always wins (note: hardest chain).<br>
<br>
If I am a miner, I have two choices:<br>
<br>
 =A0(a) try to replace the top block on the current hardest chain<br>
 =A0(b) try to append to the current hardest chain<br>
<br>
Either of these is acceptable; but in case (a) I have to generate a more<br=
>
difficult block to replace it; in case (b), at the start of the window, any=
<br>
difficulty is acceptable (however, I&#39;m competing with other miners, so =
_any_<br>
difficulty won&#39;t beat them).<br>
<br>
The rule then is that you&#39;re trying to win the one block reward that is=
<br>
available every 10 minutes; and your peers will be rejecting blocks with<br=
>
timestamps that are lies.<br>
<br>
Perhaps an example...<br>
<br>
=A0- I (a node), download the blockchain<br>
=A0- The blockchain has N potential heads. =A0Each of those heads has a tim=
e, t<br>
 =A0 and a sum_of_difficulty.<br>
=A0- The next block reward is going to go to the highest difficulty with<br=
>
 =A0 t &lt; timestamp &lt; (t + T) _and_ verified timestamp (i.e. not recei=
ved more<br>
 =A0 than, say 5 minutes, from its claimed timestamp).<br>
=A0- I can choose any head to start generating from, but given that it&#39;=
s the<br>
 =A0 highest difficulty chain that&#39;s going to win the next reward (not =
the<br>
 =A0 highest difficulty block), I will surely pick the most difficult?<br>
=A0- A rogue miner then issues a block with a fake timestamp; it actually<b=
r>
 =A0 generated at (t + T + 5) but claims (t + 5). =A0Should I start using<b=
r>
 =A0 that block as my new head? =A0Obviously not, because my peers might de=
cide<br>
 =A0 that it is a lie and reject it because it was received too late, makin=
g my<br>
 =A0 work useless. =A0It is in my interest to pick a head that is honest.<b=
r>
<br>
Resolving forks is easy:<br>
<br>
=A0- 50 coins every ten minutes only<br>
=A0- most difficult chain wins<br>
<br>
I&#39;m certainly not saying it&#39;s a simple change. =A0There are certain=
ly areas I<br>
haven&#39;t thought about, and could be game-overs; but I do like the idea =
of<br>
there being no target difficulty, and instead the blocks are issued at a fi=
xed<br>
ten minute rate (or rather the rewards are).<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
Andy<br>
<br>
--<br>
Dr Andy Parkins<br>
<a href=3D"mailto:andyparkins@gmail.com">andyparkins@gmail.com</a><br>
</div></div><br>-----------------------------------------------------------=
-------------------<br>
All the data continuously generated in your IT infrastructure<br>
contains a definitive record of customers, application performance,<br>
security threats, fraudulent activity, and more. Splunk takes this<br>
data and makes sense of it. IT sense. And common sense.<br>
<a href=3D"http://p.sf.net/sfu/splunk-novd2d" target=3D"_blank">http://p.sf=
.net/sfu/splunk-novd2d</a><br>_____________________________________________=
__<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br>

--f46d040715f590e1e104b267e3d1--