Consensus Reached

[adamstgBit]

...

This is the loophole. If core blockstream proposes a HF that includes controversial changes along with an increase in the maximum block size then such HF will not get adopted.

Not controversial features, fixes I'd say. Fixes that might be needed (e.g. Time-warp attack).

But if they wanted to, they could put controversial features in a HF, right?

What you are arguing could be a possibility, but hopefully they have worked out those terms as well.

In your opinion, what could be added to the July 2016 HF proposal that would be a deal breaker or be seen as bad faith?

I lack the technical knowledge to give all the possibilities that could be included in a HF that would essentially make the 2 MB HF a deal breaker, however one possibility is that the mining algo is changed in a way so that current ASICs cannot continue to mine (note: changing the mining algo is currently on the Hardfork Wishlist).

From the looks of it however, it appears that several blockstream core devs are already opposed to the HF (that currently only has changing the maximum block size to 2 MB in what is changing), so even if there are no controversial features in the HF, it is possible there will be significant resistance to the HF from the blockstream devs.

I think it probably would have been more sensible for the agreement to state that a consensus for a HF must be delivered by x date and then there could be a soft fork that allows for SegWit. This would essentially close the loophole of blockstream devs who did not attend the roundtable of torpedoing any HF that increases the maximum block size

if they do torpedo the HF.... then there word means nothing, and no one will want to follow a bunch of liars weather or not they agree with them. already a huge % of poeple are unhappy with core, for whatever reason, but we'll stick with them because core + miners were able to came up with something we can all agree on. breaking their word mean that % of people automatically leave, and i wouldn't be surprised if there supports leave simply because no one likes being lied to.

[franky1]

once all the bandwidth and hard drive doomsday stories got debunked. and the only remaining defense was contention of those who dont upgrade becoming left behind.. it makes no rational reason to choose to stay behind purely for the worry that staying behind leaves you stuck behind..

thats something that has been racking my brain for the last year why core was so adement against the blocksize since summer of last year, when the only issue would be that they themselves by not providing a compatible version would cause their fanboys to be left behind..

the even funnier thing is that the roadmap last year stated they were thinking about putting in the 2mb in 2017. and so nothing has really changed.. the community for months now has been trying to get core to alter their roadmap to bring the basic changes into aprils update to get 2mb available before christmas.. but now the PR wagon of blockstream are going to pretend that they have given in to the community as if july 2017 is other peoples idea, even though it was part of the plan since 2015

[Lauda]

I lack the technical knowledge to give all the possibilities that could be included in a HF that would essentially make the 2 MB HF a deal breaker, however one possibility is that the mining algo is changed in a way so that current ASICs cannot continue to mine (note: changing the mining algo is currently on the Hardfork Wishlist).

This will not happen. The only reason for which you are thinking of this is because Luke-jr made a proposal to change the algorithm. People reacted in panic. I can write a BIP on why we should increase the supply to 100 trillion and propose it. This does not mean that it is going to happen.

Switch to block hashing algorithm secure against block withholding attacks.

This would be fine. The wishlist has a few things that could be applied in this HF (why not use the opportunity).

From the looks of it however, it appears that several blockstream core devs are already opposed to the HF (that currently only has changing the maximum block size to 2 MB in what is changing), so even if there are no controversial features in the HF, it is possible there will be significant resistance to the HF from the blockstream devs.

Which tells us that the propaganda behind Blockstream is foolish at best. As Mark F. has stated, people at Blockstream are allowed to think for themselves and strongly voice their opinions. The people who have been at the consensus roundtable can only (truly) represent themselves. By this agreement, the people who signed the statement have to come up with a HF proposal between April and July. How about we first wait and see? Luke-jr (IIRC) even asked for help (reddit, IIRC) so that they get it out in May.

[Quickseller]

if they do torpedo the HF.... then there word means nothing, and no one will want to follow a bunch of liars weather or not they agree with them. already a huge % of poeple are unhappy with core, for whatever reason, but we'll stick with them because core + miners were able to came up with something we can all agree on. breaking their word mean that % of people automatically leave, and i wouldn't be surprised if there supports leave simply because no one likes being lied to.

