You've never heard of a loan, have you?  When you take out a loan, your bank produces dollars that did not exist previously.  No one cares which bank produced the dollars in your checking account, and no one even knows.

It is only physical paper dollars that have monopolized production, and those are a tiny, tiny niche in the dollar economy.

I didn't read very carefully, but I didn't see any part of this that wouldn't apply just as well to dollars.

I've never understood the notion of bitcoin as a commodity.

Money, in the abstract sense, is value that you have given to society, that you have not yet redeemed.  It is a token of a half-completed trade.  Bitcoin is an excellent implementation of that abstract idea.

No worries.  It happens.

Since everything goes through a dispatch table, it was easy enough to put duplicate entries in so that the old commands would keep working.  The catch is that the list of commands that you get from typing "bitcoind help" is generated from that table, and I wasn't sure how to prevent duplicates.  Turned out that the problem had already come up before and someone else had fixed it so I didn't have to.

You didn't actually look at my commit, did you? 

Start with the header.  It is described in that link I posted.  Be careful of endianness issues.  Once you get to the point where you can build a header and get the same hash that the rest of the network sees, you can move on to parsing the block body, which is fairly simple, and hashing the transactions to build the Merkle Tree.

Then you can start building a database of transaction outputs and checking that transaction inputs are valid.  The final step will be checking the signatures in the transactions.  The signatures themselves aren't too bad, but first you need to prepare it in a specific way.

https://en.bitcoin.it/wiki/Protocol_specification#Variable_length_integer VI pops up in a lot of places, you'll need to know how to read it to do anything
https://en.bitcoin.it/wiki/File:TxBinaryMap.png this map helps you parse transactions.
https://en.bitcoin.it/wiki/Script list of opcodes, needed for parsing scripts
https://en.bitcoin.it/wiki/File:Bitcoin_OpCheckSig_InDetail.png this map is for preparing transactions for signing
https://en.bitcoin.it/wiki/OP_CHECKSIG description of the signing process
https://bitcointalk.org/index.php?topic=101514.0 format of the block files, essentially a dump of the block messages minus the command string, also the magic and the blocksize aren't part of the block proper.

I had to rebase this against the latest master.  New link is:

https://github.com/kjj2/bitcoin/commit/4ba9b0603e235c2579622e3fc4d554da8507f345

First, the nodes don't have hardcoded trusted nodes.  There are DNS seeds that can be used when a new node is bootstrapping and needs a way to find running nodes to connect to.

Each block is composed of a header and a list of transactions.  The transactions are hashed together in a Merkle Tree and the root of that tree is included in the header in such a way that none of the transactions can be changed without changing the hash in the header.  The header also includes the hash of the previous header, proving that it came after the previous block, and also ensuring that the previous block can't be changed without changing the current header.

The nonce field is allowed to be anything at all, provided that it leads to a valid hash.  This means that each miner iterates through all 2³² possible nonces for the block candidate they are working on hoping that one of them works out.  If none works, they ask for a new candidate, which means changing the timestamp or Merkle root hash.  Changing the Merkle root means that at least one transaction needs to change (or a new transaction can be added).  The generate transaction is allowed to contain arbitrary data, giving nodes the ability to generate new trees as needed.

The header is then fed into hash=SHA256(SHA256(header)).  SHA256 is expected to have essentially a random distribution, meaning that the output is similar to getting a random number.  The network tracks a target value, and only accepts blocks that are less than the target.  There is no way to design a block header in advance that will have a hash that is below the target value, so miners have to check each one hoping to get lucky.  The current target gives each hash about a 1 in 15 quadrillion chance of being below the target, so miners are checking (in aggregate) about 25 trillion hashes per second.

When a new block is found, every transaction is checked to make sure it is well formed and valid, and that each redeemed output is valid and not previously spent.  The Merkle tree is created and checked to make sure that it matches the root hash in the header.  The timestamp is checked to make sure it is within the allowable range, the difficulty is checked to make sure it agrees with the network, and the header hash is checked to make sure it is below the target value.  If all of the checks are true, and the previous block hash in the header belongs to the block that was the previously highest block, the chain is extended.

