What do you think of this change on the GUI

[cellard]

I would like to have a slideable menu that is next to the receiving tab just like this:



The current situation is this one:



What do you think of that idea of having the 3 different formats in there? seems ideal in my opinion.

You could set the default one to be nested and eventually bech32 but make it easy for people to choose whatever format they want on the fly.

[1715033217]

1715033217

[1715033217]

1715033217

[1715033217]

1715033217

[1715033217]

1715033217

[Rath_]

What's the point of keeping legacy? If some services are still not compatible with Bech32 then Nested should work just fine. Your GUI edit looks pretty good but it would confuse newbies which probably don't see any difference between these three types of addresses. Don't you think that there should be a short description of every type of address? I guess that Bech32 won't be a standard wallet because some services still have problem with this type of address.

[RNC]

Looks good, written is visual studio by the looks of it so are you using RPC to a local full node or does the program go out on 8333 ?

is the "3" for Segwit in the combo ?

Does this wallet use microsoft AES encryption behind the Secp256k after keys are exchanged ?

Good job we now have BigInts to play with or we would be stuffed.

[cellard]

What's the point of keeping legacy? If some services are still not compatible with Bech32 then Nested should work just fine. Your GUI edit looks pretty good but it would confuse newbies which probably don't see any difference between these three types of addresses. Don't you think that there should be a short description of every type of address? I guess that Bech32 won't be a standard wallet because some services still have problem with this type of address.

What's the point of not keeping it? Some people will only accept legacy payments and they have they right to do so, and people have their right to use legacy at any time.

It would not be any more confusing than having that "Generate Bech32 address" button which already exists there.

And like I said, this could be hidden by default and shown if you enable advanced features on the menu.

In any case, noobs in general don't use full nodes. Anyone using a full node knows what that is anyway.

[achow101]

What's the point of not keeping it? Some people will only accept legacy payments and they have they right to do so, and people have their right to use legacy at any time.

It would not be any more confusing than having that "Generate Bech32 address" button which already exists there.

And like I said, this could be hidden by default and shown if you enable advanced features on the menu.

In any case, noobs in general don't use full nodes. Anyone using a full node knows what that is anyway.

The idea to use dropdowns came up frequently in discussions on how to support getting segwit addresses in the GUI. We decided to stick with the checkbox approach because we want to encourage users to use segwit. The only reason to have the checkbox is to let people use bech32 addresses when they want to and default to backwards compatible p2sh-segwit addresses. There's little reason to use legacy addresses except out of principle (i.e. those who hate segwit). For such people, they can start Bitcoin Core with addresstype=legacy, and hopefully those options will be available from the settings menu too (there's an open PR for that).

[Rath_]

In any case, noobs in general don't use full nodes. Anyone using a full node knows what that is anyway.

Actually, I often see that many people, in my country, recommend using either Bitcoin Core or Electrum as a first wallet. Usually, most newbies decide to use Electrum because it doesn't require you to download lots of data. I have met quite a lot people who didn't know about SegWit at all.

There's little reason to use legacy addresses except out of principle (i.e. those who hate segwit). For such people, they can start Bitcoin Core with addresstype=legacy, and hopefully those options will be available from the settings menu too (there's an open PR for that).

Oh, I almost forgot about people who would rather increase the blocksize. Well, even if Legacy wasn't included they still could use another software or even a paper wallet.

[Kakmakr]

I think it is an exellent question. Most newbies are not even aware that there are different formats and by adding the formats, they would be forced to do some more research, before they simply use the default option.

Legacy addresses should be retained until everyone has migrated to SegWit. We would never know if something might happen in the future <exploit found in SegWit> and then people might want to resort to using the Legacy wallet.

[jnano]

What do you think of that idea of having the 3 different formats in there?

I like it.

While it adds more complexity, the UI already suffers from not being very friendly. I think Core caters to a different audience anyway.

There's little reason to use legacy addresses except out of principle (i.e. those who hate segwit).

What's the actual-bytes transaction size (or, well, per-input size) in the case of P2SH-P2WPKH versus P2PKH or "legacy" single-key P2SH?

Is it currently possible to sign a message with a P2SH-P2WPKH address?

[achow101]