The thing is that only a small minority (5?) of the blockstream core devs signed the document. The blockstream core devs that did not sign the document can do and say whatever they wish and not loose their credibility. It would be possible that the blockstream core devs would release and (publicly) support a HF that *only* changes the maximum block size to 2 MB (yet still takes ~5 months to release), then all/most of the other blockstream core devs would strongly oppose this HF, effectively torpedoing it. In this scenario, no one would technically be reneging on their word yet the maximum block size would still be at 1 MB. This is why it would have been more advantageous for the blockstream core devs to have to deliver consensus on a HF before SegWit is implemented and before the economic/mining stakeholders agreement to not run Classic goes into effect.....eg. no consensus, no agreement.

From the looks of it however, it appears that several blockstream core devs are already opposed to the HF (that currently only has changing the maximum block size to 2 MB in what is changing), so even if there are no controversial features in the HF, it is possible there will be significant resistance to the HF from the blockstream devs.

Which tells us that the propaganda behind Blockstream is foolish at best. As Mark F. has stated, people at Blockstream are allowed to think for themselves and strongly voice their opinions. The people who have been at the consensus roundtable can only (truly) represent themselves. By this agreement, the people who signed the statement have to come up with a HF proposal between April and July. How about we first wait and see? Luke-jr (IIRC) even asked for help (reddit, IIRC) so that they get it out in May.

Not having all of the blockstream core devs sign the agreement is what effectively makes it toothless.

It also just to happens that the blockstream core devs who work for blockstream are advocating a particular side of an argument that is something that I believe would be beneficial to their employer.

once all the bandwidth and hard drive doomsday stories got debunked. and the only remaining defense was contention of those who dont upgrade becoming left behind.. it makes no rational reason to choose to stay behind purely for the worry that staying behind leaves you stuck behind..

Are there any outstanding bandwidth and HD doomsday stories that need to be debunked?

I don't watch a whole lot of Netflix, but when I do, according to Netflix, I download about 3 GB of data every hour, which works out to roughly 50 MB every minute, or roughly 833 kb every second. It would take me roughly 2.4 seconds to download a full 2 MB block in that time, and assuming download speeds are the same as upload speeds, I could relay a 2 MB block to 8 peers in roughly 19 seconds.

The above assumes that I am consuming all of my bandwidth capacity watching Netflix, which I am not considering that I am able to watch an HD show while simultaneously browsing the internet without any issues.  

[Lauda]

Not having all of the blockstream core devs sign the agreement is what effectively makes it toothless.

It also just to happens that the blockstream core devs who work for blockstream are advocating a particular side of an argument that is something that I believe would be beneficial to their employer.

No. I don't think you understood the point of this meeting. This has nothing to do with Blockstream nor the other people from Core (who were not present). The people present there can only represent themselves. This statement ensures continued work on Segwit and the work on a HF proposal (note: by the people who signed the statement). They will submit the HF proposal and then we will see what happens. The developers might not like it, the community might not like it, etc. We can't know right now.

[adamstgBit]

Not having all of the blockstream core devs sign the agreement is what effectively makes it toothless.

80% hashing power and a bunch of devs all agreeing to somthing that most of the community likes is toothless???

  


this agreement awesome!

its this or we continue the blocksizebitchfest indefinitely

take your pick.

[franky1]

pay no attention to lauda trying to twist everything. it was only 1 month ago that he thought bitcoin was programmed in java.. which reveals how little he really knows.

miners have actually tweaked their implementations to be more efficient for mining. so it wont take much for them to implement the 2mb buffer without needing core to hold their hand. so although core wants to stay on their 2 year roadmap of delaying 2mb until mid 2017. the miners and community do not need core to do it..

what would be helpful is that if the growth of the indicators that 2mb is going to happen soon. that core also release a version with the code aswell. that way their fanboys are not left behind causing contention, but also going with the majority and not causing contention.

[Laosai]

Not having all of the blockstream core devs sign the agreement is what effectively makes it toothless.

80% hashing power and a bunch of devs all agreeing to somthing that most of the community likes is toothless???

  


this agreement awesome!

its this or we continue the blocksizebitchfest indefinitely

take your pick.

Already took mine. And seeing the current price trend, seems like most investors did the same.

[Quickseller]

