< Chris_Stewart_5>
Was there a bug in master recently related to -datadir?
< wumpus>
Chris_Stewart_5: not that I know o, what kind of bug?
< Chris_Stewart_5>
Ooh, nvm. Seems it might have been related to a systemd config
< wumpus>
right
< jonasschnelli>
sipa_: a) is the master key fingerprint optional?
< sipa_>
jonasschnelli: where?
< jonasschnelli>
sipa: in the descriptor. :)
< jonasschnelli>
would ... pkh(d34db33f/44'/0'/0':xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/1/*)
< sipa>
that's valid
< jonasschnelli>
also work as pkh(xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/1/*)
< sipa>
yes of course
< jonasschnelli>
Oh... NM, that is already implemented..
< sipa>
it just doesn't have key origin info if you don't specify it
< jonasschnelli>
Is a key origin always fingerprint & path or can it just be the fingerprint?
< sipa>
it can just be fingerprint
< sipa>
in case the path is empty
< jonasschnelli>
okay... but that wouldn't not imply that the fingerprint must be the related xpubs fingerprint?
< sipa>
uh, i guess it would be
< sipa>
yeah, there isn't much sense in that case, i guess
< jonasschnelli>
I'm asking because the fingerprint could also be a hint to the signing device without revealing the path
< sipa>
or at least it should be enforced
< jonasschnelli>
sipa: would it make sense to always support 'h' as hardened key indicator...
< wumpus>
Chris_Stewart_5: yeah that one should be merged...
< phantomcircuit>
Hello
< Chris_Stewart_5>
sorry, RAPIDCHECK=1 in DEP_OPTS
< wumpus>
Chris_Stewart_5: and it makes sense to have it enabled for at least one travis build if it's merged, after all, otherwise it'll probably get under-tested
< phantomcircuit>
i'm working on implementing poll on *nix systems, the first step is to cleanup ThreadSocketHandler to separate the select() logic from the rest of the logic
< wumpus>
oh topic
< wumpus>
#topic poll() (phantoncircuit)
< Chris_Stewart_5>
wumpus: I'll try to take care of that in the next 2 days
< phantomcircuit>
i've started that in #14147 (which is as far as im going to go in that particular pr)
< wumpus>
Chris_Stewart_5: I mean it'd be perfectly valid to say you don't want to hold up this PR for that, and do it later
< wumpus>
Chris_Stewart_5: just be clear :)
< phantomcircuit>
next step after that is going to be to separate the socket handling logic from the select() logic
< wumpus>
phantomcircuit: good
< gmaxwell>
phantomcircuit: my understanding is that your refactors are driven by a more complete set of commits that go all the way to actually enabling poll, you just haven't PRed the ret, right?
< phantomcircuit>
gmaxwell, right
< wumpus>
so enabling poll turns out to be more work than was expected, I was told at some point it'd basically be a five-line patch, or is this because you want to do it properly? :)
< sipa>
it seems we're pretty close on track for the 0.17 release schedule
< gmaxwell>
he's doing it more properly.
< gmaxwell>
ISTM at least the current PR is a perfectly fine change even considered independantly of poll().
< phantomcircuit>
doing it more property, there's a smaller patchset possible but that does things like iterate over every fd for every cnode looking for it's own fd
< phantomcircuit>
which is O(n^2) worst case for n = vNodes.size()
< phantomcircuit>
so probably dont want to do that
< wumpus>
ok, yes, that would be good to avoid, we don't want to worsen performance
< wumpus>
right, thanks for the explanation, it's common for people to underestimate how much work something is anyhow :)
< gmaxwell>
I think I made the 5 line comment before, but it was based on an actual ~5 line patch that matt was previously using. :P
< phantomcircuit>
and indeed the current patchset is specifically selected to make sense even without poll() (but that's certainly why im doing it)
< wumpus>
should we add 14147 to high priority for review? I suppose it's blocking further work for you
< phantomcircuit>
poll() works more like epoll than select, specifically there's no equivalent for FD_ISSET, so either you need to keep some sort of mapping or iterate over them
< phantomcircuit>
i believe matts patchset just iterated which is trivial but certainly not what we want to do
< wumpus>
indeed
< wumpus>
it was just aproof of concept then
< sipa>
makes sense
< phantomcircuit>
wumpus, im building off that pr for the rest of the poll() logic assuming it'll eventually be fine
< phantomcircuit>
there's 7 commits to that pr and 100 loc changed but mostly that's just moving things
< BlueMatt>
I mean iterating is essentially fine, really
< gmaxwell>
It's a nearly trivial review in any case. It's just moving things around.
< BlueMatt>
its not like we're handling 10k connections
< gmaxwell>
?w=1 eliminates 90% of the diff. :)
< BlueMatt>
(and less error-prone than tracking things with CNodes)
< BlueMatt>
cause we've had errors in the past with CNode deletion ordering....
< BlueMatt>
or, if not errors, shitloads of complication that made review hard
< gmaxwell>
I agree that iterating is fine for a few hundred connections, but I think we'd prefer to avoid it unless we really do get mired in review.
< wumpus>
anyhow, let's review phantomcircuit 's work
< BlueMatt>
wumpus: yea, fair
< wumpus>
I don't see the point of discussing this now
< BlueMatt>
yep
< wumpus>
if it's really so hard to review (there's nothing what people have said that would suggest that) then of course we can look for another solution
< wumpus>
any other topics?
< gmaxwell>
+1
< gmaxwell>
sipa: wumpus: Where did we ever land in replacing the openssl RNG?
< wumpus>
#topic replacing the openssl RNG
< wumpus>
good question, I think that kind of stranded at some point
< sipa>
gmaxwell: i don't feel like spending much work on it
< gmaxwell>
It would be nice if we could finally be rid of the dependency in 0.18.
< sipa>
but we should probably write some requirements for what it needs to be replaced with
< wumpus>
ok so someone would need to pick up sipa 's old work probably
< gmaxwell>
I think in part because we reasonably wanted to break some of it off into a library, and then that sounded like too much work. :)
< sipa>
yes
< meshcollider>
Is there an old PR or something
< wumpus>
I don't care about that part anymore
< meshcollider>
Or a gist
< moneyball>
suggested topic: Tokyo CoreDev topic ideas
< gmaxwell>
I'd be happy to do something, but I also really don't feel like making a library right now. (or rather, I'd prefer to spend that time working on something else)
< wumpus>
just put it in its own subdirectory under src, someone that wants it as library can do the work for that
< wumpus>
if not, there's no need to do build system work etc
< gmaxwell>
(in particular, librarizing it is hard because a library ought to be reentrant and probably C callable ... which are things that don't matter much for our own use)
< wumpus>
I know all too well how frustrating making libraries for c++ is
< wumpus>
yesl et's start piling up other requirements as well
< wumpus>
ok, another topic?
< gmaxwell>
luke-jr: So one of the things we could do for it would be rewrite in C, but thats something that people don't feel like doing.
< provoostenator>
Probably continue the coin selection fun?
< wumpus>
let's rewrite it in rust !
< moneyball>
wumpus suggested topic: Tokyo CoreDev topic ideas
< kanzure>
hi.
< wumpus>
#topic Tokyo CoreDev topic ideas (provoostenator)
< sipa>
CoreDev topics: descriptors and extensions to them
< kanzure>
already on there
< jtimon>
rust all your problems
< kanzure>
what would you guys like to hjear from other people, and/or from yourselves
< moneyball>
kanzure has reached out to some folks, and i plan to as well to solicit topic ideas. also feel free to share them here as you are already doing :)
< wumpus>
jtimon: I have C/C++ burnout
< kanzure>
oh no that's terminal
< jtimon>
wumpus: well, you write python too :p
< wumpus>
jtimon: python is still somewhat cute
< * jonasschnelli>
can't be in Tokyo :/
< achow101>
kanzure: moneyball: what are the current topics, if any?
< gmaxwell>
I'd like to see kallewoof's progress on input grouping get done.
< gmaxwell>
Maybe people could think about rhavar's bustapay... I think it might be reasonable to support it in the bitcoin core wallet.
< gmaxwell>
lattice-based digital signatures?!?!
< kanzure>
who would be a good candidate to fly the flag of bustapay
< kanzure>
gmaxwell: it's a meshcollider thing
< moneyball>
here is what kanzure has collected so far, from about 10 people:
< moneyball>
* partially signed bitcoin transactions
< moneyball>
* hardware wallet support
< moneyball>
* script validation
< moneyball>
* input grouping
< moneyball>
* output descriptors
< moneyball>
* Schnorr signatures BIP
< moneyball>
* k-of-n threshold signatures using Schnorr
< moneyball>
* forward blocks
< moneyball>
* hardware wallet support in Bitcoin Core
< moneyball>
* status of client-side filtering and neutrino
< moneyball>
* client side filtering
< sipa>
please don't paste long lists in IRC
< meshcollider>
Heh I don't think it's worth discussing lattice sigs at CoreDev
< moneyball>
oh, sorry
< meshcollider>
That's just what I'm working on
< achow101>
kanzure: re bustapay, me? I was part of the meeting that came up with the basis for that
< kanzure>
okay it is you
< kanzure>
done
< jnewbery>
maybe offtopic for now, but how is bustapay different from p2ep?
< wumpus>
nah pasting 12 lines which are relevant topics isn't that bad, but yes, never do that with error messages / logs pelase :)
< BlueMatt>
"forward blocks"
< BlueMatt>
?
< instagibbs>
BlueMatt, maaku's thing
< instagibbs>
IIRC
< kanzure>
BlueMatt: time travel exploit
< achow101>
jnewbery: it's basically the same thing, but actually implemented
< gmaxwell>
jnewbery: actually implementable and not woo.
< kanzure>
moneyball and i will be heckling each of you for more topic suggestions soon, thanks for the input
< achow101>
it cuts out some of the complexity as a tradeoff for a possible and very small (IMO) privacy risk
< BlueMatt>
ah, right, the exploit-timeward-to-change-blocktime-and-fork-to-lock-it-in thing....I feel like thats something that needs more broad bitcoin-dev or whatever discussion, its not something to be discussed a technical planning meeting
< wumpus>
do you need even more topics? seems a decent list
< kanzure>
this list is tiny compared to last few times; it'll grow.
< BlueMatt>
dandelion, depending on who's there, should be discussed
< wumpus>
none trivial
< jtimon>
kallewoof: has been working on a "signet" branch I'm currently reviewing and testing that allows the creation of signed blocks testchains ala elements, not sure if that could be a topic, but I would be very happy to see something like that get into master at some point
< instagibbs>
BlueMatt, ACK
< sipa>
agree with BlueMatt as well
< kanzure>
jtimon: added
< kanzure>
BlueMatt: added
< gmaxwell>
agree with BlueMatt as well
< BlueMatt>
agree with BlueMatt as well
< BlueMatt>
wait, hmmm
< kanzure>
don't do that you'll break the universe
< sipa>
try typing 'google' into google
< michagogo>
Or ‘recursion’
< BlueMatt>
Did you mean recursion?
< sipa>
BlueMatt: it was an it crowd joke
< provoostenator>
Something that might be worth putting in the meeting minutes: multiple PR's are suffering from 500 server error for multiple days. Apparantly Github is aware of the problem.
< * BlueMatt>
emailed support and got back a "we're looking into it, its visible on a few projects"
< achow101>
do we have so many PRs and issues that we broke github?
< wumpus>
github is falling apart, so soon after ms took it over
< sipa>
nah, it was falling apart before
< wumpus>
I think they switched the server hosting to windows 95
< sipa>
haha
< wumpus>
if it helps I'll send a mail too
< luke-jr>
at least not ME
< wumpus>
haah then it would alrady be gone
< kanzure>
other topics?
< gmaxwell>
WinCE.
< michagogo>
How did everyone get a bionic gitian environment working?
< meshcollider>
MS haven't actually taken over yet have they
< luke-jr>
michagogo: I ended up installing from the iso by hand
< sipa>
jonasschnelli: to be clear, if you have an xpub without key origin in a descriptor, it'll still report a fpr/path in its expansion; just one with fpr = xpub's short id, and empty path
< jonasschnelli>
ok
< sipa>
i think i'll add a test that if you supply a key origin with empty path, its hash matches the xpub's short id
< michagogo>
Okay, I'm now running bionic
< michagogo>
And yep, looks like now the build's working
< michagogo>
So, hey, looks like my new i7-8750H is quite a bit faster than my i7-3610QM :D