--- 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::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