Segwit support?

[DJviolin]

I just spent 40USD a few days ago getting out of my money from warpwallet with Electrum client, because it doesn't support segwit. Is there any ETA to support it?

[JamesTheAwesomeDude]

According to Subhan Nadeem's article on Hackernoon,

if you send a SegWit transaction using a SegWit wallet right now, you save 30%–40% on transaction fees instantly.

and

If every transaction in the Bitcoin network was a SegWit transaction today, blocks would contain up to 8,000 transactions, and the 138,000 unconfirmed transaction backlog would disappear instantly. Transaction fees would be almost non-existent once again.

It costs upwards of $20 to make a transaction these days. WarpWallet seems like hands-down the best brainwallet in existence now, but deez fees are no joke

SegWit is great, WarpWallet is great..can we get a mashup of these 2 great things?

[dabura667]

Currently there is no WIF format for segwit, so the second you copy the private key, other wallets have no way of knowing how to encode that private key into segwit...

I keep thinking of writing a BIP to cover all these new segwit wallet types... everyone is all over the place. Electrum created some new "ypub" and "zpub" thing for extended keys... but since Electrum doesn't allow exporting of individual private keys, he didn't bother to think of a new format for WIF keys...

[JamesTheAwesomeDude]

So, @dabura667 you are raising a specific concern over SegWit wallets not being properly recognized as such / having no way to be reliably imported into existing wallet software?

I know that it would be better to weight the software in this list: https://bitcoincore.org/en/segwit_adoption/ by popularity, but even just a cursory visual examination shows green rows for roughly well over half all the entries.

So the concern over whether or not the SegWit wallets can be imported seems a secondary issue, and furthermore out-of-scope for this project to worry about? Just display them to the user clearly labeled (as are the private-vs-public keys currently), so he/she knows exactly what options to select when importing the key into their wallets?

Also, as long as the cryptography remains the same, then if precisely the same underlying ED25519 private keys are used for the generated "regular" and "SegWit" wallets, there is practically zero concern over "lost" funds by sending to the wrong address, right?

[dabura667]

It’s less of a concern, and more of a practicality.

I do not know of any single wallet, with the exception of bitcoin core via “importprivkey” and “addsegwitaddress” rpc commands in order, that allows you to import/sweep an individual private key and specify that it is segwit.

So you would either need:

1. All wallets to add logic to select segwit or non-segwit during sweeping/importing.
2. Add the segwit/non-segwit info into the WIF key and have all wallets add logic to read the segwit flag and sweep accordingly.

The former requires that the user remembers what kind of segwit they used, and a naive user could easily forget, import the key as is, see the non-segwit address and freak out.

Whereas encoding the segwit flag in the key itself will make legacy wallets choke on it and break. They will say “invalid WIF key” if they don’t support segwit, and if they do support segwit, they won’t even have to ask the user what type it is.

tl;dr you could add segwit, but it would cause problems for naive users.

[dabura667]

Wait... warpwallet only outputs WIF keys, and not HD keys, right?

[JamesTheAwesomeDude]

Re:"problems for naive users"

$20 transaction fees are a problem

Just add a message highlighting the difference between a SegWit wallet and an "old wallet" to the user. With a message to the effect of

[SegWit Private Key]==[SegWit Public Key] [Regular Private Key]==[Regular Public Key] Remember: these wallets are completely separate! And you'll need a wallet software that supports SegWit to use the SegWit one!

and ya good

Within the year they better be standard anyway, considering the fact that they literally bandaid the situation to satisfaction as it stands now, if everyone starts using them.

"But what if the user gets confused / loses his keys / whatever" nor "but what if the user has a wallet that can't import it" seem like a reason against at least providing the user with the option for 30% to 40% lower fees..

[DJviolin]

Electrum supports segwit addresses, but even if you encrypt your wallet file, the mnemonic seed created before that step. So I think the private key is not salted with a passphrase, only the wallet file that you use in electrum?

[dabura667]

