How are spend and change addresses derived?

[pomme7000]

Hi all. I am preparing a general talk on bitcoin and would like some help on a basic question.

Suppose I have 10 bitcoin and I want to send 1 bitcoin to you. My understanding is that this transaction would create three entries in the blockchain as follows:

Entry 1: Spends my 10 bitcoin. I will call this my "spend" address.
Entry 2: Sends 1 bitcoin to your recipient address.
Entry 3: Returns 9 bitcoin to me. I will call this my "change" address.

I assume that both my spend address and my change address are simply public keys that are derived from my private key. Is this correct?

[ranochigo]

On the more abstract level, addresses actually don't exist. The blockchain consists of unspent outputs and transactions are simply destroying the unspent outputs and creating new ones.

Spend and change addresses are likewise terms that are created and they're terms used to distinguish the different addresses and their purpose within the transaction. One entry is created in the blockchain for the transaction that you've stated, not three. In that transaction, one unspent output is also removed while two new ones are created.

The two addresses that you've used have their own private, and the public keys respectively. Address is not considered a public key, it is the hash of a public key.

[Charles-Tim]

I assume that both my spend address and my change address are simply public keys that are derived from my private key. Is this correct?

No. That was P2PK. When bitcoin can be sent to public key. Bitcoin address has not been created that time. But starting from P2PKH, the hash of the public key was derived and called the address. Also other addresses derivation path was derived which save more fees while making transaction if compared to P2PKH.

[pomme7000]

Thank you for responding. That is helpful.

I didn't realize that the two addresses I mentioned each have their own private key (I thought they both were generated from a single private key). So in the case of a cold wallet (eg, Ledger, Trezor), I guess it's the wallet software that is generating all the necessary private and public keys, and then keeping track of all these keys.

Thanks again!

[ranochigo]

No. That was P2PK. When bitcoin can be sent to public key. Bitcoin address has not been created that time. But starting from P2PKH, the hash of the public key was derived and called the address. Also other addresses derivation path was derived which save more fees while making transaction if compared to P2PKH.

Slight correction, P2PKH existed since the earliest version of Bitcoin-qt. It was used for peer to peer transactions rather than Bitcoins mined directly to the wallet. The derivation path is not the correct term used for the address formats, they have vastly different encoding.

I didn't realize that the two addresses I mentioned each have their own private key (I thought they both were generated from a single private key). So in the case of a cold wallet (eg, Ledger, Trezor), I guess it's the wallet software that is generating all the necessary private and public keys, and then keeping track of all these keys.

Addresses that are generated from the seed will have one single private key. However, hierarchical deterministic wallets, or HD wallets for short hae a master private key (and master public key). They're able to derive the individual private-public keypair and consequently each unique addresses accordingly.

[pomme7000]

Addresses that are generated from the seed will have one single private key. However, hierarchical deterministic wallets, or HD wallets for short hae a master private key (and master public key). They're able to derivate the individual private-public keypair and consequently each unique addresses accordingly.

Clear. Thank you.

[nc50lc]

So in the case of a cold wallet (eg, Ledger, Trezor), I guess it's the wallet software that is generating all the necessary private and public keys, and then keeping track of all these keys.

In those examples wallets and others that use the same standards (BIP44, 49, 84, 86);
The addresses are derived with the standard "m/purpose'/coin'/account'/chain_index/address_index" derivation path from your "master private key" (m)
In which the specific private keys of each of your change addresses are derived with "internal chain" (1) chain_index; receiving addresses with "external chain" (0).

e.g. (Native SegWit, Bitcoin, first account index):

• 1st change address:     m/84'/0'/0'/1/0
• 2nd change address:    m/84'/0'/0'/1/1
• 3rd change address:     m/84'/0'/0'/1/2
• 1st receiving address:  m/84'/0'/0'/0/0
• 2nd receiving address: m/84'/0'/0'/0/1

Since those "cold wallets" are following the standard, it will use those derivation paths when restoring the wallet or when looking for the correct private key.

[ABCbits]

Suppose I have 10 bitcoin and I want to send 1 bitcoin to you. My understanding is that this transaction would create three entries in the blockchain as follows:

Entry 1: Spends my 10 bitcoin. I will call this my "spend" address.
Entry 2: Sends 1 bitcoin to your recipient address.
Entry 3: Returns 9 bitcoin to me. I will call this my "change" address.

Don't forget to mention transaction/TX fee on your talk. Some people consider TX fee on Bitcoin isn't cheap.

[NotATether]

Those three "entries" are contained in the same transaction and each entry is either an input (if they are being spent) or an output (if they are being created anew).

The blockchain transactions don't directly work with addresses, they work with scripts which are formed by adding a few bytes depending on if it's a legacy or segwit address, followed by the address hash - which you can get by decoding the base58 or bech32 - and possibly some other bytes.

[Cricktor]

Don't forget to mention transaction/TX fee on your talk. Some people consider TX fee on Bitcoin isn't cheap.

Indeed, we've seen periods with absurdly high required transaction fee to get a transaction mined/confirmed within a reasonable time. Fortunately it's quite relaxed now again (if you disregard sudden spikes like happened on August 22^nd), though I believe we won't see transaction fees below 2 sat/vB as long as this Ordinal, Runes or other spam bullshit exist.

Transaction fee is the difference of the sum of transaction inputs minus the sum of transaction outputs. The extreme cases are:

• both sums are equal, meaning the transaction fee is then zero. Standard nodes won't relay such transactions as currently the minimum standard transaction fee is 1 sat/vB (a mining pool can mine transactions with zero transaction fee; that's not against the protocol).
  
• the sum of outputs is zero, e.g. a single OP_RETURN with 0sat which translates to the transaction fee being the same as the sum of inputs (the miner won't mind such a present if the sum of inputs is reasonably high and not just a few hundred sats).

It's important to fully understand the UTXO (unspent transaction output) transaction model of Bitcoin to avoid costly mistakes. E.g. if you want to partially spend an UTXO of a paperwallet (let's assume there's only one UTXO that has been sent to the paperwallet's public address), you have to send the change which you don't want to spend back to the paperwallet's address (which would be address re-use; not immediately harmful) or to an address of another paperwallet address or other wallet address.

The costly mistake would be as follows: the paperwallet "holds" 1BTC; you want to spend half of it to some destination address; you create a transaction which spends the 1BTC and sends only one transaction output of amount 0.5BTC to the destination address; nothing more. The result is a transaction fee of 0.5BTC which no miner would mind collecting, while you'll need a bucket to collect your tears.


If you need to lookup Bitcoin basics or need to dig deeper, I highly recommend the website https://learnmeabitcoin.com!