12024-04-18T00:29:52  *** Guest65 <Guest65!~Guest59@45.79.155.42> has joined #bitcoin-core-dev
  22024-04-18T00:31:17  *** jonatack <jonatack!~jonatack@user/jonatack> has quit IRC (Ping timeout: 272 seconds)
  32024-04-18T00:32:13  *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
  42024-04-18T00:56:39  *** S3RK <S3RK!~S3RK@user/s3rk> has joined #bitcoin-core-dev
  52024-04-18T00:59:59  *** S3RK_ <S3RK_!~S3RK@user/s3rk> has quit IRC (Ping timeout: 264 seconds)
  62024-04-18T01:03:54  *** kalle <kalle!~quassel@user/kallewoof> has quit IRC (Ping timeout: 255 seconds)
  72024-04-18T02:24:18  *** Guest65 <Guest65!~Guest59@45.79.155.42> has quit IRC (Ping timeout: 250 seconds)
  82024-04-18T02:32:49  *** cman <cman!~con@180-150-21-3.b49615.mel.static.aussiebb.net> has joined #bitcoin-core-dev
  92024-04-18T02:36:21  *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has joined #bitcoin-core-dev
 102024-04-18T02:36:53  *** conman <conman!~con@180-150-21-3.b49615.mel.static.aussiebb.net> has quit IRC (Ping timeout: 268 seconds)
 112024-04-18T03:52:08  *** abubakarsadiq <abubakarsadiq!uid602234@id-602234.hampstead.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)
 122024-04-18T04:01:02  *** cmirror <cmirror!~cmirror@4.53.92.114> has quit IRC (Remote host closed the connection)
 132024-04-18T04:01:33  *** cmirror <cmirror!~cmirror@4.53.92.114> has joined #bitcoin-core-dev
 142024-04-18T04:42:24  *** kinlo <kinlo!~peter@user/kinlo> has quit IRC (Ping timeout: 260 seconds)
 152024-04-18T04:44:01  *** kinlo <kinlo!~peter@user/kinlo> has joined #bitcoin-core-dev
 162024-04-18T05:47:49  *** blockdyor <blockdyor!~blockdyor@dynamic-adsl-94-34-196-193.clienti.tiscali.it> has joined #bitcoin-core-dev
 172024-04-18T06:59:39  <Sjors[m]> In net.cpp there's a comment:
 182024-04-18T06:59:40  <Sjors[m]> > If -proxy is in use, we make an ADDR_FETCH connection to the DNS resolved peer address
 192024-04-18T07:00:02  <Sjors[m]> What is that supposed to do? Is it looking for a peer at the DNS seeder domain?
 202024-04-18T07:00:51  <Sjors[m]> Oh I guess this effectively connects to the first result?
 212024-04-18T07:04:34  <Sjors[m]> Or in any case, it will connect to whatever IPv4 / IPv6 IP the operating system picks.
 222024-04-18T08:32:17  *** Guyver2 <Guyver2!~Guyver@77-174-98-73.fixed.kpn.net> has joined #bitcoin-core-dev
 232024-04-18T08:48:23  <bitcoin-git> [bitcoin] hebasto pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/dbd2000b3490...aaab5fb3c51c
 242024-04-18T08:48:24  <bitcoin-git> bitcoin/master 6d8eecd MarcoFalke: refactor: Avoid implicit-integer-sign-change in createTransaction
 252024-04-18T08:48:25  <bitcoin-git> bitcoin/master 321f105 MarcoFalke: refactor: Avoid implicit-signed-integer-truncation-or-sign-change in Freed...
 262024-04-18T08:48:25  <bitcoin-git> bitcoin/master 0541642 MarcoFalke: refactor: Avoid implicit-integer-sign-change in processNewTransaction
 272024-04-18T08:49:05  <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
 282024-04-18T08:52:49  *** vasild <vasild!~vd@user/vasild> has joined #bitcoin-core-dev
 292024-04-18T09:05:28  <bitcoin-git> [bitcoin] hebasto pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/aaab5fb3c51c...c05c214f2e9c
 302024-04-18T09:05:28  <bitcoin-git> bitcoin/master c6d1b8d Sebastian Falbesoner: gui: change example address from legacy (P2PKH) to bech32m (P2TR)
 312024-04-18T09:05:29  <bitcoin-git> bitcoin/master c05c214 merge-script: Merge bitcoin-core/gui#808: Change example address from legacy (P2PKH) to ...
 322024-04-18T09:05:35  <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
 332024-04-18T09:09:15  *** vasild <vasild!~vd@user/vasild> has quit IRC (Remote host closed the connection)
 342024-04-18T09:09:38  *** vasild <vasild!~vd@user/vasild> has joined #bitcoin-core-dev
 352024-04-18T09:13:08  <laanwj> <Sjors[m]> "Oh I guess this effectively..." <- yes, that's what it effectively does
 362024-04-18T09:18:07  <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
 372024-04-18T09:18:45  <laanwj> using the local DNS would be a clear DNS leak
 382024-04-18T09:25:01  <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
 392024-04-18T09:30:28  <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...
 402024-04-18T09:30:51  *** Zenton <Zenton!~user@user/zenton> has quit IRC (Read error: Connection reset by peer)
 412024-04-18T09:31:14  *** Zenton <Zenton!~user@user/zenton> has joined #bitcoin-core-dev
 422024-04-18T09:32:19  <laanwj> oh!
 432024-04-18T09:39:50  <bitcoin-git> [bitcoincore.org] fanquake pushed 2 commits to master: https://github.com/bitcoin-core/bitcoincore.org/compare/847d30cf150d...e0e634fb61b7
 442024-04-18T09:39:50  <bitcoin-git> bitcoincore.org/master 40722b7 Ava Chow: ci: Fix verify commits ci
 452024-04-18T09:39:51  <bitcoin-git> bitcoincore.org/master e0e634f merge-script: Merge bitcoin-core/bitcoincore.org#1019: ci: Fix verify commits ci
 462024-04-18T09:39:56  <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
 472024-04-18T09:42:05  <bitcoin-git> [bitcoincore.org] fanquake pushed 2 commits to master: https://github.com/bitcoin-core/bitcoincore.org/compare/e0e634fb61b7...e7c59501bca6
 482024-04-18T09:42:06  <bitcoin-git> bitcoincore.org/master 523fef7 azuchi: Add japanese translation for 25.2
 492024-04-18T09:42:07  <bitcoin-git> bitcoincore.org/master e7c5950 merge-script: Merge bitcoin-core/bitcoincore.org#1017: Add japanese translation for 25.2
 502024-04-18T09:42:13  <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
 512024-04-18T09:45:09  <bitcoin-git> [bitcoincore.org] fanquake pushed 2 commits to master: https://github.com/bitcoin-core/bitcoincore.org/compare/e7c59501bca6...6825a895fd94
 522024-04-18T09:45:10  <bitcoin-git> bitcoincore.org/master bc87e05 azuchi: Add japanese translation for 27.0
 532024-04-18T09:45:10  <bitcoin-git> bitcoincore.org/master 6825a89 merge-script: Merge bitcoin-core/bitcoincore.org#1018: Add japanese translation for 27.0
 542024-04-18T09:45:15  <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
 552024-04-18T10:11:50  *** Guyver2 <Guyver2!~Guyver@77-174-98-73.fixed.kpn.net> has left #bitcoin-core-dev (Closing Window)
 562024-04-18T10:18: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
 572024-04-18T10:44: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
 582024-04-18T10:50:44  <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
 592024-04-18T10:53:43  *** the_mariner <the_mariner!~Thunderbi@179.180.142.244> has joined #bitcoin-core-dev
 602024-04-18T10:58:20  *** the_mariner <the_mariner!~Thunderbi@179.180.142.244> has quit IRC (Ping timeout: 256 seconds)
 612024-04-18T11:12:27  <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 ?
 622024-04-18T11:16:01  <sipa> Sjors[m]: almost; the tor exit node will generally forward the connection to a *random* DNS seed result; not the first one
 632024-04-18T11:16:18  <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.
 642024-04-18T11:16:31  <fanquake> It would probably also be good for us to provide the changelog there, and try and fix (where possible) the "potentially unsafe" markers
 652024-04-18T11:16:39  <fanquake> Don't think we can do anything about Qts windowing system, but we should be able to fix the tor auth cookie issue
 662024-04-18T11:17:11  <fanquake> That could be followed up on in https://github.com/flathub/org.bitcoincore.bitcoin-qt
 672024-04-18T11:17:38  <Sjors[m]> sipa: Is https://man7.org/linux/man-pages/man3/getaddrinfo.3.html what's doing the actual DNS query?
 682024-04-18T11:18:07  <laanwj> fanquake: do you know why it shows it as "legacy window system"
 692024-04-18T11:18:45  <fanquake> I'd assume something to do with it's using X, and not proper Wayland?
 702024-04-18T11:18:46  <laanwj> lack of wayland support i guess?
 712024-04-18T11:19:14  <laanwj> right, that makes sense
 722024-04-18T11:19:37  <sipa> Sjors[m]: i haven't looked at tor's source code, but that seems likely
 732024-04-18T11:20:01  <Sjors[m]> Oh not tor, our own code.
 742024-04-18T11:20:12  <hebasto> speaking of Wayland support -- https://github.com/bitcoin/bitcoin/pull/22708
 752024-04-18T11:20:15  <Sjors[m]> For when there is no proxy, it calls that
 762024-04-18T11:20:20  <laanwj> i'm happy to work on wayland support but it makes only sense to fix that after cmake and (i guess) qt6
 772024-04-18T11:20:45  <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
 782024-04-18T11:20:46  <sipa> Sjors[m]: in that case yes, but that is not used (or should not be used) in case we have a tor proxy
 792024-04-18T11:21:00  <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
 802024-04-18T11:21:28  <laanwj> * library dynamially at run time, which
 812024-04-18T11:23:52  *** SpellChecker <SpellChecker!~SpellChec@user/SpellChecker> has quit IRC (Remote host closed the connection)
 822024-04-18T11:24:10  <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
 832024-04-18T11:24:30  *** SpellChecker <SpellChecker!~SpellChec@user/SpellChecker> has joined #bitcoin-core-dev
 842024-04-18T11:25:15  <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
 852024-04-18T11:25:20  <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
 862024-04-18T11:25:45  <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
 872024-04-18T11:25:50  <laanwj> there's no way around maintaining both for a while i'm afaid
 882024-04-18T11:26:10  *** dviola <dviola!~diego@user/dviola> has quit IRC (Quit: WeeChat 4.2.2)
 892024-04-18T11:26:38  <laanwj> in any case no hurry for the wayland part imo
 902024-04-18T11:26:45  <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
 912024-04-18T11:27:07  <laanwj> yes it's the future but the future is ever far away
 922024-04-18T11:27:38  <laanwj> anyone reasonable runs Xwayland, there are plenty of linux aplications that still require X, eg krita
 932024-04-18T11:28:05  <laanwj> and it's not like we're doing high perf frame-synced embedded graphics stuf
 942024-04-18T11:28:22  <hebasto> ^ right
 952024-04-18T11:28: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
 962024-04-18T11:30:06  *** dviola <dviola!~diego@user/dviola> has joined #bitcoin-core-dev
 972024-04-18T11:30:37  <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 😄
 982024-04-18T11:30:43  *** the_mariner <the_mariner!~Thunderbi@2804:7f7:e082:64b0:75fd:4f5a:8f0c:5faf> has joined #bitcoin-core-dev
 992024-04-18T11:31:17  <fanquake> Yea. Plenty of other gui bugs/problems that'd be more useful to solve in the interim
