Ah, I see. For those wanting to do their own calculations, it would appear that only odd-numbered blocks are actually mined. Even-numbered blocks are created by some kind of trusted node or something and pay 3.2 SC to RealSolid's CPF in place of the usual generation payout.

Nope, because I'm still not clear on what exactly CoinHunter has done with premining; it only counts the number of coins that were mined normally on 1.0 and 2.0 combined.

Hard to tell; as far as I know there's no block explorer for Solidcoin 2.0 yet and RealSolid hasn't released the information needed to write one, so it's quite tricky to see what's going on. Probably the only person that knows is BitcoinEXpress and I don't think we're going to be hearing from him any time soon. It does look like we're going to see a really substantial increase in the total number of solidcoins in existence during the first 24-48 hours of 2.0 though; if my maths is right then a third of all SolidCoin 2.0 coins existing right now were mined on 2.0 since it was opened and it's only going to get worse.

Whoops, forgot about the merkle tree size and merkle nonce; 46 bytes is correct.

As far as I know, the code in the official bitcoin client isn't enough to trivially support merged mining with.

Strictly speaking, it's nearly impossible to tell if a program is malicious just by running it in a virtual machine and inspecting what it does. For example, suppose the actual SolidCoin 2.0 client had a booby-trap "if block number is greater than 8000 and difficulty is greater than 100, find and upload all wallets for all Bitcoin variants to RealSolid and erase the hard disk". Easy to code, very difficult to detect because until the booby-trap is triggered it doesn't do anything suspicious - no unexpected network activity, no dodgy file accesses, nothing. It'd also be more or less impossible to meet the booby trap condition in testing before it triggered for real.

(The observant will notice that SolidCoin has actually crossed that threshold and nothing's happened - it's just a hypothetical example.)

If memory serves me correctly, Bitcoin's moved to having its binaries compiled by multiple trusted developers that check they all get the same binary as each other in order to make this kind of attack harder. It's a shame SolidCoin doesn't do the same thing.

You forgot that SolidCoin 2.0 is meant to have some kind of 51% attack protection, which by its nature means that under some circumstances the client has to reject a chain with a greater sum of work in favour of a chain with a lesser sum ofr work. Depending on how exactly CoinHunter implemented it, it'd be trivial for someone with a decent amount of hashing power to persistently fork the network in a way that would never get healed automatically. Unfortunately he's refused to say publicly how it works and the source isn't available.

Maged: I have a feeling that BitcoinEXpress wasn't kidding. I've no idea if he was bluffing about the namecoin attack because it was quite thoroughly forestalled (I submitted a patch with a really paranoid set of block lockins designed to stop any attack I'd heard of or could think of, including the obvious-but-impractical checkpoint bypass), but this isn't looking good.

Edit: I should really set up a couple of isolated VMs and test this, but effort...

Which still requires things like exchanges and nice GUIs. Even being able to access .bit domains is very user-unfriendly at the moment; actually registering them is positively painful.

Right now, the software available for merged mining and the pools that support it are both a lot less tested and more unreliable than just mining Bitcoins, so there's definitely a cost to merged mining. At the moment I'm not sure the Namecoins I'm getting from MM are enough to compensate for the extra stales I'm seeing over a good BTC-only pool. Then there's the cost of developing and testing and setting up that software.

36 bytes of data per block - far smaller than even the smallest Bitcoin transaction. If you do just one test transaction you're bloating up the blockchan a lot more than merged mining. (The average Bitcoin block is somewhere in the 20-30 KB range these days IIRC, and that's going to increase if Bitcoin takes off.)

Merged solo mining doesn't seem to be too bad, but pooled is another matter entirely. For example, I can't figure out how you're meant to tell if the aux chain part of a share is stale or not...

IIRC, one of the factors limiting pools has been how slow bitcoin is to answer getwork requests. It turns out that it's reasonably easy - with a few tweaks to the Bitcoin client - to move most of the work-generation out of bitcoind and into the pool server, with the pool server using one modified work item from Bitcoin to answer essentially as many getwork requests as it likes. So that's what I did:

https://github.com/makomk/bitcoin/tree/poolserv-work-gen https://github.com/makomk/pushpool/tree/local-work-gen

The changes are relatively straightforward: there's a new getworkex RPC call that provides a copy of the coinbase transaction and the merkle branch it's on, and when submitting solutions the pool server can send in a modified coinbase tx that's used instead of the original. pushpoold in turn now knows how to use getworkex, insert its own additional nonce into the coinbase, increment that nonce to generate work items,  and convert the submitted shares back into a form that bitcoind will accept. A very quick-and-dirty benchmark suggests it should be able to reach in the ballpark of around 3000 getworks/sec, which is much better than I was seeing before. (I'm planning to implement a way for bitcoin to push new work to the pool server at some point too.)

These changes are also incredibly experimental; I've basically only tested them with poclbm and cgminer on a testnet-in-a-box install so far. I hear that luke-jr has been working on something vaguely similar too, and shadders is developing another approach to poolserver work generation in PoolServerJ as well.

Edit: Exercise for the curious: the Bitcoin patch should in theory be enough to implement the parent blockchain side of merged mining, maybe even more effectively than the existing approach. You can use getworkex to add whatever you like to the coinbase transaction, and it gives you the merkle branch needed to submit the work to the auxiliary blockchains.

You just need to upgrade to the latest release of namecoin that supports merged mining.

simplecoin.us doesn't appear to quite grasp that namecoin difficulty is not the same as bitcoin difficulty; they're quoting me the same estimated payout for both and don't appear to have solved any namecoin blocks even though they should've by now. They don't even have a place to list Namecoin shares though. (I wonder if the work's just been wasted or if the payout has gone into the pool owner's pocket.) masterpool.eu was under a DDoS earlier by Bitcoin supporters. nmcbit.com lost a whole bunch of supposedly accepted shares earlier and isn't reporting me as having earned any Bitcoin shares at all.

Wait, what? That's a load of horsecrap - the first sign that something was seriously, badly wrong at MyBitcoin was a wave of people complaining on here that their withdrawals hadn't actually come through. Not just that they weren't confirming, but that the transactions hadn't been sent to the Bitcoin network at all. From what I can tell, Bruce Wagner only appeared to find out about this relatively late on compared to the rest of us.

Not trivially; I don't think pushpoold supports storing worker passwords as anything other than plaintext.

I'm sure there must be better dirt out there on SA you could be digging up, you know...

Yeah, recovery programs won't be very good at recovering wallet.dat files. I've found your other thread, and given that you're recovering your wallet from a reformat what you need to do is get a 32-bit Linux CD (Ubuntu or something similar), and follow the instructions here: https://bitcointalk.org/index.php?topic=25091.0

Edit: Be sure to read and follow the warnings though.

That'd probably be very good for Solidcoin - over there the owner of the Solidcoin forum can (and from what I can tell does) delete comments that contain inconvenient facts and opinions. It probably wouldn't be so good for Bitcoin; people might start thinking that the other chains were a credible alternative.

"The law, in its majestic equality, forbids the rich and the poor alike to sleep under bridges, to beg in the streets, and to steal bread."

It's probably an EP1C20 at a guess. The short answer is maybe, but it's probably not worth the hassle...

Presumably if the Bitcoin developers decided they needed to change the difficulty algorithm fix this issue, they could just as easily change over from nInterval-1 to nInterval at a specified block some time in the future?

That's unusual. He didn't even do that for people whose accounts were compromised in circumstances suggesting it was due to the password database being extracted by hackers...