No.  Are you?

~$250 for a five-fold speed up on 1600 tests?  Sounds a little cheap.

The version control history is pretty well organized.  I have gotten some mileage out of browsing it with gitk.   Also, libcoin is a fork which sells itself as a drop-in bitcoin replacement with better organized source code.  Might be worth a look.

  This setup is a horrendous kludge, requiring laborious startup every time you want to get on the web.  Nothing wrong with that if you need results in a hurry and it's the best you can do at the moment but it seems quite likely that better instructions/automation for this will be available in a few months, in which case hours of effort could be saved just by waiting.  (At the very least, a script which starts the VMs and services and hooks them up to each other would be a good idea.  I am also a bit surprised that an extra linux VM is needed for bridging the tor traffic.  Can't you do that on the windows side?  But I don't know much about windows.)

I got a little excited when he started talking about freenode, because I have found it quite hard to set up a truly anonymous account on it which can be accessed over tor.  Disappointing that he didn't go that far.

The speedup over a CPU is less than an order of magnitude.  It's not fatal.

The IRS calls this "structuring", and will come down on you like a hammer if they catch you at it.

What makes a ltc pool attractive?  I'm seeing perfectly acceptable variance, mining solo with an i5.

If I wanted to address this problem in a protocol changing way, I would probably go for the heart of the matter, and devise a scheme which periodically embeds easily verifiable summaries of the current list of spendable coins.  Then the blockchain could get as big as it wanted.  A node catching up on the state of the ledger would only need to download the blocks generated since the last summary.

It's a bit more technically plausible than Butterfly Labs was.

I believe the scrypt paper has estimates on how the runtime complexity of the algorithm varies as you change its parameters.  Perhaps you could change those parameters every two weeks instead, of changing the hash image criterion.

The Secret Service is a lot scarier than the DEA. </speculation>

Your fear that someone might find a faster implementation by running one instance of it through some magical optimization software doesn't seem that plausible to me.  Roughly speaking, scrypt is based on randomly mixing up the results of a large number of SHA256 hashes, so any substantial optimization which didn't also optimize SHA256 would be pretty surprising.  Any accurate optimization would still need random access to all those hashes, which forces a very large circuit.

 Could someone please identify the block which contains this so those of us who don't have a full copy of the blockchain can verify it online?

Ha ha, are you saying there's nothing wrong with being an asshole because it does not violate property rights?

I read through the bitcoin-dev archive's discussion of OP_EVAL, and don't understand the extent of the concern about Turing completeness.  Guaranteeing resource limits on script execution is important, but runtime constraints like limiting numbers of recursions already go a long way toward imposing these guarantees.  Defense in depth of these guarantees is important, too, but if such a heavily-scrutinized proposal can go months without anyone noting that it affords Turing-completeness then relying on formal analysis Script-the-language to guarantee resource constraints by static analysis is infeasibly delicate and unreliable. 

A more direct and robust defense-in-depth would be for bitcoin's Script implementation to track the resource usage resulting from the execution of each opcode, and reject the script as invalid when usages exceed some thresholds.  If static analysis is currently valuable for miners assessing whether it's worth their while to process a given transaction, then OP_EVAL could be extended to include guarantees on the memory usage and counts of the opcodes and signatures executed by the script which invokes it, guarantees which could be ensured by simply rejecting the script if it violates them. 

Beyond the advantage of greatly strengthening the resource constraints, this approach would probably be much less expensive than junking all the analysis, development and testing put into OP_EVAL so far.

Maaku, are you guys still working on blockchains using folding@home etc.?

If a security flaw is found in a blockchain client or protocol and a fast fix is needed, is there a fast way for developers to push a revised client out there?  For that matter, what is the earliest version of the canonical bitcoin client that will work on the current network, and how is that enforced?  I saw that Ixcoin had a mandatory update recently; in what sense was it mandatory?

I don't know much about it, but there is definitely one radically new blockchain under development.

Not a good fit for me, but thanks for the info.

Is it wise to publish a binary of uncertain provenance for public download?