Topic: The Barry Silbert segwit agreement with >80% miner agreement. (Part II) - page 2. (Read 1335 times)

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.


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.

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

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.

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.

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

Then you make a self moderated thread?

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

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

-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

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:

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.