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-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RdfsG-0006Mr-AC for bitcoin-development@lists.sourceforge.net; Thu, 22 Dec 2011 10:27:44 +0000 X-ACL-Warn: Received: from backup-server.nordu.net ([193.10.252.66]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1RdfsE-0004oD-RC for bitcoin-development@lists.sourceforge.net; Thu, 22 Dec 2011 10:27:44 +0000 Received: from [109.105.106.215] ([109.105.106.215]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pBMARWnl017746 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 22 Dec 2011 11:27:33 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_Gr=F8nager?= In-Reply-To: <201112221012.55565.andyparkins@gmail.com> Date: Thu, 22 Dec 2011 11:27:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <23F92B83-4E96-401B-8A1C-3E6FE9DD8A8B@ceptacle.com> References: <028C9CB5-A7C9-4042-BC00-269046E2DD19@ceptacle.com> <201112221012.55565.andyparkins@gmail.com> To: Andy Parkins X-Mailer: Apple Mail (2.1251.1) X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1RdfsE-0004oD-RC Cc: bitcoin-development@lists.sourceforge.net 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:27:44 -0000 It is analog to getting assigned a random part (based on IP) of the = hashspace and then only verify transactions within this fraction. But, there is in fact a subtle difference: If anyone can choose to = verify at random, you will see lazy implementations where random means = none, and as it is random you cannot, from the outside, judge if a node = is taking part in the validation work or if it just benefitting from = others announcements. In the hash space part, you can monitor peers and = see if they did not tell you about a failed validation and then = disconnect from them as they are either malicious or lazy. Besides from that, I like a setup where we scream about failed = verifications, but keep a low profile on things that actually = verifies... /M On 22/12/2011, at 11:12, Andy Parkins wrote: > On 2011 December 21 Wednesday, Christian Decker wrote: >=20 >> 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 = (otherwise >> 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. >=20 > 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 add 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 = forward=20 > the negative-announce. >=20 > Miners can then listen for negative-announcements and use them to = decide were=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. >=20 > (I've actually mentioned this idea before, but that time I was using = it as a=20 > double-spend prevention method). >=20 >=20 >=20 > Andy >=20 > --=20 > Dr Andy Parkins > andyparkins@gmail.com