Pages:
Author

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

hv_
legendary
Activity: 2534
Merit: 1055
Clean Code and Scale
should be discussed by the community in as open and as free a manner as possible.
Then you make a self moderated thread? Tongue

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!  
legendary
Activity: 1946
Merit: 1055

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.
hero member
Activity: 574
Merit: 500
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.
legendary
Activity: 1946
Merit: 1055
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.
staff
Activity: 4284
Merit: 8808
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.

Quote
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.) Tongue


But it seems that this thread is offtopic now-- Segwit2x is dead, with it main miner supporter now breaking it. Time for another thread? Smiley
legendary
Activity: 1946
Merit: 1055
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.
legendary
Activity: 1946
Merit: 1055
Then you make a self moderated thread? Tongue

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.
staff
Activity: 4284
Merit: 8808
should be discussed by the community in as open and as free a manner as possible.
Then you make a self moderated thread? Tongue

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.
legendary
Activity: 3808
Merit: 1723
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?

hero member
Activity: 574
Merit: 500
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.

Quote from: franky1
-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
legendary
Activity: 1946
Merit: 1055
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.

Quote from: -ck
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:
Quote
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.
Pages:
Jump to: