--- Log opened Wed Dec 26 00:00:05 2018
00:04 -!- harrymm [~harrymm@mx-ll-223.204.198-37.dynamic.3bb.co.th] has joined #bitcoin-core-dev
00:32 -!- tiagotrs [~user@unaffiliated/tiagotrs] has joined #bitcoin-core-dev
00:37 -!- harrymm [~harrymm@mx-ll-223.204.198-37.dynamic.3bb.co.th] has quit [Ping timeout: 246 seconds]
00:50 -!- harrymm [~harrymm@69.161.195.103] has joined #bitcoin-core-dev
01:01 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-nrgbenpcgnfxidig] has joined #bitcoin-core-dev
01:04 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
01:34 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-dev
01:50 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #bitcoin-core-dev
02:02 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
02:47 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
02:56 -!- harrymm [~harrymm@69.161.195.103] has quit []
03:02 -!- rh0nj [~rh0nj@136.243.139.96] has quit [Remote host closed the connection]
03:03 -!- rh0nj [~rh0nj@136.243.139.96] has joined #bitcoin-core-dev
03:35 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
03:40 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
03:56 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
04:06 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Quit: Leaving]
04:06 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev
04:14 -!- Yaggi [910ec76e@gateway/web/freenode/ip.145.14.199.110] has joined #bitcoin-core-dev
04:25 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
04:29 < fanquake> wumpus are you around tonight?
04:36 -!- Yaggi [910ec76e@gateway/web/freenode/ip.145.14.199.110] has quit [Ping timeout: 256 seconds]
04:46 -!- YAGGI [910ec76e@gateway/web/freenode/ip.145.14.199.110] has joined #bitcoin-core-dev
05:10 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
05:17 -!- YAGGI [910ec76e@gateway/web/freenode/ip.145.14.199.110] has quit [Ping timeout: 256 seconds]
05:26 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 272 seconds]
05:30 -!- bsm117532 [~mcelrath@c-24-61-184-150.hsd1.ma.comcast.net] has joined #bitcoin-core-dev
05:37 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has joined #bitcoin-core-dev
05:52 -!- mistergold [~mistergol@37.19.108.39] has joined #bitcoin-core-dev
05:54 -!- cluelessperson [~cluelessp@2604:4080:1326:83c5:604f:2ff:fe8e:c545] has joined #bitcoin-core-dev
05:54 -!- cluelessperson is now known as Guest88093
05:56 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-tzrsngfjwbvvlkbb] has joined #bitcoin-core-dev
05:56 < bitcoin-git> [bitcoin] hebasto opened pull request #15038: docs: Get more info about GUI-related issue on Linux (master...20181226-issue-template-gui-linux) https://github.com/bitcoin/bitcoin/pull/15038
05:56 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-tzrsngfjwbvvlkbb] has left #bitcoin-core-dev []
06:04 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Quit: quit]
06:04 -!- Guest88093 [~cluelessp@2604:4080:1326:83c5:604f:2ff:fe8e:c545] has quit [Quit: Laters]
06:07 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #bitcoin-core-dev
06:08 -!- cluelessperson [~cluelessp@unaffiliated/cluelessperson] has joined #bitcoin-core-dev
06:31 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 250 seconds]
06:54 -!- jpe [~jpe@2001:16b8:48db:900:dc86:9c39:a6e8:8d3e] has joined #bitcoin-core-dev
06:55 -!- mistergold [~mistergol@37.19.108.39] has quit [Read error: Connection reset by peer]
06:59 -!- fabianfabian [~fabianfab@D9656CCE.cm-27.dynamic.ziggo.nl] has joined #bitcoin-core-dev
07:03 < wumpus> fanquake: maybe a bit
07:04 -!- rh0nj [~rh0nj@136.243.139.96] has quit [Remote host closed the connection]
07:05 -!- rh0nj [~rh0nj@136.243.139.96] has joined #bitcoin-core-dev
07:05 -!- flex [59f77f12@gateway/web/freenode/ip.89.247.127.18] has joined #bitcoin-core-dev
07:06 -!- flex [59f77f12@gateway/web/freenode/ip.89.247.127.18] has quit [Client Quit]
07:07 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-njbhjfkxzskhigyw] has joined #bitcoin-core-dev
07:07 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #15039: wallet: Avoid leaking nLockTime fingerprint when anti-fee-sniping (master...Mf1812-walletLocktimeFingerprint) https://github.com/bitcoin/bitcoin/pull/15039
07:07 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-njbhjfkxzskhigyw] has left #bitcoin-core-dev []
07:08 < fanquake> wumpus np, bunch of PRs mergable, but can deal with em later
07:13 < wumpus> PSA: there's no meeting today (there was confusion about this last week)
07:15 < hebasto> wumpus: today is Wednesday. Do you mean tomorrow?
07:18 < wumpus> oh sorry yes I mean tomorrow
07:19 < fanquake> only Wednesday for another 41 minutes anyway
07:20 < sipa> wumpus: no, you're right, no meeting today!
07:21 -!- ryanofsky [~russ@jumpy.yanofsky.org] has quit [Quit: ZNC 1.7.1 - https://znc.in]
07:24 -!- ryanofsky [~russ@jumpy.yanofsky.org] has joined #bitcoin-core-dev
07:28 -!- peevsie [~peevsie@2604:2000:f184:9300::4] has joined #bitcoin-core-dev
07:39 -!- tiagotrs [~user@unaffiliated/tiagotrs] has quit [Ping timeout: 268 seconds]
07:53 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit []
07:59 -!- kinlo [~peter@unaffiliated/kinlo] has quit [Quit: !]
08:03 -!- tiagotrs [~user@unaffiliated/tiagotrs] has joined #bitcoin-core-dev
08:06 -!- kinlo [~peter@unaffiliated/kinlo] has joined #bitcoin-core-dev
08:07 -!- jpe [~jpe@2001:16b8:48db:900:dc86:9c39:a6e8:8d3e] has quit [Remote host closed the connection]
08:13 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #bitcoin-core-dev
08:16 -!- cyber55 [~cyber55@unaffiliated/cyber55] has quit [Ping timeout: 272 seconds]
08:34 -!- mistergold [~mistergol@37.19.108.149] has joined #bitcoin-core-dev
08:47 -!- Murch [~murch@adsl-89-217-32-254.adslplus.ch] has joined #bitcoin-core-dev
09:10 < andytoshi> are there any guarantees about the order of `getrawmempool` output? in particular do ancestors always precede descendants?
09:12 -!- grubles [~grubles@unaffiliated/grubles] has quit [Remote host closed the connection]
09:19 -!- achow101_ [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev
09:19 < instagibbs> from my cursory reading they are indexed in 4 different ways, none of which are related to ancestors/decendants 
09:19 -!- Murch [~murch@adsl-89-217-32-254.adslplus.ch] has quit [Quit: Snoozing.]
09:20 < andytoshi> kk thanks, i won't rely on that then
09:20 < instagibbs> salted txid, feerate(including desc), entry time, and sorted feerate(including ancestor
09:20 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 250 seconds]
09:20 < andytoshi> i mean, somehow when creating blocks they have to wind up in ancestor order ... is there an explicit sorting step then?
09:21 < instagibbs> they grab "packages" as they sort via package feerate
09:22 < instagibbs> there are internal links between the entries, just not exposed here afaik
09:22 < andytoshi> ah, yep, that makes sense
09:22 < andytoshi> my goal here is to recreate the packages from the output of getrawmempool
09:22 -!- achow101_ is now known as achow101
09:22 -!- Murch [~murch@adsl-89-217-32-254.adslplus.ch] has joined #bitcoin-core-dev
09:26 < sipa> andytoshi: i'm pretty sure they're sorted by increasing total number of (recursive) unconfirmed dependencies, and then by feerate 
09:26 < sipa> and then by txid as tiebreaker or so
09:26 < sipa> which guarantees that dependencies always come before the dependendees (?)
09:27 < sipa> that code is not shared with the block creation code, btw
09:30 < instagibbs> andytoshi, also try getmempoolentry which comes with more details?
09:32 < andytoshi> instagibbs: oh, yeah (or `getrawmempool true` which gives me the same details). will take a look at that to see if it's useful. i suspect not, i think i need to manually recreate a lot of this data in my code because i need a bunch of extra details, like the set of yet-ununspent inputs/outputs for the whole package
09:32 < andytoshi> sipa: cool, thanks. but i guess that's an implementation detail and if i were to write production software that depended on it, you'd be annoyed :)
09:35 < andytoshi> i wish there was some way i could signal core that i don't want certain outputs to be 0conf-spendable (or if they are, that i don't want cpfp rules to be applied)
09:36 < gmaxwell> andytoshi: encountering the RBF pinning problem?
09:37 < andytoshi> gmaxwell: roughly ... but i think it doesn't even need RBF to be a problem .. e.g. see russell's mailing list post https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016519.html
09:38 < andytoshi> the issue is that if my software is making a package A of transactions and doing all sorts of CPFP logic to make that sensible, and meanwhile some customer of mine is creating a package B with a massive low-fee sweep or whatever
09:38 -!- Murch [~murch@adsl-89-217-32-254.adslplus.ch] has quit [Quit: Snoozing.]
09:38 < andytoshi> and then that customer creates a tx spending an output of A alongside the output of B...
09:38 < andytoshi> ...those packages become merged and suddenly my logic has been blindsided
09:38 < gmaxwell> that isn't how the implementation works.
09:39 < gmaxwell> I think Russell is like... reasoning from the feature's name.
09:39 -!- jarthur [~jarthur@pool-108-4-180-254.ronkva.east.verizon.net] has joined #bitcoin-core-dev
09:40 < andytoshi> well, the code is not super straightforward to someone uninvolved with it. the mempool logic related to the descendant limit looks kinda like it would do stuff like what i described
09:41 < gmaxwell> The descndant limit stuff can do things along those lines, but requires actually hitting the descendant limit.
09:45 < gmaxwell> If the limits are getting hit by ordnary usage we should look into fixing that. They were set so they were never hit when established (except for some obviously dumb floody crap), and only exist to prevent a bad computational blowup in the tracking code.
09:48 < instagibbs> one thing to note is that a single ~100kvB sweep can hose the descendant size limit pretty much
09:54 < gmaxwell> so fix it?
09:55 < gmaxwell> IIRC the reason for the size limits in the tracking is just so it doesn't falsely credit parents for feerate coming from transactions that are never going to fit in the same block.
10:00 -!- peevsie [~peevsie@2604:2000:f184:9300::4] has quit [Ping timeout: 252 seconds]
10:00 < andytoshi> maybe i'm confused about cpfp. my understanding is that if i make a tx with outputs controlled by other people, those other people are able to grief me and undermine my ability to use cpfp
10:00 < andytoshi> by extending the package such that i'd be hitting limits
10:02 < gmaxwell> yes, though also at the expense of delaying their own transaction confirmation.
10:02 < gmaxwell> I don't believe we've ever seen cpfp 'griefing' reported.
10:02 < gmaxwell> RBF pinning for sure, because a common usage pattern immediately causes it.
10:04 < gmaxwell> The limits exist only because there are computational overheads in the tracking, e.g. when removing a transaction its ancestors and descendants need to be walked to update their tracking.
10:11 -!- jarthur [~jarthur@pool-108-4-180-254.ronkva.east.verizon.net] has quit []
10:12 -!- gelmutshmidt [~gelmutshm@188.113.57.68] has joined #bitcoin-core-dev
10:13 -!- gelmutshmidt [~gelmutshm@188.113.57.68] has quit [Remote host closed the connection]
10:13 -!- gelmutshmidt [~gelmutshm@188.113.57.68] has joined #bitcoin-core-dev
10:14 -!- tiagotrs [~user@unaffiliated/tiagotrs] has quit [Ping timeout: 246 seconds]
10:16 -!- IGHOR [~quassel@93.178.216.72] has quit [Quit: http://quassel-irc.org ? ??????????? ?????????. ????-??.]
10:16 < andytoshi> sorry for the dumb questions, but can you clarify - if i'm making cpfp packages, and one of my customers 0conf spends one of the outputs i create, will their transaction pull my effective feerate toward the feerate of that tx? if so, then i need logic to reason about that, and by nature that logic needs to know about the limits (even though in practice i don't expect anyone to pull me close to 
10:16 < andytoshi> them)
10:16 < andytoshi> or is it safe if i just make my own transactions that chain off each others' change outputs, and ignore everything else?
10:17 < andytoshi> maybe i should just pester sipa in person in a couple of weeks :)
10:17 < andytoshi> and i will try to write down what i'm learning as i do this
10:18 < gmaxwell> No, it will not.
10:20 < gmaxwell> The parents effective feerate is the highest feerate you can construct with it.
10:20 < andytoshi> ok, i think i've got it
10:21 < gmaxwell> They can, if they spam out to the limits, prevent new descendants from being taken.
10:21 < gmaxwell> But thats only in the case that the tracking limits are hit.
10:21 < andytoshi> so is this a rough high-level view of cpfp in core?: (a) "packages" only exist during miners' transaction selection; in the case that a transaction might be in multiple packages, they're computed greedily to maximize feerate; (b) but when accepting to the mempool, Core checks whether a transaction might cause a limit-violating package to exist, and if it would, the tx is rejected
10:26 < gmaxwell> close enough;  the limits aren't really limits on 'packages', they're more limits on the tracking datastructures used to create packages.
10:26 < andytoshi> yep, that's what i meant
10:29 -!- IGHOR [~quassel@93.178.216.72] has joined #bitcoin-core-dev
10:39 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev
10:40 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 240 seconds]
10:48 -!- Guyver2_ [~Guyver@2001:985:f3f:1:3973:8912:183b:55da] has joined #bitcoin-core-dev
10:51 -!- peevsie [~peevsie@2604:2000:f184:9300::4] has joined #bitcoin-core-dev
10:51 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Ping timeout: 264 seconds]
11:06 -!- rh0nj [~rh0nj@136.243.139.96] has quit [Remote host closed the connection]
11:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
11:09 -!- rh0nj [~rh0nj@136.243.139.96] has joined #bitcoin-core-dev
11:35 -!- mistergold [~mistergol@37.19.108.149] has quit [Quit: leaving]
11:49 -!- tiagotrs [~user@unaffiliated/tiagotrs] has joined #bitcoin-core-dev
11:56 -!- tiagotrs [~user@unaffiliated/tiagotrs] has quit [Ping timeout: 250 seconds]
12:00 -!- gelmutshmidt [~gelmutshm@188.113.57.68] has quit [Remote host closed the connection]
12:06 -!- IGHOR [~quassel@93.178.216.72] has quit [Quit: http://quassel-irc.org ? ??????????? ?????????. ????-??.]
12:11 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-nrgbenpcgnfxidig] has quit [Quit: Connection closed for inactivity]
12:21 -!- fabianfabian [~fabianfab@D9656CCE.cm-27.dynamic.ziggo.nl] has quit [Quit: Textual IRC Client: www.textualapp.com]
12:24 -!- IGHOR [~quassel@93.178.216.72] has joined #bitcoin-core-dev
12:27 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-hwxjmityqfxwuvbf] has joined #bitcoin-core-dev
12:27 < bitcoin-git> [bitcoin] hebasto opened pull request #15040: qt: Add workaround for QProgressDialog bug on macOS (master...20181226-fix-macos-qprogressdialog) https://github.com/bitcoin/bitcoin/pull/15040
12:27 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-hwxjmityqfxwuvbf] has left #bitcoin-core-dev []
12:29 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
12:46 -!- bsm117532 [~mcelrath@c-24-61-184-150.hsd1.ma.comcast.net] has quit [Remote host closed the connection]
12:47 -!- bsm117532 [~mcelrath@c-24-61-184-150.hsd1.ma.comcast.net] has joined #bitcoin-core-dev
12:55 -!- Krellan [~Krellan@2601:640:4000:a876:d5b7:d9c4:4922:5f37] has quit [Quit: Leaving...]
13:03 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection]
13:28 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-dev
13:36 -!- Guyver2_ [~Guyver@2001:985:f3f:1:3973:8912:183b:55da] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
13:41 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev
13:46 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Remote host closed the connection]
13:56 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has quit [Read error: Connection reset by peer]
13:56 -!- jcorgan [~jcorgan@64-142-68-61.dsl.static.sonic.net] has joined #bitcoin-core-dev
14:03 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
14:10 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
14:10 -!- tiagotrs [~user@unaffiliated/tiagotrs] has joined #bitcoin-core-dev
14:15 -!- rex4539 [~rex4539@balticom-197-78.balticom.lv] has quit [Quit: rex4539]
14:16 -!- tiagotrs [~user@unaffiliated/tiagotrs] has quit [Ping timeout: 246 seconds]
14:42 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev
15:10 -!- rh0nj [~rh0nj@136.243.139.96] has quit [Remote host closed the connection]
15:16 < jnewbery> andytoshi: I think that's mostly right. In (a), the miner is ordering by ancestor feerate (see BlockAssembler::addPackageTxs in miner.cpp). In (b), all of the {(ancestor|descedant) (count|size)} are taken into account (see CTxMemPool::CalculateMemPoolAncestors() in txmempool.cpp)
15:18 < jnewbery> "and i will try to write down what i'm learning as i do this". Please consider contributing that to https://github.com/bitcoinops/scaling-book/blob/master/1.fee_bumping/fee_bumping.md if you think you can document it!
15:31 < gmaxwell> jnewbery: your last statement sounds confusing, and plays into roconnor's misunderstanding.
15:32 < gmaxwell> Basically what roconnor was thinking was that if there is an unconfirmed txn and then I add a gigantic low feerate child to it,  I lower the feerate of the txn because the "package" has a lower feerate.. And that is not how it works, because of the max operation in the combining.
15:37 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
15:42 -!- mistergold [~mistergol@37.19.108.149] has joined #bitcoin-core-dev
15:44 < jnewbery> (b) is not looking at feerate. Just tx count and size
15:48 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
15:54 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 240 seconds]
16:05 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Remote host closed the connection]
16:06 < andytoshi> i am still worried about the descendant size limit in practice though. if one of my customers is some giant exchange doing a massive sweep that's close to 100 KB in size, and they 0conf spend an output from my tx, that will compromise my ability to cpfp the tx, correct?
16:06 < andytoshi> well, i guess 100Kb is a _lot_
16:08 < gmaxwell> So fix it.
16:09 < gmaxwell> I agree that if a single "ordinarly created" txn can will defeat CPFP that shouldn't be possible.
16:09 < gmaxwell> The size isn't even an important aspect of the DOS protection, it could be handled entirely differently.
16:39 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev
17:07 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
17:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
17:55 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 245 seconds]
18:42 -!- rh0nj [~rh0nj@136.243.139.96] has joined #bitcoin-core-dev
18:48 -!- notmandatory [~notmandat@cpe-76-169-37-102.socal.res.rr.com] has quit [Ping timeout: 272 seconds]
18:52 -!- peevsie [~peevsie@2604:2000:f184:9300::4] has quit [Ping timeout: 252 seconds]
18:55 -!- mistergo1d [~mistergol@77.243.23.222] has joined #bitcoin-core-dev
18:55 -!- mistergold [~mistergol@37.19.108.149] has quit [Read error: Connection reset by peer]
19:48 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has quit [Ping timeout: 246 seconds]
19:49 -!- humphrey [18bd1550@gateway/web/freenode/ip.24.189.21.80] has joined #bitcoin-core-dev
20:08 -!- gelmutshmidt [~gelmutshm@188.113.57.68] has joined #bitcoin-core-dev
20:10 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has joined #bitcoin-core-dev
20:25 -!- notmandatory [~notmandat@cpe-76-169-37-102.socal.res.rr.com] has joined #bitcoin-core-dev
20:26 -!- mistergo1d [~mistergol@77.243.23.222] has quit [Read error: Connection reset by peer]
20:47 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev
21:07 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has quit [Ping timeout: 250 seconds]
21:11 -!- CodeBlue1776 [~CodeBlue1@107-215-134-60.lightspeed.cicril.sbcglobal.net] has quit [Ping timeout: 250 seconds]
21:11 -!- humphrey [18bd1550@gateway/web/freenode/ip.24.189.21.80] has quit [Ping timeout: 256 seconds]
21:13 -!- CodeBlue1776 [~CodeBlue1@107-215-134-60.lightspeed.cicril.sbcglobal.net] has joined #bitcoin-core-dev
21:43 -!- CodeBlue1776 [~CodeBlue1@107-215-134-60.lightspeed.cicril.sbcglobal.net] has quit [Read error: Connection reset by peer]
21:44 -!- CodeBlue1776 [~CodeBlue1@107-215-134-60.lightspeed.cicril.sbcglobal.net] has joined #bitcoin-core-dev
21:52 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 252 seconds]
22:07 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
22:15 -!- gelmutshmidt [~gelmutshm@188.113.57.68] has quit [Ping timeout: 244 seconds]
22:30 -!- Klox [~Klox@c-73-22-66-195.hsd1.il.comcast.net] has joined #bitcoin-core-dev
22:44 -!- notmandatory [~notmandat@cpe-76-169-37-102.socal.res.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
22:59 -!- notmandatory [~notmandat@cpe-76-169-37-102.socal.res.rr.com] has joined #bitcoin-core-dev
23:12 -!- rex4539 [~rex4539@balticom-197-78.balticom.lv] has joined #bitcoin-core-dev
23:38 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
23:53 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
--- Log closed Thu Dec 27 00:00:03 2018