--- Day changed Wed Feb 24 2021
00:05 -!- jadi [~jadi@185.197.71.29] has joined #bitcoin-core-pr-reviews     
00:43 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection]     
00:43 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
01:12 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has joined #bitcoin-core-pr-reviews     
01:45 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]     
01:46 -!- Bridgette75Wiza [~Bridgette@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
01:49 -!- Bridgette75Wiza [~Bridgette@static.57.1.216.95.clients.your-server.de] has quit [Remote host closed the connection]     
01:56 -!- Marc31Lueilwitz [~Marc31Lue@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
01:58 -!- Marc31Lueilwitz [~Marc31Lue@static.57.1.216.95.clients.your-server.de] has quit [Read error: Connection reset by peer]     
01:59 -!- Waino78Murazik [~Waino78Mu@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
02:03 -!- Waino78Murazik [~Waino78Mu@static.57.1.216.95.clients.your-server.de] has quit [Read error: Connection reset by peer]     
02:05 -!- Dion1Von [~Dion1Von@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
02:10 -!- Dion1Von [~Dion1Von@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 256 seconds]     
02:12 -!- da39a3ee5e6b4b0d [~da39a3ee5@184.22.159.161] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
02:16 -!- Reina39Stehr [~Reina39St@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
02:21 -!- Reina39Stehr [~Reina39St@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 240 seconds]     
02:26 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:c8ae:2c0d:ad79:de13:e3a6] has joined #bitcoin-core-pr-reviews     
02:33 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:c8ae:2c0d:ad79:de13:e3a6] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
02:41 -!- reallll [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews     
02:43 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds]     
03:18 -!- jadi [~jadi@185.197.71.29] has quit [Read error: Connection reset by peer]     
03:20 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Disconnected by services]     
03:20 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
03:20 -!- vasild_ is now known as vasild     
03:20 -!- Giovanna69Reinge [~Giovanna6@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
03:31 -!- Giovanna69Reinge [~Giovanna6@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 240 seconds]     
03:39 -!- jadi [~jadi@185.197.71.29] has joined #bitcoin-core-pr-reviews     
04:05 -!- virtu [~virtu@gateway/tor-sasl/virtu] has quit [Remote host closed the connection]     
04:06 -!- virtu [~virtu@gateway/tor-sasl/virtu] has joined #bitcoin-core-pr-reviews     
04:29 -!- eoin [5d6bd2bc@93.107.210.188] has joined #bitcoin-core-pr-reviews     
04:34 -!- aferreira44 [~andre@2001:1284:f013:e991:e5ae:4270:cdb:4daa] has joined #bitcoin-core-pr-reviews     
04:46 -!- shesek` [~shesek@164.90.217.137] has joined #bitcoin-core-pr-reviews     
04:47 -!- reallll is now known as belcher     
05:13 -!- jonatack_ [~jon@37.169.20.238] has joined #bitcoin-core-pr-reviews     
05:14 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:c8ae:2c0d:ad79:de13:e3a6] has joined #bitcoin-core-pr-reviews     
05:25 -!- jonatack_ [~jon@37.169.20.238] has quit [Quit: jonatack_]     
05:28 -!- jonatack [~jon@37.169.20.238] has joined #bitcoin-core-pr-reviews     
05:35 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]     
05:38 -!- eoin [5d6bd2bc@93.107.210.188] has quit [Quit: Connection closed]     
05:39 -!- shesek` is now known as shesek     
05:39 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]     
05:39 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews     
06:03 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
06:09 -!- eoin [5d6bd2bc@93.107.210.188] has joined #bitcoin-core-pr-reviews     
06:36 -!- harrigan [~harrigan@ptr-93-89-242-202.ip.airwire.ie] has quit [Ping timeout: 246 seconds]     
06:41 -!- eoin [5d6bd2bc@93.107.210.188] has quit [Quit: Connection closed]     
06:42 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-pr-reviews     
06:45 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Remote host closed the connection]     
06:46 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-pr-reviews     
07:03 < pinheadmz> ping ?
07:22 -!- Alberta58Schmele [~Alberta58@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
07:22 -!- Alberta58Schmele [~Alberta58@static.57.1.216.95.clients.your-server.de] has quit [Remote host closed the connection]     
07:26 -!- jadi [~jadi@185.197.71.29] has quit [Ping timeout: 265 seconds]     
07:27 -!- jadi [~jadi@185.197.71.29] has joined #bitcoin-core-pr-reviews     
07:27 -!- Elvis85Kuphal [~Elvis85Ku@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
07:33 -!- Elvis85Kuphal [~Elvis85Ku@static.57.1.216.95.clients.your-server.de] has quit [Remote host closed the connection]     
07:34 -!- Cristian84Gutman [~Cristian8@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
07:42 -!- Cristian84Gutman [~Cristian8@static.57.1.216.95.clients.your-server.de] has quit [Read error: Connection reset by peer]     
07:43 -!- Eusebio68Kuhn [~Eusebio68@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
07:48 -!- Eusebio68Kuhn [~Eusebio68@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 265 seconds]     
07:57 < glozow> pinheadmz: pong?
07:57  * pinheadmz does the cabbage-patch
07:57 < pinheadmz> i have weird IRC issues seomtimes
07:58 < pinheadmz> nothing more awkward than asking great questions in review club and wondering why everyoens ignoring me
07:59 < glozow> indeed
08:09 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-pr-reviews     
08:10 -!- eoin [5d6bd2bc@93.107.210.188] has joined #bitcoin-core-pr-reviews     
08:23 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:c8ae:2c0d:ad79:de13:e3a6] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
08:28 -!- elle [~ellemouto@155.93.252.70] has joined #bitcoin-core-pr-reviews     
08:38 -!- ecola [~3cola@95.175.17.147] has joined #bitcoin-core-pr-reviews     
08:39 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 240 seconds]     
08:40 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-pr-reviews     
08:47 < jnewbery> we'll get started in 14 minutes. Time to put the kettle on
08:47 < elle> lekker :)
08:48 < pinheadmz> "adjective (S. African slang) delicious, tasty, luscious"
08:48 < pinheadmz> always learning in this channel ;-)
08:49 < elle> heheh!
08:49 < pinheadmz> one thing i find confusing in C++ is knowing where certain objects are imported from. For example in this PR its the boost multi-index thing
08:50 < pinheadmz> in javascript its clear: you require a module, and then always see that module name: module.object...
08:50 < pinheadmz> but in C++ you kinda have to know which .h file to lok through if you want to see how a class is implemented
08:58 -!- abstract [~abstract@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews     
08:58 -!- AnthonyRonning [0cee2182@12.238.33.130] has joined #bitcoin-core-pr-reviews     
08:59 -!- maqusat [d98ac166@217.138.193.102] has joined #bitcoin-core-pr-reviews     
09:00 -!- maqusat [d98ac166@217.138.193.102] has quit [Client Quit]     
09:00 -!- andozw [43057765@67-5-119-101.spok.qwest.net] has joined #bitcoin-core-pr-reviews     
09:00 < jnewbery> #startmeeting
09:00 -!- maqusat [d98ac166@217.138.193.102] has joined #bitcoin-core-pr-reviews     
09:00 < emzy> hi     
09:00 < kanzure> hi     
09:00 < pinheadmz> hi     
09:00 < dergoegge> hi     
09:00 < maqusat> hi     
09:00 < amiti> hi!     
09:00 < AnthonyRonning> hi     
09:00 < schmidty> hi     
09:00 < jnewbery> hi folks! It's Wednesday afternoon (at least where I am). You know what that means - another edition of Bitcoin Core PR Review Club.
09:00 < elle> hey hey!
09:00 < andozw> hiii
09:00 < jnewbery> Feel free to say hi to let everyone know you're here.
09:00 < ariard> hi     
09:00 < sdaftuar> hi     
09:00 < glozow> hi     
09:00 < jnewbery> If this is your first time, there are some tips here to help you get the most out of your time with us: https://bitcoincore.reviews/your-first-meeting
09:00 < michaelfolkson> hi     
09:00 < jnewbery> Anyone here for this first time?
09:00 -!- craigraw [9b5dfc46@155.93.252.70] has joined #bitcoin-core-pr-reviews     
09:00 < sunon> hi     
09:01 < abstract> hi     
09:01 < elle> no waaayyys hi craigraw !
09:01 < craigraw> Hi all
09:01 < jnewbery> welcome craigraw :)
09:01 -!- darius70 [52114c69@finc-22-b2-v4wan-160991-cust104.vm7.cable.virginm.net] has joined #bitcoin-core-pr-reviews     
09:01 < jnewbery> Notes and questions where you'd expect them: https://bitcoincore.reviews/21224
09:02 < jnewbery> This week, we're very lucky to have special guest host elle. It's going to be lekker 😎
09:02 < emzy> craigraw: small world :)
09:02 < jnewbery> over to you, elle
09:02 < elle> Thanks john! Hi everyone! Today we are looking at #21224: Halt processing of unrequested transactions. It was originally part of #20277 but has recently been split off to its own PR. The PR touches some interesting parts of the code that handles how we learn about new transactions. Let’s dive in!
09:02 < elle> Also, feel free to ask questions at any time. We are all here to support each other and learn. If you are confused about something, chances are that others are confused about it too and so asking your question will benefit everyone :) I’m also a newbie so please correct me if I misspeak.
09:02 < elle> Ok cool, lets get cracking!
09:02 < elle> 1. First of all, who has had a chance to review the PR? (y/n). No problem if you haven’t.
09:02 < amiti> y     
09:03 < pinheadmz> y     
09:03 < jnewbery> y     
09:03 < felixweis> hi     
09:03 < AnthonyRonning> conceptually yes, code no :)
09:03 < emzy> n     
09:03 < dergoegge> n     
09:03 < craigraw> n     
09:03 < elle> awesomeness! No problem if you havent. We are gonna get into it all now. Lets do this!
09:03 < schmidty> y     
09:04 < maqusat> conceptually yes and partially code
09:04 < elle> 2. What is the `TxRequestTracker` class in src/txrequest.h used for?
09:04 < pinheadmz> elle its a data sturcture that acts like a relational database to track transaction requests to peers
09:04 < dergoegge> managing tx downloads from peers
09:05 < jnewbery> pinheadmz: I'd say it's a class rather than a data structure
09:05 < pinheadmz> jnewbery  ty
09:05 < jnewbery> (distinction being that it also has member functions)
09:06 < pinheadmz> ah ok works for me
09:06 < elle> pinheadmz: dergoegge: indeed! it is used to keep track of the txs that our peers have notified us about and then we also use it to determine which peers we will request the txs from and when we will do so
09:06 < elle> what data does it hold? what is its most important member?
09:07 < jnewbery> introduced in PR 19988: https://github.com/bitcoin/bitcoin/pull/19988 🥰
09:07 < pinheadmz> most important member is the `Index` which is a multi-index um.... thing from boost
09:07 < pinheadmz> jnewbery is _that_ a data structure? or a class lol. i guess class ?
09:07 -!- ben2 [bd7a7e53@189.122.126.83] has joined #bitcoin-core-pr-reviews     
09:07 < sdaftuar> data structure seems appropriate for multi_index :)
09:08 < pinheadmz> sdaftuar 🙏
09:08 < elle> pinheadmz: yes indeed. And the index is pretty much a collection of announcements.
09:08 -!- Caralie [185a59be@cpe-24-90-89-190.nyc.res.rr.com] has joined #bitcoin-core-pr-reviews     
09:08 < elle> Where each announcement is what?
09:08 -!- effexzi [uid474242@gateway/web/irccloud.com/x-eprewwrxgtvpbdea] has joined #bitcoin-core-pr-reviews     
09:09 < glozow> stored and multi-indexed, so you know what to request from which peers, when
09:09 < pinheadmz> hm an Announcement is a struct
09:09 < pinheadmz> with a txid and a peer id
09:09 < glozow> and what to evict
09:09 < amiti> its stored as a struct and represents that a peer notified us about a txn, stored until we either get the txn or give up
09:09 < pinheadmz> and a state !
09:10 < elle> yebo yes! pretty much a peer/txhash combo + state
09:10 < elle> and yes pinheadmz that leads us nicely into the next question:
09:10 < elle> Im gonna break question 3 up into 2 parts cause it is chunky
09:11 -!- larryruane_ [uid473749@gateway/web/irccloud.com/x-upkfdqqafqqugupm] has joined #bitcoin-core-pr-reviews     
09:11 < elle> 3.1: First of all: `TxRequestTracker` manages our announcements using a state machine. What are the different states that an announcement can be in?
09:11 < pinheadmz> CANDIDATE_DELAYED, CANDIDATE_READY, CANDIDATE_BEST, REQUESTED, COMPLETED
09:11 < elle> Yebo!
09:11 < pinheadmz> yebo!
09:12 < pinheadmz> (more s african slang? :-P )
09:12 < elle> You can see the enum here: https://github.com/bitcoin/bitcoin/blob/b54a10e777f912081e5c00dabcf3643b10775a50/src/txrequest.cpp#L39
09:12 < sunon> Zulu for yes :)
09:12 < elle> haha yes sorry yebo is SA slang :) whoops, it is a habbit
09:12 < sunon> Ah I didn't see the other candidate states
09:12 -!- ivanacostarubio [~ivan@189.172.197.192] has joined #bitcoin-core-pr-reviews     
09:13 < elle> There is also a nice desciption of the 3 overall states here: https://github.com/bitcoin/bitcoin/blob/b54a10e777f912081e5c00dabcf3643b10775a50/src/txrequest.h#L106-L121
09:13 -!- jay67 [2f1f26c7@47.31.38.199] has joined #bitcoin-core-pr-reviews     
09:14 < elle> Does someone want to tell us what the 3 overall states mean?
09:14 < amiti> CANDIDATE* represents that a peer has announced the tx to us (sent us an INV)
09:14 < amiti> REQUESTED represents that we have sent a GETDATA for the tx
09:15 < amiti> and COMPLETED means we either got the txn, a NOTFOUND, or the response timed out
09:15 -!- craigraw [9b5dfc46@155.93.252.70] has quit [Quit: Connection closed]     
09:15 < elle> amiti: Nice one! perfect
09:15 < dergoegge> when are COMPLETED announcements deleted? i read that they are kept for while because we need them for deduplication
09:17 < elle> hmmm im not sure. Will have a look now. Does anyone else know?
09:17 -!- jay67 [2f1f26c7@47.31.38.199] has quit [Client Quit]     
09:17 < jnewbery> dergoegge: once we've received a transaction or the request state is COMPLETED for all peers (i.e. we don't have anyone else we can ask for the tx)
09:18 < michaelfolkson> This is all relatively new code ~ 5 months old. Easy to follow and comments are great
09:18 < dergoegge> jnewbery: i see ty
09:18 < elle> thanks jnewbery!
09:18 -!- craigraw [9b5dfc46@155.93.252.70] has joined #bitcoin-core-pr-reviews     
09:19 < elle> Cool so lets quickly go through where an announcement is shifter between the various states
09:19 < eoin> jnewbery: what is a pull request?
09:19 < jnewbery> elle: dit is 'n plesier
09:19 < pinheadmz> eoin a PR is a proposal to change the source code
09:20 < elle> First of all, where do we insert a new announcement? amiti gave us a hint earlier
09:20 < amiti> the code to actually shift the states all lays in the txrequest module, but the triggers are in net processing
09:20 < elle> amiti: indeed. Where in net_processing does the trigger for adding a new announcement happen?
09:21 < eoin> ty pinheadmz
09:21 < amiti> I think the main events that kick off state changes are when we ProcessMessage INV, TX, NOTFOUND or when we SendMessages GETDATA
09:21 < amiti> so, new announcement is ProcessMessage INV
09:21 < amiti> or if we are dealing with orphans there's also a code path in ProcessMessage TX to try to request the parent
09:21 -!- ngaldeman [5e0f2480@94.15.36.128] has joined #bitcoin-core-pr-reviews     
09:22 < glozow> what if we see tx in a block?
09:22 < elle> amiti: exactly. Which TxRequestMethod do we call to add the new announcement?
09:22 < abstract> eoin  if thenomenclature of pull rather than push is confusing, despite the request originating from someone who's changing something (hence a push), it's a request to the repository maintainer to "pull" in the code to the repo
09:23 < glozow> oh i just realized that was a dumb question oops
09:23 < glozow> nvm     
09:23 < pinheadmz> glozow i dont think thats dumb, im looking for an asnwer
09:23 < pinheadmz> it should delete tx requests once a tx is confirmed right?
09:24 < elle> pinheadmz: that is a good point... im guessing that maybe the `ForgetTxHash` might be called then? im not sure
09:24 < glozow> yeah definitely should, trying to find where the code path is
09:24 < amiti> glozow: are you asking about if we see a txn in a block for the first time?
09:24 < pinheadmz> amiti either / or
09:24 < amiti> or if we have a txn announcement / in flight and hten we see it in a block
09:24 < glozow> yeah if we got an inv, maybe sent a getdata, and then we see the actual tx itself in the context of a block
09:25 < amiti> gotcha
09:25 < jnewbery> glozow pinheadmz: it's a great question! Take a look here: https://github.com/bitcoin/bitcoin/blob/b54a10e777f912081e5c00dabcf3643b10775a50/src/net_processing.cpp#L1463-L1466
09:25 < pinheadmz> jnewbery great! so fast
09:25 < elle> ah! nice one
09:25 < glozow> ahhh `BlockConnected`
09:25 -!- Caralie [185a59be@cpe-24-90-89-190.nyc.res.rr.com] has quit [Quit: Connection closed]     
09:25 < jnewbery> if a tx is confirmed in a block, we don't need to request it anymore, so we delete it from TxRequest
09:25 < pinheadmz> ah BlockConnected -- same function that evicts confirmed tx from mempool
09:25 < glozow> yebo jnewbery! (am i using it right?)
09:25 < pinheadmz> yebo lekker yebo!
09:26 < jnewbery> glozow: bakgat!
09:26 < elle> wow guys, hahaha spreading the Afrikaans culture here
09:27 < elle> ok, lets continue. I think you all understand the state machine so lets move on to question 4
09:27 < elle> 4. What does the author claim the problem is with the current way in which transaction messages are handled?
09:27 < emzy> DoS / DDoS possibility by opening many connectionions to a node and send junk transactions that are expensive to validate but. I think after the PR we will be limited by the in-flight transactions?
09:27 < AnthonyRonning> Transactions could be relayed to a node without solicitation via INV. Results in additional CPU processing which could be abused.
09:28 < elle> emzy AnthonyRonning: yes exactly. Currently the INV/GETDATA sequence is not enforced
09:28 < dergoegge> the inv does not prevent DoS though right? inv(junk txs) -> getdata -> tx(junk txs) also works for an attacker
09:29 < elle> dergoegge: good point!
09:29 < pinheadmz> dergoegge not to mention... https://invdos.net/
09:29 < AnthonyRonning> dergoegge: that's my understanding too
09:29 < pinheadmz> inv messages have had their own issues
09:29 < ariard> dergoegge: when you're thinking about DoS, it's not a binary question, is a low-fee, expensive-to-validate tx a DoS in period of mempool congestion?
09:30 < jnewbery> pinheadmz: that particular issue was fixed several releases ago
09:30 < pinheadmz> jnewbery yah
09:30 < pinheadmz> jnewbery braydon and i were coworkers for 2 years, he wouldnt even tell me! just that he had a CVE #
09:31 < elle> 5. What is the change that this PR is making and how does it solve the problem mentioned in Q4?
09:31 < emzy> A node only processes TX messages that it requsted via GETDATA first.
09:31 < pinheadmz> elle  simply, when it receives a TX message it checks if it was ever requested and if not, drops the tx
09:32 < elle> emzy: pinheadmz: exactly
09:32 < pinheadmz> although i notice it does not ban the peer -- it would if the peer was conecnted as blocks_only however
09:32 < jnewbery> pinheadmz: I think "ever requested _from that peer_
09:32 < pinheadmz> jnewbery yes
09:33 < elle> pinheadmz: it cant ban the peer because up till now, the INV/GETDATA sequence has not been needed so some clients dont even bother with it
09:33 < pinheadmz> p.s. jnewbery so there is only one global TxRequestTracker right? and it gets added to each peer object upon instnatiation ?
09:33 < pinheadmz> elle ah right
09:34 < AnthonyRonning> elle: do you know what clients don't do that?
09:34 < jnewbery> there's only one TxRequestTracker object that gets instantiated when PeerManagerImpl is constructed
09:34 < elle> ah, jnewbery i think you know of a client that does that?
09:34 < glozow> does it solve the DoS problem? idk if it would stop an attacker that's sending us cpu-intensive transactions, they can still send plenty of invs and we'll ask for them. I like jnewbery's good highlight of aj's good point: "If what we want to do is rate-limit TX messages we receive from a peer IMO we should literally do that."
09:34 < felixweis> im not certain but maybe bitcoinj?
09:35 < jnewbery> it doesn't get added to the Peer objects. It just tracks individual announcements (and makes sure they're cleared up when a peer disconnect, for example)
09:35 < elle> glozow: yeah that is a great point
09:35 < jnewbery> yeah bitcoinj is one: https://github.com/bitcoinj/bitcoinj/blob/7d2d8d7792ec5f4ce07ff82980b4e723993221e8/core/src/main/java/org/bitcoinj/core/TransactionBroadcast.java#L145
09:35 < AnthonyRonning> jnewbery: ty
09:35 < sdaftuar> glozow: this PR woudl not solve any DoS problems at the moment (though it would achieve ariard's original goal of ignoring unrequested transactions during IBD)
09:36 < sdaftuar> jnewbery: thanks for sharing that (has anyone commented on the PR or mailing list to that effect?  i did not know)
09:36 < AnthonyRonning> "blast out the TX here for a couple of reasons. Firstly it's simpler" lol
09:36 < glozow> ignoring unrequested transactions during IBD does make sense to me - do we even have a mempool to add them to?
09:36 < felixweis> bitcoinj, after it sends a constructed transaction to a peer it does however check for INV messages for that hash on other peers to build confidence the wallet transaction has propagated trough the bitcoin network
09:36 < elle> why cant we just ignore all txs during IBD?
09:37 < ben2> Ho often a node receive unrequested txs ? Why would an honest node send unrequested tx ?
09:37 < ben2> * How
09:37 < sdaftuar> my (mild) objection to ariard's original proposal is that i think it complicates our logic to special-case things for IBD, especially when it makes sense that they shoudl hold true generally
09:37 < pinheadmz> glozow no mempool during IBD - how could we verify ?
09:37 < jnewbery> sdaftuar: harding shared that with me. I asked whether he thought it should be pointed out on the mailing list, but his understanding was that the author was already aware that clients were doing this
09:37 < ariard> glozow: yes but our utxo set might lead us to relay invalid transactions (their utxos has already been spent at tip), and feerate evaluation of such unrequested is really uncertain
09:38 < sdaftuar> jnewbery: i was certainly unaware, fyi
09:38 < jnewbery> from antoine's mailing list post:
09:38 < jnewbery> Raw TX message processing has always been tolerated by Core and as such
09:38 < jnewbery> some Bitcoin clients aren't bothering with an INV/GETDATA sequence.
09:38 < AnthonyRonning> ben2: check out that link jnewbery shared, it has a paragraph of comments as to why the honest node sends unrequested tx's
09:38 < jnewbery> he didn't think pointing out individual examples of clients that did that would be helpful
09:39 < sdaftuar> jnewbery: imo it's helpful to know how much we're breaking things (if at all) with changes like this. ie i don't know if it's just researchers doing tests that are the soruce of unrequested transactions, or wallets with widespread communities or what
09:39 < elle> Quick implementation detail question:
09:39 < elle> 6. When checking the `TxRequestTracker` to see if the node has requested a transaction, why are both the transaction’s txid and wtxid identifiers used? (hint: See PR 19569 for details on fetching orphan parents from wtxid peers)
09:39 < ariard> yeah I think bitcoinj has been pointed to me by phantomcircuit a while back
09:39 < glozow> ariard: it's surprising to me that we try to verify during IBD :O
09:39 < elle> glozow: agreed
09:39 < dergoegge> glozow: same
09:40 < eoin> What does 'IBD' stand for?
09:40 < felixweis> initial block download
09:40 < elle> which is why i ask why we cant just ignore all Tx messages during IBD..?
09:40 < felixweis> when you first start to run a bitcoin node, and all you know is the genesis block
09:41 < amiti> elle: good question, I'm wondering too
09:41 < ariard> glozow: I did react the same while reviewing tx request overhaul, and such opening the previous PR
09:41 < eoin> ty felixweis
09:42 < jnewbery> eoin: when we first start the node and we're catching up to the tip, we're in a state called IBD until we catch up. That effects various parts of our logic. I don't think all those differences are documented in a single place, but this comment from sipa in a different PR is a good overview: https://github.com/bitcoin/bitcoin/pull/21106#issuecomment-783676898
09:42 < glozow> ariard: is there any consideration for separating the during-IBD case with the non-IBD case?
09:42 < amiti> elle: I think we can?
09:42 < amiti> ariard: was your previous proposal to ignore all txs during IBD? or just unrequested ones?
09:42 < ariard> amiti: this what my initial motivation until suhas came with the idea of bouncing off unrequested txn, ibd-or-not
09:42 < glozow> amiti: do we ever request during IBD?
09:42 < felixweis> eoin: you start requesting/downloading all historical blocks from archival peers and verify their integrity. during that time you can't verify the integrity of almost all recent mempool transactions because they are spending coins created at a much later point in time anyway.
09:43 < pinheadmz> glozow i thin kthats the question! i dont think we do, but i see the INV messages in the log during IBD
09:43 < ariard> glozow: yes see the point above breaking raw tx broadcast bitcoin clients
09:43 < ariard> amiti: all txs, we ignore inv(tx) during IBD
09:43 < glozow> pinheadmz: you might get an inv, but you shouldn't send a getdata right?
09:44 < eoin> Is IBD when you first download Bitcoin Core and are downloading the blockchain?
09:44 < pinheadmz> glozow ariard looking for this logic in net_processing...
09:44 < felixweis> eoin: correct
09:45 < ariard> pinheadmz: L2898, net_processing.cpp
09:45 < glozow> pinheadmz: i think it's this https://github.com/bitcoin/bitcoin/blob/b54a10e777f912081e5c00dabcf3643b10775a50/src/net_processing.cpp#L2973
09:45 < jnewbery> glozow: yebo
09:45 < felixweis> your node will use the memory allocated for the mempool (default 300MB) for the dbcache. that speeds up the generation of your local UTXO set because it needs to write to disk less often.
09:46 < ariard> glozow: yeah this one, not on the same master :p
09:46 < pinheadmz> `fImporting` ?
09:46 < emzy> felixweis: interesting detail.
09:46 < jnewbery> felixweis eoin: these are good questions/answers, but a little off-topic. Perhaps we can circle back to them after the meeting?
09:46 < glozow> pinheadmz: I think importing from blocks db?
09:46 < pinheadmz> felixweis yes agreed, interesting optimization
09:46 < elle> ok cool yeah so we dont add the new announcement to TxRequestTracker if we are in IBD and so never send out a GETDATA
09:47 < eoin> jnewbery: Ok
09:47 < elle> Let's navigate back to question 6 (we can skip 7 and do the discussion question after):
09:47 < elle> 6. When checking the `TxRequestTracker` to see if the node has requested a transaction, why are both the transaction’s txid and wtxid identifiers used? (hint: See PR 19569 for details on fetching orphan parents from wtxid peers)
09:47 -!- craigraw [9b5dfc46@155.93.252.70] has quit [Quit: Connection closed]     
09:48 < pinheadmz> elle some peers dont relay by wtxid yet ?
09:48 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews     
09:49 < elle> pinheadmz: true, but we need to check both even on a wtxid relay connection
09:49 < elle> why?
09:49 < jnewbery> pinheadmz: will eventually all tx fetching be done with wtxid, or are there some cases where txid will still have to be used?
09:50 < sdaftuar> jnewbery: i sure hope eventually all tx fetching will be done by wtxid, fwiw
09:50 < glozow> oh, we wouldn't know if a txid and wtxid are for the same thing until we see the tx, right?
09:50 < pinheadmz> jnewbery i hope this is a trick Q but i feel like if all nodes upgrade then yeah wtxid is all we'll need
09:51 < glozow> and if you have an orphan, it refers to its parent via txid?
09:51 < elle> glozow: yebo yes!
09:51 < jnewbery> glozow: exactly!
09:51 < ariard> sdaftuar: i think we should, it would prevent tx-relay interferences around non-witness txn mutated with witness
09:51 < pinheadmz> glozow that makes sense! bc the wtxid isnt in the prevout, the txid is !
09:51 < elle> pinheadmz: indeedio
09:51 < ariard> a case not documented around your rejection filters big warnings
09:51 < jnewbery> the only way we can fetch an orphan's parent is by its txid (since that's what the txin of the child refers to)
09:52 < jnewbery> sdaftuar: I guess you mean after we have package relay and no longer do orphan handling in the same way?
09:52 < elle> Cool lets skip 7 and move onto the discusssion. The question is specific but we can also talk more generally about the pros vs cons of this change:
09:52 < sdaftuar> right, somehow we should make orphan handling better
09:53 < ariard> jnewbery: epends if package relay gets its own identifier or not...
09:53 < sdaftuar> for instance, by a p2p change to request all unconfirmed ancestors, that sort of thing
09:53 < jnewbery> sdaftuar: +1
09:53 < glozow> ariard: like package id?
09:54 < glozow> wow package relay sounds great
09:54 < ariard> glozow: yeah to avoid someone sticking parent-or-children in rejection filter, and thus interfering with your package evaluation
09:55 < elle> very cool
09:55 < ariard> glozow: I really hope we would deprecate orphans once we have pacakge relay
09:56 < elle> but that would result in some duplication right? Cause the parent would be relayed and then when the child comes then the package would be relayed etc etc?
09:56 < elle> short on time. here is question 8: 8. Discussion: Since the `inv` -> `getdata` -> `tx` sequence has not been necessary for communicating and receiving transaction data, some other clients don’t bother with the sequence at all. This means that if this change was deployed to Bitcoin Core nodes then other clients would not be able to relay transactions to upgraded Bitcoin Core nodes.
09:56 < elle> Eventually upgraded nodes would make up the majority of the network, and so those clients would have to adapt and update. Do the pros out weigh these cons? And if so, what is fair time frame to allow for the other clients to adapt?
09:56 -!- dampsat [66b0f792@102.176.247.146] has joined #bitcoin-core-pr-reviews     
09:56 < sdaftuar> is bitcoinj the only client we're aware of that does this?
09:56 < ariard> elle: or you do atomic-package-relay, sounds harder but promise better bandwidth gains
09:57 < felixweis> im still wondering if packaging, not requesting an orphans parents twice and minisketch can be combined
09:57 < emzy> Maybe the can do the same as blomfilters (for bitcoinj)? We can generally allow it the same way via a config option.
09:57 < ariard> elle: I think this question is really interesting because it underscores the fact that Core as a project doesn't have a process for p2p breaking changes
09:58 < AnthonyRonning> maybe we can do something like if 95% of all relayed transactions have gone through via inv -> getdata -> tx then we enforce it :)
09:58 < jnewbery> I think the Andreas Schildback android bitcoin wallet was based on the same codebase, so I'd guess it does the same. I don't know of any others (but I wouldn't)
09:58 < ariard> samurai wallet is java based IIRC
09:58 < sdaftuar> well i wonder if those clients only connect to NODE_BLOOM peers anyway, then this could potentially be non-breaking (if we wanted it)
09:58 < felixweis> maybe BRD is using bitcoinj as well
09:58 < emzy> jnewbery: Bisq is another.
09:58 < pinheadmz> felixweis i dont think so, BRD is written in C but im going to check ;-)
09:59 < pinheadmz> i checked bcoin and it does queue all tx broadcastss in INV messages
09:59 < felixweis> pinheadmz: ok then ignore what i just said
09:59 < pinheadmz> https://github.com/breadwallet/breadwallet-core/blob/8eb05454df3e2d5cca248b4e24eeffa420c97e3a/bitcoin/BRPeerManager.c#L544
09:59 < glozow> wait, is the proposal that if they have NODE_BLOOM we're ok with their unrequested txns?
09:59 < pinheadmz> looking good so far
09:59 < emzy> But we have at Bisq already another way to broadcast TX. So It is not true anymore.
10:00 < sdaftuar> i think aj (and jnewbery) made arguments that this is undesirable regardless of whether this is breaking (at least, no discussion on the PR indicated that people thought this was breaking, though it's an open question)
10:00 < michaelfolkson> What was harding's rationale for not wanting to highlight a specific alternative implementation jnewbery? Not wanting to highlight something that is no longer well maintained?
10:01 < jnewbery> Yeah, lots of good discussion on the PR between aj and sdaftuar. I'd recommend reading it for a good lesson in "considerations when making p2p protocol changes"
10:01 < sdaftuar> glozow: right, you could imagine that if we thought this was a good change, but just didn't want to break existing software, that if that existing software doens't connect to default Bitcoin COre nodes anyway then maybe there's room to make a change, at least for users who aren't enabling NODE_BLOOM on their own node
10:01 < AnthonyRonning> it sounded like it doesn't solve the attack vector, not alone at least.
10:01 < elle> #endmeeting
10:02 < jnewbery> awesome. Thanks elle!
10:02 < sdaftuar> AnthonyRonning: definitely not. my argument in favor of this is that it's preparatory for future anti-DoS measures that i coudl imagine. aj thinks we don't need it, and wouldn't want to use this line of thinking anyway
10:02 < felixweis> thanks elle!
10:02 < dergoegge> thank you elle!
10:02 < jnewbery> probably the most lekker review club yet
10:02 < amiti> thanks elle!
10:02 < AnthonyRonning> thanks elle and all!
10:02 < glozow> thank you elle! yebo elle!
10:02 < elle> haha jnewbery
10:02 < michaelfolkson> Thanks elle
10:02 < sdaftuar> thanks elle!
10:02 < pinheadmz> thanks elle great job
10:02 < elle> that was fun, thanks guys! Super intersting discussion!
10:02 < AnthonyRonning> sdaftuar: makes sense, ty
10:03 < ariard> sdaftuar: I still think we would benefit from a better defined attack model otherwise any proposal is hard to evaluate, included aj's per-peer CPU time bounds
10:03 < maqusat> thank you
10:03 < pinheadmz> jnewbery yeah this PR has massive comments !
10:03 < sdaftuar> ariard: yeah that's fair, i think it's reasonable if people want to shelve this proposal until such time as we have something that would actually use it.
10:03 < glozow> sdaftuar: what would the next step be? re: preparatory for more anti-DoS measures
10:04 < sdaftuar> ariard: my concern is that it's unclear whether this change is actually breaking or not for other software, so i have now at least learned (at this meeting) that there's some software people use that do this
10:04 < felixweis> ariard: is there some design doc/code for per-peer CPU measurment?
10:04 < sdaftuar> which raises the bar for making a change
10:04 < ariard> sdaftuar: gonna shelve this one, I want to reporduce first your attack on low-grade node, like raspi
10:04 < emzy> thank you elle!
10:05 < sdaftuar> ariard: makes sense
10:05 -!- elle [~ellemouto@155.93.252.70] has quit [Quit: leaving]     
10:05 < ariard> sdaftuar: yeah and also look on I/O DoS around utxo fetching, I know you had a concern about it
10:06 < sdaftuar> glozow: well i think coming up with an attack that is CPU draining on nodes today, and then coming up with an algorithm that mitigates the attack (and any obvious variants on it) would be probably enough to get momentum on making some sort of change
10:06 < eoin> what does BRD stand for?
10:06 < sdaftuar> ariard: i think that is a hopeless problem unfortunately
10:06 < felixweis> eoin: BRD is a somewhat popular iOS bitcoin wallet
10:06 < sipa> it used to be called breadwallet
10:06 < pinheadmz> eoin used to be "breadwallet"
10:07 < pinheadmz> but during the ICO craze everyone had to have a TLA
10:07 < pinheadmz> (three letter acronym)
10:07 < pinheadmz> i actually like it, its perhaps the last SPV mobile wallet and you can tether to a speicifc full node
10:07 < pinheadmz> so i have my iphone connect to my bitcoind on a raspberry pi at home
10:08 < eoin> Is bitcoind bitcoin daemon?
10:08 < pinheadmz> eoin yeah ;-)
10:08 < emzy> pinheadmz: a TLA is a TLA itself. ;)
10:08 < michaelfolkson> There are a lot of projects (and implementations) that aren't really used anymore and hence aren't well maintained. I think I would be a touch bolder in not worrying so much about those projects. But I understand the conservatism
10:09 < sdaftuar> well i definitely think we shouldn't break things unless we at least have a really good reason!
10:09 < michaelfolkson> Or just a good reason rather than a really good reason
10:10 < michaelfolkson> If the project/implementation hasn't been active for years
10:11 -!- maqusat [d98ac166@217.138.193.102] has left #bitcoin-core-pr-reviews []     
10:13 -!- AnthonyRonning [0cee2182@12.238.33.130] has quit [Quit: Connection closed]     
10:15 -!- darius70 [52114c69@finc-22-b2-v4wan-160991-cust104.vm7.cable.virginm.net] has quit [Quit: Ping timeout (120 seconds)]     
10:16 -!- dampsat [66b0f792@102.176.247.146] has quit [Ping timeout: 240 seconds]     
10:18 -!- ben2 [bd7a7e53@189.122.126.83] has quit [Quit: Ping timeout (120 seconds)]     
10:23 -!- andozw [43057765@67-5-119-101.spok.qwest.net] has quit [Quit: Connection closed]     
10:26 -!- eoin [5d6bd2bc@93.107.210.188] has quit [Quit: Connection closed]     
10:27 -!- Ahmed37Bahringer [~Ahmed37Ba@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
10:31 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has quit [Quit: Leaving]     
10:31 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-pr-reviews     
10:32 -!- jadi [~jadi@185.197.71.29] has quit [Ping timeout: 246 seconds]     
10:33 -!- ivanacostarubio [~ivan@189.172.197.192] has left #bitcoin-core-pr-reviews []     
10:35 -!- Ahmed37Bahringer [~Ahmed37Ba@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 256 seconds]     
10:39 -!- ngaldeman [5e0f2480@94.15.36.128] has left #bitcoin-core-pr-reviews []     
10:41 -!- jadi [~jadi@185.197.71.29] has joined #bitcoin-core-pr-reviews     
10:54 -!- worc3131 [~quassel@2a02:c7f:dcc4:6500:217b:6c7a:eac3:3be9] has joined #bitcoin-core-pr-reviews     
11:11 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Quit: Konversation terminated!]     
11:13 -!- virtu [~virtu@gateway/tor-sasl/virtu] has quit [Remote host closed the connection]     
11:13 -!- virtu [~virtu@gateway/tor-sasl/virtu] has joined #bitcoin-core-pr-reviews     
11:27 < harding> sdaftuar: sorry for not communicating about BitcoinJ's behavior.  When I read the log mentioned in your comment https://github.com/bitcoin/bitcoin/pull/20277#issuecomment-754642226 , I saw phantomcircuit telling ariard such clients existed on the network (though he didn't mention BitcoinJ by name) and so I assumed the general behavior pattern was known.
11:30 < harding> michaelfolkson: my rationale for not posting was that I thought the information was already known in a general sense, so it wouldn't have been particularly beneficial to highlight a specific example.
11:48 -!- effexzi [uid474242@gateway/web/irccloud.com/x-eprewwrxgtvpbdea] has quit [Quit: Connection closed for inactivity]     
11:50 < sdaftuar> harding: thanks, i think when i read phantomcircuit's comment i dismissed it due to lack of specificity (and "various modified clients" sounds like research projects to me, rather than production software)
12:03 < phantomcircuit> sdaftuar, there's also almost certainly exchanges which do that
12:04 < sdaftuar> phantomcircuit: presumably they would have the ability to use the PF_RELAY flag though, right?
12:04 < phantomcircuit> sdaftuar, of course the real solution is to keep track of how much work peers have had us do that ultimately was pointless and then deprioritize those peers, but that's much more annoying to implement
12:04 < phantomcircuit> sdaftuar, ability yes, actually do? ha
12:05 < sdaftuar> i think doing it between your own nodes -- where PF_RELAY is an easy workaround -- is different than if wallet software is doing this with random nodes on the network
12:06 < phantomcircuit> sdaftuar, it would surprise me if there wasn't at least one exchange that has bitcoinj connected directly to random peers
12:14 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]     
12:20 < phantomcircuit> sdaftuar, the issue of network latency basically has two solutions, pipeline better and add threads, and/or punish peers by delaying processing their messages if they spam us with garbage
12:20 < phantomcircuit> but i think just completely ignoring transactions we didn't ask for would cause someone somewhere lots of issues
12:27 < sdaftuar> phantomcircuit: you may be right that dropping unrequested transactions will break things. but i think the problem with the idea of punishing peers by delaying processing their messages is that it can be hard to tell if CPU DoS from unaccepted transactions is really our peer's fault or our own (eg due to policy changes)--
12:27 < sdaftuar> so if we delay all messages, including block messges from our peer, we can be harming ourselves
12:28 < sdaftuar> there may be other solutions though, like prioritizing blocks/headers/compactblocks from peers regardless (which is probably an independent improvement)
12:32 -!- fauz1_ [~Fauzi@185.192.70.87] has joined #bitcoin-core-pr-reviews     
12:33 < sipa> sdaftuar: that's something i've considered before... we really always want to process (pow-valid) blocks immediately
12:33 < sipa> a problem is the synchronicity of the protocol, so we can't just reorder processing of messages
12:34 < sipa> one possible solutions is just splitting connections in two (one for blocks, one for everything else), even if it means having two connections between the same peer
12:35 < sipa> or of course just negotiating a protocol extension that allows reordering some messages wrt others
12:41 -!- worc3131 [~quassel@2a02:c7f:dcc4:6500:217b:6c7a:eac3:3be9] has quit [Remote host closed the connection]     
12:42 -!- worc3131 [~quassel@2a02:c7f:dcc4:6500:cf0e:3346:8766:ab20] has joined #bitcoin-core-pr-reviews     
12:49 < phantomcircuit> sipa, i don't think there's anything that will actually break by reordering message processing
12:49 < phantomcircuit> except the early options negotiation
12:50 < sipa> phantomcircuit: it would at the very least break ~all our tests :p
12:56 < glozow> sdaftuar: would you happen to know the best way to DoS using transactions or know of any existing DoS simulations? I've been playing around on this branch https://github.com/glozow/bitcoin/commit/4b37f95834864ef1e5f596e94e2310543c14497b
12:56 < glozow> making txns with 679 inputs + 1 output, which just fits under the 100KvB limit. I think I could make it heavier and maybe I'm making a really dumb error somewhere but it's not nearly as slow as i had imagined
12:57 < darosior> glozow: you could use a legacy transaction with as many checksig as possible (didn't check the code maybe you already do this)
12:58 < glozow> darosior: yeah, 679 checksigs with an extra OP_1 in the last input so it fails cleanstack
12:58 < darosior> 15 checksigs / input?
12:59 < glozow> ooh, does it make a difference if there's a bunch of checksigs per input vs 1 per input?
13:00 < sipa> you can certainly pack more CPU per vbyte if you perform more checksigs per input
13:00 < darosior> Well you check 15 times per input (and do FindAndDelete too for legacy inputs)
13:01 < glozow> oh tru, if in witness right?
13:01 < sipa> witness or not
13:01 < glozow> i have no idea if this is correct intuition but i thought we'd hit the quadratic sighashing if i used legacy
13:01 < sipa> yes, you would hit it
13:01 < glozow> with a lotta inputs mebbe
13:01 < sipa> ah, good point
13:02 < glozow> :D     
13:02 -!- abstract [~abstract@195.181.160.175.adsl.inet-telecom.org] has quit [Ping timeout: 256 seconds]     
13:02 < sipa> this calls for a simplex optimization problem
13:02 < glozow> i'm certainly having a lot of fun
13:07 < darosior> glozow: rusty had a gist for the max time spent hashing too
13:07 < darosior> Here it is, does not take standardness into account though https://gist.github.com/rustyrussell/9c3c4bf3127419bd3f1d
13:07 < sipa> if you ignore standardness, it's certainly possible to do far worse
13:08 < glozow> darosior: ah cool, thank you :)
13:08 < glozow> I'm thinking about DoSing by sending transactions on p2p, so i don't think i can ignore standardness?
13:08 < sipa> you cannot
13:15 < darosior> Hmmm i wonder that if hashing is still a bottleneck you could do worse by using a lot of hashes since you would not be limited by the sigops
13:15 < darosior> There is the size limit for legacy P2SH though..
13:16 < sipa> darosior: that only gives you a linear effect
13:17 < sipa> you need N checksigs in a tx, where each checksig triggers O(N) hashes to get quadratic behavior
13:17 < darosior> Oh right
13:31 -!- fauz1_ [~Fauzi@185.192.70.87] has quit [Ping timeout: 240 seconds]     
13:40 < harding> glozow: you might also want to try a DoS that relies on spending old entries from the UTXO that are unlikely to be cached.  (Though I don't know how you can easily write a test for that.)  This might especially affect users with spinning disks.
13:43 < glozow> harding: ahh good point. could mine a ton of blocks in the beginning and then spend older coinbases? not sure how big the coins cache is
13:44 < glozow> could debug log fetching coins from disk
13:44 -!- worc3131 [~quassel@2a02:c7f:dcc4:6500:cf0e:3346:8766:ab20] has quit [Ping timeout: 272 seconds]     
13:59 < sdaftuar> sipa: that issue about message reordering is exactly why i thought it would be easier if we could decide to stop processing unrequested transactions :)
13:59 < sdaftuar> but if that also breaks things, then other ideas (like having a separate blocks-channel with a peer) might work too
14:01 < sipa> after blocksonly mode, now also noblocks mode?
14:01 < sdaftuar> oh man
14:04 < gleb> haha for a second I thought sdaftuar wanted to talk in wizards but missed chat
14:04 < sdaftuar> what if we just have logic that looks into each peer's receive queue to see if there are any compact blocks, and if there are, we copy that out and treat it like it's been dropped out of the sky to our node.  so for any given peer, including the one that happened to give it to us, the protocol retains its synchronicity, but our node might reconstruct the block sooner than that
14:04 < gleb> We're discussing IBD cheap-long-chain DoS and checkpoints there...
14:22 < phantomcircuit> sdaftuar, iirc there's DoS prevention logic that relies on knowing which peer sent you the compact block
14:22 < sipa> that'd still work i think; the peer's messages would still be processed as normal
14:23 < sipa> except the validation code would already have the block before we actually process the messages :p
14:33 -!- ecola [~3cola@95.175.17.147] has quit [Ping timeout: 246 seconds]     
14:46 -!- ecola [~3cola@95.175.17.147] has joined #bitcoin-core-pr-reviews     
15:19 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Disconnected by services]     
15:20 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
15:20 -!- vasild_ is now known as vasild     
15:31 -!- jonatack_ [~jon@37.164.140.210] has joined #bitcoin-core-pr-reviews     
15:34 -!- jonatack [~jon@37.169.20.238] has quit [Ping timeout: 256 seconds]     
15:53 -!- jonatack_ [~jon@37.164.140.210] has quit [Ping timeout: 256 seconds]     
16:00 -!- rjected [~weechat-h@natp-128-119-202-10.wireless.umass.edu] has quit [Quit: WeeChat 3.0.1]     
16:02 -!- rjected [~weechat-h@natp-128-119-202-10.wireless.umass.edu] has joined #bitcoin-core-pr-reviews     
16:07 -!- brunog [bbb72bc8@187.183.43.200] has joined #bitcoin-core-pr-reviews     
16:17 -!- brunog [bbb72bc8@187.183.43.200] has quit [Quit: Connection closed]     
16:29 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:c8ae:2c0d:ad79:de13:e3a6] has joined #bitcoin-core-pr-reviews     
16:30 -!- ecola [~3cola@95.175.17.147] has quit [Ping timeout: 240 seconds]     
16:55 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews     
16:58 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]     
16:59 -!- TheRec_ [~toto@drupal.org/user/146860/view] has quit [Read error: Connection reset by peer]     
17:00 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has joined #bitcoin-core-pr-reviews     
17:00 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has quit [Changing host]     
17:00 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-pr-reviews     
17:16 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-pr-reviews     
17:28 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:c8ae:2c0d:ad79:de13:e3a6] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
18:27 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:c8ae:2c0d:ad79:de13:e3a6] has joined #bitcoin-core-pr-reviews     
19:09 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has quit [Read error: Connection reset by peer]     
19:42 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 240 seconds]     
20:00 -!- mol [~mol@unaffiliated/molly] has quit [Read error: Connection reset by peer]     
20:01 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
20:04 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Quit: Leaving]     
20:29 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-pr-reviews     
20:41 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews     
20:44 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 256 seconds]     
21:19 -!- jessepos_ [~jp@2601:645:200:162f:18b0:ad00:6043:7e74] has joined #bitcoin-core-pr-reviews     
21:21 -!- jesseposner [~jp@2601:645:200:162f:70af:6c8d:477c:f040] has quit [Ping timeout: 240 seconds]     
21:33 -!- shafiunmiraz0 [~shafiunmi@103.220.205.190] has joined #bitcoin-core-pr-reviews     
21:39 -!- shafiunmiraz0 is now known as miraz     
21:39 -!- miraz is now known as shafiunmiraz0     
21:47 -!- shafiunmiraz0 [~shafiunmi@103.220.205.190] has quit [Quit: Leaving]     
21:47 -!- shafiunmiraz0 [~shafiunmi@103.220.205.190] has joined #bitcoin-core-pr-reviews     
21:51 < shafiunmiraz0> • /msg shafiunmiraz0 identify shafiunmiraz0 Shafiun#77
21:52 -!- shafiunmiraz0 [~shafiunmi@103.220.205.190] has quit [Client Quit]     
21:53 -!- shafiunmiraz0 [~shafiunmi@103.220.205.190] has joined #bitcoin-core-pr-reviews     
21:54 -!- shafiunmiraz0 [~shafiunmi@103.220.205.190] has left #bitcoin-core-pr-reviews []     
22:04 -!- shafiunmiraz0 [~shafiunmi@103.220.205.190] has joined #bitcoin-core-pr-reviews     
22:09 -!- shafiunmiraz0 [~shafiunmi@103.220.205.190] has quit [Quit: Leaving]     
22:09 -!- shafiunmiraz0 [~shafiunmi@103.220.205.190] has joined #bitcoin-core-pr-reviews     
22:10 -!- shafiunmiraz0 [~shafiunmi@103.220.205.190] has quit [Client Quit]     
22:32 -!- SurajUpadhyay [uid421192@gateway/web/irccloud.com/x-uefgzwkzruiwmhar] has quit [Quit: Connection closed for inactivity]     
23:14 < jarolrod> someone made an oopsy
23:44 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has joined #bitcoin-core-pr-reviews     
23:48 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has quit [Remote host closed the connection]     
23:48 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has joined #bitcoin-core-pr-reviews