18:59:23 <wumpus> #startmeeting
18:59:23 <lightningbot> Meeting started Thu Oct 22 18:59:23 2020 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:59:23 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:59:39 <kanzure> hi
18:59:43 <jnewbery> hello
18:59:47 <emzy> hi
18:59:48 <hebasto> hi
18:59: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
18:59:53 <wumpus> amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
19:00:01 <sipa> hi
19:00:04 <jonatack> hi
19:00:22 <jonasschnelli> hi
19:00:23 <wumpus> no topics have been proposed yet in http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt
19:00:40 <wumpus> any last-minute ones?
19:01:05 <sipa> yay for all the work that made it into 0.21
19:01:15 <jnewbery> +1
19:01:15 <wumpus> yes!!!
19:01:32 <achow101> hi
19:01:36 <michaelfolkson> 21.0 not 0.21
19:01:44 <achow101> michaelfolkson: not yet
19:01:47 <michaelfolkson> haha
19:02:10 <wumpus> #topic 0.21 milestone
19:02:15 <wumpus> https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.21.0
19:02:17 <emzy> I have a DNSSEC setup for dnsseed. Not directly bitcoin core related.
19:02:48 <wumpus> I think this is the high priority for review now
19:03:06 <fjahr> hi
19:03:25 <hebasto> is any way to label with 0.21 milestone prs from the https://github.com/bitcoin-core/gui ?
19:03:53 <wumpus> the planned date for the branch split-off and rc1 is 2020-11-01
19:04:06 <wumpus> hebasto: there are no milestones there?
19:04:19 <wumpus> we probably need to create them then
19:05:06 <hebasto> wumpus: no milestones at all
19:05:19 <wumpus> emzy: would DNSSEC help there?
19:06:06 <wumpus> I guess it would hide what results are returned from the DNS seed to the public internet
19:06:15 <emzy> wumpus: was for the last-minute topic list.
19:06:35 <jonatack> perhaps #20220 which has fixes for 0.21 and on which the #19543 work is building
19:06:37 <gribble> https://github.com/bitcoin/bitcoin/issues/20220 | wallet, rpc, test: explicit feerate follow-ups by jonatack · Pull Request #20220 · bitcoin/bitcoin · GitHub
19:06:38 <gribble> https://github.com/bitcoin/bitcoin/issues/19543 | Normalize fee units for RPC ("BTC/kB" and "sat/B) · Issue #19543 · bitcoin/bitcoin · GitHub
19:06:52 <wumpus> that's ok, you weren't clear about it being a proposed topic
19:07:09 <emzy> wumpus: it is mainly to add DNSSEC to the sipa seeds.
19:08:00 <wumpus> jonatack: ok added
19:08:05 <emzy> wumpus: not hiding insted signing.
19:08:49 <achow101> maybe #20205 should be added
19:08:51 <gribble> https://github.com/bitcoin/bitcoin/issues/20205 | wallet: Properly support a wallet id by achow101 · Pull Request #20205 · bitcoin/bitcoin · GitHub
19:09:03 <wumpus> right, DNSSEC authenticates it doesn't encrypt, my bad
19:09:35 <wumpus> achow101: is that a bugfix?
19:09:49 <achow101> wumpus: luke-jr argues it is.
19:10:23 <achow101> something about sqlite wallets need unique ids too to not cause problems in the future
19:10:24 <wumpus> you might want to mention this in the PR description, it is currently unclear about the why of the change, in any case, added
19:11:07 <wumpus> hebasto: we definitely need to add the milestones there then
19:11:12 <jonasschnelli> hebasto: I just created the milestones
19:11:23 <hebasto> jonasschnelli: thanks!
19:11:32 <wumpus> jonasschnelli: perfect, thanks!
19:12:58 <hebasto> jonasschnelli: possible candidates for 0.21 https://github.com/users/hebasto/projects/5
19:12:59 <wumpus> okay, moving to emzy's topic
19:13:13 <wumpus> #topic DNSSEC setup for dnsseed
19:13:27 <emzy> Ok. All new here for me to attend.. :)
19:14:08 <emzy> This is the issue https://github.com/bitcoin/bitcoin/issues/19714
19:14:35 <wumpus> #19714
19:14:36 <gribble> https://github.com/bitcoin/bitcoin/issues/19714 | ops: Enable DNSSEC on all Bitcoin DNS Seed domain names · Issue #19714 · bitcoin/bitcoin · GitHub
19:15:16 <emzy> It's about having DNSSEC on all dnsseeds. Sipas implementation has no dnssec so I made a setup to run it behind a Bind9
19:15:44 <emzy> The howto to set it up is here: https://github.com/sipa/bitcoin-seeder/pull/85
19:16:06 <wumpus> neat
19:16:13 <jonasschnelli> nice emzy. Thanks
19:16:18 <jonasschnelli> Will it only work with bind?
19:16:26 <jonasschnelli> Would there be the chance to get it working it djbdns?
19:16:29 <emzy> Someone needs to check it. I hope it is compleate.
19:16:51 <sipa> emzy: i'll read in more detail later, but how big a batch of IPs does it serve at any point in time?
19:16:54 <emzy> jonasschnelli: if djbdns allows dynamic updates. Yes.
19:17:10 <sipa> (as in, how many get extracted from the seeder and pushed into zonefiles)
19:17:23 <emzy> sipa: it clones the responce from your seeder.
19:17:42 <sipa> but a response only has 20 or so IP addresses
19:17:46 <emzy> maybe better say caches it.
19:17:57 <sipa> i hope it's not serving the same 20 for a whole day?
19:18:05 <emzy> no 1h
19:18:43 <sipa> if there was a way to load more of them into the zone file at once, would bind serve random subsets?
19:18:50 <emzy> could be changed. but the ttl on the sipa seeder is also 1h
19:19:03 <sipa> emzy: yes, but per request - every ISP gets different results
19:19:07 <emzy> ah I see.
19:19:49 <michaelfolkson> practicalswift wants to avoid a "bind monoculture". What are the concerns with that?
19:20:08 <emzy> I could also request every minute or so. But every time it needs to be signed. So it can't be every request different.
19:20:11 <luke-jr> wumpus: 20205 is a bugfix because otherwise sqlite wallets lack a unique id which bdb has provided until now
19:21:10 <emzy> michaelfolkson: there is still the dnsseed from bluematt
19:21:11 <sipa> emzy: your doc has a cronjob in cron.daily
19:21:15 <sipa> is that something else?
19:21:19 <wumpus> luke-jr: this unique id is there to detect loading the same wallet twice?
19:22:06 <sipa> emzy: i think bluematt's dnsseed also uses bind
19:22:08 <emzy> sipa: thats wrong. I will fix that.
19:22:24 <luke-jr> wumpus: to identify the same wallet even if renamed/moved/backedup/etc
19:22:33 <sipa> emzy: if you'd load say 100 IP addresses in the zone file instead, would everyone get those 100 IPs on every request?
19:22:40 <emzy> sipa: wrong in my documentation. My seed has it in crom.hourly
19:22:49 <emzy> sipa: yes
19:22:50 <wumpus> luke-jr: right
19:22:51 <luke-jr> wumpus: we *can* use it for a warning of loading it twice, but thats only one use case
19:23:13 <sipa> also 20025 doesn't actually prevent loading twice; it just adds an ID (iirc)
19:23:35 <wumpus> luke-jr: but I thought that was the one that was critical
19:23:46 <luke-jr> wumpus: my prune locks pr is an example of another use case
19:23:57 <sipa> wumpus: it was for BDB, due to environments being unable to load same db twice
19:24:04 <achow101> wumpus: loading duplicate sqlite wallets is not a problem. it's only an issue with bdb due to environment caching stuff
19:24:15 <wumpus> oh
19:24:21 <sipa> wumpus: in sqlite wallets there is no such constraint, but it may be useful at an application level
19:24:36 <michaelfolkson> Ah there have been past vulnerabilities in BIND
19:24:44 <sipa> there is also no use for that currently in the codebase, but adding one is harder if old wallets don't have unique ids
19:24:56 <sipa> i'm not convinced it's very urgent, but it does seem harmless to add one
19:25:07 <luke-jr> achow101: it can still be a problem due tio metadata divergence
19:25:10 <sipa> (correct me if i'm wrong on any of this)
19:26:10 <sipa> luke-jr: it may be undesirable at an application level (though ryanofsky seems to disagree with that), but that's different from BDB which has an actual problem with it
19:26:26 <wumpus> I think adding it cannot hurt in any case and it might come in useful
19:26:32 <sipa> yeah
19:27:37 <luke-jr> sipa: yes imo we should at least warn but thats another pr
19:28:09 <sipa> luke-jr: seems reasonable to me
19:28:26 <luke-jr> going from error to silently fine is not very good ux imo
19:29:07 <bitcoin-git> [13bitcoin] 15sushant-varanasi opened pull request #20224: doc: CI system link added, clarity increased (squashed into a single commit) (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/20224
19:29:10 <sipa> well, sqlite wallets are new; anything supported for them is whatever we declare is supported
19:29:31 <luke-jr> well "silently fine *except* you may end up with divergent metadatat" :p
19:29:33 <sipa> release notes can state in which ways they are different from bdb wallets, which may include support for loading multiple copies
19:29:40 <sipa> right
19:29:46 <sipa> i agree with at least warning
19:30:23 <luke-jr> sipa: ideally users dont care about underlying db
19:31:00 <luke-jr> (sorry laggy irc today)
19:31:42 <wumpus> any other topics?
19:31:59 <achow101> changing the version number scheme?
19:32:25 <wumpus> #topic Change version number scheme (achow101)
19:32:44 <achow101> it's about that time of year again to have users complain about our version numbers
19:32:48 <wumpus> I don't really feel strongly about it either way but a ok with it
19:32:51 <michaelfolkson> Good blog post from achow101 on moving to sqlite https://achow101.com/2020/10/0.21-wallets
19:33:01 <achow101> so #20223 drops the leading 0.
19:33:01 <luke-jr> lets keep semver at least…
19:33:02 <gribble> https://github.com/bitcoin/bitcoin/issues/20223 | Drop the leading 0 from the version number by achow101 · Pull Request #20223 · bitcoin/bitcoin · GitHub
19:33:18 <achow101> and makes our major version number actually the major version
19:33:29 <sipa> concept ack
19:33:47 <sipa> nobody really treats our 0 as a major version
19:33:48 <achow101> and maybe people will stop asking for 1.0
19:34:09 <luke-jr> I'd rather just bump 0 to 1
19:34:31 <achow101> this should also be a purely cosmetic change since CLIENT_VERSION doesn't change
19:34:57 <luke-jr> why not?
19:35:09 <achow101> 1000000 * 0 is still 0
19:35:10 <sipa> luke-jr: i'm afraid that'd be misinterpreted as an actual major step in development
19:35:23 <wumpus> it also wouldn't solve anything
19:35:29 <wumpus> besides 'there is a zero at the beginning'
19:35:45 <sipa> which i don't think this is; it's correcting for the fact that in practice our minor version number has turned into a conceptual major version
19:35:57 <luke-jr> sipa: 1.21?
19:36:08 <wumpus> yes, that is the issue
19:36:15 <sipa> luke-jr: and what would be next one be? 2.0 or 1.22?
19:36:21 <achow101> luke-jr: but that 1 is meaningless like 0 is now
19:36:30 <sipa> (the "next" one as in what would otherwise become 0.22)
19:36:30 <wumpus> having a static 1 at the beginning would be the same as a 0
19:36:33 <wumpus> right
19:36:35 <sipa> wumpus: indeed
19:37:08 <luke-jr> sipa: I don't agree… major versions rarely reach 20+…
19:37:36 <luke-jr> sipa: next could be 1.22 or 2.0 depending non what we think its significance is
19:37:44 <luke-jr> on*
19:37:45 <michaelfolkson> Could cause some limited confusion with references to previous 0. versions
19:37:50 <jonatack> I found the versioning mildly unusual at first, nevertheless am unsure it's worth fixing at this point
19:37:50 <wumpus> that's not how it works with our project
19:37:52 <achow101> luke-jr: and yet here we are with a version number that's ostensibly major at 21
19:38:03 <wumpus> we don't judge significance of versions and have a fixed release schedule
19:38:20 <luke-jr> achow101: but it really isnt
19:38:21 <emzy> I feel having a high number in front of the dot is more marketing related.
19:38:29 <wumpus> if we change the version scheme it should be to better reflect what we're actually doing
19:38:30 <michaelfolkson> Replace questions on when 1.0 with questions on what happened from 0.21 to 22.0
19:38:56 <achow101> luke-jr: we call it a major release..
19:38:56 <wumpus> not what other projects are doing
19:39:07 <luke-jr> bugfixes increment the 3rd int
19:39:18 <achow101> michaelfolkson: but that's way easier to explain
19:39:31 <sipa> luke-jr: if we'd actually also switch to releases that are based on magnitude of changes, but i don't think that's what we're doing
19:39:42 <sipa> our numbers are already just an indication of time
19:39:58 <luke-jr> magnitude would only determine 2.0 vs 1.22
19:40:33 <bitcoin-git> [13bitcoin] 15jonasschnelli pushed 2 commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/88271184e822...9453fbf5a022
19:40:34 <bitcoin-git> 13bitcoin/06master 146ed4bca 15Hennadii Stepanov: qt: Wrap tooltips in the intro window
19:40:35 <bitcoin-git> 13bitcoin/06master 149453fbf 15Jonas Schnelli: Merge #20: Wrap tooltips in the intro window
19:40:42 <luke-jr> it's not like versions are the release schedule
19:41:20 <wumpus> we do not classify versions by magnitude, the whole reason for proposing to remove the 0. would be to get rid of that illusion (for some people) once and for all
19:41:21 <achow101> luke-jr: there are software with high major versions. e.g. pip
19:41:48 <wumpus> firefo
19:41:50 <sipa> https://bitcoincore.org/en/lifecycle/
19:41:54 <achow101> chrome
19:41:54 <sipa> Bitcoin Core releases are versioned as follows: 0.MAJOR.MINOR, and release candidates are suffixed with rc1, rc2 etc.
19:41:58 <sipa> We aim to make a major release every 6-7 months.
19:42:02 <luke-jr> wumpus: well thats what versions are for
19:42:32 <wumpus> luke-jr: not in this project
19:42:53 <luke-jr> sigh
19:43:36 <luke-jr> then everything should be 1.x forever
19:43:47 <achow101> then that's just as meaningless
19:43:49 <sipa> that's no better than 0.x forever
19:44:08 <achow101> and then we'll get questions about for when 2.0
19:44:12 <wumpus> going in circles now
19:44:22 <luke-jr> either we should classify or not… -.-
19:44:55 <wumpus> we don't and we won't, the only proposal is to remove a useless 0. that pretty much everyone already leaves out anyway
19:45:36 <achow101> do we want it for this release or the next?
19:45:42 <luke-jr> it's not useless and people leaving it off should stop so long as it's  there
19:45:45 <wumpus> this is too late for 0.21 imo
19:45:58 <wumpus> I don't see any reason to push this last minute
19:46:04 <achow101> sure
19:46:06 <sipa> luke-jr: they won't stop given that it's meaningless
19:46:32 <sipa> our versioning scheme is literally 0.MAJOR.MINOR; the 0. serves no function
19:46:32 <fjahr> Major versions means breaking API changes. If we say breaking API changes are breaking consensus changes in Bitcoin wouldn't it make sense to keep 0.x until we have to do a hardfork? I know that's not how people think of the versioning but I think that would make sense.
19:47:27 <luke-jr> fjahr: Core and Bitcoin are different things
19:47:35 <wumpus> no, the versioning ahs nothing to do with forks and hardforks
19:47:44 <wumpus> luke-jr: exactly
19:47:45 <sipa> firefox's versioning scheme is not based on which HTML version they support
19:47:47 <fjahr> ok
19:48:05 <michaelfolkson> I thought it was an interesting idea fjahr
19:48:09 <achow101> fjahr: then we'd be on version 5 or something like that with the changes satoshi made early on
19:48:19 <luke-jr> sipa: its really 0.minor.bugfixi
19:48:26 <sipa> luke-jr: it's on our site
19:48:40 <luke-jr> then the site is wrong
19:48:58 <achow101> luke-jr: we refer to every 0.x release as a major release
19:49:27 <luke-jr> so 21.0.bugfix,l 22.0.bugfix?
19:49:59 <luke-jr> looks silly imo but at least it can make some sense2…
19:50:08 <michaelfolkson> Ditching the zero assumes we will *never* have a use for it. Any reason for redundancy here however fanciful?
19:50:23 <emzy> luke-jr: there was a 0.19.0.1
19:50:35 <luke-jr> emzy: I'm aware
19:50:43 <sipa> michaelfolkson: that's exactly the problem
19:50:58 <sipa> michaelfolkson: nobody has an answer to the question "what would constitute something worthy of a 1.x release"
19:51:01 <luke-jr> ?
19:51:23 <luke-jr> we should really be past 1.0
19:51:59 <sipa> yes, we do a major release every 6-7 months!
19:52:45 <michaelfolkson> If the redundancy is entirely unnecessary for all possible future scenarios I think get rid of it. Just so this discussion doesn't keep coming up (assuming there are no downsides other than a little user confusion)
19:52:52 <luke-jr> if its not major enough to get 1.0, it's not major ;)
19:53:06 <sipa> luke-jr: circular reasoning gets us nowhere
19:53:16 <wumpus> michaelfolkson: I agree
19:53:26 <luke-jr> sipa: circular?
19:53:46 <luke-jr> 1.0 is no more importwant that 22.0
19:53:53 <wumpus> michaelfolkson: that would be the only reason to do it, really, in the end it's just a number and doesn't matter that much, there's no strong reason to change anything
19:54:10 <achow101> luke-jr: 1.0 has a meaning to dumb humans
19:54:16 <luke-jr> if we can't do 1.0 because its not important enough, it shoouldnt be 22.0 either
19:54:37 <achow101> 1.0 is a magic number even if it shouldn't be
19:54:49 <sipa> i think none of this matters
19:54:59 <luke-jr> it won't be 2 years later
19:55:11 <sipa> our release process is around time-based releases, and our version numbers _are_ time-based too
19:56:15 <sipa> however much you'd like that to be different, the number X in 0.X.Y doesn't mean anything else but "the series of stable releases forked off at a point in time depending on X"
19:56:16 <luke-jr> then do a calendar version like Ubuntu? :/
19:56:32 <luke-jr> I prefer semver, but at least we should use some stabdard…
19:56:53 <wumpus> 5 minutes to go
19:56:56 <sipa> it doesn't convey magnitude of changes, and without substantial changes to our release process, they won't be
19:56:58 <achow101> luke-jr: i'd honestly prefer a calendar version, but dropping 0 is the simplest and least confusing change to make
19:57:03 <sipa> luke-jr: firefox? chrome?
19:57:27 <emzy> achow101: +1
19:57:39 <luke-jr> actually this is our one chance to switch to calendar cleanly
19:57:53 <achow101> luke-jr: ikr. I proposed that for 0.20
19:58:15 <luke-jr> sipa: nt for bugfixes
20:01:06 <wumpus> #endmeeting