Thank you DeathAndTaxes for the response. Bob might not try to give the 80BTC to anyone for months. Eve might post her fraudulent transaction immediately. It seems Eve's would then be accepted (unless Bob's software tells him that someone else is trying to spend his 80BTC).
And if Bob and Eve did both send new transactions almost simultaneously and the nodes notice the double-spend, then how can Bob (aliased by his public key) ever convince the network that he is the proper owner?
Cheers, Ed
I misunderstood your first post and thus answered a question not asked likely adding confusion.
A transaction contains the outputs of the prior transaction. You must have the private key that corresponds to those outputs to transfer them.
So
Alice -> Bob. To spend Bob uses this output and signs it w/ his private key (only he has).
Alice -> Bob. Eve can't spend because to include this output she would need Bob's private key. Time doesn't matter. She will never be able to create a valid transaction from this input.
The output of that transaction is Bob's ADDRESS (
which yes is a hash (along with error checking & meta data of the public key but not the public key itself). To spend Bob includes his public key, the prior transaction output, the new destination, amount ,etc and signs everything w/ his private key.
With the public key they can reconstruct the prior output's address.
With the public key they can verify the signature.
This ensures other nodes can:
a) verify this output hasn't been used before (prevent double spend)
b) this transaction is signed by the right private key (ensure only owner can transfer).
Now "a" is only partially complete because no node can know it has seen all transactions. "a" is "solved" once it has been hashed into a block making a canonical record of the transaction preventing those outputs from being used again (well baring 51% attack).