--- Log opened Wed Feb 22 00:00:28 2023
--- Day changed Wed Feb 22 2023
00:00 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 252 seconds]
00:07 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
00:11 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 255 seconds]
00:17 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
00:22 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 260 seconds]
00:23 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
00:28 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 248 seconds]
00:34 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
00:39 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 260 seconds]
00:44 -!- __gotcha [~Thunderbi@94.105.118.205.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
00:45 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
00:50 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 260 seconds]
00:51 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
00:56 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 264 seconds]
00:57 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
01:05 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 255 seconds]
01:23 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
01:31 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 265 seconds]
01:32 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
01:39 -!- __gotcha [~Thunderbi@94.105.118.205.dyn.edpnet.net] has quit [Remote host closed the connection]
01:39 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 260 seconds]
01:39 -!- __gotcha [~Thunderbi@94.105.118.205.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
01:42 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
01:47 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 252 seconds]
01:49 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
01:54 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 255 seconds]
01:56 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
02:00 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 252 seconds]
02:06 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
02:11 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 246 seconds]
02:13 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
02:17 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 264 seconds]
02:40 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
02:45 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 260 seconds]
02:51 -!- theStack [~theStack@95.179.145.232] has joined #bitcoin-core-pr-reviews
02:51 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
02:58 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 246 seconds]
03:00 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
03:04 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 260 seconds]
03:11 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
03:15 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 260 seconds]
03:27 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
04:26 -!- abubakarS64 [~abubakarS@197.210.71.64] has joined #bitcoin-core-pr-reviews
04:26 -!- abubakarS64 [~abubakarS@197.210.71.64] has quit [Client Quit]
04:38 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
04:39 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
04:46 -!- abubakarsadiq [~abubakars@102.91.4.95] has joined #bitcoin-core-pr-reviews
05:03 -!- __gotcha1 [~Thunderbi@94.105.118.205.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
05:03 -!- __gotcha [~Thunderbi@94.105.118.205.dyn.edpnet.net] has quit [Read error: Connection reset by peer]
05:03 -!- __gotcha1 is now known as __gotcha
05:13 -!- abubakarsadiq [~abubakars@102.91.4.95] has quit [Read error: Connection reset by peer]
05:18 -!- abubakar1adiq [~abubakars@102.91.5.16] has joined #bitcoin-core-pr-reviews
05:26 -!- abubakarsadiq [~abubakars@102.91.4.95] has joined #bitcoin-core-pr-reviews
05:26 -!- abubakar1adiq [~abubakars@102.91.5.16] has quit [Read error: Connection reset by peer]
05:35 -!- __gotcha [~Thunderbi@94.105.118.205.dyn.edpnet.net] has quit [Remote host closed the connection]
05:36 -!- __gotcha [~Thunderbi@94.105.118.205.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
05:48 -!- Zenton [~user@user/zenton] has joined #bitcoin-core-pr-reviews
05:49 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 246 seconds]
05:56 -!- buddy85 [~Teresia@149.34.242.38] has joined #bitcoin-core-pr-reviews
06:46 -!- abubakarsadiq [~abubakars@102.91.4.95] has quit [Read error: Connection reset by peer]
06:48 -!- __gotcha [~Thunderbi@94.105.118.205.dyn.edpnet.net] has quit [Read error: Connection reset by peer]
06:49 -!- __gotcha [~Thunderbi@94.105.118.205.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
07:10 -!- abubakarsadiq [~abubakars@197.210.52.214] has joined #bitcoin-core-pr-reviews
07:11 -!- abubakarsadiq is now known as abubakar
07:35 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
07:37 -!- pakaro [~quassel@142.157.222.64] has joined #bitcoin-core-pr-reviews
08:09 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
08:10 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
08:24 -!- codo [~codeautis@user/codeautist] has joined #bitcoin-core-pr-reviews
08:41 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has joined #bitcoin-core-pr-reviews
08:55 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
08:57 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews
08:57 -!- abubakar [~abubakars@197.210.52.214] has quit [Ping timeout: 252 seconds]
08:59 -!- abubakar [~abubakars@197.210.52.214] has joined #bitcoin-core-pr-reviews
09:00 < glozow> #startmeeting
09:00 -!- Tobses [~Tobses@102.89.44.131] has joined #bitcoin-core-pr-reviews
09:00 < glozow> Hi everyone, welcome to PR Review Club! Feel free to say hi so we know who's here.
09:00 -!- d33r_gee [~d33r_gee@45-27-31-99.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-pr-reviews
09:00 < LarryRuane> hi!
09:00 < Tobses> Hi
09:00 < svav> Hi!
09:00 < codo> hi
09:00 < theStack> hi
09:00 < d33r_gee> hello
09:00 < michaelfolkson> hi
09:00 < glozow> We're looking at #25038 today, focusing on the v3 transaction relay policy commits. Notes are here: https://bitcoincore.reviews/25038
09:01 < stickies-v> hi
09:01 < pakaro> hi
09:01 < glozow> I wrote up questions but it's highly unlikely we'll get through all of them. Also the goal here is to learn, so please feel free to ask your own questions whenever you like.
09:01 < glozow> To get a sense of where everyone's at, did y'all get a chance to read through some of the notes or take a look at the PR?
09:02 < pakaro> y, read notes & some history
09:02 < codo> Using the notes as a guide I spent a lot of time catching up on background knowlegde (what are pinning attacks, watch old presentation, read doc/policy/* on master, what is nVersion, broaden git knowledge, ...). I will lurk and see how much of the conversation I understand.
09:02 < svav> Read the notes
09:02 < LarryRuane> Hey really quick meta github type question, if I may ... Does a PR being in "draft" status mean it's going to change a lot so hold off reviewing? Or does it tell the maintainers not to merge it yet (but what's there is good to review)? I've seen both interpretations
09:02 < stickies-v> y notes
09:02 < theStack> read the notes, didn't look too far into the code yet
09:02 < LarryRuane> y notes, referenced materials
09:02 < glozow> Wonderful to hear how much preparation y'all have done! :)
09:02 < d33r_gee> read the notes and watch your presentation glozow
09:03 < stickies-v> LarryRuane: I always interpret it as looking for concept/approach ack but nothing further
09:03 < glozow> larryruane: I think "draft" means "not mergeable" and sometimes "not reviewable." I put PRs in draft when the depend on other PRs, or if there's a bug in it I haven't fixed yet
09:03 < glozow> when they*
09:03 -!- abubakar [~abubakars@197.210.52.214] has quit [Ping timeout: 246 seconds]
09:03 < LarryRuane> glozow: stickies-v: thanks!
09:04 < michaelfolkson> y notes
09:04 -!- abubakar [~abubakars@197.210.52.214] has joined #bitcoin-core-pr-reviews
09:04 < jamesob> hi
09:04 < glozow> and yes, like stickies-v mentioned, I think usually reviewing it =  concept and approach. I wouldn't leave a comment like "hey you should rename this variable" on a draft PR
09:04 < glozow> hi jamesob!
09:04 -!- ranemirus [~ranemirus@181.105.17.185] has joined #bitcoin-core-pr-reviews
09:05 < abubakar> hi new here
09:05 < glozow> Would anybody like to summarize what problems we're trying to solve, and how V3 might be a solution?
09:05 < glozow> abubakar: welcome!
09:06 < LarryRuane> at a very high level, I would say that without V3 (as things are currently), there are a lot of DoS potentials; V3 is trying to close them
09:06 -!- Jim51 [~Jim@cpe-66-75-11-2.san.res.rr.com] has joined #bitcoin-core-pr-reviews
09:06 < LarryRuane> but V3 is strictly policy (not consensus), so only affects mempool acceptance and relay
09:06 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
09:06 < d33r_gee> mitigate pinning attacks (?)
09:07 < stickies-v> we're trying to make it easier for (mostly) off-chain protocols to ensure being able to quickly confirm on-chain if necessary, and v3 does that by reducing the complexity of allowed (unconfirmed) transaction clusters
09:07 < abubakar> v3 will enable rbf without signaling opting into rbf
09:08 < glozow> LarryRuane: d33r_gee: stickies-v: yep, I agree with these descriptions. The goal is to create a policy that's DoS-resistant and makes it more feasible to assess the incentive-compatibility of transactions. If adopted by most nodes, it should close pinning attacks which grief l2 protocols.
09:08 < pakaro> currently when LN-transactions settle on chain, the fee-rate is set when the anchor tx was first signed but unpublished. rbf is a solution, but currently vulnerable to tx-pinning attacks. v3's are non-standard txs that preclude tx-pinning [hopefully]
09:09 < glozow> abubakar: I think you're thinking of Full Rbf. V3 is another way of opting in to replaceability. It does not change the fact that RBF policy requires opt-in.
09:09 < LarryRuane> curious about one thing, I was initially surprised that we could even bump the version number! Are we doing that because we already used `nSequence` "hack" for BIP125 indication? Another way to ask, could RBF BIP125 have bumped the version number instead of using `nSequence`?
09:11 < LarryRuane> pakaro: "v3's are non-standard txs" -- well, that changes if / when this and related PRs get merged
09:11 < pakaro> Thanks LarryRuane: i was wondering v3s would propogate through the network, so if merged, v3s will become standard then
09:12 < pakaro> wondering how v3s**
09:12 < glozow> LarryRuane: good question. I used nVersion instead of nSequence because I could use something that was currently non-standard. It's hard to ensure apps/protocols aren't already reserving nSequence numbers for things.
09:13 < glozow> abubakar's point, though, brings us to Question #1: What is the difference between a transaction that “explicitly” signals BIP125 and one that “inherits” BIP125 signaling? Why is it impossible for a v3 transaction to be one but not the other?
09:14 -!- Eppie [~Eppie@102.89.46.237] has joined #bitcoin-core-pr-reviews
09:14 < svav> What's an nSequence number?
09:14 < theStack> "explicit" signaling: one of the tx's inputs have an nSequence < 0xfffffffe (see `SignalsOptInRBF`); "inherited" signaling: one of the tx's ancestors txs shows "explicit" signaling; in v3 world we just always signal replacability
09:14 < LarryRuane> glozow: makes sense... and if old (pre- these PRs) see a v3 tx in a block, they consider it valid (probably don't even care about the version number?)
09:14 < LarryRuane> *old nodes
09:14 < theStack> should say "one of the tx's _unconfirmed_ ancestors" i guess
09:15 < glozow> svav: it's one of the fields in a tx input. https://github.com/bitcoin/bitcoin/blob/8b4dc94734a2472a201296376bfb18f982e6d92f/src/primitives/transaction.h#L79
09:15 < glozow> We use it for timelocks and signaling BIP125
09:15 < stickies-v> svav: see https://bitcoin.stackexchange.com/questions/87372/what-does-the-sequence-in-a-transaction-input-mean for a nice overview
09:16 < svav> Thanks guys
09:16 < abubakar> glowzow: the non v3 transaction opt in via the nsequence whereas ancestor of v3 transaction inherits BIP125 signaling
09:16 < Jim51> Thanks x2
09:17 < glozow> theStack: correct! And yes, in v3, you can't spend from an unconfirmed v3 without also being v3. So there is no way to inherit but not explicitly signal.
09:19 < glozow> LarryRuane: yes, there is no change in consensus. But in policy we want to strictly loosen rules. Otherwise we could accidentally censor transaction relay for an application. So either we really really make sure nobody is using it currently, or just pick something that's nonstandard today. In a sense, we always want consensus changes to be soft forks, but policy changes to be "hard forks."
09:20 < glozow> stickies-v: ahh nice link!
09:21 < LarryRuane> let's say someone submits a NON-v3 that spends an unconfirmed v3 ... it's not accepted into the mempool, but depending on timing, if its unconfirmed parent happens to get mined, then this non-v3 can be accepted -- that's interesting i think
09:21 < LarryRuane> glozow: very interesting!! thanks!
09:21 < michaelfolkson> Ha that's interesting. Policy is being loosened over time and consensus is being unloosened over time. Going in opposite directions
09:22 < glozow> abubakar: yes, a non-v3 transaction opts in by setting one of is nSequence numbers to a BIP125-signaling number. A v3 transaction is free to do this too. Ancestors do not inherit anything.
09:22 < LarryRuane> michaelfolkson: +1
09:23 < glozow> I'm going to throw out the next question but again feel free continue asking your own. Why should there be a rule to check whether a replacement transation is more incentive compatible to mine?
09:24 < LarryRuane> because if we don't do that, miners may run custom software that IS incentive compat, and then miners' mempools and the rest of the full nodes mempools would diverge?
09:24 < glozow> LarryRuane: yes, it's normal for mempool acceptance to depend on the chainstate. Similar to a transaction that spends 25 just-confirmed transactions. Or even a transaction that spends a 1-block relative timelocked output that just confirmed.
09:25 < LarryRuane> glozow: yes, good point!
09:25 < d33r_gee> q2:  it is important to ensure that the replacement transaction that replaces an existing unconfirmed transaction offers a higher fee so that it is more attractive to miners and has a higher chance of being included in the next block.
09:26 -!- Eppie [~Eppie@102.89.46.237] has quit [Quit: Connection closed]
09:26 < stickies-v> glozow: "A v3 transaction is free to do this too." - it's allowed, but pointless, right?
09:26 < LarryRuane> and in the scenarios both of us mentioned, if a tx is currently non-standard but MAY become standard soon, we don't hold onto it in an orphanage or something, do we? We just drop it immediately?
09:27 < LarryRuane> stickies-v: (if i may attempt an answer), yes, pointless, but doesn't make the tx invalid
09:28 < glozow> stickies-v: yeah, it would be redundant to be both v3 and signal, but harmless. I imagine it would happen because wallets are automatically setting their nSequence to signal BIP125, and then they add support for v3 and there's no reason to change the former default
09:28 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
09:28 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
09:29 < glozow> and signal BIP125*
09:29 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
09:30 < abubakar> why is it that descendant of v3 transaction sizes are restricted to 1000vb
09:30 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
09:31 < pakaro> abubakar: 1000vb is enough so that many inputs are allowed, but not so high that you aren't abusing the network. iirc.
09:31 < glozow> d33r_gee: yes, that's part of the answer! but, rewording the question a bit, assuming the replacement tx always increases the overall fee and feerate of the mempool, would it be ok if the replacer would be selected later than the replacee?
09:32 < glozow> hint: see the "No increase in incentive compatibility required" pinning attack in the notes
09:32 < stickies-v> abubakar: in addition to pakaro 's answer - replacement rules require the new transaction to pay for all descendants too, so the more descendants allowed, the more expensive it can become to replace a transaction
09:32 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed]
09:32 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has quit [Quit: Client closed]
09:32 < glozow> abubakar: you may want to take a look at "Pinning through absolute fee rules" in the notes
09:33 < abubakar> will do thanks..
09:34 < glozow> We can answer this question by asking "is there ever a scenario where you would want to pay *more* fees for a transaction to confirm *slower*?"
09:35 < pakaro> stickies-v how do descendants and unconfirmed parents relate? In my understanding, a v3 tx can only have 1 unconfirmed parents...To me that means that, inversely, a parent can only have 1 descendant..so how do we get multiple descendants? Is it that multiple-descendants exist in situations where the v3 was not included, and then the design is that v3 transactions come in later, and _those_ can only have 1 descendant?
09:36 < LarryRuane> glozow: if you're an attacker, trying to pin?
09:36 < glozow> pakaro: in the non-v3 world, a transaction can have multiple descendants. A transaction can also have an up-to-100KvB descendant.
09:36 < michaelfolkson> glozow: You mean like ensuring a child transaction was in a different block to its parent rather than in the same one? Probably but can't think of a scenario...
09:37 < pakaro> glozow: so the multiple descendants were already there, in this hypthetical case?
09:37 < stickies-v> pakaro: I was talking about "descendants" in terms of total size (vbytes) here, not count. sorry for the confusion. if we allow only a single descendant, but it can be a very large descendant, that can become costly again
09:37 < pakaro> stickies-v: hadn't thought about v.large single descendants, thanks!
09:38 < michaelfolkson> Maybe if you wanted to wait and see what other parties did and then depending on that RBFing the parent so the child was no longer valid...
09:38 < glozow> LarryRuane: bingo! Since we don't require the replacer to be more incentive compatible to mine than the replacee, attackers can pin transactions by replacing them and adding low-feerate ancestors. Of course, they have to be able to edit the transaction and bring in more inputs. But this is the case with SIGHASH_ANYONECANPAY transactions (of which there are thousands every day).
09:39 < d33r_gee> glozow hmmm... yes the replacer could be selected later than the replaccee if the replacee is time-sensitive (e.g. it is a transaction needed for a time-sensitive application), it may be important to prioritize the replacee over the replacer even if the replacer has a higher fee and feerate (still wrapping my head around those use cases)
09:39 < michaelfolkson> (Ha I was thinking honest non-attacker use cases)
09:40 -!- Eppie [~Eppie@102.89.43.142] has joined #bitcoin-core-pr-reviews
09:41 < stickies-v> d33r_gee: the network can't have an understanding about what's time-sensitive or honest etc, so I think in practice we only really have the fees to look at
09:41 < glozow> yeah my point here is the only use case is pinning attacks haha
09:43 < d33r_gee> glozow makes sense... so being aware of the attacker use case would be the thing to look for (?)
09:45 < glozow> d33r_gee: the hope is we get rid of this pinning attack
09:46 < d33r_gee> glozow got it
09:46 < glozow> Is min(package feerate, individual feerate) an accurate incentive compatibility score for v3 transactions? What about non-v3?
09:47 < michaelfolkson> d33r_gee: Depending on the protocol (Lightning, vaults etc) part of security model is you watch the chain for an attacker broadcasting a transaction they shouldn't and respond. Being pinned prevents your a speedy response
09:47 -!- grettke [~grettke@184.55.131.155] has joined #bitcoin-core-pr-reviews
09:47 < LarryRuane> glozow: I think it is, at least for v3, because it recognizes that children can pay for parents, but parents can NOT pay for children!
09:48 -!- Eppie [~Eppie@102.89.43.142] has quit [Quit: Connection closed]
09:48 < glozow> Ah I just realized my question is a bit ambiguously worded. More precisely, is `CheckMinerScores` an accurate assessment for v3 https://github.com/bitcoin-core-review-club/bitcoin/commit/58e811ecb1e1977422ecda2af62460e8efc057be
09:49 < glozow> But yes the idea is, in v3, it's accurate. In non-v3, it's not accurate. You need to look further than your ancestor set or descendant set.
09:50 < LarryRuane> you have to look at your entire cluster (cousins, etc)
09:50 < LarryRuane> *siblings, actually, and beyond
09:51 < glozow> LarryRuane: yep. If you're a child, min(child, parent+child) is correct since your parent can get selected without you.
09:51 < glozow> LarryRuane: yes :D
09:52 < glozow> What's the maximum cluster size for a v3 transaction? What's the maximum cluster size for a non-v3?
09:52 < codo> 2 resp. 101?
09:52 < pakaro> 1000vb and 100,000vb ?
09:52 < d33r_gee> michaelfolkson thanks for clarifying and here a response is to remove the tx from our mempool?
09:53 < glozow> codo: 2 is correct for v3
09:53 < theStack> maximum cluster size for non-v3 seems to be basically unlimited?
09:53 < glozow> I'm looking for an answer where the unit is number of transactions
09:53 < stickies-v> theStack: +1
09:53 < glozow> theStack: stickies-v: bingo 💯
09:54 < glozow> frequent review club attendees and people who have been around me for more than 10 minutes know: there is currently no limit on cluster size
09:54 < glozow> If all mining nodes on the network are running with this v3 policy, while none of the non-mining nodes are, what happens?
09:55 < michaelfolkson> d33r_gee: No your response is to broadcast a pre-signed transaction remedying the situation (assuming you can and you aren't pinned)
09:55 < theStack> no v3 txs would ever reach a miner, since all non-mining nodes reject those form the mempool. so i guess the answer to that question would be "nothing" :p
09:55 < theStack> *from
09:56 < pakaro> +1 thestack
09:56 < LarryRuane> glozow: I'd say the v3 stuff still gets mined, but the non-mining mempools would have a lot of junk that can't get mined
09:56 -!- abubakar_ [~abubakars@197.210.77.158] has joined #bitcoin-core-pr-reviews
09:56 < abubakar_> does cluster size means the descendant and ancestors altogether?
09:56 < d33r_gee> michaelfolkson ah good to know... this attack vector is tricky indeed
09:57 < LarryRuane> abubakar_: yes, but "THERE'S MORE!" ... also all siblings, uncles, cousins, 2nd cousins, etc.
09:57 < glozow> theStack: correct! also, if a miner mines v3 transactions, everybody would still accept them. the point of this question is "it's policy, not consensus"
09:58 < LarryRuane> oh I forgot that v3 is currently non-standard ... right glozow: and @theStack
09:58 < pakaro> is a sibling just another unconfirmed tx that spends the same inputs as _its_ sibling?
09:59 < glozow> pakaro: sibling is a tx that spends another output from your parent tx
09:59 -!- abubakar [~abubakars@197.210.52.214] has quit [Ping timeout: 252 seconds]
09:59 < stickies-v> abubakar_: see the notes in https://bitcoincore.reviews/26152 for more info about ancestors vs clusters
09:59 < LarryRuane> pakaro: simplest example of a sibling is one that has a parent that's also our own parent
09:59 < pakaro> ofc, thx glozow larryruane
10:00 < abubakar_> stickies-v:thanks!
10:00 < glozow> We're out of time but I'm around for a bit longer to answer any questions anybody has
10:00 < glozow> #endmeeting
10:00 < codo> For LN to profit from this, a large part of the network should see V3 as standard, right? If so: won't it take some time (like a year) before LN channels based on V3 will be opened?
10:00 < LarryRuane> glozow: any chance we could have a part 2 next week? there's a lot we didn't get to, and this is great stuff!
10:01 < michaelfolkson> LarryRuane: +1
10:01 < stickies-v> 🥇 to glozow for probably the most elaborate notes and questions in the history and future of the review club - thank you!
10:01 < LarryRuane> (or part 2 could be later, but then people might forget part 1)
10:01 < Jim51> +1
10:01 < d33r_gee> LarryRuane +1
10:01 < glozow> last time I did a part 2, nobody really showed up to the second one 😅
10:01 < abubakar_> glowzow :the 2 clusters of v3, is it helpful to LN 
10:01 < LarryRuane> stickies-v: 💯
10:01 < LarryRuane> oh sorry to hear that
10:01 < theStack> thanks for hosting glozow! really interesting topic, would also love to see a part 2 :)
10:01 < abubakar_> LarryRuane:+1
10:02 < michaelfolkson> The +1s promise to attend a second one
10:02 < glozow> closing pinning attacks and adding package RBF would be helpful to LN yes, and adopting this set of policies would be one way of doing that
10:02 < pakaro> +1
10:02 < pakaro> i had a [hopefully quick] meta-question -> the _v3_ refers to v0=p2pkh, v1-p2sh-p2wpkh, v2=p2wpkh, v3=anti-pinning-tx.?
10:02 < LarryRuane> is there much controversy about adding v3?
10:02 < abubakar_> +1
10:03 < ranemirus> thanks everyone, first time here!
10:03 < LarryRuane> pakaro: no, all of those are v2
10:03 < d33r_gee> thanks glozow and every1! See yall next time
10:03 < glozow> LarryRuane: well v3 isn't perfect. It'll also take time, as codo points out
10:03 -!- d33r_gee [~d33r_gee@45-27-31-99.lightspeed.sntcca.sbcglobal.net] has quit [Quit: Connection closed]
10:03 < LarryRuane> ranemirus: great to have you here!
10:03 < theStack> i have one question regarding the actual code, on the very first commit ( https://github.com/bitcoin/bitcoin/pull/25038/commits/5d0a0ca44aea14b9e907114daef15106a9311c95 ) ... was getting very confused about the naming "poor" and "rich" there. the tx_poor pays a fee, while the tx_rich pays zero fee. shouldn't it be the other way round?
10:04 -!- Jim51 [~Jim@cpe-66-75-11-2.san.res.rr.com] has quit [Quit: Connection closed]
10:04 < Tobses> Thank you, everyone... really learnt alot.. First time here also.
10:04 < LarryRuane> theStack: +1 - i was wondering that too
10:04 < LarryRuane> Tobses: so glad you could be here!
10:05 -!- abubakar [~abubakars@197.210.53.131] has joined #bitcoin-core-pr-reviews
10:05 -!- abubakar_ [~abubakars@197.210.77.158] has quit [Read error: Connection reset by peer]
10:05 < pakaro> LarryRuane what are v0, v1 transactions? i was thinking v0 segwit & v1 segwit.
10:05 -!- abubakar [~abubakars@197.210.53.131] has quit [Read error: Connection reset by peer]
10:06 < glozow> requires some patience. here's a podcast painting a picture of a Whole New World with v3, ephemeral anchors, eltoo, etc.: https://podcast.chaincode.com/2023/02/15/greg-sanders.html
10:06 -!- ranemirus [~ranemirus@181.105.17.185] has quit [Quit: Connection closed]
10:06 < LarryRuane> glozow: ty!
10:06 < glozow> theStack: haha I suppose the naming is weird, though notice that tx_rich has a high modified fee
10:06 < glozow> tx_poor pays minrelay fee
10:07 < glozow> L94: `node.prioritisetransaction(tx_rich["txid"], 0, int(DEFAULT_FEE * COIN))`
10:08 < glozow> pakaro: those are output witness versions. here, we're talking about the value of the transaction's nVersion field
10:08 < theStack> glozow: oh, i see. should have looked further
10:09 < theStack> IIUC then the comment "another has 0 fees but is bumped by child" should probably be "another has minrelay fee but is bumped by child"?
10:09 < pakaro> glozow thanks!
10:10 < glozow> theStack: yes, that comment is not very accurate, apologies
10:17 < theStack> no worries, just wanted to check that my assumption of "poor"/"rich" refering to the fees paid by that tx and not something else
10:17 < theStack> do you still have time for q4? (or would that be better for part2? :p)
10:18 < glozow> I guess part 2 is happening 😂 y'all better be here
10:18 < theStack> :D
10:18 < glozow> yes, I'm free for Q4 if you have an answer!
10:18 < glozow> Imagine that there are two conflicting transactions, txA and txB, both 2,000vB. We really need one of them to confirm immediately, but it doesn’t matter which one. A malicious counterparty has already broadcast transaction txB which pays 10,000sat in fees (5sat/vB). We also know that it’s guaranteed (just pretend, ok?) that anything above 20sat/vB will be mined immediately, while anything below 20sat/vB will not. 
10:18 < glozow> Let’s say txA and txB are non-v3 transactions. What fee can we put on txA to guarantee that either txA or txB will reach a package feerate of 20sat/vB?
10:20 < theStack> struggled a bit at first on this... ended up with answer 2010000 sats (solved equation `(10000 + x) / (2000 + 99000) = 20` for x)
10:20 < glozow> Yes wonderful answer!
10:21 < Tobses> wow
10:21 < glozow> Idea being, you might need to replace a 99KvB descendant
10:21 < glozow> But if that 99KvB descendant pays enough to bump to 20sat/vB, then you win even if you didn't RBF
10:22 < glozow> Now imagine txA and txB are both v3 transactions. What fee can we put on txA to guarantee that either txA or txB will reach a package feerate of 20sat/vB?
10:23 -!- Zenton [~user@user/zenton] has quit [Ping timeout: 260 seconds]
10:23 < theStack> in this case the descendant can only have a max size of 1KvB
10:23 < glozow> Yep, so (10000 + x) / (2000 + 1000) = 20
10:23 < theStack> so i got the result 50000 sats... (solving `(10000 + x) / (2000 + 1000) = 20` for x)
10:24 < glozow> Yep, much more reasonable!
10:25 < theStack> indeed... txA's fee-rate would then be 25 sats/vbyte instead of 1005 sats/vbyte
10:25 < glozow> I suppose the *exact* fee also depends on the size of txB in order to meet Rule 4, but that'd be a few hundred sats different
10:26 < theStack> ah, interesting point, didn't think of that
10:27 < glozow> So yes :) this addresses "Rule 3 pinning" by effectively setting a more reasonable upper bound on what you might need to pay if they try to pin you this way
10:27 < pakaro> 40x more reasonable!
10:27 -!- IgboPharaoh [~IgboPhara@197.210.53.234] has joined #bitcoin-core-pr-reviews
10:30 -!- IgboPharaoh [~IgboPhara@197.210.53.234] has quit [Client Quit]
10:30 -!- IgboPharaoh [~IgboPhara@197.210.76.187] has joined #bitcoin-core-pr-reviews
10:31 < theStack> very nice idea creating a "v3 world" with quite strict policy limits to solve the pinning issues. is there any risk that the limits are chosen to be too tight, and other L2 protocols than lightning may need a v4,v5 etc. in the future?
10:32 < glozow> theStack: it's possible yeah. sadly I think loosening any of the rules breaks the properties we want. If we make it 2 parent 2 child, we're back to infinite max cluster size :P
10:33 < glozow> and multi parent 1 child doesn't fix Rule 3 pinning. txB in the example above could be 1000vB but have another 98KvB parent
10:35 < theStack> oh right. so the only limit one could in theory still tweak a bit is the max descendant size of 1kvB i guess (though 1kvB sounds like a lot already)
10:36 < michaelfolkson> Can I ask where you think we are re how close to finalizing replacement for BIP 125/RBF rules, V3, package RBF etc glozow? To what extent does package RBF depend on those other two and whether there is mempoolfullrbf=1 default in Core?
10:36 < theStack> have to leave, thanks again for hosting glozow!
10:37 < glozow> thanks theStack!
10:37 < michaelfolkson> There seems to be a lot of moving parts and it is hard to dip in and out of
10:37 < michaelfolkson> If you need to go that's fine, I can ask at the follow up
10:39 < glozow> michaelfolkson: I'd say RBF signaling rules are pretty much orthogonal to the economic RBF rules and mempool package limits.
10:40 < glozow> The goal isn't necessarily to "make package RBF" happen but to make fee bumping robust. In that sense, package RBF depends on v3 in order to be useful
10:41 < glozow> I don't know what "finalizing replacement rules" would look like. I'd imagine we are always going to try to make things better.
10:43 < michaelfolkson> Thanks. To me finalize is merging into Core. That doesn't prevent future changes but people are comfortable with it being merged
10:45 < michaelfolkson> Sounds like v3 is merged pre package RBF anyway
10:45 -!- IgboPharaoh [~IgboPhara@197.210.76.187] has quit [Ping timeout: 246 seconds]
10:46 < glozow> Oh I see what you're saying. That depends on a lot of other people - it needs review before merge. I can't control that haha
10:49 < michaelfolkson> No of course. In an ideal world maybe mempoolfullrbf=1 default, then v3 then package RBF
10:51 < michaelfolkson> The RBF signaling rules might still need to be defined for those who changed the default back to mempoolfullrbf=0 but I guess your primary job is default policy and not optimizing non default policy
10:51 -!- abubakar [~abubakars@197.210.52.41] has joined #bitcoin-core-pr-reviews
10:52 < michaelfolkson> So whatever the RBF signaling rules currently are in Core, wouldn't be changed again
11:02 -!- Tobses [~Tobses@102.89.44.131] has quit [Quit: Connection closed]
11:04 -!- abubakar [~abubakars@197.210.52.41] has quit [Read error: Connection reset by peer]
11:45 -!- pakaro [~quassel@142.157.222.64] has quit [Ping timeout: 252 seconds]
12:09 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:49 -!- Zenton [~user@user/zenton] has joined #bitcoin-core-pr-reviews
13:04 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
13:05 -!- pakaro [~quassel@142.157.222.64] has joined #bitcoin-core-pr-reviews
13:21 -!- darosior [~darosior@194.36.189.246] has quit [Quit: darosior]
13:39 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Remote host closed the connection]
13:39 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
13:44 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 265 seconds]
13:53 -!- pakaro [~quassel@142.157.222.64] has quit [Ping timeout: 255 seconds]
14:00 -!- pakaro [~quassel@142.157.222.64] has joined #bitcoin-core-pr-reviews
14:12 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
14:21 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 252 seconds]
14:26 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
14:39 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 255 seconds]
14:45 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
14:50 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 246 seconds]
14:56 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
15:00 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 248 seconds]
15:02 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
15:06 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 246 seconds]
15:13 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
15:24 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 246 seconds]
15:25 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
15:31 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 248 seconds]
15:33 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
15:37 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 246 seconds]
16:00 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
16:04 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 252 seconds]
16:06 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
16:11 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 246 seconds]
16:13 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
16:17 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 252 seconds]
16:24 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
16:26 -!- Mercury [~root@31.125.90.17] has quit [Ping timeout: 248 seconds]
16:28 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 248 seconds]
16:29 -!- __gotcha [~Thunderbi@94.105.118.205.dyn.edpnet.net] has quit [Read error: Connection reset by peer]
16:29 -!- __gotcha [~Thunderbi@94.105.118.205.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
16:30 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
16:33 -!- Mercury [~root@31.125.90.17] has joined #bitcoin-core-pr-reviews
16:34 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 252 seconds]
17:26 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
17:30 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 246 seconds]
17:45 -!- pakaro [~quassel@142.157.222.64] has quit [Ping timeout: 255 seconds]
18:10 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
18:14 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 255 seconds]
18:34 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
18:38 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 252 seconds]
18:56 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
19:01 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 260 seconds]
19:07 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
19:11 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 252 seconds]
19:13 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
19:17 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 248 seconds]
19:24 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
19:28 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 260 seconds]
19:57 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
20:01 -!- __gotcha [~Thunderbi@94.105.118.205.dyn.edpnet.net] has quit [Remote host closed the connection]
20:01 -!- __gotcha [~Thunderbi@94.105.118.205.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
20:02 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 248 seconds]
20:08 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
20:13 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 268 seconds]
20:14 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
20:17 -!- codo [~codeautis@user/codeautist] has left #bitcoin-core-pr-reviews [nil]
20:19 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 260 seconds]
20:31 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
20:35 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 248 seconds]
20:42 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
20:46 -!- grettke [~grettke@184.55.131.155] has quit [Quit: grettke]
20:46 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 268 seconds]
20:53 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
20:57 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 248 seconds]
20:59 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
21:03 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 252 seconds]
21:04 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
21:09 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 260 seconds]
21:15 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
21:20 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 248 seconds]
21:21 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
21:25 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 255 seconds]
21:27 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
21:32 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 260 seconds]
21:34 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
21:39 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 248 seconds]
21:51 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
21:56 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 252 seconds]
22:02 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
22:06 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 255 seconds]
22:13 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
22:17 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 248 seconds]
22:19 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
22:23 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 252 seconds]
22:25 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
22:29 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 248 seconds]
22:30 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
22:34 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 248 seconds]
22:41 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
22:46 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 260 seconds]
22:52 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
22:56 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 246 seconds]
22:58 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
23:03 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 260 seconds]
23:09 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
23:14 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 268 seconds]
23:20 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
23:24 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 260 seconds]
23:26 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
23:27 -!- b_101 [~robert@185.244.212.67] has quit [Ping timeout: 252 seconds]
23:28 -!- b_101 [~robert@185.244.212.67] has joined #bitcoin-core-pr-reviews
23:30 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 248 seconds]
23:37 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
23:41 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 246 seconds]
23:48 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
23:52 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has quit [Ping timeout: 264 seconds]
23:59 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:78bc:c821:9318:4539] has joined #bitcoin-core-pr-reviews
--- Log closed Thu Feb 23 00:00:53 2023