Your message dated Tue, 22 Mar 2011 14:39:06 -0400
with message-id <[email protected]>
and subject line Re: Bug#619183: Hashcash token does not represent bits
calculated [Bug]
has caused the Debian Bug report #619183,
regarding Hashcash token does not represent bits calculated [Bug]
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
619183: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619183
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: hashcash
Version: 1.21-1
According to the documentation, the hashcash binary supports the '-b
bits' switch and argument for calculating a hashcash token of the size
specified. The default size is 20 bits. The '-b' switch argument
supports an exact size, say '-b 40' for minting a 40 bit token, or
incrementing/decrementing the size from default, such as '-b +10' to
create an additional 10 bits from default (20). This should create a
token of 30 bits in size. Same holds for decrementing.
Consider the following example:
$ hashcash -m foo -Z 2
hashcash token: 1:20:110321:foo::oMOAOyoyMfeKOPg7:5z7t
As per the 2nd column of the token, the default of 20 bits was used.
Let's increase to 30 bits:
$ hashcash -m foo -b 30 -Z 2
hashcash token: 1:20:110321:foo::DPuJxVpBd5hjE+WX:7CR2
The 2nd colomn shows that only 20 bits were calculated, versus the 30
that I requested. This can be verified with SHA1 showing that the first
20 bits are zero, not the first 30:
$ echo -n 1:20:110321:foo::DPuJxVpBd5hjE+WX:7CR2 | sha1sum
00000239da10b8f4cf3aadd15d62b2d0c261dc82 -
The same bug exists for incrementing and decrementing the bit size. The
2nd column should convey the bit size that I requested with '-b bits'
and verifying with SHA1 should show the firt few bits as zero, as
specified. Compare with a 44 bit token found at
http://hashcash.org/stamps/:
$ echo -n 1:44:070217:foo::xSi0bPjoswUh6h1Y:TMNI7 | sha1sum
000000000005ae959bd508c19ba300b1088410aa -
This is a Debian GNU/Linux unstable operating system running with:
2.6.37-1-686 #1 SMP Tue Feb 15 18:21:50 UTC 2011 i686 GNU/Linux
With C library version:
Version: 2.11.2-11
--
. o . o . o . . o o . . . o .
. . o . o o o . o . o o . . o
o o o . o . . o o o o . o o o
signature.asc
Description: Digital signature
--- End Message ---
--- Begin Message ---
All options must come *before* the resource to be minted. So
On Mon, 2011-03-21 at 15:08 -0600, Aaron Toponce wrote:
> $ hashcash -m foo -b 30 -Z 2
> hashcash token: 1:20:110321:foo::DPuJxVpBd5hjE+WX:7CR2
should instead be:
$ hashcash -m -b 30 -Z 2 foo
(though, producing a 30-bit stamp takes quite a bit of time)
--
Hubert Chathi <[email protected]> -- Jabber: [email protected]
PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/
Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA
--- End Message ---
