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

On Aug 13, 2004, at 10:00 AM, Steven Nikkel wrote:

> I think you might have a misunderstanding of D.net. We gladly welcome 
> new people and would especially welcome you to port the client to a 
> hardware/FPGA based cruncher.

I think it is you that has misunderstood what we are asking for. I'll 
try to explain.

It is not just 1 FPGA based cruncher that we want to interface to the 
d.net client but thousands. All different designs, many one of a kind, 
build and programmed by students, mostly experimental and continually 
tweaked and pushed for optimum performance.

RC5-72 itself is a total waist. It cannot prove anything more than 
RC5-64 (except perhaps that it is too big of a task to complete). Do 
the calculations for what just the electricity costs for the current 
key rate using the most efficient processor and even subtracting the 
idle power of the processor.

Some people think it's all about the stats. If that's the case then 
instead of sending your nickel to the power company why not send it to 
me and I'll give you a stat point and donate the nickels to a deserving 
charity. At least that will accomplish something.

One useful purpose for running RC5-72 is as a platform for learning 
about distributed processing and as a place for students to compare 
their hardware designs. For an educational project, the RC5 hardware 
engine is well defined, not too difficult, and offers numerous 
alternative design options.

RC5-72 is going to be around for a long time. (even if we get 
exceptionally lucky there is always RC5-80 which can be started on the 
same hardware without modification :) This longevity means that 
instructional material (design parameters and such) will remain valid 
and future core designs can be compared with older designs.


> There is no history of rejection or secrecy as you suggest.

  :-)

> Rather suggestions for improvements arrive on a
> regular basis. While these ideas aren't rejected, they may not see the 
> light
> of day for a period of time. D.net is a volunteer based organization 
> and as
> such there is often a lack of time or expertise required to implement 
> the
> suggestion. As for the closed source, this document provides a good 
> background on the reasoning: 
> http://www.distributed.net/source/specs/opcodeauth.html

I already referenced that document earlier in this discussion. In fact, 
I like to think I am partially responsible for it's creation from my 
earlier attempts to open the client. It mentions the "Inline Testing" 
that I earlier developed to solve the client verification problem. The 
procedure was complicated by the constraint that completed blocks were 
used for stats and submission of forged blocks was a particular 
concern. By removing the artificial constraint and substituting a more 
appropriate and verifiable counter for stats the solution becomes 
downright trivial and instead of adding overhead to the core it 
actually makes the core faster.

My earlier attempts to open the client never went anywhere because 
there was no real advantage to having an open client. Most users just 
run the client and watch the stats. The few platforms that didn't have 
a client were either too slow or too few to significantly contribute. 
But now the hardware cores man turn the tables. Instead of d.net not 
needing the extra contribution, a hardware project may not need d.net.

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