Bitcoin Forum

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?

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.  :)

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

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.
 

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?)

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.

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:
https://i.imgur.com/LliXVbT.png

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.

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."

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

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.

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

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.

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.

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.

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

I thought bitcoin has hard forked before, in 2012 or 2013? If you give enough notice, hard fork can be implemented properly.

Once, completely accidentally. The fork was caused by a major bug which literally broke uᴉoɔʇᴉq. Other than that, there have been no hard forks in bitcoin.

its worth noting it took a few hours to get all the miners running the right version again.
and remarkably my TX ( which was sent DURING the "bug which literally broke" ) ended up working!

so there was 0 notice and miners all upgraded within a few hours.

from none. to once. so how about the millions of bitcoin created in the early years..
wait, thats twice that we have had a hard fork..
wait.. lets just clear this matter up

august 2010.. making millions of bitcoin
february 2012.. version message
march 2013.. db bug

so now there are three..

the funny thing is. when the code was released, and by this im not talking about how long it took to debate what and how it should be done.. im talking about when the code was actually released.. it did not take 12 months for everyone to move over.

I knew about the accidental hardfork, but I didn't realize how quickly it was fixed.  That makes this whole argument that much more ridiculous. A few hours is nothing.  I'm ready for a hardfork to 2+ MB right now.  All it would do is allow for more room, it wouldn't force blocks to be 2MB, it would just be the MAX size.

You're comparing the (almost) incomparable here (Bitcoin back then and Bitcoin now - when the size of the ecosystem is concerned). Additionally, let's not forget that there was at least 1 known double spend due to this problem (OKPay IIRC).

You still don't understand what happened at the roundtable.

It does.

---

---

I would support it only with a proper consensus threshold and grace period.

theres so much fail in this post.

firstly the number of NODES is not much different.
secondly if people know its going to happen. there wont be double spends.. a planned fork does not need 12 months. especially if an unplanned fork got fixed in HOURS!!.

seriously. will you stop bashing your head against the blockstream bible and start thinking for yourself

Proof it!
I know of 1 hard fork. And that was due to some serious issue. Right now we don't have any issue why we should rush through a hardfork.Things should be done properly.And scaling is not only raising the blocksize!!
Furthermore there's still space in the blocks.So all the noise is ridiculous.
And you can not compare some stupid altcoins with a lousy market cap with Bitcoin where some serious money is at stake.

There is again so many empty blahblah about HF risks.

Point us to a rigorous risk analysis why this HF (just 2MB) is worse than a SF + SW + LN including all use cases for a frictionless growth compared to the past...


I say just a bit provocant:  HF fear is good for making politics & business. I cannot buy this w/o independent study.

But yes nobody might be able to do this or just dont want to and we are still in the boat.  :)

Thats pretty confusing pool question, as far as I know some Core members agreed to try put code for 2MB HF voting this July release of Bitcoin Core, with 12 month grace period for activation.

The problem is 12 month grace period which is unnecessary too long.



With such long grace periods you need to plan ahead. So argument we are fine now is worth nothing because you dont consider what can happen during one year at least.

With such long grace periods for activation you really need to be good central planner (this reminds me of Soviet Union five-year plans, we all know how good their central planning over comparable long periods went...)

Yes, that is correct. There is nobody that could sign such an agreement for everyone who is involved in Core (some seem to think otherwise).

