Blocks are full.

[BlindMayorBitcorn]

It's the Fullblocalypse!

Panic! Stop! Run away!!










(Ok now come back.)

[1714027315]

1714027315

[1714027315]

1714027315

[1714027315]

1714027315

[SebastianJu]

You guys must be kidding me with this. Bitcoin works perfectly, I just send a transaction through my Core wallet, sent the recommended fee, and I didn't had any problems. Don't be cheap on the fees, and wait until 0.12 comes, and wait for SegWit, we can do this without raising the block size now. In the future maybe if needed, but right now, we have SegWit and we can resist until Lightning Network is operative. We must resist the pressures.

Guess you don't get all the threads and complaints about newbies and established bitcoiners whose fees again were not sufficient. And fees will only rise now.

1mb blocks enable easy spamming too so that makes things worse.

I can't see when a big part of the community became that conservative and fearfull that nothing is allowed to change anymore because "what if".

[jonald_fyookball]

Classic has no roadmap or anything. Even if we disregard the safety risk of 2 MB blocks right now, we would have this same discussion very soon (if the growth is going to increase). There's a proposal that aims to fix the validation time being quadratic; we should wait for that to be implemented.

Lauda, so in addition to the 'quadratic' risk (for which you admit there is a fix but core is not implementing),
you're also giving us the 'nothing is better than something' argument.

Really seems like you're shilling hard for core/blockstream.  Not that I
think they are paying you or anything.  You just have a huge bias
and seem to always support their position and actions.  That's
my OPINION and my impression.  Just saying.

[YoonYeonghwa]

I guess that we need to see frequent backlogs in 30 - 60 MB range for things to start changing.

Exactly. That is the only way that people are going to realise that we need change.

[Cryptology]

I guess that we need to see frequent backlogs in 30 - 60 MB range for things to start changing.

Exactly. That is the only way that people are going to realise that we need change.

Yes. Plus bitcoin's price < $50 and Ethereum's capitalization taking over Bitcoin. We will have "consensus by fear".

[Lauda]

Lauda, so in addition to the 'quadratic' risk (for which you admit there is a fix but core is not implementing),
you're also giving us the 'nothing is better than something' argument.

So let's set the situation straight. We have two proposals:

1. 2MB Block size

• doubles the theoretical tps
• introduces a new attack vector
• Simple change
• Hard fork

2. SegWit

• Fixes transaction malleability
• Fraud proofs
• Simpler script upgrades
• Theoretical tps possibly equal or higher than with 2 MB blocks depending on adoption
• Somewhat complex; decent complexity for inexperienced users
• Soft fork

I'm definitely shilling for Core because obviously SegWit is not far superior to a 'simple' block size increase.   I 'don't seem to always support them'. Do I support them in 'Core vs Classic', 'SegWit vs 2 MB blocks'? Yes.

[Karartma1]

I hear talking like the big guys we are here to defeat: this is not the FED.

If the economy goes wrong then let's give them some QE, then after a while QE2, then QE3 and so forth.

If we start raising the block size it will be like that in a way: tomorrow 2MB, in one week 4MB, you understand the trick.

This is not the $ and never it will be.

If it's needed to bring adoption forward then go ahead. Bitcoin will never succeed when adoption is hindered effectively. Sure there are potential problems, one has to deal with it like it happened all the time. And suddenly an arbitrarely setting becomes a breaking stone.

To me there's one fundamental assumption to make: this coin is made of 21 millions pieces. We can break it into more digits but we will always have 21 mln unless we don't super hard fork it.
Let's not be unrealistic: BTC is not for mass adoption. This is what I wanted to say in regard to my dollar metaphor.
And, look, I'm not saying problems require to be left on their own but more thank a block size, hard fork debate I see different people's opinions having battles.

[Zarathustra]

Classic has no roadmap or anything. Even if we disregard the safety risk of 2 MB blocks right now, we would have this same discussion very soon (if the growth is going to increase). There's a proposal that aims to fix the validation time being quadratic; we should wait for that to be implemented.

Lauda, so in addition to the 'quadratic' risk (for which you admit there is a fix but core is not implementing),
you're also giving us the 'nothing is better than something' argument.

Really seems like you're shilling hard for core/blockstream.  Not that I
think they are paying you or anything.  You just have a huge bias
and seem to always support their position and actions.  That's
my OPINION and my impression.  Just saying.

He is shilling for the Politbüro. He loves censorship and totalitarianism. He tries to sell us a non-consensual monster fork that gives us 1.35MB as a 'short term scaling solution' in the year of the Great Halvening.

[Matias]

If blocks are full, why average transaction confirmation  time doesn't increase?

https://blockchain.info/charts/avg-confirmation-time?timespan=1year&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=

[Matias]

2. SegWit

• Fixes transaction malleability
• Fraud proofs
• Simpler script upgrades
• Theoretical tps possibly equal or higher than with 2 MB blocks depending on adoption
• Somewhat complex; decent complexity for inexperienced users
• Soft fork

