Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: =?iso-8859-1?Q?Michael_Gr=F8nager?= <gronager@ceptacle.com>
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: <CABr1YTebhitO4g-SarZ7H=aoG9a8zW1wd0rfR32o8i0vODbLJw@mail.gmail.com>
	<028C9CB5-A7C9-4042-BC00-269046E2DD19@ceptacle.com>
	<CALxbBHW4v2FohtaFi0MRey5RoBQodEK5kPsGCAv5xVmmDOOjZQ@mail.gmail.com>
	<201112221012.55565.andyparkins@gmail.com>
To: Andy Parkins <andyparkins@gmail.com>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Protocol extensions
Precedence: list

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