--- Log opened Mon Nov 20 00:00:31 2023
00:04 -!- salvatoshi__ [~salvatosh@194.65.48.125] has joined #bitcoin-core-dev
00:12 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
00:17 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 252 seconds]
00:40 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
00:44 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 252 seconds]
00:51 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
00:56 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 255 seconds]
01:25 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
01:26 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-dev
01:32 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
01:32 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Remote host closed the connection]
01:35 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
01:40 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 268 seconds]
02:05 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
02:18 < bitcoin-git> [bitcoin] hethm999 opened pull request #28915: Update SECURITY.md (master...patch-1) https://github.com/bitcoin/bitcoin/pull/28915
02:19 < bitcoin-git> [bitcoin] fanquake closed pull request #28915: Update SECURITY.md (master...patch-1) https://github.com/bitcoin/bitcoin/pull/28915
02:20 -!- lbia [~lbia@user/lbia] has joined #bitcoin-core-dev
02:21 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has joined #bitcoin-core-dev
02:44 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Remote host closed the connection]
02:44 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
02:49 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 255 seconds]
03:01 -!- jespada [~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
03:06 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
03:10 -!- vysn [~vysn@user/vysn] has joined #bitcoin-core-dev
03:11 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 256 seconds]
03:29 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
03:29 -!- puchka [~puchka@185.203.122.118] has quit [Ping timeout: 256 seconds]
03:30 -!- kevkevin [~kevkevin@2600:1700:b30:47c0:307c:11a6:5e85:ee66] has joined #bitcoin-core-dev
03:31 -!- vysn [~vysn@user/vysn] has quit [Quit: WeeChat 4.0.3]
03:33 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 255 seconds]
03:35 -!- kevkevin [~kevkevin@2600:1700:b30:47c0:307c:11a6:5e85:ee66] has quit [Ping timeout: 260 seconds]
03:51 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
03:55 -!- TheRec [~toto@user/therec] has quit []
03:56 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 256 seconds]
04:08 -!- jonatack [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer]
04:09 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
04:13 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
04:18 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 264 seconds]
04:31 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has joined #bitcoin-core-dev
04:31 -!- TheRec [~toto@user/therec] has changed host
04:35 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
04:40 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 256 seconds]
05:08 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
05:13 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 268 seconds]
05:14 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
05:14 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-dev
05:23 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
05:27 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 256 seconds]
05:33 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
05:37 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 256 seconds]
05:39 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
05:49 < bitcoin-git> [bitcoin] hebasto opened pull request #28919: build: Fix regression in "ARMv8 CRC32 intrinsics" test (master...231120-crc-arm64) https://github.com/bitcoin/bitcoin/pull/28919
06:12 -!- salvatoshi__ [~salvatosh@194.65.48.125] has quit [Remote host closed the connection]
06:12 -!- salvatoshi [~salvatosh@194.65.48.125] has joined #bitcoin-core-dev
06:17 -!- benwestgate [~BenWestga@2603-8080-74f0-e960-9c6a-f2d7-0602-347d.res6.spectrum.com] has joined #bitcoin-core-dev
07:02 -!- kevkevin [~kevkevin@2600:1700:b30:47c0:307c:11a6:5e85:ee66] has joined #bitcoin-core-dev
07:05 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Remote host closed the connection]
07:05 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
07:10 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 255 seconds]
07:27 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
07:32 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 256 seconds]
07:36 -!- puchka [~puchka@185.203.122.121] has joined #bitcoin-core-dev
07:46 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
08:01 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
08:06 < bitcoin-git> [bitcoin] furszy opened pull request #28920: wallet: birth time update during tx scanning (master...2023_wallet_birhtime_update) https://github.com/bitcoin/bitcoin/pull/28920
08:06 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 255 seconds]
08:11 < sdaftuar> sjors: thanks for your comments on cluster mempool. regarding RBF and carveout i think it might be easier to discuss here
08:12 -!- Sjors[m] [~provooste@2620:6e:a000:ce11::1f] has joined #bitcoin-core-dev
08:12 < Sjors[m]> sdaftuar: or even park them in a tracking issue
08:12 < sdaftuar> since i opened the draft pr, sipa and i have been doing a lot more thinking about rbf, and the rules i have proposed in the PR are going to change
08:13 < Sjors[m]> Do you have a tl&dr of those changes?
08:13 < sdaftuar> it turns out that even with the rules that I initially proposed, it's possible that the mempool might not get "strictly better" as a result of an RBF that satisfied those tests.
08:13 < sdaftuar> so the tldr is that I'm going to write up what it means for the mempool to be "strictly better", and then test for that condition directly when evaluating a potential replacement.
08:14 -!- preimage [~halosghos@user/halosghost] has joined #bitcoin-core-dev
08:14 < sdaftuar> the quick summary of what "strictly better" means is: if you look at the mempool chunks sorted in descending feerate order, you want the new mempool (after a replacement happens) to contain the old one.
08:15 < sdaftuar> the implementation of this is still a work in progress, but i'll update the PR once I finish it.  it shouldn't change the algorithmic complexity of what we're doing.
08:15 < Sjors[m]> How do you mean "contain the old one"?
08:15 -!- martinus [~martinus@2001:4bc9:814:3b9a:ce4:a0d6:761e:3] has joined #bitcoin-core-dev
08:16 < sdaftuar> imagine drawing a graph where you have accumulated fee on the y-axis, and cumulative size on the x-axis.
08:16 < sipa> Sjors[m]: you draw a diagram with the cumulative size and cumulative fee after every chunk in (the combination of) all the clusters
08:16 < sipa> connect those with straight lines
08:17 < sipa> the diagram of the new mempool has to be nowhere below that of the old mempool, and at least in some places above it
08:19 < Sjors[m]> So it has be a steeper hill and at every point at least as high as before?
08:19 -!- martinus [~martinus@2001:4bc9:814:3b9a:ce4:a0d6:761e:3] has quit [Client Quit]
08:19 < sdaftuar> yeah that's basically it
08:19 < sipa> not necessarily; just at every point at least as high
08:19 -!- martinus_ [~martinus@2001:4bc9:814:3b9a:ce4:a0d6:761e:3] has joined #bitcoin-core-dev
08:19 < sdaftuar> the idea is that for every size block that could be mined, you collect more fee in the new mempool than the old one.
08:19 < sdaftuar> (ignoring tail effects at the end of a block)
08:20 < sipa> the steepness of segments of the diagram is the feerate of the individual chunks; it's not necessary that all the feerates are higher - it's possible that the first chunk just takes you high enough so that further chunks don't need to be very steep anymore to always stay above
08:21 < Sjors[m]> Ok, I'll wait for that update.
08:22 < Sjors[m]> Regarding CPFP carveout, I think that's orthogonal to the above?
08:22 < sdaftuar> yes, separate topic
08:22 < Sjors[m]> My thinking is that we either need really large clusters, or allow eviction inside a cluster
08:22 < Sjors[m]> Otherwise afaik you're always at risk of pinning by maxing out a cluster.
08:22 < sdaftuar> the problem with allowing eviction within a cluster is that there's not a good way to do so that will avoid pinning problems in all adversarial scenarios
08:23 < sipa> some forms of pinning are inevitable regardless, because of a conflict between incentive-compatibility and dos protection
08:23 < sdaftuar> and so if your concern is that there's an adversarial scenario where your counterparty fills up a cluster to mess with you, that they can do that differently even if we allow eviction
08:24 < sdaftuar> basically because any form of eviction that i can conceive of would (to be DoS-resistant) still require that the total fee in the mempool must increase
08:24 < sdaftuar> and so therefore if you fill up a cluster with large transactions, evicting them will be expensive
08:25 < instagibbs> ephemeral anchors is the current constrained answer, that's how you get non-DoSy sibling eviction(via explicit RBF)
08:25 < sdaftuar> if we don't care about that, and just want to argue that allowing any form of same-cluster-eviction is valuable so that you always have some way to broadcast a transaction (by putting a sufficiently high fee on it), then i could agree with that.
08:25 < Sjors[m]> So this is a universal RBF rule 3?
08:26 < instagibbs> sdaftuar it makes everything basically fullrbf ;) 
08:26 < instagibbs> well, in lots of scenarios 
08:26 < sdaftuar> no, not transactions that are not in full clusters?
08:26 < sdaftuar> well you could argue it i guess
08:26 < Sjors[m]> instagibbs: that could also make sense, but does that imply we have to wait with (wide) cluster mempool deployment until ephemaral anchors work? 
08:26 < instagibbs> attacker makes it full to replace it
08:26 < instagibbs> "attacker"
08:27 < Sjors[m]> Or does nobody use the CPFP carveout anyway?
08:27 < sdaftuar> you could also argue that everythign is full rbf anyway due to mempool eviction
08:27 < sdaftuar> \shrug
08:27 < instagibbs> psh :)
08:28 < instagibbs> Sjors[m] no, ephemeral anchors works today, it simplifies the problem to clusters of size 2
08:28 < sdaftuar> Sjors[m]: the problem with carveout is that it exists to deal with descendant limits, and descendant counts are a property that is local to a particular transaction. cluster size is a concept that is not specific to one transaction, so there's no way to allow a carveout to bypass that limit in any meaningful way
08:29 < Sjors[m]> instagibbs: "ephemeral anchors works today" ?? I thought it required package relay. Or is that deployed already?
08:29 < sdaftuar> our thought is to first deploy some form of v3 transaction policy, so that people relying on carveout could migrate to that first, and then we can get rid of carveout and deploy cluster mempool afterward
08:29 < instagibbs> Sjors[m] v3 shrinks the packages to size 2, ephemeral anchors allows dust outputs and provides a type of sibling eviction
08:29 < Sjors[m]> Oh
08:29 < instagibbs> Sjors[m] I meant it doesn't require clsuter mempool sorry
08:30 < Sjors[m]> Right, so if we drop the CPFP carveout before v3 is ready, that might be a problem
08:30 < instagibbs> https://github.com/bitcoin/bitcoin/issues/27463#issuecomment-1810836012 1 parent 1 child package relay/rbf, with v3/epehemeral anchors, wean people off cpfp carveout
08:31 < Sjors[m]> But the other around, v3 doesn't have to wait for cluster mempool.
08:31 < sdaftuar> Sjors[m]: yeah right now i'm assuming that cluster mempool is going to be delayed for v3
08:32 < instagibbs> practically speaking, the only users of cpfp carevout are LN implementations, so getting uptake there is key. Good news is it's a huge simplification of their state machines, security, and fee savings, so it's about getting going
08:33 < Sjors[m]> instagibbs: but it does suggest having one or two major releases in between the moment v3 is ready before clusters can be (at large scale) deployed, since LN folks need time.
08:34 < instagibbs> (not trying to go off topic) depends on uptake speed, most important imo is getting implementations using it done and deployed, as soon as parent-child package relay is considered deployed
08:35 < Sjors[m]> The other question I raised in the PR is we can drop RBF rule 5. But maybe we should wait for the new "better than before" mempool commits to be pushed.
08:35 < instagibbs> that's not this project's burden clearly, just noting
08:35 < sdaftuar> ah rule 5.  i have a few thoughts on that
08:35 < instagibbs> you need to constrain how many re-linearizations you do
08:36 < Sjors[m]> I haven't seen a clear illustration of the worst case abuse that rule prevents.
08:36 < sdaftuar> do you mean in the new cluster mempool model, or legacy model?
08:36 < sdaftuar> i wrote up an explanation on the mailing list of why that rule exists currently
08:37 < sdaftuar> in the new model, the concern is around avoiding too many re-linearizations, as instagibbs mentioned.  every cluster that is changed by a replacement needs to be re-linearized, which is a costly operation
08:37 < sdaftuar> the basic tradeoff here is that the more clusters you have that might be linearized at once, then the smaller clusters can be
08:38 < Sjors[m]> sdaftuar: in the new cluster model
08:38 < sdaftuar> so in theory, you could imagine that replacing a bunch of transactions that are in clusters which would disappear entirely may be ok, because those don't contribute linearization costs
08:38 < sdaftuar> Sjors[m]: right
08:40 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
08:40 < sdaftuar> however i haven't exactly figured out what limits make sense when we switch from the RBF heuristic i originally proposed to the new one i described before, where we actually measure if the new mempool is "strictly better" in order to process a replacement.
08:40 < Sjors[m]> sdaftuar: this post? https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021177.html
08:41 < sdaftuar> roughly speaking, it's the same issue, but i think the constants get bigger when we analyze the computational work being performed
08:41 < sdaftuar> Sjors[m]: yep that one
08:42 < sdaftuar> so, tldr: more to come on exactly how we can engineer that, and what the new limit or rule would be
08:42 < Sjors[m]> Whether it's useful to drop RBF rule 5 also depends on how big a cluster size is realistic. If the limit is ~100 anyway, then there's not much benefit other than just fewer rules.
08:42 < sdaftuar> no that's not true, because a single transaction can conflict with multiple clusters.
08:42 < sdaftuar> so regardless of what the cluster size limit is, it's useful to think about how many in-mempool transactions are being conflicted
08:43 -!- martinus_ is now known as martinus
08:43 < sdaftuar> for instance a transaction might have 500 inputs -- that could conflict with 500 different unrelated transactions
08:44 -!- martinus [~martinus@2001:4bc9:814:3b9a:ce4:a0d6:761e:3] has quit [Quit: Konversation terminated!]
08:44 -!- martinus [~martinus@2001:4bc9:814:3b9a:ce4:a0d6:761e:3] has joined #bitcoin-core-dev
08:44 < Sjors[m]> What I mean is: the RBF rule 5 limit makes it possible to pin something using just 100 transactions. If we dropped that limit, but if the cluster limit is 100, then you can still pin someone with just 100 transactions. Even though it would be a different kind of pinning attack. 
08:45 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 276 seconds]
08:45 < instagibbs> I told sdaftuar that counting directly conflicts would be better, then a txn creator can "just not do that"
08:45 < instagibbs> it's in the PR I'm sure you saw
08:45 < sdaftuar> Sjors[m]: not sure i follow -- the cluster size limit is applied after the conflicting transactinos are removed.
08:46 < bitcoin-git> [bitcoin] dergoegge closed pull request #28882: fuzz: Delete wallet_notifications (master...2023-11-fuzz-nuke-wn) https://github.com/bitcoin/bitcoin/pull/28882
08:46 < sdaftuar> oh and yes, we should be able to just count direct conflicts i think.
08:46 < sdaftuar> or do better, and just count number-of-relinearized-clusters or something
08:47 < instagibbs> either works 👍
08:49 < Sjors[m]> sdaftuar: put another way, if the goal is to get rid of all pinning attacks that can be done with 100 transactions, you would need to drop/increase the RBF rule 5 limit AND increase the maximum cluster size. If we can't do the latter for performance reasons, then it's not very useful worry about the former.
08:50 < sdaftuar> ok i think i see your broader point.  the biggest RBF pinning vector that will remain is the one that we have today, which is that you have to pay a greater total fee than what is being evicted.
08:51 -!- bugs_ [~bugs@user/bugs/x-5128603] has joined #bitcoin-core-dev
08:51 < sdaftuar> i think maximum-cluster-size is not exactly an anti-RBF pinning vector? it seems like more of a vector to prevent spending some related unconfirmed output...
08:52 < sdaftuar> but yes, pinning vectors remain.
08:52 < Sjors[m]> It's a thorny problem.
08:54 < Sjors[m]> Last question, sipa are you planning any major changes to the linearize code?
08:55 < sdaftuar> sipa has discovered some stuff that i think will likely result in some additional changes (my best guess)
08:55 < Sjors[m]> It would be good to have some prose at the top of cluster_linearize.h to explain what's going on and where to start reading.
08:56 < sipa> Sjors[m]: i think my approach will be to create a python reimplementation of the same algorithm(s)
08:57 < sipa> so that it can abstract away the complexity that's due to data structures, and just explain it all as operations on feerates and sets
08:57 < Sjors[m]> Sounds good.
08:58 < sipa> Sjors[m]: i don't expect big changes to the algorithms compared to what's implemented there, and perhaps some optimizations that don't contribute much may be dropped to reduce review complexity
08:59 < sipa> i do have a nice O(n^2) linearization post-processing algorithm that just improves it, which can be run after normal linearization
08:59 < sipa> that's not implemented there
09:00 < Sjors[m]> One thing that's useful to clarify is which linearization is perfect and which is "merely" pretty good.
09:01 < Sjors[m]> At least my understanding was that for small clusters you can find the best result?
09:01 < sipa> yeah up to 10-15 transactions
09:01 < Sjors[m]> And is there some metric of goodness?
09:01 < sdaftuar> yes, the mempool fee-size diagram we discussed before
09:02 < sdaftuar> you can imagine applying that a single cluster, and comparing two cluster linearizations by their fee-size diagrams.
09:02 < Sjors[m]> I mean, is there a metric to determine if you found the optimum or (stastitically) how far away you are
09:02 < sipa> but it's only a partial ordering - it's possible to have two linearizations for which in some places one's diagram is on top, and in other places the other one is; such linearizations are incomparable
09:02 < sipa> Sjors[m]: nope, i don't even have a way to quickly tell if a linearization is optimal or not
09:02 < sipa> apart from recomputing it
09:02 < sdaftuar> Sjors[m]: so, we don't have a proof that there exists an optimal ordering always.
09:03 < sdaftuar> Sjors[m]: however, we believe the optimal ordering is the one you get by doing the naive thing: at every step, select the topologically valid subset of remaining transactions with highest feerate
09:03 < sipa> also, i also just came up with an algorithm that can given two incomparable linearizations, finds a third linearization that's strictly better than both
09:03 < Sjors[m]> Are there any papers that explain the general problem?
09:03 < sipa> i have no clue what keywords to even look for
09:04 < sdaftuar> Sjors[m]: research links would be welcome!
09:17 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
09:22 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 264 seconds]
09:35 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
09:40 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 255 seconds]
09:43 -!- micha_ [uid14316@user/micha/x-4648593] has joined #bitcoin-core-dev
09:46 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
09:48 -!- salvatoshi [~salvatosh@194.65.48.125] has quit [Ping timeout: 256 seconds]
09:49 -!- kabaum [~kabaum@92.60.40.214] has quit [Ping timeout: 264 seconds]
09:51 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 255 seconds]
09:53 -!- benwestgate [~BenWestga@2603-8080-74f0-e960-9c6a-f2d7-0602-347d.res6.spectrum.com] has quit [Quit: Leaving.]
10:01 -!- kabaum [~kabaum@169.150.196.38] has joined #bitcoin-core-dev
10:03 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
10:08 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 256 seconds]
10:11 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
10:26 -!- szkl [uid110435@id-110435.uxbridge.irccloud.com] has joined #bitcoin-core-dev
10:49 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
11:09 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has quit [Quit: Connection closed for inactivity]
11:09 -!- dviola [~diego@user/dviola] has joined #bitcoin-core-dev
11:18 -!- Guest77 [~Guest77@2804:431:cff5:9c8:1d01:4909:9a32:1caa] has joined #bitcoin-core-dev
11:20 -!- Guest77 [~Guest77@2804:431:cff5:9c8:1d01:4909:9a32:1caa] has quit [Client Quit]
11:31 -!- pablomartin [~pablomart@185.216.146.35] has joined #bitcoin-core-dev
11:53 -!- Talkless [~Talkless@mail.dargis.net] has quit [Remote host closed the connection]
12:03 -!- Guest14 [~Guest80@2a02:e840:303:9600:a9ba:914c:9137:5983] has quit [Quit: Client closed]
12:10 -!- cryptapus_ [~cryptapus@user/cryptapus] has joined #bitcoin-core-dev
12:11 -!- cryptapus [~cryptapus@user/cryptapus] has quit [Ping timeout: 256 seconds]
12:16 -!- mudsip [~mudsip@user/mudsip] has joined #bitcoin-core-dev
12:23 -!- micha_ [uid14316@user/micha/x-4648593] has quit [Quit: Connection closed for inactivity]
12:25 -!- micha_ [uid14316@user/micha/x-4648593] has joined #bitcoin-core-dev
12:26 -!- cryptapus_ [~cryptapus@user/cryptapus] has quit [Ping timeout: 255 seconds]
12:27 -!- mudsip [~mudsip@user/mudsip] has quit []
12:30 -!- jon_atack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
12:30 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 256 seconds]
12:34 -!- mudsip [~mudsip@user/mudsip] has joined #bitcoin-core-dev
12:35 -!- mudsip [~mudsip@user/mudsip] has quit [Client Quit]
13:17 -!- cryptapus_ [~cryptapus@user/cryptapus] has joined #bitcoin-core-dev
13:21 -!- cryptapus [~cryptapus@user/cryptapus] has joined #bitcoin-core-dev
13:21 -!- cryptapus_ [~cryptapus@user/cryptapus] has quit [Ping timeout: 255 seconds]
13:22 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Remote host closed the connection]
13:23 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
13:31 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Remote host closed the connection]
13:32 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
13:37 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 255 seconds]
13:53 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
13:53 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has joined #bitcoin-core-dev
13:57 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 255 seconds]
14:01 -!- pablomartin [~pablomart@185.216.146.35] has quit [Ping timeout: 256 seconds]
14:05 -!- cryptapus [~cryptapus@user/cryptapus] has quit [Read error: Connection reset by peer]
14:08 -!- cryptapus [~cryptapus@user/cryptapus] has joined #bitcoin-core-dev
14:09 -!- pablomartin [~pablomart@89.37.175.80] has joined #bitcoin-core-dev
14:12 < bitcoin-git> [bitcoin] ryanofsky opened pull request #28921: multiprocess: Add basic type conversion hoois (master...pr/ipcc) https://github.com/bitcoin/bitcoin/pull/28921
14:15 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
14:20 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 264 seconds]
14:25 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
14:26 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Remote host closed the connection]
14:26 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
14:34 -!- cryptapus [~cryptapus@user/cryptapus] has quit [Ping timeout: 252 seconds]
14:37 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Remote host closed the connection]
14:38 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
14:41 -!- cryptapus [~cryptapus@user/cryptapus] has joined #bitcoin-core-dev
14:47 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 255 seconds]
14:53 -!- pablomartin [~pablomart@89.37.175.80] has quit [Ping timeout: 264 seconds]
15:04 -!- bugs_ [~bugs@user/bugs/x-5128603] has quit [Quit: Leaving]
15:15 -!- vasild [~vd@user/vasild] has quit [Ping timeout: 240 seconds]
15:33 -!- micha_ [uid14316@user/micha/x-4648593] has quit [Quit: Connection closed for inactivity]
16:00 -!- kevkevin [~kevkevin@2600:1700:b30:47c0:307c:11a6:5e85:ee66] has quit [Remote host closed the connection]
16:01 -!- Guest87 [~Guest42@70.32.1.81] has joined #bitcoin-core-dev
16:12 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has quit [Quit: Connection closed for inactivity]
16:12 -!- benwestgate [~BenWestga@035-146-116-233.res.spectrum.com] has joined #bitcoin-core-dev
16:16 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
16:20 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 252 seconds]
16:20 -!- arowser [~quassel@216.24.179.16.16clouds.com] has joined #bitcoin-core-dev
16:34 -!- arowser [~quassel@216.24.179.16.16clouds.com] has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
16:38 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
16:41 -!- vasild [~vd@user/vasild] has joined #bitcoin-core-dev
16:43 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 264 seconds]
16:45 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Remote host closed the connection]
17:01 -!- boris [~boris@user/boris] has quit [Ping timeout: 245 seconds]
17:01 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
17:01 -!- boris [~boris@user/boris] has joined #bitcoin-core-dev
17:10 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 256 seconds]
17:16 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #bitcoin-core-dev
17:29 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
17:33 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 255 seconds]
17:35 -!- cryptapus [~cryptapus@user/cryptapus] has quit [Remote host closed the connection]
17:35 -!- Guest87 [~Guest42@70.32.1.81] has quit [Quit: Client closed]
17:41 -!- kevkevin [~kevkevin@2601:241:8703:7b30:6c26:e298:ed99:a4f2] has joined #bitcoin-core-dev
17:42 -!- cryptapus [~cryptapus@user/cryptapus] has joined #bitcoin-core-dev
17:50 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Ping timeout: 260 seconds]
17:51 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
17:53 -!- pablomartin [~pablomart@89.37.175.79] has joined #bitcoin-core-dev
17:56 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 264 seconds]
18:09 -!- preimage [~halosghos@user/halosghost] has quit [Quit: WeeChat 4.1.1]
18:20 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 260 seconds]
18:22 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
18:26 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 264 seconds]
18:27 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
18:32 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 255 seconds]
18:38 -!- conman [~con@180-150-21-3.b49615.mel.static.aussiebb.net] has joined #bitcoin-core-dev
18:41 -!- pablomartin [~pablomart@89.37.175.79] has quit [Ping timeout: 256 seconds]
18:42 -!- aureleoules [~aureleoul@82-64-162-213.subs.proxad.net] has quit [Ping timeout: 256 seconds]
18:44 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
18:48 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 256 seconds]
18:54 -!- aureleoules [~aureleoul@82-64-162-213.subs.proxad.net] has joined #bitcoin-core-dev
19:06 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
19:11 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 252 seconds]
19:16 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
19:29 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
19:34 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 255 seconds]
19:48 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #bitcoin-core-dev
20:17 -!- mikehu44 [~quassel@2a09:bac1:6520:8::278:a7] has joined #bitcoin-core-dev
20:21 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Ping timeout: 256 seconds]
20:25 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
20:25 -!- mikehu44_ [~quassel@2a09:bac5:55fc:101e::19b:184] has joined #bitcoin-core-dev
20:25 -!- mikehu44 [~quassel@2a09:bac1:6520:8::278:a7] has quit [Ping timeout: 268 seconds]
20:30 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 252 seconds]
20:32 -!- szkl [uid110435@id-110435.uxbridge.irccloud.com] has quit [Quit: Connection closed for inactivity]
20:58 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
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:08 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 256 seconds]
21:26 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
21:31 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 256 seconds]
21:32 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
21:37 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 255 seconds]
21:48 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #bitcoin-core-dev
21:51 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
21:56 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 256 seconds]
21:56 -!- puchka [~puchka@185.203.122.121] has quit [Ping timeout: 276 seconds]
21:59 -!- hernanmarino [~hernanmar@2800:2130:2800:133:fdd3:fd3f:76e:bd35] has quit [Ping timeout: 260 seconds]
22:00 -!- hernanmarino [~hernanmar@181.98.56.2] has joined #bitcoin-core-dev
22:13 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
22:18 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 264 seconds]
22:19 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
22:24 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 256 seconds]
22:40 -!- rbatty [~rbatty@pool-74-98-206-161.pitbpa.ftas.verizon.net] has joined #bitcoin-core-dev
22:52 -!- vysn [~vysn@user/vysn] has joined #bitcoin-core-dev
22:58 -!- puchka [~puchka@185.203.122.36] has joined #bitcoin-core-dev
23:14 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
23:20 -!- szkl [uid110435@id-110435.uxbridge.irccloud.com] has joined #bitcoin-core-dev
23:24 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 256 seconds]
23:26 -!- rbatty [~rbatty@pool-74-98-206-161.pitbpa.ftas.verizon.net] has quit [Quit: rbatty]
23:31 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
23:36 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 256 seconds]
23:38 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Remote host closed the connection]
23:39 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
--- Log closed Tue Nov 21 00:00:32 2023