[hashcash] Re: Hashcash performance improvements
- From: Adam Back <adam@xxxxxxxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Mon, 31 May 2004 11:35:27 +0100
Jonathan Morton wrote:
>> 1:10,4:040525:foo::c82a215126afb2c2:416,416,416,416
>>
>> being considered valid with the over-writing semantics.
>
> Well, that and sending a batch of mails with the same set of stamps
> attached.
Same sub-stamps permuted would be another thing yes.
1:10,4:040525:foo::c82a215126afb2c2:416,123,314,100
1:10,4:040525:foo::c82a215126afb2c2:416,123,100,314
etc
> OK, I think I see your point. You can avoid the database storage and
> re-use problems by storing exactly 16 characters (96 bits) of the random
> field, along with the hash of the whole stamp.
I think you don't even need the hash of the whole stamp, just the
randomness field alone should be enough. Any stamp with the same random
field would be rejected anyway (whatever it hashed to, whether the
attacker tried to re-use a whole stamp, some or all sub-stamps, permuted
sub-stamps etc).
Think it would also be good to keep the date (which you need to purge
old stamps), and re-accept earlier random fields on different days.
(The uniqueness being on random field and date). (Birthday effect
creeps up in some high traffic scenarios if keep one double-spend
context forever).
> If we're going to store 16 characters from the random
> field in our database, perhaps that field should always be 16 characters
> wide, no more, no less.
Fixed 16 chars of base-64, that would be fine, also per Malcolm's
comment about keeping things of defined sizes.
Adam
Other related posts:
