Blockchain weaknesses, how does bitcoin solve/protect against it ?

[Skybuck]

Hello,

I have some questions about potential weaknesses in the blockchain idea and how bitcoin potentially solves it ?

First question:

1. Suppose the attackers manage to outrun the defenders with a blockchain of +1 for the attackers.

Are the attackers capable of replacing the entire blockchain with bullshit transactions ?

If not how does bitcoin protect against replacing/invalidating the entire blockchain ? (Perhaps it uses some kind of timestamp/datestamping to prevent this from happening ? For example after X days the transactions/blockchain cannot be replaced ?)

2. How does bitcoin protect against the "no work to do" situation ? For example: there are no transactions being broadcasted, miners have no work to do. But an attacker could make a bullshit transaction and start working on the next block, while the miners have nothing to do... (More or less related to question 1 as well).

Bye,
  Skybuck.

[1714150599]

1714150599

[1714150599]

1714150599

[1714150599]

1714150599

[BTCurious]

Note: I am using alternate terminology, better suited to explain bitcoin to new people, as discussed here. I'm trying to get this terminology used more, not implying you are new. The old terms are bracketed.

1. A ledger (blockchain) is a book with pages (chain of blocks). Every time 1 page (block) is written (added), it doesn't change all the previous pages in the ledger (blocks in the blockchain).
This basically means that to get your scenario of "replacing the entire blockchain with bullshit transactions" they would need to do all the calculations the recorders (miners) did since the start of bitcoin, doing a calculation for every page of this completely new book. This is practically impossible.

2. The recorders (miners) can record "empty" pages (blocks) without any transactions. This is no problem.

[Skybuck]

I found some partially answers to parts of my questions on this wikipedia link:

https://en.bitcoin.it/wiki/Weaknesses

Which I will quote here:

"
Every few releases of Bitcoin, a recent block hash is hardcoded into the source code. Any blocks before that point can't be changed. An attacker starting at that point would have to reduce the difficulty, but this would require him to generate blocks at a much slower rate than once per 10 minutes. By the time he finally gets to a difficulty of 1, a new version of Bitcoin with an updated hardcoded block will probably have been released.

"Block chain length" is calculated from the combined difficulty of all the blocks, not just the number of blocks in the chain. The one that represents the most CPU usage will win.
"

My thoughts on it:

The hardcoded block hash, assuming it is just a hash, offers some protection, but not absolute protection, a block hash collision might still be found by an attacker, which could still allow him to change the history of the blockchain.

This is pretty much the same thing as "bitcoin mining" where a hash needs to be find with zeros in it, except this time, the entire hash must match.

So it can probably be considered "maximum difficulty" for the attacker.

Which is a good question: Is there such a thing as "maximum difficulty" ?

If not, how is maximum difficulty extended to infinity ?

If no, then bitcoin might fail in the future when maximum difficulty is easily processed.

