< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/b46f37ba5ec4...dda18e7310a2
< bitcoin-git> bitcoin/master fa5f466 MarcoFalke: test: Fix rpc_net intermittent issue
< bitcoin-git> bitcoin/master dda18e7 fanquake: Merge #20214: test: Fix rpc_net intermittent issue
< bitcoin-git> [bitcoin] fanquake merged pull request #20214: test: Fix rpc_net intermittent issue (master...2010-testFixNet) https://github.com/bitcoin/bitcoin/pull/20214
< bitcoin-git> [bitcoin] theStack opened pull request #20216: wallet: fix buffer over-read in SQLite file magic check (master...20201022-wallet-fix-sqlite-magic-buffer-overread) https://github.com/bitcoin/bitcoin/pull/20216
< kallewoof> Signet miner now running master. Haven't tested it, but I think this means taproot is activated on signet now
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/dda18e7310a2...1cb4e339f978
< bitcoin-git> bitcoin/master 5aadd4b Prayank: Convert amounts from float to decimal
< bitcoin-git> bitcoin/master 1cb4e33 MarcoFalke: Merge #20039: test: Convert amounts from float to decimal
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20039: test: Convert amounts from float to decimal (master...floatdecimal) https://github.com/bitcoin/bitcoin/pull/20039
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/1cb4e339f978...7012db2a6bcd
< bitcoin-git> bitcoin/master fa3af2c MarcoFalke: test: Fix intermittent issue in p2p_feefilter
< bitcoin-git> bitcoin/master fa5a91a MarcoFalke: test: Fix typo (one tx is enough) in p2p_feefilter
< bitcoin-git> bitcoin/master 7012db2 MarcoFalke: Merge #20176: test: Fix intermittent issue in p2p_feefilter
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20176: test: Fix intermittent issue in p2p_feefilter (master...2010-testFixIntIssue) https://github.com/bitcoin/bitcoin/pull/20176
< gwillen> /win goto sully
< gwillen> whoops, heh
< bitcoin-git> [bitcoin] jnewbery opened pull request #20217: net: Remove g_relay_txes (master...2020-10-remove-grelaytxes) https://github.com/bitcoin/bitcoin/pull/20217
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/7012db2a6bcd...88271184e822
< bitcoin-git> bitcoin/master fa299ac MarcoFalke: test: Speed up wallet_resendwallettransactions test with mockscheduler RPC
< bitcoin-git> bitcoin/master 8827118 MarcoFalke: Merge #20112: test: Speed up wallet_resendwallettransactions with mocksche...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20112: test: Speed up wallet_resendwallettransactions with mockscheduler RPC (master...2010-testFasterMock) https://github.com/bitcoin/bitcoin/pull/20112
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #20218: test: Suppress MaybeCompactWalletDB data race (master...2010-testSuppWalletRace) https://github.com/bitcoin/bitcoin/pull/20218
< bitcoin-git> [bitcoin] luke-jr closed pull request #20204: Wallet: Generate UUID for SQLite wallets (master...sqlite_wallet_uuid) https://github.com/bitcoin/bitcoin/pull/20204
< bitcoin-git> [bitcoin] jonatack opened pull request #20220: rpc, test, doc: explicit feerate follow-ups (master...explicit-feerate-follow-ups) https://github.com/bitcoin/bitcoin/pull/20220
< bitcoin-git> [bitcoin] hebasto opened pull request #20221: net: compat.h related cleanup (master...201022-compat) https://github.com/bitcoin/bitcoin/pull/20221
< bitcoin-git> [bitcoin] ellemouton opened pull request #20222: refactor: CTxMempool constructor clean up (master...ctxmempool_refactor) https://github.com/bitcoin/bitcoin/pull/20222
< bitcoin-git> [bitcoin] achow101 opened pull request #20223: Drop the leading 0 from the version number (master...drop-leading-0) https://github.com/bitcoin/bitcoin/pull/20223
< dongcarl> Anyone know of a way to get the DEBUG_LOG out from Travis? Or is it unobtainable?
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Oct 22 18:59:23 2020 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< kanzure> hi
< jnewbery> hello
< emzy> hi
< hebasto> hi
< 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
< wumpus> amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
< sipa> hi
< jonatack> hi
< jonasschnelli> hi
< wumpus> no topics have been proposed yet in http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt
< wumpus> any last-minute ones?
< sipa> yay for all the work that made it into 0.21
< jnewbery> +1
< wumpus> yes!!!
< achow101> hi
< michaelfolkson> 21.0 not 0.21
< achow101> michaelfolkson: not yet
< michaelfolkson> haha
< wumpus> #topic 0.21 milestone
< emzy> I have a DNSSEC setup for dnsseed. Not directly bitcoin core related.
< wumpus> I think this is the high priority for review now
< fjahr> hi
< hebasto> is any way to label with 0.21 milestone prs from the https://github.com/bitcoin-core/gui ?
< wumpus> the planned date for the branch split-off and rc1 is 2020-11-01
< wumpus> hebasto: there are no milestones there?
< wumpus> we probably need to create them then
< hebasto> wumpus: no milestones at all
< wumpus> emzy: would DNSSEC help there?
< wumpus> I guess it would hide what results are returned from the DNS seed to the public internet
< emzy> wumpus: was for the last-minute topic list.
< jonatack> perhaps #20220 which has fixes for 0.21 and on which the #19543 work is building
< gribble> https://github.com/bitcoin/bitcoin/issues/20220 | wallet, rpc, test: explicit feerate follow-ups by jonatack · Pull Request #20220 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/19543 | Normalize fee units for RPC ("BTC/kB" and "sat/B) · Issue #19543 · bitcoin/bitcoin · GitHub
< wumpus> that's ok, you weren't clear about it being a proposed topic
< emzy> wumpus: it is mainly to add DNSSEC to the sipa seeds.
< wumpus> jonatack: ok added
< emzy> wumpus: not hiding insted signing.
< achow101> maybe #20205 should be added
< gribble> https://github.com/bitcoin/bitcoin/issues/20205 | wallet: Properly support a wallet id by achow101 · Pull Request #20205 · bitcoin/bitcoin · GitHub
< wumpus> right, DNSSEC authenticates it doesn't encrypt, my bad
< wumpus> achow101: is that a bugfix?
< achow101> wumpus: luke-jr argues it is.
< achow101> something about sqlite wallets need unique ids too to not cause problems in the future
< 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
< wumpus> hebasto: we definitely need to add the milestones there then
< jonasschnelli> hebasto: I just created the milestones
< hebasto> jonasschnelli: thanks!
< wumpus> jonasschnelli: perfect, thanks!
< hebasto> jonasschnelli: possible candidates for 0.21 https://github.com/users/hebasto/projects/5
< wumpus> okay, moving to emzy's topic
< wumpus> #topic DNSSEC setup for dnsseed
< emzy> Ok. All new here for me to attend.. :)
< wumpus> #19714
< gribble> https://github.com/bitcoin/bitcoin/issues/19714 | ops: Enable DNSSEC on all Bitcoin DNS Seed domain names · Issue #19714 · bitcoin/bitcoin · GitHub
< 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
< emzy> The howto to set it up is here: https://github.com/sipa/bitcoin-seeder/pull/85
< wumpus> neat
< jonasschnelli> nice emzy. Thanks
< jonasschnelli> Will it only work with bind?
< 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
< michaelfolkson> Good blog post from achow101 on moving to sqlite https://achow101.com/2020/10/0.21-wallets
< achow101> so #20223 drops the leading 0.
< luke-jr> lets keep semver at least…
< gribble> https://github.com/bitcoin/bitcoin/issues/20223 | Drop the leading 0 from the version number by achow101 · Pull Request #20223 · bitcoin/bitcoin · GitHub
< achow101> and makes our major version number actually the major version
< sipa> concept ack
< sipa> nobody really treats our 0 as a major version
< achow101> and maybe people will stop asking for 1.0
< luke-jr> I'd rather just bump 0 to 1
< achow101> this should also be a purely cosmetic change since CLIENT_VERSION doesn't change
< luke-jr> why not?
< achow101> 1000000 * 0 is still 0
< sipa> luke-jr: i'm afraid that'd be misinterpreted as an actual major step in development
< wumpus> it also wouldn't solve anything
< wumpus> besides 'there is a zero at the beginning'
< 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
< luke-jr> sipa: 1.21?
< wumpus> yes, that is the issue
< sipa> luke-jr: and what would be next one be? 2.0 or 1.22?
< achow101> luke-jr: but that 1 is meaningless like 0 is now
< sipa> (the "next" one as in what would otherwise become 0.22)
< wumpus> having a static 1 at the beginning would be the same as a 0
< wumpus> right
< sipa> wumpus: indeed
< luke-jr> sipa: I don't agree… major versions rarely reach 20+…
< luke-jr> sipa: next could be 1.22 or 2.0 depending non what we think its significance is
< luke-jr> on*
< michaelfolkson> Could cause some limited confusion with references to previous 0. versions
< jonatack> I found the versioning mildly unusual at first, nevertheless am unsure it's worth fixing at this point
< wumpus> that's not how it works with our project
< achow101> luke-jr: and yet here we are with a version number that's ostensibly major at 21
< wumpus> we don't judge significance of versions and have a fixed release schedule
< luke-jr> achow101: but it really isnt
< emzy> I feel having a high number in front of the dot is more marketing related.
< wumpus> if we change the version scheme it should be to better reflect what we're actually doing
< michaelfolkson> Replace questions on when 1.0 with questions on what happened from 0.21 to 22.0
< achow101> luke-jr: we call it a major release..
< wumpus> not what other projects are doing
< luke-jr> bugfixes increment the 3rd int
< achow101> michaelfolkson: but that's way easier to explain
< 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
< sipa> our numbers are already just an indication of time
< luke-jr> magnitude would only determine 2.0 vs 1.22
< bitcoin-git> [bitcoin] jonasschnelli pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/88271184e822...9453fbf5a022
< 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
< wumpus> firefo
< achow101> chrome
< 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
< 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)
< jonatack> Wallet meeting tomorrow?
< jonasschnelli> Oh no. I think I messed up my first GUI repository merge. Made it the "wrong way" (so messed up bitcoin/bitcoin).
< jonatack> #walletmeetingtopic standardize feerate unit on sat/vB (or sat/kvB... or sat/sipa...)
< jonasschnelli> Unsure how to proceed now...
< jonasschnelli> I probably messed up the SHA512 tree.
< achow101> jonatack: yes
< michaelfolkson> Where can you see the topics for these meetings?
< jonatack> achow101: 👌 c u there
< jonasschnelli> wumpus: do you have an idea how to correct my latest merge: https://github.com/bitcoin/bitcoin/commits/master?
< jonasschnelli> I guess a force push is a no go ... :|
< michaelfolkson> Thanks achow101
< 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: I think our versioning pretty closely resembles firefox's actually
< achow101> I also don't understand chrome's
< achow101> the inflated versioning is only because they make releases every 2 months
< luke-jr> achow101: IIRC they did a huge skip a few years ago
< 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"
< luke-jr> right
< bitcoin-git> [bitcoin] fanquake closed pull request #20215: doc: CI system link added, clarity increased (master...patch-1) https://github.com/bitcoin/bitcoin/pull/20215