How do transactions work?

If Alice wants to pay Bob via bank transfer, she notifies her bank. Let’s assume that the two parties use the same bank for simplicity’s sake. The bank checks that Alice has the funds to perform the transaction, before updating its database (e.g., -$50 to Alice, +$50 to Bob). This isn’t too dissimilar to what goes on with a blockchain. After all, it’s also a database. The key difference is that there isn’t a single party performing the checks and updating the balances. All of the nodes must do it. If Alice wants to send five bitcoins to Bob, she broadcasts a message saying this to the network. It won’t be added to the blockchain straight away – nodes will see it, but other actions must be completed for the transaction to be confirmed. See How are blocks added to the blockchain? Once that transaction is added to the blockchain, all of the nodes can see that it’s been made. They’ll update their copy of the blockchain to reflect it. Now, Alice can’t send those same five units to Carol (thus, double-spending), because the network knows that she’s already spent them in an earlier transaction. There’s no concept of usernames and passwords – public-key cryptography is used to prove ownership of funds. To receive funds in the first place, Bob needs to generate a private key. That’s just a very long random number that would be virtually impossible for anyone to guess, even with hundreds of years at their disposal. But if he tells anyone his private key, they’ll be able to prove ownership over (and therefore spend) his funds. So it’s important that he keeps it secret. What Bob can do, however, is derive a public key from his private one. He can then give the public key to anyone because it’s near-infeasible for them to reverse-engineer it to get the private key. In most cases, he’ll perform another operation (like hashing) on the public key to get a public address.