Topic: Trying to spend an unconfirmed input by mistake (Read 309 times)

I think you've got this backwards. The reason for the 100 confirmation limit is so that if a deep reorganization occurs, there are no transactions which spend coinbase transactions (directly or indirectly) to become invalidated.

To answer P2PECS: If a chain reorganization occurs (which happens at a shallow depth of 1 or 2 blocks not that infrequently), then almost any transaction which was valid on one chain will also be valid on the other chain. If I spend coins on one chain, and that chain then gets replaced, my transaction is still valid and can also be relayed, mined, and confirmed on the other chain, if it hasn't already. However, whenever a chain reorganization occurs, then the coinbase transactions on one chain are replaced by the coinbase transactions on the other chain. Any transaction spending these coinbase coins or any transaction building on top of transactions which sent these coinbase coins will not be valid on the other chain. Those transactions will simply disappear, and all the recipients of those coins will be left with nothing.

The reason for the delay is to stop this from happening. It actually used to be 120 blocks, and still is in some old Bitcoin clients, although this was a local client setting as opposed to a consensus rule.

I think that the reason is more like historical, from the days then the network was not as strong as today.
In the same way, the merchants ask for much more than Bitcoin's 6 confirmations for a lot of altcoins. And when the risk of reorg is getting smaller there too, the number of required confirmations (by merchants) decreases.

On the other hand, the rule from the code doesn't harm, the miners can wait that much easily. So there's no good reason to change.
And maybe I'm overthinking it, but maybe a very small number for coinbase maturity could incentivize miners mine forked/stale blocks and scam somebody?

There isn't always a reason. The creator chose it, the users agreed with it, there's no reason to change now there's consensus. Setting a coinbase maturity to 100 is an exaggeration, but it makes sure that if a deep chain reorganization occurs, the transactions that spend the coinbase outputs are invalidated, which is needed.

It seemed useful with the value overflow incident as it reorged by 53 blocks.

And what is the reason for this? It seems to me a lot of confirmations considering that 6 it is usually considered safe for transactions with inputs and outputs. This would be for transaction without inputs or coinbase I understand, there must be a good reason.

Correct:

https://github.com/bitcoin/bitcoin/blob/7fcf53f7b4524572d1d0c9a5fdc388e87eb02416/src/consensus/consensus.h#L19

Yes, both transactions can be confirmed in the same block.


No. The miner does not need to wait for additional confirmations. Both transactions can be included in the same block and therefore each receives its first confirmation at the same time.

There is nothing special about 6 confirmations.  There is nothing in the protocol, the nodes, or the miners that care about 6 confirmations.

6 confirmations is just a guideline for users to feel comfortable that their very high-value transactions are extremely unlikely to be a part of an abandoned block from a split chain. Some wallet creators have decided to include this guideline as a limitation of the wallet, some have not.  As far as the protocol is concerned, the first confirmation is the only one that matters for the vast majority of transactions. A transaction is either unconfirmed (has no confirmations yet) or is confirmed (has received its first confirmation).

One exception to this rule is the generation transaction that gives a miner (or mining pool) their mining reward.  The protocol DOES impose a limitation on that particular transaction. I'm not 100% certain, but I think I remember it requiring 100 confirmations before it can be spent?  I'll have to go look it up when I've got a bit of time available.

The number of 5, 6 confirmations is something the merchants and various platforms require and here the discussion is a bit different.
Here, by confirmed, we say that the transaction is included into a block.
If you do CPFP then the parent and the paying child are both getting included into the same block.
That means 1 confirmation. For both.
Afterwards, with every new block added to the blockchain after the one with your transaction(s), their number of confirmations is increasing.

In this regard I was thinking, when can a miner confirm the child transaction?

It occurred to me the other day while doing a transaction and I will try to explain what I mean. Suppose I have an unconfirmed parent transaction, given that a transaction is usually considered confirmed after 6 confirmations, or maybe less if it is a low amount, if I send a child transaction with a high fee for both to be confirmed, can the same miner who confirms the parent transaction confirm the child transaction without waiting for more confirmations of the parent transaction? Or has he to wait for 5 confirmations more until he confirms the child transacion? I don't know if I make myself clear.

