Spending unconfirmed output from a change address

Question

Consider a custom program which will occasionally need to send out bitcoin to users to whom I owe money.

Let's say I have 100 unspent BTC at address ADDR_A.

UserX demands payment of 1 BTC to ADDR_X. I honor the request, spending my 100 BTC from ADDR_A, directing 1 BTC to ADDR_X and 99 to ADDR_CHANGE_A. (Let's ignore the impact of transaction fees in this contrived example.) The raw transaction is submitted via a public Bitcoin API like Insight.

Five seconds later UserY demands payment of 1 BTC to ADDR_Y. I want to use ADDR_CHANGE_A as an input to facilitate the transaction.

Question: Can I use my newly created ADDR_CHANGE_A address as an input given that the original change output that targeted ADDR_CHANGE_A has not yet confirmed? Other material on this site indicates that the transaction should work but I'd like to understand WHY it works. Assuming that the public Bitcoin API receives my transaction that uses ADDR_CHANGE_A as an input, but has no knowledge that ADDR_CHANGE_A was used as an output in a prior transaction which took place only seconds earlier, wouldn't it balk at my attempt to spend from ADDR_CHANGE_A?

Answer 1

You are technically able to do this but it is strongly not recommended. A transaction can spend the output of another transaction so long as the parent transaction is known by the node in question, however this is quite fragile.

Bitcoin transactions back reference by TXID, a cryptographic hash of the previous one being spent. Due to a property known as transaction malleability it is currently possible for this TXID to change spontaneously when it it broadcast through the network, due to some nodes running custom code which mutates transactions in specific ways. If you build a long chain of unconfirmed transactions and one early on is mutated, all subsequent transactions can suddenly appear to spend outputs which don't exist anymore and are effectively invalidated. It's difficult to produce safe software which can handle this situation with this as there's a lot of edge cases that need dealing with.

If you need to make a number of payments to many parties in a short period, many large providers will split their outputs up ahead of time to avoid ever needing to spend unconfirmed change. When they receive a 100 BTC output they might break it into four 25 BTC chunks paying themselves, which will allow them to pay four people when required without needing to ever attempt to spend unconfirmed change. Some delicate balancing is required here, if you have too many outputs in your wallet the fees increase dramatically and the software will become slow.