Not having all of the blockstream core devs sign the agreement is what effectively makes it toothless.

80% hashing power and a bunch of devs all agreeing to somthing that most of the community likes is toothless???

The issue is not with the hashing power (the operators of the pools actually), it is with the blockstream devs. The economic majority of Bitcoin and (most likely) the majority of the mining pools (which currently have the majority of the mining power pointed at them) have wanted larger blocks for a long time. The same is most likely true for much of the userbase. It is the blockstream core devs that are opposed to increasing the maximum block size. If the blockstream core devs oppose a HF then such HF will have a difficult time in getting it's way into production.

Not having all of the blockstream core devs sign the agreement is what effectively makes it toothless.

It also just to happens that the blockstream core devs who work for blockstream are advocating a particular side of an argument that is something that I believe would be beneficial to their employer.

No. I don't think you understood the point of this meeting. This has nothing to do with Blockstream nor the other people from Core (who were not present). The people present there can only represent themselves. This statement ensures continued work on Segwit and the work on a HF proposal (note: by the people who signed the statement). They will submit the HF proposal and then we will see what happens. The developers might not like it, the community might not like it, etc. We can't know right now.

Do you think there was a reason why the blockstream core devs only agreed to submit a HF proposal and did not agree to deliver a consensus (especially among the other blockstream core devs)? Do you think there was a reason why SegWit is to be implemented prior to the HF proposal is even released? Do you think there is a reason why Adam Black signed the agreement as an individual and not as the CEO of blockstream (he should have the authority to sign on behalf of blockstream as the CEO, and if blockstream as an entity agrees with the document then someone from the company should sign the document)?

Did you notice that several people signed on behalf of various pools and Bitcoin related companies? Do you think they also only represented themselves? Were these people only agreeing to not run classic on their own person equipment and not on their company's/pool's  equipment?

[adamstgBit]

Not having all of the blockstream core devs sign the agreement is what effectively makes it toothless.

80% hashing power and a bunch of devs all agreeing to somthing that most of the community likes is toothless???

The issue is not with the hashing power (the operators of the pools actually), it is with the blockstream devs. The economic majority of Bitcoin and (most likely) the majority of the mining pools (which currently have the majority of the mining power pointed at them) have wanted larger blocks for a long time. The same is most likely true for much of the userbase. It is the blockstream core devs that are opposed to increasing the maximum block size. If the blockstream core devs oppose a HF then such HF will have a difficult time in getting it's way into production.

market reacted very well to the news, economic majority likes this.

the operators said it themselves they CANNOT act without the consent of their clients. they knew what there clients wanted coming in and they got that.and one of the operators is actually a private pool.

for that last point, miners will switch to classic in that case, thats what they said coming in, "we are so fed up with you we will switch to classic if you don't listen to us" or somthing to that effect. I think that is the general sentiment for mostly everyone, so if the  blockstream core devs give us a hard time, we will HF AS SCHEDULED without them.

https://twitter.com/gavinandresen/status/701258037747646464

So.... what's the process for deciding what goes into Core hard fork and how it's deployed? Same way timeline was decided?

Burn?

burn indeed

we'll be fine,  blockstream core devs are learning that the only power they really have is the ability to let there voice be heard, and if they choose to ignore our voice, they will get  what they deserve.

[chopstick]

I think the bottom line is that there is no good reason not to immediately implement 2 MB blocks. A lot of people are already having much longer than normal transaction confirmation times, and it's going to get a lot worse as the transaction volume continues to grow.

It just makes no sense whatsoever not to implement a simple solution immediately.

So why the fuck are the blockstream devs so opposed to a blocksize increase? It just seems completely devoid of logic.

[AliceWonderMiscreations]

I think the bottom line is that there is no good reason not to immediately implement 2 MB blocks. A lot of people are already having much longer than normal transaction confirmation times, and it's going to get a lot worse as the transaction volume continues to grow.

It just makes no sense whatsoever not to implement a simple solution immediately.

So why the fuck are the blockstream devs so opposed to a blocksize increase? It just seems completely devoid of logic.

The "longer than normal" confirmation times are not being caused by the blocks being too small. If they were, then the blocks would always be full when this happens but that isn't the case.

