Topic: Legacy vs segwit (Read 330 times)

Thank, for your feedback and explanation about fees, I will try to use some noncustodial exchange to receive my coins on my own address.


Yes, I was aware but I wasn't knowing about the extending seeds and also the wallet backup thing. Thank you so much for explaining to me in such an easy and informative way.

it is not the method, it is the optional first byte. we don't even need that first byte to verify a message!
let me explain the process of message signing and verification, maybe that helps in understanding why it is so trivial to implement.
the part that is the exact same thing:
1. normalize the input string (message) and add a fixed predefined string (Bitcoin Signed Message:\n) to the beginning then decode (convert to byte array) using UTF8 encoding.
2. compute SHA256 of SHA256 of the result from step 1
3. pass the 32 byte result to the ECDSA function to sign and return signature (r and s).
(* there is an extra step here i'll explain below)
4. encode the signature using base64
To verify:
5. decode signature using base64
6. perform steps 1 and 2 above to get the same hash
7. recover from 0 up to 4 possible public key(s) using result of step 5 and 6 (* extra explanation below)
8. convert the result(s) of step 7 to address of same type as user entered to see if they match
9. publish result of the match to user

these 9 steps are the exact same way that you sign and verify any message using ECDSA. these are sections 4.1.3 Signing Operation and 4.1.4 Verifying Operation and 4.1.6 Public Key Recovery Operation of SEC 1: Elliptic Curve Cryptography standard.
address type doesn't make any difference in these steps at all.

---

* now the extra step explanation the part that makes things be different:
the thing about public key recovery (step 7) is that it can recover up to 4 possible public keys from a given ECDSA signature on secp256k1 curve (usually it is just one though). it still doesn't make a difference in verification since we can still recover all 4 and check all 4 to see if any match the given address. but we can help the verifier to know which public key is the correct one and by doing that reduce its work.
in bitcoin we use hash of the public key and since hash of compressed key is different from hash of uncompressed key, that also makes a difference. so the verifier has to check up to 8 hashes (addresses) instead. we can help the verifier know this too.
so far both of these are happening by adding an additional byte to the beginning of the signature. it is a number between 27 and 34.
to indicate address type (P2PKH or P2SH/P2WPKH or P2WPKH) they decided to add another value to this first byte.

so in short it is that non-standard self-defined optional first byte that is making some tools not be able to verify the signature created by another tool even if they understand the address.

The problem is that "those that cant" = "all but electrum"

I just found a discussion where you did participate where a user claimed trezor and electrum made different  signing methods...
https://bitcointalksearch.org/topic/m.50817536

i haven't closely followed the situation but i believe it has something to do with the fact that the way we currently sign messages is lacking some features which is why BIP322 exists. in fact core doesn't have other popular functionality either because of similar reasons (eg. mnemonic backups).


any wallet/tool that can sign/verify a transaction can already verify message signatures from any address type. those that can't verify messages signed from a P2WPKH or P2SH/P2WPKH addresses can't do it because that part of their application is not capable of recognizing the "address type". it has nothing to do with the signature itself since as i said, the signature is the exact same thing with the exact same process and only 1 byte difference (recid).

Can you please elaborate what you mean by the devs being hard-assed?  Are they debating another method to sign messages with a segwit key?

Back then in 2016, when there was this whole "scaling debate", the anti-Bitcoin trolls were spreading misinformation that SegWit addresses/transactions are less secure, so if you are reading old articles or discussions as a beginner you still might encounter them. But don't worry, there's nothing unsecure about SegWit, it's actually even better, because it fixed the malleability problem, and this problem caused some losses of funds, though usually not for ordinary users, but for services.

I've stayed with legacy addresses for my main funds because you never know when an airdrop or shitfork may strike. There were plenty that couldn't work with Segwit private or required signatures. And you never know, coins on quaint olde worlde addresses may become highly sought after by hipsters. We're moving into a weird future.

I don't have the technical knowledge to confirm what you are saying, but I believe you are correct.
But I think it is important that core validates that, so all wallets would simple sign and verify those messages.

For now, electrum signature cannot be verified in most of the softwares....

core devs are being too hard-assed about it in my opinion
we don't sign a message from an address. we sign a message using the private key just like we sign anything else including transactions with that private key. and the standard is already there (add a fixed string at the beginning -> double SHA256 hash -> sign -> encode with base64 with a recid).
that is what we have been doing all this time with legacy addresses and that is what Electrum continues to do with all types of addresses.

Exactly.
So, if you need to sign messages to prove that you own the funds, it is better to use a Legacy address. That's the only advantage of legacy addresses.

Agree. Even so, it is better to use a Segwit address in almost every situation.

I don't have funds in Legacy addresses anymore.

The only downside of segwit addresses is that they do not allow to sign messages. Only Electrum does, and its signature is not recognized by Bitcoin Core.

None of them are better or worse with regards to its security. Typr of Bitcoin doesn't affects its security but rather its structure. The only difference with them is that the transaction fee with segwit is cheaper than the legacy. Most of secured wallets such as Ledger are now using segwit address instead of legacy which obviously because it's cheaper thus it's a great choice to be considered.

Before know how secure your bitcoin on Legacy or SegWit address, you should know how its work. So I will prefer to read this article to understand shortly, Bitcoin Legacy vs SegWit wallet address. What is the difference ?. I am not familiar with security of address, because a wallet or clients give security of your funds. Most of exchange using nested segwit or Legacy formats to generate address but it doesn't effect on their security. If you are really much worried about security then you may use a Hardware wallet like Ledger. Segwit & legacy both type address supported by Ledger.

you are both wrong.
SegWit does not reduce transaction size in fact in some cases such as witness inside a pay to script hash (nested SegWit) the transaction size is a lot higher than a normal (legacy) transaction. that is why purpose of SegWit has never been reduction of size or fees. it helped increase capacity in a backward compatible way and solved some malleability problems.
the reason why you end up paying less fees is because fees for the past ~3 years have been calculated based on transaction weight not size and SegWit transactions have less weight.

Hello so in terms of security legacy and segwit is almost he same and still vulnerable. Ive quite noticed that exchange wallets are starting with 1 so they are still using legacy.

Ive read couples of guide about these and almost all suggest to shift on using segwit than this legacy. I think as long as we have the keys to our own wallet regardless of type it is more secure way. But I am using nested segwit address.

I read some of the responses and some are really good. I have not much idea which is most secure in between Legacy and SegWit but I use multiSig SegWit to store my coins. I also use extended seed for it. The reason I prefer SegWit over Legacy is the fees. And multiSig with extended seeds gives me extra two layers of protection.

So basically I have 2/2 multiSig wallet. One cosigner is one device and another cosigner is another device. Chances for anyone to have both device and to find both cosigner keys are very low to move funds from my wallet.

Your fund security depends on how you backup your wallet (its private key/ mnemonic seeds) and how your wallet backups work smoothly. How you keep your backups safely from threats of water, fire, and thieves (both off-line and online).

You can run wallet on your phones or computers but the vital step is backup. If you don't have backup, when you lost your devices or they get broken, you will lose bitcoin in your wallet.

Only download and upgrade wallet from official legit sites, not phishing ones. Example: Electrum vulnerability allows arbitrary messages, phishing

There are some SPV wallet like Electrum, that gives you extra security by extending seeds (their default seeds is 12, but you can extend more).

If you intend to run your wallet on mobile devices, I advice you to visit official site and get link to their apps for your OS. Don't search for wallet apps on Stores because it will put you under higher risks of fake apps in the air. Maybe you are not aware of this risk before reading my post. 

And just to add this as you asked some services do not accept the native segwit address. Native segwit addresses start with bc1, using that may be a problem. In that case, you can use nested segwit which starts with 3.

And just to add to this, if you're currently using a wallet(regardless if custodial or non-custodial) that's STILL using legacy addresses in 2020(though as far as I know like 95% are using SegWit already thankfully), please move to a different better service. One of the effective ways of sort of "forcing" services to use SegWit is to boycott them.

to be more accurate, segwit is used to reduce the transaction size which leads to reducing fees.