What do you mean "Somewhat complex; decent complexity for inexperienced users"? Doesn't average user send bitcoins with segwit exactly the same as before?

[SuperCoinGuy]

How much is the confirmation speed impaired when the blocks are full?

[crazyivan]

It is frustrating how much energy is being wasted.  Just scale the blocksize  already...

This. Bitcoin Classic is an obvious solution which solves this issue for the next two year. Large miners support it.

So WTF is the issue then?

[Lauda]

What do you mean "Somewhat complex; decent complexity for inexperienced users"? Doesn't average user send bitcoins with segwit exactly the same as before?

Complex as in implementation, not the usage. Using Bitcoin will be pretty much the same.

How much is the confirmation speed impaired when the blocks are full?

It is not if you include the right fee.

This. Bitcoin Classic is an obvious solution which solves this issue for the next two year. Large miners support it.

So WTF is the issue then?

1. It is not an 'obvious solution'.
2. It does not solve anything, especially not for 'two years'.
3. They withdrew their support.
4. You wouldn't be asking such questions if you actually spent time reading threads. Two words: Validation time.

[BitUsher]

In fairness to Bitcoin Classic , I do need to clear up some confusion... but I also added some other distinctions which make Core the better choice of the two.

So let's set the situation straight. We have two proposals:

1. 2MB Block size

• doubles the theoretical tps
• introduces a new attack vector(They are aware of this and including sigop protections)
• Simple change(Yet not as simple as changing maxBlockSize, much more code needs to be changes for sigop protections)
• Hard fork(Which is more dangerous)

• Smaller team of less experienced developers maintaining implementation(5 devs , with 2 very experienced)

2. SegWit

• Fixes transaction malleability
• Fraud proofs
• Simpler script upgrades
• Allows for one to prune the signature data and reduce the blockchain size
• Theoretical tps possibly equal or higher than with 2 MB blocks depending on adoption(But likely an effective 1.7MB to 2MB)
• Somewhat complex; decent complexity for inexperienced users to understand(UI and usability won't be effected )
• Soft fork(are indeed safer than HF)
• Has a team of dedicated and experienced developers testing and supporting it -45+

[Amph]

segwit is not 2mb is actually less, 1.75-1.8, still it should suffice for the short term future

bnut in the end they need to increase the capacity directly, this within the halving of 2020 must be done for sure

[lottery248]

this is in order to encourage mining i guess. if less fees, then the miners would not wish to secure the bitcoin, you understand that the cost of mining in bitcoin is too high, and at least $0.3 every GH and at lease 2 cents is gone per GH to pay the electricity, that would be a bit fair.

this would not benefit the transaction, explicitly. that's why i would recommend for 4MB on this.

[DimensionZ]

What do you mean "Somewhat complex; decent complexity for inexperienced users"? Doesn't average user send bitcoins with segwit exactly the same as before?

Complex as in implementation, not the usage. Using Bitcoin will be pretty much the same.

How much is the confirmation speed impaired when the blocks are full?

It is not if you include the right fee.

This. Bitcoin Classic is an obvious solution which solves this issue for the next two year. Large miners support it.

So WTF is the issue then?

1. It is not an 'obvious solution'.
2. It does not solve anything, especially not for 'two years'.
3. They withdrew their support.
4. You wouldn't be asking such questions if you actually spent time reading threads. Two words: Validation time.

Wait so setting the miners fee above the average can move your transactions faster even if there is a backlog? I didn't know that trick.

[Lauda]

Wait so setting the miners fee above the average can move your transactions faster even if there is a backlog? I didn't know that trick.

Of course. The higher the fee, the higher the priority of your transaction. I've never had any problems transacting because I tend to add the highest possible fee with the wallet (Core, using the slider) or add a custom one that is even higher.

[jonald_fyookball]

Lauda, so in addition to the 'quadratic' risk (for which you admit there is a fix but core is not implementing),
you're also giving us the 'nothing is better than something' argument.

So let's set the situation straight. We have two proposals:

1. 2MB Block size

• doubles the theoretical tps
• introduces a new attack vector
• Simple change
• Hard fork

2. SegWit

• Fixes transaction malleability
• Fraud proofs
• Simpler script upgrades
• Theoretical tps possibly equal or higher than with 2 MB blocks depending on adoption
• Somewhat complex; decent complexity for inexperienced users
• Soft fork

I'm definitely shilling for Core because obviously SegWit is not far superior to a 'simple' block size increase.   I 'don't seem to always support them'. Do I support them in 'Core vs Classic', 'SegWit vs 2 MB blocks'? Yes.[/list]

HUH?

if its not far superior then why do it?

Also dont see what that has to do with your comment of "we would have this same discussion very soon if growth is going to increase".

whatevs. 

 

[Lauda]

HUH?
if its not far superior then why do it?

Your sarcasm detector has run out of fuel or has never worked in the first place. One could easily conclude from that list that SegWit is much greater of the both proposals.

Also dont see what that has to do with your comment of "we would have this same discussion very soon if growth is going to increase".

Because 2 MB blocks don't solve anything. All it does is kick the can a little bit down the road.