19:00:09 <laanwj> #startmeeting 
19:00:09 <core-meetingbot> Meeting started Thu Nov 11 19:00:09 2021 UTC.  The chair is laanwj. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
19:00:09 <core-meetingbot> Available commands: action commands idea info link nick
19:00:19 <hebasto> hi
19:00:24 <provoostenator> hi
19:00:28 <fjahr> hi
19:00:37 <michaelfolkson> hi
19:00:45 <laanwj> #bitcoin -core-dev Meeting: achow101 _aj_ amiti ariard BlueMatt cfields Chris_Stewart_5 darosior digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jarolrod jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral laanwj larryruane lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball
19:00:47 <laanwj> morcos nehan NicolasDorier paveljanik petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
19:01:16 <ariard> hi
19:01:26 <larryruane> Hi
19:01:41 <laanwj> one proposed meeting topic for this week: Some ASMap questions (fjahr)
19:02:42 <laanwj> any other topics people want to discuss in the meeting?
19:03:23 <michaelfolkson> Maybe quickly on bitcoincore.org
19:03:24 <laanwj> #topic High priority for review
19:03:24 <core-meetingbot> topic: High priority for review
19:03:32 <sipa> hi
19:03:33 <laanwj> michaelfolkson: ok
19:03:36 <dongcarl> hi
19:04:05 <laanwj> https://github.com/bitcoin/bitcoin/projects/8   currently 11 blockers, 1 chasing concept ACK
19:04:18 <laanwj> anything to add, remove, or that is almost ready for merge?
19:05:26 <sipa> what is the status with #23114 ?
19:05:29 <gribble> https://github.com/bitcoin/bitcoin/issues/23114 | Add minisketch subtree and integrate into build/test by fanquake · Pull Request #23114 · bitcoin/bitcoin · GitHub
19:06:09 <laanwj> sipa: i think it's ready or very close to
19:07:52 <sipa> yeah just not sure if anyone is waiting for something
19:08:11 <laanwj> sipa: no, thanks for reminding me
19:09:11 <laanwj> nothing to change in blockers? moving on to next topic, then
19:09:27 <laanwj> #topic Some ASMap questions (fjahr)
19:09:27 <core-meetingbot> topic: Some ASMap questions (fjahr)
19:09:38 <fjahr> Hi! In coordination with Gleb I am working on getting ASMap bucketing the attention that it deserves. As many probably know, the feature was merged almost 2 years ago and is currently opt-in.
19:09:49 <fjahr> If you want to use the feature without trusting someone’s random file you have to build and run a couple of scripts in order to create the file yourself. This was intentional, allowing those interested and savvy enough to use the feature with making it the default. It seems now the time has come to make asmap the default.
19:10:13 <fjahr> I am still doing a lot of research on what the process of creating the “official” asmap file should look like ideally. I will come back with more info on that, but for now I have a few questions with the goal of nailing down a few other pieces of the puzzle.
19:10:39 <fjahr> First of all I want to renew Gleb’s call to action here (see https://blog.bitmex.com/call-to-action-testing-and-improving-asmap/) and ask anyone to share feedback if there is any that you haven’t shared with Gleb already. Please let me know if you have been running the feature made any experiences worth sharing (good or bad could both be helpful)!
19:11:14 <laanwj> yes, it now has been experimental for quite a while, people tested it and didn't find any critical issues
19:11:35 <sipa> i think the big questions are around tooling & process for distributing/integrating an asmap file
19:11:40 <laanwj> though there are some practical issues with integrating the file into the build process
19:11:41 <sipa> not the lookup code itself
19:12:04 <laanwj> right
19:12:23 <fjahr> sipa: what is the lookup code?
19:13:33 <sipa> fjahr: the currently integrated asmap code in bitcoin core, i mean
19:13:44 <sipa> that looks up ASNs in the asmap file
19:13:53 <fjahr> ah, ok, yeah
19:14:36 <fjahr> So, one question on tooling in the wider sense: Technically #18573 has received enough concept acks but I liked Sjors’ suggestion to put it into bitcoin-util, which might make it easier to pull out the functionality later on. Some people have noted that putting it in a separate library would be good for reuse in other projects, others would like to see that code shipped with core. I think this is a good middle ground for now. Does
19:14:36 <fjahr> anyone have objections? (I know a better question to ask in the issue but I thought, while I am here…)
19:14:37 <laanwj> e.g. one thing to consider, besides deterministic build details, is how to ship it, to embed the data into the binary is not practical because then bitcoind and bitcoin-qt would both need a copy
19:14:37 <gribble> https://github.com/bitcoin/bitcoin/issues/18573 | [RFC] bitcoin-asmap utility by sipa · Pull Request #18573 · bitcoin/bitcoin · GitHub
19:15:49 <laanwj> no, no objections with adding it to bitcoin-util
19:15:58 <_aj_> +1 on adding it to bitcoin-util
19:16:01 <sipa> the problem is really that it can't be made deterministic, as there is no authoritative source
19:16:23 <fjahr> laanwj: hm, my impression was that shipping it included in a release would be the most practical option
19:16:25 <luke-jr> separate is usually better
19:16:32 <laanwj> better than adding yet another binary
19:16:48 <sipa> there are many ways of gathering source data of ASNs, like downloading it from certain providers, or if you're BlueMatt, generating it from your own BGP router
19:17:22 <laanwj> fjahr: yes, but that would imply a deterministic build, and some way for the bitcoind/bitcoin-qt to automatically find the file that was downloaded with the distribution, i mean
19:17:36 <fjahr> sipa: yes, I am actively researching this part so I would like to keep this discussion for another time :)
19:17:41 <sipa> fjahr: surew
19:17:51 <laanwj> it could be something simple like 'look in the directory of the binary' or a relative path or whatnot
19:18:28 <sipa> what tooling do we expect to have? i think we want ways to encode/decode/lookup (as the current code has), but probably always ways of diffing/patching, and perhaps other kinds of analysis
19:18:29 <laanwj> in any case it's something that needs to be considered, clearly not in thismeeting
19:18:33 <luke-jr> laanwj: the directory of the binary can be /usr/bin :p
19:18:47 <sipa> do we imagine all of these to become separate commands in bitcoin-util?
19:18:49 <laanwj> luke-jr: yes, it's different for linux and windows maybe
19:18:55 <laanwj> sipa: i suppose so
19:19:31 <luke-jr> why the push to put it in the Core repo? it has nothing to do with Bitcoin and is a generally useful thing…?
19:19:44 <_aj_> sipa: either "bitcoin-util asmap {encode,decode,lookup}" or "bitcoin-util {asmap-encode,asmap-decode,asmap-lookup}"
19:19:55 <fjahr> yeah, that's what I am thinking too but I first want to have a clear picture which commands are really helpful
19:20:24 <sipa> luke-jr: well the obvious question is which is most likely to progress - there are barriers/overhead to creating yet another repository to maintain
19:20:41 <sipa> i agree it's potentially generally useful though, but as long as it doesn't get built, it's nothing at all
19:20:42 <laanwj> luke-jr: not sure if you're talking about the utilities or the file here, but the asmap file is not going to be in the repo, the idea is to put the utilities there for now it can always be spun off
19:20:54 <sipa> i was talking about the tools
19:21:30 <sipa> so my thinking is that if starting the project as being something integrated into core results in it being actually useful/used, it can be spun off
19:21:35 <laanwj> if someone wants to maintain separate asmap utilties might be better to wait until other projects actually want to use it
19:21:41 <fjahr> luke-jr: also some people noted it would be better to have the the tools right there so people would not need to get another tool for the auditing. But long term I absolutely agree.
19:22:14 <luke-jr> they're no more "right there" than any other tool :/
19:22:44 <fjahr> sipa, laanwj: I agree, let's see if there is actual interest
19:23:04 <sipa> i don't think the "right here" matters that much - normal users won't be using these tools
19:23:13 <sipa> it's just a matter of getting the project going
19:24:00 <michaelfolkson> +1
19:24:03 <laanwj> i'm also against scope creep, but, in bitcoin-util doesn't seem to be a big problem, it's some maintenance cost, sure, but no attack surface or bug risk for running nodes
19:24:04 <luke-jr> the only overhead I know of is writing a configure script; if that's the issue, I can try to make time to put one together
19:24:27 <laanwj> of course, there already *is* the bitcoin-maintainer-tools repository where it could go
19:24:31 <sipa> luke-jr: there is also just management overhead; you need maintainers for a project, who are active, ...
19:24:33 <laanwj> but that's also bitcoin speicifc
19:24:39 <sipa> reviewers, who care to look at the repo
19:24:44 <luke-jr> sipa: that's true no matter what repo it's part of
19:24:49 <laanwj> (well, github-merge.py does see some externral use)
19:25:14 <lightlike> if the plan is  to have some kind of ceremony for each release, in which multiple contributors are going to build the asmap that would be distributed with it and compare these in some way, I think it might make sense to have it in the repo
19:26:13 <laanwj> lightlike: i don't think it matters for that if the tools are in the repo or a separate one for that?
19:26:52 <sipa> we'll definitely wants scripts/tooling specific to the creation/ceremony of the bitcoin-core-shipped asmap file in our repo, but that doesn't require the software tools involved to be there too
19:27:13 <laanwj> the main difference is whether they're versioned in tandem with bitcoin core itself
19:27:16 <sipa> right
19:27:40 <laanwj> sipa: yes, true
19:28:06 <_aj_> unless the format changes, you'd want to use the latest asmap file even if you're running an old bitcoind for some reason, no?
19:28:25 <sipa> _aj_: that's a good point
19:28:39 <laanwj> that makes sense
19:28:42 <fjahr> yeah, I would suggest we create a new repo in the org which hosts all of the asmap files that are shipped with each release. The historic ones would be interesting for auditing and the newest ones can be used by users of older releases that still wish to run with a newer asmap file.
19:29:09 <laanwj> agree, a separate repository for the asmap files definitely a good idea
19:29:40 <laanwj> the build process has to get them from somewhere too
19:29:40 <luke-jr> which makes the case for a separate tool repo even stronger IMO
19:30:09 <fjahr> Related to that, in terms of releasing the updated “official” ASMaps I am thinking that once with every release (major and minor) will be sufficient. Some people suggested a higher frequency but it is not clear yet if that is a significant win in terms of security and it would produce more work for maintainers.
19:30:19 <laanwj> what's the argument against putting the tools in bitcoin-maintainer-tools
19:30:33 <fjahr> Of course if my research ends up suggesting otherwise, I would propose a higher frequency
19:30:43 <_aj_> encoding/decoding is presumably easier with all the code already in bitcoind?
19:30:43 <luke-jr> laanwj: they're not Bitcoin-related? :P
19:30:45 <laanwj> it's for maintainers / very involved developers anyway
19:31:13 <_aj_> (though using the python code would probably be just as easy as using the c++ code, i guess?)
19:31:36 <sipa> _aj_: the code in bitcoin core currently only does lookup
19:31:48 <laanwj> the language doesn't matter that much
19:31:53 <_aj_> sipa: i mean #18573
19:31:55 <gribble> https://github.com/bitcoin/bitcoin/issues/18573 | [RFC] bitcoin-asmap utility by sipa · Pull Request #18573 · bitcoin/bitcoin · GitHub
19:31:58 <sipa> ah yes
19:32:05 <laanwj> sure, currently all the maintainer tools are python, but there's no reason there couldn't be c++ code there
19:32:11 <luke-jr> fjahr: maybe update them when there are major changes, but at least once every 6 months?
19:32:25 <laanwj> i'm sure that's advantegous from a performance perspective
19:32:40 <laanwj> it's quite a lot of data to crunch isn't it?
19:32:44 <_aj_> i'm +1 on either bitcoin-util or adding to the maintainer tools repo, whichever actually gets a PR
19:33:01 <laanwj> yes, no strong opinion either really
19:33:04 <fjahr> luke-jr: it will be very hard to define what a major change is but I am working on getting a better picture on that
19:33:21 <laanwj> but creating yet another repo for the tools seems suboptimal to me right now
19:34:11 <laanwj> but if someone wants to commit to maintaining this i'm also not strongly against it
19:34:44 <laanwj> exactly, whatever gets a PR
19:34:46 <_aj_> laanwj: should the asmap data be in its own repo, or some other one?
19:35:00 <laanwj> _aj_: asmap *files* should get their own repo
19:35:07 <laanwj> not the same one as the tools in any case :)
19:35:38 <_aj_> sgtm
19:35:39 <laanwj> i think that's straightforward, no maintenance there, just put the file in the repo when it's done
19:35:59 <laanwj> same as the various -sigs ones
19:36:35 <fjahr> Ok, last question for now: I think it would be good to provide a startup parameter that allows switching back to /16 if people feel they want to do that. So basically forcing the 'asmap file missing' case. Should there also be a comfortable option to switch for GUI users or is it not needed? (asking this as a true GUI noob)
19:37:10 <laanwj> if it's a startup parameter it could also be an option in the GUI options dialog
19:37:16 <laanwj> not that much work
19:37:33 <fjahr> ok, sounds good
19:37:44 <_aj_> fjahr: -noasmap ?
19:38:10 <fjahr> _aj_: didn't think about a name but yeah
19:38:26 <laanwj> though it maybe somewhat obscure and hard to explain for GUI end users, the people diving so deep into network specifics are likely able to edit bitcoin.conf
19:39:06 <laanwj> e.g. imagine translators being confronted with stuff about autonomous systems :-)
19:39:20 <fjahr> heh, true
19:40:05 <laanwj> next topic?
19:40:07 <fjahr> Unless there are other comments, that's it from me, thanks for the input!
19:40:18 <laanwj> no problem, thanks for your work on this
19:40:28 <sipa> cool
19:40:49 <laanwj> #topic Maybe quickly on bitcoincore.org (michaelfolkson)
19:40:49 <core-meetingbot> topic: Maybe quickly on bitcoincore.org (michaelfolkson)
19:41:22 <michaelfolkson> Ok so I was looking through bitcoincore.org and I was wondering if I was missing some historical context on the purpose of the site
19:41:50 <laanwj> it basically has one purpose: downloading the software
19:41:53 <michaelfolkson> It was heavily used for the SegWit soft fork and for things like RBF info to users but hasn't been used at all for Taproot information really
19:42:05 <michaelfolkson> Ok and that's deliberate right?
19:42:15 <laanwj> there's also developer documentation on it under the doxygen subdomain
19:42:19 <laanwj> yes
19:42:39 <michaelfolkson> Ok that answers my question :)
19:43:25 <laanwj> agree there's some really outdated information on it
19:43:30 <michaelfolkson> I wondered if it was just because harding had less time these days or something. But good to know it is deliberate
19:43:43 <michaelfolkson> I can see the arguments for doing that too
19:43:51 <laanwj> or at least, stuff written against a very old context, like the RBF faq you mention
19:44:14 <michaelfolkson> Most of it is still interesting/a good read but yeah slightly outdated
19:44:26 <_aj_> optech and stackoverflow seem more popular places for that sort of info today; they weren't really options at the time
19:44:32 <laanwj> that's also part of the reason, there's also no one to do it, but i'm also not sure it should be done, there's enough information in other places
19:44:40 <laanwj> yes optech is great
19:44:51 <michaelfolkson> Ok cool, thanks
19:45:38 <laanwj> thanks, that concludes the meeting, i think, unless someone has another last minute topic
19:46:28 <laanwj> #endmeeting