--- Log opened Wed Jul 21 00:00:12 2021
02:13 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-pr-reviews
02:25 -!- promag [~promag@188.250.84.129] has quit [Remote host closed the connection]
02:26 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-pr-reviews
04:43 -!- promag [~promag@188.250.84.129] has quit [Remote host closed the connection]
04:43 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-pr-reviews
07:02 -!- vicarious24 [~vicarious@c-98-214-196-137.hsd1.il.comcast.net] has joined #bitcoin-core-pr-reviews
07:41 -!- Murch[m] [~murchmatr@2001:470:69fc:105::2aa8] has joined #bitcoin-core-pr-reviews
08:32 -!- user__ [~davterra@178.128.106.205] has joined #bitcoin-core-pr-reviews
08:34 -!- davterra [~davterra@143.244.186.214] has quit [Ping timeout: 268 seconds]
09:08 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
09:28 -!- user__ [~davterra@178.128.106.205] has quit [Ping timeout: 258 seconds]
09:31 -!- gite [~gite@103.81.243.2] has joined #bitcoin-core-pr-reviews
09:33 -!- stickies-v [~stickies-@2a05:4f44:21b:ed00:b593:9ce5:4c55:7be0] has joined #bitcoin-core-pr-reviews
09:42 -!- user__ [~davterra@143.198.56.186] has joined #bitcoin-core-pr-reviews
09:48 -!- user__ [~davterra@143.198.56.186] has quit [Ping timeout: 265 seconds]
09:49 -!- gite [~gite@103.81.243.2] has quit [Quit: Connection closed]
09:50 -!- raj_ [~raj_@103.77.139.179] has joined #bitcoin-core-pr-reviews
09:51 -!- ghost43_ is now known as ghost43
09:53 -!- observer66 [~observer@cpe-23-242-148-67.socal.res.rr.com] has joined #bitcoin-core-pr-reviews
09:54 -!- dariusp [~dariusp@c-73-252-226-175.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews
09:56 -!- theStack [~honeybadg@vps1648322.vs.webtropia-customer.com] has joined #bitcoin-core-pr-reviews
09:57 < willcl_ark> michaelfolkson: thanks, I wanted to watch that but had to miss the session!
09:57 -!- ajonas [sid385278@id-385278.brockwell.irccloud.com] has joined #bitcoin-core-pr-reviews
09:58 -!- unplanted [~switch@185.212.170.140] has joined #bitcoin-core-pr-reviews
09:58 -!- lopp [~lopp@104.129.24.124] has joined #bitcoin-core-pr-reviews
09:59 -!- Sachin [~Sachin@136-24-115-54.cab.webpass.net] has joined #bitcoin-core-pr-reviews
10:00 < jnewbery> #startmeeting
10:00 < willcl_ark> hi
10:00 < stickies-v> hi!
10:00 < larryruane> hi
10:00 < theStack> hi
10:00 < jnewbery> Hi folks! Welcome to Bitcoin Core PR Review Club
10:00 < raj_> hi
10:00 < emzy> hi
10:00 < dariusp> hi!
10:00 < glozow> hi!
10:01 < jnewbery> The review club is a place for people to come and learn about the process of contributing to Bitcoin Core. Everyone is welcome to come and ask questions
10:01 < jnewbery> Feel free to say hi to let people know you're here
10:01 < jnewbery> Anyone here for the first time?
10:01 < lopp> First time participant, reporting for duty!
10:01 < Sachin> hi
10:01 -!- Azorcode [~Azorcode@201.242.208.94] has joined #bitcoin-core-pr-reviews
10:01 -!- pglazman [~pglazman@136-24-115-54.cab.webpass.net] has joined #bitcoin-core-pr-reviews
10:01 < jnewbery> lopp: welcome!!
10:02 < Azorcode> Hello everyone
10:02 < jnewbery> Notes and questions are here: https://bitcoincore.reviews/22383. I'll use the questions as prompts to guide the conversation, but feel free to jump in at any point if you have any questions or points you want to add
10:02 < sanket1729_> Hi
10:03 < jnewbery> Who had a chance to review the PR this week? (y/n)
10:03 < raj_> y
10:03 < unplanted> hi
10:03 < larryruane> y
10:03 < stickies-v> y
10:03 < neha> hi
10:03 < glozow> 0.5y
10:03 < theStack> y
10:03 < willcl_ark> y
10:03 < pglazman> y
10:03 < unplanted> n
10:03 < dariusp> n
10:03 < emzy> 0,5y
10:04 < jnewbery> Did you review the PR? Concept ACK, approach ACK, tested ACK, or NACK? And for those that reviewed the PR, can you briefly summarise what it's doing?
10:04 < Murch[m]> N
10:04 < Murch[m]> Well sort of
10:04 -!- kiran [~kiran@218.185.248.66] has joined #bitcoin-core-pr-reviews
10:05 < raj_> Using txindex if enabled irrespective of weather blockhash is provided or not. But return failure provided blockhash dont match with found blockhash.
10:05 -!- pglazman [~pglazman@136-24-115-54.cab.webpass.net] has quit [Client Quit]
10:05 < larryruane> tested ACK -- summary: if the transaction index is enabled (`-txindex`), then use that to loop up a transaction, rather than reading a block from disk
10:06 < theStack> code-review ACK
10:06 < jnewbery> raj_ larryruane: correct!
10:06 < stickies-v> Approach ACK - it resolves unexpected performance loss where (when having a txindex) GetTransaction becomes slower when providing the optional block_index parameter
10:06 -!- pglazman [~pglazman@136-24-115-54.cab.webpass.net] has joined #bitcoin-core-pr-reviews
10:06 < jnewbery> stickies-v: correct
10:06 < jnewbery> 2. Without looking at the code, why do you think that performance is worse when providing a block hash (assuming txindex is enabled)?
10:06 -!- murch [~murchin@user/murch] has joined #bitcoin-core-pr-reviews
10:07 < stickies-v> because the entire block instead of just the transaction gets deserialized
10:07 < raj_> De-serialization of the entire block takes more time than finding via txindex?  
10:07 < jnewbery> (and if you've reviewed the PR, you can ignore the part about not looking at the code)
10:07 < theStack> the txindex is not used in this case, and the slow path of deserializing the whole block from disk is taken
10:08 -!- merkle_noob[m] [~merklenoo@2001:470:69fc:105::bad0] has joined #bitcoin-core-pr-reviews
10:08 < jnewbery> stickies-v raj_: I think you're right. Reading the block from disk and deserializing is probably what's causing the delay.
10:08 < jnewbery> theStack: right
10:08 < larryruane> also, is it likely that the parts of the txindex we need are already in memory (so no disk read needed)? (But the deserialization is the most important thing)
10:08 < unplanted> jnewbery would it be appropriate/relevant to visualize the slowdown with a fireplot?
10:08 < jnewbery> Did anyone do any profiling to see how long deserialization of a block takes?
10:09 < stickies-v> didn't run any code, not on my dev machine...
10:10 < sipa> jnewbery: that's also what i assume
10:10 < jnewbery> larryruane: the txindex points to the location of the transaction on the disk, so a disk read is always required for that part. You may be right about the txindex itself being in memory. I'm not familiar with the txindex code and how often it gets flushed or if there's any caching
10:11 < murch> I mean, don't you also need to linearly search through the whole transaction set of the block if you're looking it up from the block?
10:11 < jnewbery> next q: If we’re looking up the transaction by block hash, then what are the steps required? How do we know where to find that block on disk? How much data is deserialized?
10:12 < larryruane> jnewbery: the block index (also leveldb, like txindex) stores the blk file number and byte offset of the start of the block on disk
10:12 < larryruane> it's indexed by block hash
10:13 < jnewbery> larryruane: I would assume that it's indexed by txid if it's a transaction index
10:13 < larryruane> murch: great point, may have to scan over a thousand transactions (on average) to find it
10:13 < sipa> the txindex stores the file number, begin offset of that block, and begin offset of that tx
10:13 < sipa> iirc
10:13 < larryruane> jnewbery: no the block index
10:13 < unplanted> when I said fireplot I meant flame graphs ':]
10:14 -!- stickies-v [~stickies-@2a05:4f44:21b:ed00:b593:9ce5:4c55:7be0] has quit [Ping timeout: 245 seconds]
10:14 < jnewbery> larryruane: the txindex is an index from txid -> (file, block pos, tx offset) , no?
10:15 < jnewbery> so you can look things up by txid
10:15 < theStack> murch: i guess once the block is deserialied into memory searching a tx doesn't take that long (in comparison), considering the limited number of txs in a block
10:15 < larryruane> jnewbery: yes, I thought you were asking about having the block hash but not the txindex
10:16 -!- stickies-v [~stickies-@2a05:4f44:21b:ed00:b593:9ce5:4c55:7be0] has joined #bitcoin-core-pr-reviews
10:16 < jnewbery> ooooh sorry I misread your earlier message!
10:16 -!- belcher_ is now known as belcher
10:17 < jnewbery> yes, you're right about the block index being an index on the block hash
10:17 < larryruane> sipa: so the txindex allows you to seek directly to the tx on disk, do a small read (relative to an entire block), deserialize only that one tx .. so that's why it's much faster
10:17 < sipa> right
10:17 < jnewbery> back to the question: what are the steps currently when looking up a transaction with a provided block hash?
10:18 < jnewbery> it's kind of been answered already
10:18 < jnewbery> we deserialize the entire block, and then scan through each transaction looking for a match: https://github.com/bitcoin/bitcoin/blob/a3791da0e80ab35e862989373f033e5be4dff26b/src/validation.cpp#L1163-L1170
10:19 < murch> Well, you find the block, deserialize it and then look through the transactions until you find the one in question
10:19 < jnewbery> murch: exactly right
10:19 < glozow> get block from disk, deserialize it, deserialize all the transactions and compare their txids with the one requested until we find it
10:19 < larryruane> glozow: I think deserializing the block implies deserializing all the transaction it contains (right?)
10:19 < raj_> Find the block, find the transaction, see if txid matches, get back the blockhash and tx. 
10:19 < glozow> larryruane: ya sorree
10:19 < jnewbery> theoretically you could stop deserializing part way through if you found a tx with the right txid, but we don't have a way of doing that
10:20 < unplanted> jnewbery we don't have a method to do that, or we haven't implemented one?
10:20 < jnewbery> but yes, it involves deserializing 1-2MB on average from disk into CBlock and CTransaction objects
10:21 < jnewbery> unplanted: there's no method to do that. I'm not suggesting that it'd be a good idea, but it's at least theoretically possible
10:22 < jnewbery> but if searching for transactions in serialized blocks was a performance critical operation, then stopping as soon as you deserialized the right transaction would be a reasonable operation
10:22 < jnewbery> *reasonable optimization
10:22 < jnewbery> ok, next question: If we’re looking up the transaction using the txindex, how much data is deserialized?
10:23 < murch> Since we know the offset of the tx data in the block, only the transaction itself
10:23 < raj_> The block header and the transaction only? 
10:23 < jnewbery> murch: right
10:23 < larryruane> murch: i agree
10:23 < jnewbery> raj_: I don't think we even need to deserialize the block header, do we?
10:24 < murch> I think larryruane said earlier that the txindex stored the offset of the block in the block file and the offset of the tx respective to that, so all credit to him :D
10:24 < larryruane> jnewbery: I think that's correct -- with txindex, you don't even know which block the tx belongs to
10:24 < unplanted> jnewbery txindex is providing the offsets, so no I think
10:24 < larryruane> murch: no i was referring to the block index
10:24 < murch> Oh, well then I just guessed well
10:24 < larryruane> murch: oh it does?? i was accidentally right! haha
10:25 < murch> So would the txindex have the offset per blockfile?
10:25 < sipa> yes, it has the offset within the blk*.dat file where the tx starts
10:25 < raj_> jnewbery, yes but it seems its still reading the header and then seeking to the tx offset (or atleast thats how I am reading the code, so might be wrong)
10:25 < sipa> (and also the offset within that file where the block it contains starts)
10:26 < murch> So, it knows where the corresponding block starts, but does not explicitly store which block that is?
10:26 < jnewbery> raj_: I take it back. You're right!
10:26 < jnewbery> https://github.com/bitcoin/bitcoin/blob/a3791da0e80ab35e862989373f033e5be4dff26b/src/index/txindex.cpp#L242-L251
10:27 < Sachin> ```if (g_txindex->FindTx(hash, block_hash, tx)) {
10:27 < Sachin>             if (!block_index || block_index->GetBlockHash() == block_hash) {
10:27 < Sachin>                 hashBlock = block_hash;
10:27 < Sachin>                 return tx;
10:27 < Sachin>             }
10:27 < Sachin>         }
10:27 < Sachin> does this code not return the blockhash of the tx? 
10:27 < Sachin> or bind it to a pointer that is available? 
10:27 < theStack> ah, TxIndex::FindTx() uses the header to find out and set the block hash
10:27 < jnewbery> Sachin: please don't paste code into the chat. You can paste a link to the code on github
10:28 < Sachin> my bad, thank you
10:28 < jnewbery> no problem! It just gets a bit noisy if we paste code in here
10:28 < raj_> Sachin, I  think the hash is returned in that `hashBlock` variable. 
10:29 < larryruane> TIL after it deserializes the header (`file >> header`), the file offset is immediately _after_ the header, so that's a relative seek to the transaction offset .. cool
10:29 < jnewbery> Right, FindTx() returns the block hash, which it gets from deserializing the header and hashing it
10:29 < raj_> jnewbery, is the reason that it still reads the block header is that tx offset starts counting after the header?
10:29 < Sachin> yeah, that's what I thought but I wanted to confirm. So the user can still determine the blockhash after this call
10:30 < glozow> right: https://github.com/bitcoin/bitcoin/blob/54e31742d208eb98ce706aaa6bbd4b023f42c3a5/src/index/txindex.cpp#L255
10:30 < sipa> murch: correct, i think (re: "does not explicitly store which block that is")
10:30 < murch> sipa: thanks
10:31 < jnewbery> raj_: the reason is that it needs to calculate the block hash from the block header. If it didn't need to do that, the index could just store the offset of the tx from the beginning of the file
10:31 < jnewbery> alright, next question: The first version of this PR included a behaviour change: when an incorrect block_index is provided to GetTransaction, but g_txindex->FindTx(hash, hashBlock, tx) finds and returns the tx. After this PR we would return the tx although it isn’t in the block the user asked for.
10:31 < jnewbery> This behaviour change was removed in a subsequent push to the PR. Do you think the behaviour change is an improvement? Should it be included in this PR?
10:33 < raj_> It doesn't seem to be an improvement to me. If the user provided wrong blockhash its better to notify that.  
10:33 < murch> No, I think it shouldn't. When you explicitly filter something for a specific block it would be odd to get data back that doesn't fit the search parameters
10:33 < theStack> generally i'd argue it's more clean to separate performance optimizations and behavioural changes into different PRs, to not mix things up and lower review burden
10:33 < murch> If the user doesn't know which block to expect it in, they shouldn't/wouldn't restrict the search to that block.
10:34 < larryruane> jnewbery: I know you've got more questions, but if I may inject a question here: what is txindex used for; why do people sometimes enable it? One answer I can think of is: block explorers .. but maybe there are other reasons?
10:34 < murch> It could perhaps give a different error message to be more helpful to the user though.
10:34 < murch> "Tx found in a different castle"
10:35 < jnewbery> larryruane: great question! Anyone have any thoughts about that? Why do people enable txindex?
10:35 < larryruane> murch: ".. it would be odd to .." I agree completely
10:35 < willcl_ark> It's easier to look up transactions which aren't related to your wallet, on your local node?
10:35 < larryruane> obviously not for validity checking, or txindex wouldn't be optional!
10:35 < raj_> To quickly find lots of transaction via txid?
10:36 < jnewbery> theStack: Yes, regardless of whether it's an improvement or not, separating performance improvements from behavioural changes into different PRs is just good hygiene
10:36 < murch> jnewbery: To run additional services on top of bitcoin
10:36 < glozow> based on what the rpc docs suggest, `getrawtransaction(txid, blockhash)` means "look for this tx in this block" so if it's not in the block and a tx is returned, seems misleading
10:36 < pglazman> In the case of duplicate TxIDs that BIP30 addresses, would providing a block_hash help filter the expected transaction? 
10:36 < larryruane> theStack: what's your opinion about separating those into different commits but still same PR? I've seen that done (i think)
10:36 < stickies-v> raj_: I don't even think it's about performance, without txindex I don't think you can search for transactions (not in your wallet) at all?
10:36 < jnewbery> murch raj_: I agree. Failing the request but returning a more specific error seems optimal
10:37 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
10:37 < jnewbery> pglazman: great question! Has anyone tried using getrawtransaction with either of the duplicate txids?
10:37 < raj_> stickies-v, ya makes sense, unless the user also happens to know the blockhash. 
10:37 < jnewbery> either with or without the txindex enabled
10:37 < theStack> glozow: +1
10:37 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
10:38 -!- gite [~gite@103.81.243.2] has joined #bitcoin-core-pr-reviews
10:38 < sipa> pglazman: i believe it will only find the latter transaction copy
10:38 < sipa> because the later one overwrites the former one
10:38 -!- gite [~gite@103.81.243.2] has quit [Client Quit]
10:38 < sipa> (when using txindex)
10:38 < raj_> jnewbery, without txindex we would only get mempool txs right? 
10:38 < larryruane> sipa: yes because leveldb isn't a multimap (can it even be?)
10:39 < sipa> no
10:39 < sipa> it's a key-value store, and the key is the txid
10:39 < jnewbery> does this PR prevent us from accessing the first one if txindex is enabled, even when providing the correct block hash?
10:39 < larryruane> sipa: got it, thanks
10:39 < lopp> jnewbery: it seems to me that anyone who has txindex enabled wouldn't want to bother searching by blockhash, though it could come in handy if you are looking for transactions in orphaned blocks.
10:39 < sipa> jnewbery: i suspect so
10:40 < sipa> i'm not sure we care for those two historical oddities...
10:40 < theStack> larryruane: i think behvaioural and optimizing changes should always at least separated by commits, but generally i'd prefer different PRs; in a single PR some people (e.g. people deep into optimization, but not caring so much about behaviour) can only "half-ACK" the PR :p
10:40 < jnewbery> I'm not sure what different information would be returned from the first and second ones. What block contextual information does getrawtransaction return?
10:41 < larryruane> theStack: +1
10:41 < murch> Just the blockheight maybe?
10:41 < jnewbery> sipa: agree that in practice, we probably don't care. It's a good test case though
10:41 < murch> and the hash of the block it was included in
10:41 < murch> The tx itself would obviously be immutable, since if it had been malleated, it would have a different txid
10:42 < glozow> jnewbery: also # confirmations and block time if verbose=true, it seems
10:42 < larryruane> for us newbies, are there 2 tx on the mainnet blockchain with the same txids? (but i assume different wtxids) And only 2?
10:42 < jnewbery> If anyone is scratching their heads about "multiple transactions with the same txid", it's all explained in BIP 30: https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki
10:43 < sipa> larryruane: yes, exactly two; no more, no less
10:43 < jnewbery> larryruane: 2 pairs, so 4 transactions
10:43 < sipa> oh right, 2 times 2
10:43 < jnewbery> or 2 transactions, depending on how you define transaction :)
10:44 < jnewbery> There's one more question: How can this PR be tested? Are any new test cases required?
10:44 < Sachin> larryruane https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki
10:44 < raj_> sipa, Where can i read more about these 2 and how/why the occurred? 
10:44 -!- promag [~promag@188.250.84.129] has quit [Remote host closed the connection]
10:44 < Sachin> raj_ see my link
10:44 < theStack> raj_: see jnewbery's link to BIP30 above
10:45 < murch> Yeahhttps://bitcoin.stackexchange.com/a/75301/5406
10:45 < raj_> Sachin, theStack Thanks.. 
10:45 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-pr-reviews
10:46 < jnewbery> any thoughts about testing?
10:46 < theStack> as far as i remember the first version of the PR with behavioural changes still passed the CI; so there seem to be test coverage missing related to GetTransaction
10:46 < theStack> jonatack opened a PR with that
10:46 < raj_> Jonatack has wrote some functional functional tests, yet to go through them.. 
10:46 < lopp> this PR seemed to reveal a lack of testing around expected behavior of this function
10:46 < larryruane> jnewbery: There's another PR to improve the functional testing of this RPC, https://github.com/bitcoin/bitcoin/pull/22437
10:47 < theStack> lopp: +1
10:47 < murch> lopp: Did you ever find out what caused the functional test hiccough?
10:47 < jnewbery> lopp: I agree! It's always a shame when you change behaviour and nothing breaks
10:47 < larryruane> jnewbery: Seems like RPCs like this should be unit-testable, but `src/test/rpc_tests.cpp` seems to mostly test just argument processing
10:48 < sipa> damn tests, they're terrible. their sole purpose in life is to *fail* at the right time, and they can't even do that correctly
10:48 < lopp> murch: oddly enough, the first few commits kept failing and then suddenly started working despite my changes being cosmetic
10:48 < murch> Right, even though I could even reproduce the test failure locally
10:49 < jnewbery> our rpc_tests unit tests are very limited
10:49  * murch scratches head
10:49 < larryruane> jnewbery: but could they be much better?
10:49 < lopp> I assumed it was a CI issue because my tests passed locally
10:49  * unplanted makes a test of a test
10:49 < larryruane> (i'm not sure if they provide enough framework to be able to do more)
10:50 < jnewbery> larryruane: I generally think we use the functional tests too much when a unit test would be more appropriate. In this case though, I think the functional tests are fine. This functionality involves a lot of components (rpc, validation, txindex), and we just don't have the unit test framework to mock all those pieces and isolate the behaviour we want to test
10:50 < larryruane> I think some of the refactoring going on (such as eliminating globals) will make RPCs more unit-testable ... (?)
10:50 < murch> sipa: Yeah, we should really get rid of them on grounds of underperforming
10:51 < larryruane> :laugh:
10:51 < murch> Although I'd say we should look into hiring replacements
10:51 < jnewbery> larryruane: yes, there's ongoing work to elimate globals which would make all of our components more testable. It's really important work
10:51 < murch> lopp: Mh, they did fail for me locally as well.
10:52 < murch> I didn't try again after they passed in the build system, tho
10:52 < jnewbery> Was anyone surprised that GetTransaction() is in validation.cpp? It seems to me that node/transaction.cpp would be a more appropriate place for it.
10:53 < raj_> jnewbery, +1
10:53 < stickies-v> agreed!
10:54 < glozow> jnewbery ya
10:54 < jnewbery> seems weird that validation would call into txindex. I wonder if we remove this function, then validation would no longer need to #include txindex
10:54 < sipa> GetTransaction predates node/transaction.cpp, and even the generic index framework itself :)
10:55 < sipa> (before 0.8, validation itself used the txindex)
10:55 < jnewbery> (and GetTransaction() seems like a natural sibling to BroadcastTransaction(), which is already in node/transaction.cpp)
10:55 < jnewbery> sipa: right, this is not meant as a criticism of course. Just wondering if we can organize things a bit more rationally now that we have better separation between things.
10:55 < sipa> jnewbery: sure, just providing background
10:56 < sipa> seems very reasonable to move it elsewhere now
10:56 < jnewbery> ok, any other questions/thoughts before we wrap this up?
10:56 < larryruane> one small thing,
10:57 < larryruane> does rolling back the blockchain (reorg) need to update txindex?
10:57 -!- Azorcode [~Azorcode@201.242.208.94] has quit [Ping timeout: 268 seconds]
10:57 < jnewbery> larryruane: great question!
10:57 < larryruane> i guess it must need to.. maybe using the rev files?
10:57 < murch> larryruane: I would certainly expect that it does!
10:57 < sipa> it doesn't need to
10:57 < sipa> it can report transactions in non-active chains, as long as the transaction wasn't re-confirmed in the main chain
10:58 < larryruane> oh that's cool!
10:58 < murch> sipa: Right, so wouldn't it weird to get a tx with a blockhash that might not be confirmed in the best chain?
10:58 < lopp> I'd expect txindex would remain the same until said transaction got confirmed in a new block, at which point the txindex pointer would get updated
10:58 < sipa> murch: eh, maybe :)
10:58 < glozow> murch: getrawtransaction tells you if it's in the active chain or not
10:58 < murch> mh
10:58 < murch> TIL
10:59 < sipa> i assume it's pretty much unused functionality, but it has always worked that way
10:59 < jnewbery> oh, I have one more question. Now that we're all experts in GDB thanks to larry's tutorial last week, did anyone step through the code using a debugger?
10:59 < larryruane> i did! haha
10:59 < jnewbery> larryruane: 🥇
11:00 < raj_> I plan to with jonatack's test tomorrow. :)
11:00 < jnewbery> Oh, there are also some gdb notes from last week that larry sent me, which I'll add to last week's meeting page
11:00 < theStack> i'm still being a noob in GDB. is there a record of larryruane's video tutorial available? 
11:00 < theStack> jnewbery: ah, that sounds useful
11:01 < stickies-v> theStack it's in the meeting notes: https://bitcoincore.reviews/22350
11:01 < jnewbery> theStack: video is linked to from https://bitcoincore.reviews/22350
11:01 < jnewbery> stickies-v: thanks!
11:01 < larryruane> I forgot to record last week, but I re-did it on my own (it's a lot better)
11:01 < jnewbery> ok, that's time. Thank you everyone. Next week, glozow is hosting
11:01 < jnewbery> #endmeeting
11:01 < theStack> stickies-v: great, thanks! for some reason i missed that
11:01 < larryruane> thanks lopp and jnewbery ! 
11:01 < murch> Thanks!
11:01 < stickies-v> thanks jnewbery for hosting and lopp for the PR! see you next week, everyone
11:01 < dariusp> thanks!!
11:02 < raj_> thanks jnewbery , nice meeting.. 
11:02 < unplanted> in case it's of interest to anyone regarding visual plots of performance "USENIX ATC '17 - Visualizing Performance with Flame Graphs" http://youtu.be/D53T1Ejig1Q
11:02 < theStack> thanks for hosting jnewbery, thanks for the PR lopp
11:02 < unplanted> thanks lopp jnewbery 
11:02 < jnewbery> unplanted: great. Thank you! If you want to host a meeting on flame graphs sometime, let me know
11:02 -!- stickies-v [~stickies-@2a05:4f44:21b:ed00:b593:9ce5:4c55:7be0] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
11:02 < emzy> Tankks jnewbery and lopp
11:03 < larryruane> unplanted: thanks, that looks really cool, I'd like to learn about this
11:03 -!- Sachin [~Sachin@136-24-115-54.cab.webpass.net] has quit [Quit: Connection closed]
11:04 -!- pglazman [~pglazman@136-24-115-54.cab.webpass.net] has left #bitcoin-core-pr-reviews [Textual IRC Client: www.textualapp.com]
11:04 -!- murch [~murchin@user/murch] has quit [Quit: "run awaaaay"]
11:05 -!- theStack [~honeybadg@vps1648322.vs.webtropia-customer.com] has quit [Quit: leaving]
11:06 < unplanted> jnewbery nicolas Dorier is probably the best person to host about flame graphs.  Here's an example of how he used them to detect some optimizations with lnd https://youtu.be/nwSuctrzV7Y?t=2913 cc larryruane 
11:08 < merkle_noob[m]> Hello everyone, and thanks to all of you who participated in the meeting. I really learnt a lot from all of you 🙏
11:09 < unplanted> glad you could attend merkle_noob[m] 
11:11 -!- dariusp [~dariusp@c-73-252-226-175.hsd1.ca.comcast.net] has quit [Quit: Ping timeout (120 seconds)]
11:11 < merkle_noob[m]> unplanted: Thanks!🙏
11:12 < unplanted> hope to see you next week
11:16 -!- lopp [~lopp@104.129.24.124] has quit [Quit: Connection closed]
11:17 < merkle_noob[m]> unplanted: Sure, I will not miss it :)
11:18 < kiran> Hi,when txindex=1 where is the txind and the information about txindex is present? Is it present in a separate DB aside the block db. Where to read more about it?
11:34 -!- raj_ [~raj_@103.77.139.179] has quit [Quit: Leaving]
11:48 -!- davterra [~davterra@143.198.56.186] has joined #bitcoin-core-pr-reviews
11:49 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Read error: Connection reset by peer]
11:50 -!- luke-jr [~luke-jr@user/luke-jr] has joined #bitcoin-core-pr-reviews
12:10 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:23 -!- unplanted [~switch@185.212.170.140] has quit [Quit: unplanted]
12:24 -!- observer66 [~observer@cpe-23-242-148-67.socal.res.rr.com] has quit [Ping timeout: 268 seconds]
12:39 -!- kiran [~kiran@218.185.248.66] has quit [Quit: Connection closed]
13:16 -!- kexkey [~kexkey@static-198-54-132-108.cust.tzulo.com] has joined #bitcoin-core-pr-reviews
13:41 -!- meshcollider [meshcollid@user/meshcollider] has quit [Quit: :wave:]
13:41 -!- vicarious24 [~vicarious@c-98-214-196-137.hsd1.il.comcast.net] has quit [Quit: Connection closed]
13:58 -!- meshcollider [meshcollid@meshcollider.jujube.ircnow.org] has joined #bitcoin-core-pr-reviews
15:26 -!- hex17or [~hex17or@gateway/tor-sasl/hex17or] has quit [Ping timeout: 244 seconds]
15:33 -!- hex17or [~hex17or@gateway/tor-sasl/hex17or] has joined #bitcoin-core-pr-reviews
15:53 -!- promag [~promag@188.250.84.129] has quit [Remote host closed the connection]
15:54 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-pr-reviews
16:15 -!- promag_ [~promag@188.250.84.129] has joined #bitcoin-core-pr-reviews
16:17 -!- promag__ [~promag@188.250.84.129] has joined #bitcoin-core-pr-reviews
16:17 -!- promag_ [~promag@188.250.84.129] has quit [Read error: Connection reset by peer]
16:17 -!- promag [~promag@188.250.84.129] has quit [Ping timeout: 268 seconds]
16:59 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 252 seconds]
17:02 -!- belcher [~belcher@user/belcher] has joined #bitcoin-core-pr-reviews
17:12 -!- belcher_ [~belcher@user/belcher] has joined #bitcoin-core-pr-reviews
17:13 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 265 seconds]
--- Log closed Thu Jul 22 00:00:15 2021