How is Recipient's Public Key Used When Receiving Coins (if at all)?

Question

I understand the above image is dated--I posted here just for reference.

Assume the first tx is for Alice (Owner 1) and the second is for Bob (Owner 2). My previous question (Confused About Hash In Satoshi Nakamoto Diagram) covered that the signature that ends up in the second transaction uses ECDSA and takes the Owner 1's private key and a message as input. The message is the hash of the transaction 1 (less the sig). The sig that gets stored in transaction 2, if verified with Alice's public key, proves that Alice released funds to Bob.

But how does the network know that Alice meant to give these funds to Bob? When Alice "sends" coins to Bob, she first get's Bob's address (let's just keep it simple for now and say that Alice has Bob's public key). After that, it seems to me that the network would encrypt the Alice's signature with Bob's public key so that when Bob wants to verify the sig with the ECDSA verification algorithm, he first would need to successfully decrypt the sig with his private key. Is that correct? The other way I can see it working is if the network creates transaction 2 with Bob's public id in it, and that only Bob can use the funds in that transaction record because to spend those funds, Bob will need the private key.

If neither assumption above is correct, is there anything about the protocol that ensures Alice's transfer of ownership reaches the intended recipient? If she makes a mistake in the recipient public key, is there any way for her to correct her mistake if Bob never receives the coins?

Answer 1

how does the network know that Alice meant to give these funds to Bob?

Transactions have different parts, an input section that specifies which funds are being spent (and proves the spender is authorized to spend them) and an output section that specifies the recipient(s):

Looking at it in a little bit more detail, outputs contain the amount to spend as well as the public key script (scriptPubKey) that will be used to determine whether or not a future spender is authorized to spend the funds. The input identifies the funds being spent by their hash (the transaction identifier) plus the indexed number of the output in that transaction, and then provide a signature script (scriptSig) containing data that is evaluated in the context of the scriptPubKey to determine whether or not the spender meets the spending conditions. In a conceptual model, the scriptPubKey is a public key, the scriptSig is a signature, and the signature has to be valid for the public key over all the data in the spending transaction (minus the signature itself). (That's not exactly how it really works in Bitcoin, but that's the principle.)

it seems to me that the network would encrypt the Alice's signature with Bob's public key

Bitcoin's consensus protocol doesn't use encryption. In Alice's transaction, she places an output saying "pay <Bob's public key> 100 bitcoins"; when Alice signs the whole transaction, she both proves that she's authorized to spend those 100 bitcoins and protects all the data in that output against change by any third party (because they can't create a signature using Alice's private key). (Assuming Alice has sole possession over her private key, there's no multisig in use, ECDSA hasn't been broken, etc...)

The other way I can see it working is if the network creates transaction 2 with Bob's public id in it, and that only Bob can use the funds in that transaction record because to spend those funds, Bob will need the private key.

This is conceptually correct. In practice, the protocol just evaluates scriptPubKeys and ScriptSigs, which can do whatever they want within the limits of the language, rather than having a specific notion of key-based identifiers.

is there anything about the protocol that ensures Alice's transfer of ownership reaches the intended recipient?

Alice's signature protects her transaction against modification (with the same caveats as listed before).

If she makes a mistake in the recipient public key, is there any way for her to correct her mistake if Bob never receives the coins?

If the transaction has not been confirmed, Alice can create an alternative version of the transaction, broadcast that, and hope the alternative gets confirmed. After confirmation, there's nothing Alice can do to change the spending conditions (scriptPubKey).

It is possible for Alice to pay a scriptPubKey that allows her to reclaim the funds if they haven't been spent by Bob within a specified amount of time. This mechanism is used to prevent denial-of-service attacks in payment channels, but I've never heard of anyone using the mechanism to ensure they paid the correct address. In typical Bitcoin operation, there's no way to reclaim bitcoins paid to the wrong address. (Note: for this reason, the common form of Bitcoin addresses starting with a 1, 3, or bc1 all contain checksums that help wallets detect typos (but this detection is not perfect, and if Alice accidentally pays an address that is valid but the wrong address, e.g. she pays Charlie, then there's nothing the wallet can do to help her or Bob).)

Images in this answer are from the Bitcoin.org Developer Guide, MIT licensed, which goes into more detail.