19:00:33 <meshcollider> #startmeeting
19:00:33 <lightningbot> Meeting started Fri Sep 13 19:00:33 2019 UTC.  The chair is meshcollider. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:33 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:39 <meshcollider> #bitcoin-core-dev Wallet 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
19:00:43 <achow101> hi
19:00:48 <instagibbs> oh hi
19:01:02 <fanquake> hi
19:01:03 <meshcollider> Topics this week?
19:01:11 <jonatack> hi
19:01:17 <sipa> hi
19:01:18 <kanzure> hi
19:01:19 <instagibbs> Last minute feature pushes? :P
19:01:33 <sipa> miniscript pretty please?
19:01:34 <jb55> hi
19:01:36 <achow101> let's merge #16341 :p
19:01:36 * sipa hides
19:01:39 <gribble> https://github.com/bitcoin/bitcoin/issues/16341 | Introduce ScriptPubKeyMan interface and use it for key and script management (aka wallet boxes) by achow101 · Pull Request #16341 · bitcoin/bitcoin · GitHub
19:01:41 <instagibbs> sipa, haha
19:02:05 <instagibbs> oh yeah #16341: I'd really like that in in not forever. It's a lot of manual looking, but not hard to track imo
19:02:08 <gribble> https://github.com/bitcoin/bitcoin/issues/16341 | Introduce ScriptPubKeyMan interface and use it for key and script management (aka wallet boxes) by achow101 · Pull Request #16341 · bitcoin/bitcoin · GitHub
19:02:14 <meshcollider> lol
19:02:20 <luke-jr> I have to go get kids at school, but how about #15987
19:02:23 <gribble> https://github.com/bitcoin/bitcoin/issues/15987 | Wallet, GUI: Warn when sending to already-used Bitcoin addresses by luke-jr · Pull Request #15987 · bitcoin/bitcoin · GitHub
19:03:28 <instagibbs> I kind of forgot to hound people for review before feature freeze, but #16727 is pretty easy
19:03:30 <gribble> https://github.com/bitcoin/bitcoin/issues/16727 | wallet: Explicit feerate for bumpfee by instagibbs · Pull Request #16727 · bitcoin/bitcoin · GitHub
19:03:40 <achow101> luke-jr: feature freeze is probably too close for that
19:03:40 <meshcollider> #15204 is the only wallet PR tagged as 0.19 at the moment I think
19:03:43 <gribble> https://github.com/bitcoin/bitcoin/issues/15204 | gui: Add Open External Wallet action by promag · Pull Request #15204 · bitcoin/bitcoin · GitHub
19:05:01 <achow101> although, looking at it gives me an idea: what if we used a bloom filter for descriptor wallet ismine rather than generating and loading every scriptpubkey?
19:05:13 <meshcollider> Basically none of these PRs have any review yet so if you want one of these in, go review it :)
19:05:15 <instagibbs> false positives lol
19:05:17 <jonatack> meshcollider: PR #16822 is tagged for 0.19
19:05:20 <gribble> https://github.com/bitcoin/bitcoin/issues/16822 | gui: Create wallet menu option follow-ups by jonatack · Pull Request #16822 · bitcoin/bitcoin · GitHub
19:06:18 <sipa> achow101: or BIP158 filter
19:06:41 <sipa> achow101: you'd generate the bloom filter on the fly from the scriptPubKeys i guess, still?
19:06:45 <achow101> on second thought, it probably wouldn't work. we still need a map of scriptPubKeys to descriptor indexes in order to be able to get the keys to sign them
19:07:13 <sipa> and false positives are not a problem; you do a full check for every match
19:08:02 <achow101> is it really that much benefit to have both a filter and all of thes scriptpubkeys?
19:08:14 <sipa> it may be much faster
19:08:27 <sipa> though, that's a question for later
19:08:46 <achow101> yes
19:08:51 <sipa> just having an explicit set of scriptPubKeys to IsMineness will be much faster than the current IsMine logic already
19:09:48 <instagibbs> good point
19:09:53 <achow101> yes
19:10:29 <achow101> although now I kinda want to know how long it takes IsMine to check that 2 GB testnet wallet that may or may not still exist
19:12:18 <meshcollider> Just checking whether a key is in a map is not that slow is it?
19:12:48 <achow101> I think std::map is O(nlog(n))
19:13:02 <instagibbs> log(n) access...
19:13:43 <sipa> std::unordered_map is O(1) (ignoring the fact that pointer size eventually has to grow O(log n) with the size of the table)
19:14:21 <meshcollider> Yeah that's a hash map right sipa?
19:15:25 <achow101> instagibbs: oh right. std::map is log(n) everything
19:16:54 <meshcollider> So I think an unordered_map of your scriptPubKeys is efficient enough without worrying about filters or whatever
19:18:27 <achow101> cool. I hadn't realized c++ actually provided a hash map
19:18:31 <tryphe> unordered map averages amort O(1) for operations, which can initially be O(n), but ordered map is always O(log n), so it really depends on how you use it.
19:18:55 <instagibbs> we're using chains of addresses we control, so hash collisions should be extremely rare?
19:18:58 <achow101> tryphe: it depends on whether there are collisions, no? or resizing, but size can be set initially
19:19:56 <achow101> not that it really matters, whatever we use will be faster than current IsMine
19:20:03 <tryphe> achow101, iirc, it does something to prevent collisions (maybe i am thinking of just QHash<>),, but i think you are right
19:22:05 <meshcollider> Yeah I think the O(n) is only the case where all n elements have the same hash and it has to linearly search through them all
19:22:10 <sipa> indeed
19:22:20 <achow101> let's just tell it to use sha256 :p
19:22:36 <sipa> we use salted siphash for hashmaps elsewhere
19:23:05 <instagibbs> more than sufficient considering wallet will control inputs
19:23:06 <sipa> which is just as good as sha256 truncated to 64 bit output
19:23:08 <instagibbs> (I think)
19:23:34 <achow101> instagibbs: people could import some weird shit
19:23:47 <instagibbs> SFTL :P
19:23:59 <achow101> actually, that wouldn't matter since each import would be its own scriptpubkeyman and thus have it's own map
19:24:11 <meshcollider> If people want to slow their own wallet down deliberately, let them :p
19:24:43 <instagibbs> actually it's a reasonable point, never know how people are going to use thew allet
19:25:01 <meshcollider> So anyway yeah in terms of PRs for 0.19, any other begs for review?
19:25:22 <meshcollider> Nothing seems particularly pushed-for at the moment
19:25:36 <meshcollider> And any other topics for today?
19:26:14 <achow101> any suggestions for having the gui inform the wallet that it's done loading transactions?
19:26:32 <achow101> context: the stuff I'm working on to not load every tx into memory
19:27:54 <achow101> the gui does some thing where it reads through every txout in order to build the transactions list. i would like it to not hammer the disk so it should do it when the transactions are initially loaded into the wallet before they are kicked out later
19:30:09 <meshcollider> It just does it once right
19:30:19 <achow101> yes
19:34:12 <meshcollider> I don't know off the top of my head but can't you do a callback thingy
19:35:51 <bitcoin-git> [13bitcoin] 15jnewbery opened pull request #16866: [wallet] Rename 'decode' argument in gettransaction method to 'verbose' (06master...062019-09-change-gettransaction-arg-name) 02https://github.com/bitcoin/bitcoin/pull/16866
19:36:01 <achow101> I guess I could just use a signal. there's some things with async that I'm not sure about (GUI has it's own thread, so may be ready before wallet is?)
19:38:46 <achow101> any other topics?
19:39:07 <meshcollider> Doesn't look like it :)
19:39:20 <meshcollider> #endmeeting