--- Log opened Thu Apr 18 00:00:03 2024
--- Day changed Thu Apr 18 2024
00:00 < Sjors[m]> What is that supposed to do? Is it looking for a peer at the DNS seeder domain?
00:00 < Sjors[m]> Oh I guess this effectively connects to the first result?
00:04 < Sjors[m]> Or in any case, it will connect to whatever IPv4 / IPv6 IP the operating system picks.
01:32 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has joined #bitcoin-core-dev
01:48 < bitcoin-git> [bitcoin] hebasto pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/dbd2000b3490...aaab5fb3c51c
01:48 < bitcoin-git> bitcoin/master 6d8eecd MarcoFalke: refactor: Avoid implicit-integer-sign-change in createTransaction
01:48 < bitcoin-git> bitcoin/master 321f105 MarcoFalke: refactor: Avoid implicit-signed-integer-truncation-or-sign-change in Freed...
01:48 < bitcoin-git> bitcoin/master 0541642 MarcoFalke: refactor: Avoid implicit-integer-sign-change in processNewTransaction
01:49 < bitcoin-git> [gui] hebasto merged pull request #806: refactor: Misc int sign change fixes (master...2403-int-fixes-) https://github.com/bitcoin-core/gui/pull/806
01:52 -!- vasild [~vd@user/vasild] has joined #bitcoin-core-dev
02:05 < bitcoin-git> [bitcoin] hebasto pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/aaab5fb3c51c...c05c214f2e9c
02:05 < bitcoin-git> bitcoin/master c6d1b8d Sebastian Falbesoner: gui: change example address from legacy (P2PKH) to bech32m (P2TR)
02:05 < bitcoin-git> bitcoin/master c05c214 merge-script: Merge bitcoin-core/gui#808: Change example address from legacy (P2PKH) to ...
02:05 < bitcoin-git> [gui] hebasto merged pull request #808: Change example address from legacy (P2PKH) to bech32m (P2TR) (master...example-addr_update_to_p2tr) https://github.com/bitcoin-core/gui/pull/808
02:09 -!- vasild [~vd@user/vasild] has quit [Remote host closed the connection]
02:09 -!- vasild [~vd@user/vasild] has joined #bitcoin-core-dev
02:13 < laanwj> <Sjors[m]> "Oh I guess this effectively..." <- yes, that's what it effectively does
02:18 < laanwj> socks5 (not even the TOR extensions) have no way to perform a DNS lookup returning multiple results, so "just connect to one using the remote OS' guess" is all it can do, or use built-in seeds
02:18 < laanwj> using the local DNS would be a clear DNS leak
02:25 < laanwj> i must admit that it confused me at first too, like "why is it connected to the DNS seed, would the DNS seed run a node"--so maybe it's not commented well enough
02:30 < lightlike> I think the comment was added because multiple people (myself included) thought at some point that we'd connect to a node run by the DNS seed operator...
02:30 -!- Zenton [~user@user/zenton] has quit [Read error: Connection reset by peer]
02:31 -!- Zenton [~user@user/zenton] has joined #bitcoin-core-dev
02:32 < laanwj> oh!
02:39 < bitcoin-git> [bitcoincore.org] fanquake pushed 2 commits to master: https://github.com/bitcoin-core/bitcoincore.org/compare/847d30cf150d...e0e634fb61b7
02:39 < bitcoin-git> bitcoincore.org/master 40722b7 Ava Chow: ci: Fix verify commits ci
02:39 < bitcoin-git> bitcoincore.org/master e0e634f merge-script: Merge bitcoin-core/bitcoincore.org#1019: ci: Fix verify commits ci
02:39 < bitcoin-git> [bitcoincore.org] fanquake merged pull request #1019: ci: Fix verify commits ci (master...fix-verify-commits-ci) https://github.com/bitcoin-core/bitcoincore.org/pull/1019
02:42 < bitcoin-git> [bitcoincore.org] fanquake pushed 2 commits to master: https://github.com/bitcoin-core/bitcoincore.org/compare/e0e634fb61b7...e7c59501bca6
02:42 < bitcoin-git> bitcoincore.org/master 523fef7 azuchi: Add japanese translation for 25.2
02:42 < bitcoin-git> bitcoincore.org/master e7c5950 merge-script: Merge bitcoin-core/bitcoincore.org#1017: Add japanese translation for 25.2
02:42 < bitcoin-git> [bitcoincore.org] fanquake merged pull request #1017: Add japanese translation for 25.2 (master...ja-translate-25.2) https://github.com/bitcoin-core/bitcoincore.org/pull/1017
02:45 < bitcoin-git> [bitcoincore.org] fanquake pushed 2 commits to master: https://github.com/bitcoin-core/bitcoincore.org/compare/e7c59501bca6...6825a895fd94
02:45 < bitcoin-git> bitcoincore.org/master bc87e05 azuchi: Add japanese translation for 27.0
02:45 < bitcoin-git> bitcoincore.org/master 6825a89 merge-script: Merge bitcoin-core/bitcoincore.org#1018: Add japanese translation for 27.0
02:45 < bitcoin-git> [bitcoincore.org] fanquake merged pull request #1018: Add japanese translation for 27.0 (master...ja-translate-27.0) https://github.com/bitcoin-core/bitcoincore.org/pull/1018
03:11 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has left #bitcoin-core-dev [Closing Window]
03:18 < laanwj> i've updated the google calendar linked on the bitcoincore.org site:  removed the wallet meeting, added links, changed PR review meeting to show first wednesday of each month only
03:44 < laanwj> if there's anything else there or on https://bitcoincore.org/en/meetings/ that isn't right let me know, i haven't paid attention for some time
03:50 < bitcoin-git> [bitcoin] willcl-ark opened pull request #29903: Move bitcoin.conf to /share/examples dir in releases (master...conf-in-dst-share) https://github.com/bitcoin/bitcoin/pull/29903
03:53 -!- the_mariner [~Thunderbi@179.180.142.244] has joined #bitcoin-core-dev
03:58 -!- the_mariner [~Thunderbi@179.180.142.244] has quit [Ping timeout: 256 seconds]
04:12 < fanquake> Does / has anyone here used our Snap package, and are they able to comment on / followup with any of the issues listed here: https://github.com/bitcoin-core/packaging/issues ?
04:16 < sipa> Sjors[m]: almost; the tor exit node will generally forward the connection to a *random* DNS seed result; not the first one
04:16 < fanquake> re flatpack. We could get https://flathub.org/apps/org.bitcoincore.bitcoin-qt marked as "verified" after merging https://github.com/bitcoin-core/bitcoincore.org/pull/975.
04:16 < fanquake> It would probably also be good for us to provide the changelog there, and try and fix (where possible) the "potentially unsafe" markers
04:16 < fanquake> Don't think we can do anything about Qts windowing system, but we should be able to fix the tor auth cookie issue
04:17 < fanquake> That could be followed up on in https://github.com/flathub/org.bitcoincore.bitcoin-qt
04:17 < Sjors[m]> sipa: Is https://man7.org/linux/man-pages/man3/getaddrinfo.3.html what's doing the actual DNS query?
04:18 < laanwj> fanquake: do you know why it shows it as "legacy window system"
04:18 < fanquake> I'd assume something to do with it's using X, and not proper Wayland?
04:18 < laanwj> lack of wayland support i guess?
04:19 < laanwj> right, that makes sense
04:19 < sipa> Sjors[m]: i haven't looked at tor's source code, but that seems likely
04:20 < Sjors[m]> Oh not tor, our own code.
04:20 < hebasto> speaking of Wayland support -- https://github.com/bitcoin/bitcoin/pull/22708
04:20 < Sjors[m]> For when there is no proxy, it calls that
04:20 < laanwj> i'm happy to work on wayland support but it makes only sense to fix that after cmake and (i guess) qt6
04:20 < fanquake> One of the problems with 22708 was that it added wayland and didn't remove X, given us twice us much stuff to maintain
04:20 < sipa> Sjors[m]: in that case yes, but that is not used (or should not be used) in case we have a tor proxy
04:21 < laanwj> using wayland is pretty easy to do in a static way, as long as you can load the GL library dynamially, which you should anyhow
04:21 < laanwj> * library dynamially at run time, which
04:23 -!- SpellChecker [~SpellChec@user/SpellChecker] has quit [Remote host closed the connection]
04:24 < fanquake> laanwj: I think it'd be good to have some sort of plan. There's a lot in flight here, CMake, Qt 6, the new GUI etc. It'd be good to know from someone working on that what is actually needed, what the timelines for each are etc, so we can avoid making a bunch of changes, just to potentially throw them all away soon after. i.e doing wayland with autotools & qt 5 vs with cmake and qt 6, and when we are dropping all the ancient x lib stuff
04:24 -!- SpellChecker [~SpellChec@user/SpellChecker] has joined #bitcoin-core-dev
04:25 < fanquake> I'm hoping that all the new wayland deps, and itself all have cmake build systems, otherwise getting rid of autotools and friends will remain a pipe dream
04:25 < laanwj> fanquake: agree, i personally think it's too early to drop X support entirely, i think we should add wayland support first, then see how it goes, then a release or so later drop X
04:25 < fanquake> annoyingly a bunch of the x libs have opted for meson, instead of cmake, so if they stay around we'd need to add another build tool to the mix
04:25 < laanwj> there's no way around maintaining both for a while i'm afaid
04:26 -!- dviola [~diego@user/dviola] has quit [Quit: WeeChat 4.2.2]
04:26 < laanwj> in any case no hurry for the wayland part imo
04:26 < hebasto> as CMake is expected to be landed into the master branch in August, it seems reasonable to handle stuff in the following order: CMake -- Qt6 -- Wayland
04:27 < laanwj> yes it's the future but the future is ever far away
04:27 < laanwj> anyone reasonable runs Xwayland, there are plenty of linux aplications that still require X, eg krita
04:28 < laanwj> and it's not like we're doing high perf frame-synced embedded graphics stuf
04:28 < hebasto> ^ right
04:28 < fanquake> I'm not even sure of the state of our x support. I think all the libs we currently use in depends have all been deprecated for some other "newer/more comprehensive" suite of x libs
04:30 -!- dviola [~diego@user/dviola] has joined #bitcoin-core-dev
04:30 < laanwj> but this is what i meant, let's worry about wayland when all the other things are done, if it's just a matter of a checkbox on flatpak.org so be it 😄
04:30 -!- the_mariner [~Thunderbi@2804:7f7:e082:64b0:75fd:4f5a:8f0c:5faf] has joined #bitcoin-core-dev
04:31 < fanquake> Yea. Plenty of other gui bugs/problems that'd be more useful to solve in the interim
04:31 < laanwj> hebasto: sgtm 
04:38 < laanwj> <fanquake> "I'm not even sure of the state..." <- could be ! the last major library change i can think of was XCB, which was a long time ago,and maybe some XKB/input bus accessiblity stuff--at least the latter is shared by wayland, development on X (besides Xwayland) is effectively dead
04:54 -!- Chris_Stewart_5 [~Chris_Ste@185.141.119.176] has quit [Ping timeout: 268 seconds]
04:55 -!- Chris_Stewart_5 [~Chris_Ste@185.141.119.146] has joined #bitcoin-core-dev
05:03 -!- pablomartin [~pablomart@89.35.25.93] has quit [Ping timeout: 240 seconds]
05:16 < laanwj> FWIW, i was (lightly) involved in the integration of wayland to Godot, there are definitely parallels with our GUI situation and games, in that they are binaries that need to run in an unpredictable, maybe even hostile environment. One think id like to do is dynamically load all dependencies at runtime. Anything to do with input, output, system integration. This reduces or even removes compile-time dependency on anything (headers can often be
05:16 < laanwj> vendored).
05:17 < laanwj> i will look into how to do this with Qt6, so we can know before we start integration
05:23 < laanwj> that is, unless someone wants to work on a godot instead of qml based gui 😄
05:25 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
05:40 -!- jon_atack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
05:42 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 255 seconds]
05:49 < sipa> sounds fancy
05:54 < laanwj> it has a great ui framework, not that different in concept to qml, also supports mobile well, some people actually use it for non-game apps! but one thing is that it's written around a real time frameloop so there's CPU/GPU usage even if there's no interaction or changes... so for a mostly static ui that's a bit of a bummer
05:59 < laanwj> so unfortunately Qt, still is a slightly better choice...
06:03 -!- oneeyedalien [~oneeyedal@user/oneeyedalien] has joined #bitcoin-core-dev
06:06 < bitcoin-git> [bitcoin] fjahr opened pull request #29904: refactor: Use our own implementation of urlDecode (master...2024-04-libevent-urldecode) https://github.com/bitcoin/bitcoin/pull/29904
06:06 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
06:08 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 256 seconds]
06:20 -!- virtu [~virtu@user/virtu] has joined #bitcoin-core-dev
06:20 -!- adil2 [~Thunderbi@2402:d000:8134:2169:250a:c404:2e98:67e6] has joined #bitcoin-core-dev
06:24 -!- adil2 [~Thunderbi@2402:d000:8134:2169:250a:c404:2e98:67e6] has quit [Client Quit]
06:48 < fjahr> Some very superficial analysis for pinheadmz's libevent topic, probably flawed but maybe it helps some that haven't interacted with libevent much: https://gist.github.com/fjahr/c0c339a4b5021ae815d5bcff42e9fc57 Posting now so people can take a quick look before we start.
06:49 < laanwj> most of it is straightforward, the most annoying and hard to replace part of libevent that we use is the webserver
06:52 < laanwj> we had tons of problems with boost::asio's http stuff, which prompted moving to libevent, which at least functionality wise worked a lot better, though there's some ugly hacks around its single thread support interaction w/ rpc
06:53 < laanwj> that said i'm happy now that we never moved P2P networing to libevent
06:53 < pinheadmz> yes, phew ;-)
06:53 < pinheadmz> is there a simpler http server in cpp with MIT we can just vendor in?
06:54 < pinheadmz> do we need a whole event loop? if so, even libuv is way better maintained
06:54 < laanwj> i don't know, maybe, webservers are a hairy mess in general, although this one is for internal use only and ot supposed to be exposed to the internet so it's slightly less security critical at least...
06:55 < pinheadmz> right, seems like the kind of thing we could vendor in or rewrite even
06:55 -!- jarthur [~jarthur@user/jarthur] has joined #bitcoin-core-dev
06:55 < laanwj> it's also not super performance criticial i'd say, though some people that do heavy use of the API might disagree here
06:56 < fjahr> yeah, for our usecase I think most projects will be overengineered and we have to understand all the code anyway but I don't was to post spoilers before we start the topic :D
06:56 < laanwj> sorry :)
06:56 < pinheadmz> fjahr you started it! 
06:56 -!- plank4 [~plank4@2402:8100:2738:b6c1:7214:60f3:73c9:cb82] has joined #bitcoin-core-dev
06:56 < fjahr> that was just reading material xD
07:00 < achow101> #startmeeting
07:00 < sdaftuar> hi
07:00 < stickies-v> hi
07:00 < fjahr> hi
07:00 < pinheadmz> yo
07:00 < cfields> hi
07:00 < hebasto> hi
07:00 < achow101> #bitcoin-core-dev Meeting: achow101 _aj_ amiti ariard aureleoules b10c BlueMatt brunoerg cfields darosior dergoegge dongcarl fanquake fjahr furszy gleb glozow hebasto instagibbs jamesob jarolrod jonatack josibake kallewoof kanzure kouloumos kvaciral laanwj LarryRuane lightlike luke-jr MacroFake Murch phantomcircuit pinheadmz promag provoostenator ryanofsky sdaftuar S3RK stickies-v sipa theStack TheCharlatan vasild
07:00 < glozow> hi
07:00 < brunoerg> hi
07:00 < vasild> hi
07:00 < furszy> hi
07:00 < achow101> There is one pre-proposed meeting topic this week. Any last minute ones to add?
07:00 < b10c> hi
07:00 < Murch[m]> hi
07:00 < dergoegge> hi
07:01 -!- mickin [~quassel@212.129.87.36] has joined #bitcoin-core-dev
07:01 < virtu> hi
07:01 < achow101> #topic package relay updates (glozow)
07:01 < glozow> #28970 is the priority. (thanks everyone for the reviews, will push later today)
07:01 <@gribble> https://github.com/bitcoin/bitcoin/issues/28970 | p2p: opportunistically accept 1-parent-1-child packages by glozow · Pull Request #28970 · bitcoin/bitcoin · GitHub
07:01 < tdb3> hi
07:02 < laanwj> hi
07:02 < josie> hi
07:02 < glozow> And I'm sure instagibbs would be happy for reviews on #28984
07:02 <@gribble> https://github.com/bitcoin/bitcoin/issues/28984 | Cluster size 2 package rbf by instagibbs · Pull Request #28984 · bitcoin/bitcoin · GitHub
07:03 < glozow> That's all from me
07:03 < achow101> #topic cluster mempool updates (sdaftuar)
07:03 < darosior> hi
07:03 < sipa> hi
07:04 < sdaftuar> I'm almost done rewriting my branch with the draft cluster mempool implementation, which I'll then rebase on master and push up to the draft PR.
07:04 < sdaftuar> I believe Pieter is working on getting a version of the linearization code ready for its own PR. Once we're at that point, that would be the first item for people to review as part of the cluster mempool roadmap.
07:04 < willcl-ark> Hi
07:04 < kanzure> hi
07:05 < sdaftuar> Also, I posted a summary of my research on data from 2023 to delving, summarizing the effects of cluster mempool on last year's data.  If anyone has further thoughts/concerns about the effects, I'd love to hear feedback.
07:05 < sdaftuar> I think that's it for me 
07:05 < achow101> is there an eta on that PR being opened?
07:06 < sdaftuar> not sure, sipa?
07:06 < sipa> i hope in the next week or so
07:07 < achow101> looking forward to it
07:08 < achow101> #topic legacy wallet removal updates (achow101)
07:08 < bitcoin-git> [bitcoin] BorjaPractica opened pull request #29905: modificación (24.x...master) https://github.com/bitcoin/bitcoin/pull/29905
07:08 < achow101> #26606 is still the pr to review, and it's been getting some review since the session we had at CoreDev. I'm hoping that it can be merged in the next couple of weeks
07:08 <@gribble> https://github.com/bitcoin/bitcoin/issues/26606 | wallet: Implement independent BDB parser by achow101 · Pull Request #26606 · bitcoin/bitcoin · GitHub
07:09 < achow101> otherwise, #28574 is also a good target for review
07:09 <@gribble> https://github.com/bitcoin/bitcoin/issues/28574 | wallet: optimize migration process, batch db transactions by furszy · Pull Request #28574 · bitcoin/bitcoin · GitHub
07:09 < bitcoin-git> [bitcoin] fanquake closed pull request #29905: modificación (24.x...master) https://github.com/bitcoin/bitcoin/pull/29905
07:09 -!- cryptapus [~cryptapus@user/cryptapus] has quit [Quit: Konversation terminated!]
07:10 < achow101> if people have weird legacy wallets, testing out #26606 on them would be great
07:10 <@gribble> https://github.com/bitcoin/bitcoin/issues/26606 | wallet: Implement independent BDB parser by achow101 · Pull Request #26606 · bitcoin/bitcoin · GitHub
07:10 < achow101> #topic Ad-hoc high priority for review
07:10 < achow101> Anything to add or remove from https://github.com/orgs/bitcoin/projects/1/views/4
07:11 -!- plank4 [~plank4@2402:8100:2738:b6c1:7214:60f3:73c9:cb82] has quit [Quit: Client closed]
07:11 < sipa> i'd like to get some eyes on #29625
07:11 <@gribble> https://github.com/bitcoin/bitcoin/issues/29625 | Several randomness improvements by sipa · Pull Request #29625 · bitcoin/bitcoin · GitHub
07:11 -!- oneeyedalien [~oneeyedal@user/oneeyedalien] has quit [Quit: Leaving]
07:12 < laanwj> still planning to do some big endian tests with the migration wallet
07:12 < achow101> sipa: added
07:12 < sipa> it gives us an actual fully deterministic mode for the RNG for use in fuzz and tests, hopefully dropping the need for various "deterministic mode" things in the future
07:13 < sipa> achow101: thanks
07:13 < achow101> #topic libevent: replace? fork & maintain? leave it alone?
07:13 -!- plank7 [~plank7@2402:8100:2738:b6c1:7214:60f3:73c9:cb82] has joined #bitcoin-core-dev
07:13 < achow101> (pinheadmz)
07:13 < pinheadmz> yeah so i started working on adding unix socket support for rpc
07:13 -!- plank7 [~plank7@2402:8100:2738:b6c1:7214:60f3:73c9:cb82] has quit [Client Quit]
07:14 < pinheadmz> libevent claims it supports unix sockets, but it dont: https://github.com/libevent/libevent/issues/1615
07:14 -!- israt [~israt@2402:8100:2738:b6c1:7214:60f3:73c9:cb82] has joined #bitcoin-core-dev
07:14 < pinheadmz> we pretty much only use libevent for http service, in the rpc server and bitcoin cli
07:14 < cfields> concept ack :)
07:14 < pinheadmz> and if you look at libevent repo, its all bitcoin core devs issues and prs anyway
07:14 < achow101> my super naive thought is that since we already do the socket stuff for p2p handling, and http is a fairly simple and straightforward protocol (especially for our usage), it wouldn't be that complicated to implement it ourselves?
07:15 < fjahr> Strongly in favor of removing libevent and replacing it with our own code. My frustrations with it are a few years old already (https://github.com/libevent/libevent/issues/1024) and there are many others that have felt the same before me and since. My mind went there very quickly also after reading the zx story, pretty much exact same symptoms can be observed in libevent. I don’t think we want to maintain a fork. I think 
07:15 < fjahr> implementing the libevent parts we actually use are not an easy project but sets us up much better for the future.
07:15 -!- cryptapus [~cryptapus@user/cryptapus] has joined #bitcoin-core-dev
07:15 < achow101> I could be totally off base though if anyone actually has experience with writing http servers
07:15 < laanwj> concept ack on replacing libevent with something of our own, not with moving to another event library like libuv, would be a large chance of the same shit again
07:15 < pinheadmz> does anyone know off hand a compact simple http server written in cpp with MIT license?
07:16 < cfields> many many years ago I tried to port our net code to libevent rather than handling sockets ourselves and found it to be woefully underpowered and unmaintained back then.
07:16 < cfields> imo it's a substantial liability at this point
07:16 < pinheadmz> ok so sounds like favor is to inlude new code in the repo. easiest would be to find an existing implementation with compatible license and vendor it i suppose
07:16 < stickies-v> at the previous coredev cfields and I had a look at potential options to replace the libevent webserver and https://github.com/uNetworking/uWebSockets seemed like a potential candidate, its C++17 and seems quite well maintained
07:16 < stickies-v> it's apache 2.0 license tho
07:16 < laanwj> a http server is doable if you can keep the scope small, internal-use only, no high perf requirements, it can't be nginx or apache
07:17 < pinheadmz> right, and if we deprecate the REST interface i think we dont even need to support GET requests ;-)
07:17 < vasild> Concept ACK on replacing the sockets stuff with our own. Maybe the http server as well.
07:17 < pinheadmz> vasild p2p sockets are already our own right? is that what you mean
07:17 < sipa> stickies-v: websockets sounds like about an order of magnitude harder than just http, actually...
07:18 < pinheadmz> who did the work to replace boost::process ? wondering how that kind of thing goes, replacing a big dependency
07:18 < achow101> sipa: I had a look at websockets a few months ago (for "serverless" payjoin I think) and it's actually not that complicated
07:19 < pinheadmz> achow101 websockets still requires http...
07:19 < laanwj> yes, websockets are more involved, but not much
07:19 < darosior> Except for backward compat, why does JSONRPC has to be through HTTP at all?
07:19 < fjahr> has anyone had experience with https://github.com/yhirose/cpp-httplib?
07:19 < laanwj> but we're not talking about changing the RPC protocol here
07:19 < sipa> okay, i know too little about webstuff to really have an informed opinion
07:19 < sipa> laanwj: yeah
07:19 < laanwj> let's keep that orthogonal
07:19 < hebasto> pinheadmz: work of still in progress; unused code has to be removed
07:19 < vasild> pinheadmz: I mean to replace all libevent-sockets with our own code - talking to the socks5 proxy. Replacing the libevent http server would be a separate bigger task, maybe feasible as well.
07:20 < darosior> (c-lightning for instance has its JSONRPC server directly without HTTP)
07:20 < achow101> darosior: because it's always been that way :p
07:20 < darosior> :)
07:20 < sipa> maybe together with a move to UNIX-socket based RPC, we can drop the HTTP part?
07:20 < pinheadmz> darosior super interesting idea
07:21 -!- israt [~israt@2402:8100:2738:b6c1:7214:60f3:73c9:cb82] has quit [Ping timeout: 250 seconds]
07:21 < pinheadmz> so users cant for example curl the api
07:21 < sipa> (we'd keep the HTTP part for TCP-based JSON-RPC, of course)
07:21 < achow101> sipa: I'd rather not. there's a ton of stuff that already uses HTTP, and switching from tcp to unix sockets as a client isn't particularly complicated
07:21 < fanquake> what is the ton of stuff
07:22 < sipa> achow101: right, but that stuff has to change anyway if it wants to use UNIX sockets
07:22 < cfields> could be a proxy http app in between?
07:22 < laanwj> agree with achow101, so much stuff is using http
07:22 < achow101> fanquake: literally anything that's already an rpc client? e.g. lightning impls, various python, rust, other language libraries
07:22 < pinheadmz> i think we have to support http forever right? its not just bitcoin-cli its the client lib written in every language
07:22 < pinheadmz> ueaj
07:22 < pinheadmz> s/yeah
07:22 < laanwj> in retrospect it'd have been better to do like c-lightning, just JSON records over a pipe, but i don't think it's a good idea to change that now
07:22 < sipa> it was just an idea, not a strong opinion
07:23 < laanwj> all user software uses the current JSON RPC, if we abandon that, no one will upgrade. anymore basically :)
07:23 < pinheadmz> ok so sounds like the move is to include a http.cpp in bitcoin core one way or another
07:23 < sipa> my idea is that we'd have two interfaces, TCP+HTTP+JSON-RPC, and UNIX+JSON-RPC, and both remain supported forever
07:23 < pinheadmz> doesnt need to be the best webserver ever but should handle long ques of rpc commands from multiple clients
07:24 < laanwj> heck there's software that still requires the legacy wallet, i intend to help joinmarket port to the new one, interface drift is a pain even where it's really needed
07:24 < pinheadmz> sipa well there is also a broader interest in not getting xz-ed by libevent
07:24 < laanwj> @pinheadmz exactly
07:24 < _aj_> pinheadmz: (can't get xz'ed if upstream never updates though?)
07:25 < pinheadmz> lol there is that
07:25 < fanquake> I think it's much less likely to happen via libevent than other deps
07:25 < fanquake> and it basically already happened via boost process
07:25 < pinheadmz> dont wanna stray but did boost get hacked ?
07:25 < fanquake> compromising one of N random boost maintainers to get something into the 130mb tarball is much easier than getting something into libevent, that doesn't do new releases
07:26 < achow101> pinheadmz: I think the next step would be to concretely propose a replacement then, as there seems to be agreement that replacing with something is the way to go.
07:26 < laanwj> i was kind of disappointed in the maintenance state of libevent, back when i tried to add UNIX socket support
07:26 < pinheadmz> laanwj i got chu fam
07:26 < darosior> achow101: +1
07:26 < pinheadmz> achow101 agreed
07:26 < laanwj> @achow101 agree
07:26 < fanquake> pinheadz: not hacked, when we re-enabled boost-process for windows it was doing random networking things, that never got picked up in review
07:27 < pinheadmz> 😬
07:27 < laanwj> windows has this wacky winsock library that should only be initialized by us
07:27 < achow101> anything else to discuss today?
07:27 < hebasto> yeap
07:27 < fjahr> If you read the timeline of the xz backdoor, it exactly sounds like the state of libevent now, if libevent started to do releases more often all of a sudden I would be very scared
07:28 < laanwj> @fjahr libevent is an attractive target because of its use in tor
07:28 < fanquake> Yea it's used all over the place. chromium, torrent libs etc
07:28 < laanwj> that also makes that there are probably lots of security conscious people looking at it though
07:29 < vasild> "if libevent started to do releases more often all of a sudden" -- or it has already been backdoored and things have settled now...
07:29 < laanwj> heeh
07:29 < achow101> #endmeeting
07:29 < pinheadmz> how tf is tor and chromium doing unix sockets then! lol
07:30 -!- mickin [~quassel@212.129.87.36] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
07:37 < laanwj> <pinheadmz> "how tf is tor and chromium doing..." <- i assume theyre not using the http part; the basic networking event handling works fine for any kind of socket, it's the web server/client that has the limitation
07:37 -!- pablomartin [~pablomart@89.35.25.98] has joined #bitcoin-core-dev
07:41 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has joined #bitcoin-core-dev
08:10 -!- ion- [ion-@user/ion-] has joined #bitcoin-core-dev
08:14 -!- ion-_ [ion-@user/ion-] has joined #bitcoin-core-dev
08:16 -!- flag [~flag@81.56.89.175] has joined #bitcoin-core-dev
08:16 -!- ion- [ion-@user/ion-] has quit [Quit: Client closed]
08:19 -!- pablomartin [~pablomart@89.35.25.98] has quit [Ping timeout: 268 seconds]
08:21 < jonatack> only distantly related, but fwiw the current work in cjdns is reportedly about getting rid of libuv. https://x.com/cjdelisle/status/1780622627540701191
08:25 < jonatack> "Cjdns running with Rust/Tokio based UDP Interface for the first time ever. Only thing left to do is port Pipe / PipeServer (i.e. unix socket / windows named pipe based interface) and then I can finally yank Libuv from the codebase." https://twitter.com/cjdelisle/status/1779990853844373820
08:31 < laanwj> jonatack: interesting; i'd assume something like cjdns does actually need high performance networking, which is a good reason to use a library like libuv (eg to abstract various fancy OS-specific completion mechanisms), that said, if they're going the rust route there's plenty of other options
08:31 -!- bugs_ [~bugs@user/bugs/x-5128603] has joined #bitcoin-core-dev
08:35 -!- preimage [~halosghos@user/halosghost] has joined #bitcoin-core-dev
08:46 -!- salvatoshi [~salvatosh@genymobile-2-6-86.fib.nerim.net] has quit [Ping timeout: 256 seconds]
08:51 -!- szkl [uid110435@id-110435.uxbridge.irccloud.com] has quit [Quit: Connection closed for inactivity]
09:03 -!- blockdyor [~blockdyor@dynamic-adsl-94-34-196-193.clienti.tiscali.it] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
09:18 -!- cjd_ [~root@91-165-39-242.subs.proxad.net] has joined #bitcoin-core-dev
09:22 -!- cjd_ is now known as cjd
09:24 -!- blockdyor [~blockdyor@dynamic-adsl-94-34-196-193.clienti.tiscali.it] has joined #bitcoin-core-dev
09:43 < cjd> Hello Folks, I understand there was some discussion about removal of Libev from Core and the topic came up that I am working on getting Libuv out of cjdns - the choice to move away from Libuv is not exactly a negative for Libuv, but the way it has been used in the context of cjdns is not ideal at all.
09:43 < cjd> 1. We use an ancient fork of Libuv which has a patch to support watching a Windows HANDLE - so we can't easily update it
09:45 < cjd> 2. Cjdns uses an Allocator structure (i.e. talloc) and Libuv does not shutdown synchronously so it is the cause of asynchronous onFree hook in the allocator which created an enormous amount of complexity
09:48 < cjd> 3. We're not going to get any faster without moving to multi-threaded code, and Libuv is not really designed for multi-threaded - at least you can't share a uv_loop_t
09:49 < cjd> 4. Rust makes multi-threaded async code so much more pleasant, and Rust and C interop is not that bad, so it made sense to move the hot & async parts of the code to Rust
09:49 < laanwj> @cjd thanks for the information, with libevent and us it's a similar situation, we're not exactly using it in an optimal way (nor for the main networking), and we'd require some custom patching to do what we want (unix sockets in http), and we use some hacks to work with the single-threaded nature of the event loop and worker threads which aren't quite nice (especially while using a C API from C++)
09:51 < cjd> If you don't hate adding Rust to the build, I would take a look at using Tokio for the event loop and calling it through C functions
09:55 < laanwj> that's for the recommendation--there's some intend to use rust more, but starting with some optional features, tools, and so on, we're not ready to use it for the core RPC, also i think we could do with something much simpler, the way we use libevent we don't quite need a heavy duty async framework
09:57 < cjd> Oh, another thing about my application is I don't use Boost (obviously) so libuv is the only thing I use to bind to the OS, it's either that, or POSIX, or OS-specific headers. I've been burned by the latter enough that having something like the Rust stdlib to call through is convenient
10:00 < laanwj> hah we're trying to get rid of boost as a dependency, i'm happy we're not using it for networking ! the main P2P code already uses OS-specific network functionality so it's a smaller step to also using it for RPC 
10:02 < laanwj> i mean the P2P code actually covers all the difficult/complex networking we do, a local RPC server should be straightforward in comparison
10:03 < laanwj> if it wouldn't have been for needing a http server/client :)
10:04 < cjd> I'm not such a fan of OS-specific code, but I get to write enough of it with the subtle differences between ... everything ... when it comes to TUN devices
10:07 -!- pablomartin [~pablomart@89.35.25.94] has joined #bitcoin-core-dev
10:08 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
10:17 -!- ion-_ [ion-@user/ion-] has quit []
11:05 < bitcoin-git> [packaging] achow101 opened pull request #224: 25.x snap: Update to 25.2 (25.x...pub-25.2) https://github.com/bitcoin-core/packaging/pull/224
11:13 < bitcoin-git> [packaging] achow101 merged pull request #224: 25.x snap: Update to 25.2 (25.x...pub-25.2) https://github.com/bitcoin-core/packaging/pull/224
11:56 -!- ion- [ion-@user/ion-] has joined #bitcoin-core-dev
11:57 -!- the_mariner [~Thunderbi@2804:7f7:e082:64b0:75fd:4f5a:8f0c:5faf] has quit [Ping timeout: 256 seconds]
12:05 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:10 < bitcoin-git> [bitcoin] ryanofsky opened pull request #29906: Disable util::Result copying and assignment (master...pr/saferesult) https://github.com/bitcoin/bitcoin/pull/29906
12:15 -!- Guest48 [~Guest48@c-73-146-73-156.hsd1.in.comcast.net] has joined #bitcoin-core-dev
12:19 -!- JTL [~jtl@user/jtl] has quit [Remote host closed the connection]
12:20 -!- JTL [~jtl@user/jtl] has joined #bitcoin-core-dev
12:22 -!- Guest48 [~Guest48@c-73-146-73-156.hsd1.in.comcast.net] has quit [Quit: Client closed]
12:41 -!- ___nick___ [~quassel@cpc68290-cdif17-2-0-cust24.5-1.cable.virginm.net] has joined #bitcoin-core-dev
12:41 -!- ___nick___ [~quassel@cpc68290-cdif17-2-0-cust24.5-1.cable.virginm.net] has quit [Client Quit]
12:43 -!- ___nick___ [~quassel@cpc68290-cdif17-2-0-cust24.5-1.cable.virginm.net] has joined #bitcoin-core-dev
12:46 -!- the_mariner [~Thunderbi@2804:29b8:518d:a89:5c14:d15d:bf33:e0ae] has joined #bitcoin-core-dev
12:58 -!- ion- [ion-@user/ion-] has quit [Remote host closed the connection]
13:04 -!- ___nick___ [~quassel@cpc68290-cdif17-2-0-cust24.5-1.cable.virginm.net] has quit [Ping timeout: 264 seconds]
13:11 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has quit [Quit: Connection closed for inactivity]
13:14 -!- ion- [ion-@user/ion-] has joined #bitcoin-core-dev
13:22 -!- ion- [ion-@user/ion-] has quit [Ping timeout: 268 seconds]
13:30 < bitcoin-git> [bitcoin] hebasto opened pull request #29907: test: Fix `test/streams_tests.cpp` compilation on SunOS / illumos (master...240418-char) https://github.com/bitcoin/bitcoin/pull/29907
13:35 -!- ion- [ion-@user/ion-] has joined #bitcoin-core-dev
13:37 -!- the_mariner [~Thunderbi@2804:29b8:518d:a89:5c14:d15d:bf33:e0ae] has quit [Ping timeout: 272 seconds]
13:39 -!- Guest48 [~Guest48@c-73-146-73-156.hsd1.in.comcast.net] has joined #bitcoin-core-dev
13:47 -!- Guest48 [~Guest48@c-73-146-73-156.hsd1.in.comcast.net] has quit [Quit: Client closed]
13:51 -!- ion- [ion-@user/ion-] has quit [Ping timeout: 264 seconds]
14:04 -!- ion- [ion-@user/ion-] has joined #bitcoin-core-dev
14:11 < bitcoin-git> [packaging] achow101 opened pull request #225: snap: bitcoin-core service app (main...service) https://github.com/bitcoin-core/packaging/pull/225
14:12 -!- ion- [ion-@user/ion-] has quit [Ping timeout: 252 seconds]
14:21 -!- preimage [~halosghos@user/halosghost] has quit [Quit: WeeChat 4.2.2]
14:24 -!- ion- [ion-@user/ion-] has joined #bitcoin-core-dev
14:25 -!- Guest33 [~Guest33@2601:18c:9281:18e0:fd21:94bf:54f1:be23] has joined #bitcoin-core-dev
14:30 -!- ion- [ion-@user/ion-] has quit [Ping timeout: 256 seconds]
14:42 -!- ion- [ion-@user/ion-] has joined #bitcoin-core-dev
14:57 -!- bugs_ [~bugs@user/bugs/x-5128603] has quit [Quit: Leaving]
15:03 -!- Guest33 [~Guest33@2601:18c:9281:18e0:fd21:94bf:54f1:be23] has quit [Quit: Client closed]
15:08 -!- Davidazde [~Davidazde@185.142.131.150] has joined #bitcoin-core-dev
15:10 -!- Davidazde [~Davidazde@185.142.131.150] has quit [Client Quit]
15:22 -!- blockdyor [~blockdyor@dynamic-adsl-94-34-196-193.clienti.tiscali.it] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
15:58 -!- ion- [ion-@user/ion-] has quit [Ping timeout: 252 seconds]
16:12 -!- ion- [ion-@user/ion-] has joined #bitcoin-core-dev
16:20 -!- the_mariner [~Thunderbi@2804:29b8:518d:a89:5c14:d15d:bf33:e0ae] has joined #bitcoin-core-dev
16:34 -!- the_mariner [~Thunderbi@2804:29b8:518d:a89:5c14:d15d:bf33:e0ae] has quit [Ping timeout: 268 seconds]
17:08 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
17:35 -!- pablomartin4btc [~pablomart@89.35.25.94] has joined #bitcoin-core-dev
17:39 -!- pablomartin [~pablomart@89.35.25.94] has quit [Ping timeout: 268 seconds]
18:02 -!- jarthur_ [~jarthur@user/jarthur] has joined #bitcoin-core-dev
18:02 -!- jarthur_ [~jarthur@user/jarthur] has quit [Client Quit]
18:05 -!- jarthur [~jarthur@user/jarthur] has quit [Ping timeout: 260 seconds]
18:59 -!- ion- [ion-@user/ion-] has quit [Ping timeout: 256 seconds]
19:12 -!- ion- [ion-@user/ion-] has joined #bitcoin-core-dev
19:21 -!- ion- [ion-@user/ion-] has quit [Ping timeout: 264 seconds]
19:33 -!- ion- [ion-@user/ion-] has joined #bitcoin-core-dev
19:38 -!- ion- [ion-@user/ion-] has quit [Ping timeout: 252 seconds]
19:50 -!- ion- [ion-@user/ion-] has joined #bitcoin-core-dev
20:03 -!- jon_atack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
20:05 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 268 seconds]
20:57 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
20:59 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 256 seconds]
21:01 -!- cmirror [~cmirror@4.53.92.114] has quit [Remote host closed the connection]
21:01 -!- cmirror [~cmirror@4.53.92.114] has joined #bitcoin-core-dev
22:09 -!- Guest98 [~Guest98@178-143-34-211.static.orange.sk] has joined #bitcoin-core-dev
22:45 -!- furszy [~furszy@user/furszy] has quit [Quit: ZNC - https://znc.in]
22:46 -!- furszy [~furszy@104.128.239.93] has joined #bitcoin-core-dev
22:52 -!- blockdyor [~blockdyor@dynamic-adsl-94-34-196-193.clienti.tiscali.it] has joined #bitcoin-core-dev
22:55 -!- Chris_Stewart_5 [~Chris_Ste@185.141.119.146] has quit [Ping timeout: 272 seconds]
22:57 -!- Chris_Stewart_5 [~Chris_Ste@185.141.119.176] has joined #bitcoin-core-dev
23:17 -!- ion- [ion-@user/ion-] has quit [Remote host closed the connection]
23:32 -!- ion- [ion-@user/ion-] has joined #bitcoin-core-dev
23:40 -!- ion- [ion-@user/ion-] has quit [Ping timeout: 256 seconds]
23:52 -!- ion- [ion-@user/ion-] has joined #bitcoin-core-dev
23:56 -!- ion- [ion-@user/ion-] has quit [Ping timeout: 256 seconds]
--- Log closed Fri Apr 19 00:00:26 2024