< 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
< 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
< 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
< 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