Skip to main content
added 82 characters in body
Source Link
Murch
  • 77.9k
  • 35
  • 190
  • 641

It's a bit easier if you think of each output as being locked to a set of conditions that need to be fulfilled for spending. In single-sig the spending condition is "pay-to-(witness-)public-key-hash". TheThis lock is satisfied by a signature of the private key corresponding to the public key that is representedspecified address. (The address in turn is derived from the hash form inof a public key which forms an addressasymmetric key pair with said private key.) In multisig the spending condition is "pay-to-(witness-)script-hash". The funds are locked to the fullfilment of a specific script. The address in this case is derived from the hash of the script. Spending such a UTXO requires 1) revealing the script that hashed to the address, 2) fulfilling the conditions specified in the script. In the case where that script is a multisig construction, it would specify a set of public keys some subset of which is sufficient to unlock the funds. However, these scripts can take various other forms as well. I'd nit that "each TxOut references one or multiple bitcoin addresses that can spend the amount" is both an overgeneralization (because not all scripts must be multisig) and an inaccuracy (because the funds are locked to the script, not to multiple addresses).

There is no way to partially spend a UTXOThere is no way to partially spend a UTXO. Spending UTXO is binary, either they are unspent or they are spent. Since UTXO can only be spent in full, any remainder from a payment gets collected into one or multiple outputs in which the sender pays themselves (see e.g. How does change work in a bitcoin transaction?).

It's a bit easier if you think of each output as being locked to a set of conditions that need to be fulfilled for spending. In single-sig the spending condition is "pay-to-(witness-)public-key-hash". The lock is satisfied by a signature of the private key corresponding to the public key that is represented in hash form in an address. In multisig the spending condition is "pay-to-(witness-)script-hash". The funds are locked to the fullfilment of a specific script. The address in this case is derived from the hash of the script. Spending such a UTXO requires 1) revealing the script that hashed to the address, 2) fulfilling the conditions specified in the script. In the case where that script is a multisig construction, it would specify a set of public keys some subset of which is sufficient to unlock the funds. However, these scripts can take various other forms as well. I'd nit that "each TxOut references one or multiple bitcoin addresses that can spend the amount" is both an overgeneralization (because not all scripts must be multisig) and an inaccuracy (because the funds are locked to the script, not to multiple addresses).

There is no way to partially spend a UTXO. Spending UTXO is binary, either they are unspent or they are spent. Since UTXO can only be spent in full, any remainder from a payment gets collected into one or multiple outputs in which the sender pays themselves (see e.g. How does change work in a bitcoin transaction?).

It's a bit easier if you think of each output as being locked to a set of conditions that need to be fulfilled for spending. In single-sig the spending condition is "pay-to-(witness-)public-key-hash". This lock is satisfied by a signature of the private key corresponding to the specified address. (The address in turn is derived from the hash of a public key which forms an asymmetric key pair with said private key.) In multisig the spending condition is "pay-to-(witness-)script-hash". The funds are locked to the fullfilment of a specific script. The address in this case is derived from the hash of the script. Spending such a UTXO requires 1) revealing the script that hashed to the address, 2) fulfilling the conditions specified in the script. In the case where that script is a multisig construction, it would specify a set of public keys some subset of which is sufficient to unlock the funds. However, these scripts can take various other forms as well. I'd nit that "each TxOut references one or multiple bitcoin addresses that can spend the amount" is both an overgeneralization (because not all scripts must be multisig) and an inaccuracy (because the funds are locked to the script, not to multiple addresses).

There is no way to partially spend a UTXO. Spending UTXO is binary, either they are unspent or they are spent. Since UTXO can only be spent in full, any remainder from a payment gets collected into one or multiple outputs in which the sender pays themselves (see e.g. How does change work in a bitcoin transaction?).

Source Link
Murch
  • 77.9k
  • 35
  • 190
  • 641

  1. a transaction (Tx) can have multiple inputs (which are previous unspent transactions = UTXOs), let's call them the TxIn

More accurate would be to say "unspent outputs from previous transactions".

  1. a Tx can have multiple outputs (which thus become UTXOs before they will themselves become spent by being used as TxIn), let's call them the TxOut
  2. the TxOut have a specific order N in the transaction: TxOut[0], TxOut[1], etc.
  3. each TxIn references the number N which corresponds to the index of the TxOut referred to in point 3 above, so this makes the link between a specific TxIn and a specific TxOut

Correct, we call the compound of transaction id and output index txid:vout the "outpoint" of a UTXO. As you describe, each input spends exactly one specific UTXO.

  1. each TxOut specifies a specific bitcoin amount (which represents the UTXO amount that can be later spent)
  2. each TxOut references one or multiple (in the case of MultiSig) bitcoin addresses (public keys) that can spend the amount

It's a bit easier if you think of each output as being locked to a set of conditions that need to be fulfilled for spending. In single-sig the spending condition is "pay-to-(witness-)public-key-hash". The lock is satisfied by a signature of the private key corresponding to the public key that is represented in hash form in an address. In multisig the spending condition is "pay-to-(witness-)script-hash". The funds are locked to the fullfilment of a specific script. The address in this case is derived from the hash of the script. Spending such a UTXO requires 1) revealing the script that hashed to the address, 2) fulfilling the conditions specified in the script. In the case where that script is a multisig construction, it would specify a set of public keys some subset of which is sufficient to unlock the funds. However, these scripts can take various other forms as well. I'd nit that "each TxOut references one or multiple bitcoin addresses that can spend the amount" is both an overgeneralization (because not all scripts must be multisig) and an inaccuracy (because the funds are locked to the script, not to multiple addresses).

  1. however, and this is what I don't understand, the TxIn does NOT specify the amount of bitcoins that are used

If the TxIn does not specify the amount that is used, how do we determine the spent amount for each TxIn, and thus the UTXO of the part of the TxIn that remains unspent?

There is no way to partially spend a UTXO. Spending UTXO is binary, either they are unspent or they are spent. Since UTXO can only be spent in full, any remainder from a payment gets collected into one or multiple outputs in which the sender pays themselves (see e.g. How does change work in a bitcoin transaction?).

Example, a transaction with 2 inputs and one output (assuming no fees):

  • TxIn[0] whose UTXO before spending is 1 BTC
  • TxIn[1] whose UTXO before spending is 1 BTC
  • TxOut[0] whose value is 1.5 BTC

How do we know which TxIn, and how much of which, was spent?

  • was it TxIn[0] for 0.75 and TxIn[1] for 0.75?
  • was it TxIn[0] for 0.5 and TxIn[1] for 1?

What am I missing? Because given the above, it is not possible to determine the spent proportion of each input.

The answer is that both TxIn[0] and TxIn[1] get spent completely and the transaction is created with two outputs: TxOut[0]: 1.5 BTC to recipient and TxOut[1]: 0.5 BTC to sender.