Cost and Confirmation time of Bitcoin Transactions

[oblongmeteor]

How? The stock Bitcoin Daemon certainly doesn't discriminate between confirmed and unconfirmed. It just seems to pick appropriately valued outputs to use as inputs - regardless if they are confirmed or not. Literally; "bitcoind sendtoaddress {ADDRESS} {VALUE}". There is no choice.

If you are the receiver of a transaction, you only accept it as valid if it has 7 transactions. Mind, this is only for high value transactions. It is unlikely that someone tries to double spend small amounts, so merchants often accept transactions that were just broadcast to the network and have not even been included in a block.

I think you are misunderstanding my question. How, exactly, do you do this? If I run a bitcoin Daemon with 5 Bitcoins in and you send me 1 Bitcoin with no fee and it's stuck unconfirmed, I then fire off a "sendtoaddress" command from my wallet to send 3 Bitcoin to another person and the bitcoind chooses to use your unconfirmed input, my new transaction is now dependent on your preceding transaction being confirmed. There is no "sendfromconfirmedinputsonly" command - it's an algorithmic lottery which inputs the daemon will use to satisfy the outbound transaction. If your transaction is used, it doesn't matter if I include a 1 BTC fee ... I'm still stuck waiting for your transaction to confirm before my new one will.

[1714666848]

1714666848

[1714666848]

1714666848

[1714666848]

1714666848

[1714666848]

1714666848

[Barek]

I think you are misunderstanding my question. How, exactly, do you do this? If I run a bitcoin Daemon with 5 Bitcoins in and you send me 1 Bitcoin with no fee and it's stuck unconfirmed, I then fire off a "sendtoaddress" command from my wallet to send 3 Bitcoin to another person and the bitcoind chooses to use your unconfirmed input, my new transaction is now dependent on your preceding transaction being confirmed. There is no "sendfromconfirmedinputsonly" command - it's an algorithmic lottery which inputs the daemon will use to satisfy the outbound transaction. If your transaction is used, it doesn't matter if I include a 1 BTC fee ... I'm still stuck waiting for your transaction to confirm before my new one will.

My bad. I am not an expert, but maybe this will help you:

https://en.bitcoin.it/wiki/Raw_Transactions


Also sendfrom allows you to specify [minconf=1]. See:

https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list

[Arksun]

The fee is currently 0.1 mBTC (~$0.05).  While this is not free it is pretty much cheaper than any other payment system.
Credit Cards: $0.30 + 2%
PayPal: $0.30 + 3%
ACH: $0.25 to $0.50
Bank Wire:  $10 to $25
International Bank Wire: $25 to $40
Check processing (business): $0.50 ea
etc

To be fair, as much as I do love Bitcoin and what it brings to world transfers.

Debit Card:  Usually $0 for a lot of major websites.
Bank Transfer (UK - UK bank account)  $0

Bitcoins primary strength is still making small to very large fast transfers across great distances around the world with tiny fees.

[DeathAndTaxes]

That's why it is good practice to wait for 7 confirmations before accepting a balance.

How? The stock Bitcoin Daemon certainly doesn't discriminate between confirmed and unconfirmed. It just seems to pick appropriately valued outputs to use as inputs - regardless if they are confirmed or not. Literally; "bitcoind sendtoaddress {ADDRESS} {VALUE}". There is no choice.

The stock bitcoind will NOT send until inputs have 1 CONFIRM when using sendtoaddress
The stock bitcoind will NOT increase the balance as seen with getbalance until you have 1 CONFIRM.
This is done INTENTIONALLY to avoid these types of situations.   The 0 confirm input could potentially NEVER confirm (as in a double spend) and thus the tx created with 0 confirm inputs will be forever invalid.

The daemon is also not the "normal clueless user tool".  The stock QT CLIENT will NEVER allow you to create a tx with unconfirmed inputs.  As far as the client is concerned you simply don't have the funds available for spending until they have 6 confirmations.

If other clients/wallets/exchages are allowing users to spend unconfirmed inputs that is a problem with those clients and should be fixed by the authors.

[oblongmeteor]

That's why it is good practice to wait for 7 confirmations before accepting a balance.

