[Hardware] Notes... The case for an open client
dan_oetting at uswest.net
Sat Aug 14 00:13:47 EDT 2004
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
> 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
> suggestion. As for the closed source, this document provides a good
> background on the reasoning:
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.
More information about the Hardware