Mitch Denny wrote:
Hi Eric,
Thanks for responding.
EJ> Comment response delivers stamp resource and required EJ> bit size. Since HTTP transactions are stateless, it EJ> would be wise to encode the bit size in the resource EJ> using some techniques like HMAC.
OK, I'm still very new to Hashcash so some of my comments may seem a little bit thick :) One of the things that I mentioned in the post was that the RDF that is embedded into the blog posts (when rendered to HTML) can be extended to include the bit size required for the stamp. You can see an example of what I am proposing at http://notgartner.com/Downloads/RDF.xml just in case you missed it. So I guess this does what you mentioned above - unless I am missing something. Its unlikely that the URL to the blog post will be able to be changed - as this has huge implications for track-backs. One of the good things about blogs is their two-way nature.
no, it does not do that. but in hindsight, it occurs that it's not necessary.
I'm always looking at ways of preventing spammers from cheating. I was thinking that spammers can cheat and deliver a smaller number of bits and other users by changing URL elements etc. I was thinking of ways to keep track of this information as part of the transaction without requiring any server side state information but unlike e-mail environments, you can tell the world how many bits are required and then you can enforce that on return.
Some of the neat things that I have seen with JavaScript include popping a little floating window over the top of the screen with a small and simple animation obscuring the calculations going on behind the scenes. I would imagine that something similar could be done. Obviously it would depend on the size of the stamp, for a 16-bit stamp my non-optimised algorithm now spews them forth very quickly, definitely not noticable in the overally request/response for a HTTP post. Given that, a larger stamp size would be more reasonable. 20-bits seems to be the standard but from what I read in the archives it looks like being upped to 24-bit???
yes, we are looking at 24-bit stamps and on the cusp of 25 bit stamps given the recent optimizations certain clever people have come up with (clever people who owe me a description of their signature method)
On threading, you don't really have any control over threads given the constrained execution environment. But I wondered how threads would really help on a single-proc box, surely driving the CPU at 100% for a few seconds can't be improved by adding threads - wouldn't that just cause context switches? I looked at the Java Hashcash implementation on the http://www.hashcash.org site and wondered what was really being gained. This is probably down to my in-experience with Hashcash.
it's more akin to running stand generation at a reduced process priority level. If nothing is going on, it sucks up all CPU but if the user is doing something, it relinquishes CPU for the user.
EJ> I would also caution you to try and run as fast a stamp EJ> generator as possible because the spammers will and any EJ> performance differential between what spammers can run EJ> and your customers can run is not in your favor. Which EJ> raises the ever popular question, is it possible to use a EJ> native hashcash from a browser?
Definitely can't run hashcash from the browser in the client process space as this would violate the sandbox. Most legit commenters could probably wait up to say twenty seconds to mint a stamp, whereas I think that would probably stop it being economical for spammers (pure guess).
there are other ways of violating the sandbox. For example, a stamper that runs in systray that listens on a localhost socket and when given bits and a resource generates a stamp. Is that not something one can do?
heck, it might be useful for practical browser based triggers for stamps
I was planning on making the resource string the track-back URL. I guess that could change, but it would be up to the blog implementation. The RDF could probably have a hashcash:expiry attribute which contains the expiry date for the resource (trackback URL), although I am not sure. The current state of blog spamming bots would have to be fairly primative, they have only really shown up over the last year or so.
don't worry, they will evolve if they're getting any sort of decent return rate.
---eric