How? The stock Bitcoin Daemon certainly doesn't discriminate between confirmed and unconfirmed. It just seems to pick appropriately valued outputs to use as inputs - regardless if they are confirmed or not. Literally; "bitcoind sendtoaddress {ADDRESS} {VALUE}". There is no choice.

The stock bitcoind will NOT send until inputs have 1 CONFIRM when using sendtoaddress
The stock bitcoind will NOT increase the balance as seen with getbalance until you have 1 CONFIRM.

This is done INTENTIONALLY to avoid these types of situations.   The 0 confirm input could potentially NEVER confirm (as in a double spend) and thus the tx created with 0 confirm inputs will be forever invalid.

But this simply does not seem to be the case. See:

https://blockchain.info/tx/35c4e8c86075cf3f5335e029abd2d981af011c142b56e04c0a6d8b0d588d32ae

and

https://blockchain.info/tx/99e6c22980571d1733986d950f564854393777ba0905d08aae36d7f4f64e4a3a

Indeed, you commented on a similar situation here: https://bitcointalk.org/index.php?topic=339792.msg3645862#msg3645862

So, which is it?

[DeathAndTaxes]

How are you determining that those tx were created using the stock bitcoin daemon using sendtoaddress by looking at the tx id?

I told the user to stop sending unconfirmed inputs SPECIFICALLY because that is NON STANDARD BEHAVIOR and one that is likely going to cause more problems than it solves.

The fact that a tx exists doesn't mean it was created using the QT client or sendtoaddress command.  I can show you a tx which 2600 BTC was sent to nowhere.  It certainly wasn't done using the QT client.  You do know there are highly advanced calls like createrawtx which will allow the user to make all kinds of tx, even impossible ones which will result in permanent loss of coins.  


Bitcoind is an advanced tool.  Your grandmother is never going to use it.  The QT CLIENT DOES NOT ALLOW SPENDING UNCONFIRMED INPUTS FOR THIS EXACT REASON (AND OTHER GOOD REASONS AS WELL).

[oblongmeteor]

How are you determining that those tx were created using the stock bitcoin daemon using sendtoaddress by looking at the tx id?

You do know there are highly advanced calls like createrawtx which will allow the user to make all kinds of tx, even impossible ones which will result in permanent loss of coins.   

Because I created them, and I created them with the stock Bitcoin Daemon with the stock BitcoinD command "sendtoaddress". What's more, I had to use the blockchain.info/pushtx functionality to make the downstream transactions show up because it seems transactions with unconfirmed inputs are just ignored by blockchain.info. It was only when I did this that I saw the fact it was spending unconfirmed inputs.

[DeathAndTaxes]

Then report it as a bug.  I often get annoyed that sendtoaddress does not allow sending unconfirmed inputs.

On edit:
Is 19VuPF5XHfp435YBMG3f1F3oXZ9BvS2eTe also an address in the same wallet?  i.e. did you send your balance from one address you own to another one you owned?  If so IIRC bitcoind allows spending that unconfirmed input because it knows that it will be eventually confirmed.  Maybe that behavior should be changed?  Still I would ask WTF did you do that if it is the case?

[ashray]

@Arksun Those fees are usually charged to the MERCHANT. This is why you don't see a charge. They are already priced into whatever you are paying for.

[oblongmeteor]

Then report it as a bug.  I often get annoyed that sendtoaddress does not allow sending unconfirmed inputs.

On edit:
Is 19VuPF5XHfp435YBMG3f1F3oXZ9BvS2eTe also an address in the same wallet?  i.e. did you send your balance from one address you own to another one you owned?  If so IIRC bitcoind allows spending that unconfirmed input because it knows that it will be eventually confirmed.  Maybe that behavior should be changed?  Still I would ask WTF did you do that if it is the case?

No. 19VuPF5XHfp435YBMG3f1F3oXZ9BvS2eTe is not in the wallet. You seem to be under the erroneous impression that some sort of black-art has been attempted with Bitcoin daemon that's gone awry. I'm telling you now that the only command that has been fired at BitcoinD to make it spend the Bitcoins is "sendtoaddress".

[CIYAM]

