Topic: How to stay with legacy address format? (Read 1771 times)

May I ask you, if all the above addresses point to the same Bitcoin private key (wallet) how did you generate them? Is there any tool where you can create a SegWit address out of a valid private key?

You are right that a hardfork that doesn't include segwit would get ignored by the majority of the community and would therefore become irrelevant, but Bitcoin Cash was also supposed to become irrelevant. I mean don't get me wrong, it's pretty irrelevant, but if you managed to dump at the top, that was a lot of "free BTC", and it looks like all you need to get a hardfork and some hashrate is a couple rich people with the right tools (propaganda, buying hashrate and then pumping the price on the markets) to get a hardfork going.

Even if eventually it becomes and irrelevant altcoin, there's a period of time that if you make hte right moves you can profit from the clusterfuck and get yourself free BTC from the fools that are buying the hardfork.

If someone with the enough resources decides to hardfork BTC into another fork that has no segwit and has 16 MB of blocksize, you want to be able to get your share of coins and dump it, and if you are holding everything on segwit you are going to need to move all of your wealth into the original format, which once again it's a problem since you can't send all of your BTC in a single transaction if you want to retain privacy, same goes for when you want to dump your coins, so you would need to go through a real annoying process of separating transactions.

In the event of a hard fork, anything can happen, including allowing for anyone to steal coins in non-segwit addresses. A hard fork can change any consensus rule; there are no restrictions, so even having your coins in non-segwit addresses would not be safe. This is only a problem if you expect that a hard fork should happen that everyone agrees to that would allow anyone to steal segwit outputs. That would mean that there would only be one blockchain. However IMO any such hard fork would be contentious (after all it would allow for stealing funds) and there would most certainly be two blockchains - the original which still has segwit activated, and the one that does not have segwit activated and thus coin theft.

Since LN uses segwit, yes, such a hard fork could result in stolen funds there too.

---

I don't understand why you are so concerned about such a theoretical hard fork. It would be a hard fork to deactivate segwit, which means that it would be contentious and lead to a chain split like Bitcoin Cash did. All that would happen is that a new altcoin is created. The thing is, with hard forks, anyone can make a hard fork at any time that changes any consensus rule, including allowing for the theft of coins. For example, I could make a hard fork right now which simply allows me to steal all of your funds right now. But that fork would be an altcoin, and no one would pay attention to it. I think you are giving too much credit to such a hard fork even existing, let along being a threat to anything. If such a fork happened, it would almost certainly be ignored by the majority of users and just become another worthless altcoin.

