--- Log opened Tue Jan 14 00:00:47 2025
00:04 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
00:18 -!- Guest63 [~Guest63@2601:c4:100:7190:9de5:1aa2:3d6e:ce2] has joined #bitcoin-core-dev
00:26 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 244 seconds]
00:43 -!- adil [~Thunderbi@2402:d000:8134:d89:4d79:d6d:6578:5292] has joined #bitcoin-core-dev
00:54 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
01:08 -!- Guest64 [~Guest64@2409:40c1:3030:87e:1ce4:56bc:bbb2:e8ba] has joined #bitcoin-core-dev
01:08 -!- Guest64 [~Guest64@2409:40c1:3030:87e:1ce4:56bc:bbb2:e8ba] has quit [Client Quit]
01:13 -!- jonatack [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer]
01:19 -!- jespada [~jespada@2800:a4:31:b00:a974:16da:8c45:e3b4] has joined #bitcoin-core-dev
01:20 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 246 seconds]
01:24 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has joined #bitcoin-core-dev
01:48 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
02:01 < bitcoin-git> [bitcoin] Sjors closed pull request #31625: miner: always treat SegWit as active (master...2025/01/gbt-segwit-active) https://github.com/bitcoin/bitcoin/pull/31625
02:02 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
02:15 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 252 seconds]
02:21 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
02:25 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 244 seconds]
02:26 -!- Earnestly [~earnest@user/earnestly] has joined #bitcoin-core-dev
02:29 -!- adil [~Thunderbi@2402:d000:8134:d89:4d79:d6d:6578:5292] has quit [Quit: adil]
02:35 -!- jespada [~jespada@2800:a4:31:b00:a974:16da:8c45:e3b4] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
02:39 -!- Victor_sueca [~Victorsue@user/victorsueca] has quit [Ping timeout: 248 seconds]
02:40 -!- eval-exec [~Thunderbi@45.78.56.68.16clouds.com] has quit [Ping timeout: 260 seconds]
02:40 -!- Guest36 [~Guest36@2405:201:c030:28a9:b19e:fe7e:f848:6ae6] has quit [Quit: Client closed]
02:40 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has left #bitcoin-core-dev [Closing Window]
02:41 -!- Victor_sueca [~Victorsue@user/victorsueca] has joined #bitcoin-core-dev
02:42 -!- epic33 [~epic@117.250.76.237] has joined #bitcoin-core-dev
02:42 -!- epic33 [~epic@117.250.76.237] has quit [Client Quit]
02:43 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
02:47 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 245 seconds]
03:01 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
03:08 -!- NakedKing [~NakedKing@user/nakedking] has joined #bitcoin-core-dev
03:10 < NakedKing> Hello, i'm trying to find best approach for my app which handles users incoming-outgoing transactions. this is generally a payment system. i want to dedicate a wallet (or a wallet kind) to my every user.  i've a big performance problem. i dont store any info at my database. every time i process api calls. And unload all wallets and load relevant wallet makes slow my system
03:11 < NakedKing> chatgpt suggested me something named HD Walllet, and suggested also $this->bitcoin->getHDWallet(); but there is no function like getHDWallet, i guess it was an hallusinotion
03:12 -!- adil [~Thunderbi@2402:d000:8134:d89:4d79:d6d:6578:5292] has joined #bitcoin-core-dev
03:17 -!- Guest79 [~Guest63@45.89.52.66] has joined #bitcoin-core-dev
03:22 -!- Cory64 [~Cory64@user/pasha] has quit [Quit: Client closed]
03:22 -!- Cory64 [~Cory64@user/pasha] has joined #bitcoin-core-dev
03:31 -!- adil [~Thunderbi@2402:d000:8134:d89:4d79:d6d:6578:5292] has quit [Quit: adil]
03:32 -!- adil [~Thunderbi@2402:d000:8134:d89:4d79:d6d:6578:5292] has joined #bitcoin-core-dev
03:33 -!- jespada [~jespada@2800:a4:31:b00:a974:16da:8c45:e3b4] has joined #bitcoin-core-dev
03:48 -!- adil [~Thunderbi@2402:d000:8134:d89:4d79:d6d:6578:5292] has quit [Quit: adil]
03:48 -!- adil [~Thunderbi@2402:d000:8134:d89:4d79:d6d:6578:5292] has joined #bitcoin-core-dev
03:53 -!- adil [~Thunderbi@2402:d000:8134:d89:4d79:d6d:6578:5292] has quit [Ping timeout: 252 seconds]
04:30 -!- eval-exec [~Thunderbi@45.78.56.68.16clouds.com] has joined #bitcoin-core-dev
04:31 < bitcoin-git> [bitcoin] Mohammed-Alanazisa opened pull request #31652: Create devcontainer.json (master...patch-1) https://github.com/bitcoin/bitcoin/pull/31652
04:31 < bitcoin-git> [bitcoin] hebasto closed pull request #31652: Create devcontainer.json (master...patch-1) https://github.com/bitcoin/bitcoin/pull/31652
04:38 -!- conman [~con@180-150-21-3.b49615.mel.static.aussiebb.net] has joined #bitcoin-core-dev
05:02 -!- Cory64 [~Cory64@user/pasha] has quit [Quit: Client closed]
05:02 -!- Cory64 [~Cory64@user/pasha] has joined #bitcoin-core-dev
05:22 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
05:33 -!- Guest63 [~Guest63@2601:c4:100:7190:9de5:1aa2:3d6e:ce2] has quit [Quit: Client closed]
05:40 -!- Guest79 [~Guest63@45.89.52.66] has quit [Quit: Client closed]
05:59 < bitcoin-git> [bitcoin] maflcko opened pull request #31653:  lint: Call more checks from test_runner  (master...2501-lint-commit-range) https://github.com/bitcoin/bitcoin/pull/31653
06:06 -!- Victor_sueca [~Victorsue@user/victorsueca] has quit [Quit: Gone frying asparagus or my Windows had a BSOD]
06:15 -!- Victor_sueca [~Victorsue@user/victorsueca] has joined #bitcoin-core-dev
06:16 -!- pyth [~pyth@113.184.143.105] has quit [Ping timeout: 260 seconds]
06:16 -!- pyth [~pyth@123.25.162.204] has joined #bitcoin-core-dev
06:23 -!- zeropoint [~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
06:24 < sipa> NakedKing: that sounds unrelated to bitcoin core
06:37 -!- Guest55 [~Guest55@2600:4041:7b2e:f700:c20a:3f6d:6c5e:4302] has joined #bitcoin-core-dev
07:30 < bitcoin-git> [bitcoincore.org] glozow pushed 2 commits to master: https://github.com/bitcoin-core/bitcoincore.org/compare/f1d9b75ccd6e...c86c62e68897
07:30 < bitcoin-git> bitcoincore.org/master c31e71d Ava Chow: 28.1 release post and notes
07:30 < bitcoin-git> bitcoincore.org/master c86c62e glozow: Merge bitcoin-core/bitcoincore.org#1100: Bitcoin Core 28.1
07:30 < bitcoin-git> [bitcoincore.org] glozow merged pull request #1100: Bitcoin Core 28.1 (master...rel-28.1) https://github.com/bitcoin-core/bitcoincore.org/pull/1100
07:31 < darosior> For next release's testing guide: it would be interesting to get more testing of the new PCP / NAT-PMP implementation against routers provided by large ISPs. At least in the US from what i read on the PR it was only tested against Verizon and Spectrum provided routers. It seems to be something non-too-technical hobbyists could help with.
07:32 < sipa> good idea
07:33 < laanwj> yes, agree
07:33 < sipa> also, how do we feel about making it on by default?
07:33 < sipa> maybe not for 29.x, but it'd be nice if we could get there
07:38 < darosior> Yes, the unit tests from laanwj, potential more testing outside of us, definitely gives more confidence in doing this. Would be nice to have fuzzing coverage first. I think some of what laanwj did for unit tests could be reused there.
07:39 < sipa> right
07:39 < darosior> Also in testing of the rc it would be nice to know if people had to modify their router's configuration. For instance on Spectrum i had to manually enable PCP support on the router, which kind of kills the purpose.
07:41 < sipa> darosior: did it actually use PCP, or fall back to NAT-PMP?
07:42 < darosior> I assumed it used PCP because i saw no log of falling back to NAT-PMP whatsoever
07:44 < laanwj> fuzzing would be nice, i'm really out of my depth there, but yes id assume a similar setup could be used to inject packets as in the unit tests
07:45 < dergoegge> https://github.com/dergoegge/bitcoin/commit/cc3906989229637da034e3324cb4a93367136f03
07:45 < dergoegge> could be a starting point, never polished it...
07:45 < darosior> I'll look into it, reviewed the unit test PR yesterday so it's still fresh in my mind
07:46 < laanwj> thanks!
07:46 < _aj_> laanwj: hey, you've automated nostr stuff, right? are there any tools/libs you can recommend?
07:51 < laanwj> _aj_: yes, i added nostr notification support to the bot that posts merged PRs (https://github.com/laanwj/ghi), and i have some scripts to post the torrents and release notifications (https://github.com/laanwj/miscellany/tree/main/nostr) - i ended up rolling my own code to sign and broadcast notes because none of the python libraries were actively maintained / documented, for rust there's the nostr-sdk crate which is very usable
07:55 < _aj_> laanwj: hmm, copying your handrolled code sounds more appealing than making/resurrecting my own at least
07:56 < _aj_> laanwj: though i guess yours is write only, and doesn't subscribe to anything?
07:58 < darosior> sipa, sdaftuar: question regarding your anti-DoS header sync work in the context of marcofleon's recent PR to remove checkpoints. We have this check to not send headers to peers unless our tip has enough work, to avoid an IDB node to be fed an invalid chain at checkpoint height and send that to peers which would ban it and it would basically
07:58 < darosior> eclipse itself from the honest network. marcofleon points out this logic can be removed along with the checkpoints as since the anti-DoS header sync work we would only ever have headers to serve that have minimum chain work. That makes sense to me, but then it begs the question why this logic was not removed with the anti-DoS header sync work
07:58 < darosior> itself? Any reason to keep it we'd be missing?
07:58 < laanwj> _aj_: correct, it's write-only, that's the only thing i've ever needed to automate
07:58 -!- jespada [~jespada@2800:a4:31:b00:a974:16da:8c45:e3b4] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
07:59 < _aj_> darosior: it wasn't removed then out of an abundance of caution, mostly iirc?
07:59 < laanwj> if you also want to subscribe to relays it gets more complicated quickly and it makes sense to use a binding for the rust crate (it's available for python at least)
08:00 < sdaftuar> darosior: that's not quite true, because an adversary can feed you the honest chain during pre-sync, and then a bogus one during redownload
08:00 < sdaftuar> darosior: so you'd detect it quickly and disconnect but be left with headers that are possibly checkpoint-violating (if your node isn't enforcing checkpoints)
08:01 < darosior> ha! thanks. Glad i asked
08:03 < _aj_> sdaftuar: doesn't headerssync fail to pass through headers that don't match presync with high probability?
08:04 < sdaftuar> _aj_: i thought it was like ~4 bits per 2000 headers that you had to match?
08:04 < sdaftuar> oh times 5 or something
08:05  * sdaftuar checks
08:06 < _aj_> 24 bits over 14k headers i think?
08:14 < dergoegge> If I'm not mistaken, you wouldn't serve those checkpoint violating headers because they wouldn't pass `PeerManagerImpl::BlockRequestAllowed`? i.e. `pindex->IsValid(BLOCK_VALID_SCRIPTS)` would never be true I think
08:30 -!- preimage [~halosghos@user/halosghost] has joined #bitcoin-core-dev
08:34 < sdaftuar> just chatted offline about this...  i think it should be very expensive for an attacker to put a node in a state where its active chain (ie block tip) violates the checkpoints, because i believe we don't download blocks unless they are part of a headers chain that has minchainwork, and we don't process unrequested blocks that are below minchainwork
08:35 < sdaftuar> since we respond to getheaders requests by looking at our active chain (ie the most-work chain based on what blocks we have, not what's in our overall headers tree), i think it ought to be "safe" to remove that check...
08:35 < sdaftuar> however, i dont' think the check costs us much either?
08:39 < Sjors[m]> dergoegge: the BlockRequestAllowed check only happens if there's no locator. IIUC a typical bootstrapping node will start by sending us a GETHEADERS message with the locator pointing to the genesis block.
08:40 < dergoegge> but then you serve from the active chain anyway
08:41 < dergoegge> which won't be the checkpoint violating one
08:41 < Sjors[m]> Right, we construct our reply by iterating ActiveChain().Next
08:42 < Sjors[m]> It still seems a bit indirect to rely on the assumption that we don't download and verify blocks until min chainwork is reached.
08:44 < Sjors[m]> The check indeed seems dirt cheap: m_chainman.ActiveTip()->nChainWork < m_chainman.MinimumChainWork()
08:49 -!- jespada [~jespada@2800:a4:31:b00:a974:16da:8c45:e3b4] has joined #bitcoin-core-dev
08:55 -!- Guest42 [~Guest42@2600:4808:53d6:d400:f5cc:e832:5f2e:dad3] has joined #bitcoin-core-dev
09:00 -!- Guest42 [~Guest42@2600:4808:53d6:d400:f5cc:e832:5f2e:dad3] has quit [Quit: Client closed]
09:04 -!- lattice [~halosghos@user/halosghost] has joined #bitcoin-core-dev
09:05 -!- preimage [~halosghos@user/halosghost] has quit [Ping timeout: 245 seconds]
09:10 -!- Guest55 [~Guest55@2600:4041:7b2e:f700:c20a:3f6d:6c5e:4302] has left #bitcoin-core-dev []
09:22 -!- tstearns [~tstearns@partridge.tstearns.net] has joined #bitcoin-core-dev
09:23 -!- bugs_ [~bugs@user/bugs/x-5128603] has joined #bitcoin-core-dev
09:27 -!- fmenezes [~fmenezes@2a09:bac0:1000:419::15:40a] has joined #bitcoin-core-dev
09:40 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
09:49 -!- vasild [~vd@user/vasild] has quit [Ping timeout: 264 seconds]
09:51 -!- fmenezes [~fmenezes@2a09:bac0:1000:419::15:40a] has quit [Quit: Client closed]
09:59 < darosior> Re turning on PCP by default, how much should we be concerned about potential bandwidth cost to users of default Bitcoin Core? Do we have stats of average cost of running a listening node? Has this been a concerned raised in the past back when UPnP was enabled by default?
10:14 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Remote host closed the connection]
10:16 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
10:20 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 252 seconds]
10:20 -!- yonson [sid663712@id-663712.helmsley.irccloud.com] has joined #bitcoin-core-dev
10:20 -!- jespada [~jespada@2800:a4:31:b00:a974:16da:8c45:e3b4] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
10:23 -!- kevkevin [~kevkevin@142.147.59.145] has joined #bitcoin-core-dev
10:28 -!- kevkevin [~kevkevin@142.147.59.145] has quit [Ping timeout: 246 seconds]
10:31 -!- kevkevin [~kevkevin@142.147.59.145] has joined #bitcoin-core-dev
10:31 -!- pyth [~pyth@123.25.162.204] has quit [Ping timeout: 260 seconds]
10:31 -!- pyth [~pyth@94.131.10.128] has joined #bitcoin-core-dev
10:35 -!- vasild [~vd@user/vasild] has joined #bitcoin-core-dev
10:45 -!- pyth [~pyth@94.131.10.128] has quit [Ping timeout: 252 seconds]
10:46 < bitcoin-git> [bitcoin] maflcko opened pull request #31655:  refactor: Avoid UB in SHA3_256::Write  (master...2501-less-ub) https://github.com/bitcoin/bitcoin/pull/31655
10:46 -!- pyth [~pyth@123.25.162.204] has joined #bitcoin-core-dev
10:57 -!- Cory64 [~Cory64@user/pasha] has quit [Quit: Client closed]
10:58 -!- Cory64 [~Cory64@user/pasha] has joined #bitcoin-core-dev
11:11 < bitcoin-git> [leveldb-subtree] maflcko opened pull request #46: Fix invalid pointer arithmetic in Hash (#1222) (bitcoin-fork...2501-less-ub-hash) https://github.com/bitcoin-core/leveldb-subtree/pull/46
11:15 -!- kevkevin [~kevkevin@142.147.59.145] has quit [Remote host closed the connection]
11:17 -!- jespada [~jespada@2800:a4:31:b00:a974:16da:8c45:e3b4] has joined #bitcoin-core-dev
11:21 -!- jespada [~jespada@2800:a4:31:b00:a974:16da:8c45:e3b4] has quit [Client Quit]
11:25 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
11:26 < bitcoin-git> [bitcoin] yancyribbens opened pull request #31656: test: Add expected result assertions (master...add-expected-results-to-coin-grinder-tests) https://github.com/bitcoin/bitcoin/pull/31656
11:48 -!- mudsip [~mudsip@user/mudsip] has joined #bitcoin-core-dev
11:54 -!- mudsip [~mudsip@user/mudsip] has quit []
11:56 -!- Cory64 [~Cory64@user/pasha] has quit [Quit: Client closed]
11:56 -!- Cory64 [~Cory64@user/pasha] has joined #bitcoin-core-dev
12:00 < laanwj> darosior arguably they'd already be running a listening node but it's not connectable due to their router; if listening is disabled, so will the port mapping. But yes, maybe one of the initial GUI questions should be whether to enable listening. On the other hand i doubt people concerned about bandwidth run bitcoin core at all
12:00 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:01 < laanwj> it's true that bandwidth requirements were lower when UPnP was default enabled, as the block chain wasn't that big yet
12:04 < laanwj> but that was never the reason to disable it, or afaik even discussed at the time, the only reason was miniupnp's insecurity
12:05 < darosior> Yes i don't expect bandwidth to be a big concern, but it depends on the load and i have no idea what it is today for a listening node
12:06 < bugs_> as more people leave the cities for the countryside more will become bandwidth concerned :-)
12:06 < sipa> do we have statistics for total up/down network volume somewhere?
12:07 < laanwj> if the bandwidth use is too large it shouldnt be dependent on enabling port forwarding, people running bitcoin core on computers with a public IP could just as well run into trouble because of bandwidth
12:07 < laanwj> i just think it's seperate concerns
12:08 -!- Guest89 [~Guest89@151.33.38.87] has joined #bitcoin-core-dev
12:09 < lightlike> seems like the potential bandwidth increase should be mentioned in the release notes. There are probably a number of nodes are currently implicitly listen-only (they know they are not reachable and therefore don't bother to set listen=0 even though they want it)  - these would need to change their configuration.
12:09 < laanwj> if you're concerned about bandwidth of incoming connections you should disable listening, not disable port forwarding
12:10 < laanwj> sure, enabling it by default would need to be mentioned in the release notes 
12:10 < sipa> or enable the maxuploadtarget functionalityu
12:10 < laanwj> exactly
12:11 < sipa> absolutely worth mentioning in the release notes, but also, we cannot really predict to what extent people might be impacted by this
12:11 < sipa> and no way to obtain data about it except trying it
12:16 < laanwj> it might also be that having more connectable nodes reduces the bandwidth requirements for each one, as the load is spread out more; new nodes need to sync from somewhere, after all
12:18 < laanwj> at least, if they're not all pruning nodes :)
12:18 < darosior> Yes, if IBD nodes choose peers to download from randomly. The other reasonable thing for an IBD node to do would be to download from faster peers, which are most likely those in a datacenter and not the ones listening behind a router at home, so it wouldn't impact those.
12:19 < laanwj> would you want to prefer nodes in datacenters? one of the reasons to do this in the first place is to be less dependent on the large datacenters
12:19 < sipa> for IBD, i don't think it matters much
12:19 < laanwj> right, sure
12:19 < darosior> I was just trying to come up with reasons not to enable PCP by default besides the increased attack surface. I agree users concerned about bandwidth should leverage the bandwidth reduction options. It also seems unlikely that a user would 1) be concerned about bandwidth 2) be indirectly relying on its firewall instead of -listen=0 3) would see a
12:19 < darosior> massive increase of his bandwidth usage.
12:19 < sipa> for steady state, i think having a large decentralized corpus of reachable nodes is ideal
12:19 < darosior> Yes, also for headers
12:20 < sipa> it's also possible that there are just a ton of PCP-reachable nodes on crappy internet, and having those join the set of reachable nodes makes the IBD experience worse for new nodes (which could potentially be mitigated by improved IBD block-fetching logic)
12:21 < darosior> But for downloading the bulk of the chain i think it'd be fine from the point of view of the IBDing node to choose to download from the fastest peers (us implementing that by default in Bitcoin Core might have undesirable effects though..)
12:21 < sipa> darosior: the stall-detection effectively functions as a weak "download from fastest peers" mechanism
12:23 < lightlike> I'm not sure if nodes should be too aggressive with peer selection during IBD, actively dropping all but the fastest peers. There is some benefit to distribute bandwidth / costs over the entire network, even if IBD is a bit slower for the individual node.
12:24 -!- Guest89 [~Guest89@151.33.38.87] has quit [Quit: Client closed]
12:24 -!- ciaox [~ciaox@151.33.38.87] has joined #bitcoin-core-dev
12:25 < laanwj> i don't think IBD is limited by download speed for most users, but by validation speed, which is limited by CPU and database disk i/o, picking fast peers makes sense but not necessarily the fastest possible ones
12:26 -!- Cory64 [~Cory64@user/pasha] has quit [Quit: Client closed]
12:26 -!- Cory64 [~Cory64@user/pasha] has joined #bitcoin-core-dev
12:28 -!- ciaox [~ciaox@user/ciaox] has changed host
12:29 < ciaox> I agree with that. I think for most users, IBD bottlenecks more on validation speed rather than download speed—CPU and disk I/O seem to be the main culprits. So while picking fast peers is important, it doesn’t necessarily have to be the absolute fastest. A balance between speed and reliability would probably be more effective without
12:29 < ciaox> overwhelming the system.
12:38 -!- ciaox [~ciaox@user/ciaox] has quit [Quit: Client closed]
13:01 < bitcoin-git> [bitcoin] glozow pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/35bf426e0221...7cd862aab94f
13:02 < bitcoin-git> bitcoin/master 6b3f6ea Vasil Dimov: test: avoid generating non-loopback traffic from p2p_seednode.py
13:02 < bitcoin-git> bitcoin/master a5746dc Vasil Dimov: test: avoid generating non-loopback traffic from feature_config_args.py
13:02 < bitcoin-git> bitcoin/master 2ed161c Vasil Dimov: test: avoid generating non-loopback traffic from p2p_dns_seeds.py
13:02 < bitcoin-git> [bitcoin] glozow merged pull request #31646: test: avoid internet traffic (master...test_avoid_internet_traffic) https://github.com/bitcoin/bitcoin/pull/31646
13:06 < bitcoin-git> [bitcoin] glozow pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/7cd862aab94f...e7c479495509
13:06 < bitcoin-git> bitcoin/master bb5f76e Ava Chow: doc: Archive 28.1 release notes
13:06 < bitcoin-git> bitcoin/master e7c4794 glozow: Merge bitcoin/bitcoin#31630: doc: Archive 28.1 release notes
13:06 < bitcoin-git> [bitcoin] glozow merged pull request #31630: doc: Archive 28.1 release notes (master...archive-28.1) https://github.com/bitcoin/bitcoin/pull/31630
13:43 -!- qwerty_qwer [~qwerty_qw@2405:201:c030:28a9:b19e:fe7e:f848:6ae6] has joined #bitcoin-core-dev
14:03 -!- qwerty_qwer [~qwerty_qw@2405:201:c030:28a9:b19e:fe7e:f848:6ae6] has quit [Quit: Client closed]
14:11 -!- lattice [~halosghos@user/halosghost] has quit [Quit: WeeChat 4.5.1]
14:21 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Remote host closed the connection]
14:26 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
14:29 -!- NakedKing [~NakedKing@user/nakedking] has quit [Quit: Leaving]
14:33 -!- bugs_ [~bugs@user/bugs/x-5128603] has quit [Quit: Leaving]
14:58 -!- TheRec [~toto@user/therec] has quit []
15:17 < bitcoin-git> [bitcoin] davidgumberg opened pull request #31657: ci: Supply `--platform` argument to `docker build`. (master...1-13-24-ci-fix) https://github.com/bitcoin/bitcoin/pull/31657
15:18 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has quit [Quit: Connection closed for inactivity]
15:32 -!- jamesob1566 [~jamesob@pool-108-44-244-107.clppva.fios.verizon.net] has quit [Read error: Connection reset by peer]
15:32 -!- jamesob15662 [~jamesob@pool-173-72-206-213.clppva.fios.verizon.net] has joined #bitcoin-core-dev
16:13 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Remote host closed the connection]
16:23 -!- Cory64 [~Cory64@user/pasha] has quit [Quit: Client closed]
16:23 -!- Cory64 [~Cory64@user/pasha] has joined #bitcoin-core-dev
16:29 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
16:54 -!- Cory64 [~Cory64@user/pasha] has quit [Quit: Client closed]
16:54 -!- Cory64 [~Cory64@user/pasha] has joined #bitcoin-core-dev
17:23 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Remote host closed the connection]
17:25 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
17:29 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 244 seconds]
17:42 -!- TheRec [~toto@user/therec] has joined #bitcoin-core-dev
17:46 -!- mudsip [~mudsip@user/mudsip] has joined #bitcoin-core-dev
17:47 -!- mudsip [~mudsip@user/mudsip] has quit [Client Quit]
18:44 -!- Guest69 [~Guest69@47.236.76.208] has joined #bitcoin-core-dev
18:44 -!- Guest69 [~Guest69@47.236.76.208] has quit [Client Quit]
19:03 -!- mudsip [~mudsip@user/mudsip] has joined #bitcoin-core-dev
19:04 -!- mudsip [~mudsip@user/mudsip] has quit [Client Quit]
19:06 < bitcoin-git> [bitcoin] theStack opened pull request #31658: test: p2p: fix sending of manual INVs in tx download test (master...202501-test-p2p-fix_inv_block_subtest) https://github.com/bitcoin/bitcoin/pull/31658
19:11 -!- zeropoint [~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net] has quit [Quit: leaving]
19:43 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
20:02 < bitcoin-git> [bitcoin] manlovepang opened pull request #31659: 1 (master...master) https://github.com/bitcoin/bitcoin/pull/31659
20:04 < bitcoin-git> [bitcoin] manlovepang closed pull request #31659: 1 (master...master) https://github.com/bitcoin/bitcoin/pull/31659
20:05 < bitcoin-git> [bitcoin] manlovepang reopened pull request #31659: 1 (master...master) https://github.com/bitcoin/bitcoin/pull/31659
20:08 -!- eval-exec [~Thunderbi@45.78.56.68.16clouds.com] has quit [Ping timeout: 248 seconds]
20:45 -!- szarka [~szarka@50.186.234.14] has quit [Quit: Leaving]
20:59 < bitcoin-git> [bitcoincore.org] azuchi opened pull request #1101: Add japanese translation for 28.1 (master...ja-translate-28.1) https://github.com/bitcoin-core/bitcoincore.org/pull/1101
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:14 -!- eval-exec [~Thunderbi@212.87.193.115] has joined #bitcoin-core-dev
21:19 -!- eval-exec [~Thunderbi@212.87.193.115] has quit [Remote host closed the connection]
21:19 -!- eval-exec [~Thunderbi@45.78.56.68.16clouds.com] has joined #bitcoin-core-dev
21:24 -!- jamesob1566 [~jamesob@pool-108-44-203-156.clppva.fios.verizon.net] has joined #bitcoin-core-dev
21:27 -!- jamesob15662 [~jamesob@pool-173-72-206-213.clppva.fios.verizon.net] has quit [Ping timeout: 265 seconds]
21:49 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has quit [Read error: Connection reset by peer]
21:49 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has joined #bitcoin-core-dev
22:01 -!- emcy__ [~emcy@148.252.146.142] has joined #bitcoin-core-dev
22:01 -!- mcey_ [~emcy@148.252.146.142] has quit [Remote host closed the connection]
22:34 -!- jamesob15660 [~jamesob@pool-108-44-203-145.clppva.fios.verizon.net] has joined #bitcoin-core-dev
22:36 -!- jamesob1566 [~jamesob@pool-108-44-203-156.clppva.fios.verizon.net] has quit [Ping timeout: 252 seconds]
22:36 -!- jamesob15660 is now known as jamesob1566
23:11 -!- cfields [~cfields@user/cfields] has quit [Ping timeout: 252 seconds]
23:12 -!- cfields [~cfields@user/cfields] has joined #bitcoin-core-dev
23:26 -!- qwerty_qwer [~qwerty_qw@2405:201:c030:28a9:20a5:add8:3f8e:d439] has joined #bitcoin-core-dev
23:31 < bitcoin-git> [bitcoin] fanquake closed pull request #31659: 1 (master...master) https://github.com/bitcoin/bitcoin/pull/31659
23:56 -!- dviola [~diego@user/dviola] has quit [Quit: WeeChat 4.5.1]
--- Log closed Wed Jan 15 00:00:49 2025