No. 19VuPF5XHfp435YBMG3f1F3oXZ9BvS2eTe is not in the wallet. You seem to be under the erroneous impression that some sort of black-art has been attempted with Bitcoin daemon that's gone awry. I'm telling you now that the only command that has been fired at BitcoinD to make it spend the Bitcoins is "sendtoaddress".

In this case I would be reporting a bug (those higher level RPC commands should not be like the raw tx ones).

[DeathAndTaxes]

Then report it as a bug.  I often get annoyed that sendtoaddress does not allow sending unconfirmed inputs.

On edit:
Is 19VuPF5XHfp435YBMG3f1F3oXZ9BvS2eTe also an address in the same wallet?  i.e. did you send your balance from one address you own to another one you owned?  If so IIRC bitcoind allows spending that unconfirmed input because it knows that it will be eventually confirmed.  Maybe that behavior should be changed?  Still I would ask WTF did you do that if it is the case?

No. 19VuPF5XHfp435YBMG3f1F3oXZ9BvS2eTe is not in the wallet. You seem to be under the erroneous impression that some sort of black-art has been attempted with Bitcoin daemon that's gone awry. I'm telling you now that the only command that has been fired at BitcoinD to make it spend the Bitcoins is "sendtoaddress".

Like I said file a bug report.  Not sure how or why bitcoind allow spending an unconfirmed output.  I use it for my automated backend and I have to drop to a lower level command to force a tx when I have funds but they are unconfirmed and I need it to go out immediately. I actually wish sendtoaddress had a [minconf=1] option with a default of 1 that would allow finer control but it doesn't.

[CIYAM]

I use it for my automated backend and I have to drop to a lower level command to force a tx when I have funds but they are unconfirmed and I need it to go out immediately. I actually wish sendtoaddress had a [minconf=1] option with a default of 1 that would allow finer control but it doesn't.

A couple of times I have resorted to doing a "getrawtransaction <id>" then pasted the raw tx into https://blockchain.info/pushtx (and that has actually worked).

[oblongmeteor]

I use it for my automated backend and I have to drop to a lower level command to force a tx when I have funds but they are unconfirmed and I need it to go out immediately. I actually wish sendtoaddress had a [minconf=1] option with a default of 1 that would allow finer control but it doesn't.

A couple of times I have resorted to doing a "getrawtransaction <id>" then pasted the raw tx into https://blockchain.info/pushtx (and that has actually worked).

I have done exactly the same, but that's just because people I send BTC to get nervous when the txID I give them doesn't appear on the network (well, blockchain.info). That's what led to this ... discovery.

As an aside, I've raised the issue here: https://github.com/bitcoin/bitcoin/issues/3288

[dsattler]

Look at this transaction:

http://blockchain.info/de/tx/5038108b9f275e8adbd86bf89df695e59b7f03ca72144ca51752904dc989c4e6

Without any fees, it needed 24 hours to get confirmed! 

[oblongmeteor]

Look at this transaction:

http://blockchain.info/de/tx/5038108b9f275e8adbd86bf89df695e59b7f03ca72144ca51752904dc989c4e6

Without any fees, it needed 24 hours to get confirmed! 

A symptom of the untempered greed of mining pools unfortunately. Everyone wants more magical internet money.

[DeathAndTaxes]

As an aside, I've raised the issue here: https://github.com/bitcoin/bitcoin/issues/3288

I took a quick (re)look at the code and sendtoaddress is pretty simple.  It does some parsing and error checking and then calls.  SendMoneyToDestination()

Code:

string CWallet::SendMoneyToDestination(const CTxDestination& address, int64_t nValue, CWalletTx& wtxNew, bool fAskFee)
{
    // Check amount
    if (nValue <= 0)
        return _("Invalid amount");
    if (nValue + nTransactionFee > GetBalance())
        return _("Insufficient funds");

    // Parse Bitcoin address
    CScript scriptPubKey;
    scriptPubKey.SetDestination(address);

    return SendMoney(scriptPubKey, nValue, wtxNew, fAskFee);
}

https://github.com/bitcoin/bitcoin/blob/d980f9b7d687a1e60eecf3691b592d9806a30f4a/src/wallet.cpp#L1467


Note the balance check calling GetBalance()

Code:

