2

To be more precise, consider the following situation:

  1. Address A gets an input of 4 BTC.
  2. You try to make a transaction from A to B with 1 BTC and a very low fee, which means its unconfirmed for a long while. The transaction's output are B and A (to account for the change of ~3 BTC after fees)
  3. Before waiting for the previous transaction to be confirmed, you send again from A to B, this time you send 2 BTC with a higher fee, hoping it'll be confirmed fast.

My question is, since the output of the first transaction is the same address A, will it need to be confirmed first for the second transaction to follow through, because the input of the second transaction is A?

In this example I used amounts to make sure there's "enough" bitcoin for each transaction separately (since if you have 1 BTC and you try to send it twice intuitively see why it shouldn't work).

Assume no extra addresses are generated automatically by the wallet to handle it. I'm talking about this specific re-use of addresses scenario.

Improve this question

1 Answer 1

Reset to default
2

Yes, if the second transaction spends the output of the first one, then #2 cannot be confirmed until after #1 is confirmed. (Though they can be confirmed in a single block, as long as #1 appears before #2 in that block, in which case the confirmations are effectively simultaneous.)

Most miners will consider transactions on a "child pays for parent" basis, so that a low fee for #1 could be compensated by a high fee in #2. The two transactions would be considered as a single "lump" with their combined fee, and a miner would confirm them if the combined lump pays a higher fee than the next most lucrative transaction (or lump) that could fill that space.

Improve this answer
7
  • 1
    Two followup clarifications: (1) Does that mean you can effectively lock your use of a wallet, since you had just one silly transaction with low fees, and all your bitcoins arrived using a single input into a single address? (2) Why would it matter, if in my example the 2 transactions are floating in the mempool, and you can confirm either one of them first without even knowing about the former. Do miners check every transaction they confirm against every other transaction in the pool as well?
    – Ahia Cohen
    Commented Dec 8, 2017 at 6:38
  • 1
    @AhiaCohen (1) It's not permanently "locked". Even if #1 is never confirmed, you may still create a different transaction #1a which spends your original 4 BTC input, sending it either to address B or anywhere else you want. This is a double-spend, and other nodes on the network may not like you very much if you send it while they still have #1 in their mempool (Bitcoin Core will disconnect from you and ban your IP for a while, I think), but it's not forbidden by the protocol, and #1a could eventually get confirmed in place of #1.
    – Nate Eldredge
    Commented Dec 8, 2017 at 7:04
  • 1
    @AhiaCohen: (2) You cannot confirm #2 before (or without) #1, that is what I am saying. It's a protocol rule that a transaction in a block may only reference inputs which already exist as outputs of previous transactions. Any block that contains #2, if #1 is not already in a previous block in the chain (or earlier in the same block), is an invalid block and will be rejected by the network. Miners do and must check this.
    – Nate Eldredge
    Commented Dec 8, 2017 at 7:06
  • 1
    @AhiaCohen: I see. Yes, that is the situation I described in my response to (1); in that case, your #2 is what I called #1a. It has all the usual issues of a double spend. Wallet software will normally not do this by default; they will prefer to spend the "change" output from #1, since they assume that you actually want #1 to confirm if possible.
    – Nate Eldredge
    Commented Dec 8, 2017 at 14:47
  • 1
    @AhiaCohen: Yes it can, and wallets often do this. This is based on the common case that #1 will confirm pretty soon, and the user may not want to wait before creating more transactions. If fees are sufficient and block space is not in short supply (which was the case when most current wallet software was designed) then it is nice to be able to queue up multiple transactions, and they could all get confirmed together in the very next block.
    – Nate Eldredge
    Commented Dec 8, 2017 at 17:55

Your Answer

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

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