The protocol supports alternative ports just fine, though you won't receive incoming connections because Bitcoin prefers not to connect to peers that are using non-standard ports.

This is the only puddinpop server currently online as far as I know.


No. That's a recommendation for the sake of anonymity, but it isn't required.

You can see the block on BBE as soon as it is generated (1-minute delay). If it shows up there, it probably won't be reversed, though from time to time this does happen. It won't appear in your balance until it is 120 blocks deep.

The block hash is printed to debug.log by Bitcoin when you find a block. poclbm itself might also do this.

You can use the hash to search BBE for the block.

It was generated recently:
http://blockexplorer.com/block/0000000000004a60c3ab36de39e76055a1df300c3c7e08a5d49d1a44d33140fa

I don't know which pool generated it, but you were part of it for at least a short while.

Puddinpop pool servers payout directly in that way.

Two different transactions to the same address will have different txids (and possibly other info).

Right now you have to delete the block database. It is possible for Bitcoin to re-scan the blocks. It doesn't look too difficult: loop through every block and run AddToWalletIfMine on each tx.

Yes. Fortunately, only the owner of the address ever needs to do this.


It's not that hard to scan through transactions, especially if you're not actually verifying the crypto for each one (which a lightweight client doesn't need to do).

"sendfrom" doesn't actually send bitcoins from a particular address/account. It just reduces the account's balance after sending.

If you can send from a particular address, you could just send a pre-set number of bitcoins from the old owner to the new owner. The stock broker watches the block chain for transactions of a certain amount from the current owner, and whoever first receives coins of the proper amount from that address becomes the new owner.

ECDSA doesn't support encryption.

I made a couple of new Real-Time Stats pages for things like this:
http://blockexplorer.com/q/getreceivedbyaddress
http://blockexplorer.com/q/addressfirstseen

If you use /q/addressfirstseen, you'll be able to make a really nice script for distributed timestamping.

If I owned BSB, I wouldn't mind. Your claim doesn't take long to verify.

Don't generate directly to site balances. The current version of bitcoind is incapable of detecting these transactions. There's nothing sites can do to fix it.

It's possible, but Bitcoin doesn't do it. A future version of Bitcoin might do it, though. In any case, it will be possible to manually extract keys from an old wallet and insert them into a new one.

Take the average number of hashes required to solve a block:
http://blockexplorer.com/q/hashestowin
And divide that by the average interval between the last 1000 blocks or whatever:
http://blockexplorer.com/q/interval/1000

Right now it's ~102 ghash/s.

The public/private keys are in there, so it should always be possible to recover them, even if Bitcoin can't do it automatically.

It will (for a while, at least). ArtForz will have 65% of the network.

With this much CPU power, he could actually prevent all other blocks from making it into the chain. I don't think he will do this, though.


Pool mining will still be unprofitable electricity-wise. They could be powered by volunteers, of course.

Good idea. Bitcoin's network is weak, and you can do a lot of mischief if you can totally surround someone.

The attack as you described it would be entirely possible if not for block timestamps. Difficulty is based on block timestamps, and blocks are rejected if their timestamps are too far from reality. An attacker attempting your attack would therefore have to match the difficulty progression of the real network in order to get a final timestamp that matches reality. If an attacker can do that, then they can overcome the real network.

An attacker that is totally surrounding the bank can put it on a separate chain. The attacker will produce blocks slower than the real network, but the bank will accept them if those are the only blocks they see. This allows double-spending attacks against the bank, which may result in the bank accidentally becoming fractional-reserve. A later version of Bitcoin will probably produce a warning when it's receiving blocks more slowly that it should.

In the future Bitcoin might support an ultra-lightweight mode that doesn't even download full blocks. This mode is clearly not meant for banks, but if the bank is running in this mode and surrounded, you can generate fake coins and make the bank take them. The bank can't verify the transactions for itself, so it relies on hash trees in the block chain. If the chain is bad, then even a transaction for 21 million BTC could be considered valid by such a client.

See http://www.bitcoin.org/wiki/doku.php?id=weaknesses#cancer_nodes

Actually surrounding someone is difficult because Bitcoin will only make outbound connections to IPs on different /16 networks. Still, a bank would be wise to set -maxconnections=50 and connect to a couple of fallback nodes.

ArtForz is planning on buying $200,000 in custom mining hardware. GPU mining will then become unprofitable for everyone. I don't know when he's going to do this (and it's not sure that he will), but I wouldn't risk buying a GPU for mining.

You need to use a 160-bit hash. SHA-1 or RIPEMD-160, for example. You could also truncate the SHA-256 hash to 160 bits -- this generally gives nearly as much security as using the entire hash. Ensure that you give /q/hashtoaddress exactly 40 hex characters in order to receive a valid address.

For Bitcoin addresses, Bitcoin first does a SHA-256 hash and then does a RIPEMD-160 hash on the output.