Well, that kinda sucks to be honest. On that case, I will be sure to keep my long term storage coins in the original bitcoin format, and use segwit for transacting, but not storing the coins (and I will still use the classic format for transacting if the fees aren't too high)

In the case a hardfork, what would happen to your BTC if the BTC are held in a lightning network hub/channel thing? You would also lose them so you need to move them back to a legacy format address?

No, there is no workaround. Read what I said again:

What I described later is how miners would actually spend the segwit outputs to steal your money. There is no workaround to not have your money stolen after such a hard fork. The only thing you can do is sent all of your coins to non-segwit outputs before the fork happens.

From what I understand in this part, you will not lose the coins and there's a workaround, but I don't really understand the process.

What you described needs to be done pre-split or can you do it post-split? (meaning that, if you are holding coins in native segwit addresses, you will not lose them in the fork that has no segwit) because if it requires you to do something pre-split in order to not lose the coins, this may be bad to convince people to use the native segwit format, specially long term hodlers that don't pay daily attention to what's going on and just sit and relax on their coins for years without checking news and price. Im sure there are a lot hodlers that still didn't even know Bitcoin Cash happened.

Yes. That is the human readable part of bech32 and will be the same for all bech32 addresses. Bech32 addresses are different from the legacy addresses (1.. and 3..) since it uses a different encoding.

Bech32 uses a different encoding scheme which is case insensitive unlike the legacy address scheme which is case sensitive. Legacy addresses are encoded with base 58. However bech32 encodes things with base 32 which does not include any casing.

The address should be invalid. It is case sensitive, so that would be wrong.

Since segwit has already activated, such a fork would result in you losing any and all money that is in a segwit output, both nested and native. This is because such a fork without segwit would regard all of those outputs as anyone-can-spend outputs and the miners who initiated that fork would steal all coins in segwit outputs and send them to themselves.

To actually spend those, for native outputs, you would just have an empty scriptSig and it would work. For P2SH nested ones, you would just put the redeemscript in the scriptSig and it would work. There would be no place for signatures to go.

Sorry for so many question, but I got additional ones:

-I see that bech32 addresses have bc1 at the beginning, is this the part that will always repeat to recognize the segwit transactions?

-I also noticed that there isn't a single character with capital letters. How come there are no caps at all? Im used the classic format and seeing it all in small characters is pretty weird. Im not even sure of legacy format being caps sensitive, but I think it was easier to recognize the shape of the address if there are caps on and off or maybe that is how my brain works.

About caps sensitive.. what would happen if instead of 12sziC91z7hwfpVDNw7UbsisaapBwFtW7t you send BTC to 12szic91z7hwfpvdnw7ubsisaapbwftw7t ?

-In the case of a split into a fork of BTC that doesn't support the segwit format... how would you receive your share?

For example if the BCH fork happened after segwit got activated and you were holding 1 BTC in address bc1qzjw3jywhf2r7k24y3gqj0fs4apddg03pujsjzx, how are you supposed to receive your 1 BCH on the other chain?

As many as you want.

Native segwit addresses (bech32) make native segwit outputs which are smaller than the P2SH nested ones (3.. addresses). This saves you 22 bytes when you go to spend the output.

That sounds good, I hope that the GUI is user friendly when managing the different wallets. How many wallet.dat files can you manage at the same time? I would like to have a "savings one", "spending one", another one for segwit addresses.. etc.



What is the difference between using the native segwit format (that begins with b) from the one that begins with 3?
Is it just a temporal way to use segwit until the ones that begin with b are available or there are any pros and cons?

When somebody asks you for your Bitcoin address because they want to send you some, give them the bolded address.

12sziC91z7hwfpVDNw7UbsisaapBwFtW7t
337cKTRkrmfXHMRKgk1xosqsEY6dToRD7h
bc1qzjw3jywhf2r7k24y3gqj0fs4apddg03pujsjzx

Each of those represents the same Bitcoin key, but they are very clearly different.  You will always be able to use the legacy Bitcoin address format, aka the first one.  I can't imagine any wallet software not letting you see a legacy version address of any of your public keys.

No, you do not need to run two different softwares with their own datadir. Bitcoin Core has functionality now to have multiple wallets loaded at the same time. This is known as multiwallet. So how it would work is that you create one wallet which is set to only ever make segwit addresses, and another wallet which is set to only ever make non-segwit addresses. When you want to send, you choose the wallet you want to send from. When you want to receive Bitcoin, you choose the wallet you want to receive to and you will get an appropriate address. Note that this is all still in development and still in the design phase, so this could change and not be the actual final design.

I see... but isn't that a bit of a mess? If I want to run a full node, now I need to run 2 different folders with 2 different software with 2 different clients just to go between formats?

Wouldn't it be better to have it all inside the same software and be able to select what you want or maybe that would make newbies too confused and it's better that newbies use segwit by default (since they don't know anything about this anyway and sometimes excess of options make newbies stressed)? But then again, advanced users like myself would suffer from having to run 2 softwares..

We don't know yet. It will likely be an option you set for that wallet specifically (we have multiwallet, so you can have a wallet only for legacy addresses and one only for bech32). I'm not sure if P2SH nested addresses will be supported as that is mostly a shim for people to be able to use segwit while native segwit addresses (bech32) was still being worked on.

But how will it work? Will there be 3 buttons?

Like,

Button 1 = Generate new legacy address
Button 2 = Generate new bech32 address
Button 3 = Generate new P2SH nested address

How do we keep this user friendly?

I also hope that you tidy up the addresses list so you can keep everything in better order. I would like to see a way to order by date of creation, and also by address format, otherwise it will be even more of a mess than it is now when sometimes you need to reach for older addresses in your ever-growing list.

Many wallets already have segwit support built in but disabled by default (like Armory). You should expect most wallets to release new versions with segwit enabled in the next few weeks. Bitcoin Core will be adding support for bech32 addresses and the P2SH nested addresses soon in a minor version after we release 0.15.0.

I see. So how are we supposed to get people using segwit format transactions if there isn't an easy way to create them? Does any wallet support segwit transactions yet without having to resort to unfriendly command lines?

I just hope it gets added easily at GUI level AND it is clearly separated from legacy transactions for the people that want to keep using the classic format. For example I want to be able to use the classic format for long term cold storage because it's the most timetested format. I don't care to temporarily use it if needed for small LN transactions or whatever.

Bitcoin Core currently has no functionality to create Segwit addresses (either P2SH nested ones or bech32 ones) in the GUI. Thus all addresses you get from the GUI are non-segwit and anyone who sends to those will be making non-segwit outputs. The legacy Bitcoin addresses did not have their definitions change.

AFAIK there is no indications on Core's gui on how to create a Segwit address. But you can do it by using the command "addwitnessaddress addr" where addr is an existing P2PKH or P2SH address of yours[1].

You can know your address is not a Segwit one because every Segwit address starts with a "3" (just like a multi-signature address). Because of that, I don't think you can differentiate a Segwit address from a regular P2SH multi-signature address.

[1] https://bitcoin.stackexchange.com/questions/57832/how-to-generate-segwit-address

Yeah but like i said, how do I know if I create a legacy address or a segwit address?

Im using Bitcoin Core 0.14.2 and there is no "create segwit address" button, it's just the same good ol interface, so there's no separation between legacy and segwit, that is what is making me confused. There's not a clear way to do this in the GUI.