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-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1ReeF2-0003uk-GE for bitcoin-development@lists.sourceforge.net; Sun, 25 Dec 2011 02:55:16 +0000 X-ACL-Warn: Received: from nm9-vm4.bullet.mail.ne1.yahoo.com ([98.138.91.169]) by sog-mx-1.v43.ch3.sourceforge.com with smtp (Exim 4.76) id 1ReeF0-0002cB-5L for bitcoin-development@lists.sourceforge.net; Sun, 25 Dec 2011 02:55:16 +0000 Received: from [98.138.90.52] by nm9.bullet.mail.ne1.yahoo.com with NNFMP; 25 Dec 2011 02:55:09 -0000 Received: from [98.138.87.7] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 25 Dec 2011 02:55:08 -0000 Received: from [127.0.0.1] by omp1007.mail.ne1.yahoo.com with NNFMP; 25 Dec 2011 02:55:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 791181.16444.bm@omp1007.mail.ne1.yahoo.com Received: (qmail 61587 invoked by uid 60001); 25 Dec 2011 02:55:08 -0000 X-YMail-OSG: _ZYq76IVM1nSuiBrJUG1X3MLHsBoMp81MkDSZFN01ZQJIgg r9Wi1K6YlRrdhQZ7nuKvEPJkGD3SOrNiya87g2GAcDkguh9xq5OiDEbpbnRw W_9tG30vKPBf0z7Ds18CVGI6tHBj1upltLYvH2RS5fbyfYW_PpE26EXebBju wqBIEgoHww.Q4XFci6re1ye25Sg9ZbdjenC3IapvCVsOq4iCc..LXuFd6h1E o6gssYNw9EnB1xMzuvmn._ehBcqadbntYdZOJM0812H_0tF1Q5zhaKaYAKcl WdP94vKvNWEMqN_kVkVlhvarOL.qxGGIPitnSIRlVsrYQj4KEihCjd4miFRJ xawLti6hFHrAVyFVZFIPgDHIBm4q198TqbTDVLqlL2Clt1fnO7FLrgTvJIIh gll3kxld1UO2sgVxVhDEeHUAdAdyWWKqfEg8rtv6Hne592tyKWtjW9cZ.rys 5fFpfdlv7llw8E6v0QLvBNbxooKKxZhJLE8UglAHF5RD.IH90MafxW3d2eEz F.nm.WqgHg_p30XOviz4DDHdIen5FeN2Ph01h673iZT_12hbOW7_bSV4Pixa esId0N9aLjw-- Received: from [108.8.7.210] by web120905.mail.ne1.yahoo.com via HTTP; Sat, 24 Dec 2011 18:55:08 PST X-Mailer: YahooMailClassic/15.0.4 YahooMailWebService/0.8.115.331698 Message-ID: <1324781708.61136.YahooMailClassic@web120905.mail.ne1.yahoo.com> Date: Sat, 24 Dec 2011 18:55:08 -0800 (PST) From: Zell Faze To: Joel Joonatan Kaartinen , Andy Parkins 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 X-Spam-Score: -1.3 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (zellfaze[at]yahoo.com) -2.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [98.138.91.169 listed in list.dnswl.org] 2.5 FREEMAIL_REPLY From and body contain different freemails -1.1 AWL AWL: From: address is in the auto white-list X-Headers-End: 1ReeF0-0002cB-5L 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: Sun, 25 Dec 2011 02:55:16 -0000 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= wrote:=0A=0A> From: Andy Parkins =0A> Subject: Re: [Bitcoin-development] Protocol extensions=0A> To: "= Joel Joonatan Kaartinen" =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>