Zell Faze [ARCHIVE] on Nostr: 📅 Original date posted:2011-12-25 🗒️ Summary of this message: A trust-based ...

📅 Original date posted:2011-12-25
🗒️ Summary of this message: A trust-based system for nodes in a blockchain network is proposed, where nodes are assigned an initial trust level and transactions are forwarded based on this level. The trust level can be adjusted based on the validity of transactions, and the system can be customized by users. The system aims to prevent untrustworthy nodes from cheating and DDoSing the network. However, there is a potential issue with new nodes being able to send invalid transactions through trusted nodes.
📝 Original message: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 at gmail.com> wrote:

> From: Andy Parkins <andyparkins at gmail.com>
> Subject: Re: [Bitcoin-development] Protocol extensions
> To: "Joel Joonatan Kaartinen" <joel.kaartinen at gmail.com>
> Cc: bitcoin-development at 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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>