12024-10-24T00:26:47 *** zeropoint <zeropoint!~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net> has quit IRC (Quit: leaving)
22024-10-24T01:11:51 *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
32024-10-24T02:46:01 <bitcoin-git> [bitcoin] cbradberry opened pull request #31143: Convert Bitcoin source code to C# (master...convert-bitcoin-to-csharp) https://github.com/bitcoin/bitcoin/pull/31143
42024-10-24T02:46:19 <bitcoin-git> [bitcoin] cbradberry closed pull request #31143: Convert Bitcoin source code to C# (master...convert-bitcoin-to-csharp) https://github.com/bitcoin/bitcoin/pull/31143
52024-10-24T02:57:18 *** adil <adil!~Thunderbi@2402:d000:8134:2758:6c36:91a6:c519:3984> has joined #bitcoin-core-dev
62024-10-24T03:42:41 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has quit IRC (Remote host closed the connection)
72024-10-24T04:01:01 *** cmirror <cmirror!~cmirror@4.53.92.114> has quit IRC (Remote host closed the connection)
82024-10-24T04:01:33 *** cmirror <cmirror!~cmirror@4.53.92.114> has joined #bitcoin-core-dev
92024-10-24T04:13:10 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has joined #bitcoin-core-dev
102024-10-24T04:18:18 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has quit IRC (Ping timeout: 252 seconds)
112024-10-24T04:54:04 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has joined #bitcoin-core-dev
122024-10-24T05:00:06 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has quit IRC (Ping timeout: 252 seconds)
132024-10-24T05:01:44 *** mcey <mcey!~emcy@148.252.146.194> has joined #bitcoin-core-dev
142024-10-24T05:01:51 *** emcy__ <emcy__!~emcy@148.252.146.194> has quit IRC (Remote host closed the connection)
152024-10-24T05:03:50 *** eragmus_ <eragmus_!uid136308@id-136308.tinside.irccloud.com> has joined #bitcoin-core-dev
162024-10-24T05:13:13 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has joined #bitcoin-core-dev
172024-10-24T05:17:27 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has quit IRC (Ping timeout: 246 seconds)
182024-10-24T05:20:15 *** adil <adil!~Thunderbi@2402:d000:8134:2758:6c36:91a6:c519:3984> has quit IRC (Ping timeout: 252 seconds)
192024-10-24T05:24:27 *** adil <adil!~Thunderbi@2402:d000:8134:2758:6c36:91a6:c519:3984> has joined #bitcoin-core-dev
202024-10-24T05:48:21 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has joined #bitcoin-core-dev
212024-10-24T05:53:59 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has quit IRC (Ping timeout: 244 seconds)
222024-10-24T05:56:27 *** flooded <flooded!flooded@gateway/vpn/protonvpn/flood/x-43489060> has quit IRC (Ping timeout: 272 seconds)
232024-10-24T06:00:47 <laanwj> sipa: i checked. as i understand, multiprocess uses two packages: Libmultiprocess and LibmultiprocessNative (same for a non-cross build), you can set their root location with "-DLibmultiprocess_ROOT=..." and "-DLibmultiprocessNative_ROOT=..." where ... is the directory that contains `LibmultiprocessConfig.cmake`
242024-10-24T06:01:34 <laanwj> this should probably be documented somewhere, i can imagine it to be quite common that people install their own libmultiprocess, it's not a thing commonly installed
252024-10-24T06:03:57 *** YaShhhh <YaShhhh!~YaShhhh@202.148.59.170> has joined #bitcoin-core-dev
262024-10-24T06:07:06 <laanwj> wait, no, it appears _ROOT is the root prefix of the package (so where it's installed) https://cmake.org/cmake/help/latest/variable/PackageName_ROOT.html not the dir where the cmake files are
272024-10-24T06:09:31 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has joined #bitcoin-core-dev
282024-10-24T06:14:34 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has quit IRC (Ping timeout: 245 seconds)
292024-10-24T06:24:17 *** PatBoy <PatBoy!xyz@cryption.cn> has quit IRC (Ping timeout: 248 seconds)
302024-10-24T06:24:41 *** PatBoy <PatBoy!xyz@cryption.cn> has joined #bitcoin-core-dev
312024-10-24T06:27:31 *** YaShhhh <YaShhhh!~YaShhhh@202.148.59.170> has quit IRC (Ping timeout: 256 seconds)
322024-10-24T06:29:11 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has joined #bitcoin-core-dev
332024-10-24T06:36:33 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has quit IRC (Ping timeout: 248 seconds)
342024-10-24T06:37:36 *** adil <adil!~Thunderbi@2402:d000:8134:2758:6c36:91a6:c519:3984> has quit IRC (Ping timeout: 246 seconds)
352024-10-24T06:51:37 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has joined #bitcoin-core-dev
362024-10-24T06:56:49 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has quit IRC (Ping timeout: 252 seconds)
372024-10-24T07:09:57 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has joined #bitcoin-core-dev
382024-10-24T07:11:26 <bitcoin-git> [bitcoin] l0rinc opened pull request #31144: optimization: pack util::Xor into 64 bit chunks instead of doing it byte-by-byte (master...l0rinc/optimize-xor) https://github.com/bitcoin/bitcoin/pull/31144
392024-10-24T07:12:20 *** adil <adil!~Thunderbi@2402:d000:8134:2758:6c36:91a6:c519:3984> has joined #bitcoin-core-dev
402024-10-24T07:14:59 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has quit IRC (Ping timeout: 245 seconds)
412024-10-24T07:32:45 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has joined #bitcoin-core-dev
422024-10-24T07:36:09 *** Guyver2 <Guyver2!~Guyver@77-174-98-73.fixed.kpn.net> has joined #bitcoin-core-dev
432024-10-24T07:37:55 *** Guyver2 <Guyver2!~Guyver@77-174-98-73.fixed.kpn.net> has left #bitcoin-core-dev
442024-10-24T07:39:54 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has quit IRC (Ping timeout: 244 seconds)
452024-10-24T07:54:55 *** brunoerg <brunoerg!~brunoerg@82.163.218.33> has joined #bitcoin-core-dev
462024-10-24T08:10:39 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has joined #bitcoin-core-dev
472024-10-24T08:11:18 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/e9b95665eeab...68f29b249070
482024-10-24T08:11:18 *** adil <adil!~Thunderbi@2402:d000:8134:2758:6c36:91a6:c519:3984> has quit IRC (Quit: adil)
492024-10-24T08:11:19 <bitcoin-git> bitcoin/master a0c9595 laanwj: doc: Make list of targets in depends README consistent
502024-10-24T08:11:19 <bitcoin-git> bitcoin/master 68f29b2 merge-script: Merge bitcoin/bitcoin#31141: doc: Make list of targets in depends README c...
512024-10-24T08:11:20 <bitcoin-git> [bitcoin] fanquake merged pull request #31141: doc: Make list of targets in depends README consistent (master...2024-10-depends-platforms) https://github.com/bitcoin/bitcoin/pull/31141
522024-10-24T08:11:44 *** adil <adil!~Thunderbi@2402:d000:8134:2758:6c36:91a6:c519:3984> has joined #bitcoin-core-dev
532024-10-24T08:21:41 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has quit IRC (Ping timeout: 265 seconds)
542024-10-24T08:28:32 *** Guest10 <Guest10!~Guest10@2001:e68:67f5:1f00:f0fb:4c71:e4fd:c74> has joined #bitcoin-core-dev
552024-10-24T08:28:48 *** Guest10 <Guest10!~Guest10@2001:e68:67f5:1f00:f0fb:4c71:e4fd:c74> has quit IRC (Client Quit)
562024-10-24T08:29:10 *** Guest49 <Guest49!~Guest49@ec2-16-162-72-14.ap-east-1.compute.amazonaws.com> has joined #bitcoin-core-dev
572024-10-24T08:34:59 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has joined #bitcoin-core-dev
582024-10-24T08:44:33 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has quit IRC (Ping timeout: 248 seconds)
592024-10-24T08:47:29 *** Guest49 <Guest49!~Guest49@ec2-16-162-72-14.ap-east-1.compute.amazonaws.com> has quit IRC (Ping timeout: 256 seconds)
602024-10-24T08:55:26 <bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/68f29b249070...7290bc61c00b
612024-10-24T08:55:27 <bitcoin-git> bitcoin/master 42e6277 TheCharlatan: build: Add static libraries to Kernel install component
622024-10-24T08:55:27 <bitcoin-git> bitcoin/master 82e16e6 Hennadii Stepanov: cmake: Refactor install kernel dependencies
632024-10-24T08:55:27 <bitcoin-git> bitcoin/master 7290bc6 merge-script: Merge bitcoin/bitcoin#31078: build: Fix kernel static lib component install
642024-10-24T08:55:28 <bitcoin-git> [bitcoin] fanquake merged pull request #31078: build: Fix kernel static lib component install (master...install_kernel_component) https://github.com/bitcoin/bitcoin/pull/31078
652024-10-24T08:58:34 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has joined #bitcoin-core-dev
662024-10-24T09:09:50 <bitcoin-git> [bitcoin] fanquake pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/7290bc61c00b...d94adc7270ba
672024-10-24T09:09:50 <bitcoin-git> bitcoin/master fa5126a MarcoFalke: fees: Pin "version that wrote" to 0
682024-10-24T09:09:51 <bitcoin-git> bitcoin/master ddddbac MarcoFalke: fees: Pin required version to 149900
692024-10-24T09:09:51 <bitcoin-git> bitcoin/master fa1c5cc MarcoFalke: fees: Log non-fatal errors as [warning], instead of info-level
702024-10-24T09:09:52 <bitcoin-git> [bitcoin] fanquake merged pull request #29702: fees: Remove CLIENT_VERSION serialization (master...2403-fees-) https://github.com/bitcoin/bitcoin/pull/29702
712024-10-24T09:10:13 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has quit IRC (Ping timeout: 248 seconds)
722024-10-24T09:25:28 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has joined #bitcoin-core-dev
732024-10-24T09:30:05 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has quit IRC (Ping timeout: 260 seconds)
742024-10-24T09:35:26 *** mcey_ <mcey_!~emcy@148.252.129.209> has joined #bitcoin-core-dev
752024-10-24T09:35:47 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has joined #bitcoin-core-dev
762024-10-24T09:38:51 *** mcey <mcey!~emcy@148.252.146.194> has quit IRC (Ping timeout: 276 seconds)
772024-10-24T09:40:24 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has quit IRC (Ping timeout: 245 seconds)
782024-10-24T09:43:18 *** ___nick___ <___nick___!~quassel@82-132-212-78.dab.02.net> has joined #bitcoin-core-dev
792024-10-24T09:50:34 *** ___nick___ <___nick___!~quassel@82-132-212-78.dab.02.net> has quit IRC (Remote host closed the connection)
802024-10-24T09:54:02 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has joined #bitcoin-core-dev
812024-10-24T09:54:42 *** jirijakes <jirijakes!~jirijakes@118.150.148.23> has joined #bitcoin-core-dev
822024-10-24T10:00:44 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has quit IRC (Ping timeout: 264 seconds)
832024-10-24T10:13:32 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has joined #bitcoin-core-dev
842024-10-24T10:17:59 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has quit IRC (Ping timeout: 252 seconds)
852024-10-24T10:19:33 *** abubakarsadiq <abubakarsadiq!uid602234@id-602234.hampstead.irccloud.com> has joined #bitcoin-core-dev
862024-10-24T10:20:14 *** dermoth <dermoth!~dermoth@user/dermoth> has joined #bitcoin-core-dev
872024-10-24T10:21:03 <bitcoin-git> [bitcoin] maflcko opened pull request #31146: ci: Temporary workaround for old CCACHE_DIR cirrus env (master...2410-ci-temp) https://github.com/bitcoin/bitcoin/pull/31146
882024-10-24T10:31:28 <bitcoin-git> [bitcoin] hebasto opened pull request #31147: cmake, qt, test: Remove problematic code (master...241024-qt-mip) https://github.com/bitcoin/bitcoin/pull/31147
892024-10-24T10:33:30 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has joined #bitcoin-core-dev
902024-10-24T10:39:06 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has quit IRC (Ping timeout: 246 seconds)
912024-10-24T10:55:12 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has joined #bitcoin-core-dev
922024-10-24T10:59:20 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has quit IRC (Ping timeout: 244 seconds)
932024-10-24T11:00:52 *** Guest11 <Guest11!~Guest75@116.37.232.238> has joined #bitcoin-core-dev
942024-10-24T11:01:35 *** Guest11 <Guest11!~Guest75@116.37.232.238> has quit IRC (Client Quit)
952024-10-24T11:28:41 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has joined #bitcoin-core-dev
962024-10-24T11:31:33 *** adil <adil!~Thunderbi@2402:d000:8134:2758:6c36:91a6:c519:3984> has quit IRC (Quit: adil)
972024-10-24T11:34:09 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has quit IRC (Ping timeout: 260 seconds)
982024-10-24T11:50:15 *** Guest91 <Guest91!~Guest29@213.74.112.42> has joined #bitcoin-core-dev
992024-10-24T11:50:33 *** Guest91 <Guest91!~Guest29@213.74.112.42> has quit IRC (Client Quit)
1002024-10-24T12:39:06 *** VonNaturAustreVe <VonNaturAustreVe!~natur@179.214.112.248> has joined #bitcoin-core-dev
1012024-10-24T12:46:19 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/d94adc7270ba...2f40e453ccdf
1022024-10-24T12:46:20 <bitcoin-git> bitcoin/master 6c6b244 LÅrinc: build: Replace MAC_OSX macro with existing __APPLE__
1032024-10-24T12:46:20 <bitcoin-git> bitcoin/master 2f40e45 merge-script: Merge bitcoin/bitcoin#29450: build: replace custom `MAC_OSX` macro with ex...
1042024-10-24T12:46:22 <bitcoin-git> [bitcoin] fanquake merged pull request #29450: build: replace custom `MAC_OSX` macro with existing `__APPLE__` (master...paplorinc/macos_to_apple_macros) https://github.com/bitcoin/bitcoin/pull/29450
1052024-10-24T13:24:37 <achow101> #proposedmeetingtopic working groups
1062024-10-24T13:56:24 *** Guest1 <Guest1!~Guest1@84-216-185-21.customers.ownit.se> has joined #bitcoin-core-dev
1072024-10-24T13:56:36 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/2f40e453ccdf...0c79c343a9f2
1082024-10-24T13:56:36 <bitcoin-git> bitcoin/master fb46d57 Hennadii Stepanov: cmake, qt, test: Remove problematic code
1092024-10-24T13:56:37 <bitcoin-git> bitcoin/master 0c79c34 merge-script: Merge bitcoin/bitcoin#31147: cmake, qt, test: Remove problematic code
1102024-10-24T13:56:38 <bitcoin-git> [bitcoin] fanquake merged pull request #31147: cmake, qt, test: Remove problematic code (master...241024-qt-mip) https://github.com/bitcoin/bitcoin/pull/31147
1112024-10-24T13:57:34 <bitcoin-git> [bitcoin] furszy opened pull request #31148: ci: display logs of failed unit tests automatically (master...2024_ci_test_output) https://github.com/bitcoin/bitcoin/pull/31148
1122024-10-24T14:00:25 <achow101> #startmeeting
1132024-10-24T14:00:31 <achow101> #bitcoin-core-dev Meeting: abubakarsadiq achow101 _aj_ ajonas b10c brunoerg cfields darosior dergoegge fanquake fjahr furszy gleb glozow hebasto instagibbs jarolrod jonatack josibake kanzure laanwj LarryRuane lightlike luke-jr maflcko maxedw Murch pinheadmz provoostenator ryanofsky sdaftuar S3RK stickies-v sipa sr_gi tdb3 theStack TheCharlatan vasild willcl-ark
1142024-10-24T14:00:37 *** Emc99 <Emc99!~Emc99@212.129.81.197> has joined #bitcoin-core-dev
1152024-10-24T14:00:38 <hebasto> hi
1162024-10-24T14:00:39 <TheCharlatan> hi
1172024-10-24T14:00:39 <jonatack> hi
1182024-10-24T14:00:39 <brunoerg> hi
1192024-10-24T14:00:41 <furszy> hi
1202024-10-24T14:00:56 *** sr_gi[m] <sr_gi[m]!~srgimatri@2620:6e:a000:ce11::2a> has joined #bitcoin-core-dev
1212024-10-24T14:01:02 <Chris_Stewart_5> hi
1222024-10-24T14:01:24 <achow101> There is 1 pre-proposed meeting topics this week. Any last minute ones to add?
1232024-10-24T14:01:45 <lightlike> Hi
1242024-10-24T14:02:27 <achow101> #topic Working Groups (achow101)
1252024-10-24T14:03:20 <achow101> Last week at CoreDev, we had a discussion about priority projects and how they don't seem to be working anymore. So we're going to try something a bit different - working groups.
1262024-10-24T14:04:18 <achow101> The idea is that people who want to work on a project together will form a working group to focus on that particular project, and will then give updates in the weekly irc meeting
1272024-10-24T14:04:22 <laanwj> hi
1282024-10-24T14:04:41 *** BlueMatt[m] <BlueMatt[m]!~bluematt@2620:6e:a000:ce11::d> has joined #bitcoin-core-dev
1292024-10-24T14:04:42 <BlueMatt[m]> Iâd like to discuss sv2 and the new bitcoin core nih mining protocol.
1302024-10-24T14:04:47 <abubakarsadiq> Hi
1312024-10-24T14:04:54 <achow101> https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Working-Groups
1322024-10-24T14:05:52 <achow101> so I guess we can go down this list and do working group updates?
1332024-10-24T14:06:24 <laanwj> sgtm
1342024-10-24T14:07:09 <TheCharlatan> I hope more people are here than said hi :P
1352024-10-24T14:07:19 <achow101> guess we'll find out
1362024-10-24T14:07:28 <glozow> hi
1372024-10-24T14:07:41 <stickies-v> hi
1382024-10-24T14:07:41 <achow101> actually, first, any working groups to add?
1392024-10-24T14:07:42 <glozow> do i understand correctly that table is editable?
1402024-10-24T14:07:46 <achow101> yes
1412024-10-24T14:08:15 <glozow> i may add something, but not this week, if thatâs ok
1422024-10-24T14:08:20 <achow101> ok
1432024-10-24T14:08:33 <glozow> thanks
1442024-10-24T14:08:37 <achow101> #topic Erlay WG Update (sr_gi, marcofleon)
1452024-10-24T14:09:02 <_aj_> (can we add links to tracking PR or similar summary page?)
1462024-10-24T14:09:20 <achow101> _aj_: sure
1472024-10-24T14:09:25 <jonatack> quite a few groups to report once per week...perhaps biweekly updates?
1482024-10-24T14:09:46 <jonatack> (half of them each week)
1492024-10-24T14:10:19 <Chris_Stewart_5> Maybe talk process stuff at the end of the updates? I have some Q's myself
1502024-10-24T14:11:11 <achow101> #topic Fuzzing WG Update (dergoegge)
1512024-10-24T14:11:21 <achow101> (if nothing is said for a minute, i'm moving on)
1522024-10-24T14:11:32 <Chris_Stewart_5> :+1:
1532024-10-24T14:11:46 *** ne0h_ <ne0h_!~natur@179.214.112.248> has joined #bitcoin-core-dev
1542024-10-24T14:12:09 *** virtu <virtu!~virtu@user/virtu> has joined #bitcoin-core-dev
1552024-10-24T14:12:10 <darosior> hi
1562024-10-24T14:12:12 <_aj_> (maybe s/#topic/#skipping/ if the leader(s) didn't say hi?)
1572024-10-24T14:12:13 <dergoegge> hi
1582024-10-24T14:12:16 <dergoegge> no updates
1592024-10-24T14:12:18 <achow101> #topic Kernel WG Update (TheCharlatan)
1602024-10-24T14:12:33 <sipa> `hi!
1612024-10-24T14:12:38 <sdaftuar> hi
1622024-10-24T14:12:40 <lightlike> (or maybe have only those groups report something that have something new to report, instead of going through the entire list each week?)
1632024-10-24T14:12:42 <virtu> hi
1642024-10-24T14:13:03 <TheCharlatan> no updates, just brushing up #30595
1652024-10-24T14:13:05 <gribble> https://github.com/bitcoin/bitcoin/issues/30595 | kernel: Introduce initial C header API by TheCharlatan · Pull Request #30595 · bitcoin/bitcoin · GitHub
1662024-10-24T14:13:23 <achow101> #topic Benchmarking WG Update (josibake, l0rinc)
1672024-10-24T14:14:08 *** VonNaturAustreVe <VonNaturAustreVe!~natur@user/vonnaturaustreve> has quit IRC (Ping timeout: 252 seconds)
1682024-10-24T14:14:21 <jonatack> (right, or ones that have something to report open a topic before the meeting)
1692024-10-24T14:14:26 <achow101> #topic Silent Payments WG Update (josibake, RubenSomsen)
1702024-10-24T14:14:42 <abubakarsadiq> +1 jonatack
1712024-10-24T14:15:31 <achow101> #topic Cluster Mempool WG Update (sdaftuar)
1722024-10-24T14:15:50 <sdaftuar> hi --
1732024-10-24T14:16:05 <laanwj> i think asking every group makes sense, it kind of keeps a pace in updates, though ofc not necessarily every week
1742024-10-24T14:16:08 <sdaftuar> as a reminder, the tracking issue is #30289
1752024-10-24T14:16:09 <gribble> https://github.com/bitcoin/bitcoin/issues/30289 | Cluster mempool tracking issue · Issue #30289 · bitcoin/bitcoin · GitHub
1762024-10-24T14:16:37 <TheCharlatan> +1 laanwj
1772024-10-24T14:16:42 <sdaftuar> i recently opened #31122 which changes the mempool interface for adding transactions. that PR is getting some review already
1782024-10-24T14:16:42 <sipa> now updated with a dependency graph about dependency graph code
1792024-10-24T14:16:44 <gribble> https://github.com/bitcoin/bitcoin/issues/31122 | cluster mempool: Implement changeset interface for mempool by sdaftuar · Pull Request #31122 · bitcoin/bitcoin · GitHub
1802024-10-24T14:17:27 <sdaftuar> i think that's it from me, i know sipa is working on the TxGraph code which will be important to review when he finishes
1812024-10-24T14:17:39 <sipa> any week now
1822024-10-24T14:17:45 <achow101> soon(tm)
1832024-10-24T14:18:31 <achow101> #topic MuSig2 WG Update (achow101)
1842024-10-24T14:18:43 <achow101> waiting for libsecp to do a release with the MuSig2 module
1852024-10-24T14:18:48 <sipa> any week now
1862024-10-24T14:19:04 <achow101> also working through a couple of rebase issues in #29675
1872024-10-24T14:19:06 <gribble> https://github.com/bitcoin/bitcoin/issues/29675 | wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys by achow101 · Pull Request #29675 · bitcoin/bitcoin · GitHub
1882024-10-24T14:19:13 <achow101> will perhaps try to split it up to make it easier to review
1892024-10-24T14:19:25 <achow101> #topic Legacy Wallet Removal WG Update (achow101)
1902024-10-24T14:20:05 <achow101> waiting for review of #30328
1912024-10-24T14:20:07 <gribble> https://github.com/bitcoin/bitcoin/issues/30328 | wallet: Remove IsMine from migration code by achow101 · Pull Request #30328 · bitcoin/bitcoin · GitHub
1922024-10-24T14:20:19 <achow101> Last step before final PR #28710
1932024-10-24T14:20:20 <gribble> https://github.com/bitcoin/bitcoin/issues/28710 | Remove the legacy wallet and BDB dependency by achow101 · Pull Request #28710 · bitcoin/bitcoin · GitHub
1942024-10-24T14:20:35 <achow101> can also try to split that too if it's too big
1952024-10-24T14:20:39 *** marcofleon <marcofleon!~marcofleo@87.249.134.130> has joined #bitcoin-core-dev
1962024-10-24T14:20:54 <achow101> #topic Multiprocess WG Update (ryanofsky)
1972024-10-24T14:22:05 *** Emc99 <Emc99!~Emc99@212.129.81.197> has quit IRC (Quit: Client closed)
1982024-10-24T14:22:09 <achow101> #topic Monitoring WG Update (b10c)
1992024-10-24T14:23:24 <achow101> That's it for working groups. I'll try to think about how we can improve this for next week, suggestions welcome.
2002024-10-24T14:23:29 <jonatack> "Last week at CoreDev, we had a discussion about priority projects and how they don't seem to be working anymore."
2012024-10-24T14:23:41 <jonatack> Was there discussion about *why*
2022024-10-24T14:23:55 <achow101> jonatack: yes
2032024-10-24T14:23:57 <Chris_Stewart_5> I like _aj_ suggestion of if no one from the wg says 'hi' we skip
2042024-10-24T14:24:03 <BlueMatt[m]> any other topics or should we talk about mining?
2052024-10-24T14:24:17 <achow101> ajonas will post notes of the meeting or something like that soon(tm)
2062024-10-24T14:24:18 <jonatack> achow101: and?
2072024-10-24T14:24:54 <achow101> #topic Ad-hoc high priority for review
2082024-10-24T14:24:54 <achow101> Anything to add or remove from https://github.com/orgs/bitcoin/projects/1/views/4
2092024-10-24T14:24:58 <marcofleon> Erlay WG update is working on fuzzing the txreconciliation class. And I believe we're meeting next week to go over the current open PR #30116. I think it still needs a bit of rework before being fully ready for review
2102024-10-24T14:25:00 <gribble> https://github.com/bitcoin/bitcoin/issues/30116 | p2p: Fill reconciliation sets (Erlay) attempt 2 by sr-gi · Pull Request #30116 · bitcoin/bitcoin · GitHub
2112024-10-24T14:25:34 <jonatack> why not have that discussion at the irc meeting?
2122024-10-24T14:25:51 <ajonas> jonatack: I will write that up
2132024-10-24T14:26:20 <stickies-v> re wg logistics: wg leaders could also write up their summary just before meeting start (e.g. in a shared doc, or whatever), and then instead of waiting for the summary and for responses, we just have to wait for responses?
2142024-10-24T14:26:26 *** ne0h_ <ne0h_!~natur@179.214.112.248> has quit IRC (Quit: Leaving)
2152024-10-24T14:27:22 <sr_gi[m]> Sorry, looks like my messages didn't go through for the Erlay update
2162024-10-24T14:27:37 <sipa> sr_gi[m]: we read you loud and clear now
2172024-10-24T14:28:02 <jonatack> (my humble thought is that these open, public IRC meetings are the ideal forum for discussions like that, rather than at a private meeting)
2182024-10-24T14:28:17 <sr_gi[m]> We have created a Signal group for those who want to start working/reviewing changes on Erlay, feel free to ping me or Gleb, or I can just paste the group link here, whatever is more convenient
2192024-10-24T14:29:25 <ajonas> I led the discussion on the changes to priority projects. Iâm happy to speak further with whoever is interested.
2202024-10-24T14:29:41 <cfields> hi
2212024-10-24T14:29:43 <sr_gi[m]> We are currently working on sims for Erlay plus getting up to speed with the people who have shown interest. Gleb offered some of his time to explain (either in one-on-ones or as a group) what the current merged code looks like, what the dessign is, and what the ongoing PR is about. I'm also happy to do so
2222024-10-24T14:29:49 <jonatack> (same for review discussions like that one...why take them to private forums?)
2232024-10-24T14:29:57 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has joined #bitcoin-core-dev
2242024-10-24T14:30:07 <ajonas> Itâs clear they were ineffective and so we discussed changes. There is nothing precluding you from participating in them.
2252024-10-24T14:30:50 <jonatack> ajonas: the interesting question is *why* they were ineffective
2262024-10-24T14:30:58 <jonatack> imho
2272024-10-24T14:31:11 <laanwj> no one knew why, it was just noticed
2282024-10-24T14:31:11 <ajonas> Yes. I will write that up as promised above.
2292024-10-24T14:31:53 <sipa> We observed that they worked initially, and didn't really work later. Various theories were suggested for why that may be the case, which I'm sure will end up in the meeting notes.
2302024-10-24T14:31:53 <achow101> I don't think the why is all that interesting. rather what worked the first time (since everyone seemed to agree the first time was successful) and what can we take from that to do something different
2312024-10-24T14:32:08 <achow101> so we have something that works all the time
2322024-10-24T14:32:12 <bitcoin-git> [bitcoin] stickies-v opened pull request #31149: tinyformat: enforce compile-time checks for format string literals (master...2024-10/remove-string-format-overload) https://github.com/bitcoin/bitcoin/pull/31149
2332024-10-24T14:32:15 <jonatack> one starting point might be to ask, what process initiatives *have* worked long-term
2342024-10-24T14:32:26 <jonatack> sustainably
2352024-10-24T14:32:43 <achow101> that is what was discussed
2362024-10-24T14:32:48 *** Emc99 <Emc99!~Emc99@212.129.81.197> has joined #bitcoin-core-dev
2372024-10-24T14:33:00 <achow101> the reason for discussing at coredev is because it's way easier to do that, and also easier to monopolize 2-3 hrs of people's time to do so
2382024-10-24T14:33:41 <achow101> as opposed to irc where people frequently talk simultaneously the typing delay results in some confusing and information loss
2392024-10-24T14:33:53 <jonatack> achow101: my opinion is that opening a topic at the open, public weekly meeting is ideal for discussions like that
2402024-10-24T14:33:59 <achow101> noted
2412024-10-24T14:34:00 <laanwj> also, people tend to attend coredevs in larger numbers than weekly IRC meetings
2422024-10-24T14:34:31 <achow101> jonatack: that is why we're talking about it now
2432024-10-24T14:35:00 <achow101> but having an initial discussion outside of this meeting makes it easier for most people to be on the same page
2442024-10-24T14:35:44 <laanwj> Matt really wants to discuss the mining topic lets go :)
2452024-10-24T14:35:53 <jonatack> i wonder if any of the process initiatives have stuck long-term
2462024-10-24T14:36:00 <achow101> #topic mining (BlueMatt)
2472024-10-24T14:36:11 <BlueMatt[m]> Apologies in advance for the wall of text, I'd tried to have this conversation in a higher-bandwidth way but was rebuffed, so instead we get garbage ð¤·ââï¸
2482024-10-24T14:36:13 <jonatack> and if not, consider why that is that case
2492024-10-24T14:36:19 <BlueMatt[m]> So Iâm really quite confused here, somehow weâve ended up with Bitcoin Core NIHing a new work providing protocol, except without any of the features of the Sv2-defined one, which is borderline worse than getblocktemplate and where no one who works on mining stuff was consulted on the design of the new protocol.
2502024-10-24T14:36:21 <BlueMatt[m]> my understanding of what happened is basically that Sjors was getting zero review and making zero progress on getting the Sv2-defined protocol in core, but there was some feedback that the Sv2 server thing should be in a separate process as a part of the multiprocess transition. This was originally an internal interface question so I pushed back a bit on timeline and practicality but as not a major contributor I donât really get to
2512024-10-24T14:36:21 <BlueMatt[m]> have a role that so thatâs the way it went.
2522024-10-24T14:36:22 <BlueMatt[m]> After doing initial work for that, Sjors then took stock and realized he's still getting zero review and making zero progress, so instead he/others(?) decided to just make the above interface a public thing, committing to it as a formal public interface with intent for the Sv2 protocol translation thing to be maintained separately.
2532024-10-24T14:36:24 <BlueMatt[m]> This is fine, except that, of course, there's absolutely no reason to have an Sv2 protocol translation proxy at all cause now we'd have two protocols and an extra daemon to maintain when we can just skip that, making this new protocol the getblocktemplate de-facto replacement. I donât have any particular feelings towards the Sv2 specific protocol here, something else which is equivalent would be totally fine, but there are various
2542024-10-24T14:36:24 <BlueMatt[m]> goals that went into it that seem to have been totally ignored here.
2552024-10-24T14:36:28 <BlueMatt[m]> The whole point of the Sv2 JD server stuff was (a) to be remote-able (TCP + cryptographically authenticated) and (b) to be "push-based" ie let Bitcoin Core decide when to create new block templates and let it immediately push templates when it wants to do so (possibly even before updating the mempool by predicting the next block's contents in advance or in a parallel thread that can run without cs_main). This new protocol is neither,
2562024-10-24T14:36:28 <BlueMatt[m]> it is both local-only (and explicitly designed in such a way that you can trivially DoS a node with it) and not push-based.
2572024-10-24T14:36:29 <achow101> Sjors does not appear to be here so idk how much discussion is going to happen
2582024-10-24T14:36:31 <BlueMatt[m]> The first goal, of course, you can build with a proxy, though to do so now you're back to having to have two daemons to maintain and two protocols which is gonna limit adoption substantially. Ideally the protocol wouldn't be so trivially DoSable so that we can make it public by just using netcat or something which trivially wraps a local connection and provides cryptographic authentication (assuming Bitcoin Core doesn't provide that in
2592024-10-24T14:36:31 <BlueMatt[m]> the future which ideally it would even if just not in the first release).
2602024-10-24T14:36:36 <BlueMatt[m]> The second goal you can not - if itâs less efficient coming out of Bitcoin Core, no amount of proxying is going to fix that.
2612024-10-24T14:36:39 <BlueMatt[m]> It seems that Bitcoin Core took a principled position that the remote-ability of this protocol doesnât matter (which is a reasonable decision, the remote-ability of work-providing is a somewhat speculative feature, but one I think is worth having a decade down the line), but Iâm not really sure why no one whoâs spent time on mining work protocols was even consulted on such a major decision. Further, the fact that the one major
2622024-10-24T14:36:39 <BlueMatt[m]> efficiency gain that Sv2 was proposing here was thrown out kinda boggles my mind.
2632024-10-24T14:36:43 <BlueMatt[m]> Finally, itâs worth noting that getblocktemplate actually has a BIP, but for some reason this new work isnât even standardized anywhere, which strikes me as strange given Bitcoin core will definitely not be the not server for this so we really canât just say âthe interface is what Bitcoin Core providesâ.
2642024-10-24T14:37:05 <BlueMatt[m]> the decisions seem to have been much broader than sjors
2652024-10-24T14:37:14 <BlueMatt[m]> though I intend to speak to him in atlanta today/tomorrow
2662024-10-24T14:37:20 <BlueMatt[m]> apparently he's there
2672024-10-24T14:37:29 <sipa> BlueMatt[m]: we did have a long discussion about this topic at coredev
2682024-10-24T14:37:30 <laanwj> would have been better to have Sjors here with this topic though
2692024-10-24T14:37:39 <BlueMatt[m]> but the situation is quite FUBAR, so its worth highlighting here...
2702024-10-24T14:38:13 <BlueMatt[m]> sipa: yes, and I attempted to provide input because it seems weird that these decisions were made to design a whole new protocol without discussing it with anyone who has worked on mining protocol, but was told to eat shit ð¤·ââï¸
2712024-10-24T14:38:26 <sipa> BlueMatt[m]: you're not being constructive here
2722024-10-24T14:38:39 <_aj_> is there some PR you're referring to?
2732024-10-24T14:38:54 <BlueMatt[m]> I'm not sure which PR it was, the protocol is already merged, however
2742024-10-24T14:39:05 <TheCharlatan> I don't think this is beyond salvage. All that has happened so far is that a interface that would have been used internally in any case is now exposed. It was not intended to be a protocol, just an interface.
2752024-10-24T14:39:21 <BlueMatt[m]> I did open an issue to highlight at least the push-based transition and sjors indicated that that could maybe still be done
2762024-10-24T14:39:30 <achow101> _aj_: probably #30200
2772024-10-24T14:39:33 <gribble> https://github.com/bitcoin/bitcoin/issues/30200 | Introduce Mining interface by Sjors · Pull Request #30200 · bitcoin/bitcoin · GitHub
2782024-10-24T14:39:50 <sipa> i think you're jumping to conclusions that the IPC protocol is (a) immutable (b) intended to be an external protocol
2792024-10-24T14:39:55 <_aj_> or #30440 or #30955 maybe?
2802024-10-24T14:39:56 <laanwj> the main train of thought is that it was not realistic to have full Sv2 support merged into core, so the second best would be to have a high-performance interface and an external implementation
2812024-10-24T14:39:57 <gribble> https://github.com/bitcoin/bitcoin/issues/30440 | Have createNewBlock() return a BlockTemplate interface by Sjors · Pull Request #30440 · bitcoin/bitcoin · GitHub
2822024-10-24T14:39:59 <gribble> https://github.com/bitcoin/bitcoin/issues/30955 | Mining interface: getCoinbaseMerklePath() and submitSolution() by Sjors · Pull Request #30955 · bitcoin/bitcoin · GitHub
2832024-10-24T14:40:03 <BlueMatt[m]> TheCharlatan: two notes: (a) the interface was not sufficient for use internally, but it sounds like that might change
2842024-10-24T14:40:14 <BlueMatt[m]> sipa: no, i was told explicitly it intends to be public now
2852024-10-24T14:40:27 <laanwj> if the interface is not sufficient, then that should be improved of course
2862024-10-24T14:40:38 <BlueMatt[m]> laanwj: yea, again I don't have any particular desire to see Sv2 merged, but rather the interface needs to be carefully considered
2872024-10-24T14:40:50 <BlueMatt[m]> because if its "the public interface" then it *is* a replacement
2882024-10-24T14:40:50 <achow101> my recollection is that the sv2 stuff would still live under "Bitcoin Core" but not in the main repo
2892024-10-24T14:40:51 <sipa> BlueMatt[m]: some people have opinions, not everyone agrees on all the details, and nothing is set in stone
2902024-10-24T14:40:52 <laanwj> do weigh in on interface details then
2912024-10-24T14:40:56 <achow101> so having the interface facilitates that
2922024-10-24T14:41:28 <BlueMatt[m]> achow101: that's somewhat nonsensical - if bitcoin core is defining a new protocol for work provisioning, there's no reason to have a different one
2932024-10-24T14:41:50 <BlueMatt[m]> the immediate short-term issue is #31109
2942024-10-24T14:41:51 <gribble> https://github.com/bitcoin/bitcoin/issues/31109 | Mining Interface doesnt allow for Bitcoin Core to create blocks when it wants · Issue #31109 · bitcoin/bitcoin · GitHub
2952024-10-24T14:42:00 *** pablomartin <pablomartin!~pablomart@103.214.46.191> has joined #bitcoin-core-dev
2962024-10-24T14:42:02 <BlueMatt[m]> which generally discusses the need to rewrite the protocol
2972024-10-24T14:42:03 <sipa> BlueMatt[m]: my personal view is that i'd like a maintained sv2 implementation as part of the bitcoin core organization, and part of its releases, tested against bitcoin... whether or not that's built from the same codebase, whether or not that's written in the same language
2982024-10-24T14:42:17 <BlueMatt[m]> but it also almost certainly needs a bip, or at least a specification document in core
2992024-10-24T14:42:17 <laanwj> the miners would still want to use Sv2 though? IPC is not something you'd want to offer to the internet, way to large attacks urface
3002024-10-24T14:42:44 <sipa> and that the IPC interface evolves from an internally defined to something stable, depending on whether there is interest in external implementations against it
3012024-10-24T14:42:44 <BlueMatt[m]> sipa: I don't see why we should have two protocols that do the same thing and (hopefully end up) roughly equivalent?
3022024-10-24T14:43:01 <BlueMatt[m]> that seems like a lot of indirection and extra crap everyone needs to implement.
3032024-10-24T14:43:05 <TheCharlatan> BlueMatt[m] sure, it will be improved. This was an attempt to get something out something out. From what I gather sjors' current implemetnation would have had the same issue you describe too.
3042024-10-24T14:43:06 <achow101> BlueMatt[m]: I don't think that's nonsensical. it's generally the direction we'd like to move towards - interfaces that are used by other parts of Bitcon Core which live in separate repos but under the same org. the interfaces are still largely an internal thing
3052024-10-24T14:43:21 <sipa> BlueMatt[m]: please, be constructive
3062024-10-24T14:43:23 <laanwj> ^^ that
3072024-10-24T14:43:23 <BlueMatt[m]> laanwj: ideally the protocol would be restructured to not be so DoS-able :)
3082024-10-24T14:43:33 <BlueMatt[m]> which it sounds like might happen on #31109
3092024-10-24T14:43:34 <gribble> https://github.com/bitcoin/bitcoin/issues/31109 | Mining Interface doesnt allow for Bitcoin Core to create blocks when it wants · Issue #31109 · bitcoin/bitcoin · GitHub
3102024-10-24T14:43:56 <achow101> BlueMatt[m]: because the point is not to have it be publicly exposed that anyone can connect to
3112024-10-24T14:44:11 <laanwj> Matt Corallo: sure! it's just that IPC is an interprocess interface, not a remote interface, and will never be
3122024-10-24T14:44:15 <achow101> and at least the pr that introduced it is just a refactoring of current stuff to get the ball rolling
3132024-10-24T14:44:29 <BlueMatt[m]> achow101: right, like i mentioned in the original wall of text, I didn't weigh in particularly on that decision because that's a bitcoin core decision, not mine. however, it sounds like now the interface intends to be something that is stable/maintained.
3142024-10-24T14:44:38 <BlueMatt[m]> at least that's what ive now repeatedly been told.
3152024-10-24T14:44:44 <sipa> BlueMatt[m]: again, you are jumping to conclusions
3162024-10-24T14:44:58 <BlueMatt[m]> no, I'm repeating what I've been told :)
3172024-10-24T14:45:00 <sipa> i'm sure some people hold that view
3182024-10-24T14:45:23 <achow101> BlueMatt[m]: stable and maintained != exposed to the internet and therefore needs all the stuff to deal with that
3192024-10-24T14:45:36 <laanwj> right
3202024-10-24T14:45:43 <BlueMatt[m]> and, more generally, if the IPC protocol *is* reasonably well-maintained such that its compatible-ish across versions then I do think we should kill off the sv2 work protocol thing cause like, why have one?
3212024-10-24T14:46:06 <achow101> BlueMatt[m]: ... because it isn't designed as a rpc protocol to be exposed to the internet
3222024-10-24T14:46:13 <achow101> it's an ipc protocol
3232024-10-24T14:46:14 <TheCharlatan> yes
3242024-10-24T14:46:19 <BlueMatt[m]> it doesnt have to be exposed to the internet in v1, of course, but ideally the protocol is structured to support that eventually, cause that's really where it should end up, assuming its set up sensibly
3252024-10-24T14:46:31 <sipa> BlueMatt[m]: i disagree
3262024-10-24T14:46:34 <achow101> maybe in like 30 years
3272024-10-24T14:46:35 <laanwj> that's where Sv2 comes in, as a standard that goes beyond bitcoin core
3282024-10-24T14:46:42 <BlueMatt[m]> achow101: i mean if it ends up being a push-based protoocl (post-31109) then it basically is something that could be exposed to the internet trivially
3292024-10-24T14:47:03 <BlueMatt[m]> could be done with netcat just copying all the messages from core, even, totally write-only
3302024-10-24T14:47:03 <laanwj> our interface is our interface, it just needs to be able to provide what Sv2 needs to use, it isn't supposed to be an actual protocol for outside use!
3312024-10-24T14:47:13 <tdb3> hi
3322024-10-24T14:47:19 <BlueMatt[m]> my point is that once it supports sv2, it will be basically write-only
3332024-10-24T14:47:36 <BlueMatt[m]> so why not just let it be ~write-only (with one message to get the coinbase tx size)
3342024-10-24T14:47:43 <laanwj> IPC will also provide the interface for wallet, GUI,and so on, all semi-internal
3352024-10-24T14:47:49 <BlueMatt[m]> because once we have that exposing the same protocol with netcat is trivial :)
3362024-10-24T14:48:05 <sipa> i would have preferred sv2 directly in bitcoin-core-the-bitcoind-binary, but i understand the objections many contributors have raised; i think for supporting the mining ecosystem, having an external binary/process that implements sv2 that speaks this IPC, and talks the well-defined Sv2 protocol, and is released-with, and tested-against every version for bitcoind
3372024-10-24T14:48:40 <BlueMatt[m]> I also generally think miners will refuse to use that - lower latency is lower latency, to them
3382024-10-24T14:48:44 <laanwj> there's just such a severe lack of reviewers interested in any mining stuff, if there were more, then maybe it would have been realistic to have Sv2 directly in core
3392024-10-24T14:48:48 <BlueMatt[m]> even though I think they're wrong and simplistic...
3402024-10-24T14:49:12 <BlueMatt[m]> and, again, I don't feel strongly about sv2 actually happening here, this protocol in sv2 is *trivial* and doing anything equivalent to it is totally fine by me
3412024-10-24T14:49:14 <sipa> is effectively the same thing, and offers some advantages like process separatations (bitcoind code reviewers don't need to review the sv2 protocol implementation for "will this not crash bitcoind"
3422024-10-24T14:49:21 <laanwj> Sjors has been mostly working on his own on this, if not for him, then there would be no progress on it at all likely
3432024-10-24T14:49:30 <sipa> BlueMatt[m]: it'd be helpful if you'd review the code then
3442024-10-24T14:49:59 <BlueMatt[m]> I don't believe I'm qualified for this anymore, at least not C++, but I did go and review the mining protocol to start a conversation about that, yes.
3452024-10-24T14:50:03 <BlueMatt[m]> at least in structure
3462024-10-24T14:50:39 <BlueMatt[m]> I also can't say I'm super jazzed about the entire bitcoin ecosystem having to support capnproto, but hey whatever, not really a huge deal (is it trivial to write a parser for it?)
3472024-10-24T14:50:43 <laanwj> that's one reason why he'd like the Sv2 server to be in rust
3482024-10-24T14:50:49 <sipa> BlueMatt[m]: ffs, it does not
3492024-10-24T14:50:59 <laanwj> so all the people who want to avoid c++ can finally look at something :)
3502024-10-24T14:51:10 <BlueMatt[m]> laanwj: ha
3512024-10-24T14:51:11 <sipa> BlueMatt[m]: capnproto and IPC is how bitcoind and the sv2 implementation can talk
3522024-10-24T14:51:13 <achow101> BlueMatt[m]: No one except you wants this interface to be publicly exposed
3532024-10-24T14:51:27 <achow101> and no one is intending on doing that
3542024-10-24T14:51:27 <sipa> it could be implemented in rust even (which i've heard some ideas about)
3552024-10-24T14:51:33 <BlueMatt[m]> achow101: that's not what I was told? sjors told me explicitly it intends to be documented/public
3562024-10-24T14:51:43 <laanwj> documented, yes
3572024-10-24T14:51:44 <achow101> BlueMatt[m]: *publicly exposed to the internet
3582024-10-24T14:51:47 <laanwj> exposed, no
3592024-10-24T14:51:51 <BlueMatt[m]> but, again, if the interface exists and is semi-stable, people *will* use that
3602024-10-24T14:51:56 <BlueMatt[m]> right, so exposed is a separate question
3612024-10-24T14:52:08 <sipa> BlueMatt[m]: well Sjors[m] isn't here
3622024-10-24T14:52:19 <BlueMatt[m]> once this becomes the standard mining protocol we'll presumably drop the sv2 protocol
3632024-10-24T14:52:27 <laanwj> we'd like to document it for people that want to use it in an inter-process way on the same machine but not use the bitcoin core tool, for some reason
3642024-10-24T14:52:27 <sipa> i really don't see why
3652024-10-24T14:52:31 <cfields> how would it even be exposed?
3662024-10-24T14:52:38 <TheCharlatan> exposed meaning there is a unix socket you can connect to on the same system. Not a public port exposed to the internet.
3672024-10-24T14:52:39 <BlueMatt[m]> and then suggest people expose this by netcat, at least once its write-only and pretty safe to do :)
3682024-10-24T14:52:58 <sipa> i think sjors may have had the impression that stable-ipc-talking-to-sv2-binary was his only way forward; i hope he's wrong
3692024-10-24T14:53:03 <achow101> so we should make it not write-only to prevent that :)
3702024-10-24T14:53:22 <BlueMatt[m]> sipa: I do believe that was his impression, i have no idea if he's right, but I'm not sure it matters?
3712024-10-24T14:53:34 <BlueMatt[m]> achow101: I don't think any sensible work-providing protocol would be anything but :p
3722024-10-24T14:53:37 <laanwj> it's not write-only, capnproto IPC just isn't suitable for that kind of thing, it has a large meta-attack surface wrt handles and such, which simplifies having high performance local interfaces but isn't suitable for internet usage
3732024-10-24T14:53:42 <BlueMatt[m]> one message to get the coinbase tx length and then write-only
3742024-10-24T14:54:01 <sipa> BlueMatt[m]: i don't think it matters, because i feel that the direction that things have been going right now is helpful for multiple possible outcomes, and furthermore, it is making progress
3752024-10-24T14:54:23 <BlueMatt[m]> laanwj: the current one isn't, but it needs to be rewritten for efficiency anyway.
3762024-10-24T14:54:27 <achow101> also, this interfaces thing likely would have happened anyways with the work on multiprocess
3772024-10-24T14:54:34 <BlueMatt[m]> sipa: right, that's basically my impression.
3782024-10-24T14:54:38 <achow101> since that is the direction the project is going in
3792024-10-24T14:54:48 <laanwj> wait, now you want to rewrite capnproto? i...
3802024-10-24T14:55:19 <BlueMatt[m]> I'm not complaining about the fact that we have a different mining protocol, I don't care, I'm highlighting that we need to treat it as a Mining Protocol
3812024-10-24T14:55:24 <BlueMatt[m]> because that's what it is
3822024-10-24T14:55:29 <achow101> perhaps we should revisit this discussion when Sjors is here and the meeting notes are published
3832024-10-24T14:55:38 <BlueMatt[m]> irrespective of whether we want it to be or not
3842024-10-24T14:55:38 <laanwj> it's an internal interface to facilitate mining protocol implementations
3852024-10-24T14:55:46 <laanwj> not a Mining Protocol
3862024-10-24T14:56:04 <BlueMatt[m]> why would a pool not connect directly to it?
3872024-10-24T14:56:05 <sipa> BlueMatt[m]: i really don't think it's helpful that you keep asserting that this is a mining protocol, despite many people here telling you that their view is that it won't be?
3882024-10-24T14:56:22 <BlueMatt[m]> I don't see why anyone would use a proxy to translate one protocol into an equivalent one?
3892024-10-24T14:56:25 <laanwj> i don't think it's useful to discuss this further without Sjors here
3902024-10-24T14:56:44 <BlueMatt[m]> we can discuss it again next week when sjors is back
3912024-10-24T14:56:49 <laanwj> yea
3922024-10-24T14:56:56 <achow101> Any other topics to discuss?
3932024-10-24T14:57:00 <jonatack> Sjors[m]: you can add me to your working group
3942024-10-24T14:57:49 *** marcofleon <marcofleon!~marcofleo@87.249.134.130> has quit IRC (Quit: Client closed)
3952024-10-24T14:57:55 <jonatack> Helpful discussion (for my understanding at least), thank you BlueMatt[m] and everyone for doing it here
3962024-10-24T14:58:43 *** marcofleon <marcofleon!~marcofleo@87.249.134.130> has joined #bitcoin-core-dev
3972024-10-24T15:00:00 <achow101> #endmeeting
3982024-10-24T15:00:02 <cfields> It's not even just a mining interface. the ipc work is attempting to make it easier to construct 3rd-party-ish downstreams of bitcoind. Mining just happens to be a consumer that makes sense for it.
3992024-10-24T15:00:26 <cfields> gui/wallet as other obvious examples.
4002024-10-24T15:01:18 *** Emc99 <Emc99!~Emc99@212.129.81.197> has quit IRC (Quit: Client closed)
4012024-10-24T15:05:37 <bitcoin-git> [bitcoin] maflcko opened pull request #31150: util: Treat Assume as Assert when evaluating at compile-time (master...2410-assume-stronger) https://github.com/bitcoin/bitcoin/pull/31150
4022024-10-24T15:11:37 <BlueMatt[m]> <cfields> "It's not even just a mining..." <- Right, but easy enough to put mining on a separate socket, presumably. Iâm noting that this is how people are going to use it, cause mining pools panic about latency and an extra proxy is obviously latency that they donât want, so theyâll connect directlyâ¦we donât get to control what they do, sadly.
4032024-10-24T15:15:15 <BlueMatt[m]> Ah I think some of the confusion was that sv2 is all about being exposed to the internet. Itâs not, and thatâs a very speculative feature that people certainly arenât goona use any time soon. I think itâs important, but very forward-looking. Thus a socket interface is what people want, at least for the next few years.
4042024-10-24T15:47:23 *** Guest1 <Guest1!~Guest1@84-216-185-21.customers.ownit.se> has quit IRC (Ping timeout: 256 seconds)
4052024-10-24T15:51:22 <gmaxwell> Any kind of external protocol translator will just be a failure point. like the situation right now where mining devices don't speak GBT, so to solo mine you need a proxy and the software documented for that is luke's BFG miner which (last I checked) doesn't compile without considerable work (including making patches and hunting down archived copies of stuff), won't let you mine to anything
4062024-10-24T15:51:28 <gmaxwell> except a p2pkh address, etc. So why would people using one instead of writing their mining infrastrcture against the bitcoin core IPC, skipping a step, source of failures, source of latency?
4072024-10-24T15:52:14 <gmaxwell> I had a friend ask me for help setting up solo mining a couple months ago and it basically took me a full day of work to make it happen, it's absurd and really demoralized me about the state of things.
4082024-10-24T15:53:13 <gmaxwell> I may have contributed to Matt's rampage above by venting to him about this expirence. (well it started off with a question of 'hey how do I use this sv2 stuff that you've been working on for something like 5 years now'
4092024-10-24T15:54:01 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/0c79c343a9f2...dd92911732d4
4102024-10-24T15:54:02 <bitcoin-git> bitcoin/master 8523d8c furszy: ci: display logs of failed tests automatically
4112024-10-24T15:54:02 <bitcoin-git> bitcoin/master dd92911 merge-script: Merge bitcoin/bitcoin#31148: ci: display logs of failed unit tests automat...
4122024-10-24T15:54:03 <bitcoin-git> [bitcoin] fanquake merged pull request #31148: ci: display logs of failed unit tests automatically (master...2024_ci_test_output) https://github.com/bitcoin/bitcoin/pull/31148
4132024-10-24T16:03:31 *** preimage <preimage!~halosghos@user/halosghost> has joined #bitcoin-core-dev
4142024-10-24T16:11:03 *** brunoerg <brunoerg!~brunoerg@82.163.218.33> has quit IRC ()
4152024-10-24T16:14:17 *** Guest45 <Guest45!~Guest45@95-24-62-67.broadband.corbina.ru> has joined #bitcoin-core-dev
4162024-10-24T16:21:32 *** zeropoint <zeropoint!~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net> has joined #bitcoin-core-dev
4172024-10-24T16:27:21 <laanwj> if that isn't important, and one could remove all the "internet hardening" features from Sv2 and it'd also be a lot more straightforward to implement in core, i guess
4182024-10-24T16:29:00 <laanwj> from what i understood the main worry is having to maintain another P2P-port like interface, with DoS robustness, encryption, etc etc
4192024-10-24T16:30:17 <laanwj> so yes if that is a misunderstanding it's one that's already held up a lot of progress
4202024-10-24T16:33:45 <sipa> not DoS robustness, but i have heard the two other parts as arguments: the desire to refactor existing P2P code stuff so it could be reused for Sv2 as well was something not everyone wanted, and all the code for implementing sv2's encryption feeling unnecessary
4212024-10-24T16:33:53 <laanwj> the goal here is to add a mining interface with a s little impact core as possible (in lines of codes, needed refactors, maintenance), and multiprocess is a way to do this
4222024-10-24T16:34:40 <sipa> gmaxwell: FWIW, my view is that whatever we end up with is something that gets tested as part of Bitcoin Core's release process
4232024-10-24T16:35:13 <sipa> which i think makes sense if we see this IPC mechanism the way it is intended, as an internal interface between different parts of the same software
4242024-10-24T16:35:39 *** pablomartin <pablomartin!~pablomart@103.214.46.191> has quit IRC (Ping timeout: 265 seconds)
4252024-10-24T16:36:58 <sipa> but also, this doesn't need to be set in stone, and the fact that it is making progress at all is far better than the opposite; the outcome could be miners/Sv2 stacks implementing this IPC mechanism directly; it could be a Sv2 sidecar binary built from and shipped with bitcoin core; it could even be something like that for some time, but eventually merged back directly
4262024-10-24T16:42:15 *** Guest45 <Guest45!~Guest45@95-24-62-67.broadband.corbina.ru> has quit IRC (Quit: Client closed)
4272024-10-24T16:42:45 *** cornfeedhobo <cornfeedhobo!~cornfeedh@user/cornfeedhobo> has quit IRC (Quit: ZNC - https://znc.in)
4282024-10-24T16:45:05 <laanwj> right just that it's a separate process communicating through ipc doesn't mean it can't be started automatically
4292024-10-24T16:45:30 *** cornfeedhobo <cornfeedhobo!~cornfeedh@user/cornfeedhobo> has joined #bitcoin-core-dev
4302024-10-24T16:45:37 *** pablomartin <pablomartin!~pablomart@103.214.46.183> has joined #bitcoin-core-dev
4312024-10-24T16:50:00 <BlueMatt[m]> <laanwj> "if that isn't important, and one..." <- I think itâs both: IMO itâs a useful hedge for Bitcoin if the mining protocol people use is trivially moved to running over the wire (with cryptographic authentication), but also that no one is going to use it in the short term- it might suddenly become important overnight at some point but itâs hopefully not soon.
4322024-10-24T16:51:07 <laanwj> that's the problem then too... it's hard to warrant implementing something whose expectations are so unclear
4332024-10-24T16:53:11 <BlueMatt[m]> Canât say I disagree, hence my stance that not having it initially is fine but ideally the protocol would trivially support it. Luckily that goal aligns with other important goals around performance
4342024-10-24T16:54:18 <laanwj> in any case, i hope Sjors doesn't get demotivated
4352024-10-24T16:54:50 <sipa> indeed
4362024-10-24T16:57:06 *** sdaftuar <sdaftuar!~sdaftuar@user/sdaftuar> has quit IRC (Quit: WeeChat 3.0)
4372024-10-24T16:57:29 *** sdaftuar <sdaftuar!~sdaftuar@user/sdaftuar> has joined #bitcoin-core-dev
4382024-10-24T16:58:11 *** sdaftuar <sdaftuar!~sdaftuar@user/sdaftuar> has quit IRC (Client Quit)
4392024-10-24T16:58:30 *** sdaftuar <sdaftuar!~sdaftuar@user/sdaftuar> has joined #bitcoin-core-dev
4402024-10-24T17:00:20 *** sdaftuar <sdaftuar!~sdaftuar@user/sdaftuar> has quit IRC (Client Quit)
4412024-10-24T17:10:03 *** pablomartin <pablomartin!~pablomart@103.214.46.183> has quit IRC (Ping timeout: 246 seconds)
4422024-10-24T17:21:35 *** marcofleon <marcofleon!~marcofleo@87.249.134.130> has quit IRC (Quit: Client closed)
4432024-10-24T17:21:38 *** Talkless <Talkless!~Talkless@mail.dargis.net> has joined #bitcoin-core-dev
4442024-10-24T17:30:12 *** pablomartin <pablomartin!~pablomart@103.214.46.185> has joined #bitcoin-core-dev
4452024-10-24T17:31:01 <bitcoin-git> [bitcoin] achow101 pushed 13 commits to master: https://github.com/bitcoin/bitcoin/compare/dd92911732d4...c16e909b3e23
4462024-10-24T17:31:02 <bitcoin-git> bitcoin/master 66c9936 furszy: bench: add coverage for wallet migration process
4472024-10-24T17:31:02 <bitcoin-git> bitcoin/master f2541d0 furszy: wallet: batch MigrateToDescriptor() db transactions
4482024-10-24T17:31:02 <bitcoin-git> bitcoin/master 6052c78 furszy: wallet: decouple default descriptors creation from external signer setup
4492024-10-24T17:31:05 <bitcoin-git> [bitcoin] achow101 merged pull request #28574: wallet: optimize migration process, batch db transactions (master...2023_wallet_batch_migration) https://github.com/bitcoin/bitcoin/pull/28574
4502024-10-24T17:31:56 *** sdaftuar <sdaftuar!~sdaftuar@user/sdaftuar> has joined #bitcoin-core-dev
4512024-10-24T17:38:26 <gmaxwell> I don't think it matters to me if there is some process seperation thing going on (though the latency of the extra serialization round trip might be unfortunate, but thats a benchmarking question). Just that you know it ought to be pratical to mine bitcoin in 'lottery mode' without depending on a trusted third party... and by pratical I mean without the side quest through broken mazes of
4522024-10-24T17:38:32 <gmaxwell> missing gitlab repositories and code that doesn't compile. The obvious thing to do would be to implement stratum v1 mining support, but my understanding is that this was unattractive for varrious reasons and sv2 was intended to be designed with input that made it both meet mining needs *and* be supportable by node software... but the latter part may have been a failure?
4532024-10-24T17:42:31 *** sdaftuar1 <sdaftuar1!~sdaftuar@user/sdaftuar> has joined #bitcoin-core-dev
4542024-10-24T17:42:36 <sdaftuar1> exit
4552024-10-24T17:42:37 *** sdaftuar1 <sdaftuar1!~sdaftuar@user/sdaftuar> has quit IRC (Client Quit)
4562024-10-24T17:46:37 <sipa> gmaxwell: i agree with that
4572024-10-24T17:47:57 *** sdaftuar <sdaftuar!~sdaftuar@user/sdaftuar> has quit IRC (Quit: WeeChat 3.0)
4582024-10-24T17:51:25 <achow101> anyone else finding that running ctest after compiling with clang and Debug mode takes a significantly longer time recently?
4592024-10-24T17:52:01 <achow101> seems to be stuck on Test #6: tests for 10 minutes longer than the next longest test
4602024-10-24T17:52:03 <gribble> https://github.com/bitcoin/bitcoin/issues/6 | Treat wallet as a generic keystore · Issue #6 · bitcoin/bitcoin · GitHub
4612024-10-24T17:52:44 <achow101> clang in RelWithDebugcccccclbnfericrrcirujdhgtcnfujbvefnefbcrufdh
4622024-10-24T17:52:54 *** sdaftuar <sdaftuar!~sdaftuar@user/sdaftuar> has joined #bitcoin-core-dev
4632024-10-24T17:52:58 <achow101> oops
4642024-10-24T17:53:16 <achow101> clang with RelWithDebug doesn't take this long, and gcc doesn't either in both mods
4652024-10-24T17:53:25 <bitcoin-git> [bitcoin] achow101 pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/c16e909b3e23...74fb19317aec
4662024-10-24T17:53:26 <bitcoin-git> bitcoin/master e31bfb2 LÅrinc: refactor: Remove unrealistic simulation state
4672024-10-24T17:53:26 <bitcoin-git> bitcoin/master 46dfbf1 LÅrinc: refactor: Return optional of Coin in GetCoin
4682024-10-24T17:53:26 <bitcoin-git> bitcoin/master 4feaa28 LÅrinc: refactor: Rely on returned value of GetCoin instead of parameter
4692024-10-24T17:53:28 <bitcoin-git> [bitcoin] achow101 merged pull request #30849: refactor: migrate `bool GetCoin` to return `optionalCoin` (master...l0rinc/GetCoin-optional) https://github.com/bitcoin/bitcoin/pull/30849
4702024-10-24T17:53:57 *** sdaftuar <sdaftuar!~sdaftuar@user/sdaftuar> has quit IRC (Client Quit)
4712024-10-24T17:54:34 *** sdaftuar <sdaftuar!~sdaftuar@user/sdaftuar> has joined #bitcoin-core-dev
4722024-10-24T18:18:45 *** ___nick___ <___nick___!~quassel@82-132-214-35.dab.02.net> has joined #bitcoin-core-dev
4732024-10-24T18:19:29 *** ___nick___ <___nick___!~quassel@82-132-214-35.dab.02.net> has quit IRC (Client Quit)
4742024-10-24T18:21:39 *** ___nick___ <___nick___!~quassel@82-132-214-35.dab.02.net> has joined #bitcoin-core-dev
4752024-10-24T18:39:41 <darosior> For the assumeutxo background sync, do we disable assumevalid?
4762024-10-24T19:03:26 <bitcoin-git> [bitcoin] jonatack closed pull request #31135: rpc, cli: return "verificationprogress" of 1 when up to date (master...2024-10-verification-progress) https://github.com/bitcoin/bitcoin/pull/31135
4772024-10-24T19:05:05 *** Talkless <Talkless!~Talkless@mail.dargis.net> has quit IRC (Remote host closed the connection)
4782024-10-24T19:06:49 *** ___nick___ <___nick___!~quassel@82-132-214-35.dab.02.net> has quit IRC (Ping timeout: 260 seconds)
4792024-10-24T19:07:21 *** ___nick___ <___nick___!~quassel@82-132-214-35.dab.02.net> has joined #bitcoin-core-dev
4802024-10-24T19:12:15 *** jlest <jlest!~jlest@user/jlest> has quit IRC (Ping timeout: 265 seconds)
4812024-10-24T19:14:17 <bitcoin-git> [bitcoin] instagibbs opened pull request #31152: functional test: Additional package evaluation coverage (master...2024-10-submitpackage_evict_cpfp_success) https://github.com/bitcoin/bitcoin/pull/31152
4822024-10-24T19:19:42 <instagibbs> cc sdaftuar glozow ^
4832024-10-24T19:25:09 <instagibbs> and sdaftuar I think you're right, the wait for trimming thing isn't a "safety" thing but an ergonomics thing. Funnily enough, if you write the test case so the "final" parent would be evicted, it actually still succeeds since it's a reconsiderable failure
4842024-10-24T19:25:57 <maflcko> achow101: Interesting. If it happened recently, can you bisect?
4852024-10-24T19:32:29 *** Guest8 <Guest8!~Guest94@2a09:bac2:395e:1c46::2d1:43> has joined #bitcoin-core-dev
4862024-10-24T19:33:12 *** Guest8 <Guest8!~Guest94@2a09:bac2:395e:1c46::2d1:43> has quit IRC (Client Quit)
4872024-10-24T19:42:53 <achow101> Will try
4882024-10-24T20:04:20 *** ___nick___ <___nick___!~quassel@82-132-214-35.dab.02.net> has quit IRC (Ping timeout: 264 seconds)
4892024-10-24T20:13:28 *** jespada <jespada!~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net> has quit IRC (Ping timeout: 252 seconds)
4902024-10-24T21:13:46 <gmaxwell> darosior: I don't have an answer to your question, but it would be interesting in general for there to be an additional validation level that indicates if signatures have been checked or not, seperately from doing the background sync in two passes being potentially interesting, a validation level would make batch validation more effective by being able to validate several blocks as one batch.
4912024-10-24T21:17:07 <darosior> Yes. In fact i think it would be interesting to do check the signatures after IBD, akin to how assumeutxo performs background sync.
4922024-10-24T21:17:37 <darosior> (Which is what triggered my question, which i should probably answer by myself)
4932024-10-24T21:17:58 <sipa> not needing to ramp up and ramp down the signature validation threads may be a significant speedup
4942024-10-24T21:18:14 <sipa> even without batch validation
4952024-10-24T21:18:58 <gmaxwell> for long ago blocks like 2012-2015 not having the concurrency slog may help a lot.
4962024-10-24T21:19:12 <gmaxwell> darosior: exactly
4972024-10-24T21:19:37 <darosior> Because as it is i think that the `-assumevalid` model is less "trustless" than assumeutxo, which eventually verifies everything.
4982024-10-24T21:19:57 <gmaxwell> darosior: I vaguely recall sipa and I looking into this before and maybe there wasn't enough space in the stored data to store an extra flag, so it would require an index disk format change, but I could be imagining it.
4992024-10-24T21:21:04 <sipa> pretty sure there is plenty of space, but it may require a disk format change anyway for compatibility reasons
5002024-10-24T21:21:25 <gmaxwell> darosior: six one way half a dozen another, in the sense that assumevalid has an extremely good review model while assumeutxo doesn't... and also the latter seems extremely likely to evolve into something where no one checks the history (regardless of what we think about that)
5012024-10-24T21:21:37 <darosior> So i just checked and since assumevalid is a parameter of the chainstate manager, it appears that it is also enabled for the background sync.
5022024-10-24T21:22:01 <gmaxwell> sipa: a format change that just prevents downgrading but is totally inplace is way better than one that requires a rewrite of all the data. :)
5032024-10-24T21:22:09 <sipa> gmaxwell: absolutely
5042024-10-24T21:22:47 <sipa> well one reason for the background sync to exist is to make sure that the full sync data remains available, which is a concern that doesn't exist with assumevalid
5052024-10-24T21:23:06 <sipa> but with the background sync existing anyway, there is no reason why it couldn't also validate signatures i think
5062024-10-24T21:23:38 <sipa> (of course, absent a assumeutxo-fetching P2P extension, it's unclear to me how many people will actually use assumeutxo...)
5072024-10-24T21:23:46 <darosior> gmaxwell: yes, i was considering this from the angle of "if assumevalid was skipping all checks (including whether inputs exist) instead of just the script checks, would it be a meaningfully different trust model?" and i don't think it would be. But it would also doesn't bring much of a gain for us, since you still need to update the UTxO set
5082024-10-24T21:23:46 <darosior> whether or not you check if inputs exist and are yet-unspent. And i agree that the assumeutxo format in itself brings other concerns.
5092024-10-24T21:24:45 <gmaxwell> darosior: the thing with assumevalid is that to review its accuracy you just need to say "is this block in my chain or not" and if not sound the alarm, and if the software isn't truthworthy enough for *that* than all bets are off since it's easy to bugdoor to disable validation entirely. ... also any attack requires a significant amount of mining. I agree if it skipped other stuff it wouldn't
5102024-10-24T21:24:51 <gmaxwell> be worse, but skipping other stuff would be pointless for it.
5112024-10-24T21:25:17 <darosior> Yes.
5122024-10-24T21:31:11 *** jirijakes <jirijakes!~jirijakes@118.150.148.23> has quit IRC (Ping timeout: 255 seconds)
5132024-10-24T21:31:19 <sipa> prior to the assumevalid point, we could even process blocks out of order, by writing a "negative" entry in the UTXO set (which is erased when its creation is encountered)... this is a quite a bit harder if signature checks are needed, because you'd need to put all the relevant information from the spending tx in the UTXO set
5142024-10-24T21:31:45 <sipa> reorgs and bip30 shenanigans complicate this further
5152024-10-24T21:33:01 <gmaxwell> the other deal with the sig flag is that letting signature validation run async would greatly improve concurrency, like right now during sync you can see slogs of {network, cpu, disk} each operating one at a time and waiting for each other.
5162024-10-24T21:33:38 <sipa> indeed
5172024-10-24T21:37:58 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has quit IRC (Remote host closed the connection)
5182024-10-24T21:38:30 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has joined #bitcoin-core-dev
5192024-10-24T21:43:01 <gmaxwell> (also for bystanders, even though modern blocks have lots of transactions making it seem like there isn't too much to be gained by validing multiple at once, I think that's less true once you introduce batch validation... as there are good gains from batching up to over 100 signatures per batch... so like 8000 txins sounds like enough for concurrency even on a 384 thread computer... but against
5202024-10-24T21:43:08 <gmaxwell> 384 threads that only allows batches of size 20... and running just 20 operations and then synchronizing threads means a lot of parallelism loss.
5212024-10-24T21:43:11 <gmaxwell> )
5222024-10-24T21:47:45 *** kevkevin <kevkevin!~kevkevin@209-242-39-30.rev.dls.net> has quit IRC (Remote host closed the connection)
5232024-10-24T22:00:10 *** preimage <preimage!~halosghos@user/halosghost> has quit IRC (Quit: WeeChat 4.4.2)
5242024-10-24T22:01:56 <bitcoin-git> [bitcoin] achow101 pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/74fb19317aec...7640cfdd6249
5252024-10-24T22:01:56 <bitcoin-git> bitcoin/master f0130ab LÅrinc: doc: replace `-?` with `-h` for bench_bitcoin help
5262024-10-24T22:01:57 <bitcoin-git> bitcoin/master 33a28e2 LÅrinc: Change default help arg to `-help` and mention `-h` and `-?` as alternativ...
5272024-10-24T22:01:57 <bitcoin-git> bitcoin/master 7640cfd Ava Chow: Merge bitcoin/bitcoin#31118: doc: replace `-?` with `-h` and `-help`
5282024-10-24T22:01:58 <bitcoin-git> [bitcoin] achow101 merged pull request #31118: doc: replace `-?` with `-h` and `-help` (master...l0rinc/bench-help) https://github.com/bitcoin/bitcoin/pull/31118
5292024-10-24T22:08:21 <bitcoin-git> [bitcoin] achow101 pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/7640cfdd6249...947f2925d55f
5302024-10-24T22:08:22 <bitcoin-git> bitcoin/master 9bb92c0 Hodlinator: util: Remove RandAddSeedPerfmon
5312024-10-24T22:08:22 <bitcoin-git> bitcoin/master 947f292 Ava Chow: Merge bitcoin/bitcoin#31124: util: Remove RandAddSeedPerfmon
5322024-10-24T22:08:24 <bitcoin-git> [bitcoin] achow101 merged pull request #31124: util: Remove RandAddSeedPerfmon (master...2024/10/rm_RandAddSeedPerfmon) https://github.com/bitcoin/bitcoin/pull/31124
5332024-10-24T22:35:06 *** kevkevin <kevkevin!~kevkevin@2607:fb90:9b30:db8c:9ca9:3143:b5ff:8610> has joined #bitcoin-core-dev
5342024-10-24T23:00:27 *** S3RK_ <S3RK_!~S3RK@user/s3rk> has joined #bitcoin-core-dev
5352024-10-24T23:03:46 *** S3RK <S3RK!~S3RK@user/s3rk> has quit IRC (Ping timeout: 265 seconds)
5362024-10-24T23:38:04 *** pablomartin <pablomartin!~pablomart@103.214.46.185> has quit IRC (Ping timeout: 252 seconds)
5372024-10-24T23:40:52 *** kevkevin <kevkevin!~kevkevin@2607:fb90:9b30:db8c:9ca9:3143:b5ff:8610> has quit IRC (Remote host closed the connection)
5382024-10-24T23:41:18 *** kevkevin <kevkevin!~kevkevin@2607:fb90:9b30:db8c:9ca9:3143:b5ff:8610> has joined #bitcoin-core-dev
5392024-10-24T23:43:15 *** kevkevin <kevkevin!~kevkevin@2607:fb90:9b30:db8c:9ca9:3143:b5ff:8610> has quit IRC (Remote host closed the connection)