Add 'Segwit capable' distinction for wallets.

[ghost]

I see lots of users asking for Segwit wallets in Bitcoin forums. I think it would be helpful to add a distinction for Segwit wallets at the Choose your wallet section if they use Bech32 addresses or nested ones, just as any other technical spec.

[prusnak]

I would suggest going even a little further and hide wallets that do not support Segwit until a user clicks a button to reveal them.

[ocZio]

@prusnak

Why? Segwit is opt-in not obfuscated-in, it is like forcing people to use p2sh instead of p2pkh...

[kyletorpey]

Average person learning about bitcoin doesn't know what SegWit is. Perhaps it would be useful to put some sort of message that says: "This wallet may have higher fees due to lack of SegWit support," or something like that. @prusnak's suggestion also good. maybe combined the two. showing more wallets would come with a warning that those wallets likely have higher fees because they lack segwit. main point i'm making: need to indicate why segwit is noteworthy.

[ghost]

@kyletorpey Yea a warning about Bech32 (currently not widely supported) and a fee discount clarification. I don't agree on hiding non Segwit wallets.

[Cobra-Bitcoin]

Like Kyle said, people visiting bitcoin.org have no idea what segwit is.

I wouldn't be in favor of adding any distinction or notice. Not even Bitcoin Core has segwit support in the wallet yet. It makes sense to do this in a year or something, but right now is too soon. Almost all big wallets have announced some intention to support segwit sometime in 2018 or sooner.

[ghost]

@Cobra-Bitcoin They will understand what 'Lower fees' mean. Right now there are wallets that support it and there's need for those.

[ApproximateSunlight]

up

[z11h]

I'd say remove the non-segwit wallet from the main page, and have them under a collapsed tab labeled "Higher-fee wallets" or something along that line. The only way to move majority of new users to segwit wallets which is good for everyone involved.

Thoughts?

[graingert]

Not worth adding until the reference client supports segwit in the GUI

[ghost]

I was rethinking this and maybe it's too premature adding this because it can be confusing for users to upgrade one time for Segwit and then another time for a lightning wallet. I think in order to maintain a single bitcoin experience and since most developing wallets will be using segwit I suggest waiting until there is production working lightning walets and only then categorize wallets by 'faster, lower fees'. and hope users will dismiss expensive wallets then. I think one can expect those ln wallets will allow onchain segwit txs as well.

[kyletorpey]

I've thought about this some more as well. I think a simple "Lower fees" vs "Higher fees" distinction would be good for each wallet page. An explanation regarding SegWit can then be added via the question mark/help button next to the text related to the fees.

I don't agree with not adding it because wallet providers have said they will update at some point in 2018. People are paying higher fees than necessary right now. The wallet directory should reflect the reality of the situation as it stands today.

I also don't agree with not adding it because it is not included in the Bitcoin Core GUI. The relevance of this would need to be explained by those making the argument.

I don't think wallets that have not upgraded to SegWit should be hidden.

[ghost]

@kyletorpey I agree with all of your points. so imo theres these 3 things the users need to know:

• Segwit for cheaper onchain txs

• payment channels (lightning)

• segwit native vs nested

[wbnns]

Since some time has passed and adoption has increased - any additional thoughts regarding the legitimacy of this issue and/or what the solution could be?

[luke-jr]

It's still preferable if people don't use segwit (unless they're also using Lightning), so I don't think this makes sense.

[ocZio]

Repeating...

@prusnak

Why? Segwit is opt-in not obfuscated-in, it is like forcing people to use p2sh instead of p2pkh...

[harding]

I agree with the remarks in this thread that casual Bitcoin users are unlikely to know what segwit is or why they should care that a wallet uses it, and so wallets shouldn't be explicitly labeled as supporting or not supporting it.

Perhaps an easy change, though, would be degrading the existing fee scoring for wallets that don't receive payments to a segwit address by default (either P2SH-wrapped or native).

@luke-jr I understand that you think the current block size is too large, but it seems unfair (and ineffective) to suggest that people who share your opinion disadvantage themselves by paying more in fees than they have to. If you want smaller blocks, you should consider instead building support for a soft fork that lowers the max block size or weight (perhaps similar to the 0.8.1 fork that temporarily lowered block size for a fixed period of time).

[luke-jr]

@harding Reducing the block max weight requires more support than it currently has. Avoiding segwit is something everyone can do immediately.

[crwatkins]

@harding Although it would be easy to implement, I can't support your suggestion for two reasons.

Perhaps an easy change, though, would be degrading the existing fee scoring for wallets that don't receive payments to a segwit address by default (either P2SH-wrapped or native).

1. The existing fee score relates to control over sending fees. I think it would be confusing to conflate the scoring of the level of control that a user has with the existence of an optimization and it would dilute the scoring.

2. I also think it would be confusing to conflate a score related to spending with an optimization for others related to receiving. I think it would be a disservice to imply that a user doesn't have control over the fees that they spend just because their wallet doesn't generate segwit addresses.

For those reasons I believe we would have to change the wording of the fee scores.

On the original subject of adding a designation for segwit, I think that would be most appropriate as part of a new scoring category that represents an entire concept instead of just a single feature, or perhaps as a standalone item in a totally new future feature/capability listing.

[harding]

@crwatkins regarding your points,

1. I think there's a (flimsy) argument to make that lack of segwit support reduces the user's control over spending fees in basically the same way lack of RBF/CPFP reduces their control. In both cases, wallets without the feature can send high fees whereas wallets with the feature can reasonably pay lower fees without sabotaging themselves.

2. Again, I think there's a flimsy argument that not having access to widely-available techniques for fee reduction is roughly equivalent to not having choice over fees. I believe the reason the scoring has the current phrasing is because in 2014 and 2015, there were many wallets that had fixed fees or fee floors above the default Bitcoin Core minimum relay feerate. (Edit: the preceding belief was incorrect.) If you think of larger-than-necessary transactions as similar to higher-than-necessary fees, I think there's a lot of similarity here.

That said, I agree it'd perhaps be better to fully rephrase fee scoring to either focus on common current fee optimizations or to make them more general so that they can apply to whatever are the current best practices (e.g. not just today's segwit but yesterday's compressed public keys and tomorrow's Schnorr and taproot/graftroot/g'root things, as well as perhaps LN).

[ghost]

@harding I think LN is such a big difference it should be be put in a totally different category/feature list.

I think another problem is that those soft fork upgrades may include many new features at once that affect many areas of your score formula. it would be nice if each bitcoin implementation used some sort of versioning for privacy, scaling, etc. like 0.17.5.1.4 meaning version 17, privacy upgrade 5, scaling upgrade 1, bugfix 4.

sorry if it sounds dumb :P