oblongmeteor (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 20, 2013, 03:51:58 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 20, 2013, 04:01:06 PM |
|
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_TransactionsAlso sendfrom allows you to specify [minconf=1]. See: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list
|
|
|
|
Arksun
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 20, 2013, 04:05:38 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.
|
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 20, 2013, 04:21:52 PM |
|
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.
|
|
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 20, 2013, 04:27:35 PM |
|
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 (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 20, 2013, 04:31:08 PM |
|
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
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 20, 2013, 04:32:46 PM |
|
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
Newbie
Offline
Activity: 45
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 20, 2013, 04:33:35 PM |
|
@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 (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 20, 2013, 04:43:11 PM |
|
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
Legendary
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 20, 2013, 04:47:58 PM |
|
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
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 20, 2013, 04:59:18 PM |
|
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
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 20, 2013, 05:02:20 PM |
|
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 (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 20, 2013, 05:07:43 PM |
|
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
Legendary
Offline
Activity: 924
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 20, 2013, 05:08:57 PM |
|
|
Bitcointalk member since 2013! ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
oblongmeteor (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 20, 2013, 05:19:41 PM |
|
A symptom of the untempered greed of mining pools unfortunately. Everyone wants more magical internet money.
|
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 20, 2013, 05:21:36 PM |
|
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() 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#L1467Note the balance check calling GetBalance() 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#L961GetBalance 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.
|
|
|
|
|
Nagle
Legendary
Offline
Activity: 1204
Merit: 1002
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 20, 2013, 06:31:20 PM |
|
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.phpThere'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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 20, 2013, 07:01:28 PM |
|
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.phpThere'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?
|
|
|
|
|