[RC5] newbie question
sgp at telsatgp.com.pl
Mon Aug 25 18:46:48 EDT 2003
Bruce Wilson wrote:
> What you're suggesting is called a "residual". Whether it is
> obtained from an XOR of the top N bits, or a CRC of the
> bottom N bits, or (in the case of OGR) a count of the
> number of nodes found in the stub, the idea is to capture
> some information which cannot easily be computed
> without actually doing the work.
It's probably the only way - require client to include
some kind of proof one had really done the work.
> One dimension which has in the past made it difficult to
> compute a residual is the fact that clients could work
> with different size workunits.
> A good residual for RC5 would need to survive
> splitting/recombining, and still be computationally
> infeasible without doing the work. I'm not sure,
> but an XOR solution may be a bit too simple.
Joining XOR residuals is obvious (just XOR them),
but it means loosing ability to detect which of the
blocks contained flawed work.
If I understand your words blocks are splitted when
travelling from keyserver to clients and recombined
on their way back.
Work travelling from keyserver through proxies
to the clients would not have residuals so there's
After residuals are joined there is no reason
to split them again. All after all they must have
origined from the same participant or we would
not be able to catch who's cheating anyway.
So if they're from the same participant then
there's little sense in checking which of the
blocks is flawed. Again - no splitting.
Of course I could have missed something, so
please tell me: why do you want to split them?
> Another factor is that tracking the running
> XOR/CRC/whatever may have a greater
> impact on performance on register-starved
> architectures (X86).
It can be hold in memory and be cached.
Of course using cache may or may not be desired.
This words about cache brings another question.
Where d.net client slows down the system most
and is it possible to reduce that effect?
More information about the rc5