int64_t CWallet::GetBalance() const
{
    int64_t nTotal = 0;
    {
        LOCK(cs_wallet);
        for (map<uint256, CWalletTx>::const_iterator it = mapWallet.begin(); it != mapWallet.end(); ++it)
        {
            const CWalletTx* pcoin = &(*it).second;
            if (pcoin->IsConfirmed())
                nTotal += pcoin->GetAvailableCredit();
        }
    }

    return nTotal;
}

https://github.com/bitcoin/bitcoin/blob/d980f9b7d687a1e60eecf3691b592d9806a30f4a/src/wallet.cpp#L961

GetBalance gets the sum of confirmed unspent outputs.

The only thing I can think of is at the time you created the second tx the unspent output used WAS CONFIRMED.  Possibly there was a short re-org in the blockchain AFTER the second tx was broadcast which made the first tx unconfirmed.  Then because of high number of free tx and miners including a limited number you ended up with the first tx not confirming for a while and that led to the second tx not confirming for a while.


IMHO the default behavior for a lot of things probably need to change.  I doubt the core devs will see it as a high priority but I think the entire system would be simpler and less prone to unexpected (from user standpoint) behavior if we saw the following.

1) Drop min fee to 0.02 mBTC.  The last time this was done the exchange rate was ~$100 USD.  The drop would put min fees back to ~$0.01 per KB.
2) Change default behavior of client to include a fee on ALL tx (not just low priority ones) and make the default fee the min fee.  Users can override this but they should be warned "including no fee may result in substantial delays before confirmation".
3) Implement "parent pays child".
4) Implement "tx replacement".

Use blogs and other public forums to advocate that authors of other wallets/eWallets/exchanges/etc do the same.

[oblongmeteor]

The only thing I can think of is at the time you created the second tx the unspent output used WAS CONFIRMED.  Possibly there was a short re-org in the blockchain AFTER the second tx was broadcast which made the first tx unconfirmed.  Then because of high number of free tx and miners including a limited number you ended up with the first tx not confirming for a while and that led to the second tx not confirming for a while.

That sounds plausible, but how often would you expect such a reorganization to occur? I have just dug through the logs and found another example:

This transaction https://blockchain.info/tx/2b7bec664c3552c605dd687404e1c7088501e88369ceabf4da04c2bd15dc2ed4 was broadcast at 02:28 GMT on the 19-11-2013. It did not confirm for 670 minutes and the transaction had to be manually pushed through blockchain.info/pushtx to appear on the blockchain.info database. The reason it didn't appear is again, because of an unconfirmed input being used: https://blockchain.info/tx/3386d4afcd5506a7bd77637b63f0ed061b878fb1557278bc3717048ca10d4c31 - This ancestor transaction was broadcast at 01:42 GMT on the 19-11-2013 and included no fee. It took 716 minutes to confirm.

You can see the overlap in confirmation times means https://blockchain.info/tx/3386d4afcd5506a7bd77637b63f0ed061b878fb1557278bc3717048ca10d4c31 could not have possibly been confirmed when it was used as an input for https://blockchain.info/tx/2b7bec664c3552c605dd687404e1c7088501e88369ceabf4da04c2bd15dc2ed4

[Nagle]

Here's a live list of Mt. Gox Bitcoin transactions stuck waiting for confirmation for more than 2 hours:
http://skanner.net/MtGox/mtgox_tx.php

There's a huge backlog of "no fee" transactions.   It looks like 0.001 BTC isn't enough to consistently get a transaction through, but 0.002 BTC is. So it now costs about $1 to do a Bitcoin transaction.

Bitcoin has now been priced out of the micropayments business. It's too expensive for, say, an iTunes track or a video rental.

[Barek]

Here's a live list of Mt. Gox Bitcoin transactions stuck waiting for confirmation for more than 2 hours:
http://skanner.net/MtGox/mtgox_tx.php

There's a huge backlog of "no fee" transactions.   It looks like 0.001 BTC isn't enough to consistently get a transaction through, but 0.002 BTC is. So it now costs about $1 to do a Bitcoin transaction.

Bitcoin has now been priced out of the micropayments business. It's too expensive for, say, an iTunes track or a video rental.

Would you mind linking a couple of those with 2h wait time and proper fee?