I didn't waste money because I set a high fee as I wanted a quick confirmation before I realized that the first transaction had not been confirmed and before I knew anything about CPFP transaction.

Although the mempool tends to empty regularly, not everyone wants to wait an indeterminate number of hours for a transaction to be confirmed, and prefers to pay a few extra satoshis, as it was my case. In fact, I just looked at the mempool just now and it is quite full. There will be many people who will pay more to avoid having to wait.

You should check to see the block containing each of your transactions. If they are both included in the same block that means it was a CPFP thing and a miner picked that up for the reward. Otherwise if they are in two different blocks, that means you just wasted money since that's normal confirmation.
Considering that fees are at the minimum most of the times, there is no need to use such methods though.

Hey,

My transaction was confirmed just after I asked here. Well, both transactions. I suppose that having used a higher fee for the so-called child transaction was key. Yes, the mempool is not that bad nowadays but the positive thing I get from this is that I learned something by a coincidence.

Cheers guys!

 

Whether or not the higher fee you paid is enough to speed up the confirmation of both parent and child transaction depends on a number of things.

What you need to do is add up the total virtual size of your transaction and the unconfirmed parent transaction (or unconfirmed parent transactions, if there is more than one), and then also add up the total absolute fee (not fee rate) of all the transactions. Once you've done that, you can divide the fee by the total virtual size to work out a combined fee rate in sats/vbyte, and see where that puts you in the mempool.

Or, the really simple way to do it is to look up your transaction on https://mempool.space/, where it will show you the "Effective fee rate" as I've just explained above. Current blocks are picking transactions down to around 7 sats/vbyte, so if your combined fee rate is higher than this then you should get confirmed soon.

There's nothing wrong with spending an unconfirmed utxo.

You can use child-pay-for-parent (CPFP) which is what you have just explained and also what BlackHatcoiner also explained. If the parent transaction (which is unconfirmed) is having many inputs and/or outputs transaction, I will advise you not to bother of using CPFP. The mempool is not that congested, the transactions (both parent and child transaction) would definitely be confirmed.

Supposing the parent unconfirmed transaction is having just few inputs like one, two or three inputs and/or just few outputs, using CPFP would be advisable, but having many inputs and/or many outputs, better wait for the transaction to be confirmed itself rather than using high fee which may not be significant to get the transaction confirmed if mempool is truly congested and the fee paid would most likely not enough to make both the parent and child transactions to be confirmed early.

A miner do not just consider a parent transaction because the child transaction pay a higher fee, the child transaction would pay a higher fee that miner will see considerable before putting both child and parent transaction into a block for confirmation. Assuming miners are accepting feerate of 5 sat/vbyte, if you have a parent transaction with 1 input and 2 outputs transaction with feerate of 1 sat/vbyte, you can use CPFP to make a child transaction of 1 input and 2 outputs with 9 sat/vbyte. The average of the 2 transactions will be 5 sat/vbyte which miners will see acceptable to include the transactions ( both parent and child transaction) into a block and be confirmed.

This is known as child-pays-for-parent. If transaction A is stuck in the mempool and can't be bumped with RBF, you can broadcast transaction B, with a higher fee, that spends A's outputs and incentivizes the miner to include both.

Wallets often have settings that let you choose whether you send confirmed inputs only or whether you can spend unconfirmed ones too.

This is also a known way to speed up an incoming transaction (by making one that incorporates that input and pays a high enough fee for both transactions).

If the person that sent funds to you paid an appropriate fee, you don't have to spend higher to get both to confirm (especially if you trust the sender).

Today I received a transaction that I was expecting, and after a couple of hours, not realizing that it had not been confirmed, I sent a transaction from that address that had no confirmed funds yet.

Has this ever happened to you? I searched and saw on reddit that a trick if you want to spend unconfirmed inputs is to set a high fee, so if the miner wants to confirm the transaction with the high fee, he will have to confirm the previous transaction as well.

When I sent the transaction I set a somewhat higher fee than usual for me, because I saw that there were more than 10,000 unconfirmed transactions and I preferred to confirm it quickly.