(Let's call this: "Super computer in your pocket which does maximum difficulty attack in 1 second " )

The block chain length is kinda interesting, this requires the attacker to examine the real blockchain, and make sure his fake blockhain is longer...

[Skybuck]

Note: I am using alternate terminology, better suited to explain bitcoin to new people, as discussed here. I'm trying to get this terminology used more, not implying you are new. The old terms are bracketed.

1. A ledger (blockchain) is a book with pages (chain of blocks). Every time 1 page (block) is written (added), it doesn't change all the previous pages in the ledger (blocks in the blockchain).
This basically means that to get your scenario of "replacing the entire blockchain with bullshit transactions" they would need to do all the calculations the recorders (miners) did since the start of bitcoin, doing a calculation for every page of this completely new book. This is practically impossible.

2. The recorders (miners) can record "empty" pages (blocks) without any transactions. This is no problem.

Ok, I get what you are saying.

This would require bitcoin to first examine the entire blockchain to make sure that all hashes are indeed valid and correct, and that all work was done.

However this does present a problem for the future: the idea was to "cut away the blockchain" and replace it with a hash only, this is the concept of the merkle tree.

Perhaps this is not yet done to make sure the blockchain is long, but after a certain while this long blockchain might become impractical and will have to be "pruned/cut away" leaving just a hash.

At that point it will become easier since there is no more blockchain to check it has been pruned away, leaving only the remaining blockchain to be checked.

Impossible is a dangerous statement to make, but I will accept it for now, but the impossibility will surely go down as computers become much more powerfull.

All processing power in the world today, might be in somebody's pocket in 10 years or so... perhaps the difficult will have risen or perhaps not, see my question about maximum difficulty.

So bottom line:

1. Large parts of processing power might be ignored because of merkle tree hash pruning.

2. Large parts of processing power might be easily reproducible because of super computers in the future.

3. Leaving only recent work done, which leads to the question of "maximum difficulty".

If maximum difficulty is achieved in 1 second times, then perhaps switching to a different hashing technique might be possible to increase it... so this probably answers my own question about difficulty.

However getting the whole world to switch to a new standard is difficult as ipv4 to ipv6 has proven to be


Considering your point 2: miners can do empty transactions, is this actually done in practice to work when there is nothing real to work on ?

[BTCurious]

Ah, I didn't understand you were talking about cutting away part of the blockchain.

So: Hash collisions. If hashes are 160 bits long, every new hash you generate has a 1 in 2^160 chance of being the same. If an attacker could generate new hashes at, say, 1 Ghash/sec (4 high end videocards) times, say, a million people (it's a well-connected attacker, I'm being generous here ), then it would take them on average 460 000 000 000 000 000 000 000 centuries to find the same hash. Or, in one century, they would have a chance of 0.0000000000000000000002% chance of finding it in one century.

But let's say the processing power doubles every year. Then after ten years the chance would be 0.00000000000000000004% (That's 2 zeroes less than that century chance up there).

In 100 years we would have a problem, if processing power doubles every year. In 100 years things will be rather different anyway. Let them figure that out

I'm not too familiar with the exact idea for cutting away the blockchain, but this seems possible, for at least the coming tens of years.

[Skybuck]

Ah, I didn't understand you were talking about cutting away part of the blockchain.

So: Hash collisions. If hashes are 160 bits long, every new hash you generate has a 1 in 2^160 chance of being the same. If an attacker could generate new hashes at, say, 1 Ghash/sec (4 high end videocards) times, say, a million people (it's a well-connected attacker, I'm being generous here ), then it would take them on average 460 000 000 000 000 000 000 000 centuries to find the same hash. Or, in one century, they would have a chance of 0.0000000000000000000002% chance of finding it in one century.

But let's say the processing power doubles every year. Then after ten years the chance would be 0.00000000000000000004% (That's 2 zeroes less than that century chance up there).

In 100 years we would have a problem, if processing power doubles every year. In 100 years things will be rather different anyway. Let them figure that out

I'm not too familiar with the exact idea for cutting away the blockchain, but this seems possible, for at least the coming tens of years.

Originally I was indeed considering replacing the entire blockchain... however if only a hash is stored then that's pretty much the equivalent... so I am just exploring both options.

Anyway hashes are broken all the time, and I think sha-1 was already broken, then there are also rainbow table attacks, birthday attacks, and so forth... I am not expert in that... but I know attack methods exist.

Did you include algorithm attacks in your chances calculations ? I don't think so... so sha-2 might be broken much more quickly... and hash collisions could become pretty real.. ?!

[BTCurious]

Algorithm attacks is weaknesses in the algorithm? I did not take those into account, no. Using two different hash algorithms reduces this chance greatly (ripemd-160 and sha160 for example. This is already done for bitcoin addresses, as far as I know).

birthday attacks is pertaining to the birthday paradox? That will account for an increased chance equal to the number of hashes you are considering as a 'success'. Won't be a lot.

SHA-1 is not really broken, but rather weaker than originally thought. A collision can theoretically be found in about 2^51 processing steps. This is still a pretty significant number.

