--- Log opened Tue May 02 00:00:49 2023
00:19 -!- gribble [~gribble@bitcoin/bot/gribble] has joined #bitcoin-core-dev
00:19 -!- mode/#bitcoin-core-dev [+o gribble] by ChanServ
00:41 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #bitcoin-core-dev
00:54 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has joined #bitcoin-core-dev
01:02 -!- vysn [~vysn@user/vysn] has joined #bitcoin-core-dev
01:32 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has left #bitcoin-core-dev [Closing Window]
01:44 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Remote host closed the connection]
02:03 -!- dberkelmans [~dberkelma@2001:1c03:530d:8100:71f6:d9c5:3781:fb4b] has joined #bitcoin-core-dev
02:06 < bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/be0325c6a625...8a373a5c7f94
02:06 < bitcoin-git> bitcoin/master 271c23e Martin Zumsande: blockstorage: Adjust fastprune limit if block exceeds blockfile size
02:06 < bitcoin-git> bitcoin/master 8f14fc8 Matthew Zipkin: test: cover fastprune with excessive block size
02:06 < bitcoin-git> bitcoin/master 8a373a5 fanquake: Merge bitcoin/bitcoin#27191: blockstorage: Adjust fastprune limit if block...
02:06 < bitcoin-git> [bitcoin] fanquake merged pull request #27191: blockstorage: Adjust fastprune limit if block exceeds blockfile size (master...202302_fastprune_oom) https://github.com/bitcoin/bitcoin/pull/27191
02:17 -!- dberkelmans [~dberkelma@2001:1c03:530d:8100:71f6:d9c5:3781:fb4b] has quit [Quit: Client closed]
02:19 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #bitcoin-core-dev
02:21 < Murch> <BlueMatt[m]> "is there a case where bitcoin..." <- Yes, generally the fee estimation can be unreliable if you were offline. We use only transactions that were in the mempool and then got included in a block, so I think if you e.g. went offline a bit before the mempool got cleared out, then started it later it would reload from the mempool file on startup, see that all these transactions have gotten confirmed, including ones that the node has just
02:21 < Murch> received and then you have no new data after that. I'd imagine that might lead to underestimation.
02:23 < Murch> Also, if the short-term data is entry it would fall back to slightly older data, up to the last couple days or so
02:24 < Murch> I'm not sure whether there is a mechanism in place to ensure it does not provide estimates if it has too little data
02:25 < Murch> It might fall back to the default fee in that case
02:27 < sipa> Yeah, there is a fallback fee setting, IIRC
02:28 < Murch> Anyway, it probably takes at least one blocks to be found for the fee estimation to have local information
02:34 < sipa> IIRC you need at least 2x as many blocks as the window you're aiming for to get a reliable estimate.
02:38 -!- aielima [~aielima@user/aielima] has quit [Quit: Ciao]
02:39 -!- dberkelmans [~dberkelma@2001:1c03:530d:8100:a47d:5302:7b01:d7f3] has joined #bitcoin-core-dev
02:44 -!- dberkelmans [~dberkelma@2001:1c03:530d:8100:a47d:5302:7b01:d7f3] has quit [Ping timeout: 245 seconds]
02:46 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Ping timeout: 246 seconds]
02:50 -!- gossie [~gossie@2001:1c02:109:6a00:df25:6321:8260:d9be] has quit [Quit: = "bye bye"]
03:00 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #bitcoin-core-dev
03:04 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Ping timeout: 240 seconds]
03:05 -!- flooded [~flooded@146.70.202.142] has quit [Ping timeout: 240 seconds]
03:13 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #bitcoin-core-dev
03:22 < sipa> Though, it shouldn't return 1 sat/vb when not enough data is available...
03:24 -!- achow101 [~achow101@user/achow101] has quit [Quit: No Ping reply in 180 seconds.]
03:26 -!- achow101 [~achow101@user/achow101] has joined #bitcoin-core-dev
03:29 < willcl_ark> glozow / Pieter  ref discussion on #19109 (which I can't reply to), just noting here that enabling NODE_BLOOM will permit our node to send peers a response to a `mempool` msg -- it doesn't require additional net permissions on the peer. (h/t b10c)
03:29 <@gribble> https://github.com/bitcoin/bitcoin/issues/19109 | Only allow getdata of recently announced invs by sipa · Pull Request #19109 · bitcoin/bitcoin · GitHub
03:33 < fanquake> willcl_ark: that thread is now unlocked
03:35 < willcl_ark> thanks
03:37 < sipa> @willcl_ark Yeah, good point. Perhaps I wasn't aware when that PR was created, or perhaps it was considered so fringe that we didn't care.
03:39 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Remote host closed the connection]
03:40 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-dev
03:44 < bitcoin-git> [bitcoin] MarcoFalke reopened pull request #25975: contrib/init: Better systemd integration (master...2022-09-systemd-improve) https://github.com/bitcoin/bitcoin/pull/25975
03:45 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 264 seconds]
03:51 -!- vysn [~vysn@user/vysn] has quit [Ping timeout: 268 seconds]
03:55 < glozow> sipa: thoughts on requiring recently announced invs even when there was a recent mempool message? Based on https://github.com/bitcoin/bitcoin/pull/27426#issuecomment-1529678174, NODE_BLOOM is extremely common and default on in some places today
04:02 < bitcoin-git> [bitcoin] Bushstar opened pull request #27551: Reduce calls to various SetNull methods (master...reduce-setnull) https://github.com/bitcoin/bitcoin/pull/27551
04:03 -!- stick [sid403625@user/prusnak] has quit [Quit: Connection closed for inactivity]
04:03 < sipa> @glozow That's crazy... do we know why Umbrel and Raspiblitz are setting peerbloomfilters? 
04:04 < sipa> If we do want to keep support for that, I think it's reasonable to indeed exclude non-yet-announced transactions from the BIP35 response.
04:06 < glozow> sipa: I agree 😭. My best guess is it’s for bisq
04:07 < sipa> BIP37 (or BIP111 now...) support should really be enabled just for peers trusted not to DoS.
04:07 < glozow> Yes, unfortunately it seems people do not know this
04:09 < glozow> I think we could open issues to umbrel and raspiblitz to discourage it and maybe put louder warnings, but for now exclude not recently announced
04:09 < sipa> That makes sense.
04:16 < darosior> Murch, BlueMatt[m]: but there is an exponential decay on data points. If all the data we've got is from too long ago we should (and i'm pretty sure do) fail to provide any estimate.
04:17 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-dev
04:19 < darosior> About the BIP37 issue i was stunt too so i've asked on Twitter yesterday why do those node-in-a-box set `peerbloomfilters` and a Raspiblitz contributor said it was indeed for Bisq support (as glozow suggested). https://twitter.com/darosior/status/1653037196704727046
04:19 < darosior> It's even crazier when you think they usually come bundled with a Lightning node...
04:19 < sipa> If so, shouldn't it suffice to provide it to 127.0.0.1 ?
04:20 -!- flooded [~flooded@146.70.202.142] has joined #bitcoin-core-dev
04:20 < darosior> I think they provide it through Tor because they use it to remotely connect to their node at home
04:21 -!- flooded is now known as _flood
04:21 < sipa> ... do they keep the onion address secret?
04:21 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 246 seconds]
04:25 < darosior> I don't know but i don't see why they'd share it. It was also an argument from the Raspiblitz contributor: that they only run the bitcoind and lightningd through Tor so it's harder to correlate them... But hey it sounds like a pretty weak protection
04:45 < emzy> FWIW I run 4 bitcoin core public nodes for Bisq, with peerbloomfilters=1. They are very busy but work fine.
04:50 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-dev
04:55 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 248 seconds]
04:56 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-dev
04:58 < darosior> emzy: could Bisq technically switch to using something like block filters instead?
05:01 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 260 seconds]
05:02 < furszy> most likely it's not bisq issue, it's bitcoinj not supporting client side filtering.
05:04 < furszy> will check what they have there, been a while since I worked with it.
05:13 < furszy> ok yep, bitcoinj master doesn't have the node_compact_filters service flag. 
05:13 < bitcoin-git> [bitcoin] sipa opened pull request #27552: Add support for "partial" fuzzers that indicate usefulness (master...202305_partial_fuzzers) https://github.com/bitcoin/bitcoin/pull/27552
05:19 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #27553: test: Simplify feature_fastprune.py (master...2305-test-fastprune-less-code-) https://github.com/bitcoin/bitcoin/pull/27553
05:20 < josie> sipa: iirc, they don't keep the onion address secret. the onion address is your "identity" in bisq and how your reputation metric is tracked
05:21 < sipa> @josie#1745 I mean the onion address of the bitcoind node. Is that the same?
05:21 <@gribble> https://github.com/bitcoin/bitcoin/issues/1745 | Misc IRC fixes. by gmaxwell · Pull Request #1745 · bitcoin/bitcoin · GitHub
05:24 < josie> sipa: ah good point, the onion address for bisq is completely separate from your bitcoind node afaik
05:30 -!- nintendo1889 [uid23646@id-23646.tinside.irccloud.com] has joined #bitcoin-core-dev
05:30 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/8a373a5c7f94...cfe5da4c9026
05:30 < bitcoin-git> bitcoin/master 82e6e3c Sebastian Falbesoner: test: add ripemd160 to test framework modules list
05:30 < bitcoin-git> bitcoin/master cfe5da4 fanquake: Merge bitcoin/bitcoin#27542: test: add ripemd160 to test framework modules...
05:30 < bitcoin-git> [bitcoin] fanquake merged pull request #27542: test: add ripemd160 to test framework modules list (master...test-test_runner_add_ripemd160_module) https://github.com/bitcoin/bitcoin/pull/27542
05:32 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
05:41 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
05:45 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/cfe5da4c9026...d654c762c82d
05:45 < bitcoin-git> bitcoin/master 24d55fb kevkevin: test: added coverage to rpc_scantxoutset.py
05:45 < bitcoin-git> bitcoin/master d654c76 fanquake: Merge bitcoin/bitcoin#27453: test: added coverage to rpc_scantxoutset.py
05:45 < bitcoin-git> [bitcoin] fanquake merged pull request #27453: test: added coverage to rpc_scantxoutset.py (master...test/scantxoutsetInvalid) https://github.com/bitcoin/bitcoin/pull/27453
05:46 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 246 seconds]
05:55 < furszy> .
05:55 < furszy> maybe Bisq, and others, could switch to use core instead of bitcoinj if we provide opt-in client side filtering capabilities.
05:55 < furszy> which.. shilling a bit, is basically what I have been implementing the past months (it’s not fully ready but, short summary: I have a PoC running with p2p, RPC and wallet support to request filters on-demand and automatically, track in-flight and stale requests and request matching blocks + update the wallet state).
05:56 < furszy> this was the reason behind #26966, #27006 and #27469..
05:56 <@gribble> https://github.com/bitcoin/bitcoin/issues/26966 | index: blockfilter initial sync speedup, parallelize process by furszy · Pull Request #26966 · bitcoin/bitcoin · GitHub
05:56 < furszy> so.. will try to get in-touch with Bisq and see what they have planned. Even if this doesn’t get into core soon (or never if there is no consensus), it’s a good use case for them and for us to get rid-off bip35 and bip37 net support.
05:56 <@gribble> https://github.com/bitcoin/bitcoin/issues/27006 | reduce cs_main scope, guard block index nFile under a local mutex by furszy · Pull Request #27006 · bitcoin/bitcoin · GitHub
05:56 <@gribble> https://github.com/bitcoin/bitcoin/issues/27469 | wallet: improve IBD sync time by skipping block scanning prior birth time by furszy · Pull Request #27469 · bitcoin/bitcoin · GitHub
05:56 < sdaftuar> jamesob6: yeah i understand the desire to not special-case the download logic. but i was hoping we can avoid parametrizing data in net_processing based on Chainstate -- it seems like most of the complexity in block download is having to deal with the case that we might need to download a chain that forks from our own chain.
05:56 < sdaftuar> jamesob6: so i was thinking that if the background chain download logic really is dead-simple, maybe we can just introduce logic that does that simple thing.  i'll play with it and see what i get
05:59 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has joined #bitcoin-core-dev
06:04 < bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/d654c762c82d...7b45d171f549
06:04 < bitcoin-git> bitcoin/master 1232c2f fanquake: ci: use LLVM/clang-16 in native_asan job
06:04 < bitcoin-git> bitcoin/master f952e67 fanquake: ci: remove usage of untrusted bpfcc-tools
06:04 < bitcoin-git> bitcoin/master 7b45d17 fanquake: Merge bitcoin/bitcoin#27360: ci: use LLVM/clang-16 in native_asan job
06:04 < bitcoin-git> [bitcoin] fanquake merged pull request #27360: ci: use LLVM/clang-16 in native_asan job (master...asan_llvm_16) https://github.com/bitcoin/bitcoin/pull/27360
06:04 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has left #bitcoin-core-dev [Closing Window]
06:08 < josie> furszy: sounds cool! so this would be bitcoin core node which asks for blocks on demand based on the wallet / rpc commands?
06:09 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-dev
06:20 < furszy> yeah. There are two modes: manual and automatic. The manual mode moves the sync responsibility to any external software (RPC commands to request filters, get the wallet needle set, check if filter matches, request the block, etc). And a automatic mode that follows bip157 client side specs.
06:26 < josie> furszy: id be interested in testing/playing around with this if you have a branch I can compile and run
06:33 -!- jamesob [~jamesob@141.156.173.67] has quit [Quit: The Lounge - https://thelounge.chat]
06:33 -!- jamesob6 [~jamesob@141.156.173.67] has quit [Quit: The Lounge - https://thelounge.chat]
06:46 -!- bugs_ [~bugs@user/bugs/x-5128603] has joined #bitcoin-core-dev
06:47 < furszy> cool josie :). I’m not that far from sharing it publicly, being pushing to reach to a point where I'm happy enough with the sources first (have a good number of pending to do). Mainly to not share something that I know that will be changing soon and get a better first review/testing experience.
06:47 < furszy> Thus why have been decoupling stuff from that branch into smaller PRs, like the ones shared above, so those can be reviewed in parallel and this branch doesn't become a big scary monster.
06:48 < josie> furszy: cool, looking forward to it!
06:50 < furszy> <3
06:52 -!- b_101 [~robert@189.236.59.209] has quit [Ping timeout: 256 seconds]
07:02 -!- jonatack1 [~jonatack@user/jonatack] has joined #bitcoin-core-dev
07:04 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Remote host closed the connection]
07:05 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 264 seconds]
07:19 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #bitcoin-core-dev
07:25 -!- vysn [~vysn@user/vysn] has joined #bitcoin-core-dev
07:36 < bitcoin-git> [bitcoin] hebasto opened pull request #27554: test: Treat `bitcoin-wallet` binary in the same way as others (master...230502-toolwallet) https://github.com/bitcoin/bitcoin/pull/27554
07:38 < instagibbs> re:estimatesmartfee, if it's degraded, it shouldn't return garbage, but an error, right?
07:39 < instagibbs> (or a fallback fee if enabled, which isn't on mainnet?)
07:42 < Murch> I think if you were just offline for a bit, and the mempool cleared after shut down, the transactions that get loaded with the mempool and the catching up to the chaintip might be the only data to estimate the short-window on
07:42 < Murch> 1 ṩ/vB seems odd though, because it should use the maximum from the short-term, mid-term, and long-term bucket
07:42 < achow101> there's a fee_estimate.dat file, so presumably we are loading that with possibly outdated data on start
07:43 < instagibbs> Murch depends on mode, not sure what mode they're using
07:46 < dergoegge> lightlike: RE https://github.com/bitcoin/bitcoin/pull/27552#pullrequestreview-1409209797
07:46 < dergoegge> You might be interested in https://mboehme.github.io/paper/FSE20.Entropy.pdf, which is something that libFuzzer implements
07:46 < dergoegge> Afaiu this is what they do now instead of picking inputs at random from the corpus, to spend more time on "interesting" inputs
07:47 < sipa> Ah yes, I found that too after looking up what the log message about "entropic power schedule" was about.
07:58 < BlueMatt[m]> <sipa> "Yeah, there is a fallback fee..." <- That’s just for wallet, though, no? The estimator itself should never use that.
07:58 < instagibbs> the estimator is supposed to barf if it's not confident
07:59 < BlueMatt[m]> <Murch> "Yes, generally the fee estimatio..." <- Right, but it won’t invent things out of whole cloth, which would be required to explain what I saw.
08:00 < BlueMatt[m]> instagibbs: Right that’s what the code I read said, I was mostly checking that (a) I read it right and (b) there’s not some other known cases where it returns 1s/van
08:00 < BlueMatt[m]> Vb
08:00 -!- nintendo1889 [uid23646@id-23646.tinside.irccloud.com] has quit [Quit: Connection closed for inactivity]
08:04 < instagibbs> Only known case I know of is sometimes mempool fills up(and trims) faster than estimator can catch up, so mempool minfee isn't reflected in it
08:08 -!- b_101 [~robert@189.194.249.94] has joined #bitcoin-core-dev
08:14 < darosior> Regarding BIP37 being manually enabled by node-in-a-box solutions, i've opened an issue in the Umbrel and Raspiblitz repositories. Just FYI: https://github.com/getumbrel/umbrel/issues/1624 https://github.com/rootzoll/raspiblitz/issues/3781.
08:14 < instagibbs> BlueMatt[m] https://github.com/bitcoin/bitcoin/issues/11800#issuecomment-349697807 squinting at this issue, maybe it indeed returns "garbage" at lower timeframes
08:14 < fanquake> darosior: thanks
08:15 < darosior> re fee estimation. "there's a fee_estimate.dat file, so presumably we are loading that with possibly outdated data on start" -> Yes but we do store the height in this file iirc. And if it's too far from our current best height we won't serve outdated data.
08:15 < fjahr> I am not sure if this is related to Matt’s issue because we are talking about very different time frames but I just synced a node that wasn’t running since early last month, so it had to catch up about 4 weeks. The mempool was cleared and as it was syncing I requested “estimatesmartfee 2” multiple times because I saw the conversation here. The suggested feerate fluctuated between 0.00006167 and 0.00022090. I don’t 
08:15 < fjahr> see how the node would be able to make reliable predictions if it hasn’t seen the blocks of the last few days and nothing in the mempool. Does anyone know on what basis these values are fluctuating in this case?
08:16 < BlueMatt[m]> instagibbs: Squinting there it shouldn’t happen on mainnet though I think?
08:16 < instagibbs> I've never seen it, though I don't restart old nodes a lot and use them
08:17 < BlueMatt[m]> At least the counterparty in one case claimed their node had crashed only a few hours before
08:17 < BlueMatt[m]> Dunno how often the estimates are written to disk during normal operation
08:17 < BlueMatt[m]> So unclear how old that file could have been
08:17 < darosior> BlueMatt[m]: only at shutdown
08:18 < BlueMatt[m]> Oh that’s bad
08:18 < instagibbs> ah, crash 
08:18 < BlueMatt[m]> So maybe that was the bug then - restarted with estimates from a month ago or something stupid
08:18 < instagibbs> seems like something we could flush every 24 hours? not a huge file
08:18 < BlueMatt[m]> Yea that plus reject if the estimates haven’t caught up with now
08:18 < BlueMatt[m]> Or otherwise are that old
08:19 < BlueMatt[m]> Or even persist once an hour
08:19 < darosior> Then how comes it would serve old data? Maybe it wasn't synced yet and didn't know it was outdated?
08:20 < BlueMatt[m]> I’d understood fjahr s point to be that it will happily serve stale data
08:20 < BlueMatt[m]> As long as it has data
08:20 < darosior> Yeah we should definitely not serve fee estimation if we are catching up
08:26 < BlueMatt[m]> https://github.com/bitcoin/bitcoin/issues/27555 okay I think I captured the conversation here
08:51 < bitcoin-git> [bitcoin] achow101 pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/7b45d171f549...da9f62f91229
08:51 < bitcoin-git> bitcoin/master 710b839 Harris: rpc: return block hash & height in getbalances, gettransaction & getwallet...
08:51 < bitcoin-git> bitcoin/master da9f62f Andrew Chow: Merge bitcoin/bitcoin#26094: rpc: Return block hash & height in getbalance...
08:51 < bitcoin-git> [bitcoin] achow101 merged pull request #26094: rpc: Return block hash & height in getbalances, gettransaction and getwalletinfo (master...return-blockhash-with-wallet-calls) https://github.com/bitcoin/bitcoin/pull/26094
08:56 < instagibbs> fjahr https://github.com/bitcoin/bips/pull/1382#issuecomment-1531716890 I think this might be "generic " vs "ancestor" package relay confusion, which also confuses me as to the purpose of the former
08:59 -!- b_101 [~robert@189.194.249.94] has quit [Ping timeout: 268 seconds]
09:11 -!- berndj [~berndj@197.189.254.139] has quit [Quit: ZNC - http://znc.in]
09:11 < fjahr> instagibbs: hm, possible, I thought I kind of understood that part (narrator: "he didn't") but there is nothing named pkginfo or similar in the generic part. Most likely I would guess the graphics haven't evolved with the text.
09:11 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Remote host closed the connection]
09:14 < fjahr> But yeah, ancpkginfo is something different and I guess plain pkginfo has been removed at some point (?)
09:16 -!- berndj [~berndj@197.189.254.139] has joined #bitcoin-core-dev
09:17 -!- jamesob6 [~jamesob@141.156.173.67] has joined #bitcoin-core-dev
09:17 -!- jamesob4 [~jamesob@141.156.173.67] has joined #bitcoin-core-dev
09:19 < jamesob6> sdaftuar: great! anything that minimizes risk is +1 from me
09:20 < instagibbs> fjahr it's in the "generic" portion imagery, otherwise not defined 
09:21 < instagibbs> (i think)
09:23 -!- b_101 [~robert@189.194.249.94] has joined #bitcoin-core-dev
09:23 < fjahr> yepp, that's what I see too, I guess glozow will have to solve that mystery :)
09:25 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #bitcoin-core-dev
09:28 -!- flooded [~flooded@146.70.195.35] has joined #bitcoin-core-dev
09:30 -!- b_101 [~robert@189.194.249.94] has quit [Ping timeout: 264 seconds]
09:32 -!- _flood [~flooded@146.70.202.142] has quit [Ping timeout: 268 seconds]
09:51 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
09:57 -!- b_101 [~robert@189.194.249.94] has joined #bitcoin-core-dev
10:02 -!- b_101 [~robert@189.194.249.94] has quit [Ping timeout: 268 seconds]
10:26 -!- b_101 [~robert@189.194.249.94] has joined #bitcoin-core-dev
10:30 -!- b_101 [~robert@189.194.249.94] has quit [Ping timeout: 240 seconds]
10:36 -!- aielima [~aielima@user/aielima] has joined #bitcoin-core-dev
10:38 < achow101> 24.1rc2 and 25.0rc1 bins are uploaded
10:41 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Remote host closed the connection]
10:53 -!- b_101 [~robert@189.194.249.94] has joined #bitcoin-core-dev
10:58 -!- b_101 [~robert@189.194.249.94] has quit [Ping timeout: 246 seconds]
11:03 -!- Guest55 [~Guest55@43.243.193.4] has joined #bitcoin-core-dev
11:06 -!- Guest55 [~Guest55@43.243.193.4] has quit [Client Quit]
11:09 < bitcoin-git> [bitcoin] furszy opened pull request #27556: wallet: fix deadlock in bdb read write operation (master...2023_wallet_db_deadlock) https://github.com/bitcoin/bitcoin/pull/27556
11:12 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #bitcoin-core-dev
11:20 -!- b_101 [~robert@189.194.249.94] has joined #bitcoin-core-dev
11:28 < bitcoin-git> [bitcoin] pinheadmz opened pull request #27557: net: call getaddrinfo() in detachable thread to prevent stalling (master...async-getaddrinfo) https://github.com/bitcoin/bitcoin/pull/27557
11:30 < bitcoin-git> [bitcoin] pinheadmz closed pull request #27505: net: use interruptible async getaddrinfo wrapper from libevent for DNS (master...dns-libevent) https://github.com/bitcoin/bitcoin/pull/27505
11:31 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Ping timeout: 240 seconds]
11:36 < jamesob6> anyone ever have a hard time reproducing threadsanitizer errors locally?
11:36 -!- jamesob6 is now known as jamesob
11:57 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #bitcoin-core-dev
12:10 -!- test_ [~flooded@146.70.195.35] has joined #bitcoin-core-dev
12:13 -!- flooded [~flooded@146.70.195.35] has quit [Ping timeout: 240 seconds]
12:16 < fjahr> FYI: For those that were testing my gitlab instance, Mike and me are making some changes as we discuss the topic with them so it's possible that the instance will not be available at some point in the coming days due to new setup or that your account changes.
12:17 < fjahr> DM me if there is something you want to test in the meantime
12:23 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:37 -!- flooded [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #bitcoin-core-dev
12:41 -!- test_ [~flooded@146.70.195.35] has quit [Ping timeout: 252 seconds]
13:13 -!- kch [~kch@45.187.210.56] has joined #bitcoin-core-dev
13:15 -!- b_101 [~robert@189.194.249.94] has quit [Ping timeout: 240 seconds]
13:35 -!- kch [~kch@45.187.210.56] has quit [Quit: Lost terminal]
14:27 -!- vysn [~vysn@user/vysn] has quit [Remote host closed the connection]
14:37 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Remote host closed the connection]
14:38 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
14:40 -!- vysn [~vysn@user/vysn] has joined #bitcoin-core-dev
14:42 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 240 seconds]
14:52 -!- bugs_ [~bugs@user/bugs/x-5128603] has quit [Quit: Leaving]
15:05 -!- aielima [~aielima@user/aielima] has quit [Quit: Ciao]
15:28 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-dev
15:33 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 248 seconds]
15:39 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-dev
15:40 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Quit: Leaving...]
15:43 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 248 seconds]
15:45 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-dev
15:47 -!- b_101 [~robert@189.236.59.209] has joined #bitcoin-core-dev
15:49 < bitcoin-git> [bitcoin] 0xB10C opened pull request #27559: doc: clarify processing of mempool-msgs when NODE_BLOOM (master...2023-05-clarify-mempool-bloom) https://github.com/bitcoin/bitcoin/pull/27559
15:49 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 240 seconds]
15:56 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-dev
15:57 < bitcoin-git> [bitcoin] furszy closed pull request #26644: wallet: bugfix, 'wallet_load_ckey' unit test fails with bdb (master...2022_walletdb_fix_bdb_deadlock) https://github.com/bitcoin/bitcoin/pull/26644
16:01 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 240 seconds]
16:22 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-dev
16:27 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 246 seconds]
16:28 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-dev
16:33 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 240 seconds]
16:45 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
16:49 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 240 seconds]
16:51 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-dev
16:55 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 240 seconds]
17:07 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-dev
17:12 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 240 seconds]
17:24 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
17:29 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 268 seconds]
17:42 < glozow> fjahr: yeah sorry about the confusion... I'm trying to give a sense of a "generic" dialogue but it just comes out as underspecified. It's true "pkginfo" is not defined anywhere. My general point is that in the future we would define more types of pkginfo but reuse getpkgtxns and pkgtxns.
17:47 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-dev
17:51 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 240 seconds]
18:00 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-dev
18:06 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Remote host closed the connection]
18:06 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-dev
18:10 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 240 seconds]
18:24 -!- robobub [uid248673@id-248673.uxbridge.irccloud.com] has joined #bitcoin-core-dev
18:27 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-dev
18:31 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 246 seconds]
18:43 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-dev
18:47 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 240 seconds]
19:00 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
19:05 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 268 seconds]
19:07 -!- vysn [~vysn@user/vysn] has quit [Remote host closed the connection]
19:23 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-dev
19:24 < _aj_> glozow: probably better to make it very explicitly a placeholder, like "future_pkginfo" or something, then?
19:27 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 240 seconds]
19:39 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
19:44 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 268 seconds]
20:06 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-dev
20:10 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 240 seconds]
20:23 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-dev
20:27 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 246 seconds]
20:28 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-dev
20:31 -!- szkl [uid110435@id-110435.uxbridge.irccloud.com] has joined #bitcoin-core-dev
20:33 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 246 seconds]
20:34 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-dev
20:35 -!- r00kiefullnode [~r00kieful@d-138-207-210-152.fl.cpe.atlanticbb.net] has joined #bitcoin-core-dev
20:39 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 240 seconds]
20:41 -!- r00kiefullnode [~r00kieful@d-138-207-210-152.fl.cpe.atlanticbb.net] has quit [Ping timeout: 245 seconds]
20:45 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-dev
20:50 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 246 seconds]
20:51 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
20:57 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 268 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
21:06 -!- lowhope_ is now known as lowhope
21:20 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
21:24 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 240 seconds]
21:31 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
21:31 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-dev
21:35 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 240 seconds]
21:46 -!- jonatack1 [~jonatack@user/jonatack] has quit [Ping timeout: 268 seconds]
21:48 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-dev
21:48 -!- jonatack1 [~jonatack@user/jonatack] has joined #bitcoin-core-dev
21:52 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 246 seconds]
21:59 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-dev
22:03 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 250 seconds]
22:10 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-dev
22:14 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 240 seconds]
22:21 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
22:25 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 240 seconds]
22:36 -!- szkl [uid110435@id-110435.uxbridge.irccloud.com] has quit [Quit: Connection closed for inactivity]
22:37 -!- amishbtc [~amishbtc@cpe-74-72-75-120.nyc.res.rr.com] has quit [Quit: Leaving]
22:37 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-dev
22:42 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 240 seconds]
22:49 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
22:53 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 240 seconds]
22:54 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-dev
22:59 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 246 seconds]
23:01 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-dev
23:05 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 240 seconds]
23:17 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-dev
23:22 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 260 seconds]
23:23 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
23:27 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 250 seconds]
23:45 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
23:55 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 268 seconds]
--- Log closed Wed May 03 00:00:50 2023