< sipa> s7r: i believe you need gcc 7 or 8, but gcc 8.3 is in debian stable
< phantomcircuit> sipa, on the ibd latching thing, you're right that it doesn't entirely fix things if there isn't a single listening peer that has headers, but it does radically increase the number of listening nodes that can provide some headers, leaving other listening peers able to maybe provide current headers and blocks
< phantomcircuit> sipa, fixing it fundamentally requires sync from tip instead of genesis i think
< phantomcircuit> iirc sdaftuar was working on that at some point but ran into issues?
< phantomcircuit> at the very least it would need a protocol change
< sipa> phantomcircuit: perhaps, yes
< sipa> though i think that modifying everything that depends on IsIBD() just for that is still a too heavy hammer
< phantomcircuit> im not sure what the perhaps is too
< sipa> i suggested earlier that we could just start responding to GETHEADERS even when not yet out of IsIBD()
< phantomcircuit> the restriction on GETHEADERS could be changed so only serve headers past our own idea of min chain work pretty easily, but the banned for serving bad headers things complicates that
< sipa> yeah, just permitting headers server past our own min work/last checkpoint seems reasomnable to me
< sipa> *serving
< phantomcircuit> im happy to setup a pr that does that instead
< sipa> i also don't want to send you on a goose chase of trying X and Y and Z, and then only figuring out it's not a desirable solution after you've implemented it
< sipa> could bring it up in the next p2p meeting or so
< phantomcircuit> sipa, sure when's that?
< phantomcircuit> sipa, i do think the ultimate solution is to get headers from more sources
< sipa> yes, but there are a whole bunch of things to improve that
< sipa> 1) reaponding to headers requests even when in ibd
< sipa> 2) some way of letting peers know "i have no more headers for you"
< sipa> 3) detecting wgen a peer has no more headers for us, and finding another one if so
< sipa> 4) not exclusively asking outbound peers
< fanquake> s7r: I take it your using Stretch. While GCC 5 & 6 have some C++17 language features, the majority didn't arrive until GCC 7
< sipa> phantomcircuit: next meeting is march 9th, maybe a bit long
< sipa> buster is also very new... 2 weeks now?
< bitcoin-git> [bitcoin] luke-jr opened pull request #21313: More robust file/directory syncing and error handling (master...fsync_dir_pt2) https://github.com/bitcoin/bitcoin/pull/21313
< fanquake> sipa: the eighth point release of Buster came out ~2 weeks ago yea
< sipa> oh, i misread then
< fanquake> sipa / wumpus: can you block schuie2528
< sipa> fanquake: done
< sipa> achow101: is there any way of generating an xprv in the test framework?
< achow101> I don't think so
< sipa> ok, i'll just pregenerate a bunch
< sipa> it'd probably not be a bad idea to have bip32 derivation in the test framework
< phantomcircuit> sipa, that seems like a long time
< sipa> Two Weeks(tm)
< bitcoin-git> [gui] RandyMcMillan opened pull request #231: splash: new layout and new icon (master...new-icon) https://github.com/bitcoin-core/gui/pull/231
< luke-jr> #18466 might be an easy review+merge
< gribble> https://github.com/bitcoin/bitcoin/issues/18466 | rpc: fix invalid parameter error codes for {sign,verify}message RPCs by theStack · Pull Request #18466 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/fb67caebe26f...e52ce9f2b312
< bitcoin-git> bitcoin/master faa06ec Hennadii Stepanov: build: Bump minimum Qt version to 5.9.5
< bitcoin-git> bitcoin/master e52ce9f fanquake: Merge #21286: build: Bump minimum Qt version to 5.9.5
< bitcoin-git> [bitcoin] fanquake merged pull request #21286: build: Bump minimum Qt version to 5.9.5 (master...210223-qtmin) https://github.com/bitcoin/bitcoin/pull/21286
< fanquake> wumpus / sipa please block Roman-ios
< Talkless> Damn I feel so utterly helpless when using Git... I used git fetch origin pull/227/head:227; git checkout 227, but how do I now update it after PR code was force-pushed?
< Talkless> jonatack: didn't you had some sort of "tutorial" for working with Bitcoin PR's?
< Talkless> It seems I can do `git fetch origin pull/227/head` and then `git reset FETCH_HEAD`
< Talkless> ...
< hebasto> Talkless: why not to fetch updated pr into another branch?
< hebasto> it could be helpful to check diff even a pr is rebased -- `git range-diff master old-pr new-pr`
< Talkless> hebasto: yeah I though I could just rage quit, delete branch and fetch again
< Talkless> oh diffing would be better, yeas...
< Talkless> yes*
< Talkless> hebasto: that's good point, thanks
< hebasto> Talkless: yw
< jonatack> Talkless: also, if you have GitHub CLI installed: gh pr checkout --help
< jonatack> (I don't use that but should add it to that section, thanks for the reminder)
< Talkless> jonatack: interesting, I did not knew it existed
< Talkless> thanks
< michaelfolkson> Such a fan of these articles, they are great :)
< jonatack> Talkless: I do use github cli as much as I can compared to the web interface because it loads PRs much faster, but it's still WIP in terms of having all of the web features, it's getting there slowly
< jonatack> michaelfolkson: (thanks!)
< jonatack> A user named KayMining appears to be spamming the repo
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #21317: util: Make Assume() usable as unary expression (master...2102-utilAssumeUnary) https://github.com/bitcoin/bitcoin/pull/21317
< bitcoin-git> [bitcoin] practicalswift closed pull request #20383: Avoid signed integer overflow and invalid integer negation when loading malformed mempool.dat files (master...signed-integer-malformed-mempool-dat-and-rpc) https://github.com/bitcoin/bitcoin/pull/20383
< bitcoin-git> [bitcoin] luke-jr opened pull request #21319: RPC/Blockchain: Optimise getblock for simple disk->hex case (master...getblock_optimise) https://github.com/bitcoin/bitcoin/pull/21319
< luke-jr> should #19763 get backported?
< gribble> https://github.com/bitcoin/bitcoin/issues/19763 | net: dont try to relay to the address originator by vasild · Pull Request #19763 · bitcoin/bitcoin · GitHub
< phantomcircuit> sipa, im starting to think that my first thought on fixing this, just to make the algorithm for selecting which peers to get headers from be 'looser' the longer it's been since you advanced makes sense
< sipa> phantomcircuit: that'd work, i think