Message-ID: <1324781708.61136.YahooMailClassic@web120905.mail.ne1.yahoo.com>
Date: Sat, 24 Dec 2011 18:55:08 -0800 (PST)
From: Zell Faze <zellfaze@yahoo.com>
To: Joel Joonatan Kaartinen <joel.kaartinen@gmail.com>,
	Andy Parkins <andyparkins@gmail.com>
In-Reply-To: <201112221446.54526.andyparkins@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Protocol extensions
Precedence: list

I may be missing something, but perhaps the simplistic method is the best. =
 =0A=0AStart all nodes off with a certain level of trust.  Lets choose an a=
rbitrary number 5.=0AIf a node's trust level is high enough (lets say 10) f=
orward transactions it sends you without checking them.=0AIf a node's trust=
 level is low enough (lets say 0) discard any transactions they send you (i=
.e. don't forward them on).=0AFor nodes with a trust level between 1 and 9,=
 forward without checking between 1 and 9 out of every 10 transactions.  Ch=
eck the others, if they are valid, increase the trust level by 1, if they a=
re invalid decrease the trust level by 3.=0A=0AAll of the numbers mentioned=
 here (1-10, 1, 10, 1, 5, and 3) are arbitrary numbers that should be deter=
mined by the client or user-preferences instead of the protocol.  This woul=
d allow for clients to have varying amounts of initial trust/paranoia about=
 their peers.=0A=0ABy decreasing the amount of trust faster than we increas=
e it, we make it harder for untrustworthy clients to cheat us.  By having a=
 cut off point, we make it so that untrustworthy clients can not DDoS us.  =
By randomly verifying some transactions in the beginning, we make it harder=
 for a new client from DDoSing us, and we prevent our own trust level from =
being hurt too much for forwarding on invalid transactions.=0A=0AThe only p=
roblem I can personally see with this system is that if Node A trusts Node =
B with a 10 and Node C connects to Node A, then Node C can send  transactio=
ns that are invalid to Node C via Node A without Node C being any the wiser=
.  This would be stopped fairly quickly as Node B would catch on and stop f=
orwarding transactions, but it would be a problem for new Nodes.=0A=0AThis =
could be fixed (somewhat) by having a message that says not to trust a part=
icular node.=0A=0A--Zell Faze=0A=0A=0A=0A--- On Thu, 12/22/11, Andy Parkins=
 <andyparkins@gmail.com> wrote:=0A=0A> From: Andy Parkins <andyparkins@gmai=
l.com>=0A> Subject: Re: [Bitcoin-development] Protocol extensions=0A> To: "=
Joel Joonatan Kaartinen" <joel.kaartinen@gmail.com>=0A> Cc: bitcoin-develop=
ment@lists.sourceforge.net=0A> Date: Thursday, December 22, 2011, 9:46 AM=
=0A> On 2011 December 22 Thursday, Joel=0A> Joonatan Kaartinen wrote:=0A> >=
 On Thu, 2011-12-22 at 11:52 +0000, Andy Parkins=0A> wrote:=0A> > > Why sho=
uld they have to?=A0 Joining the=0A> network as a node is very low cost=0A>=
 > > to the other nodes.=A0 You can't force any=0A> node not to be lazy, si=
nce=0A> > > their option is to disconnect themselves.=A0=0A> As to maliciou=
sness, that is=0A> > > defended against because when a node negative=0A> an=
nounces a transaction,=0A> > > that transaction is going to be checked (not=
e=0A> that there is still no=0A> > > implicit trust) -- if a node is incorr=
ectly=0A> negative-announcing then it=0A> > > can justifiably be kicked.=0A=
> > =0A> > a node that is not doing any checking themselves can=0A> not rel=
iably=0A> > forward failed verifications without getting the blame=0A> for =
doing faulty=0A> > work. Those nodes would then have the incentive not to=
=0A> relay the failed=0A> > verifications. This ends up making it important=
 to=0A> know which nodes will=0A> > be checking transactions or not so you =
don't isolate=0A> yourself from other=0A> > nodes that are also checking tr=
ansactions.=0A> =0A> Yes; I appreciate that.=A0 It's the very point I'm=0A>=
 making.=A0 A node can choose =0A> what work to do, and should have a way o=
f forwarding the=0A> results of that work =0A> to other nodes.=A0 Transacti=
on verifification is the=0A> main one.=0A> =0A> Once a negative-announce me=
ssage exists, it wouldn't be=0A> hard to have the other =0A> two you need a=
s well: positive-announce and=0A> neutral-announce.=A0 At present we =0A> h=
ave only neutral-announce.=A0 However, as the need for=0A> super nodes and =
=0A> distributed verification gets bigger, having the forwarder=0A> able to=
 offer an =0A> opinion on the quality of a transaction seems ideal to=0A> m=
e.=A0 Dishonesty will =0A> get you isolated pretty quickly if you use=0A> p=
ositive-announce and negative-=0A> announce to lie.=0A> =0A> The problem wi=
th this is that it requires a web of trust as=0A> well as a web of =0A> con=
nections.=A0 The only way to gain an advantage from=0A> this classified =0A=
> forwarding is if you have some way of assigning enough=0A> trust so that =
you can =0A> forward a classified transaction _without_ checking it=0A> you=
rself.=A0 That doesn't =0A> sound like an easy problem though.=0A> =0A> =0A=
> =0A> Andy=0A> =0A> -- =0A> Dr Andy Parkins=0A> andyparkins@gmail.com=0A> =
=0A> -----Inline Attachment Follows-----=0A> =0A> -------------------------=
-----------------------------------------------------=0A> Write once. Port =
to many.=0A> Get the SDK and tools to simplify cross-platform app=0A> devel=
opment. Create =0A> new or port existing apps to sell to consumers worldwid=
e.=0A> Explore the =0A> Intel AppUpSM program developer opportunity.=0A> ap=
pdeveloper.intel.com/join=0A> http://p.sf.net/sfu/intel-appdev=0A> -----Inl=
ine Attachment Follows-----=0A> =0A> ______________________________________=
_________=0A> Bitcoin-development mailing list=0A> Bitcoin-development@list=
s.sourceforge.net=0A> https://lists.sourceforge.net/lists/listinfo/bitcoin-=
development=0A>