Unconfirmed Transactions Problem

[20kevin20]

Just got a confirmation after 16 hours and i feel lucky, lol

You have to be careful with the fees. I have spent 0.05 in only 20 transactions on fees which is a huge loss and I didn't even notice. Now I am very careful about it and I set 0.0001BTC for every transaction I do. They are usually confirmed in max 1 day.

[Carlton Banks]

Either way, it seems to me that it is currently too easy for the network to get overwhelmed. We need a quicker solution than SegWit.

What's your proposal?

[dothebeats]

Just got a confirmation after 16 hours and i feel lucky, lol

2 days and I'm still here, waiting for just a single confirmation, currently figuring out how to do a double spend in an android wallet. Maybe I won't bother for days or weeks, not sure how long but one thing's for certain: I would not trust dynamic fee setting of the android wallet ever again.

[Doamader]

I had requested a withdraw from yesterday and today i waked up and my transaction, with tiny bitcoin and a fee of 20k satoshi has arrived already, soo i do believe the big issue has been clear already yesterday there were 70k transactions today there is just 20k transactions i do hope now all the transactions get confirmed as  before.

[Scott J]

Either way, it seems to me that it is currently too easy for the network to get overwhelmed. We need a quicker solution than SegWit.

What's your proposal?

In the short-term, a modest increase in the block size.

Then we can see if SegWit/Lightning can be deployed soon enough for adoption not to be hurt due to lack of scalability.

Edit: Just for clarity, I'll add that I don't believe SegWit alone to be enough.

[Hugroll]

This site can be helpful to you all https://bitcoinfees.21.co/. "predicting bitcoin fees for transactions."

Hmm that site is pretty interesting. I usually go with 0.1$ fees and my transactions confirm within 20 min but site is suggesting almost double that fee for a fast transaction.

[Omegasun]

Just got a confirmation after 16 hours and i feel lucky, lol

2 days and I'm still here, waiting for just a single confirmation, currently figuring out how to do a double spend in an android wallet. Maybe I won't bother for days or weeks, not sure how long but one thing's for certain: I would not trust dynamic fee setting of the android wallet ever again.

Dude. Try to send again another btc to the same address even it is just a small fee. This method works on me. I received immediately my funds stuck for 1 day when i send again few btc on my wallet. I hope it works on your case too.

[Carlton Banks]

Either way, it seems to me that it is currently too easy for the network to get overwhelmed. We need a quicker solution than SegWit.

What's your proposal?

In the short-term, a modest increase in the block size.

Then we can see if SegWit/Lightning can be deployed soon enough for adoption not to be hurt due to lack of scalability.

Edit: Just for clarity, I'll add that I don't believe SegWit alone to be enough.

Unfortunately, your beliefs do not correspond to reality.


Segwit puts a stop to 3rd parties malforming transactions. That means that 2nd layer solutions become possible, where now, they're not. Scaling on the first layer is not going to happen, it simply isn't possible.

The way to handle the 1st layer is to choose a blocksize that represents a compromise between number of network nodes and transaction rate. We're there, right now.



Nodes are at a local low point.

Transactions are at an all time high point.


That means 1st layer is exhausted, and that any attempts to use the 1st layer to increase the transaction rate can only end in the number of Bitcoin nodes decreasing. Have you not researched any of this stuff?

[skierchewing]

Blocks are probably full due to the price increase. That move surprised all the ant colony and now everyone is rushing !

[Red-Apple]

To be honest , it is starting to become annoying. each day fees change and it becomes more competitive to get a high priority so you have to pay more fees and yet there are still a huge number of unconfirmed transactions waiting to be confirmed!

[jeraldskie11]

I had seen forum yesterday like this topic. Don't worry about your transaction problem they will not scammed your Bitcoin.
The reason why its still unconfirmed because maybe have a trouble. But they said that why still unconfirmed because; first, millions of people had registered that wallet so you could expect that in every seconds or minutes many are doing transaction, it's also because your wallet is for worldwide. If they seen your transaction it will be processing for success. So that don't worry, they will fix it. For more information just click here—https://blockchain.info/wallet/bitcoin-faq

