high-level Bitcoin transaction understanding

[nickp3]

Hi all,

I recently got into the Bitcoin development scene and am trying very hard to understand transactions as a start. I've been using the Bitcoin wiki, as well as the following guide to familiarize myself: https://bitcoin.org/en/developer-guide#transactions

I was wondering if anybody could help me go through my logic (below), and point out any misunderstandings I may have. Any help is appreciated!

For the sake of understanding, let's assume the sender is Alice, and the receiver is Bob.

1) The receiver (Bob) must generate a private key, and therefore public key, and therefore a Bitcoin address (which is the pubkeyhash?). He sends it to Alice (the sender).

2) Alice must sign her UTXOs (unspent outputs) with her private key (using ECDSA to sign?) and append her signature (from what I understand, the signature is made from P2SH or P2PKH scripts, but what does "append" mean?).

3) She also appends Bob's address to her outputs given to him (again, what does "append" mean technically?).

4) She broadcasts this to the Bitcoin network and once a miner verifies that it was indeed her UTXO to use, the transaction itself is verified.

5) Bob now has his UXTO to spend. This is where I get confused. How does Bob prove that it is his UTXO now? Since it was Alice who signed it, how does he prove it?

I apologize if this may seem trivial to some of you, but to me, a newcomer, this is all very confusing. I would appreciate any help that you guys can spare. Thanks in advanced!

[1714615656]

1714615656

[1714615656]

1714615656

[azeteki]

This is complicated by the fact that p2pkh, p2pk, p2sh transactions are only a subset of all valid transactions.
You can go into a lot of depth here, really.

5) Bob now has his UXTO to spend. This is where I get confused. How does Bob prove that it is his UTXO now? Since it was Alice who signed it, how does he prove it?

The transaction inputs are 'solved' and signed by Alice. In the case of boring transactions, solving generally means proving you have a key and signing with it.

The outputs are also signed by Alice; so they cannot be modified without her private key.

The outputs contain conditions for their spending; 'if you can solve this script, it's yours'.
In the case of a pay-to-pubkey tx, the solution is 'roughly' to sign the input with the private key corresponding to that pubkey.
Pay-to-pubkey-hash; sign the input with a private key, that corresponds to a pubkey, that hashes to the hash given.

