19:00:25 <wumpus> #startmeeting
19:00:25 <lightningbot> Meeting started Thu Sep 10 19:00:25 2020 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:25 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:30 <kanzure> hi
19:00:31 <achow101> hi
19:00:33 <jonasschnelli> hi
19:00:35 <hebasto> hi
19:00:36 <fjahr> hi
19:00:44 <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james
19:00:47 <wumpus> amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
19:01:01 <wumpus> two proposed meeting topics for today
19:01:02 <vasild> hi
19:01:06 <wumpus> strategies for removing recursive locking in the mempool (jnewbery), review the experience of 3 month bitcoin-core/gui repository (jonasschnelli)
19:01:06 <meshcollider> hi
19:01:23 <wumpus> any last minute topic proposals?
19:01:23 <jonatack> hi
19:02:36 <wumpus> #topic High priority for review
19:03:07 <wumpus> https://github.com/bitcoin/bitcoin/projects/8  11 blockers, 1 bugfix, 2 chasins concept ACK
19:03:24 <jonatack> #19845?
19:03:37 <gribble> https://github.com/bitcoin/bitcoin/issues/19845 | net: CNetAddr: add support to (un)serialize as ADDRv2 by vasild · Pull Request #19845 · bitcoin/bitcoin · GitHub
19:04:17 <meshcollider> Actually 10 now :) one was merged and hadn't been removed
19:04:27 <jnewbery> hi
19:04:48 <wumpus> jonatack: added
19:05:06 <meshcollider> #16378 pls
19:05:10 <gribble> https://github.com/bitcoin/bitcoin/issues/16378 | The ultimate send RPC by Sjors · Pull Request #16378 · bitcoin/bitcoin · GitHub
19:05:52 <achow101> #19077 please
19:06:00 <gribble> https://github.com/bitcoin/bitcoin/issues/19077 | wallet: Add sqlite as an alternative wallet database and use it for new descriptor wallets by achow101 · Pull Request #19077 · bitcoin/bitcoin · GitHub
19:06:12 <promag> #19033 for hp, ty
19:06:15 <gribble> https://github.com/bitcoin/bitcoin/issues/19033 | http: Release work queue after event base finish by promag · Pull Request #19033 · bitcoin/bitcoin · GitHub
19:06:21 <phantomcircuit> hi
19:06:52 * luke-jr pokes gribble
19:07:22 <wumpus> meshcollider, achow101  added
19:07:27 <wumpus> promag: already on there, right?
19:08:01 <jeremyrubin> i think so
19:08:58 <promag> indeed, I guess I have to name it "http: blocklist work queue..."
19:09:04 <wumpus> unless someone else just added it, but I vaguely remember it was already there
19:09:43 <wumpus> #topic Strategies for removing recursive locking in the mempool (jnewbery)
19:09:51 <wumpus> (https://github.com/bitcoin/bitcoin/pull/19872#issuecomment-688852261)
19:09:58 <jnewbery> Thanks wumpus
19:10:16 <jnewbery> gist here: https://gist.github.com/hebasto/072ad3a9370641b035a36d08607a3d34
19:10:53 <jnewbery> summary: RecusiveMutex is generally considered bad, and avoided if possible. It'd be nice to change the mempool's mutex from recursive to non-recursive
19:11:00 <wumpus> I think getting rid of the recursive locks is good, though, it seems changes are becoming increasingly risky
19:11:07 <wumpus> and involved
19:11:22 <jnewbery> There are different ways to do this, and hebasto would like some input on which way is preferred
19:11:23 <wumpus> we had all the low-hanging fruit I guess
19:12:00 <jnewbery> wumpus: i don't think so. I think there's a lot more low-hanging fruit (although cs_mempool isn't very low hanging)
19:12:33 <hebasto> tracking issue for all recursive mutexes #19303
19:12:35 <gribble> https://github.com/bitcoin/bitcoin/issues/19303 | Replace all of the RecursiveMutex instances with the Mutex ones · Issue #19303 · bitcoin/bitcoin · GitHub
19:12:40 <jeremyrubin> Probably makes more sense to have the locking external to the functions
19:12:55 <jeremyrubin> More general to e.g., calling a function in a for loop
19:13:01 <jnewbery> Two possible ways are making a lot more of the mempool functions require the lock, and make locking external to the mempool
19:13:03 <wumpus> "... two functions could be used - one that locks and another that does not..." yes, that's the common solution
19:13:26 <jnewbery> and the other way is having two versions of the function - one which requires the lock and one which takes the lock
19:13:31 <jnewbery> wumpus: right
19:13:32 <wumpus> moving locking external has its own risks
19:13:51 <hebasto> what risk?
19:13:52 <jeremyrubin> wumpus: if we use the clang safety annotations it's lesser, right?
19:13:55 <wumpus> having separate private "without lock" avoids that
19:13:57 <jnewbery> wumpus: I agree. Best to keep locking internal wherever possible
19:14:24 <vasild> "the locking mechanism used by a thread-safe class is part of its internal implementation" (from https://gist.github.com/hebasto/072ad3a9370641b035a36d08607a3d34#gistcomment-3448023)
19:14:32 * luke-jr stabs ISP
19:14:36 <sipa> ideally, locks are internal
19:14:37 <wumpus> hebasto: well, it goes against, the principle of encapsulation, knowledge of how to remove locks moves to outside the code
19:15:06 <wumpus> hebasto: at the least it makes reasoning more difficult
19:15:14 <hebasto> wumpus: agree
19:15:25 <sipa> if a lock is internal to a class, and the class never invokes a callback passed down from elsewhere while holding that lock, it even guarantees no deadlocks
19:15:35 <wumpus> lock annotations are not a replacement for that
19:16:30 <jnewbery> if locks can't always be internal, then making two versions of the public interface function makes it explicit where the function is called with the lock held and without.
19:16:49 <sipa> jnewbery: that's what CAddrMan does
19:16:59 <sipa> but i don't see how one conflicts with the other
19:17:04 <jeremyrubin> What about a type-safe (using newtype) pass lock guard in as arugment?
19:17:14 <jeremyrubin> That would have both safety properties
19:17:20 <sipa> jeremyrubin: it works, but imho it still reeks of bad design
19:17:28 <jeremyrubin> as there would only be one way to get a satisfying lock
19:17:33 <wumpus> I don't really like that, I hope that can be avoided
19:17:34 <promag> and I'd like to discuss for() { LOCK(cs); } VS { LOCK() for() {} }
19:18:11 <hebasto> how to name this two functions? some kind of suffix to distinguish them?
19:18:12 <jnewbery> sipa: I'm not saying they do. Ideally, all locks are internal. If they can't be and sometimes need to be held by the caller, make it explicit where that is by using Mutex and having two versions of public functions where needed.
19:18:20 <aj> promag: with or without performance benchmarks?
19:18:29 <wumpus> promag: well that depends on the granularity of the work, so locking overhad versus the loop body, and whether it's undesirable to hold the lock for long
19:18:31 <sipa> promag: grabbing an uncontended lock is ~100 cpu cycles
19:18:46 <jeremyrubin> hebasto: I'd do a type tag argument maybe; like atmoic primitives.
19:19:09 <jeremyrubin> but maybe that's overkill
19:19:25 <sipa> jnewbery: sorry, i misread what you suggested
19:20:00 <aj> jeremyrubin: void foo(int x); void foo(int x, LockAlreadyHeld h);  foo(3, LockAlreadyHeld()); // ?
19:20:21 <wumpus> I'm starting to understand Marcofalke's point now--this is a lot of work, conflicts with other changes, while we don't have a direct problem with RecursiveMutex
19:20:23 <aj> jeremyrubin: LockAlreadyHeld(cs_main); ?
19:20:26 <jeremyrubin> aj: Uh that can work yeah
19:20:28 <vasild> promag: I would say if the current code does one of that, we better have some proof that changing it is for the better.
19:20:39 <sdaftuar> wumpus: that is my gut reaction as well
19:21:11 <promag> aj: in simple cases not really
19:21:26 <sdaftuar> it would be nice to motivate this change with some new behavior we wish to implement, that woudl benefit from it?
19:21:30 <wumpus> if it helps to have a non-recursive mutex for future mempool changes it makes sense to do it, of course, but this seems a lot of design work for a pure refactor
19:21:34 <wumpus> sdaftuar: +1
19:21:41 <jeremyrubin> overall, same. It works as is.
19:22:20 <luke-jr> I suspect it actually might make future changes harder :x
19:22:39 <sipa> luke-jr: depends on how it's done, i think
19:22:48 <jeremyrubin> I think that's the motivation; if future changes are leaning more on the recursive mutexing we don't want to make them that way
19:22:51 <sipa> really usually cleaning up locking means cleaning up the boundary between interfaces
19:23:01 <sipa> and if that's a side effect, it may definitely make things easier
19:23:04 <promag> sipa: I'm taking about cs_main
19:23:05 <jnewbery> sipa: +1
19:23:10 <wumpus> sipa: yes, if it can make that clearer it's a good thing
19:23:10 <promag> wumpus: agree
19:23:14 <jnewbery> cs_main is something else entirely
19:23:30 <sipa> just doing a dumb "whatever necessary to avoid recursive locking" is unlikely to be beneficial
19:23:37 <wumpus> agree
19:24:14 <promag> vasild: agree
19:24:26 <sipa> but it's probably hard to speak very generically here
19:24:43 <jnewbery> I think adding a lock-not-held version of all public functions which may or may not hold a lock is a pretty trivial change
19:25:16 <promag> i'm meh with that approach
19:25:19 <jeremyrubin> It's kinda annoying for other patches if you have to change 2 func signatures
19:25:35 <wumpus> jnewbery: at least that can be done virtually mechanically which makes it easier to review
19:25:36 <jnewbery> I think changing the function to assert the lock is held and then adding locks outside the class _isn't_ a good change
19:25:53 <vasild> funcUnprotected() { do stuff; }; func() { LOCK(); funcUnprotected(); }
19:25:54 <sipa> jnewbery: that does not seem crazy, but it's easier to judge with code
19:26:11 <wumpus> jnewbery: +1
19:26:18 <sdaftuar> i'm a bit confused -- would some of those functions not be used?
19:26:30 <promag> jnewbery: IMO it's a good change if it comes with a follow up refactor
19:26:40 <luke-jr> I don't see what's wrong with func() that locks if necessary, but also works inside an external lock :x
19:26:55 <jnewbery> sdaftuar: you'd only add new functions where it may or may not already hold the lock
19:27:20 <jeremyrubin> luke-jr: I think that's basically a recursive lock
19:27:25 <sipa> luke-jr: it's a very abstract objection, but to me it is: code should be written to work inside our outside the private parts of a class that need locking
19:27:34 <vasild> luke-jr: that's like re-implementing recursive mutex
19:27:35 <jeremyrubin> the difference being maybe you can assert if you know you have lock already or not
19:27:53 <luke-jr> sipa: this does..?
19:27:55 <sipa> luke-jr: it's just hard to reason about the interface if you have code that works in both
19:28:10 <wumpus> hand rolling a recursive-ish mutex sounds even worse than simply using one
19:28:17 <sipa> please no
19:28:22 <nehan> the argument in https://gist.github.com/hebasto/072ad3a9370641b035a36d08607a3d34 for why RecursiveMutex is bad indicates why it's bad to use RecursiveMutex in the first place (it is a symptom of an underlying problem). i do not see how it explains the benefit of removing RecursiveMutex without addressing the underlying problem.
19:28:38 <sipa> nehan: +1
19:28:41 <nehan> which it sounds like what this dual-function thing is doing
19:28:58 <sipa> nehan: i think the dual function makes the interface layer explicit
19:29:44 <nehan> so the benefit of it is making a small (perhaps important) step towards making the interface more clear?
19:29:48 <luke-jr> my point wasn't to reinvent RM, but that RM has a use :p
19:29:52 <jnewbery> and by making it explicit, brings to attention what the underlying problem may be
19:29:58 <sipa> nehan: right, it makes it obvious where the problem is
19:30:02 <sipa> it doesn't fix it
19:30:06 <wumpus> nehan: yes, the general arguments against recursive mutex described there definitely make sense
19:30:08 <sdaftuar> so i think the right next step would be to precisely define what the interface ought ot be
19:30:17 <sdaftuar> and then we can work towards that
19:30:18 <jeremyrubin> It sounds like it might be worth to prepare this PR and not merge it
19:30:34 <jeremyrubin> Because if it indentifies what the problem is, then we can see if a fix can be built on it
19:30:39 <sdaftuar> refactoring without a design in mind seems bad to me
19:31:02 <jnewbery> sometimes it's not a problem to have a function that can be called with or without a lock. Sometimes you want to carry out multiple operations on an object atomically. That's not a problem, but it's always better to be explicit about what you're doing
19:32:18 <bitcoin-git> [13bitcoin] 15instagibbs opened pull request #19936: Test: batch rpc with params (06master...06batch_param) 02https://github.com/bitcoin/bitcoin/pull/19936
19:33:14 <promag> sipa: WITH_LOCK(..., ...) is already an indicator
19:33:25 <jnewbery> hebasto: did you have anything else that you wanted input on?
19:33:33 <vasild> I think we can/should make mempool.cs mutex private
19:33:51 <jnewbery> vasild: that's a lot of work
19:34:00 <jnewbery> and might not even be desirable
19:34:02 <hebasto> jnewbery: it seems all discussed. what is consensus?
19:34:21 <promag> vasild: lots of refactors right?
19:34:24 <vasild> IMO amount of work would be comparable to making it non-recursive
19:35:10 <jnewbery> vasild: not even close, I don't think. There are lots of places where we make multiple calls to the mempool atomically. Those would all need to be changed into higher-level interfaces to the mempool
19:35:12 <wumpus> vasild: at least that'd remove the problem of public functions needing the lock held
19:35:28 <wumpus> but yes, it's also much more work
19:35:54 <vasild> ok, my assessment could be wrong
19:36:10 <jeremyrubin> wild idea: mempool via message passing only?
19:36:24 <jnewbery> vasild: eg all of this would need to become a single call to the mempool: https://github.com/bitcoin/bitcoin/blob/564e1ab0f3dc573bd3ea60a80f6649c361243df9/src/rpc/blockchain.cpp#L1406-L1421
19:36:25 <jeremyrubin> Might be good as there are some proposals to make the mempool a separate entity
19:36:44 <jeremyrubin> and message passing based would cleanly separate internal details
19:37:01 <hebasto> vasild: that is possible
19:37:16 <vasild> jnewbery: yes, I looked into that, it would be one call that returns a struct holding all the data, not a big deal
19:38:14 <jonatack> i like sdaftuar's suggestion that it be motivated by new behavior or a clear idea of the desired design/interface
19:38:27 <jnewbery> vasild: maybe. It just feels like a much bigger change. If you had a branch that moved the lock to be totally internal, I'd be very interested to see it
19:38:40 <vasild> mempool.AtomicallyGiveMeYourStats(&pool_stats); ;-)
19:39:00 <vasild> jnewbery: no, I don't have
19:39:15 <aj> time for the gui repo topic?
19:39:24 <jeremyrubin> vasild: a mempool interior thread/workqueue with condvar for wake on return could implement that API :p
19:39:25 <wumpus> I guess it would be good to see an example of the various proposals and maybe re-discuss next week
19:39:46 <hebasto> wumpus: +1
19:39:51 <wumpus> if this is all worth it at all
19:40:03 <wumpus> maybe we're creaeting a problem where there's none
19:40:27 <wumpus> #topic Review the experience of 3 month bitcoin-core/gui repository (jonasschnelli)
19:40:39 <sdaftuar> i would reiterate that a design document for how the mempool would ideally interact with the rest of our software would be very helpful for evaulating any proposals
19:40:48 <jonasschnelli> I'd like to collect feedback on how well the separation of the GUI repository has been received.
19:41:16 <jonasschnelli> my feedback: it's seems still unclear how we merge things back to the main repository and if that has been documented.
19:41:23 <wumpus> yes, what's the plan for merging back the GUI changes?
19:41:32 <jonasschnelli> on top, the mix of PRs on both sides feels confusing to me.
19:41:54 <jnewbery> I think Marco has a script that merges them into both repositories simultaneously, no?
19:41:55 <jonasschnelli> Overall,... i would have prefered to split of the repository with a split off through a clean interface (process seperation in some ways)
19:42:08 <wumpus> I think it's nice to have GUI design discussions etc in the other repo
19:42:19 <jonasschnelli> jnewbery: could be. I don't know.
19:42:35 <jonasschnelli> Yes. I also like the split of the discussions and some GUI only PRs.
19:42:47 <jonasschnelli> I just don't know what burden we have when merging things back
19:42:58 <wumpus> it's sufficiently distinct from what happens in the main repo that that makes sense
19:43:05 <jonasschnelli> Also,... things that touch both "sides": still unclear how to handle that
19:43:16 <wumpus> I don't know either, looks like Marco Falke is missing for this discussion
19:43:22 <jonasschnelli> looks like
19:43:27 <promag> wumpus: most people just have to go to both repos.. it was a good change for those that want stay away from gui stuff
19:43:40 <jonasschnelli> However we go further, I think it would be nice to document the process more clear
19:44:29 <jnewbery> they seem to be pretty synchronized. The GUI repository is just one merge commit behind bitcoin/bitcoin
19:44:31 <jonasschnelli> Also unclear to me how we handle merge conflicts if we merge node stuff into the GUI repository
19:44:39 <jeremyrubin> jonasschnelli: +1 on process isolation being important for making the separation clearer
19:44:41 <luke-jr> did anyone ever get in touch with GitHub about the PR issues?
19:44:53 <jnewbery> jonasschnelli: they're the same commits
19:45:26 <jnewbery> there's no conflicts because it's always fast-forwards
19:45:28 <wumpus> jeremyrubin: IIRC there's a PR that does process isolation
19:45:29 <jonasschnelli> jnewbery: Right. I tihink its a non-issue as long as they stay in sync. Which I guess is a manual script
19:46:02 <jeremyrubin> wumpus: ryanofsky's right?
19:46:02 <michaelfolkson> I think the major concern is if review decreases with it being separate. I think people on the GUI repo need to regularly prod (cc) GUI reviewers who spend most of their time on the main repo.
19:46:22 <wumpus> ryanofsky is working on that #19461
19:46:25 <gribble> https://github.com/bitcoin/bitcoin/issues/19461 | multiprocess: Add bitcoin-gui -ipcconnect option by ryanofsky · Pull Request #19461 · bitcoin/bitcoin · GitHub
19:46:25 <wumpus> yes
19:46:33 <jonasschnelli> michaelfolkson: maybe only an initial issue. I think there are now also contributors stepping forward _because_ its GUI only
19:47:06 <hebasto> ^ and designers
19:47:07 <wumpus> jonasschnelli: exactly, though there's some overlap, it's also meant to get a different group of people involved
19:47:22 <michaelfolkson> But mainly designers right jonasschnelli? It needs normal Core reviewers too
19:48:03 <michaelfolkson> I think for design related review it is a material success so far
19:48:08 <wumpus> ideally we want more GUI contributors, improving the GUI, they don't necessarily need to get involved with the rest of the code
19:48:18 <jonasschnelli> michaelfolkson: Yes. Thats correct.
19:48:29 <jonasschnelli> It's a different complexity level (mostly). Also the risks are different.
19:48:36 <vasild> I think a separate GUI repository only makes sense as long as both repositories contain different chunks of software. Right now both contain the same, e.g. the gui repo contains bitcoind.cpp, net_processing.cpp, etc. Would it be possible to make only src/qt in the gui repo (and then make it a git submodule in the main one)?
19:48:45 <wumpus> a different kind of complexity to navigate at least
19:48:55 <jeremyrubin> wumpus: is there a framework for moving forward ryanofsky's work? last I checked it was still nack on capnproto?
19:49:15 <wumpus> I definitely found out I can't do it, I can't handle the subjectivity and bikeshedding involved :)
19:49:37 <jonasschnelli> vasild: this is a valid point
19:49:52 <jonasschnelli> wumpus : that. yes.
19:50:08 <wumpus> vasild: maybe, though it can't be built independently anymore then, it's harder for contributors
19:50:28 <hebasto> bikeshedding is a work for designers, no?
19:50:31 <yanmaani> Can't you refactor it to make the GUI an RPC client?
19:50:33 <vasild> hm, right, src/qt can't be build separately
19:50:50 <yanmaani> (and then optionally have it spawn a bitcoind)
19:50:55 <vasild> make make it compilable, libsrcqt.so :)
19:51:03 <jonasschnelli> yanmaani: I would also like to see that
19:51:16 <yanmaani> Then the GUI could indeed be moved to a separate repo
19:51:23 <jonasschnelli> but I guess we are drifting off-topic
19:51:24 <yanmaani> and you could have other people making other GUIs in other frameworks
19:51:26 <wumpus> yanmaani: that's what the multiprocess PR does, basically
19:51:28 <sipa> people tried that in 2012 or so, but it's terrible as RPC is query-response based, not asynchronous
19:51:46 <sipa> but the multiprocess work does this the right way
19:51:46 <jonasschnelli> sipa: we could use the long polling to make it faster though
19:51:47 <yanmaani> sipa: is RPC single-threaded?
19:51:48 <wumpus> yanmaani: (except it doesn't use JSON-RPC but its own RPC mechanism)
19:52:00 <promag> yanmaani: no
19:52:03 <wumpus> in any case ryanofsky's work already exists
19:52:10 <sipa> yanmaani: it would be more useful if you'd comment after you've spent some time looking at the code
19:52:21 <yanmaani> ok :)
19:52:34 <wumpus> no need to brainstorm the 2012 idea of doing it again now
19:52:37 <provoostenator> I suggest waiting a while before opening that can of worms though :-)
19:52:40 <jnewbery> yanmaani: even more useful if you review/test ryanofsky's work!
19:53:02 <jonasschnelli> I think I suggest then that we pimp up the documentation on how things are managed between the two repositories, avoid questions, etc.
19:53:17 <wumpus> jonasschnelli: +1
19:53:19 <jeremyrubin> wumpus: if some set of maintainers can establish a bit more of a framework on the validity of ryanofsky's approach i would spend some cycles on it. but AFAIU some contribs are nack on the approach so I'm not sure how likely it will proceed if that remains the case or what can be done to un-nack
19:53:21 <jonasschnelli> Let's hope MarcoFalke has time and willingness to do this
19:53:22 <wumpus> just documenting things would make sense
19:53:40 <wumpus> jeremyrubin: who is completely against it?
19:53:43 <jonasschnelli> people deserve to know what happens with PRs they write on the GUI repo
19:53:45 <jeremyrubin> gmax iirc?
19:54:15 <jeremyrubin> iirc he was against capnproto at all and wanted a custom IPC lib
19:54:16 <hebasto> +1 for documenting
19:54:24 <wumpus> for using capnproto for the GUI? I don't think so, he hates using it for internet protocols, but for internal communication between processes it doesn't matter too much
19:54:41 <sipa> no reason to speculate here
19:54:56 <sipa> afaik ryanofsky said that capnproto could easily be swapped out for something else if needed
19:55:06 <jonasschnelli> just the glue
19:55:11 <provoostenator> Indeed
19:55:12 <wumpus> I'd really dislike rolling our own IPC mechanism tbh
19:55:19 <jeremyrubin> do we already depend on it?
19:55:25 <jeremyrubin> It's in depends :)
19:55:38 <wumpus> there are so many one already, not everything needs to be invented here
19:55:44 <provoostenator> We already merged the build stuff for it.
19:55:54 <jonasschnelli> I'm still in favour or RPC
19:55:55 <jeremyrubin> https://github.com/bitcoin/bitcoin/pull/10102#issuecomment-289842646
19:55:56 <provoostenator> But it's an opt-in config flag
19:55:58 <wumpus> sipa: yes, it should be easy to swap out
19:56:14 <wumpus> he designed it so that the specific mechanism used is abstracted
19:56:15 <jnewbery> jonasschnelli: I think it's even easier than I said. Marco just merges the gui PR branch into the bitcoin/bitcoin repo
19:56:18 <wumpus> better just review the code...
19:56:29 <jonasschnelli> RPC can also work async. But yes. Not the topic now.
19:56:46 <wumpus> jonasschnelli: I mean we can do something wildly different but *only* if someone is willing to do the work
19:56:47 <jnewbery> and then I guess there's a bot or something that is syncing bitcoin-core/gui to the latest master
19:56:52 <jonatack> there is a good recent writeup by ryanofsky, one month ago, here: https://bitcoincore.reviews/19160
19:56:57 <wumpus> I see no reason to second-guess ryanofsky now after all this time
19:57:00 <jonasschnelli> wumpus: that's a point.
19:57:02 <jnewbery> https://github.com/bitcoin/bitcoin/pull/19071
19:57:14 <jeremyrubin> I have no issue with capnproto I think it's fine :)
19:57:18 <provoostenator> Last time I dug into it I found the approach pretty sane.
19:57:33 <wumpus> at least it's a step forward
19:57:34 <jeremyrubin> I spent a bunch of time reviewing it in '17 and think it's a good approach
19:57:44 <wumpus> when RPC one day converges on what we need for the GUI, then we can switch to that
19:58:18 <jonasschnelli> Haven't looked into it. But separating the GUI from the node via the internet/wireguard would be a requirement,.. right?
19:58:22 <wumpus> I think it's *very important* to take a step by step approach with things
19:58:23 <provoostenator> Conversely, when the IPC interface simplifies and needs fewer locks...
19:59:07 <wumpus> if not, we'll never go anywhere, this kind of thing has been proposed since at least 2012
19:59:16 <jonasschnelli> indeed
19:59:20 <wumpus> because everyone wants something else
19:59:29 <jonasschnelli> the power of open source
19:59:30 <wumpus> and then someone does it and peopel want yet something else
19:59:59 <jeremyrubin> I think that's all I'm asking. If ryanofsky's pr is reasonably reviewed
20:00:03 <wumpus> so, anyhow, if you're interested in process separation, please review ryanofsky's PRs
20:00:06 <jeremyrubin> there is no 'hard reason' it can't be merged
20:00:30 <jeremyrubin> which is great news for anyone willing to spend review cycles on it, it derisks that time spent
20:00:33 <wumpus> dont' come up with new wild ideas that would have to start from scratch :)
20:00:47 <sdaftuar> jeremyrubin: i would hope not, my understanding is that ryanofsky has been making progress towards this goal for quite some time now
20:01:28 <wumpus> of course after reviewing the PR you could give more targeted suggestions
20:01:38 <wumpus> oh, it's time
20:01:42 <wumpus> #endmeeting