12025-01-14T00:07:24 *** mcey_ <mcey_!~emcy@148.252.146.142> has quit IRC (Remote host closed the connection)
22025-01-14T00:07:58 *** mcey <mcey!~emcy@148.252.146.142> has joined #bitcoin-core-dev
32025-01-14T00:08:19 *** mcey <mcey!~emcy@148.252.146.142> has quit IRC (Remote host closed the connection)
42025-01-14T00:08:43 *** mcey <mcey!~emcy@148.252.146.142> has joined #bitcoin-core-dev
52025-01-14T01:23:10 *** Earnestly <Earnestly!~earnest@user/earnestly> has quit IRC (Read error: Connection reset by peer)
62025-01-14T02:48:08 *** zeropoint <zeropoint!~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net> has quit IRC (Quit: leaving)
72025-01-14T03:05:28 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Remote host closed the connection)
82025-01-14T03:10:01 *** mcey <mcey!~emcy@148.252.146.142> has quit IRC (*.net *.split)
92025-01-14T03:10:03 *** TallTim <TallTim!~talltim@165-23-61-81-dynamic.midco.net> has quit IRC (*.net *.split)
102025-01-14T03:14:56 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
112025-01-14T03:15:03 *** mcey <mcey!~emcy@148.252.146.142> has joined #bitcoin-core-dev
122025-01-14T03:15:04 *** TallTim <TallTim!~talltim@165-23-61-81-dynamic.midco.net> has joined #bitcoin-core-dev
132025-01-14T03:19:34 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 245 seconds)
142025-01-14T03:38:31 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
152025-01-14T03:44:04 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 252 seconds)
162025-01-14T03:57:19 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
172025-01-14T04:00:01 *** tdb3 <tdb3!~tdb3@ip74-208-205-30.pbiaas.com> has quit IRC ()
182025-01-14T04:00:38 *** tdb3 <tdb3!~tdb3@ip74-208-205-30.pbiaas.com> has joined #bitcoin-core-dev
192025-01-14T04:08:45 *** eval-exec <eval-exec!~Thunderbi@45.78.56.68.16clouds.com> has quit IRC (Ping timeout: 260 seconds)
202025-01-14T04:19:57 *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has joined #bitcoin-core-dev
212025-01-14T05:01:01 *** cmirror <cmirror!~cmirror@4.53.92.114> has quit IRC (Remote host closed the connection)
222025-01-14T05:01:32 *** cmirror <cmirror!~cmirror@4.53.92.114> has joined #bitcoin-core-dev
232025-01-14T05:03:01 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 252 seconds)
242025-01-14T05:16:03 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
252025-01-14T05:40:17 *** eval-exec <eval-exec!~Thunderbi@45.78.56.68.16clouds.com> has joined #bitcoin-core-dev
262025-01-14T06:01:23 *** mcey_ <mcey_!~emcy@148.252.146.142> has joined #bitcoin-core-dev
272025-01-14T06:01:38 *** mcey <mcey!~emcy@148.252.146.142> has quit IRC (Remote host closed the connection)
282025-01-14T06:19:28 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 252 seconds)
292025-01-14T06:34:44 <achow101> #proposedmeetingtopic new meeting time
302025-01-14T06:35:38 <achow101> Reminder that the poll for the irc meeting time is still ongoing. please vote if you attend the meetings. https://app.rallly.co/invite/k0zyyk2uD3ug
312025-01-14T06:43:55 *** S3RK_ <S3RK_!~S3RK@user/s3rk> has quit IRC (Ping timeout: 244 seconds)
322025-01-14T06:47:33 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
332025-01-14T06:56:00 *** S3RK <S3RK!~S3RK@user/s3rk> has joined #bitcoin-core-dev
342025-01-14T07:30:31 *** Guest36 <Guest36!~Guest36@2405:201:c030:28a9:b19e:fe7e:f848:6ae6> has joined #bitcoin-core-dev
352025-01-14T07:41:22 *** Guest0 <Guest0!~Guest0@137.132.26.92> has joined #bitcoin-core-dev
362025-01-14T07:52:55 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 272 seconds)
372025-01-14T07:56:00 *** Guest0 <Guest0!~Guest0@137.132.26.92> has quit IRC (Quit: Client closed)
382025-01-14T08:04:31 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
392025-01-14T08:18:05 *** Guest63 <Guest63!~Guest63@2601:c4:100:7190:9de5:1aa2:3d6e:ce2> has joined #bitcoin-core-dev
402025-01-14T08:26:44 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 244 seconds)
412025-01-14T08:43:44 *** adil <adil!~Thunderbi@2402:d000:8134:d89:4d79:d6d:6578:5292> has joined #bitcoin-core-dev
422025-01-14T08:54:12 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
432025-01-14T09:08:20 *** Guest64 <Guest64!~Guest64@2409:40c1:3030:87e:1ce4:56bc:bbb2:e8ba> has joined #bitcoin-core-dev
442025-01-14T09:08:52 *** Guest64 <Guest64!~Guest64@2409:40c1:3030:87e:1ce4:56bc:bbb2:e8ba> has quit IRC (Client Quit)
452025-01-14T09:13:32 *** jonatack <jonatack!~jonatack@user/jonatack> has quit IRC (Read error: Connection reset by peer)
462025-01-14T09:19:58 *** jespada <jespada!~jespada@2800:a4:31:b00:a974:16da:8c45:e3b4> has joined #bitcoin-core-dev
472025-01-14T09:20:33 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 246 seconds)
482025-01-14T09:24:51 *** Guyver2 <Guyver2!~Guyver@77-174-98-73.fixed.kpn.net> has joined #bitcoin-core-dev
492025-01-14T09:48:12 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
502025-01-14T10:01:18 <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
512025-01-14T10:02:22 *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
522025-01-14T10:15:40 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 252 seconds)
532025-01-14T10:21:08 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
542025-01-14T10:25:47 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 244 seconds)
552025-01-14T10:26:24 *** Earnestly <Earnestly!~earnest@user/earnestly> has joined #bitcoin-core-dev
562025-01-14T10:29:09 *** adil <adil!~Thunderbi@2402:d000:8134:d89:4d79:d6d:6578:5292> has quit IRC (Quit: adil)
572025-01-14T10:35:05 *** jespada <jespada!~jespada@2800:a4:31:b00:a974:16da:8c45:e3b4> has quit IRC (Quit: My Mac has gone to sleep. ZZZzzzâ¦)
582025-01-14T10:39:49 *** Victor_sueca <Victor_sueca!~Victorsue@user/victorsueca> has quit IRC (Ping timeout: 248 seconds)
592025-01-14T10:40:45 *** eval-exec <eval-exec!~Thunderbi@45.78.56.68.16clouds.com> has quit IRC (Ping timeout: 260 seconds)
602025-01-14T10:40:49 *** Guest36 <Guest36!~Guest36@2405:201:c030:28a9:b19e:fe7e:f848:6ae6> has quit IRC (Quit: Client closed)
612025-01-14T10:40:49 *** Guyver2 <Guyver2!~Guyver@77-174-98-73.fixed.kpn.net> has left #bitcoin-core-dev (Closing Window)
622025-01-14T10:41:48 *** Victor_sueca <Victor_sueca!~Victorsue@user/victorsueca> has joined #bitcoin-core-dev
632025-01-14T10:42:38 *** epic33 <epic33!~epic@117.250.76.237> has joined #bitcoin-core-dev
642025-01-14T10:42:51 *** epic33 <epic33!~epic@117.250.76.237> has quit IRC (Client Quit)
652025-01-14T10:43:16 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
662025-01-14T10:47:29 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 245 seconds)
672025-01-14T11:01:30 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
682025-01-14T11:08:13 *** NakedKing <NakedKing!~NakedKing@user/nakedking> has joined #bitcoin-core-dev
692025-01-14T11:10:26 <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
702025-01-14T11:11:43 <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
712025-01-14T11:12:06 *** adil <adil!~Thunderbi@2402:d000:8134:d89:4d79:d6d:6578:5292> has joined #bitcoin-core-dev
722025-01-14T11:17:28 *** Guest79 <Guest79!~Guest63@45.89.52.66> has joined #bitcoin-core-dev
732025-01-14T11:22:28 *** Cory64 <Cory64!~Cory64@user/pasha> has quit IRC (Quit: Client closed)
742025-01-14T11:22:46 *** Cory64 <Cory64!~Cory64@user/pasha> has joined #bitcoin-core-dev
752025-01-14T11:31:41 *** adil <adil!~Thunderbi@2402:d000:8134:d89:4d79:d6d:6578:5292> has quit IRC (Quit: adil)
762025-01-14T11:32:01 *** adil <adil!~Thunderbi@2402:d000:8134:d89:4d79:d6d:6578:5292> has joined #bitcoin-core-dev
772025-01-14T11:33:32 *** jespada <jespada!~jespada@2800:a4:31:b00:a974:16da:8c45:e3b4> has joined #bitcoin-core-dev
782025-01-14T11:48:31 *** adil <adil!~Thunderbi@2402:d000:8134:d89:4d79:d6d:6578:5292> has quit IRC (Quit: adil)
792025-01-14T11:48:50 *** adil <adil!~Thunderbi@2402:d000:8134:d89:4d79:d6d:6578:5292> has joined #bitcoin-core-dev
802025-01-14T11:53:11 *** adil <adil!~Thunderbi@2402:d000:8134:d89:4d79:d6d:6578:5292> has quit IRC (Ping timeout: 252 seconds)
812025-01-14T12:30:37 *** eval-exec <eval-exec!~Thunderbi@45.78.56.68.16clouds.com> has joined #bitcoin-core-dev
822025-01-14T12:31:03 <bitcoin-git> [bitcoin] Mohammed-Alanazisa opened pull request #31652: Create devcontainer.json (master...patch-1) https://github.com/bitcoin/bitcoin/pull/31652
832025-01-14T12:31:47 <bitcoin-git> [bitcoin] hebasto closed pull request #31652: Create devcontainer.json (master...patch-1) https://github.com/bitcoin/bitcoin/pull/31652
842025-01-14T12:38:38 *** conman <conman!~con@180-150-21-3.b49615.mel.static.aussiebb.net> has joined #bitcoin-core-dev
852025-01-14T13:02:38 *** Cory64 <Cory64!~Cory64@user/pasha> has quit IRC (Quit: Client closed)
862025-01-14T13:02:55 *** Cory64 <Cory64!~Cory64@user/pasha> has joined #bitcoin-core-dev
872025-01-14T13:22:57 *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has quit IRC (Quit: = "")
882025-01-14T13:33:16 *** Guest63 <Guest63!~Guest63@2601:c4:100:7190:9de5:1aa2:3d6e:ce2> has quit IRC (Quit: Client closed)
892025-01-14T13:40:07 *** Guest79 <Guest79!~Guest63@45.89.52.66> has quit IRC (Quit: Client closed)
902025-01-14T13:59:23 <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
912025-01-14T14:06:56 *** Victor_sueca <Victor_sueca!~Victorsue@user/victorsueca> has quit IRC (Quit: Gone frying asparagus or my Windows had a BSOD)
922025-01-14T14:15:42 *** Victor_sueca <Victor_sueca!~Victorsue@user/victorsueca> has joined #bitcoin-core-dev
932025-01-14T14:16:35 *** pyth <pyth!~pyth@113.184.143.105> has quit IRC (Ping timeout: 260 seconds)
942025-01-14T14:16:58 *** pyth <pyth!~pyth@123.25.162.204> has joined #bitcoin-core-dev
952025-01-14T14:23:32 *** zeropoint <zeropoint!~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net> has joined #bitcoin-core-dev
962025-01-14T14:24:48 <sipa> NakedKing: that sounds unrelated to bitcoin core
972025-01-14T14:37:51 *** Guest55 <Guest55!~Guest55@2600:4041:7b2e:f700:c20a:3f6d:6c5e:4302> has joined #bitcoin-core-dev
982025-01-14T15:30:45 <bitcoin-git> [bitcoincore.org] glozow pushed 2 commits to master: https://github.com/bitcoin-core/bitcoincore.org/compare/f1d9b75ccd6e...c86c62e68897
992025-01-14T15:30:45 <bitcoin-git> bitcoincore.org/master c31e71d Ava Chow: 28.1 release post and notes
1002025-01-14T15:30:46 <bitcoin-git> bitcoincore.org/master c86c62e glozow: Merge bitcoin-core/bitcoincore.org#1100: Bitcoin Core 28.1
1012025-01-14T15:30:46 <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
1022025-01-14T15:31:59 <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.
1032025-01-14T15:32:54 <sipa> good idea
1042025-01-14T15:33:07 <laanwj> yes, agree
1052025-01-14T15:33:47 <sipa> also, how do we feel about making it on by default?
1062025-01-14T15:33:59 <sipa> maybe not for 29.x, but it'd be nice if we could get there
1072025-01-14T15:38:24 <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.
1082025-01-14T15:39:37 <sipa> right
1092025-01-14T15:39:51 <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.
1102025-01-14T15:41:37 <sipa> darosior: did it actually use PCP, or fall back to NAT-PMP?
1112025-01-14T15:42:34 <darosior> I assumed it used PCP because i saw no log of falling back to NAT-PMP whatsoever
1122025-01-14T15:44:57 <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
1132025-01-14T15:45:02 <dergoegge> https://github.com/dergoegge/bitcoin/commit/cc3906989229637da034e3324cb4a93367136f03
1142025-01-14T15:45:02 <dergoegge> could be a starting point, never polished it...
1152025-01-14T15:45:47 <darosior> I'll look into it, reviewed the unit test PR yesterday so it's still fresh in my mind
1162025-01-14T15:46:03 <laanwj> thanks!
1172025-01-14T15:46:49 <_aj_> laanwj: hey, you've automated nostr stuff, right? are there any tools/libs you can recommend?
1182025-01-14T15:51:53 <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
1192025-01-14T15:55:20 <_aj_> laanwj: hmm, copying your handrolled code sounds more appealing than making/resurrecting my own at least
1202025-01-14T15:56:30 <_aj_> laanwj: though i guess yours is write only, and doesn't subscribe to anything?
1212025-01-14T15:58:21 <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
1222025-01-14T15:58:21 <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
1232025-01-14T15:58:21 <darosior> itself? Any reason to keep it we'd be missing?
1242025-01-14T15:58:30 <laanwj> _aj_: correct, it's write-only, that's the only thing i've ever needed to automate
1252025-01-14T15:58:57 *** jespada <jespada!~jespada@2800:a4:31:b00:a974:16da:8c45:e3b4> has quit IRC (Quit: My Mac has gone to sleep. ZZZzzzâ¦)
1262025-01-14T15:59:38 <_aj_> darosior: it wasn't removed then out of an abundance of caution, mostly iirc?
1272025-01-14T15:59:41 <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)
1282025-01-14T16:00:18 <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
1292025-01-14T16:00:37 <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)
1302025-01-14T16:01:02 <darosior> ha! thanks. Glad i asked
1312025-01-14T16:03:40 <_aj_> sdaftuar: doesn't headerssync fail to pass through headers that don't match presync with high probability?
1322025-01-14T16:04:26 <sdaftuar> _aj_: i thought it was like ~4 bits per 2000 headers that you had to match?
1332025-01-14T16:04:39 <sdaftuar> oh times 5 or something
1342025-01-14T16:05:11 * sdaftuar checks
1352025-01-14T16:06:53 <_aj_> 24 bits over 14k headers i think?
1362025-01-14T16:14: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
1372025-01-14T16:30:09 *** preimage <preimage!~halosghos@user/halosghost> has joined #bitcoin-core-dev
1382025-01-14T16:34:09 <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
1392025-01-14T16:35:15 <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...
1402025-01-14T16:35:55 <sdaftuar> however, i dont' think the check costs us much either?
1412025-01-14T16:39:40 <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.
1422025-01-14T16:40:54 <dergoegge> but then you serve from the active chain anyway
1432025-01-14T16:41:13 <dergoegge> which won't be the checkpoint violating one
1442025-01-14T16:41:41 <Sjors[m]> Right, we construct our reply by iterating ActiveChain().Next
1452025-01-14T16:42:28 <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.
1462025-01-14T16:44:14 <Sjors[m]> The check indeed seems dirt cheap: m_chainman.ActiveTip()->nChainWork < m_chainman.MinimumChainWork()
1472025-01-14T16:49:17 *** jespada <jespada!~jespada@2800:a4:31:b00:a974:16da:8c45:e3b4> has joined #bitcoin-core-dev
1482025-01-14T16:55:05 *** Guest42 <Guest42!~Guest42@2600:4808:53d6:d400:f5cc:e832:5f2e:dad3> has joined #bitcoin-core-dev
1492025-01-14T17:00:16 *** Guest42 <Guest42!~Guest42@2600:4808:53d6:d400:f5cc:e832:5f2e:dad3> has quit IRC (Quit: Client closed)
1502025-01-14T17:04:09 *** lattice <lattice!~halosghos@user/halosghost> has joined #bitcoin-core-dev
1512025-01-14T17:05:49 *** preimage <preimage!~halosghos@user/halosghost> has quit IRC (Ping timeout: 245 seconds)
1522025-01-14T17:10:09 *** Guest55 <Guest55!~Guest55@2600:4041:7b2e:f700:c20a:3f6d:6c5e:4302> has left #bitcoin-core-dev
1532025-01-14T17:22:51 *** tstearns <tstearns!~tstearns@partridge.tstearns.net> has joined #bitcoin-core-dev
1542025-01-14T17:23:11 *** bugs_ <bugs_!~bugs@user/bugs/x-5128603> has joined #bitcoin-core-dev
1552025-01-14T17:27:10 *** fmenezes <fmenezes!~fmenezes@2a09:bac0:1000:419::15:40a> has joined #bitcoin-core-dev
1562025-01-14T17:40:11 *** Talkless <Talkless!~Talkless@mail.dargis.net> has joined #bitcoin-core-dev
1572025-01-14T17:49:24 *** vasild <vasild!~vd@user/vasild> has quit IRC (Ping timeout: 264 seconds)
1582025-01-14T17:51:34 *** fmenezes <fmenezes!~fmenezes@2a09:bac0:1000:419::15:40a> has quit IRC (Quit: Client closed)
1592025-01-14T17:59:44 <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?
1602025-01-14T18:14:33 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Remote host closed the connection)
1612025-01-14T18:16:04 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
1622025-01-14T18:20:24 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 252 seconds)
1632025-01-14T18:20:26 *** yonson <yonson!sid663712@id-663712.helmsley.irccloud.com> has joined #bitcoin-core-dev
1642025-01-14T18:20:34 *** jespada <jespada!~jespada@2800:a4:31:b00:a974:16da:8c45:e3b4> has quit IRC (Quit: My Mac has gone to sleep. ZZZzzzâ¦)
1652025-01-14T18:23:51 *** kevkevin <kevkevin!~kevkevin@142.147.59.145> has joined #bitcoin-core-dev
1662025-01-14T18:28:18 *** kevkevin <kevkevin!~kevkevin@142.147.59.145> has quit IRC (Ping timeout: 246 seconds)
1672025-01-14T18:31:06 *** kevkevin <kevkevin!~kevkevin@142.147.59.145> has joined #bitcoin-core-dev
1682025-01-14T18:31:30 *** pyth <pyth!~pyth@123.25.162.204> has quit IRC (Ping timeout: 260 seconds)
1692025-01-14T18:31:50 *** pyth <pyth!~pyth@94.131.10.128> has joined #bitcoin-core-dev
1702025-01-14T18:35:12 *** vasild <vasild!~vd@user/vasild> has joined #bitcoin-core-dev
1712025-01-14T18:45:49 *** pyth <pyth!~pyth@94.131.10.128> has quit IRC (Ping timeout: 252 seconds)
1722025-01-14T18:46:11 <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
1732025-01-14T18:46:18 *** pyth <pyth!~pyth@123.25.162.204> has joined #bitcoin-core-dev
1742025-01-14T18:57:52 *** Cory64 <Cory64!~Cory64@user/pasha> has quit IRC (Quit: Client closed)
1752025-01-14T18:58:10 *** Cory64 <Cory64!~Cory64@user/pasha> has joined #bitcoin-core-dev
1762025-01-14T19:11:29 <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
1772025-01-14T19:15:19 *** kevkevin <kevkevin!~kevkevin@142.147.59.145> has quit IRC (Remote host closed the connection)
1782025-01-14T19:17:12 *** jespada <jespada!~jespada@2800:a4:31:b00:a974:16da:8c45:e3b4> has joined #bitcoin-core-dev
1792025-01-14T19:21:11 *** jespada <jespada!~jespada@2800:a4:31:b00:a974:16da:8c45:e3b4> has quit IRC (Client Quit)
1802025-01-14T19:25:00 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
1812025-01-14T19:26:08 <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
1822025-01-14T19:48:21 *** mudsip <mudsip!~mudsip@user/mudsip> has joined #bitcoin-core-dev
1832025-01-14T19:54:18 *** mudsip <mudsip!~mudsip@user/mudsip> has quit IRC ()
1842025-01-14T19:56:00 *** Cory64 <Cory64!~Cory64@user/pasha> has quit IRC (Quit: Client closed)
1852025-01-14T19:56:18 *** Cory64 <Cory64!~Cory64@user/pasha> has joined #bitcoin-core-dev
1862025-01-14T20:00:09 <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
1872025-01-14T20:00:11 *** Talkless <Talkless!~Talkless@mail.dargis.net> has quit IRC (Quit: Konversation terminated!)
1882025-01-14T20:01:43 <laanwj> it's true that bandwidth requirements were lower when UPnP was default enabled, as the block chain wasn't that big yet
1892025-01-14T20:04:24 <laanwj> but that was never the reason to disable it, or afaik even discussed at the time, the only reason was miniupnp's insecurity
1902025-01-14T20:05:22 <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
1912025-01-14T20:06:02 <bugs_> as more people leave the cities for the countryside more will become bandwidth concerned :-)
1922025-01-14T20:06:52 <sipa> do we have statistics for total up/down network volume somewhere?
1932025-01-14T20:07:05 <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
1942025-01-14T20:07:16 <laanwj> i just think it's seperate concerns
1952025-01-14T20:08:49 *** Guest89 <Guest89!~Guest89@151.33.38.87> has joined #bitcoin-core-dev
1962025-01-14T20:09:15 <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.
1972025-01-14T20:09:34 <laanwj> if you're concerned about bandwidth of incoming connections you should disable listening, not disable port forwarding
1982025-01-14T20:10:27 <laanwj> sure, enabling it by default would need to be mentioned in the release notes
1992025-01-14T20:10:37 <sipa> or enable the maxuploadtarget functionalityu
2002025-01-14T20:10:55 <laanwj> exactly
2012025-01-14T20:11:13 <sipa> absolutely worth mentioning in the release notes, but also, we cannot really predict to what extent people might be impacted by this
2022025-01-14T20:11:53 <sipa> and no way to obtain data about it except trying it
2032025-01-14T20:16:15 <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
2042025-01-14T20:18:02 <laanwj> at least, if they're not all pruning nodes :)
2052025-01-14T20:18:13 <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.
2062025-01-14T20:19:01 <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
2072025-01-14T20:19:16 <sipa> for IBD, i don't think it matters much
2082025-01-14T20:19:29 <laanwj> right, sure
2092025-01-14T20:19:29 <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
2102025-01-14T20:19:30 <darosior> massive increase of his bandwidth usage.
2112025-01-14T20:19:39 <sipa> for steady state, i think having a large decentralized corpus of reachable nodes is ideal
2122025-01-14T20:19:58 <darosior> Yes, also for headers
2132025-01-14T20:20:25 <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)
2142025-01-14T20:21:04 <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..)
2152025-01-14T20:21:37 <sipa> darosior: the stall-detection effectively functions as a weak "download from fastest peers" mechanism
2162025-01-14T20:23:25 <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.
2172025-01-14T20:24:19 *** Guest89 <Guest89!~Guest89@151.33.38.87> has quit IRC (Quit: Client closed)
2182025-01-14T20:24:52 *** ciaox <ciaox!~ciaox@151.33.38.87> has joined #bitcoin-core-dev
2192025-01-14T20:25:47 <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
2202025-01-14T20:26:06 *** Cory64 <Cory64!~Cory64@user/pasha> has quit IRC (Quit: Client closed)
2212025-01-14T20:26:21 *** Cory64 <Cory64!~Cory64@user/pasha> has joined #bitcoin-core-dev
2222025-01-14T20:29:13 <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
2232025-01-14T20:29:14 <ciaox> overwhelming the system.
2242025-01-14T20:38:32 *** ciaox <ciaox!~ciaox@user/ciaox> has quit IRC (Quit: Client closed)
2252025-01-14T21:02:00 <bitcoin-git> [bitcoin] glozow pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/35bf426e0221...7cd862aab94f
2262025-01-14T21:02:00 <bitcoin-git> bitcoin/master 6b3f6ea Vasil Dimov: test: avoid generating non-loopback traffic from p2p_seednode.py
2272025-01-14T21:02:01 <bitcoin-git> bitcoin/master a5746dc Vasil Dimov: test: avoid generating non-loopback traffic from feature_config_args.py
2282025-01-14T21:02:01 <bitcoin-git> bitcoin/master 2ed161c Vasil Dimov: test: avoid generating non-loopback traffic from p2p_dns_seeds.py
2292025-01-14T21:02:05 <bitcoin-git> [bitcoin] glozow merged pull request #31646: test: avoid internet traffic (master...test_avoid_internet_traffic) https://github.com/bitcoin/bitcoin/pull/31646
2302025-01-14T21:06:48 <bitcoin-git> [bitcoin] glozow pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/7cd862aab94f...e7c479495509
2312025-01-14T21:06:49 <bitcoin-git> bitcoin/master bb5f76e Ava Chow: doc: Archive 28.1 release notes
2322025-01-14T21:06:49 <bitcoin-git> bitcoin/master e7c4794 glozow: Merge bitcoin/bitcoin#31630: doc: Archive 28.1 release notes
2332025-01-14T21:06:51 <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
2342025-01-14T21:43:58 *** qwerty_qwer <qwerty_qwer!~qwerty_qw@2405:201:c030:28a9:b19e:fe7e:f848:6ae6> has joined #bitcoin-core-dev
2352025-01-14T22:03:52 *** qwerty_qwer <qwerty_qwer!~qwerty_qw@2405:201:c030:28a9:b19e:fe7e:f848:6ae6> has quit IRC (Quit: Client closed)
2362025-01-14T22:11:45 *** lattice <lattice!~halosghos@user/halosghost> has quit IRC (Quit: WeeChat 4.5.1)
2372025-01-14T22:21:26 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Remote host closed the connection)
2382025-01-14T22:26:17 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
2392025-01-14T22:29:37 *** NakedKing <NakedKing!~NakedKing@user/nakedking> has quit IRC (Quit: Leaving)
2402025-01-14T22:33:16 *** bugs_ <bugs_!~bugs@user/bugs/x-5128603> has quit IRC (Quit: Leaving)
2412025-01-14T22:58:03 *** TheRec <TheRec!~toto@user/therec> has quit IRC ()
2422025-01-14T23:17:45 <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
2432025-01-14T23:18:48 *** abubakarsadiq <abubakarsadiq!uid602234@id-602234.hampstead.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)
2442025-01-14T23:32:08 *** jamesob1566 <jamesob1566!~jamesob@pool-108-44-244-107.clppva.fios.verizon.net> has quit IRC (Read error: Connection reset by peer)
2452025-01-14T23:32:15 *** jamesob15662 <jamesob15662!~jamesob@pool-173-72-206-213.clppva.fios.verizon.net> has joined #bitcoin-core-dev