--- Log opened Wed Nov 23 00:00:25 2022
00:01 -!- sandipndev [~sandipnde@shindig.notmandatory.org] has joined #bitcoin-core-pr-reviews
00:02 -!- yakshaver [~yakshaver@shindig.notmandatory.org] has joined #bitcoin-core-pr-reviews
00:02 -!- notmandatory [notmandato@2600:3c00::f03c:92ff:fe8e:dce6] has joined #bitcoin-core-pr-reviews
00:03 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has quit [Ping timeout: 260 seconds]
00:25 -!- notmandatory [notmandato@2600:3c00::f03c:92ff:fe8e:dce6] has quit [Ping timeout: 260 seconds]
00:25 -!- sandipndev [~sandipnde@shindig.notmandatory.org] has quit [Ping timeout: 260 seconds]
00:25 -!- yakshaver [~yakshaver@shindig.notmandatory.org] has quit [Ping timeout: 260 seconds]
00:28 -!- notmandatory [~notmandat@shindig.notmandatory.org] has joined #bitcoin-core-pr-reviews
00:29 -!- sandipndev [~sandipnde@shindig.notmandatory.org] has joined #bitcoin-core-pr-reviews
00:31 -!- Guest2111 [~Good@2607:fb90:8a2c:cca8:d9c0:cc71:f7c8:5f12] has quit [Ping timeout: 255 seconds]
00:32 -!- yakshaver [yakshaver@2600:3c00::f03c:92ff:fe8e:dce6] has joined #bitcoin-core-pr-reviews
00:33 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
00:38 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has quit [Ping timeout: 248 seconds]
01:03 -!- RubenSomsen [sid301948@user/rubensomsen] has quit [Read error: Software caused connection abort]
01:03 -!- RubenSomsen [sid301948@user/rubensomsen] has joined #bitcoin-core-pr-reviews
01:06 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
01:07 -!- NorrinRadd [~me@185.238.231.43] has quit [Ping timeout: 260 seconds]
01:11 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has quit [Ping timeout: 252 seconds]
01:15 -!- jnewbery [~john@user/jnewbery] has quit [Read error: Software caused connection abort]
01:19 -!- NorrinRadd [~me@105.112.154.106] has joined #bitcoin-core-pr-reviews
01:19 -!- NorrinRadd [~me@105.112.154.106] has quit [Client Quit]
01:20 -!- jnewbery [~john@user/jnewbery] has joined #bitcoin-core-pr-reviews
01:21 -!- NorrinRadd [~me@98.159.224.221] has joined #bitcoin-core-pr-reviews
01:35 -!- NorrinRadd [~me@98.159.224.221] has quit [Ping timeout: 260 seconds]
01:41 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
01:49 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has quit [Ping timeout: 248 seconds]
02:01 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
02:08 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has quit [Ping timeout: 260 seconds]
02:39 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
02:46 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has quit [Ping timeout: 260 seconds]
03:08 -!- duderonomy [~duderonom@c-24-5-92-249.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
03:17 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
03:34 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has quit [Ping timeout: 260 seconds]
03:47 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
03:56 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has quit [Ping timeout: 260 seconds]
04:27 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:106:4bbd:89e1:a78a] has joined #bitcoin-core-pr-reviews
04:32 -!- gleb0712250 [~gleb@178.150.137.228] has quit [Ping timeout: 260 seconds]
04:39 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:106:4bbd:89e1:a78a] has quit [Remote host closed the connection]
04:40 -!- brunoerg [~brunoerg@187.183.43.178] has joined #bitcoin-core-pr-reviews
04:44 -!- brunoerg [~brunoerg@187.183.43.178] has quit [Ping timeout: 260 seconds]
04:46 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
04:51 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has quit [Ping timeout: 260 seconds]
05:03 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds]
05:13 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:106:4bbd:89e1:a78a] has joined #bitcoin-core-pr-reviews
05:17 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:106:4bbd:89e1:a78a] has quit [Ping timeout: 246 seconds]
05:28 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
05:33 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has quit [Ping timeout: 268 seconds]
05:34 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:106:4bbd:89e1:a78a] has joined #bitcoin-core-pr-reviews
05:41 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:106:4bbd:89e1:a78a] has quit [Ping timeout: 260 seconds]
05:42 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:106:4bbd:89e1:a78a] has joined #bitcoin-core-pr-reviews
05:47 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:106:4bbd:89e1:a78a] has quit [Ping timeout: 256 seconds]
05:53 -!- brunoerg [~brunoerg@187.183.43.178] has joined #bitcoin-core-pr-reviews
05:58 -!- brunoerg [~brunoerg@187.183.43.178] has quit [Ping timeout: 248 seconds]
05:59 -!- brunoerg [~brunoerg@187.183.43.178] has joined #bitcoin-core-pr-reviews
06:00 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
06:04 -!- brunoerg [~brunoerg@187.183.43.178] has quit [Ping timeout: 268 seconds]
06:05 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has quit [Ping timeout: 260 seconds]
06:10 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:106:4bbd:89e1:a78a] has joined #bitcoin-core-pr-reviews
06:15 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:106:4bbd:89e1:a78a] has quit [Ping timeout: 260 seconds]
06:16 -!- NorrinRadd [~me@64.64.116.142] has joined #bitcoin-core-pr-reviews
06:21 -!- jon_atack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
06:27 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:106:4bbd:89e1:a78a] has joined #bitcoin-core-pr-reviews
06:31 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:106:4bbd:89e1:a78a] has quit [Ping timeout: 252 seconds]
06:32 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
06:37 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has quit [Ping timeout: 260 seconds]
06:38 -!- brunoerg [~brunoerg@187.183.43.178] has joined #bitcoin-core-pr-reviews
06:42 -!- brunoerg [~brunoerg@187.183.43.178] has quit [Ping timeout: 260 seconds]
06:44 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:106:4bbd:89e1:a78a] has joined #bitcoin-core-pr-reviews
06:48 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:106:4bbd:89e1:a78a] has quit [Ping timeout: 252 seconds]
06:55 -!- brunoerg [~brunoerg@187.183.43.178] has joined #bitcoin-core-pr-reviews
07:00 -!- brunoerg [~brunoerg@187.183.43.178] has quit [Ping timeout: 252 seconds]
07:07 -!- brunoerg [~brunoerg@187.183.43.178] has joined #bitcoin-core-pr-reviews
07:11 -!- brunoerg [~brunoerg@187.183.43.178] has quit [Ping timeout: 260 seconds]
07:25 -!- b_101 [~robert@172.86.186.171] has joined #bitcoin-core-pr-reviews
07:29 -!- b_101 [~robert@172.86.186.171] has quit [Ping timeout: 260 seconds]
07:40 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:106:4bbd:89e1:a78a] has joined #bitcoin-core-pr-reviews
07:44 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
07:45 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:106:4bbd:89e1:a78a] has quit [Ping timeout: 260 seconds]
07:49 -!- pablomartin [~pablomart@155.133.14.253] has joined #bitcoin-core-pr-reviews
07:49 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has quit [Ping timeout: 260 seconds]
07:51 -!- brunoerg [~brunoerg@187.183.43.178] has joined #bitcoin-core-pr-reviews
07:52 -!- BlueMoon [~BlueMoon@dgb3.dgbiblio.unam.mx] has joined #bitcoin-core-pr-reviews
07:53 -!- BlueMoon [~BlueMoon@dgb3.dgbiblio.unam.mx] has quit [Client Quit]
07:55 -!- brunoerg [~brunoerg@187.183.43.178] has quit [Ping timeout: 256 seconds]
08:03 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:106:4bbd:89e1:a78a] has joined #bitcoin-core-pr-reviews
08:05 < LarryRuane> for anyone who (like me) needs to brush up on effective value for today's review club, here's a great explanation: https://bitcoin.stackexchange.com/questions/103654/calculating-fee-based-on-fee-rate-for-bitcoin-transaction/103661#103661
08:07 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:106:4bbd:89e1:a78a] has quit [Ping timeout: 260 seconds]
08:09 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:106:4bbd:89e1:a78a] has joined #bitcoin-core-pr-reviews
08:13 < pablomartin> thanks Larry!
08:13 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:106:4bbd:89e1:a78a] has quit [Ping timeout: 260 seconds]
08:15 -!- Guest2111 [~Good@2607:fb90:8a2c:cca8:d9c0:cc71:f7c8:5f12] has joined #bitcoin-core-pr-reviews
08:16 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:106:4bbd:89e1:a78a] has joined #bitcoin-core-pr-reviews
08:24 -!- hernanmarino_ [~hernanmar@181.228.255.13] has joined #bitcoin-core-pr-reviews
08:28 < LarryRuane> Also, question 5 refers to ancestor feerate, and I found this to be very helpful: https://bitcoin.stackexchange.com/a/114217/97099
08:37 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
08:41 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has quit [Ping timeout: 260 seconds]
08:47 -!- NorrinRadd [~me@64.64.116.142] has quit [Ping timeout: 256 seconds]
08:51 -!- NorrinRadd [~me@188.215.95.113] has joined #bitcoin-core-pr-reviews
08:55 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has joined #bitcoin-core-pr-reviews
08:58 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
09:00 < glozow> hi
09:00 < glozow> #startmeeting
09:00 < glozow> Hi everyone! Welcome to Bitcoin Core PR review club!
09:00 -!- BlueMoon [~BlueMoon@dgb3.dgbiblio.unam.mx] has joined #bitcoin-core-pr-reviews
09:00 -!- yashraj [yashraj@gateway/vpn/protonvpn/yashraj] has joined #bitcoin-core-pr-reviews
09:00 < kouloumos> hi!
09:00 < hernanmarino_> Hi Gloria !
09:00 < stickies-v> hi!
09:00 < ishaanam[m]> hi
09:00 < josie[m]> hi
09:00 < hernanmarino_> and everyone :)
09:00 < emzy> hi
09:00 < BlueMoon> Hello!
09:01 < glozow> hello friends! ^_^
09:01 < pablomartin> Hello!
09:01 < lightlike> Hi
09:01 < yashraj> hi
09:01 < brunoerg> hu
09:01 < glozow> We're looking at #26152 today, notes here: https://bitcoincore.reviews/26152
09:01 < LarryRuane> hi
09:01 < brunoerg> hi*
09:01 < glozow> Have y'all had a chance to look at the notes and/or review the PR? how about a y/n?
09:01 < b_101> hi all
09:02 -!- inauman [~inauman@ip70-176-106-211.ph.ph.cox.net] has joined #bitcoin-core-pr-reviews
09:02 -!- inauman [~inauman@ip70-176-106-211.ph.ph.cox.net] has quit [Client Quit]
09:02 < stickies-v> 0.5y - a lot to cover!
09:02 < LarryRuane> notes y, review 0.5y
09:02 < hernanmarino_> Just did a light reading of the notes and first questions a couple of hours ago, I will thoroughly revier the PR later 
09:02 < emzy> n
09:02 < ishaanam[m]> y, I looked at the notes, reviewed the wallet part of the pr
09:02 < pablomartin> y for the notes, pending review
09:02 < yashraj> y, notes
09:03 -!- inauman [~inauman@ip70-176-106-211.ph.ph.cox.net] has joined #bitcoin-core-pr-reviews
09:03 < glozow> yes there's a lot to cover, but hopefully interesting enough to keep us going
09:03 < b_101> y/n
09:03 < glozow> Let's start with the first question: What issue does this PR address?
09:03 < kouloumos> notes y, review 0.1y, didn't got out of the mempool rabbit hole yet
09:03 -!- BlueMoon [~BlueMoon@dgb3.dgbiblio.unam.mx] has quit [Client Quit]
09:03 -!- BlueMoon [~BlueMoon@dgb3.dgbiblio.unam.mx] has joined #bitcoin-core-pr-reviews
09:03 -!- guest [~guest@23-47-59-81.ftth.glasoperator.nl] has joined #bitcoin-core-pr-reviews
09:04 < hernanmarino_> It fixes an overestimation in the effective value of unconfirmed UTXOs by the fees necessary to bump their ancestor transactions. 
09:04 < glozow> Right, I presume the MiniMiner implementation will be the most difficult to review (?)
09:04 -!- d33r_gee [~d33r_gee@45-27-31-99.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-pr-reviews
09:04 < LarryRuane> The Core wallet may construct a transaction with a lower fee than required by the requested feerate. This transaction won't be mined as quickly as expected (given the requested feerate).
09:04 < hernanmarino_> I quitted when I got to the MiniMiner :))
09:05 < LarryRuane> Positive feedback loop: The resulting larger number of unconfirmed UTXOs coin selection has available to it, the more likely it will choose these UTXOs, creating even more too-low fee unconfirmed transactions
09:05 < stickies-v> the wallet fee estimation doesn't take into account that it also has to pay for all unconfirmed ancestors with a lower feerate than the target
09:06 < glozow> LarryRuane: hernanmarino_:  stickies-v: yes, thank you!
09:06 < ishaanam[m]> Would it be correct to describe this PR as fixing an inconsistency between what a miner sees as our transaction's feerate vs what the wallet sees as the transaction's feerate?
09:07 < LarryRuane> That positive feedback loop idea came from https://github.com/bitcoin/bitcoin/issues/15553#issue-418076345 "This can contribute to long unconfirmed chains forming ..."
09:08 < LarryRuane> ishaanam[m]: +1 (IIUC)
09:08 < glozow> ishaanam[m]: yes, i definitely think so! CPFP has 2 sides to it: it lets us fee-bump tx ancestors, but also means we *must* pay for them. we've basically only implemented the former to do it intentionally
09:08 < stickies-v> that's interesting, I hadn't considered the feedback loop, thanks LarryRuane - makes sense!
09:09 < glozow> Before we jump in, would anybody like to give us an overview of the approach taken in this PR?
09:09 < Murch> LarryRuane: Not necessarily. We will only consider unconfirmed UTXOs in later backoff attempts on Coin Selection.
09:10 < LarryRuane> Murch: ah, thank you, that actually answers a question I was just about to ask: From notes: "Goal: when funding a transaction using unconfirmed inputs...also include the fees necessary to bump " -- Would this be a reason to avoid using unconfirmed outputs? 
09:10 < LarryRuane> So we do prioritize confirmed UTXOs in coin selection (IIUC)
09:10 < hernanmarino_> glozow : I think Murch will be able to answer that :D
09:11 < glozow> Yes, we already *only* try to use unconfirmed inputs to fund the transaction if we can't cover it using confirmed ones.
09:11 < Murch> In the first round of coin selection attempts, we only use UTXOs that have six confirmations on UTXOs received from external wallets, and one confirmation on UTXOs sent to ourselves.
09:11 < Murch> hernanmarino_: Sure, but that's not the point of it :D
09:11 < LarryRuane> glozow: Murch: also we only use _change_ outputs (change to ourselves)?
09:11 < hernanmarino_> :D
09:11 < guest> at a very high level, this PR tries to accurately determine the bump fee by organizing them into clusters and then passes them to the MiniMiner to see how the transactions would be ranked
09:12 < glozow> LarryRuane: here is the code Murch is referring to https://github.com/bitcoin/bitcoin/blob/38d06e1561013f4ca845fd5ba6ffcc64de67f9c0/src/wallet/spend.cpp#L617-L663
09:12 < stickies-v> we simulate the mining process to calculate how much we'd have to pay to bump up an outpoint's ancestor feerate to the target feerate, and use that to decrease an outpoint's effective value?
09:12 < Murch> LarryRuane: Correct, assuming that you haven't enabled “allowUnsafe”
09:13 < Murch> guest: That's not quite it. Consider what the wallet knows about its UTXOs and what information it might be missing
09:13 < LarryRuane> Murch: thanks, seems like one reason you would want to "allowUnsafe" is if you're making a refund transactions... someone sent you a payment, but now you want to give a refund, you SHOULD use that payment's output, or else the payment may get replaced and you've issued the refund!
09:13 < Murch> LarryRuane: Right, but in that case you will also explicitly pick a specific UTXO, in which case the automatic filtering of your UTXO pool does not apply
09:14 -!- sanya [~sanya@178-221-64-18.dynamic.isp.telekom.rs] has joined #bitcoin-core-pr-reviews
09:14 < LarryRuane> Murch: oh i see, that makes sense
09:14 < glozow> stickies-v: exactly. the first half of the PR implements a "bump fee" calculator. It's implemented using the same algorithm as the miner (we'll get to why that is later). The second half adds wallet functionality, deducting the bump fees from the effective values, and adding another mini miner function to calculate the total bump fees once the exact coins have been selected
09:14 < LarryRuane> "simulate the mining process" -- but without the Pow haha
09:15 -!- guest [~guest@23-47-59-81.ftth.glasoperator.nl] has quit [Quit: Connection closed]
09:15 < LarryRuane> the code in this PR is really interesting, it must have been a blast to write, @murch!
09:15 < stickies-v> LarryRuane: yeah which is why I actually proposed calling it `MiniBlockAssembler` instead of `MiniMiner` hah but now I'm phrasing it like that myself
09:15 < glozow> LarryRuane: Ah right good call - psa when we refer to the "mining algorithm" here we're talking about the block template creation algorithm. The other, more famous algorithm, is not very interesting.
09:15 < LarryRuane> stickies-v: good point!
09:16 -!- josibake [~josibake@23-47-59-81.ftth.glasoperator.nl] has joined #bitcoin-core-pr-reviews
09:16 < glozow> *not very interesting in this context
09:16 < LarryRuane> hey if not too much sidetracking, isn't the getblocktemplate RPC out of favor these days?
09:16 < LarryRuane> thought i'd read that somewhere
09:17 < glozow> I'll move on to the implementation questions. 
09:17 < glozow> In `CalculateCluster`, what does a transaction’s “cluster” consist of? (code here: https://github.com/bitcoin-core-review-club/bitcoin/commit/995107782a1a512811d54f7abf29249f351a7cbf#diff-c065d4cd2398ad0dbcef393c5dfc53f465bf44723348892395fffd2fb3bac522R1218)
09:17 < LarryRuane> given a set (vector) of transactions, return deduped vector of all connected transactions (ancestors and decendants recursively)
09:17 < hernanmarino_> It consists of all in-mempool ancestors of a set of transactions not already in the mempool (considering ancestor and descendant limits)
09:17 < LarryRuane> the list won't include the original transactions, except those that are connected to other transactions in the cluster
09:19 < LarryRuane> can i ask a general mempool question (feel free to ignore): why does so much of the code use `mapTx` iterators, rather than just some kind of direct reference?
09:19 < Murch> LarryRuane: Thanks, it is a very interesting project. A lot of the code was created by glozow, and we also had a lot of input from achow101
09:19 -!- sanya [~sanya@178-221-64-18.dynamic.isp.telekom.rs] has quit [Quit: Connection closed]
09:20 < stickies-v> LarryRuane: "except those that are connected to other transactions in the cluster" the transactions specified in `txids` can never be included in the cluster, I think
09:21 < stickies-v> because in the beginning of the function we visit them all with `for (const auto& it : cluster) { visited(it); }`
09:21 < stickies-v> oh wait. it's opposite. they're always included haha. whoops
09:21 < glozow> Er, I'm pretty sure the cluster includes those specified in `txids`? in the beginning we also initialize `cluster{GetIterVec(txids)}`
09:21 < LarryRuane> stickies-v: yes but let's say we're spending from two outputs of the same ancestor transaction? would that do it?
09:22 < Murch> Mh, maybe I'm misunderstanding you, but the cluster is the set of all transactions that are either ancestors or descendants to any other transactions in the cluster
09:22 < josibake> stickies-v: this was something i was a little fuzzy on .. they are already in the cluster and then we visit all of them so that they don't get added again?
09:22 < josibake> at least from my understanding
09:22 < josibake> but we initialize cluster from the list of txids and we don't remove anything, so the original txids would also be in the cluster
09:22 < LarryRuane> glozow: you're right, thanks, i had missed that
09:23 < stickies-v> yep josibake glozow  you're right
09:23 < glozow> Murch: you are correct. LarryRuane and hernanmarino_'s answers were part of the way there so I was waiting for more answers :P
09:23 < glozow> Yes, a cluster is every single "connected" transaction. So a "sibling" i.e. a child of your parent, who is neither your ancestor nor your descendant, would be part of your cluster.
09:24 < Murch> It's the maximal strongly connected component of the initial transactions
09:24 < LarryRuane> `CalculateCluster()` is really interesting, I had written python code months ago that does almost exactly the same thing (while trying to understand package relay)
09:25 < josibake> something that occurred to me, what happens if a list of txids is passed to calculate cluster where the txids themselves create distinct clusters?
09:25 < lightlike> did you introduce the MiniMiner because adjusting the actual miner for this use case would be too complicated? I think the algorithm is kind of implemented twice now (even with some adjustments).
09:25 < josibake> or perhaps a better question, who is deciding which txids to pass to CalculateCluster? the wallet?
09:25 < LarryRuane> josibake: I think that's perfectly okay (and normal), you just get the union
09:26 < LarryRuane> lightlike: is the actual miner conditionally compiled in? (i don't recall)
09:27 < Murch> Well, in that case, the approach of this PR is owed that the wallet doesn't know about unconfirmed transactions unless they pertain to itself. So when we spend unconfirmed UTXOs we must get more information from the mempool. It turned out that we were basically recreating block building on the wallet side then to cover all of the possible constellations of transaction relations, so we instead used the existing data structures in mempool to extract
09:27 < Murch> only the result of the graph analysis.
09:27 < Murch> josibake: The wallet asks for all of the transactions that created unconfirmed UTXOs in its pool
09:28 -!- guest_student [~guest_stu@45-27-31-99.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-pr-reviews
09:28 < hernanmarino_> Murch : that's interesting 
09:28 < glozow> lightlike: good question, there's a few reasons: We only need to operate on a cluster and not the entire mempool + don't need to apply any of the checks that `BlockAssembler` does. I also got a suggestion to do this without holding the mempool lock. We'd also need to change the block assembler to be tracking bump fees rather than building the block template - the amount of refactoring necessary was equivalent to rewriting.
09:28 < josibake> Murch: ah, got it! that makes more sense
09:29 < glozow> I can understand why the duplication of the algo could be considered an inferior approach, feedback welcome of course
09:29 < Murch> Also, we need to stop assembling the block at a specific feerate which is a different mechanism than running out of space
09:30 -!- b_101_ [~robert@189.236.40.220] has joined #bitcoin-core-pr-reviews
09:30 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has quit [Ping timeout: 260 seconds]
09:30 < glozow> Yes, though I must admit that the `BlockAssembler::blockMinFeeRate` also achieves this
09:31 < josibake> glozow: i think the reasons specified make a lot of sense. if anything, sounds like an opportunity to pull the algo out into it's own function and have both MiniMiner and and BlockAssembler call it? but haven't looked at block assembler to know if that's feasible/sane
09:31 < glozow> it's a good way to compare the algos we can fuzz them pretty easily given they have this in common
09:31 < lightlike> glozow: ah, thanks. Don't know the BlockAssembler enough to have an opinion, just wanted to understand the reasons.
09:31 < LarryRuane> josibake: I like that idea (pull the common code, if there's a significant amount of it) out into a separate function or class, then call from both places
09:32 < LarryRuane> then that function can be unit-tested too very easily
09:33 < glozow> josibake: yeah, considered that too, but a "general algorithm" is pretty much the only thing they have in common at this point. For instance, `BlockAssembler` builds a `mapModifiedTx` to "make changes" to mapTx, while `MiniMiner` operates directly on copies of the mempool entries. One builds a block template and the other builds a map of outpoint to bumpfee.
09:34 < LarryRuane> glozow: seems like you made a good engineering decision
09:34 -!- guest_student [~guest_stu@45-27-31-99.lightspeed.sntcca.sbcglobal.net] has quit [Quit: Connection closed]
09:35 < LarryRuane> (er, you and murch I guess)
09:35 < josibake> regarding CalcCluster (and sorry if this was asked already, had some issues with my irc client), but why the `GetIterVec` function?
09:35 -!- b_101 [~robert@172.86.186.171] has joined #bitcoin-core-pr-reviews
09:36 < LarryRuane> josibake: you mean why not make it inline?
09:36 < glozow> josibake: good question, brings us to the Epoch Mempool topic. A vector is much smaller than a set. we have a wider effort to switch, though it's taken years. I felt that new code should try to use epochs and vectors instead of setEntries
09:36 -!- b_101_ [~robert@189.236.40.220] has quit [Ping timeout: 248 seconds]
09:36 < glozow> oh! is it LarryRuane's question?
09:37 < LarryRuane> glozow: oh that's good to know! wasn't aware of that effort
09:38 < LarryRuane> epochs == really cool idea
09:38 < josibake> glozow: thanks, that makes more sense. i think i need to dig in more as to what a txiter is before i fully grok whats going on
09:38 < josibake> LarryRuane: not really concerned about inline or not, just curious why we were starting with a list of txids and then converting it to a vec of txiter's
09:38 < glozow> haha yes `txiter` is an alias for a very very long type
09:39 < glozow> txiter def: https://github.com/bitcoin/bitcoin/blob/38d06e1561013f4ca845fd5ba6ffcc64de67f9c0/src/txmempool.h#L406
09:39 < glozow> indexed_transaction_set: https://github.com/bitcoin/bitcoin/blob/38d06e1561013f4ca845fd5ba6ffcc64de67f9c0/src/txmempool.h#L374
09:39 < josibake> im guessing txiters are specific to epochs then? (also , read a little on the epoch pr's as background, very cool idea)
09:39 -!- yashraj [yashraj@gateway/vpn/protonvpn/yashraj] has quit []
09:40 < glozow> Ah no, txiters are just mapTx iterators. The entry's `m_epoch` can change without the txiter changing
09:40 < glozow> Continuing with the CalculateCluster commit. A transaction's cluster is both necessary and sufficient for calculating its bump fees. Let's show "sufficient" first: why do we only need the cluster and not the whole mempool to calculate what a transaction's mining "priority" will be?
09:41 < glozow> And why does the `MiniMiner` require an entire cluster? Why can’t it just use the union of each transaction’s ancestor sets?
09:41 < pablomartin> josibake: could you pls share that epoch pr?
09:42 < glozow> Epoch Mempool: https://github.com/bitcoin/bitcoin/pull/17925 and https://github.com/bitcoin/bitcoin/pull/17268
09:42 < glozow> (would people be interested in an epoch mempool review club?
09:42 < LarryRuane> first question, I don't think we care what the mining priority is, just that this newly-created tx has the requested feerate
09:42 < glozow> )
09:42 < pablomartin> glozow: as we discussed before, we need descendant and even siblings... ?
09:42 < Murch> Hint: The test-cases might provide some ideas
09:42 < lightlike> because some of the ancestors may already have been paid for by some of their other descendants - so we don't have to do it with our transaction.
09:42 < josibake> re: sufficient, a transactions mining priority is determined by it's ancestor fee, right? so we dont need to know anything about a tx except it's full ancestory
09:42 -!- __gotcha [~Thunderbi@94.105.119.88.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
09:42 < stickies-v> josibake: I'll try and explain my understanding briefly. CTxMemPoolEntry wraps a CTransaction and adds some mempool-specific stats to it. CTXMemPool stores CTxMemPoolEntry objects in a boost multi-index (`mapTx`) so we can quickly query the mempool in different ways. `txiter` is a shorthand for boost iterators that point to CTxMemPoolEntry objects in `mapTx`
09:43 < stickies-v> We use `txiter` for internal consistency (e.g. ensuring multiindex stays up to date, and that entries are still in mempool). I hope my explanation didn't contain too many inaccuraries - again, just my understanding!
09:43 < LarryRuane> lightlike: +1, Because an ancestor (A) may have a CPFP child that is already increasing A's effective feerate, so we don't need to "help" A
09:43 < Murch> pablomartin: Why though? What mistake might we make if we don't consider them?
09:43 < josibake> well, i take that back. because the cluster includes more than strictly the ancestory for a single tx
09:44 < Murch> josibake: Njet. What if your sibling has bumped the parent already to a higher package feerate than what you're aiming for?
09:44 < josibake> stickies-v: thanks, that helps!
09:44 < glozow> pablomartin: lightlike: yes exactly. to find out how much to bump, we need to know whether something is already bumped.
09:44 < Murch> There is also another issue that hasn't been mentioned yet
09:44 < Murch> Or only indirectly, I guess
09:45 < glozow> and josibake: yes that's the general idea. we don't need anything that cannot impact these transactions during block assembly
09:45 < LarryRuane> Murch: a little more context please? issue with not consideringly only ancestors?
09:46 < Murch> You can't just sum up all ancestors and take their summed up fee and weight, because some of the ancestors might have a higher effective feerate than what you're aiming for by themselves and will not actually be part of your package
09:46  * lightlike we just have to make sure that we don't pay for something that has low-fee descendants (that does the opposite of bumping them). But I guess the BlockAssembly algorithm takes care of that?
09:46 < Murch> Children pay for parents, but parents cannot pay for children
09:47 < LarryRuane> that's mean ... oh i forgot to mention at the start of the meeting, in the notes, the effective_value expression should use max, not min (correct?)
09:47 < pablomartin> Murch: true, I agree (only children pay for parents -> direction)
09:47 < Murch> So, if your grandparent tx has a higher feerate, you may only need to bump the parent, but if you had summed up the two, you would underestimate the bump fee
09:47 < ishaanam[m]> LarryRuane: yes
09:47 < glozow> LarryRuane: yes, its should be max. ishaanam also pointed this out to me. I'll fix it when I add the logs later today. Thanks you both for catching!
09:48 < pablomartin> Murch: so you need to check if sibling were already bumping common parents...
09:48 < lightlike> sure - but the low-fee children would be included in the Cluster at first, and then discarded later, right?
09:48 < Murch> however, if your parent tx has a higher feerate than what you're aiming for, it might still have a lower ancestor feerate, because it's bumping a grandparent.—In that case, you do have to bump both the parent and grandparent
09:49 < LarryRuane> Murch: that's mind-bending! cool tho
09:50 < LarryRuane> and just to be clear.. when we say "bump" we just mean reduce the EV of the output that we're considering spending
09:50 < Murch> So, you can't just skip over txs that have a higher individual feerate, but you can also not just take their summed up fees and weights. You actually have to traverse the cluster in order to find out which ancestors, descendants and cousins are relevant
09:50 < glozow> Yes, so there really isn't a quick and easy way of calculating the bump fees just by looking at aggregate feerates etc. running the mining algorithm on the cluster is the easiest way imo, even if it seems like a lot
09:51 < Murch> LarryRuane: Yes, reduce the effective value of the UTXO in order to pay a higher fee when it's used that will go towards elevating ancestors to the target feerate
09:52 < Murch> lightlike: Yeah, we first collect siblings, niblings, cousins, etc., but if they do not bump some of the shared ancestry, we can disregard them for the bumpfee calculation
09:52 < Murch> pablomartin: Yep!
09:53 < glozow> To hammer this home:  If two mempool transactions X and Y have ancestor feerates gX and gY where gX > gY, which of the following are possible?
09:53 < glozow>     (a) X is selected sooner than Y
09:53 < glozow>     (b) X is selected later than Y
09:53 < LarryRuane> sorry I didn't really look yet, but are there tests, I could imagine setting up these weird graphs and then making sure the algorithm does the right thing (right as determined manually)
09:53 < LarryRuane> glozow: Both are possible! (a) is obvious, but (b) can happen if some of Y's ancestors have (other) decendants that are high feerate
09:54 < LarryRuane> this would, in effect, "remove" those low-feerate ancestors from Y's ancestor set, which may then increase Y's ancestor feerate
09:54 < Murch> LarryRuane: I've created a bunch of graphs that will exhibit these sort of issues for the functional tests. I'm not 100% sure that they're exhaustive yet, though
09:54 < glozow> LarryRuane: bingo! both are possible!
09:54 < glozow> To all: We're running out of time and have just looked at the concept + approach today, and didn't really get into wallet. Would you all be interested in continuing with this PR next week? The questions will be the same, but we'll have more time to dive into implementation and tests :)
09:55 < pablomartin> glozow: sure
09:55 < LarryRuane> glozow: +1 yes!
09:55 < josibake> definitely interested in continuing next week
09:55 < Murch> ishaanam: I wrote the test with unconfirmed and confirmed UTXOs you proposed, but I've not finished my update  of the PR yet
09:55 < josibake> glozow: also, yes to having a epoch review club in the future
09:55 < ishaanam[m]> glozow: yes
09:55 < LarryRuane> josibake: +1
09:55 < stickies-v> (to everyone voting yes: thanks for kicking me out of  (hosting) job. names are noted)
09:55 < d33r_gee> glozow +1
09:55 < hernanmarino_> glozow : yes please
09:56 < stickies-v> but yes, I would also like to continue this PR next week - very interesting!
09:56 < Murch> Cool
09:56 < glozow> Great :) let's do one more question and then to be continued - hahaha sorry stickies-v
09:56 < LarryRuane> josebake: i'm not sure epoch is itself enough for an entire review club...
09:56 < josibake> stickies-v:  >:D
09:56 < Murch> Also looking forward to the further questions and comments your review will unearth
09:56 < glozow> Can `CalculateBumpFees()` overestimate, underestimate, both, or neither? By how much?
09:57 < ishaanam[m]> Murch: great!
09:58 -!- b_101 [~robert@172.86.186.171] has quit [Ping timeout: 260 seconds]
09:58 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
09:58 < josibake> my guess is overestimate
09:59 < glozow> josibake: yes!
09:59 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
09:59 < glozow> Next week, we'll get to why that is, and how the PR resolves it :)
09:59 < ishaanam[m]> CalculateBumpFees can overestimate since it doesn't take into account two sibling transactions both being selected (since the calculation is done independently)
09:59 < Murch> Methinks that for an individual UTXO the result of CalculateBumpFees() should be accurate regarding the available information. But it can overestimate, if two UTXOs have overlapping ancestries and are spent together. It can underestimate if there is a later sibling transaction that bumps an ancestor harder than our own, but that's not really a mistake.
09:59 < Murch> err.
10:00 < Murch> The latter is also an overestimate
10:00 < pablomartin> glozow: yes pls
10:00 < josibake> Murch: in the case of a later sibling, i think that would also be an overestimate?
10:00 < glozow> ishaanam[m]: yep exactly, if any UTXOs have overlapping ancestors, they'll both count
10:00 < hernanmarino_> I have to go, thank you all for everything, see you next week !
10:00 < Murch> Anyway, what I wanted to get at was that more transactions published after ours might take precedence and outdate our prior estimate 
10:00 < glozow> (exercise for the attendees: can it *ever* underestimate?)
10:00 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
10:00 < josibake> glozow: thanks for hosting! great questions on the PR, too
10:01 < glozow> Thanks everyone for a wonderful session! See you next week!
10:01 < glozow> #endmeeting
10:01 < d33r_gee> thank you!
10:01 < pablomartin> thanks glozow, Murch and all!
10:01 < LarryRuane> thank you @glozow and @Murch!! this has been amazing! one of the best in my experience!
10:01 < emzy> Thank you
10:01 < lightlike> thanks glozow,  Murch!
10:01 < stickies-v> thank you glozow and Murch!
10:01 < glozow> LarryRuane: me too! one of my favorite review club meetings so far ^_^
10:02 < ishaanam[m]> glozow: Murch: thanks!
10:02 < LarryRuane> in large part because of your excellent notes and questions!!
10:02 < b_101> glozow: thanks for hosting and all, very good session!
10:02 < Murch> Thanks for attending and your interest in this PR
10:02 < josibake> its a really cool topic! much more complicated than first glance implies
10:02 < Murch> Thanks glozow for the prep!
10:02 -!- inauman [~inauman@ip70-176-106-211.ph.ph.cox.net] has quit [Quit: Connection closed]
10:03 -!- josibake [~josibake@23-47-59-81.ftth.glasoperator.nl] has quit [Quit: Connection closed]
10:03 < Murch> glozow: Does your exercise question permit additional transactions to be submitted later or not? ;D
10:03 < LarryRuane> I got lucky today, because I had only worked through the first 5 questions, and that's all the time we ended up having!
10:04 < Murch> LarryRuane: Good job on your JIT prep :D
10:04 < LarryRuane> Murch: wouldn't everything get recalculated if additional transactions are submitted later?
10:04 < glozow> Murch: haha no, this tx only
10:05 < LarryRuane> glozow: but couldn't one of our ancestors get a new child?
10:05 < Murch> I was thinking of a specific use of RBF
10:06 < Murch> LarryRuane: A new child cannot increase the fees we need to pay
10:06 < Murch> But…
10:06 < LarryRuane> ... may decrease?
10:07 < Murch> If one of our siblings or cousins that was previously bumping an ancestor got RBFed and then no longer spent that ancestor, we might have underestimated
10:07 < LarryRuane> oh wow .. yeah
10:09 < LarryRuane> One thing I'm generally confused about.. so much of the code using txiter variables, and I don't understand their validity lifetimes ... If a tx is added to the mempool, that doesn't invalidate existing iterators, right? but removing does? How do we ensure that we're not using invalid iterators?
10:09 -!- hernanmarino_ [~hernanmar@181.228.255.13] has quit [Ping timeout: 260 seconds]
10:10 < LarryRuane> or maybe the lifetime is only as long as the mempool cs is held? release that cs invalidates them all?
10:11 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
10:15 -!- BlueMoon [~BlueMoon@dgb3.dgbiblio.unam.mx] has quit [Quit: Connection closed]
10:37 -!- hernanmarino_ [~hernanmar@181.228.255.13] has joined #bitcoin-core-pr-reviews
10:37 -!- jon_atack [~jonatack@user/jonatack] has quit [Quit: WeeChat 3.7.1]
10:41 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
10:41 -!- pablomartin_ [~pablomart@185.183.181.11] has joined #bitcoin-core-pr-reviews
10:45 -!- b_101_ [~robert@189.236.40.220] has joined #bitcoin-core-pr-reviews
10:45 -!- pablomartin [~pablomart@155.133.14.253] has quit [Ping timeout: 260 seconds]
10:46 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has quit [Ping timeout: 256 seconds]
10:52 -!- hernanmarino_ [~hernanmar@181.228.255.13] has quit [Read error: Connection reset by peer]
10:59 -!- __gotcha [~Thunderbi@94.105.119.88.dyn.edpnet.net] has quit [Ping timeout: 260 seconds]
11:00 -!- __gotcha [~Thunderbi@94.105.119.88.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
11:01 -!- NorrinRadd [~me@188.215.95.113] has quit [Ping timeout: 268 seconds]
11:15 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
11:16 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
11:17 -!- b_101_ [~robert@189.236.40.220] has quit [Ping timeout: 260 seconds]
11:18 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
11:18 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [Client Quit]
11:20 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
11:42 -!- d33r_gee [~d33r_gee@45-27-31-99.lightspeed.sntcca.sbcglobal.net] has quit [Quit: Connection closed]
11:55 -!- jesseposner [~jesse@user/jesseposner] has quit [Ping timeout: 248 seconds]
12:10 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
12:25 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:36 -!- Guest2111 [~Good@2607:fb90:8a2c:cca8:d9c0:cc71:f7c8:5f12] has quit [Ping timeout: 260 seconds]
12:40 -!- duderonomy [~duderonom@c-24-5-92-249.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews
12:42 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has quit [Ping timeout: 260 seconds]
12:55 -!- __gotcha [~Thunderbi@94.105.119.88.dyn.edpnet.net] has quit [Remote host closed the connection]
12:56 -!- __gotcha [~Thunderbi@94.105.119.88.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
13:00 -!- jesseposner [~jesse@user/jesseposner] has joined #bitcoin-core-pr-reviews
13:04 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [Ping timeout: 260 seconds]
13:19 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has quit [Quit: Connection closed]
13:40 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
13:45 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has quit [Ping timeout: 268 seconds]
13:48 -!- jb55 [~jb55@user/jb55] has quit [Ping timeout: 248 seconds]
13:57 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:106:4bbd:89e1:a78a] has quit []
14:08 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
14:10 -!- duderonomy [~duderonom@c-24-5-92-249.hsd1.ca.comcast.net] has quit [Ping timeout: 260 seconds]
14:10 -!- pablomartin_ [~pablomart@185.183.181.11] has quit [Read error: Connection reset by peer]
14:11 -!- pablomartin [~pablomart@185.183.181.11] has joined #bitcoin-core-pr-reviews
14:13 -!- duderonomy [~duderonom@c-24-5-92-249.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews
14:26 -!- duderonomy [~duderonom@c-24-5-92-249.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
14:27 -!- duderonomy [~duderonom@c-24-5-92-249.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews
14:29 -!- duderonomy [~duderonom@c-24-5-92-249.hsd1.ca.comcast.net] has quit [Client Quit]
15:09 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has quit [Ping timeout: 260 seconds]
15:35 -!- pablomartin [~pablomart@185.183.181.11] has quit [Quit: Leaving]
15:49 -!- NorrinRadd [~me@188.215.95.221] has joined #bitcoin-core-pr-reviews
15:52 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
15:58 -!- NorrinRadd [~me@188.215.95.221] has quit [Ping timeout: 260 seconds]
16:01 -!- NorrinRadd [~me@188.215.95.221] has joined #bitcoin-core-pr-reviews
16:03 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has quit [Ping timeout: 260 seconds]
16:09 -!- jon_atack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
16:11 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 260 seconds]
16:16 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
16:21 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has quit [Ping timeout: 260 seconds]
16:48 -!- NorrinRadd [~me@188.215.95.221] has quit [Ping timeout: 260 seconds]
16:50 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
17:25 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has quit [Ping timeout: 260 seconds]
17:39 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
17:43 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has quit [Ping timeout: 268 seconds]
17:56 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
18:00 -!- __gotcha [~Thunderbi@94.105.119.88.dyn.edpnet.net] has quit [Remote host closed the connection]
18:00 -!- __gotcha [~Thunderbi@94.105.119.88.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
18:01 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has quit [Ping timeout: 260 seconds]
18:03 -!- qubenix [~qubenix@user/qubenix] has joined #bitcoin-core-pr-reviews
18:05 -!- qubenix [~qubenix@user/qubenix] has quit [Client Quit]
18:06 -!- qubenix [~qubenix@user/qubenix] has joined #bitcoin-core-pr-reviews
18:28 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
18:33 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has quit [Ping timeout: 268 seconds]
19:04 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
19:09 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has quit [Ping timeout: 268 seconds]
19:56 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
20:00 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has quit [Ping timeout: 248 seconds]
20:09 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
20:15 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has quit [Ping timeout: 256 seconds]
20:30 -!- b_101 [~robert@172.86.186.171.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
20:45 -!- Guest2111 [~Good@2607:fb90:8a2c:cca8:d9c0:cc71:f7c8:5f12] has joined #bitcoin-core-pr-reviews
20:56 -!- __gotcha [~Thunderbi@94.105.119.88.dyn.edpnet.net] has quit [Read error: Connection reset by peer]
20:56 -!- __gotcha1 [~Thunderbi@94.105.119.88.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
20:59 -!- __gotcha1 is now known as __gotcha
21:55 -!- Guest2111 [~Good@2607:fb90:8a2c:cca8:d9c0:cc71:f7c8:5f12] has quit [Ping timeout: 260 seconds]
23:10 -!- duderonomy [~duderonom@c-24-5-92-249.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews
23:44 -!- Netsplit *.net <-> *.split quits: sloorush
23:46 -!- Netsplit over, joins: sloorush
23:49 -!- __gotcha [~Thunderbi@94.105.119.88.dyn.edpnet.net] has quit [Ping timeout: 268 seconds]
--- Log closed Thu Nov 24 00:00:26 2022