When doing the initial download, some checks are abbreviated or skipped on old blocks, but the 2500 most recent blocks always get full verification.

These are pretty easy changes.

https://github.com/kjj2/bitcoin/commit/c82fa0b722b0aec843e4538b1f21f5298fb2fee6

I changed the names of the functions too, so I'm running a full recompile to make sure I didn't typo anything.

This isn't worth 5 BTC by the way.  If this gets accepted, either give the bounty to some worthy cause, or hold onto it until you have a more difficult change request.

So, you see the correct icon for the attacker's address.  Nothing gained.

Well, you are wrong about that.  If that is the conclusion you've come to, then you aren't tracking the costs and rewards properly along with the probabilities of success for all of the parties.  It gets worse when you add in reputation costs, but even ignoring those, it still doesn't work.

Have you tried the importprivkey RPC call on a normal bitcoin 0.7.1 node?

Sounds to me like the WIF is incorrect, but the tools you are using aren't checking the checksum, so they happily import it, but since it isn't right, they can't actually make a valid signature for it.

It would be hard to know more without seeing it, and you probably don't want to hand a stranger on the internet what could be $500.  That said, I'd be willing to take a look at it if you'd like.

In a transaction big enough that you can afford to bribe miners to reverse it?  Not likely.

Don't forget that no one will ever trust the attacker again after he publishes the proof of his misdeeds for the entire world to see.  Also, no one should be accepting transactions on low confirmation counts unless they can afford to lose it.

Heh.  You didn't actually read that article did you?

Look at the transaction that you got.  The input part of that transaction will have a list of transaction outputs redeemed.  For each of them, look up the transaction and check the scriptpubkey part of that output.

But you really should figure out a way to do whatever you are doing that doesn't require that, because no matter how much you think you need it, the system totally doesn't work that way.  Transactions do not have From: addresses.

The biggest consequence is that no one would have taken it seriously.  And even now that MD5 is considered to be totally broken and should never be used for anything at all, the other constraints in the system would cover our asses if we used them.

Being able to find a collision in MD5 is totally not the same thing as being able to find two valid blocks with the same MD5 hash, or two valid transactions with the same MD5 hash, or two private keys where the corresponding public keys have the same MD5 hash.

Pieter is right, collision attacks don't hurt us at all, and even in MD5, preimage attacks don't exist.  Well, they sorta do, but they still require more than 2¹²⁰ operations, making them barely better than brute force.  And I'm not even sure that a full preimage attack could meet the system requirements.

Ok, so they vote.  So what?  What do you think they will be voting on, and who do you think will be bound by the votes?  What sort of matters do you think that foundation has authority over?

You haven't even said it once yet!  You are just repeating your baseless assertion that the foundation has magical powers for evil.

And if you really think that my English skills are lacking, I'd be happy to take the red pen to your posts and fix all of your trivial errors.

It would be expensive to do this.

The network uses a calculation called priority to decide if it should relay your transaction without requiring a fee.  The basic idea is that a simple transaction takes about 250 bytes, and "1 BTC that is 1 day old" is a good rule of thumb.  So, we look at each of your inputs and calculate the amount in BTC times the number of confirmations, and add those up.  Then we divide by the size of the total transaction, and if the ratio of BTC-days to bytes is worse than 1:250, we don't relay it until it has aged enough to make that ratio true.*  The standard behavior for mining is then to do the same calculation to decide if that transaction should be included in the next block candidate created.  **

So, if you are redeeming a 1 BTC input that has 1500 confirmations, most of the network will accept it with no fee up to about 2500 bytes, (very) roughly 10 outputs.  But then each of those outputs will be 0.1 BTC, and you won't be able to send them for free until 10 more days have passed.  If you need to move them faster, you can do so, but not for free, you need to include a fee in your transaction.

Spamming the network in this way very quickly becomes too costly to do.

* nodes running different software, or that have been modified, will do this differently.  Some nodes relay everything on principle.
** nodes running different software, or that have been modified, will do this differently.  Some nodes mine everything on princple.