Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.213.47 as permitted sender)
	client-ip=209.85.213.47; envelope-from=andyparkins@gmail.com;
	helo=mail-yw0-f47.google.com; 
From: Andy Parkins <andyparkins@gmail.com>
To: Christian Decker <decker.christian@gmail.com>
Date: Wed, 23 Nov 2011 15:11:07 +0000
User-Agent: KMail/1.13.6 (Linux/3.0.0-1-686-pae; KDE/4.6.3; i686; ; )
References: <201111231035.48690.andyparkins@gmail.com>
	<201111231313.12534.andyparkins@gmail.com>
	<CALxbBHW2KGv=sEvYqpGGsy8jjJ3+yE02BegwPhjGapuT9z7v_Q@mail.gmail.com>
In-Reply-To: <CALxbBHW2KGv=sEvYqpGGsy8jjJ3+yE02BegwPhjGapuT9z7v_Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1449198.ETQnSKqp99";
	protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <201111231511.14980.andyparkins@gmail.com>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Addressing rapid changes in mining power
Precedence: list

--nextPart1449198.ETQnSKqp99
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable

On 2011 November 23 Wednesday, Christian Decker wrote:
> Just brainstorming here, no idea if this would work:
>=20
>    - 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
>=20
> If this is possible it would allow you to revoke all transactions and cla=
im
> 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=
=20
"hardest chain", then I have indeed reverted all the existing transactions.=
=20

Look at CBlock::AddToBlockIndex(),=20

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

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

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

I'm not entirely convinced that this method of totalling chain work is the=
=20
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 give=
n=20
difficulty isn't required, but a higher difficulty beats a lower difficulty=
=2E =20
So whatever the hashing power of the network at that moment, it's used.  Th=
at=20
makes the chain more secure, not less.


Andy

=2D-=20
Dr Andy Parkins
andyparkins@gmail.com

--nextPart1449198.ETQnSKqp99
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEABECAAYFAk7NDQsACgkQwQJ9gE9xL21W6gCgvU8lonkOAd6hreW1lINpIIQ3
JWYAnRaes5N1uLcDjMBWSCHpUJHpGXDw
=0Mxq
-----END PGP SIGNATURE-----

--nextPart1449198.ETQnSKqp99--