--- Log opened Wed Dec 21 00:00:52 2022
00:52 -!- kevkevin [~kevkevin@2601:243:197e:8f10:b44f:b35c:323e:2005] has joined #bitcoin-core-pr-reviews
00:57 -!- kevkevin [~kevkevin@2601:243:197e:8f10:b44f:b35c:323e:2005] has quit [Ping timeout: 260 seconds]
01:04 -!- jonatack1 [~jonatack@user/jonatack] has quit [Ping timeout: 260 seconds]
01:04 -!- jonatack1 [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
01:06 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
01:06 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
01:50 -!- MrFrancis [~MrFrancis@2001:8a0:fa4c:901:847b:35f5:3748:7a4b] has joined #bitcoin-core-pr-reviews
02:38 -!- BUSY [~BUSY@user/busy] has joined #bitcoin-core-pr-reviews
02:53 -!- kevkevin [~kevkevin@2601:243:197e:8f10:b44f:b35c:323e:2005] has joined #bitcoin-core-pr-reviews
02:58 -!- kevkevin [~kevkevin@2601:243:197e:8f10:b44f:b35c:323e:2005] has quit [Ping timeout: 260 seconds]
03:05 -!- MrFrancis [~MrFrancis@2001:8a0:fa4c:901:847b:35f5:3748:7a4b] has quit [Remote host closed the connection]
03:05 -!- MrFrancis [~MrFrancis@2001:8a0:fa4c:901:847b:35f5:3748:7a4b] has joined #bitcoin-core-pr-reviews
03:26 -!- realtbast[m] [~realtbast@2001:470:69fc:105::1:69a9] has quit [Ping timeout: 256 seconds]
03:26 -!- ishaanam[m] [~ishaanamm@2001:470:69fc:105::2:4078] has quit [Ping timeout: 246 seconds]
03:27 -!- stratospher[m] [~stratosph@2001:470:69fc:105::2:728e] has quit [Ping timeout: 246 seconds]
03:28 -!- sipa [~sipa@user/sipa] has quit [Ping timeout: 246 seconds]
03:28 -!- jomat [~jomat@2001:470:69fc:105::21] has quit [Ping timeout: 246 seconds]
03:29 -!- ShohamChakrabort [~shohamc1m@2001:470:69fc:105::2:d8cb] has quit [Ping timeout: 252 seconds]
03:29 -!- Murch1 [~murch@user/murch] has quit [Ping timeout: 260 seconds]
03:29 -!- vincenzopalazzo [~vincenzop@2001:470:69fc:105::a67] has quit [Ping timeout: 252 seconds]
03:29 -!- dunxen [~dunxen@2001:470:69fc:105::1:fec1] has quit [Ping timeout: 265 seconds]
03:29 -!- willcl_ark [~willcl-ar@user/willcl-ark/x-8282106] has quit [Ping timeout: 265 seconds]
03:30 -!- virtu [~virtu@user/virtu] has quit [Ping timeout: 260 seconds]
03:47 -!- jomat [~jomat@2001:470:69fc:105::21] has joined #bitcoin-core-pr-reviews
03:53 -!- realtbast[m] [~realtbast@2001:470:69fc:105::1:69a9] has joined #bitcoin-core-pr-reviews
03:56 -!- ishaanam[m] [~ishaanamm@2001:470:69fc:105::2:4078] has joined #bitcoin-core-pr-reviews
04:14 -!- stratospher[m] [~stratosph@2001:470:69fc:105::2:728e] has joined #bitcoin-core-pr-reviews
04:23 -!- willcl_ark [~willcl-ar@user/willcl-ark/x-8282106] has joined #bitcoin-core-pr-reviews
04:24 -!- ShohamChakrabort [~shohamc1m@2001:470:69fc:105::2:d8cb] has joined #bitcoin-core-pr-reviews
04:24 -!- Murch1 [~murch@user/murch] has joined #bitcoin-core-pr-reviews
04:27 -!- vincenzopalazzo [~vincenzop@2001:470:69fc:105::a67] has joined #bitcoin-core-pr-reviews
04:30 -!- dunxen [~dunxen@2001:470:69fc:105::1:fec1] has joined #bitcoin-core-pr-reviews
04:32 -!- sipa [~sipa@user/sipa] has joined #bitcoin-core-pr-reviews
04:37 -!- virtu [~virtu@2001:470:69fc:105::2:c105] has joined #bitcoin-core-pr-reviews
04:54 -!- kevkevin [~kevkevin@2601:243:197e:8f10:b44f:b35c:323e:2005] has joined #bitcoin-core-pr-reviews
04:59 -!- kevkevin [~kevkevin@2601:243:197e:8f10:b44f:b35c:323e:2005] has quit [Ping timeout: 260 seconds]
05:17 -!- brunoerg [~brunoerg@2804:5e70:4004:7800:198e:7d56:ee86:112e] has joined #bitcoin-core-pr-reviews
06:01 -!- virtu [~virtu@2001:470:69fc:105::2:c105] has quit [Changing host]
06:01 -!- virtu [~virtu@user/virtu] has joined #bitcoin-core-pr-reviews
06:10 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
06:10 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 255 seconds]
06:33 -!- brunoerg [~brunoerg@2804:5e70:4004:7800:198e:7d56:ee86:112e] has quit []
06:33 -!- Cory [~Cory@user/pasha] has quit [Ping timeout: 268 seconds]
06:50 -!- MacroFake [~none@72.5.34.65] has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
06:52 -!- MacroFake [~none@72.5.34.65] has joined #bitcoin-core-pr-reviews
06:52 -!- vnprc [~vnprc@136.56.39.155] has joined #bitcoin-core-pr-reviews
07:37 -!- MrFrancis [~MrFrancis@2001:8a0:fa4c:901:847b:35f5:3748:7a4b] has quit [Remote host closed the connection]
07:38 -!- MrFrancis [~MrFrancis@2001:8a0:fa4c:901:847b:35f5:3748:7a4b] has joined #bitcoin-core-pr-reviews
07:59 -!- kevkevin [~kevkevin@c-98-226-43-69.hsd1.il.comcast.net] has joined #bitcoin-core-pr-reviews
08:02 -!- MrFrancis [~MrFrancis@2001:8a0:fa4c:901:847b:35f5:3748:7a4b] has quit [Ping timeout: 252 seconds]
08:04 -!- kevkevin [~kevkevin@c-98-226-43-69.hsd1.il.comcast.net] has quit [Ping timeout: 260 seconds]
08:06 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a9de:1899:6798:4861] has joined #bitcoin-core-pr-reviews
08:25 -!- yashraj [yashraj@gateway/vpn/protonvpn/yashraj] has joined #bitcoin-core-pr-reviews
08:33 -!- yashraj_ [yashraj@gateway/vpn/protonvpn/yashraj] has joined #bitcoin-core-pr-reviews
08:37 -!- yashraj [yashraj@gateway/vpn/protonvpn/yashraj] has quit [Ping timeout: 246 seconds]
08:39 -!- hernanmarino [~hernanmar@181.99.169.107] has joined #bitcoin-core-pr-reviews
08:48 -!- yashraj_ [yashraj@gateway/vpn/protonvpn/yashraj] has quit [Ping timeout: 260 seconds]
08:54 -!- pablomartin [~pablomart@181.99.169.107] has joined #bitcoin-core-pr-reviews
08:55 -!- km64 [~km@151.38.240.6] has joined #bitcoin-core-pr-reviews
08:55 -!- rozehnal_paul [~rozehnal_@142.243.254.224] has joined #bitcoin-core-pr-reviews
09:00 -!- d33r_gee [~d33r_gee@45-27-31-99.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-pr-reviews
09:00 < d33r_gee> hello
09:01 < rozehnal_paul> hi
09:03 < glozow> hi
09:03 < glozow> #startmeeting
09:03 < stickies-v> hello!
09:03 < hernanmarino> Hi 
09:03 < pablomartin> hello
09:03 < emzy> hi
09:03 < glozow> apologies for the late start. this is PR Review Club, and we're looking at #26695 today: https://bitcoincore.reviews/26695
09:04 < schmidty_> hi
09:04 < glozow> has anyone had a chance to review the PR and/or the notes? how about a y/n
09:04 < stickies-v> y
09:04 < LarryRuane> hi
09:04 < d33r_gee> y
09:04 < rozehnal_paul> y
09:05 < pablomartin> y
09:05 < emzy> n (I'm testing right now)
09:05 < LarryRuane> y
09:05 < hernanmarino> y
09:05 < glozow> amazing! would anybody like to summarize the commits in the PR?
09:07 < stickies-v> first we decouple the construction of `BlockAssembler` from the global `gArgs`
09:07 < hernanmarino> The first two deal with BlockAssembler Options 
09:08 < hernanmarino> then there's the bypassing the TestBlockValidity 
09:08 < stickies-v> then we introduce a new option to bypass block validation checks and make PopulateMempool more realistic by using random fees
09:09 < stickies-v> and finally add a benchmark to performance test more realistically sized/shaped packages (which is the purpose of the PR)
09:09 < hernanmarino> and after what stickies-v mentioned, there is a change in the LOCKs order 
09:09 < glozow> stickies-v: hernanmarino: ⭐ ⭐ ⭐
09:09 < hernanmarino> :)
09:10 < glozow> so yes exactly, the point is to add a benchmark. Why might we care about the performance of `BlockAssembler::CreateNewBlock()`?
09:10 < hernanmarino> Because miners are interested in fast block generation
09:11 < pablomartin> + hernanmarino -> miners want to start mining asap after a block is found.
09:11 < schmidty_> One reason would be if its slow, miners wont use Bitcoin Core for block creation (or would use modified versions).
09:11 < rozehnal_paul> +1 pablomartin
09:11 -!- b_101_ [~robert@189.236.6.68] has joined #bitcoin-core-pr-reviews
09:11 < LarryRuane> hen a new block arrives, miners want to build on it and start mining as soon as possible (any delay is wasted hash power). Profit margins are super thin, so every millisecond counts!
09:11 < stickies-v> it minimizes the amount of empty blocks!
09:12 < LarryRuane> A miner could initially try to mine an empty block (we do see those sometimes), while assembling the new block in parallel, but then they lose out on the fees
09:12 < glozow> hernanmarino: pablomartin: schmidty_: LarryRuane: stickies-v: good answers!
09:12 < LarryRuane> There have been several empty blocks recently, wrote a little script to find them: https://gist.github.com/LarryRuane/35eb30cd2051e3629bbb768a19f0c320
09:12 < hernanmarino> LarryRuane: cool 
09:12 < LarryRuane> (sorry about  that, didn't know it would expand so much!)
09:12 < stickies-v> and also, if CreateNewBlock is really inefficient then large miners might fork and implement a faster version, giving them a slight benefit over smaller miners that can't afford that development cost
09:13 < LarryRuane> stickies-v: +1 (similar to @schmidty_'s answer)
09:13 < stickies-v> oh woops I missed that, yes schmidty_  was faster!
09:14 < glozow> very big brain answers 🧠
09:14 < LarryRuane> "implement a faster version" -- and not open-source it!
09:14 < glozow> Examining the implementation of `CreateNewBlock()` : https://github.com/bitcoin/bitcoin/blob/7386da7a0b08cd2df8ba88dae1fab9d36424b15c/src/node/miner.cpp#L106
09:14 < rozehnal_paul> wasn't this happening pre-segwit days?
09:14 < glozow> What does it do, and which tasks do you expect to take the most time?
09:14 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has quit [Ping timeout: 272 seconds]
09:15 < rozehnal_paul> wasn't it called antbleed or something? there was a nonce-exploit or something...was that something all miners were capable of or just higher development miners?
09:15 < rozehnal_paul> i may be way off
09:15 < rozehnal_paul> something i'll read about later
09:15 < schmidty_> My thought was that the TestBlockValidity check would be most time intensive since it looks like it calls CheckBlock which checks each transaction
09:16 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a9de:1899:6798:4861] has quit [Ping timeout: 260 seconds]
09:16 < stickies-v> rozehnal_paul: I think you're referring to ASICboost?
09:16 < rozehnal_paul> stickies-v yup!
09:16 < schmidty_> rozehnal_paul: asicboost https://bitcoinops.org/en/topics/asicboost/
09:17 < pablomartin> creates a block from template, create coinbase transaction, fill in header, validates block state...
09:17 < pablomartin> +1 shmidty_
09:17 < LarryRuane> "which tasks do you expect to take the most time" (schmidty beat me to it) i *think* TestBlockValidity calls ConnectBlock
09:18 < glozow> rozehnal_paul: you may want to google "covert asic boost," empty blocks could make it more efficient https://blog.bitmex.com/an-overview-of-the-covert-asicboost-allegation-2/
09:18 < stickies-v> I think calling `addPackageTxs()` is also a slow task because that selects the transactions to be included?
09:19 < LarryRuane> stickies-v: +1 especially because it can't do that ahead of time (don't know which tx will be present in the new latest block)
09:19 < glozow> schmidty_: stickies-v: good thinking, I don't know the exact answer but I would expect that those 2 are the biggest bits. they definitely take more time than constructing the coinbase tx.
09:20 < hernanmarino> My two guesses were TestBlockValidity and addPackageTxs also, but I was unsure
09:21 -!- km64 [~km@151.38.240.6] has quit [Ping timeout: 252 seconds]
09:21 < glozow> Just so we're all on the same page - what does `addPackageTxs()` do and why would it take time?
09:23 < rozehnal_paul> it fills the blocks with the highest fee transactions, which cannot be done ahead of time because a miner can't know for certain which txs will be left in the mempool once the previous block is mined...im not sure if addpackagetxs() also does merkleroot calculation...probably doesn't
09:23 < rozehnal_paul> definitely doesn't
09:23 < hernanmarino> it 's the transaction selection algorithm 
09:23 < stickies-v> it looks at the txs in mempool and sorts them by their total (incl ancestors) feerate - I think the results are then stored in the mempool's `mapModifiedTxs` member?
09:24 < stickies-v> I was a bit confused how the transactions are actually added into the block though, I weirdly don't see that happening in `CreateNewBlock`
09:24 < rozehnal_paul> +1 stickies-v it's the sorting of the mempool that takes time...im not sure how ancestor-finding works but that seems non-trivial as well
09:24 -!- km28 [~km@151.38.240.6] has joined #bitcoin-core-pr-reviews
09:25 < hernanmarino> and it's not a trivial problem to solve, in terms of complexity 
09:26 < glozow> rozehnal_paul: hernanmarino: stickies-v: yep that's what it does! correct, we can't really precalculate it. `mapModifiedTx` is how we "update" the fee information on mempool entries without modifying `mapTx` itself. just fyi it isn't a member of `CTxMemPool`, it's a data structure local to `BlockAssembler`
09:27 < glozow> the sorting doesn't take too much time thanks to the beauty of the multi index container. but as we include transactions, we need to update the entries that depend on them
09:28 < rozehnal_paul> Just to confirm: Since block-mining is found on a poisson distribution, miners can update their prospective blocks to include higher fee tx's without lowering their chances at finding the next block...so i imagine they DO do this...or is there some reason why a miner would create a potential block and stick to it in a 1-and-done style?
09:29 < stickies-v> ohhh thanks glozow, I totally misunderstood the scopes there. had another look and now I get it 👍
09:29 < glozow> stickies-v: see `AddToBlock()` https://github.com/bitcoin/bitcoin/blob/7386da7a0b08cd2df8ba88dae1fab9d36424b15c/src/node/miner.cpp#L222-L231
09:29 < glozow> which updates `block.vtx`
09:30 < rozehnal_paul> sorry if im getting off-base, i can do my own research later
09:30 < glozow> rozehnal_paul: correct that there's no "progress" made trying to mine a particular block template, so you can definitely update it to include new transactions
09:30 < hernanmarino> rozehnal_paul: I don't think they do that , block creation takes time, as we are discussing 
09:30 < glozow> as for whether they do it, i have no idea
09:32 < glozow> Next question. There are two BlockAssembler constructors: with and without the Options parameter. Given references to the active chainstate and mempool, `chainstate` and `mempool` respectively, what would be the difference between calling `BlockAssembler(chainstate, mempool)` and `BlockAssembler(chainstate, mempool, Options())`?
09:32 < schmidty_> Usually the mining pool creates the block right? So you have time to create the new block + time to propagate the instructions to the miners of the pool.
09:32 < LarryRuane> rozehnal_paul: "update their prospective blocks" -- I'm pretty sure most or all miners do this, about every 2 seconds (that's that I heard once) .. tradeoff between doing that too often (need to communicate to all ASICs) or not often enough (missing out on fees)
09:33 < glozow> links to the 2 ctors: https://github.com/bitcoin/bitcoin/blob/7386da7a0b08cd2df8ba88dae1fab9d36424b15c/src/node/miner.cpp#L90-L91
09:33 < glozow> https://github.com/bitcoin/bitcoin/blob/7386da7a0b08cd2df8ba88dae1fab9d36424b15c/src/node/miner.cpp#L65-L73
09:33 < hernanmarino> the first one calls the 2nd one with default Options 
09:33 < pablomartin> you could change the options (weight and feerate) rather than using the defaults
09:34 < glozow> let's be more specific. when we say "default Options" I assume we mean an `Options` instance constructed using the default, no-params constructor?
09:34 < glozow> Or do we mean `DefaultOptions()`?
09:35 < schmidty_> That was confusing for me. The DefaultOptions actually reads from the args, if provided.
09:35 < hernanmarino> I was referring to DefaultOptions() 
09:36 < hernanmarino> which is kind of a shallow answer, perhaps we cant talk about the details ... 
09:37 < glozow> schmidty_: was confusing for me as well that the default `Options` ctor *doesn't* read gArgs
09:37 < pablomartin> if you call the first constructor, it will use the default options... 
09:38 -!- p2plife [~p2plife@vps-46773dd2.vps.ovh.net] has quit [Quit: quit]
09:39 < schmidty_> In DefaultOptions(), why is "blockmaxweight" assigned in a straightforward call to GetIntArg(), while "blockmintxfee" has all the ceremony around its assignment?
09:39 < pablomartin> yeah and if you haven't passed by params... eg DEFAULT_BLOCK_MIN_TX_FEE
09:39 < schmidty_> Is it simply a matter of type? (int vs "money?(?))
09:41 < glozow> haha, i'll point out that there is some ceremony afterwards: https://github.com/bitcoin/bitcoin/blob/7386da7a0b08cd2df8ba88dae1fab9d36424b15c/src/node/miner.cpp#L72
09:41 < glozow> `nBlockMaxWeight` gets a lil sanitization later
09:42 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
09:43 < LarryRuane> schmidty_: I think you're right, it's just because of the need to ParseMoney on the blockmintxfee argument
09:44 < stickies-v> glozow: to answer your initial question, I'd say the first option constructs BlockAssembler taking startup options (e.g. -blockmaxweight) into account, or otherwise fallback to hardcoded defaults (e.g. DEFAULT_BLOCK_MAX_WEIGHT), whereas the second option will go straight to the hardcoded defaults and ignore user options
09:44 -!- b_101_ [~robert@189.236.6.68] has quit [Read error: Connection reset by peer]
09:44 -!- kevkevin [~kevkevin@c-98-226-43-69.hsd1.il.comcast.net] has joined #bitcoin-core-pr-reviews
09:45 < glozow> stickies-v: yes exactly. the point of this question was mostly so everybody pays attention to the ctors. but this scared me, because I was imagining constructing a testing setup with -blockMinFeeRate set, but then I use `Options()` and the config doesn't apply 😅
09:46 < stickies-v> yeah, it's confusing. the name `DefaultOptions()` doesn't help
09:46 < hernanmarino> mmhh , interesting 
09:47 < schmidty_> And does why is the value_or required  here? https://github.com/bitcoin/bitcoin/blob/7386da7a0b08cd2df8ba88dae1fab9d36424b15c/src/node/miner.cpp#L83 Weve just checked for presence of the arg and parsed it?
09:47 -!- b_101_ [~robert@189.236.6.68] has joined #bitcoin-core-pr-reviews
09:47 < stickies-v> schmidty_: the amount provided could be an invalid CAmount amount
09:47 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has quit [Ping timeout: 265 seconds]
09:48 < glozow> just to embarass myself a little bit here. I once wrote a benchmark for mempool `check()` and had this exact issue, I set `-check_ratio=1` and the config was ignored, so `check()` was actually not run in the bench at all https://github.com/bitcoin/bitcoin/issues/24634
09:48 -!- karliatto [~karliatto@TELEYECLA-12-224-100-176.CPEs.teleyecla.net] has joined #bitcoin-core-pr-reviews
09:48 -!- karliatto_ [~karliatto@TELEYECLA-12-224-100-176.CPEs.teleyecla.net] has joined #bitcoin-core-pr-reviews
09:48 < glozow> which is why this spooked me so much
09:48 < schmidty_> stickies-v: Shouldnt something yell at me instead of defaulting to another fee?
09:48 < glozow> Ok next commit. Given that block assembly time depends on what transactions there are in the mempool, is it a problem that `PopulateMempool()` randomly determines the transaction fees?
09:49 < LarryRuane> schmidty_: does seem like it should do that
09:49 < stickies-v> schmidty_: at first sight, I would agree with that - not sure why this is silent
09:49 < schmidty_> glozow: The randomness could affect the timing based on if certain random values are chosen that would speed or slow things
09:50 -!- p2plife [~p2plife@vps-46773dd2.vps.ovh.net] has joined #bitcoin-core-pr-reviews
09:50 < stickies-v> for benchmarks, we want to be able to compare across iterations (time, versions, ...) - so if the test is too variable, it's not a great benchmark
09:51 < stickies-v> luckily glozow had the foresight to use a deterministic randomness generator
09:51 < glozow> schmidty_: stickies-v: excellent deductions. random fee could mean variance in the benchmark results! good thing we use a deterministic random seed :P
09:51 < schmidty_> Does this random tx fee selection qualify as fuzz testing
09:51 < schmidty_> Oh ok :) Deterministic
09:51 < stickies-v> i'm wondering - is the randomness deterministic across environments, too?
09:52 < glozow> stickies-v: unsure. i'd assume so since it's a test we might want to reproduce results for.
09:52 -!- karliatto [~karliatto@TELEYECLA-12-224-100-176.CPEs.teleyecla.net] has quit [Client Quit]
09:52 < LarryRuane> Yeah I think a principle we're supposed to follow is that each iteration of a benchmark should do the same work... so any variation is due to slight variations in cpu speed or disk speed, etc.
09:53 < LarryRuane> (i just wrote a benchmark for that fee bump PR and almost made that mistake!
09:53 < glozow> Ok next question: one of the commits changes the order in which `PopulateMempool()` grabs locks. Why? https://github.com/bitcoin-core-review-club/bitcoin/commit/50218324dac18556d87688dc1a8e89bbe4d5f69e
09:55 < stickies-v> (I checked: it indeed seems to be deterministic across environments, since we just set the seed to 0: https://github.com/bitcoin/bitcoin/blob/6d40a1a7e7f09ff2c32e53237f968adf8300d028/src/random.cpp#L683-L684)
09:55 < LarryRuane> was that not just a bug fix? elsewhere, it's always cs_main then mempool.cs
09:56 < glozow> stickies-v: cool! thanks for checking!
09:56 < hernanmarino> Without digging deeper in the code, my guess is there was a deadlock . I tested this PR with enable-debug and found no problems, but perhaps before this commit, there were.
09:56 < LarryRuane> (i count 6  occurrences of the cs_main then mempool.cs)
09:56 < schmidty_> For those that missed the deterministic random like myself, I think its here which uses I believe uses a Bitcoin Core class: https://github.com/bitcoin/bitcoin/pull/26695/files#diff-6cecf3c89a982a4375a9112f3aff4d076760d84a2f3da41f5d862a6823b0b6c4R51
09:57 < glozow> LarryRuane: correct, it's a bug fix
09:57 < stickies-v> Assume two locks `L1` and `L2`, and two functions `F1` and `F2` where `F1` grabs locks `(L1, L2)` and `F2 grabs locks `(L2, L1)`. If one thread `T1` calls `F1` while another thread `T2` simultaneously calls `F2`, it’s possible that `T1` acquires `L1` and `T2` acquires `L2` but both threads cannot proceed because the second lock they need is already acquired.
09:57 < stickies-v> (dang, messed up the markdown - sorry)
09:57 < LarryRuane> stickies-v: +1
09:58 < glozow> yep exactly. ensuring that locks are acquired in a consistent order is a way to prevent deadlock
09:58 < LarryRuane> (better than messing down on the markup)
09:59 < stickies-v> (🤣)
09:59 < glozow> Last question: can you think of other mempool-related activities or scenarios worth benchmarking?
10:00 < stickies-v> reorgs!
10:00 < rozehnal_paul> a reorg is what happens right after a block is found, right?
10:01 < hernanmarino> stickies-v: yes ! I haven thought of that initially
10:01 < rozehnal_paul> ie. reorganizing a mempool now that a chunk has been taken out?
10:01 < rozehnal_paul> wait
10:01 < rozehnal_paul> nvm
10:01 < rozehnal_paul> it's a block-race condition
10:01 < glozow> stickies-v: very good idea yes. inserting things back into the mempool that have descendants in the mempool 👀 👀 👀
10:01 < rozehnal_paul> oh
10:01 < LarryRuane> stickies-v: just to play devils advocate, are reorgs rare enough that we don't really care about their performance?
10:01 < glozow> i'm going to end the meeting here but very interested to hear if people have more ideas
10:02 < glozow> #endmeeting
10:02 < LarryRuane> thanks Gloria, amazing session as always!
10:02 < emzy> Thank you glozow and all others!
10:02 < rozehnal_paul> thanks gloria, thanks everyone
10:02 < glozow> LarryRuane: you can't start mining the next block until you're done processing the chain tip update
10:02 < hernanmarino> great session indeed 
10:02 < d33r_gee> thanks glozow and every1
10:02 < glozow> ehehe thanks :D
10:02 < pablomartin> thanks Gloria and all!
10:02 < stickies-v> thanks for hosting this holiday special glozow!
10:02 < stickies-v> or should i say... glozo-ho-ho-ho
10:02 < hernanmarino> hahaha
10:03 < LarryRuane> glozow: OHHHH... so if there is a reorg, (even if rare) then it is important to generate the next block! good point!
10:03 -!- d33r_gee [~d33r_gee@45-27-31-99.lightspeed.sntcca.sbcglobal.net] has quit [Quit: Connection closed]
10:03 < hernanmarino> or hohoho
10:03 < rozehnal_paul> are we running next week or taking a holiday-break?
10:03 < schmidty_> LarryRuane: arguably reorgs could increase with the decreasing block subsidy resulting in miners reorg-ing for those tx fees?
10:03 < glozow> That's the last review club for 2022. We will resume on January 11th - stickies-v will be hosting!
10:03 < LarryRuane> stickies-v: HAHA
10:03 < schmidty_> Thanks glozow !
10:03 < LarryRuane> schmidty_: yes I believe that's called fee sniping
10:03 < hernanmarino> Ohh, I ll miss you guys 
10:04 < hernanmarino> See you next time and thanks for everything !
10:05 < glozow> if anybody wants some cool PRs to review over the holidays: https://github.com/bitcoin/bitcoin/pull/25325 https://github.com/bitcoin/bitcoin/pull/26403 https://github.com/bitcoin/bitcoin/pull/26531
10:05 < LarryRuane> schmidty_: https://bitcoin.stackexchange.com/questions/32547/do-miners-get-a-reward-for-re-confirming-blocks/32548#32548
10:06 < LarryRuane> glozow: will do, thanks!
10:06 < glozow> :)
10:06 < schmidty_> LarryRuane: Also see: https://bitcoinops.org/en/topics/fee-sniping/
10:07 < LarryRuane> schmidty_: +1
10:12 -!- rozehnal_paul [~rozehnal_@142.243.254.224] has quit [Quit: Connection closed]
10:13 < LarryRuane> schmidty_: One thing I don't see in that Optech article, that I've read about somewhere, is the idea of smaller miners including a tx to "bribe" the larger miners ... this lowers the net value of replacing the block (by the miner(s) being "bribed"). Seems very unfortunate if that would need to be done!
10:14 -!- hernanmarino [~hernanmar@181.99.169.107] has quit [Quit: Leaving]
10:14 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
10:16 -!- b_101_ [~robert@189.236.6.68] has quit [Ping timeout: 246 seconds]
10:22 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
10:30 -!- karliatto_ [~karliatto@TELEYECLA-12-224-100-176.CPEs.teleyecla.net] has quit [Quit: Leaving]
10:34 -!- MrFrancis [~MrFrancis@2001:8a0:fa4c:901:f522:f190:40b3:9561] has joined #bitcoin-core-pr-reviews
10:35 -!- pablomartin_ [~pablomart@195.140.215.182] has joined #bitcoin-core-pr-reviews
10:38 -!- pablomartin [~pablomart@181.99.169.107] has quit [Ping timeout: 246 seconds]
10:41 -!- km28 [~km@151.38.240.6] has quit [Ping timeout: 268 seconds]
10:42 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
10:44 -!- vnprc [~vnprc@136.56.39.155] has quit [Ping timeout: 246 seconds]
11:08 < LarryRuane> glozow: "haha, i'll point out that there is some ceremony afterwards: https://github.com/bitcoin/bitcoin/blob/7386da7a0b08cd2df8ba88dae1fab9d36424b15c/src/node/miner.cpp#L72" -- use of `std::clamp` could make that slightly simpler (i always have to mentally process those min-max or max-min statements) https://en.cppreference.com/w/cpp/algorithm/clamp (but that line was written 6 years ago, pre-c++17)
11:19 -!- MrFrancis [~MrFrancis@2001:8a0:fa4c:901:f522:f190:40b3:9561] has quit [Ping timeout: 256 seconds]
11:43 -!- MrFrancis [~MrFrancis@2001:8a0:fa4c:901:f522:f190:40b3:9561] has joined #bitcoin-core-pr-reviews
12:31 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:51 -!- pablomartin_ [~pablomart@195.140.215.182] has quit [Ping timeout: 268 seconds]
12:54 -!- MrFrancis [~MrFrancis@2001:8a0:fa4c:901:f522:f190:40b3:9561] has quit [Ping timeout: 246 seconds]
13:04 -!- MrFrancis [~MrFrancis@2001:8a0:fa4c:901:f522:f190:40b3:9561] has joined #bitcoin-core-pr-reviews
13:07 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has quit [Ping timeout: 272 seconds]
13:58 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
13:59 -!- MrFrancis [~MrFrancis@2001:8a0:fa4c:901:f522:f190:40b3:9561] has quit [Ping timeout: 248 seconds]
13:59 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
14:04 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
14:04 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
14:22 -!- __gotcha [~Thunderbi@85.234.220.109] has quit [Remote host closed the connection]
14:25 -!- __gotcha [~Thunderbi@85.234.220.109] has joined #bitcoin-core-pr-reviews
14:28 -!- __gotcha [~Thunderbi@85.234.220.109] has quit [Remote host closed the connection]
14:28 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
14:28 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
14:29 -!- __gotcha [~Thunderbi@85.234.220.109] has joined #bitcoin-core-pr-reviews
14:31 -!- __gotcha [~Thunderbi@85.234.220.109] has quit [Remote host closed the connection]
14:33 -!- __gotcha [~Thunderbi@85.234.220.109] has joined #bitcoin-core-pr-reviews
14:44 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Quit: Leaving]
14:45 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
15:17 -!- MrFrancis [~MrFrancis@2001:8a0:fa4c:901:f522:f190:40b3:9561] has joined #bitcoin-core-pr-reviews
15:17 -!- TheRec_ [~toto@84-75-225-47.dclient.hispeed.ch] has quit [Read error: Connection reset by peer]
15:19 -!- TheRec [~toto@84.75.225.47] has joined #bitcoin-core-pr-reviews
15:19 -!- TheRec [~toto@84.75.225.47] has quit [Changing host]
15:19 -!- TheRec [~toto@user/therec] has joined #bitcoin-core-pr-reviews
15:32 -!- __gotcha [~Thunderbi@85.234.220.109] has quit [Remote host closed the connection]
15:47 -!- pablomartin_ [~pablomart@217.146.90.152] has joined #bitcoin-core-pr-reviews
15:50 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
15:55 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has quit [Ping timeout: 246 seconds]
15:55 -!- pablomartin_ [~pablomart@217.146.90.152] has quit [Ping timeout: 260 seconds]
16:11 -!- MrFrancis [~MrFrancis@2001:8a0:fa4c:901:f522:f190:40b3:9561] has quit [Ping timeout: 246 seconds]
16:25 -!- MrFrancis [~MrFrancis@2001:8a0:fa4c:901:4cfb:3d74:a29b:b2da] has joined #bitcoin-core-pr-reviews
17:00 -!- MrFrancis [~MrFrancis@2001:8a0:fa4c:901:4cfb:3d74:a29b:b2da] has quit [Ping timeout: 248 seconds]
17:53 < harding> LarryRuane: https://bitcoinops.org/en/newsletters/2022/07/20/#paying-fees-forward
18:02 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
18:02 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
18:15 -!- __gotcha [~Thunderbi@85.234.220.109] has joined #bitcoin-core-pr-reviews
18:18 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
18:19 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
19:22 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
19:33 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has quit [Ping timeout: 268 seconds]
19:34 -!- pablomartin [~pablomart@190.193.221.10] has joined #bitcoin-core-pr-reviews
19:36 -!- pablomartin_ [~pablomart@185.169.233.161] has joined #bitcoin-core-pr-reviews
19:40 -!- pablomartin [~pablomart@190.193.221.10] has quit [Ping timeout: 268 seconds]
20:05 -!- NorrinRadd [~me@64.64.116.61] has joined #bitcoin-core-pr-reviews
20:05 -!- NorrinRadd [~me@64.64.116.61] has quit [Client Quit]
20:31 -!- pablomartin_ [~pablomart@185.169.233.161] has quit [Ping timeout: 272 seconds]
21:26 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
21:30 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has quit [Ping timeout: 264 seconds]
22:38 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
22:39 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
23:04 -!- sdfgsdfg [~sdfgsdfg@user/sdfgsdfg] has joined #bitcoin-core-pr-reviews
23:58 -!- __gotcha1 [~Thunderbi@85.234.220.109] has joined #bitcoin-core-pr-reviews
23:58 -!- __gotcha [~Thunderbi@85.234.220.109] has quit [Read error: Connection reset by peer]
23:58 -!- __gotcha1 is now known as __gotcha
--- Log closed Thu Dec 22 00:00:52 2022