This web interface implements a Hashcash/Proof-of-work system that requires a sender to perform a small amount of computational work before sending a message.
This computation yields a unique token (the Hashcash stamp).
Each Hashcash token includes a UTC timestamp, limiting its validity to a short window and preventing the same stamp from being reused repeatedly.
Because generating such a token costs CPU effort, it significantly raises the expense of automated spam and abuse.
Because generating such
On Fri, 04 Apr 2025 22:46:05 GMT, Gabx <nessuno@domain.invalid> wrote:
This web interface implements a Hashcash/Proof-of-work system that requires a sender to perform a small amount of computational work before sending a message.
Gabx wrote:
This web interface implements a Hashcash/Proof-of-work system that requires a sender to perform a small amount of computational work before sending a message.
This computation yields a unique token (the Hashcash stamp).
Each Hashcash token includes a UTC timestamp, limiting its validity to a short window and preventing the same stamp from being reused repeatedly.
Because generating such a token costs CPU effort, it significantly raises the expense of automated spam and abuse.
Gabx
https://m2usenet.virebent.art
# often offline, I'll fix it as soon as I have some time
In article <vspo6k$19r4k$1@news.tcpreset.net> Gabx wrote:
Gabx wrote:
This web interface implements a Hashcash/Proof-of-work system that requires a sender to perform a small amount of computational work before sending a message.
This computation yields a unique token (the Hashcash stamp).
Each Hashcash token includes a UTC timestamp, limiting its validity to a short window and preventing the same stamp from being reused repeatedly.
Because generating such a token costs CPU effort, it significantly raises the expense of automated spam and abuse.
Gabx
https://m2usenet.virebent.art
# often offline, I'll fix it as soon as I have some time
| X-Hashcash: 1:16:202504050827:test@test.example:::Yh7SGdhy:56725
I doubt you get anything with a 16 bit Hashcash token minted in
milliseconds furthermore calculated at your server instead of the
client. That may even be too small for a DOS attack on your service.
;-)
| H Hashcash value after 0,0 sec. is '1:16:250404:test@test.example::DjMt8LWLG8ebvqp+:00000000000000000000000000000000000000000000062S'
Better only accept users that provide the complete token, which means
they themselves have to pay for and are thereby handicapped by the calculation.
Then activate Hashcash's database for double spending detection (-d),
allow an expiry period of at least 2 days (-e) and do without the exact
time using only the date (YYMMDD).
Apart from going without an expiry period due to unpredictable remailer latencies the same goes with Sec3's m2n gateway. And with computers
getting much faster I'd ask for at least a 28 bit token to hurt mass
mailers.
I am using 26 bit for my m2n and have not seen much of a difference with 28.
I am wondering also if Gabx uses the reference inplementation, because his >tokens look a bit different to regular ones.
Regards
Stefan
Stefan Claas wrote:
I am using 26 bit for my m2n and have not seen much of a difference with 28.
| c:\hashcash-1.22-win32-dll>hashcash -m -v -b 28 -X -u -z 6 -t 2504050930 -r test@test.example
| core: xxxxxx
| speed: 16777216 preimage tests per second
| compression: 0
| mint: 28 bit partial hash preimage
| expected: 268435456 tries (= 2^28 tries)
| time estimate: 16 seconds
| tries: 516963658 193% of expected
| time: 36 seconds
| X-Hashcash: 1:28:250405:test@test.example::BdBVK5rPOZE1LACI:00000000000000000000
| 00000000000000000000000Uq3r8
|
| c:\hashcash-1.22-win32-dll>hashcash -m -v -b 26 -X -u -z 6 -t 2504050930 -r test@test.example
| core: xxxxxx
| speed: 15768061 preimage tests per second
| compression: 0
| mint: 26 bit partial hash preimage
| expected: 67108864 tries (= 2^26 tries)
| time estimate: 5 seconds
| tries: 61312466 91% of expected
| time: 5 seconds
| X-Hashcash: 1:26:250405:test@test.example::tPoWAVogIELbWh+b:00000000000000000000
| 000000000000000000000003futH
|
| c:\hashcash-1.22-win32-dll>
So on my standard computer 5 seconds of minting result in 12 (spam)
messages per minute whereas with 28 bits you achieve a third of that
number, which still is a lot.
I am wondering also if Gabx uses the reference inplementation, because his tokens look a bit different to regular ones.
Regards
Stefan
Unfortunately till now my OmniMix postings with headers
| To: mail2news@oc2mx.net
| Newsgroups: alt.privacy.anon-server
| References: <d0b88a773d.1743809313@kfxhz.xa>
| Subject: Re: ping - Gabx
| MIME-Version: 1.0
| Content-Type: text/plain; charset=us-ascii
| Content-Transfer-Encoding: 7bit
| X-Hashcash: 1:26:250405:mail2news::kC/drhYJVOYo8ddI:00000000e1Ng
and
| To: mail2news@oc2mx.net
| Newsgroups: alt.privacy.anon-server
| References: <d0b88a773d.1743809313@kfxhz.xa>
| Subject: Re: ping - Gabx
| MIME-Version: 1.0
| Content-Type: text/plain; charset=us-ascii
| Content-Transfer-Encoding: 7bit
| X-Hashcash: 1:26:250404:mail2news::AyJm78q1rpfcc6PR:00000000unvP
didn't make it.
If you would try my m2n with Mini Mailer or Onion Courier or standard
email services, with smtp access, all messages will come through, as
I have tested until this afternoon.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 499 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 55:44:18 |
| Calls: | 9,839 |
| Files: | 13,764 |
| Messages: | 6,194,586 |
| Posted today: | 1 |