Rainbow tables can't be used, since we need to make an actual blockchain. Rainbow tables are only generated for short strings. Generating them for a blockchain-type message would take longer than just doing the attack.

So to sum it up, it may be true that at some point this could pose a problem. However, I don't expect this to be in at least 5 years, more likely 20.

[DeathAndTaxes]

Anyway hashes are broken all the time, and I think sha-1 was already broken, then there are also rainbow table attacks, birthday attacks, and so forth... I am not expert in that... but I know attack methods exist.

rainbow tables = only work because one can search a tiny % of possible hashes due to fact that most passwords have only small amount of entropy
birthday attacks = only work when the chance is small relative to the number of trials (checking 1 day vs only 31 possible chances and 20 kids in the class)

SHA-1 isn't already broken.  Flaws have been found which reduce its strength.  Its strength currently is still more than adequate but it is a good idea to move to more secure algorithms in case deeper attacks are found in the future.  This highlights how attacks which completely break an algorithm tend to not just appear out of nowhere.  The first attack on SHA-1 was published in 2005, 8 years later it still requires 2^51 operations to find a collision in SHA-1 (vs 2^80 by brute force).  So while SHA-1 is 8 million times weaker it is still computationally intensive to find collision.  Far too computationally intensive to be of any practical value. 

Still companies are urged to move away from SHA-1 to stronger algorithms.  SHA-1 may be broken eventually but it likely will be decades after the first flaws were published.  Bitcoin is capable of changing algorithms if a flaw was found in SHA-256 there would be litterally years (maybe decades) to plan for a migration.

Did you include algorithm attacks in your chances calculations ? I don't think so... so sha-2 might be broken much more quickly... and hash collisions could become pretty real.. ?!

I don't think you realize how large 2^256 is.  Hey it is only 256 it doesn't sound that much bigger than 32 bit or 64 bit right?

Lets assume:
Someday Bitcoin has 10 billion users and they on average have 1 million active addresses or 1 quadrillion known addresses/hashes. 

Lets also assume that computers are so powerful they could instantly find collision in a 56bit hash (DES) in 1 second.  For the record today it takes roughly 24 hours to find a collision in DES using special built hashing array so that would be on the order of  100,000x increase in computing power.

Lets also assume you used 1 billion computing nodes nonstop 24/7 to look for collisions.  The have a 0.01% chance of finding a collision would on average take  5,095,567,111.43 quadrillion years.   

Now lets say an attack similar to the one found on SHA-1 reduced the number of rounds from 2^80 to 2^51 in that case it would "only" take you 607 quadrillion years .... to have a 0.01% chance of finding a collision against a random existing hash.

[JoelKatz]

However this does present a problem for the future: the idea was to "cut away the blockchain" and replace it with a hash only, this is the concept of the merkle tree.

Perhaps this is not yet done to make sure the blockchain is long, but after a certain while this long blockchain might become impractical and will have to be "pruned/cut away" leaving just a hash.

At that point it will become easier since there is no more blockchain to check it has been pruned away, leaving only the remaining blockchain to be checked.

If the pruned away part of the blockchain is replaced with just a hash, replacing that part of the blockchain will go from difficult to impossible. The client could not possibly accept a different view of those blocks because it would have no way to undo their transactions and replace them with transactions in different blocks. A client can only reorganize the block chain for blocks it has. Any pruning of the block chain would only be possible for blocks that had been permanently locked in.

Pruning a block means forever accepting the version of that block you pruned. Without the old contents of that block, there's no way you can replace them with new contents.

[Skybuck]

However this does present a problem for the future: the idea was to "cut away the blockchain" and replace it with a hash only, this is the concept of the merkle tree.

Perhaps this is not yet done to make sure the blockchain is long, but after a certain while this long blockchain might become impractical and will have to be "pruned/cut away" leaving just a hash.

At that point it will become easier since there is no more blockchain to check it has been pruned away, leaving only the remaining blockchain to be checked.

