From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RdfeG-0003El-MU for bitcoin-development@lists.sourceforge.net; Thu, 22 Dec 2011 10:13:16 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.175 as permitted sender) client-ip=74.125.82.175; envelope-from=andyparkins@gmail.com; helo=mail-we0-f175.google.com; Received: from mail-we0-f175.google.com ([74.125.82.175]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1RdfeA-0003nk-Cd for bitcoin-development@lists.sourceforge.net; Thu, 22 Dec 2011 10:13:16 +0000 Received: by werm13 with SMTP id m13so4867389wer.34 for ; Thu, 22 Dec 2011 02:13:04 -0800 (PST) Received: by 10.216.138.148 with SMTP id a20mr11070716wej.15.1324548784291; Thu, 22 Dec 2011 02:13:04 -0800 (PST) Received: from dvr.localnet (mail.360visiontechnology.com. [92.42.121.178]) by mx.google.com with ESMTPS id di5sm21157448wib.3.2011.12.22.02.13.02 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Dec 2011 02:13:02 -0800 (PST) From: Andy Parkins To: bitcoin-development@lists.sourceforge.net Date: Thu, 22 Dec 2011 10:12:48 +0000 User-Agent: KMail/1.13.6 (Linux/3.0.0-1-686-pae; KDE/4.6.3; i686; ; ) References: <028C9CB5-A7C9-4042-BC00-269046E2DD19@ceptacle.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3250111.n8fbuK3pA9"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201112221012.55565.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 0.0 AWL AWL: From: address is in the auto white-list X-Headers-End: 1RdfeA-0003nk-Cd Cc: Michael Subject: Re: [Bitcoin-development] Protocol extensions 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: Thu, 22 Dec 2011 10:13:16 -0000 --nextPart3250111.n8fbuK3pA9 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable On 2011 December 21 Wednesday, Christian Decker wrote: > Supernodes will be those nodes that verify all transactions and make them > available to miners. Since miners will become more and more specialized > these supernodes are likely to be owned by the miners themself. To be a > miner either you need to verify all the transactions you include (otherwi= se > others might be able to find an error in your block and thus drop it) or > have someone that verifies them for you. In the end I think we'll end up > with a hierarchical network, with the miners/supernodes tighly > interconnected at the top and the lightweight clients that simply verify > transactions (or their inputs to be precise) that are destined for them at > the bottom. A thought occurred to me. We already run a decentralised system, but it's= =20 done by making everyone duplicate all other work. There is no fundamental= =20 reason why all work needs to be duplicated though. What about this: every= =20 node randomly chooses whether to verify any particular transaction. If we= =20 assume the network is large and the random factor is correctly chosen, then= we=20 can still guarantee that every transaction is verified. Then, we simply ad= d a=20 protocol message that is a negative-announce transaction. That is to say, = we=20 give nodes a way of telling other nodes that they think a transaction is=20 invalid. The other nodes are then free to verify _that_ assertion and forw= ard=20 the negative-announce. Miners can then listen for negative-announcements and use them to decide we= re=20 to dedicate their verification efforts. They then don't need to verify all= =20 (or perhaps even any) transactions themselves and can dedicate their=20 processing power to mining. (I've actually mentioned this idea before, but that time I was using it as = a=20 double-spend prevention method). Andy =2D-=20 Dr Andy Parkins andyparkins@gmail.com --nextPart3250111.n8fbuK3pA9 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) iEYEABECAAYFAk7zAqEACgkQwQJ9gE9xL22LZwCeO9nXVb+/ILPidMv5rPAG5h3F OfUAnAuEu5WrgJ2n965CDfwKe/AkX1MY =WJHC -----END PGP SIGNATURE----- --nextPart3250111.n8fbuK3pA9--