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 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 ; 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 To: Christian Decker 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> In-Reply-To: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--