What's the actual-bytes transaction size (or, well, per-input size) in the case of P2SH-P2WPKH versus P2PKH or "legacy" single-key P2SH?

The actual byte size for a P2PKH input is 148 bytes. For a P2SH-P2WPKH input, it is 171 bytes. For a P2WPKH it's also 148 bytes.

However the actual byte size doesn't really matter. Blocks are not limited by size but rather by weight. And transaction fees are actually by weight or virtual size (weight/4) and not actual size. So th weight for a P2PKH output is 592. For P2SH-P2WPKH it is 360 and P2WPKH it is 268. So as you can see, the segwit inputs consume less weight and are thus cheaper to spend.

Is it currently possible to sign a message with a P2SH-P2WPKH address?

No. There is no standard for signing messages with segwit addresses yet. That's something that is being worked on. Note that messages aren't actually signed with an address. Rather they are signed with a public-private key pair which can correspond to multiple addresses. Your wallet software will calculate the public key for a message and convert that into an address. A wallet could just as easily show you a P2SH-P2WPKH or P2WPKH address instead of a P2PKH address when it is verifying a signed message. What needs to happen is a specification for signing messages with a script which can thus be generalized to signing with an address. Such messages and signatures would actually correspond to addresses and not a public key which your wallet just turns into an address.

[jnano]

So as you can see, the segwit inputs consume less weight and are thus cheaper to spend.

I know, but I was thinking in terms of actual blockchain size increase, not fees.

What's the input size for non-Segwit P2SH?

Note that messages aren't actually signed with an address.

I know, but that's how it's exposed in Core. The current lack of this feature is one reason I can see for some people still wanting to use P2PKH addresses.

[cellard]

True, but i think those who hate SegWit no longer use Bitcoin or already use altcoin which don't use SegWit.

Ehh.. actually the majority of people using Bitcoin still use legacy addresses, as measured by this website at least:

http://segwit.party/charts/

Now if they hate segwit or not is another history, but it would be a big mistake to pretend to kick people that for whatever reason hate segwit out of Bitcoin. If they don't like segwit, no one can force them to use segwit, they can continue using legacy, and Core shouldn't drop easy access to legacy addresses, it should be accessible from the menu.

And so far anyone registering on this website using Core, the first thing they should do is get a legacy address and stake it on the "stake your address" thread in case you lose your account, because for now segwit addresses can't do the job for signing and verification.

So I would like to see that drop down menu, and again, if they want to push segwit adoption I understand it, they can hide it by default just like Coin Control features are hidden, just let anyone that wants to use it enable it in the menu.

[achow101]

What's the input size for non-Segwit P2SH?

It depends on the script wrapped by the P2SH address. It could be 0 bytes, or it could be 10000 bytes (the maximum scriptsig size).

[Rath_]

And so far anyone registering on this website using Core, the first thing they should do is get a legacy address and stake it on the "stake your address" thread in case you lose your account, because for now segwit addresses can't do the job for signing and verification.

As far as I know, Electrum has no problem with signing messages with both Nested and Bech32 type of address. Although, you can verify signed message with these types of address only using the latest Electrum, it seems that their implementation isn't compatible with others. The lack of standard takes its toll. This feature is quite popular, Bitcoin Core Team should fix it in the next version.

Github issue: https://github.com/bitcoin/bitcoin/issues/10542

[cellard]

And so far anyone registering on this website using Core, the first thing they should do is get a legacy address and stake it on the "stake your address" thread in case you lose your account, because for now segwit addresses can't do the job for signing and verification.

As far as I know, Electrum has no problem with signing messages with both Nested and Bech32 type of address. Although, you can verify signed message with these types of address only using the latest Electrum, it seems that their implementation isn't compatible with others. The lack of standard takes its toll. This feature is quite popular, Bitcoin Core Team should fix it in the next version.

Github issue: https://github.com/bitcoin/bitcoin/issues/10542

Yeah I know. I wonder what happened... wasn't it able to reach a consensus to get a standard on all wallets to deal with segwit addresses? I wanted to get my coins from the Electrum wallet into my Core wallet and I found out that you can't import your private segwit keys from Electrum into Core because of the lack of compatibility, so it means I will need to send coins to myself from one wallet into another... well thank god that the fees are pretty low at least for now.