19:03:54 <wumpus> #startmeeting
19:03:54 <lightningbot> Meeting started Thu Aug 16 19:03:54 2018 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:03:54 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:03:56 <jonasschnelli> Yeah... hi
19:04:03 <meshcollider> hi
19:04:07 <promag> hi
19:04:12 <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark mi
19:04:16 <wumpus> chagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator
19:04:24 <gmaxwell> darn, just beat me to it.
19:04:29 <achow101> hi
19:04:33 <sipa> hi
19:04:43 <wumpus> apparently I divided michagogo in two
19:04:55 <sdaftuar> ouch
19:05:24 <meshcollider> Hope he's not too cut up about it
19:05:25 <wumpus> PSA: we've tagged 0.17.0rc1, let us know if you have any trouble gitian-building due to the upgrade of the guest to Ubuntu 18.04/bionic
19:06:31 <jonasschnelli> As mentioned its a bit sad that we dropped debian 9 (newest version) as gitian host,... but apparently compiling lxc was simpler then expected
19:06:36 <wumpus> now that 0.17 release cycle is started, it might be time to bring back "high priority for review" as a topic
19:07:10 <wumpus> I have some instructions for debian 9 here: https://gist.github.com/laanwj/c62e101bfd68718f0686926dfd10666b
19:07:27 <jtimon> hi
19:07:29 <wumpus> (yes, you need to build lxc and debootstrap from source)
19:07:32 <jonasschnelli> Nice wumpus
19:07:43 <wumpus> we should probably integrate that into the documentation
19:08:25 <jonasschnelli> Yes. Until lxc 2.1.1 is supported by debians apt
19:08:40 <wumpus> yes, 3.x is probably overkill
19:08:59 <luke-jr> wumpus: did we ever get a solution for making a bionic base VM? :/
19:08:59 <jonasschnelli> Works fine here with 2.1.1
19:09:09 <luke-jr> (for qemu)
19:09:17 <achow101> also, with the suite bump, don't forget to do bin/make-base-vm again
19:09:29 <wumpus> luke-jr: I don't think so, I think LXC and Docker are the only options at the moment
19:09:34 <luke-jr> achow101: last I checked that doesn't work
19:09:42 <achow101> luke-jr: there's a fork of vmbuilder that works for bionic
19:09:59 <achow101> luke-jr: https://github.com/newroco/vmbuilder
19:10:06 <luke-jr> #link https://github.com/newroco/vmbuilder
19:10:09 <wumpus> but the fork might be worth a try !
19:10:12 <achow101> luke-jr: see also https://github.com/devrandom/gitian-builder/issues/191
19:11:54 <wumpus> anyhow -- please ask in this channel if you have any problems getting gitian running
19:12:04 <wumpus> #topic High priority for review
19:12:30 <wumpus> https://github.com/bitcoin/bitcoin/projects/8  there's only one PR in there at the moment, #13100
19:12:35 <gribble> https://github.com/bitcoin/bitcoin/issues/13100 | gui: Add dynamic wallets support by promag · Pull Request #13100 · bitcoin/bitcoin · GitHub
19:12:51 <sipa> i'd like #13723
19:12:53 <gribble> https://github.com/bitcoin/bitcoin/issues/13723 | PSBT key path cleanups by sipa · Pull Request #13723 · bitcoin/bitcoin · GitHub
19:13:05 <sipa> (it's the basis for further psbt/descript integration)
19:13:24 <instagibbs> https://github.com/bitcoin/bitcoin/pull/13968 bugfixes for psbt stuff too(0.17 backport)
19:13:54 <instagibbs> #13968
19:13:56 <gribble> https://github.com/bitcoin/bitcoin/issues/13968 | [wallet] couple of walletcreatefundedpsbt fixes by instagibbs · Pull Request #13968 · bitcoin/bitcoin · GitHub
19:14:42 <ken2812221> #13866
19:14:44 <gribble> https://github.com/bitcoin/bitcoin/issues/13866 | utils: Use _wfopen and _wfreopen on Windows by ken2812221 · Pull Request #13866 · bitcoin/bitcoin · GitHub
19:14:48 <wumpus> 13723 added
19:15:33 <jtimon> if high priority is still for blockers, https://github.com/bitcoin/bitcoin/pull/13311 is kind of a blocker for https://github.com/bitcoin/bitcoin/pull/8994 which is itself a blocker for toher things I wanted to do
19:15:38 <wumpus> the other two as well
19:15:55 <wumpus> #13311
19:15:57 <gribble> https://github.com/bitcoin/bitcoin/issues/13311 | Dont edit Chainparams after initialization by jtimon · Pull Request #13311 · bitcoin/bitcoin · GitHub
19:16:12 <promag> wumpus: can you replace 13100 with #13529?
19:16:14 <gribble> https://github.com/bitcoin/bitcoin/issues/13529 | Use new Qt5 connect syntax by promag · Pull Request #13529 · bitcoin/bitcoin · GitHub
19:17:05 <wumpus> promag: ok
19:17:09 <wumpus> jtimon: added
19:17:16 <jtimon> yeah, thanks
19:17:20 <achow101> I would like #12493
19:17:22 <gribble> https://github.com/bitcoin/bitcoin/issues/12493 | [wallet] Reopen CDBEnv after encryption instead of shutting down by achow101 · Pull Request #12493 · bitcoin/bitcoin · GitHub
19:17:41 <promag> ty
19:17:56 <wumpus> achow101: ok, yes, probably makes sense to merge that early in the 0.18 cycle
19:18:11 <wumpus> achow101: it sounds sort of--risky
19:18:14 <gmaxwell> achow101: did we ever work through the problems that were preventing "don't create a wallet until a key is requested or until encryption is added" ?
19:18:32 <gmaxwell> As that would also get rid of the shutdown on encryption for many users.
19:18:37 <achow101> gmaxwell: the problems with that were backups IIRC
19:19:10 <achow101> gmaxwell: actually that problem was with generate keys on use, not create wallet on use
19:19:59 <achow101> in that case, I don't think so. but I also don't remember the problems with create wallet on use. I think I just never got around to implementing it
19:20:17 <gmaxwell> right. I thought there were some dumb bugs with create on use that were going to get fixed as a side effect of pending multiwallet work.
19:21:51 <wumpus> any other proposed topics?
19:23:59 <sipa> short announcement: we're working on an extension to descriptors to support nested and/or/threshold constructions
19:25:03 <wumpus> cool!
19:25:38 <sdaftuar> topic suggestion: open floor for people to share what they
19:25:40 <jonasschnelli> nice
19:25:41 <sdaftuar> re wokring on
19:26:01 <sdaftuar> (since we don't have any other topics apparently :P)
19:26:29 <sipa> i like wok rings
19:26:33 <wumpus> #topic open floor for people to share what they are working on
19:26:40 <jonasschnelli> Working on p2p level encryption since a couple of weeks (thats why I'm pretty quite on github). Will open PR in 1-2 weeks.
19:27:16 <wumpus> sipa: so this is for further improvements to scantxoutset I suppose?
19:27:24 <sipa> wumpus: and all the things :)
19:27:34 <wumpus> right
19:27:48 <sipa> wumpus: so you can import and(xpub/...,or(xpub/...,xpub/...)) into your wallet as watch-only chain for example
19:27:53 <achow101> wumpus: hopefully for eventually a replacement-ish thing to the wallet
19:27:54 <sipa> and get psbt to sign for it
19:28:20 <instagibbs> so excite
19:28:22 <wumpus> that's neat
19:28:25 <jonasschnelli> sipa: how would/could that lead to xpub watch only wallets?
19:28:57 <sipa> jonasschnelli: yes
19:29:02 <sipa> that's the goal of the descriptors
19:29:45 <instagibbs> achow101, not sure if he was joking, but he said he wouldnt have to implement it if I did the HWI version. I'll keep leaning on him
19:29:52 <jonasschnelli> That would be a great feature... could also be extended to the GUI including coin selection (send screen), but don't sign/broadcast (obviously) but will create a PSBT (file)
19:30:16 <instagibbs> my guess is for any hope of Core support of HWW, we want to not have to support a bunch of PSBT drivers...
19:30:52 <instagibbs> oh sorry wrong window
19:30:56 <jonasschnelli> instagibbs: you mean more support then the PSBT?
19:31:15 <sipa> jonasschnelli: seems reasonable yes
19:31:37 <sipa> i need to think through how to integrate things in the wallet itself, so you can import descriptors
19:31:46 <sipa> and how to make it compatible with all existing RPCs etc
19:32:16 <gmaxwell> sipa: not just and/or/threshold but also CSV and hashlocks?
19:32:22 <instagibbs> gmaxwell, yes
19:32:22 <sipa> gmaxwell: oh yes
19:32:27 <instagibbs> (oh rhetorical)
19:32:32 <sipa> but my goal is that the wallet eventually consists of a bunch of descriptors with metadata (and labels and transactions, and precomputed pubkeys to replace keypools)
19:33:41 <gmaxwell> If lots of people can help sipa finish that work it would be good. :P
19:34:15 <sipa> but independently andytoshi and i started looking into how we can efficiently compile arbitrary and/or/k-of-n/locktime/hash expressions to script
19:34:44 <sipa> which would just plug into descriptors, and then be available to everything that uses them
19:36:12 <wumpus> so I"ve been working on the RISC-V support, today I was able to do basic bring-up of the hardware (HiFive Unleashed) and test the gitian-built executables, which work!
19:36:28 <wumpus> been able to run the test_bitcoin succesfully and sync part of the chain, I'll keep the node running
19:36:34 <wumpus> probably the first RISC-V bitcoin node in the world
19:37:03 <jonasschnelli> \o/ nice!
19:37:39 <gmaxwell> nmkgl and I have been working on reconciliation based transaction relay.  (With sipa's help too, that why I want people to help finish the descriptor work, ... :P )
19:38:26 <sdaftuar> gmaxwell: as in set reconciliation, eg to sync mempools?
19:38:52 <sipa> sdaftuar: yup
19:39:04 <gmaxwell> sdaftuar: Yes, but I believed we found a better design that doesn't sync the mempools directly.
19:39:46 <sdaftuar> neat, i'd be interested in learning more if you guys have a summary at some point.
19:39:49 <sipa> sdaftuar: it uses a more computationally expensive set reconcilation protocol than IBLT, but it's much more space efficient
19:40:06 <gmaxwell> muuuch more.
19:40:11 <sipa> (basically the amount of data transferred is equal to the expected difference between the two sets)
19:41:15 <sipa> but it's in the order of 40ms here to find 300 differences
19:41:24 <gmaxwell> I also came up with a new reconcilation protocol with a different performance tradeoff (much faster to decode, but slightly less space efficient), though it doesn't look like we'll have cause to use it.
19:42:04 <gmaxwell> sdaftuar: in any case the short summary of what we're thinking now vs before is that instead of reconciling mempools, reconcile the transactions that the peers would have otherwise INVed to each other.
19:42:42 <gmaxwell> this avoids cases like a mempool policy difference causing transations to get 'stuck' in the difference set forever until they get mined.
19:42:51 <sipa> oooh nice
19:42:53 <sipa> i missed that
19:43:23 <gmaxwell> Then it can just be coupled with some simple mechenism to fast-start an empty or stale mempool.
19:43:53 <gmaxwell> (I have a proposal for that too, just a simple one/two message protocol)
19:44:22 <instagibbs> would this be complementary to a ip-hiding protocol like dandelion?
19:44:25 <sdaftuar> ah, that sounds neat
19:44:25 <BlueMatt> hmm, and then you could bucket and do reconciliation slowly for low-feerate buckets, or no reason to do that anymore?
19:44:46 <BlueMatt> instagibbs: I'd presume so, this would be during fluff-faze :p
19:44:55 <sipa> instagibbs: yes, orthogonal
19:45:04 <sipa> this is changing the diffusion phase
19:45:06 <sipa> not the stem
19:45:09 <instagibbs> BlueMatt, not exactly fluffing anymore :)
19:45:16 <gmaxwell> instagibbs: it's orthorgonal, the main motivation is getting rid of the really high bandwidth overhead for rumoring.
19:45:17 <instagibbs> sipa understood
19:45:28 <gmaxwell> Probably some differences in context here. :)
19:45:52 <gmaxwell> Right now, ignoring peers that IBD, the vast majority of node bandwidth is wasted on INV rumoring.
19:45:54 <BlueMatt> gmaxwell: wait, was that a response to my question?
19:46:30 <gmaxwell> BlueMatt: sure, it could be split by feerate too, though I'm not sure we'll have a reason to because the reconcilation is so efficient.
19:46:52 <BlueMatt> hmm, guess I need to think about this more
19:46:54 <sdaftuar> do you have an estimate on the bandwidth reduction?
19:47:38 <gmaxwell> No, don't have a mature enough simulator yet. Also I haven't measured overheads since we improved inv batching.
19:49:04 <gmaxwell> But previously INV overhead was something like 80% of node bandwidth (excluding IBDing peers).
19:49:33 <gmaxwell> And this should mostly eliminate that overhead.
19:52:22 <wumpus> looks like we've run out of topics, but not out of time yet
19:52:34 <gmaxwell> In any case, we've been largely off in number theory land optimizing the recon itself... but I think we've got what we need there now. :)
19:53:38 <sdaftuar> btw i've been thinking about dandelion recently, trying to work through anti-DoS measures for stem routing
19:57:17 <gmaxwell> sdaftuar: Good!  This seems to be one of those things that is easy in theory (if either you ignore getting it right or ignore how hard it is to implement) but hard in practice. :)
19:57:37 <wumpus> would be good to reduce the DoS surface there, yes
20:00:02 <sipa> PLOINKIDOOF
20:00:03 <wumpus> #endmeeting