--- Day changed Fri Jan 13 2017
00:00 < gmaxwell> fanquake: my first guess is the connection refused is just that the sleep that drove it hit its timeout while the slow operation happened, so it happened immediately after update tip.
00:01 < gmaxwell> fanquake: and I would assume the updatetip took a while whole holding CS main because it was processing a bunch of blocks at once due to a reodering.
00:01 < gmaxwell> e.g. you get a bunch of blocks with one massively out of order, when you finally fill in that missing block it goes and connects 100 at a time holding locks the whole time, which stalls the gui and causes some loss of network transfer speed.
00:03 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
00:03 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
00:08 < gmaxwell> fanquake: there may be some more interesting bug lurking for sure... but if so I wouldn't notice it because I'd discount it because we already know that ProcessNewBlock can have very high latency.
00:33 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
00:44 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
00:51 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:cd2b:f49d:fe68:cdf9] has quit [Read error: Connection reset by peer]     
00:51 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:cd2b:f49d:fe68:cdf9] has joined #bitcoin-core-dev     
00:52 < fanquake> gmaxwell thanks for the explanation. I'll collect a few more details and open an issue to track it.
00:53 < fanquake> gmaxwell btw, final sync time with 9484 -dbcache=4096 -par=8 was 2h12m
00:53 < fanquake> s/sync/-reindex-chainstate
00:53 < gmaxwell> you might want to add some logs around proceessnew block, e.g. enter and exit times. to try to validate my theory.
00:53 < gmaxwell> fanquake: fantastic.
00:54 < fanquake> That was to block 447885.
00:56 -!- gielbier_ [~michiel@unaffiliated/gielbier] has quit [Quit: Leaving]     
00:56 < gmaxwell> we could also consider adding a locking debug mode that saves the time of lock/unlock and prints if a lock is held more than (say) 1 second by a single piece of code.
01:19 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-suxnsdefkfbqizoo] has quit [Quit: Connection closed for inactivity]     
01:45 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-abxhpwlzcpbdrhdi] has joined #bitcoin-core-dev     
02:36 -!- xinxi [~xinxi@116.87.187.139] has quit [Remote host closed the connection]     
02:41 -!- AaronvanW [~AaronvanW@207pc74.sshunet.nl] has joined #bitcoin-core-dev     
02:41 -!- AaronvanW [~AaronvanW@207pc74.sshunet.nl] has quit [Changing host]     
02:41 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
02:45 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #bitcoin-core-dev     
03:12 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
03:16 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds]     
03:23 -!- xinxi [~xinxi@116.87.187.139] has quit [Remote host closed the connection]     
03:30 < cjamthagen> Are timelocked transactions included in your mempool if they are not yet valid?
03:41 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
03:44 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Quit: Leaving.]     
03:46 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
03:52 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
04:03 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]     
04:34 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
04:35 -!- JackH [~laptop@79-73-188-131.dynamic.dsl.as9105.com] has quit [Quit: Leaving]     
04:36 -!- str4d [~str4d@ip-80-236-233-113.dsl.scarlet.be] has joined #bitcoin-core-dev     
04:37 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 252 seconds]     
04:58 -!- xinxi [~xinxi@116.87.187.139] has quit [Remote host closed the connection]     
05:01 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
05:05 -!- moli_ [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer]     
05:05 -!- xinxi [~xinxi@116.87.187.139] has quit [Ping timeout: 248 seconds]     
05:18 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
05:20 -!- waxwing [~waxwing@110-170-176-164.static.asianet.co.th] has joined #bitcoin-core-dev     
05:24 -!- moli_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
05:31 -!- str4d_ [~str4d@ip-80-236-233-30.dsl.scarlet.be] has joined #bitcoin-core-dev     
05:32 < morcos> cjamthagen: no, they are not
05:34 -!- str4d [~str4d@ip-80-236-233-113.dsl.scarlet.be] has quit [Ping timeout: 252 seconds]     
05:41 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
05:45 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 256 seconds]     
05:47 -!- xinxi [~xinxi@116.87.187.139] has quit [Remote host closed the connection]     
05:51 -!- windsok [~windsok@45.63.59.8] has quit [Ping timeout: 255 seconds]     
06:03 -!- windsok [~windsok@45.63.59.8] has joined #bitcoin-core-dev     
06:06 < morcos> luke-jr: just want to be sure you realize in #9519 it's not all txs that signal opt-in RBF that are excluded, but only actual replacements, regardless of whether they themselves signal opt-in RBF.
06:06 < gribble> https://github.com/bitcoin/bitcoin/issues/9519 | Exclude RBF replacement txs from fee estimation by morcos · Pull Request #9519 · bitcoin/bitcoin · GitHub
06:49 -!- str4d_ [~str4d@ip-80-236-233-30.dsl.scarlet.be] has quit [Ping timeout: 240 seconds]     
06:49 < bitcoin-git> [bitcoin] jnewbery opened pull request #9542: Docs: Update CONTRIBUTING.md (master...CONTRIBUTINGcomponents) https://github.com/bitcoin/bitcoin/pull/9542
06:50 < jeremyru1in> This is not really critical, but as jtimon points out there is a lot of confusion over "Trivial" tags for PR's. https://github.com/bitcoin/bitcoin/blob/03dd707dc027fbf6f24120213f8eb66571600374/CONTRIBUTING.md is the closest thing to a specification of what Trivial means. I think that we'd save ourselves a lot of confusion if we adopted a policy that was more in line with how people typically (and in many other projects) use "trivial
06:50 < jeremyru1in> oops
06:50 < jeremyru1in> I see jnewbery has just opened something on that, will move my message there
06:57 -!- jnewbery [~john@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
07:07 < bitcoin-git> [bitcoin] laudaa opened pull request #9543: [Trivial] Grammar and typo correction (master...master) https://github.com/bitcoin/bitcoin/pull/9543
07:16 < sipa> jeremyru1in: i'm sure we had that written down somewhere, but i can't find it anymore
07:16 < sipa> i also can't find the description of utACK etc anymore, which used to be in some document
07:17 < achow101> sipa: it's still there: https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#peer-review
07:17 < sipa> ah!     
07:21 < achow101> is the sync overlay thing supposed to show up on windows? because I don't see it
07:27 -!- str4d_ [~str4d@cable-185.30.54.182.coditel.net] has joined #bitcoin-core-dev     
07:27 < gmaxwell> cjamthagen: only if they'll be valid at the next block or sooner.
07:28 < sipa> jonasschnelli: yes, that patch fixes the lack of dns response
07:29 < jonasschnelli> sipa: Great.
07:33 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
07:38 -!- cheese_ [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
07:41 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Ping timeout: 240 seconds]     
07:44 < instagibbs> can I PR directly against a BIP or should I bug the author?
07:45 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds]     
07:48 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
07:49 < jtimon> instagibbs: not sure what's the norm, but you definitely can technically, I received some PRs to my PR for bip99
07:49 < jonasschnelli> instagibbs: I think you can PR but don't expect a merge without authors ack
07:50 < jtimon> oh, you mean PR directly to the repo, not his own PR
07:50 < jtimon> yeah then what jonasschnelli said
07:52 -!- xinxi [~xinxi@116.87.187.139] has quit [Ping timeout: 248 seconds]     
08:00 < sdaftuar> BlueMatt: not sure you saw my comment in #9375 -- i suggested adding a "to do" comment in ProcessGetData, to remind us of the issues we discussed in requests for invalid blocks.  thoughts?
08:00 < gribble> https://github.com/bitcoin/bitcoin/issues/9375 | Relay compact block messages prior to full block connection by TheBlueMatt · Pull Request #9375 · bitcoin/bitcoin · GitHub
08:07 -!- paveljanik [~paveljani@79.98.72.176] has joined #bitcoin-core-dev     
08:07 -!- paveljanik [~paveljani@79.98.72.176] has quit [Changing host]     
08:07 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev     
08:10 < paveljanik> Unicorn...
08:11 < luke-jr> morcos: oh, I didn't realise that. But we can't know if they are or aren't replacements necessarily?
08:12 < instagibbs> RIP github
08:12 < BlueMatt> annnddd github down
08:12 < instagibbs> anyone need coffee
08:12 < BlueMatt> yes!
08:14 < paveljanik> good idea!
08:14 < BlueMatt> sdaftuar: hum, I did miss that comment
08:14 -!- chris2000 [~chris2000@p5DCB4BEE.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
08:15 < BlueMatt> sdaftuar: remind me of the context again?
08:15 -!- chris200_ [~chris2000@p5082ABC7.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]     
08:17  * luke-jr just got hot cocoa
08:18 < BlueMatt> for those bored during the github outage, https://0bin.net/paste/gPzFQpbXtDj9hQO8#NG+mcjz5Xuro4XPK4ZijCtV0sE4U-nFdoi8AWBL1IZX is #9535 and while its not tagged 0.14, its itself a big win and it would be swell if it could go in
08:18 < gribble> https://github.com/bitcoin/bitcoin/issues/9535 | HTTP Error 503: Service Unavailable
08:18 < BlueMatt> :p     
08:18 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 245 seconds]     
08:19 < BlueMatt> (is also super easy to review)
08:25 < sdaftuar> BlueMatt: general issue is that we don't have a way to tell a peer that we're intentionally ignoring a request, so our peer can't distinguish stalling from "sorry i now think this block is invalid"
08:25 < sdaftuar> i think we talked about eventually extending the p2p protocol to communicate this, potentially?
08:25 < sdaftuar> but documenting that we might announce a block and then ignore the request in ProcessGetData() seems prudent 
08:26 < BlueMatt> I'm not sure we talked about it, but, yea, thats something to consider...
08:26 < luke-jr> if github is down a day, do we defer the freeze a day too? :P
08:26 < BlueMatt> we do, technically, have reject messages, but ignore them because they're already not serialized with the rest of the p2p protocol
08:26 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
08:26 < BlueMatt> luke-jr: I vote yes (and will do review today either way :p)
08:26 < sdaftuar> right, we could extend the reject message generation to also apply to getdata messages
08:27 < sdaftuar> rather than just block/tx messages
08:27 < luke-jr> I wish GitHub's review thing worked offline
08:29 < achow101> it looks like they're back
08:30 < BlueMatt> sdaftuar: we'd probably have to also fix the reject messages so that they are serialized
08:30 < BlueMatt> instead of at some random time in the future, who knows
08:33 < morcos> luke-jr: yes we do know that... look at the code when GitHub is back
08:34 < sipa> going over 9441 a last time
08:39 -!- sanada [sanada@36-2-119-80.chiba.ap.gmo-isp.jp] has joined #bitcoin-core-dev     
08:45 < BlueMatt> sdaftuar: actually, if we're gonna extend it, we should just throw out the reject messages we have now entirely (no one uses them, they have some simple design flaws, and they are a big anonymity issue)
08:45 < BlueMatt> sdaftuar: then we can add something that says "I will not respond to your block request"
08:45 < BlueMatt> but we will send such a message only if we already announced said block
08:45 < BlueMatt> (and this would not apply to transactions)
08:48 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
09:02 < BlueMatt> someone wanna kick travis for #9484? sipa or wumpus, though I think gmaxwell can do it too
09:03 < gribble> https://github.com/bitcoin/bitcoin/issues/9484 | Introduce assumevalid setting to skip validation presumed valid scripts. by gmaxwell · Pull Request #9484 · bitcoin/bitcoin · GitHub
09:16 < sipa> i'll do so in a bit
09:18 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
09:22 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]     
09:29 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]     
09:34 -!- str4d_ [~str4d@cable-185.30.54.182.coditel.net] has quit [Ping timeout: 245 seconds]     
09:41 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
09:44 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 240 seconds]     
09:47 -!- str4d_ [~str4d@cable-185.30.54.182.coditel.net] has joined #bitcoin-core-dev     
09:50 < bitcoin-git> [bitcoin] JeremyRubin closed pull request #9503: listreceivedbyaddress Filter Address (master...listreceivedbyaddress-filtered) https://github.com/bitcoin/bitcoin/pull/9503
09:51 -!- str4d_ [~str4d@cable-185.30.54.182.coditel.net] has quit [Ping timeout: 245 seconds]     
09:51 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
09:52 < jeremyru1in> Ugh that's annoying that it reports that here ^^; just did that to force travis to restart Z(failed during the github downtime due to not being able to hit github)
09:52 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
09:56 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 252 seconds]     
09:59 < luke-jr> jonasschnelli: would it help if I go over my suggestions for 9294 and do them myself?
10:01 < sipa> BlueMatt: restart
10:02 < gmaxwell> jeremyru1in: force push also does that.
10:02 < bitcoin-git> [bitcoin] sipa pushed 17 new commits to master: https://github.com/bitcoin/bitcoin/compare/02e5308c1b9f...8b66bf74e2a3
10:02 < bitcoin-git> bitcoin/master 53ad9a1 Cory Fields: net: fix typo causing the wrong receive buffer size...
10:02 < bitcoin-git> bitcoin/master e5bcd9c Cory Fields: net: make vRecvMsg a list so that we can use splice()
10:02 < bitcoin-git> bitcoin/master 5b4a8ac Cory Fields: net: make GetReceiveFloodSize public...
10:02 < BlueMatt> wooooo
10:02 < bitcoin-git> [bitcoin] sipa closed pull request #9441: Net: Massive speedup. Net locks overhaul (master...connman-locks) https://github.com/bitcoin/bitcoin/pull/9441
10:03 < BlueMatt> c-c-c-combo-breaker
10:03 < jeremyru1in> nooo matt now nothing will get merged
10:04 < BlueMatt> sipa: I'm too lazy to squash #9375 (and each commit passes the "it works, and passes test" rule), fyi, in case you were planning on waiting for that
10:04 < gribble> https://github.com/bitcoin/bitcoin/issues/9375 | Relay compact block messages prior to full block connection by TheBlueMatt · Pull Request #9375 · bitcoin/bitcoin · GitHub
10:05 -!- jeremyru1in is now known as jeremyrubin     
10:06 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev     
10:10 -!- str4d [~str4d@cable-185.30.54.182.coditel.net] has joined #bitcoin-core-dev     
10:12 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]     
10:13 < jeremyrubin> gmaxwell: yeah, I was just lazy and on github.com at the moment :/
10:26 -!- str4d [~str4d@cable-185.30.54.182.coditel.net] has quit [Ping timeout: 252 seconds]     
10:27 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
10:28 < cfields> \o/     
10:29 < cfields> BlueMatt: 9535 needs rebase
10:35 < BlueMatt> cfields: done
10:35 < cfields> thanks
10:48 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
10:53 -!- xinxi [~xinxi@116.87.187.139] has quit [Ping timeout: 248 seconds]     
10:56 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
11:16 < sipa> ugh, master broken in p2p-segwit?
11:16  * sipa restarts
11:16 < sipa> i tested locally before merge
11:20 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
11:24 < bitcoin-git> [bitcoin] practicalswift opened pull request #9544: Add end of namespace comments. Improve consistency for anonymous namespaces. (master...consistent-use-of-end-of-namespace-comments) https://github.com/bitcoin/bitcoin/pull/9544
11:24 -!- xinxi [~xinxi@116.87.187.139] has quit [Ping timeout: 255 seconds]     
11:27 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has quit [Quit: MarcoFalke]     
11:28 < bitcoin-git> [bitcoin] practicalswift opened pull request #9545: Add override:s where appropriate (master...add-overrides-where-appropriate) https://github.com/bitcoin/bitcoin/pull/9545
11:30 < cfields> sipa: pebkac, i hope?
11:31 < sipa> cfields: ?
11:32 < cfields> <sipa> ugh, master broken in p2p-segwit?
11:35 < sipa> i assume it's somehow a spurious travis error
11:35 < sipa> not pebcak
11:36 < cfields> oh, i didn't see the failure, thought you were seeing it locally. got a link?
11:42 < sipa> you don't get an email?
11:42 < sipa> https://travis-ci.org/bitcoin/bitcoin/builds/191711996
11:42 < sipa> though i think the log may be unavailable as i've restarted
11:46 -!- ClockCat [~CattieCat@75-109-228-219.stjocmtk01.res.dyn.suddenlink.net] has quit [Quit: Leaving]     
11:48 -!- sanada [sanada@36-2-119-80.chiba.ap.gmo-isp.jp] has quit []     
12:00 < BlueMatt> grrr, I hate reviewing wallet changes
12:01 -!- JackH [~laptop@79-73-188-131.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev     
12:03 < gmaxwell> BlueMatt: why? it use to be more obnoxious but I think it's no big deal now.
12:03 < BlueMatt> because unlike some of our other codepaths, any change to eg spendability (like bumpfee) means reviewing like 20 functions which use spendability in slightly different ways
12:09 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
12:09 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
12:10 -!- brg444 [~bergealex@184-23-239-227.dedicated.static.sonic.net] has joined #bitcoin-core-dev     
12:11 < morcos> BlueMatt: I think its useful to look at it similar to how sdaftuar suggested.  imagine you stop your node, you restart it, and before your wallet can try to reaccept your old transaction an external replacement comes in.  its not required to _do anything_ to affect whether your orig tx affects spendability.
12:12 < morcos> All bumpfee is doing is adding an extra layer of conservativeness on top...  You know what... if you replace a tx, you're never going to be allowed to chain unconfirmed txs on the original tx again..
12:14 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 252 seconds]     
12:16 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]     
12:18 < BlueMatt> morcos, sdaftuar: I'm not convinced that not allowing a user to spend an input they removed from a replacement is The Right Behavior, especially as we move towards more loose replacement policies, but I'm fine with that for now. I don't see how thats massively different from an abandon (which means "pretend this isnt here, unless it somehow gets confirmed")
12:20 < gmaxwell> BlueMatt: bumpfee doesn't change the inputs. And any released inputs should not be spendable until the other spend is clearly conflicted.
12:20 < morcos> I think we're conflating two different things here...  Whether you can chain transactions off the original tx (the only change made in bumpfee) and whether any inputs spent by the original tx are still considered spent by the original tx (this is treated the same way any double spend is, both spends are spends)
12:20 < BlueMatt> gmaxwell: yes, this was essentially all theoretical as it cant happen yet
12:20 < gmaxwell> since bumpfee can't do that right now we can ignore having to handle the case where it does become spendable yet..
12:20 < morcos> If you want inputs spent by the original tx to not count as spent, there is nothing stopping you from manually abandoning the original tx, but i can't possibly imagine thinking it was a good idea to happen in an automatic fashion
12:22 < gmaxwell> morcos: well it should abandon the replacement or replaced txn automatically once it is well conflicted, I think? (doesn't need to now, but eventual functionality)
12:23 < BlueMatt> morcos: I think eventually if we have some super fancy gui that allows you to replace a transaction, and you swap the inputs selected, it woud be weird to not be able to re-spend them, as you can for abandon
12:23 < BlueMatt> but, agreed, lets table for now
12:23 < BlueMatt> the thing it does now is the more conservative option
12:23 < BlueMatt> which is good, and its a moot point unless we have other features added
12:23 < gmaxwell> BlueMatt: are you saying you should be immediately able to respend them in that case?
12:24 < BlueMatt> gmaxwell: dunno, probably not? unclear to me...but, lets table for now
12:24 < gmaxwell> BlueMatt: if so that would be a huge footgun, I think, as it would assume the user has a better mental model for what gets confirmed than we know they do. (than even many of us do much of the time).  
12:24 < BlueMatt> but should be able to respend them after the replacement confirms, which you cannot do now
12:24 < BlueMatt> gmaxwell: yea, well abandon is the same thing :p
12:24 < morcos> gmaxwell: but that happens automatically right?
12:25 < BlueMatt> morcos: my reading of the code now, you cannot ever respend the inputs which are no longer being replaced
12:25 < morcos> if A spends inputs 1 , 2, 3 and you use futurebumpfee to replace A with A' which spends inputs 2, 3, 4
12:25 < sdaftuar> yeah when the replacement confirms, the original will be cobnflicted, freeing up the inputs
12:25 < morcos> then until either are confirmed, 1,2,3, and 4 will appear spent.  When A' confirms, input 1 will automatically become spendable again because A is conflicted.
12:26 < morcos> this seems like roughly the right behavior, and more importantly not a change from the existing behavior
12:27 < morcos> but maybe BlueMatt is saying there is a bug and thats not happening?
12:27 < BlueMatt> sdaftuar: oh, youre right, sorry missed that
12:27 < BlueMatt> morcos: nope, misreading, I think
12:28 < BlueMatt> sdaftuar: I do think we need the RelayWalletTransaction isReplaced gate: https://github.com/bitcoin/bitcoin/pull/8456#discussion_r96068068
12:28 < BlueMatt> if we ever change the min relay fee it could blow up
12:28 < gmaxwell> need morcos feesplit
12:29 < BlueMatt> gmaxwell: was that a please-review reminder?
12:29 < BlueMatt> (for #9380)
12:29 < gribble> https://github.com/bitcoin/bitcoin/issues/9380 | Separate different uses of minimum fees by morcos · Pull Request #9380 · bitcoin/bitcoin · GitHub
12:29 < BlueMatt> :p     
12:29 < morcos> BlueMatt: I'm not sure I agree with that either...
12:29 < morcos> In the case A
12:29 < morcos> sorry
12:30 < morcos> In the case A' becomes conflicted... you want to Relay A, so I think that means you always want to relay A
12:30 < morcos> it would be nice if you first try to reaccept everything and then only relay them if they are in your mempool at the end
12:30 < gmaxwell> we shouldn't be relaying multiple verions of conflicting transactions at a time. but the mempool will make sure we don't.
12:31 < morcos> I _think_ that'll be mostly what happens in practice, but i guess its not guaranteed.. (so assuming you have both A and A' probably only the second will be relayeD)
12:32 < BlueMatt> lets say you have A and its been replaced by A' -> normally you restart, A (might be) accepted first, then A' replaces it, like normal
12:32 < BlueMatt> I think this does mean we'll announce A, but proobably not if its been delayed-announced
12:32 < BlueMatt> however, if the user restarts with a higher min relay fee, A' might not meet the replacement requirements
12:32 < BlueMatt> and so A ends up in your mempool
12:32 < BlueMatt> which sucks
12:32 < morcos> isn't it always delayed-announced
12:32 < BlueMatt> dont think so?
12:33 < sdaftuar> BlueMatt: i agree that is a possible edge case
12:33 < morcos> i mean you're almost right.. A' by definition has a higher relay fee
12:33 < morcos> but you could restart with a higher dust limit, which could cause A to be accepted and not A'
12:33 < BlueMatt> morcos: huh? relay fee is a property of your software, not the transacion?
12:33 < morcos> but in that case you probably want A to be relayed!
12:33 < BlueMatt> yes, dust limit is calculated from minrelayfee, iirc
12:33 < gmaxwell> we probably should sort the unconfirmed transaction by dependency/relay fee before inserting, instead of just by order. but I don't think thats urgent now.
12:33 < morcos> A' by definition has a higher feerate
12:34 < morcos> gmaxwell: agreed.. not urgent...  this is like rare edge case
12:34 < morcos> and even if both get relayed or the wrong one, its not necessarily a BAD thing
12:34 < BlueMatt> I think its an easy solution to just add a replaced_by check prior to relay?
12:34 < morcos> but that has downsides
12:34 < sdaftuar> that opens the door to morcos' edge case 
12:34 < BlueMatt> ehh...I mean I think once you've replaced you probably want the replacement relayed
12:35 < BlueMatt> like, if you restart and it has a lower feerate that gets stuck in your mempool, that sucks and just means you're gonna have to replace again
12:35 < BlueMatt> plus you might've done something else in the replace, like set it to not-replaceable
12:35 < BlueMatt> or whatever
12:35 < morcos> but the only reason the old one is stuck is there is something wrong wiht the new one
12:35 < morcos> in that case you are basically just screwed anyway, unless you replace the new one
12:36 < BlueMatt> not really...? the new one is just as fine as the old one
12:36 < morcos> then why is that not replacing the old one in your mempool?
12:36 < BlueMatt> just maybe that the new one wont auto-replace the old one in peoples' mempool across the network
12:36 < morcos> don't you have chicken soup to eat?
12:36 < BlueMatt> heh     
12:36 < morcos> oh b/c of the incremental relay fee getting raised
12:37 < morcos> i missed that that was your point
12:37 < BlueMatt> because either a) you're manually setting a higher -minrelayfee (for some reason...)...or b) you updated to a new version with a higher -minrelayfee default
12:37 < BlueMatt> oh, sorrry, yes, that was my point
12:37 < BlueMatt> so maybe the replacement wont relay that well depending on how much the rest of the network has upgraded
12:37 < morcos> sure.. but look.. you shouldn't NEED to rerelay either of them
12:37 < morcos> just b/c you restarted your node, doesn't mean everyone else did
12:37 < BlueMatt> huh???
12:37 < BlueMatt> and if you're (bumped) fee is low enough that it'll take a few days to get in?
12:38 < BlueMatt> we cant break re-announce???
12:38 < BlueMatt> eg a key use-case for bumpfee is setting the fee super low and bumping it eventually if it doesnt get in for a few days
12:38 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
12:38 < morcos> we're not breaking it.. we're just saying there is a contrived edge case where it might not be super effective
12:38 < BlueMatt> or a week
12:38 < BlueMatt> whats the downside of adding the check to relay???
12:38 < BlueMatt> it fixes an edge case, and....?
12:39 < BlueMatt> eg I use bumpfee in greenaddress to send transactions with super low feerate to transfer between my wallets cause I dont care about conf time
12:39 < sdaftuar> if you have upgraded settings so that the new tx is not sufficiently above the old one's feerate to relay through your own node, you might as well assume that you have to fee bump again to get it to relay across the network
12:39 < morcos> i think the right way to do it is what gmaxwell said...  some sort of sort..  where you follow the chain of A->A'->A'' to the end and then start by trying to rebroadcast A''
12:39 < BlueMatt> and if it never gets in, i just bump it slightly
12:39 < BlueMatt> sdaftuar: nope, it could time out, or maybe you're on a new version that much of the network isnt
12:39 < morcos> but thats an improvement that can be done later
12:40 < BlueMatt> (or you manually set -minrelayfee higher, which a bunch of folks did when we didnt have limited mempool and likely still have)
12:40 < morcos> just blindly saying skip A if we have A' is not obviously better to me
12:40 < sdaftuar> what would you have done if you upgraded before the bumpfee call?
12:40 < BlueMatt> morcos: so you announce all three txn potentially to your peers? that blows
12:41 < sdaftuar> BlueMatt: that is already what your recipient(s) will do
12:41 < morcos> how so... relay happens to run in the middle of reacceptWalletTransactions
12:41 < BlueMatt> yea, also what about announce? I'm pretty sure there are a few not-delayed-announce cases?
12:41 < morcos> ok, how about this for a fix
12:41 -!- catlasshrugged [d0a7fe36@gateway/web/freenode/ip.208.167.254.54] has joined #bitcoin-core-dev     
12:41 < morcos> its hacky but i think strictly better
12:41 < BlueMatt> (also because we're likely to change relay in the future to do some fast-path'ing stuff through some nodes)
12:42 < morcos> on startup only, we call ReaccpetWalletTransactions with a bool which skips txs that have been replaced
12:42  * BlueMatt is still super confused as to why y'all want to try to add a replaced transaction to mempool
12:42 < gmaxwell> BlueMatt: maybe the replacement is non-standard?
12:42 < morcos> bc the replacement might be bad/conflicted/soemthing wrong with it
12:42 < gmaxwell> it could, btw with bumpfee... dust limit changing between restarts.
12:43 < BlueMatt> gmaxwell: fair...i suppose if the replacement fails to get accepted into our mempool we would want to try the original
12:43 < gmaxwell> In that case you get to keep both pieces, but ... it's worth discussing.
12:43 < morcos> yes this is the point...  but if we skip the replacees the first time through..  then they'll get skipped by virtue of the replacer already being in the mempool on future runs, and if for some reason it isn't.. then they'll get broadcast
12:44 < morcos> will lead to this order A'', A, A'   but that's an improvement
12:44 < BlueMatt> morcos: so you mean only do this on initial run? not on the timer-based one?
12:44 < morcos> yes     
12:44 < BlueMatt> I'm happy with that
12:44 < morcos> I'm compromisey with that
12:44 < BlueMatt> it is super hacky
12:44 < morcos> that we can agree on
12:44 < sdaftuar> seems like a nice optimization for a futre pr
12:44 < BlueMatt> but should at least fix the issue while not (really) risking anything
12:45 < BlueMatt> sdaftuar: yea, which will be so chock-full of edge cases......
12:45 < BlueMatt> but, ok
12:45 < BlueMatt> sounds good
12:45 < morcos> yeah can we make that a bugfix PR to 8456
12:45 < morcos> so we can just get 8456 merged
12:45 < sdaftuar> haha
12:46 < BlueMatt> morcos: note how I did that to you when you asked me to change the logprints in #9375 :p
12:46 < gribble> https://github.com/bitcoin/bitcoin/issues/9375 | Relay compact block messages prior to full block connection by TheBlueMatt · Pull Request #9375 · bitcoin/bitcoin · GitHub
12:47 < morcos> good, i had no objection to that!
12:51 < morcos> BlueMatt: just looking at the code.. there is actually no way for relay to happen before all the txs have tried to be accepted to the mempool right?
12:52 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
12:54 < cfields> morcos: mind fixing up the mempool minReasonableRelayFee while you're messing around there? as i read the code, it doesn't respect -minrelaytxfee
12:54 < cfields> (i'm not familiar enough with all of the interactions to know if that matters much)
12:55 < BlueMatt> morcos: not sure? havent looked in a while?
12:55 < BlueMatt> doesnt really fully address the issue, though
12:55 < morcos> right still your edge case of A' no longer being able to replace A, but you think its better if you try to rebroadcast only A' in that case?
12:56 < morcos> it seems to me if that happens, then its likely b/c you raised the required increment (probably b/c a lot of other people did too) so even if you broadcast A' it might not propagate and you might be more likely to figure that out if you have A in your mempool instead of A'
12:58 < morcos> cfields: you are right it doesn't respect it...  but it actually is better that it doesn't i think...  it should probably just be cleaned up separtely in another fee estimation clean up.
12:58 < BlueMatt> morcos: hmmmm
12:59 < cfields> morcos: ok good, I was hoping you'd say that. So it should just take DEFAULT_MIN_RELAY_TX_FEE instead?
12:59 < morcos> i thought through what i thought it should be a couple of weeks ago, but now i can't exactly remember....   
12:59 < morcos> almost.... i think if you ever want a minrelaytxfee less than DEFAULT, then you'd probably want that number to be less
13:00 < morcos> but maybe we can just worry abou tthat when it happens...  and probably best to just change it to DEFAULT_MIN_RELAY_TX_FEE for now
13:01 < morcos> or its own fee estimation constant... its basically used for determining the bucket sizes... so don't want to change it b/c then your old data file is useless
13:01 < bitcoin-git> [bitcoin] practicalswift opened pull request #9547: Avoid potential division by zero in benchmark::State::KeepRunning() (master...avoid-potential-division-by-zero-in-benchmark-state-keeprunning) https://github.com/bitcoin/bitcoin/pull/9547
13:01 < morcos> ok maybe i should PR a change for it while we're thinking about it
13:02 < cfields> morcos: heh, yes please :). No problem with doing it later, i just see it now and then and make a mental note to ask you, and have never managed to do so.
13:02 < BlueMatt> morcos: I mean there's a strong argument for both - if you replaced a transaction, you really dont want to be relaying an old version out...on the flip side, if you replace a transaction and you wouldn't have accepted the replacement, maybe you want to know that...I think for my use-case (slowly bumping fee on a tx that I dont care when it confirms), I prefer the second - keep relaying the bumped one, especially because if the 
13:02 < BlueMatt> original eventually times out on other folks' mempool's, I'd want the one with ever-so-sligly-higher fee to relay out and try to get confirmed
13:02 < BlueMatt> instead of the original one
13:02 < BlueMatt> because I obviously bumped it for a reason
13:03 < morcos> heh timeout is 2 weeks now..  you're a patient man
13:04 < BlueMatt> oh, i thought we set it to 1
13:04 < BlueMatt> oh well
13:04 < BlueMatt> there goes that argument
13:07 < BlueMatt> morcos: so technically the first add-all-wallet-txn-to-mempool is after CConnmanStart
13:07 < BlueMatt> (its in postInitProcess, the very last thing called in AppInit
13:07 < BlueMatt> )     
13:07 < BlueMatt> so you could relay out old transactions if you get connections fast and have a massive wallet
13:07 < BlueMatt> theoretically, at least
13:08 < sdaftuar> if we did that after the load mempool from disk finishes, that might solve a lot of the problem?  m aybe messy to do that way, i haven't looked
13:09 < BlueMatt> hmm? dont think that would make it better?
13:09 < BlueMatt> oh, i see your point
13:09 < BlueMatt> i mean problem is that mempool-load is so super slow...
13:09 < sdaftuar> yeah
13:09 < sdaftuar> but there's kind of no hurry for this is there?  i was more concerned about layer violations
13:10 < morcos> it looks to me like the first resendwallettransactions doesn't happen for 30 mins
13:11 < BlueMatt> I mean I started by seeing the fact that your wallet might accept the pre-bump transaction into mempool after the bump as a bug....but y'all've convinced me that its at least conceivably the right outcome depending on what the user wants
13:11 < morcos> and thats the only way they get relayed
13:11 < morcos> just accepting them to the mempool doesn't relaythem
13:13 < BlueMatt> i think reaccepting post-mempool-disk-load still carries risk, though - some of the wallet logic depends on mempool-reading
13:13 < BlueMatt> so I wouldnt feel comfortable making that change without more than 2 days of review....
13:16 -!- catlasshrugged [d0a7fe36@gateway/web/freenode/ip.208.167.254.54] has left #bitcoin-core-dev []     
13:19 < gmaxwell> BlueMatt: we already try to reaccept wallet transactions continually.
13:20 < BlueMatt> yea?
13:20 < gmaxwell> yea. at the rebroadcast times.
13:20 < BlueMatt> I'm aware?
13:21 < BlueMatt> whats your point?
13:21 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 260 seconds]     
13:21 < gmaxwell> and the wallet 'works' without transactions in mempool... e.g. you can setup so that all transactions are rejected from the mempool.
13:21 < BlueMatt> my point was that we have wallet logic which depends on whether a transaction is in mempool, and if we're gonna change it so that you could spend a bunch more time at load with transactions not yet in mempool, that would require audit and careful thought about those places
13:22 < BlueMatt> I mean, yes, it works, but some things in it wont work
13:22 < BlueMatt> at least last I checked
13:22 < BlueMatt> even blocksonly puts wallet transactions in mempool, i think
13:22 < BlueMatt> just doenst relay them
13:23 < gmaxwell> BlueMatt: no it doesn't. 
13:23 < gmaxwell> (unless you've enabled that specifically)
13:23 < BlueMatt> oh, heh, indeed it doesnt
13:25 < BlueMatt> yea, ok, looking at it again it looks like it would only disable features, not enable you to do anything you shouldnt be able to
13:26 < BlueMatt> anywayyyy
13:51 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
13:53 < morcos> BlueMatt: anywayyy.......... ->  ACK ?
13:58 < BlueMatt> morcos: getting there
13:58 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Quit: Leaving]     
13:59 < BlueMatt> morcos: ran out of steam so had to take a coffee break...digging into the meat now :p
14:01 < bitcoin-git> [bitcoin] morcos opened pull request #9548: Remove min reasonable fee (master...removeMinReasonableFee) https://github.com/bitcoin/bitcoin/pull/9548
14:22 < luke-jr> would it be terrible, if wallets upon encounting a transaction they sent yet is still unconfirmed but is being spent already, were to double-spend their transaction to the latter destination(s)?
14:23 < luke-jr> eg, if I pay morcos, and see morcos paying BlueMatt before mine confirms, double-spend it to BlueMatt (and morcos's change address) directly
14:23 < BlueMatt> lol, lets not do that, I think
14:23 < BlueMatt> that has all kinds of fun potentials
14:23 < BlueMatt> "no, you didnt pay me, look at the blockchain!"
14:24 < luke-jr> :D     
14:24 < luke-jr> save their transaction as proof
14:24 < BlueMatt> of course I'd appreciate that particular scenario, because I get all the btc :p
14:24 < BlueMatt> can we just hardcode my pubkey?
14:24 < luke-jr> haha
14:29 < luke-jr> would be a pain to implement in Core; maybe I'll make a highly experimental wallet that does crazy things like this if I ever get time
14:30 < sipa> ACK hardcoding BlueMatt's pubkey
14:31 < BlueMatt> morcos/ryanofsky: ok, so lets say you have tx A, then you bumpfee it to get A'....BUT someone has already built a tx on A (called B) (which you hadnt seen at the time of bump)....great, so now we have a scenario where, if A' times out of your mempool, it might get replaced with A (because you might see A+B from a peer prior to rebroadcasting A')
14:31 < luke-jr> only if I get a copy of his privkey
14:31 < sdaftuar> yes     
14:31 < BlueMatt> now you have a few goofy things - like qt's getBalance is different from wallet's GetBalance (because AvailableCoins is different from pcoin->IsTrusted())
14:32 < BlueMatt> I know, I'm coming up with crazy edge cases now
14:32 < gmaxwell> luke-jr: autocuttrhough could be done, I suppose but you'd want to only do it with parties that opted into it.
14:33 < ryanofsky> don't understand the problem. if A gets added to a block then A' is conflicted and we don't care about it
14:33 < BlueMatt> no, not in a block
14:33 < BlueMatt> A' gets replaced in your mempool with A
14:33 < luke-jr> so?     
14:33 < BlueMatt> (I came up with a convoluted case where that might happen, so now I'm gonna pretend we have to handle it gracefully :p)
14:34 < BlueMatt> luke-jr: well I dont think we handle that case gracefully
14:34 < sdaftuar> there's nothing you can really do right?
14:35 < BlueMatt> I think in this case qt's balance will suddenly forget about both txn
14:35 < BlueMatt> CWallet::GetBalance will just trust whatever's in your mempool, I think
14:35 < sdaftuar> if A has a high fee child spend, then A might well be more likely to be be mined than A'
14:35 < luke-jr> I don't see what the problem is?
14:35 < BlueMatt> sdaftuar: sure, but your balance shouldnt be different getween rpc and gui
14:35 < gmaxwell> sdaftuar: which change will it show in your balance?
14:35 < BlueMatt> let alone should the gui suddenly think the balance of both options will be 0
14:35 < sdaftuar> neither
14:35 < sdaftuar> i think
14:35 < sdaftuar> ?     
14:36 < sdaftuar> oh, i am not sure
14:36 < BlueMatt> but CWallet::GetBalance will show the one which is in your mempoo
14:36 < BlueMatt> l     
14:36 < gmaxwell> E.g. A, A'  then A ends up back in your mempool.   Your balance doesn't go to zero when you spend coins and have change.
14:36 < gmaxwell> (if it did users would freak often)
14:36 < BlueMatt> rpc will list the balance assuming the one in your mempool gets confirmed, I /think/ gui would be 0
14:36 < BlueMatt> or, at least, WalletModel::getBalance would be 0
14:36 < BlueMatt> need to figure out what calls that
14:37 < gmaxwell> I think it's fine if balance reads a bit low, e.g. assumes you paid the largest of the fees. It's not okay if it goes to zero.
14:37 < BlueMatt> oh, no, its inconsistent, now I have no idea what this effects
14:38 < gmaxwell> Because it will cause someone to freak -- "I sent 1 bitcoin and by 10 BTC balance went to zero! where are all my coins! please help. I tried deleting my wallet 5 times and they haven't come back!"
14:38 < BlueMatt> ahh, ok, so nvm, what i think it does (because getBalance() is normally called without a coinControl) is that if you try to create a transaction it'll refuse to spend from either
14:38 < BlueMatt> and give you an "insufficient funds" error
14:38 < BlueMatt> but the display will be right
14:38 < gmaxwell> yes, thats fine. it's like spendzeroconfchange=0 for those inputs.
14:38 < BlueMatt> which is strange, but probably fine given its a crazy edge case
14:39 < BlueMatt> gmaxwell: you asked why I hated reviewing wallet prs? :p
14:39 < BlueMatt> billion and one possible corner cases
14:39 < gmaxwell> if you think this is easier that reviewing network or consensus changes, I am frightened. :P
14:40 < BlueMatt> harder than network? yea it is
14:40 < BlueMatt> consensus, ok, maybe not
14:40 < gmaxwell> there are just as many corner cases! we just mishandle them more often. :P
14:40 < BlueMatt> heh, ok, fair point
14:43 < BlueMatt> note: I still havent even fucking looked at the rpc code for bumpfee :'(
14:43 < BlueMatt> do we document that listunspent will not list the outputs from bumped transactions (they will dissapear after you bump and neither the bumped or unbumped version's outputs will show up)
14:43 < BlueMatt> which is super strange because it normally lists everything except abandoned outputs
14:47 < gmaxwell> outputs disappear anytime they're used in a spend, ... bumpfee is no behavior change there.
14:47 < BlueMatt> not in listunspent, no, I dont think so?
14:47 < gmaxwell> any output thats spent (including in an unconfirmed txn) is not included in list_un_spent. :)
14:47 < gmaxwell> oh do you mean the change?
14:48 < BlueMatt> yes, change, sorry
14:48 < gmaxwell> the change should probably still be there but marked held. :-/ basically anything in the balance computation sould be there.
14:48 < BlueMatt> I believe its also not listed in the gui's coincontrol options for inputs
14:49 < BlueMatt> but I'm guessing there because I'd need to go read a whole 'nother pile of code to double-check
14:51 < BlueMatt> yes, but which one should show up in that list?
14:51 < BlueMatt> :p     
14:51 < BlueMatt> replaced or original?
14:52 < bitcoin-git> [bitcoin] sipa pushed 15 new commits to master: https://github.com/bitcoin/bitcoin/compare/8b66bf74e2a3...3908fc472805
14:52 < bitcoin-git> bitcoin/master 8017547 Matt Corallo: Make CBlockIndex*es in net_processing const
14:52 < bitcoin-git> bitcoin/master 9a0b2f4 Matt Corallo: [qa] Make compact blocks test construction using fetch methods
14:52 < bitcoin-git> bitcoin/master 8baaba6 Matt Corallo: [qa] Avoid race in preciousblock test....
14:52 < BlueMatt> woooo
14:53 < bitcoin-git> [bitcoin] sipa closed pull request #9375: Relay compact block messages prior to full block connection (master...2016-12-compact-fast-relay) https://github.com/bitcoin/bitcoin/pull/9375
14:53 < BlueMatt> one more down for 0.14
14:54 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds]     
14:58 < owowo> how about skipping 0.14 and got directly to 0.15? I mean _4_ sounds like death in Chinese. ;0)
14:58 < morcos> BlueMatt: ok i admit, that's some good finds.  i did test some of this stuff both in RPC and GUI, but I dont think I fully thought through all the ways different balances might differ
14:59 < morcos> Indeed change from bumper txs do not appear in coin control (as they shouldn't i think b/c you can't spend them)
14:59 < sipa> cfields: i think we should detect whether the compiler supports -fsanitize (gcc 4.8 added -fsanitize=address, 4.9 added -fsanitize=undefined, 5.0 added -fsanitize=leak), and build test/production binaries with it to run unit tests with
14:59 < morcos> Perhaps you are right that some of these new behaviors need to be more clearly documented
15:00 < sipa> cfields: there is also -fsanitize=thread, which cannot be used in conjunction with any of the others
15:00 < morcos> I'm not sure about listing the outputs in listunspent though...   hmm..  Will take a look at any more comments you have tomorrow
15:02 < sipa> cfields: downside is that both compilation and running is much slower
15:03 < bitcoin-git> [bitcoin] kallewoof closed pull request #9235: [WIP] Refactor: Remove all uses of using namespace in all source files. (master...no-using-ns2) https://github.com/bitcoin/bitcoin/pull/9235
15:10 < BlueMatt> morcos: I'm not sure about listing either, thats why my first request was to just document it
15:10 -!- xinxi [~xinxi@116.87.187.139] has quit [Remote host closed the connection]     
15:10 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
15:16 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
15:20 -!- xinxi [~xinxi@116.87.187.139] has quit [Remote host closed the connection]     
15:25 -!- bsm117532 [~mcelrath@38.121.165.30] has quit [Ping timeout: 248 seconds]     
15:34 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]     
15:34 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev     
15:52 -!- brg444 [~bergealex@184-23-239-227.dedicated.static.sonic.net] has quit [Ping timeout: 255 seconds]     
16:03 < midnightmagic> In src/core_write.cpp:ScriptToAsmStr() there is a check for an integer printout with 0 <= vch.size() <= 4 -- otherwise it prints out a hex string. But for decodescript 6900, (decoding to OP_VERIFY 0) the vch.size() I believe for the second byte is 0, rather than an actual 0x00, and so the decode works apparently by accident..? Am I missing something?
16:05 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
16:06 < bitcoin-git> [bitcoin] sipa pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/3908fc472805...e126d0c12ca6
16:06 < bitcoin-git> bitcoin/master 997a98a Gregory Maxwell: Replace FindLatestBefore used by importmuti with FindEarliestAtLeast....
16:06 < bitcoin-git> bitcoin/master 4b06e41 Suhas Daftuar: Add unit test for FindEarliestAtLeast
16:06 < bitcoin-git> bitcoin/master e126d0c Pieter Wuille: Merge #9490: Replace FindLatestBefore used by importmuti with FindEarliestAtLeast....
16:06 < bitcoin-git> [bitcoin] sipa closed pull request #9490: Replace FindLatestBefore used by importmuti with FindEarliestAtLeast. (master...fix_find_latest_before) https://github.com/bitcoin/bitcoin/pull/9490
16:11 -!- brg444 [~bergealex@184-23-239-227.dedicated.static.sonic.net] has joined #bitcoin-core-dev     
16:21 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
16:23 -!- bsm117532 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev     
16:25 -!- xinxi [~xinxi@116.87.187.139] has quit [Ping timeout: 248 seconds]     
16:29 < cfields> sipa: good idea. I'm not exactly sure how to execute it though. I'd rather not trip up someone's manual efforts to enable sanitizers. Maybe add a --enable-sanitizers config option, off by default, that tries to turn on as many non-conflicting ones as possible?
16:29 < cfields> BlueMatt: woohoo! congrats on merge.
16:31 < sipa> cfields: we may need 2 or 3 separate builds with sanitizers, unfortunately
16:32 < sipa> cfields: but yes, optional sounds right
16:32 < cfields> sipa: right. Maybe there's no realistic way to add to configure, then? We can just handle with cflags for travis/gitian :(
16:32 -!- brg444 [~bergealex@184-23-239-227.dedicated.static.sonic.net] has quit [Ping timeout: 260 seconds]     
16:32 < sipa> you wouldn't want to enable sanitizers on production binaries, obviously
16:33 < cfields> right, it'd build both sets
16:33 < cfields> I suppose just doing it for travis would be a start
16:34 < cfields> we already have a slow, minimal build with debug cranked up for libstdc++.
16:36 < sipa> the sets you can do are 1) -fsanitize=address -fsanitize=undefined -fno-omit-frame-pointer 2) -fsanitize=thread 3) -fsanitize=memory (clang only, and requires rebuild of all dependencies)
16:36 < sipa> i've only played around with the first for now
16:38 < cfields> is no-omit-frame-pointer needed for correctness? or just helpful backtraces?
16:39 < sipa> i am not sure
16:39 < cfields> that one might be tricky since it's enabled at -O2, iirc. Not sure what "-fno-omit-frame-pointer -O2" turns into
16:39 < cfields> ok     
16:40 < sipa> i think individual -f things override the -O defaults
16:41 < cfields> i would hope so. My fear is that it's order-based, like warnings.
16:41 < sipa> ah     
16:41 < sipa> seems likely
16:42 < cfields> if so, that'd be tricky, since -Ox sneak in all over the place.
16:42 < cfields> will mess around with 'em
16:45 -!- juscamarena [~justin@47.148.176.74] has quit [Remote host closed the connection]     
16:45 -!- juscamarena [~justin@47.148.176.74] has joined #bitcoin-core-dev     
16:47 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
16:47 -!- brg444 [~bergealex@184-23-239-227.dedicated.static.sonic.net] has joined #bitcoin-core-dev     
16:47 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-klitxyrlpvkxrtqa] has quit [Quit: Connection closed for inactivity]     
16:59 < BlueMatt> cfields: yea, feels good to get a few things in for 0.14....do feel bad that I havent done enough review this week and am holding up things like bumpfee :'(
16:59 < BlueMatt> will at least finish this review before going out :/
16:59  * BlueMatt hopes ryanofsky has time to spare this weekend
17:00 < cfields> heh. it'd be a rookie move to make plans the weekend before freeze/release :)
17:00 < BlueMatt> well he is a rookie, after all :p
17:01 < sipa> like 'participating in the mit mystery hunt'
17:01 < BlueMatt> (at least in bitcoin)
17:01 < sipa> or 'agreeing to review workshop papers with deadline the 15th' ?
17:01 < BlueMatt> heh, yea, what were you and gmaxwell thinking, sipa????
17:01 < BlueMatt> :P     
17:01 < cfields> sipa: ahah, that's this weekend?
17:01 < sipa> i'll be so happy when i get back to california on tuesday
17:02 < sipa> all this vacation thing is too stressful
17:02 < cfields> heh     
17:04 < cfields> jeremyrubin: are you still pushing for your checkqueue rewrite? I'm rebasing the interruptible threads, and just remembered how terribly inefficient that is. There are some easy gains for sure. But I won't mess with it if it's being nuked anyway.
17:07 < gmaxwell> cfields: we should be careful with '--enable' because there are users that run ./configure and then turn on every enable.
17:08 < luke-jr> sipa: note that -fsanitize=memory also has weird LLVM/kernel matching issues, and is basically impossible on Travis currently (I used to use it)
17:08 < cfields> gmaxwell: well --enable-debug would already be hurting them pretty badly :)
17:08 < sipa> luke-jr: ah, good to know
17:09 < gmaxwell> cfields: yea agreed we should probably fix that -- though at least that one says 'debug'.
17:09 < luke-jr> sipa: cfields: also, we absolutely should NOT use -fsanitize=x with prod binaries. they are not intended for that, and add exploits
17:09 < sipa> luke-jr: absolutely!
17:10 < bitcoin-git> [bitcoin] practicalswift opened pull request #9549: [net] Avoid possibility of NULL pointer dereference in MarkBlockAsInFlight(...) (master...avoid-potential-null-pointer-dereference-in-markblockasinflight) https://github.com/bitcoin/bitcoin/pull/9549
17:10 < gmaxwell> maybe making them -dev-debug -dev-sanatize-foo etc would be sufficient.
17:10 < gmaxwell> can someone tell him that if he thinks he actually has a possible null reref in code like that he should send it privately?
17:11 < gmaxwell> oh the description is okay
17:11 < gmaxwell> (ignore me)
17:11 < sipa> ideally i think those sanitize things should build separate binaries (bitcoind_san_X, test_bitcoin_san_X, ...)
17:11 < sipa> if that's at all possible
17:12 < sipa> maybe it's easier with a wrapper script around configure/make rather than inside the system
17:12 < luke-jr> is there a reason to special-case it at all? what's wrong with just passing CXXFLAGS?
17:12 < cfields> luke-jr: read the discussion above :)
17:12 < sipa> ideally, make check etc... build the multiple configurations and run all tests on all
17:13 < gmaxwell> As another side, we use the oneliners in our release notes but often our choice of them is really poor for this purpose.  Case in point ^ sounds like a serious crasher or even exploitable.
17:13 < luke-jr> cfields: I did skim it, but didn't see a rationale
17:15 < sipa> luke-jr: if we do it as a wrapper around (and just re-run configure and test for each of the sanitizers), it will just be passing CXXFLAGS/LDFLAGS
17:15 < cfields> luke-jr: i was kinda thinking same as you. Not sure it makes sense to handle in the build-system. as sipa said, maybe a wrapper makes more sense
17:15 < sipa> luke-jr: but it would be nice if it was completely integrated, so that the multiple tests/builds can run in parallel just from make, for exampe
17:15 < luke-jr> oh, for make check basically?
17:15 < sipa> right
17:16 < sipa> but make check should also run pull-tester/rpc-tests.py then
17:16 < sipa> i guess we can just start by doing it as a wrapper over the build system
17:17 < luke-jr> making make check run rpc tests shouldn't be hard, unlike sanitizers :P
17:19 -!- moli_ [~molly@unaffiliated/molly] has quit [Remote host closed the connection]     
17:20 -!- moli_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
17:21 < cfields> sipa: hmm, how do they interact with lto? it'd be nice if some of them could be enabled at link-time
17:22 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
17:22 < sipa> cfields: they play well with lto, but you need to pass them both at compile and at link time, i think
17:22 < midnightmagic> Is a verbose transaction decode available through the rpc block decode interfaces..?
17:23 < sipa> decoderawtransaction?
17:24 < midnightmagic> sipa: The function interface has a txDetails bool which defaults to false but .. I don't know where it can be called with true through the rpc. Only the REST interface I think..?
17:24 < midnightmagic> blockToJSON() I mean.
17:24 < achow101> midnightmagic: you mean with something like getblock?
17:24 < midnightmagic> Yeah.
17:25 < achow101> no. but I have an open pr for that
17:25 < midnightmagic> ah, nice. \o thanks. I'll look for your PR then instead of doing my own.
17:26 < bitcoin-git> [bitcoin] gmaxwell opened pull request #9550: Trim down the XP notice and say more about what we support. (master...we_got_it_already) https://github.com/bitcoin/bitcoin/pull/9550
17:26 < achow101> midnightmagic: #8704
17:27 < gribble> https://github.com/bitcoin/bitcoin/issues/8704 | [RPC] Transaction details in getblock by achow101 · Pull Request #8704 · bitcoin/bitcoin · GitHub
17:27 -!- xinxi [~xinxi@116.87.187.139] has quit [Ping timeout: 256 seconds]     
17:28 < midnightmagic> excellent.
17:29 < sipa> </mrburns>
17:30 < gmaxwell> luke-jr: I really wish make check ran the rpc tests though the rpc tests have more dependencies than the oridnary builds.
17:30 < gmaxwell> But I think we need to, because increasingly the useful tests are in rpctests.
17:30 < gmaxwell> I think current make check has a poor ratio of excution time to sensitivity.
18:06 < BlueMatt> morcos: getbalance("*", 1, True) is defined as a synonym of getbalance(), but bumpfee breaks that
18:06 < BlueMatt> (note that I think bumpfee also breaks some account balance shit, but I didnt bother to audit that - do we care?)
18:08 < BlueMatt> morcos / sdaftuar / ryanofsky: please add the following test-case https://0bin.net/paste/m91nHUQbD39EXaQ6#9fJ3bvAfAib5xWWwVdh3Ck0v7jQht1r8iDMQKQDpfTC
18:08 < gribble> https://github.com/bitcoin/bitcoin/issues/9 | Fix for GUI on Macs and latest wxWidgets by gavinandresen · Pull Request #9 · bitcoin/bitcoin · GitHub
18:08 < BlueMatt> no gribble
18:10 < BlueMatt> (it currently fails on the last line of the test)
18:10 < BlueMatt> note that if you move that test to be the last one run you'll get fun results - getbalance("*", 1, True) is negative!
18:16 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
18:19 < instagibbs> BlueMatt, https://github.com/bitcoin/bitcoin/issues/8183 Perhaps still the case
18:19 < instagibbs> they haven't been the same in a number of cases already :(
18:20 < BlueMatt> hum, ok, that seems shit
18:21 < BlueMatt> can we tag #8183 for 0.14, then, that is insane
18:21 < gribble> https://github.com/bitcoin/bitcoin/issues/8183 | getbalance comment incorrect · Issue #8183 · bitcoin/bitcoin · GitHub
18:21 < morcos> BlueMatt: I had assumed there might be an issue like that after you brought up your GUI question, and it was on my list to look into...
18:21 < BlueMatt> we either need to fix it or fix the docs in getbalance
18:21 < BlueMatt> they significantly imply that if you specify "*" as account you'll get sane results
18:21 < morcos> i guess in my head i sometimes confuse getbalance "*" with something that has to do with accounts
18:21 < morcos> but quite honestly getbalance "*" is a shit show
18:21 < morcos> why do we even need it
18:21 -!- xinxi [~xinxi@116.87.187.139] has quit [Ping timeout: 260 seconds]     
18:21 < instagibbs> yeah it's really bad
18:21 < instagibbs> :)     
18:21 < instagibbs> i mean :(
18:21 < morcos> i would suggest it should be deprecated with accounts
18:21 < BlueMatt> getbalance "*" should throw an exception as "FUCK YOU, WE DEPRECATED THIS FOREVER AGO"
18:21 < BlueMatt> it is marked deprecated the way i read the docs
18:22 < BlueMatt> the fact that it returns insanity is gonna confuse someone, and it has been deprecated, so it should throw an exception as its known-unsafe and we likely wont fix it
18:22 < morcos> From #9167 : "Note that the fee reported in the details and any other function which depends on ListTransactions is not changed as getbalance("*") depends on having incorrect negative fees calculated on mixed debit transactions in order to track the right balances."
18:23 < gribble> https://github.com/bitcoin/bitcoin/issues/9167 | IsAllFromMe by morcos · Pull Request #9167 · bitcoin/bitcoin · GitHub
18:23 < BlueMatt> I mean it may be deprecated, but that doesnt mean it gets to return insanity
18:23 < BlueMatt> if its gonna return insanity, it needs to die
18:25 < morcos> anyway got to go
18:26 -!- brg444 [~bergealex@184-23-239-227.dedicated.static.sonic.net] has quit [Ping timeout: 240 seconds]     
18:28 -!- brg444 [~bergealex@184-23-239-227.dedicated.static.sonic.net] has joined #bitcoin-core-dev     
18:28 < BlueMatt> when you have to google C++ operator precedence in the process of review, something has gone horribly wrong :'(
18:43 -!- brg444 [~bergealex@184-23-239-227.dedicated.static.sonic.net] has quit [Ping timeout: 248 seconds]     
18:43 -!- abpa [~abpa@2602:306:b837:dbf0:f8fa:d3f5:c92c:37bf] has joined #bitcoin-core-dev     
18:43 -!- abpa [~abpa@2602:306:b837:dbf0:f8fa:d3f5:c92c:37bf] has quit [Client Quit]     
18:44 < gmaxwell> BlueMatt: time to study operator precidence more! :)
18:47 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
18:48 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
18:50 < BlueMatt> clearly
18:50 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev     
18:51 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]     
18:57 -!- xinxi [~xinxi@116.87.187.139] has quit [Remote host closed the connection]     
19:02 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
19:03 -!- veleiro [~veleiro@fsf/member/veleiro] has joined #bitcoin-core-dev     
19:07 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []     
19:12 -!- xinxi [~xinxi@116.87.187.139] has quit [Remote host closed the connection]     
19:14 < fanquake> cfields Made the required changes in 9469, and pulled in your commits. Any chance while your looking at Qt stuff, you can take a look at #9126. Have you seen that issue at all?
19:14 < gribble> https://github.com/bitcoin/bitcoin/issues/9126 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
19:17 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
19:18 -!- brg444 [~bergealex@192.77.237.110] has joined #bitcoin-core-dev     
19:29 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-abxhpwlzcpbdrhdi] has quit [Quit: Connection closed for inactivity]     
19:30 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]     
19:42 < BlueMatt> I think #9484 is ready for merge
19:42 < gribble> https://github.com/bitcoin/bitcoin/issues/9484 | Introduce assumevalid setting to skip validation presumed valid scripts. by gmaxwell · Pull Request #9484 · bitcoin/bitcoin · GitHub
19:42 < BlueMatt> (just thought I'd mention it so it doesnt slip 0.14)
19:44 < BlueMatt> gmaxwell: you were saying you'd be super dissapointed if some of the net fixes didnt make 0.14...well there is one bunch left from your pr that is at risk - #9535
19:44 < gribble> https://github.com/bitcoin/bitcoin/issues/9535 | Split CNode::cs_vSend: message processing and message sending by TheBlueMatt · Pull Request #9535 · bitcoin/bitcoin · GitHub
19:45  * BlueMatt does solomly swear all helgrind issues will be thoroughly debugged prior to release :p
19:45 < BlueMatt> 9535 wont add any, but I know of a few still left
19:47 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
20:01  * sipa tests 9535 with -fsanitize=thread
20:03 < BlueMatt> sipa: thar be dragons
20:03 < BlueMatt> (not cause by 9535)
20:04 < BlueMatt> d     
20:04 < sipa> yes, i expect it to fail (on master)
20:04 < BlueMatt> can I buy a "d"?
20:04 < BlueMatt> I can give you a list of places it will fail :p
20:05 < BlueMatt> alright folks, I'm all reviewed-out...and likely wont have time tomorrow. apologize for those I didnt get to, but will try again on sunday
20:05 < sipa> thanks!
20:08 < sipa> ok, bitcoin-cli fails with -fsanitize=thread... i think there is some build config failure
20:10 -!- windsok [~windsok@45.63.59.8] has quit [Ping timeout: 240 seconds]     
20:16 -!- chris200_ [~chris2000@p5DCB55BA.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
20:18 -!- chris2000 [~chris2000@p5DCB4BEE.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]     
20:20 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
20:25 -!- windsok [~windsok@45.63.59.8] has joined #bitcoin-core-dev     
20:28 < bitcoin-git> [bitcoin] 2HCHO opened pull request #9551: disable out of sync warnings for regtest network (master...ca4b90519c3c210f) https://github.com/bitcoin/bitcoin/pull/9551
20:34 -!- xinxi [~xinxi@116.87.187.139] has quit [Remote host closed the connection]     
20:41 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
20:58 -!- brg444 [~bergealex@192.77.237.110] has quit [Quit: brg444]     
20:59 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
20:59 < cfields> sipa: yes, i'd expect that to be a bloodbath if it works. But there should be no new issues, i think
20:59 < cfields> sipa: specifically, anything that uses CNodeStats is very racy.
21:00 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
21:02 -!- brg444 [uid207215@gateway/web/irccloud.com/x-deyhwaqrwaqlharu] has joined #bitcoin-core-dev     
21:19 < sipa> cfields: i think it inteferes with some fortify/aslr/... we're using
21:19 < sipa> bitcoin-cli has no threads
21:29 < cfields> sipa: oh, yes, for sure
21:29 < cfields> i read somewhere that FORTIFY is incompatible with some, sec for link
21:30 < sipa> in fact, the compiler detector fails with -fsanitize=thread ("C++ compiler cannot produce binaries")
21:31 < cfields> sipa: https://www.sourceware.org/ml/libc-alpha/2016-09/msg00080.html
21:31 < cfields> comes from here: https://github.com/google/sanitizers/wiki/AddressSanitizer
21:35 < cfields> fanquake: will have a look at 9126
21:36 < cfields> (at some point this weekend)
21:37 < fanquake> cfields cheers. Interesting build error on just the osx build of 9469. "Qt requires a C++11 compiler and yours does not seem to be that."
21:38 < fanquake> Thought I might have messed up passing -c++std c++11. But that looks ok. https://travis-ci.org/bitcoin/bitcoin/jobs/191837557#L895
21:41 < sipa> -std=c++11 ?
21:51 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-jbmcjsbwjeotqazr] has joined #bitcoin-core-dev     
21:55 < cfields> fanquake: hmm, strange. it built fine for me locally
21:55 -!- xinxi [~xinxi@116.87.187.139] has quit [Remote host closed the connection]     
21:55 < fanquake> cfields yes me too.
21:56 < cfields> fanquake: ah, it's the damn .mm again
21:57 < cfields> fanquake: i noticed something at one point and suspected that might happen
21:57 < cfields> trying to remember
21:59 < cfields> ah, right
21:59 < cfields> fanquake: https://github.com/bitcoin/bitcoin/blob/master/depends/config.site.in#L66
21:59 < cfields> mind nuking that line and giving it a try?
22:01 < fanquake> cfields Have pushed that change up to GH.
22:01 < fanquake> Will start a new build here also.
22:01 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
22:02 < cfields> thanks
22:04 < fanquake> Just realised I forgot you had two commits on top of mine, so that change is now part of your translations build commit. 
22:04 < cfields> fanquake: for the reasoning, see https://github.com/bitcoin/bitcoin/blob/master/configure.ac#L62
22:04 < fanquake> Can fixup later if the builds passed. Otherwise np.
22:05 < cfields> fanquake: np. Though if this fixes, we probably want to commit it as a one-liner. It's a good backport candidate.
22:06 < fanquake> cfields good point. Will split it out post builds passing.
22:08 < cfields> fanquake: only reason i mention is that i had a theory at one point that it was the cause of the 10.7 back-compat breakage. Since it's responsible for intoducing c++03 abi objects into the 0.13 build.
22:11 < fanquake> cfields ok. Just made note of it in a comment in that PR.
22:11 -!- xinxi [~xinxi@116.87.187.139] has quit [Remote host closed the connection]     
22:14 < cfields> fanquake: thanks :)
22:15 < fanquake> cfields I'll stop pestering now, you can go and enjoy the rest of your saturday heh
22:17 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
22:18 < cfields> fanquake: heh, np. i meant to test that a long time ago, glad it came up either way
22:18 < cfields> besides, this is what i enjoy :)
22:19 < cfields> woohoo, success
22:21 < fanquake> Awesome. I'll fixup that commit then.
22:22 < cfields> great, thanks again!
23:00 -!- dermoth [~thomas@dsl-66-36-128-167.mtl.aei.ca] has quit [Read error: Connection reset by peer]     
23:00 -!- dermoth [~thomas@dsl-66-36-128-167.mtl.aei.ca] has joined #bitcoin-core-dev     
23:08 -!- xinxi [~xinxi@116.87.187.139] has quit [Remote host closed the connection]     
23:21 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
23:44 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Quit: Leaving.]