Topic: Is there any chance 0.15 will have segwit support anytime soon? (Read 800 times)

Yes, it will.

I don't remember the actual behavior. I don't think it will upgrade the database.

Here's a question: Are BDB forwards compatible? If I force a build with-incompatible-bdb and it's a newer version than what the existing wallet has, will that be able to read and work with the existing wallet? Will bdb keep using the old format on disk or upgrade the database?

Ah thats great. I thought you would need to keep your segwit addresses in a different wallet because it wasn't compatible with an already-existing wallet.

Im still using the old pre-HD format, will I have any problems generating segwit addresses on there? Also on the GUI, will we get a better way to order our list of addresses? right now is just a straight list that you can only order alphanumerically. I would like to have more options than that. Maybe by format, date of creation.. etc. We need more columns.

You will be able to use both in the same wallet.

GUI support for multiwallet is not yet complete and not available in 0.15.0. It should hopefully be complete for 0.16.0.

You are right, maybe we should give it more time and see if the transactions go up while leaving the legacy format as default, but if we want newbies to use it, at some point it must be the default, because newbies can't be bothered to look around with settings.

And btw, if you are receiving transactions in a legacy format address (for example, the BTC I receive for the signature campaign, which is paid in a legacy format address) could I use bc1 addresses within that same wallet, or I would need a new wallet for that? Because im not sure if they can be mixed within the same wallet, or you would need a wallet for legacy addresses, and a separate new wallet for bc1 addresses.

Thankfully, as far as I know, Bitcoin Core 0.15 allows for multiple wallets at the same time. I haven't tried it yet so I wonder how it looks like on the GUI.

It's being worked on right now. The final details of what will happen are not yet final. You can read the discussions on #bitcoin-core-dev to see what we are thinking of for this. You can also read what was discussed about this at the Bitcoin Core in person meeting here: http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2017-09-05/. Please note that all of this is currently not final and no final decision will be made until a PR with the functionality is merged.

---

The current idea that will probably be implemented is as follows: two command line options will be added which determine which type of address is given out and which type of change address is used. These will have the option to be set to P2PKH, P2WPKH (bech32), and P2SH-P2WPKH. One of these will be the default, but which one is still up for debate. When a new address is requested, it will be witnessfied in the same (or a similar) way to how addwitnessaddress works. Additionally there may be options to choose which type of address you want, but that functionality is still being discussed. The getnewaddress RPC will likely have a new parameter that allows you to specify the type of address that you want to use.

---

As for the time frame of when these changes will happen, that is still unknown. It will hopefully be happening within the next few weeks.

---

New versions of BDB are backwards incompatible so you cannot downgrade your wallet if you wanted to (this happens with BDB minor versions too) and that is a bit of a usability problem. Also, newer versions of BDB have licenses incompatible with Bitcoin Core's license.

I don't think it's gonna happen like that (although I don't think the decision on this is final yet)


Segwit is a soft fork, and so it really does make more sense to make it opt-in, not a default. Sure, it should be clearly labelled and simple to opt into, but making it the default straight away obscures the choice from the user. I mean sure, there aren't many good reasons to continue to use P2PKH or P2SH (i.e. legacy type) transactions now, but there are just a few (including "unreasonable" reasons, such as continuing to do business with any users that might refuse to use Segwit addresses or compatible clients).

I can imagine it becoming default in later versions, but not yet. The users should really lead the move to make Segwit transactions the general standard, the developers can then respond to that appropriately.

But how will it look like? I would like it to be very user friendly. Segwit addresses should be the default new addresses, so normal people can click generate address and they get a native segwit address ready to use, but give us advanced users the possibility to keep generating original format addresses as usual (the ones that begin with 1)

I recommend devs to hear this guy, he explains it here, how the GUI should be like:

https://www.youtube.com/watch?v=wExvvOOa7YI&t=1h14m38s

I think he is spot on. Don't confuse people and make it easy. Make segwit the default from now on, advanced features for the rest. (the only mistake he says is that the format should be the one that begins with a 3, I think that format is not as ideal as the bc1 one, bc1 one should be the new default one.)

Armory 0.96.2 has been out a few weeks, Segwit addresses is enabled in 0.96.2 (Armory has a track record of adding the more advanced wallet capabilities earlier than other wallet software does)

Let alone 0.15, I just downloaded armory and found that P2WPKH option is greyed out. Hmm

But is there any estimate when that will be? It's been "coming soon" a long time.

0.15.1 will have native segwit support from what I know atm.

the latest revision of ref client needs a segwit support. When will that be added? And why it still uses berkley db 4.8? Wouldnt it be more suitable to opt for newer versions of db