Bitcoin Forum

https://blockchain.info/tx/c07d47a5e1d023d0fd2c47c600a4ca178c7a2954754c88f3fb7f729bafb94539

will my transfer get throught ? its been like this for like 50mins

edit: ~12h passed.

Don't panic, just give it time more, it happens sometimes.

still not went through im getting scared lol

Just so you know I did check again, it's saying two minutes now, but the queue position is just under 300.

Good luck. I'm not sure why it's taking so long then now, sorry.

Update

That estimated timer is still all over the place.

Looking over the blockchain one of the inputs has loads of micro transactions, and the other has a few very regular 5 BTC transactions.

here's an idea: stop using blockchain.info's wildly inaccurate "estimated confirmation time"

This has two inputs -- one of which results from several hundred transactions (So, cashing it out is going to take some space in the blockchain) and the other of which has a confirmed but fairly recent transaction (so it may be delayed a little while things that the transaction processors are more sure of go first). 

Did you include a tx processing fee, or is this thing queueing up for the very limited space in a block's free area? 

Hi, Cryddit. I transfered these from blockchain.info wallet.. they asked me to adjust the fees and I did it. as you can see i paid 0.0034 BTC in fees.

Now its been hours... like this.

Its very hard to accurately predict the confirmation time as:

a) The time between mined blocks varies
b) The number of transactions in blocks varies
c) It's impossible to predict if transactions will be made in future that bump yours down the queue.
d) Unknown if the biggest miners have received your transaction of not.

So don't be surprised if the estimated confirmation time changes.

As far as I can tell, other than the transaction being very large, there is nothing which should prevent it confirming.  I have rebroadcasted it manually now so hopefully that should help.

Thanks!

Agreed, that sounds hard. However the wild variations in the prediction turn this indicatior into something nearly useless. I've had transactions estimated to be confirmed within a few minutes, then 4 hours, then yay one confirmation! Wouldn't a more naive approach make more sense? E.g. taking into account only the position in the queue and some average block confirmation time, which would turn out to be around 7 minutes these days.

maybe some fix

May I ask you please how you can rebroadcast it manually. Thanks in advance.

https://blockchain.info/pushtx

See, I think this is nuts.  I mean, it's a pretty severe problem when a transaction can be out there for hours without getting into a block, especially with an appropriate tx fee paid.

Ten or twenty minutes is acceptable.  Thirty ought to be something that's very rare. 

But this is looking more and more like a service failure -- something about the P2P protocol that needs to be fixed. 

We keep talking about "bitcoin is the future" - but the future has better service than this. 

almost a day (more than 12h)

https://blockchain.info/tx/c07d47a5e1d023d0fd2c47c600a4ca178c7a2954754c88f3fb7f729bafb94539

still unconfirmed.

Okay, I'm not fully "up" on the ins & outs of mining.

But for what reasons do miners choose which transactions to include and exclude when they form a block? 

Why wouldn't they take these transaction fees?

I'm here (invested in Bitcoin) because I believe that it's a Better Solution to transferring money via the Internet.  And if it's failing to be a Better Solution I want to understand why, and what is necessary to fix it.

With more and more mentions in the news, Bitcoin is headed for a sort of "general awareness" as an option that it hasn't achieved now.  But when it gets that sort of "general awareness" we don't want people experiencing service failures as their first interaction with it, because if that happens they'll drop it like a rock. This is one of the biggest reasons I'm concerned about mining and scalability; those are where we have the biggest vulnerabilities to failure. 

If the miners are picking transactions to not process, or if the blockchain cannot handle it when one day we get slashdotted and it's hit with massive volume, then we have a fundamental problem that will prevent Bitcoin from achieving a critical mass of public acceptance and becoming what it could otherwise become -- a universal, easy, reliable, cheap way to transfer money via the Internet. 

So, when something like this happens and the system isn't even terribly stressed, I am more than a little concerned.  If we want public acceptance, we must have public trust.  If we want public trust, then service failure is not an option. 

Hopefully the transaction will revert back.

but I agree with you Cryddit.

Also gavin and his team are working hard on this new fees system, hopefully he can fix bugs like these.

