Probably more than half of all accounts are spambots.

That transaction is confirmed:
http://blockexplorer.com/tx/719e2e73698cd2c955c17486e04e5b50234f4c9d59080e5c7c23065112ec36e5

Run Bitcoin with the -rescan switch and it should become unstuck.

Edit: Actually, since that's a recent block, the transaction probably just didn't broadcast correctly the first time. No need to rescan unless it's still stuck.

It should send immediately, but maybe all of your connections were dead or some other fluke happened. It rebroadcasts every ~30 minutes, but the timer resets every time you close Bitcoin.

Run Bitcoin with the -debug switch, double-click the transaction, and post the transaction dump.

It just wasn't properly broadcast, probably. It's not queued. How long have you kept Bitcoin continuously open since you sent it?

It's pretty simple, which is why I didn't mention it. The client will only send coins with >6 confirmations unless you have none of those left. So you just keep depositing and withdrawing lots of coins and MyBitcoin will quickly send every coin they have. Once the same coins start to be resent, you know you've seen them all. Now you know how many coins MyBitcoin has with high accuracy as well as exactly which coins make up that balance. You've also "brought to the surface" all of MyBitcoin's coins, which might allow other attacks.

I haven't tried this. Maybe MyBitcoin limits site-wide BTC movements, which might make it more difficult.

An acronym is a type of abbreviation. It would also be annoying if they said:


If they know that, then they can just say FF. Either spell it out or just use the abbreviation. There's no point in doing both unless you're going to reuse the abbreviation later in the post.

Every time I see something like this, I want to stab the author. The abbreviation is not important for the reader's understanding, and it's never used again in the post for ease of reference. It's totally pointless. Why would anyone write something like this!?

This is certainly one of my top three most annoying stylistic errors.

If someone releases a huge alternative chain, that chain would just get blacklisted by the next client version. The attacker could keep the network offline for as long as they maintain control, but it'd get sorted out eventually.

MyBitcoin is still accepting payments with only 1 confirmation. This is insane for a bank. Any miner capable of mining two blocks in a row can steal money from MyBitcoin pretty easily. I'm surprised no one has attempted it yet.

There's another attack made possible by accepting payments with less than 6 confirmations that would allow you to see exactly which coins MyBitcoin has, and possibly do other damage.

Bitcoin already supports OP_HASH256 in script, so it would be trivial to increase the number of addresses if it ever became a problem.

I mean that your method might be an improvement over incrementing the transaction version and doing a "phased rollout" for every script change.

It's easy to block annoying ones with Adblock Plus.

I don't like the idea of "stealing" threads from people and moderating them more heavily. Maybe they could be copied, so that both a heavily-moderated and lightly-moderated version exist.

SMF supports neither cloning topics nor requiring mod approval for replies, though.

Actually, I think it would work if there was just one OP_OP_ENABLE that takes a list of many opcodes to enable. If the node can't understand any of these opcodes, then it stops here. If it does understand all of the opcodes, it also needs to verify the transaction again as though it doesn't understand them, and this "legacy" verification must also pass.

This will prevent new nodes from allowing any transactions that would be rejected by nodes without an understanding of new opcodes. Then it should be safe as long as clients using new opcodes control the network.

It might be a better method of changing things than the currently-planned method.

Every time script is updated, the network will be split until everyone upgrades to the new version. So there's no point in adding "extensible" script ops: adding any extended script op in the future still requires everyone to upgrade if they want to be part of the Bitcoin network.

For example:


Old clients now have a different view of which blocks are valid. They are on a separate network, isolated from the rest of Bitcoin.

getblocks does not send just the latest hash. It sends a CBlockLocator object, which contains many hashes going far back into the chain.

You can change everything.

No, but probably a relatively small number of people share it.

For one thing, they should publish the results of the audit they claimed was performed.