The Barry Silbert segwit agreement with >80% miner agreement. (Part II)

[CoinCube]

Edit: Since there had been no further activity in this thread for several day I am locking it.

I have started this thread because -ck has decided to close his original thread on this topic. I have tremendous respect for -ck and feel he is one of the most rational voices in this dispute. That said I disagree with his decision to close his thread as this is an important topic and should be discussed by the community in as open and as free a manner as possible.

So you've probably heard by now that the large pools have been meeting in secret to discuss a way forward for the bitcoin protocol that would both activate segwit and a future 2MB hard fork. It appears the closed doors meetings did indeed come to an agreement, but not quite what has been assumed by the community.

This is allegedly the draft agreement:
https://pastebin.com/VuCYteJh

Copied below:

We agree to immediately support the following parallel upgrades to the bitcoin protocol, which will be deployed simultaneously and based on the original Segwit2Mb proposal:
 
 
 
·         Activate Segregated Witness at an 80% threshold, signaling at bit 4
 
·         Activate a 2 MB hard fork on September 21, 2017
 
 
 
The following companies have committed to provide technical and engineering support to test and support the upgrade software, as well as to assist companies with preparing for the upgrades:
 
 
 
·         Bitcoin.com
 
·         BitFury
 
·         BitGo
 
·         Bitmain
 
·         BitPay
 
·         Blockchain
 
·         Bloq
 
·         RSK Labs
 
·         Xapo
 
 
 
We are also committed to the research and development of technical mechanisms to improve signaling in the bitcoin community, as well as to put in place communication tools, in order to more closely coordinate with ecosystem participants in the design, integration and deployment of safe solutions that increase bitcoin capacity
 
We welcome all companies, miners, developers and users to join us and help prepare bitcoin for the future

In short, what this actually means is a large proportion of the big mining pools have agreed to ignore pretty much all scaling signalling and adopt their own to further their desires. They plan to do a hard fork within 4 months6 months(updated) that both activates segwit and creates a base block size increase of 2MB concurrently. In addition, they are NOT going to be using the existing segwit bits, signalling instead their own bit to activate segwit which is incompatible with the segwit activation from core. They are also planning activation at >80% hashrate.

In essence this means the pools are creating a fork of the current bitcoin code which is planned to be incompatible with any current version should their hard fork go ahead. Which means that every single current code node user, be they core, BU, classic, XT, whatever, is currently going to be on an incompatible fork of bitcoin after their planned deployment in SeptemberDecember. So they are asking the entire community to ignore all existing bitcoin implementations and adopt their software node implementation before that time, or risk being on a very hashrate poor fork, even though there is no published code to support this SeptemberDecember fork yet.

This isn't remotely what many of us were expecting when we heard the pools were agreeing to implement segwit provided a hard fork was also available. In retrospect it makes sense given their aggressive stance in the past, but basically this is without doubt the most aggressive stance yet by the mining consortium. It's even more amazing given bitcoin.com allegedly signed the agreement - BU's reference pool implementation owned by Roger Ver. I wonder if all the groups that allegedly signed the agreement are even aware of what it is they're agreeing to? Bitfury for example are in there, who have been vocal proponents of segwit to date.

This will no doubt make the community even more aggressive in response with its BIP148 stance. I don't like BIP148, but I like this even less.

I'd like to believe this draft agreement was heavily revised and is basically wrong, but at this stage this is all we have to go off.

[25hashcoin]

And I'll repost a post that seems to have been removed from the previous thread as predicted, just before it was closed by -ck. This type of censorship is shameful.

-ck only wants posts that agree with his narrative

my post is about sgwit... not any other implementation or people..(not bu, ver, jihan, classic, xt)
but expect my post to get deleted even if it speaks truth

1. if core is perfect working code, then why does it need "fixes" such as malleability, quadratics
2. if segwit works beautifully on litecoin then why are the pools who voted for it not even using segwit keys (where the actual segwit function/benefits lay)

i find it funny that pools pushed for segwit but too afraid to put their coinbase(blockrewards) into a segwit keypair..

