There's the criticism I was looking for :)
On Sunday 30 November 2003 02:20 pm, Jim Dixon wrote:
> On Sun, 30 Nov 2003 [EMAIL PROTECTED] wrote:
> > The idea is this: We eliminate the notion of HTL. Instead we replace
> > it with a trust based system with TTL.
>
> ...
>
> > void processRequest(Node node,Key key, TTL ttl)
> > {
> > float load=getCurrentLoad(); //Check our current load.
> >
> > //Tenitively subtract the maximum amount of credit that the node could
> > owe us. //Subtract returns the amount it took away. (never more than
> > there was there) float credit = node.credit.subtract(ttl * 1.414214);
>
> This is a penalty imposed on the requestor, refunded only if the request
> is eventually successful.
Not all of it is refunded. Only the difference between that and the eventual
cost of the request. We just subtract the maximal possible cost, temporarily
to be safe.
> > void requestComplete( Node requester, Node provider, TTL requesterTTL,
> > TTL providerTTL, float requesterTime, float providerTime, bool
> > successful) {
> > if (successful)
> > {
> > if ( requester != me )
> > { //add back the amount we took away minus the amount they owe
> > us.
> > requester.trust.add( requesterTTL * 1.414214 - Max( 0 ,
> > squareRoot( 2
> > * requesterTTL^2 - requesterTime^2 ) ) ); requester.trustInMe.add( Max(
> > 0 , squareRoot( 2 * requesterTTL^2 - requesterTime^2 ) ) ); }
> > //Pay out. Pay up.
> > if ( provider != me )
> > {
> > provider.trust.add( Max( 0 , squareRoot( 2 * providerTTL^2 -
> > providerTime^2 ) ) ); //add back the amount they took away minus the
> > amount we owe them. provider.trustInMe.add( providerTTL * 1.414214 - Max(
> > 0 , squareRoot( 2 * providerTTL^2 - providerTime^2 ) ) ); }
> > }
> > else
> > {
> > //everything already subtracted. Nothing to add.
> > }
> > }
>
> While the details are not all that clear and the code doesn't quite make
> sense, a network adopting this approach would suffer from grave defects.
>
> A. THE NETWORK WOULD NEVER LEAVE THE ttl==0 PHASE.
>
> In the early stages of network development, all nodes would be at zero
> credit, and so all processRequest calls would be rejected. End of story,
> really ;-)
Right, must be ways to infuse trust into the system.
> However, there is a vague proposal for ttl==0 requests giving some small
> amount of credit.
Actually, I think it should be rather large. Like the full amount for a normal
request. That way, there is plenty of trust comming in. However TTL=0 is only
handled if we are in a non-overload situation. Hopefully by the time we
become overloaded, we'll have enough trust to work with.
> These would be treated as requests with large HTL are
> now; the proposal is for HTL==25. Let's say that a node acquires some
> credit in this way and then makes a request using the proposed ttl>0
> protocol. Freenet experience so far is that that request is unlikely to
> succeed. The penalty is ttl*1.4. End of story, really; any credit gained
> using the ttl==0 protocol is very likely to disappear immediately. The
> network is stable in a state where all nodes have no credit with one
> another.
Excellent point. That gives a target rate for infusion of trust. Trust needs
to be being created at a rate of 1.4*ProportionOfLigitimateDNF*RequestRate.
Good point. I'll work on that.
> B. ONE-SHOT INJECTION OF CREDIT
>
> Let's say that there is a one-time injection of credit into a brand-new
> network. There are two likely outcomes. In the first, the more likely
> case, because of lack of specialization, everyone simply slides back to
> zero credit. This occurs because the penalty for failure is high and the
> chance of success is low, as no one is specialized.
>
> C. METASTABLE: A FEW STARS, MOST NODES BROKE
>
> In the second state (far less likely, in my opinion), a few nodes
> specialize narrowly and hold to their specializations. The rest slide
> back to no credit. This state is at least metastable: everyone learns
> who is reliable, and so requests from them succeed and gain them credit.
> The request chains to these stars rapidly become very short -- in fact,
> most requests should be direct.
Yes, but you said your self. Those that have learned to request from the well
established nodes, will gain credit from those that ask them for the data.
Then they will look good to those further away. They gain even more credit if
they get lucky and happen to return some data from their store. The credit
starts to spread out.
> Most requests to other nodes fail, and they remain broke. They trade only
> at ttl==0.
Trading at TTL==0 does give some credit. However you could argue that if a
well established node, with good performance and a big data store, was where
most of the data was comming from, then the credit would all be on the side
of those routing in the direction toward the center node.
(Many nodes would be gaining credit because each gives a fixed amount to the
next up stream node. Even there is only a fixed amount given out, Owing one
node a request and having credit to ask for one on another, is actually a
very good situation, even though you have no net trust gain. This is because
if you do this 5 times, then sooner or later 5 requests will come in, and for
each of those you have 5 places to route to. So then you can gain real
credit.)
I say I don't think all the trust would end up on the sides of nodes pointing
towards the center, because we route biased on the key. So I don't think
there will ever be a situation where all key values get routed in the same
direction. Even with just 2 or 3 main nodes, I think they would not be near
to one another. So then trust is gained by all the nodes along the way, and
even requests with TTL==0 give 'borrowed' trust to intermediate nodes, so
they could route effectively without any problems. This would mean that the
whole network should be on it's feet in a fairly short order.
> The stars can trade among themselves successfully. They know each other
> well, and all requests between them are direct.
OK.
> In this state, there is minimal replication, because request chains are
> short. There is also minimal anonymity for the same reason. In other
> words, this protocol might work for some nodes, but it ain't Freenet.
Request chains can only get so much shorter unless, the star nodes, or nodes
that connect to them, allow an unlimited number of connections. Besides, the
nodes along the chain will still cache the data. There is the same amount of
replication as there ever was.
There is exactly the same level of plausible deniability for the original
requester and the inserter of the data. The host where the data is stored
currently has no deniability. Faster routing does not make the system any
less anonymous. This has changed none of the fundamental aspects of Freenet.
> D. ATTACK ON A STAR
>
> A cluster of nodes can easily attack a star by agreeing among themselves
> to subdivide its specialization, cooperating among themselves as described
> in E.
Nodes should naturally divide specialization, and cache whatever gives them
the most benefit.
> They will become more attractive in each subdivision, so traffic
> will shift to them.
Good.
> The natural result is for the star to fall back to
> zero credit status.
No, It will move or narrow it's specialization to maximize it's credit gain.
Secondly no-matter if they completely took every request that was ever going
to be routed to the other node, it does not LOOSE credit. It keeps what it
has. Which should be enough to get fetch data for any node that happens to
notice it. And that is enough to keep it 'in the black'.
> Alternatively, all nodes in the cluster could just adopt the same
> specialization as the star. If there are N nodes in the cluster, the star
> should lose N/(N+1) of its traffic. The natural result is that the star
> slides back towards zero credit.
The other node will move else where, in terms of specialization long before it
makes enough original requests to go back to 0.
> One would have to experiment to see which tactic is more successful. ;-)
>
> E. COOPERATE TO CONQUER
>
> A cluster of nodes can agree to divide all of keyspace among them. Each
> will give unlimited credit to any node. Each either handles requests
> directly if the key lies in its range or forwards the request to the
> cluster node responsible for the key. Requests are never rejected. If
> the key is not held by the appropriate node, it gets it, if necessary
> using the ttl==0 protocol. It always names itself as the source.
If we are not overloaded, we don't reject. Making your self the source does
not affect credit.
> The proposed protocol has no penalty for this kind of behaviour.
Why should there be. It is perfectly normal and acceptable network behavior.
You would want nodes on a trusted LAN to have the ability to know what each
has in their stores and give each unlimited trust.
> The
> cluster nodes become stars and accumulate credit. They use this credit to
> attack non-cluster stars. They can do this in a variety of ways, for
> example by asking random nodes in the network for data in the range of
> specialization of a star but not held by it; the appropriate cluster node
> has it, but won't give it to the star under attack. The cluster can also
> use the method described in D.
OK. That is a problem. That is an anti-specialization attack. It is possible
on the current network. It is not as bad under a trust based network, because
the trust is lower when it reaches the target, than what it left with, and
also because it costs trust to launch. If you have ideas on how to prevent
this under ANY network, submit them to the list.
> F. SYBIL ATTACK
>
> A single node with suffient capacity can pretend to be N nodes, and then
> the N nodes can divide key space between them and conquer the network as
> described in E.
That is not an attack. There is no difference between one big and several
little nodes. It would more efficient to run one big one. But anyway, yes,
anti-specialization is still a problem, but that is really a flaw in
NGrouting.
> > Problems this solves.
> > 1. No single user can abuse the network.
>
> There are a number of abuses possible. See F, for example.
Amended statement: No single user can do more net harm, In terms of request
seconds delayed, than they benefited the network in the same measure.
> > 2. Users that donate more in their data store or bandwidth get
> > rewarded by better network performance.
> > 3. NGrouting can have accurate estimates because it does not need to
> > know pDNF which previously was calculated without taking into account
> > the HTL.
> > 4. All data will ether be found or fail in a fixed time frame.
>
> There are no timeouts in the proposed protocol. A rogue node can just use
> a different processRequest, one that ignores the TTL. There is no penalty
> for this.
So, what. What are they going to do? Ask for some data and then drop it when
it gets sent to them? or are they going to continue to process a request
anyway, even after it's worthless? Fine. I don't care.
> -------------------------------------- 8< -------------------------------
> // pseudocode
> RogueNode.processRequest (Node requestor, Key key, TTL ttl) {
> // set the load to something that looks good; no need to be honest
> float load = goodNumber;
> // we accept all requests
> queryAccept (requestor, key, load);
> int ndx = getBucket(key); // map key into cluster index
> if (ndx == myIndex) {
> if (myNode.contains(key)) {
> // return the key
> } else {
> // get the key using ttl==0 protocol
> }
> } else {
> // forward the request to another node in the cluster
> clusterRoute (ndx, requestor, key);
> }
> }
> -------------------------------------- 8< -------------------------------
>
> > 5. Requesting Non existant keys cannot DOS the network
>
> Not true. In a metastable network with a few stars and most nodes broke,
> the effect of requesting non-existent keys is to discredit the stars,
> driving the network from C towards A (no one specializes, everyone is
> broke).
Amended statement: Non-existent keys as requested by applications like frost,
and are biased towards any specific value, do not DOS the network.
> > 6. We learn about a nodes specialization even if the request does not
> > work.
>
> Ah, but nodes are free to lie ;-)
Yeah, you can tell them you are however slow you like. You can't convince them
your any faster.
> > 7. EVERYTHING can now we done non-alchemisticly. (Data store contents,
> > Caching, Rejecting, etc.) Nodes maximize for profit.
>
> Yes, nodes maximize for profit, but this doesn't prevent attacks and this
> certainly doesn't provide anonymity of any sort.
It prevents Flooding attacks for both inserting and requesting data. It
decreases, but not eliminates the effects of an anti-specialization attack.
And it does not REDUCE the anonymity in any way.
> This is the crux of the problem with this approach: it is an attempt to
> change the basic purpose of Freenet. Nodes maximize for benefit in terms
> of rapid and reliable replies to requests. The fundamental goals of
> anonymity to the publisher and reader are ignored.
The ARCHITECTURE provides this ROUTING does NOT. You can route to any node you
want, and it does not revail the originator of the request.
> If the network works
> at all, everyone knows where a given document is to be found.
>
> > 8. Current overload and routing problems go away.
>
> Along with the network?
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
