< jonasschnelli>
Would there be the chance to get it working it djbdns?
< emzy>
Someone needs to check it. I hope it is compleate.
< sipa>
emzy: i'll read in more detail later, but how big a batch of IPs does it serve at any point in time?
< emzy>
jonasschnelli: if djbdns allows dynamic updates. Yes.
< sipa>
(as in, how many get extracted from the seeder and pushed into zonefiles)
< emzy>
sipa: it clones the responce from your seeder.
< sipa>
but a response only has 20 or so IP addresses
< emzy>
maybe better say caches it.
< sipa>
i hope it's not serving the same 20 for a whole day?
< emzy>
no 1h
< sipa>
if there was a way to load more of them into the zone file at once, would bind serve random subsets?
< emzy>
could be changed. but the ttl on the sipa seeder is also 1h
< sipa>
emzy: yes, but per request - every ISP gets different results
< emzy>
ah I see.
< michaelfolkson>
practicalswift wants to avoid a "bind monoculture". What are the concerns with that?
< 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.
< luke-jr>
wumpus: 20205 is a bugfix because otherwise sqlite wallets lack a unique id which bdb has provided until now
< emzy>
michaelfolkson: there is still the dnsseed from bluematt
< sipa>
emzy: your doc has a cronjob in cron.daily
< sipa>
is that something else?
< wumpus>
luke-jr: this unique id is there to detect loading the same wallet twice?
< sipa>
emzy: i think bluematt's dnsseed also uses bind
< emzy>
sipa: thats wrong. I will fix that.
< luke-jr>
wumpus: to identify the same wallet even if renamed/moved/backedup/etc
< sipa>
emzy: if you'd load say 100 IP addresses in the zone file instead, would everyone get those 100 IPs on every request?
< emzy>
sipa: wrong in my documentation. My seed has it in crom.hourly
< emzy>
sipa: yes
< wumpus>
luke-jr: right
< luke-jr>
wumpus: we *can* use it for a warning of loading it twice, but thats only one use case
< sipa>
also 20025 doesn't actually prevent loading twice; it just adds an ID (iirc)
< wumpus>
luke-jr: but I thought that was the one that was critical
< luke-jr>
wumpus: my prune locks pr is an example of another use case
< sipa>
wumpus: it was for BDB, due to environments being unable to load same db twice
< achow101>
wumpus: loading duplicate sqlite wallets is not a problem. it's only an issue with bdb due to environment caching stuff
< wumpus>
oh
< sipa>
wumpus: in sqlite wallets there is no such constraint, but it may be useful at an application level
< michaelfolkson>
Ah there have been past vulnerabilities in BIND
< 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
< sipa>
i'm not convinced it's very urgent, but it does seem harmless to add one
< luke-jr>
achow101: it can still be a problem due tio metadata divergence
< sipa>
(correct me if i'm wrong on any of this)
< 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
< wumpus>
I think adding it cannot hurt in any case and it might come in useful
< sipa>
yeah
< luke-jr>
sipa: yes imo we should at least warn but thats another pr
< sipa>
luke-jr: seems reasonable to me
< luke-jr>
going from error to silently fine is not very good ux imo
< bitcoin-git>
[bitcoin] sushant-varanasi opened pull request #20224: doc: CI system link added, clarity increased (squashed into a single commit) (master...master) https://github.com/bitcoin/bitcoin/pull/20224
< sipa>
well, sqlite wallets are new; anything supported for them is whatever we declare is supported
< luke-jr>
well "silently fine *except* you may end up with divergent metadatat" :p
< sipa>
release notes can state in which ways they are different from bdb wallets, which may include support for loading multiple copies
< sipa>
right
< sipa>
i agree with at least warning
< luke-jr>
sipa: ideally users dont care about underlying db
< luke-jr>
(sorry laggy irc today)
< wumpus>
any other topics?
< achow101>
changing the version number scheme?
< wumpus>
#topic Change version number scheme (achow101)
< achow101>
it's about that time of year again to have users complain about our version numbers
< wumpus>
I don't really feel strongly about it either way but a ok with it
< bitcoin-git>
bitcoin/master 6ed4bca Hennadii Stepanov: qt: Wrap tooltips in the intro window
< bitcoin-git>
bitcoin/master 9453fbf Jonas Schnelli: Merge #20: Wrap tooltips in the intro window
< luke-jr>
it's not like versions are the release schedule
< 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
< achow101>
luke-jr: there are software with high major versions. e.g. pip
< sipa>
Bitcoin Core releases are versioned as follows: 0.MAJOR.MINOR, and release candidates are suffixed with rc1, rc2 etc.
< sipa>
We aim to make a major release every 6-7 months.
< luke-jr>
wumpus: well thats what versions are for
< wumpus>
luke-jr: not in this project
< luke-jr>
sigh
< luke-jr>
then everything should be 1.x forever
< achow101>
then that's just as meaningless
< sipa>
that's no better than 0.x forever
< achow101>
and then we'll get questions about for when 2.0
< wumpus>
going in circles now
< luke-jr>
either we should classify or not… -.-
< 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
< achow101>
do we want it for this release or the next?
< luke-jr>
it's not useless and people leaving it off should stop so long as it's there
< wumpus>
this is too late for 0.21 imo
< wumpus>
I don't see any reason to push this last minute
< achow101>
sure
< sipa>
luke-jr: they won't stop given that it's meaningless
< sipa>
our versioning scheme is literally 0.MAJOR.MINOR; the 0. serves no function
< 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.
< luke-jr>
fjahr: Core and Bitcoin are different things
< wumpus>
no, the versioning ahs nothing to do with forks and hardforks
< wumpus>
luke-jr: exactly
< sipa>
firefox's versioning scheme is not based on which HTML version they support
< fjahr>
ok
< michaelfolkson>
I thought it was an interesting idea fjahr
< achow101>
fjahr: then we'd be on version 5 or something like that with the changes satoshi made early on
< luke-jr>
sipa: its really 0.minor.bugfixi
< sipa>
luke-jr: it's on our site
< luke-jr>
then the site is wrong
< achow101>
luke-jr: we refer to every 0.x release as a major release
< luke-jr>
so 21.0.bugfix,l 22.0.bugfix?
< luke-jr>
looks silly imo but at least it can make some sense2…
< michaelfolkson>
Ditching the zero assumes we will *never* have a use for it. Any reason for redundancy here however fanciful?
< emzy>
luke-jr: there was a 0.19.0.1
< luke-jr>
emzy: I'm aware
< sipa>
michaelfolkson: that's exactly the problem
< sipa>
michaelfolkson: nobody has an answer to the question "what would constitute something worthy of a 1.x release"
< luke-jr>
?
< luke-jr>
we should really be past 1.0
< sipa>
yes, we do a major release every 6-7 months!
< 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)
< luke-jr>
if its not major enough to get 1.0, it's not major ;)
< sipa>
luke-jr: circular reasoning gets us nowhere
< wumpus>
michaelfolkson: I agree
< luke-jr>
sipa: circular?
< luke-jr>
1.0 is no more importwant that 22.0
< 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
< achow101>
luke-jr: 1.0 has a meaning to dumb humans
< luke-jr>
if we can't do 1.0 because its not important enough, it shoouldnt be 22.0 either
< achow101>
1.0 is a magic number even if it shouldn't be
< sipa>
i think none of this matters
< luke-jr>
it won't be 2 years later
< sipa>
our release process is around time-based releases, and our version numbers _are_ time-based too
< 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"
< luke-jr>
then do a calendar version like Ubuntu? :/
< luke-jr>
I prefer semver, but at least we should use some stabdard…
< wumpus>
5 minutes to go
< sipa>
it doesn't convey magnitude of changes, and without substantial changes to our release process, they won't be
< achow101>
luke-jr: i'd honestly prefer a calendar version, but dropping 0 is the simplest and least confusing change to make
< sipa>
luke-jr: firefox? chrome?
< emzy>
achow101: +1
< luke-jr>
actually this is our one chance to switch to calendar cleanly
< achow101>
luke-jr: ikr. I proposed that for 0.20
< luke-jr>
sipa: nt for bugfixes
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu Oct 22 20:01:06 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< achow101>
jonasschnelli: it doesn't seem that messed up except the commit message is wrong
< wumpus>
jonasschnelli: let me see
< jonasschnelli>
achow101: Yes. It's just the commit message
< jonasschnelli>
(which includes the Tree-SHA512)
< wumpus>
so the only thing wrong is the PR # in the commit message?
< wumpus>
the Tree-SHA256, signature looks to be ok
< wumpus>
and you did intend to merge this?
< wumpus>
if so, I don't think this warrants a force push no
< jonasschnelli>
wumpus: yes. It was an intentional merge. I just used the github-merge tool the wrong way
< jonasschnelli>
wumpus: Oh. Right. The SHA512 should be right as it is the same in the GUI repository
< jonasschnelli>
It is then just the title... which I think is bad but probably not worth a force push
< luke-jr>
sipa: Chromium's version is 4 ints, with bugfixes apparently the 4th; Firefox's are 3 ints, with bugfixes apparently the 3rd; both with marketting-specific inflated major versions
< yanmaani>
Does the Bitcoin Core RPC use HTTP 2.0? Is there any way to query it asynchronously?
< yanmaani>
(other than making a new thread for each connection or using a thread pool)
< luke-jr>
if we're going to switch to calendar, we should just rename 0.21 to 20.11 for a clean continuity
< luke-jr>
yanmaani: that is entirely up to your RPC interface..
< achow101>
luke-jr: all I remember is that firefox just wasn't relevant for a while
< luke-jr>
they had a 33.1, but otherwise it looks like almost all their minor versions are 0
< achow101>
68 has a bunch of minor releases
< achow101>
seems like they primarily use minor versions for the esr releases
< luke-jr>
I guess that makes sense
< luke-jr>
I assume not for just fixes
< luke-jr>
major.0.bugfix leaves the door open if anyone wants to do some kind of backports-only interim releases
< achow101>
.. all of our minor releases are backports only
< luke-jr>
bugfixes only
< luke-jr>
which is the 3rd int
< achow101>
firefox esr releases are only bug and security fixes only
< luke-jr>
well, that's not a standard use for int 2
< yanmaani>
luke-jr: You could release 0.21 now, keep it through 2021, and then have 0.22 be the 2022 release as well. You don't have to do it retroactively
< yanmaani>
Wht do you mean 'my RPC interface'? Caller is whatever, but does the server support HTTP 2.0?
< meshcollider>
yanmaani: we release ~twice per year not just once
< yanmaani>
meshcollider: well just stop doing that then :)
< yanmaani>
have minor versions be 'month of release' after say June 2021
< luke-jr>
yanmaani: HTTP 1.0 can be done async just fine
< luke-jr>
sync vs async is entirely your JSON-RPC interface/library
< yanmaani>
luke-jr: Yes but I'll have to start more connections
< luke-jr>
so?
< yanmaani>
If I want to make 10 requests that take 100ms of wall-clock time each, then I'll need to open 1 connection with HTTP 2.0 and 10 with HTTP 1.0
< yanmaani>
It's more implementation work, and probably slightly more resource intensive
< luke-jr>
it's less because you don't need the logic to determine when you need more connections :P
< luke-jr>
less impl work*
< yanmaani>
And because I need to keep the state of which sockets are blocked.
< luke-jr>
or just open a connection per request *shrug*
< yanmaani>
yep. How much resources does it take to open say 100 threads?
< luke-jr>
well, you can always do it async ;)
< yanmaani>
send to threads[rand() % 100], hope for the best
< yanmaani>
gotta keep them open too
< yanmaani>
like does it just need a few MB of RAM, or something more?
< luke-jr>
anyway, Core uses libevent for the HTTP server
< luke-jr>
yanmaani: there is nothing to stop a single thread from managing many connections each with one request
< yanmaani>
with evhttp?
< luke-jr>
yes
< yanmaani>
I mean thread in bitcoind
< luke-jr>
ah
< yanmaani>
there's a setting "RPC threads", default was 4 on my machine
< luke-jr>
well, if you have N requests you want to run simultaneously, you're going to have N threads Core side to do it
< yanmaani>
Does it gain you anything to have >N connections then?
< luke-jr>
probably not, just a matter of what's easier for you to do
< yanmaani>
and what's the performance cost in spinning up a gazillion threads?
< luke-jr>
if you don't mind them running in sequence, you might consider batching
< yanmaani>
yeah, I might just do that, have a separate piece of code exposing an async API and then just have a queue + thread pool monstrosity hidden behind there
< yanmaani>
Would a PR to add an option to make Bitcoin Core crash/quit if an incorrect RPC password attempt is made be welcomed?
< luke-jr>
yanmaani: I think I would ACK it as an option
< yanmaani>
cool
< luke-jr>
yanmaani: keep in mind it could become a DoS risk
< yanmaani>
luke-jr: That's the point, to degrade a security risk to a DoS risk
< yanmaani>
"oops I exposed my RPC port, my money is gone" -> "oops I exposed my RPC port, I'll have to restart my node"