19:01:19 <wumpus> #startmeeting
19:01:19 <lightningbot> 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 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:01:22 <jnewbery> hi
19:01:23 <kanzure> hi
19:01:24 <jeremyrubin> hi
19:01:24 <wumpus> let's try...
19:01:26 <jkczyz> hi
19:01:36 <achow101> hi
19:01:42 <fjahr> hi
19:01:49 <ariard> hi
19:01:51 <wumpus> #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 <jonatack> late night hi
19:01:52 <wumpus> jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
19:02:02 <hebasto> hi
19:02:24 <elichai2> Hi
19:02:33 <wumpus> one proposed meeting topic: alternative transports support (ariard)
19:02:39 <ariard> yes!
19:02:49 <instagibbs> hi
19:02:51 <wumpus> any last minute proposals?
19:02:53 <amiti> hi
19:02:59 <meshcollider> hi
19:03:42 <wumpus> okay, let's start with high priority for review as usual
19:03:48 <wumpus> #topic High priority for review
19:03:48 <luke-jr> hi
19:03:57 <aj> hi
19:03:58 <hebasto> could #18297 be added to hi-prio?
19:04:00 <gribble> 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 <wumpus> https://github.com/bitcoin/bitcoin/projects/8  4 blockers, 1 bugfix, 4 chasing concept ACK
19:04:28 <wumpus> hebasto: yes
19:04:37 <hebasto> wumpus: thanks
19:05:00 <achow101> #18787 for hi prio
19:05:02 <gribble> 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 <wumpus> achow101: added
19:07:31 <wumpus> #topic Alternative transports support (ariard)
19:07:41 <wumpus> #18989
19:07:43 <gribble> https://github.com/bitcoin/bitcoin/issues/18989 | Towards alternative transports first-class support · Issue #18989 · bitcoin/bitcoin · GitHub
19:07:48 <ariard> Okay so I've explored a bit alternative transports support
19:08:08 <ariard> as it has been previously attempted by Matt with headers-over-radio or headers-over-DNS
19:08:15 <wumpus> is there anything special needed at our side with regard to that?
19:08:32 <ariard> well I want to assert project worthiness
19:08:39 <wumpus> couldn't any extenal software route the P2P port over some other transport?
19:08:40 <luke-jr> there's also Blockstream's blocks-over-satellite
19:09:02 <ariard> yes but idea is to increase easiness of link layer diversity
19:09:34 <ariard> wumpus: you may want to receive blocks on one transport like satellites and broadcast them over another medium
19:09:49 <wumpus> 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 <wumpus> I didn't read your proposal yet so I might be off
19:10:12 <ariard> wumpus: I agree that's why my proposal is splitting drivers from fetching logic
19:10:27 <ariard> It's just a generic driver framework
19:10:40 <sipa> but the drivers would things you compile in?
19:10:41 <ariard> drivers should obviously lay outside of core
19:10:44 <sipa> or external applications?
19:10:52 <wumpus> if it's external applications that's great
19:10:55 <sipa> (even if not maintained in our repository)
19:11:01 <ariard> sipa: compile in or external applications like meek or snowflake
19:11:10 <jb55> why do we integrate tor then
19:11:13 <ariard> yes I don't want them to be maintained in the repo
19:11:34 <sipa> jb55: i think there is a difference between routing and non-routing transports
19:11:34 <wumpus> jb55: historical legacy, as well as being the most popular one probably
19:11:36 <ariard> jb55: with regards to their pluggable transports
19:12:02 <sipa> 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 <ariard> wumpus: it's the most popuplar one ofc, but their threat model is a bit diffrent than our
19:12:07 <luke-jr> we don't integrate tor really
19:12:15 <luke-jr> we just have bits to interoperate with it
19:12:21 <ariard> sipa: yes peer policy would be left to the driver
19:12:22 <sipa> but just a "i have a way to connect to some other node, please communicate through it"
19:12:53 <wumpus> that makes sense
19:12:57 <ariard> like if your alternative transport is a satellite, there is no that much peer
19:13:21 <sipa> so this would be outside addrman, addr (or addrv2) messages, ...
19:13:22 <ariard> also you may receive block from an uni-directional channel but want to broadcast tx over another one
19:13:23 <wumpus> yes, I agree that could be facilitatd better
19:13:26 <ariard> in reaction to this
19:13:39 <ariard> sipa: yes not melding with addrman
19:13:45 <wumpus> maybe through hints in a special-permissioned P2P connection
19:13:56 <ariard> sipa: you may reuse addr messages but that's up to driver
19:13:59 <luke-jr> p2p stuff needs Core-side integration ofc
19:14:13 <luke-jr> well, maybe not
19:14:17 <wumpus> yes, in a sense
19:14:18 <ariard> luke-jr: may you precise ?
19:14:31 <luke-jr> I guess they can do their own addr-equivalent messages on their own transport
19:14:31 <sipa> 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 <sipa> but there may be easier ways of integrating
19:14:50 <fjahr> 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 <ariard> sipa: like a supplemental daemon supporting all drivers ?
19:15:02 <sipa> fibre-like things are harder, as they need mempool access
19:15:08 <luke-jr> would be ideal to split out current p2p stuff external someday too
19:15:11 <sipa> ariard: or one daemon per driver
19:15:13 <wumpus> what we're not going to do: include it all into the repository, or dynamic library based plugin mechanisms
19:15:23 <sipa> wumpus: agree
19:15:30 <ariard> fjahr: yes some LN routing nodes operators would like block redundancy
19:15:34 <wumpus> everything else is fine
19:16:03 <ariard> sipa: yes you may have one daemon per driver but ideally you may react on what your learn one driver
19:16:21 <sipa> i can't parse your sentence
19:16:48 <wumpus> if it runs in an external process and communicates with bitcoin core that's the right way
19:16:56 <ariard> wumpus: yes agree doesn't make sense to include it all into the repo
19:17:08 <wumpus> if it requires a little extra support on our side that's ok
19:17:15 <jb55> for tor it just connects to a local proxy socket right? isn't this general enough?
19:17:19 <jeremyrubin> What about making our P2P function that way wumpus?
19:17:43 <wumpus> jb55: yes, there's a little specificsupport for incoming connections by creating a hidden service
19:17:52 <ariard> 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 <sipa> jb55: that wouldn't work for a satellite connection for example
19:18:02 <jeremyrubin> 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 <wumpus> jeremyrubin: in the long run maybe
19:18:13 <sipa> jb55: as you can't route a bidirectional byte stream
19:18:26 <jb55> sipa: satellite would require custom deserialization code as well if I understand correctly
19:18:33 <ariard> jeremyrubin: ideally but that's too much carefull refactor
19:18:34 <jeremyrubin> wumpus: also seems good from a security perspective -- no DMA if you pop the transit layer :)
19:19:00 <jeremyrubin> I think ryanofsky probably has some insight here
19:19:16 <jeremyrubin> Don't you have a seperate network process branch right now?
19:19:25 <jeremyrubin> Or is it just wallet stuff presently
19:19:26 <ariard> better integration with core would ease deployement therefore making the number of such alternative transport used higher
19:19:36 <wumpus> jeremyrubin: yes, gmaxwell had some ideas in that direction as well, run the whole P2P in a sandboxed process
19:19:38 <sipa> 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 <ariard> and this would increase network security
19:20:11 <ariard> sipa: fibre is so much special, not in my integration target
19:20:16 <sipa> ariard: ok
19:20:29 <ariard> I'm more interesred by headers-over-DNS or domain-fronting or radio integration
19:20:35 <wumpus> let's aim lower first ...
19:20:37 <jeremyrubin> sipa: IPC shared memeory the mempool for fibre?
19:20:38 * jeremyrubin ducks
19:20:39 <sipa> that's fair
19:20:40 <wumpus> it coudl always be extended later
19:20:50 <wumpus> to way-out ideas like that
19:20:57 <ariard> yes I want something simple first, like headers-over-DNS
19:20:58 <jb55> what's the simplest non-invasive use case?
19:21:14 <sipa> ariard: headers-over-DNS could even just done with RPC, i think?
19:21:16 <wumpus> nothgin is going to happen at all if that's a requirement for the first version though :)
19:21:23 <sipa> (a daemon communicating through RPC)
19:21:47 <wumpus> memmap the mempool lol :)
19:21:54 <ariard> 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 <ariard> even for power users
19:22:54 <ariard> I want to explore if we can integrate with multiprocess and just have another new process supporting the drivers
19:22:56 <sipa> ariard: compared to c-lightning which is already half a dozen daemons? ;)
19:23:36 <ariard> sipa: I know it doesn't work well for embedded or mobile envs
19:24:41 <wumpus> why not?
19:24:57 <ariard> and I think actually blocksat is its own fork of core
19:24:58 <wumpus> on limited 32-bit platforms it's usually better to have a zillion separate processes than threads within the same process
19:25:28 <wumpus> e.g. at least they don't have to share an address space
19:25:42 <ariard> well actually with my driver interface design if you want to fork() behind you can
19:25:46 <ryanofsky> 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 <ariard> it's up to the driver implementation
19:26:14 <wumpus> ryanofsky: security, limits static linking, and having to provide a binary interface
19:26:51 <wumpus> also cross platform stuf
19:27:07 <wumpus> dynamic libraries are slightly but different enough to make your life a pain between windows and linux
19:27:11 <ariard> wumpus: on security/fault-tolerance that's why I think a separate process would be better
19:27:17 <wumpus> yes, it is
19:27:24 <ariard> contrary to Matt stuff spawning new threads
19:27:41 <wumpus> separate processes are better for isolation/security
19:27:41 <ariard> now what should be the threading model of such new process it's another question
19:27:49 <ariard> wumpus: agree
19:28:47 <ariard> but current proposal is just to have fetching/broadcast logic in this new process and talk to a driver interface
19:29:04 <ryanofsky> 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 <ariard> fetching logic is operating over abstract driver attributes like fHeaders or fBlocks
19:29:07 <wumpus> that's interesting, I'll read the issue more closely
19:29:36 <ryanofsky> 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 <ariard> wumpus: yes I want to rely drivers devs to write their own fetching logic for each transport
19:29:51 <BlueMatt> 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 <BlueMatt> 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 <wumpus> bitcoin core is I/O bound but usually only on disk, not on P2P/network
19:30:37 <ariard> BlueMatt: I know, I need to rework the threading model, but ideally your rust-based drivers should be reused
19:30:48 <BlueMatt> ariard: I dont think the threading model is the only issue there
19:30:53 <BlueMatt> i think it needs to be way more free-form
19:31:15 <BlueMatt> eg the rust stuff was just exposing ProcessNewBlock(Headers) and FindNextBlocksToDownload
19:31:20 <BlueMatt> as well as an api to get header state
19:31:21 <ariard> BlueMatt: more asynchronous ?
19:31:32 <BlueMatt> and leaving it up to the driver what to do with that
19:31:41 <BlueMatt> cause drivers may have very different capabilities in terms of how to query
19:31:52 <sipa> i guess that's a question of layering
19:31:53 <ryanofsky> 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 <BlueMatt> 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 <sipa> 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 <BlueMatt> ryanofsky: I'm suggesting start with less api, and add more over time :)
19:32:22 <sipa> but it's not the right solution for everything
19:32:37 <BlueMatt> i dont think its the right solution for...almost anything we'd want to do here?
19:32:50 <BlueMatt> like, some of the most exciting options would be https domain fronting
19:32:56 <BlueMatt> and its not a byte stream, its a query interface
19:33:08 <sipa> what is https domain fronting?
19:33:08 <ariard> yes that's why fetching logic should adapt its request to driver capabilities
19:33:18 <ariard> like don't send GETHEADERS if it's unidirectional
19:33:41 <ariard> sipa: https://www.bamsoftware.com/papers/fronting/
19:33:42 <BlueMatt> sipa: where you hit commoncdn.amazon.com in SNI, but the http host header is magicbitcoinproxy.amazonuser.com
19:33:54 <sipa> SNI?
19:34:10 <BlueMatt> 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 <BlueMatt> sipa: ssl plaintext hostname in the connection setup
19:34:19 <ariard> sipa: https://en.wikipedia.org/wiki/Server_Name_Indication
19:34:32 <sipa> i'll read the link
19:34:41 <sipa> no need to unnoob be here
19:35:10 <BlueMatt> ariard: i dont even think 'bidirectional' is a reasonable assumption here - eg radio-based stuff is likely to be unidirectional
19:35:16 <BlueMatt> (and could be *either* read or write)
19:35:20 <ariard> yes censorship circumvention is a huge topic in itself, and some of Tor stuff may not fit your threat model
19:35:33 <jnewbery> if it's possible to unnoob the rest of us in a sentence or two, that might be helpful though
19:35:46 <ariard> BlueMatt: yes capabilities need refinement
19:35:59 <ryanofsky> jnewbery, it's just a string passed to disambiguate when you have web servers for different domains on the same ip
19:36:03 <jb55> jnewbery: its like the http Host header for tls connections
19:36:23 <BlueMatt> 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 <sipa> i feel people are trying to explain minor details while i (or some) are missing the big picture
19:36:38 <BlueMatt> think of, eg, amazon aws javascript cache
19:37:05 <BlueMatt> 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 <sipa> i hear "something something https bypass GFW", but not what or how that'd be used
19:37:13 <ariard> sipa: agree there is a lot of alternative transports, integration with each of them may bring you more security/privacy
19:37:28 <ariard> therefore making them easier to deploy would be great
19:37:35 <jeremyrubin> ariard: or less as you add more too
19:37:39 <ryanofsky> 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 <sipa> ryanofsky: ok, that's helpful!
19:38:01 <sipa> why is it unidirectional?
19:38:04 <ariard> jeremyrubin: there is a risk of privacy leakage, it should be well-documented I agree
19:38:24 <jnewbery> Very helpful. Thanks ryanofsky jb55 BlueMatt
19:39:05 <ariard> domain-fronting increase cost of censorship, because now you have to harm ingenous traffic too
19:39:16 <instagibbs> Signal uses this IIRC
19:39:59 <jb55> could I use altnet to send a tx via carrier pidgin
19:40:03 <BlueMatt> its been very effecive for signal, in fact
19:40:18 <ariard> 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 <instagibbs> BlueMatt, AWS got mad at them didn't hear the result of it :P
19:40:32 <BlueMatt> instagibbs: the result was to use azure
19:40:35 <BlueMatt> who did not get mad
19:40:37 <sipa> jb55: using pidgin to steganographically hide the traffic is a great idea!
19:40:40 <instagibbs> Ahhh
19:40:41 <BlueMatt> (yet)
19:40:52 <wumpus> hehe
19:40:54 <jb55> pigeon*
19:41:01 <instagibbs> But indeed, seems to work inside China quite well considering
19:41:26 <ariard> yes if we have such generic driver framework, drivers devs may just focus on improving protocol fingerprint hidding
19:42:58 <BlueMatt> exactly. but it needs to be super flexible to support all these different crazy ideas
19:43:11 <wumpus> but not necessarily initially, it just needs to be extendable
19:43:17 <ariard> 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 <ariard> and come with a cleaner design proposal
19:43:31 <jnewbery> 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 <sipa> 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 <wumpus> 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 <ariard> sipa: I've been working on this the last few days, will make it public soon
19:44:46 <ariard> wumpus: you don't want to overdesign, but let room in the design to step-by-step extend it
19:44:47 <BlueMatt> jnewbery: these types of things need only very few calls into the rest of core
19:44:53 <wumpus> ariard: yes
19:45:03 <BlueMatt> 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 <ariard> jnewbery: the kind of changes Carl is working on to separate net_processing from validation
19:45:21 <BlueMatt> (and that branch has all 4 written, though in rust)
19:45:24 <wumpus> just trying to warn to not get overenthousiastic I've seen this before :)
19:45:32 <BlueMatt> so I really dont think separating or cleaning up net_processing is at all required here
19:45:47 <BlueMatt> 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 <ariard> wumpus: I agree, that's kind of slow work like multiprocess is
19:45:54 <wumpus> jeremyrubin: ROFL
19:45:58 <BlueMatt> and validation.h is a relatively small API
19:46:01 <ariard> I'm well aware of
19:46:46 <wumpus> i'm stoked for neutrino relay, uncensorable by physics !
19:46:55 <sipa> "it's faster than C!"
19:47:02 <BlueMatt> lol
19:47:05 <wumpus> hehe
19:47:06 <ariard> 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 <wumpus> that would be very nice
19:47:57 <BlueMatt> cause, like, some issues with using spectrum without pissing off a bunch of hams aside, is totally practical
19:48:00 <jeremyrubin> I'd just be worried that if we set up neutrino relay that we'd start getting extraterrestrial blocks
19:48:11 <sipa> 800 bytes per 10 minutes is slightly higher than 1 bit per second
19:48:17 <wumpus> jeremyrubin: win/win
19:48:18 <sipa> i wonder how much energy you need to moonbounce that
19:48:29 <ariard> 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 <BlueMatt> sipa: ha! I was having a conversation about moonbouncing header relay like an hour ago
19:48:47 <BlueMatt> ariard: I just have the 4 that I listed previously, all of which I think are cool.
19:48:56 <jeremyrubin> How many TXs can we fit in the latency between here and the moon?
19:49:06 <BlueMatt> (and sufficiently variable in the features they offer that they are a good test case)
19:49:06 <jeremyrubin> MoonMemPoolTapeDeck
19:49:17 <ariard> BlueMatt: cooool will go through this whole conv again to bookmark
19:49:44 <ariard> oh in fact i've already you branch bookmarked :) the doc starter is nice
19:49:44 <BlueMatt> 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 <BlueMatt> 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 <ariard> 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 <BlueMatt> 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 <ariard> anyone has opinion on this ?
19:51:16 <BlueMatt> ariard: as long as its purely additive, who cares! :)
19:51:16 <ariard> and such side-effect may not be desirable
19:51:30 <jonatack> 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 <ariard> BlueMatt: right if everything is opt-in I think that's okay
19:51:53 <jeremyrubin> I don't think it's addititive
19:51:57 <BlueMatt> (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 <ariard> jonatack: I know review process and getting the first chunks PRs are the hardest steps :)
19:52:03 <jeremyrubin> This increases partitionability
19:52:21 <jeremyrubin> but increases availability I think?
19:52:22 <BlueMatt> 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 <BlueMatt> but maybe only after having the regular p2p code make some new connections
19:52:45 <ariard> BlueMatt: exactly that's kind of the idea of having a watchdog for this
19:52:58 <BlueMatt> you dont need anything fancy to do that, though
19:53:04 <BlueMatt> only a sleep(300) :)
19:53:13 <ariard> that's hacky
19:53:16 <BlueMatt> no its not
19:53:24 <BlueMatt> its actually exactly what you want here
19:53:35 <sipa> wth are you guys talking about
19:53:38 <BlueMatt> give net_processing a chance to figure out how to fetch the block if we're missing one
19:53:47 <ariard> BlueMatt: don't use a privacy-harming communication channel if you don't have to
19:53:51 <BlueMatt> and if it fails to within 5 minutes, turn on the http client and give up privacy for the block data
19:54:00 <BlueMatt> right, exactly, thats why you sleep(300) :)
19:54:17 <wumpus> ~5 minutes to go
19:54:19 <jnewbery> I agree with sipa
19:54:24 <BlueMatt> sipa: if, eg, you learn a header over radio, but that source doesnt provide blocks, what do you do?
19:54:36 <BlueMatt> oh, wait, is this still a meeting? lol I'll shut up.
19:54:47 <jnewbery> perhaps this more speculative discussion is better suited to bitcoin-wizards or similar?
19:54:49 <ariard> 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 <sipa> sleep(300) till the end of the meeting
19:55:04 <wumpus> jnewbery: yes, though we don't have any other topics queued for today
19:55:39 <ariard> jnewbery: agree again I invite people to pursue discussion on the issue or PR, it's better suited
19:55:43 <sipa> BlueMatt: i don't know, why would you do anything?
19:56:24 <sipa> i feel like i'm missing a lot of context
19:56:58 <wumpus> anyhow I agree with jonatack: restrict scope initially, don't try to do too many out-there things at once
19:57:25 <wumpus> though it's good that you're clearly having a lot of ideas
19:57:28 <ariard> sipa: yes I will try to come with some Q&A-style of doc to inform people better
19:57:40 <wumpus> but some of us hardly follow :)
19:57:44 <BlueMatt> 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 <BlueMatt> 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 <ariard> wumpus: thanks, I want to spend more time scoping to the minimal step but yet extendable after
19:58:42 <BlueMatt> 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 <BlueMatt> this all was, in fact, the rust branches.
20:00:05 <wumpus> 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 <ariard> BlueMatt: okay I see your point, but you need to dissociate cleanly 1) anomalies detection and 2) reaction
20:00:14 <ariard> reaction may happen through net_processing or alt-transports
20:00:20 <BlueMatt> wullon5: yea, no, not complaining, just providing historical context for folks
20:00:22 <BlueMatt> wumpus:
20:00:54 <BlueMatt> 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 <wumpus> wrapping up the meeting
20:01:14 <wumpus> thanks everyone for the lively discussion
20:01:22 <ariard> BlueMatt: ideally yes but I fear our internal components aren't that much clean yet
20:01:29 <BlueMatt> 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 <wumpus> #endmeeting