--- Day changed Wed Jan 08 2020
00:06 -!- paultroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #bitcoin-core-pr-reviews     
00:58 -!- pinheadmz [~matthewzi@185.236.200.116] has quit [Quit: pinheadmz]     
01:33 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-pr-reviews     
01:37 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
01:40 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]     
02:14 -!- paultroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit [Ping timeout: 258 seconds]     
02:18 -!- paultroon [~paultroon@185.128.24.51] has joined #bitcoin-core-pr-reviews     
02:52 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews     
02:55 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 260 seconds]     
03:03 -!- Susana25Brakus [~Susana25B@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-pr-reviews     
03:08 -!- Susana25Brakus [~Susana25B@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 240 seconds]     
03:26 -!- diogosergio [~diogoserg@0545f855.skybroadband.com] has joined #bitcoin-core-pr-reviews     
03:32 -!- emilengler [~emilengle@unaffiliated/emilengler] has joined #bitcoin-core-pr-reviews     
03:34 -!- diogosergio [~diogoserg@0545f855.skybroadband.com] has quit [Quit: Lost terminal]     
03:54 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews     
04:00 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has quit [Remote host closed the connection]     
04:18 -!- jonatack [~jon@213.152.162.94] has joined #bitcoin-core-pr-reviews     
05:02 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has joined #bitcoin-core-pr-reviews     
05:06 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has quit [Client Quit]     
05:11 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has joined #bitcoin-core-pr-reviews     
05:51 -!- felixfoertsch23 [~felixfoer@2001:16b8:504d:7a00:9c86:4c59:e23a:4d93] has quit [Quit: ZNC 1.7.4 - https://znc.in]     
05:56 -!- felixfoertsch [~felixfoer@2001:16b8:504d:7a00:a0ab:8573:e073:e300] has joined #bitcoin-core-pr-reviews     
06:01 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has quit [Quit: This computer has gone to sleep]     
06:22 -!- paultroo_ [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #bitcoin-core-pr-reviews     
06:23 -!- paultroon [~paultroon@185.128.24.51] has quit [Read error: Connection reset by peer]     
06:28 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has joined #bitcoin-core-pr-reviews     
06:42 -!- jonatack [~jon@213.152.162.94] has quit [Ping timeout: 268 seconds]     
06:43 -!- jonatack [~jon@109.202.107.147] has joined #bitcoin-core-pr-reviews     
06:51 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 240 seconds]     
07:27 -!- jonatack [~jon@109.202.107.147] has quit [Ping timeout: 260 seconds]     
07:43 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has quit [Quit: This computer has gone to sleep]     
07:56 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has joined #bitcoin-core-pr-reviews     
08:21 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews     
08:26 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews     
08:39 -!- shesek [~shesek@5.22.135.198] has joined #bitcoin-core-pr-reviews     
08:39 -!- shesek [~shesek@5.22.135.198] has quit [Changing host]     
08:39 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews     
08:53 -!- avril [wha@unaffiliated/avril] has quit [Quit: later skater]     
09:07 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews     
09:07 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Client Quit]     
09:08 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews     
09:23 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews     
09:24 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 240 seconds]     
09:28 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-yykaxgczrolqfbhm] has quit [Ping timeout: 248 seconds]     
09:28 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 240 seconds]     
09:41 -!- paultroo_ [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit [Remote host closed the connection]     
09:45 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews     
09:50 -!- Irssi: #bitcoin-core-pr-reviews: Total of 73 nicks [0 ops, 0 halfops, 0 voices, 73 normal]     
09:51 -!- marcinja [~marcinja@2604:a880:400:d1::89a:e001] has joined #bitcoin-core-pr-reviews     
09:51 < marcinja> hello
09:53 < jnewbery> marcinja: hi! We start in 7 minutes
09:53 -!- paultroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #bitcoin-core-pr-reviews     
09:54 < raj_> Hi..
09:54 < emilengler> raj_: Hi
09:55 < emilengler> sorry can't participate at todays meeting. Something came up and got to go soon
09:56 < nehan_> hi     
09:57 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:d831:3541:1e0f:d67e] has joined #bitcoin-core-pr-reviews     
09:57 -!- van [18bf0fb0@ool-18bf0fb0.dyn.optonline.net] has joined #bitcoin-core-pr-reviews     
10:00 < jnewbery> #startmeeting
10:00 < jkczyz> hi     
10:00 < jonatack> hi     
10:00 < jnewbery> hi     
10:00 < _andrewtoth_> hi     
10:00 < fjahr> hi     
10:00 < jnewbery> Hi folks. Welcome to the first Review Club of 2020 :)
10:00 < michaelfolkson> hi     
10:00 < emzy> Hi     
10:00 < amiti> hi     
10:00 < jnewbery> Notes are in the usual place: https://bitcoincore.reviews/14053.html
10:00 < jnewbery> Feel free to say "hi" to let everyone know that you're at keyboard.
10:00 < jnewbery> Before we begin, just a reminder of some of our meeting conventions:
10:00 < jnewbery> 1. You don't have to ask to ask a question (e.g. "I have a question about x but I don't know if it's on-topic?"). Just go ahead and ask. If it's off-topic we'll tell you.
10:01 < jnewbery> 2. You don't need to wait for the host to ask a specific question — just jump in at any point.
10:01 < van> hi     
10:01 < jnewbery> Ok, let's get started. Did everyone get a chance to review the PR? How about a quick y/n from everyone
10:01 < _andrewtoth_> y     
10:01 < raj_> y     
10:01 < jkczyz> n (read the notes)
10:01 < emzy> y     
10:01 < kanzure> hi     
10:02 < michaelfolkson> y     
10:02 < amiti> n - read notes and brief overview of PR
10:02 < fjahr> working on it
10:02 < jonatack> y     
10:02 < jnewbery> First question was about whether Bitcoin Core should include an address index. I don't think we want to get into a long debate, but did people think a bit about the arguments for and against?
10:03 < marcinja> cccccclkninbdfgdifvjhklfgutvrdrtetdfbirvveuj
10:03 < kanzure> was there a recent address index proposal..?
10:03 < fjahr> pro: clearly there is a need for it based on user requests
10:03 < marcinja> oops sorry, new yubikey is being annoying
10:03 < fjahr> con: storage requirements
10:03 < amiti> con: unscalable in the long term
10:03 < jnewbery> kanzure: not recent. We're reviewing 14053 which was opened last year
10:03 < jonatack> I'll admit I'm having trouble concept acking this being in bitcoin core despite the long-term request for this
10:04 < nehan_> con: more code to maintain / added complexity
10:04 < raj_> pro: seems like an useful tool. con:  worried about storage and IBD time.
10:04 < amiti> pro: people need it so often depend on 3rd party services. having it in core would be preferable
10:04 < michaelfolkson> Yeah if it keeps coming up, there's almost an argument to just get it over with. Assuming the downsides aren't that severe which they don't seem to be (at least for the Core project itself)
10:04 < nehan_> pro: seems to be real desire for this and good use cases
10:04 < kanzure> jnewbery: thanks for the clarification.
10:05 < _andrewtoth_> pro: increased privacy and not forcing users to use third-party services/software
10:05 < jnewbery> raj_: this wouldn't impact IBD time (well perhaps for people that decided to enable an address index, but this would be disabled by default)
10:05 < fjahr> I did not see any stats and projections on storage usage, should not be to hard to I think, or did I miss something?
10:05 < _andrewtoth_> con: creating reliance on it being available when it won't scale
10:05 < jnewbery> yeah, I think that's a good summary of the arguments. What did people think about this particular implementation. Does it address any of those concerns?
10:05 < jonatack> Opportunity cost, maintainence, and disincentivises the more sustainable dedicated external solution, pushing it down the road
10:06 < jonatack> at first look in any case
10:06 < emzy> pro: you could habe a more simple elecrum wallet connector. Or use electrum direct with bitcoin core.
10:06 < _andrewtoth_> emzy: you can already do that with https://github.com/chris-belcher/electrum-personal-server
10:06 < _andrewtoth_> I guess it would be more simple though, yeah
10:07 < emzy> _andrewtoth_: I know. But you have te reindex und put ypu xpub in EPS.
10:07 < nehan_> jnewbery: does not address long-term scalability issue. doesn't seem too bad in terms of added code though.
10:07 < raj_> i feel like its a good addition, given optionality.
10:07 < emzy> xpub.
10:07 < jnewbery> I think using the base index infrastructure addresses some of the concerns about code complexity and performance
10:08 < fjahr> pro of this particular PR against the historical ones: it uses the base index which should make it easier to maintain, which means this is probably also much easier to maintain as an external patch if it does not get in
10:08 < michaelfolkson> Any reason why EPS wasn't included in the summary jonatack?
10:08 < jnewbery> nehan_: right, I agree
10:08 < jnewbery> fjahr: I agree that it'd be nice to see stats and storage projections
10:09 < jonatack> michaelfolkson: i did not understand your comment
10:09 < _andrewtoth_> emzy: with https://github.com/bitcoin/bitcoin/pull/10785 it would make it much faster to rescan. I think that's ultimately the better solution, block filter indexing and fast rescanning for addresses you want to know about
10:09 < jnewbery> marcinja: did you run this on mainnet? Do you know what the storage requirements are for indexing the full mainnet?
10:09 < raj_> yes stats would be very informative
10:09 < jnewbery> (or did anyone else run this on mainnet?)
10:09 < raj_> I am clueless about the potential impact otherwise.
10:09 -!- paultroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit []     
10:10 < michaelfolkson> jonatack: "Bitcore, electrs and ElectrumX are three examples." I just wondered if EPS was missing something or not intentional.
10:10 < _andrewtoth_> i started running this on mainnet last evening. It's only at block 473300 now
10:10 < marcinja> jnewbery: I did a full sync on mainnet last year but I don't remember the size off the top of my head
10:10 < _andrewtoth_> storage is at 98 GB already
10:10 < _andrewtoth_> so it's several times slower than reindex-chainstate
10:10 < nehan_> it's useful for me to understand what's missing from something like this before it might be considered for merging.  one is definitely stats/benchmarks.
10:11 < nehan_> another is testing and the documentation jnewbery pointed out in his comment
10:11 < jnewbery> nehan_: that's a good question. What do other people think?
10:11 < nehan_> or perhaps others think it is mergeable without those things?
10:11 < michaelfolkson> About stats/benchmarks?
10:11 < raj_> agreed with nehan_
10:11 < nehan_> michaelfolkson: what else needs to be done before considering this PR for merging?
10:12 < _andrewtoth_> nehan_: agree, we need those numbers before considering
10:12 < jnewbery> _andrewtoth_: how large is the blockchain up to height 473300? (I'm interested in how large the address index is in comparison to the blockchain)
10:12 < raj_> i do have one point regarding testing. But i think we will hit that later anyway.
10:12 < nehan_> marcinja: what do you think?
10:12 < _andrewtoth_> jnewbery: du -h | grep addr_index -> 98G	./addr_index
10:13 < _andrewtoth_> oh sorry you want to know blockchain size, not sure
10:13 < marcinja> nehan_: I definitely agree it should be documented better, that should at least make it easier to review. Stats and benchmarks would put people at ease maybe and also won't be hard to get
10:13 < jonatack> michaelfolkson: Ah! I do not know. I did not write this summary :)
10:14 < jnewbery> _andrewtoth_: du -h blocks should tell you
10:14 < jkczyz> Did jamesob report back on the use cases that companies had for this? Seems any solution that would scale requires multiple nodes and mechanism to resolve inconsistencies across nodes.
10:14 < _andrewtoth_> oh, i'm already synced
10:14 < _andrewtoth_> it's just indexing in the addrindex thread
10:15 < jnewbery> _andrewtoth_: ah, ok. I forgot that the indexer could fall behind!
10:15 < michaelfolkson> jkczyz: So on the use case front I saw local block explorers. What else?
10:15 < _andrewtoth_> jnewbery: well i already had the node synced, i just built on the branch and ran with -addrindex
10:16 < jnewbery> jkczyz: I'd *hope* that there wouldn't be inconsistencies
10:17 < jnewbery> I linked to a couple of comments from engineers building services, and their use cases for an address index: https://github.com/bitcoin/bitcoin/pull/2802#issuecomment-26712372, https://github.com/bitcoin/bitcoin/pull/14053#issuecomment-558344637
10:17 < jkczyz> By inconsistencies I mean competing versions of the tip
10:17 < fjahr> michaelfolkson: people who use block explorers but don't want to use public ones
10:17 < jkczyz> chain tip
10:17 < fjahr> ah sorry, that's what you meant
10:18 < raj_> cant then this be done in standalone way for those who want to use their own explorer?
10:18 < jnewbery> jkczyz: Is that concern specific to address indexes or general to any service built on Bitcoin?
10:18 < michaelfolkson> I'm finding it hard to care about the Approach ACK when there isn't agreement on the Concept ACK. And at least the Concept nACK seems to be the primary reason why the other attempts were rejected
10:18 < jkczyz> any service really
10:19 < jonatack> marcinja: Since you are here (which is great!) could you discuss your motivation for reviving this PR? I didn't you mention the *why* in the PR description, which seemed quite succinct for a change like this.
10:19 < jonatack> I didn't see* you mention the *why*
10:19 < jnewbery> michaelfolkson: I don't see any concept NACKs on the PR
10:20 < michaelfolkson> jnewbery: But you agree that's the primary reason why other attempts failed?
10:20 < raj_> any service really. Seems like something you can write your own script for. This PR can be used as a refference.
10:21 < michaelfolkson> Don't mean to derail discussion :/ The PR seems good
10:21 < raj_> But yes, through discussion it does seem like a high demand functionality.
10:22 < jonatack> marcinja: In other words, you provide the how but without your why. I would have liked to hear your why :)
10:22 < jnewbery> michaelfolkson: maybe. The final comment on the last attempt was from sipa: "I vote to close this; this should be done in an external index. Perhaps at some point when we can a more modular design it can be supported as an optionally buildable module, but let's not complicate the current database tracking code."
10:22 < fjahr> raj_: that was the feedback in most of the discussions. As a standalone or patch. But of course people would like a really robust solution maintained by core because this is not so easy to maintain.
10:22 < jnewbery> we now have that more modular design!
10:23 < raj_> fjahr: any particular reason why its hard to maintain?
10:23 < michaelfolkson> Ok fair enough. Thanks :)
10:23 < jnewbery> ok, let's move on to the next question: What steps did you take to review and test this PR? Did you try to create an address index over the full mainnet block chain?
10:24 < raj_> standard unit and functional testing. Didint tried on mainnet.
10:24 < jnewbery> and we can also talk about the next question at the same time: Did you review the unit and functional tests? Are there any additional test cases that you’d like to see added?
10:24 < nehan_> i just read the code
10:24 < ariard> I agree with sipa we should do this in its own module post-multiprocess with the rest of the server code
10:24 < _andrewtoth_> built and ran tests, but as I mentioned, mainnet syncing is taking a long time
10:24 < fjahr> raj_: I don't have seen any particular reference to which problems these projects have.
10:24 < _andrewtoth_> however, testing already indexed addresses with searchrawtransactions works
10:25 < marcinja> jonatack: Sure. One of the main justifications is that it seems like a lot of people don't want to run extra software in addition to Bitcoin Core to get block explorer functionality. If people can get that functionality easily without sacrificing privacy its a plus for me.
10:25 < emzy> I just read the PR and compiled the PR. But had no time to run it. Mainet data is still rsyning
10:25 < jnewbery> ariard: what do you think having multiprocess provides as an improvement for an address index?
10:25 < _andrewtoth_> as i mentioned on github, we should have ability to skip transactions, so we can page through them. I'd like to see that implemented and tested
10:25 < raj_> functional testing does not include any check for spends_results. It only checks consistency of creation_results.
10:26 < jnewbery> raj_: yes, I'd definitly like to see that added to the tests. Did anyone test it manually?
10:26 < _andrewtoth_> yes i tested manually and got spend results
10:26 < ariard> jnewbery: architectural level, you should split all indexes in its own process (like bitcoin-server) so the server would be able to serve multiple clients without encumbering operation of the consensus/p2p module
10:27 < ariard> so easier to maintain, smaller binary for ones not interested, easier to have its improvements pace, like if we split the wallet from the node
10:29 < jonatack> marcinja: Thanks. It's true there is accumulated context behind the PR, but my intuition (which can be wrong ofc) is that providing context (and links to more) in your PR description can help "sell" the PR.
10:29 < jnewbery> ariard: binary size is negligable (a few hundred lines of code), I don't think there's any difference in maintenance - that's more of a code separation issue than process separation
10:29 < nehan_> ariard: what needs to be done before one could build this PR the way you suggest? How far out is that?
10:30 < jnewbery> Serving RPC requests to the index doesn't take cs_main, so I don't think it encumbers operation of consensus/p2p
10:30 < jnewbery> and improvements pace is another code separation thing, not process separation
10:30 < michaelfolkson> I agree jonatack. I think jnewbery point on the modularity of Core being improved since the previous attempts is a key "sell" too
10:30 < jonatack> marcinja: because if the *why* isn't justified, then the *how* doesn't matter.
10:30 < jnewbery> (I'm not arguing against multiprocess, but I don't think it directly impacts this PR)
10:30 < marcinja> jonatack: That's a good point. I'll try to summarize the background better for a new PR description
10:32 < jonatack> marcinja: yes, and give it a bit of your personal conviction too perhaps, without being too subjective. Just a side thought, maybe not a helpful one, but I was looking for that.
10:32 < ariard> jnewbery: code separation let you do process separation so both of them are tied, having different processes would let them running on different machines
10:32 < ariard> and if you server is doing heavy rescans, not taking cpu time for the validation
10:33 < jnewbery> ariard: I agree those things are true, but I don't think it's a requirement for this PR
10:33 < jnewbery> there are lots of things that *could* be improved about Bitcoin Core architecture, but we shouldn't pull all of those into discussion of individual PRs
10:34 < ariard> jnewbery: I'm worried it would make it harder to split it latter, that's really IMO but if you take the wallet, more there is features, more the chain interface is stuffed, harder it make it to refactor
10:34 < nehan_> ariard: you can run 2 bitcoin core nodes, one with this on and one with this off, if you wanted.
10:35 < ariard> nehan_: hmm that's a good question, harder point would be to memory isolate indexes from the rest of the node, cut dependencies between them, and get it its own p2p stack
10:36 < jnewbery> I believe the only validation interface method this uses is BlockConnected, which is in the base indexer class
10:36 < jnewbery> It's interface with the rest of the node is minimal
10:36 < jnewbery> *Its
10:36 < ariard> nehan_: okay but know you do 2 ibds, even if the second one is pruned, seems more a hack than doing it cleanly
10:37 < jnewbery> Next question!
10:37 < jnewbery> The address index is stored in LevelDB, which is a key-value store. What is used as the key, and what is used as the value?
10:37 < nehan_> ariard: if one implemented a blockexplorer from scratch they'd have to do IBD anyway.
10:38 < ariard> jnewbery: dunno if this is that hard to split, want to try at some point
10:38 < nehan_> this was confusing. marcinja please add documentation :) but i think the key is scripthash, outpoint
10:38 < ariard> nehan_: a pruned wallet does not need ibd, you already speaking about one specific application requirement I think
10:39 < belcher> earlier people were saying this addrindex could be used as an electrum server, electrum's protocol uses hash(scriptPubKey) as the key for its queries, so if an electrum server implementation is desired that would probably need to be the key in core
10:39 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 240 seconds]     
10:39 < raj_> The key seems to be [type, outpoint] and value: [CDiskTxPos, Script]
10:39 < nehan_> belcher: hash(scriptPubKey) is the key prefix, so that works here too. How does electrum handle multiple outpoints with the same hash(scriptPubKey)?
10:39 < raj_> I might be wrong, i am very new to c++
10:40 < jnewbery> nehan_: I think it's (type | script hash | outpoint) . Is that right, marcinja?
10:40 < nehan_> oh yes. type, sorry, forgot.
10:40 < belcher> nehan_ the electrum client sends a list of its bitcoin addresses encoded as hash(spk) and the server replies with transactions on those addresses, so if an address contains multiple outputs then the server replies with all those txes
10:41 < jnewbery> I was confused about the outpoint being used: https://github.com/bitcoin/bitcoin/pull/14053#discussion_r363971325
10:41 < michaelfolkson> Type being SEED, SPENT, CREATED
10:41 < belcher> electrum doesnt use outpoints in its protocol, it only uses hash(spk) and transactions encoded as hex
10:42 < nehan_> belcher: the rpc interface doesn't use outpoints either. so I think this is compatible.
10:42 < marcinja> jnewbery: it's (script hash | type | outpoint)
10:42 < jnewbery> belcher: sorry, the question might be a bit confusing. I was asking about the internal levelDB representation. The RPC query uses the script or address to lookup in the index
10:43 < michaelfolkson> +1 on nehan_ docs suggestion
10:44 < jnewbery> marcinja: you sure? I think it's (type | scripthash | outpoint) : https://github.com/bitcoin/bitcoin/pull/14053/files#diff-11cde577be5c21f1d0cb1527c50543b3R188
10:44 < nehan_> jnewbery: i believe it is always the outpoint where the scriptPubKey was created. I believe this is used to get unique keys when the same scriptPubKey is used multiple times.
10:45 < marcinja> nehan_: that's right. leveldb doesn't support multiple values for a single key so adding the outpoint is one way to have unique keys.
10:46 < jnewbery> It looked to me like that part of the key (the outpoint) is included in the RPC response as txid: https://github.com/bitcoin/bitcoin/pull/14053/files#diff-01aa7d1d32f1b9e5a836c9c411978918R314
10:46 < jnewbery> so I *think* that for spends, the txid given is actually the txid of the transaction creating the UTXO not the txid of the transaction spending the UTXO
10:48 < jnewbery> ok, time's running out so let's move on to the next question: Where is MurmurHash3 used in this PR? How are hash collisions resolved? Where else is MurmurHash3 used in the Bitcoin Core codebase?
10:49 < marcinja> jnewbery: yes that's right, the transaction from the value should be used for that txid. clearly that needs a functional test :)
10:50 < marcinja> jnewbery: I think the key is serialized in the order I gave, but the constructor shows them in a different order which is definitely confusing
10:50 < michaelfolkson> The address index stores a copy of the CScript in case of hash collisions
10:51 < nehan_> jnewbery: i think you caught a bug. I'm leaving a comment.
10:51 < jnewbery> michaelfolkson: yes, that's right
10:52 < jnewbery> ok, final question. How does the address index handle reorgs?
10:54 < jnewbery> ok, perhaps something to look into when you all do your reviews :)
10:54 < jnewbery> 5 minutes left. Any final questions?
10:55 < michaelfolkson> What is the answer to the reorg question? :)
10:55 < instagibbs> anyone run benchmarks up to different heights? both benchmarking IBD and query response times?
10:55 < instagibbs> michaelfolkson, "hopefully" ;)
10:56 -!- van [18bf0fb0@ool-18bf0fb0.dyn.optonline.net] has quit [Remote host closed the connection]     
10:56 < jnewbery> michaelfolkson: left as an exercise for the reader
10:56 < emzy> I will run a benchmark with a blockchain that has already a txindex.
10:57 < nehan_> jnewbery: https://github.com/bitcoin/bitcoin/pull/14053/files#r364389525
10:57 < jnewbery> emzy: the presence/absence of a txindex shouldn't have any impact
10:58 < _andrewtoth_> instagibbs: just generating the addrindex with a synced node has taken 16 hours to get to 478000 blocks :/
10:58 < jnewbery> nehan_: thanks!
10:58 < _andrewtoth_> IBD with assumevalid on has taken the same machine < 6 hours
10:59 < jnewbery> I'm slightly unconcerned about performance of building the address index for the first time, since it only has to be done once
10:59 < jnewbery> I wonder how this compares to external tools like electrs
10:59 < _andrewtoth_> also, querying can be optimized by taking count and returning early
10:59 < _andrewtoth_> i commented on github
10:59 < jnewbery> belcher: do you know how long building an index in electrs takes, or is it doing something different?
11:00 < emzy> electrs will do a full sync in about 16h
11:00 < michaelfolkson> In this case why use MurmurHash3? Would another hash function offer better collision resistance? Understand it is a trade-off with simplicity, speed etc
11:00 < belcher> i dont know
11:00 -!- meshcollider [meshcollid@209.141.50.204] has joined #bitcoin-core-pr-reviews     
11:00 < michaelfolkson> "good enough" collision resistance I suppose
11:00 < jnewbery> That's time. Thanks everyone. Hope you all enjoyed!
11:00 < _andrewtoth_> thanks!
11:00 < jnewbery> And thanks to marcinja for dropping in
11:01 < marcinja> thanks jnewbery for hosting, and thanks to everyone who reviewed and gave feedback. This was very helpful :)
11:01 < amiti> thank you!
11:01 < nehan_> thanks!
11:01 < michaelfolkson> You mean in EPS jnewbery?
11:01 < michaelfolkson> Thanks!
11:01 < raj_> Thanks.
11:01 < fjahr> thanks, very good choice!
11:01 < emzy> thanks jnewbery, marcinja and everyone!
11:01 < _andrewtoth_> EPS uses the wallet and imports the addresses, then does a rescan
11:01 < jnewbery> Next week is fuzzing, hosted by MarcoFalke. Notes are already available: https://bitcoincore.reviews/17860.html
11:01 < jnewbery> #endmeeting
11:01 < jonatack> thanks marcinja and jnewbery and all
11:05 -!- fox2p [~fox2p@cpe-66-108-32-173.nyc.res.rr.com] has quit [Ping timeout: 258 seconds]     
11:06 < instagibbs> _andrewtoth_, not inspiring, but it's a priori known that eventually it will not be usable on a pleb machine. Question is how many years...
11:09 < michaelfolkson> An index in Core? Or any index, internal or external to Core?
11:16 < instagibbs> Fuzzing frameworks is a huge hole in my knowledge. Going to try and study up this coming week
11:16 -!- Aruk [51f31eaa@81.243.30.170] has joined #bitcoin-core-pr-reviews     
11:24 -!- pinheadmz [~matthewzi@185.236.200.116] has joined #bitcoin-core-pr-reviews     
11:25 -!- fox2p [~fox2p@66.108.32.173] has joined #bitcoin-core-pr-reviews     
11:34 -!- pinheadmz [~matthewzi@185.236.200.116] has quit [Ping timeout: 265 seconds]     
11:36 -!- pinheadmz [~matthewzi@ip68-96-198-25.lv.lv.cox.net] has joined #bitcoin-core-pr-reviews     
11:39 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!]     
11:58 -!- emilengler [~emilengle@unaffiliated/emilengler] has quit [Quit: Leaving]     
12:00 < jnewbery> Meeting Log is posted: https://bitcoincore.reviews/14053.html
12:29 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-pr-reviews     
12:56 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]     
13:37 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
13:40 -!- seven_ [~seven@2a00:ee2:410c:1300:3902:ba7d:4f17:e920] has joined #bitcoin-core-pr-reviews     
13:40 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]     
13:49 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews     
13:54 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:d831:3541:1e0f:d67e] has quit [Ping timeout: 252 seconds]     
14:15 -!- michaelfolkson [~textual@host86-133-235-133.range86-133.btcentralplus.com] has joined #bitcoin-core-pr-reviews     
15:01 -!- avril [wha@unaffiliated/avril] has joined #bitcoin-core-pr-reviews     
15:44 -!- michaelfolkson [~textual@host86-133-235-133.range86-133.btcentralplus.com] has quit [Quit: Sleep mode]     
15:50 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 268 seconds]     
15:52 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:a430:fcab:6567:f900] has joined #bitcoin-core-pr-reviews     
15:54 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:a430:fcab:6567:f900] has quit [Client Quit]     
15:58 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-pr-reviews     
16:12 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:a430:fcab:6567:f900] has joined #bitcoin-core-pr-reviews     
16:13 -!- felixfoertsch [~felixfoer@2001:16b8:504d:7a00:a0ab:8573:e073:e300] has quit [Quit: ZNC 1.7.4 - https://znc.in]     
16:13 -!- felixfoertsch [~felixfoer@2001:16b8:504d:7a00:a0ab:8573:e073:e300] has joined #bitcoin-core-pr-reviews     
16:13 -!- felixfoertsch [~felixfoer@2001:16b8:504d:7a00:a0ab:8573:e073:e300] has quit [Remote host closed the connection]     
16:17 -!- felixfoertsch [~felixfoer@i6DFA6C69.versanet.de] has joined #bitcoin-core-pr-reviews     
16:25 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has joined #bitcoin-core-pr-reviews     
16:29 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 260 seconds]     
16:32 -!- jkczyz [~jkczyz@135.84.132.250] has quit [Ping timeout: 268 seconds]     
16:33 -!- jkczyz [~jkczyz@135.84.132.250] has joined #bitcoin-core-pr-reviews     
16:34 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews     
16:40 -!- Aruk [51f31eaa@81.243.30.170] has quit [Remote host closed the connection]     
16:41 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 240 seconds]     
17:00 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has quit [Quit: This computer has gone to sleep]     
17:02 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has joined #bitcoin-core-pr-reviews     
17:20 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews     
17:37 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has quit [Remote host closed the connection]     
17:43 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has quit [Quit: This computer has gone to sleep]     
17:47 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has joined #bitcoin-core-pr-reviews     
18:11 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:a430:fcab:6567:f900] has quit [Quit: Sleep mode]     
18:18 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 252 seconds]     
19:34 -!- felixfoertsch23 [~felixfoer@i6DFA6402.versanet.de] has joined #bitcoin-core-pr-reviews     
19:35 -!- felixfoertsch [~felixfoer@i6DFA6C69.versanet.de] has quit [Ping timeout: 265 seconds]     
20:42 -!- emilengler [~emilengle@unaffiliated/emilengler] has joined #bitcoin-core-pr-reviews     
20:50 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has quit [Quit: This computer has gone to sleep]     
21:17 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has joined #bitcoin-core-pr-reviews     
22:25 -!- pinheadmz [~matthewzi@ip68-96-198-25.lv.lv.cox.net] has quit [Quit: pinheadmz]     
22:30 -!- pinheadmz [~matthewzi@ip68-96-198-25.lv.lv.cox.net] has joined #bitcoin-core-pr-reviews     
23:45 -!- pinheadmz [~matthewzi@ip68-96-198-25.lv.lv.cox.net] has quit [Quit: pinheadmz]     
23:46 -!- emilengler [~emilengle@unaffiliated/emilengler] has quit [Quit: Leaving]     
23:47 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews     
23:56 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has joined #bitcoin-core-pr-reviews