< bitcoin-git>
[bitcoin] fanquake opened pull request #16371: trivial: build: ignore osx_volname & add it to clean-local (master...ignore_osx_volname) https://github.com/bitcoin/bitcoin/pull/16371
< jnewbery>
provoostenator: from the base bitcoin directory: ./test/functional/test_runner.py $(for f in test/functional/wallet*; do echo $f | xargs -n 1 basename; done)
< provoostenator>
jnewbery: thanks!
< jnewbery>
better: ./test/functional/test_runner.py $(for f in test/functional/wallet*; do basename $f; done)
< jnewbery>
or you could just cd to test/functional I suppose :)
< provoostenator>
cd'ing into test/functional is suboptimal, because I often do: make -j20 && make check && test/functional/...
< shesek>
provoostenator, I don't know what's the context here, but cd'ing inside a subshell might be helpful, e.g. make -j20 && make check && (cd test/functional/ && foobar)
< shesek>
this will keep the same cwd in your shell
< * luke-jr>
wonders why make check doesn't run the functional tests ;)
< wumpus>
*originally* because the functional tests required python whereas the rest of the build did not
< luke-jr>
could skip them when Python isn't found
< wumpus>
this hasn't been the case for a long time
< luke-jr>
no?
< wumpus>
configure doesn't even pass without python, does it?
< provoostenator>
shesek: cool!
< provoostenator>
make check indeed requires (a non messed up) python somewhere along the way
< luke-jr>
wumpus: I thought it did
< luke-jr>
I guess probably nobody is testing it without Python
< wumpus>
i'm fine with having python as required dependency of the project, it has become the de-facto standard cross-platform scripting language
< luke-jr>
wumpus: there are platforms without it (eg, Android)
< luke-jr>
Perl still seems to be a bit more ubiquitous
< luke-jr>
I guess the most portable is POSIX sh
< wumpus>
definitely not saying that it's the *most portable*, but it seems a good compromise nowadays
< wumpus>
oh yes and i meant 'required build time dependency', not run-time dependency, native android has no gcc and toolchains either so as a build platform it's useless anyway :)
< jamesob>
at this rate assumeutxo'll be done by 2028
< sdaftuar>
so you're saying it's going to be done at some point :)
< instagibbs>
jamesob, woah there, why so optimistic
< jamesob>
good points
< wumpus>
jamesob:sure
< jamesob>
thanks
< sipa>
topic suggestion: explicit privkey derivation through descriptors, or generic support for all signingproviders?
< wumpus>
#topic explicit privkey derivation through descriptors, or generic support for all signingproviders?
< sipa>
so, right now (and correct me if i'm wrong), i think the only way to get a private key for a xpub-derived key, is by having a descriptor that encapsulates it, and then expanding it at the right position
< sipa>
which is a weird restriction i think; signingproviders can contain keys, and derivation paths for derived pubkeys... they have all the information necessary to compute derived privkeys in general
< sipa>
i'm suggesting this because i'd like a bitcoin-psbt tool that you just give psbts and utxos and descriptors and keys and figures out what it can do
< sipa>
but if a psbt contains a pubkey derivation field, and you have one of the parent privkeys available, we *should* have enough to sign
< sipa>
but afaik the current structure doesn't permit that
< achow101>
sipa: you'd be missing the chaincode
< sipa>
achow101, meshcollider: does this make any sense?
< sipa>
achow101: ugh right... thanks :)
< sipa>
it's not that easy
< sipa>
i guess end of topic, back to drawing board :)
< sipa>
ack sdaftuar's topic to share what people are working on
< meshcollider>
That seems like a weird situation to be in anyway, if you have a descriptor and it's private keys in your wallet then why wouldn't you have included the privkey in the descriptor in the first place
< sipa>
meshcollider: yeah but from a generic psbt perspective, if you have an xprv for example, and a psbt that claims the need for a key derived from it... it feels like you should be able to use it
< sipa>
i think the point is that psbt assumes your "keystore" consists of xpubs/xprvs more than it assumes just individual leaf keys
< sipa>
but i'll come up with something else :)
< wumpus>
#topic what people are working on
< wumpus>
feel free to say something about what you're working on, or want to review-beg for a PR etc
< * sipa>
working mostly on miniscript, still a lot of design and proof of concept... no PRable code yet
< achow101>
i'm working on native descriptor wallets (take 2) based on the SPKManager stuff
< sdaftuar>
i'm working on an ATMP refactor to support package relay, and generally working on p2p improvements
< sipa>
cool
< instagibbs>
in review mode these days, focusing on wallet. With proper motivation you can bug me to review your scary p2p/consensus code :)
< sdaftuar>
i'm also happy to be pinged to review (if anyone has a PR they think i should look at)
< wumpus>
thanks for sharing everyone; I'm pretty much in review mode too at the moment
< wumpus>
I think that concludes the meeting, maybe it's good to have this as recurring topic like "high priority for review"
< sdaftuar>
+1
< sipa>
agree
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu Jul 11 19:25:53 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< achow101>
sipa: meshcollider: in native descriptor wallets, do you think it makes sense to populate a CKeyMetadata for each scriptpubkey? I don't think that really makes sense, but I feel like it's necessary for getaddressinfo to give usable info. or is just the descriptor in getaddressinfo enough?
< achow101>
also, does key birth time really matter?
< instagibbs>
key time affects some rescan logic IIRC
< instagibbs>
maybe not anymore though...
< achow101>
only the time of the first key
< achow101>
afaik individual key birth times are only used in getaddressinfo and dumpwallet
< wumpus>
right, the key birth is only used to determine where to start rescanning
< sipa>
achow101: is it just for birth times?
< achow101>
sipa: I don't think the keymetadata is being used for anything else. it's just for information to display to the user (or in dumpwallet)
< sipa>
i think in a descriptor wallet individual keys shouldn't have birth times; the descriptor/record itself can have a birth time though
< achow101>
right
< instagibbs>
the descriptor already stores everything else except the derivation index, which I presume can be calculated somehow
< achow101>
instagibbs: we will be storing in memory the index for each scriptpubkey generated
< achow101>
so given a scriptpubkey, we can find the index and get the rest from the descriptor
< wumpus>
CKeyMetadata does have some other fields too: version, hdKeypath, hd_seed_id, key_origin
< wumpus>
don't seem to be relevant there though
< sipa>
all the other information becomes implicit
< wumpus>
right
< achow101>
version is just ckeymetadata version. the hd stuff can come from the descriptor itself
< sipa>
yup
< instagibbs>
nice
< instagibbs>
achow101, these scriptpubkeys are never dumped from memory? ever-growing in other words?
< achow101>
my idea was to have a GetMetadata function which the ScriptPubKeyMan would populate when a metadat was requested instead of storing metadata. but this doesn't really work well when a descriptor isn't just a single key descriptor
< instagibbs>
I mean we already do that today, so stupid question :)
< achow101>
instagibbs: yes, but we already do that for keys, so...
< instagibbs>
is there scripted-diff docs somewhere in the repo?
< wumpus>
I don't think so, but it's simply sh script, best way to find examples would be to look at 'git log --grep="BEGIN VERIFY SCRIPT"'
< bitcoin-git>
[bitcoin] jonatack opened pull request #16374: test: Enable passing wildcard test names to test runner from root (master...enable-passing-wildcard-files-to-test-runner-from-root) https://github.com/bitcoin/bitcoin/pull/16374
< instagibbs>
ok so it's just a thing you can run in your own repo, check the diff, got it, not validated in travis or anything
< sipa>
it is validated by travis
< sipa>
travis reruns the script, and verifies that the commit exactly matches the diff it applies to the repo
< instagibbs>
ok, so the magic to make this happen is -BEGIN VERIFY SCRIPT-\n<scripttorun>\n-END VERIFY SCRIPT- in commit message?