|
Title: .1 BTC transaction pending with 48 peers for 36 hours??? Post by: TexasRebel on January 06, 2017, 05:28:57 PM has anyone seen this problem?? I've got .1 BTC sending from my local wallet address to another address and it's been pending for confirmation
for over 36 hours.. It's currently got 48 peers.. Is this due to the price plunge in the past 2 days?? TR Title: Re: .1 BTC transaction pending with 48 peers for 36 hours??? Post by: Carlton Banks on January 06, 2017, 05:40:37 PM What fee rate are you using? i.e. satoshis per kB
Title: Re: .1 BTC transaction pending with 48 peers for 36 hours??? Post by: alyssa85 on January 06, 2017, 06:00:44 PM Is it made up of lots and lots of small inputs? If so then you will be sending a lot of bytes and need to up your fee. (the only way around this is to let small inputs age for a few years).
Title: Re: .1 BTC transaction pending with 48 peers for 36 hours??? Post by: Carlton Banks on January 06, 2017, 06:08:40 PM (the only way around this is to let small inputs age for a few years). Miners aren't paying much attention to the age of inputs these days, especially since they're likely all aware that the priority status for a given input will be removed from the code by the end of the year (slated for version 0.15). So, it's best not to encourage that way of looking at fees, as it will be moot pretty soon. Satoshis per kilobyte is what miners are interested in. Title: Re: .1 BTC transaction pending with 48 peers for 36 hours??? Post by: alyssa85 on January 06, 2017, 06:28:51 PM (the only way around this is to let small inputs age for a few years). Miners aren't paying much attention to the age of inputs these days, especially since they're likely all aware that the priority status for a given input will be removed from the code by the end of the year (slated for version 0.15). The new rules arn't in force yet though, are they? Which means the old rules about priority still stand. If OP's output is made up of lots of fairly young inputs, that's the reason he is having trouble. Title: Re: .1 BTC transaction pending with 48 peers for 36 hours??? Post by: Lauda on January 06, 2017, 06:35:44 PM (the only way around this is to let small inputs age for a few years). Miners aren't paying much attention to the age of inputs these days, especially since they're likely all aware that the priority status for a given input will be removed from the code by the end of the year (slated for version 0.15). The new rules arn't in force yet though, are they? Which means the old rules about priority still stand. If OP's output is made up of lots of fairly young inputs, that's the reason he is having trouble. Quote The mining of transactions based on their priority is also now disabled by default. To re-enable it, simply set -blockprioritysize=<n> where is the size in bytes of your blocks to reserve for these transactions. The old default was 50k, so to retain approximately the same policy, you would set -blockprioritysize=50000. https://github.com/bitcoin/bitcoin/blob/v0.12.0/doc/release-notes.md#relay-and-mining-priority-transactionsThe miners can factor in priority if they want, but they do not have to. If I'm correct, most miners in fact do not use priority nowadays. @OP: Post your TX ID or the fee rate (as suggested by Carlton). In case that you don't know how to make this trivial calculation, post the transaction size in addition to the fee included. Title: Re: .1 BTC transaction pending with 48 peers for 36 hours??? Post by: TexasRebel on January 06, 2017, 11:26:06 PM What fee rate are you using? i.e. satoshis per kB https://dl.dropboxusercontent.com/u/66726565/BTC-.1-Transaction%20pending.JPG Title: Re: .1 BTC transaction pending with 48 peers for 36 hours??? Post by: Snub on January 07, 2017, 04:29:58 AM What fee rate are you using? i.e. satoshis per kB https://dl.dropboxusercontent.com/u/66726565/BTC-.1-Transaction%20pending.JPG currently there are still 15MB in size of unconfirmed transction waiting to be included in a block. you paid 20k satoshi as fee but the question is how large is your transaction? can you give us the transaction ID instead so we can see what the problem really is and some users might give you a clear answer about this? |
