Generate segwit address in receive payment tab? #11124

mb300sd commented at 5:36 AM on August 24, 2017: contributor

Now that segwit is active, should there be a check box added so the request payment button generates a segwit address? Perhaps a flag on getnewaddress as well, but it's not that inconvenient to call addwitnessaddress if you're already using CLI.

fanquake added the label GUI on Aug 24, 2017

laanwj added this to the milestone 0.15.1 on Aug 24, 2017

laanwj commented at 8:45 AM on August 24, 2017: member

Yes, this should become possible.

ghost commented at 9:45 PM on August 24, 2017: none

An option to make the change address SegWit when you send a transaction would also be nice.

Sjors commented at 7:36 PM on August 25, 2017: member

I noticed addwitnessaddress happily produces a SegWit address even if its private key has a 'legacy' address with funds.

This seems unsafe to me for two reasons:

privacy wise: when the output of both are spent, anyone can see it's the same public key and learn the addresses have the same owner
if only one is spent, the public key is known, so you lose the protection of the public key hash

Would it be better if the UI always creates a new address?

I agree with @cedenday regarding change addresses. Out of scope perhaps, but it might be useful to have a wallet setting "use SegWit". This would cause new (change and receive) addresses to be SegWit by default.

BIP 49 uses different private keys for SegWit vs. non-SegWit addresses. But BIP 44 is a prerequisite for that. See also https://github.com/bitcoin/bips/pull/456#issuecomment-324937956

sipa commented at 7:57 PM on August 25, 2017: member

The UI and RPC interface should of course always generate a new key. addwitnessaddress is a temporary approach to facilitate testing.

justnonamenoname commented at 2:52 AM on August 26, 2017: none

why not to create segwit by default without any checkboxes?

ghost commented at 3:41 AM on August 26, 2017: none

Apparently some people don't want to.

I think @luke-jr only wants to use it for lightning.

luke-jr commented at 4:17 AM on August 26, 2017: member

FWIW, I think the default should probably be to create a segwit address (provided the wallet loaded is of sufficient version). While I do support avoiding using segwit unnecessarily at this time, that should be the decision of the user, and using segwit by default makes sense here.

CydeWeys commented at 5:43 PM on September 12, 2017: none

Any updates on this? I would love to be able to start using segwit. I've been using Bitcoin Core for over six years (since it was just "Bitcoin"), and I would hate to have to switch to another client, but segwit is a really important feature that I want to use now.

sipa commented at 5:44 PM on September 12, 2017: member

Planned for the next major release.

CydeWeys commented at 5:49 PM on September 12, 2017: none

Awesome, I'm looking forward to it. Is there a rough release date planned for that yet? Are we talking a month? Many months?

dooglus commented at 7:01 PM on September 12, 2017: contributor

@CydeWeys > I would love to be able to start using segwit.

You can already. Get a new receiving address as you would normally, then do:

Help > Debug Window > Console > addwitnessaddress <address>

That will give you a SegWit address (beginning with a 3) that you can give to the person who is going to pay you.

It's not as convenient as it could be, but if you're in a hurry to start using SegWit, it works.

janmande commented at 9:19 AM on September 15, 2017: none

I have chosen this as my first attempt at getting to know, and contributing, to the bitcoin project, but would like some input on how to go about it.

rpcwallet.cpp contains the local class Witnessifier that adds a witness script to an address and is used by the addwitnessaddress function.

My idea is to add a new function in AddressTableModel called addWitnessRow that behaves the same way as addRow, but uses the Witnessifier class to add the witness script to the address. Is there a reason why Witnessifier class is not exposed in wallet.h which AddressTableModel allready depends on?

meshcollider commented at 11:22 AM on September 15, 2017: contributor

@janmande, @sipa has already taken this under his wing, but thank you for your interest in helping, there are plenty more issues to claim as a first contribution :)

janmande commented at 11:26 AM on September 15, 2017: none

Thanks for the update @MeshCollider, I'll take a look at his ( @sipa ) solution when it's done and look for other issues to dig into.

MarcoFalke removed this from the milestone 0.15.2 on Nov 10, 2017

MarcoFalke added this to the milestone 0.16.0 on Nov 10, 2017

CydeWeys commented at 8:51 PM on November 10, 2017: none

How's this looking now? It's been almost two months since the last update. I'm eagerly awaiting the ability to author segwit transactions through the GUI.

sipa commented at 8:55 PM on November 10, 2017: member

Feel free to help review and/or test the patch: #11403

A previous patch (which adds support for Bech32 addresses internally) was already merged in master but is not in a release yet: https://github.com/bitcoin/bitcoin/pull/11167

CydeWeys commented at 3:28 PM on November 13, 2017: none

So it's looking like this is currently scheduled for May? That's ... unfortunate. Segwit locked in in August, meaning that GUI implementation will be lagging by a minimum of three quarters. Segwit transaction adoption will remain low until segwit becomes the default transaction type in all major wallets, and Bitcoin Core is of course the biggest of them all.

I'm curious about the prioritization here. Bottlenecked transaction throughput and the resultant high fees are big problems facing Bitcoin, and are driving users away to altcoins like BCH. Segwit is part of the fix for this problem, and yet we're not seeing anything close to the same fervor in making segwit usable to end users as we saw in getting it locked in in the first place.

Should we be recommending that people switch to using wallets with full segwit support, like Electrum? I've been using Bitcoin Core since 2011, and I trust it, but at this point I'm seriously considering switching instead of waiting at least half a year.

CydeWeys commented at 3:36 PM on November 13, 2017: none

And Peter, this comment isn't particularly directed at you. You've done lots of excellent work over the years. I'm just ranting about the situation in general. Companies are making billions of dollars off of Bitcoin, most of them using this exact software, yet few seem willing to invest engineering effort back into the ecosystem even for such important benefits as ~doubling transaction volume through global adoption of segwit.

achow101 commented at 4:09 PM on November 13, 2017: member

@CydeWeys The release schedule is not necessarily accurate. While we normally do a time based release, 0.16 will likely be a feature based release and released whenever it is ready which will probably be some time before May.

montvid commented at 11:23 AM on December 8, 2017: none

Yes, it is a big shame that the project adopts segwit but forgets to fix the gui wallet. And then Greg Maxwell dares to say that people don't seem to care about lower fees @ https://www.youtube.com/watch?v=EHIuuKCm53o&feature=youtu.be&t=1h15m06s

jonasschnelli commented at 7:23 AM on January 11, 2018: contributor

Since #11403, it's selectable via startup argument, config. A GUI setting is proposed in #11937.

laanwj commented at 7:03 PM on January 18, 2018: member

Closing, this is implemented in #11991

laanwj closed this on Jan 18, 2018

MarcoFalke locked this on Sep 8, 2021