From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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> <201111231313.12534.andyparkins@gmail.com> From: Christian Decker Date: Wed, 23 Nov 2011 15:38:55 +0100 Message-ID: To: Andy Parkins 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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:
  • Pick any ol= d block
  • Create a chain fork by creating simpler blocks on top of yo= ur chosen one
  • The chain will not be accepted by others
  • At s= ome point you might find an incredibly hard block that makes your forked ch= ain the hardest one in the network
  • Suddenly all your blocks are valid and you force people to switch to yo= ur forked chain
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.

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.

Regards,
Chris

On Wed, Nov 23, 2011 at 2:13 PM, Andy Parkins <andyparkins@gmail.com> wrot= e:
On 2011 November 23 Wednesday, Christian Decker wrote:
> The current block generation with a fixed difficulty was chosen becaus= e 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 f= or
> forks in the chain all over the place. Furthermore the delay in propag= ation
> will also cause forks.
>
> If 1/2 of the network see one block as the hardest, and for the rest o= f 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 i= t is
> more of a proof-of-existence before, as the contained timestamp cannot= be
> trusted anyway.

These are reasonable objections. =A0My counter is this:

Let's view block difficulty as a measure of time, not time itself. =A0T= he
timestamp is merely a convenience for the block. =A0You 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:

=A0(a) try to replace the top block on the current hardest chain
=A0(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...

=A0- I (a node), download the blockchain
=A0- The blockchain has N potential heads. =A0Each of those heads has a tim= e, t
=A0 and a sum_of_difficulty.
=A0- The next block reward is going to go to the highest difficulty with =A0 t < timestamp < (t + T) _and_ verified timestamp (i.e. not recei= ved more
=A0 than, say 5 minutes, from its claimed timestamp).
=A0- I can choose any head to start generating from, but given that it'= s the
=A0 highest difficulty chain that's going to win the next reward (not = the
=A0 highest difficulty block), I will surely pick the most difficult?
=A0- A rogue miner then issues a block with a fake timestamp; it actually =A0 generated at (t + T + 5) but claims (t + 5). =A0Should I start using =A0 that block as my new head? =A0Obviously not, because my peers might de= cide
=A0 that it is a lie and reject it because it was received too late, makin= g my
=A0 work useless. =A0It is in my interest to pick a head that is honest.
Resolving forks is easy:

=A0- 50 coins every ten minutes only
=A0- most difficult chain wins

I'm certainly not saying it's a simple change. =A0There are certain= ly 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 fi= xed
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-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--f46d040715f590e1e104b267e3d1--