bitcoind "sendtoaddress" spending unconfirmed outputs

[oblongmeteor]

The Bitcoind daemon is spending unconfirmed outputs as inputs in new transactions. This is leading to dependency chains that could be susceptible to double spends.

Some examples of this behavior:

This transaction https://blockchain.info/tx/35c4e8c86075cf3f5335e029abd2d981af011c142b56e04c0a6d8b0d588d32ae which included a fee spent the unconfirmed output transaction https://blockchain.info/tx/99e6c22980571d1733986d950f564854393777ba0905d08aae36d7f4f64e4a3a which included no fee.

Note that in both cases, the only command executed against the Bitcoin Daemon (0.8.5) was "sendtoaddress". Also note that https://blockchain.info/tx/35c4e8c86075cf3f5335e029abd2d981af011c142b56e04c0a6d8b0d588d32ae had to have its raw tx manually pushed using blockchain.info/pushtx functionality in order to appear. This is what led to the discovery that unconfirmed outputs were being spent.

This issue appears to have become noticeable because of the increased user traffic on the Bitcoin network leading to more transactions with no fees. As a consequence, miners are cherry picking transactions with fees leading to backlogs and dependency chains becoming evident. There are numerous issues in the bitcointalk.org [Technical Support] sub-board as well as topics such as: https://bitcointalk.org/index.php?topic=339792.0 on the problem.

[oblongmeteor]

Please see this thread: https://bitcointalk.org/index.php?topic=339802.20 and specifically this message https://bitcointalk.org/index.php?topic=339802.msg3654039#msg3654039 for another example.

[gmaxwell]

The software only spends its own unconfirmed outputs and only as a last resort. There is nothing improper about spending unconfirmed coins, though the wallet software won't do so when they come from an untrusted source.
What exactly is the behavior that you want?

[oblongmeteor]

I believe the behavior should default to only spending confirmed outputs. As suggested by DeathAndTaxes here: https://bitcointalk.org/index.php?topic=339802.msg3653378#msg3653378 - a minconf optional parameter with either a default value of 0 - to retain the existing behavior as default - or 1 to ensure that no unconfirmed outputs are ever used to create transactions when the "sendtoaddress" method is invoked, regardless of whether the transaction chain is being generated incestuously by outputs within your wallet.

You may also wish to consider some of the additional recommendations proposed such as setting a min fee for all transactions as the default.

[gmaxwell]

In cases where it spent its own change it would have been unable to spend at all. This is not a desirable outcome.

Why do you believe the behavior should be to only spend confirmed outputs? The current behavior is that it only spends funds from third parties that is confirmed, but its own outputs (with no unconfirmed third party contributions) can be spent whenever.

[oblongmeteor]

Because in the situation illustrated in the thread (see: https://bitcointalk.org/index.php?topic=339802.20) - where an ancestor transaction does not include a fee but is used as an input to a child, regardless of whether that child includes a fee it will not be confirmed until the ancestor is. In effect, your transaction chain is bottle necked by any preceding transaction used as an input that is not favored for inclusion in a block.

In the two examples cited in the above thread, downstream transactions included a fee but were not confirmed in a timely manner because they filed a dependency on an 0 fee ancestor that was ignored by miners until its priority mandated its inclusion. By providing a minconf parameter, you avoid the situation where unconfirmed outputs are spent, and therefore ensure that the addition of a fee is actually meaningful in the context of the current transaction.

[gmaxwell]

Some miners probably about 15-20% of the hashrate consider all dependencies as a group, so your argument of the fee being irrelevant doesn't hold compeltely.

You're still not answering my core question, which is why do you think refusing to make a transaction at all would be an improvement?

[oblongmeteor]

Perhaps I'm misunderstanding your question. I have said the BitcoinD software "sendtoaddress" method should either default too or provide the ability to spend only from confirmed outputs.

The core reason - as I've indicated in my previous response - is because downstream child transactions that are created and rely on the unconfirmed output of an ancestor that does not include a fee are delayed until that ancestor is included in a block.

Edit: In addition, since the default behavior of the client is *not to include a fee unless the size of the transaction exceeds 1KB, a single transaction sent without a fee can cause significant downstream delays to any dependents especially during periods of increased traffic.

[gmaxwell]

"can cause significant downstream delays to any dependents"

It only uses the unconfirmed inputs as a last resort. Meaning that the software would refuse to make a transaction until some of its unconfirmed change confirmed. It only attempts to use its own unconfirmed change if it was unable to construct a transaction that didn't do so.

Some miners already consider the transactions as a group, fees on the subsequent transactions will pay for their parents. I'd rather see that expanded than change the behavior with change.

(There are reasons unrelated to this why spending unconfirmed anything isn't great— the transaction malleability problem, but thats a separate issue)

[oblongmeteor]

Perhaps then it may be prudent to skip "minconf" as a parameter on "sendtoaddress" and default the behavior to always only using confirmed inputs and refusing to complete a transaction if insufficient confirmed outputs exist.

Those who wish more granular control can use the preexisting raw transaction functionality (https://en.bitcoin.it/wiki/Raw_Transactions).

[gmaxwell]

I don't see why you believe users would find it acceptable to potentially be only able to issue a single transaction at a time until their prior transaction confirms, or if you don't realize that is an outcome from what you're proposing.

[gavinandresen]

Closing; this works as intended.

The intended behavior is:

1. Use confirmed outputs, unless there are not enough, in which case:
2. Use unconfirmed outputs that we created ourself, on the assumption that we will not double-spend ourselves and that those transactions we created ourself will confirm reasonably quickly.

Right now, the "will confirm reasonably quickly" is a bad assumption, but that is a separate issue that is being fixed with my "smartfee" work.