I have the fee set to 0.009BTC/kB in Electrum. I could be wrong, but I'm pretty sure that's a good amount.
Yes this is good enough for now, but this queue size seems unusual enough to me... |
|
|
|
|
Besides the speculation going on here, do you have any clue about the basis used for the mining maintenance fees?
It's quite obscure to know if there is any chance of ROI after the halving...
Thanks!
|
|
|
|
Euh je vois pas en quoi le cours explose là? il monte pas du tout, il oscille entre baisse et remonter "normal", il dépasse meme plus 620E
Pardon? "Il monte pas du tout" ? Hé faut dézoomer un peu, tu crois pas?  |
|
|
|
Thanks. how can you tell how many bytes? I see it says this one was 668. How do u know before u send. I am learning lol
Are you using Multibit Classic or Multibit HD? These 2 are completely different programs actually... Basically you need to know about the inputs (and outputs, but obviously, that, you do) of your tx |
|
|
|
|
Currently I would say ~80 satoshi / byte (0.0008BTC / KB) is required for reasonable delay (i.e. next block or the one after)
|
|
|
|
|
Yes, very bad timing with the "low" fee here (it used to be not that low, a while ago...)
|
|
|
|
Matt, I tried this before, but, I'll try again. It looks to me that your chart does not include 50 sat/byte in the >= 50 sat/byte group. I think it is 51 sat/byte and over. (comparing to bitcoinfees21) Could you double check for me? Thanks  ps. don't think the bug is fixed! I have checked bitcoinfees.21.co and upon first look, the >=50 s/B group should (now) be correct on the charts, i.e. the teal colored area in the chart, currently about 8k out of about 20k in the queue. Please also note that I had to transition data stream from an older version to a newer version of the process, so data should be more accurate starting about 16:00 UTC (4pm) today Jun 15. BUT at any rate I will be working hard over the next few days to improve accuracy and debug the code Sometimes it hard to keep up with the flow without switching to more expensive, multi-core server instances. Thanks for your feedback, I will post updates here |
|
|
|
The Bitcoin blockchain is currently overloaded and it takes much longer than normal for transactions to confirm. See BitcoinQueue.com or this topic for more discussion on the subject. You may use higher fees for higher priority transactions in the meantime...  |
|
|
|
700 is coming back this week for sure. Hey guys, it's summer again, so just smile  |
|
|
|
UPDATEThere was a bug in the presentation of the stacked charts, where the cumulative values were used for each series instead of the correct data. The bug has been fixed and all graphs are now correct. Unfortunately, matts chart here is too vague to be able to judge how much fee to pay.
Yes, but there is a much better transaction fee breakdown view coming up
|
|
|
|
For me , I think the confirmations are not really getting faster, it's on the opposite side as for me Because before, everytime I transfer .01BTC it only took 2 to 10 min before my transactions are confirmed by the blockchain but it when I transferred a while ago it took more than an hour. Well I guess there are a lot of factors to consider in measuring the time before our transactions were confirmed.
Yes, it's highly variable and dependant on the size of the tx queue. That was the motivation behind BitcoinQueue.com, so we can understand the fee price market and confirmation time implications. |
|
|
|
Nice website did not know before how to calculate the fees for each transaction. Normally I use XAPO and there you don't need to fill in any transaction amount. Will save this website could be really handy in the future.
Thanks, it's an early beta version and I'm working on a more real-time, better interface in the future. I also want to increase the expiry time from 8 hours to 72 hours to match the default mempoolexpiry. Your transaction has enough fees: 4460 satoshi / 223 bytes = 20 satoshi / byte, but the queue is overloaded as you can see on the site |
|
|
|
When the price rises the network gets congested because everyone decides to send coins to exchanges.
You need to age your coins, or only pick the oldest inputs to make up your output, otherwise you will be low priority.
Yes, although aging coins car be difficult especially for newcomers buying from exchanges. The stats show that it's still efficient to raise the fees to 50+ sat/B in order to "bypass" the queue to some extent, but this extra fee burden is probably not wanted in the long run, although this amount to politics in the end. |
|
|
|
More people experience some delay in transaction processing today. The speed also depend on the amount of fees you paid for your transaction. Post your tx and people can take a look into it and possible help you out. In another treat there was also an discussion about it: https://bitcointalk.org/index.php?topic=1511984.0See this thread for an explanation about the block chain jams...  |
|
|
|
See this thread for an explanation about the block chain jams... |
|
|
|
|
The 1MB block limit under the current (v4) protocol is clearly showing its limits right now...
|
|
|
|
Disons que le scénario catastrophe devient de moins en moins crédible....  |
|
|
|
Matt,
The 50 sat/byte is mixed with the "over 10 sat/byte"?
That makes 50 sat/byte look a bit spammy.
And it means it does not show what I am talking to Lauda about.
Would it be better 50 sat/bite and over (not 51 as now?)
10 - 49 sat/byte
It's a stacked chart, meaning you can either read partitions or total. I have arbitrarily chosen to make fee groups like this: (1) 50 satoshi / byte or greater,(2) 10 satoshi / byte or greater, (3) all transactions Obviously (2) contains (1), and (3) contains both (1) and (2). But you can easily use the difference to figure out the number of transactions / queue size with less than 10 satoshi / byte, over 50 satoshi / byte, between 10 and 50, etc. That is my point really. Is it, "50 satoshi / byte or greater," or "over 50 satoshi / byte" Big difference. (take this to your thread if you like) It means exactly this: Class 1: any transaction in the pool Class 2: tx with fee >= 10 satoshi / byte Class 3: tx with fee >= 50 satoshi / byte (Class 1 - Class 2) = tx with fee less than 10 satoshi / byte (Class 2 - Class 3) = tx with between 10 and 50 satoshi / byte Currently there is an explosion both in size and number of transactions in the queue. |
|
|
|
Toujours possible mais je ne pense pas que cela provoquerait le même crash et une pause de 2 ans.
Tout à fait d'accord, même si on retrouve un excès d'optimise dans le marché actuel, on a débranché Willy |
|
|
|
Planning to hold the btc i have until halving.
+1 Somehow, the Chinese have managed to force the double-me-up option upon the halving. |
|
|
|
|
Show Posts