all these efforts of
core-bip9
uasf
barry silbert
are all the same crap trying to get segwit activated but doing NOTHING to ensure any user benefit is guaranteed.
doing nothing to meet any promises of segwit or anything after segwit

expect my post to get deleted even if it speaks truth

[adaseb]

I read Bitmains Contingency plan posted here

https://blog.bitmain.com/en/uahf-contingency-plan-uasf-bip148/

Got lost half way. Can someone explain exactly what is going on?

[gmaxwell]

should be discussed by the community in as open and as free a manner as possible.

Then you make a self moderated thread?

In any case... I'd say stick a fork in it,  but it sounds like Bitmain is now planning on doing just that.  They've announced their intention to fork off onto a new and incompatible direction,  (also publicly announced that they plan to do a 72-hour selfish mine on their fork, which is ... odd to announce).

In my view, that after the near unanimous rejection of segwit2x by active developers (even BU) Bitmain announcing they're gonna do a spinoff is the final killing blow on that absurd agreement.

1. if core is perfect working code, then why does it need "fixes" such as malleability, quadratics

uh, those things are not dealing with "code" features they're limitations in the Bitcoin protocol which are fixed by segwit. Segwit is the fix and it was needed because the protocol design Satoshi had a few limitations.  There have been many softforks in the past to fix other limitations in the original design-- some performed by Satoshi himself, some performed by the current folks that maintain the software.

[CoinCube]

Then you make a self moderated thread?

Given the vitriol in the community on this topic I unfortunately felt that was necessary. This is the only self moderated thread I have ever started.

I have never before deleted anyone's post on any forum to date and I hope to keep this record. However the hostility around this topic necessitates the following rule.

Rule: No personal attacks.

Example: "CoinCube is a Russian agent looking to hack and take over bitcoin" would get deleted. Similar personal attacks on either miners or developers would be deleted.

[CoinCube]

As a general rule of thumb consensus is best facilitated through open and censorship free discussion. Exceptions must be made for those who repeatedly spam as well as for those who are seeking to be purposefully disruptive.

So far bitcoin is doing exactly what it is suppose to do and lock into immutability unless there is a broad consensus for change.

The failure here is entirely a human one. People need to give up the idea of "winning this debate" and imposing their vision on the broader community. UASF and a hostile miner takeover are moral equivalents and equally unacceptable actions in a consensus system.

I am not a programmer and like most people in the bitcoin community I am unable to fully evaluate the technical merits of the multiple scaling solutions. Nevertheless, the basic dispute is quite simple.

1) The core developers and small blockers believe that block size must be limited to maintain decentralization and thus favor small block sizes and the long term development of side chains to allow for increased functionality.

2) The large miners and big blockers are interested in maximizing on-chain scaling. They disagree with the centralization dangers and view off-chain scaling as a possible long term economic threat.  They fear long term revenue declines and economic irrelevance.

Core will never accept any form of automatically increasing on-chain scaling as they view this as the leading to the centralization and ultimately the failure of bitcoin. The miners will never accept SegWit as it currently stands because to do so would be tantamount to surrender and giving up on the concept of any substantial increase in on-chain scaling ever.

This is a setup for locking into immutability and status quo for the foreseeable future.

The perception of immutability is not necessarily bad for value so this is not a terrible thing. That said if the cost to send bitcoin approach the cost to wire fiat this will slow growth and adoption.

Perhaps the rolling out of side chain projects such as RSK will break the deadlock if mining these proves profitable? If the economic threat of side chains vanished or better yet if side chains become profitable for the miners they are likely to soften their insistence for on-chain transactions. Alternatively if the small block folks set some metrics for tolerable increases in on-chain scaling over time as hardware and infrastructure improves globally this may also lead to compromise.

[gmaxwell]

Core will never accept any form of automatically increasing on-chain scaling as they view this as the leading to the centralization and ultimately the failure of bitcoin.

This is simply untrue, and in fact the published capacity increases plan message directly contradicts you.

