< bitcoin-git> [bitcoin] fanquake opened pull request #16370: depends: cleanup package configure flags (master...not_so_great_configure_cleanup) https://github.com/bitcoin/bitcoin/pull/16370
< 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 :)
< provoostenator> Some thoughs on how to apply achow101's The Box to hardware wallets: https://github.com/bitcoin/bitcoin/pull/14912#issuecomment-510520757
< instagibbs> provoostenator, cool thanks
< bitcoin-git> [bitcoin] instagibbs opened pull request #16373: Add bumpfee option to return PSBT instead of commiting to wallet (master...bump_psbt) https://github.com/bitcoin/bitcoin/pull/16373
< wumpus> meeting in about 15 minutes
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Jul 11 19:00:04 2019 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral
< kanzure> hi
< achow101> hi
< jamesob> hi
< sdaftuar> hi
< wumpus> looks like there have been no proposed topics in https://gist.github.com/moneyball/071d608fdae217c2a6d7c35955881d8a
< wumpus> does anyone have any last minute suggestions?
< sipa> hi
< midnightmagic> hello! \o/
< wumpus> hi
< meshcollider> hi
< instagibbs> hi!
< wumpus> #topic High priority for review
< wumpus> 5 blockers, and 5 things chasing concept ACK
< wumpus> anything to add/remove?
< sipa> seems not
< wumpus> no...
< wumpus> that's a short meeting I suppose then
< midnightmagic> :-)
< sipa> no wallet meeting tomorrow, right?
< sdaftuar> perhaps people can discuss what they're working on, if there's nothing else to discuss and anyone is inclined to share
< achow101> sipa: right
< sipa> if not, i have a small wallet related topic
< 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...
< bitcoin-git> [bitcoin] laanwj pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/4fcccdac785e...28d1353f4837
< bitcoin-git> bitcoin/master af5d1b5 Jonas Schnelli: Add ChaCha20Poly1305@Bitcoin AEAD implementation
< bitcoin-git> bitcoin/master 99aea04 Jonas Schnelli: Add ChaCha20Poly1305@Bitcoin tests
< bitcoin-git> bitcoin/master bb326ad Jonas Schnelli: Add ChaCha20Poly1305@Bitcoin AEAD benchmark
< bitcoin-git> [bitcoin] laanwj merged pull request #15649: Add ChaCha20Poly1305@Bitcoin AEAD (master...2019/03/chachapoly1305) https://github.com/bitcoin/bitcoin/pull/15649
< 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?
< wumpus> yes, exactly
< instagibbs> :)
< wumpus> :-)
< wumpus> instagibbs: your comments on #16227 aren't blocking right? (I was just about to merge it)
< gribble> https://github.com/bitcoin/bitcoin/issues/16227 | Refactor CWallets inheritance chain by achow101 · Pull Request #16227 · bitcoin/bitcoin · GitHub
< instagibbs> no! merge please
< instagibbs> one was confirming proper behavior based on read of code, and one is mu-nit comment thing
< bitcoin-git> [bitcoin] laanwj pushed 9 commits to master: https://github.com/bitcoin/bitcoin/compare/28d1353f4837...735d6b57e795
< bitcoin-git> bitcoin/master 1b699a5 Andrew Chow: Add HaveKey and HaveCScript to SigningProvider
< bitcoin-git> bitcoin/master c7797ec Andrew Chow: Remove CKeyStore and squash into CBasicKeyStore
< bitcoin-git> bitcoin/master a913e3f Andrew Chow: Move HaveKey static function from keystore to rpcwallet where it is used
< bitcoin-git> [bitcoin] laanwj merged pull request #16227: Refactor CWallet's inheritance chain (master...rm-keystores) https://github.com/bitcoin/bitcoin/pull/16227
< achow101> \o/
< achow101> this is going far faster than I expected
< wumpus> wallet development seems to be going quite quickly lately
< achow101> wumpus: #16301 for hi prio please
< gribble> https://github.com/bitcoin/bitcoin/issues/16301 | Use CWallet::Import* functions in all import* RPCs by achow101 · Pull Request #16301 · bitcoin/bitcoin · GitHub
< wumpus> it used to be impossible to find reviewers for wallet changes
< wumpus> achow101: done
< instagibbs> wallet gang
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #13903: Significantly reduce GetTransaction cs_main locking (TheBlueMatt) (master...Mf1808-ReadBlockFromDiskCsMain) https://github.com/bitcoin/bitcoin/pull/13903
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #13947: Dandelion transaction relay (BIP 156) (master...Mf1804-dandelion) https://github.com/bitcoin/bitcoin/pull/13947
< bitcoin-git> [bitcoin] antigaius opened pull request #16375: secp256k1/src/tests.c: Properly handle sscanf return value. (master...2019-07-12) https://github.com/bitcoin/bitcoin/pull/16375
< bitcoin-git> [bitcoin] antigaius closed pull request #16375: secp256k1/src/tests.c: Properly handle sscanf return value. (master...2019-07-12) https://github.com/bitcoin/bitcoin/pull/16375
< fanquake> I like the “what is everyone working on” idea for the meeting as well. 👍