19:03:54 #startmeeting 19:03:54 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:03:56 Yeah... hi 19:04:03 hi 19:04:07 hi 19:04:12 #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 chagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator 19:04:24 darn, just beat me to it. 19:04:29 hi 19:04:33 hi 19:04:43 apparently I divided michagogo in two 19:04:55 ouch 19:05:24 Hope he's not too cut up about it 19:05:25 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 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 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 I have some instructions for debian 9 here: https://gist.github.com/laanwj/c62e101bfd68718f0686926dfd10666b 19:07:27 hi 19:07:29 (yes, you need to build lxc and debootstrap from source) 19:07:32 Nice wumpus 19:07:43 we should probably integrate that into the documentation 19:08:25 Yes. Until lxc 2.1.1 is supported by debians apt 19:08:40 yes, 3.x is probably overkill 19:08:59 wumpus: did we ever get a solution for making a bionic base VM? :/ 19:08:59 Works fine here with 2.1.1 19:09:09 (for qemu) 19:09:17 also, with the suite bump, don't forget to do bin/make-base-vm again 19:09:29 luke-jr: I don't think so, I think LXC and Docker are the only options at the moment 19:09:34 achow101: last I checked that doesn't work 19:09:42 luke-jr: there's a fork of vmbuilder that works for bionic 19:09:59 luke-jr: https://github.com/newroco/vmbuilder 19:10:06 #link https://github.com/newroco/vmbuilder 19:10:09 but the fork might be worth a try ! 19:10:12 luke-jr: see also https://github.com/devrandom/gitian-builder/issues/191 19:11:54 anyhow -- please ask in this channel if you have any problems getting gitian running 19:12:04 #topic High priority for review 19:12:30 https://github.com/bitcoin/bitcoin/projects/8 there's only one PR in there at the moment, #13100 19:12:35 https://github.com/bitcoin/bitcoin/issues/13100 | gui: Add dynamic wallets support by promag · Pull Request #13100 · bitcoin/bitcoin · GitHub 19:12:51 i'd like #13723 19:12:53 https://github.com/bitcoin/bitcoin/issues/13723 | PSBT key path cleanups by sipa · Pull Request #13723 · bitcoin/bitcoin · GitHub 19:13:05 (it's the basis for further psbt/descript integration) 19:13:24 https://github.com/bitcoin/bitcoin/pull/13968 bugfixes for psbt stuff too(0.17 backport) 19:13:54 #13968 19:13:56 https://github.com/bitcoin/bitcoin/issues/13968 | [wallet] couple of walletcreatefundedpsbt fixes by instagibbs · Pull Request #13968 · bitcoin/bitcoin · GitHub 19:14:42 #13866 19:14:44 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 13723 added 19:15:33 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 the other two as well 19:15:55 #13311 19:15:57 https://github.com/bitcoin/bitcoin/issues/13311 | Dont edit Chainparams after initialization by jtimon · Pull Request #13311 · bitcoin/bitcoin · GitHub 19:16:12 wumpus: can you replace 13100 with #13529? 19:16:14 https://github.com/bitcoin/bitcoin/issues/13529 | Use new Qt5 connect syntax by promag · Pull Request #13529 · bitcoin/bitcoin · GitHub 19:17:05 promag: ok 19:17:09 jtimon: added 19:17:16 yeah, thanks 19:17:20 I would like #12493 19:17:22 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 ty 19:17:56 achow101: ok, yes, probably makes sense to merge that early in the 0.18 cycle 19:18:11 achow101: it sounds sort of--risky 19:18:14 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 As that would also get rid of the shutdown on encryption for many users. 19:18:37 gmaxwell: the problems with that were backups IIRC 19:19:10 gmaxwell: actually that problem was with generate keys on use, not create wallet on use 19:19:59 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 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 any other proposed topics? 19:23:59 short announcement: we're working on an extension to descriptors to support nested and/or/threshold constructions 19:25:03 cool! 19:25:38 topic suggestion: open floor for people to share what they 19:25:40 nice 19:25:41 re wokring on 19:26:01 (since we don't have any other topics apparently :P) 19:26:29 i like wok rings 19:26:33 #topic open floor for people to share what they are working on 19:26:40 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 sipa: so this is for further improvements to scantxoutset I suppose? 19:27:24 wumpus: and all the things :) 19:27:34 right 19:27:48 wumpus: so you can import and(xpub/...,or(xpub/...,xpub/...)) into your wallet as watch-only chain for example 19:27:53 wumpus: hopefully for eventually a replacement-ish thing to the wallet 19:27:54 and get psbt to sign for it 19:28:20 so excite 19:28:22 that's neat 19:28:25 sipa: how would/could that lead to xpub watch only wallets? 19:28:57 jonasschnelli: yes 19:29:02 that's the goal of the descriptors 19:29:45 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 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 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 oh sorry wrong window 19:30:56 instagibbs: you mean more support then the PSBT? 19:31:15 jonasschnelli: seems reasonable yes 19:31:37 i need to think through how to integrate things in the wallet itself, so you can import descriptors 19:31:46 and how to make it compatible with all existing RPCs etc 19:32:16 sipa: not just and/or/threshold but also CSV and hashlocks? 19:32:22 gmaxwell, yes 19:32:22 gmaxwell: oh yes 19:32:27 (oh rhetorical) 19:32:32 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 If lots of people can help sipa finish that work it would be good. :P 19:34:15 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 which would just plug into descriptors, and then be available to everything that uses them 19:36:12 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 been able to run the test_bitcoin succesfully and sync part of the chain, I'll keep the node running 19:36:34 probably the first RISC-V bitcoin node in the world 19:37:03 \o/ nice! 19:37:39 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 gmaxwell: as in set reconciliation, eg to sync mempools? 19:38:52 sdaftuar: yup 19:39:04 sdaftuar: Yes, but I believed we found a better design that doesn't sync the mempools directly. 19:39:46 neat, i'd be interested in learning more if you guys have a summary at some point. 19:39:49 sdaftuar: it uses a more computationally expensive set reconcilation protocol than IBLT, but it's much more space efficient 19:40:06 muuuch more. 19:40:11 (basically the amount of data transferred is equal to the expected difference between the two sets) 19:41:15 but it's in the order of 40ms here to find 300 differences 19:41:24 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 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 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 oooh nice 19:42:53 i missed that 19:43:23 Then it can just be coupled with some simple mechenism to fast-start an empty or stale mempool. 19:43:53 (I have a proposal for that too, just a simple one/two message protocol) 19:44:22 would this be complementary to a ip-hiding protocol like dandelion? 19:44:25 ah, that sounds neat 19:44:25 hmm, and then you could bucket and do reconciliation slowly for low-feerate buckets, or no reason to do that anymore? 19:44:46 instagibbs: I'd presume so, this would be during fluff-faze :p 19:44:55 instagibbs: yes, orthogonal 19:45:04 this is changing the diffusion phase 19:45:06 not the stem 19:45:09 BlueMatt, not exactly fluffing anymore :) 19:45:16 instagibbs: it's orthorgonal, the main motivation is getting rid of the really high bandwidth overhead for rumoring. 19:45:17 sipa understood 19:45:28 Probably some differences in context here. :) 19:45:52 Right now, ignoring peers that IBD, the vast majority of node bandwidth is wasted on INV rumoring. 19:45:54 gmaxwell: wait, was that a response to my question? 19:46:30 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 hmm, guess I need to think about this more 19:46:54 do you have an estimate on the bandwidth reduction? 19:47:38 No, don't have a mature enough simulator yet. Also I haven't measured overheads since we improved inv batching. 19:49:04 But previously INV overhead was something like 80% of node bandwidth (excluding IBDing peers). 19:49:33 And this should mostly eliminate that overhead. 19:52:22 looks like we've run out of topics, but not out of time yet 19:52:34 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 btw i've been thinking about dandelion recently, trying to work through anti-DoS measures for stem routing 19:57:17 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 would be good to reduce the DoS surface there, yes 20:00:02 PLOINKIDOOF 20:00:03 #endmeeting