Bitcoin is still BETA ;)

$5000 eternally trapped in limbo...

2013-11-01 13:06:41 ERROR: CTxMemPool::accept() : not enough fees c07d47a5e1d023d0fd2c47c600a4ca178c7a2954754c88f3fb7f729bafb94539, 340000 < 350000

piuk: If you have the getrawtransaction style tx, I'll push it through on Eligius.

Frustrating it's only 0.0001 BTC out. If you are able to that would be great: http://pastebin.com/raw.php?i=uV10H0M6

Piuk, thanks!

But this was a fee error from blockchain.info I ajusted according to it... and it still missed  0.0001. Hopefully this won't happen to more people.

Np. It should confirm in Eligius's next block. (Edit: Done in block 267335)

Might I suggest adding a public getrawtransaction equiv for blockchain.info? :)

Yea, we would have been able to help JimJones in IRC if that existed.

Also, — roundup! :)

+1

Thanks. You can now request hex format e.g.

https://blockchain.info/tx/c07d47a5e1d023d0fd2c47c600a4ca178c7a2954754c88f3fb7f729bafb94539?format=hex


Also, divide the tx size by 1000 bytes rather than 1024 :P

Just a note here but I think that basing fees on tx size, while technically accurate, is too opaque for mainstream users.   Fees IMO ought to be based on some measure that they can easily see and understand knowing no more than the amounts they're transferring, the same way sales taxes are in most jurisdictions.

If the tx fees were to be an ultra-simple 0.1% of the transaction, rounded to a MicroCoin,  I think we'd get a lot less confusion and mistakes, and miners would get about the same amount in fees. 

'Cos here, the "low fees" obstruction was based on tx size divided by 1000 and the fee estimation was based on tx size divided by 1024 - But Joe and Jane end-user have no idea what a tx size is if it isn't the amount of money they're transferring in the first place.

Why did you try to set the fee manually? Normally you set the fee rate, say 0.0001, and let client take care of the actual fee based on the size of the transaction.

The basic issue with this transaction is it didn't pay the minimum fees. This transaction activated every spam prevention feature there is:

1. The transaction was 34235 bytes; the fee is 0.0001 BTC per kB (not KiB) but this transaction paid 34x, not 35x minfee. Transactions with less than the minimum are considered the same as zero-fee by Bitcoin. They are not relayed across the Bitcoin network.

2. If free transactions make it to a miner, default Bitcoin has a small area of a block for including some free transactions if block is less than 27kB when received. This transaction is bigger than the whole free area - only transactions under 10kB in size are even considered.

3. The priority (based on total weighted coin age by value) was too low to be considered for any fee-free inclusion. This transaction was a whole bunch of dust, plus 25 BTC; the 25BTC had just recently been received by the wallet. If the contents of the wallet had been allowed to age for a few days, they likely could have been sent for free.

Blockchain.info is mostly at fault, they shouldn't let users do stupid things, and should calculate (and enforce) the exact minimum fee Bitcoin-qt would use. It also helps if users don't spam up their own wallets with dust.

Bitcoin doesn't easily allow web applications to figure out what the correct/current fee is; it needs an RPC feature I will call "sendtoaddressfee", where bitcoin txouts are not spent, but reserved, and the fee amount is returned. When the same bitcoin amount is actually spent, the transaction is constructed from the reserved bitcoins txouts; any other transaction besides the original clears the reservation.

All of that is true.  Now, did you have a point?

Good luck explaining to Joe and Jane end-user that the fee for transferring a given amount is going to be different every time and will depend on things they can't even see.  They will tell you that's stupid, without even wanting to learn why you think the fees should be different.

This seems to be one of the major bitcoin future issues.  Is bitcoin meant to be used to buy your morning coffee or is it meant to be as a large wealth transfer mechanism.  Tech question, can dust still be sent free or is there a minimum fee that makes that impossible?

Big gz.

228 confirmations.

yea but if it wasn't for the help of some #bitcoin-dev users and #eligius fellas, it would still be unconfirmed/pending.

Hope gavin addresses to the fees system :p

Yes I had realised that. Ty to the users that helped him.