If only 80% of the available space is used then doubling the space isn't going magically make transactions added that weren't included when there was space to include them.

I pay more than minimum, that is true, but it still works out to less than a nickel for every transaction - hell, often around a penny.

Maybe some transactions cost more because the user has a wallet full of micro-payments from gambling or from faucets etc. and lots of small inputs really increases the size increasing the cost. That could be fixed by making a button consolidate small inputs into bigger inputs, and that transaction may take awhile.

Maybe some clients are having problems because the client is not well connected, I don't have a solution for that other than maybe manually connecting to well connected nodes.

The blocks are rarely at full capacity though, so its not a block size problem.

https://blockchain.info/charts/avg-block-size

Yes at some point it will start being a problem, though segwit may delay when it is, but it isn't a problem now, ergo people with delayed transactions won't benefit from an increase now. It's simply not the cause of their delay.

[adamstgBit]

I think the bottom line is that there is no good reason not to immediately implement 2 MB blocks. A lot of people are already having much longer than normal transaction confirmation times, and it's going to get a lot worse as the transaction volume continues to grow.

It just makes no sense whatsoever not to implement a simple solution immediately.

So why the fuck are the blockstream devs so opposed to a blocksize increase? It just seems completely devoid of logic.

i guess, implementing 2MB first probably feels like admitting they were wrong.

it feels like we just convinced a child to do eat his supper, let's not push it and make sure he eats the meat first.

[danielW]

I think the bottom line is that there is no good reason not to immediately implement 2 MB blocks. A lot of people are already having much longer than normal transaction confirmation times, and it's going to get a lot worse as the transaction volume continues to grow.

It just makes no sense whatsoever not to implement a simple solution immediately.

So why the fuck are the blockstream devs so opposed to a blocksize increase? It just seems completely devoid of logic.

i guess, implementing 2MB first probably feels like admitting they were wrong.

it feels like we just convinced a child to do eat his supper, let's not push it and make sure he eats the meat first.

If you implement 2mb hardfork it will delay segwit significantly. segwth plus 2mb hardfork will give around 4mb blocks which will mean too high orphan rates for miners, and it would require devs to work on hardfork instead of segwit now.

Segwit gives similar block increase to hard-fork can be rolled out immediately and has many important additional benefits. It also is the quickest way to increase block-size as  devs rightly believe that a hard-fork needs long activation time.

Also if fork is done later we can add some other improvements that also require hard-fork.

[adamstgBit]

I think the bottom line is that there is no good reason not to immediately implement 2 MB blocks. A lot of people are already having much longer than normal transaction confirmation times, and it's going to get a lot worse as the transaction volume continues to grow.

It just makes no sense whatsoever not to implement a simple solution immediately.

So why the fuck are the blockstream devs so opposed to a blocksize increase? It just seems completely devoid of logic.

i guess, implementing 2MB first probably feels like admitting they were wrong.

it feels like we just convinced a child to do eat his supper, let's not push it and make sure he eats the meat first.

If you implement 2mb hardfork it will delay segwit significantly. segwth plus 2mb hardfork will give around 4mb blocks which will mean too high orphan rates for miners, and it would require devs to work on hardfork instead of segwit now.

Segwit gives similar block increase to hard-fork can be rolled out immediately and has many important additional benefits. It also is the quickest way to increase block-size as  devs rightly believe that a hard-fork needs long activation time.

Also if fork is done later we can add some other improvements that also require hard-fork.

AH HA!
thank you
its nice to understand their reasoning behind the decision.
i would like to apologise  for my ignorance, and most incorrect analogy. i am but a simple bitcoiner, shame on me for questioning the validity of the agreement.
it sure FEELS like they are stalling and acting in their own self interest (blockstream), but that is only because I do not understand the details.

[danielW]

I think the bottom line is that there is no good reason not to immediately implement 2 MB blocks. A lot of people are already having much longer than normal transaction confirmation times, and it's going to get a lot worse as the transaction volume continues to grow.

It just makes no sense whatsoever not to implement a simple solution immediately.

So why the fuck are the blockstream devs so opposed to a blocksize increase? It just seems completely devoid of logic.

i guess, implementing 2MB first probably feels like admitting they were wrong.