If the pruned away part of the blockchain is replaced with just a hash, replacing that part of the blockchain will go from difficult to impossible. The client could not possibly accept a different view of those blocks because it would have no way to undo their transactions and replace them with transactions in different blocks. A client can only reorganize the block chain for blocks it has. Any pruning of the block chain would only be possible for blocks that had been permanently locked in.

Pruning a block means forever accepting the version of that block you pruned. Without the old contents of that block, there's no way you can replace them with new contents.

Let's see if I understand correctly, and then examine a possible way of totally replacing the blockchain.

Conceptually speaking, all bit coins in existence form a chain of coins. These coins can be moved around from person to person, account to account, can be transerred, sold, bought etc.

Everytime coins are exchanged the chain starts to grow with new coins.

A possible problem with this concept is the chain grows too large.

So the idea is to cut away the tail of the chain to make it shorter again.

The idea behind cutting away the tail is to replace the tail with a single hash. (Merkle Tree Partially collapsed ? or perhaps something else, simply a single hash unrelated to merkle, or perhaps a new merkle hash root node, since something has to be the previous hash for the last block in the tail ?).

Anyway the question is now:

What happens about all the transaction data ?

You seem to imply as well, that this transaction data would have to been thrown away as well, since that would otherwise also grow to large, and since the blocks have been thrown away it makes no sense to store the transactions.

So the bottom line is:

1. Blocks are thrown away.
2. Transactions are thrown away.
3. What remains is a single hash.

My claim/idea was that an attacker could create "fake" transactions which represent the transactions which were thrown away in step 2.

You claim that doing so would be useless, because the entire network/system has apperently agreed to cut away the tail.

So everybody using bitcoin throws away the tail, the blocks, the transactions that went with it, and everybody agrees that that data is now no longer in play.

So you say making those fake transactions won't be usefull because they would be rejected by the system

You seem to say that these transactions cannot be re-injected into the system ?!?

But then my question is:

How does the remaining part of the system, the section beyond the tail, the section that was not cut off know who owns what ?

All those transactions which were done before the tail was cut off, result into some kind of wealth, some kind of account money ?!?

I assume that when a bitcoin application starts up, it starts to scan all transactions for it's own addresses, sums them together and thus figures out what it's balance is ?!?

If those transactions have been thrown away, and/or the blocks are not available for verification purposes ?!?!? Then how would the client know what it's balance is ?!?!?

Is this perhaps why bitcoin could be considered a pyramid scheme ?!?!? Once the cut happens wealth disappears ?!?!?

[BTCurious]

When you spend coins, you tell the network: I take the coins from this transaction and that transaction as inputs, and send them to this address and that address as outputs. You never actually store any coins, you just know which transactions went to your address, and which of those have been "spent", i.e., sent to a different address.

If the blockchain is collapsed or whatever, only the transactions that have been spent would be removed. That way you could still scan the blockchain, and find out how much money you have, by adding all transactions that have not yet been spent.

If there was an attacker claiming "Look! I have this trail of (fake) transactions, and they add up to this hash!" then they would still need to add up to the transactions to your address which you haven't spent yet. This means the attacker doesn't actually achieve anything with his 'attack'. That is beside the point that finding a hash collision really is impossible for the coming few decades.

[Skybuck]

Addition to my previous posting: By the way this means there is another potentially way/attack to bitcoin:

A trojan/virus/malware/worm could start to alter the data which is on everybodies drive and starts to create it's own fake chain as an attempt to chain the thruth.

If the trojan/virus/malware/worm manages to infect enough system for example the 51% then history could be altered ?!?

[Skybuck]

When you spend coins, you tell the network: I take the coins from this transaction and that transaction as inputs, and send them to this address and that address as outputs. You never actually store any coins, you just know which transactions went to your address, and which of those have been "spent", i.e., sent to a different address.

If the blockchain is collapsed or whatever, only the transactions that have been spent would be removed. That way you could still scan the blockchain, and find out how much money you have, by adding all transactions that have not yet been spent.

If there was an attacker claiming "Look! I have this trail of (fake) transactions, and they add up to this hash!" then they would still need to add up to the transactions to your address which you haven't spent yet. This means the attacker doesn't actually achieve anything with his 'attack'. That is beside the point that finding a hash collision really is impossible for the coming few decades.

What matters is what is stored. The transactions as far as I know are stored on disk ? The transactions are the archive which could be used to makes sense out of things.

You seem to imply that there is a difference between "spending" and "receiving" ? Does this mean there is a difference between "spent" and "receive" transactions ?

What does this mean for a potential collapse/cut of of the trail ? Does this mean all "receive transactions" are kept and the "spent transactions" can be thrown away ?

If so then suddenly you would become rich because it would seem you didn't spent anything ? So that doesn't make sense.

Another conclusion could be possible as well:

If the fake blockchain does not add up to your account balance, then your account balance is fraud !

In another words if suddenly the fake blockchain would be acceptable by a majority for some strange reasons, for example some people got rich and don't mind getting rich, and some people lost a lot, then oops.

If you would be the person suddenly losing a lot, and you complained the guys who got rich would say well ofcourse he's complaining, he's poor and a fraud !

[Skybuck]

Perhaps I miss-understand the roll of the hashes and the merkle hash tree.

This article seems to explain it a bit more:

http://sakabatou.dyndns.org/b2evolution/index.php/2011/09/04/how-does-bitcoin-work-technical

Apperently the merkle hash tree is used to allow, multiple chains to exist.

Once the longer chain is discovered after 100 blocks it becomes the main chain.

The other leaves/trees are collapse and re-fed into the system/chain/merkle hash to be tried and reincluded into the system.

So perhaps the blockchain itself is never pruned ?!? The tail is never cut off !?

The blockchain must always keep existing ?!?

This then raises the question:

What if the blockchain becomes to large for average computers to store ?!?!?!?

Does this mean that if bitcoin grows faster then harddisk space that bitcoin will more or less be doomed ?! At least for average people ?!?

Hmmm...

Maybe some compression can help for a while...

I shall have to re-examine how it all works and what's possible for attack vectors

[BTCurious]

You seem to imply that there is a difference between "spending" and "receiving" ? Does this mean there is a difference between "spent" and "receive" transactions ?

A transaction is basically a bit of info roughly structured like this:

Code:

Transaction ID: 1234321
Inputs:
    Transaction ID: 1234300
        Output number: 3
    Transaction ID: 1234301
        Output number: 1
Outputs:
    1:
        Address: 1myaddressarstarstarstarst
        Amount: 10 BTC
    2:
        Address: 1someaddressarstarstarstar
        Amount: 30 BTC

Now if I own 1myaddressarstarstarstarst, then I can make a transaction like this:

Code:

Transaction ID: 1234322
Inputs:
    Transaction ID: 1234321
        Output number: 1
Outputs:
    1:
        Address: 1youraddressarstarstarstar
        Amount: 10 BTC

If I have broadcasted that transaction, and it's verified and accepted, then Transaction 1234321's output 1 will no longer be used. Thus you could forget about it.

[DeathAndTaxes]

Addition to my previous posting: By the way this means there is another potentially way/attack to bitcoin:

A trojan/virus/malware/worm could start to alter the data which is on everybodies drive and starts to create it's own fake chain as an attempt to chain the thruth.

If the trojan/virus/malware/worm manages to infect enough system for example the 51% then history could be altered ?!?

Still can't get around the proof or work requirement.

If an attacker modifies a block that block now needs to be "signed" w/ a hash.  Finding that hash would require attempting quadrillions of hashes (just like when block was originally signed).  This is what we are doing when we "mine" for coins.