That's debatable. I've recently read somewhere that someone will suggest a shorter one (not sure where; I'll try to find it).

Not really, no. Segwit should be deployed and activated and we should see the capacity growing over time.

One year from now is too late. The road map should be to double block size every year. Exponential growth is the road to mass use of bitcoin, doubling block size only once is not going to do that.

Actually it isn't. What Bitcoin needs is a secondary layer (e.g. Lightning Network).

I support this whole-heartedly

z

Why?

Just no analysis again....

The 1 MB maximum blocksize limit was added,, I believe in 2010, via a hard fork.

Edit: The previous effective blocksize limit was 32 MB.

There have been plenty of analyses over time. You can't blame me if you either haven't been here long enough or are unwilling to search (there are too many threads about this).

---

---

I'm willing to shortly explain it to you. What are we looking at here, doubling every two years year?

No thanks Lauda. Nobody really is able to condense all threads here.

For proper decicision making in any risk exposed business you need to provide some prestudy that contains an analysis covering

Status quo

Future expectation / simulation

Many different solutions to compare

Risks

?....


From that all can easy derive / vote the best choice.

All that needs to be really done independent from say 2-3 institutions like MIT, ETH Zürich, accenture,...


Thats how you can save lot of threads and politics, but nothing is done here and a flaw remains and looks like a joke in financial business....

Nope, there was no hard fork. There was no need to as there was not enough transaction volume to even come close to the limit. The limit was simply just added in this commit: https://github.com/bitcoin/bitcoin/commit/9d2174b6f5f3fac2463c7ebc2dbb9004b3740d23.

I don't see how this is relevant to the person that I've quoted. They stated that the block size limit should double every year, without mentioning any "side", developers and whatnot. You don't need third party institutions for minor calculations based on true information (when sources are provided).

What do you mean by "done here"?

so you have just proved blockstreams contention doomsday is a non thing.
if USERS ungrade their clients in hours/days or weeks.. knowing miners wont make more transactions then the present limit.. there wont be a fork..
and then when miners deem that there are enough nodes not to be a fork, they then start making bigger blocks.

its kind of funny that the blockstream fanboys own arguments actually make their positions meaningless..

the only reason there would be a fork is by blockstream fanboys refusing to upgrade.. like a self fulfilling prophecy.. not upgrading because of a hardfork will itself be the cause of a fork.

the code is not the contention or the fork. but the desire of blockstreamers to delay or refuse is the cause of the fork

Yeah, you know what that is called? It is called DEPLOYMENT. The deployment is the whole thing about the threshold and grace period. The miners with that new limit won't make blocks more than the present limit and then when they deem that there are enough nodes and miners to not have a fork (X out of the last 1000 blocks indicated support for their fork) then they start making bigger blocks. This is exactly how deployment works.

What I was saying was that there was no deployment like that to add the 1 Mb limit in. It was simply one version didn't have it, the next suddenly did. It didn't matter back then because there weren't enough transactions to fill up the blocks and go over that limit. That was the deployment, and if that happened now, there would be a fork because there are enough transactions to produce a block larger than 1 Mb.

lol.. i see what your trying to say. but blockstreams refusing to add code purely for the numbskull belief that miners will make bigger blocks when a threshold is reached, is itself just causing controversy to cause controversy.

its like not going out of your basement because you know that going out of your basement means your no longer in your basement. you know there is no risk to getting out of your basement. but you want to stupidly plan that you will only leave your basement 2 years after other people ask you to leave your basement. just to waste peoples time making them wait for you for no good reason but your own stupid desire to stay in your basement.

again you know there is no risk. and u are only doing it to piss people off and feel like other people need to wait for you, like a power/ego trip. thinking it makes you important and wanted by having people begging you to just get out of your basement.

there is no reason at all to refuse to add the code now. and we all know that miners wont make bigger blocks until they are sure that their coins wont get orphaned. so refusing to add the code on the stupid idea that miners will make bigger blocks before the threshold is obsured.

its the blockstreamers that are preventing the threshold from ever getting reached. they should release the code along with their segwit, THIS MONTH.. and not in july with a stupid further 12 month delay.

that way people dont need to upgrade twice.(this month and this july) they can upgrade once. and have the code active when the thresholds are met.

by having the code with a 12 month grace, is going to make people lazy and think they dont need to upgrade.. causing even further delay.
but having a 1 month grace. and then let the miners themselves PREFERENTIALLY wait after that for the threshold. will ensure the blocks grow only when its safe to, without all this delay crap to make people not want to upgrade.

Why wouldn't they? People complain that there is a backlog, and when the threshold is reached that allows miners to add more transactions to blocks thus getting them more fees and removing the backlog, why wouldn't they? People would complain that miners aren't doing anything and the miners themselves are missing out on fees.

They can't release something that doesn't exist. And no they cannot just take classic's code because there are significant differences that would need to be worked out that it is better and more effective to write the code for a hard fork separately on the changes that Core has made.

People don't need to upgrade twice. The only required upgrade is for the hard fork. There is no requirement to upgrade to still be able to use Bitcoin after segwit's deployment. It is just to use segwit you need to upgrade. They can simply put off the upgrade until the hard fork release is out and have no ill effect.

I will support it. I also think that is getting late for this... Instead of form a year from now it should be made tomorrow already.
Blocks are getting full and the fees are increasing, in a year from now the fees will be impossible to bear and everybody will be using other options. This can seriously put bitcoin at risk

The only thing that would put Bitcoin at a risk (relevant to this thread) is what you've just proposed.

Who are these "blockstreamers" then? I don't know of anybody working on Bitcoin who doesn't want to upgrade and move Bitcoin forward. Obviously it isn't the Core developers since they are doing segwit, versionbits, and csv, among other stuff which will all move Bitcoin forward. Moving forward and upgrading does not have to be limited to one specific change.

And why do you say that these "blockstreamers" don't want to upgrade and just want an ego trip? Have you any quotes which would support this or is it just speculation based on a (biased) reading of people's words?

lets count it
one
two

but if the 2mb was included in aprils release there would be only ONE upgrade. and with a reduced grace period people will know its a priority to upgrade.

blockstream fully know there is no practical reason for the 12 months. but the only EGO trip of having the 12 months is to make it not a priority so that they can circe jerk each other and say that only X% have upgraded in X hours.. purely because the graace period makes it a non-prioority.

they fully know that if it was a priority eg 1 week or 1 month then people can EASILY upgrade in that time.. the 12 months is just to fudge the numbers and get people to wait and not upgrade just so they can pretend that the reason people are waiting is due to hate or lack of desire of the limit increase. when we know its just to do with not being a priority because blockstream want their code to control bitcoin in a way they want it to be controlled

they really love their self fullfilling prophecies just to boost their ego's

check out icebreakers 75page censored thread for the circle jerking ego trip of blockstreamers

gmaxwell and luke Jr are definitely on power trips too..

Right, but for the lazy person who doesn't want to upgrade unless absolutely necessary, then it is only one, the hard fork release. There is no need to upgrade for segwit because you can simply keep on spending and using Bitcoin as you do now with no ill effect.

Where the hell are you getting the 12 month grace period from? It says that the code will be available by July. So it will be tested thoroughly when the code is available and that will take some time. Then it will be merged in and tested over and over again and then the release process starts and that takes even more time. Between the code being available and the actual release there is probably about two months for all of the testing and the gitian build process to complete. Then it says that it is LIKELY that activation will happen around July 2017 because miners need to upgrade and the blocks supporting the fork need to be produced to meet whatever threshold is set. Absolutely nowhere can I find anything that says that there is a 12 month grace period.

I'd ask you for a tl;dr but I wouldn't get an objective summary of the thread.

Really, how so?

Oh please you mean to say that reversing those changes is not a hard fork. Of course it is a hard fork. By your same argument one can introduce a 32 MB blocksize limit after say block 1000000 and claim it is not a "hard fork"

Alright, if you want to call it a hard fork, then it's a hard fork. But the difference between that and now is the context of its deployment. They are not comparable.

Yes the circumstances are very different and this is fast becoming a serious problem for BItcoin.

The difference is that it is very easy to hard fork a cypto currency when the community is still small and there are no economic interests adversely impacted by the hard fork. As a coin matures it should be design be very difficult or impossible to hard fork if the hard fork has an adverse impact on existing economic interests. The problem that Bitcoin faces is that it needs to hard fork in order to scale, while at the same time it may be already too late for a hard fork that may have adverse economic impacts on members of the community. The miners trapped behind the Great Firewall of China may be a good example of this kind of economic interest.

There is a very critical lesson here for alt-coin developers.

What makes you say that? If you're among the people (?) who think that Bitcoin can only scale by increasing the block size limit, then you're wrong. Besides, you should be aware that transacting on a secondary layer is much more efficient (in theory) than transacting on the main-chain.

Indeed.

... And with that very good argument it is much more better to do the HF NOW than next year, where it should be way bigger & more mature and so more harder to do. But I see this argument than used next year to refuse a HF again....

According to the road map by the Core development team, the SegWit will be available from April. I will support that.

That road map was not followed properly. So the SegWit had not come out yet. I am looking forward to the implementation.

We will see. If we have lightning network, segregated witness, schnorr signatures... and so on and so on, then it might be irrelevant to risk a hard fork at that point, since we will probably still not be at top capacity after all those features are deployed, so it's maybe not worth the risk of both the hard fork itself and node centralization as well. Time will tell, now the focus is on making bitcoin better, and that's exactly what they are doing.

Just SegWit and Schnoor Sigs alone will bring us a capacity boost similar to a 3-3,4MB Blocksize!
Lightning as additional layer will make it much more easier to use micropayments and offers completely new possibilities for business ideas.
Really amazing and I'm looking forward to all of this.

Your wrong, final SegWit code was pulled to Github in April as promised (around 19 April).

This mean Core has today 2 and 1/2 months to pull hardfork proposal to 2 MB as two respected Core contributors and Blockstream CEO promised to miners they prepare such hardfork code within 3 months of Segwit code.

So time is slowly ticking, if they fail to deliver as promised and minners still honouring the agrement, the reputation of these 2 Core contributors and Blockstream become worth very little. The end of Blockstream dominance over Bitcoin development ? We shall see soon if they fail to deliver in time - 2 and 1/2 months to get popcorn ready...