--- Day changed Wed Aug 19 2020
00:20 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 260 seconds]     
01:24 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Read error: Connection reset by peer]     
01:27 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #bitcoin-core-pr-reviews     
01:41 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-pr-reviews     
02:34 < jnewbery> fjahr wins the bug hunting prize. There in fact *wasn't* a bug in the implementation that we reviewed. It was only introduced in a later force push.
02:34 < jnewbery> the bug is described here: https://github.com/bitcoin/bitcoin/pull/17977#issuecomment-674183128
02:35 < jnewbery> it was that 0x80 wasn't rejected as an invalid sighash
02:36 < jnewbery> code here:
02:36 < jnewbery> if (!(hash_type <= 0x03 || (hash_type >= 0x80 && hash_type <= 0x83))) return false;
02:36 < jnewbery> but in the version we reviewed:
02:36 < jnewbery> const uint8_t output_type = (hash_type == SIGHASH_DEFAULT) ? SIGHASH_ALL : (hash_type & SIGHASH_OUTPUT_MASK);
02:36 < jnewbery> if (output_type != SIGHASH_ALL && output_type != SIGHASH_SINGLE && output_type != SIGHASH_NONE) return false;
02:37 < jnewbery> so 0x80 would be correctly rejected, since output_type would be 0
02:49 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews     
02:58 -!- evanlinjin [~evanlinji@2404:4408:43ff:bb00:67a3:453a:d686:317c] has joined #bitcoin-core-pr-reviews     
03:18 -!- Shania89Baumbach [~Shania89B@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
03:20 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection]     
03:23 -!- Shania89Baumbach [~Shania89B@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 265 seconds]     
03:24 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
03:55 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
03:59 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]     
03:59 -!- vasild_ is now known as vasild     
04:54 -!- dergoegge [uid453889@gateway/web/irccloud.com/x-ncxvfwxizoirngdr] has quit [Quit: Connection closed for inactivity]     
05:57 -!- dergoegge [uid453889@gateway/web/irccloud.com/x-xlhofqvmmqwkybrf] has joined #bitcoin-core-pr-reviews     
06:05  * michaelfolkson is feeling better that he couldn't find the bug now...
06:14 -!- troygiorshev [~troygiors@d67-193-140-136.home3.cgocable.net] has joined #bitcoin-core-pr-reviews     
06:24 -!- troygiorshev [~troygiors@d67-193-140-136.home3.cgocable.net] has quit [Quit: leaving]     
06:24 -!- troygiorshev [~troygiors@d67-193-140-136.home3.cgocable.net] has joined #bitcoin-core-pr-reviews     
06:29 -!- Tralfaz [~Davterra@69.4.234.76] has joined #bitcoin-core-pr-reviews     
06:31 -!- Davterra [~Davterra@69.4.234.76] has quit [Ping timeout: 256 seconds]     
06:33 -!- Davterra [~Davterra@69.4.234.76] has joined #bitcoin-core-pr-reviews     
06:36 -!- Tralfaz [~Davterra@69.4.234.76] has quit [Ping timeout: 264 seconds]     
06:42 -!- Davterra [~Davterra@69.4.234.76] has quit [Remote host closed the connection]     
06:43 -!- Davterra [~Davterra@69.4.234.76] has joined #bitcoin-core-pr-reviews     
07:23 -!- thomasb06 [863be68d@gateway/web/cgi-irc/kiwiirc.com/ip.134.59.230.141] has quit [Quit: Connection closed]     
07:49 < pinheadmz> I had bitcoin synced to 100% a week or so ago, > 300 GB on disk. today I pull a PR and start bitcoind and its "loading blocks from disk" 5%.... 6%... :-( did i lose my chain index somehow ?
07:56 < michaelfolkson> What PRs have you built previously in the last week?
08:01 < pinheadmz> https://github.com/bitcoin/bitcoin/pull/19643 is the first one I'm running with this datadir that isnt a tagged release
08:02 < pinheadmz> i dont see any log messages about reindexing or anything, maybe i screwed something up before and dont realize
08:09 -!- reallll [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews     
08:13 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Ping timeout: 256 seconds]     
08:55 < troygiorshev> hey everyone, we'll get started in just over an hour!
09:00 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has joined #bitcoin-core-pr-reviews     
09:22 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Ping timeout: 240 seconds]     
09:24 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-pr-reviews     
09:31 < michaelfolkson> The Hubble Space Telescope review club
09:31 -!- lightlike [~lightlike@p200300c7ef17a900b8f2655f7b7fe0a2.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews     
09:32 -!- Davterra [~Davterra@69.4.234.76] has quit [Ping timeout: 265 seconds]     
09:33 -!- Davterra [~Davterra@69.4.234.76] has joined #bitcoin-core-pr-reviews     
09:40 -!- gzhao408 [uid453516@gateway/web/irccloud.com/x-nogyhtmriloeqhsr] has joined #bitcoin-core-pr-reviews     
09:54 -!- riyasingh [~riyasingh@146.196.35.76] has joined #bitcoin-core-pr-reviews     
09:58 -!- commodore [~commodore@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews     
10:00 < troygiorshev> #startmeeting
10:00 < troygiorshev> hellooo
10:00 < commodore> hi hi
10:00 < nehan> hi     
10:00 < jkczyz> hi     
10:00 < jnewbery> hi     
10:00 < gzhao408> heyooooo
10:00 < lightlike> hi     
10:00 < troygiorshev> welcome to review club everyone!  today we'll be talking about a feature pr, adding per-peer message logging to core!
10:00 < michaelfolkson> hi     
10:01 < troygiorshev> notes and questions in the usual spot: https://bitcoincore.reviews/19509.html
10:01 < ajonas> hi     
10:01 < amiti> hi     
10:01 < troygiorshev> who's had a chance to review the pr? (y/n)
10:01 < amiti> y     
10:01 < felixweis> Hi     
10:01 < michaelfolkson> y     
10:01 < jkczyz> n     
10:02 < jnewbery> y     
10:02 < lightlike> y     
10:02 -!- ecurrencyhodler [68ac287f@cpe-104-172-40-127.socal.res.rr.com] has joined #bitcoin-core-pr-reviews     
10:02 < gzhao408> y     
10:02 < troygiorshev> awesome!
10:02 < troygiorshev> would anyone like to summarize 19509?
10:03 < troygiorshev> (for anyone lurking :D )
10:04 < michaelfolkson> Anyone new want to try to summarize? I thought your descriptions were very good troygiorshev, commit messages too
10:04 < ecurrencyhodler> It's a way to log p2p messages between nodes in Bitcoin Core.
10:04 -!- hanhua [63687d99@99-104-125-153.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-pr-reviews     
10:05 < troygiorshev> michaelfolkson: thanks!
10:05 < troygiorshev> ecurrencyhodler: yup, that's it!
10:05 < commodore> as well as code to produce json outputs for the logs
10:05 < lightlike> Adding an option to dump all p2p messages our node sends/receives into a binary file, with some tools to parse this data.
10:05 < troygiorshev> commodore lightlike: great points as well
10:06 < ariard> hi     
10:06 < troygiorshev> it's not a ton more than what it says on the tin!  important for feature PRs to be simple and well defined
10:06 < troygiorshev> ok, first question, how did you test this PR? Was setting up and running everything straightforward enough?
10:07 < ecurrencyhodler> I thought Bitcoin Core already kept track of p2p message logs through -printtoconsole. Is the difference that this would just be recorded to a file?
10:08 -!- behradkhodayar [~behrad@static.126.222.46.78.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
10:08 < amiti> my experience was smooth! I recompiled and ran my node locally with `logmessages` enabled, saw the new files in the data dir & fed them into the parser to interpret them. it was super cool!
10:09 < amiti> some other things I did to test involved adding logging to the p2p_message_logging test to see what messages are being recorded
10:09 < troygiorshev> ecurrencyhodler: good catch on that config option.  It's not quite the same though.  printtoconsole is used to print the _debug log_ to console (as opposed to file).  This PR is adding much more.  Not just debugging, it logs all of the p2p messages that your node sends back and forth, with their details in a mostly human readable form.  this isn't currently being done anywhere
10:09 < jnewbery> ecurrencyhodler: -printtoconsole prints the debug log to the console, not the p2p messages
10:10 < ecurrencyhodler> very cool ty
10:11 -!- shesek [~shesek@164.90.217.137] has joined #bitcoin-core-pr-reviews     
10:11 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]     
10:11 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews     
10:11 < jnewbery> another thing you could do to test would be to add -logmessages to the config for a functional test, then run with --nocleanup, and check the logging files that are left in the test directory
10:11 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]     
10:12 < troygiorshev> amiti: good point bringing up p2p_message_logging.py, it's becoming a very multipurpose test!
10:12 < jnewbery> I think you could just add "-logmessages" to the list here: https://github.com/bitcoin/bitcoin/blob/c6532fa6c14d3cea5941cff9411937db9a8d5f1a/test/functional/test_framework/test_node.py#L95-L102
10:13 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews     
10:13 < lightlike> though if "-net" debugging is enabled, most p2p messages get an entry in the log - so I would think that this is mostly useful for testing the low-level "net" stuff (as opposed to the net_processing higher-level logic)?
10:14 < jnewbery> lightlike: exactly. You should usually be able to trace control flow using the debug logs. This new message logging would help if you need to know the exact messages being sent/received.
10:15 < troygiorshev> lightlike: especially for beginners, or for people debugging their node, they might want to see *exactly* what's going on
10:16 < troygiorshev> next question: Did you verify that file descriptor accounting was being done correctly in the "Add LogMessage" commit?  What is the soft file descriptor limit on your system? What about the hard limit?
10:16 < troygiorshev> if you didn't find this, try `ulimit -a` and `ulimit -aH` :)
10:18 -!- riyasingh [~riyasingh@146.196.35.76] has quit [Remote host closed the connection]     
10:19 < lightlike> for me, it's 4096 "open files". Is this considerably lower on some systems?
10:19 < gzhao408> Verified to the best of my ability :P my limits say 256 and "unlimited"
10:19 < gzhao408> I have a question about why NUM_FDS_MESSAGE_LOGGING is just 1? Do we only allocate one file descriptor for all peer message logging, and we open/close every time we log so we can reuse it every time? (I could be misunderstanding how the file descriptors are used here, I’m assuming we need 1 per open file).
10:20 < troygiorshev> gzhao408: that's a great question!
10:20 < jnewbery> mine are 1024 and ~1 million
10:21 < troygiorshev> gzhao408: you have it exactly right, because we open and close every time we log, we can reuse our single file descriptor each time!
10:22 < troygiorshev> on my system I get the following:
10:22 < troygiorshev> ulimit -n:  1024
10:22 < troygiorshev> ulimit -nH: 4096
10:22 < troygiorshev> ulimit -x:  unlimited
10:23 < troygiorshev> The first two are especially important for a single process.  If a process tries to take more than its soft limit (-n) of file descriptors, the OS will kill it!
10:23 < jonatack> hi     
10:24 < troygiorshev> Any process is allowed to increse their soft limit (-n) up to but not past their hard limit (-nH)
10:24 -!- gimballock [b8a4b1b9@d-184-164-177-185.fl.cpe.atlanticbb.net] has joined #bitcoin-core-pr-reviews     
10:24 < troygiorshev> and -x is the total number available to all processes combined
10:24 -!- gimballock [b8a4b1b9@d-184-164-177-185.fl.cpe.atlanticbb.net] has quit [Remote host closed the connection]     
10:25 < troygiorshev> I can guess that gzhao408 is probably on a Mac, because they're the only modern system that has such a low limit!
10:25 < troygiorshev> lightlike: so, yeah, it is :)
10:25 < gzhao408> Does using more file descriptors help with performance? e.g. I'm guessing that writes are buffered, and you flush on close (depends on implementation) so I was curious if you had considered using 1 per peer or something? Or how you came to the conclusion of just 1?
10:25 < commodore> soft: 256, hard unlimited
10:26 < gzhao408> troygiorshev: u caught me :cold_sweat
10:26 < commodore> ulimit -S -n; ulimit -H -n #macos
10:26 < lightlike> did I read the code correctly such that this means that we need one file descriptor per peer connection, so we will be able to connect one peer less after this?
10:26 < sipa> gzhao408: if you have fewer file descriptors available, bitcoin core will just refuse to create more connections
10:26 < sipa> it doesn't change performance
10:26 < gzhao408> sipa: so the fewer the better?
10:26 < sipa> what?
10:26 < troygiorshev> lightlike: see what sipa just said, yup
10:27 < troygiorshev> lightlike: IF we don't have enough available
10:27 < sipa> gzhao408: if you want many connections you need more file descriptors
10:27 < sipa> if you don't, you don't care
10:28 < troygiorshev> gzhao408: so having one (or maybe two) file descriptors per peer could more than triple our usage!  It's possible this would bring it up to the hard limit on some systems and restrict the number of peers we could connect to
10:28 < gzhao408> Sorry I meant, I'm gathering that choosing to use 1 file descriptor is to minimize the file descriptor requirements
10:28 < felixweis> if you have low resources, you might want to reduce file descriptors if you run a pi webserver.
10:28 < troygiorshev> if anyone has found it fun diving into this file descriptor stuff, there's an issue open right now to clean it up!  #18911
10:28 < sipa> gzhao408: right
10:29 < gzhao408> thanks sipa!
10:29 < lightlike> it seems that nMaxConnections is reduced even if we don't enable the new logging option - though we probably don't care about this?
10:29 < troygiorshev> anyone interested keep going on that, I'll throw the next question down
10:29 < troygiorshev> The "Add Message Logging Test" commit adds a test. What is being tested? What isn't being tested? Should this be expanded? Did you read the out-of-tree build discussion?
10:31 < michaelfolkson> So only the structure of the message, not deserializing or order of messages or message type
10:32 < troygiorshev> michaelfolkson: yup, did you see why it was done that way?
10:32 < amiti> I think it makes sense for it to be more of a validity check & not worry about the specific messages etc.
10:32 < jnewbery> lighlike: generally, we're not at the limit of permitted file descriptors
10:32 < michaelfolkson> By too brittle you mean not the best place to test it? Test will be too unreliable?
10:34 < troygiorshev> michaelfolkson: pretty much yup!  if, say, the order of messages in our handshake changes, or the format of one changes even a little bit then the test would break!  that's too much of a pain for everyone
10:34 < felixweis> is ":" not an issue on windows filesystem?
10:34 < felixweis> for the directory name ip:port
10:36 < troygiorshev> felixweis: it almost certainly is, good catch!
10:37 < troygiorshev> looks like nobody has tested it on windows yet, and while I expect most people running the debug options will be on linux or mac, this definitely needs to be checked and fixed
10:37 < ecurrencyhodler> Sorry for the tangent. But what is the value of a PR like this? Is it purely educational? Or is there a more functional purpose such as potentially identifying a bad acting node?
10:38 < sipa> or debugging
10:39 < troygiorshev> ecurrencyhodler: not a tangent at all.  feature PRs have to be treated a little differently than refactor or bugfix prs.
10:39 < troygiorshev> ecurrencyhodler: so that sort of question is a really useful one
10:40 < ecurrencyhodler> okay whew haha
10:40 < troygiorshev> i agree with both you and sipa, educational and debugging.  though I wouldn't be surprised if someone uses it for something else some day!
10:41 < jnewbery> I'm interested in being able to see exactly what traffic I'm receiving from peers on my node
10:41 < jnewbery> particularly if I'm able to filter by version/subversion/etc
10:41 < felixweis> yeah i've tried to decypher wireshark in the past
10:42 < troygiorshev> felixweis: how did it go?
10:42 < michaelfolkson> Do a lot of contributors use Wireshark currently? I have never used it on Core. One of the thousand things I'd like to have done but haven't yet
10:42 < felixweis> too much hasstle
10:42 < troygiorshev> michaelfolkson: do you think you would use this more?
10:42 < jnewbery> I could do that using wireshark outside the software, but having a toggle in the application itself that just dumps application level data for the peers I'm interested in seems much more useful
10:42 < ecurrencyhodler> I wonder if you could you also do some data analysis on the information that's dumped? Maybe clue people in to optimizing p2p network more?
10:42 < felixweis> i've played around with this now. this gives me together with message-logging-parser.py  is the MVP
10:43 < jnewbery> felixweis: yes, wireshark is very powerful and customizable but is definitely a hassle to get what you want
10:43 < troygiorshev> ecurrencyhodler: that's a great idea!  I await your results :D
10:43 < felixweis> since the messages are POST p2p encoding. e.g. application messages
10:43 < ecurrencyhodler> hehe will do troy.
10:44 < michaelfolkson> troygiorshev: Yeah certainly more accessible
10:45 < troygiorshev> next question
10:45 < troygiorshev> The "Clean PushMessage and ProcessMessages" commit is a cleanup. Is this justified or is this just noise? When should cleanups like this be done?
10:47 < michaelfolkson> This was just style guide type stuff right?
10:48 < amiti> I am +1 for cleanup commits that are separate and its made clear that its just a cleanup
10:48 < troygiorshev> michaelfolkson: yup!
10:48 < troygiorshev> amiti: glad to hear it
10:49 < michaelfolkson> Yeah +1 don't see why not. I suppose only question is whether it should be its own PR? But I'd lean towards no
10:49 < jnewbery> amiti: I agree. If you're touching most of a function and you're going to end up changing it to use the new code style, you might as well do it in the first commit and get it out of the way
10:49 < amiti> also I've spent way too long debugging how the code broke when I just added logging, turned out it was one of those one-line-if-statements without brackets. so small stuff like this can matter.
10:50 < sipa> ifs with missing braces is one of the (few) actual known examples of coding style that has caused real world bugs
10:50 < troygiorshev> sipa: ah cool!
10:50 < sipa> in openssl, of course
10:50 < troygiorshev> 10 minutes left, last question!
10:51 < troygiorshev> Both jnewbery and practicalswift proposed extensions to this message logging. What are they? Do you agree that these are a good idea? Are there any extensions that you would like to see?
10:51 < troygiorshev> there are definitly no wrong answers to this one!
10:51 -!- behradkhodayar [~behrad@static.126.222.46.78.clients.your-server.de] has quit [Quit: Leaving]     
10:52 < jnewbery> sipa: if it's the one I'm thinking of, I think it was apple's ssl implementation that had the if braces bug
10:52 < troygiorshev> https://github.com/bitcoin/bitcoin/pull/19509#pullrequestreview-447894982
10:52 < troygiorshev> https://github.com/bitcoin/bitcoin/pull/19509#pullrequestreview-448269477
10:52 < michaelfolkson> Right so jnewbery only wants to log messages for a specific peer. To save space, make it cleaner I'm assuming
10:52 < sipa> jnewbery: you're right!
10:53 < ajonas> I love the idea of the building a fuzzing corpus
10:54 < jnewbery> ajonas: I agree. It's a great idea
10:54 < jnewbery> michaelfolkson: yes, if I want to debug interactions with an individual peer, I don't want to dump potentially 100s of MBs of traffic from other peers
10:55 < jnewbery> especially if I want to leave this running for long periods
10:55 < michaelfolkson> Makes sense. Both good suggestions
10:55 < troygiorshev> anyone tried enabling this over an entire ibd?  how large were the files?
10:56 < felixweis> this works during IBD? could be interesting to visualize peer round-robin
10:56 < jnewbery> it'd be >300GB since you'd be dumping the entire blockchain in net serialized format
10:56 < sipa> one use case i have is that when investigating the effect of some P2P change, i want to look at the exact transcript... usually not at the level of seeing all the messages, but you do want to see it per peer; using debug.log is really annoying as peer ids get reused across restarts, for example
10:57 < sipa> so having a file per peer solves that pretty elegantly
10:57 < ajonas> I did IBD on testnet with it on
10:58 < ajonas> the files were big, the python script just seemed to hang
10:58 < sipa> if i can ask: what is the rationale for splitting received/sent messages up into two files?
10:58 < felixweis> maybe a flag to limit to certain message types
10:58 < sipa> (maybe this was addressed in the PR, just tell me so if i'm missing context)
10:59 < jonatack> https://github.com/bitcoin/bitcoin/pull/19509#issuecomment-664374225
10:59 < troygiorshev> sipa: 1: saves a byte per message, 2: hypothetically someone might want to just see received or sent
10:59 < troygiorshev> one minute left!
11:00 -!- commodore [~commodore@195.181.160.175.adsl.inet-telecom.org] has quit [Ping timeout: 246 seconds]     
11:00 < jnewbery> it means we don't need to a field to indicate whether the message was outgoing or incoming. The parser can take any number of files as input, so you can use both together if you want the two-way transcript
11:00 < troygiorshev> ok that's time!  didn't get to the bonus question but anyone interested in python can find it themselves :)
11:00 < felixweis> hm maybe interweaving send/receive isn't that bad because ofthen things are request/respongs (inv/getdata, ...)
11:01 < sipa> troygiorshev: is there a way to interleave them again?
11:01 < sipa> having to look at them separately would make it very painful to use
11:01 < troygiorshev> sipa: yup! just giving both files to the parser interleaves them
11:01 < troygiorshev> it's the intended use :)
11:01 < sipa> ah great
11:01 < lightlike> can we reconstruct the time order in which messages were processed in our node, even with the splitting in two files?
11:01 < troygiorshev> thanks to everyone for coming and thanks for all of the great discussion!
11:02 < jnewbery> lightlike: yes, each message has a timestamp of sent/received time
11:02 < felixweis> thans troygiorshev
11:02 < lightlike> thanks
11:02 < jnewbery> so feeding them both into the parser will interleave them in order
11:02 < michaelfolkson> Thanks troygiorshev!
11:03 < jnewbery> the idea is that the parser is just one potential tool to analyze these files. If you want to do more quantitive analysis of the traffic, you could build a tool that parses/analyzes them in a different way.
11:03 < troygiorshev> #endmeeting
11:06 < amiti> thanks troy!
11:06 < jnewbery> thanks troy. Great meeting!
11:07 < gzhao408> thanks troy!!!
11:07 < sipa> jnewbery: of course
11:08 < jonatack> thanks, troy. getting features/tools merged isn't always easy. looking forward to seeing where this goes.
11:10 -!- commodore [~commodore@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews     
11:10 < sipa> jnewbery: indeed, apple ssl: https://blog.codecentric.de/en/2014/02/curly-braces/
11:17 < jonatack> sipa: interesting article
11:21 < commodore> reminds of engineering of train brakes
11:21 < commodore> "Air brakes on railway trains and air brakes on trucks. The brakes are held in the "off" position by air pressure created in the brake system. Should a brake line split, or a carriage become de-coupled, the air pressure will be lost and the brakes applied, by springs in the case of trucks, or by a local air reservoir in trains. It is impossible to drive a truck with a serious leak in the air brake system.
11:21 < commodore>  (Trucks may also employ wig wags to indicate low air pressure.)"
11:21 < commodore> https://en.wikipedia.org/wiki/Fail_safe
11:22 < commodore> If error -> run # bad design
11:22 < commodore> opps typo
11:22 < commodore> ':)     
11:29 -!- commodore [~commodore@195.181.160.175.adsl.inet-telecom.org] has quit [Quit: commodore]     
11:33 -!- ecurrencyhodler [68ac287f@cpe-104-172-40-127.socal.res.rr.com] has quit [Remote host closed the connection]     
11:48 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]     
11:57 -!- reallll is now known as belcher     
12:01 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Ping timeout: 240 seconds]     
12:08 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-pr-reviews     
12:31 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Ping timeout: 240 seconds]     
12:32 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-pr-reviews     
12:55 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
14:14 -!- brickinedifice [600a744a@rrcs-96-10-116-74.se.biz.rr.com] has joined #bitcoin-core-pr-reviews     
14:14 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!]     
14:19 -!- brickinedifice [600a744a@rrcs-96-10-116-74.se.biz.rr.com] has quit [Remote host closed the connection]     
14:25 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has quit [Remote host closed the connection]     
14:35 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]     
14:36 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews     
15:02 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]     
15:02 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-pr-reviews     
15:31 -!- harrigan- [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-pr-reviews     
15:33 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Ping timeout: 256 seconds]     
15:38 -!- harrigan- [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Ping timeout: 256 seconds]     
15:47 -!- lightlike [~lightlike@p200300c7ef17a900b8f2655f7b7fe0a2.dip0.t-ipconnect.de] has quit [Quit: Leaving]     
15:53 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-pr-reviews     
15:59 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]     
16:01 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Ping timeout: 240 seconds]     
16:05 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-pr-reviews     
16:10 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Ping timeout: 256 seconds]     
16:10 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
16:45 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Read error: Connection reset by peer]     
16:45 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-pr-reviews     
16:59 -!- gzhao408 [uid453516@gateway/web/irccloud.com/x-nogyhtmriloeqhsr] has quit [Quit: Connection closed for inactivity]     
17:27 -!- evanlinjin [~evanlinji@2404:4408:43ff:bb00:67a3:453a:d686:317c] has quit [Read error: Connection reset by peer]     
17:28 -!- evanlinjin [~evanlinji@2404:4408:43ff:bb00:67a3:453a:d686:317c] has joined #bitcoin-core-pr-reviews     
17:34 -!- wullon58 [~wullon@241.243.86.88.rdns.comcable.net] has quit [Ping timeout: 256 seconds]     
17:42 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 240 seconds]     
17:43 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-pr-reviews     
17:54 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds]     
18:08 -!- seven_ [~seven@2a00:ee2:410c:1300:114b:c702:bd4f:127e] has quit [Read error: Connection reset by peer]     
18:17 -!- wullon58 [~wullon@241.243.86.88.rdns.comcable.net] has joined #bitcoin-core-pr-reviews     
19:12 -!- wullon58 [~wullon@241.243.86.88.rdns.comcable.net] has quit [Ping timeout: 260 seconds]     
19:25 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]     
19:25 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection]     
19:25 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]     
19:26 -!- sipa [~pw@unaffiliated/sipa1024] has joined #bitcoin-core-pr-reviews     
19:26 -!- ghost43 [~daer@unaffiliated/daer] has joined #bitcoin-core-pr-reviews     
19:26 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews     
19:37 -!- troygiorshev [~troygiors@d67-193-140-136.home3.cgocable.net] has quit [Quit: leaving]     
19:48 -!- wullon58 [~wullon@241.243.86.88.rdns.comcable.net] has joined #bitcoin-core-pr-reviews     
20:31 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has quit [Read error: Connection reset by peer]     
20:31 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has joined #bitcoin-core-pr-reviews     
20:41 -!- harrigan [~harrigan@ptr-93-89-242-202.ip.airwire.ie] has joined #bitcoin-core-pr-reviews     
20:46 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has quit [Read error: Connection reset by peer]     
20:47 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has joined #bitcoin-core-pr-reviews     
20:49 -!- hanhua [63687d99@99-104-125-153.lightspeed.sntcca.sbcglobal.net] has quit [Ping timeout: 245 seconds]     
21:02 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has quit [Read error: Connection reset by peer]     
21:02 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has joined #bitcoin-core-pr-reviews     
21:06 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]     
21:07 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews     
21:18 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has quit [Read error: Connection reset by peer]     
21:18 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has joined #bitcoin-core-pr-reviews     
21:23 -!- harrigan [~harrigan@ptr-93-89-242-202.ip.airwire.ie] has quit [Read error: Connection reset by peer]     
21:25 -!- harrigan [~harrigan@ptr-93-89-242-202.ip.airwire.ie] has joined #bitcoin-core-pr-reviews     
21:33 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has quit [Read error: Connection reset by peer]     
21:34 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has joined #bitcoin-core-pr-reviews     
21:44 -!- harrigan [~harrigan@ptr-93-89-242-202.ip.airwire.ie] has quit [Read error: Connection reset by peer]     
21:45 -!- harrigan [~harrigan@ptr-93-89-242-202.ip.airwire.ie] has joined #bitcoin-core-pr-reviews     
21:49 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has quit [Read error: Connection reset by peer]     
21:49 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has joined #bitcoin-core-pr-reviews     
22:05 -!- harrigan [~harrigan@ptr-93-89-242-202.ip.airwire.ie] has quit [Read error: Connection reset by peer]     
22:05 -!- harrigan [~harrigan@ptr-93-89-242-202.ip.airwire.ie] has joined #bitcoin-core-pr-reviews     
22:05 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has quit [Read error: Connection reset by peer]     
22:05 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has joined #bitcoin-core-pr-reviews     
22:06 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]     
22:16 -!- evanlinjin [~evanlinji@2404:4408:43ff:bb00:67a3:453a:d686:317c] has quit [Quit: Konversation terminated!]     
22:20 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has quit [Read error: Connection reset by peer]     
22:21 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has joined #bitcoin-core-pr-reviews     
22:36 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has quit [Read error: Connection reset by peer]     
22:36 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has joined #bitcoin-core-pr-reviews     
22:37 -!- shesek [~shesek@164.90.217.137] has joined #bitcoin-core-pr-reviews     
22:38 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]     
22:38 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews     
22:38 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]     
22:38 -!- shesek [~shesek@164.90.217.137] has joined #bitcoin-core-pr-reviews     
22:38 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]     
22:38 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews     
22:46 -!- harrigan [~harrigan@ptr-93-89-242-202.ip.airwire.ie] has quit [Read error: Connection reset by peer]     
22:48 -!- harrigan [~harrigan@ptr-93-89-242-202.ip.airwire.ie] has joined #bitcoin-core-pr-reviews     
22:52 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has quit [Read error: Connection reset by peer]     
22:52 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has joined #bitcoin-core-pr-reviews     
22:56 -!- peltre [sid268329@gateway/web/irccloud.com/x-nytfjnuxesrlmope] has quit [Ping timeout: 246 seconds]     
22:56 -!- peltre [sid268329@gateway/web/irccloud.com/session] has joined #bitcoin-core-pr-reviews     
23:02 -!- aj [aj@cerulean.erisian.com.au] has quit [Ping timeout: 256 seconds]     
23:03 -!- aj [aj@139.162.42.226] has joined #bitcoin-core-pr-reviews     
23:07 -!- wullon58 [~wullon@241.243.86.88.rdns.comcable.net] has quit [Quit: Ping timeout (120 seconds)]     
23:07 -!- harrigan [~harrigan@ptr-93-89-242-202.ip.airwire.ie] has quit [Read error: Connection reset by peer]     
23:07 -!- wullon58 [~wullon@241.243.86.88.rdns.comcable.net] has joined #bitcoin-core-pr-reviews     
23:07 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has quit [Read error: Connection reset by peer]     
23:08 -!- harrigan [~harrigan@ptr-93-89-242-202.ip.airwire.ie] has joined #bitcoin-core-pr-reviews     
23:08 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has joined #bitcoin-core-pr-reviews     
23:23 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has quit [Read error: Connection reset by peer]     
23:24 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has joined #bitcoin-core-pr-reviews     
23:27 -!- harrigan [~harrigan@ptr-93-89-242-202.ip.airwire.ie] has quit [Read error: Connection reset by peer]     
23:29 -!- harrigan [~harrigan@ptr-93-89-242-202.ip.airwire.ie] has joined #bitcoin-core-pr-reviews     
23:39 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has quit [Read error: Connection reset by peer]     
23:39 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has joined #bitcoin-core-pr-reviews     
23:48 -!- harrigan [~harrigan@ptr-93-89-242-202.ip.airwire.ie] has quit [Read error: Connection reset by peer]     
23:49 -!- harrigan [~harrigan@ptr-93-89-242-202.ip.airwire.ie] has joined #bitcoin-core-pr-reviews     
23:55 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has quit [Read error: Connection reset by peer]     
23:55 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has joined #bitcoin-core-pr-reviews