Bitcoin Block Size Debate - Talk about what seems must be Done!

[Zeta0S]

In this Topic we can talk about the Block-Size problems and the need to Block size limit controversy.

After seeing my transaction getting slower and slower confirmations, this one is the longest until now!

This i my transaction, from a Echange to my personal wallet after 18 hours 44 minutes still no confirmations.
https://www.blocktrail.com/BTC/tx/30281123d298170702a38fc1fda1a8f034d85aaefd89102f1af7a820c9561b01
Senders fee: Fee / KB    0.00035537 BTC  So sending out 0.343 BTC is not cheap!

Let`s Increase the Block Size!

[MicroGuy]

In order for Bitcoin to remain strong and healthy the main chain must be kept unthrottled. It's okay if we develop off-chain solutions like Lightning, but they should "supplement and relieve" traffic not be a substitute for on-chain capacity.

As these technologies are tested and developed, the main chain will naturally get relief. But the main chain should always have ample capacity for those that wish to use it. So my advice would be to hard fork in 2MB blocks. This would buy us a little more time to further test and study emerging off-chain solutions.

[Kprawn]

This whole debacle will chase merchants away. We have already seen some merchants and service providers moving on, like Fiverr. Either that, or

off-chain 3rd parties like Xapo will have to take over, where Bitcoin failed. This situation is really unhealthy for Bitcoin going forward, and forcing

people with "spam" attacks like this to move to SegWit / LN is under-handed and sick. Satoshi would have never allowed this to happen. 

[DooMAD]

The problem is, one side don't want a blocksize increase before SegWit and the other side believes once SegWit is in, the blocksize increase won't materialise.  If the deadlock isn't broken one way or the other, we should do the obvious thing and just implement both ideas at once.  That should, in theory at least, get enough support to activate successfully.

[loserkids]

So my advice would be to hard fork in 2MB blocks. This would buy us a little more time to further test and study emerging off-chain solutions.

You're saying it as it was as easy as pushing the button. From what we can see it's not even possible to soft fork. Hard forks are totally out of question. The market doesn't want it and we may be stuck with 1MB blocks forever.

[Zeta0S]

So my advice would be to hard fork in 2MB blocks. This would buy us a little more time to further test and study emerging off-chain solutions.

You're saying it as it was as easy as pushing the button. From what we can see it's not even possible to soft fork. Hard forks are totally out of question. The market doesn't want it and we may be stuck with 1MB blocks forever.

This waiting a day for one confirmation is also not ideal, What els is possible?

[Kprawn]

So my advice would be to hard fork in 2MB blocks. This would buy us a little more time to further test and study emerging off-chain solutions.

You're saying it as it was as easy as pushing the button. From what we can see it's not even possible to soft fork. Hard forks are totally out of question. The market doesn't want it and we may be stuck with 1MB blocks forever.

This waiting a day for one confirmation is also not ideal, What els is possible?

Well, I wanted to say... going off-chain with wallets like Xapo, but you will be caught in these "back logs" when you want to withdraw

from Xapo, so not even that would solve the problem. The only way forward will be for one of the sides to give in and to allow for one

of the implementations to go through. I just hate that the issue is being forced with spam attacks like this. 

[franky1]

So my advice would be to hard fork in 2MB blocks. This would buy us a little more time to further test and study emerging off-chain solutions.

You're saying it as it was as easy as pushing the button. From what we can see it's not even possible to soft fork. Hard forks are totally out of question. The market doesn't want it and we may be stuck with 1MB blocks forever.

firstly you need to learn the difference betweent soft and hard. and the the subcategories of each.
many people talk about the best case scenario of a soft. but the worse case of a hard.. but they avoid talking about best case of hard when yapping about soft.. and avoid talking about worse case of soft when yapping about hard.

so here it is

softfork: consensus - >94% pools no banning of minority. result: small 5% orphan drama then one chain. minority unsynced and dead
softfork: controversial - >50% pools no banning of minority. result: long big% orphan drama then one chain. minority unsynced and dead
softfork: bilateral - intentionally ignoring/banning opposing rules and not including them. result: 2 chains

hardfork: consensus - >94% nodes, then >94% pools no banning of minority. result: 5% orphan drama then one chain. minority unsynced / dead
hardfork: controversial - >50% nodes, then >50% pools no banning of minority. result: big% orphan drama then one chain. minority unsynced / dead
hardfork: bilateral - intentionally ignoring/banning opposing rules and not including them. result: 2 chains

ultimately the only difference is do you let the nodes get to vote first(hard), or just the pools(soft)

now that is explained.. rationally the community want the consensus.. and to ensure it works without issue hard is more secure.. the only issue with hard is that its a double vote, which takes time.
yep core hoped to get it activated by christmas by going soft. but they didnt factor in that pools wont jump at something without being sure that the network can take it.

so concentrating on the consensus, remember this.

if pools are not sure that nodes can handle a change, then pools will be unsure to show desire for it..
this is where soft consensus failed. because while the nodes dont actually vote.. pools still for pools own confidence and reassusance privately look at the node count, before deciding.. and with only a 50% node count.. only 25% of pools have show desire for segwit..

now if it was hard (node vote first, then pool vote second) the nodes have to reach target before pools even need to decide.. so that would actually give pools the confidence much faster.

P.S dont meander the topic into the doomsday of bilateral(altcoin creation).. no sane person has proposed a change that is bilateral. apart from a particular core dev who has demanded non core devs to bilaterally split off,to which they refused. so no need to even try shouting the doomsdays of bilateral (altcoin creation)

[MicroGuy]

So my advice would be to hard fork in 2MB blocks. This would buy us a little more time to further test and study emerging off-chain solutions.

You're saying it as it was as easy as pushing the button. From what we can see it's not even possible to soft fork. Hard forks are totally out of question. The market doesn't want it and we may be stuck with 1MB blocks forever.

Hard forks should never be "out of the question." They are needed for the currency to grow, to adapt, and to evolve.

[Killerpotleaf]

BU can solve the problem, but as long as people still fooled by FUD or don't understand BU at all, BU can't be activated. If we force BU while less than 95% miners or node operators, blockchain could split into 2, community could divided, panic sell and bad reputation for bitcoin.
Off-chain solution such as LN could fix the problem, but i think it's not the best solution since LN has some risks and i think bitcoin could be "centralized" if users/services become dependent with LN.

So, i think all miners and node operators must accept BU or tx fee keep rising and condition will be worse over time

[franky1]

BU can solve the problem, but as long as people still fooled by FUD or don't understand BU at all, BU can't be activated. If we force BU while less than 95% miners or node operators, blockchain could split into 2, community could divided, panic sell and bad reputation for bitcoin.

no.. under 95% of nodes just increases the orphan risk. which eventually sorts itself out.. the lower the % the longer and more headache the orphan drama persists. until one chain is ahead leaving minority nodes unable to sync

only an intentional split. (banning the opposing side) which then avoids each side from seeing the blocks to see the orphans. is what causes 2 permanent chains alternate. by avoiding using consensus

Off-chain solution such as LN could fix the problem, but i think it's not the best solution since LN has some risks and i think bitcoin could be "centralized" if users/services become dependent with LN.

So, i think all miners and node operators must accept BU or tx fee keep rising and condition will be worse over time

agreed that LN will cause issues if that is the only end goal core devs want to aim for. LN should only be treated as a voluntary side service.. not the end solution

[BitcoinBarrel]

Oh wahhh....

The transactions are instant, but it sometimes takes hours to confirm? So WHAT?!

Just like your bank, the transaction posts about instant, but takes 3 DAYS to confirm. No one complains about that....

We should leave the Bitcoin protocol the way it is. Let Alt-coins take the place of instant transactions and micro payments.

[franky1]

Oh wahhh....

The transactions are instant, but it sometimes takes hours to confirm? So WHAT?!

Just like your bank, the transaction posts about instant, but takes 3 DAYS to confirm. No one complains about that....

We should leave the Bitcoin protocol the way it is. Let Alt-coins take the place of instant transactions and micro payments.

learn about RBF double spends
learn about tx drop offs.

no one should trust a zero confirm tx

learn about CSV chargebacks
learn about orphans

no one should trust a immature confirmed tx

only if you are spending a small amount should you risk accepting a tx 'as paid' as soon as seen.. but the tx fee has priced small purchases out. so the risk exists because we cant spend micro amounts to not care about risks

[deadsilent]

Thats a big problem. So whats the solution? Is lightning network is the only solution for this? But as far i know lightning network is centralise system. Am i right? Segwit is not even close to 50% of votes. I dont think it will happen. So what now? Is there any solution for this?  If segwit will never happen. What will happen to bitcoin?

[defconone]

Oh wahhh....

The transactions are instant, but it sometimes takes hours to confirm? So WHAT?!

Just like your bank, the transaction posts about instant, but takes 3 DAYS to confirm. No one complains about that....

We should leave the Bitcoin protocol the way it is. Let Alt-coins take the place of instant transactions and micro payments.

Is this guy retarded?

[Zeta0S]

Oh wahhh....

The transactions are instant, but it sometimes takes hours to confirm? So WHAT?!

Just like your bank, the transaction posts about instant, but takes 3 DAYS to confirm. No one complains about that....

We should leave the Bitcoin protocol the way it is. Let Alt-coins take the place of instant transactions and micro payments.

Is this guy retarded?

Hey Buddy how are you? Long time no see! When is your next btc fest?

About your post, You can not say retarded , even if there forum post is a bit strange.
Please do not, or this topic can be closed.

Ontopic, the media is getting in to this!
https://www.cryptocoinsnews.com/bitcoin-slows-crawl-transactions-backlog-reaches-quarter-billion-dollars/

[franky1]

Thats a big problem. So whats the solution? Is lightning network is the only solution for this? But as far i know lightning network is centralise system. Am i right? Segwit is not even close to 50% of votes. I dont think it will happen. So what now? Is there any solution for this?  If segwit will never happen. What will happen to bitcoin?

increasing the blocksize in a natural pace, as a dynamic scaled approach where nodes set their limit and consensus forms what the next rise gets to based on what the nodes allow.

no harm can be done if using consensus.
nodes already exist on the networl for the last couple years with their settings at 2-8mb and nothing has gone wrong.. because the blocksize rule is for anything below X.... meaning even 1mb is acceptable.

pools will only move forward making blocks any larger than 1mb when pools see their is no risk of their attempts getting orphaned. so they are not going to be foolish and do something controversial/bilateral.

forget the doom of "gigabyte blocks by midnight" and "servers". because nodes will set the max capacity.

this can be done by nodes doing a 'speed test' that sets a score. or users manually setting the limit. and that score/limit is then inserted as part of the user agent or a few bytes as part of users tx's. so that the network can see whats in majority accepted

there are many many ways to get nodes to know whats acceptable.. the important part is it being consensus.. not bilateral

[BillyBobZorton]

We need segwit first as adviced by everyone worth listening to in the field.

After segwit is activated, then we can raise the blocksize in a safer way.

We should also focus on LN since its the only way to scale globally.

In other words, you can thank the miners that keep blocking segwit for the lack of any major movement in the capacity increases. If it went as it should, we should already have segwit with smoother transactions and the 2MB blocksize increase planned as intended in the Core roadmap, then once we have LN there will be no complains about transactions taking too long anymore.

[franky1]

We need segwit first as adviced by everyone worth listening to in the field.

After segwit is activated, then we can raise the blocksize in a safer way.

We should also focus on LN since its the only way to scale globally.

In other words, you can thank the miners that keep blocking segwit for the lack of any major movement in the capacity increases. If it went as it should, we should already have segwit with smoother transactions and the 2MB blocksize increase planned as intended in the Core roadmap, then once we have LN there will be no complains about transactions taking too long anymore.

dont be foolish..

you can thank the devs..
they decided to make the miners accountable by violating consensus and not giving nodes a vote.. no sane and smart pool is going to change something without having the network as a whole ready to accept it first.

devs chose to make the pools the decision makers so that devs can take the glory if it happened quickly but shift the blame to the pools if it didnt happen quickly.. (standard political point the finger gaming when things go wrong.)

nodes should have had a vote first.. to then give pools confidence there wont be any large orphan risk. thats just rational logical common sense.

secondly.. LN has a niche, but is not the end solution for all users.. try researching further
its also not the open permissionless zero barrier of entry bitcoin ethos either.. hope you enjoy your research