Bitcoin Forum

Bitcoin => Development & Technical Discussion => Topic started by: stslimited on August 20, 2013, 03:53:03 PM



Title: large portion of network rejecting transactions?
Post by: stslimited on August 20, 2013, 03:53:03 PM
Hello

I am having bad luck doing commerce as my transactions randomly take a long time to go through from my local bitcoin client and transactions sometimes rejected, I see some weird anomalies sometimes and of course coinbase always takes forever.

It makes me wonder if a large portion of the new unknown miners are rejecting transactions due to a previously less common implementation of bitcoin and not prioritizing based on the fees


just a heads up and insight appreciated


Title: Re: large portion of network rejecting transactions?
Post by: evilpete on August 20, 2013, 04:27:56 PM
It would always be helpful to include a problematic transaction id or two so that folks can see what the actual problem is and not have to guess.

The network generally rejects non-economical dust outputs now.  This affects things like faucets etc where the faucet amounts often cost more in fees for the recipient to spend than they actually received.

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


Title: Re: large portion of network rejecting transactions?
Post by: GCInc. on August 20, 2013, 04:49:37 PM
I am experiencing delays of several blocks before a single confirmation for decent amount transfers with 0.0001 fee. Does the fee amount have anything to do with this postponing of confirmations? Blockchain.info shows Estimated Confirmation Time    4 minutes (queue position 76)


Title: Re: large portion of network rejecting transactions?
Post by: gmaxwell on August 20, 2013, 05:31:02 PM
You really need to provide more data, like a transaction ID (better, full hex of the transaction in question, but a TXID would be a start). Also, it's helpful to know where it was sent from and if possible what software it was using.


Title: Re: large portion of network rejecting transactions?
Post by: GCInc. on August 20, 2013, 05:55:39 PM
https://blockchain.info/tx/7881441471aed70bdbb07f0a80bdfe5b9073b213854a06b55ff7290801007fa3

Don't see anything strange there any more, it got confirmed properly after skipping over 4-5 blocks

What does the queue position mean? I am supposing blocks are filled up with higher priority transactions, and during a run of several long block intervals many pending transactions not get included in blocks. I was however surprised that a 0.25 BTC transaction with 0.0001 fee was considered low priority and delayed over 5 blocks. Thus my question of whether a higher fee amount would help anything or is it not a prioritization issue at all.


Title: Re: large portion of network rejecting transactions?
Post by: Peter Todd on August 20, 2013, 07:05:37 PM
Transaction volume was very high earlier today - your transaction had a relatively low fee given it's size, so it was probably just being outbid for blockchain space by transactions that paid a higher fee/kb. (your wallet uses uncompressed addresses, which are bigger, which doesn't help)

I don't know if your wallet software/service lets you set fees, but in the future if you want to be sure a transaction will go through quickly a fee of about 0.001BTC pretty much guarantees it'll get mined in a block or two these days.


Title: Re: large portion of network rejecting transactions?
Post by: GCInc. on August 20, 2013, 08:18:52 PM
to be sure a transaction will go through quickly a fee of about 0.001BTC pretty much guarantees it'll get mined in a block or two these days.
Thanks, this answered my question, hope it helps OP also.


Title: Re: large portion of network rejecting transactions?
Post by: Mike Hearn on August 20, 2013, 10:00:23 PM
Which wallet app are you using, by the way?


Title: Re: large portion of network rejecting transactions?
Post by: GCInc. on August 21, 2013, 11:09:11 AM
I used Electrum 1.7.1 (windows) for that transaction. A week or so ago I had serious problems with any version of Electrum not updating the wallet properly for several days, but apparently these incidents were not related.