--- Day changed Wed Jul 24 2019
00:28 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-jzwnvoevrxrrshiu] has quit [Quit: Connection closed for inactivity]     
01:36 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-pr-reviews     
02:09 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-pr-reviews     
02:32 -!- jonatack [d598a259@213.152.162.89] has quit [Remote host closed the connection]     
03:08 -!- tuirektiujm[m] [tuirektiuj@gateway/shell/matrix.org/x-tdjpyifvaedkwljm] has quit [Ping timeout: 250 seconds]     
03:49 -!- tuirektiujm[m] [tuirektiuj@gateway/shell/matrix.org/x-avbcvmonjmubrpvl] has joined #bitcoin-core-pr-reviews     
04:30 -!- Netsplit *.net <-> *.split quits: tuirektiujm[m]
04:37 -!- Netsplit over, joins: tuirektiujm[m]
06:18 -!- pinheadmz [~matthewzi@207.189.24.147] has joined #bitcoin-core-pr-reviews     
06:25 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 258 seconds]     
06:56 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-neblnlgotdayqnjg] has joined #bitcoin-core-pr-reviews     
06:58 -!- davterra [~none@195.242.213.120] has joined #bitcoin-core-pr-reviews     
07:03 -!- shesek [~shesek@141.226.145.179] has joined #bitcoin-core-pr-reviews     
07:03 -!- shesek [~shesek@141.226.145.179] has quit [Changing host]     
07:03 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews     
07:03 -!- davterra [~none@195.242.213.120] has quit [Ping timeout: 248 seconds]     
07:04 -!- davterra [~none@195.242.213.120] has joined #bitcoin-core-pr-reviews     
08:09 -!- jnewbery [~john@rrcs-184-74-240-156.nyc.biz.rr.com] has quit [Ping timeout: 246 seconds]     
08:09 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Ping timeout: 260 seconds]     
08:14 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/]     
08:15 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-pr-reviews     
08:16 -!- jnewbery [~john@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #bitcoin-core-pr-reviews     
08:37 -!- jonatack [d598a259@213.152.162.89] has joined #bitcoin-core-pr-reviews     
09:01 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 245 seconds]     
09:22 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Ping timeout: 260 seconds]     
09:23 -!- jnewbery [~john@rrcs-184-74-240-156.nyc.biz.rr.com] has quit [Ping timeout: 245 seconds]     
09:27 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-pr-reviews     
09:30 -!- jnewbery [~john@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #bitcoin-core-pr-reviews     
09:34 < jnewbery> Hi folks. We'll get started in around 25 minutes
09:39 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Ping timeout: 260 seconds]     
09:39 -!- jnewbery [~john@rrcs-184-74-240-156.nyc.biz.rr.com] has quit [Ping timeout: 268 seconds]     
09:46 -!- john____ [~john@ip-184-207-115-226.nymnny.spcsdns.net] has joined #bitcoin-core-pr-reviews     
09:47 -!- corey [cc9ca366@204.156.163.102] has joined #bitcoin-core-pr-reviews     
09:47 -!- corey is now known as Guest59965     
09:48 -!- Guest59965 is now known as coreybt     
09:49 -!- csknk [~csknk@unaffiliated/csknk] has joined #bitcoin-core-pr-reviews     
09:55 -!- john____ is now known as jnewbery     
09:56 -!- jkczyz [~jkczyz@104.133.8.66] has joined #bitcoin-core-pr-reviews     
09:57 -!- bpo [~bpo@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews     
09:58 -!- lightlike [~lightlike@2001:16b8:57e8:5b00:f599:4455:3c73:d4b0] has joined #bitcoin-core-pr-reviews     
10:00 < jnewbery> hi     
10:00 -!- shesek [~shesek@bzq-218-147-172.cablep.bezeqint.net] has joined #bitcoin-core-pr-reviews     
10:00 -!- shesek [~shesek@bzq-218-147-172.cablep.bezeqint.net] has quit [Changing host]     
10:00 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews     
10:00  * bpo wave
10:00 < lightlike> hi     
10:00 < ariard> hi     
10:01 < emzy> hi     
10:01  * jkczyz waves
10:01 < fjahr> hi     
10:01 < jnewbery> Hi folks, we’re having internet issues at the office, so my connectivity might be intermittent
10:01 < jonatack> hi !
10:01 < jonatack>  * wipes sweat from sweltering brow in the heatwave
10:02 < amiti> hi     
10:02 < davterra> hi all
10:02 < jnewbery> Before we begin, I'd like to encourage everyone to leave review comments on github. Review club should be here to help answer your questions, but the point is to give you the knowledge and tools to take part in the review process
10:03 < jnewbery> even if your comment is "I built and tested this PR by doing <x>", that's still helpful!
10:03 < jnewbery> ok, onto this week's PR: https://github.com/bitcoin/bitcoin/pull/15713
10:04 < jnewbery> Did people have a chance to build, review and read the notes/questions at https://bitcoin-core-review-club.github.io/15713.html ?
10:04 -!- ajonas [~ajonas@167.71.185.62] has joined #bitcoin-core-pr-reviews     
10:04 < jonatack> done
10:04 < bpo> I haven't but going to try to follow along as best I can
10:04 < amiti> q: with PRs like this that have multiple commits, do you often go through and make sure they all build & pass tests separately?
10:04 < amiti> seems ... tedious
10:05 < jkczyz> I briefly reviewed and read through comments
10:05 < lightlike> built it and looked at code
10:05 < jnewbery> amiti: I don't run tests on all commits, but I might build commits if I suspect there might be build issues
10:06 < jnewbery> first question: Why is the wallet able to directly call functionality to broadcast transactions to peers?
10:06 < jkczyz> It's running in the same process?
10:07 -!- michaelfolkson [~textual@82-132-221-26.dab.02.net] has joined #bitcoin-core-pr-reviews     
10:07 < jnewbery> jkczyz: that's true, but perhaps I should rephrase my question: "Why does the wallet call functionality directly?"
10:07 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-pr-reviews     
10:07 < jonatack> The wallet still relays txns
10:08 < jnewbery> jonatack: that's correct. The reason it does that is historic.
10:08 < jnewbery> if you look back through the git history, you'll see that the wallet and node functionality were much more mixed up in earlier versions
10:09 < jnewbery> we're trying to separate out the wallet from the node, and the fact that the wallet can tell the node to relay transactions to peers is really a hangover from when it was more mixed up
10:09 < jnewbery> Next question: What is a transaction rebroadcast? How (and how often) are they currently triggered?
10:11 < jonatack> * cue up amiti
10:11 < amiti> when a new block comes in, a node will rebroadcast any wallet txns that were not confirmed (with a variable delay)
10:11 < emzy> It is rebroadcasted if it is not included in a block.
10:11 < jnewbery> amiti: emzy: that's right!
10:12 < jnewbery> The code for that is here: https://github.com/bitcoin/bitcoin/blob/0626b8cbdf0aa971500eb5613c7ab4096c496966/src/wallet/wallet.cpp#L2327
10:13 < emzy> oh nice it is random.
10:13 < bpo> All wallets rebroadcast all transactions if the wallet sees that a new chain tip doesn't include the wallet's transactions?  Isn't that a large overhead?
10:13 < lightlike> why is the reboradcast done that often? Shouldn't the tx have propagated into enough peers' mempools after the first relay?
10:13 < jnewbery> Note that we won't rebroadcast every block. There's a random timer before each resend
10:14 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 245 seconds]     
10:14 < harding> As an aside, transaction rebroadcast is really useful if your node didn't have any peers at the time you created your transaction, perhaps because you were having issues with Internet at the office.  :-)
10:14 < bpo> lol     
10:14 < hugohn> is it based on the arrival of a new block or a periodic schedule? I looked up who calls MabeResendWalletTxs() & it seems it's only called by the scheduler?
10:14 < hugohn> *scheduler
10:15 < jnewbery> bpo: lightlike: the rebroadcast logic right now isn't great. The main purpose it's serving is to make sure that your transaction doesn't get dropped. Like harding says, that's mostly useful if you tried to send the tx when you didn't have connectivity
10:15 < emzy> But sometimes you like to lose the transaction and don't rebroadcast.
10:15 < jnewbery> the downside is that it's terrible for privacy
10:16 < jnewbery> amiti has a proposal to improve rebroadcast logic here: https://gist.github.com/amitiuttarwar/b592ee410e1f02ac0d44fcbed4621dba
10:16 < bpo> jnewbery so I potential improvement would be to have logic that would estimate how likely that your txn was received by peers (If transaction was relayed when node had no peers, try again when I have peers)
10:16 < bpo> reviewing b592 now
10:17 < michaelfolkson> When the node and wallet are eventually entirely separated your node will rebroadcast other people's transactions as well as your own?
10:17 < jnewbery> hugohn: it's based on both. I can't remember the exact logic, but the idea is that we won't rebroadcast too frequently (that's the part that's handled by the scheduler), and we only rebroadcast after a block is received
10:17 < amiti> michaelfolkson: as per my proposal, yes
10:18 < jnewbery> michaelfolkson: we don't need to wait for full separation for that
10:18 < michaelfolkson> Just for the privacy benefit? Or because that helps other people's transactions be propagated (in the case that they have bad connectivity)?
10:18 < jnewbery> but yes, rebroadcasting transactions that aren't yours is how we preserve privacy
10:19 < jnewbery> Next question: What are some reasons that submitting a transaction to the mempool might fail?
10:19 < jnewbery> hint: take a look at AcceptToMemoryPoolWorker()
10:20 < emzy> invalid transaction
10:20 < hugohn> non-standard txs
10:20 < bpo> mempool overflow, network segmentation to miners
10:20 < lightlike> https://github.com/bitcoin/bitcoin/pull/15713#discussion_r306122680 :-)
10:20 < jnewbery> emzy: hugohn: yes, txs could be consensus-invalid or policy-invalid
10:20 < hugohn> RBF tx that violates RBF rules
10:21 < jonatack> No transactions are allowed below minRelayTxFee
10:21 < jnewbery> lightlike: yeah, that's pretty comprehensive :)
10:22 < michaelfolkson> MAX_FEE_EXCEEDED?!
10:22 < emzy> Dublicate transaction
10:22 < harding> A feerate below the node's current dynamic minimum feerate (BIP133).
10:22 < michaelfolkson> Didn't realize there was a max
10:23 < lightlike> there is some logic to prevent "absurd"ly high fees afaik
10:23 < jnewbery> michaelfolkson: Yeah, MAX_FEE_EXCEEDED is pretty weird. When we submit a transaction to the mempool locally, we set a max feerate to make sure we don't accidentally set a huge feerate.
10:23 < emzy> michaelfolkson: somtimes there was a transcations with way to much fee. like you forget to include one output
10:24 < harding> A transaction that's not valid now, but will be valid after a BIP9 soft fork transitions to activated.
10:24 < jnewbery> that's only for txs submitted to the mempool from an RPC like `sendrawtransaction` or by the wallet
10:24 < jonatack> git grep -ni absurd
10:24 < harding> Um, s/valid/policy allowed/g
10:24 < jnewbery> if we receive a tx over P2P, we don't reject it for 'absurdly high fee'
10:24 < michaelfolkson> Plenty of tales of people making that mistake and losing all their money to fees. Didn't realize there was this check
10:25 < michaelfolkson> But sorry I'm derailing discussion
10:25 < jnewbery> (I'd like to remove that argument from the AcceptToMemoryPool() interface and have the client check before submitting it. WIP PR here: https://github.com/bitcoin/bitcoin/pull/15810)
10:26 < jnewbery> harding: that's a good one. I think it's pretty rare that we make policy looser (ie more permissive), but one example is making segwit v1+ segwit txs standard recently
10:26 < harding> Another set of reasons would be because of ancestor limits.
10:27 < jnewbery> harding: yes ancestor/descendant size and count limits
10:27 < jnewbery> ok, so why in the interface method do we only care about a subset of those errors: https://github.com/bitcoin/bitcoin/pull/15713/commits/f2da7210c8e3f9ab5a5dac7b3c39bf9f0252faf7#diff-a6585739217ca647d3f10c40cccff7f1R305
10:29 < hugohn> because presumably when constructing the tx from the wallet, it should already perform all the other checks?
10:30 < jnewbery> hugohn: not quite. The answer is in the comment above the line I linked to
10:30 < jonatack> "Chain clients only care about failures to accept the tx to the mempool. Disregard non-mempool related failures" ?\
10:31 < jnewbery> This PR is a refactor, so we're trying to maintain behaviour from before the PR
10:33 < harding> So if the wallet created a consensus-invalid transaction, we don't worry about it here (doesn't matter---it'll never confirm anyway).  We only care about mempool errors that might be temporary and that we can get around by rebroadcasting?
10:33 < jnewbery> check where the new broadcastTransaction() interface method is called, and the code that it is replacing
10:34 < lightlike> Wouldn't it be better if the wallet knew and cared if its tx is accepted to the mempool but not relayed because P2P is not working?
10:34 < jnewbery> so if the tx gets into the mempool, but is not relayed to peers because P2P is disabled, the wallet still considers it successful
10:35 < jnewbery> lightlike: potentially yes, but we don't do anything about it now. This PR doesn't change that
10:35 < jnewbery> lightlike: what different behaviour would you like to see if the wallet knew about it?
10:36 < lightlike> jnewbery: maybe alert the user at least.
10:36 < jnewbery> yes, I could imagine that being useful
10:36 < jnewbery> ok, final question: What do we mean by locking order? Why must locks always be acquired in the same order?
10:36 < lightlike> jnewbery: and possibly some faster rebroadcast tries
10:37 < hugohn> potential deadlocks
10:37 < jkczyz> The order in which locks are acquired and released to avoid deadlocks
10:38 < jnewbery> lighlike: maybe. I think that would go away once amiti's proposal is implemented. It'd be the node/mempool's responsibility to rebroadcast once it has peers
10:38 < jonatack> for thread consistency
10:38 < jnewbery> hugohn: jkczyz: correct. If one thread acquires lock A then lock B, and another acquires lock B then lock A, then there could be a deadlock
10:38 < jonatack> unless the locks can be acquired in a single op with std::lock
10:39 < jnewbery> there's a build flag that will check lock orders. I can't remember what it's called, but we run it on at least one travis job
10:39 < ariard> --enable-debug
10:39 < jnewbery> thanks ariard!
10:40 < jnewbery> The last PR in this sequence is https://github.com/bitcoin/bitcoin/pull/16426 which actually reverses the cs_main / cs_wallet lock order
10:40 < hugohn> probably should have a wrapper locking method & make the individual locks private, to ensure the right order is always honored
10:40 < jnewbery> currently we have to take cs_main before we take cs_wallet. After 16426, it'll be the other way round
10:41 < jnewbery> Were there any other general questions about the PR?
10:41 < hugohn> or better yet, remove locks altogether! which ariard is working on 🙂
10:41 < hugohn> question about https://github.com/bitcoin/bitcoin/pull/15713/files#diff-b2bb174788c7409b671c46ccc86034bdL2024
10:42 < hugohn> I see we're removing GetDepthInMainChain() & IsCoinBase() checks in wallet.cpp
10:42 < amiti> I also have a question- can you help me understand the `NODISCARD` thing here? https://github.com/bitcoin/bitcoin/pull/15713/files?file-filters%5B%5D=.h#diff-3f841b5d557d579ef74c43ff582b16ebL22
10:42 < hugohn> is it because those are already checked by ATMP?
10:42 < jnewbery> hugohn: they're already checked by BroadcastTransaction() in node/transaction.cpp I think
10:43 < jnewbery> amiti: I believe it just means that the return value shouldn't be dropped
10:43 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 246 seconds]     
10:43 < hugohn> I see. I also see a IsCoinBase() check in ATMP. So perhaps redundant hmm?
10:44 < jnewbery> ie it's forbidden to call this function without assigning the return value to something
10:44 < harding> hugohn: ATMP is really meant to run on transactions you receive from other nodes, and you don't want other nodes sending you loose coinbase transactions.
10:45 < jnewbery> looks like NODISCARD was added here: https://github.com/bitcoin/bitcoin/pull/13815
10:46 < hugohn> harding: you mean we shouldn't rely on ATMP checks for our own txs? they both route to the same path though yeah? I suppose defensive programming doesn't hurt
10:46 < jonatack>  Question: Should there be tests for the changed code? SubmitMemoryPoolAndRelay? As someone who is in the habit of TDD, this seems somewhat... precarious :D
10:46 < amiti> jnewbery: cool, thanks.I found the definition in `attributes.h` but didn't know how to interpret what its doing
10:47 < jnewbery> jonatack: how would you go about testing this?
10:48 -!- jonatack [d598a259@213.152.162.89] has quit [Remote host closed the connection]     
10:49 < jnewbery> some of the functionality is moving across the interface border from the wallet to the node (eg the IsCoinBase() and GetDepthInMainChain() checks that used to be in RelayWalletTransction())
10:49 -!- jonatack [d598a259@213.152.162.89] has joined #bitcoin-core-pr-reviews     
10:49 < jonatack> Apologies, lost the connection
10:50 < jnewbery> So I don't think you could test no regressions in unit tests
10:50 < jnewbery> I think this code should be fairly well covered by the functional tests
10:51 < jonatack> For example, when I find myself writing code comments like "  // Note: this will need to be updated if BroadcastTransactions() is updated to return other non-mempool failures        // that Chain clients do not need to know about."
10:51 < harding> hugohn: sorry, looks like I misunderstood you.  I thought you were proposing to remove code from ATMP.
10:52 < jonatack> ... I try to add a test to ensure that.
10:53 < jonatack> (Perhaps the way the codebase is currently structured makes testing difficult, thus my question)
10:53 < jnewbery> Yeah, ajtowns had a suggestion for that here: https://github.com/bitcoin/bitcoin/pull/15713#discussion_r306122680
10:54 < jnewbery> I don't have any great suggestions
10:54 < jnewbery> ok, 5 minutes left. Any last minute questions?
10:54 -!- sdaftuar_ [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-pr-reviews     
10:54 < jkczyz> Could you clarify the outcome of the discussion around the addition of the relay parameter to BroadcastTransaction?
10:55 < jkczyz> err to SubmitMemoryPoolAndRelay?
10:55 < hugohn> harding: ah ok, yeah. not removing anything from ATMP, but perhaps leveraging ATMP logic to avoid redundant checks.
10:57 < jnewbery> jkczyz: I don't think the interface methods that we end up with in this PR are ideal. I'd prefer to see something like https://gist.github.com/amitiuttarwar/b592ee410e1f02ac0d44fcbed4621dba implemented so the wallet has no access to relaying txs.
10:57 < hugohn> since ATMP seems like the common entry point for all txs (external or internal, broadcast or rebroadcast)
10:58 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Ping timeout: 260 seconds]     
10:58 < jnewbery> BUT, this gets us closer to https://github.com/bitcoin/bitcoin/pull/16426, which is definitely a good change
10:58 < jkczyz> got it, thanks!
10:58 < harding> hugohn: that makes sense to me.
10:58 < amiti> jkczyz: the relay param is needed mainly for `ResendWalletTransactions` to force the node relaying txns that would otherwise not be sent out due to the checks in `BroadcastTransaction`. my proposed changes to rebroadcast logic should make a cleaner separation between wallet & node and allow us to remove that relay param
10:58 < amiti> delay in send... internet struggles
10:59 < jonatack> amiti: nice :+1:
10:59 -!- ajonas [~ajonas@167.71.185.62] has quit [Ping timeout: 248 seconds]     
11:00 -!- sdaftuar_ [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Ping timeout: 260 seconds]     
11:00 < jnewbery> ok, let's wrap it up there. Reminder that next week we'll look at https://github.com/bitcoin/bitcoin/pull/15505. It's been closed, but it's still an interesting PR, and if enough of us review it, maybe we can get it opened again and merged!
11:01 < jnewbery> thanks everyone!
11:01 < lightlike> thanks!
11:01 < jonatack> thanks!
11:01 < michaelfolkson> Thanks :)
11:01 < hugohn> thanks jnewbery & everyone
11:02 < emzy> Thanks!
11:02 < amiti> thanks !
11:02 < jkczyz> likeise
11:02 < fjahr> thanks!
11:02 -!- ajonas [~ajonas@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #bitcoin-core-pr-reviews     
11:02 < jonatack> (ariard and amiti: great work * clapping
11:03 -!- sdaftuar_ [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-pr-reviews     
11:03 -!- jkczyz [~jkczyz@104.133.8.66] has left #bitcoin-core-pr-reviews []     
11:05 -!- ajonas [~ajonas@rrcs-184-74-240-156.nyc.biz.rr.com] has quit [Read error: Connection reset by peer]     
11:06 -!- jnewbery_ [~john@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #bitcoin-core-pr-reviews     
11:07 -!- ajonas [~ajonas@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #bitcoin-core-pr-reviews     
11:10 -!- ajonas [~ajonas@rrcs-184-74-240-156.nyc.biz.rr.com] has quit [Client Quit]     
11:11 -!- csknk [~csknk@unaffiliated/csknk] has quit [Quit: leaving]     
11:14 -!- michaelfolkson [~textual@82-132-221-26.dab.02.net] has quit [Quit: Sleep mode]     
11:19 -!- f1323l [68840b4a@104.132.11.74] has joined #bitcoin-core-pr-reviews     
11:20 -!- f1323l [68840b4a@104.132.11.74] has quit [Remote host closed the connection]     
11:21 -!- f499l [68840b4a@104.132.11.74] has joined #bitcoin-core-pr-reviews     
11:23 -!- f499l [68840b4a@104.132.11.74] has quit [Remote host closed the connection]     
11:35 -!- bpo [~bpo@195.181.160.175.adsl.inet-telecom.org] has quit [Quit: bpo]     
11:53 -!- coreybt [cc9ca366@204.156.163.102] has quit [Remote host closed the connection]     
12:04 -!- jnewbery [~john@ip-184-207-115-226.nymnny.spcsdns.net] has quit [Ping timeout: 245 seconds]     
12:15 -!- jonatack [d598a259@213.152.162.89] has quit [Remote host closed the connection]     
12:34 -!- jonatack [d598a259@213.152.162.89] has joined #bitcoin-core-pr-reviews     
12:52 -!- davterra [~none@195.242.213.120] has quit [Remote host closed the connection]     
12:52 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-pr-reviews     
12:52 -!- davterra [~none@195.242.213.120] has joined #bitcoin-core-pr-reviews     
12:58 -!- davterra [~none@195.242.213.120] has quit [Quit: Leaving]     
12:58 -!- davterra [~none@195.242.213.120] has joined #bitcoin-core-pr-reviews     
12:59 -!- davterra [~none@195.242.213.120] has quit [Remote host closed the connection]     
12:59 -!- davterra [~none@195.242.213.120] has joined #bitcoin-core-pr-reviews     
13:23 -!- michaelfolkson [~textual@92.19.76.0] has joined #bitcoin-core-pr-reviews     
13:26 -!- michaelfolkson [~textual@92.19.76.0] has quit [Client Quit]     
14:05 -!- hebasto [~hebasto@95.164.65.194] has quit [Read error: Connection reset by peer]     
14:05 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-pr-reviews     
14:13 -!- michaelfolkson [~textual@92.19.76.0] has joined #bitcoin-core-pr-reviews     
14:15 -!- hebasto [~hebasto@95.164.65.194] has quit [Read error: Connection reset by peer]     
14:15 -!- hebasto_ [~hebasto@95.164.65.194] has joined #bitcoin-core-pr-reviews     
14:22 -!- michaelfolkson [~textual@92.19.76.0] has quit [Quit: Sleep mode]     
14:57 -!- jnewbery [~john@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #bitcoin-core-pr-reviews     
14:58 -!- jnewbery is now known as Guest34423     
14:58 -!- lightlike [~lightlike@2001:16b8:57e8:5b00:f599:4455:3c73:d4b0] has left #bitcoin-core-pr-reviews ["Leaving"]     
15:02 -!- Guest34423 [~john@rrcs-184-74-240-156.nyc.biz.rr.com] has quit [Ping timeout: 244 seconds]     
15:13 -!- jnewbery1 [~john@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #bitcoin-core-pr-reviews     
15:18 -!- jnewbery1 [~john@rrcs-184-74-240-156.nyc.biz.rr.com] has quit [Ping timeout: 258 seconds]     
15:28 -!- michaelfolkson [~textual@92.19.76.0] has joined #bitcoin-core-pr-reviews     
15:38 -!- michaelfolkson [~textual@92.19.76.0] has quit [Quit: Sleep mode]     
15:40 -!- michaelfolkson [~textual@92.19.76.0] has joined #bitcoin-core-pr-reviews     
15:57 -!- michaelfolkson [~textual@92.19.76.0] has quit [Quit: Sleep mode]     
16:06 -!- michaelfolkson [~textual@92.19.76.0] has joined #bitcoin-core-pr-reviews     
16:08 -!- davterra [~none@195.242.213.120] has quit [Quit: Leaving]     
16:17 -!- michaelfolkson [~textual@92.19.76.0] has quit [Quit: Sleep mode]     
17:14 -!- jnewbery [~john@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #bitcoin-core-pr-reviews     
17:14 -!- jnewbery is now known as Guest56187     
17:18 -!- Guest56187 [~john@rrcs-184-74-240-156.nyc.biz.rr.com] has quit [Ping timeout: 245 seconds]     
19:15 -!- jnewbery [~john@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #bitcoin-core-pr-reviews     
19:15 -!- jnewbery is now known as Guest23504     
19:19 -!- Guest23504 [~john@rrcs-184-74-240-156.nyc.biz.rr.com] has quit [Ping timeout: 246 seconds]     
19:25 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-neblnlgotdayqnjg] has quit [Quit: Connection closed for inactivity]     
19:45 -!- pinheadmz [~matthewzi@207.189.24.147] has quit [Read error: Connection reset by peer]     
19:49 -!- pinheadmz [~matthewzi@cpe-68-173-75-211.nyc.res.rr.com] has joined #bitcoin-core-pr-reviews     
20:52 -!- hebasto_ [~hebasto@95.164.65.194] has quit [Remote host closed the connection]     
21:16 -!- jnewbery [~john@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #bitcoin-core-pr-reviews     
21:16 -!- jnewbery is now known as Guest39181     
21:20 -!- Guest39181 [~john@rrcs-184-74-240-156.nyc.biz.rr.com] has quit [Ping timeout: 244 seconds]     
21:37 -!- pinheadmz [~matthewzi@cpe-68-173-75-211.nyc.res.rr.com] has quit [Quit: pinheadmz]     
21:41 -!- pinheadmz [~matthewzi@184.170.246.164] has joined #bitcoin-core-pr-reviews     
23:17 -!- jnewbery [~john@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #bitcoin-core-pr-reviews     
23:17 -!- jnewbery is now known as Guest14280     
23:21 -!- Guest14280 [~john@rrcs-184-74-240-156.nyc.biz.rr.com] has quit [Ping timeout: 244 seconds]