Attempted to buy via cash in mail; did not receive bitcoins. This is not necessarily their fault (the money could easily have been lost in the mail) but if many users report similar outcomes then in aggregate this may indicate a problem.

Update: 'bitcoin listtransactions' reveals that I actually did receive the bitcoins some time ago, but the order page (example, not mine) has not been updated to reflect this.

It turns out they fail even harder than I thought, which is actually kind of an accomplishment.

First, they suspended demurrage for April, presenting this as a good thing. So even they don't believe their own bullshit philosophy.

Second, the email in which they announced this put all the recipients' email addresses in the To: line. So now I have the emails of everyone on their list. (link)

It should be possible to optionally flag your upload as publicly-visible. Then, create a page linked from the front page of the site that lists all the publicly-visible files, sorted by number of downloads, or maybe by when they were uploaded.

I claim http://myB.TC/delia (code=19697)

I recommend non-constant domains per block. Let block generation only be used for maintaining a verifiable history (i.e., demonstrating that you registered a domain "first"); actual domain generation can be keyed to an entirely independent proof-of-work challenge.

Too low blocks per hour increases the wait time for confirmation; too high causes network latency to become an issue.

Nefario:

Holding block difficulty constant would cause the blocks-per-hour rate to vary wildly, which is undesirable for technical reasons (as opposed to policy reasons, which are more debatable).

Holding domain difficulty (as measured in hashes per domain) constant would result in domains becoming exponentially cheaper with advances in computing hardware. This is probably not what we want.

We can still make reasonable estimates. Moore's law has been relatively stable for some time, and it seems likely to continue for the forseeable future.

It seems to me that what we want is for the cost of registering or renewing a single domain to remain roughly constant. The only variable we should take into account is then the cost in dollars of computation. I'd suggest a simple fixed deflation rate calibrated to the Moore's-law predicted curve. (But be careful about gotchas like GPU mining.)

Possible attack against a connected-mode pool: when you find a pool-grade hash, send it immediately to gain credit, but when you find a block-grade hash, hold it until the pool hashrate dips.

This introduces some risk that someone outside the pool will find a block in the meantime, so you can't hold too long, but the optimal wait time is almost certainly greater than zero.

+1

Even "Truecoin" would be superior.

+1 Bitcoin4Cash.

The hashing can be done in javascript, and the nonce can be generated randomly by default or accept mashing keys into a text field if the user wants.

If I read the spec correctly, an fn-only node needs IRL friends in order to make transactions. It would probably be worth having a within-Freenet introduction system, like FMS's captcha puzzles.

In theory, it should be possible to generate a provably random number. I don't know whether PIW's customers care enough for it to be worthwhile to implement. The protocol would go like this:

PIW generates a secret.
Secret: 0cd645b8cc7325838b2fa809f308e28ef9463494

PIW sends hash of secret to user.
Hashed-Secret: d18b235bd2c80890a8aee4c564cfbce251633bb3

User records hashed secret.
User generates a nonce.
Nonce: ce61948f0d95be1746017cc327b8d28316055c8f

Secret and Nonce are concatenated and hashed to form the final random result.
Concatenation: 0cd645b8cc7325838b2fa809f308e28ef9463494ce61948f0d95be1746017cc327b8d28316055c8 f
Random: 4f20d70d465fd0743a808048b7a7780e76627d58

Elastic Coalition.

I ran up against the 1-confirmation bug, but it seems to have failed non-gracefully:

Just a reminder: the deadline is tomorrow.

+1

I believe you're describing Hashcash.