Blocks are full. - page 15. | Bitcointalksearch.org

BitUsher

legendary

Activity: 994

Merit: 1035

Quote from: jonald_fyookball on January 22, 2016, 02:56:44 PM

It is easy to say "nothing should be done without consensus"
if you're one of the parties holding up the consensus which
is exactly what core has been doing.

My position is quite the opposite in that I support the right of other implementations to openly fork the code and try and take over governance. Individuals without consensus should have this right, they should also be free to choose not to upgrade thus indirectly causing a fork, or choose to cooperate and submit BIPs or leave.

The only reason the 95% of last mined blocks is mentioned is because we understand that it is not really measuring the vote of the people, nodes or economic majority but a less accurate indirect approximation of such a measurement by miners. Bitcoin classic should have the right to fork at 51% or 75% .... these are all arbitrary numbers... but since they are indirect approximations , the lower the number the greater a chance there will be two competing coins. This isn't a threat but a reality. In the short term it would be chaotic , messy , and both sides would certainly lose a lot of value/or one side dying off ... this isn't completely bad , but can create PR problems with investor confidence.

jonald_fyookball

legendary

Activity: 1302

Merit: 1008

Core dev leaves me neg feedback #abuse #political

Quote from: Lauda on January 22, 2016, 02:24:01 PM

Quote from: jonald_fyookball on January 22, 2016, 08:49:34 AM

Right. Hence the "nothing is better than something".
You're saying you'd rather do nothing (and wait for segwit, etc).

I say something is definitely better than nothing,
even if it does nothing else than promote unity
in the community.

Wrong. You obviously lack the understanding in the soft fork vs hard fork case. Essentially a proper hard fork needs time to be deployed. Rushing it can be very damaging to the ecosystem. Currently in both Classic and Core what you're doing is waiting. You're waiting for the code and then you're waiting for consensus and deployment. In both 'nothing' is wrong as 'something' is being done.

Quote from: gkv9 on January 22, 2016, 01:55:15 PM

So, does it mean that even if the block size gets upgraded with the hard fork, the transactions will still get confirmed in the same time as proposed by Satoshi, i.e.; 10 minutes or will the blocks take longer based on being bigger in capacity???

Confirmation time has nothing to do with the capacity. Blocks generation rate will remain the same (i.e. confirmations should take ~10 minutes).

I'm aware that hard forks need more preparation.

It is easy to say "nothing should be done without consensus"
if you're one of the parties holding up the consensus which
is exactly what core has been doing.

Lauda

legendary

Activity: 2674

Merit: 2965

Terminated.

Quote from: jonald_fyookball on January 22, 2016, 08:49:34 AM

Right. Hence the "nothing is better than something".
You're saying you'd rather do nothing (and wait for segwit, etc).

I say something is definitely better than nothing,
even if it does nothing else than promote unity
in the community.

Wrong. You obviously lack the understanding in the soft fork vs hard fork case. Essentially a proper hard fork needs time to be deployed. Rushing it can be very damaging to the ecosystem. Currently in both Classic and Core what you're doing is waiting. You're waiting for the code and then you're waiting for consensus and deployment. In both 'nothing' is wrong as 'something' is being done.

Quote from: gkv9 on January 22, 2016, 01:55:15 PM

So, does it mean that even if the block size gets upgraded with the hard fork, the transactions will still get confirmed in the same time as proposed by Satoshi, i.e.; 10 minutes or will the blocks take longer based on being bigger in capacity???

Confirmation time has nothing to do with the capacity. Blocks generation rate will remain the same (i.e. confirmations should take ~10 minutes).

gkv9

legendary

Activity: 1246

Merit: 1000

!!! RiSe aBovE ThE StoRm !!!

Quote from: jonald_fyookball on January 22, 2016, 08:49:34 AM

Quote from: Lauda on January 22, 2016, 08:39:49 AM

All it does is kick the can a little bit down the road.

Right. Hence the "nothing is better than something".
You're saying you'd rather do nothing (and wait for segwit, etc).

I say something is definitely better than nothing,
even if it does nothing else than promote unity
in the community.

