Talk:Segwit support

From Bitcoin Wiki
Jump to navigation Jump to search

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