I'm not sure if your question is based on an assumption about double-entry accounting. Bitcoin is not double-entry, at least in the sense that there aren't two separate entries. A transaction transferring $50 from Alice to Bob is a single thing in the global ledger, signed by Alice's key, transferring it to Bob. There's no way to sever "Alice spends $50" from "Bob receives $50", so even if you can cause transactions to be ignored, the whole thing, atomically, gets ignored. The transfer never happened, and no money is created or destroyed.

It is certainly possible for someone to modify a block and try to mine it. There's no required consensus process in advance; you can just try to generate a block that has the data you want, and find a hash that starts with enough zeros. (You can't alter a block so that money is spent without the consent of the money-holder, since each expenditure requires a digital signature. But if, say, Alice's key has signed both "Transfer this bitcoin to Bob" and "Transfer this bitcoin to Carol", you can mine either of those.)

The trouble with trying to do that is that mining is slow. The math problem is timed so that it takes roughly 10 minutes for someone, somewhere to successfully find an answer. So the CPU time is 10 minutes times the number of mining nodes on the Bitcoin network. If you, on your own computer, start trying to mine a block that's different from what everyone else is trying to mine, you are going to have to be extraordinarily lucky to be able to get the math problem solved on your own within 10 minutes. The entire rest of the Bitcoin network is trying to mine a different block, and they'll probably win.

Let's say that you are extraordinarily lucky, or maybe you control like 30% of the network and you're slightly lucky. What you've accomplished is to make a fork in the block chain: there are two blocks with the same parent. You can now send your fork to people, because there's no way to to tell which one was "real" and which one wasn't. But now you need to keep mining on your fork, because people will notice if the block chain mysteriously stops updating. You need to be incorporating everyone else's transactions onto your fork. So not only do you need to be lucky, you need to be repeatedly lucky, all the time, so that your mining keeps up with the other fork. This is only feasible if you actually control 50% of the network.

But still, what have you accomplished? There's no "merge" in Bitcoin. Everyone sees a single history. If they see two blockchains updating at the same speed, they know that something is up and it can be resolved by humans; no program is going to simultaneously trust both histories. So either Alice transferred a bitcoin to Bob (and thus not to Carol), as she authorized, or she transferred a bitcoin to Carol (and therefore not to Bob), as she authorized, or the bitcoin remains with Alice and no transaction happened. The best you can do is prevent people from spending their money, if you reliably control 50% or more of the network. You can't cause money to be double-spent.

And yes, it is common to wait 10 minutes or often 60 minutes to wait out an attacker's luck, at least for large transactions. The official Bitcoin client calls transactions "unconfirmed" until it sees six blocks mined on top, at which point it's assumed infeasible for you to have a separate history from the rest of the network. For smaller transactions, people tend not to wait as long. But the same thing happens with conventional currency. Most stores don't check small bills with counterfeit pens. Most credit card readers support offline transactions, but you get the product immediately. Personal checks can take up to a month to clear or bounce. If there's something high-value, you get a cashier's check or you run a credit report on the person. Otherwise you trade off the risk for convenience.

See the Bitcoin wiki article on confirmation for a bit more discussion about how long to wait vs. how strong an attacker is: https://en.bitcoin.it/wiki/Confirmation

Let me know if I understood you correctly and whether that was answering the question you asked.