Cost and Confirmation time of Bitcoin Transactions - page 2.

oblongmeteor

full member

Activity: 134

Merit: 100

Quote from: dsattler on November 20, 2013, 12:08:57 PM

Look at this transaction:

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

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

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

dsattler

legendary

Activity: 924

Merit: 1000

Look at this transaction:

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

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

oblongmeteor

full member

Activity: 134

Merit: 100

Quote from: CIYAM on November 20, 2013, 12:02:20 PM

Quote from: DeathAndTaxes on November 20, 2013, 11:59:18 AM

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 " 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

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Quote from: DeathAndTaxes on November 20, 2013, 11:59:18 AM

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 " then pasted the raw tx into https://blockchain.info/pushtx (and that has actually worked).

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: oblongmeteor on November 20, 2013, 11:43:11 AM

Quote from: DeathAndTaxes on November 20, 2013, 11:32:46 AM

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

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Quote from: oblongmeteor on November 20, 2013, 11:43:11 AM

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).

oblongmeteor

full member

Activity: 134

Merit: 100

Quote from: DeathAndTaxes on November 20, 2013, 11:32:46 AM

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".

ashray

newbie

Activity: 45

Merit: 0

@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.

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

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?

oblongmeteor

full member

Activity: 134

Merit: 100

Quote from: DeathAndTaxes on November 20, 2013, 11:27:35 AM

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

donator

Activity: 1218

Merit: 1079

Gerald Davis

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

full member

Activity: 134

Merit: 100

Quote from: DeathAndTaxes on November 20, 2013, 11:21:52 AM

Quote from: oblongmeteor on November 20, 2013, 10:33:54 AM

Quote from: Barek on November 20, 2013, 10:21:49 AM

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://bitcointalksearch.org/topic/m.3645862

So, which is it?

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: oblongmeteor on November 20, 2013, 10:33:54 AM

Quote from: Barek on November 20, 2013, 10:21:49 AM

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.

Arksun

sr. member

Activity: 616

Merit: 250

Quote from: DeathAndTaxes on November 19, 2013, 10:32:17 PM

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.

Barek

full member

Activity: 168

Merit: 100

Quote from: oblongmeteor on November 20, 2013, 10:51:58 AM

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

oblongmeteor

full member

Activity: 134

Merit: 100

Quote from: Barek on November 20, 2013, 10:41:06 AM

Quote from: oblongmeteor on November 20, 2013, 10:30:54 AM

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.

Barek

full member

Activity: 168

Merit: 100

Quote from: oblongmeteor on November 20, 2013, 10:30:54 AM

Take block #270632. This includes a fairly typical 469 transactions, and gets 25 BTC reward (13949.34 USD according to CoinMill). They only took 0.14727399 BTC (82.17 USD) in fees. Basically, they received an extra 0.58% in reward fees. Bitcoin price has dropped by 1.07% (src: Bitstamp - Open 536.01, Close - 530.25) today alone. Does 0.58% extra really justify killing the performance and usability of Bitcoin?

I doesn't kill anything. It just takes a little longer. Paying a few USD cent gets rid of the wait time. It's everyone's choice what to do. Personally, I don't think twice about those few cents. And on top of that, I know that those few cents even go towards improving the network (in a tiny way).

Quote from: oblongmeteor on November 20, 2013, 10:33:54 AM

Quote from: Barek on November 20, 2013, 10:21:49 AM

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.

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.

Or are you asking how to see how many confirmations a transactions has? Your client should show you. You could also use https://blockchain.info/address/.

oblongmeteor

full member

Activity: 134

Merit: 100

Quote from: Barek on November 20, 2013, 10:21:49 AM

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.

oblongmeteor

full member

Activity: 134

Merit: 100

Quote from: Barek on November 20, 2013, 10:18:18 AM

Quote from: oblongmeteor on November 20, 2013, 10:08:21 AM

But isn't the increased value of Bitcoin with respect to FIAT reward enough?

The way mining and difficulty works, the infrastructure is directly proportional to the block rewards (base reward + fees). More fees and higher exchange rates will always directly improve the hashing power of the network. No such thing as enough if you are interested in improving the hash rate.

But this doesn't make sense. The whole way Bitcoin is architected means that whether you've got one person mining on a single PC, or an entire continent on high power ASICS, the base reward is fixed with respect to the number of Bitcoins mined thus far (100->50->25->[...]->0 etc). Since we won't reach a mining reward that is near zero before 2040? The performance of the network and the faith people have in it is being significantly hampered for the sake of fractions of a Bitcoin.

Take block #270632. This includes a fairly typical 469 transactions, and gets 25 BTC reward (13949.34 USD according to CoinMill). They only took 0.14727399 BTC (82.17 USD) in fees. Basically, they received an extra 0.58% in reward fees. Bitcoin price has dropped by 1.07% (src: Bitstamp - Open 536.01, Close - 530.25) today alone. Does 0.58% extra really justify killing the performance and usability of Bitcoin?

laowai80

member

Activity: 98

Merit: 10

I've sent a few transactions recently with a 0.0005 BTC fee, the waiting time is normal, so I guess it's the minimum fee to have no issues. If you want to save on fees, then I guess exchange your BTC to LTC for micro-payments. BTC is getting into heavy-weight category, can't be bothered with micro-payments (as measured in USD).

Topic: Cost and Confirmation time of Bitcoin Transactions - page 2. (Read 17142 times)