19:01:19 #startmeeting 19:01:19 Meeting started Thu May 21 19:01:19 2020 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:19 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:01:22 hi 19:01:23 hi 19:01:24 hi 19:01:24 let's try... 19:01:26 hi 19:01:36 hi 19:01:42 hi 19:01:49 hi 19:01:51 #bitcoin-core-dev 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 kvaciral ariard digi_james amiti fjahr 19:01:52 late night hi 19:01:52 jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2 19:02:02 hi 19:02:24 Hi 19:02:33 one proposed meeting topic: alternative transports support (ariard) 19:02:39 yes! 19:02:49 hi 19:02:51 any last minute proposals? 19:02:53 hi 19:02:59 hi 19:03:42 okay, let's start with high priority for review as usual 19:03:48 #topic High priority for review 19:03:48 hi 19:03:57 hi 19:03:58 could #18297 be added to hi-prio? 19:04:00 https://github.com/bitcoin/bitcoin/issues/18297 | build: Use pkg-config in BITCOIN_QT_CONFIGURE for all hosts including Windows by hebasto · Pull Request #18297 · bitcoin/bitcoin · GitHub 19:04:05 https://github.com/bitcoin/bitcoin/projects/8 4 blockers, 1 bugfix, 4 chasing concept ACK 19:04:28 hebasto: yes 19:04:37 wumpus: thanks 19:05:00 #18787 for hi prio 19:05:02 https://github.com/bitcoin/bitcoin/issues/18787 | wallet: descriptor wallet release notes and cleanups by achow101 · Pull Request #18787 · bitcoin/bitcoin · GitHub 19:05:55 achow101: added 19:07:31 #topic Alternative transports support (ariard) 19:07:41 #18989 19:07:43 https://github.com/bitcoin/bitcoin/issues/18989 | Towards alternative transports first-class support · Issue #18989 · bitcoin/bitcoin · GitHub 19:07:48 Okay so I've explored a bit alternative transports support 19:08:08 as it has been previously attempted by Matt with headers-over-radio or headers-over-DNS 19:08:15 is there anything special needed at our side with regard to that? 19:08:32 well I want to assert project worthiness 19:08:39 couldn't any extenal software route the P2P port over some other transport? 19:08:40 there's also Blockstream's blocks-over-satellite 19:09:02 yes but idea is to increase easiness of link layer diversity 19:09:34 wumpus: you may want to receive blocks on one transport like satellites and broadcast them over another medium 19:09:49 while I think alternative transports are great, I don't think we should integrate the code for all the transports into bitcoin core 19:10:05 I didn't read your proposal yet so I might be off 19:10:12 wumpus: I agree that's why my proposal is splitting drivers from fetching logic 19:10:27 It's just a generic driver framework 19:10:40 but the drivers would things you compile in? 19:10:41 drivers should obviously lay outside of core 19:10:44 or external applications? 19:10:52 if it's external applications that's great 19:10:55 (even if not maintained in our repository) 19:11:01 sipa: compile in or external applications like meek or snowflake 19:11:10 why do we integrate tor then 19:11:13 yes I don't want them to be maintained in the repo 19:11:34 jb55: i think there is a difference between routing and non-routing transports 19:11:34 jb55: historical legacy, as well as being the most popular one probably 19:11:36 jb55: with regards to their pluggable transports 19:12:02 i think the things ariard is thinking about doesn't have addresses or a way to initiate a connection to a particular peer 19:12:05 wumpus: it's the most popuplar one ofc, but their threat model is a bit diffrent than our 19:12:07 we don't integrate tor really 19:12:15 we just have bits to interoperate with it 19:12:21 sipa: yes peer policy would be left to the driver 19:12:22 but just a "i have a way to connect to some other node, please communicate through it" 19:12:53 that makes sense 19:12:57 like if your alternative transport is a satellite, there is no that much peer 19:13:21 so this would be outside addrman, addr (or addrv2) messages, ... 19:13:22 also you may receive block from an uni-directional channel but want to broadcast tx over another one 19:13:23 yes, I agree that could be facilitatd better 19:13:26 in reaction to this 19:13:39 sipa: yes not melding with addrman 19:13:45 maybe through hints in a special-permissioned P2P connection 19:13:56 sipa: you may reuse addr messages but that's up to driver 19:13:59 p2p stuff needs Core-side integration ofc 19:14:13 well, maybe not 19:14:17 yes, in a sense 19:14:18 luke-jr: may you precise ? 19:14:31 I guess they can do their own addr-equivalent messages on their own transport 19:14:31 i'm not sure what the best way to support such things is... on the face of it, it could all be done as an external application talking P2P 19:14:39 but there may be easier ways of integrating 19:14:50 ariard: have users expressed interest in any specific alternative transports? which one would have the most interest in the beginning do you think? 19:15:00 sipa: like a supplemental daemon supporting all drivers ? 19:15:02 fibre-like things are harder, as they need mempool access 19:15:08 would be ideal to split out current p2p stuff external someday too 19:15:11 ariard: or one daemon per driver 19:15:13 what we're not going to do: include it all into the repository, or dynamic library based plugin mechanisms 19:15:23 wumpus: agree 19:15:30 fjahr: yes some LN routing nodes operators would like block redundancy 19:15:34 everything else is fine 19:16:03 sipa: yes you may have one daemon per driver but ideally you may react on what your learn one driver 19:16:21 i can't parse your sentence 19:16:48 if it runs in an external process and communicates with bitcoin core that's the right way 19:16:56 wumpus: yes agree doesn't make sense to include it all into the repo 19:17:08 if it requires a little extra support on our side that's ok 19:17:15 for tor it just connects to a local proxy socket right? isn't this general enough? 19:17:19 What about making our P2P function that way wumpus? 19:17:43 jb55: yes, there's a little specificsupport for incoming connections by creating a hidden service 19:17:52 sipa: let's say I learn I'm currently eclipsed, I send a notification to my LN daemon, LN daemon react by closing channnel and broadcast through some emergency channel 19:17:55 jb55: that wouldn't work for a satellite connection for example 19:18:02 I mean it seems like a silly suggestion but if we want fully capable alt-p2ps, then we should be able to dogfood it with our current p2p system 19:18:12 jeremyrubin: in the long run maybe 19:18:13 jb55: as you can't route a bidirectional byte stream 19:18:26 sipa: satellite would require custom deserialization code as well if I understand correctly 19:18:33 jeremyrubin: ideally but that's too much carefull refactor 19:18:34 wumpus: also seems good from a security perspective -- no DMA if you pop the transit layer :) 19:19:00 I think ryanofsky probably has some insight here 19:19:16 Don't you have a seperate network process branch right now? 19:19:25 Or is it just wallet stuff presently 19:19:26 better integration with core would ease deployement therefore making the number of such alternative transport used higher 19:19:36 jeremyrubin: yes, gmaxwell had some ideas in that direction as well, run the whole P2P in a sandboxed process 19:19:38 if one goal is supporting FIBRE in an external process... that's pretty hard; i think the reconstruction code needs low latency access to the mempool etc 19:19:39 and this would increase network security 19:20:11 sipa: fibre is so much special, not in my integration target 19:20:16 ariard: ok 19:20:29 I'm more interesred by headers-over-DNS or domain-fronting or radio integration 19:20:35 let's aim lower first ... 19:20:37 sipa: IPC shared memeory the mempool for fibre? 19:20:38 * jeremyrubin ducks 19:20:39 that's fair 19:20:40 it coudl always be extended later 19:20:50 to way-out ideas like that 19:20:57 yes I want something simple first, like headers-over-DNS 19:20:58 what's the simplest non-invasive use case? 19:21:14 ariard: headers-over-DNS could even just done with RPC, i think? 19:21:16 nothgin is going to happen at all if that's a requirement for the first version though :) 19:21:23 (a daemon communicating through RPC) 19:21:47 memmap the mempool lol :) 19:21:54 sipa: yes my concern is if you have to manage one daemon per alternative transport that's a bit cumbersome to deploy 19:22:01 even for power users 19:22:54 I want to explore if we can integrate with multiprocess and just have another new process supporting the drivers 19:22:56 ariard: compared to c-lightning which is already half a dozen daemons? ;) 19:23:36 sipa: I know it doesn't work well for embedded or mobile envs 19:24:41 why not? 19:24:57 and I think actually blocksat is its own fork of core 19:24:58 on limited 32-bit platforms it's usually better to have a zillion separate processes than threads within the same process 19:25:28 e.g. at least they don't have to share an address space 19:25:42 well actually with my driver interface design if you want to fork() behind you can 19:25:46 sipa/wumpus is there quick way to say what you don't like about the shared library approach? build complications? memory safety? 19:25:53 it's up to the driver implementation 19:26:14 ryanofsky: security, limits static linking, and having to provide a binary interface 19:26:51 also cross platform stuf 19:27:07 dynamic libraries are slightly but different enough to make your life a pain between windows and linux 19:27:11 wumpus: on security/fault-tolerance that's why I think a separate process would be better 19:27:17 yes, it is 19:27:24 contrary to Matt stuff spawning new threads 19:27:41 separate processes are better for isolation/security 19:27:41 now what should be the threading model of such new process it's another question 19:27:49 wumpus: agree 19:28:47 but current proposal is just to have fetching/broadcast logic in this new process and talk to a driver interface 19:29:04 ariard, i'll take a look at your prs and what the interfaces are. i'd expect they are easy just to get working across processes 19:29:05 fetching logic is operating over abstract driver attributes like fHeaders or fBlocks 19:29:07 that's interesting, I'll read the issue more closely 19:29:36 the issue is just performance, it's a easier to have great performance if you aren't doing io and just accessing memory 19:29:50 wumpus: yes I want to rely drivers devs to write their own fetching logic for each transport 19:29:51 ariard: i think it may be useful for you to take a look at all the rust-based drivers that I had written 19:30:07 ariard: I think the current API design in 18988 is much too tied to certain assumptions about what the thing will look like 19:30:20 bitcoin core is I/O bound but usually only on disk, not on P2P/network 19:30:37 BlueMatt: I know, I need to rework the threading model, but ideally your rust-based drivers should be reused 19:30:48 ariard: I dont think the threading model is the only issue there 19:30:53 i think it needs to be way more free-form 19:31:15 eg the rust stuff was just exposing ProcessNewBlock(Headers) and FindNextBlocksToDownload 19:31:20 as well as an api to get header state 19:31:21 BlueMatt: more asynchronous ? 19:31:32 and leaving it up to the driver what to do with that 19:31:41 cause drivers may have very different capabilities in terms of how to query 19:31:52 i guess that's a question of layering 19:31:53 BlueMatt, is starting with an API and just changing over time hard here? it seems like a brand new API you can declare unstable 19:32:03 eg headers-over-dns may only be able to query by block height, and its a poll, its not a file descriptor or a socket. 19:32:13 it does make sense to have a "i have a bidirection byte stream connection to another node... tell me what to route over it" interface 19:32:21 ryanofsky: I'm suggesting start with less api, and add more over time :) 19:32:22 but it's not the right solution for everything 19:32:37 i dont think its the right solution for...almost anything we'd want to do here? 19:32:50 like, some of the most exciting options would be https domain fronting 19:32:56 and its not a byte stream, its a query interface 19:33:08 what is https domain fronting? 19:33:08 yes that's why fetching logic should adapt its request to driver capabilities 19:33:18 like don't send GETHEADERS if it's unidirectional 19:33:41 sipa: https://www.bamsoftware.com/papers/fronting/ 19:33:42 sipa: where you hit commoncdn.amazon.com in SNI, but the http host header is magicbitcoinproxy.amazonuser.com 19:33:54 SNI? 19:34:10 sipa: and it routes to your domain. this is a *functional* way to connect to tor through the gfw still today, last i heard, though the common endpoint is slow 19:34:17 sipa: ssl plaintext hostname in the connection setup 19:34:19 sipa: https://en.wikipedia.org/wiki/Server_Name_Indication 19:34:32 i'll read the link 19:34:41 no need to unnoob be here 19:35:10 ariard: i dont even think 'bidirectional' is a reasonable assumption here - eg radio-based stuff is likely to be unidirectional 19:35:16 (and could be *either* read or write) 19:35:20 yes censorship circumvention is a huge topic in itself, and some of Tor stuff may not fit your threat model 19:35:33 if it's possible to unnoob the rest of us in a sentence or two, that might be helpful though 19:35:46 BlueMatt: yes capabilities need refinement 19:35:59 jnewbery, it's just a string passed to disambiguate when you have web servers for different domains on the same ip 19:36:03 jnewbery: its like the http Host header for tls connections 19:36:23 jnewbery: tl;dr: a way to connect to a super common https endpoint (so common that any censors wont block it cause they'd break many websites) and then route your own data over it 19:36:31 i feel people are trying to explain minor details while i (or some) are missing the big picture 19:36:38 think of, eg, amazon aws javascript cache 19:37:05 but you magically make the censor think you're connecting to that but are in fact connecting to a bitcoin core reset endpoint 19:37:05 i hear "something something https bypass GFW", but not what or how that'd be used 19:37:13 sipa: agree there is a lot of alternative transports, integration with each of them may bring you more security/privacy 19:37:28 therefore making them easier to deploy would be great 19:37:35 ariard: or less as you add more too 19:37:39 i think big picture is it's harder to censor an ip when it's an amazon ip also hosting things you're not trying to censor 19:37:57 ryanofsky: ok, that's helpful! 19:38:01 why is it unidirectional? 19:38:04 jeremyrubin: there is a risk of privacy leakage, it should be well-documented I agree 19:38:24 Very helpful. Thanks ryanofsky jb55 BlueMatt 19:39:05 domain-fronting increase cost of censorship, because now you have to harm ingenous traffic too 19:39:16 Signal uses this IIRC 19:39:59 could I use altnet to send a tx via carrier pidgin 19:40:03 its been very effecive for signal, in fact 19:40:18 but sipa was right, we miss the bigger picture, I would be glad to explain domain-fronting or how we may incorporate it in core in a pr review club session or other 19:40:20 BlueMatt, AWS got mad at them didn't hear the result of it :P 19:40:32 instagibbs: the result was to use azure 19:40:35 who did not get mad 19:40:37 jb55: using pidgin to steganographically hide the traffic is a great idea! 19:40:40 Ahhh 19:40:41 (yet) 19:40:52 hehe 19:40:54 pigeon* 19:41:01 But indeed, seems to work inside China quite well considering 19:41:26 yes if we have such generic driver framework, drivers devs may just focus on improving protocol fingerprint hidding 19:42:58 exactly. but it needs to be super flexible to support all these different crazy ideas 19:43:11 but not necessarily initially, it just needs to be extendable 19:43:17 I invite anyone to let comment on the PR/issues and in the meanwhile I will explore more each alt-transports to see how much generic framework 19:43:30 and come with a cleaner design proposal 19:43:31 ariard: what do you need help with? From my perspective, there's still a lot of work to be done internally in Bitcoin Core cleaning up the layer separation between net / net_processing / validation, but I haven't reviewed your branch yet 19:43:35 * BlueMatt notes that, after initialization, before any read()/write()s to the remote host, openssl can be run in a sanboxed processes which has no access to any syscalls except read() and write() :) 19:44:06 maybe it's good to make a list of potential alternative transport that are useful, and then see if there's a reasonable subset that can easily be supported 19:44:20 you don't want to overdesign either, nor make such a large stack of requirements that you give up in the idea 19:44:26 sipa: I've been working on this the last few days, will make it public soon 19:44:46 wumpus: you don't want to overdesign, but let room in the design to step-by-step extend it 19:44:47 jnewbery: these types of things need only very few calls into the rest of core 19:44:53 ariard: yes 19:45:03 eg you can write dns + http + radio + a full second p2p client with only these functions: https://github.com/TheBlueMatt/bitcoin/blob/d3ca09afbc38d7f73866da33948651ac2c40fd58/src/rusty/src/cpp_bridge.cpp 19:45:12 jnewbery: the kind of changes Carl is working on to separate net_processing from validation 19:45:21 (and that branch has all 4 written, though in rust) 19:45:24 just trying to warn to not get overenthousiastic I've seen this before :) 19:45:32 so I really dont think separating or cleaning up net_processing is at all required here 19:45:47 in fact, I think using any parts of net_processing or even net is an anti-goal. 19:45:47 * jeremyrubin excited for audio relay so I can fill my neighborhood with the glorious sound of decentralization 19:45:54 wumpus: I agree, that's kind of slow work like multiprocess is 19:45:54 jeremyrubin: ROFL 19:45:58 and validation.h is a relatively small API 19:46:01 I'm well aware of 19:46:46 i'm stoked for neutrino relay, uncensorable by physics ! 19:46:55 "it's faster than C!" 19:47:02 lol 19:47:05 hehe 19:47:06 jeremyrubin: receives block from space and pass headers-over-radio to your neighboors, be a good network citizen :) 19:47:33 * BlueMatt is excited for cross-ocean global radio header relay 19:47:56 that would be very nice 19:47:57 cause, like, some issues with using spectrum without pissing off a bunch of hams aside, is totally practical 19:48:00 I'd just be worried that if we set up neutrino relay that we'd start getting extraterrestrial blocks 19:48:11 800 bytes per 10 minutes is slightly higher than 1 bit per second 19:48:17 jeremyrubin: win/win 19:48:18 i wonder how much energy you need to moonbounce that 19:48:29 if anyone has idea of alternarive transport pleae note them in the issue, I will inquiry to see how you can integrate 19:48:33 sipa: ha! I was having a conversation about moonbouncing header relay like an hour ago 19:48:47 ariard: I just have the 4 that I listed previously, all of which I think are cool. 19:48:56 How many TXs can we fit in the latency between here and the moon? 19:49:06 (and sufficiently variable in the features they offer that they are a good test case) 19:49:06 MoonMemPoolTapeDeck 19:49:17 BlueMatt: cooool will go through this whole conv again to bookmark 19:49:44 oh in fact i've already you branch bookmarked :) the doc starter is nice 19:49:44 ariard: also take a look at the fn list at https://github.com/TheBlueMatt/bitcoin/blob/d3ca09afbc38d7f73866da33948651ac2c40fd58/src/rusty/src/cpp_bridge.cpp or the actual api at https://github.com/TheBlueMatt/bitcoin/blob/d3ca09afbc38d7f73866da33948651ac2c40fd58/src/rusty/src/bridge.rs 19:50:11 thats the api that I was exposing to all 4 clients in rust, and was pretty easy to write again. its not a class-based thing, just a bag of functions, though, so not quite what you're going for. 19:50:43 okay I've had a different concern, if such stuff get wider deployement we may have side-effect on the network topology 19:50:44 in other news, these things are back in stock, and can be used to pick up headers most places in new york city: https://unsigned.io/product/rnode/ 19:50:57 anyone has opinion on this ? 19:51:16 ariard: as long as its purely additive, who cares! :) 19:51:16 and such side-effect may not be desirable 19:51:30 ariard: at the risk of stating the obvious (but that is often forgotten in the excitement): restrict scope inititally to the smallest possible, minimum viable thing, that can be reviewed and that people can/will actually use on a small scale but eagerly 19:51:31 BlueMatt: right if everything is opt-in I think that's okay 19:51:53 I don't think it's addititive 19:51:57 (one of the key observations made previously is that these types of relays can be bucketed into a few categories: a) privacy preserving ones, often which only provide headers due to bandwidth constraints, and b) not that...) 19:51:59 jonatack: I know review process and getting the first chunks PRs are the hardest steps :) 19:52:03 This increases partitionability 19:52:21 but increases availability I think? 19:52:22 in such cases, we can use (a)-category sources to detect when there are blocks we dont have, and turn on the non-privacy-preserving modes in such cases 19:52:36 but maybe only after having the regular p2p code make some new connections 19:52:45 BlueMatt: exactly that's kind of the idea of having a watchdog for this 19:52:58 you dont need anything fancy to do that, though 19:53:04 only a sleep(300) :) 19:53:13 that's hacky 19:53:16 no its not 19:53:24 its actually exactly what you want here 19:53:35 wth are you guys talking about 19:53:38 give net_processing a chance to figure out how to fetch the block if we're missing one 19:53:47 BlueMatt: don't use a privacy-harming communication channel if you don't have to 19:53:51 and if it fails to within 5 minutes, turn on the http client and give up privacy for the block data 19:54:00 right, exactly, thats why you sleep(300) :) 19:54:17 ~5 minutes to go 19:54:19 I agree with sipa 19:54:24 sipa: if, eg, you learn a header over radio, but that source doesnt provide blocks, what do you do? 19:54:36 oh, wait, is this still a meeting? lol I'll shut up. 19:54:47 perhaps this more speculative discussion is better suited to bitcoin-wizards or similar? 19:54:49 BlueMatt: but no, you may start to be eclipsed after IBD and due to block variance sleep doesn't make sense IMO :p 19:54:51 sleep(300) till the end of the meeting 19:55:04 jnewbery: yes, though we don't have any other topics queued for today 19:55:39 jnewbery: agree again I invite people to pursue discussion on the issue or PR, it's better suited 19:55:43 BlueMatt: i don't know, why would you do anything? 19:56:24 i feel like i'm missing a lot of context 19:56:58 anyhow I agree with jonatack: restrict scope initially, don't try to do too many out-there things at once 19:57:25 though it's good that you're clearly having a lot of ideas 19:57:28 sipa: yes I will try to come with some Q&A-style of doc to inform people better 19:57:40 but some of us hardly follow :) 19:57:44 ariard: no thats my point - you learn absolutely that there is probably something amiss if you have headers for which you do not have a block, and several of these things are fine from a privacy perspective to learn that. in that case, it makes sense for net_processing to go make some new connections and see if it cant find the block. if it fails to after some time, go query cloudflare.deanonymizingseed.com cause, like, its better 19:57:44 than not getting the block (at least if you're a ln user or so and have it configured to do this), but you first want to give net_processing a chance here. so, essentially, sleep(300) is exactly what you want :) 19:58:16 wumpus: thanks, I want to spend more time scoping to the minimal step but yet extendable after 19:58:42 wumpus: lol, sorry...I wrote out all 4 of the (headers-over-dns, headers-over-radio, blocks-over-http, secondary-p2p-client) things before, so apologies we're a bit three-steps-ahead here :/ 19:59:38 this all was, in fact, the rust branches. 20:00:05 BlueMatt: yes, I know, it was great! unfortuantely the approach to integrate them into bitcoin core didn't work with regard to review and organizationaly 20:00:05 BlueMatt: okay I see your point, but you need to dissociate cleanly 1) anomalies detection and 2) reaction 20:00:14 reaction may happen through net_processing or alt-transports 20:00:20 wullon5: yea, no, not complaining, just providing historical context for folks 20:00:22 wumpus: 20:00:54 ariard: right, kinda, but I think part of my goal at least here is that there should be an absolute minmal amount of common code between the various sources 20:01:06 wrapping up the meeting 20:01:14 thanks everyone for the lively discussion 20:01:22 BlueMatt: ideally yes but I fear our internal components aren't that much clean yet 20:01:29 ariard: cause if there's a bug in anomoly-detection (which we've had 20 issues with in the past, turns out its hard to get right), then all of a sudden your 5 block sources are all stuck, instead of providing the redundancy they're there for. 20:01:41 #endmeeting