19:00:14 <meshcollider> #startmeeting
19:00:14 <lightningbot> Meeting started Fri Jul 17 19:00:14 2020 UTC.  The chair is meshcollider. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:14 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:17 <achow101> hi
19:00:18 <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 ariard digi_james amiti fjahr
19:00:18 <meshcollider> jeremyrubin emilengler jonatack hebasto jb55
19:00:18 <provoostenator> hi
19:00:49 <emzy> hi
19:00:56 <meshcollider> Any topic suggestions?
19:01:19 <meshcollider> I don't remember anything being suggested during the weeks
19:02:39 <achow101> 2020-06-19.log:16:10 < bsm117532> #proposedwalletmeetingtopic descriptor specification for watch-only wallets, and repeated payments without address use via BIP32 paths
19:03:02 <meshcollider> Is bsm117532 around?
19:04:04 <meshcollider> I guess not
19:04:36 <achow101> hmm, that was from a while ago
19:04:44 <achow101> did we skip a meeting?
19:05:12 <meshcollider> No, but we may have missed the topic?
19:05:35 <achow101> probably
19:05:37 <meshcollider> achow101: do you want to talk a bit about current status of SQLite replacement
19:05:43 <achow101> ok
19:06:15 <meshcollider> And provoostenator maybe want to talk about your current goals? Maybe current state of hardware wallet stuff?
19:06:30 <provoostenator> Sure, but not much changed.
19:06:33 <achow101> #19334 is nominally the last step before the sqlite PR (#19077) is ready
19:06:36 <gribble> https://github.com/bitcoin/bitcoin/issues/19334 | wallet: Introduce WalletDatabase abstract class by achow101 · Pull Request #19334 · bitcoin/bitcoin · GitHub
19:06:38 <gribble> https://github.com/bitcoin/bitcoin/issues/19077 | wallet: Add sqlite as an alternative wallet database and use it for new descriptor wallets by achow101 · Pull Request #19077 · bitcoin/bitcoin · GitHub
19:06:53 <provoostenator> I'd like some feedback on #16378 now that most of its prerequisites are merged.
19:06:55 <gribble> https://github.com/bitcoin/bitcoin/issues/16378 | The ultimate send RPC by Sjors · Pull Request #16378 · bitcoin/bitcoin · GitHub
19:06:55 <achow101> but I'd like to do #19335 and #19102 first
19:06:57 <gribble> https://github.com/bitcoin/bitcoin/issues/19335 | wallet: Cleanup and separate BerkeleyDatabase and BerkeleyBatch by achow101 · Pull Request #19335 · bitcoin/bitcoin · GitHub
19:06:59 <gribble> https://github.com/bitcoin/bitcoin/issues/19102 | wallet: Introduce and use DummyDatabase instead of dummy BerkeleyDatabase by achow101 · Pull Request #19102 · bitcoin/bitcoin · GitHub
19:07:07 <achow101> both of those need 19334
19:07:39 <provoostenator> Still waiting for more blessings (and re-reviews) of #15382
19:07:42 <gribble> https://github.com/bitcoin/bitcoin/issues/15382 | util: add RunCommandParseJSON by Sjors · Pull Request #15382 · bitcoin/bitcoin · GitHub
19:08:32 <meshcollider> Ah yes!
19:08:43 <meshcollider> I almost forgot about that one
19:08:51 <provoostenator> I see it needs _another_ rebase...
19:09:55 <meshcollider> Do either of the new projects need updating with new PRs btw?
19:10:10 <provoostenator> Oh and I need to work something out with AppVeyor :-)
19:10:30 <phantomcircuit> i dont really see the purpose of sqlite as a backend unless the database interface is changed to actively query the database when you need things
19:10:43 <phantomcircuit> for sure sqlite is better than bdb, but are we really going to drop bdb support?
19:10:57 <provoostenator> meshcollider: the merged stuff can go: https://github.com/bitcoin/bitcoin/projects/15
19:11:03 <achow101> meshcollider: 19334 and 19335 need to be added
19:11:03 <jonatack> hi
19:11:27 <achow101> phantomcircuit: the goal is to actively query the database at some point
19:11:28 <provoostenator> phantomcircuit: there's some earlier (IRC) discussion about this, which should probably be linked from that PR
19:11:37 <achow101> and maybe use the relational stuff too
19:12:06 <achow101> I would like to drop bdb eventually
19:12:14 <phantomcircuit> achow101, sure, but that's going to require significant changes to the way the wallet works, also im not sure how useful that's really going to be, even for huge wallets
19:12:35 <sipa> i don't think the actual db stuff is useful
19:12:36 <sipa> for us
19:12:52 <achow101> phantomcircuit: my next major project is going to be significant changes to how transactions and stored and loaded (i.e. not loading every single tx into memory)
19:12:56 <sipa> but i think sqlite is just the most well-tested storage layer thete is
19:13:29 <sipa> exactly designed for the sort of app-level compatibility requirements we have
19:13:47 <phantomcircuit> achow101, you need to have all of the script pubkeys to quickly scan a block, is it really going to reduce memory usage that much to avoid loading the entire transaction?
19:14:01 <achow101> phantomcircuit: transactions are big, keys are small
19:14:23 <phantomcircuit> sipa, sure and i agree that sqlite is *better* than bdb, but we're gonna end up supporting both forever and that seems kind of sad to me
19:14:34 <achow101> rescans are usually a one time thing, not something people do routinely
19:14:48 <sipa> phantomcircuit: i'd day that in maybe 2-3 years the bdb support can move to some comversion tool
19:15:19 <phantomcircuit> achow101, you need the script pubkeys to scan a block as they come in
19:15:36 <meshcollider> Yeah we talked about that before, eventually it should be okay
19:15:44 <phantomcircuit> if you're reloading those from the database every time you see a new block, you're gonna have a bad time (tm)
19:16:27 <achow101> phantomcircuit: sure. for now, everything is still being loaded into memory. I would like to move the less used stuff like old txs, address book data, etc. to be loaded as needed
19:16:59 <meshcollider> This also reminds me of #16910
19:17:00 <achow101> you don't need to load that tx where every output has already been spent. we don't need those unless someone is digging through their history, in which case we can fetch it. and that doesn't really need to be performant
19:17:03 <gribble> https://github.com/bitcoin/bitcoin/issues/16910 | wallet: reduce loading time by using unordered maps by achow101 · Pull Request #16910 · bitcoin/bitcoin · GitHub
19:17:12 <meshcollider> We should try and get that in
19:17:14 <phantomcircuit> sure, but it seems like that work, which is certainly more annoying to do, should be done before adding another database format
19:17:33 <sipa> phantomcircuit: seems orthogonal to me
19:17:54 <achow101> I don't see how they're related
19:18:15 <achow101> now seems to be a good-ish time to introduce sqlite wallets for descriptor wallets only because that's a new thing for storage
19:18:16 <meshcollider> Plus the database work has already been done so it's kinda too late to say that ;)
19:19:41 <phantomcircuit> what's the point of another database unless you can leverage that it's a relational database?
19:20:12 <achow101> well the point is to get away from bdb
19:20:17 <achow101> at least initially
19:20:28 <sipa> phantomcircuit: no crazy flushing all the time to harness bdb in not needing active maintenance
19:20:35 <sipa> phantomcircuit: not needing db environments
19:20:48 <sipa> not needing a whole directory per wallet
19:21:00 <sipa> not relying on 10 year old software
19:23:02 <achow101> meshcollider: I think 18971 can be moved to "Design" in the sqlite project
19:23:55 <meshcollider> achow101: done
19:24:20 <meshcollider> sipa: is there any wallet relevant discussion re taproot at this stage?
19:24:41 <meshcollider> I've vaguely seen a lot more activity around it on twitter
19:25:05 <achow101> can we support taproot for descriptor wallets only?
19:25:12 <sipa> achow101: yes please
19:25:28 <sipa> meshcollider: not at this stage, i think
19:25:32 <provoostenator> Whaha, did anyone seriously think of adding taproot to legacy wallets?
19:25:32 <achow101> it would just mean the only waallet changes are descriptor changes
19:25:33 <achow101> I think
19:26:02 <provoostenator> We're still cleaning up the complexity from adding SegWit to that...
19:26:07 <sipa> things like musig signing integration may be a bit more involved, as it requires stateful signers
19:26:20 <sipa> but even that doesn't need to be supported in a very initial versiin
19:26:20 <provoostenator> Musig would be real cool
19:26:31 <sipa> it'll be a lot easier with musig2 ;)
19:27:32 <meshcollider> What's musig2?
19:29:07 <sipa> an improved version that is as of yet unpublished, but only needs 2 rounds, and supports transparent nesting (so if you have musig-in-musig you don't need to reveal to your cosigners that you in fact consist of multiple signers yourself)
19:30:36 <meshcollider> Ooh that sounds very nice
19:31:45 <meshcollider> With the same security assumptions as musig?
19:31:55 <sipa> mostly
19:33:07 <meshcollider> Cool, I like forward to seeing it
19:33:09 <sipa> we should have more to show soon (real_or_random and nickler really)
19:33:23 <meshcollider> Any other topics?
19:34:18 <meshcollider> #endmeeting