< bitcoin-git>
bitcoin/master b59b450 Andrew Chow: have GenerateNewKey and DeriveNewChildKey take a CHDChain as an argument
< bitcoin-git>
bitcoin/master 45f2f6a Andrew Chow: Determine inactive HD seeds from key metadata and track them in LegacyScri...
< bitcoin-git>
bitcoin/master c93082e Andrew Chow: Generate new keys for inactive seeds after marking used
< bitcoin-git>
[bitcoin] meshcollider merged pull request #17681: wallet: Keep inactive seeds after sethdseed and derive keys from them as needed (master...keep-inactive-seeds) https://github.com/bitcoin/bitcoin/pull/17681
< bitcoin-git>
[bitcoin] achow101 opened pull request #19046: Replace CWallet::Set* functions that use memonly with Add/Load variants (master...rm-load-memonly) https://github.com/bitcoin/bitcoin/pull/19046
< bitcoin-git>
bitcoin/master faf1c3c MarcoFalke: test: Replace TEST_PREVIOUS_RELEASES env var with test_framework option
< bitcoin-git>
bitcoin/master fad798b MarcoFalke: test: Default --previous-releases to false if dir is empty
< bitcoin-git>
bitcoin/master b5c423c MarcoFalke: Merge #19014: test: Replace TEST_PREVIOUS_RELEASES env var with test_frame...
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #19014: test: Replace TEST_PREVIOUS_RELEASES env var with test_framework option (master...2005-testPrevReleases) https://github.com/bitcoin/bitcoin/pull/19014
< theStack>
does anyone know why we tend to store hashes/tx-ids as integers within the functional test framework, rather thany bytes(trings)? i wouldn't know that an integer operation on a hash ever makes sense, and the reoccuring conversions via int(..., 16) are also annoying
< bitcoin-git>
[bitcoin] practicalswift opened pull request #19052: tests: Don't limit fuzzing inputs to 1 MB for afl-fuzz (now: ∞ ∀ fuzzers) (master...remove-afl-limit) https://github.com/bitcoin/bitcoin/pull/19052
< bitcoin-git>
[bitcoin] theStack opened pull request #19053: refactor: replace CNode pointers by references within net_processing.{h,cpp} (master...20200522-refactor-use-cnode-references-within-net_processing) https://github.com/bitcoin/bitcoin/pull/19053
< bitcoin-git>
[bitcoin] achow101 opened pull request #19054: wallet: Skip hdKeypath of 'm' when determining inactive hd seeds (master...inactive-seed-skip-m) https://github.com/bitcoin/bitcoin/pull/19054
< meshcollider>
#startmeeting
< lightningbot>
Meeting started Fri May 22 19:00:16 2020 UTC. The chair is meshcollider. Information about MeetBot at http://wiki.debian.org/MeetBot.
< instagibbs>
gwillen, I offered to taking on the offline signing PR if you don't have the time to champion it
< fjahr>
hi
< jonatack>
unsure if it's wallet territory
< meshcollider>
jonatack: sounds good, I'll have a look after the meeting
< meshcollider>
No topics?
< meshcollider>
Short meeting then!
< achow101>
very short
< jnewbery>
short meetings are good meetings
< instagibbs>
provoostenator_, any motion on hww signer stuff? what's next? Still debating boost?
< jonatack>
fwiw i've been looking at some BDB issues with undesired writes on what should be read-only operations
< jonatack>
and breaking when wallet file permissions are set to read-only
< jonatack>
not sure yet if it's a fool's errand
< meshcollider>
Sounds interesting at least
< jonatack>
e.g. fixing the TODOs in toolwallet.py... might reach out to people for help
< meshcollider>
achow101 might be interested because he's reworking the bdb code atm
< jonatack>
his refactoring looks like it might make things easier. the minimum start to a solution involves setting different nflag values in BDB batch
< jonatack>
but there are other issues
< achow101>
I can certainly help with that
< achow101>
although it feels a little weird to work on legacy wallets and bdb after we've basically decided to deprecate them
< instagibbs>
legacy wallets aren't close ot deprecated yet :)
< meshcollider>
We are still going to have them for a while :p
< instagibbs>
i read your release notes!
< achow101>
unfortunately
< jonatack>
achow101: ty, will ping on irc if/when blocked :)
< meshcollider>
Alright let's wrap it up for today :)
< meshcollider>
#endmeeting
< lightningbot>
Meeting ended Fri May 22 19:16:02 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< phantomcircuit>
i've been looking at using the GCS filter indexes to improve rescan performance; i've gotten to the point of wanting to generate all the possible scriptPubKey's to make the search possible; sipa suggested i ask achow101 if putting them in mapScripts made sense
< phantomcircuit>
i feel like you probably answered and i lost the scrollback
< achow101>
phantomcircuit: that doesn't make sense as I don't think mapScripts is used to check bare scriptPubKeys
< achow101>
i agree with sipa, you can just generate it at rescan time
< sipa>
due to recursion
< sipa>
like you add a private key and suddenly a previously-imported P2SH-P2WSH multisig script becomes watched
< achow101>
even if generating it each time takes a while, it'll still be faster than what we currently do for rescan
< sipa>
it'd be seconds at most
< phantomcircuit>
sipa, no i meant only adding them to the map when a rescan was requested, i could also create a new map or list or something that contains them all
< sipa>
phantomcircuit: i think that's better (that also lets you optimize the datastructure better... say use an unordered_map or a GCSFilter or whatever)
< phantomcircuit>
sipa, there's broadly two options for handling this, use the gcs filter indexes or generate a filter for all of the scriptPubKeys and walk the entire chain as we do now
< phantomcircuit>
the main issue with walking the chain now is confirming the merkle root is correct everytime we load a block
< achow101>
phantomcircuit: do both approaches require enumerating all scriptPubKeys?
< phantomcircuit>
(or at least that's what it seems to be im not actually 100% sure, but it's definitely some use of sha256)
< sipa>
achow101: yes
< phantomcircuit>
achow101, yes they do
< sipa>
phantomcircuit: loading blocks is slow; there is SHA256, but also just all the dynamic memory for all the transactions/inputs/outputs/scripts
< phantomcircuit>
im really not sure which will be faster, but it *feels* like using the gcs filter index should be
< sipa>
would be interesting to find out
< instagibbs>
jonatack, ah yeah, that PR has boost::process :)
< phantomcircuit>
well either way i need to generate all the scriptPubKeys, once that's done i can try both ways relatively easily
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #19056: rpc: Make gettxoutsetinfo/GetUTXOStats interruptible (master...2005-rpcInterrupt) https://github.com/bitcoin/bitcoin/pull/19056
< instagibbs>
provoostenator_, fjahr meshcollider I'd like to point people's attention to trying to get #17331(and it's parent PR) merged sometime soon. It's a prereq for some more interesting fee bumping work I'd like to do