19:00:09 <wumpus> #startmeeting
19:00:09 <lightningbot> Meeting started Thu Apr 19 19:00:09 2018 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:09 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:15 <sipa> ohai
19:00:22 <jonasschnelli> hi
19:00:25 <promag> hi
19:00:30 <achow101> hi
19:00:35 <jnewbery> hi
19:00:37 <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator
19:00:39 <kanzure> hi.
19:00:41 <instagibbs> hi
19:00:42 <aj> 'lo
19:00:50 <cfields> hi
19:01:24 <jonasschnelli> ;;seen gmaxwell
19:01:24 <gribble> gmaxwell was last seen in #bitcoin-core-dev 5 weeks, 0 days, 1 hour, and 59 seconds ago: <gmaxwell> it's not like you pay lower fees due to it.
19:01:35 <meshcollider> hi
19:01:37 <wumpus> any proposed topics?
19:01:50 <jonasschnelli> I'd like to touch the light client mode design
19:02:02 <wumpus> ok
19:02:04 <promag> check high priority review first?
19:02:08 <kanzure> 11:10 < BlueMatt> I'll probably miss the meeting, but, hey, I got through 3/4 of the high-priority PRs, even acked 2, and left blocking comments on the 3rd....how did *you* do this week?
19:02:09 <jonasschnelli> ack
19:02:22 <wumpus> promag: yes, that's always the first topic
19:02:22 <jonasschnelli> we can't view jimpos txindex PR
19:02:31 <jonasschnelli> github issue... can we reopen the PR in a new #?
19:02:33 <sipa> I'd like #13002 on the high-priority list
19:02:34 <gribble> https://github.com/bitcoin/bitcoin/issues/13002 | Do not treat bare multisig outputs as IsMine unless watched by sipa · Pull Request #13002 · bitcoin/bitcoin · GitHub
19:02:46 <wumpus> #topic high priority for review
19:02:50 <wumpus> https://github.com/bitcoin/bitcoin/projects/8
19:03:00 <Murch> hi
19:03:00 <sipa> Also, I can't open #11857
19:03:05 <gribble> https://github.com/bitcoin/bitcoin/issues/11857 | Build tx index in parallel with validation by jimpo · Pull Request #11857 · bitcoin/bitcoin · GitHub
19:03:19 <jonasschnelli> added 13002
19:03:22 <sipa> Do we at some point just close the PR and open a new one, to flush all historical discussion?
19:03:31 <jonasschnelli> sipa: yes
19:03:35 <sipa> (assuming that's the reason for the sad unicorn)
19:03:41 <jonasschnelli> jimpo should do it though...
19:03:46 <sipa> yes
19:03:48 <kanzure> has someone reported the unicorn to support@github.com
19:03:49 <jonasschnelli> I could not get hold of him in. the last days
19:03:54 <achow101> maybe telling github would help...
19:03:57 <jonasschnelli> kanzure: please do
19:04:12 <sipa> probably better if a repo owner does so
19:04:18 <sipa> i'll send a mail
19:04:20 <jonasschnelli> I doubt it would help in a resonable timeframe
19:04:21 <meshcollider> I don't get the unicorn, I can see it fine
19:04:28 <jonasschnelli> it's wired
19:04:33 <promag> me to, but in incognito
19:04:37 <instagibbs> kanzure, i did
19:04:39 <wumpus> I see the unicorn
19:04:40 <jonasschnelli> I can't. But i can in mobile view
19:04:51 <instagibbs> incognito works reliably for me
19:04:52 <jnewbery> instagibbs reported it
19:04:54 <kanzure> instagibbs: thanks. i'll refrain.
19:05:10 <sipa> instagibbs: when?
19:05:14 <instagibbs> couple days ago
19:05:18 <sipa> any response?
19:05:21 <instagibbs> no
19:05:29 <achow101> I've reported it just now
19:05:40 <achow101> also works in private browsing (firefox)
19:06:21 <jonasschnelli> logged out state works
19:06:34 <jonasschnelli> however, jimpo should just open a new PR
19:07:38 <jamesob> I can view it in lynx just fine
19:07:40 <sipa> suggested tiny topic: cyclic dependency
19:07:47 <jonasschnelli> hah jamesob
19:07:50 <jamesob> ;)
19:08:28 <wumpus> #topic cyclic dependency
19:09:06 <sipa> i was wondering if we should have a policy against the type of cyclic dependency where the .cpp files include eachother's .h files (but not .h files include eachother)
19:09:36 <wumpus> do we have that problem?
19:09:36 <sipa> that's not a cyclic dependency for the compiler, but it does mean those two modules can't really be used independently and is generally a sign of bad separation
19:09:38 <kanzure> do we have many of that
19:09:38 <cfields> sipa: example?
19:09:45 <sipa> there are a few open PRs that introduce them
19:10:15 <wumpus> I do agree cyclic dependency should be avoided in general
19:10:20 <sipa> so i wanted to bring it up here to see if that should be a PR merging blocker
19:10:29 <sipa> or just a "try to fix it up afterwards if introduced"
19:10:46 <sipa> i'm fine with either
19:11:07 <cfields> indeed sounds like likely bad design that should at least be justified in the PR
19:11:19 <sdaftuar> cfields: +1
19:11:21 <jonasschnelli> Yes. And maybe mention it in the developer guidelines?
19:11:23 <wumpus> right, might make sense to discuss this in the PR
19:11:23 <meshcollider> Sounds like it'd be a painful thing to fix up afterwards in some cases
19:11:25 <aj> seems good to fix it before merge, but not sure it should be added as a lint check or similar
19:11:27 <sdaftuar> i can imagine that in some contexts we'd merge anyway
19:11:54 <sdaftuar> but might be blocking in others
19:12:02 <meshcollider> ^
19:12:10 <sipa> #12954 introduces one for example
19:12:11 <gribble> https://github.com/bitcoin/bitcoin/issues/12954 | util: Refactor logging code into a global object by jimpo · Pull Request #12954 · bitcoin/bitcoin · GitHub
19:12:36 <wumpus> for a refactor it should definitely be avoided
19:12:44 <wumpus> refactoring is supposed to make the code better
19:12:50 <wumpus> not introduce further bad design
19:12:58 <sdaftuar> that might be an example of an improvement that just doens't go far enough though?
19:13:05 <sipa> well one way of looking at it is that the current util.cpp there has two subcomponents that already have a cyclic dependency
19:13:16 <sipa> within the same .cpp file
19:13:27 <sipa> and forcing people to fix it before they can separate it is maybe counterproductive
19:13:35 <sipa> or not ;)
19:13:36 <wumpus> maybe...
19:14:16 <sipa> enough on the topic i guess
19:14:27 <jcohen> one "quick" solution to avoiding that circular dep would be to jam it all into a single file - which i think would be even less desireable
19:14:39 <wumpus> it is already in a single file
19:14:42 <jcohen> the alternative would be to split util up even further, which would lengthen the diff
19:15:06 <sipa> this is just an example, it's relatively easy to fix in this case
19:15:07 <cfields> sipa: right. Since the point of this one is to break up a big blob anyway, requiring it to solve the circular issue in one go would be pretty burdensome. But if it's moving in the right direction, imo maintaining the status quo is ok.
19:15:23 <cfields> we could go back to main.cpp :p
19:15:32 <sipa> cat *.cpp | gcc -
19:15:33 <wumpus> cfields: true...
19:15:40 <achow101> "just put everything into one big file and call it main.cpp"
19:15:52 <wumpus> I don't think I feel strong enough about this one to put it in the guidelines
19:15:59 <jtimon> well, perhaps breaking util as needed first makes sense
19:16:10 <wumpus> though commenting on it where relevant is a good idea
19:16:14 <sipa> sgtm
19:16:45 <wumpus> if there's an obvious solution to avoid it that's better, but we cannot enumerate every single software design compromise
19:17:19 <wumpus> #topic light client mode design (jonasschnelli)
19:17:39 <aj> #13021 does the "break util as needed first" by the looks - logging.cpp includes util.h, util.h includes logging.h
19:17:40 <gribble> https://github.com/bitcoin/bitcoin/issues/13021 | MOVEONLY: Move logging code from util.{h,cpp} to new files. by jimpo · Pull Request #13021 · bitcoin/bitcoin · GitHub
19:17:42 <jonasschnelli> I'd like to get some feedback about the light client mode... particular the "requestblock" design
19:17:50 <jonasschnelli> #10794
19:17:53 <gribble> https://github.com/bitcoin/bitcoin/issues/10794 | Add simple light-client mode (RPC only) by jonasschnelli · Pull Request #10794 · bitcoin/bitcoin · GitHub
19:17:59 <jonasschnelli> if that is something we should follow or drop
19:18:26 <jonasschnelli> I know the use-cases with 10794 are limited, but a stepping stone towards hybrid and BIP158 light validation
19:19:01 <sipa> jonasschnelli: will review
19:19:19 <jonasschnelli> maybe first check for a concept ACK/NACK
19:19:28 <jtimon> aj: yeah, and it seems moveonly, so perhaps just rebasing 12954 on top of 13021 solves the issue in this case? sipa
19:20:23 <sipa> jonasschnelli: yes, makes sense - it's a bit too much to look at right now in the meeting though, i think
19:20:30 <jonasschnelli> sure...
19:20:58 <jonasschnelli> I'm only interested to know if the concept make sense for you guys
19:21:14 <jonasschnelli> (of having a light client mode)
19:21:20 <wumpus> they have been open for a long time, probably should et around to at least concept-acking them
19:21:26 <sipa> yes
19:21:45 <jonasschnelli> Great. Thanks
19:21:47 <sipa> jonasschnelli: oh, the idea of having a client mode - that makes absolutely sense to me
19:21:53 <sipa> but it heavily depends on how and what :)
19:22:04 <meshcollider> Having a light client mode is definitely a concept ACK for me
19:22:11 <LukeJr> jonasschnelli: only as a temporary stage
19:22:19 <sipa> LukeJr: how so?
19:22:21 <jonasschnelli> right... I wasn't sure if the PR is the right place to discuss that or if we want to do it in a meeting
19:22:43 <LukeJr> sipa: it should always be building up to a full node in the bg
19:23:13 <sipa> LukeJr: i disagree - it's a perfectly valid usecase to have one full node you run yourself, and then have multiple client nodes connect exclusively to it
19:23:16 <LukeJr> (even if that bg process is paused for a time)
19:23:36 <LukeJr> sipa: hmm
19:23:43 <cfields> jonasschnelli: I realize this is really unhelpful feedback, but I find the current download logic nearly impossible to follow as-is. I remember giving up on review of this last time for that reason. Imo it's due for a bit of a cleanup/encapsulation before piling more on :(
19:24:13 <sipa> LukeJr: but lightweight upgrading to full in the background is also an very good usecase, imho
19:24:15 <cfields> (feel free to ignore that, maybe it's just my issue reading the code)
19:24:43 <sdaftuar> cfields: you are not the only person who finds the download logic confusing :)
19:25:02 <sipa> i believe those who (helped) write it agree :)
19:25:12 <jonasschnelli> heh. Yes. The open PR is not the first try to make this with a possible very small impact on the code...
19:25:26 <sipa> jonasschnelli: thanks for stickin with it, though
19:25:56 <cfields> yes, I was hesitant to mention that because I didn't want to de-motivate at all.
19:26:00 <LukeJr> sipa: as soon as the wallet is split, your use case just works
19:26:31 <sipa> LukeJr: this is how i imagine the wallet being split :)
19:27:14 <jamesob> *cough* #10973 *cough*
19:27:17 <gribble> https://github.com/bitcoin/bitcoin/issues/10973 | Refactor: separate wallet from node by ryanofsky · Pull Request #10973 · bitcoin/bitcoin · GitHub
19:27:19 <jonasschnelli> It's still unclear though how fee estimations and mempool checks would be done "in that way"
19:27:46 <sipa> jamesob: that's modularizing the code better, which is independently useful
19:29:08 <sipa> i don't think the goal should be separating the wallet from the node into different processes, and then inventing a protocol between the two... instead of just making the wallet run as a light client
19:29:41 <jamesob> the two sound very similar to me
19:29:50 <LukeJr> I don't agree. There's no reason the wallet and node should be in the same process.
19:30:50 <jonasschnelli> sipa: I agree. For me its just unclear how to transport fee estimations and mempool checks between light client and the fullnode.
19:31:00 <wumpus> LukeJr: that's not what sipa is saying, in his case the node and wallet would also be in different processes, but without custom protocol
19:31:17 <sipa> jamesob: the advantage of using P2P as communication between node and wallet (which is what you get if you see wallets as just lightweight nodes) is that it actually modularizing things: you can run _any_ wallet software or _any_ node software
19:31:30 <jamesob> wumpus sipa: but then using what protocol? a more fleshed out rpc interface?
19:31:37 <sipa> jamesob: P2P
19:31:37 <instagibbs> p2p messages
19:31:50 <instagibbs> with whitelisted fee estimation type messages, i assume
19:31:55 <wumpus> right
19:32:05 <jonasschnelli> instagibbs: but not before we have BIP150/151
19:32:19 <wumpus> I think for localhost it's fine without?
19:32:22 <jonasschnelli> I don't want MITMled fees
19:32:24 <jonasschnelli> yes. sure
19:32:32 <sipa> oh, short topic: update on private authentication protocols
19:32:41 <wumpus> but yes, in general that's correct
19:32:56 <jnewbery> I don't think doing process separation with IPC precludes later doing a p2p-based wallet
19:32:58 <jamesob> sipa: thanks for the explanation; will noodle on that
19:33:16 <jnewbery> p2p-based wallet seems like a very large project
19:33:17 <sipa> jnewbery: i agree, but i think it's a bit overkill
19:33:25 <sipa> jnewbery: however, i don't think that's a choice that needs to be made
19:33:43 <jonasschnelli> jnewbery: we are not too far away from a p2p based wallet IMO
19:33:46 <sipa> encapsulating the communication between node and wallet is an objective improvement to the code
19:34:06 <sipa> even if it does not lead to also a process separation along that interface
19:34:38 <jnewbery> jonasschnelli: really? Maybe I overestimate the difficulty, but it seems like we'd need a lot of new logic in the wallet to understand p2p
19:34:48 <sipa> jnewbery: you misunderstand!
19:34:56 <sipa> jnewbery: it would reuse all the existing full node code
19:35:00 <sipa> and p2p implementation
19:35:06 <sipa> just don't do validation
19:35:07 <instagibbs> turn off full validation, ofc
19:35:08 <ryanofsky> just catching up, but yeah, i think two approaches are not exclusive, and work done to support ipc will be useful anyway for making wallet more independent and better able to do async p2p stuff
19:35:10 <jonasschnelli> jnewbery: it needs BIP158 light client mode (or fullblock), fee and mempool checks. Done
19:35:29 <sipa> ryanofsky: yes, fully agree
19:35:51 <jonasschnelli> You just start two instances of Core. One as a full node, one with disabled validation pointing to the full node
19:36:59 <LukeJr> does it simplify or complicate the internal code? (ignoring the present level of complexity in itself)
19:36:59 <jonasschnelli> --> <sipa>	oh, short topic: update on private authentication protocols
19:37:00 <jnewbery> ok, I understand. How much work is it to make core work in --disablevalidation mode?
19:37:12 <sipa> jnewbery: that's the current topic :)
19:37:29 <jonasschnelli> jnewbery: 10794
19:37:32 <jonasschnelli> (does it)
19:37:33 <jnewbery> ok, I'll shut up and read the PR
19:38:03 <jonasschnelli> although 10794 leads out the wallet
19:38:11 <jonasschnelli> (to make it reviewable)
19:38:21 <jonasschnelli> *lefts out
19:38:39 <wumpus> #topic update on private authentication protocols (sipa)
19:39:25 <sipa> so, as some know gmaxwell and i have been thinking about authentication protocols that have better privacy than bip150
19:40:06 <jonasschnelli> privacy in the sense of fingerprinting?
19:40:09 <sipa> yes
19:40:23 <sipa> the goal is to have a design where one node has 1 or more private keys, and the other node has 1 or more public keys
19:40:40 <sipa> and the second node learns whether one of the other node's private keys matches one of your public keys
19:40:43 <sipa> but _nothing_ else
19:40:57 <sipa> the node with the private keys does not even learn if authentication was succesful
19:41:09 <sipa> or doesn't learn which keys it was being queried for
19:41:26 <jonasschnelli> the use case is then wide deploey authentication sheme rather then the more client-server-ish approach?
19:41:42 <sipa> it's still client-server
19:42:01 <sipa> the cool thing about this is that you can always run the authentication protocol
19:42:03 <LukeJr> sounds hard to give an "authentication failiure" error?
19:42:34 <sipa> LukeJr: the idea is that most of our connections are unauthentication anyway (and should be)... so whatever privileges you give to authenticated nodes, you just don't give if auth fails
19:42:45 <sipa> this has a very cool property
19:42:53 <sipa> you can _always_ run this authentication protocol
19:43:00 <sipa> even if you don't care who the other party is
19:43:05 <jonasschnelli> sipa: but, if you have node A and node B's pubkeys and you want connect to A, how can you be sure you'r not connecting to B?
19:43:11 <LukeJr> sipa: but if the authenticating node doesn't know if it failed, then it doesn't know if it has an authentication connection it expects
19:43:37 <sipa> LukeJr: it can run the same protocol in the other direction to find out
19:43:43 <LukeJr> hmm
19:43:54 <sipa> jonasschnelli: you just query for who you want the other party to be
19:43:59 <phantomcircuit> or just ask for something that requires authentication
19:44:41 <sipa> the cool thing is that if you always run the authentication protocol, but if you're not interested in authentication do it with just a randomly generated pubkey, a MitM can't find out what you're doing
19:44:49 <sipa> they have to assume you're trying to authenticate
19:45:02 <sipa> anyway, turns out... this is difficult
19:45:05 <cfields> sipa: i'm not sure if this has evolved from when we discussed last... does your peer learn how many pubkeys you'd accept?
19:45:20 <sipa> cfields: yes, but you can stuff your request with a number of random ones
19:45:28 <cfields> right, ok
19:45:29 <sipa> just pad to 256 keys or whatever, always
19:45:52 <instagibbs> so, did you fix it? :)
19:45:55 <jonasschnelli> sounds interesting.. are there written specs already?
19:46:00 <sipa> we have a protocol that works with 1 privkey and 1 pubkey - which means you need to run in many times sometimes which doesn't lead to great fingerprinting properties
19:46:10 <sipa> and i'm talking to some people to extend it :)
19:46:46 <jonasschnelli> Great. Thanks!
19:46:50 <sipa> jonasschnelli: https://gist.github.com/sipa/d7dcaae0419f10e5be0270fada84c20b
19:46:58 <sipa> note that that protocol linked to is broken
19:47:16 <sipa> but it does explain the rationale pretty well, i think
19:47:37 <sipa> end topic
19:47:51 <jonasschnelli> I guess this protocol would require more cryptoanalysis then the exiting BIP150
19:48:09 <sipa> jonasschnelli: that's ok, i'm talking to dan boneh about it
19:48:28 <jonasschnelli> Good!
19:48:51 <meshcollider> Dan is the solution to all crypto problems
19:48:57 <jonasschnelli> heh
19:49:18 <wumpus> it'd be good as a future successor to BIP150 - though I guess this research shouldn't discourage anyone from implementing BIP150 and having something working on more short term
19:49:26 <sipa> right
19:49:42 <wumpus> (maybe that's obvious, but just to be clear)
19:49:44 <jonasschnelli> Implementing BIP151/150 is still hold back due to the network refactor, right?
19:50:03 <jonasschnelli> If not, I can continue on BIP150
19:50:09 <jonasschnelli> sry. 1541
19:50:10 <jonasschnelli> sry. 151
19:50:11 <cfields> sipa: I'm still a bit confused as to the use-case. Is the intent to be able to explicitly find a known peer, or more generally to build up a list of tofu-ish nodes that aren't known to misbehave, and look for them first when creating outbound connections?
19:50:27 <jnewbery> cfields: what's the state of network refactor? Any PRs awaiting review?
19:50:28 <sipa> cfields: you can't do TOFU, you don't learn who you're connecting to
19:50:50 <sipa> cfields: the whole point is avoiding having discoverable identities for things that should be identityless
19:51:06 <sipa> but sometimes you have a node you trust already (due to external reasons, for example you run it yourself)
19:51:21 <sipa> in which case you'd configure an addnode with a known pubkey or so
19:51:36 <cfields> sipa: got it, thanks.
19:51:51 <cfields> jnewbery: #11457 still, looks like it needs rebase again
19:51:54 <sipa> yes, BIP150 can continue independently
19:51:54 <gribble> https://github.com/bitcoin/bitcoin/issues/11457 | Introduce BanMan by theuni · Pull Request #11457 · bitcoin/bitcoin · GitHub
19:51:56 <cfields> doing now, thanks for the reminder
19:51:58 <sipa> eh, BIP151
19:52:01 <Murch> cfields: In the case that you for example want to connect with a thin client to your own node, the only valid key you query for is your home node's. If you want to defend against Sybil, you may query a list of known friends and accept any of them. If you just want to scare off a MITM, you query for random keys.
19:52:28 <sipa> this is just a replacement for the authentication part; it needs an existing encrypted connection to run over anyway
19:52:49 * jonasschnelli will continue with 151
19:53:14 <LukeJr> how does one authenticate the encryption key?
19:53:20 <sipa> you don't
19:53:39 <jonasschnelli> bip151 does not protect from MITM
19:53:40 <sipa> encryption is done with ephemeral keys, and is completely unauthenticated
19:53:46 <sipa> it does not protect against MitM
19:53:51 <jonasschnelli> Only from passible observing and undetectable interception
19:53:55 <jonasschnelli> *passive
19:54:11 <sipa> but then you run an authentication protocol which can determine if the party you are talking to (possibly the MitM) is who you think it is
19:54:36 <sipa> anyway, enough on the topic
19:54:44 <sipa> just wanted to give an update that there are some cool ideas
19:54:50 <wumpus> yes, thanks!
19:54:54 * sipa lunch
19:55:00 <jonasschnelli> thanks sipa for working on this!
19:55:22 <wumpus> unless someone has a very quick last-minutet topic I think that was the last topic for today
19:56:02 <wumpus> clear :)
19:56:03 <wumpus> #endmeeting