But the issue is that Bitmain and friends are frantically saying there is no issue in all these different dimensions that scaling impacts. They also claim that only miners should run nodes, that it's okay if eventually Bitcoin nodes just exist in five data centers.   There are hard and unsolved problems, but people saying duh we're not going to participate with undermining the technical argument for Bitcoin's long term viability without solving them (and especially under the claim that they just don't exist) doesn't mean that they wouldn't support automatic increases.

Your remark is doubly off the mark, to the point of a bit of offense,  because segwit _IS_ "on chain" scaling.    (It is both an increase of the chains scalablity and of its capacity.)--  doubly so because the same people have been doing all this work to keep up with load since _2011_ and have been responsible for 100+ times increases in scalablity from the original software.

The perception of immutability is not necessarily bad for value so this is not a terrible thing. That said if the cost to send bitcoin approach the cost to wire fiat this will slow growth and adoption.

We've got a long way to go fees wise to get to wire transfer levels. (E.g. $35 for a one day delayed transfer.)


But it seems that this thread is offtopic now-- Segwit2x is dead, with it main miner supporter now breaking it. Time for another thread?

[CoinCube]

Core will never accept any form of automatically increasing on-chain scaling as they view this as the leading to the centralization and ultimately the failure of bitcoin.

This is simply untrue, and in fact the published capacity increases plan message directly contradicts you.
...
Your remark is doubly off the mark, to the point of a bit of offense,  because segwit _IS_ "on chain" scaling.    (It is both an increase of the chains scalablity and of its capacity.)--  doubly so because the same people have been doing all this work to keep up with load since _2011_ and have been responsible for 100+ times increases in scalablity from the original software.

That was an interesting read. I did not understand it all but it was interesting. There is a lot of technically advanced work being done behind the scenes in bitcoin.  

Perhaps my statement was overly broad. I should have simply said that Core will not accept any of the currently proposed algorithms for automatic blocksize increases as they believe these threaten progressive centralization. I did not intend to imply that the Core developers would be opposed to automatic scaling should a technical breakthrough change the perceived risks.

Segwit may be an on-chain scaling increase but as far as I can tell the miners don't see it that way. They view it as capitulation and giving up on future on-chain scaling in favor of pursuing off-chain solutions going forward. Just as Core feels rash increases in block size threatens bitcoin viability. The miners seem to feel that favoring of off-chain over on-chain transactions will in the future threatens their long term viability. Thus we get gridlock. This is my current understanding of the current dynamics in play. Am I misunderstanding anything?

I am glad that you highlighted the work the Core team and yourself have put into this. The community should know the blood sweat and tears that have been investing into the protocol to date and most of us don't.

[25hashcoin]

Core will never accept any form of automatically increasing on-chain scaling as they view this as the leading to the centralization and ultimately the failure of bitcoin.

This is simply untrue, and in fact the published capacity increases plan message directly contradicts you.
...
Your remark is doubly off the mark, to the point of a bit of offense,  because segwit _IS_ "on chain" scaling.    (It is both an increase of the chains scalablity and of its capacity.)--  doubly so because the same people have been doing all this work to keep up with load since _2011_ and have been responsible for 100+ times increases in scalablity from the original software.

That was an interesting read. I did not understand it all but it was interesting. There is a lot of technically advanced work being done behind the scenes in bitcoin.  

Perhaps my statement was overly broad. I should have simply said that Core will not accept any of the currently proposed algorithms for automatic blocksize increases as they believe these threaten progressive centralization. I did not intend to imply that the Core developers would be opposed to automatic scaling should a technical breakthrough change the perceived risks.

Segwit may be an on-chain scaling increase but as far as I can tell the miners don't see it that way. They seem to view it as capitulation and giving up on future on-chain scaling in favor of pursuing off-chain solutions going forward. Just as Core feels rash increases in block size threatens to bitcoin viability. The miners seem to feel that favoring of off-chain over on-chain transactions will in the future threatens their long term viability. Thus we get gridlock. This is my current understanding of the current dynamics in play. Am I misunderstanding anything?

