From: Zell Faze <zellfaze@yahoo•com>
To: Joel Joonatan Kaartinen <joel.kaartinen@gmail•com>,
Andy Parkins <andyparkins@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Protocol extensions
Date: Sat, 24 Dec 2011 18:55:08 -0800 (PST) [thread overview]
Message-ID: <1324781708.61136.YahooMailClassic@web120905.mail.ne1.yahoo.com> (raw)
In-Reply-To: <201112221446.54526.andyparkins@gmail.com>
I may be missing something, but perhaps the simplistic method is the best.
Start all nodes off with a certain level of trust. Lets choose an arbitrary number 5.
If a node's trust level is high enough (lets say 10) forward transactions it sends you without checking them.
If a node's trust level is low enough (lets say 0) discard any transactions they send you (i.e. don't forward them on).
For nodes with a trust level between 1 and 9, forward without checking between 1 and 9 out of every 10 transactions. Check the others, if they are valid, increase the trust level by 1, if they are invalid decrease the trust level by 3.
All of the numbers mentioned here (1-10, 1, 10, 1, 5, and 3) are arbitrary numbers that should be determined by the client or user-preferences instead of the protocol. This would allow for clients to have varying amounts of initial trust/paranoia about their peers.
By decreasing the amount of trust faster than we increase 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.
The only problem 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 transactions 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 forwarding transactions, but it would be a problem for new Nodes.
This could be fixed (somewhat) by having a message that says not to trust a particular node.
--Zell Faze
--- On Thu, 12/22/11, Andy Parkins <andyparkins@gmail•com> wrote:
> From: Andy Parkins <andyparkins@gmail•com>
> Subject: Re: [Bitcoin-development] Protocol extensions
> To: "Joel Joonatan Kaartinen" <joel.kaartinen@gmail•com>
> Cc: bitcoin-development@lists•sourceforge.net
> Date: Thursday, December 22, 2011, 9:46 AM
> On 2011 December 22 Thursday, Joel
> Joonatan Kaartinen wrote:
> > On Thu, 2011-12-22 at 11:52 +0000, Andy Parkins
> wrote:
> > > Why should they have to? Joining the
> network as a node is very low cost
> > > to the other nodes. You can't force any
> node not to be lazy, since
> > > their option is to disconnect themselves.
> As to maliciousness, that is
> > > defended against because when a node negative
> announces a transaction,
> > > that transaction is going to be checked (note
> that there is still no
> > > implicit trust) -- if a node is incorrectly
> negative-announcing then it
> > > can justifiably be kicked.
> >
> > a node that is not doing any checking themselves can
> not reliably
> > forward failed verifications without getting the blame
> for doing faulty
> > work. Those nodes would then have the incentive not to
> relay the failed
> > verifications. This ends up making it important to
> know which nodes will
> > be checking transactions or not so you don't isolate
> yourself from other
> > nodes that are also checking transactions.
>
> Yes; I appreciate that. It's the very point I'm
> making. A node can choose
> what work to do, and should have a way of forwarding the
> results of that work
> to other nodes. Transaction verifification is the
> main one.
>
> Once a negative-announce message exists, it wouldn't be
> hard to have the other
> two you need as well: positive-announce and
> neutral-announce. At present we
> have only neutral-announce. However, as the need for
> super nodes and
> distributed verification gets bigger, having the forwarder
> able to offer an
> opinion on the quality of a transaction seems ideal to
> me. Dishonesty will
> get you isolated pretty quickly if you use
> positive-announce and negative-
> announce to lie.
>
> The problem with this is that it requires a web of trust as
> well as a web of
> connections. The only way to gain an advantage from
> this classified
> forwarding is if you have some way of assigning enough
> trust so that you can
> forward a classified transaction _without_ checking it
> yourself. That doesn't
> sound like an easy problem though.
>
>
>
> Andy
>
> --
> Dr Andy Parkins
> andyparkins@gmail•com
>
> -----Inline Attachment Follows-----
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app
> development. Create
> new or port existing apps to sell to consumers worldwide.
> Explore the
> Intel AppUpSM program developer opportunity.
> appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> -----Inline Attachment Follows-----
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
next prev parent reply other threads:[~2011-12-25 2:55 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-17 7:41 Eric Lombrozo
2011-12-17 13:13 ` Michael Grønager
2011-12-17 13:37 ` Christian Decker
[not found] ` <CABsx9T0puk3CWH1cfNHMSVEoCPaLJJWNJ+H5ObCERZrzMbrTyA@mail.gmail.com>
2011-12-17 19:06 ` Gavin Andresen
2011-12-17 21:49 ` theymos
2011-12-18 0:44 ` Jordan Mack
2011-12-18 1:07 ` Jeff Garzik
2011-12-18 1:27 ` Jordan Mack
2011-12-18 14:16 ` Andy Parkins
2011-12-18 17:09 ` theymos
2011-12-18 18:06 ` Alan Reiner
2011-12-18 18:47 ` Amir Taaki
2011-12-18 19:37 ` Jorge Timón
2011-12-17 19:28 ` Gregory Maxwell
2011-12-17 20:34 ` Christian Decker
2011-12-18 21:19 ` Stefan Thomas
2011-12-19 21:43 ` Jordan Mack
2011-12-20 9:10 ` Wladimir
2011-12-20 10:44 ` Nicolas Fischer
2011-12-21 0:47 ` Kyle Henderson
2011-12-21 8:50 ` Michael Grønager
2011-12-21 11:42 ` Eric Lombrozo
2011-12-21 12:41 ` Michael Grønager
2011-12-21 16:10 ` Christian Decker
2011-12-22 9:18 ` Michael Grønager
2011-12-22 10:12 ` Andy Parkins
2011-12-22 10:27 ` Michael Grønager
2011-12-22 11:52 ` Andy Parkins
2011-12-22 12:14 ` Joel Joonatan Kaartinen
2011-12-22 12:26 ` Christian Decker
2011-12-22 12:42 ` Michael Grønager
2011-12-22 14:46 ` Andy Parkins
2011-12-25 2:55 ` Zell Faze [this message]
2011-12-21 17:17 ` Jordan Mack
2011-12-22 9:19 ` Michael Grønager
2011-12-21 6:19 Eric Lombrozo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1324781708.61136.YahooMailClassic@web120905.mail.ne1.yahoo.com \
--to=zellfaze@yahoo$(echo .)com \
--cc=andyparkins@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=joel.kaartinen@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox