Actually, I'm not sure this makes sense without major protocol changes. Currently, if you throw away the transaction inputs you can't prove to other nodes that the transaction was actually buried in the blockchain at the place you claim it was - transactions are hashed as a single piece of data and there's no way of verifying the hash without the entire transaction. So it's not really safe to bootstrap new mining nodes without a complete transaction history including inputs, even if they don't validate the entire chain.

Almost, except that Spartan-6 LUTs aren't equivalent to the LUTs used in other FPGAs - about half of them are useless for Bitcoin mining because they don't have any adders. Expect somewhere in the ballpark of half that many LUTs for a completely unrolled miner on a more suitable FPGA.

That's not the main obstacle to competition though - the main obstacle seems to be how on earth to get the FPGAs at a low enough price.

Unless I'm entirely mistaken there was a rather nasty vulnerability in OP_EVAL caused by this added bit of complexity, one that BIP 16 would've inherited if you hadn't spotted and fixed it. While technically it was only a denial of service vulnerability that prevented nodes that supported it from mining any blocks, a denial of service vulnerability of this kind is enough to create transactions spending other people's bitcoins from their P2SH addresses and get non-upgraded nodes to accept them even after the switch-on date, which is kind of a big deal.

Yeah, that's the problem. It only works so long as whoever's attacking the chain doesn't attempt a double spend. We can still cope with sub-50% double spend attempts by essentially picking the side of the double-spend with the most confirmations (though there's a lot of subtlty in how this must be calculated) and throwing away the other double-spend block and its descendants, but greater-than-51% ones are a huge problem.

Interestingly, it looks like there is actually a way of making coins immune from this particular attack that doesn't require any kind of trusted central authorities and can't be used to fork the blockchain. Unfortunately it'd be a huge pain to implement correctly and wouldn't be able to deal with 51% double-spending attacks.

The trick is that there's no inherent reason why the Bitcoin blockchain actually had to be in the form of a chain. Simply add a rule that blocks can merge multiple non-conflicting forks of the blockchain by having multiple parents, calculating its total work as the sum of its work and work done for all its ancestor blocks. That way, it doesn't matter that Eligius is mining faster than the rest of the network because we can use the attacker's work against him - our non-attack versions of the best chain are counted as having the strength of all his work plus all ours, and the only way he can benefit from this effect is if he includes other's blocks and transactions which is what we wanted in the first place!

There's almost certainly some subtle flaw in this and it'd be a nightmare to implement correctly and in a way that couldn't be exploited, but on paper it seems like a clever idea. Don't think I'm going to go through with it though. (There are a whole bunch of subtle details that have to be taken care of. For example, we need to cap how far back a fork that's being merged can come from to block spam, but this limits the power of this scheme against denial-of-service.)

Not entirely. Luke-Jr keeps making statements that whilst technically true are carefully worded to mislead people into thinking that Eligius was not in fact merged mining CLC, and I think a few people have come to believe this. (Not that it'd probably make much difference anyway.)

Errrm... you do realize that Bitcoin has more or less the same cryptographic flaw, right?

That's... non-trivial, and most of the proposed suggestions either require centralization, cause more problems, or both

It's important that different nodes' view of the blockchain converges in a reasonable time, and this is hard - probably even impossible - to guarantee if every node is following different rules about which blockchain they prefer.

They're detectable, even automatically detectable in theory, there's just not an easy way to prevent them.

There is no economic incentive to do so so long as you're primarily invested in Bitcoins. For example, suppose someone really wealthy concluded that Bitcoins were potentially harmful to their wealth elsewhere; it might make economic sense for them to spend a few million dollars destroying Bitcoin.

Except they're not exactly consenting parties and they don't exactly agree on the contract - one party unilaterally offers a contract whose terms are hidden in cryptic fine print if they're even mentioned at all. In fact, the media companies are obviously aware that people wouldn't be willing to buy their products if the conditions were more obvious. How many ads have you seen encouraging customers to "buy" a particular product with DRM? Now how many have you seen encouraging them to "enter a contract to access, subject to technical and legal restrictions on what hardware may be used to access" one? The media companies rely on the fact that consumers think of it as just buying a copy of something, much like they would a book, in order to avoid scaring customers away.

OK, so since Luke Jr doesn't seem to think he can explain this usefully, a brief summary merged mining for miners:

As far as miners are concerned, it looks to your mining software as though you're just mining Bitcoins normally with all your mining power. Your mining software gets normal Bitcoin-mining work and submits normal shares at the same rate as it would if you weren't merged mining, if the pool is well-written it'll credit your shares towards Bitcoins at the same rate as if it wasn't merged mining, and the pool will have the same chance of finding blocks too. From a purely Bitcoin-mining perspective it doesn't have any effect whatsoever.

However, because of a clever trick with the work you're sent that you have no way to detect, the shares you submit can also be used as shares towards every other merged-mining-supporting altchain that the pool chooses to mine and can be used to generate blocks for that chain. Again, they don't stop being valid as Bitcoin shares or blocks because they're used them in this way - in theory all the chains gets the benefit of all the shares you submit, though in practice this is only entirely true for Bitcoin. This is actually how I can prove that Eligius is merged mining CLC. A large proportion of the Bitcoin blocks found by Eligius were created from the same share as a CLC block.

In summary, whilst this doesn't affect your income from Bitcoin or Namecoin mining in any way it does mean that you're helping to shut down CLC by mining at Eligius. How important this is, is something for you to judge.

Edit: as k9quant in IRC points out, there's one small inaccuracy. It's more accurate to say that you have no easy way to detect that you're merged mining and no reliable way to tell which chains you're helping to mine on. If you personally find a Bitcoin block you can tell from the block that merged mining was used but not which chains, and in theory you could also detect that you'd mined a block on a particular altchain if you knew to look out for it.

Errm, good luck with that. Apparently he's already made his position on this quite clear:
Again, both technically true and intentionally misleading. Because of the way merged mining works hashing involving CLC was indeed done by him - even if they were helping to mine CLC the miners just hashed normal Bitcoin blocks which unbeknownst to them were constructed to be used as proof-of-work for CLC blocks. Even if their hash power was being utilized to help shut down CLC - and it looks like it was - they weren't directly hashing anything CLC-related.

Well, it's certainly rather less than honest, but he genuinely does seem to believe that whatever other things he does with his pool are irrelevant to miners so long as they get their Bitcoins.

(By the way, the same is true of the Eligius-mined Bitcoin block two earlier, block #161142, and Coiledcoin block #6433. Also, by "corresponds" I mean that they share the exact same proof-of-work and were therefore merged-mined together. There are almost certainly more too, I just haven't looked further back.)

Well, he's pointing well over 250 GHash/sec of mining power at CLC, and he's also been begging in IRC for remote access to computers with OpenCL-capable GPUs for unrelated software develoment purposes due to not having any of his own, so it'd be rather... surprising if he didn't use Eligius users' hash power for this.

Edit: Coiledcoin block #6948 corresponds to Bitcoin block #161234, the 3rd most recent block mined by Eligius, so yeah...

There's a slight error in your logic here. Nodes can only be forced to adopt an update if CodeHunter's "enforcer nodes" go along with it, and they've got no reason to do this for an update that takes away their power. Assuming that those nodes are genuinely independent of CoinHunter, he doesn't actually have much more control over SolidCoin than the Bitcoin developers have over Bitcoin - if they release a major change and the mining pools go along with it, users pretty much have to go along too.

I think that had rather less to do with laziness and rather more to do with the fact that shorting Bitcoins would require trusting Bitcoinica.

Interesting. The other statement from him was rather more weasily:

Which of course, is entirely true except for the part about not losing confirmed CLC, because that's how merged mining works - through the pool adding data they'd hashed themselves (namely the merged mining merkle-tree root) to their own transactions (more specifically, the pool's coinbase transactions). Judging from observations of the hashrate, the reason Eligius miners weren't adversely affected was because he intentionally didn't trigger long polls on receiving a new CLC block.

That's about when he removed OP_EVAL support from the pool's Bitcoin client. (During Coiledcoin development I found an interesting security vulnerability in it whereby you could feed pools and mining nodes a poisoned transaction that'd make them unable to successfully mine any blocks. Thankfully not everyone is quite as malicious as Luke Jr. Apparently Gavin had already fixed it in the proposed replacement for OP_EVAL but presumably not thought to warn the pools for whatever reason.)

Here's a fun exercise by the way: figure out what flaw in Bitcoin's implementation of OP_EVAL this code triggers, and if you've got a copy of the Coiledcoin source take a look at how it fixes it. (Only just got around to looking into this properly.) For bonus points, can you guess why Luke Jr is really lucky I don't hold a grudge?

In that case, I'm sure you'll figure everything out by yourselves. Good luck.