I am glad that you highlighted the work the Core team and yourself have put into this. The community should know the blood sweat and tears that have been investing into the protocol to date and most of us don't.

Statements from Core don't mean anything. This you should know by now.

[CoinCube]

Statements from Core don't mean anything. This you should know by now.

Not a comment that positively contributes to the conversation.
If we want to build a consensus and solve problems we have to be respectful to each other.

Regardless of your opinions on the technical merits of the Core position they deserve respect.

[hv_]

should be discussed by the community in as open and as free a manner as possible.

Then you make a self moderated thread?

In any case... I'd say stick a fork in it,  but it sounds like Bitmain is now planning on doing just that.  They've announced their intention to fork off onto a new and incompatible direction,  (also publicly announced that they plan to do a 72-hour selfish mine on their fork, which is ... odd to announce).

In my view, that after the near unanimous rejection of segwit2x by active developers (even BU) Bitmain announcing they're gonna do a spinoff is the final killing blow on that absurd agreement.

1. if core is perfect working code, then why does it need "fixes" such as malleability, quadratics

uh, those things are not dealing with "code" features they're limitations in the Bitcoin protocol which are fixed by segwit. Segwit is the fix and it was needed because the protocol design Satoshi had a few limitations.  There have been many softforks in the past to fix other limitations in the original design-- some performed by Satoshi himself, some performed by the current folks that maintain the software.

I'd guess, all what we will do to bitcoin from now on will be backward incompatible per se - or a hack that's shifting the time point a bit further - and than we must do that incompatible change.

The hard task is just to filter out what we NOT want to do.

I still like to see sth as open (source) as possible, small code base, minimum protocol like - multiple clients , markets decide what's best -> evolution!  

[jbreher]

also publicly announced that they plan to do a 72-hour selfish mine on their fork, which is ... odd to announce

Well, no odder than the UASF-ers (gleefully) announcing that they plan to allow that, should their chain depth overtake the legacy chain depth, all transactions ont he legacy chain would be rolled back.

Tellingly, the so-called 'selfish' mine is a direct defense against the above contingency.

[franky1]

Core will never accept any form of automatically increasing on-chain scaling as they view this as the leading to the centralization and ultimately the failure of bitcoin.

This is simply untrue, and in fact the published capacity increases plan message directly contradicts you.

HA HA HA HA HA

message:
"The particular proposal amounts to a 4MB blocksize increase at worst."

segwit is 4mb AT BEST as it requires every user to use segwit keypairs (not gonna happen) and everyone to do a certain X-in X-out tx to reach the 4mb buffer limit (not gonna happen)

message:
"Further out, there are several proposals related to flex caps or
incentive-aligned dynamic block size controls based on allowing miners
to produce larger blocks at some cost. These proposals help preserve
the alignment of incentives between miners and general node operators,
and prevent defection between the miners from undermining the fee
market behavior that will eventually fund security. I think that right
now capacity is high enough and the needed capacity is low enough that
we don't immediately need these proposals, but they will be critically
important long term. I'm planning to help out and drive towards a more
concrete direction out of these proposals in the following months."

this was in 2015... so come on wheres the 'concrete direction' months after your 2015 message

[jbreher]

1. if core is perfect working code, then why does it need "fixes" such as malleability, quadratics

uh, those things are not dealing with "code" features they're limitations in the Bitcoin protocol which are fixed by segwit.

While I have some empathy for your position here, your assertion is not quite accurate. As just one counterpoint, parallel validation renders the quadratics situation a non-issue. It does this by orphaning any and all blocks that require an inordinate amount of time to validate. All by a simple code fix - no change to the protocol required.

[XbladeX]

this agreement is joke from community . This reminds me LTC round table when 12 miners called themselves all users.
I have never been fo staing at 1MB forever but this binding segwit to HF in 6 months is joke.
HF to just increase to 2MB is weak. With HF you can add some good features to protocol why rush so much.
I don't want BTC hijacked by miners and their GREED...
this agreement is joke from 90% users running core client that are my 2 cents

[franky1]