Bob 'proves that it is his UTXO' because he can sign with the pubkey that Alice decided would be the condition for spending. (Prior to the spend event, no-one really 'owns' the output. In fact, 'ownership' is possibly a flawed analogy in general, here; you can produce a UTXO that's unspendable).

Technical description:
Outputs contain a scriptPubKey field.
Inputs contain a scriptSig field, and a reference to a previous output.
The condition for validity of an input is that exec(scriptSig+scriptPubKey) == True.

[nickp3]

Thank you for replying azeteki,

From what I understand of what you said, basically because Alice (sender) appended Bob's (receiver) address (and therefore public key) to the outputs. If he can then, sign the outputs (now considered inputs for his next transaction) with his public key, then he will be able to spend it? I was under the assumption that you can only sign with your private key?

The inputs (relative to Bob's spending transaction with someone else) are solved by Alice (as outputs of their exchange)?

Lastly, in your opinion, if I am just trying implement a function to create a transaction, would p2pkh be the simplest way of creating a valid transaction? Thanks again! I truly appreciate any help!

[azeteki]

From what I understand of what you said, basically because Alice (sender) appended Bob's (receiver) address (and therefore public key) to the outputs. If he can then, sign the outputs (now considered inputs for his next transaction) with his public key, then he will be able to spend it? I was under the assumption that you can only sign with your private key?

Consider an output as a 'puzzle to be solved'.

Alice creates her transaction and ensures that the output is a puzzle only solvable by Bob.

Here is a pseudo example of a sufficient puzzle;

A signature must be provided. This signature must be verifiable by public key Y.

The only way to (feasibly) produce said signature, would be to be in possession of the private key X which corresponds to public key Y.

Alice knows Bob's public key. Or else, she knows a hash of his public key (a 1... address).

But she doesn't know his private key.

The puzzle is implemented in practice using Script opcodes.

Standard Transaction to Bitcoin address (pay-to-pubkey-hash)

scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

Note that these are spread across two transactions.

scriptPubKey is part of an output, in tx 1.
scriptSig is part of an input, in tx 2. The input references the corresponding output, in tx 1.

That is to say; Alice produces scriptPubKey. Bob produces scriptSig.

Alice knows <pubKeyHash>. It's simply a decoded Bitcoin address. So she can make scriptPubKey.
What she and no-one else but Bob can do, is provide the scriptSig. Bob is the only one that can produce a valid <sig>.

Bob is the only one who can spend the output. This is equivalent to saying that he's the only one with the ability to produce the corresponding valid input.

[azeteki]

Note that the scriptSig signature does not sign only the inputs.
To my knowledge the entire transaction is signed (with the exception of other signatures because this would be recursive).

The outputs must included within the signature too (with the correct key as described in the input) because otherwise an attacker could re-use Bob's input signature and change the outputs.

[nickp3]

So in tx2, Bob is creating a signature (scriptSig), which is based off of his private key. The scriptSig can be used to sign inputs, as well as the entire transaction (as in the whole transaction block? Or other elements of that block?).

Alice has already created scriptPubKey from tx1, containing Bob's public key (or it's pubkeyhash).

In tx2, Bob's scriptSig must produce a value verifiable by pubkeyHash (of tx1). On a lower level, is his signature is being compared to his public key from pubkeyhash?

Also, when you stated: "The outputs must included within the signature too (with the correct key as described in the input) because otherwise an attacker could re-use Bob's input signature and change the outputs."
Outputs (I'm assuming are large numbers, similar to addresses), are embedded into the scriptSig as well? But I'm guessing there is a signature part of scriptSig that signs the transaction?

So generally, outputs to Bob contain a scriptPubKey from the sender (Alice). To be used as inputs and used, the receiver (Bob) must have produce the scriptSig that satisfies the scriptPubKey. So in the context of him spending to a third man, he would have to attach a new scriptPubKey to that input (to become an output in tx2)? And the third man would have to produce sigScript3rd to be able to spend it?


Thanks for all your help once again. I apologize if this may seem a bit slow.

[azeteki]

Here is what a transaction looks like, interpreted from https://bitcoin.it/wiki/Transactions.

Stripping out metadata that isn't really relevant:

input 0
input 1
input 2
...
input n

output 0
output 1
output 2
...
output n

That's it. The other bits are listed on the wiki but they're not really relevant here.
Hashed, the entire tx has a 'txid'. And each output is numbered.

An input generally looks a bit like this:

prev_txid:vout scriptSig

where prev_txid = the previous transaction, vout = the previous output, and scriptSig = the solution to scriptPubKey of that previous output.

An output generally looks a bit like this:
value scriptPubKey

where value = the amount to be transferred, and scriptPubKey = the 'puzzle' to be solved by an input that may later wish to redeem it.

'In the context of Bob spending to a third man': he creates a whole new transaction and this formulation starts all over again. His inputs are the previous transaction's outputs, his outputs are whatever he wants (e.g. spending to a third man).

I suggest you read the wiki page on transactions; otherwise it seems you're trying to reinvent the wheel

scriptSig is not an ECDSA signature. It's a solution to the scriptPubKey puzzle; a signature in the general sense.
A script does not have to require ECDSA signatures at all; but in the majority of cases they are used, to prevent others from modifying a transaction before its' inclusion into a block.
Bitcoin script is really rather powerful. I advise reading the above linked page and limiting yourself to specific cases at first, rather than trying to understand the whole model.

[amaclin]

5) Bob now has his UXTO to spend. This is where I get confused. How does Bob prove that it is his UTXO now? Since it was Alice who signed it, how does he prove it?

Bob also verifies all transactions. If he is online - he will receive Alice's transaction twice - first time in "wild" state, and second included in block. Bob knows his address and filters all transactions looking for funds sent to him. This is "client syncing"

So, Bob is sure that Alice sent him funds. And everybody on the network who knows Bobs address also can check it.

But the real proof will be when Bob will send these bitcoins to Charlie

[nickp3]

azeteki, thanks for simplifying it for me. I appreciate your consistently detailed replies 
I was kind of lost when I initially tried to read that page. So basically, the scriptPubKey was provided by Alice as an output from tx1, and Bob, wanting to spend it, must provide his scriptSig as a input in tx2 (to the third man - Charlie).

amaclin, thanks for chiming in and helping. So from what I understand, you are saying that Bob sees Alice's transaction to him initially, but sees it again when it becomes "official" when included in the block (the transaction block in the block chain I assume?). Bob's real proof comes when he's trying to send it to Charlie - through means of providing his scriptSig to the input (corresponding to output of his transaction with Alice)?

Thanks again to the both of you.

[rapport]

Bob's real proof comes when he's trying to send it to Charlie - through means of providing his scriptSig to the input (corresponding to output of his transaction with Alice)?

Yes, you got it.
As azeteki wrote: Bob 'proves that it is his UTXO' because he can sign with the pubkey that Alice decided would be the condition for spending. (Prior to the spend event, no-one really 'owns' the output. In fact, 'ownership' is possibly a flawed analogy in general, here; you can produce a UTXO that's unspendable).

[nickp3]

Thank-you all for our contributions! Over the last few days of studying, I [think that I] understand all of the basics of transactions now! I truly appreciate it.

I'm not starting to familiarize myself with the scripting process. I understand that the scriptPubKey sets conditions to be solved by the scriptSig. I also understand that there are different ways to do it. Here is the standard one I found on the wiki: https://en.bitcoin.it/wiki/Script#Standard_Generation_Transaction_.28pay-to-pubkey.29

The one before it, P2PKH seems much more complicated. https://en.bitcoin.it/wiki/Script#Standard_Transaction_to_Bitcoin_address_.28pay-to-pubkey-hash.29

My question is, is there an advantage that P2PKH offers over Standard in terms of security? If I were trying to implement my own transaction, which one should I follow? Thanks in advanced for any help!

[rapport]

Thank-you all for our contributions! Over the last few days of studying, I [think that I] understand all of the basics of transactions now! I truly appreciate it.

I'm not starting to familiarize myself with the scripting process. I understand that the scriptPubKey sets conditions to be solved by the scriptSig. I also understand that there are different ways to do it. Here is the standard one I found on the wiki: https://en.bitcoin.it/wiki/Script#Standard_Generation_Transaction_.28pay-to-pubkey.29

The one before it, P2PKH seems much more complicated. https://en.bitcoin.it/wiki/Script#Standard_Transaction_to_Bitcoin_address_.28pay-to-pubkey-hash.29

My question is, is there an advantage that P2PKH offers over Standard in terms of security? If I were trying to implement my own transaction, which one should I follow? Thanks in advanced for any help!

You'll actually find that P2PKH is much more common than P2PK.
You should use P2PKH over P2PK.  P2PKH hides the public key until you spend.  It is more secure than P2PK: in the future, if there's a way to compute a privkey from pubkey, using a pubkeyhash will add an extra step, since hacking will require going from pubkeyhash->pubkey->privkey.  (Others may have written/explained better)

[medicine]

Thanks for this description.   I am very happy to find this developers guide linked in this thread.  Now time to finish studying it!