14:00:25 <achow101> #startmeeting 
14: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
14:00:38 <hebasto> hi
14:00:39 <TheCharlatan> hi
14:00:39 <jonatack> hi
14:00:39 <brunoerg> hi
14:00:41 <furszy> hi
14:01:02 <Chris_Stewart_5> hi
14:01:24 <achow101> There is 1 pre-proposed meeting topics this week. Any last minute ones to add?
14:01:45 <lightlike> Hi
14:02:27 <achow101> #topic Working Groups (achow101)
14: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.
14: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
14:04:22 <laanwj> hi
14:04:42 <BlueMatt[m]> I’d like to discuss sv2 and the new bitcoin core nih mining protocol.
14:04:47 <abubakarsadiq> Hi
14:04:54 <achow101> https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Working-Groups
14:05:52 <achow101> so I guess we can go down this list and do working group updates?
14:06:24 <laanwj> sgtm
14:07:09 <TheCharlatan> I hope more people are here than said hi :P
14:07:19 <achow101> guess we'll find out
14:07:28 <glozow> hi
14:07:41 <stickies-v> hi
14:07:41 <achow101> actually, first, any working groups to add?
14:07:42 <glozow> do i understand correctly that table is editable?
14:07:46 <achow101> yes
14:08:15 <glozow> i may add something, but not this week, if that’s ok
14:08:20 <achow101> ok
14:08:33 <glozow> thanks
14:08:37 <achow101> #topic Erlay WG Update (sr_gi, marcofleon)
14:09:02 <_aj_> (can we add links to tracking PR or similar summary page?)
14:09:20 <achow101> _aj_: sure
14:09:25 <jonatack> quite a few groups to report once per week...perhaps biweekly updates?
14:09:46 <jonatack> (half of them each week)
14:10:19 <Chris_Stewart_5> Maybe talk process stuff at the end of the updates? I have some Q's myself
14:11:11 <achow101> #topic Fuzzing WG Update (dergoegge)
14:11:21 <achow101> (if nothing is said for a minute, i'm moving on)
14:11:32 <Chris_Stewart_5> :+1:
14:12:10 <darosior> hi
14:12:12 <_aj_> (maybe s/#topic/#skipping/ if the leader(s) didn't say hi?)
14:12:13 <dergoegge> hi
14:12:16 <dergoegge> no updates
14:12:18 <achow101> #topic Kernel WG Update (TheCharlatan)
14:12:33 <sipa> `hi!
14:12:38 <sdaftuar> hi
14: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?)
14:12:42 <virtu> hi
14:13:03 <TheCharlatan> no updates, just brushing up #30595
14:13:05 <gribble> https://github.com/bitcoin/bitcoin/issues/30595 | kernel: Introduce initial C header API by TheCharlatan · Pull Request #30595 · bitcoin/bitcoin · GitHub
14:13:23 <achow101> #topic Benchmarking WG Update (josibake, l0rinc)
14:14:21 <jonatack> (right, or ones that have something to report open a topic before the meeting)
14:14:26 <achow101> #topic Silent Payments WG Update (josibake, RubenSomsen)
14:14:42 <abubakarsadiq> +1 jonatack
14:15:31 <achow101> #topic Cluster Mempool WG Update (sdaftuar)
14:15:50 <sdaftuar> hi --
14:16:05 <laanwj> i think asking every group makes sense, it kind of keeps a pace in updates, though ofc not necessarily every week
14:16:08 <sdaftuar> as a reminder, the tracking issue is #30289
14:16:09 <gribble> https://github.com/bitcoin/bitcoin/issues/30289 | Cluster mempool tracking issue · Issue #30289 · bitcoin/bitcoin · GitHub
14:16:37 <TheCharlatan> +1 laanwj
14:16:42 <sdaftuar> i recently opened #31122 which changes the mempool interface for adding transactions. that PR is getting some review already
14:16:42 <sipa> now updated with a dependency graph about dependency graph code
14: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
14: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
14:17:39 <sipa> any week now
14:17:45 <achow101> soon(tm)
14:18:31 <achow101> #topic MuSig2 WG Update (achow101)
14:18:43 <achow101> waiting for libsecp to do a release with the MuSig2 module
14:18:48 <sipa> any week now
14:19:04 <achow101> also working through a couple of rebase issues in #29675
14: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
14:19:13 <achow101> will perhaps try to split it up to make it easier to review
14:19:25 <achow101> #topic Legacy Wallet Removal WG Update (achow101)
14:20:05 <achow101> waiting for review of #30328
14:20:07 <gribble> https://github.com/bitcoin/bitcoin/issues/30328 | wallet: Remove IsMine from migration code by achow101 · Pull Request #30328 · bitcoin/bitcoin · GitHub
14:20:19 <achow101> Last step before final PR #28710
14: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
14:20:35 <achow101> can also try to split that too if it's too big
14:20:54 <achow101> #topic Multiprocess WG Update (ryanofsky)
14:22:09 <achow101> #topic Monitoring WG Update (b10c)
14: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.
14:23:29 <jonatack> "Last week at CoreDev, we had a discussion about priority projects and how they don't seem to be working anymore."
14:23:41 <jonatack> Was there discussion about *why*
14:23:55 <achow101> jonatack: yes
14:23:57 <Chris_Stewart_5> I like _aj_ suggestion of if no one from the wg says 'hi' we skip
14:24:03 <BlueMatt[m]> any other topics or should we talk about mining?
14:24:17 <achow101> ajonas will post notes of the meeting or something like that soon(tm)
14:24:18 <jonatack> achow101: and?
14:24:54 <achow101> #topic Ad-hoc high priority for review
14:24:54 <achow101> Anything to add or remove from https://github.com/orgs/bitcoin/projects/1/views/4
14: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
14: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
14:25:34 <jonatack> why not have that discussion at the irc meeting?
14:25:51 <ajonas> jonatack: I will write that up
14: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?
14:27:22 <sr_gi[m]> Sorry, looks like my messages didn't go through for the Erlay update
14:27:37 <sipa> sr_gi[m]: we read you loud and clear now
14: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)
14: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
14:29:25 <ajonas> I led the discussion on the changes to priority projects. I’m happy to speak further with whoever is interested.
14:29:41 <cfields> hi
14: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
14:29:49 <jonatack> (same for review discussions like that one...why take them to private forums?)
14:30:07 <ajonas> It’s clear they were ineffective and so we discussed changes. There is nothing precluding you from participating in them.
14:30:50 <jonatack> ajonas: the interesting question is *why* they were ineffective
14:30:58 <jonatack> imho
14:31:11 <laanwj> no one knew why, it was just noticed
14:31:11 <ajonas> Yes. I will write that up as promised above.
14: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.
14: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
14:32:08 <achow101> so we have something that works all the time
14: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
14:32:15 <jonatack> one starting point might be to ask, what process initiatives *have* worked long-term
14:32:26 <jonatack> sustainably
14:32:43 <achow101> that is what was discussed
14: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
14:33:41 <achow101> as opposed to irc where people frequently talk simultaneously the typing delay results in some confusing and information loss
14:33:53 <jonatack> achow101: my opinion is that opening a topic at the open, public weekly meeting is ideal for discussions like that
14:33:59 <achow101> noted
14:34:00 <laanwj> also, people tend to attend coredevs in larger numbers than weekly IRC meetings
14:34:31 <achow101> jonatack: that is why we're talking about it now
14:35:00 <achow101> but having an initial discussion outside of this meeting makes it easier for most people to be on the same page
14:35:44 <laanwj> Matt really wants to discuss the mining topic lets go :)
14:35:53 <jonatack> i wonder if any of the process initiatives have stuck long-term
14:36:00 <achow101> #topic mining (BlueMatt)
14: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 🤷‍♂️
14:36:13 <jonatack> and if not, consider why that is that case
14: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.
14: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
14:36:21 <BlueMatt[m]> have a role that so that’s the way it went.
14: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.
14: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
14:36:24 <BlueMatt[m]> goals that went into it that seem to have been totally ignored here.
14: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,
14: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.
14:36:29 <achow101> Sjors does not appear to be here so idk how much discussion is going to happen
14: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
14:36:31 <BlueMatt[m]> the future which ideally it would even if just not in the first release).
14: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.
14: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
14:36:39 <BlueMatt[m]> efficiency gain that Sv2 was proposing here was thrown out kinda boggles my mind.
14: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”.
14:37:05 <BlueMatt[m]> the decisions seem to have been much broader than sjors
14:37:14 <BlueMatt[m]> though I intend to speak to him in atlanta today/tomorrow
14:37:20 <BlueMatt[m]> apparently he's there
14:37:29 <sipa> BlueMatt[m]: we did have a long discussion about this topic at coredev
14:37:30 <laanwj> would have been better to have Sjors here with this topic though
14:37:39 <BlueMatt[m]> but the situation is quite FUBAR, so its worth highlighting here...
14: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 🤷‍♂️
14:38:26 <sipa> BlueMatt[m]: you're not being constructive here
14:38:39 <_aj_> is there some PR you're referring to?
14:38:54 <BlueMatt[m]> I'm not sure which PR it was, the protocol is already merged, however
14: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.
14: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
14:39:30 <achow101> _aj_: probably #30200
14:39:33 <gribble> https://github.com/bitcoin/bitcoin/issues/30200 | Introduce Mining interface by Sjors · Pull Request #30200 · bitcoin/bitcoin · GitHub
14:39:50 <sipa> i think you're jumping to conclusions that the IPC protocol is (a) immutable (b) intended to be an external protocol
14:39:55 <_aj_> or #30440 or #30955 maybe?
14: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
14:39:57 <gribble> https://github.com/bitcoin/bitcoin/issues/30440 | Have createNewBlock() return a BlockTemplate interface by Sjors · Pull Request #30440 · bitcoin/bitcoin · GitHub
14:39:59 <gribble> https://github.com/bitcoin/bitcoin/issues/30955 | Mining interface: getCoinbaseMerklePath() and submitSolution() by Sjors · Pull Request #30955 · bitcoin/bitcoin · GitHub
14:40:03 <BlueMatt[m]> TheCharlatan: two notes: (a) the interface was not sufficient for use internally, but it sounds like that might change
14:40:14 <BlueMatt[m]> sipa: no, i was told explicitly it intends to be public now
14:40:27 <laanwj> if the interface is not sufficient, then that should be improved of course
14: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
14:40:50 <BlueMatt[m]> because if its "the public interface" then it *is* a replacement
14:40:50 <achow101> my recollection is that the sv2 stuff would still live under "Bitcoin Core" but not in the main repo
14:40:51 <sipa> BlueMatt[m]: some people have opinions, not everyone agrees on all the details, and nothing is set in stone
14:40:52 <laanwj> do weigh in on interface details then
14:40:56 <achow101> so having the interface facilitates that
14: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
14:41:50 <BlueMatt[m]> the immediate short-term issue is #31109
14: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
14:42:02 <BlueMatt[m]> which generally discusses the need to rewrite the protocol
14: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
14:42:17 <BlueMatt[m]> but it also almost certainly needs a bip, or at least a specification document in core
14: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
14: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
14: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?
14:43:01 <BlueMatt[m]> that seems like a lot of indirection and extra crap everyone needs to implement.
14: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.
14: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
14:43:21 <sipa> BlueMatt[m]: please, be constructive
14:43:23 <laanwj> ^^ that
14:43:23 <BlueMatt[m]> laanwj: ideally the protocol would be restructured to not be so DoS-able :)
14:43:33 <BlueMatt[m]> which it sounds like might happen on #31109
14: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
14:43:56 <achow101> BlueMatt[m]: because the point is not to have it be publicly exposed that anyone can connect to
14:44:11 <laanwj> Matt Corallo: sure! it's just that IPC is an interprocess interface, not a remote interface, and will never be
14:44:15 <achow101> and at least the pr that introduced it is just a refactoring of current stuff to get the ball rolling
14: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.
14:44:38 <BlueMatt[m]> at least that's what ive now repeatedly been told.
14:44:44 <sipa> BlueMatt[m]: again, you are jumping to conclusions
14:44:58 <BlueMatt[m]> no, I'm repeating what I've been told :)
14:45:00 <sipa> i'm sure some people hold that view
14:45:23 <achow101> BlueMatt[m]: stable and maintained != exposed to the internet and therefore needs all the stuff to deal with that
14:45:36 <laanwj> right
14: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?
14:46:06 <achow101> BlueMatt[m]: ... because it isn't designed as a rpc protocol to be exposed to the internet
14:46:13 <achow101> it's an ipc protocol
14:46:14 <TheCharlatan> yes
14: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
14:46:31 <sipa> BlueMatt[m]: i disagree
14:46:34 <achow101> maybe in like 30 years
14:46:35 <laanwj> that's where Sv2 comes in, as a standard that goes beyond bitcoin core
14: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
14:47:03 <BlueMatt[m]> could be done with netcat just copying all the messages from core, even, totally write-only
14: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!
14:47:13 <tdb3> hi
14:47:19 <BlueMatt[m]> my point is that once it supports sv2, it will be basically write-only
14:47:36 <BlueMatt[m]> so why not just let it be ~write-only (with one message to get the coinbase tx size)
14:47:43 <laanwj> IPC will also provide the interface for wallet, GUI,and so on, all semi-internal
14:47:49 <BlueMatt[m]> because once we have that exposing the same protocol with netcat is trivial :)
14: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
14:48:40 <BlueMatt[m]> I also generally think miners will refuse to use that - lower latency is lower latency, to them
14: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
14:48:48 <BlueMatt[m]> even though I think they're wrong and simplistic...
14: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
14: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"
14: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
14:49:30 <sipa> BlueMatt[m]: it'd be helpful if you'd review the code then
14: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.
14:50:03 <BlueMatt[m]> at least in structure
14: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?)
14:50:43 <laanwj> that's one reason why he'd like the Sv2 server to be in rust
14:50:49 <sipa> BlueMatt[m]: ffs, it does not
14:50:59 <laanwj> so all the people who want to avoid c++ can finally look at something :)
14:51:10 <BlueMatt[m]> laanwj: ha
14:51:11 <sipa> BlueMatt[m]: capnproto and IPC is how bitcoind and the sv2 implementation can talk
14:51:13 <achow101> BlueMatt[m]: No one except you wants this interface to be publicly exposed
14:51:27 <achow101> and no one is intending on doing that
14:51:27 <sipa> it could be implemented in rust even (which i've heard some ideas about)
14:51:33 <BlueMatt[m]> achow101: that's not what I was told? sjors told me explicitly it intends to be documented/public
14:51:43 <laanwj> documented, yes
14:51:44 <achow101> BlueMatt[m]: *publicly exposed to the internet
14:51:47 <laanwj> exposed, no
14:51:51 <BlueMatt[m]> but, again, if the interface exists and is semi-stable, people *will* use that
14:51:56 <BlueMatt[m]> right, so exposed is a separate question
14:52:08 <sipa> BlueMatt[m]: well Sjors[m] isn't here
14:52:19 <BlueMatt[m]> once this becomes the standard mining protocol we'll presumably drop the sv2 protocol
14: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
14:52:27 <sipa> i really don't see why
14:52:31 <cfields> how would it even be exposed?
14: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.
14:52:39 <BlueMatt[m]> and then suggest people expose this by netcat, at least once its write-only and pretty safe to do :)
14: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
14:53:03 <achow101> so we should make it not write-only to prevent that :)
14: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?
14:53:34 <BlueMatt[m]> achow101: I don't think any sensible work-providing protocol would be anything but :p
14: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
14:53:42 <BlueMatt[m]> one message to get the coinbase tx length and then write-only
14: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
14:54:23 <BlueMatt[m]> laanwj: the current one isn't, but it needs to be rewritten for efficiency anyway.
14:54:27 <achow101> also, this interfaces thing likely would have happened anyways with the work on multiprocess
14:54:34 <BlueMatt[m]> sipa: right, that's basically my impression.
14:54:38 <achow101> since that is the direction the project is going in
14:54:48 <laanwj> wait, now you want to rewrite capnproto?  i...
14: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
14:55:24 <BlueMatt[m]> because that's what it is
14:55:29 <achow101> perhaps we should revisit this discussion when Sjors is here and the meeting notes are published
14:55:38 <BlueMatt[m]> irrespective of whether we want it to be or not
14:55:38 <laanwj> it's an internal interface to facilitate mining protocol implementations
14:55:46 <laanwj> not a Mining Protocol
14:56:04 <BlueMatt[m]> why would a pool not connect directly to it?
14: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?
14:56:22 <BlueMatt[m]> I don't see why anyone would use a proxy to translate one protocol into an equivalent one?
14:56:25 <laanwj> i don't think it's useful to discuss this further without Sjors here
14:56:44 <BlueMatt[m]> we can discuss it again next week when sjors is back
14:56:49 <laanwj> yea
14:56:56 <achow101> Any other topics to discuss?
14:57:00 <jonatack> Sjors[m]: you can add me to your working group
14:57:55 <jonatack> Helpful discussion (for my understanding at least), thank you BlueMatt[m] and everyone for doing it here
15:00:00 <achow101> #endmeeting