Simplistic outline of mining:
1) Take all transactions that will be in the block.
2) Make a coinbase transaction which awards the block reward + any transaction fees to the miner's address
2) Create merkle tree of all transactions in the block
3) Take the version, merkle root, time, prior block hash, target, and nonce (value from 0 to 2^32 -1).  This forms the block header.
4) double hash the block header.  check if hash is smaller than the target.  if so then submit to network.
4a) if double hash is not msaller than target discard, increment nonce and goto step 4
4b) if nonce is max nonce then modify coinbase (creating different merkle tree), reset nonce to 0 and goto step 4

So for a malware to rewrite existing blocks would require not just 51% of hashing power but 51% of hashing power PLUS more hashing power to retroactively rewrite older blocks.   

[DeathAndTaxes]

As far as blockchain pruning no client currently does this but you can prune any block where ALL the coins have changed after the block to be pruned.

For example say in block 105 there is only a single transaction the coinbase.
50 BTC -> address 123

later in the block chain (say block 210) you have this transaction
address 123 tx 50 BTC to address 999

If block 210 has been accepted by the network (and now is considered canonical by both age and being behind checkpoints) there is no need for block 210 anymore.

The client could mark block 105 as pruned (leaving only the hash to allow validation of block 106), delete the data from block 105 and mark the input of address 123 in block 210 as from a pruned block.

This was a simplistic example.  If a block involves multiple transactions then all coins from all transactions must be involved in a subsequent block in order for the block to be pruned.  This means addresses with "lost coins" can never be pruned.

Still there is sufficient number of "dead end" transactions that IIRC there was a simulation showing block chain pruning could reduce size of blockchain by about 70%.

[JoelKatz]

Let's see if I understand correctly, and then examine a possible way of totally replacing the blockchain.

Conceptually speaking, all bit coins in existence form a chain of coins. These coins can be moved around from person to person, account to account, can be transerred, sold, bought etc.

Everytime coins are exchanged the chain starts to grow with new coins.

A possible problem with this concept is the chain grows too large.

So the idea is to cut away the tail of the chain to make it shorter again.

The idea behind cutting away the tail is to replace the tail with a single hash. (Merkle Tree Partially collapsed ? or perhaps something else, simply a single hash unrelated to merkle, or perhaps a new merkle hash root node, since something has to be the previous hash for the last block in the tail ?).

That's correct. You remove the entire chain and all you keep is the hash and a table of all Bitcoins that are still spendable. You throw everything else away.

Anyway the question is now:

What happens about all the transaction data ?

All you need is the transaction IDs and output offsets of any outputs that are still spendable. You can throw everything else away.

You seem to imply as well, that this transaction data would have to been thrown away as well, since that would otherwise also grow to large, and since the blocks have been thrown away it makes no sense to store the transactions.

Well, you have to keep track of all coins that are spendable. Other transactions can be thrown away.

So the bottom line is:

1. Blocks are thrown away.
2. Transactions are thrown away.
3. What remains is a single hash.

In principle, all that remains is a single hash. But that hash is sufficient to reconstruct the one and only state of all current transactions.

My claim/idea was that an attacker could create "fake" transactions which represent the transactions which were thrown away in step 2.

How could he? One of two things would have to be the case for the transactions to be accepted:

1) They'd have to claim spendable transaction outputs that this node still knows. In which case, in what sense are the transactions "fake"?

2) They'd have to claim spendable transaction outputs that could be proven valid based on the hash the node still knows. In this case, the attacker either needs to find a hash collision (in which case, everything is screwed) or the transaction must claim valid outputs.

You claim that doing so would be useless, because the entire network/system has apperently agreed to cut away the tail.

So everybody using bitcoin throws away the tail, the blocks, the transactions that went with it, and everybody agrees that that data is now no longer in play.

So you say making those fake transactions won't be usefull because they would be rejected by the system

You seem to say that these transactions cannot be re-injected into the system ?!?

They cannot be injected because they do not claim transaction outputs that any node would consider valid by any method.

But then my question is:

How does the remaining part of the system, the section beyond the tail, the section that was not cut off know who owns what ?

