--- Log opened Wed Oct 04 00:00:47 2023
00:34 -!- S3RK [~S3RK@user/s3rk] has quit [Ping timeout: 258 seconds]
00:36 -!- S3RK [~S3RK@user/s3rk] has joined #bitcoin-core-pr-reviews
01:27 -!- TheRec [~toto@user/therec] has quit [Read error: Connection reset by peer]
01:28 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has joined #bitcoin-core-pr-reviews
01:28 -!- TheRec [~toto@user/therec] has changed host
02:56 -!- lowhope [~lowhope@cow9.org] has quit [Remote host closed the connection]
03:06 -!- lowhope_ [~lowhope@2602:fffa:fff:108c:216:3eff:fe86:c70e] has joined #bitcoin-core-pr-reviews
03:30 -!- lowhope_ [~lowhope@2602:fffa:fff:108c:216:3eff:fe86:c70e] has quit [Ping timeout: 260 seconds]
03:45 -!- lowhope_ [~lowhope@cow9.org] has joined #bitcoin-core-pr-reviews
03:55 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 252 seconds]
03:56 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
04:21 -!- somecharacter [~somechara@90.203.107.196] has joined #bitcoin-core-pr-reviews
05:08 -!- somecharacter [~somechara@90.203.107.196] has quit [Quit: Connection closed]
06:11 -!- __gotcha [~Thunderbi@94.105.116.209.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
06:42 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has joined #bitcoin-core-pr-reviews
08:07 -!- pablomartin4btc [~pablomart@217.146.93.163] has joined #bitcoin-core-pr-reviews
09:33 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 258 seconds]
09:43 -!- vmammal [~vmammal@162.250.26.106] has joined #bitcoin-core-pr-reviews
09:45 -!- dberkelmans [~dberkelma@2001:1c03:530d:8100:34bc:a510:2726:99e9] has joined #bitcoin-core-pr-reviews
09:49 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
10:00 < stickies-v> #startmeeting
10:00 -!- BrandonOdiwuor [~BrandonOd@105.162.7.163] has joined #bitcoin-core-pr-reviews
10:00 < dberkelmans> hi
10:00 < dergoegge> hi
10:00 < BrandonOdiwuor> Hello
10:01 < lightlike> hi
10:01 -!- dberkelmans11 [~dberkelma@2001:1c03:530d:8100:bd43:62ae:9708:47f8] has joined #bitcoin-core-pr-reviews
10:01 < larryruane_> hi
10:01 < vmammal> first timer here. im here to learn
10:01 < stickies-v> welcome everyone! Today we're looking at #28107, authored by dergoegge . The notes and questions are available on https://bitcoincore.reviews/28107
10:01 -!- dberkelmans11 [~dberkelma@2001:1c03:530d:8100:bd43:62ae:9708:47f8] has quit [Client Quit]
10:02 < stickies-v> great, glad you're joining us vmammal! any other first timers today?
10:02 -!- dberkelmans62 [~dberkelma@2001:1c03:530d:8100:bd43:62ae:9708:47f8] has joined #bitcoin-core-pr-reviews
10:02 < Murch[m]> Hey
10:02 < stickies-v> even if you're just lurking, feel free to say hi!
10:02 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
10:02 < sipa> hi
10:02 -!- somecharacter [~somechara@90.203.107.196] has joined #bitcoin-core-pr-reviews
10:02 < larryruane_> will we be back here tomorrow? are we covering the first set of questions today (concept)?
10:03 -!- maxedwards [~maxedward@90.203.107.196] has joined #bitcoin-core-pr-reviews
10:03 < glozow> hi
10:03 < stickies-v> correct larryruane_ ! same time tomorrow for the second batch of questions
10:03 < effexzi> Hi every1
10:03 < maxedwards> hi
10:03 < stickies-v> who got the chance to review the PR or read the notes? (y/n)
10:03 < Murch[m]> n
10:03 < maxedwards> y
10:03 < BrandonOdiwuor> y
10:03 < lightlike> y
10:03 < dberkelmans62> y
10:03 < abubakarsadiq> hi
10:03 < glozow> woohooo welcome newcomers!
10:03 < glozow> y
10:04 < stickies-v> alright wonderful, let's dive into the wonderfully wholesome world of type-safety
10:05 -!- dberkelmans [~dberkelma@2001:1c03:530d:8100:34bc:a510:2726:99e9] has quit [Ping timeout: 245 seconds]
10:05 < larryruane_> i heard someone say years ago, "strong types are for weak minds" (haha I don't agree!)
10:05 < stickies-v> for those of you who were able to review, would you give it a Concept ACK, Approach ACK, Tested ACK, or NACK? what was your review approach?
10:05 -!- somecharacter [~somechara@90.203.107.196] has quit [Client Quit]
10:05 < vmammal> concept ACK
10:06 < larryruane_> i'm still reviewing
10:06 < maxedwards> Concept ACK
10:06 < BrandonOdiwuor> Concept ACK
10:06 < abubakarsadiq> Concept ACK, did not do code review but I think this is very useful improvement, not only that uint256 can be block hask, header, txid and wtxid. It will be nice to distinguish between wtxid and txid with type. Because there is ambiguity in the code whereby hash is referred to txid, wtxid and blockhash. Using type specifier for wtxid and txid will help distinguish even if an ambiguous variable name is used
10:07 < maxedwards> built and ran tests, read through the code, looked at the super class of uint256
10:07 < stickies-v> abubakarsadiq: I agree! compile-time checks (which we'll get to in a bit) are a great improvement on their own, but just improving code readability is quite nice too imo
10:08 < stickies-v> so, diving into the conceptual side of things a bit
10:08 < stickies-v> 2. What does it mean for a transaction identifier to be type-safe? Why is that important or helpful? Are there any downsides?
10:08 < larryruane_> before I approach ACK, I'm trying to figure out if it would be better for a `Txid` and a `Wtxid` to *inheret* from `uint256`, or for them to simply *include* a `uint256` (and nothing more, you could call this wrapping)
10:09 < BrandonOdiwuor> A 'transaction identifier' is considered 'type-safe' when it undergoes rigorous type-checking during compile-time, guaranteeing that operations involving these identifiers are thoroughly validated and constrained to their intended data types before the program is executed, thus preventing type-related errors and ensuring program reliability.
10:09 < BrandonOdiwuor> Some advantages include: Early detection of type-errors at compile time and preventing runtime errors
10:10 < larryruane_> type safe means the two kinds of transaction IDs have distinct types (instead of both being `uint256`), so trying to assign one type to a variable of another type (for example) is like trying to assign a `float` to an `int`
10:10 < stickies-v> larryruane_: I have had similar thoughts. I think inheritance makes the transition easier, i.e. if we don't want to update all places that use a transaction identifier
10:10 < stickies-v> but ignoring that it seems like just having a `uint256` member seems like it would simplify the implementation quite a bit
10:11 < larryruane_> @stickies-v thanks, that's my suspicion too, but wasn't sure, want to investigate further
10:11 -!- BrandonOdiwuor94 [~BrandonOd@105.162.7.163] has joined #bitcoin-core-pr-reviews
10:12 < abubakarsadiq> there are two types of transaction identifiers in post segwit bitcoin, txid and wtxid. 
10:12 < abubakarsadiq> To avoid ambiguity and logic error where both are interchanged, it will be better if they are distinct types
10:12 < abubakarsadiq> The code won't compile if one is used in the place of another.
10:13 < larryruane_> a C codebase i worked on years ago had a really cool concept of "wrapped" integers, so you couldn't assign a block count (this was a storage system) to a byte count, etc. .... so similar goal as here, but it used the wrapped approach (since there's no inheretence in C)
10:13 < stickies-v> BrandonOdiwuor: would you say the error catching happens mostly at compile time or at runtime?
10:13 < maxedwards> can you elaborate on the simplicity enabled by having an internal uint256 vs subclassing?
10:13 < stickies-v> larryruane_: is type safety guaranteed by just having two distinct types, though?
10:14 < BrandonOdiwuor94> stickies-v it would be better to catch the errors at compile-time rather than do runtime assertions to catch the errors
10:14 < larryruane_> no, a block count type was a C struct with just one member, conventionally called `i` (for `integer`), and the byte count was a different C struct (also with just `i`) ... so you couldn't assign one to the other for example
10:15 -!- BrandonOdiwuor [~BrandonOd@105.162.7.163] has quit [Ping timeout: 255 seconds]
10:15 < maxedwards> simply providing the types is not enough, they have to be consumed
10:15 < Murch[m]> I assume that with inheritance assignments might permit to autoconvert between the types without complaining
10:15 < stickies-v> BrandonOdiwuor94:  yeah, catching stuff at compile time is great - makes it quick for the developer to spot their error as they are developing, as opposed to relying on writing extensive test suites etc (that still may miss things) to catch things in runtime
10:15 < larryruane_> i.e. so it wasn't just two typedefs (which does NOT give type safety)
10:16 < stickies-v> larryruane_: i don't just mean typedefs: in a naive implementation, just having Txid and Wtxid each subclass uint256 does not provide type safety on its own, as e.g. we can still do comparisons between them
10:16 < larryruane_> yeah trying to catch things are runtime is tricky, you might never happen to go through the buggy code path! (but for sure one of our users will!)
10:17 < stickies-v> well, it does provide some type safety, just not entirely
10:17 < stickies-v> Murch[m]: yes exactly@
10:17 < maxedwards> Murch[m]: I believe there is a comment about doing just that in the PR
10:17 -!- BrandonOdiwuor94 is now known as BrandonOdiwuor
10:18 < stickies-v> maxedwards:  so the complexity that I was talking about is that currently we have to specify which kinds of comparisons etc we allow, because currently both `Txid` and `Wtxid` inherit from `uint256`
10:19 < stickies-v> I guess we already largely covered the next question but I'll throw it in here regardless in case anyone has something to add:
10:19 < larryruane_> to me, with my not-great understanding of subclassing, the wrapping approach seems simpler and safer -- two classes both with just one member, a `uint256` (like we did with the wrapped integers in C) ... but never mind, we can move on, sorry to distrupt
10:19 < stickies-v> 3. Why is it better to enforce types at compile-time instead of at run-time?
10:19 < glozow> find bug moar fast.
10:19 < BrandonOdiwuor> Early Error Detection: Compile-time checking allows for the identification of type-related errors and mismatches at compile time before the program is even executed. This means that issues are caught during the development and testing phase, reducing the chances of runtime errors and unexpected program behavior.
10:20 < larryruane_> stickies-v: kind of answered already, but it prevents coding mistakes where the wrong kind of ID is used (txid instead of wtxid or the reverse)
10:20 < stickies-v> larryruane_: but with wrapping, would you still be able to not update all callsites of functions that return a Txid/Wtxid right away?
10:20 < stickies-v> I think there's merit to allowing this to be a gradual improvement
10:20 < stickies-v> glozow: much accurate
10:20 < larryruane_> @stickies-v yes very true! that's an important consideration
10:21 < stickies-v> BrandonOdiwuor: yeah it's generally much quicker
10:22 < BrandonOdiwuor> I saw this comment on the notes (https://github.com/bitcoin/bitcoin/pull/28031#discussion_r1261648754) I think it would help with this
10:23 < glozow> yeah I write this bug approximately once every 2 weeks
10:23 < maxedwards> assuming less than perfect test coverage and a bug, a runtime check could end up throwing on production
10:23 < maxedwards> worst case and I'm sure with the scrutiny of bitcoin it would be caught in an earlier stage
10:24 < glozow> Usually I catch it before I push a PR tho. always need to have a "try 2 transactions with same txid but diff witness" test
10:24 < glozow> catching at compile time would be nice
10:25 < stickies-v> maxedwards: even if it can be tested, being able to remove tests because it's checked at compile time is a big win
10:25 < abubakarsadiq> glozow: with this you dont have to do that right \o/?
10:25 < stickies-v> launching the next question already - but as always, feel free to continue the conversation on previous questions too!
10:25 < stickies-v> 4. Conceptually, when writing new code that requires referring to transactions, when should you use `txid` and when should you use `wtxid`? Can you point to any examples in the code where using one instead of the other could be very bad? (1 point per example)
10:26 < lightlike> seems like testing this would still be useful.  having type safety won't prevent us from using the wrong type of id (but consistently) in the first place.
10:27 < larryruane_> stickies-v: not sure if this is what you're asking, but two pure segwit transactions with the same txid (even if different wtxids) have the same *effect* (modify the UTXO set the same way)
10:27 < larryruane_> lightlike: +1
10:27 < glozow> lightlike +1
10:28 < larryruane_> (pure meaning *all* the inputs are segwit)
10:28 < glozow> this is a good example imo: https://github.com/bitcoin/bitcoin/blob/3cd02806ecd2edd08236ede554f1685866625757/src/net_processing.cpp#L4334
10:28 < sipa> larryruane_: two non-segwit transactions with the same txid also have the same effect :p
10:28 < glozow> if you use txid, that means I can censor any tx I want to you by sending you a version with a mutated witness first
10:29 < stickies-v> glozow: 1 point!
10:30 < larryruane_> sipa: oh right... two tx with different txids could have the same effect (i think??)
10:30 < larryruane_> (that's malleability)
10:30 < sipa> larryruane_: yes
10:30 < sipa> the same txid implies the same effect, but different txid does not imply different effect
10:31 < lightlike> so "when in doubt use wtxid" is a good role of thumb i guess?
10:31 < stickies-v> so even if you haven't found any examples, conceptually - what do you think is a good heuristic for when to use wtxid instead of txid, or txid instead of wtxid?
10:32 < stickies-v> lightlike: that seems a reasonable starting point :-D 
10:33 < glozow> pretty much always wtxid unless it's prevout-related
10:33 < sipa> or tx relay for pre-BIP339 peers
10:33 < larryruane_> stickies-v: in the mempool, we definitely want to use txids as keys, because if we used wtxid, two tx with the same txid could be there simultaneously, and if that happened, an output from both of them could be spent separately, leading to double-spend bug?
10:34 < stickies-v> glozow: yeah, and also almost always wtxid when it's about unconfirmed txs?
10:34 -!- dberkelmans [~dberkelma@2001:1c03:530d:8100:cdd4:737d:a1e7:1e6f] has joined #bitcoin-core-pr-reviews
10:35 < larryruane_> stickies-v: that sounds opposite to what i said? (but i may be wrong)
10:36 < abubakarsadiq> we could have identical transaction with multiple wtxid's using wtxid almost everytime, will that not bring duplication especially for unconfirmed txs?
10:36 < stickies-v> larryruane_: well i think gloria covered that already by it being prevout related?
10:36 < sipa> the mempool is indexed by both txid and wtxid, because we need to be able to look up by both
10:36 < glozow> unsure if unconfirmed txs are special. But one distinction that springs to mind is you should never try to cache feerate to a txid
10:37 < glozow> I think larryruane's point might be that having an index by txid can be a useful way to bake in the assumption that no 2 transactions in the data structure should have the same txid
10:37 < larryruane_> sipa: gotcha, but we definitely don't want to allow > 1 tx with the same txid
10:38 -!- dberkelmans62 [~dberkelma@2001:1c03:530d:8100:bd43:62ae:9708:47f8] has quit [Ping timeout: 245 seconds]
10:38 < maxedwards> am I right in thinking that in theory this same/different effect shouldn't be a concern for this PR as the existing code should already be using the correct id, it's just that it's represented by the same type?
10:39 < lightlike> larryruane: we don't want conflicting transactions in general, even if they don't share the txid.
10:39 < sipa> my guess is actually that if we dropped the unicity of the txid index in the mempool, nothing would break, as different-wtxid-same-txid transactions would still just conflict with each other
10:39 < sipa> the unicity just allows enforcing that constraint independently
10:39 < sipa> uniqueness? unicity?
10:40 < stickies-v> maxedwards: this is more conceptual discussion about txid/wtxid indeed and not directly critical for the PR
10:40 < larryruane_> lightlike: oh yes that's right, as glozow said, the prevout is txid-based so would be the same
10:40 < sipa> (tangent, english stackexchange says "I suspect most people would take "Unicity" to be a town where everyone rides unicycles.")
10:40 < maxedwards> stickies-v: very interesting still
10:41 < larryruane_> i took bicycle riding lessons but ran out of money halfway through, so now i can only ride a unicycle
10:41 < glozow> sipa: tbh I would have thought of it as the british equivalent of "college town"
10:41 -!- BrandonOdiwuor88 [~BrandonOd@105.162.7.163] has joined #bitcoin-core-pr-reviews
10:41 < glozow> larryruane: are there 100 seats on 100 unicycles...
10:42 < sipa> :D
10:42 < stickies-v> alright time to move on 😅
10:42 < sipa> glozow: and they ride one by one into a room with 100 boxes, ...
10:42 < stickies-v> 5. In which concrete way(s) could using `transaction_identifier` instead of `uint256` help find existing bugs or prevent the introduction of new ones? On the other hand, could this change introduce new bugs?
10:42 < glozow> 😂
10:43 < larryruane_> stickies-v: is it because lots of other things besides txids and wtxids can be uint256 type? so using `transaction_identifier` would exclude those accidental uses?
10:45 -!- BrandonOdiwuor [~BrandonOd@105.162.7.163] has quit [Ping timeout: 252 seconds]
10:45 < BrandonOdiwuor88> larryruane_ I think it would help prevent mixing up using Txid and Wtxid unintentionally such as the comment that was linked in the notes(https://github.com/bitcoin/bitcoin/pull/28031#discussion_r1261648754)
10:45 < stickies-v> larryruane_: yup. a function that takes a `uint256 hash` as an argument can specify in the docs that `hash` is supposed to be a wtxid, but if a developer (and the reviewers) don't read that properly then it's trivial to pass a txid and potentially (probably) break things
10:46 < glozow> fun anecdote related to this: one time while working in wallet code, I saw a variable named `wtxid` and assumed it was a witness ID. nope, it stood for "wallet transaction id"
10:47 < stickies-v> on the other hand - does having this explicit type potentially introduce other, new bugs? can you think of any?
10:47 < stickies-v> glozow: oooh yeah those are sneaky
10:47 < maxedwards> can you pass a uint256 to a function that asks for a txid?
10:47 < maxedwards> or do you have to cast?
10:47 < larryruane_> i just noticed that there are 1687 occurrences of `uint256` in our code base -- many (maybe most) of which are not transaction ID related!
10:49 < dergoegge> maxedwards: you would have to use `Txid::FromUint256`
10:49 < glozow> maxedwards: try and see if it compiles!
10:50 < stickies-v> maxedwards: see also question 16 that we'll be dealing with tomorrow!
10:50 < lightlike> dergoegge: did you try to change it everywhere, just to see how big the effort is?
10:50 < maxedwards> even with this, would it not be possible to change a parameter to a txid when it should be a wtxid and everything would still work?
10:50 < maxedwards> the uint256 was representing a wtxid
10:51 < maxedwards> but the type isn't actually enforcing that it is
10:51 < maxedwards> and could lead to much confusion
10:51 < maxedwards> even more confusion than had it been left as a uint256
10:51 < BrandonOdiwuor88> maxedwards I think the compiler would throw an error you have to cast explicitly with reinterpret_cast
10:51 < maxedwards> yes so I'm assuming you do cast
10:52 < stickies-v> maxedwards: what do you mean with change a parameter? the function signature?
10:52 < maxedwards> but there's nothing stopping you from casting a uint256 that represented a wtxid to a txid is there?
10:52 < maxedwards> yes function signature
10:52 < stickies-v> well obviously the function signature has to be correct, if you need a wtxid and have your function signature take a `Txid txid` then that's going to lead to problems
10:53 < maxedwards> not compile time problems though is my question
10:53 < dergoegge> lightlike: no haven't tried, my guess would be that it is a bunch of effort but also not to crazy
10:54 < stickies-v> it depends on the callsites of course. sorry i'm not sure i fully understand your question - type-safety doesn't prevent a developer from writing wrong code, indeed
10:55 < vmammal> dergoegge do you plan to continue the refactor in a future PR?
10:55 < dergoegge> `Txid::FromUint256(Wtxid{})` might actually work because `uint256 a = Wtxid{}` is allowed.
10:55 < stickies-v> gonna skip a few questions as we're running out of time
10:55 < dergoegge> vmammal: yes but I'd also be happy to see other people going for it
10:55 < stickies-v> 8. The `GenTxid` class already exists. How does it already enforce type correctness, and how is it different from the approach in this PR?
10:55 < stickies-v> (link: https://github.com/bitcoin/bitcoin/blob/dcfbf3c2107c3cb9d343ebfa0eee78278dea8d66/src/primitives/transaction.h#L425) 
10:58 < dberkelmans> It also contains a bool saying if the witness is included
10:58 < dberkelmans> It's one type instead of 2
10:58 < dberkelmans> So it doesn't make the code more readable
10:59 < larryruane_> for one thing, an instance of a txid and a wtxid (contained within a GenTxid) compare as false, even if the hashes are true ... but there's more I'm sure
10:59 < stickies-v> dberkelmans: if it doesn't make the code more readable, should we then replace it entirely with transaction_identifier?
11:00 < BrandonOdiwuor88> I think GenTxid uses uint256 to store the hash and the bool m_is_wtxid to indicate whether its Wtxid or Txid
11:00 < dberkelmans> I haven't seen enough code to say anything sensible about that
11:01 < stickies-v> I think an important difference is that GenTxid allows type checking, by exposing the `IsWtxid()` function, but it's still on the user to do that checking
11:01 < stickies-v> and more importantly, it happens at runtime
11:01 < dberkelmans> I suppose if you only need the uint256 then having it in one type makes sense
11:02 < larryruane_> stickies-v: so it's runtime checking rather than compile-time
11:02 < stickies-v> with transaction_identifer, the type checking is enforced at compile time
11:02 < stickies-v> larryruane_: yeah
11:02 < stickies-v> dberkelmans: well one important use case that GenTxid solves is that in quite a few places we want to be able to take input that can be either a txid or a wtxid, as opposed to just one or the other
11:03 < dergoegge> If we go for the type safe ids, my thinking was that we would replace `GenTxid` with `std::variant<Txid, Wtxid>`
11:03 < stickies-v> actually, from my quick skimming it seems like *all* the places where we use GenTxid we want to be able to accept both types (which surprised me a little)
11:03 < stickies-v> so, we're at time for this meeting
11:03 < stickies-v> #endmeeting
11:03 < larryruane_> dergoegge: +1
11:03 < glozow> thanks stickies-v!
11:03 < dergoegge> stickies-v: thank you!
11:03 < maxedwards> thanks!
11:04 < larryruane_> thanks @stickies-v!
11:04 < lightlike> Thanks! 
11:04 < stickies-v> thanks everyone for joining in the discussion! we'll be back tomorrow. same time, same place
11:04 < BrandonOdiwuor88> Thanks stickies-v
11:04 < dberkelmans> thanks
11:04 < stickies-v> we'll start with question 10 tomorrow!
11:04 < larryruane_> lightlike: and thanks for the PR, great stuff!
11:04 < abubakarsadiq> thanks @stickies-v
11:04 < maxedwards> tomorrow?
11:04 < lightlike> Larryruane: Not my pr :) 
11:04 < effexzi> Thanks every1 
11:05 < stickies-v> maxedwards: yes, today was conceptual questions, tomorrow we'll dive into the PR code
11:05 -!- vmammal [~vmammal@162.250.26.106] has quit [Quit: Connection closed]
11:06 < maxedwards> ah, I thought "first Wednesday and Thursday of the month" was a typo
11:06 < maxedwards> so I read it as or
11:06 < maxedwards> but thinking about it or doesn't make any sense!
11:16 -!- BrandonOdiwuor88 [~BrandonOd@105.162.7.163] has quit [Ping timeout: 260 seconds]
11:20 < stickies-v> today's meeting logs have been added to https://bitcoincore.reviews/28107 already - in case you want to review!
11:27 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
11:28 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 252 seconds]
11:32 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
11:36 -!- pablomartin4btc [~pablomart@217.146.93.163] has quit [Ping timeout: 246 seconds]
11:42 -!- maxedwards [~maxedward@90.203.107.196] has quit [Quit: Connection closed]
11:47 -!- dberkelmans [~dberkelma@2001:1c03:530d:8100:cdd4:737d:a1e7:1e6f] has quit [Quit: Client closed]
11:47 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
11:48 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Client Quit]
11:48 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
12:15 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:32 -!- pablomartin [~pablomart@host113.181-5-214.telecom.net.ar] has joined #bitcoin-core-pr-reviews
12:34 -!- pablomartin4btc [~pablomart@185.216.146.241] has joined #bitcoin-core-pr-reviews
12:37 -!- pablomartin [~pablomart@host113.181-5-214.telecom.net.ar] has quit [Ping timeout: 255 seconds]
12:45 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 255 seconds]
12:57 -!- __gotcha [~Thunderbi@94.105.116.209.dyn.edpnet.net] has quit [Remote host closed the connection]
13:01 -!- __gotcha [~Thunderbi@94.105.116.209.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
13:05 -!- _i_n_j_i_r_ [~hexchat@87.76.253.250] has joined #bitcoin-core-pr-reviews
13:13 -!- __gotcha [~Thunderbi@94.105.116.209.dyn.edpnet.net] has quit [Remote host closed the connection]
13:14 -!- __gotcha [~Thunderbi@94.105.116.209.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
13:23 -!- __gotcha [~Thunderbi@94.105.116.209.dyn.edpnet.net] has quit [Remote host closed the connection]
13:24 -!- __gotcha [~Thunderbi@94.105.116.209.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
13:39 -!- _i_n_j_i_r_ [~hexchat@87.76.253.250] has quit [Quit: Leaving]
13:46 -!- __gotcha1 [~Thunderbi@94.105.116.209.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
13:49 -!- __gotcha [~Thunderbi@94.105.116.209.dyn.edpnet.net] has quit [Ping timeout: 255 seconds]
13:49 -!- __gotcha1 is now known as __gotcha
13:50 -!- pablomartin4btc [~pablomart@185.216.146.241] has quit [Ping timeout: 264 seconds]
13:59 -!- pablomartin [~pablomart@217.146.93.17] has joined #bitcoin-core-pr-reviews
14:07 -!- Zenton [~user@user/zenton] has quit [Ping timeout: 245 seconds]
14:09 -!- pablomartin [~pablomart@217.146.93.17] has quit [Ping timeout: 272 seconds]
14:24 -!- __gotcha [~Thunderbi@94.105.116.209.dyn.edpnet.net] has quit [Ping timeout: 255 seconds]
14:29 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Remote host closed the connection]
14:30 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
14:35 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 264 seconds]
14:46 -!- __gotcha [~Thunderbi@94.105.116.209.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
14:50 -!- __gotcha [~Thunderbi@94.105.116.209.dyn.edpnet.net] has quit [Ping timeout: 272 seconds]
14:56 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
14:58 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Remote host closed the connection]
14:59 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
15:02 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
15:03 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 258 seconds]
15:10 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
15:30 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Remote host closed the connection]
15:30 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
15:35 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 264 seconds]
15:36 -!- pablomartin [~pablomart@217.146.93.19] has joined #bitcoin-core-pr-reviews
15:41 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
15:46 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 258 seconds]
15:47 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
15:55 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 258 seconds]
16:12 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
16:23 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 264 seconds]
16:46 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
16:50 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 240 seconds]
16:51 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
16:56 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 258 seconds]
17:09 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
17:13 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 240 seconds]
17:25 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
17:30 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 240 seconds]
17:30 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
17:35 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 264 seconds]
17:41 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
17:46 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 248 seconds]
17:53 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
17:58 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 272 seconds]
18:16 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
18:21 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 240 seconds]
18:27 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
18:32 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 258 seconds]
18:52 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
18:57 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 272 seconds]
19:07 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
19:09 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
19:13 -!- MatrixBot1234561 [~matrixbot@2001:bc8:1824:bc3::1] has quit [Ping timeout: 272 seconds]
19:14 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 264 seconds]
19:30 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
19:31 -!- MatrixBot1234561 [~matrixbot@2001:bc8:1824:bc3::1] has joined #bitcoin-core-pr-reviews
19:36 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 240 seconds]
19:44 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
19:48 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 240 seconds]
19:49 -!- grettke [~grettke@065-026-198-174.biz.spectrum.com] has quit [Quit: grettke]
20:05 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
20:11 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 272 seconds]
20:11 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
20:16 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 260 seconds]
20:17 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
20:21 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 240 seconds]
20:28 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
20:32 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 240 seconds]
20:34 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
20:38 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 258 seconds]
20:39 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
20:46 -!- __gotcha [~Thunderbi@94.105.116.209.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
20:48 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 272 seconds]
20:48 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
20:50 -!- __gotcha [~Thunderbi@94.105.116.209.dyn.edpnet.net] has quit [Ping timeout: 255 seconds]
20:53 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 240 seconds]
20:54 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
20:59 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 272 seconds]
21:22 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
21:26 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 260 seconds]
21:32 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
21:36 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 258 seconds]
21:54 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
21:59 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 240 seconds]
22:00 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
22:01 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 252 seconds]
22:01 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
22:06 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 272 seconds]
22:07 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
22:08 -!- __gotcha [~Thunderbi@94.105.116.209.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
22:12 -!- __gotcha [~Thunderbi@94.105.116.209.dyn.edpnet.net] has quit [Ping timeout: 240 seconds]
22:12 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 255 seconds]
22:13 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
22:14 -!- pablomartin [~pablomart@217.146.93.19] has quit [Ping timeout: 255 seconds]
22:20 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 240 seconds]
22:38 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
22:43 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 258 seconds]
22:45 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
22:50 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 258 seconds]
22:56 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
22:56 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
23:03 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
23:07 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 240 seconds]
23:08 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
23:13 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 246 seconds]
23:31 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
23:35 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 272 seconds]
--- Log closed Thu Oct 05 00:00:48 2023