< jonasschnelli>
Or how would we later distinct between hd generated keys and imported keys?
< jonasschnelli>
A simple metadata bit would be sufficient but I prefer 8205 (adds the keypath to the metadata)
< luke-jr>
jonasschnelli: I think that conflicts with key origin?
< jonasschnelli>
luke-jr: in Knots?
< jonasschnelli>
We could use a different version number...
< jonasschnelli>
And Knots should do some migration to keep compatibility between Core
< luke-jr>
IMO just merge [old] key origin first seems to make the most sense?
< jonasschnelli>
Agree. Not sure what's holding back the key origin PR... Something was controversial? Currently phone typing and can't check.
< Chris_Stewart_5>
Is there a slight difference in a GetHeaders message and a GetBlocks message where one includes the hash stop and the other doesn't?
< sipa>
indeed
< sipa>
no idea why this is the case
< Chris_Stewart_5>
Hmm well that makes me feel better. Thanks
< GitHub165>
[bitcoin] MarcoFalke opened pull request #8319: [qa] wallet*.py: Check for salvagewallet regressions (master...Mf1607-qaSalv) https://github.com/bitcoin/bitcoin/pull/8319
< MarcoFalke>
^ Hmm, apparently this runs fine with -usehd=0, but fails with -usehd=1.
< GitHub137>
[bitcoin] KrzysiekJ opened pull request #8320: Fix 0.12 release notes on block relaying (master...0.12-release-notes-block-relaying) https://github.com/bitcoin/bitcoin/pull/8320
< luke-jr>
jonasschnelli: well, we don't really have someone designated to maintain the wallet right now - so I'd think the merging falls to you or wumpus primarily :p
< luke-jr>
but I guess first either youuu or I need to revise the PR to simply the old code (IIRC that was the conclusion last discussion)