--- Day changed Wed Oct 16 2019
00:28 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
00:33 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has quit [Ping timeout: 268 seconds]     
01:23 -!- infognom [~infognom@2a02:810d:d00:708:813d:a26e:3fb9:85aa] has joined #bitcoin-core-pr-reviews     
01:42 -!- infognom [~infognom@2a02:810d:d00:708:813d:a26e:3fb9:85aa] has quit [Ping timeout: 246 seconds]     
02:29 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
02:34 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has quit [Ping timeout: 265 seconds]     
03:27 -!- infognom [~infognom@2a02:810d:d00:708:813d:a26e:3fb9:85aa] has joined #bitcoin-core-pr-reviews     
03:43 -!- infognom [~infognom@2a02:810d:d00:708:813d:a26e:3fb9:85aa] has quit [Remote host closed the connection]     
03:43 -!- infognom [~infognom@2a02:810d:d00:708:813d:a26e:3fb9:85aa] has joined #bitcoin-core-pr-reviews     
04:21 -!- infognom [~infognom@2a02:810d:d00:708:813d:a26e:3fb9:85aa] has quit [Remote host closed the connection]     
04:22 -!- infognom [~infognom@2a02:810d:d00:708:813d:a26e:3fb9:85aa] has joined #bitcoin-core-pr-reviews     
04:30 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
04:35 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has quit [Ping timeout: 268 seconds]     
04:56 -!- infognom [~infognom@2a02:810d:d00:708:813d:a26e:3fb9:85aa] has quit [Ping timeout: 245 seconds]     
05:17 -!- infognom [~infognom@2a02:810d:d00:708:813d:a26e:3fb9:85aa] has joined #bitcoin-core-pr-reviews     
05:32 -!- pinheadmz_ [~matthewzi@185.217.69.177] has joined #bitcoin-core-pr-reviews     
05:34 -!- pinheadmz [matthewzip@gateway/vpn/nordvpn/pinheadmz] has quit [Ping timeout: 268 seconds]     
05:34 -!- pinheadmz_ is now known as pinheadmz     
05:42 -!- pinheadmz_ [~matthewzi@185.59.223.120] has joined #bitcoin-core-pr-reviews     
05:44 -!- pinheadmz [~matthewzi@185.217.69.177] has quit [Ping timeout: 265 seconds]     
05:45 -!- pinheadmz [matthewzip@gateway/vpn/nordvpn/pinheadmz] has joined #bitcoin-core-pr-reviews     
05:47 -!- pinheadmz_ [~matthewzi@185.59.223.120] has quit [Ping timeout: 265 seconds]     
05:57 -!- davterra [~none@91.132.136.92] has joined #bitcoin-core-pr-reviews     
06:06 -!- emilengler_ is now known as emilengler     
06:10 -!- infognom [~infognom@2a02:810d:d00:708:813d:a26e:3fb9:85aa] has quit [Ping timeout: 246 seconds]     
06:16 -!- infognom [~infognom@2a02:810d:d00:708:813d:a26e:3fb9:85aa] has joined #bitcoin-core-pr-reviews     
06:24 -!- lightlike [~lightlike@2001:16b8:574d:f200:908d:df92:e3c:9289] has joined #bitcoin-core-pr-reviews     
06:31 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
06:35 -!- infognom [~infognom@2a02:810d:d00:708:813d:a26e:3fb9:85aa] has quit [Ping timeout: 276 seconds]     
06:36 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has quit [Ping timeout: 265 seconds]     
06:41 -!- lightlike [~lightlike@2001:16b8:574d:f200:908d:df92:e3c:9289] has quit [Remote host closed the connection]     
07:11 < pinheadmz> maybe someone can help me out before we get going: I noticed the modified tests in this PR are cpp not python - looks like `make check` compiles the whole test suite -- is there a way to just run one at a time? Or are they even structured in such a way?
07:14 < fanquake> pinheadmz You can use something like src/test/test_bitcoin --run_test=coins_tests to filter for and run specific tests
07:15 < fanquake> Or pass --help to test_bitcoin and take a look through the options
07:15 < pinheadmz> fanquake: got it thanks, also just found the README in /src/test, I was looking around /test :-)
07:17 < jnewbery> Reminder that today's meeting is on PR 16279. Notes and questions at https://bitcoincore.reviews/16279.html . See you all in 2 hours and 43 minutes :)
07:29 -!- ajonas [uid385278@gateway/web/irccloud.com/x-tmpetcproqzqsnvg] has joined #bitcoin-core-pr-reviews     
07:59 < jnewbery> https://bitcoincore.reviews/ was very slow to load for me this morning. Let me know if any of you see the same thing
08:02 < emzy> Also slow here (Germany)
08:07 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-pr-reviews     
08:32 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
08:39 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews     
08:39 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]     
09:02 -!- jonatack [~jon@p57B4C1A5.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews     
09:14 -!- jonatack [~jon@p57B4C1A5.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]     
09:15 -!- jonatack [~jon@213.152.161.35] has joined #bitcoin-core-pr-reviews     
09:17 -!- lightlike [~lightlike@2001:16b8:574d:f200:908d:df92:e3c:9289] has joined #bitcoin-core-pr-reviews     
09:23 -!- zenogais [~user@cpe-76-175-74-114.socal.res.rr.com] has joined #bitcoin-core-pr-reviews     
09:34 -!- jkczyz [~jkczyz@135.84.132.56] has joined #bitcoin-core-pr-reviews     
09:43 -!- sebastianvstaa [~sebastian@95.211.188.18] has joined #bitcoin-core-pr-reviews     
09:45 -!- jkczyz [~jkczyz@135.84.132.56] has quit [Ping timeout: 268 seconds]     
09:45 < jnewbery> we'll get started in 15 minutes
09:47 -!- jkczyz [~jkczyz@135.84.132.56] has joined #bitcoin-core-pr-reviews     
10:00 < jnewbery> hi     
10:00 < zenogais> hi     
10:00 < fox2p> hey     
10:00 < ariard> hi     
10:00 < amiti> hi     
10:01 < jnewbery> what did everyone think of this week's PR?
10:01 < sebastianvstaa> hi     
10:01 < ajonas> hi     
10:01 < zenogais> Was interesting, small change that interacts with a lot of crucial systems.
10:01 < jnewbery> zenogais: yes! I agree
10:02 -!- jonatack_ [~jon@p57B4C1A5.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews     
10:02 < jnewbery> very little functional change, but there's lots to dig into
10:02 < jonatack_> hi     
10:02 < zenogais> Definitely caused me to explore parts of the codebase I'd never seen before.
10:02 -!- jonatack [~jon@213.152.161.35] has quit [Ping timeout: 240 seconds]     
10:02 < amiti> yeah agreed, not a ton changed but I learned/explored a lot to get the context
10:02 < jnewbery> we've touched on the CValidationInterface in a few previous reviews, but I think this is the first time we've looked at changes in validation.cpp
10:02 < pinheadmz> hi !
10:03 < amiti> very context heavy, as many of the conversations revealed
10:03 -!- jonatack_ [~jon@p57B4C1A5.dip0.t-ipconnect.de] has quit [Client Quit]     
10:03 -!- jonatack [~jon@p57B4C1A5.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews     
10:03 < jnewbery> So I think the first thing to do for this one is understand what's going on with the CValidationInterface. It's declared here: https://github.com/jnewbery/bitcoin/blob/2ec121f09d8f7117fc9a8f830a7242f9a3602b78/src/validationinterface.h#L71
10:03 < jnewbery> that's where the useful comments are
10:04 < jnewbery> you can see that there are 8 methods in the interface. Most of them are asynchronous, but a couple are synchronous. Can you see which ones?
10:05 < pinheadmz> well, like RegisterBackgroundSignalScheduler takes a callback as an arg?
10:06 < pinheadmz> so id guess that is async
10:06 < jnewbery> RegisterBackgroundSignalScheduler is adding the scheduler thread. I think it's only called at startup/initialization
10:06 < jnewbery> The methods are in the CValidationInterface() class
10:07 < jnewbery> UpdatedBlockTip, TransactionAddedToMempool, etc
10:07 < jnewbery> It might be easier if you look at where those methods are defined: https://github.com/jnewbery/bitcoin/blob/2ec121f09d8f7117fc9a8f830a7242f9a3602b78/src/validationinterface.cpp#L131
10:07 < ariard> ChainStateFlushed and BlockChecked
10:08 < ariard> and NewPowValidBlock?
10:08 < fox2p> and NewPoWValidBlock?
10:08 < fox2p> yeah
10:08 < zenogais> So anything that doesn't call `AddToProcessQueue`?
10:08 < jnewbery> zenogais: correct
10:08 < ajonas>  so not ChainStateFlushed then
10:09 < jnewbery> BlockChecked and NewPOWValidBlock are synchronous
10:09 < ariard> No ChainStateFlushed sorry
10:09 < jnewbery> you can see those two methods are making direct function calls. The other methods are all adding a lambda function to the queue
10:10 < jnewbery> the scheduler thread will come and service those functions in the background at some point.
10:10 < jnewbery> ok, so with that background, let's move onto the PR
10:10 < jnewbery> describe briefly what the PR is doing
10:11 < jnewbery> all of you... GO!
10:11 < pinheadmz> ha!     
10:12 < pinheadmz> adds a new arg to ProcessNewBlock, a CValidationState
10:12 < pinheadmz> so every time you call PNB, you have to init a state first, pass it in, thenafter PNB returns, you can examine it for isValid()
10:12 < jnewbery> pinheadmz: right, and what's that CValidationState argument used for
10:12 < jnewbery> pinheadmz: yes
10:12 < pinheadmz> seems to just return validation errors and state
10:12 < pinheadmz> i was hoping the util tests would have a bad block in there and i could see a "bad" response
10:13 < pinheadmz> but I think all the tests return boring valid states
10:13 < zenogais> Validation state is used for DoS checks
10:13 < jnewbery> zenogais: correct. And where do we do those DoS checks?
10:13 < jnewbery> Which function handles invalid blocks?
10:14 < pinheadmz> is that checkblock and contextualcheckblock ?
10:14 < zenogais> InvalidBlockFound
10:14 < zenogais> and some others, let me check
10:15 < jnewbery> pinheadmz: I'm thinking more about on the net processing layer. Which function sees that we've received an invalid block and then handles whether to punish peers?
10:15 < zenogais> Ah and BlockChecked
10:15 < pinheadmz> BlockChecked()
10:15 < jnewbery> exactly
10:15 < pinheadmz> funny to name a function past-tense but ok i get it
10:16 < jnewbery> pinheadmz: the function is an implementation of that CValidationInterface method
10:16 < zenogais> which calls MaybePunishNode with the state given
10:16 < jnewbery> so that method is telling subscribers that 'a block has been checked'
10:17 < pinheadmz> 👍
10:17 < jnewbery> You can see here (in master) where the function is defined: https://github.com/bitcoin/bitcoin/blob/c34b88620dc8435b83e6744895f2ecd3c9ec8de7/src/net_processing.cpp#L1231
10:18 < jnewbery> It's a member function of the PeerLogicValidation class
10:19 < jnewbery> and you can see where that class is declared that it's inheriting from CValidationInterface: https://github.com/bitcoin/bitcoin/blob/c34b88620dc8435b83e6744895f2ecd3c9ec8de7/src/net_processing.h#L22
10:19 < jnewbery> so prior to this PR, we had net processing calling into validation (using ProcessNewBlock()), which then called directly into net processing (using the BlockChecked() validation interface method, which is a direct function call)
10:20 < jnewbery> so net processing -> validation -> net processing
10:20 < jnewbery> does that make sense? any questions about that?
10:20 < zenogais> Yep makes sense
10:20 < pinheadmz> cool.
10:20 < zenogais> Looks like it's registered here in init.cpp: https://github.com/bitcoin/bitcoin/blob/master/src/init.cpp#L1323
10:21 < jnewbery> zenogais: exactly. Any client that wants to register with the validation interface needs to call that RegisterValidationInterface() function
10:22 < jnewbery> and how does this PR change that?
10:22 < jnewbery> (the net processing -> validation -> net processing stack)
10:23 < zenogais> Adds CConnman* as an argument
10:23 < pinheadmz> oh yeah i was a bit confused - what would be a 'client' in this sense?
10:23 < pinheadmz> are we actually talking about a process outside bitcoind? like ZMQ notificaitons ?
10:24 < jnewbery> pinheadmz: no, the clients are the components or classes that register with the validation interface. They're all internal to bitcoind
10:24 < ariard> like the index or wallet
10:24 < jnewbery> ariard: exactly
10:25 < jnewbery> other clients are the ZMQ component, which receives notifcations over the validation interface and then sends ZMQ notifications out
10:25 < ariard> and mining stack IIRC
10:25 < jnewbery> and PeerLogicValidation, which is net processing
10:26 < jnewbery> ariard: right. That uses the validation interface to check that a submitted block was valid
10:26 < zenogais> Adds an argument to ProcessNewBlock as well to bubble up the CValidationState
10:26 < jnewbery> I think that's all of them. Just look for classes which inherit CValidationInterface
10:26 < jnewbery> and then call RegisterValidationInterface()
10:27 < jnewbery> zenogais: right, so ProcessNewBlock is no longer calling BlockChecked directly
10:27 < jnewbery> which means validation is not making a direct functional call into net processing
10:28 < jnewbery> why is that important/interesting here?
10:28 < zenogais> Breaks the dependency there
10:29 < pinheadmz> The PR emphasizes pushing validation into a backgroun thread there as well
10:29 < pinheadmz> does it allow the process to be async then?
10:29 < amiti> easier to make async if its just a message being passed from net processing -> validation ?
10:29 < jnewbery> great! Yes, that's the motivation for this PR
10:30 < jnewbery> PR 16175 (WIP, currently closed) is the PR to make ProcessNewBlock async: https://github.com/bitcoin/bitcoin/pull/16175
10:31 < jnewbery> really, I think we want net processing to just be passing blocks/transactions up to validation, and being informed asynchronously of any validation events
10:31 < jnewbery> validation shouldn't be calling functions directly in net processing
10:31 -!- LarryRuane [cda8418a@205-168-65-138.dia.static.qwest.net] has joined #bitcoin-core-pr-reviews     
10:32 < jnewbery> any thoughts about that? Shall we move onto the questions: https://bitcoincore.reviews/16279.html#questions
10:32 < amiti> can you hash that out a bit further?
10:32 < amiti> why not?
10:32 < amiti> it mostly makes sense to me, but not entirely
10:32 < zenogais> My guess would be cleaner separation of concerns, and ability to run more work in parallel.
10:33 < jnewbery> zenogais: yeah, that's it
10:34 < jnewbery> if we want net processing and validation to run in parallel, we want net processing to be simply handing messages to validation and not have net processing and validation calling into each other
10:35 < ariard> we would be able to check validity of blocks in parallel
10:35 < amiti> ok ya. thanks
10:35 < zenogais> Also just cleaner to understand if its strict message passing rather than nested levels of function calls between components.
10:36 < jonatack> Yes, while avoiding reaching into internals across layers.
10:36 < jnewbery> Perhaps we can look at PR 16175 in a future review club meeting if people are interested
10:36 < jnewbery> to see where these changes are heading
10:36 < ariard> have a look on this https://bitcoincore.org/en/meetings/2018/05/03/
10:37 < ariard> about #12934, the OG refactoring PR
10:37 < jnewbery> ariard: thanks! Nice find
10:37 < jnewbery> ok, onto questions
10:37 < jnewbery> What steps did you take, beyond reading the code?
10:38 < jnewbery> Did you test this? If so, how?
10:38 < pinheadmz> ran the tests, tried adding extra logging with printf to see what happens to dos_state
10:38 < zenogais> I ran all unit and functional tests and reviewed the existing DoS tests to look for blind spots.
10:38 < jnewbery> pinheadmz: zenogais: that's great!
10:38 < zenogais> It seems like most of what is easy to test is tested already
10:38 < jnewbery> did you find anything interesting?
10:39 < pinheadmz> not really, the validation_block_tests dont seem to test bad blocks
10:40 < pinheadmz> probably could have been better for me to log in CValidationState and then run the python tests
10:40 < jnewbery> interesting. I don't think I've looked at that file. A lot of the block failure modes are tested in the feature_blocks.py functional test
10:40 < pinheadmz> yeah, but the PR didn't touch those :-)
10:41 < jnewbery> You all should go back and ACK https://bitcoincore.reviews/16688.html so we have better logging in the CValidationInterface :)
10:41 < zenogais> One interesting thing I found was `CheckForkWarningConditions`. Seems untested, but interesting system to have in place.
10:41 < jnewbery> ok, next question: Did anything about the way new blocks are checked and accepted surprise you? Do you have any questions about the series of steps to add a block to the block chain?
10:42 < pinheadmz> (heh - the link on that 16688.html page goes to the wrong PR...)
10:43 < jnewbery> pinheadmz: oops. Thanks - I'll fix after this meeting
10:43 < ariard> have a look on BlockStatus in src/chain.h
10:44 < ariard> we have different state according the validation work which has been done on a given Block
10:44 < zenogais> ah yeah, the BlockStatus stuff was interesting
10:44 < zenogais> still don't fully understandit
10:45 < jnewbery> Yeah, I went digging into that because of this change: https://github.com/bitcoin/bitcoin/pull/16279/commits/c16e139246f215965bb572da1a11382b4f61d957
10:45 < jnewbery> (which Matt moved into its own commit today)
10:47 < jnewbery> BlockStatus is kind of weird. It seems to be partly treated as an enum and partly as a bitfield
10:48 -!- earthrise89 [c6309fb2@198-48-159-178.cpe.pppoe.ca] has joined #bitcoin-core-pr-reviews     
10:48 < ariard> jnewbery: where it's treated as a bitfield?
10:48 < jnewbery> everything above the bottom three bits are treated as a bitfield, no?
10:48 < jnewbery>     BLOCK_HAVE_DATA          =    8, //!< full block available in blk*.dat
10:49 < jnewbery>     BLOCK_HAVE_UNDO          =   16, //!< undo data available in rev*.dat
10:49 < zenogais> The bottom three bits seem to be treated as a bitfield
10:49 < jnewbery> etc     
10:49 < zenogais> BLOCK_VALID_MASK ors some of those bits together AFAICT
10:49 < ariard> Oh I see what you mean
10:49 < zenogais> it's odd to or BLOCK_VALID_TRANSACTIONS w/ BLOCK_VALID_RESERVED and BLOCK_VALID_TREE since some of them flip the same bits on
10:50 < jnewbery> the bottom three bits are used to store the validity
10:50 < jnewbery> the fourth bit is whether the block is available in a blk*.dat file
10:51 < ariard> well a OR of enum is still an enum
10:51 < jnewbery> BLOCK_VALID_MASK could just be defined as 7 (or 0b11100000...)
10:51 < jnewbery> ok, we've got 10 minutes left. Let's keep moving through the questions
10:51 < jnewbery> The author describes this PR as “a first step towards a series of cleanups leading to a (more-complete) #16175. It’s just two rather-nice (IMO) cleanups.” Do you agree? Is this just a cleanup PR or are there behaviour changes?
10:52 < ajonas> you definitely don't agree in https://github.com/bitcoin/bitcoin/pull/16279/files#r333115791
10:52 < jnewbery> ajonas: :)
10:52 < ariard> I agree there is a confusion between validity of block and its availability as data in BlockStatus
10:52 < zenogais> Hard to draw the line between cleanup and behavior change. I think some of the stuff pointed out with BlockStatus by jnewbery leads me to believe there's a behavior change.
10:53 < jnewbery> yeah, I found that change very difficult to review.
10:54 < jnewbery> before I put my ACK on a PR I want to understand exactly how behaviour might change, especially in net processing and validation where very tiny changes can have surprising and dangerous effects
10:55 < jnewbery> changing from `if (pindex->IsValid(BLOCK_VALID_TRANSACTIONS))` to `if (dos_state.IsValid())` seems reasonable, but it sent me off in lots of different directions trying to work out when BlockStatus is changed, what MarkBlockAsReceived() is doing exactly, etc
10:56 < zenogais> Yeah, I found I went down some pretty interesting rabbit holes there
10:56 < jnewbery> ok, a couple of minutes left. I had two other questions:
10:56 < jnewbery> Are there any other CValidationInterface clients that use the BlockChecked callback?
10:56 < jnewbery> The other place that the BlockChecked method is called is in ConnectTip() in ActivateBestChain(). Why does that need to be a callback? Why does net processing need to keep a mapBlockSource map from the block to the peer that provided it?
10:57 < jnewbery> I'm happy to extend this for a few extra minutes if everyone else is
10:57 < zenogais> submitblock_StateCatcher
10:57 < jnewbery> zenogais: nice. What's that used for?
10:58 < zenogais> I'm not exactly sure lol
10:58 < zenogais> It's in mining.cpp so clearly related to that
10:58 < zenogais> But hadn't had a chance to explore it
10:58 < jnewbery> right. It temporarily registers with the validation interface
10:58 < jnewbery> and then the block is submitted
10:59 < jnewbery> and it catches whether a BlockChecked notification was sent
10:59 < ariard> You need to keep a mapBlockSource to punish peer in case of invalidity ?
10:59 < jnewbery> ariard: yes!
10:59 < jnewbery> because we don't necessarily know whether a block was invalid until we try to connect it to the chain
10:59 < ariard> exactly
11:00 < jnewbery> and so at that point, if it is invalid (eg it contains a double-spend or invalid tx), we want to disconnect from the peer that sent it to us
11:00 < jnewbery> so mapBlockSource keeps a map from the block hash to the peer that sent it to us
11:01 < jnewbery> ok, we've overrun a bit, but does anyone have any final questions before we wrap it up?
11:02 < amiti> yes! I'm confused by this comment: https://github.com/bitcoin/bitcoin/pull/16279/files#diff-349fbb003d5ae550a2e8fa658e475880R213
11:02 < amiti> if fForceProcessing is set, then you force going through ProcessNewBlock again right
11:03 < amiti> cause it passes that value through to AcceptBlock
11:03 < jnewbery> yes, and I think it forces you to save to disk
11:04 < amiti> so, reasons you would go through ProcessNewBlock are 1. fNewBlock is true 2. you force it with fForceProcessing 3. pruning enabled & trying to re-download a block that was pruned
11:05 < jnewbery> fNewBlock I think is a return argument
11:05 < amiti> oh right
11:05 -!- davterra [~none@91.132.136.92] has quit [Remote host closed the connection]     
11:05 -!- earthrise89 [c6309fb2@198-48-159-178.cpe.pppoe.ca] has quit [Ping timeout: 260 seconds]     
11:05 < amiti> ok so if you force it or pruned the block, you could repeat
11:05 -!- davterra [~none@91.132.136.92] has joined #bitcoin-core-pr-reviews     
11:06 < amiti> but otherwise you wouldnt ever repeat with the same hash
11:06 < zenogais> Have to head out. Thanks for hosting jnewberry!
11:07 -!- zenogais [~user@cpe-76-175-74-114.socal.res.rr.com] has left #bitcoin-core-pr-reviews ["ERC (IRC client for Emacs 26.1)"]     
11:07 < jnewbery> I think the comment is trying to say - we don't need to call ProcessNewBlock again if we receive a block with the same hash, as long as the state returned was valid and (it was fForceProcessing or a new block)
11:07 -!- davterra [~none@91.132.136.92] has quit [Remote host closed the connection]     
11:07 -!- davterra [~none@91.132.136.92] has joined #bitcoin-core-pr-reviews     
11:08 < jnewbery> the state.IsValid() means that the block hasn't been mutated - ie that the PoW is valid
11:08 < amiti> ok     
11:09 < amiti> I think I get it
11:09 < jnewbery> it's a confusing comment!
11:09 < amiti> yeah and I was trying to fix it, but didn't actually understand what was trying to be said
11:09 < pinheadmz> ive been down this road before - bc a legacy node could send a block w no witness data, but itd have the same hash
11:10 < jnewbery> we're about 10 minutes over. Let's close it there.
11:10 < amiti> thank you :)
11:10 < jnewbery> Thanks everyone. Great discussion this week!
11:10 < pinheadmz> yeah thanks JN!!!!
11:11 < ariard> thanks
11:11 < sebastianvstaa> thanks
11:11 < ajonas> thanks John
11:13 < jnewbery> It's a shame zenogais had to run. He sent me a suggestion about using this channel to discuss the PR/ask questions/share progress in the week leading up to the meeting. I've previously discouraged that because I think it's useful to concentrate all the discussion to a set time when we're all here, but I'm interested in hearing other people's thoughts (this club belongs to everyone here).
11:14 -!- jonatack [~jon@p57B4C1A5.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds]     
11:17 -!- sebastianvstaa [~sebastian@95.211.188.18] has left #bitcoin-core-pr-reviews ["Leaving"]     
11:18 < LarryRuane> This was my first time joining, had no idea what everyone was talking about, but love the tone of the discussion! Will love to come back, and hope to be able to contribute!
11:30 -!- jonatack [~jon@p57B4C1A5.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews     
11:30 < jnewbery> LarryRuane: thanks for joining! we enjoyed reviewing https://github.com/bitcoin/bitcoin/pull/16115 a few weeks ago
11:35 < jonatack> Connection issues (just arrived in Berlin), excellent topic today, looking forward to reading the log :)
12:00 -!- drbrule [uid395654@gateway/web/irccloud.com/x-pulspqwqpdwatdys] has joined #bitcoin-core-pr-reviews     
12:08 -!- jkczyz [~jkczyz@135.84.132.56] has quit [Ping timeout: 240 seconds]     
12:13 < amiti> +1 to using this channel more actively during the week leading up. theres more to cover than can fit into an hour and I think ahead-of-time convo would encourage more people to get involved. I don't really see it detracting from the time we are all here, so maybe worth a try?
12:15 -!- jkczyz [~jkczyz@135.84.132.56] has joined #bitcoin-core-pr-reviews     
12:17 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!]     
12:38 < jonatack> amiti: I can't see the previous discussion but yes, discussing the reviews, thoughts, and context here sounds good to me!
12:45 -!- jkczyz [~jkczyz@135.84.132.56] has quit [Ping timeout: 240 seconds]     
12:46 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection]     
13:02 -!- lightlike [~lightlike@2001:16b8:574d:f200:908d:df92:e3c:9289] has quit [Remote host closed the connection]     
13:12 < jnewbery> emzy: I've moved the hosting from github pages to netlify now. Hopefully that fixes the slow-loading issue
13:39 < emzy> jnewbery: yes fast now.
14:18 -!- drbrule [uid395654@gateway/web/irccloud.com/x-pulspqwqpdwatdys] has quit [Quit: Connection closed for inactivity]     
15:20 -!- LarryRuane [cda8418a@205-168-65-138.dia.static.qwest.net] has quit [Remote host closed the connection]     
16:06 -!- pinheadmz_ [matthewzip@gateway/vpn/nordvpn/pinheadmz] has joined #bitcoin-core-pr-reviews     
16:09 -!- pinheadmz [matthewzip@gateway/vpn/nordvpn/pinheadmz] has quit [Ping timeout: 265 seconds]     
16:09 -!- pinheadmz_ is now known as pinheadmz     
16:15 -!- pinheadmz [matthewzip@gateway/vpn/nordvpn/pinheadmz] has quit [Quit: pinheadmz]     
16:31 -!- davterra [~none@91.132.136.92] has quit [Quit: Leaving]     
16:50 -!- emilengler [~emilengle@unaffiliated/emilengler] has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]     
16:54 -!- pinheadmz [matthewzip@gateway/vpn/nordvpn/pinheadmz] has joined #bitcoin-core-pr-reviews     
16:56 -!- ajonas [uid385278@gateway/web/irccloud.com/x-tmpetcproqzqsnvg] has quit [Quit: Connection closed for inactivity]     
17:18 -!- pinheadmz [matthewzip@gateway/vpn/nordvpn/pinheadmz] has quit [Quit: pinheadmz]     
17:19 -!- fox2p [~fox2p@82.102.24.131] has quit [Read error: Connection reset by peer]     
17:21 -!- fox2p [~fox2p@185.9.18.99] has joined #bitcoin-core-pr-reviews     
17:26 -!- pinheadmz [matthewzip@gateway/vpn/nordvpn/pinheadmz] has joined #bitcoin-core-pr-reviews     
17:36 -!- pinheadmz [matthewzip@gateway/vpn/nordvpn/pinheadmz] has quit [Quit: pinheadmz]     
18:15 -!- pinheadmz [matthewzip@gateway/vpn/nordvpn/pinheadmz] has joined #bitcoin-core-pr-reviews     
19:05 -!- emilengler [~emilengle@unaffiliated/emilengler] has joined #bitcoin-core-pr-reviews     
19:08 -!- felixfoertsch23 [~felixfoer@2001:16b8:5093:fb00:cd6e:99fe:a5a0:6b60] has joined #bitcoin-core-pr-reviews     
19:09 -!- felixfoertsch [~felixfoer@2001:16b8:5041:8500:cd6e:99fe:a5a0:6b60] has quit [Ping timeout: 276 seconds]     
21:16 -!- felixfoertsch23 [~felixfoer@2001:16b8:5093:fb00:cd6e:99fe:a5a0:6b60] has quit [Quit: ZNC 1.7.3 - https://znc.in]     
21:16 -!- felixfoertsch [~felixfoer@2001:16b8:5093:fb00:d507:249:7728:4c1] has joined #bitcoin-core-pr-reviews     
21:39 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
21:54 -!- shesek` [~shesek@5.22.135.66] has joined #bitcoin-core-pr-reviews     
21:56 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 268 seconds]     
22:01 -!- pinheadmz_ [matthewzip@gateway/vpn/nordvpn/pinheadmz] has joined #bitcoin-core-pr-reviews     
22:03 -!- pinheadmz [matthewzip@gateway/vpn/nordvpn/pinheadmz] has quit [Ping timeout: 265 seconds]     
22:03 -!- pinheadmz_ is now known as pinheadmz     
22:58 -!- shesek` [~shesek@5.22.135.66] has quit [Read error: Connection reset by peer]     
22:58 -!- shesek`` [~shesek@5.22.135.181] has joined #bitcoin-core-pr-reviews     
23:12 -!- shesek` [~shesek@5.22.135.66] has joined #bitcoin-core-pr-reviews     
23:13 -!- shesek`` [~shesek@5.22.135.181] has quit [Read error: Connection reset by peer]     
23:51 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]