| 1 |
On Thu, 21 May 2020 10:47:07 +0200 |
| 2 |
Michał Górny <mgorny@g.o> wrote: |
| 3 |
|
| 4 |
> An alternative of using a proof-of-work algorithm was suggested to me |
| 5 |
> yesterday. The idea is that every submission has to be accompanied with |
| 6 |
> the result of some cumbersome calculation that can't be trivially run |
| 7 |
> in parallel or optimized out to dedicated hardware. |
| 8 |
|
| 9 |
If the proof of work mechanism was restricted to ID generation, then |
| 10 |
the amoritized cost would be acceptable. |
| 11 |
|
| 12 |
So instead of the ID being generated locally, you'd send a request |
| 13 |
asking for an ID, it would send you the challenge math, you'd send the |
| 14 |
answer, and then you'd get your ID. |
| 15 |
|
| 16 |
And their ID would be an encoded copy of their input vectors and |
| 17 |
responses, a random chunk, and chunk representing the signature of |
| 18 |
IV/RESPONSE/RAND. |
| 19 |
|
| 20 |
Or something like that. |
| 21 |
|
| 22 |
But the gist is it would be impossible to use ID's not generated by the |
| 23 |
server. |
| 24 |
|
| 25 |
Then the spam factor to monitor wouldn't be submission rates, it would |
| 26 |
be "New ID request" rates, as these should never be needed to be |
| 27 |
generated in large volumes. |
| 28 |
|
| 29 |
_And_ taking 5 minutes for ID generation wouldn't be a terrible thing. |
| 30 |
|
| 31 |
( We could possibly collect anonymous stats on ID generation rates, and |
| 32 |
average times to generate a response to a challenge, and use that to |
| 33 |
determine what our challenge complexity should be ) |
Archives