--- Log opened Thu Oct 24 00:00:29 2024
00:09 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-dev
00:11 < 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
00:12 -!- adil [~Thunderbi@2402:d000:8134:2758:6c36:91a6:c519:3984] has joined #bitcoin-core-dev
00:14 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Ping timeout: 245 seconds]
00:32 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-dev
00:36 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has joined #bitcoin-core-dev
00:37 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has left #bitcoin-core-dev []
00:39 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Ping timeout: 244 seconds]
00:54 -!- brunoerg [~brunoerg@82.163.218.33] has joined #bitcoin-core-dev
01:10 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-dev
01:11 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/e9b95665eeab...68f29b249070
01:11 -!- adil [~Thunderbi@2402:d000:8134:2758:6c36:91a6:c519:3984] has quit [Quit: adil]
01:11 < bitcoin-git> bitcoin/master a0c9595 laanwj: doc: Make list of targets in depends README consistent
01:11 < bitcoin-git> bitcoin/master 68f29b2 merge-script: Merge bitcoin/bitcoin#31141: doc: Make list of targets in depends README c...
01:11 < 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
01:11 -!- adil [~Thunderbi@2402:d000:8134:2758:6c36:91a6:c519:3984] has joined #bitcoin-core-dev
01:21 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Ping timeout: 265 seconds]
01:28 -!- Guest10 [~Guest10@2001:e68:67f5:1f00:f0fb:4c71:e4fd:c74] has joined #bitcoin-core-dev
01:28 -!- Guest10 [~Guest10@2001:e68:67f5:1f00:f0fb:4c71:e4fd:c74] has quit [Client Quit]
01:29 -!- Guest49 [~Guest49@ec2-16-162-72-14.ap-east-1.compute.amazonaws.com] has joined #bitcoin-core-dev
01:34 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-dev
01:44 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Ping timeout: 248 seconds]
01:47 -!- Guest49 [~Guest49@ec2-16-162-72-14.ap-east-1.compute.amazonaws.com] has quit [Ping timeout: 256 seconds]
01:55 < bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/68f29b249070...7290bc61c00b
01:55 < bitcoin-git> bitcoin/master 42e6277 TheCharlatan: build: Add static libraries to Kernel install component
01:55 < bitcoin-git> bitcoin/master 82e16e6 Hennadii Stepanov: cmake: Refactor install kernel dependencies
01:55 < bitcoin-git> bitcoin/master 7290bc6 merge-script: Merge bitcoin/bitcoin#31078: build: Fix kernel static lib component install
01:55 < 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
01:58 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-dev
02:09 < bitcoin-git> [bitcoin] fanquake pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/7290bc61c00b...d94adc7270ba
02:09 < bitcoin-git> bitcoin/master fa5126a MarcoFalke: fees: Pin "version that wrote" to 0
02:09 < bitcoin-git> bitcoin/master ddddbac MarcoFalke: fees: Pin required version to 149900
02:09 < bitcoin-git> bitcoin/master fa1c5cc MarcoFalke: fees: Log non-fatal errors as [warning], instead of info-level
02:09 < bitcoin-git> [bitcoin] fanquake merged pull request #29702: fees: Remove CLIENT_VERSION serialization (master...2403-fees-) https://github.com/bitcoin/bitcoin/pull/29702
02:10 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Ping timeout: 248 seconds]
02:25 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-dev
02:30 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Ping timeout: 260 seconds]
02:35 -!- mcey_ [~emcy@148.252.129.209] has joined #bitcoin-core-dev
02:35 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-dev
02:38 -!- mcey [~emcy@148.252.146.194] has quit [Ping timeout: 276 seconds]
02:40 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Ping timeout: 245 seconds]
02:43 -!- ___nick___ [~quassel@82-132-212-78.dab.02.net] has joined #bitcoin-core-dev
02:50 -!- ___nick___ [~quassel@82-132-212-78.dab.02.net] has quit [Remote host closed the connection]
02:54 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-dev
02:54 -!- jirijakes [~jirijakes@118.150.148.23] has joined #bitcoin-core-dev
03:00 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Ping timeout: 264 seconds]
03:13 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-dev
03:17 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Ping timeout: 252 seconds]
03:19 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has joined #bitcoin-core-dev
03:20 -!- dermoth [~dermoth@user/dermoth] has joined #bitcoin-core-dev
03:21 < 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
03:31 < 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
03:33 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-dev
03:39 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Ping timeout: 246 seconds]
03:55 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-dev
03:59 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Ping timeout: 244 seconds]
04:00 -!- Guest11 [~Guest75@116.37.232.238] has joined #bitcoin-core-dev
04:01 -!- Guest11 [~Guest75@116.37.232.238] has quit [Client Quit]
04:28 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-dev
04:31 -!- adil [~Thunderbi@2402:d000:8134:2758:6c36:91a6:c519:3984] has quit [Quit: adil]
04:34 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Ping timeout: 260 seconds]
04:50 -!- Guest91 [~Guest29@213.74.112.42] has joined #bitcoin-core-dev
04:50 -!- Guest91 [~Guest29@213.74.112.42] has quit [Client Quit]
05:39 -!- VonNaturAustreVe [~natur@179.214.112.248] has joined #bitcoin-core-dev
05:39 -!- VonNaturAustreVe [~natur@user/vonnaturaustreve] has changed host
05:46 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/d94adc7270ba...2f40e453ccdf
05:46 < bitcoin-git> bitcoin/master 6c6b244 Lőrinc: build: Replace MAC_OSX macro with existing __APPLE__
05:46 < bitcoin-git> bitcoin/master 2f40e45 merge-script: Merge bitcoin/bitcoin#29450: build: replace custom `MAC_OSX` macro with ex...
05:46 < 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
06:24 < achow101> #proposedmeetingtopic working groups
06:56 -!- Guest1 [~Guest1@84-216-185-21.customers.ownit.se] has joined #bitcoin-core-dev
06:56 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/2f40e453ccdf...0c79c343a9f2
06:56 < bitcoin-git> bitcoin/master fb46d57 Hennadii Stepanov: cmake, qt, test: Remove problematic code
06:56 < bitcoin-git> bitcoin/master 0c79c34 merge-script: Merge bitcoin/bitcoin#31147: cmake, qt, test: Remove problematic code
06:56 < 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
06:57 < 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
07:00 < achow101> #startmeeting
07:00 < 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
07:00 -!- Emc99 [~Emc99@212.129.81.197] has joined #bitcoin-core-dev
07:00 < hebasto> hi
07:00 < TheCharlatan> hi
07:00 < jonatack> hi
07:00 < brunoerg> hi
07:00 < furszy> hi
07:00 -!- sr_gi[m] [~srgimatri@2620:6e:a000:ce11::2a] has joined #bitcoin-core-dev
07:01 < Chris_Stewart_5> hi
07:01 < achow101> There is 1 pre-proposed meeting topics this week. Any last minute ones to add?
07:01 < lightlike> Hi
07:02 < achow101> #topic Working Groups (achow101)
07:03 < 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.
07:04 < 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
07:04 < laanwj> hi
07:04 -!- BlueMatt[m] [~bluematt@2620:6e:a000:ce11::d] has joined #bitcoin-core-dev
07:04 < BlueMatt[m]> I’d like to discuss sv2 and the new bitcoin core nih mining protocol.
07:04 < abubakarsadiq> Hi
07:04 < achow101> https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Working-Groups
07:05 < achow101> so I guess we can go down this list and do working group updates?
07:06 < laanwj> sgtm
07:07 < TheCharlatan> I hope more people are here than said hi :P
07:07 < achow101> guess we'll find out
07:07 < glozow> hi
07:07 < stickies-v> hi
07:07 < achow101> actually, first, any working groups to add?
07:07 < glozow> do i understand correctly that table is editable?
07:07 < achow101> yes
07:08 < glozow> i may add something, but not this week, if that’s ok
07:08 < achow101> ok
07:08 < glozow> thanks
07:08 < achow101> #topic Erlay WG Update (sr_gi, marcofleon)
07:09 < _aj_> (can we add links to tracking PR or similar summary page?)
07:09 < achow101> _aj_: sure
07:09 < jonatack> quite a few groups to report once per week...perhaps biweekly updates?
07:09 < jonatack> (half of them each week)
07:10 < Chris_Stewart_5> Maybe talk process stuff at the end of the updates? I have some Q's myself
07:11 < achow101> #topic Fuzzing WG Update (dergoegge)
07:11 < achow101> (if nothing is said for a minute, i'm moving on)
07:11 < Chris_Stewart_5> :+1:
07:11 -!- ne0h_ [~natur@179.214.112.248] has joined #bitcoin-core-dev
07:12 -!- virtu [~virtu@user/virtu] has joined #bitcoin-core-dev
07:12 < darosior> hi
07:12 < _aj_> (maybe s/#topic/#skipping/ if the leader(s) didn't say hi?)
07:12 < dergoegge> hi
07:12 < dergoegge> no updates
07:12 < achow101> #topic Kernel WG Update (TheCharlatan)
07:12 < sipa> `hi!
07:12 < sdaftuar> hi
07:12 < lightlike> (or maybe have only those groups report something that have something new to report, instead of going through the entire list each week?)
07:12 < virtu> hi
07:13 < TheCharlatan> no updates, just brushing up #30595
07:13 <@gribble> https://github.com/bitcoin/bitcoin/issues/30595 | kernel: Introduce initial C header API by TheCharlatan · Pull Request #30595 · bitcoin/bitcoin · GitHub
07:13 < achow101> #topic Benchmarking WG Update (josibake, l0rinc)
07:14 -!- VonNaturAustreVe [~natur@user/vonnaturaustreve] has quit [Ping timeout: 252 seconds]
07:14 < jonatack> (right, or ones that have something to report open a topic before the meeting)
07:14 < achow101> #topic Silent Payments WG Update (josibake, RubenSomsen)
07:14 < abubakarsadiq> +1 jonatack 
07:15 < achow101> #topic Cluster Mempool WG Update (sdaftuar)
07:15 < sdaftuar> hi --
07:16 < laanwj> i think asking every group makes sense, it kind of keeps a pace in updates, though ofc not necessarily every week
07:16 < sdaftuar> as a reminder, the tracking issue is #30289
07:16 <@gribble> https://github.com/bitcoin/bitcoin/issues/30289 | Cluster mempool tracking issue · Issue #30289 · bitcoin/bitcoin · GitHub
07:16 < TheCharlatan> +1 laanwj
07:16 < sdaftuar> i recently opened #31122 which changes the mempool interface for adding transactions. that PR is getting some review already
07:16 < sipa> now updated with a dependency graph about dependency graph code
07:16 <@gribble> https://github.com/bitcoin/bitcoin/issues/31122 | cluster mempool: Implement changeset interface for mempool by sdaftuar · Pull Request #31122 · bitcoin/bitcoin · GitHub
07:17 < 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
07:17 < sipa> any week now
07:17 < achow101> soon(tm)
07:18 < achow101> #topic MuSig2 WG Update (achow101)
07:18 < achow101> waiting for libsecp to do a release with the MuSig2 module
07:18 < sipa> any week now
07:19 < achow101> also working through a couple of rebase issues in #29675
07:19 <@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
07:19 < achow101> will perhaps try to split it up to make it easier to review
07:19 < achow101> #topic Legacy Wallet Removal WG Update (achow101)
07:20 < achow101> waiting for review of #30328
07:20 <@gribble> https://github.com/bitcoin/bitcoin/issues/30328 | wallet: Remove IsMine from migration code by achow101 · Pull Request #30328 · bitcoin/bitcoin · GitHub
07:20 < achow101> Last step before final PR #28710
07:20 <@gribble> https://github.com/bitcoin/bitcoin/issues/28710 | Remove the legacy wallet and BDB dependency by achow101 · Pull Request #28710 · bitcoin/bitcoin · GitHub
07:20 < achow101> can also try to split that too if it's too big
07:20 -!- marcofleon [~marcofleo@87.249.134.130] has joined #bitcoin-core-dev
07:20 < achow101> #topic Multiprocess WG Update (ryanofsky)
07:22 -!- Emc99 [~Emc99@212.129.81.197] has quit [Quit: Client closed]
07:22 < achow101> #topic Monitoring WG Update (b10c)
07:23 < achow101> That's it for working groups. I'll try to think about how we can improve this for next week, suggestions welcome.
07:23 < jonatack> "Last week at CoreDev, we had a discussion about priority projects and how they don't seem to be working anymore."
07:23 < jonatack> Was there discussion about *why*
07:23 < achow101> jonatack: yes
07:23 < Chris_Stewart_5> I like _aj_ suggestion of if no one from the wg says 'hi' we skip
07:24 < BlueMatt[m]> any other topics or should we talk about mining?
07:24 < achow101> ajonas will post notes of the meeting or something like that soon(tm)
07:24 < jonatack> achow101: and?
07:24 < achow101> #topic Ad-hoc high priority for review
07:24 < achow101> Anything to add or remove from https://github.com/orgs/bitcoin/projects/1/views/4
07:24 < 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
07:25 <@gribble> https://github.com/bitcoin/bitcoin/issues/30116 | p2p: Fill reconciliation sets (Erlay) attempt 2 by sr-gi · Pull Request #30116 · bitcoin/bitcoin · GitHub
07:25 < jonatack> why not have that discussion at the irc meeting?
07:25 < ajonas> jonatack: I will write that up
07:26 < 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?
07:26 -!- ne0h_ [~natur@179.214.112.248] has quit [Quit: Leaving]
07:27 < sr_gi[m]> Sorry, looks like my messages didn't go through for the Erlay update
07:27 < sipa> sr_gi[m]: we read you loud and clear now
07:28 < 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)
07:28 < 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
07:29 < ajonas> I led the discussion on the changes to priority projects. I’m happy to speak further with whoever is interested.
07:29 < cfields> hi
07:29 < 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
07:29 < jonatack> (same for review discussions like that one...why take them to private forums?)
07:29 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-dev
07:30 < ajonas> It’s clear they were ineffective and so we discussed changes. There is nothing precluding you from participating in them.
07:30 < jonatack> ajonas: the interesting question is *why* they were ineffective
07:30 < jonatack> imho
07:31 < laanwj> no one knew why, it was just noticed
07:31 < ajonas> Yes. I will write that up as promised above.
07:31 < 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.
07:31 < 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
07:32 < achow101> so we have something that works all the time
07:32 < 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
07:32 < jonatack> one starting point might be to ask, what process initiatives *have* worked long-term
07:32 < jonatack> sustainably
07:32 < achow101> that is what was discussed
07:32 -!- Emc99 [~Emc99@212.129.81.197] has joined #bitcoin-core-dev
07:33 < 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
07:33 < achow101> as opposed to irc where people frequently talk simultaneously the typing delay results in some confusing and information loss
07:33 < jonatack> achow101: my opinion is that opening a topic at the open, public weekly meeting is ideal for discussions like that
07:33 < achow101> noted
07:34 < laanwj> also, people tend to attend coredevs in larger numbers than weekly IRC meetings
07:34 < achow101> jonatack: that is why we're talking about it now
07:35 < achow101> but having an initial discussion outside of this meeting makes it easier for most people to be on the same page
07:35 < laanwj> Matt really wants to discuss the mining topic lets go :)
07:35 < jonatack> i wonder if any of the process initiatives have stuck long-term
07:36 < achow101> #topic mining (BlueMatt)
07:36 < 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 🤷‍♂️
07:36 < jonatack> and if not, consider why that is that case
07:36 < 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.
07:36 < 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
07:36 < BlueMatt[m]> have a role that so that’s the way it went.
07:36 < 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.
07:36 < 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
07:36 < BlueMatt[m]> goals that went into it that seem to have been totally ignored here.
07:36 < 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,
07:36 < 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.
07:36 < achow101> Sjors does not appear to be here so idk how much discussion is going to happen
07:36 < 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
07:36 < BlueMatt[m]> the future which ideally it would even if just not in the first release).
07: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.
07:36 < 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
07:36 < BlueMatt[m]> efficiency gain that Sv2 was proposing here was thrown out kinda boggles my mind.
07:36 < 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”.
07:37 < BlueMatt[m]> the decisions seem to have been much broader than sjors
07:37 < BlueMatt[m]> though I intend to speak to him in atlanta today/tomorrow
07:37 < BlueMatt[m]> apparently he's there
07:37 < sipa> BlueMatt[m]: we did have a long discussion about this topic at coredev
07:37 < laanwj> would have been better to have Sjors here with this topic though
07:37 < BlueMatt[m]> but the situation is quite FUBAR, so its worth highlighting here...
07:38 < 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 🤷‍♂️
07:38 < sipa> BlueMatt[m]: you're not being constructive here
07:38 < _aj_> is there some PR you're referring to?
07:38 < BlueMatt[m]> I'm not sure which PR it was, the protocol is already merged, however
07:39 < 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.
07:39 < 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
07:39 < achow101> _aj_: probably #30200
07:39 <@gribble> https://github.com/bitcoin/bitcoin/issues/30200 | Introduce Mining interface by Sjors · Pull Request #30200 · bitcoin/bitcoin · GitHub
07:39 < sipa> i think you're jumping to conclusions that the IPC protocol is (a) immutable (b) intended to be an external protocol
07:39 < _aj_> or #30440 or #30955 maybe?
07:39 < 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
07:39 <@gribble> https://github.com/bitcoin/bitcoin/issues/30440 | Have createNewBlock() return a BlockTemplate interface by Sjors · Pull Request #30440 · bitcoin/bitcoin · GitHub
07:39 <@gribble> https://github.com/bitcoin/bitcoin/issues/30955 | Mining interface: getCoinbaseMerklePath() and submitSolution() by Sjors · Pull Request #30955 · bitcoin/bitcoin · GitHub
07:40 < BlueMatt[m]> TheCharlatan: two notes: (a) the interface was not sufficient for use internally, but it sounds like that might change
07:40 < BlueMatt[m]> sipa: no, i was told explicitly it intends to be public now
07:40 < laanwj> if the interface is not sufficient, then that should be improved of course
07:40 < 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
07:40 < BlueMatt[m]> because if its "the public interface" then it *is* a replacement
07:40 < achow101> my recollection is that the sv2 stuff would still live under "Bitcoin Core" but not in the main repo
07:40 < sipa> BlueMatt[m]: some people have opinions, not everyone agrees on all the details, and nothing is set in stone
07:40 < laanwj> do weigh in on interface details then
07:40 < achow101> so having the interface facilitates that
07:41 < 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
07:41 < BlueMatt[m]> the immediate short-term issue is #31109
07:41 <@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
07:41 -!- pablomartin [~pablomart@103.214.46.191] has joined #bitcoin-core-dev
07:42 < BlueMatt[m]> which generally discusses the need to rewrite the protocol
07:42 < 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
07:42 < BlueMatt[m]> but it also almost certainly needs a bip, or at least a specification document in core
07:42 < 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
07:42 < 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
07:42 < BlueMatt[m]> sipa: I don't see why we should have two protocols that do the same thing and (hopefully end up) roughly equivalent?
07:43 < BlueMatt[m]> that seems like a lot of indirection and extra crap everyone needs to implement.
07:43 < 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.
07:43 < 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
07:43 < sipa> BlueMatt[m]: please, be constructive
07:43 < laanwj> ^^ that
07:43 < BlueMatt[m]> laanwj: ideally the protocol would be restructured to not be so DoS-able :)
07:43 < BlueMatt[m]> which it sounds like might happen on #31109
07:43 <@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
07:43 < achow101> BlueMatt[m]: because the point is not to have it be publicly exposed that anyone can connect to
07:44 < laanwj> Matt Corallo: sure! it's just that IPC is an interprocess interface, not a remote interface, and will never be
07:44 < achow101> and at least the pr that introduced it is just a refactoring of current stuff to get the ball rolling
07:44 < 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.
07:44 < BlueMatt[m]> at least that's what ive now repeatedly been told.
07:44 < sipa> BlueMatt[m]: again, you are jumping to conclusions
07:44 < BlueMatt[m]> no, I'm repeating what I've been told :)
07:44 < sipa> i'm sure some people hold that view
07:45 < achow101> BlueMatt[m]: stable and maintained != exposed to the internet and therefore needs all the stuff to deal with that
07:45 < laanwj> right
07:45 < 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?
07:46 < achow101> BlueMatt[m]: ... because it isn't designed as a rpc protocol to be exposed to the internet
07:46 < achow101> it's an ipc protocol
07:46 < TheCharlatan> yes
07:46 < 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
07:46 < sipa> BlueMatt[m]: i disagree
07:46 < achow101> maybe in like 30 years
07:46 < laanwj> that's where Sv2 comes in, as a standard that goes beyond bitcoin core
07:46 < 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
07:47 < BlueMatt[m]> could be done with netcat just copying all the messages from core, even, totally write-only
07:47 < 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!
07:47 < tdb3> hi
07:47 < BlueMatt[m]> my point is that once it supports sv2, it will be basically write-only
07:47 < BlueMatt[m]> so why not just let it be ~write-only (with one message to get the coinbase tx size)
07:47 < laanwj> IPC will also provide the interface for wallet, GUI,and so on, all semi-internal
07:47 < BlueMatt[m]> because once we have that exposing the same protocol with netcat is trivial :)
07:48 < 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
07:48 < BlueMatt[m]> I also generally think miners will refuse to use that - lower latency is lower latency, to them
07:48 < 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
07:48 < BlueMatt[m]> even though I think they're wrong and simplistic...
07:49 < 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
07:49 < 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"
07:49 < 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
07:49 < sipa> BlueMatt[m]: it'd be helpful if you'd review the code then
07:49 < 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.
07:50 < BlueMatt[m]> at least in structure
07:50 < 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?)
07:50 < laanwj> that's one reason why he'd like the Sv2 server to be in rust
07:50 < sipa> BlueMatt[m]: ffs, it does not
07:50 < laanwj> so all the people who want to avoid c++ can finally look at something :)
07:51 < BlueMatt[m]> laanwj: ha
07:51 < sipa> BlueMatt[m]: capnproto and IPC is how bitcoind and the sv2 implementation can talk
07:51 < achow101> BlueMatt[m]: No one except you wants this interface to be publicly exposed
07:51 < achow101> and no one is intending on doing that
07:51 < sipa> it could be implemented in rust even (which i've heard some ideas about)
07:51 < BlueMatt[m]> achow101: that's not what I was told? sjors told me explicitly it intends to be documented/public
07:51 < laanwj> documented, yes
07:51 < achow101> BlueMatt[m]: *publicly exposed to the internet
07:51 < laanwj> exposed, no
07:51 < BlueMatt[m]> but, again, if the interface exists and is semi-stable, people *will* use that
07:51 < BlueMatt[m]> right, so exposed is a separate question
07:52 < sipa> BlueMatt[m]: well Sjors[m] isn't here
07:52 < BlueMatt[m]> once this becomes the standard mining protocol we'll presumably drop the sv2 protocol
07:52 < 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
07:52 < sipa> i really don't see why
07:52 < cfields> how would it even be exposed?
07:52 < TheCharlatan> exposed meaning there is a unix socket you can connect to on the same system. Not a public port exposed to the internet.
07:52 < BlueMatt[m]> and then suggest people expose this by netcat, at least once its write-only and pretty safe to do :)
07:52 < 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
07:53 < achow101> so we should make it not write-only to prevent that :)
07:53 < 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?
07:53 < BlueMatt[m]> achow101: I don't think any sensible work-providing protocol would be anything but :p
07:53 < 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
07:53 < BlueMatt[m]> one message to get the coinbase tx length and then write-only
07:54 < 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
07:54 < BlueMatt[m]> laanwj: the current one isn't, but it needs to be rewritten for efficiency anyway.
07:54 < achow101> also, this interfaces thing likely would have happened anyways with the work on multiprocess
07:54 < BlueMatt[m]> sipa: right, that's basically my impression.
07:54 < achow101> since that is the direction the project is going in
07:54 < laanwj> wait, now you want to rewrite capnproto?  i...
07:55 < 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
07:55 < BlueMatt[m]> because that's what it is
07:55 < achow101> perhaps we should revisit this discussion when Sjors is here and the meeting notes are published
07:55 < BlueMatt[m]> irrespective of whether we want it to be or not
07:55 < laanwj> it's an internal interface to facilitate mining protocol implementations
07:55 < laanwj> not a Mining Protocol
07:56 < BlueMatt[m]> why would a pool not connect directly to it?
07:56 < 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?
07:56 < BlueMatt[m]> I don't see why anyone would use a proxy to translate one protocol into an equivalent one?
07:56 < laanwj> i don't think it's useful to discuss this further without Sjors here
07:56 < BlueMatt[m]> we can discuss it again next week when sjors is back
07:56 < laanwj> yea
07:56 < achow101> Any other topics to discuss?
07:57 < jonatack> Sjors[m]: you can add me to your working group
07:57 -!- marcofleon [~marcofleo@87.249.134.130] has quit [Quit: Client closed]
07:57 < jonatack> Helpful discussion (for my understanding at least), thank you BlueMatt[m] and everyone for doing it here
07:58 -!- marcofleon [~marcofleo@87.249.134.130] has joined #bitcoin-core-dev
08:00 < achow101> #endmeeting
08:00 < 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.
08:00 < cfields> gui/wallet as other obvious examples.
08:01 -!- Emc99 [~Emc99@212.129.81.197] has quit [Quit: Client closed]
08:05 < 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
08:11 < 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.
08: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.
08:47 -!- Guest1 [~Guest1@84-216-185-21.customers.ownit.se] has quit [Ping timeout: 256 seconds]
08:51 < 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 
08:51 < 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? 
08:52 < 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.
08:53 < 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'
08:54 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/0c79c343a9f2...dd92911732d4
08:54 < bitcoin-git> bitcoin/master 8523d8c furszy: ci: display logs of failed tests automatically
08:54 < bitcoin-git> bitcoin/master dd92911 merge-script: Merge bitcoin/bitcoin#31148: ci: display logs of failed unit tests automat...
08:54 < 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
09:03 -!- preimage [~halosghos@user/halosghost] has joined #bitcoin-core-dev
09:11 -!- brunoerg [~brunoerg@82.163.218.33] has quit []
09:14 -!- Guest45 [~Guest45@95-24-62-67.broadband.corbina.ru] has joined #bitcoin-core-dev
09:21 -!- zeropoint [~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
09:27 < 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
09:29 < laanwj> from what i understood the main worry is having to maintain another P2P-port like interface, with DoS robustness, encryption, etc etc
09:30 < laanwj> so yes if that is a misunderstanding it's one that's already held up a lot of progress
09:33 < 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
09:33 < 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
09:34 < 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
09:35 < 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
09:35 -!- pablomartin [~pablomart@103.214.46.191] has quit [Ping timeout: 265 seconds]
09:36 < 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
09:42 -!- Guest45 [~Guest45@95-24-62-67.broadband.corbina.ru] has quit [Quit: Client closed]
09:42 -!- cornfeedhobo [~cornfeedh@user/cornfeedhobo] has quit [Quit: ZNC - https://znc.in]
09:45 < laanwj> right just that it's a separate process communicating through ipc doesn't mean it can't be started automatically
09:45 -!- cornfeedhobo [~cornfeedh@user/cornfeedhobo] has joined #bitcoin-core-dev
09:45 -!- pablomartin [~pablomart@103.214.46.183] has joined #bitcoin-core-dev
09:50 < 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.
09:51 < laanwj> that's the problem then too... it's hard to warrant implementing something whose expectations are so unclear
09:53 < 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
09:54 < laanwj> in any case, i hope Sjors doesn't get demotivated
09:54 < sipa> indeed
09:57 -!- sdaftuar [~sdaftuar@user/sdaftuar] has quit [Quit: WeeChat 3.0]
09:57 -!- sdaftuar [~sdaftuar@user/sdaftuar] has joined #bitcoin-core-dev
09:58 -!- sdaftuar [~sdaftuar@user/sdaftuar] has quit [Client Quit]
09:58 -!- sdaftuar [~sdaftuar@user/sdaftuar] has joined #bitcoin-core-dev
10:00 -!- sdaftuar [~sdaftuar@user/sdaftuar] has quit [Client Quit]
10:10 -!- pablomartin [~pablomart@103.214.46.183] has quit [Ping timeout: 246 seconds]
10:21 -!- marcofleon [~marcofleo@87.249.134.130] has quit [Quit: Client closed]
10:21 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
10:30 -!- pablomartin [~pablomart@103.214.46.185] has joined #bitcoin-core-dev
10:31 < bitcoin-git> [bitcoin] achow101 pushed 13 commits to master: https://github.com/bitcoin/bitcoin/compare/dd92911732d4...c16e909b3e23
10:31 < bitcoin-git> bitcoin/master 66c9936 furszy: bench: add coverage for wallet migration process
10:31 < bitcoin-git> bitcoin/master f2541d0 furszy: wallet: batch MigrateToDescriptor() db transactions
10:31 < bitcoin-git> bitcoin/master 6052c78 furszy: wallet: decouple default descriptors creation from external signer setup
10:31 < 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
10:31 -!- sdaftuar [~sdaftuar@user/sdaftuar] has joined #bitcoin-core-dev
10:38 < 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 
10:38 < 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?
10:42 -!- sdaftuar1 [~sdaftuar@user/sdaftuar] has joined #bitcoin-core-dev
10:42 < sdaftuar1> exit
10:42 -!- sdaftuar1 [~sdaftuar@user/sdaftuar] has quit [Client Quit]
10:46 < sipa> gmaxwell: i agree with that
10:47 -!- sdaftuar [~sdaftuar@user/sdaftuar] has quit [Quit: WeeChat 3.0]
10:51 < achow101> anyone else finding that running ctest after compiling with clang and Debug mode takes a significantly longer time recently?
10:52 < achow101> seems to be stuck on Test #6: tests for 10 minutes longer than the next longest test
10:52 <@gribble> https://github.com/bitcoin/bitcoin/issues/6 | Treat wallet as a generic keystore · Issue #6 · bitcoin/bitcoin · GitHub
10:52 < achow101> clang in RelWithDebugcccccclbnfericrrcirujdhgtcnfujbvefnefbcrufdh
10:52 -!- sdaftuar [~sdaftuar@user/sdaftuar] has joined #bitcoin-core-dev
10:52 < achow101> oops
10:53 < achow101> clang with RelWithDebug doesn't take this long, and gcc doesn't either in both mods
10:53 < bitcoin-git> [bitcoin] achow101 pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/c16e909b3e23...74fb19317aec
10:53 < bitcoin-git> bitcoin/master e31bfb2 Lőrinc: refactor: Remove unrealistic simulation state
10:53 < bitcoin-git> bitcoin/master 46dfbf1 Lőrinc: refactor: Return optional of Coin in GetCoin
10:53 < bitcoin-git> bitcoin/master 4feaa28 Lőrinc: refactor: Rely on returned value of GetCoin instead of parameter
10:53 < 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
10:53 -!- sdaftuar [~sdaftuar@user/sdaftuar] has quit [Client Quit]
10:54 -!- sdaftuar [~sdaftuar@user/sdaftuar] has joined #bitcoin-core-dev
11:18 -!- ___nick___ [~quassel@82-132-214-35.dab.02.net] has joined #bitcoin-core-dev
11:19 -!- ___nick___ [~quassel@82-132-214-35.dab.02.net] has quit [Client Quit]
11:21 -!- ___nick___ [~quassel@82-132-214-35.dab.02.net] has joined #bitcoin-core-dev
11:39 < darosior> For the assumeutxo background sync, do we disable assumevalid?
12:03 < 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
12:05 -!- Talkless [~Talkless@mail.dargis.net] has quit [Remote host closed the connection]
12:06 -!- ___nick___ [~quassel@82-132-214-35.dab.02.net] has quit [Ping timeout: 260 seconds]
12:07 -!- ___nick___ [~quassel@82-132-214-35.dab.02.net] has joined #bitcoin-core-dev
12:12 -!- jlest [~jlest@user/jlest] has quit [Ping timeout: 265 seconds]
12:14 < 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
12:19 < instagibbs> cc sdaftuar glozow ^ 
12:25 < 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
12:25 < maflcko> achow101: Interesting. If it happened recently, can you bisect?
12:32 -!- Guest8 [~Guest94@2a09:bac2:395e:1c46::2d1:43] has joined #bitcoin-core-dev
12:33 -!- Guest8 [~Guest94@2a09:bac2:395e:1c46::2d1:43] has quit [Client Quit]
12:42 < achow101> Will try
13:04 -!- ___nick___ [~quassel@82-132-214-35.dab.02.net] has quit [Ping timeout: 264 seconds]
13:13 -!- jespada [~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net] has quit [Ping timeout: 252 seconds]
14:13 < 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.
14:17 < darosior> Yes. In fact i think it would be interesting to do check the signatures after IBD, akin to how assumeutxo performs background sync.
14:17 < darosior> (Which is what triggered my question, which i should probably answer by myself)
14:17 < sipa> not needing to ramp up and ramp down the signature validation threads may be a significant speedup
14:18 < sipa> even without batch validation
14:18 < gmaxwell> for long ago blocks like 2012-2015 not having the concurrency slog may help a lot.
14:19 < gmaxwell> darosior: exactly
14:19 < darosior> Because as it is i think that the `-assumevalid` model is less "trustless" than assumeutxo, which eventually verifies everything.
14:19 < 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.
14:21 < sipa> pretty sure there is plenty of space, but it may require a disk format change anyway for compatibility reasons
14:21 < 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)
14:21 < 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.
14:22 < 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. :)
14:22 < sipa> gmaxwell: absolutely
14:22 < 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
14:23 < sipa> but with the background sync existing anyway, there is no reason why it couldn't also validate signatures i think
14:23 < sipa> (of course, absent a assumeutxo-fetching P2P extension, it's unclear to me how many people will actually use assumeutxo...)
14:23 < 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
14:23 < 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.
14:24 < 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 
14:24 < gmaxwell> be worse, but skipping other stuff would be pointless for it.
14:25 < darosior> Yes.
14:31 -!- jirijakes [~jirijakes@118.150.148.23] has quit [Ping timeout: 255 seconds]
14:31 < 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
14:31 < sipa> reorgs and bip30 shenanigans complicate this further
14:33 < 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.
14:33 < sipa> indeed
14:37 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Remote host closed the connection]
14:38 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-dev
14:43 < 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 
14:43 < 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.
14:43 < gmaxwell> )
14:47 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Remote host closed the connection]
15:00 -!- preimage [~halosghos@user/halosghost] has quit [Quit: WeeChat 4.4.2]
15:01 < bitcoin-git> [bitcoin] achow101 pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/74fb19317aec...7640cfdd6249
15:01 < bitcoin-git> bitcoin/master f0130ab Lőrinc: doc: replace `-?` with `-h` for bench_bitcoin help
15:01 < bitcoin-git> bitcoin/master 33a28e2 Lőrinc: Change default help arg to `-help` and mention `-h` and `-?` as alternativ...
15:01 < bitcoin-git> bitcoin/master 7640cfd Ava Chow: Merge bitcoin/bitcoin#31118: doc: replace `-?` with `-h` and `-help`
15:01 < 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
15:08 < bitcoin-git> [bitcoin] achow101 pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/7640cfdd6249...947f2925d55f
15:08 < bitcoin-git> bitcoin/master 9bb92c0 Hodlinator: util: Remove RandAddSeedPerfmon
15:08 < bitcoin-git> bitcoin/master 947f292 Ava Chow: Merge bitcoin/bitcoin#31124: util: Remove RandAddSeedPerfmon
15:08 < bitcoin-git> [bitcoin] achow101 merged pull request #31124: util: Remove RandAddSeedPerfmon (master...2024/10/rm_RandAddSeedPerfmon) https://github.com/bitcoin/bitcoin/pull/31124
15:35 -!- kevkevin [~kevkevin@2607:fb90:9b30:db8c:9ca9:3143:b5ff:8610] has joined #bitcoin-core-dev
16:00 -!- S3RK_ [~S3RK@user/s3rk] has joined #bitcoin-core-dev
16:03 -!- S3RK [~S3RK@user/s3rk] has quit [Ping timeout: 265 seconds]
16:38 -!- pablomartin [~pablomart@103.214.46.185] has quit [Ping timeout: 252 seconds]
16:40 -!- kevkevin [~kevkevin@2607:fb90:9b30:db8c:9ca9:3143:b5ff:8610] has quit [Remote host closed the connection]
16:41 -!- kevkevin [~kevkevin@2607:fb90:9b30:db8c:9ca9:3143:b5ff:8610] has joined #bitcoin-core-dev
16:43 -!- kevkevin [~kevkevin@2607:fb90:9b30:db8c:9ca9:3143:b5ff:8610] has quit [Remote host closed the connection]
17:05 -!- __DuBPiRaTe__ [~E_bomb@2600:6c50:7f7f:d89a:2ecf:67ff:fe08:b362] has joined #bitcoin-core-dev
17:06 -!- zeropoint [~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net] has quit [Quit: leaving]
17:29 -!- kevkevin [~kevkevin@2607:fb90:9b30:db8c:9ca9:3143:b5ff:8610] has joined #bitcoin-core-dev
17:33 -!- kevkevin [~kevkevin@2607:fb90:9b30:db8c:9ca9:3143:b5ff:8610] has quit [Ping timeout: 252 seconds]
17:42 -!- adil [~Thunderbi@2402:d000:8134:2758:6c36:91a6:c519:3984] has joined #bitcoin-core-dev
17:50 -!- adil [~Thunderbi@2402:d000:8134:2758:6c36:91a6:c519:3984] has quit [Ping timeout: 248 seconds]
18:43 -!- kevkevin [~kevkevin@2601:243:197e:8f10:45bb:1ea8:b84b:9be] has joined #bitcoin-core-dev
18:51 -!- kevkevin [~kevkevin@2601:243:197e:8f10:45bb:1ea8:b84b:9be] has quit [Remote host closed the connection]
19:12 -!- gribble [~gribble@bitcoin/bot/gribble] has quit [Remote host closed the connection]
19:19 -!- gribble [~gribble@bitcoin/bot/gribble] has joined #bitcoin-core-dev
19:19 -!- mode/#bitcoin-core-dev [+o gribble] by ChanServ
19:38 -!- adil [~Thunderbi@2402:d000:8134:2758:6c36:91a6:c519:3984] has joined #bitcoin-core-dev
19:56 -!- adil [~Thunderbi@2402:d000:8134:2758:6c36:91a6:c519:3984] has quit [Quit: adil]
20:11 -!- __DuBPiRaTe__ [~E_bomb@2600:6c50:7f7f:d89a:2ecf:67ff:fe08:b362] has quit [Quit: Leaving]
20:52 -!- kevkevin [~kevkevin@c-73-111-168-5.hsd1.il.comcast.net] has joined #bitcoin-core-dev
20:57 -!- kevkevin [~kevkevin@c-73-111-168-5.hsd1.il.comcast.net] has quit [Ping timeout: 265 seconds]
21:01 -!- cmirror [~cmirror@4.53.92.114] has quit [Remote host closed the connection]
21:01 -!- cmirror [~cmirror@4.53.92.114] has joined #bitcoin-core-dev
21:25 -!- sdaftuar [~sdaftuar@user/sdaftuar] has quit [Read error: Connection reset by peer]
21:25 -!- sdaftuar [~sdaftuar@user/sdaftuar] has joined #bitcoin-core-dev
21:25 -!- sdaftuar [~sdaftuar@user/sdaftuar] has quit [Read error: Connection reset by peer]
21:26 -!- sdaftuar [~sdaftuar@user/sdaftuar] has joined #bitcoin-core-dev
21:44 -!- elichai2 [sid212594@id-212594.hampstead.irccloud.com] has quit [Ping timeout: 252 seconds]
21:45 -!- elichai2 [sid212594@id-212594.hampstead.irccloud.com] has joined #bitcoin-core-dev
22:01 -!- emcy__ [~emcy@148.252.129.209] has joined #bitcoin-core-dev
22:04 -!- mcey_ [~emcy@148.252.129.209] has quit [Ping timeout: 245 seconds]
23:17 -!- adil [~Thunderbi@2402:d000:8134:2758:f1be:5afc:62d0:fbcb] has joined #bitcoin-core-dev
23:20 -!- adil [~Thunderbi@2402:d000:8134:2758:f1be:5afc:62d0:fbcb] has quit [Client Quit]
23:29 < bitcoin-git> [gui-qml] jarolrod opened pull request #427: Introduce Signal Based Navigation Model to have Self-Contained Pages (main...contain-pages) https://github.com/bitcoin-core/gui-qml/pull/427
23:33 < bitcoin-git> [gui-qml] jarolrod opened pull request #428: Migrate to PageStack's (main...pagestack-migration) https://github.com/bitcoin-core/gui-qml/pull/428
--- Log closed Fri Oct 25 00:00:30 2024