1

Scenario: Alice has a wallet A1bz (let's say these are the first 4 characters of the private key in wallet import format so we don't have to deal with too many characters) with wallet address 1A1 and 100 mBTC in it. She also has a wallet A2bz with wallet address 1A2 for change and wants to send 50 mBTC to Bob's wallet with public address 1B1 at 15:00 but only pays 0.01 mBTC fees (as opposed to 0.1 mBTC) which would be the recommended amount. This means that the transaction probably won't go through right away but will have to wait for a few hours.

This means that transaction1 is built like this:

transaction1: (1A1) -> (1A2(49.99 mBTC), 1B1(50 mBTC), fee(0.01 mBTC))

So transaction1 requires that there are 100 mBTC in wallet 1A1.

However, Carlos comes along and sends 1 mBTC to Alice at 15:05:

transaction2: (1C1) -> (1A1(1 mBTC), 1C2(4.9 mBTC), fee(0.1 mBTC))

transaction2 goes through right away in the block which closes at 15:10. transaction1 isn't confirmed at that point in time.

Does this mean that Carlos aborted transaction1? Afaik, the inputs need to be depleted entirely which is why change is needed in the first place.

Improve this question

1 Answer 1

Reset to default
5

No.

The addresses in Bitcoin only signify ownership. You don't need to spend all money from an address or any such thing. The atomic units of Bitcoin transactions are Unspent Transaction Outputs (UTXO).

UTXO are uniquely identified by the txid of the transaction that created them, and their position in said transation's output list.

E.g. if the transaction id of transaction1 were tx01 the 49.99mBTC output to Alice would be tx01-00 and the 50mBTC output to Bob would be tx01-01 (computer scientists start counting at 0).

To spend a UTXO, you'd reference them by this identifier, i.e. "I want to spend tx01-00". Then you need to provide a signature that corresponds to the address that tx01-00 was assigned to, and you get to reassign the balance that tx01-00 represents. Afterwards, tx01-00 is invalidated.

So, in your example transaction1 spends UTXO that are unrelated to transaction2, so transaction2 has no bearing whatsoever on transaction1.

Improve this answer
8
  • Does this mean that Alice doesn't need a change address at all if her wallet 1A1 (which holds exactly 100 mBTC) previously received 50.01 mBTC, 30 mBTC, and 19.99 mBTC and she wants to send 50 mBTC to 1B1?
    – UTF-8
    Jun 14, 2016 at 19:33
  • Correct. Addresses can be reused indefinitely. They are not chiefly due to privacy reasons.
    – Murch ♦
    Jun 14, 2016 at 19:35
  • 1
    I know that they can be reused. But I read somewhere that you always have to spend everything an input has. What exactly is an "input"? Is it the unpent transaction output or is it an address? Let's say Alice wants to spend 99.99 mBTC and has the same history for address 1A1 as mentioned above (she received money 3 times). She does not include any other address in the transaction, so all 99.99 mBTC come from 1A1. Is the number of inputs 1 or 3?
    – UTF-8
    Jun 14, 2016 at 19:42
  • 1
    Addresses are only a marker for ownership. They only symbolize the private-key that needs to be invoked to sign validly. Transactions consume UTXO as inputs. Those you have to spend completely. Anything you don't assign falls to the miners as transaction fee. So, in the above example, the 100mBTC would presumably be one UTXO, and if the rest were not assigned, it would all be a transaction fee. Fees are not outputs, just unassigned left-overs of the inputs.
    – Murch ♦
    Jun 14, 2016 at 19:50
  • It made perfect sense until you wrote "So, in the above example, the 100mBTC would presumably be one UTXO". Shouldn't the 50.01 mBTC chunk be 1 UTXO, the 30 mBTC chunk be another one, and the 19.99 mBTC be a third one?
    – UTF-8
    Jun 14, 2016 at 19:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.