[wahb]

that is one of the most big problem of bitcoin, last night i wanted to recharge my mobile but it take a lot of time it really disturb me and i receive the balance on next day.

[Looarn]

I think it's not the aim of bitcoin to be instant payment method.

Low fee, maybe.
Decentralized for sure.

[hv_]

To be honest , it is starting to become annoying. each day fees change and it becomes more competitive to get a high priority so you have to pay more fees and yet there are still a huge number of unconfirmed transactions waiting to be confirmed!

Thas just the predicted fee squeeze to kick out low budget usr as spammers and yes we ve been warned about a year ago....

[Scott J]

Either way, it seems to me that it is currently too easy for the network to get overwhelmed. We need a quicker solution than SegWit.

What's your proposal?

In the short-term, a modest increase in the block size.

Then we can see if SegWit/Lightning can be deployed soon enough for adoption not to be hurt due to lack of scalability.

Edit: Just for clarity, I'll add that I don't believe SegWit alone to be enough.

Unfortunately, your beliefs do not correspond to reality.


Segwit puts a stop to 3rd parties malforming transactions. That means that 2nd layer solutions become possible, where now, they're not. Scaling on the first layer is not going to happen, it simply isn't possible.

The way to handle the 1st layer is to choose a blocksize that represents a compromise between number of network nodes and transaction rate. We're there, right now.



Nodes are at a local low point.

Transactions are at an all time high point.


That means 1st layer is exhausted, and that any attempts to use the 1st layer to increase the transaction rate can only end in the number of Bitcoin nodes decreasing. Have you not researched any of this stuff?

Thanks for your condescending tone!

I believe the risk of not increasing the blocksize modestly (congestion) is greater than the risk of node count lowering (centralisation).

Do you believe 1MB is exactly right? If layer one is really that exhausted then surely we should lower it? I find it funny how so many people say we should not increase, but so few say we should decrease. 1MB was arbitrarily chosen after all.

Right now I see full blocks as a bigger problem than the number of nodes. 2MB or even 4MB gives us enough time for Lightning to be ready.

[Chronobank]

Wow lots of unconfimed transactions, relax they will confirm somehow...this is good ....indicates world are using bitcoin...

Someday, any time, somewhere

Blocks are probably full due to the price increase. That move surprised all the ant colony and now everyone is rushing !

What if behind it is hidden a direct correlation? Price increases, but the majority can not sell because of the fact that they can not move their coins to sell it? So let's say only those who controls all of this can skim the cream...

[Carlton Banks]

Thanks for your condescending tone!

Please don't clutter up the thread with huge quotes. I hope that meets your expectations on netiquette.

I believe the risk of not increasing the blocksize modestly (congestion) is greater than the risk of node count lowering (centralisation).

Do you believe 1MB is exactly right? If layer one is really that exhausted then surely we should lower it? I find it funny how so many people say we should not increase, but so few say we should decrease. 1MB was arbitrarily chosen after all.

Right now I see full blocks as a bigger problem than the number of nodes. 2MB or even 4MB gives us enough time for Lightning to be ready.

Well, 2MB or 4MB is exactly what the new soft fork in 13.1 is delivering. It's got more support than any of the other forks that weren't adopted, and makes Lightning possible. Without getting rid of sig malforming, Lightning doesn't work.

[Scott J]

Well, 2MB or 4MB is exactly what the new soft fork in 13.1 is delivering. It's got more support than any of the other forks that weren't adopted, and makes Lightning possible. Without getting rid of sig malforming, Lightning doesn't work.

Only for transaction that meet the SegWit format - we will see how much of a saving it really is if it gets adopted.

[Carlton Banks]

Explain, given how it satisfies all your stated expectations, why Segwit shouldn't get adopted. You're sounding a little negative, Scott.

[Scott J]

Explain, given how it satisfies all your stated expectations, why Segwit shouldn't get adopted. You're sounding a little negative, Scott.

Have another read, where did I say it shouldn't be adopted?