[SegWit Private Key]==[SegWit Public Key] [Regular Private Key]==[Regular Public Key]

That would be a great idea............. if there was a difference between [SegWit Private Key] and [Regular Private Key]

My concern is that currently, there is no segwit private key format! lol

You should write a BIP and make one. Currently all discussions I have had ended in "oh but everyone uses HD wallets anyways so yprv and zprv should be fine." (referring to Electrum's new encoding for HD keys where segwit keys change from xpub and xprv to zpub and zprv or something like that.)

Your example is great, and I would love to see the yprv and zprv equivalent in non-HD WIF format keys.

I am not against supporting segwit. I am just telling you the facts. There is no WIF format for segwit, so in order to support segwit, someone needs to decide on a format, and wallets need to support sweeping that new format otherwise it's pretty useless.

[JamesTheAwesomeDude]

@dabura667

I thought that this wallet exists already

So furthermore if there's no difference between the private keys, is it just a matter of telling your wallet to use it "as" a SegWit key?

In which case, the only thing required to add support is just to display the SegWit version of the public key, then; if the private key format is identical / the same private key can be used for a SegWit and old-style wallet, right?

All we gotta do is display

• Private key
• Old-style address
• SegWit address

appropriately labeled with warnings about "your client better support segwit to use this second address" and such?

[dabura667]

Currently, private keys starting with:

5 = “please use uncompressed public keys”
L or K = “please use compressed public keys”

So if you showed a segwit address (which, segwit requires compressed public keys by the way) and a private key with a 5 at the beginning, importing that private key into any wallet will say “oh, you want to use the address generated from the uncompressed pubkey non-Segwit address.”

We need a new format... we could modify the 0x01 compression byte to 0x02 for segwit p2sh and 0x03 for native segwit.....?

But to be honest, since that wouldn’t change the L or K at the beginning of the key, people would get confused... and if we’re going to make a forwards incompatible format anyways, bech32 encoding is much better.

The major problem is that any proposal to create a new format for individual private keys will likely get shot down. Individual private key management is deprecated in favor of HD private key management.

[dabura667]

If any wallet software imports a “5” private key and generates a segwit address, it is incorrect.

Electrum had a use case for new formatting extended keys, so now they are going through the process of getting it standardized via a BIP proposal.

If warpwallet wants to do something similar. Someone will need to go through the same process if you want any wallet to be able to import it.

[leptonitron]

Couldn't you just paste the legacy private key "5" from warpwallet into this: https://www.cryptocurrencytools.org/# (segwit converter) ? Of course you would want to be on an airgap machine.

[junderw]

@leptonitron Looking at the results from that tool you linked:

1. When I pasted a WIF key that started with 5 (uncompressed) it automatically ignored it, and converted it to a compressed key (K or L). While it is true that Segwit forbids uncompressed keys. We are dealing with money here, so "oh I'll just automatically fix the mistake one person made in this way I think is best" can lead to a different wallet saying "oh, this is a 5 wallet, let's throw an Error"... now a user needs to think about which wallet they use and why and where and what format to save in etc... THIS IS WHY WE HAVE BIPS PEOPLE! Normal people do not have the skill or capacity to think about these things, so we need to define standards and not change things willy nilly.
2. The WIF private keys for "Segwit Address" and "Bech32 Address" change the version byte of the compressed WIF key from 0x80 (128) to 0x82 (130) and 0x81 (129) respectively. I have yet to see any BIP that defines this behavior... but it does seem reasonable. (However, many people in the community of developers think that individual private keys are no longer necessary as HD keys (BIP32) are more useful. I tend to agree with them.

[leptonitron]

@junderw THANK YOU!

[stopfeds]

Just went quickly through the code and I fear that a simple change in the source code isn't enough. Huge parts need to be changed due to the reasons mentioned above.

It's a pity...

[junderw]

@dabura667 is 100% correct.

There is no standardized methodology for encoding script type into WIF keys.

Not to mention keybase and all of its cryptocurrency focused projects are dead. So arguing anything is a moot point tbh.