1 year from now 2MB HF will be proposed will you support it?

[adamstgBit]

assuming classic will fail to gain >75% of miners we will go with Core's roadmap, in which a 2MB HF will be proposed ~1year from now.

will you support this proposal or actively speak out against it? why or why not?

[1714754665]

1714754665

[1714754665]

1714754665

[1714754665]

1714754665

[1714754665]

1714754665

[rizzlarolla]

Can you link me to a Core roadmap that says that please. I've not seen it.

If we have segwit, (big if), will we still need 2mb?
Will the network be able to support segwit and a block size increase?

A year is a long time in politics bitcoin. 

[adamstgBit]

the HK round table, had agreed to put forth a 2MB block limit incress in ~1 year's time
i thought they had added it to their road map.
But Core doesn't seem to have a road map.
we can find clues here and there.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

at some point the capacity increases from the above may not
be enough.  Delivery on relay improvements, segwit fraud proofs, dynamic
block size controls, and other advances in technology will reduce the risk
and therefore controversy around moderate block size increase proposals
(such as 2/4/8 rescaled to respect segwit's increase). Bitcoin will
be able to move forward with these increases when improvements and
understanding render their risks widely acceptable relative to the
risks of not deploying them. In Bitcoin Core we should keep patches
ready to implement them as the need and the will arises, to keep the
basic software engineering from being the limiting factor.

[FUBAR-BDHR]

I don't think bitcoin will survive as we know it today without a hard fork much sooner than that.  Some other coin will take over and bitcoin will become just another altcoin to it.

[adamstgBit]

I don't think bitcoin will survive as we know it today without a hard fork much sooner than that.  Some other coin will take over and bitcoin will become just another altcoin to it.

In the short term segwit should provide enough blockspace so there is minimal fee pressure.
but i agree if bitcoin isn't kept frictionless, if the plan is high fees and complex LN, poeple will gravitate to altcoins.
 

[rizzlarolla]

In the short term segwit should provide enough blockspace so there is minimal fee pressure.
but i agree if bitcoin isn't kept frictionless, if the plan is high fees and complex LN, poeple will gravitate to altcoins.
 

How can there be high fees if segwit doubles the block size that took 6 yrs to fill.
(i dont want high fees, just saying, all this bs by some about todays/tomorrows fees market is needed and wanted and structured)

The maximum size of a block (with segwit) becomes just under 4 MB.

Adam, in your quote it says "(such as 2/4/8 rescaled to respect segwit's increase)."
If segwit is 4 mb, there will be no need/network capacity for block increase will there, if we respect segwit's increase?
(if core supporters REALLY dont want 1.1 mb now, to tide us over, why would they want to increase on 4mb next year?)

[achow101]

the HK round table, had agreed to put forth a 2MB block limit incress in ~1 year's time
i thought they had added it to their road map.
But Core doesn't seem to have a road map.
we can find clues here and there.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

at some point the capacity increases from the above may not
be enough.  Delivery on relay improvements, segwit fraud proofs, dynamic
block size controls, and other advances in technology will reduce the risk
and therefore controversy around moderate block size increase proposals
(such as 2/4/8 rescaled to respect segwit's increase). Bitcoin will
be able to move forward with these increases when improvements and
understanding render their risks widely acceptable relative to the
risks of not deploying them. In Bitcoin Core we should keep patches
ready to implement them as the need and the will arises, to keep the
basic software engineering from being the limiting factor.

They do have a roadmap, right here: https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/.

What was agreed at the HK roundtable was that some core developers would propose and implement the a block size limit increase. However, this isn't guaranteed to make it into Core because it is the proposal of specific people not of the Bitcoin Core developers.

[broseph]

In the short term segwit should provide enough blockspace so there is minimal fee pressure.
but i agree if bitcoin isn't kept frictionless, if the plan is high fees and complex LN, poeple will gravitate to altcoins.
 

How can there be high fees if segwit doubles the block size that took 6 yrs to fill.
(i dont want high fees, just saying, all this bs by some about todays/tomorrows fees market is needed and wanted and structured)

The maximum size of a block (with segwit) becomes just under 4 MB.

Adam, in your quote it says "(such as 2/4/8 rescaled to respect segwit's increase)."
If segwit is 4 mb, there will be no need/network capacity for block increase will there, if we respect segwit's increase?
(if core supporters REALLY dont want 1.1 mb now, to tide us over, why would they want to increase on 4mb next year?)

Fees seem big but if I remember correctly they were higher back a couple of years ago, gonna go look at blockchain stats and edit it in if I find it.

edit: Ok looking at all time chart of transaction fees it seems we aren't paying that much compared to 2013 transactions. Check it:

[danda]

I've read a lot of comments about core supposedly agreeing to a 2Mb increase.  I usually just kind of shrug and smirk.   I'll believe it when I see it.

At the time of the HK consensus my reading of the statement was only that code would be developed by some of the individuals present.  I remember thinking at the time that it fell short of actually saying such code would be accepted into core and widely deployed.   Though I believe many in the community interpreted it that way, and that may have been the intent.

Am I wrong?   Did core truly commit to deploying a 2Mb hardfork, apart from segwit?    source?


So yeah, I don't believe a controversial (consensus breaking) hardfork will ever be widely deployed and accepted.  It's like trying to hardfork ipv4 all at once.   good luck with that.

[adamstgBit]

In the short term segwit should provide enough blockspace so there is minimal fee pressure.
but i agree if bitcoin isn't kept frictionless, if the plan is high fees and complex LN, poeple will gravitate to altcoins.
 

How can there be high fees if segwit doubles the block size that took 6 yrs to fill.
(i dont want high fees, just saying, all this bs by some about todays/tomorrows fees market is needed and wanted and structured)

The maximum size of a block (with segwit) becomes just under 4 MB.

Adam, in your quote it says "(such as 2/4/8 rescaled to respect segwit's increase)."
If segwit is 4 mb, there will be no need/network capacity for block increase will there, if we respect segwit's increase?
(if core supporters REALLY dont want 1.1 mb now, to tide us over, why would they want to increase on 4mb next year?)

segwit's effective capacity incress is confusing as fuck to say the least
4MB is not achievable
in all likelihood we can expect the equivalent of 1.75MB blocks as a result of segwit's effective blocksize incress
TX demand on the network increases exponentially. the first few years there was no where to spend your coins, and there was alot less usages, I would be surprised if we do not quick fill blocks up again with 1.75MB effective blocksize

[rizzlarolla]

In the short term segwit should provide enough blockspace so there is minimal fee pressure.
but i agree if bitcoin isn't kept frictionless, if the plan is high fees and complex LN, poeple will gravitate to altcoins.
 

How can there be high fees if segwit doubles the block size that took 6 yrs to fill.
(i dont want high fees, just saying, all this bs by some about todays/tomorrows fees market is needed and wanted and structured)

The maximum size of a block (with segwit) becomes just under 4 MB.

Adam, in your quote it says "(such as 2/4/8 rescaled to respect segwit's increase)."
If segwit is 4 mb, there will be no need/network capacity for block increase will there, if we respect segwit's increase?
(if core supporters REALLY dont want 1.1 mb now, to tide us over, why would they want to increase on 4mb next year?)

segwit's effective capacity incress is confusing as fuck to say the least
4MB is not achievable
in all likelihood we can expect the equivalent of 1.75MB blocks as a result of segwit's effective blocksize incress
TX demand on the network increases exponentially. the first few years there was no where to spend your coins, and there was alot less usages, I would be surprised if we do not quick fill blocks up again with 1.75MB effective blocksize

It's supposed to be confusing.

No sorry, 4mb of todays tx's are not achievable.
But verifying nodes will have to have a 4mb capacity? (in case everyone uses segwit at the same time)

Thats why Core say "the maximum size of a block becomes just under 4 MB."

[adamstgBit]

[shinratensei_]

that's damn too long, i've got bottleneck in almost in every transaction,i need to wait 30minutes+ just to get confirmed and it's too damn annoying,
bitcoin getting slow and slow,i hope those dev can move faster than snail

[MingLee]

It all depends on if the blocks remain full and if there is no other movement to try and fix that issue.

I will support 2MB blocks in the event that blocks are being capped out and transactions are being delayed because of it. The future of Bitcoin is more important than some circlejerk about how much we have to stick to the existing technology.

[adamstgBit]

that's damn too long, i've got bottleneck in almost in every transaction,i need to wait 30minutes+ just to get confirmed and it's too damn annoying,
bitcoin getting slow and slow,i hope those dev can move faster than snail

have you tired throwing 5 cents in a wishing well? i hear it helps

[Herbert2020]

i don't feel there is any rush for getting a block size increase like right now but also i do believe that there is a need for block size increase as soon as possible and 1 year from now sounds too late to me. and it might hurt bitcoin if it is prolonged.

[franky1]

i don't feel there is any rush for getting a block size increase like right now but also i do believe that there is a need for block size increase as soon as possible and 1 year from now sounds too late to me. and it might hurt uᴉoɔʇᴉq if it is prolonged.

so your the kind of person that lives in a house with no food in the fridge. and you only get what you need for that day, not even thinking of the future.
not preparing yourself for the possibility that one night you might need more food, but cant get to a shop.

if you lived in the victorian era i bet you would love to walk up to Fagen and ask "please sir, can i have some more" every day. instead of not having to worry about your next meal because there is enough available as you need it.

the blocksize is a BUFFER. it increases the POTENTIAL. if does not FORCE bloat. it just allows more growth at a natural pace, without hindrance or arguments.
blockstream is causing contention, meaning they are the cause of a contentious fork by not even being willing to allow an update any sooner.


the bloat argument is now proved nonsense. because blockstreams own roadmap for potential of their 1mb+segwit+confidential payment codes is 2.85mb for just 3800tx BEFORE summer 2017.
and when they finally allow 2mb+segwit+confidential payment codes. they are literally saying that the possibility of full blocks in the future is not an issue at 5.7mb for 7600tx after summer 2017.

so their own roadmap talking about what they think is acceptable debunks their original arguments in regards to the true block limit.
because 2mb block using traditional transaction types= 4000tx for 2mb, which beats the roadmap 1mb+SW+CPC of 2.85mb for 3800tx

meaning if blockstream deem 5.7mb safe after summer 2017..
then 5mb block using traditional transaction types= 10,000tx for 5mb, beats the roadmap 2mb+SW+CPC of 5.7mb for 7600tx

it also makes me laugh that they find 5.7mb acceptable in a year. but want to keep the maxblocksize variable low.. do they even realise the purpose of maxblocksize.. what is the point of code saying maximum size of a block is 2mb if the real data being sent is upto 5.7mb

that like telling your doctor that after the age of 3 you stopped growing past 2foot. and that everyone on the planets medical records needs to show 2 foot or less..
even though the reality is people average 5foot 7.. making medical records a useless tool.

[Kakmakr]

At this stage, <kicking the can down the street> will be a better solutions than just rushing into a hard fork for the sake of doing it to achieve a power grab. If I have to chose between the lesser of two evils, I will chose to go with the Core Road map. Let's gamble on something and see if this decision will be the best one for now. If they fail, we just support the next team. ^smile^

[Maslate]

At this stage, <kicking the can down the street> will be a better solutions than just rushing into a hard fork for the sake of doing it to achieve a power grab. If I have to chose between the lesser of two evils, I will chose to go with the Core Road map. Let's gamble on something and see if this decision will be the best one for now. If they fail, we just support the next team. ^smile^

Hard fork is not a problem as it has happened several times to bitcoin. This happens every day in many altcoins.

[achow101]

At this stage, <kicking the can down the street> will be a better solutions than just rushing into a hard fork for the sake of doing it to achieve a power grab. If I have to chose between the lesser of two evils, I will chose to go with the Core Road map. Let's gamble on something and see if this decision will be the best one for now. If they fail, we just support the next team. ^smile^

Hard fork is not a problem as it has happened several times to uᴉoɔʇᴉq. This happens every day in many altcoins.

That is simply not true. Bitcoin has had no intentional hard fork ever. We have only had soft forks.