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);
} Note 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;
} 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. |
|
|
|
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. |
|
|
|
|
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?
|
|
|
|
|
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).
|
|
|
|
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. |
|
|
|
|
Rule #1) Never buy all at once.
Rule #2) Never sell all at once.
Rule #3) Never sell all your coins.
|
|
|
|
Just how would a pool go about putting more transactions into the blocks they find? I assume they have to modify the source code, recompile, and then deploy? Are the changes trivial for the average pool operator? My understanding (pool ops feel free to correct me) is that pools are already running highly customized version of bitcoind. Honestly if you can't compile bitcoind then you probably don't have the technical skills to run a pool. Still up to 250KB you wouldn't even need to compile bitcoind simply modify one line in the bitcoin.conf file. A LOT of blocks are much smaller than 250KB. So it becomes a no brainer to focus on that first. The average block in past 30 days is ~150KB. Eyeballing it, it looks like 80% of blocks are <250KB. A good 25% of blocks aren't even 100KB and at least 10% aren't even 50KB. If all blocks were 250KB we wouldn't even have a backlog (except for no-fee txs). There are some exceptions. BTC Guild does sometimes push out much larger blocks (350KB to 400KB). Not sure what conditions trigger that. Maybe they only do it when the backlog gets real bad. https://blockchain.info/block-index/441049And on top of this there is a greater chance of an orphan block resulting in the loss of 25 BTC? It simply does not justify the risk to add more transactions and lose out on the reward. Is this a correct assumption(s)?
There is a cost but fees do offset that. Users shouldn't expect pools to make larger blocks full of free tx but paid tx offset the marginal cost of larger blocks. One estimate put the marginal cost (due to increased orphan risk) at ~0.04 mBTC per KB. Still at some point pool ops have to decide if 1% or so lower orphan losses worth the bad PR of Bitcoin "choking" at ~0.3 tps. I mean 0.3 tps. The 1 MB limit is 4 to 6 tps. PayPal is 50 tps. VISA is 5,000 tps. We are at 0.3 tps, and the network seems to be straining. If pools are unwilling to push the envelope to at least 300KB to 500KB blocks well we might as well pack it up because this experiment is going nowhere. For the record I do think they will adapt and I do think the protocol will eventually handle block broadcasting in a more intelligent manner so this becomes less of an issue over time. The falling subsidy will also improve the economics of larger blocks. It also isn't all on the pools. Users need to accept you either PAY or you get a confirmation eventually where eventually can be days or possibly weeks. It is a "charity" option and you get space when space is available (which probably means a block on Tuesday at 2:48 in the morning). The days of pay no fee and see it in the next block are over. So doing that over and over and getting mad is just silly. |
|
|
|
|
wow it temporarily pushed gox below other exchanges
|
|
|
|
Are solo miners affected? I mean, those who use bitcoind and their own ASIC devices, at the usual or standard set up.
If, for example, I had maybe 100 TH/s of mining equipment, and I decide to go do solo or p2pool ...
What do you mean affected? You can create blocks of any size up to 1MB. Of course pools can do as well. They have simply CHOSEN to make much much smaller blocks. It looks like a few regular miners are keeping blocks <100KB. Most seem to cap at 250KB. The average for prior 30 days is ~150KB or a staggering 0.3 transactions per second. Oh okay. So it's only the major pools are choosing to make small blocks. If I were a solo miner, I could set up and be customized to a larger block size (one that won't fork the chain.) Larger blocks up to 1MB yes. Creating blocks greater than 1MB no. |
|
|
|
|
Right NOW, the reality is 0.1 mBTC IS fine. There isn't a massive backlog of paying tx. The backlog is on free tx. The average block size isn't >250KB it is ~150KB. That isn't to say it won't be an issue in the future but right now the min fee is fine.
Still the larger fee for larger blocks is a huge landmine and beyond stupid. It makes absolutely no sense. Users have no idea what size blocks miners are targeting. If a user pays double but a miner is targeting 100KB block the higher fee is just useless. The larger fees for larger blocks nonsense should just be scrapped. It might have made sense in the early history when average block was 20KB and there was a risk of a spam attack creating 1MB bloat blocks but those days are gone now.
|
|
|
|
Current problem here is that Bitcoin price moves signifcantly more rapidly than fee amendments. In the last 72 hours, the price of one Bitcoin on BTC China peaked at circa 1,100 USD. Moving one BTC with the minimum fee of 0.0001 BTC would cost you 11 cents. Amazon pay less than that to process a credit card transaction.
When the price stabilizes the min fee can be reduced. It doesn't have to be exactly fixed in fiat terms. Throughout the history of Bitcoin despite the exchange rate rising 60,000,000% the min fee has been ~0.5 cents to 10 cents per KB. The last min fee reduction happened when Bitcoin sustained an exchange rate >$100 and after the reduction the fee was ~1 US cent. |
|
|
|
There seems to be a substantial backlog (6000) of Bitcoin transactions building up thanks to the increasing number of users taking to the technology ( https://bitcointalk.org/index.php?topic=338999.0) and numerous questions in the [Technical Support] board ( https://bitcointalk.org/index.php?board=4.0) over why transactions are seemingly now stuck in Limbo even when they include a fee. Suggestions have been mooted such as "include a higher fee" and "be more generous", but how does this work in the context of most users? The average person will do what their wallet tells them. They'll have no idea what constitutes a suitable fee for inclusion in a block and when they realize that even if they include the required 0.0001 BTC minimum fee, this puts them in the same position and requires they still wait 12-48 hours for their transaction to confirm - it's going to raise serious questions over Bitcoin's scalability... In addition, according to CoinMill - the cost of 1 BTC is currently 641.84 USD and a transaction fee of 0.0001 BTC is 0.06 USD (6 cents). 0.0005 (the old fee) is 30 cents. As Bitcoin appreciates (if it does), the cost of transactions relative to the value of a Bitcoin grows substantially. This makes it pretty uneconomical for any merchant to engage in using Bitcoin as a currency as A) they'll be waiting ages for their transaction to confirm if the user incorrectly attaches an 'unacceptable' fee and B) the cost of moving BTC is likely to rapidly meet or exceed that of preexisting payment methods such as ACH, Debit and eventually Credit cards... and in the case of the latter two it doesn't generally take 24-48 hours to even acknowledge your transaction exists. Are there any solutions to this conundrum? You are taking things out of context. Please show me a single user that a) is using standard transactions b) paid the MINIMUM fee c) didn't create a tx w/ unconfirmed inputs (which have to be confirmed before the tx can confirm) and has a tx stuck for hours. 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 Most users with tx "stuck" issues involve either a) a free as in no fee at all b) giant bloated dust spam tx that miners are reluctant to include in blocks c) tx which have no fee issues like using unconfirmed outputs as inputs. |
|
|
|
Are solo miners affected? I mean, those who use bitcoind and their own ASIC devices, at the usual or standard set up.
If, for example, I had maybe 100 TH/s of mining equipment, and I decide to go do solo or p2pool ...
What do you mean affected? You can create blocks of any size up to 1MB. Of course pools can do as well. They have simply CHOSEN to make much much smaller blocks. It looks like a few regular miners are keeping blocks <100KB. Most seem to cap at 250KB. The average for prior 30 days is ~150KB or a staggering 0.3 transactions per second. |
|
|
|
|
Well it isn't future proofing or improving confidence to just raise a limit and then have the defacto size remain the same. Lets see if pools can use the available resources first.
|
|
|
|
I think maybe pools should advertise a "guaranteed to process given available space" fee level? Lots of people may prefer to pay quite a bit more than being kept in the unknown, which is infuriating.
The min fee (0.1 mBTC per kB) should be fine. Comparing the memory pool to recent blocks almost all paying tx are included in the next block. The issue is more people creating tx w/ unconfirmed inputs and people creating tx w/ no fee (and any fee < 0.1 mBTC is considered no fee). Still pools DO need to start making blocks large. 150KB (0.3 tps) isn't going to cut it. Bitcoin growth is essentially halted until pools start expanding block size. |
|
|
|
Agreed. I would strongly recommend paying the min fee on ALL transactions. Most wallets have the option to set a default fee. Set it to 0.1 mBTC and be done with it. Piuk indicated he will be improving blockchain wallet as the reality is tx volume is higher now and assumming a tx can get away with no fee just because it is high priority is no longer a good assumption. It WAS a good assumption in the past but it needs to change.
Clients do need to get smarter. I updated my post prior to seeing your response so we have some agreement on that. Remember Bitcoin is in beta and it is an experiment.
As a practical peice of advice to anyone reading.
Set your client to pay the min fee (0.1 mBTC per KB) for all transactions. Trying to send some free tx is bound to be a penny wise and pound foolish scenario.
...this leads to another problem though. Cost. I'll quote: https://bitcointalk.org/index.php?topic=339802.0: "according to CoinMill - the cost of 1 BTC is currently 641.84 USD and a transaction fee of 0.0001 BTC is 0.06 USD (6 cents). 0.0005 (the old fee) is 30 cents. As Bitcoin appreciates (if it does), the cost of transactions relative to the value of a Bitcoin grows substantially. This makes it pretty uneconomical for any merchant to engage in using Bitcoin as a currency as A) they'll be waiting ages for their transaction to confirm if the user incorrectly attaches an 'unacceptable' fee and B) the cost of moving BTC is likely to rapidly meet or exceed that of preexisting payment methods such as ACH, Debit and eventually Credit cards... and in the case of the latter two it doesn't generally take 24-48 hours to even acknowledge your transaction exists." Miners want to have their cake and eat it. They want the reward from mining a block as well as only cherry picking the transactions that add additional gravy. This doesn't work for a payment network. If you want to move value around, there needs to be some reasonable expectation that the process will complete in a timely manner without a risk of significant delays. You can't "add a bit on" if you mess up and anyone downstream who includes your unconfirmed output is going to screw their transaction confirmation times over... The min fee has been reduced 4 times since the inception of Bitcoin from 10 mBTC to 1 mBTC to 0.5 mBTC to 0.1mBTC. Miners can always require a higher fee but to date they really haven't. If the exchange rate keeps rising it will probably be lowered again. In fiat terms is has ranged from ~1 cent to ~10 cents and usually when it gets to the high end the min fee gets cut. |
|
|
|
i didnt find out how to set the fees automaticly deducted on blockchain
There is the following choice: Generous - Fees will be set to ensure transactions are high priority (0.001 BTC Base Fee). But this will be $0.60 per transaction. So I suggest that during the review of the transaction before you send it make sure it has the 0.0001 BTC fee for now. As others have stated a fix to this issue may be in the works. Some needs to have piuk update that 1 mBTC is just stupid. The default was dropped to 0.1 mBTC a while ago. Not having an option for 0.1 mBTC for all tx is just a bad bad oversight. |
|
|
|
i didnt find out how to set the fees automaticly deducted on blockchain
Wallet Home > Account Settings > General > Default Fee Policy |
|
|
|
This isn't a I paid the default fee but it wasn't enough issue. Paying tx seem to be confirmed relatively quickly.
Some of OP tx have no fee and some have unconfirmed outputs using inputs. Neither are going to be processed quickly. The OP just has to wait. I have my wallet set at default fee for all tx (even those which can be sent free). Had about 80+ tx in the last couple days. Not a single one was delayed more than 1 block or so.
With respect, I think you're missing the point. In the scenario you've indicated the likely reason the transaction isn't confirming is because one input in the chain didn't include a fee. It likely didn't include a fee because it didn't need to include a fee as far as the client was concerned (age of inputs, size etc met the criterion required for inclusion). That one output has been used as an input in a subsequent transaction (I've experienced this myself, see: https://bitcointalk.org/index.php?topic=339709.0). As a consequence, even if child, grandchild etc transactions include a fee, they will not be processed until the 0 FEE ancestor input is confirmed. You can be waiting 24+ hours for this... Users use Bitcoin - they don't dig into the API or form a raw transaction manually to ensure they don't spend unconfirmed outputs and they take the software at it's word (I'm talking stock Bitcoin Client here) when it doesn't force them to pay a fee. It is a problem, maybe not for veterans like yourself, but for the average user it's a real usability issue. Agreed. I would strongly recommend paying the min fee on ALL transactions. Most wallets have the option to set a default fee. Set it to 0.1 mBTC and be done with it. Piuk indicated he will be improving blockchain wallet as the reality is tx volume is higher now and assumming a tx can get away with no fee just because it is high priority is no longer a good assumption. It WAS a good assumption in the past but it needs to change. Clients do need to get smarter. I updated my post prior to seeing your response so we have some agreement on that. Remember Bitcoin is in beta and it is an experiment. As a practical peice of advice to anyone reading. Set your client to pay the min fee (0.1 mBTC per KB) for all transactions. Trying to send some free tx is bound to be a penny wise and pound foolish scenario. |
|
|
|
the main idea of bitcoin at the first was simplicity...and no speculation...funny times
Here is simplicity. Pay the min fee (0.1 mBTC) on all tx, always. I can't get any simpler than that. As far as no speculation. Care to point to where Satoshi said that. Humans have speculated on just about everything that has ever existed and was publicly traded. Bitcoin isn't going to change human nature. |
|
|
|
|
Show Posts
