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 <andyparkins@gmail.com>) id 1RTETw-000544-SD
	for bitcoin-development@lists.sourceforge.net;
	Wed, 23 Nov 2011 15:11:28 +0000
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; 
Received: from mail-yw0-f47.google.com ([209.85.213.47])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1RTETu-0001l9-Mr
	for bitcoin-development@lists.sourceforge.net;
	Wed, 23 Nov 2011 15:11:28 +0000
Received: by ywb20 with SMTP id 20so1724462ywb.34
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 23 Nov 2011 07:11:21 -0800 (PST)
Received: by 10.204.148.75 with SMTP id o11mr24914805bkv.95.1322061080669;
	Wed, 23 Nov 2011 07:11:20 -0800 (PST)
Received: from dvr.localnet (mail.360visiontechnology.com. [92.42.121.178])
	by mx.google.com with ESMTPS id z15sm13108640bkv.4.2011.11.23.07.11.16
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 23 Nov 2011 07:11:16 -0800 (PST)
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>
X-Spam-Score: -1.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
	(andyparkins[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	-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
X-Headers-End: 1RTETu-0001l9-Mr
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 15:11:28 -0000

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