Talk:Segwit support

Active in column(s)

I added in the 'active in' column, since it looked like we might be getting random folks from Reddit adding themselves. Someone doesn't have to be active in core for their opinion to matter by any means, but people have been citing this document to counter the reality distortion field claiming that the developers of Bitcoin Core support "segwit2x" and getting a bunch of who-knows-who-they-are people on the page would break that purpose without something like this. The criteria I used was one commit since a year before the creation of the page which is an arbitrary but pretty low bar. A low bar is justifiable because some people contribute primarily in the form of review or long term changes that produce just a commit or two in a few months... but someone who isn't making a commit a year is really hard to argue as being part of the projects regardless of anything else. I believe if the criteria were upped to at least two the only change would be that Warren would drop out. If it were dropped to 6 months Decker would drop out (as he's busy with lightning). Both would be justifiable, as I don't consider either of them very involved right now-- but either way is fine. I just mention it to show that it's not overly sensitive to the parameter. Cheers --Gmaxwell (talk) 20:08, 11 June 2017 (UTC)

Sources Please

Please add sources for companies supporting BIP148. For example Bitstamp is not listed on coin.dance as in support.

company list

I removed the company list from the page because I don't see any evidence supporting most of the claims in it. If I were one of these companies and my position was misrepresented I would be very unhappy. Please get some actual confirmation before listing companies on the page. --Gmaxwell (talk) 07:13, 15 June 2017 (UTC)

PLEASE NOTE: This list is not yet complete, nor completely vetted by the parties listed for accuracy.

Company		Segwit itself	Deployment methods			Hardfork bundles (Silbert agreement)
		BIP 141	BIP 148	BIP 149	BIP 91	Segwit2x	COOP
Bitfury	miner	Prefer[1]	Acceptable			Acc. until July
Bitsquare	exchange	Prefer	Prefer[2]
Coinbase	wallet	Prefer[3]	Evaluating	Weak		Acc. until July[4]
Xapo	wallet	Prefer[5]	Evaluating			Acc. until July[6]
Blockchain.info	wallet	Prefer	Evaluating	Weak		Acc. until July[7]
Kraken	exchange	Prefer[8]	Acceptable			Acc. until July[9]
Bitstamp	exchange	Prefer[10]	Acceptable			Acceptable[11]
Bitfinex	exchange	Prefer[12]	Acceptable			Acceptable[13]
Bitpay	wallet	Prefer[14]	No			Prefer
Localbitcoins	exchange	Prefer[15]	Acceptable	Weak		Acc. until July
Poloniex	exchange	Prefer[16]	Wanting			Acc. until July
Bitmain	miner	No	No			Prefer

Can't we improve these definitions?

First, let me start with the "community support" part.

What is included, in "community"? Clearly it deliberately excludes miners... (how else could there be an apples-to-apples comparison, on "community support", between BIP 148 and BIP 141?). Ok, fine, I suppose...given that we can already measure miner support using the bit-signaling, we don't need to measure it again. But if it excludes miners, how can there be any difference between the responses for BIP 141 and BIP 91? And yet the responses are very different.

Does "community" only refer to "the technical community". In such a case, however, the table would seem to imply some circular reasoning -- how is one to know the community support, before the table is filled out? Surely we can just use the table itself, over the entries *in* the table...

And what does a "No", even mean, given that the respondent "**might or might not go along with it** with sufficient community support". This would imply the 'community support' is powerful enough to override any individual's preferences...making their response logically equivalent to the traditional meaning of the word "Acceptable", I think.

If "community" refers to businesses, we should just have them report in the table below. Why would an expert developer necessarily know anything about what a business supports?

Second, many people are answering "Prefer" for more than one column. That doesn't make sense...

In general, I feel that the table would have more legitimacy if some of this crazy were removed. I don't know how to fix it all, but a simple thing would be to add new categories, and hope that people switch to those.

Specifically, I would keep "Evaluating", and then impose an ordered series "Prefer > Endorse > Acceptable > Needs Revision > Unacceptable > LOL" ; ...where you can only promote one of your Endorse to Prefer (and you can only demote one of your Unacceptable to LOL).

Prefer = Is my personal favorite / what I would do as dictator. Endorse = I support this, and like it. Acceptable = I will support this, even though I don't like it. Needs Revision = I would support it if a few peripheral details were changed. Unacceptable = I do not support this (and would not, unless core central aspects of it were changed). LOL = This is unacceptable, and anyone who feels it is acceptable should be ashamed.

Sincerely, psztorc

"Community support" means from the entire community of users - not necessarily unanimous in the case of softforks (and it is up to each entity to decide what level of support they require for this, and when it has been met). Miners may also be users, but merely mining does not give a say in protocol changes.

BIP 141 and BIP 91 vary in the same way that BIP 148 and BIP 149 vary: they are different methods of deployment. Being okay with BIP 141 does not necessarily imply being okay with BIP 91.

Multiple "Prefer" makes sense, so long as the preferences are compatible with each other (both can be done together).

--Luke-jr (talk) 20:30, 16 June 2017 (UTC)

I see, so one would select "No" for BIP148 if they felt that the community of users was unprepared for SegWit, or felt that the community of users did not want SegWit to be activated for some reason. And someone would disparage BIP 91 if they were against "aggressive" orphaning (where aggressive is determined somewhat arbitrarily).

--Psztorc (talk) 02:03, 17 June 2017 (UTC)