1002024-04-18T11:31:42  <laanwj> hebasto: sgtm
1012024-04-18T11:38:00  <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
1022024-04-18T11:54:21  *** Chris_Stewart_5 <Chris_Stewart_5!~Chris_Ste@185.141.119.176> has quit IRC (Ping timeout: 268 seconds)
1032024-04-18T11:55:51  *** Chris_Stewart_5 <Chris_Stewart_5!~Chris_Ste@185.141.119.146> has joined #bitcoin-core-dev
1042024-04-18T12:03:41  *** pablomartin <pablomartin!~pablomart@89.35.25.93> has quit IRC (Ping timeout: 240 seconds)
1052024-04-18T12:16:59  <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
1062024-04-18T12:16:59  <laanwj> vendored).
1072024-04-18T12:17:49  <laanwj> i will look into how to do this with Qt6, so we can know before we start integration
1082024-04-18T12:23:01  <laanwj> that is, unless someone wants to work on a godot instead of qml based gui 😄
1092024-04-18T12:25:15  *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has quit IRC (Quit: = "")
1102024-04-18T12:40:21  *** jon_atack <jon_atack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
1112024-04-18T12:42:46  *** jonatack <jonatack!~jonatack@user/jonatack> has quit IRC (Ping timeout: 255 seconds)
1122024-04-18T12:49:27  <sipa> sounds fancy
1132024-04-18T12:54:19  <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
1142024-04-18T12:59:56  <laanwj> so unfortunately Qt, still is a slightly better choice...
1152024-04-18T13:03:21  *** oneeyedalien <oneeyedalien!~oneeyedal@user/oneeyedalien> has joined #bitcoin-core-dev
1162024-04-18T13:06:33  <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
1172024-04-18T13:06:44  *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
1182024-04-18T13:08:45  *** jon_atack <jon_atack!~jonatack@user/jonatack> has quit IRC (Ping timeout: 256 seconds)
1192024-04-18T13:20:43  *** virtu <virtu!~virtu@user/virtu> has joined #bitcoin-core-dev
1202024-04-18T13:20:54  *** adil2 <adil2!~Thunderbi@2402:d000:8134:2169:250a:c404:2e98:67e6> has joined #bitcoin-core-dev
1212024-04-18T13:24:18  *** adil2 <adil2!~Thunderbi@2402:d000:8134:2169:250a:c404:2e98:67e6> has quit IRC (Client Quit)
1222024-04-18T13:48:45  <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.
1232024-04-18T13:49:47  <laanwj> most of it is straightforward, the most annoying and hard to replace part of libevent that we use is the webserver
1242024-04-18T13:52:14  <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
1252024-04-18T13:53:27  <laanwj> that said i'm happy now that we never moved P2P networing to libevent
1262024-04-18T13:53:40  <pinheadmz> yes, phew ;-)
1272024-04-18T13:53:54  <pinheadmz> is there a simpler http server in cpp with MIT we can just vendor in?
1282024-04-18T13:54:36  <pinheadmz> do we need a whole event loop? if so, even libuv is way better maintained
1292024-04-18T13:54:42  <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...
1302024-04-18T13:55:12  <pinheadmz> right, seems like the kind of thing we could vendor in or rewrite even
1312024-04-18T13:55:44  *** jarthur <jarthur!~jarthur@user/jarthur> has joined #bitcoin-core-dev
1322024-04-18T13:55:47  <laanwj> it's also not super performance criticial i'd say, though some people that do heavy use of the API might disagree here
1332024-04-18T13:56:04  <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
1342024-04-18T13:56:30  <laanwj> sorry :)
1352024-04-18T13:56:39  <pinheadmz> fjahr you started it!
1362024-04-18T13:56:56  *** plank4 <plank4!~plank4@2402:8100:2738:b6c1:7214:60f3:73c9:cb82> has joined #bitcoin-core-dev
1372024-04-18T13:56:58  <fjahr> that was just reading material xD
1382024-04-18T14:00:21  <achow101> #startmeeting
1392024-04-18T14:00:23  <sdaftuar> hi
1402024-04-18T14:00:25  <stickies-v> hi
1412024-04-18T14:00:27  <fjahr> hi
1422024-04-18T14:00:29  <pinheadmz> yo
1432024-04-18T14:00:30  <cfields> hi
1442024-04-18T14:00:32  <hebasto> hi
1452024-04-18T14:00:35  <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
1462024-04-18T14:00:37  <glozow> hi
1472024-04-18T14:00:41  <brunoerg> hi
1482024-04-18T14:00:41  <vasild> hi
1492024-04-18T14:00:43  <furszy> hi
1502024-04-18T14:00:50  <achow101> There is one pre-proposed meeting topic this week. Any last minute ones to add?
1512024-04-18T14:00:52  <b10c> hi
1522024-04-18T14:00:55  <Murch[m]> hi
1532024-04-18T14:00:55  <dergoegge> hi
1542024-04-18T14:01:06  *** mickin <mickin!~quassel@212.129.87.36> has joined #bitcoin-core-dev
1552024-04-18T14:01:13  <virtu> hi
1562024-04-18T14:01:34  <achow101> #topic package relay updates (glozow)
1572024-04-18T14:01:50  <glozow> #28970 is the priority. (thanks everyone for the reviews, will push later today)
1582024-04-18T14:01:54  <gribble> https://github.com/bitcoin/bitcoin/issues/28970 | p2p: opportunistically accept 1-parent-1-child packages by glozow · Pull Request #28970 · bitcoin/bitcoin · GitHub
1592024-04-18T14:01:58  <tdb3> hi
1602024-04-18T14:02:11  <laanwj> hi
1612024-04-18T14:02:40  <josie> hi
1622024-04-18T14:02:55  <glozow> And I'm sure instagibbs would be happy for reviews on #28984
1632024-04-18T14:02:57  <gribble> https://github.com/bitcoin/bitcoin/issues/28984 | Cluster size 2 package rbf by instagibbs · Pull Request #28984 · bitcoin/bitcoin · GitHub
1642024-04-18T14:03:08  <glozow> That's all from me
1652024-04-18T14:03:29  <achow101> #topic cluster mempool updates (sdaftuar)
1662024-04-18T14:03:31  <darosior> hi
1672024-04-18T14:03:43  <sipa> hi
1682024-04-18T14:04:01  <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.
1692024-04-18T14:04:37  <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.
1702024-04-18T14:04:43  <willcl-ark> Hi
1712024-04-18T14:04:50  <kanzure> hi
1722024-04-18T14:05:42  <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.
1732024-04-18T14:05:51  <sdaftuar> I think that's it for me
1742024-04-18T14:05:53  <achow101> is there an eta on that PR being opened?
1752024-04-18T14:06:27  <sdaftuar> not sure, sipa?
1762024-04-18T14:06:44  <sipa> i hope in the next week or so
1772024-04-18T14:07:43  <achow101> looking forward to it
1782024-04-18T14:08:00  <achow101> #topic legacy wallet removal updates (achow101)
1792024-04-18T14:08:38  <bitcoin-git> [bitcoin] BorjaPractica opened pull request #29905: modificación (24.x...master) https://github.com/bitcoin/bitcoin/pull/29905
1802024-04-18T14:08:45  <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
1812024-04-18T14:08:47  <gribble> https://github.com/bitcoin/bitcoin/issues/26606 | wallet: Implement independent BDB parser by achow101 · Pull Request #26606 · bitcoin/bitcoin · GitHub
1822024-04-18T14:09:13  <achow101> otherwise, #28574 is also a good target for review
1832024-04-18T14:09:15  <gribble> https://github.com/bitcoin/bitcoin/issues/28574 | wallet: optimize migration process, batch db transactions by furszy · Pull Request #28574 · bitcoin/bitcoin · GitHub
1842024-04-18T14:09:35  <bitcoin-git> [bitcoin] fanquake closed pull request #29905: modificación (24.x...master) https://github.com/bitcoin/bitcoin/pull/29905
1852024-04-18T14:09:49  *** cryptapus <cryptapus!~cryptapus@user/cryptapus> has quit IRC (Quit: Konversation terminated!)
1862024-04-18T14:10:22  <achow101> if people have weird legacy wallets, testing out #26606 on them would be great
1872024-04-18T14:10:25  <gribble> https://github.com/bitcoin/bitcoin/issues/26606 | wallet: Implement independent BDB parser by achow101 · Pull Request #26606 · bitcoin/bitcoin · GitHub
1882024-04-18T14:10:46  <achow101> #topic Ad-hoc high priority for review
1892024-04-18T14:10:50  <achow101> Anything to add or remove from https://github.com/orgs/bitcoin/projects/1/views/4
1902024-04-18T14:11:33  *** plank4 <plank4!~plank4@2402:8100:2738:b6c1:7214:60f3:73c9:cb82> has quit IRC (Quit: Client closed)
1912024-04-18T14:11:39  <sipa> i'd like to get some eyes on #29625
1922024-04-18T14:11:41  <gribble> https://github.com/bitcoin/bitcoin/issues/29625 | Several randomness improvements by sipa · Pull Request #29625 · bitcoin/bitcoin · GitHub
1932024-04-18T14:11:58  *** oneeyedalien <oneeyedalien!~oneeyedal@user/oneeyedalien> has quit IRC (Quit: Leaving)
1942024-04-18T14:12:06  <laanwj> still planning to do some big endian tests with the migration wallet
1952024-04-18T14:12:23  <achow101> sipa: added
1962024-04-18T14:12:32  <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
1972024-04-18T14:13:16  <sipa> achow101: thanks
1982024-04-18T14:13:28  <achow101> #topic libevent: replace? fork & maintain? leave it alone?
1992024-04-18T14:13:39  *** plank7 <plank7!~plank7@2402:8100:2738:b6c1:7214:60f3:73c9:cb82> has joined #bitcoin-core-dev
2002024-04-18T14:13:43  <achow101> (pinheadmz)
2012024-04-18T14:13:46  <pinheadmz> yeah so i started working on adding unix socket support for rpc
2022024-04-18T14:13:48  *** plank7 <plank7!~plank7@2402:8100:2738:b6c1:7214:60f3:73c9:cb82> has quit IRC (Client Quit)
2032024-04-18T14:14:02  <pinheadmz> libevent claims it supports unix sockets, but it dont: https://github.com/libevent/libevent/issues/1615
2042024-04-18T14:14:18  *** israt <israt!~israt@2402:8100:2738:b6c1:7214:60f3:73c9:cb82> has joined #bitcoin-core-dev
2052024-04-18T14:14:32  <pinheadmz> we pretty much only use libevent for http service, in the rpc server and bitcoin cli
2062024-04-18T14:14:48  <cfields> concept ack :)
2072024-04-18T14:14:54  <pinheadmz> and if you look at libevent repo, its all bitcoin core devs issues and prs anyway
2082024-04-18T14:14:57  <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?
2092024-04-18T14:15:05  <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
2102024-04-18T14:15:05  <fjahr> implementing the libevent parts we actually use are not an easy project but sets us up much better for the future.
2112024-04-18T14:15:08  *** cryptapus <cryptapus!~cryptapus@user/cryptapus> has joined #bitcoin-core-dev
2122024-04-18T14:15:35  <achow101> I could be totally off base though if anyone actually has experience with writing http servers
2132024-04-18T14:15:37  <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
2142024-04-18T14:15:39  <pinheadmz> does anyone know off hand a compact simple http server written in cpp with MIT license?
2152024-04-18T14:16:05  <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.
2162024-04-18T14:16:23  <cfields> imo it's a substantial liability at this point
2172024-04-18T14:16:30  <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
2182024-04-18T14:16:33  <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
2192024-04-18T14:16:39  <stickies-v> it's apache 2.0 license tho
2202024-04-18T14:16:42  <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
2212024-04-18T14:17:20  <pinheadmz> right, and if we deprecate the REST interface i think we dont even need to support GET requests ;-)
2222024-04-18T14:17:23  <vasild> Concept ACK on replacing the sockets stuff with our own. Maybe the http server as well.
2232024-04-18T14:17:48  <pinheadmz> vasild p2p sockets are already our own right? is that what you mean
2242024-04-18T14:17:59  <sipa> stickies-v: websockets sounds like about an order of magnitude harder than just http, actually...
2252024-04-18T14:18:44  <pinheadmz> who did the work to replace boost::process ? wondering how that kind of thing goes, replacing a big dependency
2262024-04-18T14:18:47  <achow101> sipa: I had a look at websockets a few months ago (for "serverless" payjoin I think) and it's actually not that complicated
2272024-04-18T14:19:07  <pinheadmz> achow101 websockets still requires http...
2282024-04-18T14:19:07  <laanwj> yes, websockets are more involved, but not much
2292024-04-18T14:19:19  <darosior> Except for backward compat, why does JSONRPC has to be through HTTP at all?
2302024-04-18T14:19:20  <fjahr> has anyone had experience with https://github.com/yhirose/cpp-httplib?
2312024-04-18T14:19:22  <laanwj> but we're not talking about changing the RPC protocol here
2322024-04-18T14:19:26  <sipa> okay, i know too little about webstuff to really have an informed opinion
2332024-04-18T14:19:29  <sipa> laanwj: yeah
2342024-04-18T14:19:30  <laanwj> let's keep that orthogonal
2352024-04-18T14:19:37  <hebasto> pinheadmz: work of still in progress; unused code has to be removed
2362024-04-18T14:19:38  <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.
2372024-04-18T14:20:06  <darosior> (c-lightning for instance has its JSONRPC server directly without HTTP)
2382024-04-18T14:20:16  <achow101> darosior: because it's always been that way :p
2392024-04-18T14:20:24  <darosior> :)
2402024-04-18T14:20:48  <sipa> maybe together with a move to UNIX-socket based RPC, we can drop the HTTP part?
2412024-04-18T14:20:53  <pinheadmz> darosior super interesting idea
2422024-04-18T14:21:02  *** israt <israt!~israt@2402:8100:2738:b6c1:7214:60f3:73c9:cb82> has quit IRC (Ping timeout: 250 seconds)
2432024-04-18T14:21:02  <pinheadmz> so users cant for example curl the api
2442024-04-18T14:21:07  <sipa> (we'd keep the HTTP part for TCP-based JSON-RPC, of course)
2452024-04-18T14:21:38  <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
2462024-04-18T14:21:56  <fanquake> what is the ton of stuff
2472024-04-18T14:22:04  <sipa> achow101: right, but that stuff has to change anyway if it wants to use UNIX sockets
2482024-04-18T14:22:08  <cfields> could be a proxy http app in between?
2492024-04-18T14:22:15  <laanwj> agree with achow101, so much stuff is using http
2502024-04-18T14:22:30  <achow101> fanquake: literally anything that's already an rpc client? e.g. lightning impls, various python, rust, other language libraries
2512024-04-18T14:22:31  <pinheadmz> i think we have to support http forever right? its not just bitcoin-cli its the client lib written in every language
2522024-04-18T14:22:33  <pinheadmz> ueaj
2532024-04-18T14:22:36  <pinheadmz> s/yeah
2542024-04-18T14:22:49  <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
2552024-04-18T14:22:50  <sipa> it was just an idea, not a strong opinion
2562024-04-18T14:23:04  <laanwj> all user software uses the current JSON RPC, if we abandon that, no one will upgrade. anymore basically :)
2572024-04-18T14:23:31  <pinheadmz> ok so sounds like the move is to include a http.cpp in bitcoin core one way or another
2582024-04-18T14:23:49  <sipa> my idea is that we'd have two interfaces, TCP+HTTP+JSON-RPC, and UNIX+JSON-RPC, and both remain supported forever
2592024-04-18T14:23:55  <pinheadmz> doesnt need to be the best webserver ever but should handle long ques of rpc commands from multiple clients
2602024-04-18T14:24:03  <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
2612024-04-18T14:24:36  <pinheadmz> sipa well there is also a broader interest in not getting xz-ed by libevent
2622024-04-18T14:24:49  <laanwj> @pinheadmz exactly
2632024-04-18T14:24:54  <_aj_> pinheadmz: (can't get xz'ed if upstream never updates though?)
2642024-04-18T14:25:03  <pinheadmz> lol there is that
2652024-04-18T14:25:05  <fanquake> I think it's much less likely to happen via libevent than other deps
2662024-04-18T14:25:26  <fanquake> and it basically already happened via boost process
2672024-04-18T14:25:45  <pinheadmz> dont wanna stray but did boost get hacked ?
2682024-04-18T14:25:55  <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
2692024-04-18T14:26:06  <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.
2702024-04-18T14:26:09  <laanwj> i was kind of disappointed in the maintenance state of libevent, back when i tried to add UNIX socket support
2712024-04-18T14:26:22  <pinheadmz> laanwj i got chu fam
2722024-04-18T14:26:25  <darosior> achow101: +1
2732024-04-18T14:26:31  <pinheadmz> achow101 agreed
2742024-04-18T14:26:38  <laanwj> @achow101 agree
2752024-04-18T14:26:40  <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
2762024-04-18T14:27:03  <pinheadmz> 😬
2772024-04-18T14:27:09  <laanwj> windows has this wacky winsock library that should only be initialized by us
2782024-04-18T14:27:20  <achow101> anything else to discuss today?
2792024-04-18T14:27:20  <hebasto> yeap
2802024-04-18T14:27:38  <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
2812024-04-18T14:28:03  <laanwj> @fjahr libevent is an attractive target because of its use in tor
2822024-04-18T14:28:23  <fanquake> Yea it's used all over the place. chromium, torrent libs etc
2832024-04-18T14:28:43  <laanwj> that also makes that there are probably lots of security conscious people looking at it though
2842024-04-18T14:29:01  <vasild> "if libevent started to do releases more often all of a sudden" -- or it has already been backdoored and things have settled now...
2852024-04-18T14:29:08  <laanwj> heeh
2862024-04-18T14:29:24  <achow101> #endmeeting
2872024-04-18T14:29:58  <pinheadmz> how tf is tor and chromium doing unix sockets then! lol
2882024-04-18T14:30:41  *** mickin <mickin!~quassel@212.129.87.36> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
2892024-04-18T14:37:57  <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
2902024-04-18T14:37:58  *** pablomartin <pablomartin!~pablomart@89.35.25.98> has joined #bitcoin-core-dev
2912024-04-18T14:41:33  *** abubakarsadiq <abubakarsadiq!uid602234@id-602234.hampstead.irccloud.com> has joined #bitcoin-core-dev
2922024-04-18T15:10:40  *** ion- <ion-!ion-@user/ion-> has joined #bitcoin-core-dev
2932024-04-18T15:14:30  *** ion-_ <ion-_!ion-@user/ion-> has joined #bitcoin-core-dev
2942024-04-18T15:16:24  *** flag <flag!~flag@81.56.89.175> has joined #bitcoin-core-dev
2952024-04-18T15:16:26  *** ion- <ion-!ion-@user/ion-> has quit IRC (Quit: Client closed)
2962024-04-18T15:19:05  *** pablomartin <pablomartin!~pablomart@89.35.25.98> has quit IRC (Ping timeout: 268 seconds)
2972024-04-18T15:21:05  <jonatack> only distantly related, but fwiw the current work in cjdns is reportedly about getting rid of libuv. https://x.com/cjdelisle/status/1780622627540701191
2982024-04-18T15:25:16  <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
2992024-04-18T15:31:11  <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
3002024-04-18T15:31:29  *** bugs_ <bugs_!~bugs@user/bugs/x-5128603> has joined #bitcoin-core-dev
3012024-04-18T15:35:17  *** preimage <preimage!~halosghos@user/halosghost> has joined #bitcoin-core-dev
3022024-04-18T15:46:51  *** salvatoshi <salvatoshi!~salvatosh@genymobile-2-6-86.fib.nerim.net> has quit IRC (Ping timeout: 256 seconds)
3032024-04-18T15:51:44  *** szkl <szkl!uid110435@id-110435.uxbridge.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)
3042024-04-18T16:03:29  *** blockdyor <blockdyor!~blockdyor@dynamic-adsl-94-34-196-193.clienti.tiscali.it> has quit IRC (Quit: My iMac has gone to sleep. ZZZzzz…)
3052024-04-18T16:18:35  *** cjd_ <cjd_!~root@91-165-39-242.subs.proxad.net> has joined #bitcoin-core-dev
3062024-04-18T16:22:17  *** cjd_ is now known as cjd
3072024-04-18T16:24:42  *** blockdyor <blockdyor!~blockdyor@dynamic-adsl-94-34-196-193.clienti.tiscali.it> has joined #bitcoin-core-dev
3082024-04-18T16:43:20  <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.
3092024-04-18T16:43:58  <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
3102024-04-18T16:45:09  <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
3112024-04-18T16:48:33  <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
3122024-04-18T16:49:42  <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
3132024-04-18T16:49:51  <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++)
3142024-04-18T16:51:32  <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
3152024-04-18T16:55:15  <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
3162024-04-18T16:57:40  <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
3172024-04-18T17:00:23  <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
3182024-04-18T17:02:59  <laanwj> i mean the P2P code actually covers all the difficult/complex networking we do, a local RPC server should be straightforward in comparison
3192024-04-18T17:03:41  <laanwj> if it wouldn't have been for needing a http server/client :)
3202024-04-18T17:04:19  <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
3212024-04-18T17:07:06  *** pablomartin <pablomartin!~pablomart@89.35.25.94> has joined #bitcoin-core-dev
3222024-04-18T17:08:56  *** Talkless <Talkless!~Talkless@mail.dargis.net> has joined #bitcoin-core-dev
3232024-04-18T17:17:48  *** ion-_ <ion-_!ion-@user/ion-> has quit IRC ()
3242024-04-18T18:05:25  <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
3252024-04-18T18:13:04  <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
3262024-04-18T18:56:07  *** ion- <ion-!ion-@user/ion-> has joined #bitcoin-core-dev
3272024-04-18T18:57:49  *** the_mariner <the_mariner!~Thunderbi@2804:7f7:e082:64b0:75fd:4f5a:8f0c:5faf> has quit IRC (Ping timeout: 256 seconds)
3282024-04-18T19:05:50  *** Talkless <Talkless!~Talkless@mail.dargis.net> has quit IRC (Quit: Konversation terminated!)
3292024-04-18T19:10:07  <bitcoin-git> [bitcoin] ryanofsky opened pull request #29906: Disable util::Result copying and assignment (master...pr/saferesult) https://github.com/bitcoin/bitcoin/pull/29906
3302024-04-18T19:15:26  *** Guest48 <Guest48!~Guest48@c-73-146-73-156.hsd1.in.comcast.net> has joined #bitcoin-core-dev
3312024-04-18T19:19:40  *** JTL <JTL!~jtl@user/jtl> has quit IRC (Remote host closed the connection)
3322024-04-18T19:20:32  *** JTL <JTL!~jtl@user/jtl> has joined #bitcoin-core-dev
3332024-04-18T19:22:48  *** Guest48 <Guest48!~Guest48@c-73-146-73-156.hsd1.in.comcast.net> has quit IRC (Quit: Client closed)
3342024-04-18T19:41:16  *** ___nick___ <___nick___!~quassel@cpc68290-cdif17-2-0-cust24.5-1.cable.virginm.net> has joined #bitcoin-core-dev
3352024-04-18T19:41:16  *** ___nick___ <___nick___!~quassel@cpc68290-cdif17-2-0-cust24.5-1.cable.virginm.net> has quit IRC (Client Quit)
3362024-04-18T19:43:47  *** ___nick___ <___nick___!~quassel@cpc68290-cdif17-2-0-cust24.5-1.cable.virginm.net> has joined #bitcoin-core-dev
3372024-04-18T19:46:32  *** the_mariner <the_mariner!~Thunderbi@2804:29b8:518d:a89:5c14:d15d:bf33:e0ae> has joined #bitcoin-core-dev
3382024-04-18T19:58:08  *** ion- <ion-!ion-@user/ion-> has quit IRC (Remote host closed the connection)
3392024-04-18T20:04:11  *** ___nick___ <___nick___!~quassel@cpc68290-cdif17-2-0-cust24.5-1.cable.virginm.net> has quit IRC (Ping timeout: 264 seconds)
3402024-04-18T20:11:11  *** abubakarsadiq <abubakarsadiq!uid602234@id-602234.hampstead.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)
3412024-04-18T20:14:41  *** ion- <ion-!ion-@user/ion-> has joined #bitcoin-core-dev
3422024-04-18T20:22:29  *** ion- <ion-!ion-@user/ion-> has quit IRC (Ping timeout: 268 seconds)
3432024-04-18T20:30:37  <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
3442024-04-18T20:35:09  *** ion- <ion-!ion-@user/ion-> has joined #bitcoin-core-dev
3452024-04-18T20:37:47  *** the_mariner <the_mariner!~Thunderbi@2804:29b8:518d:a89:5c14:d15d:bf33:e0ae> has quit IRC (Ping timeout: 272 seconds)
3462024-04-18T20:39:43  *** Guest48 <Guest48!~Guest48@c-73-146-73-156.hsd1.in.comcast.net> has joined #bitcoin-core-dev
3472024-04-18T20:47:32  *** Guest48 <Guest48!~Guest48@c-73-146-73-156.hsd1.in.comcast.net> has quit IRC (Quit: Client closed)
3482024-04-18T20:51:35  *** ion- <ion-!ion-@user/ion-> has quit IRC (Ping timeout: 264 seconds)
3492024-04-18T21:04:39  *** ion- <ion-!ion-@user/ion-> has joined #bitcoin-core-dev
3502024-04-18T21:11:06  <bitcoin-git> [packaging] achow101 opened pull request #225: snap: bitcoin-core service app (main...service) https://github.com/bitcoin-core/packaging/pull/225
3512024-04-18T21:12:08  *** ion- <ion-!ion-@user/ion-> has quit IRC (Ping timeout: 252 seconds)
3522024-04-18T21:21:57  *** preimage <preimage!~halosghos@user/halosghost> has quit IRC (Quit: WeeChat 4.2.2)
3532024-04-18T21:24:18  *** ion- <ion-!ion-@user/ion-> has joined #bitcoin-core-dev
3542024-04-18T21:25:14  *** Guest33 <Guest33!~Guest33@2601:18c:9281:18e0:fd21:94bf:54f1:be23> has joined #bitcoin-core-dev
3552024-04-18T21:30:41  *** ion- <ion-!ion-@user/ion-> has quit IRC (Ping timeout: 256 seconds)
3562024-04-18T21:42:20  *** ion- <ion-!ion-@user/ion-> has joined #bitcoin-core-dev
3572024-04-18T21:57:32  *** bugs_ <bugs_!~bugs@user/bugs/x-5128603> has quit IRC (Quit: Leaving)
3582024-04-18T22:03:54  *** Guest33 <Guest33!~Guest33@2601:18c:9281:18e0:fd21:94bf:54f1:be23> has quit IRC (Quit: Client closed)
3592024-04-18T22:08:28  *** Davidazde <Davidazde!~Davidazde@185.142.131.150> has joined #bitcoin-core-dev
3602024-04-18T22:10:02  *** Davidazde <Davidazde!~Davidazde@185.142.131.150> has quit IRC (Client Quit)
3612024-04-18T22:22:26  *** blockdyor <blockdyor!~blockdyor@dynamic-adsl-94-34-196-193.clienti.tiscali.it> has quit IRC (Quit: My iMac has gone to sleep. ZZZzzz…)
3622024-04-18T22:58:51  *** ion- <ion-!ion-@user/ion-> has quit IRC (Ping timeout: 252 seconds)
3632024-04-18T23:12:44  *** ion- <ion-!ion-@user/ion-> has joined #bitcoin-core-dev
3642024-04-18T23:20:17  *** the_mariner <the_mariner!~Thunderbi@2804:29b8:518d:a89:5c14:d15d:bf33:e0ae> has joined #bitcoin-core-dev
3652024-04-18T23:34:16  *** the_mariner <the_mariner!~Thunderbi@2804:29b8:518d:a89:5c14:d15d:bf33:e0ae> has quit IRC (Ping timeout: 268 seconds)