< luke-jr> can someone tag #15801 for 0.18 backport before it gets forgotten?
< gribble> https://github.com/bitcoin/bitcoin/issues/15801 | Bugfix: GUI: Options: Initialise prune setting range before loading current value, and remove upper bound limit by luke-jr · Pull Request #15801 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] sdaftuar opened pull request #15834: Fix NOTFOUND bug and expire getdata requests for transactions (master...2019-04-fix-getdata) https://github.com/bitcoin/bitcoin/pull/15834
< fanquake> luke-jr done
< luke-jr> thx
< bitcoin-git> [bitcoin] ajtowns closed pull request #15776: Expire inflight GETDATA requests (master...201904-inflighttxtimeout) https://github.com/bitcoin/bitcoin/pull/15776
< aj> fanquake: mind replacing 15776 in high-pri list with #15834 ?
< gribble> https://github.com/bitcoin/bitcoin/issues/15834 | Fix NOTFOUND bug and expire getdata requests for transactions by sdaftuar · Pull Request #15834 · bitcoin/bitcoin · GitHub
< fanquake> aj sure
< bitcoin-git> [bitcoin] jonasschnelli opened pull request #15836: Add feerate histogram to getmempoolinfo (master...2019/04/feeinfo) https://github.com/bitcoin/bitcoin/pull/15836
< 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)
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/0c9de67f343c...e2b5fdee0068
< bitcoin-git> bitcoin/master e377846 João Barbosa: rest/rpc: Make mempoolinfo atomic
< bitcoin-git> bitcoin/master e2b5fde MarcoFalke: Merge #15474: rest/rpc: Make mempoolinfo atomic
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15474: rest/rpc: Make mempoolinfo atomic (master...2019-02-atomic-mempoolinfo) https://github.com/bitcoin/bitcoin/pull/15474
< 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)
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/e2b5fdee0068...429a7cf34fa8
< bitcoin-git> bitcoin/master fad81d8 MarcoFalke: test: Fixup creatmultisig documentation and whitespace
< bitcoin-git> bitcoin/master fab6a0a MarcoFalke: test: Add test that addmultisigaddress fails for watchonly addresses
< bitcoin-git> bitcoin/master 429a7cf MarcoFalke: Merge #15831: test: Add test that addmultisigaddress fails for watchonly a...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15831: test: Add test that addmultisigaddress fails for watchonly addresses (master...1904-testMulti) https://github.com/bitcoin/bitcoin/pull/15831
< bitcoin-git> [bitcoin] nkostoulas opened pull request #15838: scripts and tools: Fetch missing review comments in github-merge.py (master...2019-04-fix-merge-script) https://github.com/bitcoin/bitcoin/pull/15838
< bitcoin-git> [bitcoin] sdaftuar opened pull request #15839: [0.18] Revert GetData randomization change (#14897) (0.18...2019-04-revert-14897) https://github.com/bitcoin/bitcoin/pull/15839
< bitcoin-git> [bitcoin] abitfan opened pull request #15840: Contrib scripts: Filter IPv6 by ASN (master...dnsseeder) https://github.com/bitcoin/bitcoin/pull/15840
< instagibbs> is there a static fully valid pubkey somewhere in the Core codebase to reference in say unit tests?
< sipa> use the generator? :)
< instagibbs> "no" is also an acceptable answer
< gmaxwell> The generator is a fully valid pubkey...
< sipa> 0x0279BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798 FYI :)
< sipa> (with secret key 0x0000....00001)
< instagibbs> indeed, hence "no", I'll have to make it
< sipa> instagibbs: i'm confused
< instagibbs> im asking if it's in the core codebase, it's not confusing at all
< instagibbs> "make your own" is fine
< sipa> sure; it's hardcoded in secp256k1
< instagibbs> it's all ok
< sipa> ok.
< instagibbs> functional test harness has static keys for quick reference when wallet isn't compiled in, was just checking if that existed
< MarcoFalke> instagibbs: ADDRESS_BCRT1_UNSPENDABLE or self.nodes[i].get_deterministic_priv_key().address ?
< instagibbs> right I've used those, was just curious about C++ land
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/429a7cf34fa8...dae72998e857
< bitcoin-git> bitcoin/master fa46ac3 MarcoFalke: bench: Add wallet_balance benchmarks
< bitcoin-git> bitcoin/master fad7c33 MarcoFalke: refactor: Add handleNotifications method to wallet
< bitcoin-git> bitcoin/master dae7299 MarcoFalke: Merge #15779: test: Add wallet_balance benchmark
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15779: test: Add wallet_balance benchmark (master...1904-benchWallet) https://github.com/bitcoin/bitcoin/pull/15779
< MarcoFalke> instagibbs: ADDRESS_BCRT1_UNSPENDABLE is also in cpp ;)
< MarcoFalke> Just merged a second ago
< instagibbs> :shakes fist:
< instagibbs> thanks
< * luke-jr> wonders if #15617 should be backported
< gribble> https://github.com/bitcoin/bitcoin/issues/15617 | p2p: Do not relay banned IP addresses by sipa · Pull Request #15617 · bitcoin/bitcoin · GitHub
< 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
< instagibbs> got it