--- Log opened Thu Oct 19 00:00:00 2023
00:03 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081] has quit [Ping timeout: 240 seconds]
00:04 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081] has joined #bitcoin-core-dev
00:09 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081] has quit [Ping timeout: 240 seconds]
00:13 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has joined #bitcoin-core-dev
00:13 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Remote host closed the connection]
00:21 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081] has joined #bitcoin-core-dev
00:26 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081] has quit [Ping timeout: 264 seconds]
00:34 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has joined #bitcoin-core-dev
00:51 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081] has joined #bitcoin-core-dev
00:55 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081] has quit [Ping timeout: 246 seconds]
01:17 -!- ibiko1 [~ibiko1@170.253.45.108] has joined #bitcoin-core-dev
01:20 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
01:21 -!- ibiko1 [~ibiko1@170.253.45.108] has quit [Ping timeout: 272 seconds]
01:24 -!- Guest7 [~Guest7@ip-62-245-75-70.bb.vodafone.cz] has quit [Quit: Client closed]
01:25 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 264 seconds]
01:37 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081] has joined #bitcoin-core-dev
01:42 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081] has quit [Ping timeout: 252 seconds]
01:43 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081] has joined #bitcoin-core-dev
01:48 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/655dc716aa60...f4049eaf08b6
01:48 < bitcoin-git> bitcoin/master fa4c683 MarcoFalke: test: Fix failing time check in rpc_net.py
01:48 < bitcoin-git> bitcoin/master f4049ea fanquake: Merge bitcoin/bitcoin#28671: test: Fix failing time check in rpc_net.py
01:48 < fanquake> Reminder that priority project voting finishes up today, if you haven't voted already
01:48 < bitcoin-git> [bitcoin] fanquake merged pull request #28671: test: Fix failing time check in rpc_net.py (master...2310-test-less-fail-) https://github.com/bitcoin/bitcoin/pull/28671
01:49 < fanquake> #28642
01:49 <@gribble> https://github.com/bitcoin/bitcoin/issues/28642 | Voting on Priority Projects for 27.0 · Issue #28642 · bitcoin/bitcoin · GitHub
01:53 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081] has quit [Ping timeout: 272 seconds]
01:59 < glozow> sdaftuar: \o/
02:07 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/f4049eaf08b6...5eb82d5706ea
02:07 < bitcoin-git> bitcoin/master 8cfa22a fanquake: build: move -fstack-reuse=none to CORE_CXXFLAGS
02:07 < bitcoin-git> bitcoin/master 5eb82d5 fanquake: Merge bitcoin/bitcoin#28672: build: move `-fstack-reuse=none` to CORE_CXXF...
02:07 < bitcoin-git> [bitcoin] fanquake merged pull request #28672: build: move `-fstack-reuse=none` to CORE_CXXFLAGS (master...move_stack_reuse_core_flags) https://github.com/bitcoin/bitcoin/pull/28672
02:20 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081] has joined #bitcoin-core-dev
02:23 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/5eb82d5706ea...091d29c49590
02:23 < bitcoin-git> bitcoin/master 004903e Brandon Odiwuor: test: Add Wallet Unlock Context Manager
02:23 < bitcoin-git> bitcoin/master 091d29c fanquake: Merge bitcoin/bitcoin#28617: test: Add Wallet Unlock Context Manager
02:24 < bitcoin-git> [bitcoin] fanquake merged pull request #28617: test: Add Wallet Unlock Context Manager (master...wallet-unlock-context-manager) https://github.com/bitcoin/bitcoin/pull/28617
02:24 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081] has quit [Ping timeout: 240 seconds]
02:25 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081] has joined #bitcoin-core-dev
02:28 -!- gerle [~quassel@212-186-78-187.static.upcbusiness.at] has joined #bitcoin-core-dev
02:29 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has left #bitcoin-core-dev [Closing Window]
02:30 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081] has quit [Ping timeout: 264 seconds]
02:32 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/091d29c49590...106ab20f121f
02:32 < bitcoin-git> bitcoin/master 2ce7e31 Greg Sanders: docs: Add reference to total.coverage report
02:32 < bitcoin-git> bitcoin/master 106ab20 fanquake: Merge bitcoin/bitcoin#28673: docs: Add reference to total.coverage report
02:32 < bitcoin-git> [bitcoin] fanquake merged pull request #28673: docs: Add reference to total.coverage report (master...cov_docs) https://github.com/bitcoin/bitcoin/pull/28673
02:36 < fanquake> 25.1 binaries are now available: https://bitcoincore.org/bin/bitcoin-core-25.1/
02:36 < fanquake> Website post needs a sanity check: https://github.com/bitcoin-core/bitcoincore.org/pull/991
02:48 -!- TallTim [~talltim@184-83-238-129-dynamic.midco.net] has quit [Remote host closed the connection]
02:48 -!- TallTim [~talltim@184-83-238-129-dynamic.midco.net] has joined #bitcoin-core-dev
02:58 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081] has joined #bitcoin-core-dev
03:02 < bitcoin-git> [bitcoin] fjahr opened pull request #28685: coinstats, asssumeutxo: fix hash_serialized2 calculation (master...2023-10-au-weird-fix) https://github.com/bitcoin/bitcoin/pull/28685
03:03 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081] has quit [Ping timeout: 240 seconds]
03:09 -!- TallTim_ [~talltim@184-83-238-129-dynamic.midco.net] has joined #bitcoin-core-dev
03:09 -!- salvatoshi_ [~salvatosh@103.151.37.100] has joined #bitcoin-core-dev
03:10 -!- salvatoshi [~salvatosh@103.151.37.100] has quit [Read error: Connection reset by peer]
03:12 -!- TallTim [~talltim@184-83-238-129-dynamic.midco.net] has quit [Ping timeout: 255 seconds]
03:23 < bitcoin-git> [bitcoin] ajtowns opened pull request #28686: refactor: Split per-peer parts of net module into new node/node module (master...202310-nodenode) https://github.com/bitcoin/bitcoin/pull/28686
03:27 -!- realies [~realies@user/realies] has quit [Ping timeout: 260 seconds]
03:32 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081] has joined #bitcoin-core-dev
03:33 -!- someone235 [uid419897@id-419897.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
03:37 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081] has quit [Ping timeout: 245 seconds]
03:41 -!- salvatoshi_ [~salvatosh@103.151.37.100] has quit [Ping timeout: 240 seconds]
03:50 -!- flooded [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #bitcoin-core-dev
03:52 -!- vasild_ [~vd@user/vasild] has quit [Quit: leaving]
03:54 -!- test_ [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Ping timeout: 258 seconds]
03:54 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081] has joined #bitcoin-core-dev
04:35 -!- mudsip [~mudsip@user/mudsip] has joined #bitcoin-core-dev
04:35 -!- mudsip [~mudsip@user/mudsip] has quit [Client Quit]
04:47 -!- salvatoshi_ [~salvatosh@103.100.173.166] has joined #bitcoin-core-dev
04:48 -!- salvatoshi_ [~salvatosh@103.100.173.166] has quit [Remote host closed the connection]
05:05 -!- TallTim_ is now known as TallTim
05:19 < fjahr> #proposedmeetingtopic Fix for hash_serialized2 calculation and implications (for context see #28675 and #28685) 
05:19 <@gribble> https://github.com/bitcoin/bitcoin/issues/28675 | Assumeutxo: Altered txoutset dump is still valid · Issue #28675 · bitcoin/bitcoin · GitHub
05:19 <@gribble> https://github.com/bitcoin/bitcoin/issues/28685 | coinstats, assumeutxo: fix hash_serialized2 calculation by fjahr · Pull Request #28685 · bitcoin/bitcoin · GitHub
05:26 < bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/106ab20f121f...9e616baec0f2
05:26 < bitcoin-git> bitcoin/master d90ad5a Hennadii Stepanov: build: Include qt sources for parsing with extract_strings.py
05:26 < bitcoin-git> bitcoin/master b59b31a Hennadii Stepanov: build: Drop redundant qt/bitcoin.cpp
05:26 < bitcoin-git> bitcoin/master 9e616ba fanquake: Merge bitcoin/bitcoin#22764: build: Include qt sources for parsing with ex...
05:26 < bitcoin-git> [bitcoin] fanquake merged pull request #22764: build: Include qt sources for parsing with extract_strings.py (master...210821-translation) https://github.com/bitcoin/bitcoin/pull/22764
05:33 -!- dviola [~diego@user/dviola] has quit [Ping timeout: 264 seconds]
05:35 -!- diego [~diego@186.222.94.177] has joined #bitcoin-core-dev
05:35 -!- diego is now known as Guest1221
05:37 < bitcoin-git> [bitcoin] stickies-v opened pull request #28687: [POC][WIP] C++20 std::views::reverse (master...2023-10/cpp20-use-ranges-reverseview) https://github.com/bitcoin/bitcoin/pull/28687
05:38 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081] has quit []
05:38 < fanquake> moar c++20
05:54 < jamesob> fjahr theStack: great catch guys 
06:01 < sipa> has there been any thought about distributing UTXO sets over P2P? presumably this will require at least some merkle-structuring to permit validation of individual chunks, or even FEC coding to allow sharding
06:01 < sipa> because if so, that may inform the kind of UTXO hash that's used?
06:01 -!- vasild [~vd@user/vasild] has joined #bitcoin-core-dev
06:06 -!- Guest1221 [~diego@186.222.94.177] has quit [Ping timeout: 255 seconds]
06:09 -!- diego [~diego@186.222.94.177] has joined #bitcoin-core-dev
06:09 < _aj_> sipa: i thought about https://gist.github.com/ajtowns/4f20d078f8831267fa49625c16ae1921 for partial validation via muhash
06:09 -!- diego is now known as Guest2177
06:12 < jamesob> sipa: yeah you and I talked about this a little years ago; I think some of that made its way into this document: https://github.com/jamesob/assumeutxo-docs/tree/2019-04-proposal/proposal#snapshot-storage-and-distribution
06:13 < jamesob> I wonder if there is any wisdom in committing to a sha256sum of the snapshot file itself in the source code as a belt and suspenders to avoid the issue that fjahr discovered
06:15 < _aj_> it's always good to authenticate data before parsing it, imo
06:15 < sipa> _aj_: what's the point of using muhash?
06:16 < _aj_> sipa: it's readily available already
06:16 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-dev
06:16 < _aj_> sipa: ie, you can verify it against any node that's running coinstatsindex
06:16 < sipa> _aj_: well, yes, but for the whole set only, not for 50 MB chinjks
06:17 < sipa> *chunks
06:18 -!- pablomartin4btc [~pablomart@193.160.245.181] has quit [Ping timeout: 255 seconds]
06:21 < glozow> reminder that #28642 will be locked soon
06:21 <@gribble> https://github.com/bitcoin/bitcoin/issues/28642 | Voting on Priority Projects for 27.0 · Issue #28642 · bitcoin/bitcoin · GitHub
06:27 < _aj_> sipa: mostly it seemed like a possible way to have the set of hashes available for a height soon after the height was mined, without requiring the node to have any downtime while the utxo set gets rehashed
06:27 < sipa> _aj_: ah, hmm
06:28 < sipa> let's talk in the meeting, i guess?
06:31 < _aj_> sipa: i think you may have already exhausted how much i thought about it :)
06:57 -!- guest-127 [~guest-127@212.129.86.235] has joined #bitcoin-core-dev
06:58 -!- SebastianvStaa [~Sebastian@ip-109-43-241-175.web.vodafone.de] has joined #bitcoin-core-dev
07:00 < achow101> #startmeeting
07:00 < core-meetingbot> Meeting started Thu Oct 19 14:00:25 2023 UTC.  The chair is achow101. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
07:00 < core-meetingbot> Available commands: action commands idea info link nick
07:00 < achow101> #bitcoin-core-dev Meeting: achow101 _aj_ amiti ariard aureleoules b10c BlueMatt brunoerg cfields darosior dergoegge dongcarl fanquake fjahr furszy gleb glozow hebasto instagibbs jamesob jarolrod jonatack josibake kallewoof kanzure kouloumos kvaciral laanwj LarryRuane lightlike luke-jr MacroFake Murch phantomcircuit pinheadmz promag provoostenator ryanofsky sdaftuar S3RK stickies-v sipa theStack TheCharlatan vasild
07:00 < vasild> hi
07:00 < stickies-v> hi
07:00 < pinheadmz> hi
07:00 < glozow> hi
07:00 < instagibbs> hi
07:00 < josie> hi
07:00 < sdaftuar>   hi
07:00 < theStack> hi
07:00 < dergoegge> hi
07:00 < furszy> hi
07:01 < hebasto> hi
07:01 < _aj_> hi
07:01 < achow101> There is 1 pre-proposed meeting topic this week. any last minute ones to add to the list?
07:01 < gleb> Hi. Poor internet here
07:01 < fjahr> hi
07:01 < darosior> Good day
07:01 < achow101> #topic priority projects
07:01 < core-meetingbot> topic: priority projects
07:02 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
07:02 < TheCharlatan> hi
07:02 < abubakarsadiq> hi
07:03 < achow101> The final count for the voting is Package relay - 19, Silent payments - 11, Multiprocess - 9, Legacy wallet removal - 9, cmake - 8, erlay - 7 stratum v2 - 4
07:03 < kanzure> hi
07:04 < achow101> We decided at CoreDev to go with the top 3 projects instead of 4, so that would be package relay, silent payments, and one of multiprocess or legacy wallet removal.
07:04 < pinheadmz> ooh a runoff
07:05 < achow101> i would be happy to have multiprocess as the priority project since legacy wallet removal has a plan to move forward this release anyways
07:05 < _aj_> i count 9 for cmake?
07:05 -!- SebastianvStaa [~Sebastian@ip-109-43-241-175.web.vodafone.de] has quit [Quit: Client closed]
07:05 < instagibbs> cmake is happening when it's happening regardless iiuc
07:06 < _aj_> true :)
07:06 < instagibbs> Two Weeks(TM) whenever ready
07:06 < fanquake> Sometime after c++20
07:06 -!- SebastianvStaa [~Sebastian@ip-109-43-241-175.web.vodafone.de] has joined #bitcoin-core-dev
07:06 < TheCharlatan> ^^
07:06 < _aj_> fanquake: woah</keanu>
07:06 < achow101> _aj_: i've not included w0xlt as they aren't in the org, and haven't seemed to be active recently?
07:06 < _aj_> achow101: ok
07:09 < achow101> any other thoughts on multiprocess vs. legacy wallet removal?
07:09 -!- guest-127 [~guest-127@212.129.86.235] has quit [Quit: Client closed]
07:09 -!- guest-127 [~guest-127@212.129.86.235] has joined #bitcoin-core-dev
07:10 < vasild> which one of mine did you count?
07:10 < achow101> vasild: the signaling one
07:11 < instagibbs> legacy wallet removal is your baby, if you think it's fine not being priority it's probably fine?
07:11 < fjahr> achow101: if you are fine with multiprocessing taking the 3rd spot sounds good to me, I think multiprocess certainly needs more attention to make progress
07:11 < _aj_> removing code seems easier to rebase than adding code, maybe?
07:12 < b10c> hi
07:12 < sipa> hi
07:12 < achow101> _aj_: you'd think so. but I started rebasing my 2 year old removal branch and it's not a fun time
07:13 -!- VisitingPeer [~VisitingP@179.red-2-139-120.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
07:14 < fjahr> _aj_ I think it's the same, it just depends on how intermingled the change is with the rest of the code.
07:14 < achow101> is there a tracking issue for multiprocess?
07:15 < glozow> is ryan here?
07:15 < instagibbs> ryanofsky ping
07:15 < sipa> just pinged him IRL
07:15 < ryanofsky> no, can easily create one
07:15 < instagibbs> In RimworLd
07:15 < furszy> I think that people working on the wallet will continue reviewing PRs (or at least I will) vs multiprocess that needs some momentum
07:15 < fjahr> There are #10102 and https://github.com/bitcoin/bitcoin/projects/10
07:15 <@gribble> https://github.com/bitcoin/bitcoin/issues/10102 | Multiprocess bitcoin by ryanofsky · Pull Request #10102 · bitcoin/bitcoin · GitHub
07:16 < achow101> https://github.com/orgs/bitcoin/projects/1/views/2 is updated
07:16 < _aj_> projects/10 is closed/read-only though
07:16 < stickies-v> there's also https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Process-Separation
07:16 < ryanofsky> right now all the code is just in 10102, there are many commits that could be split up
07:19 < achow101> #topic Ad-hoc high priority for review
07:19 < core-meetingbot> topic: Ad-hoc high priority for review
07:19 < achow101> Anything to add or remove from https://github.com/orgs/bitcoin/projects/1/views/4
07:19 < pinheadmz> I wanna shill #27375 again
07:19 <@gribble> https://github.com/bitcoin/bitcoin/issues/27375 | net: support unix domain sockets for -proxy and -onion by pinheadmz · Pull Request #27375 · bitcoin/bitcoin · GitHub
07:19 < pinheadmz> has 2 ACKs, follwoups will offer unix sockets for rpc and zmq as well
07:19 < pinheadmz> imagine no more http://localhost!
07:21 < achow101> cool, will look when we start merging for 27.0
07:22 < achow101> #topic 26.0 milestone
07:22 < core-meetingbot> topic: 26.0 milestone
07:22 < achow101> branching is scheduled for sunday. there's still a bunch of things in the milestone
07:22 < achow101> https://github.com/bitcoin/bitcoin/milestone/60
07:23 < achow101> please review them
07:23 < achow101> #topic Fix for hash_serialized2 calculation and implications (for context see #28675 and #28685) (fjahr)
07:23 < core-meetingbot> topic: Fix for hash_serialized2 calculation and implications (for context see #28675 and #28685) (fjahr)
07:23 -!- SebastianvStaa [~Sebastian@ip-109-43-241-175.web.vodafone.de] has quit [Ping timeout: 248 seconds]
07:23 <@gribble> https://github.com/bitcoin/bitcoin/issues/28675 | Assumeutxo: Altered txoutset dump is still valid · Issue #28675 · bitcoin/bitcoin · GitHub
07:23 <@gribble> https://github.com/bitcoin/bitcoin/issues/28685 | coinstats, assumeutxo: fix hash_serialized2 calculation by fjahr · Pull Request #28685 · bitcoin/bitcoin · GitHub
07:23 <@gribble> https://github.com/bitcoin/bitcoin/issues/28675 | Assumeutxo: Altered txoutset dump is still valid · Issue #28675 · bitcoin/bitcoin · GitHub
07:23 <@gribble> https://github.com/bitcoin/bitcoin/issues/28685 | coinstats, assumeutxo: fix hash_serialized2 calculation by fjahr · Pull Request #28685 · bitcoin/bitcoin · GitHub
07:23 < fjahr> tldr; the hash_serialized_2 calculation had a bug as described here by theStack: https://github.com/bitcoin/bitcoin/issues/28675#issuecomment-1770389468 The fix is in #28685 and it will be renamed to hash_serialized_3.
07:23 <@gribble> https://github.com/bitcoin/bitcoin/issues/28685 | coinstats, assumeutxo: fix hash_serialized2 calculation by fjahr · Pull Request #28685 · bitcoin/bitcoin · GitHub
07:24 < fjahr> This has implications particularly for assumeutxo, the hashes in the chainparams will need to change. But we are also discussing a bunch of additional changes to improve further while we change the resulting hash already.
07:24 -!- SebastianvStaa [~Sebastian@ip-109-43-241-175.web.vodafone.de] has joined #bitcoin-core-dev
07:24 < fjahr> Particularly dergoegge found another issue with his fuzzer on negative values and proposed to get rid of VARINT completely. I would really like to hear if people would like do that or if we should keep the change more minimal. I have started preparing the change with the VARINTs removed but it would be good to know which one we want now so we only have to change the chainparams once since that causes some significant review 
07:24 < fjahr> effort.
07:25 < fjahr> To be precise I think we have the choice between getting rid of all VARINTs in kernel/coinstats, getting rid of it just where dergoegge found the issue and leaving it and checking for negative value in deserialization (I guess we will add this check either way).
07:25 < fjahr> So generally would be good to have a few more eyes on this but particularly looking for feedback on the VARINT question.
07:26 < sipa> For performance reasons, my guess would be that removing all VARINTs from UTXO hashes is better.
07:26 < theStack> as commented in the PR, I think removing VARINTs in `ApplyHash` would make sense, but is only an option if that doesn't come with noticable loss in performance
07:26 < sipa> I suspect that VARINT coding costs per-byte more than SHA256 per-byte.
07:26 < sipa> But I haven't benchmarked it.
07:26 < dergoegge> something that also seems weird to me is that the serialization format is different for hashing with muhash
07:27 < theStack> sipa: oh, interesting, i would have expected it's the other way round. but i don't know too much about sha256 internals TBH
07:27 < fjahr> I think at the time we already new the muhash one made more sense, just kept the hash_serialized one around for consistency
07:27 < fjahr> *knew
07:27 < sipa> SHA256 (without hardware acceleration) is maybe a dozen CPU cycles per byte; varint coding involves lots of branches that can be mispredicted... less work overall, but probably a lot lower ILP
07:29 < sipa> Does the fact that it may impact chainparams really matter? I can imagine it's likely we want to revisit the actual hashing scheme for assumeutxo before mainnet deployment anyway, depending on how P2P serving would happen.
07:29 < achow101> was hash_serialized_2 always incorrect?
07:29 -!- VisitingPeer [~VisitingP@179.red-2-139-120.dynamicip.rima-tde.net] has quit [Ping timeout: 248 seconds]
07:29 < fjahr> That would be another option, to apply the MuHash serialization so we are consistent
07:29 < fjahr> achow101: since 2018
07:29 < theStack> achow101: i think it's incorrect since v0.17 (see linked commit in the issue)
07:30 < theStack> at least that's the earliest tag that is shown by `git tag --contains 34ca75032012562d226b06ef9e86a2948d3a8d16`
07:30 < fjahr> sipa: at least we need to fix the testnet and signet params before the release
07:31 < sipa> fjahr: that doesn't sound like a big deal
07:31 < fjahr> not sure when we will even get into p2p distribution, if that's a focus for jamesob for 27
07:33 < fjahr> sipa: I just would like it if we can come to an agreement now then we don't need another follow-up to 28685
07:34 < achow101> if we change the serialization, will the coinstatsindex need to be reindexed?
07:34 < fjahr> no, the hash_serialized is not part of it
07:34 -!- Guest2177 [~diego@186.222.94.177] has quit [Quit: WeeChat 4.1.0]
07:35 < sipa> i'm happy with either just using the muhash serialization for hash_serialized_3, or keeping VARINT
07:35 < sipa> but a benchmark would be useful
07:35 < achow101> why are the serialziations different?
07:36 < sipa> i suppose because they were designed at different times
07:37 < fjahr> what I wrote above, I think pieter came up with the one for muhash but we kept the old one for consistency of hash_serialized
07:37 < sipa> well i think i also came up with the one for hash_serialized
07:37 < fjahr> :)
07:38 < sipa> the muhash one is simpler, the hash_serialized one is more compact
07:38 < achow101> it'd be nice if they were consistent
07:38 < achow101> but it seems like people don't particularly care?
07:39 < sipa> for muhash i think performance matters less also, because the serialization cost is probably dwarfed by the muhash math overhead
07:39 < sipa> can someone benchmark if it matters at all, and if the more compact one is not significantly better, pick the muhash serialization for hash_serialized_3 ?
07:39 < fjahr> I can run the benchmarks and post them in the PR
07:40 -!- SebastianvStaa [~Sebastian@ip-109-43-241-175.web.vodafone.de] has quit [Quit: Client closed]
07:40 < sipa> great
07:40 < achow101> sounds like a plan
07:41 < achow101> any other topics to discuss?
07:41 -!- pablomartin4btc [~pablomart@193.160.245.175] has joined #bitcoin-core-dev
07:42 < MacroFake> Is the content hash needed, if the full file hash will be checked in the future?
07:42 < MacroFake> I guess to protect against the file changing while reading it?
07:43 < sipa> i could imagine introducing some kind of merkle-structured content hash in the future, that's used as a full file hash too
07:44 < sipa> but it sounds like there is a lot of design space for that
07:45 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/9e616baec0f2...6e721c923c87
07:45 < bitcoin-git> bitcoin/master 2338715 fanquake: doc: add historical release notes for 25.1
07:45 < bitcoin-git> bitcoin/master 6e721c9 fanquake: Merge bitcoin/bitcoin#28667: doc: add historical release notes for 25.1
07:46 < bitcoin-git> [bitcoin] fanquake merged pull request #28667: doc: add historical release notes for 25.1 (master...add_25_1_rel_notes) https://github.com/bitcoin/bitcoin/pull/28667
07:46 < MacroFake> Are you saying with your proposal the full file hash would be equal to the content hash?
07:46 -!- pablomartin [~pablomart@193.160.245.176] has joined #bitcoin-core-dev
07:46 < MacroFake> (With full file hash I mean the dumb hash of the byte file, without parsing the content or looking at it)
07:47 < fjahr> I think flat file hash might be limiting as a hard requirement when we think about p2p distribution, not sure if it makes sense as temporary belt and suspenders 
07:47 < sipa> no; i'm saying you'd verify the full file by computing its contents hash... which is designed in such a way that it's easy to validate the serialized file (and chunks of it) against
07:47 -!- BlueMatt[m] [~bluematt@2620:6e:a000:ce11::d] has quit [Ping timeout: 240 seconds]
07:47 < sipa> and not having a dumb hash of the file at all
07:47 -!- pablomartin4btc [~pablomart@193.160.245.175] has quit [Ping timeout: 240 seconds]
07:49 < sipa> i guess there could also be a dumb hash of the whole file as a final last-resort check, but for P2P distribution you really need a way to check for incorrect chunks very early anyway
07:51 < sipa> i guess it could be a tree-structured hash over the serialized file (and not over individual utxo entries in it)?
07:52 < achow101> seems like something that requires more thought than we can do for a fix for this release
07:52 < sipa> but this doesn't need to be part of this meeting, i think
07:52 < achow101> #endmeeting
07:52 < core-meetingbot> topic: Bitcoin Core development discussion and commit log | Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/, http://gnusha.org/bitcoin-core-dev/ | Weekly Meeting Thursday @ 14:00 UTC | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt
07:52 < core-meetingbot> Meeting ended Thu Oct 19 14:52:30 2023 UTC.  
07:52 < core-meetingbot> Minutes:        https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2023/bitcoin-core-dev.2023-10-19-14.00.moin.txt
07:52 < MacroFake> [16:51] <sipa> i guess it could be a tree-structured hash over the serialized file (and not over individual utxo entries in it)?
07:52 -!- guest-127 [~guest-127@212.129.86.235] has quit [Quit: Client closed]
07:52 < MacroFake> Yes, that is what I thought, but agree, no need to be part of the meeting
07:53 < sipa> Well, it's not anymore!
07:53 < _aj_> if you're generating something, i don't quite see why you wouldn't just make a .torrent file of the serialized utxo set?
07:54 < sipa> _aj_: and then store a hash of the torrent file as assumeutxo hash?
07:54 < _aj_> sipa: yeah
07:54 < sipa> i guess that is a tree-structured hash (with just 2 levels of tree)
07:54 < _aj_> sipa: along with the hash_serialized_3 or muhash, to verify it
07:56 < sipa> i was more thinking along the lines of SHA256'ing say 4 KiB chunks of the serialized file, and then build a Merkle tree over those hashes, and make that the file hash
07:56 < sipa> and then whenever you download a (range of) chunks from someone, they'd give a Merkle path to connect it to the file hash
07:57 < sipa> this gives a lot of freedom later in how to schedule the downloading
07:59 < sipa> i picked 4 KiB because it's as small as you can go while retaining the property that the Merkle overhead is negligible in bandwidth/cpu compared to the data itself
07:59 < _aj_> sipa: i just wonder if there's much overlap between p2p distribution of old chainstate vs keeping a node up to date, and if we'd effectively just be reimplementing bittorrent?
08:00 -!- pablomartin [~pablomart@193.160.245.176] has quit [Ping timeout: 255 seconds]
08:00 < _aj_> sipa: like where are we storing the old serialized utxo set? block data somehow? ldb snapshot? somewhere else? is that better than just having it dumped to disk as a file?
08:01 < sipa> that's a fair point... the distribution mechanism (if it's done entirely using file-level hashes) is effectively bittorrent
08:02 -!- BlueMatt[m] [~bluematt@2620:6e:a000:ce11::d] has joined #bitcoin-core-dev
08:02 < _aj_> sipa: and especially for "version 0.1", might be worth just getting something that's quick and works?
08:02 < sipa> how the whole snapshotting happens isn't something i've thought too hard about
08:02 < sipa> because that's the other side of this... we don't just need easy distribution, but also easy creation
08:04 < _aj_> it doesn't need to be that easy to create? one person creates -- everyone else downloads, and verifies the muhash against coinstatsindex?
08:04 < sipa> _aj_: well if we want P2P fetching then you need to be able to fetch from nodes that just have been running, and didn't themself bootstrap from the snapshot
08:06 < sipa> so for that the snapshotting needs to be efficient and deterministic (at least deterministic w.r.t. whatever hash mechanism is used for validating fetching)
08:07 < _aj_> sipa: depends if the p2p is over the bitcoin network or over a bittorrent network?
08:07 < sipa> _aj_: oh you mean *actually* bittorrent
08:07 < _aj_> sipa: as a strawman at least, yeah
08:08 < sipa> i think it'd be nice if fetching utxo snapshots can happen from random network nodes, but admittedly it is a very different problem than what's served now
08:09 < _aj_> sipa: fanquake updates chainparams. stops his bitcoind node. generates the serializaed snapshot at height X. publishes the torrent file. others vet it. ACK the PR. torrent file is published in bitcoincore.org, and seeded by random folks?
08:09 < sipa> do we ship a bittorrent client inside bitcoin core?
08:10 < sipa> or do you need to manually run a bittorrent client to get the snapshot file?
08:10 < _aj_> sipa: i think it'd be nice too; but i think making your node do that would be the exact same resource usage as being a bittorrent seeder of the same data? like, you'd need an extra copy of the utxo set, and have an extra bunch of p2p messages equivalent to the bittorrent protocol?
08:10 -!- mraugust [~mraugust@185.199.102.30] has joined #bitcoin-core-dev
08:11 < _aj_> sipa: presumably it wouldn't be a default config option due to the extra resources? and that selecting the snapshot height is probably a manual thing that code can't automatically adopt?
08:11 < _aj_> sipa: strawman: manually run a bittorrent client?
08:12 < sipa> i was imagining that nodes would automatically make snapshots at predetermined heights, and be able to serve the last few - through some sharding mechanism that this doesn't result in storing 3-4 full chainsate copies
08:13 < _aj_> hmm, is there any recent data about how quickly things cycle through the utxo set?
08:13 < sipa> _aj_: if users have to run a bittorrent client manually, i worry that someone will just offer chainstates instead, which are just as easy to distribute and faster to load
08:14 < sipa> so i think if we want to think about any kind of distribution mechanism, the goal is actually to be that it becomes *the* easiest way to bootstrap a node
08:16 < _aj_> could we structure the snapshot so that it's super fast to import into a chainstate?
08:21 < sipa> unsure
08:25 -!- gerle [~quassel@212-186-78-187.static.upcbusiness.at] has quit [Quit: https://quassel-irc.org - Komfortabler Chat. Überall.]
08:30 < _aj_> presuming we have a hardcoded merkle root, presumably we want to have many peers like bittorrent, rather than only outgoings like IBD, and also relay the chunks we've downloaded and checked to other peers
08:33 -!- brunoerg [~brunoerg@2001:12d0:2080:2800:172:26:0:80a] has joined #bitcoin-core-dev
08:35 -!- DarrylTheFiiish [~DarrylThe@user/DarrylTheFish] has quit [Remote host closed the connection]
08:40 -!- brunoerg_ [~brunoerg@2001:12d0:2080:2800:172:26:0:80a] has joined #bitcoin-core-dev
08:40 -!- brunoerg [~brunoerg@2001:12d0:2080:2800:172:26:0:80a] has quit [Read error: Connection reset by peer]
08:41 < _aj_> sipa: i find myself fairly convinced by the "why not just bittorrent chainstate/ directly". new strawman: just dumptxoutset every 25000 blocks, and serve that; but only keep the most recent 3 of them? it's an extra 30GB but on a full node that's got 600GB anyway, that's not that terrible?
08:44 < sipa> _aj_: that's not terrible; i think it'd be nicer if we could let pruned nodes also participate in the serving
08:47 < sipa> and with FEC, that's not impossible; say you use an 8-bit 255/16 RS code... so now UTXO-serving nodes can choose to store between 18.75% (3/16) of a UTXO set and 300% of a UTXO set (if they keep 3 snapshots)
08:48 < sipa> and to bootstrap, you need to just find a set of peers that together have 16 distinct shards
08:52 < sipa> sadly, unless the merkle tree structure commits to all FEC shards, you can't validate individual pieces of coding until you have all 16 for a given chunk
08:53 < _aj_> i'm not following the shard vs chunk split?
08:53 < _aj_> if you're 3/16, are you keeping 3 shards of every chunk?
08:53 < sipa> so the idea is the file is split up in chunks, say 4 KiB each
08:54 < sipa> these chunks get FEC coded in a way that 16 shards of chunk (each 512 bytes) are sufficient to reconstruct it
08:55 < sipa> but each chunk has 255 possible shards, and every node would pick between 1 and 16 distinct integers in range 0..255, and keep those shards for each chunk
08:56 < sipa> so whenever you have 16 distinct shards for a chunk, you can reconstruct the chunk
08:58 < sipa> but by offering 255 possibilities rather than just 16, you now don't need to find a set of peers that together offer all 16... any 16 out of 255 suffices
09:04 < _aj_> 512B*16=8KiB not 4KiB? is that a lot of error detection or typo?
09:07 < _aj_> filling in missing data as a 2d puzzle seems complex, i guess; do i get shards 1-16 for chunk 5 from peer 1, or shard 1 for chunk 10-26? i guess you just throw enough peers at the problem and it's fine though
09:08 < sipa> brb, lunch
09:11 < sipa> _aj_: err yes 256B, not 512B
09:12 -!- brunoerg_ [~brunoerg@2001:12d0:2080:2800:172:26:0:80a] has quit [Read error: Connection reset by peer]
09:12 -!- brunoerg [~brunoerg@2001:12d0:2080:2800:172:26:0:80a] has joined #bitcoin-core-dev
09:16 < _aj_> seems like you should rarely need more than 6 peers, even with only 3 shards each
09:18 -!- brunoerg_ [~brunoerg@2001:12d0:2080:2800:172:26:0:80a] has joined #bitcoin-core-dev
09:18 -!- brunoerg [~brunoerg@2001:12d0:2080:2800:172:26:0:80a] has quit [Read error: Connection reset by peer]
09:22 < sipa> _aj_: so one way of looking at it, is it expands every 4 KiB chunk into 255/16 * 4 KiB = 63.75 KiB of data... but you can reconstruct the whole thing with *any* 4 KiB out of those 63.75 KiB; so each node can choose to store some subset of those 63.75 KiB only
09:22 -!- jQrgen [~jQrgen@2001:8c0:ea04:37:fd50:6346:e4a3:11dc] has joined #bitcoin-core-dev
09:23 < sipa> (but aligned with 256B boundaries(
09:26 -!- preimage [~halosghos@user/halosghost] has joined #bitcoin-core-dev
09:28 < _aj_> sipa: so this would kind of be `dumptxoutshards 65 115 252` (which does dumptxoutset but also does FEC calculations but also potentially is 3/16th of the size) every 20k blocks, then you serve those for 20k/40k/60k blocks, then you delete them.
09:28 -!- test_ [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #bitcoin-core-dev
09:29 < _aj_> i guess if we can get pruned nodes to serve the data, there's less need for nodes that are still downloading the data to serve it out to others; that would let you download the data in order, rather than randomly. that might then let you import it into leveldb as you download it?
09:30 -!- ibiko1 [~ibiko1@170.253.45.108] has joined #bitcoin-core-dev
09:31 -!- flooded [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Ping timeout: 240 seconds]
09:34 -!- ibiko1 [~ibiko1@170.253.45.108] has quit [Ping timeout: 252 seconds]
09:46 -!- brunoerg_ [~brunoerg@2001:12d0:2080:2800:172:26:0:80a] has quit [Remote host closed the connection]
09:47 -!- brunoerg [~brunoerg@2001:12d0:2080:2800:172:26:0:80a] has joined #bitcoin-core-dev
09:49 < bitcoin-git> [bitcoin] achow101 pushed 7 commits to master: https://github.com/bitcoin/bitcoin/compare/6e721c923c87...0655e9dd92ea
09:49 < bitcoin-git> bitcoin/master 64d6f77 Vasil Dimov: net: put CJDNS prefix byte in a constant
09:49 < bitcoin-git> bitcoin/master c42ded3 Vasil Dimov: fuzz: ConsumeNetAddr(): avoid IPv6 addresses that look like CJDNS
09:49 < bitcoin-git> bitcoin/master 6e30865 Vasil Dimov: net: move IsReachable() code to netbase and encapsulate it
09:49 < bitcoin-git> [bitcoin] achow101 merged pull request #27071: Handle CJDNS from LookupSubNet() (master...lookup_subnet_cjdns) https://github.com/bitcoin/bitcoin/pull/27071
10:04 -!- brunoerg [~brunoerg@2001:12d0:2080:2800:172:26:0:80a] has quit [Remote host closed the connection]
10:05 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
10:06 -!- mraugust [~mraugust@185.199.102.30] has quit [Quit: Client closed]
10:09 -!- brunoerg [~brunoerg@2001:12d0:2080:2800:172:26:0:80a] has joined #bitcoin-core-dev
10:14 -!- brunoerg [~brunoerg@2001:12d0:2080:2800:172:26:0:80a] has quit [Remote host closed the connection]
10:24 -!- ___nick___ [~quassel@host86-130-0-61.range86-130.btcentralplus.com] has joined #bitcoin-core-dev
10:25 -!- ___nick___ [~quassel@host86-130-0-61.range86-130.btcentralplus.com] has quit [Client Quit]
10:26 -!- ___nick___ [~quassel@host86-130-0-61.range86-130.btcentralplus.com] has joined #bitcoin-core-dev
10:31 -!- achow101 [~achow101@user/achow101] has quit [Remote host closed the connection]
10:32 -!- achow101 [~achow101@user/achow101] has joined #bitcoin-core-dev
10:53 -!- Guest91 [~Guest77@adsl-109-200-172-56.dynamic.yemennet.ye] has joined #bitcoin-core-dev
10:53 -!- Guest91 [~Guest77@adsl-109-200-172-56.dynamic.yemennet.ye] has quit [Client Quit]
11:13 -!- Evel-Knievel [~Evel-Knie@user/evel-knievel] has quit [Ping timeout: 255 seconds]
11:14 -!- Evel-Knievel [~Evel-Knie@user/evel-knievel] has joined #bitcoin-core-dev
11:32 -!- jQrgen [~jQrgen@2001:8c0:ea04:37:fd50:6346:e4a3:11dc] has quit []
11:47 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
11:48 -!- pablomartin [~pablomart@193.160.245.181] has joined #bitcoin-core-dev
12:04 -!- ibiko1 [~ibiko1@170.253.45.108] has joined #bitcoin-core-dev
12:05 -!- ibiko1_ [~ibiko1@170.253.45.108] has joined #bitcoin-core-dev
12:08 -!- ibiko1 [~ibiko1@170.253.45.108] has quit [Ping timeout: 255 seconds]
12:32 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has quit [Quit: Connection closed for inactivity]
12:43 -!- brunoerg [~brunoerg@2001:12d0:2080:2800:172:26:0:80a] has joined #bitcoin-core-dev
12:51 -!- ibiko1_ [~ibiko1@170.253.45.108] has quit [Ping timeout: 255 seconds]
13:03 -!- ___nick___ [~quassel@host86-130-0-61.range86-130.btcentralplus.com] has quit [Ping timeout: 246 seconds]
13:08 < bitcoin-git> [bitcoin] achow101 pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/0655e9dd92ea...77f0ceb7175d
13:08 < bitcoin-git> bitcoin/master 762404a Vasil Dimov: i2p: also sleep after errors in Accept()
13:08 < bitcoin-git> bitcoin/master 5c8e15c Vasil Dimov: i2p: destroy the session if we get an unexpected error from the I2P router
13:08 < bitcoin-git> bitcoin/master 77f0ceb Andrew Chow: Merge bitcoin/bitcoin#28077: I2P: also sleep after errors in Accept() & de...
13:08 < bitcoin-git> [bitcoin] achow101 merged pull request #28077: I2P: also sleep after errors in Accept() & destroy the session if we get an unexpected error (master...i2p_accept_issue22759) https://github.com/bitcoin/bitcoin/pull/28077
13:13 -!- realies [~realies@user/realies] has joined #bitcoin-core-dev
13:25 < theStack> wouldn't it be nice if utxo dumps had magic bytes (probably with a version) at the beginning so they could be easily identified as such? for better error handling ("this is not an UTXO dump"), but also long-term for utilities like file(1)
13:41 -!- VisitingPeer [~VisitingP@179.red-2-139-120.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
13:41 -!- VisitingPeer [~VisitingP@179.red-2-139-120.dynamicip.rima-tde.net] has quit [Client Quit]
13:45 -!- realies [~realies@user/realies] has quit [Ping timeout: 255 seconds]
13:46 -!- Guest7 [~Guest7@2401:f540:7:2010::76ad] has joined #bitcoin-core-dev
13:47 -!- vysn [~vysn@user/vysn] has joined #bitcoin-core-dev
13:50 < jamesob> Apologies I missed the meeting today, and great job to all involved diagnosing and fixing. I have no intention of doing p2p distribution of snapshots, so someone else will have to tackle that if it is desired; I'm honestly not sure that juice is worth the squeeze.
13:51 < jamesob> In any case, it would be a shame to see a very useful feature held up by deciding on what the perfect hash structure is; that can always be changed later afaict 
13:57 -!- brunoerg [~brunoerg@2001:12d0:2080:2800:172:26:0:80a] has quit [Remote host closed the connection]
14:02 -!- brunoerg [~brunoerg@143.107.231.30] has joined #bitcoin-core-dev
14:12 -!- p [~p@194.195.91.36] has joined #bitcoin-core-dev
14:13 -!- p is now known as Guest7362
14:13 -!- Robotico [~101@2a0c:5a84:3200:6400:649d:1d81:c9ce:2a4c] has joined #bitcoin-core-dev
14:15 -!- Guest7362 [~p@194.195.91.36] has quit [Client Quit]
14:15 -!- paddingtonbear [~paddingto@194.195.91.33] has joined #bitcoin-core-dev
14:18 -!- Robotiko [~101@2a0c:5a84:3200:6400:866d:6046:f377:313d] has joined #bitcoin-core-dev
14:18 -!- Robotico [~101@2a0c:5a84:3200:6400:649d:1d81:c9ce:2a4c] has quit [Quit: Leaving]
14:19 -!- Robotiko [~101@2a0c:5a84:3200:6400:866d:6046:f377:313d] has quit [Remote host closed the connection]
14:19 -!- Robotico [~101@2a0c:5a84:3200:6400:866d:6046:f377:313d] has joined #bitcoin-core-dev
14:19 -!- Robotico [~101@2a0c:5a84:3200:6400:866d:6046:f377:313d] has quit [Remote host closed the connection]
14:20 -!- realies [~realies@user/realies] has joined #bitcoin-core-dev
14:23 < paddingtonbear> hey - i can learn more than i can teach here - but was sent by someone to discuss the bitcoind upstream issue
14:23 < paddingtonbear> this is x.com/123456 (pad)
14:23 < paddingtonbear> happy to talk in dms or in broad daylight haha
14:28 -!- brunoerg [~brunoerg@143.107.231.30] has quit [Remote host closed the connection]
14:34 -!- realies1 [~realies@user/realies] has joined #bitcoin-core-dev
14:35 -!- realies [~realies@user/realies] has quit [Ping timeout: 240 seconds]
14:35 -!- realies1 is now known as realies
14:50 -!- realies [~realies@user/realies] has quit [Ping timeout: 240 seconds]
14:55 -!- preimage [~halosghos@user/halosghost] has quit [Quit: WeeChat 4.1.0]
15:02 -!- realies [~realies@user/realies] has joined #bitcoin-core-dev
15:06 -!- flooded [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #bitcoin-core-dev
15:10 -!- test_ [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Ping timeout: 240 seconds]
15:19 -!- aureleoules [~aureleoul@82-64-162-213.subs.proxad.net] has quit [Ping timeout: 245 seconds]
15:32 -!- aureleoules [~aureleoul@82-64-162-213.subs.proxad.net] has joined #bitcoin-core-dev
16:13 -!- jamesob [~jamesob@108.44.248.162] has quit [Ping timeout: 255 seconds]
16:29 -!- Guest7 [~Guest7@2401:f540:7:2010::76ad] has quit [Quit: Client closed]
16:47 -!- brunoerg [~brunoerg@2804:14d:5281:8c2e:5d45:8de:e791:79a8] has joined #bitcoin-core-dev
16:48 -!- vysn [~vysn@user/vysn] has quit [Remote host closed the connection]
16:51 -!- brunoerg [~brunoerg@2804:14d:5281:8c2e:5d45:8de:e791:79a8] has quit [Ping timeout: 264 seconds]
17:03 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
17:08 -!- paddingtonbear [~paddingto@194.195.91.33] has quit [Quit: Client closed]
17:55 -!- test_ [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #bitcoin-core-dev
17:59 -!- flooded [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Ping timeout: 255 seconds]
18:12 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has joined #bitcoin-core-dev
18:18 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has quit [Ping timeout: 240 seconds]
18:47 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has joined #bitcoin-core-dev
18:51 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has quit [Ping timeout: 272 seconds]
18:59 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has joined #bitcoin-core-dev
19:03 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has quit [Ping timeout: 248 seconds]
19:10 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has joined #bitcoin-core-dev
19:15 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has quit [Ping timeout: 258 seconds]
19:33 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
19:37 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 255 seconds]
19:49 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has joined #bitcoin-core-dev
19:54 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has quit [Ping timeout: 264 seconds]
20:11 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has joined #bitcoin-core-dev
20:16 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has quit [Ping timeout: 258 seconds]
20:21 < _aj_> sipa: hmm, which shards you make available would probably allow fingerprinting your node (so, if you run a tor node, you could identify what your ipv4 address is)... maybe that's okay if you only supply shards to incoming connections?
20:24 < sipa> _aj_: hmm, good point - or pick different shards for every network interface
20:24 < sipa> but that's perhaps too high a price
20:30 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has joined #bitcoin-core-dev
20:34 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has quit [Ping timeout: 240 seconds]
20:35 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has joined #bitcoin-core-dev
20:37 < _aj_> if it was 32 or 64 shares needed instead of 16, you'd need 12-14 or 24-30 peers instead of 6 or 7; could be okay
20:38 < _aj_> (assuming each peer offered 3 shards to inbounds)
20:40 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has quit [Ping timeout: 252 seconds]
20:43 < sipa> that's pretty high, i'd say?
20:45 < sipa> compared to the 8 regular outbound peers currently
20:45 < _aj_> they're more like block-relay-only connections though, since you're not doing tx relay while you're downloading an initial utxo set
20:46 < sipa> unless the specific utxoset checking hash structure we use commits to the FEC data directly, you must pretty have all these peers simultaneously, and download from them in lockstep to decode and verify chunks
20:46 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has joined #bitcoin-core-dev
20:46 < lightlike> is the idea that serving assumeutxo shards would be something all non-pruned nodes would do automatically?  Or more of a configuration thing tied to a service flag, that is opt-in?
20:46 < _aj_> lightlike: s/non-pruned// even
20:47 < _aj_> lightlike: (maybe still opt-in, but in an "everyone should opt-in" way)
20:47 < sipa> i hope we can make it lightweight enough that the default can be on for all nodes
20:49 < _aj_> sipa: i guess i'd argue a downloading peer should connect to more peers even then, so that the load on any given sending peer is lower?
20:50 < sipa> and i guess these can be block-only (or utxo-only...?) connections, without all the txrelay overhead
20:51 < _aj_> utxo-only, then reconnect after you've setup the utxo set is i guess what i was thinking
20:54 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has quit [Ping timeout: 272 seconds]
20:59 < _aj_> random linux iso seems to jump straight to ~30 seeds
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:05 < sipa> ha
21:05 < sipa> i am now hoping that "random linux" is the name of some actual distro
21:07 < _aj_> have it manage your editor/desktop/window manager/browser/shell, and choose a different one every day
21:07 < _aj_> on first april, it restricts you to a freebsd vm
21:08 < sipa> or android
21:10 < _aj_> i was going for mind-expanding, not mind-flaying
21:21 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has joined #bitcoin-core-dev
21:30 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has quit [Ping timeout: 240 seconds]
21:37 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
21:42 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 258 seconds]
21:42 -!- mxz [~mxz@user/mxz] has quit [Quit: cya]
21:44 -!- mxz [~mxz@user/mxz] has joined #bitcoin-core-dev
22:05 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has joined #bitcoin-core-dev
22:09 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has quit [Ping timeout: 240 seconds]
22:16 -!- xzmeng [~xzmeng@42-2-114-012.static.netvigator.com] has joined #bitcoin-core-dev
22:21 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has joined #bitcoin-core-dev
22:26 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has quit [Ping timeout: 264 seconds]
22:33 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
22:42 -!- ibiko1 [~ibiko1@170.253.45.108] has joined #bitcoin-core-dev
22:43 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 264 seconds]
22:57 -!- xzmeng [~xzmeng@42-2-114-012.static.netvigator.com] has quit [Quit: Client closed]
23:06 -!- qxs [~qxs@gateway/tor-sasl/qxs] has quit [Remote host closed the connection]
23:06 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has joined #bitcoin-core-dev
23:06 -!- qxs [~qxs@gateway/tor-sasl/qxs] has joined #bitcoin-core-dev
23:10 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has quit [Ping timeout: 245 seconds]
23:11 -!- ibiko1 [~ibiko1@170.253.45.108] has quit [Remote host closed the connection]
23:17 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
23:22 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 246 seconds]
23:23 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has joined #bitcoin-core-dev
23:26 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Read error: Connection reset by peer]
23:26 -!- qxs [~qxs@gateway/tor-sasl/qxs] has quit [Remote host closed the connection]
23:26 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Read error: Connection reset by peer]
23:26 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-dev
23:26 -!- qxs [~qxs@gateway/tor-sasl/qxs] has joined #bitcoin-core-dev
23:26 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
23:28 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has quit [Ping timeout: 272 seconds]
23:33 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
23:34 -!- flooded [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #bitcoin-core-dev
23:35 -!- test__ [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #bitcoin-core-dev
23:37 -!- test_ [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Ping timeout: 260 seconds]
23:38 -!- test_ [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #bitcoin-core-dev
23:38 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 240 seconds]
23:39 -!- flooded [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Ping timeout: 240 seconds]
23:39 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has joined #bitcoin-core-dev
23:41 -!- test__ [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Ping timeout: 240 seconds]
23:44 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has quit [Ping timeout: 240 seconds]
23:45 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has joined #bitcoin-core-dev
23:48 -!- dougefish [~dougefish@2a06:c701:c0fa:9b11::ffd5] has quit [Remote host closed the connection]
23:49 -!- dougefish [~dougefish@2a06:c701:c0fa:9b11::ffd5] has joined #bitcoin-core-dev
23:49 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has quit [Ping timeout: 252 seconds]
23:56 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:682f:f299:bf3e:5223] has joined #bitcoin-core-dev
--- Log closed Fri Oct 20 00:00:01 2023