They either keep track of all spendable transaction outputs or they require verifiable proof that there exists a spendable transaction output that they don't know of -- validating by hashes and signatures traceable back to data they know is valid.

All those transactions which were done before the tail was cut off, result into some kind of wealth, some kind of account money ?!?

They're still valid. Their outputs are still spendable.

I assume that when a bitcoin application starts up, it starts to scan all transactions for it's own addresses, sums them together and thus figures out what it's balance is ?!?

If those transactions have been thrown away, and/or the blocks are not available for verification purposes ?!?!? Then how would the client know what it's balance is ?!?!?

The client would store its balance, along with the identities of any transaction outputs it could spend.

Is this perhaps why bitcoin could be considered a pyramid scheme ?!?!? Once the cut happens wealth disappears ?!?!?

Nothing disappears. The cut is just to save memory and disk space. The semantics remain precisely the same. The difference is that everyone can forget about transactions with no spendable outputs and they can forget about blocks prior to a checkpoint.

[JoelKatz]

So perhaps the blockchain itself is never pruned ?!? The tail is never cut off !?

Currently, the chain is not so big that anyone has implemented any pruning. Pruning is a bit tricky to do correctly.

This then raises the question:

What if the blockchain becomes to large for average computers to store ?!?!?!?

Then clients can start using pruning. But disk space is growing much faster than the hash chain, so this may never be an issue.

Does this mean that if bitcoin grows faster then harddisk space that bitcoin will more or less be doomed ?! At least for average people ?!?

Probably people will cut over to clients that don't keep the entire block chain but instead keep only their own transactions.

[Terikan]

Addition to my previous posting: By the way this means there is another potentially way/attack to bitcoin:

A trojan/virus/malware/worm could start to alter the data which is on everybodies drive and starts to create it's own fake chain as an attempt to chain the thruth.

If the trojan/virus/malware/worm manages to infect enough system for example the 51% then history could be altered ?!?

Still can't get around the proof or work requirement.

If an attacker modifies a block that block now needs to be "signed" w/ a hash.  Finding that hash would require attempting quadrillions of hashes (just like when block was originally signed).  This is what we are doing when we "mine" for coins.

Simplistic outline of mining:
1) Take all transactions that will be in the block.
2) Make a coinbase transaction which awards the block reward + any transaction fees to the miner's address
2) Create merkle tree of all transactions in the block
3) Take the version, merkle root, time, prior block hash, target, and nonce (value from 0 to 2^32 -1).  This forms the block header.
4) double hash the block header.  check if hash is smaller than the target.  if so then submit to network.
4a) if double hash is not msaller than target discard, increment nonce and goto step 4
4b) if nonce is max nonce then modify coinbase (creating different merkle tree), reset nonce to 0 and goto step 4

So for a malware to rewrite existing blocks would require not just 51% of hashing power but 51% of hashing power PLUS more hashing power to retroactively rewrite older blocks.   

Firstly, sorry for necro'ing.  I'm going to write an article about bitcoins as they have become interesting to people in the investing world.  However, as more of a computer guy than most traders, I came here out of concerns about the integrity of the transaction system used by bitcoin.  In particular, this quote above leaves me with more questions than answers, so I thought maybe I could ask for some more info.

"Still can't get around the proof or work requirement.

If an attacker modifies a block that block now needs to be "signed" w/ a hash."

Simple question, why?  You've got these blockchains duplicated in computers all over the place, and no one who's checking for valid transactions (like retailers I mean) will know whether it's been signed with a hash, so if every blockchain gets modified in the same way by some sort of virus that utilizes some sort of software vulnerability and thereby was able to spread to every node in the network, how would an end user know what's valid or not? 

Is there some entity or centralized verifier somewhere that holds the key or algorithm to knowing when a transaction entry/hash is valid/invalid?  If the problem was simpler, conflicts between chains that could not be resolved, or massive deletions of transactions from the chain, is there a reference point somewhere that says "ok I'm the big guy in charge, copy from me to restore order". Break it down for me. 

Thanks.