this agreement is joke from community . This reminds me LTC round table when 12 miners called themselves all users.
I have never been fo staing at 1MB forever but this binding segwit to HF in 6 months is joke.
HF to just increase to 2MB is weak. With HF you can add some good features to protocol why rush so much.
I don't want BTC hijacked by miners and their GREED...
this agreement is joke from 90% users running core client that are my 2 cents

the barry silbert agreement is the same as the 2015 blockstream roadmap..
empty promises and wrote up by the same cartel.
barry silbert is stil part of the blockstream family..

barry silbert is still making the same empty promise of a main(base) block increase after segwit
barry silbert is just re-stirring the blockstream plan. but making it sound like its a miner decision instead of a dev decision..

when infact the blockstream and barry plans are the same..

so i agree its all a joke.. all to push segwit in.. yet give nothing realistic to users as real true benefits

[jbreher]

But the issue is that Bitmain and friends ... claim that only miners should run nodes,

Well, that's not quite true either.

In satoshi's lexicon, 'nodes' are mining entities. While the language has since been altered to include 'validating wallets' in the definition of 'node', there is little support for this terminology in the whitepaper (the caveat being nodes that have simply 'switched off' their mining capability).

The arguing about the relative merits of this change in language is probably fruitless. However, there is significant disagreement about how much power validating wallets have - either in the singular or in the aggregate. 'Bitmain and friends' merely point out that validating wallets mean essentially nothing to the network as a whole.

To misrepresent this as 'only miners should run nodes' would seem to belie either a willful ignorance or maliciousness.

[The One]

Then you make a self moderated thread?

Given the vitriol in the community on this topic I unfortunately felt that was necessary. This is the only self moderated thread I have ever started.

I have never before deleted anyone's post on any forum to date and I hope to keep this record. However the hostility around this topic necessitates the following rule.

Rule: No personal attacks.

Example: "CoinCube is a Russian agent looking to hack and take over bitcoin" would get deleted. Similar personal attacks on either miners or developers would be deleted.

What if it true you are a Russian agent? Delete it?

False personal attacks based on no evidence should be deleted.

[The One]

should be discussed by the community in as open and as free a manner as possible.

Then you make a self moderated thread?

In any case... I'd say stick a fork in it,  but it sounds like Bitmain is now planning on doing just that.  They've announced their intention to fork off onto a new and incompatible direction,  (also publicly announced that they plan to do a 72-hour selfish mine on their fork, which is ... odd to announce).

In my view, that after the near unanimous rejection of segwit2x by active developers (even BU) Bitmain announcing they're gonna do a spinoff is the final killing blow on that absurd agreement.

1. if core is perfect working code, then why does it need "fixes" such as malleability, quadratics

uh, those things are not dealing with "code" features they're limitations in the Bitcoin protocol which are fixed by segwit. Segwit is the fix and it was needed because the protocol design Satoshi had a few limitations.  There have been many softforks in the past to fix other limitations in the original design-- some performed by Satoshi himself, some performed by the current folks that maintain the software.

More details instead of generalisation would be helpful. Not everyone is going to understand what you typed.

[franky1]

But the issue is that Bitmain and friends ... claim that only miners should run nodes,

..says the guy that actually is part of the tier network creation where he and his partner forced the only vote to the pools.
..says the guy that tells the community that not being a full validating node is acceptable
..says the guy that is creating a cesspit of leaching nodes with all the stripped, prunned, lite, spv nodes...

yep pools didnt create the node cesspit concept... blockstream devs did.

blockstream should leave things like prunned/no witness for the SPV/lite brands like electrum and multibit to have... not be trying to turn full nodes into the cesspit of leacher nodes.

damn hypocrit

...
anyway gmaxwll just popped into this topic to poke the bear. so lets deal with the topic

all these proposals are just bait and switched versions of the same 'get segwit activated ASAP' while offering empty promises.
lets just get on with a proper dynamic block implementation with 1merkle where all the features and benefits can be added to full upgrade

..then everyone can have their cake and eat it..instead of all these half assed delay attempts