--- Log opened Wed Nov 06 00:00:42 2024
00:07 -!- PaperSword1 [~Thunderbi@securemail.qrsnap.io] has joined #bitcoin-core-pr-reviews
00:07 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has quit [Remote host closed the connection]
00:08 -!- PaperSword1 is now known as PaperSword
00:30 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-pr-reviews
00:31 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has quit [Quit: PaperSword]
00:35 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Ping timeout: 252 seconds]
00:43 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
01:08 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-pr-reviews
01:14 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Ping timeout: 260 seconds]
01:36 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-pr-reviews
01:39 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds]
01:43 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Ping timeout: 260 seconds]
02:15 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-pr-reviews
02:22 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Ping timeout: 252 seconds]
02:37 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
02:55 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-pr-reviews
03:01 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Ping timeout: 276 seconds]
03:09 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has joined #bitcoin-core-pr-reviews
03:33 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-pr-reviews
03:42 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Ping timeout: 272 seconds]
04:15 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-pr-reviews
04:20 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Ping timeout: 246 seconds]
04:30 -!- jon_atack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
04:32 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 246 seconds]
05:03 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-pr-reviews
05:08 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Ping timeout: 276 seconds]
05:17 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-pr-reviews
05:56 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Ping timeout: 260 seconds]
05:58 -!- pablomartin [~pablomart@92.118.61.186] has joined #bitcoin-core-pr-reviews
06:13 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-pr-reviews
06:18 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has joined #bitcoin-core-pr-reviews
06:19 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has quit [Client Quit]
06:37 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has joined #bitcoin-core-pr-reviews
06:55 -!- pablomartin [~pablomart@92.118.61.186] has quit [Ping timeout: 248 seconds]
07:16 -!- itamar [~itamar@2a0d:6fc0:9fd:1900:f0d0:2a67:419c:a2f1] has joined #bitcoin-core-pr-reviews
07:17 -!- itamar [~itamar@2a0d:6fc0:9fd:1900:f0d0:2a67:419c:a2f1] has quit [Client Quit]
07:17 -!- itamar53 [~itamar@2a0d:6fc0:9fd:1900:f0d0:2a67:419c:a2f1] has joined #bitcoin-core-pr-reviews
07:32 < itamar53> Hi
07:33 < stickies-v> hey!
07:38 < itamar53> I'm new here
07:38 < itamar53> I love the idea of Bitcoin
07:38 < itamar53> I want to learn and hopefully even contribute to the Bitcoin Core development, but I have no expirience.
07:38 < itamar53> Where can I learn (video is prefered) how to work with the git repository of bitcoin, how to run tests etc...
07:42 < stickies-v> itamar53: that's great, there are lots of materials out there but finding your way can be challenging. I'd suggest to start having a look at https://bitcoindevs.xyz/bitcoin-core
07:43 < stickies-v> hope you enjoy the journey!
07:57 < itamar53> The link looks geat! Thank you :-)
08:16 -!- hernanmarino [~hernanmar@2800:2330:2800:29b:9956:b57f:a89b:4808] has joined #bitcoin-core-pr-reviews
08:33 -!- adys [~adys@2a06:c701:cb5d:2500:a59d:1140:8cc2:b367] has joined #bitcoin-core-pr-reviews
08:33 < stickies-v> you're welcome!
08:34 < adys> Hey, thanks, happy to join
08:56 -!- chinggg [~chinggg@cspsrv00-ext.mpi-sp.org] has joined #bitcoin-core-pr-reviews
08:59 < tdb3> hi
08:59 -!- hodlinator [~hodlinato@user/hodlinator] has joined #bitcoin-core-pr-reviews
08:59 -!- Emc99 [~Emc99@212.129.76.208] has joined #bitcoin-core-pr-reviews
09:00 < stickies-v> #startmeeting
09:00 < tdb3> Welcome everyone to this month's PR review club
09:00 < hodlinator> hi
09:00 < stickies-v> hi!
09:00 < tdb3> The PR is #30239 (Ephemeral Dust)
09:01 < instagibbs> hi
09:01 < chinggg> Hi
09:01 < tdb3> Let's get started
09:01 < tdb3> Did you review the PR? Concept ACK, approach ACK, tested ACK, or NACK? What was your review approach?
09:01 < stickies-v> do we have any first timers in today's review club? feel free to say hi, even if you're just lurking!
09:02 < stickies-v> (the notes and questions are available on https://bitcoincore.reviews/30239)
09:02 < chinggg> I am a first timer
09:02 < itamar53> HI :-)
09:02 < tdb3> welcome
09:02 < stickies-v> oh hi chinggg, glad you found your way here! i hope you'll find it useful!
09:03 < tdb3> Did folks have a chance to take a look at the PR?
09:03 < stickies-v> i'm still going through the code but it looks like a pretty strong concept ack from me! my review approach is going through the code commit-by-commit
09:04 < tdb3> Same here. The author instagibbs did a great job of making each commit digestible
09:05 < tdb3> Let's dive into some specifics
09:05 < tdb3> Where in code is it determined if an amount is dust?
09:06 < chinggg> IsDust function?
09:07 < stickies-v> that's my understanding too, although there's a bit of a call hierarchy so it depends on how you look at it?
09:07 < hodlinator> ..which is called from IsStandardTx() in policy.cpp, right?
09:07 < tdb3> chinggg: great, yes, IsDust() is called, which in turn calls GetDustThreshold()
09:07 < tdb3> hodlinator: right!
09:07 < tdb3> https://github.com/bitcoin/bitcoin/blob/2a52718d734cf65aaeeb18f627547e5bca3483f4/src/policy/policy.cpp#L26
09:08 < tdb3> Is dust restricted by consensus? Policy? Both?
09:09 < hodlinator> since GetDustThreshold() is implemented in policy.cpp I would expect consensus to not depend on it.
09:10 < hodlinator> (so it would not be restricted by consensus).
09:10 < chinggg> The commit message for GetDustThreshold() was from `Consensus: Minimal way to move dust out of consensus`
09:11 < instagibbs> chinggg woah, TIL
09:11 < chinggg> I mean the comment for the function was from commit `Consensus: Minimal way to move dust out of consensus`, so the function is probably not restricted by consensus anymore
09:12 < instagibbs> ah, it's just moving the defintion
09:12 < instagibbs> 330bb5a456a5f9c26703fa742e4c80691e1455ab
09:13 < tdb3> So then as a follow up to all, could a miner mine a transaction with dust if they chose to?
09:14 -!- __gotcha [~Thunderbi@88-182-109-149.subs.proxad.net] has quit [Ping timeout: 248 seconds]
09:14 < hodlinator> ("move dust out of Consensus" in 330bb5a456a5f9c26703fa742e4c80691e1455ab might be referring to the deprecated libconsensus rather than an actual change to the bitcoin protocol?)
09:15 < stickies-v> yeah they could, both before and after this PR
09:15 < tdb3> stickies-v: right
09:15 < hodlinator> stickies-v +1
09:15 < tdb3> How can dust be problematic? Why do we care if a miner mines dust?
09:16 -!- catnip [~catnip@host-92-9-206-105.as13285.net] has joined #bitcoin-core-pr-reviews
09:18 < tdb3> Any thoughts?
09:18 < stickies-v> it's more an implementation optimization concern than a protocol risk - dust transactions are unlikely to be ever spent, so they may end up bloating the UTXO set forever
09:18 < hodlinator> since dust costs more to spend than the amount it provides by definition, the risk is that the UTXO set will grow for all nodes (pruned and non-pruned, blocks-only and regular).
09:19 < stickies-v> a larger UTXO set can affect transaction validation speed / resource requirements
09:20 < tdb3> stickies-v, hodlinator: that's right. dust transactions can bloat the UTXO set and avoiding performance/resource issues is desirable
09:20 < tdb3> Why is the term ephemeral significant? What are the proposed rules specific to ephemeral dust?
09:20 < instagibbs> tiny utxos may have incentives to sweep them outside of the satoshi value themselves, but putting sats in outputs is another incentive to eventually spend it
09:21 < chinggg> I am not so familiar with the miner's economics. I guess dust could be problematic because the transaction output will not be usable anymore in the future, leading to fragments.
09:22 < tdb3> chinggg: it's great that you brought up the concept of miner's economics/incentives
09:22 < tdb3> Why is the term ephemeral significant? What are the proposed rules specific to ephemeral dust?
09:24 < hodlinator> The PR proposes to allow for relaying dust, but forces the fee of the tx to 0, meaning it is unlikely to make it into a block without a child, which now *has to* spend the dust (else it won't be relayed).
09:25 < tdb3> hodlinator: great description!
09:25 < hodlinator> So the dust is supposed to be short-lived, ephemeral.
09:25 < stickies-v> i think it's significant because it indicates that the dust output is not meant to last, i.e. it gets cleaned up "by definition" (even if it's not guaranteed)
09:25 < tdb3> stickies-v: right! lines up nicely with the meaning of ephemeral
09:26 < tdb3> Why is it important to impose a fee restriction? (0-fee on dusty tx)
09:27 < stickies-v> I think hodlinator already covered that in his previous response about making it less attractive for a minor to include the dusty tx into a block without a spending child?
09:27 < tdb3> That's right. Effectively "has to" be spent
09:27 < tdb3> How are 1P1C relay and TRUC transactions relevant to ephemeral dust?
09:29 < hodlinator> beats me :)
09:29 < tdb3> Let's think through 1P1C relay
09:29 < instagibbs> the PR was originally written with TRUC in mind, which might be a hint 
09:31 < tdb3> Food for thought: If transaction containing dust is 0-fee, then would it meet the minimum relay fee?
09:32 < hodlinator> instagibbs: Yes, but do the latest pushes still rely on it?
09:32 < instagibbs> hodlinator nope, no particular reason it has to
09:32 < stickies-v> an ephemeral dust tx (pretty much) requires a fee-bumping child, but without 1P1C we wouldn't really have a mechanism of relaying this
09:32 < hodlinator> Feels like package relay is more of a requirement to bypass the min relay fee.
09:33 < tdb3> stickies-v: thank you. yes!
09:34 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
09:34 < stickies-v> and TRUC aligns very nicely as well, given that it restricts a v3 transaction having just one unconfirmed parent tx
09:34 < stickies-v> *ancestor, not parent
09:35 < tdb3> that's my understanding as well
09:35 -!- catnip [~catnip@host-92-9-206-105.as13285.net] has quit [Quit: Client closed]
09:35 < instagibbs> one last thing: TRUC currently is the only way to allow <minrelay transactions, including 0-fee
09:35 < instagibbs> (with default settings)
09:35 < hodlinator> okay, so pinning is prevented and sibling eviction is supported.
09:36 < hodlinator> if parent is v3
09:37 -!- itamar53 [~itamar@2a0d:6fc0:9fd:1900:f0d0:2a67:419c:a2f1] has quit [Quit: Client closed]
09:38 < tdb3> The ephemeral dust rules force the child to spend the parent's dust. Why enforce this?
09:38 < tdb3> What could happen if this restriction wasn't in place?
09:41 < stickies-v> i think it's mostly a dos issue?
09:42 < tdb3> If the child wasn't forced to spend the dust of the parent, then the dust would make its way into the UTXO set, right?
09:42 < instagibbs> You could imagine a first child spending dust(yay), then a 2nd child, higher fee, not spending dust. Parent and second child get mined first, then first child evicted
09:42 < instagibbs> (boo!)
09:43 < tdb3> thanks instagibbs
09:43 < stickies-v> wait isn't that talking about two different things?
09:44 < stickies-v> as in: what instagibbs said is about why we don't allow a dusty tx to have > 1 child transactions
09:44 < stickies-v> whereas tdb3's question is about requiring any child to spend the dust output?
09:44 < instagibbs> I'll let people discuss :)
09:45 < tdb3> yeah, I think you're right, we sort of talked about two different things, but they seem fairly related in the sense that we want to avoid non-ephemeral dust as much as possible.
09:46 < instagibbs> You could imagine the rule being: "Make sure the dust is spent by *a* child", but is that sufficient, in other words?
09:47 < stickies-v> oh yes, i agree we can't enforce making the sure the dust output is spent without also enforcing there's only 1 child
09:47 < hodlinator> Should probably be the highest paying child in that case... to encourage it to be within the same block as the parent. Code gets complicated/slower by allowing multiple children..?
09:48 < stickies-v> i just thought the question was about why force the dust to be spent in the first place, which is why i mentioned dos - because otherwise we'd be relaying 0-fee transactions without limit, i think?
09:50 < stickies-v> (and of course the utxo bloat, but i suppose technically that doesn't *need* to be addressed at the relay level)
09:50 < instagibbs> hodlinator yeah you're thinking along the right lines, I think it just becomes really complicated quickly
09:50 < tdb3> great points
09:50 < tdb3> When reviewing the PR, all great things to reason through!
09:51 < tdb3> Looks like we have a few minutes left
09:51 < tdb3> Can a node operator change the amounts considered to be dust? If so, how?
09:53 < hodlinator> By running a pre-segwit node that doesn't see witness bytes?
09:54 < tdb3> Interesting. How so?
09:54 < stickies-v> there's also the `-dustrelayfee` startup option
09:55 < hodlinator> If the witness data makes the tx big enough that segwit nodes calculate the outputs as below the dust limit, but a non-segwit node only sees the transaction without the witness data bytes?
09:55 < tdb3> stickies-v: yes, thanks
09:56 < tdb3> hodlinator: that's pretty interesting!
09:56 < tdb3> hadn't thought of that
09:57 < instagibbs> can you elaborate? GetDustThreshold is a function over the output being made, and the dust relay rate
09:57 < tdb3> If a node set -dustrelayfee such that all dust is allowed, are the ephemeral dust rules enforced?
09:58 < stickies-v> instagibbs: +1, I don't think segwit is relevant here
09:58 < tdb3> What would happen if the node tries to broadcast a transaction after adjusting the amounts it considers dust?
10:01 < tdb3> any thoughts?
10:01 < hodlinator> tdb3: Probably rejected by peers.
10:02 < chinggg> +1
10:02 < tdb3> hodlinator: yes, as I understand it, the other nodes receiving the tx would refuse to relay it
10:02 -!- catnip [~catnip@host-92-9-206-105.as13285.net] has joined #bitcoin-core-pr-reviews
10:03 < tdb3> and to touch on the first question, the first commit of the PR creates a great test that ensures that ephemeral dust rules don't conflict with adjusting dust limits
10:04 < tdb3> I don't want to hold people up, but I'm happy to stay a bit longer
10:04 < instagibbs> thanks tdb3
10:04 < tdb3> As a last bit to discuss, there are some great tests introduced in this PR
10:04 < stickies-v> let's wrap up the meeting here and folks who want to stay on / discuss more are of course welcome to do so!
10:05 < tdb3> Which types of tests were created for the PR? What is the purpose of each type of test?
10:05 < tdb3> stickies-v: sounds great, thanks
10:05 < stickies-v> thanks a lot for hosting this meeting tdb3, that was such a helpful way to go through the PR. and of course thank you instagibbs for your work on this code, and to join today as well!
10:05 < tdb3> thanks all, take care
10:05 < hodlinator> thanks!
10:05 < stickies-v> #endmeeting
10:06 < chinggg> I used to contribute to fuzz testing of Bitcoin Core. I can see there is functional test implemented.
10:06 -!- Emc99 [~Emc99@212.129.76.208] has quit [Quit: Client closed]
10:06 -!- adys [~adys@2a06:c701:cb5d:2500:a59d:1140:8cc2:b367] has quit [Ping timeout: 256 seconds]
10:06 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
10:07 < tdb3> chinggg: yes, that's right. there are some great functional tests in this PR, covering various ephemeral dust scenarios
10:08 < tdb3> functional tests are a great way to exercise a node as a whole
10:08 < tdb3> what other types of tests are present?
10:09 < chinggg> Oh, there are also fuzz tests added in package_eval.cpp
10:09 -!- catnip [~catnip@host-92-9-206-105.as13285.net] has quit [Quit: Client closed]
10:10 < instagibbs> chinggg yes, big believer in fuzz harnesses 
10:10 < tdb3> any other types?
10:10 < tdb3> (of tests)
10:11 < chinggg> unit tests in transaction_tests.cpp and txvalidation_tests.cpp
10:12 -!- catnip [~catnip@host-92-9-206-105.as13285.net] has joined #bitcoin-core-pr-reviews
10:13 -!- catnip [~catnip@host-92-9-206-105.as13285.net] has quit [Client Quit]
10:13 < tdb3> what would be the purpose of a functional test vs a unit test?
10:17 < chinggg> As you said in previous message, "functional tests are a great way to exercise a node as a whole", so I guess may detect unexpected bug? While unit tests should just manually assert that implementation of ephemeral dust meets the spec of proposed concept.
10:17 -!- itamar [~itamar@2a0d:6fc0:9fd:1900:f0d0:2a67:419c:a2f1] has joined #bitcoin-core-pr-reviews
10:19 < tdb3> Some aspects would be scope, and another would be coverage. Unit tests help exercise smaller, more scoped portions of the code. Also, sometimes it's not as easy to exercise paths through the code from the outside, so unit tests provide a way to test these types of paths.
10:20 < tdb3> I have to jump off soon, so I'll mention the last type of "test": benchmarks
10:20 < chinggg> Gotcha
10:20 < tdb3> These provide a way to obtain information about the performance rather than just the functional aspects of the code
10:21 < tdb3> I wanted to make sure mention tests, because I think instagibbs did an excellent job of including many types of tests in this PR. It's a bit of a unicorn!
10:22 < tdb3> That's all for now, but thanks again for joining and take care!
10:23 < chinggg> Thanks tdb3 hosting the meeting and instagibbs making the PR and any others joining the meeting!
10:31 -!- adys [~adys@2a06:c701:cb5d:2500:a59d:1140:8cc2:b367] has joined #bitcoin-core-pr-reviews
10:51 -!- pablomartin [~pablomart@92.118.61.174] has joined #bitcoin-core-pr-reviews
11:07 -!- adys [~adys@2a06:c701:cb5d:2500:a59d:1140:8cc2:b367] has quit [Ping timeout: 256 seconds]
11:08 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has quit [Quit: PaperSword]
11:36 -!- pablomartin [~pablomart@92.118.61.174] has quit [Ping timeout: 248 seconds]
11:39 -!- itamar [~itamar@2a0d:6fc0:9fd:1900:f0d0:2a67:419c:a2f1] has quit [Ping timeout: 256 seconds]
11:41 -!- chinggg [~chinggg@cspsrv00-ext.mpi-sp.org] has quit [Ping timeout: 256 seconds]
12:33 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
13:01 -!- Talkless [~Talkless@mail.dargis.net] has quit [Ping timeout: 276 seconds]
14:58 -!- hebasto [sid449604@id-449604.uxbridge.irccloud.com] has quit [Ping timeout: 260 seconds]
14:58 -!- hebasto [sid449604@id-449604.uxbridge.irccloud.com] has joined #bitcoin-core-pr-reviews
14:59 -!- RubenSomsen [sid301948@user/rubensomsen] has quit [Ping timeout: 260 seconds]
15:00 -!- RubenSomsen [sid301948@user/rubensomsen] has joined #bitcoin-core-pr-reviews
16:01 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has quit [Quit: Connection closed for inactivity]
16:53 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has joined #bitcoin-core-pr-reviews
16:55 -!- pablomartin [~pablomart@92.118.61.181] has joined #bitcoin-core-pr-reviews
18:00 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Remote host closed the connection]
18:00 -!- dongcarl [~dongcarl@syn-066-065-169-019.res.spectrum.com] has quit [Quit: Ping timeout (120 seconds)]
18:01 -!- dongcarl [~dongcarl@syn-066-065-169-019.res.spectrum.com] has joined #bitcoin-core-pr-reviews
18:31 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-pr-reviews
18:36 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Ping timeout: 276 seconds]
18:55 -!- pablomartin [~pablomart@92.118.61.181] has quit [Ping timeout: 248 seconds]
19:07 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-pr-reviews
19:17 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Ping timeout: 260 seconds]
19:40 -!- Netsplit *.net <-> *.split quits: ghost43
19:46 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-pr-reviews
19:53 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Ping timeout: 252 seconds]
20:09 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-pr-reviews
20:18 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Ping timeout: 246 seconds]
20:33 -!- takinbo [~takinbo@user/takinbo] has quit [Ping timeout: 244 seconds]
20:43 -!- takinbo [~takinbo@user/takinbo] has joined #bitcoin-core-pr-reviews
20:49 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-pr-reviews
20:55 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Ping timeout: 252 seconds]
21:13 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-pr-reviews
21:19 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Ping timeout: 260 seconds]
21:51 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-pr-reviews
21:56 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Ping timeout: 252 seconds]
22:10 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-pr-reviews
22:15 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Ping timeout: 260 seconds]
22:28 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-pr-reviews
22:34 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Ping timeout: 276 seconds]
22:45 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-pr-reviews
22:50 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Ping timeout: 272 seconds]
23:22 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-pr-reviews
23:27 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has quit [Ping timeout: 248 seconds]
23:58 -!- kevkevin [~kevkevin@209-242-39-30.rev.dls.net] has joined #bitcoin-core-pr-reviews
--- Log closed Thu Nov 07 00:00:43 2024