--- Day changed Wed Jul 08 2020
01:00 -!- vindard [~vindard@190.83.165.233] has quit [Read error: Connection reset by peer]     
01:00 -!- vindard [~vindard@190.83.165.233] has joined #bitcoin-core-pr-reviews     
01:55 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack]     
02:08 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]     
02:51 -!- dr-orlovsky [~dr-orlovs@xdsl-188-154-184-23.adslplus.ch] has joined #bitcoin-core-pr-reviews     
02:52 -!- jonatack [~jon@192.113.14.109.rev.sfr.net] has joined #bitcoin-core-pr-reviews     
02:57 -!- jonatack [~jon@192.113.14.109.rev.sfr.net] has quit [Ping timeout: 256 seconds]     
02:58 -!- jonatack [~jon@213.152.162.5] has joined #bitcoin-core-pr-reviews     
03:03 -!- Pearl25Miller [~Pearl25Mi@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
03:10 -!- Pearl25Miller [~Pearl25Mi@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 240 seconds]     
03:52 -!- belcher [~belcher@unaffiliated/belcher] has quit [Read error: Connection reset by peer]     
03:52 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews     
04:07 -!- slivera [~slivera@103.231.88.10] has joined #bitcoin-core-pr-reviews     
06:23 -!- jonatack [~jon@213.152.162.5] has quit [Ping timeout: 256 seconds]     
06:46 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has quit [Quit: ZNC 1.7.4+deb7 - https://znc.in]     
06:46 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has joined #bitcoin-core-pr-reviews     
07:13 -!- Guest92810 is now known as real_or_random     
07:21 -!- seven_ [~seven@2a00:ee2:410c:1300:3140:7629:7ac3:a5b2] has quit [Read error: Connection reset by peer]     
07:24 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
07:27 -!- slivera [~slivera@103.231.88.10] has quit [Remote host closed the connection]     
07:52 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has quit [Ping timeout: 260 seconds]     
07:52 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has joined #bitcoin-core-pr-reviews     
08:30 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
08:34 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]     
08:34 -!- vasild_ is now known as vasild     
09:00 -!- amiti [6bd29f36@107-210-159-54.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-pr-reviews     
09:04 < amiti> testing..  anyone see this?
09:04 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews     
09:04 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection]     
09:05 < sipa> amiti: ack
09:05 < amiti> sipa: great! thanks :)
09:07 -!- csknk [~csknk@unaffiliated/csknk] has joined #bitcoin-core-pr-reviews     
09:10 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
09:15 -!- seven [~seven@2a00:ee2:410c:1300:f868:4110:634b:6ae6] has joined #bitcoin-core-pr-reviews     
09:16 -!- csknk [~csknk@unaffiliated/csknk] has quit [Quit: leaving]     
09:19 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews     
09:33 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has joined #bitcoin-core-pr-reviews     
09:45 -!- overall [~overall@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews     
09:49 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]     
09:56 -!- salvatoshi [~salvatosh@2001:b07:644b:1d18:6c5a:2f01:8465:b542] has joined #bitcoin-core-pr-reviews     
09:57 -!- figs [592e721e@89.46.114.30] has joined #bitcoin-core-pr-reviews     
09:58 -!- benthecarman [~ben@185.204.1.206] has joined #bitcoin-core-pr-reviews     
09:59 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews     
10:00 < amiti> #startmeeting
10:00 < amiti> hi     
10:00 < nehan> hi     
10:00 < benthecarman> hi     
10:00 < troygiorshev> hi     
10:00 < willcl_ark> hi     
10:00 < andrewtoth> hi     
10:00 < michaelfolkson> hi     
10:00 < jnewbery> hi     
10:00 < amiti> hi everyone! welcome to this weeks review club. today, we'll chat about transaction privacy on the network
10:01 < overall> hi     
10:01 < amiti> notes and questions in the normal place: https://bitcoincore.reviews/19109.html
10:01 < amiti> who has gotten a chance to look at the proposed changes?
10:01 < amiti> (y/n)
10:01 < jnewbery> y     
10:02 < michaelfolkson> y     
10:02 -!- felixweis_k [4f8c7225@gateway/web/cgi-irc/kiwiirc.com/ip.79.140.114.37] has joined #bitcoin-core-pr-reviews     
10:02 < troygiorshev> y     
10:02 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews     
10:02 < nehan> y     
10:02 < willcl_ark> n (sorry!)
10:02 < benthecarman> y     
10:03 < amiti> cool! let's get started with the questions
10:03 < amiti> What are possible techniques for an adversary to probe a node for a particular mempool transaction? What changes with this PR?
10:04 -!- a__jonas [185c3307@cpe-24-92-51-7.nycap.res.rr.com] has joined #bitcoin-core-pr-reviews     
10:04 < andrewtoth> is sending a GETDATA the only real way?
10:04 < michaelfolkson> So this is Gleb's comment. Attacker connects to us right after we put the transaction in MapRelay
10:05 < amiti> andrewtoth: the only real way to solicit a TX response?
10:05 < andrewtoth> to try and probe a node for a particular mempool transaction?
10:05 < felixweis_k> you could give it a transaction that spends a certain input
10:06 < andrewtoth> ahh felixweis_k interesting
10:06 < felixweis_k> if it requests the input tx, it didn't have it
10:06 < amiti> michaelfolkson: yes, could you break that down further? we could also go into this more in the next question
10:07 < amiti> felixweis_k: yeah! using children to observe request patterns can help a spy deduce tx presence
10:07 < michaelfolkson> So my (limited) understanding is that the previous PR fixed a lot of the premature announcement logic. And so now we are working out what still needs to be fixed
10:08 < michaelfolkson> #18861 (previous PR, now merged)
10:08 < amiti> alright, lets jump into the next question and discuss the previous PR (18861) and how this PR (19109) addresses a leak
10:08 < amiti> from the notes: PR 18861 improved transaction-origin privacy. The idea is that if we haven’t yet announced a transaction to a peer, we shouldn’t fulfill any GETDATA requests for that transaction from that peer. The implementation for that PR checks the list of transactions we are about to announce to the peer (setInventoryTxToSend), and if it
10:08 < amiti> finds the transaction that the peer has requested, then responds with a NOTFOUND instead of with the transaction. While this helps in many cases, it is an imperfect heuristic.
10:08 < amiti> What were drawbacks of using setInventoryTxToSend as a heuristic?
10:08 < michaelfolkson> Sorry I think I misunderstood the first question :)
10:09 < overall> michaelfolkson premature or non-privacy preserving announcement  logic?
10:09 < amiti> michaelfolkson: nah, the two questions overlap.
10:09 -!- Davterra [~tralfaz@104.200.129.62] has quit [Quit: Leaving]     
10:10 < jnewbery> sipa's original PR description answers this question...
10:11 < michaelfolkson> overall: Premature is non-privacy preserving. I don't understand distinction...
10:12 < jnewbery> so setInventoryTxToSend is a set of transactions that we haven't yet announced to that peer
10:12 < troygiorshev> The issue in sipa's original PR description is a "false negative" sort of problem, right?  i.e. we'll tell a node that we don't have a transaction even when they know that we actually do?
10:12 < amiti> troygiorshev: that's one of the issues, pointed out in the convo with luke-jr & sipa
10:12 < amiti> here: https://github.com/bitcoin/bitcoin/pull/18861#discussion_r419695831
10:12 < overall> michaelfolkson just checking if there was another metric, besides privacy, that wasn't needed to be managed
10:13 < amiti> but from my understanding, it seems pretty unlikely
10:13 < jnewbery> we'll only add txids to a peer's setInventoryTxToSend if we're connected to that peer when we relay the transaction
10:13 < sipa> overall: well, memory usage - we could also just keep a list of all things we've ever announced to a peer, and only allow them to query exactly that... but that would easily run into memory problems
10:14 < jnewbery> so using the old heuristic, if a node connects to us and immediately asks for a transaction, it won't be in the setInventoryTxToSend, and we'll happily send the transaction
10:14 < michaelfolkson> overall: Yeah I think it is just privacy. Apart from privacy, announcing prematurely doesn't matter. Unless you literally don't want to be announcing it at all (not a concern)
10:15 < amiti> jnewbery: exactly. does this make sense to people?
10:15 < andrewtoth> jnewbery: makes sense thanks!
10:15 < sipa> michaelfolkson: it's not announcing; it is allowing requests
10:15 < troygiorshev> jnewbery amiti: it does now :)
10:15 < sipa> michaelfolkson: this is about not permitting requests of things that weren't announced
10:16 < sipa> announcement itself has a bunch of privacy protections already, since a few years ago, and they're pretty good
10:16 < sipa> this is making sure that it can't be bypassed by tx requests
10:17 < andrewtoth> still a little unclear on the second point though. how does using setInventoryTxToSend prevent some locally resubmitted invs from being requested?
10:19 < amiti> andrewtoth: the idea is if we are using setInventoryTxToSend to prevent fulfilling a txn request, if we put a txn on there for a _second_ time, then it would be valid for the peer to request (since we prev announced), but we would deny them the txn
10:19 < michaelfolkson> sipa: Not permitting the providing of what they request right? They are free to request whatever they want. Just don't want to give it to them
10:19 < andrewtoth> amiti: thanks!
10:19 < sipa> michaelfolkson: exactly
10:20 < sipa> andrewtoth: it's a pretty contrived scenario, see https://github.com/bitcoin/bitcoin/pull/18861#discussion_r419707909
10:20 < felixweis_k> whats a mental model to aproximate what consitutes an acceptable amount of per peer memory?
10:21 < luke-jr> amiti: it seems like it could result in efforts to relay a tx, making it harder to relay
10:21 < amiti> sipa: my understanding of your comment there was that you were identifying the precise steps / timing that would have to happen to not serve the txn, is that correct?
10:21 < amiti> (aka not as simple as resubmit via sendrawtransaction)
10:22 < sipa> amiti: yeah, because it also requires the old submission to have been expired from filterAlreadyKnown
10:22 < amiti> luke-jr: I don't follow
10:22 -!- csknk [~csknk@unaffiliated/csknk] has joined #bitcoin-core-pr-reviews     
10:22 < andrewtoth> sipa: thanks. both these cases seem pretty unlikely, right? but probably better to not have any edge cases
10:22 < sipa> andrewtoth: probability is the wrong metric when thinking about attacks
10:23 < sipa> andrewtoth: the question is how costly it is for an attacker to make it happen - they won't let it to chance
10:23 < jnewbery> felixweiss_k: that's a really good question! I don't know if there are any hard numbers
10:23 < luke-jr> amiti: unless I'm confusing my own comment (it's been a while), it seems sendrawtransaction (ie, the user explicitly wants to relay it) could end with it not being relayed even if it would have otherwise been?
10:23 < andrewtoth> interesting
10:23 < amiti> sipa: 👍🏽, and you were calculating the most feasible / quick way to expire (using mempool requests)
10:24 < amiti> luke-jr: so, you're talking about your comment here- https://github.com/bitcoin/bitcoin/pull/18861#discussion_r419695831?
10:24 < sipa> andrewtoth: an analogy i like: a civilian engineer designs building resistant to natural causes (earthquakes, ...), and needs probability. a military engineer designs structures that are designed to protect against attacks; they don't go compute the probability that a missile will randomly hit it; they care about how hard it is for an attack that make that happen
10:25 < amiti> ok, so these are some of the identified drawbacks of using `setInventoryTxToSend` as a heuristic. what does PR 19109 implement as an alternative solution?
10:25 < andrewtoth> sipa: :)
10:25 < michaelfolkson> But probability still informs what should be prioritized to fix!
10:25 < sipa> michaelfolkson: how so?
10:26 < sipa> we care about probabilities of things _randomly_ going wrong absent attack scenarios of course
10:26 < michaelfolkson> Well if there are two possible attacks and one attack is more likely than the other, fix that one first
10:26 < sipa> michaelfolkson: no, you fix the cheapest to perform first
10:26 < sipa> attacks are not random
10:27 < michaelfolkson> I guess I am seeing the cost of the attack as informing how likely that attack is to happen
10:27 < amiti> felixweis_k: good question about acceptable amount of memory / peer, something I also wonder
10:27 < luke-jr> andrewtoth: if an attack is possible, it increases the possibility
10:28 -!- benthecarman [~ben@185.204.1.206] has quit [Quit: Leaving]     
10:28 < sipa> at a very level view, you could see it that way
10:28 < sipa> but it's misleading imo
10:29 < andrewtoth> makes sense
10:29 < troygiorshev> sipa: we would want to prioritize on the "product" of the "ease" of the attack and the "damage" of the attack, no?
10:29 < jnewbery> felixweiss_k: without having specific numbers, I think a good rule is that keeping sets of items per-peer isn't scalable, but keeping a probabilistic filter is
10:30 < sipa> i think we'd like to have some sort of upper bound of memory usage per peer
10:30 < jnewbery> and in many cases, a probabilistic filter is good enough for the specific function
10:30 < sipa> or, alternatively, actual acconting of memory, and a way to deprioritize/disconnect peer if we're using to much memory on behalf of a peer, and it gets tight
10:31 < jnewbery> sipa: I think deprioritizing based on memory usage would be difficult. How do you shed the memory? Deprioriritizing based on CPU/bandwidth usage seems much easier
10:32 < sipa> jnewbery: agree
10:32 < amiti> lets jump into this question: What are some relevant considerations when reviewing/implementing a bloom filter? What choices does this patch make?
10:32 < amiti> since we are talking about one of the considerations- memory usage
10:32 < jnewbery> (not saying they're exclusive - just that the latter is much more straightforward)
10:34 < a__jonas> amiti: Generally things you'd want to consider are the are number of items to keep track of and the acceptable false-positive rate
10:34 < amiti> a__jonas: yes!
10:35 < amiti> did you catch what values were chosen in this PR ?
10:35 < jnewbery> how are those parameters chosen?
10:35 < a__jonas> (3500 and 0.000001)
10:35 < troygiorshev> amiti: False positive rate is 0.000001
10:36 < amiti> a__jonas, troygiorshev: yup!
10:36 < andrewtoth> so number of items increases memory, false positive rate increases CPU time?
10:36 < amiti> let's dig into jnewbery's question- how were these numbers chosen? so as reviewers, we can evaluate that it makes sense
10:37 < sipa> andrewtoth: better false positive rate also increases memory usage
10:37 -!- csknk [~csknk@unaffiliated/csknk] has quit [Quit: leaving]     
10:37 < sipa> a rolling bloom filter has around -log2(fprate)*3/log(2) bits usage per tracked item
10:39 < jnewbery> 'rolling bloom filter' is perhaps a bit of a misleading name because you might expect that you can remove items
10:39 < amiti> if anyone is interested, I found this site useful to wrap my head around how bloom filters work: https://llimllib.github.io/bloomfilter-tutorial/
10:39 < jnewbery> in fact, it's implemented as 3 separate bloom filters, each with capacity 1/2 of the desired capacity
10:39 < andrewtoth> amiti: cool site!
10:40 < amiti> (props to aj for sharing with me)
10:40 < felixweis_k> thanks, amiti!
10:40 < sipa> jnewbery: in general you can't delete things from bloom filters
10:40 < sipa> there are generalizations that can, but they need more memory
10:40 < jnewbery> and we roll through the different filters (ie put items into the first filter until it's at capacity, then the second, then the third, then delete the first filter and start filling it again)
10:40 < felixweis_k> yeah rolling bloom filters are cool i've been thinking recently about something like that. didn't know we had them in core
10:40 < sipa> jnewbery: exactly
10:41 < jnewbery> so that's where the *3 in sipa's memory usage comes from
10:41 < jnewbery> because we actually have 3 bloom filters
10:41 < jnewbery> (I think)
10:41 < sipa> correct
10:41 < sipa> though it's not the entire picture
10:42 < amiti> jnewbery: oh cool, I was wondering how it worked but didn't get the chance to dig in yet. thanks!
10:42 < sipa> we also get a factor 2 gain from having 2 active generations (each of the 3 generations is only half the window size)
10:42 < felixweis_k> when you add, you add to the latest 2, when you check you check for OR in any of the 3? then a counter as to when advance the "ring buffer"?
10:42 < sipa> but also a factor 2 again because we need 2 bits per entry (which can store a number from 0 to 3... 0 for unused; 1-3 for each of the 3 generations)
10:42 < felixweis_k> sorry im just going to read the code
10:43 < jnewbery> felixweiss_k: you only add to the latest generation I believe. And yes, there's a counter to determine which generation we should be adding to
10:43 < michaelfolkson> What is AJ doing re running the patch to find premature requests?
10:44 < michaelfolkson> This is to explore when premature requests still happen when someone is running Core and is not malicious?
10:44 < jnewbery> felixweis_k: oops, I've been inserting and extra s in your name!
10:45 < sipa> michaelfolkson: indeed
10:45 < sipa> to see if our logic isn't too strict in what it permits
10:46 < amiti> 15 minutes left
10:46 < michaelfolkson> You want to allow a certain number of premature requests?! Don't get it
10:46 < sipa> michaelfolkson: no?
10:46 < michaelfolkson> Surely better if there are zero premature requests unless doing testing
10:46 < sipa> michaelfolkson: yes
10:47 < sipa> i'm confused by your conclusion :)
10:47 < felixweis_k> no worries, i've written new berry probably too in the past ;-)
10:47 < michaelfolkson> The "logic isn't too strict" comment. Surely we want extreme strictness in this case (unless doing testing)
10:47 < sipa> michaelfolkson: but it's an approximation
10:48 < troygiorshev> michaelfolkson: we're seeing false positives, right?
10:48 < sipa> we don't know exactly what all legitimate (and safe) behaviors are
10:48 < sipa> so we want to know if this policy we have implemented isn't going to accidentally affect legitimate use
10:49 < sipa> because we might have forgotten some protocol interaction where someone ends up legitimately requesting something that the filter approach disallows
10:49 < sipa> aj's testing is to figure this by running it in the wild, and seeing if there are legitimately-looking requests that get blocked by it
10:49 < jnewbery> I have a question on my new favorite subject in Bitcoin Core (locking), inspired by neha's question in the previous PR: https://github.com/bitcoin/bitcoin/pull/18861#discussion_r451666992
10:50 < michaelfolkson> Ok makes sense, thanks. So some premature requests are legitimate. e.g. the example AJ found.
10:50 < sipa> michaelfolkson: well, they're not premature - we're just accidentally marking them as such
10:50 < jnewbery> is this new data structure threadsafe? If so, what synchronization method is used to guard it? Do you think it's in the right place?
10:51 < a__jonas> to answer your question amiti, I think these numbers could be adjusted (as AJ maths and Sipa's response suggests)
10:52 < overall> jnewbery nice question :)
10:52 < a__jonas> It looks like caching was a consideration (as noted in the comment on the assert on line 134)
10:52 < andrewtoth> jnewbery: looks like it's protected by cs_main
10:52 < jnewbery> overall: credit goes to neha for asking in the previous PR :)
10:53 < jnewbery> andrewtoth: yes, can you explain why/
10:53 < overall> nehan +1
10:53 < sipa> a__jonas: i don't think i've commented at all on those numbers or how they could be changed
10:54 < andrewtoth> i need to look closer at the code here :/
10:55 < amiti> a__jonas: are you talking about the convo early on in the PR?
10:55 < troygiorshev> sipa: a__jonas: this? https://github.com/bitcoin/bitcoin/pull/19109#issuecomment-636712875
10:55 < nehan> jnewbery: +1. Also, I don't see how cs_vRecv is taken out properly in the previous PR, but maybe that could be answered more quickly here.
10:55 < amiti> ah, I think that convo lead to introducing `UNCONDITIONAL_RELAY_DELAY`
10:55 < sipa> or maybe i'm just wrong! and clang didn't detect it
10:56 < amiti> lets chat about it in the last few minutes here... How is this delay constant being used when deciding whether or not to fulfill a request?
10:56 < jnewbery> andrewtoth: the answer is that it m_recently_announced_invs is added to CNode, which is guarded by cs_main.
10:56 < sipa> nehan: i believe i'm wrong!
10:56 < nehan> sipa: where does net lock cs_vRecv?
10:56 < nehan> sipa: yeah ok good i'm not going crazy :)
10:56 < a__jonas> troygiorshev, yes - that and AJ's previous comment
10:56 -!- salvatoshi [~salvatosh@2001:b07:644b:1d18:6c5a:2f01:8465:b542] has quit [Quit: Leaving]     
10:56 < jnewbery> sipa: wrong about what?
10:56 < sipa> jnewbery: about claiming that net grabs cs_vRecv
10:57 < nehan> jnewbery: vRecvGetData isn't protected by cs_vRecv. But as you both pointed out it's only accessed in one thread. That seems worth documenting to me though.
10:57 < overall> 3 minutes remaining
10:58 < sipa> same with orphan_work_set
10:58 < jnewbery> nehan: definitely document it at the very least
10:58 < sipa> agree
10:58 < nehan> ok     
10:58 < sipa> or fix it
10:59 < jnewbery> vRecvGetData and orphan_work_set are similar - they're both work queues for an individual peer. As such they're only pushed to/popped from in ProcessMessages
10:59 < nehan> sipa: ok!
10:59 < amiti> a__jonas, troygiorshev: that conversation calculated the number of transactions in 15 minutes, because after 15 minutes is the time set by mapRelay. after that review, sipa introduced `UNCONDITIONAL_RELAY_DELAY` as 2 mins. so now, if a peer requests a txn thats >2 minutes old, we will serve
10:59 < jnewbery> but agree it should be fixed!
10:59 < sipa> net_processing.cpp:1653:43: warning: reading variable 'vRecvGetData' requires holding mutex 'pfrom.cs_vRecv' [-Wthread-safety-analysis] std::deque<CInv>::iterator it = pfrom.vRecvGetData.begin();
11:00 < sipa> i recompiled and just missed the warning, silly me
11:00 < amiti> but if the txn is < 2 minutes old, it must be in the `m_recently_announced_invs` filter
11:00 < amiti> okay! it looks like thats time
11:00 < sipa> and the filter is sized such that it can store as many transactions as we can possibly announce in 2 minutes
11:01 < amiti> thanks for coming all :)
11:01 < troygiorshev> thanks amiti!
11:01 < felixweis_k> thanks all, and amiti for hosting! very informative as always.
11:01 < sipa> thanks!
11:01 < andrewtoth> thanks amiti! and everyone else for the discussion
11:01 < overall> thanks amiti!
11:01 < nehan> thanks amiti!
11:01 < jnewbery> thanks amiti. Great discussion!
11:02 < a__jonas> Thanks amiti
11:02 < amiti> #endmeeting
11:02 < michaelfolkson> Thanks amiti! New IRC nick?
11:03 < sipa> jnewbery: so, you're right - the memory usage of the rolling bloom filter (which i'll completely unambiguously abbreviate to RBF) is indeed exactly equal to having 3 completely separate bloom filters
11:03 < sipa> and even operationally it's very similar to that
11:03 < amiti> hah, my normal irc client is down (I use irccloud) , hopefully it will be back soon
11:03 < felixweis_k> using irccloud too usually. lol
11:04 < troygiorshev> sipa: unambiguously :D
11:04  * sipa suggests ssh + vps + screen + irssi :)
11:04 < felixweis_k> maybe someone should create a decentralized IRC client
11:04 < overall> lol     
11:04 < felixweis_k> (im kidding)
11:04 < sipa> jnewbery: the difference is that you'd need to access 3x as many memory locations
11:04 < overall> on a time chain
11:05 < jnewbery> sipa: so a 3x constant factor in checking for membership
11:05 < overall> sipa and connect irssi to freenet over tor? the sasl registration over clearnet bugs me :(
11:06 < sipa> overall: indeed
11:06 < a__jonas> thanks sipa
11:06 -!- a__jonas [185c3307@cpe-24-92-51-7.nycap.res.rr.com] has quit [Remote host closed the connection]     
11:06 -!- felixweis_k [4f8c7225@gateway/web/cgi-irc/kiwiirc.com/ip.79.140.114.37] has quit [Quit: Connection closed]     
11:07 < overall> I understand that abuse / rate limiting demands that require sasl but still wish there was another way to handle it (surety bond)
11:07 < sipa> jnewbery: with a rolling cuckoo filter you only need 28ish bits per elememt (at 20 bits fprate), instead of 86ish
11:08 < jnewbery> if anyone wants to dig deeper on probabilistic filters, sipa left this rather tantalizing comment about _cuckoo_ filters on a different PR: https://github.com/bitcoin/bitcoin/pull/19219#issuecomment-652685715
11:08 < jnewbery> paper here: https://www.cs.cmu.edu/~dga/papers/cuckoo-conext2014.pdf
11:09 < troygiorshev> jnewbery: thx
11:09 < sipa> happy to do a review session about it, if/when it's done :)
11:09 < jnewbery> sipa: that'd be great!
11:09 < amiti> sipa: +1
11:12 -!- figs [592e721e@89.46.114.30] has quit [Remote host closed the connection]     
11:14 -!- amiti [6bd29f36@107-210-159-54.lightspeed.sntcca.sbcglobal.net] has quit [Remote host closed the connection]     
11:15 < jnewbery> sipa: I haven't looked at the implementation recently, but do the 3 bloom filters use the same hash functions? If so, my comment ("3x constant factor in checking for membership") isn't correct because you'd only do the hashing once
11:15 < sipa> jnewbery: they dk
11:15 < sipa> they do
11:16 < jnewbery> ok, so checking 3x memory locations but that doesn't equate to 3x lookup times
11:16 < sipa> right; number of hashes would be identical across them
11:17 < sipa> in practice i expect the filter data to not be hot in the cache, so memory accesses dominate
11:17 < sipa> (which is annoyingly hard to measure in microbenchmarks)
11:29 < jnewbery> meeting log is posted: https://bitcoincore.reviews/19109.html
11:32 -!- x1289 [6dc173a4@HSI-KBW-109-193-115-164.hsi7.kabel-badenwuerttemberg.de] has joined #bitcoin-core-pr-reviews     
11:32 -!- x1289 [6dc173a4@HSI-KBW-109-193-115-164.hsi7.kabel-badenwuerttemberg.de] has quit [Remote host closed the connection]     
11:35 -!- overall [~overall@195.181.160.175.adsl.inet-telecom.org] has quit [Ping timeout: 272 seconds]     
11:51 -!- MasterdonX [~masterdon@185.246.211.104] has quit [Quit: ZNC 1.7.5 - https://znc.in]     
11:51 -!- MasterdonX [~masterdon@185.246.211.104] has joined #bitcoin-core-pr-reviews     
12:04 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!]     
12:19 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-xbyekbisruhrxfzl] has joined #bitcoin-core-pr-reviews     
12:28 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
12:29 -!- RubenSomsen [sid301948@gateway/web/irccloud.com/x-siipwwkhxjcfolyk] has joined #bitcoin-core-pr-reviews     
12:31 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]     
12:31 -!- GoldmanSats [sid428607@gateway/web/irccloud.com/x-uewlrukodyfemgkq] has joined #bitcoin-core-pr-reviews     
12:32 -!- wallet42_ [sid154231@gateway/web/irccloud.com/x-sljhsvrgirujqlul] has joined #bitcoin-core-pr-reviews     
12:37 -!- felixweis [sid154231@gateway/web/irccloud.com/x-rwtspefaioxloplv] has joined #bitcoin-core-pr-reviews     
12:42 -!- hugohn [sid304114@gateway/web/irccloud.com/x-ybcpgnhejhwlosqh] has joined #bitcoin-core-pr-reviews     
12:44 -!- jkczyz [sid419941@gateway/web/irccloud.com/x-zovdjflzyiyrwvds] has joined #bitcoin-core-pr-reviews     
12:47 -!- ajonas [sid385278@gateway/web/irccloud.com/x-eggekqzoqpimvolz] has joined #bitcoin-core-pr-reviews     
12:49 -!- pierre_rochard [sid299882@gateway/web/irccloud.com/x-ogxyowsqnwpethyv] has joined #bitcoin-core-pr-reviews     
12:51 -!- drbrule [sid395654@gateway/web/irccloud.com/x-himkbrxcyzglcihv] has joined #bitcoin-core-pr-reviews     
12:52 -!- ethzero [sid396973@gateway/web/irccloud.com/x-reeslejphuosofvj] has joined #bitcoin-core-pr-reviews     
12:54 -!- peltre [sid268329@gateway/web/irccloud.com/x-ycsrlsshjhabxbnv] has joined #bitcoin-core-pr-reviews     
12:55 -!- fanquake [sid369002@gateway/web/irccloud.com/x-olctokxewerkqszl] has joined #bitcoin-core-pr-reviews     
12:55 -!- Aleru [sid403553@gateway/web/irccloud.com/x-bzlawewlmjbhxtqv] has joined #bitcoin-core-pr-reviews     
12:56 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-jbulpdnugspyzpyb] has joined #bitcoin-core-pr-reviews     
12:57 -!- schmidty [sid297174@gateway/web/irccloud.com/x-ckqifnzpczeptffn] has joined #bitcoin-core-pr-reviews     
13:00 -!- moneyball [sid299869@gateway/web/irccloud.com/x-whutuxnrmoxirczs] has joined #bitcoin-core-pr-reviews     
13:00 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-eodttputhgzwdsdn] has joined #bitcoin-core-pr-reviews     
13:02 -!- dburkett [sid411344@gateway/web/irccloud.com/x-zbaaeyoitclfskum] has joined #bitcoin-core-pr-reviews     
13:03 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-xbyekbisruhrxfzl] has quit []     
13:04 -!- hebasto [sid449604@gateway/web/irccloud.com/x-ppwcubvoagzjjmyc] has joined #bitcoin-core-pr-reviews     
13:07 -!- petezz4_ [sid2429@gateway/web/irccloud.com/x-qvayemaqolmsdbvd] has joined #bitcoin-core-pr-reviews     
13:14 -!- digi_james [sid281632@gateway/web/irccloud.com/x-acapbubtjyrfcjrf] has joined #bitcoin-core-pr-reviews     
13:15 -!- corollari [sid405633@gateway/web/irccloud.com/x-vcjdzklbopcytrtc] has joined #bitcoin-core-pr-reviews     
13:21 -!- amiti [sid373138@gateway/web/irccloud.com/x-ufqeiiiqpjmxxnfp] has joined #bitcoin-core-pr-reviews     
13:25 -!- gzhao408_ [uid453516@gateway/web/irccloud.com/x-jetyhkmssezoadob] has joined #bitcoin-core-pr-reviews     
13:26 -!- jamesob [sid180710@gateway/web/irccloud.com/x-msxrcsfqcftqvufi] has joined #bitcoin-core-pr-reviews     
13:28 -!- fjahr [sid374480@gateway/web/irccloud.com/x-uivuzkqvxqkxtfmn] has joined #bitcoin-core-pr-reviews     
13:51 -!- slivera [~slivera@103.231.88.26] has joined #bitcoin-core-pr-reviews     
13:53 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has joined #bitcoin-core-pr-reviews     
14:32 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has quit [Quit: ERC (IRC client for Emacs 26.3)]     
14:43 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has quit [Quit: Leaving]     
14:59 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has joined #bitcoin-core-pr-reviews     
14:59 -!- dfmbbtc [~dfmb_@unaffiliated/dfmb/x-4009105] has joined #bitcoin-core-pr-reviews     
15:49 -!- molz_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
15:52 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 264 seconds]     
16:11 -!- dfmbbtc [~dfmb_@unaffiliated/dfmb/x-4009105] has quit [Quit: Leaving]     
16:11 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has quit [Quit: Leaving]     
16:42 -!- seven [~seven@2a00:ee2:410c:1300:f868:4110:634b:6ae6] has quit [Remote host closed the connection]     
16:43 -!- seven [~seven@2a00:ee2:410c:1300:f868:4110:634b:6ae6] has joined #bitcoin-core-pr-reviews     
16:54 -!- Davterra [~tralfaz@104.200.129.62] has joined #bitcoin-core-pr-reviews     
17:13 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Ping timeout: 256 seconds]     
17:14 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews     
18:04 -!- seven [~seven@2a00:ee2:410c:1300:f868:4110:634b:6ae6] has quit [Ping timeout: 272 seconds]     
20:22 -!- dr-orlovsky [~dr-orlovs@xdsl-188-154-184-23.adslplus.ch] has quit [Read error: Connection reset by peer]     
20:23 -!- dr_orlovsky [~dr-orlovs@xdsl-188-154-184-23.adslplus.ch] has joined #bitcoin-core-pr-reviews     
20:30 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
20:33 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]     
20:33 -!- vasild_ is now known as vasild     
21:28 -!- vindard [~vindard@190.83.165.233] has quit [Quit: No Ping reply in 180 seconds.]     
21:28 -!- vindard [~vindard@190.83.165.233] has joined #bitcoin-core-pr-reviews     
21:40 < jonatack> great questions, nehan!
21:40 < jonatack> over time, the same issues just keep coming up in review
21:41 < jonatack> UB, locks and data races, memory efficiency, cost of attacks...
21:42 < jonatack> (in addition to DoSing and privacy leaks)
21:42 < jonatack> just added a post-it on my monitor as a reminder to keep these things foremost in mind while reviewing
21:44 < jonatack> we did a review club last December about UB (Undefined Behavior): https://bitcoincore.reviews/17639
21:44 < jonatack> i think a review club about locks and data races could be a good resource too!
22:00 -!- slivera [~slivera@103.231.88.26] has quit [Remote host closed the connection]     
22:06 -!- gleb [~gleb@159.224.16.138] has joined #bitcoin-core-pr-reviews     
22:25 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack]     
22:35 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews     
23:55 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-jbulpdnugspyzpyb] has quit [Ping timeout: 246 seconds]     
23:55 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-xakextsjllqfoobo] has joined #bitcoin-core-pr-reviews     
23:55 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-eodttputhgzwdsdn] has quit [Ping timeout: 244 seconds]     
23:56 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-idnbndmrmcjvfrnz] has joined #bitcoin-core-pr-reviews