< wumpus>
strange, how to get an old wallet to generate a p2sh-segwit of bech32 receiving address? I don't seem to be able to from the GUI, I've done -upgradewallet and it upgrades the wallet in the log, but still, I get a 1xxxxx address when I generate a receiving address (and I've tried to uncheck "generate legacy address"
< wumpus>
fwiw it did "Performing wallet upgrade to 169900" "Upgrading wallet to HD" "Upgrading wallet to use HD chain split"
< wumpus>
we might want to disable that checkbox completely in this case
< achow101>
wumpus: the wallet version shouldn't matter
< achow101>
try setting addresstype=p2sh-segwit?
< wumpus>
I've done that, didn't work, I don't think that's supposed to affect the GUI. Also checked that it did work with a new wallet.
< wumpus>
I was asking in case the answer was obvious and I was missing soething, but apparently not :) I'll investigate deeper later, have some administration to do now
< achow101>
it's supposed to effect the gui and it has been for me (at least addresstype=bech32 does)
< provoostenator>
addresstype=bech32 should indeed affect the GUI, but it merely changes the default checkbox. 1x addresses suggest a different problem.
< sdaftuar>
gmaxwell: i wonder if we should just revert #14897 for 0.18? i would like those changes to go in but i'm nervous about the edge cases we have overlooked thus far, which result in things like tx relay failing en masse and fill-up-your-memory attacks.
< gribble>
https://github.com/bitcoin/bitcoin/issues/14897 | randomize GETDATA(tx) request order and introduce bias toward outbound by naumenkogs · Pull Request #14897 · bitcoin/bitcoin · GitHub
< sdaftuar>
(well, maybe the memory issue is just in the bugfix PR, i need to re-read aj's comment)
< gmaxwell>
Probably but otoh, backports appear to be a waste of time.
< gmaxwell>
(beyond the most recent major version)
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #15841: test: append node stderr and stdout if it exists (master...1904-testLogStdErr) https://github.com/bitcoin/bitcoin/pull/15841
< luke-jr>
gmaxwell: well, in this case a backport would be to 0.18 ;)
< gmaxwell>
oh that was supposted to go into 0.18.
< gmaxwell>
Did it get missed? :-/
< luke-jr>
oh, nm, I see it there, just didn't get noted on github
< luke-jr>
… or I just somehow entirely didn't see it :/
< instagibbs>
MarcoFalke, do we normally close issues when someone opens a related PR? (re 15841)
< luke-jr>
I guess after reviewing the code, I ended up scrolled past the backport stuff
< sipa>
15617 is in 0.18 (commit 238ef336929606632f0564e417ee0b6fd649c2a9)
< MarcoFalke>
instagibbs: Usually we don't
< MarcoFalke>
But I close my issues when no one has picked them up, which shows a lack of interest