Dissension is stirring because nothing has been implemented.
I guess core is cool with that. they've "got everything under
control"...right?

So, does it mean that even if the block size gets upgraded with the hard fork, the transactions will still get confirmed in the same time as proposed by Satoshi, i.e.; 10 minutes or will the blocks take longer based on being bigger in capacity???

jonald_fyookball

legendary

Activity: 1302

Merit: 1008

Core dev leaves me neg feedback #abuse #political

Quote from: Lauda on January 22, 2016, 08:39:49 AM

All it does is kick the can a little bit down the road.

Right. Hence the "nothing is better than something".
You're saying you'd rather do nothing (and wait for segwit, etc).

I say something is definitely better than nothing,
even if it does nothing else than promote unity
in the community.

Dissension is stirring because nothing has been implemented.
I guess core is cool with that. they've "got everything under
control"...right?

Lauda

legendary

Activity: 2674

Merit: 2965

Terminated.

Quote from: jonald_fyookball on January 22, 2016, 08:32:48 AM

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.

Quote from: jonald_fyookball on January 22, 2016, 08:32:48 AM

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.

jonald_fyookball

legendary

Activity: 1302

Merit: 1008

Core dev leaves me neg feedback #abuse #political

Quote from: Lauda on January 22, 2016, 01:41:27 AM

Quote from: jonald_fyookball on January 22, 2016, 12:39:05 AM

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. Roll Eyes

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.

Roll Eyes

Lauda

legendary

Activity: 2674

Merit: 2965

Terminated.

Quote from: DimensionZ on January 22, 2016, 08:13:20 AM

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.

DimensionZ

sr. member

Activity: 350

Merit: 251

Shit, did I leave the stove on?

Quote from: Lauda on January 22, 2016, 05:10:31 AM

Quote from: Matias on January 22, 2016, 04:49:27 AM

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.

Quote from: SuperCoinGuy on January 22, 2016, 04:54:07 AM

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

It is not if you include the right fee.

Quote from: crazyivan on January 22, 2016, 04:55:58 AM

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.

lottery248

legendary

Activity: 1582

Merit: 1006

beware of your keys.

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.

Amph

legendary

Activity: 3248

Merit: 1070

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

BitUsher

legendary

Activity: 994

Merit: 1035

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.

Quote from: Lauda on January 22, 2016, 01:41:27 AM

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+

Lauda

legendary

Activity: 2674

Merit: 2965

Terminated.

Quote from: Matias on January 22, 2016, 04:49:27 AM

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.

Quote from: SuperCoinGuy on January 22, 2016, 04:54:07 AM

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

It is not if you include the right fee.

Quote from: crazyivan on January 22, 2016, 04:55:58 AM

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.

crazyivan

legendary

Activity: 1652

Merit: 1007

DMD Diamond Making Money 4+ years! Join us!

Quote from: bitcoin carpenter on January 20, 2016, 10:20:48 AM

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?

SuperCoinGuy

full member

Activity: 224

Merit: 100

Defender of Bitcoin

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

Matias

full member

Activity: 182

Merit: 101

Quote from: Lauda on January 22, 2016, 01:41:27 AM

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?

Matias

full member

Activity: 182

Merit: 101

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=

Zarathustra

legendary

Activity: 1162

Merit: 1004

Quote from: jonald_fyookball on January 22, 2016, 12:39:05 AM

Quote from: Lauda on January 21, 2016, 09:48:04 AM

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.

Karartma1

legendary

Activity: 2310

Merit: 1422

Quote from: SebastianJu on January 21, 2016, 06:44:31 PM

Quote from: Karartma1 on January 21, 2016, 03:24:26 AM

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.

Lauda

legendary

Activity: 2674

Merit: 2965

Terminated.

Quote from: jonald_fyookball on January 22, 2016, 12:39:05 AM

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. Roll Eyes

I 'don't seem to always support them'. Do I support them in 'Core vs Classic', 'SegWit vs 2 MB blocks'? Yes.

Topic: Blocks are full. - page 15. (Read 14985 times)