Re: Notes... The case for an open client

Elektron <elektron_rc5-FFYn/[email protected]> writes:
> > ASCII files are a horror to parse in perl?, or python? Sure beats 
> > having
> > to release several hundred binary P2P clients
> 
> Huge ones, yes. They take way too long to load. And I hate python, but 
> that's probably just me.

That only matters if it's an interactive process and somebody actually
has to wait for the results. As a background batch process that keeps
a local copy of the database updated, it's not a sigificant issue as
the time to locally apply updates and forward them is probably significantly
less than the network propagation time between the most two time distant
nodes.

> It's still luck anyway. And if you want, feel free to search whatever 
> keyspace you wish.

That is exactly the point! ... you don't get that option accepting
d.net generated key assignments.

> Everyone should use d.net!

Why? Why reduce the prize by 80%? What value does d.net really bring to
the table over a small set of perl/python/sh scripts implementing a simple
P2P database of keys currently being searched, and/or completed?

That they exist already today and have already searched an insigificant
amount of the RC5-72 key space?

I don't see any reason to pay d.net 80% of the prize, when technology
exists today to take the project pure peer-to-peer in a way that openly
distributes the key database in near real-time.

> The problem with splitting it up a lot is then you have the problem of 
> trusting people to search those blocks. You may work on your 
> competition's blocks first, to try to stop them from finding the key 
> (I'm not sure if this actually works though). There is also a high 
> potential of sabotaging the entire project, unless you can find a lot 
> of trusted servers (and projects willing to cooperate). And then, you 
> don't get as nice stats.

Ah ... trust, strategies and game theory :)

As for sabotaging the entire project, it seems pretty difficult for a
single player to do so if some of Dan suggestions like requiring partial
match keys to be posted as proof of searching the space, as it becomes
computationally trival to verify those keys as minimim to accept the
blocks before including them in the database.

Sure, DoS problems could be created ... but d.net faces similar risks.

John
_______________________________________________
Hardware mailing list
Hardware-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected]
http://lists.distributed.net/mailman/listinfo/hardware