it feels like we just convinced a child to do eat his supper, let's not push it and make sure he eats the meat first.

If you implement 2mb hardfork it will delay segwit significantly. segwth plus 2mb hardfork will give around 4mb blocks which will mean too high orphan rates for miners, and it would require devs to work on hardfork instead of segwit now.

Segwit gives similar block increase to hard-fork can be rolled out immediately and has many important additional benefits. It also is the quickest way to increase block-size as  devs rightly believe that a hard-fork needs long activation time.

Also if fork is done later we can add some other improvements that also require hard-fork.

AH HA!
thank you
its nice to understand their reasoning behind the decision.
i would like to apologise  for my ignorance, and most incorrect analogy. i am but a simple bitcoiner, shame on me for questioning the validity of the agreement.
it sure FEELS like they are stalling and acting in their own self interest (blockstream), but that is only because I do not understand the details.

  I think its a good plan and I can see its merit. All I did was explain why I think its good and what I think is the rationale. Maybe you disagree.  I did not mean to offend you.

[Lauda]

Do you think there was a reason why the blockstream core devs only agreed to submit a HF proposal and did not agree to deliver a consensus (especially among the other blockstream core devs)? Do you think there was a reason why SegWit is to be implemented prior to the HF proposal is even released? Do you think there is a reason why Adam Black signed the agreement as an individual and not as the CEO of blockstream (he should have the authority to sign on behalf of blockstream as the CEO, and if blockstream as an entity agrees with the document then someone from the company should sign the document)?

You're being hyperbolic here and asking too many obvious questions. I've told you how it is. People who were at that meeting (Core/Blockstream) represent themselves as individuals, and in no way possible can they represent (in this case) everyone else (Core).

Did you notice that several people signed on behalf of various pools and Bitcoin related companies? Do you think they also only represented themselves? Were these people only agreeing to not run classic on their own person equipment and not on their company's/pool's  equipment?

Those have signed it in the name of their respective companies/pools. Also keep in mind that both Garzik and Gavin were invited (allegedly 'busy').

i would like to apologise  for my ignorance, and most incorrect analogy. i am but a simple bitcoiner, shame on me for questioning the validity of the agreement.
it sure FEELS like they are stalling and acting in their own self interest (blockstream), but that is only because I do not understand the details.

The problem is that you're not spending enough time reading and trying to understand. You'd rather go around and make accusations. Similar questions have been asked thousands of time. Segwit will give a capacity boost that should be similar to a 2 MB block size limit (exact numbers depend on adoption and type of transactions). How is 'adding capacity' equal to "stalling"? Some calculations:

          p2pkh           2-of-2 msig
now     100%            100%
segwit  174%-181%   197%-204%

[sadasa]

It would be better if the hard fork of 2MB comes earlier than the SegWit. I think the latter is more risky.

[MeteoImpact]

Just want to clear up one point that some people might be missing (or intentionally misrepresenting to create FUD). In the roundtable plan, it is stated that, "If there is strong community support, the hard-fork activation will likely happen around July 2017". This is not, as I am interpreting it, a declaration that the hard-fork will be scheduled to activate in July 2017, but that July 2017 is merely the prediction for how long it will take the network to reach consensus (950 of the last 1000 blocks, I'm assuming) and activate the fork; the code which will allow miners to signal support of the fork is scheduled to be available in July 2016. What this means is that the hard-fork could occur any time after the Core release in July 2016 and will be entirely dependent at that point on how quickly miners update to the new version of Core--July 2017 is merely an estimate of when this might occur. If miners really do see the issue as something which needs to be addressed immediately and therefore update quickly, the fork could occur at a much earlier date (1000 blocks is approximately 1 week of mining, so the first week where 95% of miners agree to fork should activate it). Regardless, the delay is not something which Core (or any other implementation) can control, and certainly isn't some nefarious plan to, "cripple", Bitcoin by delaying the changes being agreed upon.

I'd be very happy if this decision could bring a bit of peace back to the Bitcoin community, though all the conspiracy theory stuff probably will take some time to make itself scarce...

[AliceWonderMiscreations]

It would be better if the hard fork of 2MB comes earlier than the SegWit. I think the latter is more risky.

Why? It has been in extensive testing.