Topic: Bitcoin network jammed? (Read 536 times)

You should give transaction fees or commission transactions that match the current market price, when you try to reduce the value of transaction costs, what you get is difficulty getting confirmation quickly. actually this concept is similar to the shipping courier, when you want your bitcoin assets to be sent quickly then you have to give more money to it.

You can't think strangely about transactions, there are now so many bitcoin users around the world, many of which even make transactions with the various businesses they run, so if you make a transaction that is problematic or fails in a transaction, you have to wait.
Because each country has a different network quality. And the network they use is certainly not comparable to what we have

yes yesterday I experienced the same thing sending btc but still had zero confirmation for 6 hours, is this a blockchain system upgrade?

I sent my bitcoin from wallet (blockchain.info) to exchange. The wallet has a "fixed" transaction cost - it cannot be changed. Probably they just needed to readjust the transaction fees to the network.

Bitcoin in such development stage will be overthrown. It sucks as a payment medium. Maybe only as a value holder as it has a fixed supply in the future (like gold).

Did you sending your bitcoin using the exchange or your own wallet with the blockchain database?
If you sent btc from your desktop personal wallet, i think there are something wrong in your blockchain database.
But if you sent your btc from exchange wallet or 3rd party wallet, you need to contact the developers of the wallet.

The decrease in the bandwidth of the Bitcoin network in early December 2018 is most likely due to the shutdown of equipment by many miners due to a decrease in profit. This is a temporary phenomenon, because the complexity of mining Bitcoin adapts to the overall hashrate of the network and decreases over time. The transaction will not disappear anywhere, and sooner or later it will be included in the blockchain.

No one is forcing anyone to use Core software. If you doni't like how Core software guesstimates the best recommended fee, then you can use any other software, or you can go on and code your own node software.

Blaming Core because "they don't raise the blocksize" is delusional and a waste of time. Even if Core said yes:

1) There would be a lot of people in Core that wouldn't agree because there are too many people now
2) There would be other people with skin in the game that wouldn't agree that aren't part of Core

You need unanimous agreement otherwise you get 2 chains again and more nonsense (see the Bcash ABC vs BCash Craig insanity)

I acknowledge that. Lightning is a different protocol made to be interoperable with Bitcoin. Same with sidechains. They have different security models and different trade-offs. I see that as a good thing. I don't see why every payment needs to be published on the blockchain, or why every payment needs Bitcoin's security guarantees.


Why don't you explain it then?

look passed the usual "must defend a dev" mindset.
it gets soo funny when people revert to defend a certain dev group rather than defend the network

its soo obvious
LN is not a bitcoin feature. it is its own independent network that happens to let multiple coins that are made compatible to function with it. bitcoin being just one

LN is just using bitcoin as the test coin to glory hound some investment.
as for scaling BITCOIN (not finding ways to tether altcoins and altnetworks to bitcoin) but to scale bitcoin can be done easily
and if you think its so linear. then i guess your just reading the standard scripts of "bitcoin is broke LN is the future" promo posters

it reminds me of history
digital photography wont work because floppy disks or servers
digital photography wont work because linear scaling of solid state media

people with that mindset are like kodak at the millenia

I'm using Exodus and never have any problems. It seems to set a correct fee for fast processing.

Check for some problems with regards on your transaction. Drop down the transaction hash for everyone to know and help you in this issue.

Pointing out the scaling limitations of blockchains =  promoting other networks?

In truth, blockchains don't scale well. Adding exponentially more throughput to the mainchain would encourage mining centralization to sidestep latency problems (or otherwise cause high orphan rates and regular unintentional forking) and would discourage full node operation due to bandwidth requirements.

Sharding is one approach to solving this problem. Offchain payment channels are another. Tree chains are another. Why do you think so many people are working on ways to achieve exponential scale? Because blockchains can't do it. They scale linearly, which is extremely limiting. The Core developers have done a great job optimizing for better scale, but there's only so much they can do.

This is the result of the reduction of market mineralization. The market is getting worse than ever before, the miners stop working, the deal not exploited, so the move not done. I think you should increase the transaction fee higher if the transaction is confirmed.

the same developers shouting blockchains cant scale and LN is the future.
i say if a bitcoin dev cant develop bitcoin. then they need to move out of bitcoin contributing and move into LN contributing full time. and to fully stop putting code into bitcoin that is only being added to make bitcoin compatible with alternative networks

bitcoin devs should be bitcoin innovation devs. not alternative network promoters and converters

The bitcoin network is slow these days. One of the many reason could be the low bitcoin price which may not attract the miners and therefore less miners would means more time processing the transactions.

bip9 did not have a august deadline
bip9 would not have caused a controversial split/fork. it would have been an accept or reject. where
if 95% agreed 5% are left receiving stripped data.
if there wasnt an agreement, things just carry on under 2016's ruleset
in short
bip 9 would have meant core devs would have had to put their tail between their legs, and gone back to the drawing board.

however the other bip. forced a fake vote. where nodes had no choice(compatibility) and pools objecting were just not counted/not included in the vote

the august event was not consensus. but as you twistingly admit. miners under threat of an august event where they would end up thrown out the network unless they comply.
if you think that there was no august event. you might want to do some research
the miners conscious decision was not a free choice it was a gun to the head decision to remain conscious on the network or be made unconscious outside the network

secondly you twistingly avoid the fact that core nodes didnt need to have it in because they pre-programmed their nodes to not even get a vote due to "compatibility". meaning the few nodes that would cause a controversial split would just supply the "compatibles" with stripped block data. meaning no need to put it in core because they already done what was needed so that they can shift the blame, while also still wave their hands in the air they want segwit.

Well, I used a blockchain.info wallet which has transaction fee fixed and predetermined. Not sure how much it was. Maybe they should update their fees, right?

Anyone can suggest a better wallet, maybe?

Its happen to me too. Sometimes i should waiting more than 6 hours before receiving my bitcoin. I dont know about technical problem but it might be because too many transaction in bitcoin network and makes transaction become slower. But hopely in the future, bitcoin transaction become more faster

No, they didn't.

Miners activated Segwit. If miners were "forced" by anything, it was the threat of BIP 148, which was never part of the reference client. Many Core developers were opposed to merging the UASF -- on such a rushed timeline or at all -- and it never was.

Miners made a conscious decision to activate Segwit to prevent a chain split with users enforcing BIP 148. Core nodes would have sided with majority hashpower either way.

they forced segwit......................