--- Day changed Thu Oct 29 2015
00:26 -!- deepcore [~deepcore@2a01:79d:469e:ed94:8e70:5aff:fe5c:ae78] has quit [Ping timeout: 268 seconds]
00:41 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-dadfgdahjgxjrqfs] has joined #bitcoin-core-dev
00:51 < wumpus> -1 for dropping 32 bit support, I want to support 32-bit ARM
00:52 < wumpus> leveldb works well enough I see no need for any kind of desperate measures
00:53 < wumpus> experimenting with other databases, fine, but I don't like this talk of dropping support for platforms just to accomodate a library
01:00 < CodeShark> I agree with not removing leveldb support - but other than the fact we have close to zero tolerance for differences in consensus behavior, I think supporting multiple databases is generally a good idea
01:01 < wumpus> we've made it very easy to switch the database, but not looking forward to maintaining and testing multiple db backends in the upstream repository
01:02 < gmaxwell> it's very easy to use another one, though most alternatives have performance so poor they're just unusable.
01:03 < wumpus> I can't say this enough, the database is not an external interface, it's just an implementation detail of bitcoind. There should be zero reason for users to switch it.
01:03 < CodeShark> apparently corruption is not that infrequent on windows
01:03 < wumpus> then fix it on windows! it's not magic or rocket science
01:03 < wumpus> I'm tired of this complaining
01:04 < CodeShark> ?
01:04 < gmaxwell> CodeShark: sure, so go fix it!  it's likely the same issue that existed on OSX or similar.
01:04 < wumpus> can we pool a bounty or something like that
01:04 < CodeShark> you mean fix leveldb itself?
01:04 < gmaxwell> (where fsync didn't work for writes via mmaps)
01:04 < wumpus> I don't want to hear "leveldb is broken on windows" every day, this is not tea time with bitcoin-dev, we should be constructive here
01:04 < gmaxwell> CodeShark: leveldb's FS access is abstracted, the windows interface we use is probably only used by us and nothing else.
01:04 < wumpus> yes
01:05 < gmaxwell> In chrome, for example, all the FS access is via some totally chrome specific layer and doesn't touch any of the FS access code we use.
01:06 < CodeShark> I don't really fricking care, personally - I don't really run a bunch of bitcoin core instances on windows - I'm just repeating what I've heard from others
01:06 < gmaxwell> CodeShark: you actually run windows though, none of the other people who would normally fix something like this do.. and we don't even have an archive of a reproduction.
01:08 < Luke-Jr> (tomorrow we find out CodeShark stopped running Windows :p)
01:08 < wumpus> I do care but I don't have access to a remotely recent windows machine at the moment, and know very little about windows internals or debugging. I generally use wine when I need to do that but it's no help here.
01:09 < CodeShark> my windows development at present consists almost 100% of crossbuilds from linux
01:10 < CodeShark> windows is just the way I access VMs and servers ;)
01:10 < CodeShark> from one machine
01:10 < CodeShark> none of my other machines run windows
01:11 < CodeShark> http://research.cs.wisc.edu/adsl/Publications/alc-hotdep13.pdf
01:29 < GitHub14> [bitcoin] laanwj opened pull request #6900: gitian: build on ubuntu 14.04 (master...2015_10_gitian_trusty) https://github.com/bitcoin/bitcoin/pull/6900
01:50 < wumpus> an easy to implement robustness option would be to auto-back up the utxo database once in a while. This can be done in a similar fashion to gettxoutsetinfo, on a snapshot inthe background. Then if unrecoverable database issues happen, restore that
01:52 < wumpus> (not meant as a substitute for solving the leveldb issue on windows, but what I like is that it helps for both known and unknown issues)
02:03 -!- [1]evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
02:04 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has quit [Ping timeout: 260 seconds]
02:04 -!- [1]evoskuil is now known as evoskuil
02:23 -!- zander [~quassel@kde/zander] has joined #bitcoin-core-dev
02:24 < zander> I'm wondering about the process of removing stuff from the mempool when a new block comes in.  So transactions from the block naturally are remove from the mempool. Is that mallaeble safe?
02:24 < zander> Is the txid used for that removal?
02:24 < zander> Or is it smarter that that.
02:24 < zander> ?
02:25 < phantomcircuit> zander, any transactions which conflicts with the new block is removed
02:25 < zander> ah, ok. Thanks!
02:28 -!- rubensayshi [~ruben@91.206.81.13] has joined #bitcoin-core-dev
02:29 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer]
02:30 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
02:54 -!- BashCo [BashCo@gateway/vpn/mullvad/x-dictdpyvardghlpn] has joined #bitcoin-core-dev
02:56 -!- max777555 [25c3cac6@gateway/web/freenode/ip.37.195.202.198] has joined #bitcoin-core-dev
02:56 < max777555> Friends start a new cloud of mining https://cldmine.com/account/registration/4075 Very similar to when registering RDPmain dogikoin 1500 bonus on you buying power and immediately start earning a great opportunity to earn at the very beginning to invite many partners and earn a passive join !!!
02:58 -!- max777555 [25c3cac6@gateway/web/freenode/ip.37.195.202.198] has quit [Client Quit]
03:02 < phantomcircuit> wumpus, sipa ^
03:07 -!- mode/#bitcoin-core-dev [+o wumpus] by ChanServ
03:07 -!- mode/#bitcoin-core-dev [+b *!*@gateway/web/freenode/ip.37.195.202.198] by wumpus
03:07 -!- mode/#bitcoin-core-dev [-o wumpus] by ChanServ
04:11 -!- PRab_ [~chatzilla@2601:40a:8000:8f9b:e53e:6986:5865:2f1f] has joined #bitcoin-core-dev
04:13 -!- PRab [~chatzilla@2601:40a:8000:8f9b:bd13:f19b:c988:ff92] has quit [Ping timeout: 240 seconds]
04:13 -!- PRab_ is now known as PRab
04:18 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Quit: This computer has gone to sleep]
04:41 -!- danielsocials [~quassel@45.32.248.113] has joined #bitcoin-core-dev
04:42 -!- fanquake [~Adium@unaffiliated/fanquake] has joined #bitcoin-core-dev
04:46 < GitHub195> [bitcoin] laanwj closed pull request #6781: [QT] pretty print (indent) multiline html output (master...2015/10/qt_rpcconsole_pp) https://github.com/bitcoin/bitcoin/pull/6781
04:51 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 255 seconds]
05:05 -!- danielsocials [~quassel@45.32.248.113] has quit [Remote host closed the connection]
05:07 -!- danielsocials [~quassel@45.32.248.113] has joined #bitcoin-core-dev
05:11 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-core-dev
05:12 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Client Quit]
05:13 < GitHub111> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8daffe227bc6...26752767df45
05:13 < GitHub111> bitcoin/master 3e187f2 Suhas Daftuar: Fix BIP65 p2p test...
05:13 < GitHub111> bitcoin/master 2675276 Wladimir J. van der Laan: Merge pull request #6894...
05:13 < GitHub96> [bitcoin] laanwj closed pull request #6894: [Tests] Fix BIP65 p2p test (master...fix-bip65-p2p-test) https://github.com/bitcoin/bitcoin/pull/6894
05:14 < bsm117532> We need a test case on windows that generates leveldb corruption, so as to evaluate other db alternatives.  Anecdotes that it happens with leveldb and might not with some other db are unsatisfactory.  What can we do to "pull the rug out from under bitcoind" and test this?
05:14 < bsm117532> Questions about performance are a lot easier to be quantitative about...
05:15 < wumpus> reproduction should be simple: run it on a windows pc, crashhe computer or disconnect the power
05:15 < wumpus> it appears that no one remotely capapble and willing to troubleshoot this issue has no windows PC to check though
05:15 < bsm117532> That's pretty tedious.  :-/
05:16 < bsm117532> I don't have a windows pc either...
05:16 < wumpus> well from what I understand it *always* happens, so it's not that bad
05:16 < bsm117532> I was thinking like kill -9 on a remote windows vm, or something like that.
05:16 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
05:16 -!- danielsocials [~quassel@45.32.248.113] has quit [Ping timeout: 240 seconds]
05:16 < wumpus> well a VM could work, I don't know - couldn't reproduce it with wine at least last time I tried
05:18 < wumpus> but a full VM is closer to the real thing. I don't have any windows licenses for a VM either, though.
05:22 < bsm117532> We should be able to get a windows VM through Azure
05:23 -!- danielsocials [~quassel@45.32.248.113] has joined #bitcoin-core-dev
05:31 < GitHub178> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/26752767df45...b2ce2c1f0fb1
05:31 < GitHub178> bitcoin/master 95f4291 MarcoFalke: [trivial] Rewrite help text for feature enabled by default...
05:31 < GitHub178> bitcoin/master bf68191 MarcoFalke: [trivial] rpcnet: fix typo
05:31 < GitHub178> bitcoin/master 6782f58 MarcoFalke: [trivial] Latest config.guess...
05:31 < GitHub152> [bitcoin] laanwj closed pull request #6870: [trivial] Misc cleanup and translations (master...MarcoFalke-2015-trivial3) https://github.com/bitcoin/bitcoin/pull/6870
05:40 < GitHub57> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b2ce2c1f0fb1...b28c229324d0
05:40 < GitHub57> bitcoin/master a83f3c2 Bob McElrath: Add explicit shared_ptr constructor due to C++11 error
05:40 < GitHub57> bitcoin/master b28c229 Wladimir J. van der Laan: Merge pull request #6899...
05:40 < GitHub144> [bitcoin] laanwj closed pull request #6899: Add explicit shared_ptr constructor due to C++11 error (master...cpp11) https://github.com/bitcoin/bitcoin/pull/6899
05:40 < GitHub189> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b28c229324d0...725539ea0376
05:40 < GitHub189> bitcoin/master 0be387a Daniel Kraft: unittest: fix test for null tx input...
05:40 < GitHub189> bitcoin/master 725539e Wladimir J. van der Laan: Merge pull request #6863...
05:40 < GitHub146> [bitcoin] laanwj closed pull request #6863: [Test Suite] Fix test for null tx input (master...null-txin-test) https://github.com/bitcoin/bitcoin/pull/6863
05:42 -!- daniel____ [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.]
05:43 -!- daniel___ [~quassel@106.120.101.38] has joined #bitcoin-core-dev
05:52 -!- danielsocials [~quassel@45.32.248.113] has quit [Remote host closed the connection]
05:53 < dcousens> wumpus: for the windows box, would I need a complete chain?
05:53 < dcousens> I can put bitcoin-qt on a old gaming rig if necessary, have to dust it off a little but, if its worth it
05:56 < bsm117532> It would be good to know quantitatively if we're actually fixing something by changing the db or just making a mess.
05:58 -!- bsm117532 is now known as mcelrath
05:58 < dcousens> mcelrath: would I need to build latest?
05:59 < dcousens> I'd assume so if the aim was to actually fix it haha
05:59 < mcelrath> build latest bitcoind?  Yes, I mean we'd want to take jgarzik's sqlite branch and a lmdb branch and violently kill them and see what happens to their db's too.
06:00 < mcelrath> It's kind of an involved test :-/
06:01 < dcousens> mcelrath: well, I'll see what I can set up tomorrow.  Midnight here so I won't go about messing with setting up a dev-env
06:01 < mcelrath> But writing a shell script to kill things in a tight loop sounds like an appropriate thing to do to Windows.  ;-)
06:02 < mcelrath> Cool, thanks!
06:02 -!- fanquake [~Adium@unaffiliated/fanquake] has quit [Quit: Leaving.]
06:02 < mcelrath> I'm pretty sure we (or lots of people) can get an azure instance.  But I've never used a remote windows vm.
06:08 < wumpus> dcousens: I don't think so, I think you just have to kill it while it's syncing
06:09 < dcousens> wumpus: likely that the shutdown time itself will be dependent on how many writeops are waiting
06:09 < dcousens> Perhaps worth doing on a HDD, not a SSD?
06:09 < dcousens>  :P
06:14 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
06:25 < mcelrath> Is bitcoin anymore consensus-dependent on leveldb?  If we swap it out with sqlite or lmdb, will it still be consensus critical? (and can it be made non-consensus critical?)
06:29 < wumpus> everything that is called by the consensus code is, in principle, consensus critical
06:30 < wumpus> so is the database, the file system, the OS. But all that should be important is that they behave correctly.
06:31 < wumpus> if there are silent bugs it is problematic. For example, if leveldb would ignoring keys with certain properties, using a database without that erratic behavior would fork off from nodes using leveldb
06:31 < mcelrath> IOW if the verification code (erroneously) can't look up a txid or utxo, it causes a block to be rejected, no?
06:33 < wumpus> not if it is reported as a database error and simply crashes the node. It is a problem if a record is reported to be present when it is not, or the other way around, or the data is corrupted
06:34 < wumpus> (which is why leveldb's checksums on everything are nice to have, it provides added assurance that if something is returned it's at least correct)
06:36 < mcelrath> I'm pretty seriously worried about silent bit flips or hash computation errors causing nodes to fail, and how to detect it.  But spurious errors like that won't cause a majority of nodes to reject blocks.
06:38 < wumpus> majority plays no role in bitcoin - if *your* node forks from the block chain, that's a risk to you
06:40 < mcelrath> Exactly.  But having a majority of miners screw up is a bigger problem than little 'ol me.  ;-)
06:42 -!- danielsocials [~quassel@45.32.248.113] has joined #bitcoin-core-dev
06:46 < wumpus> but yes the most dangerous bugs are consistent ones - note that an database-OS bug could be dangerous in that way, for example forking off all MacOSX nodes
06:57 -!- jgarzik [~jgarzik@172.85.35.242] has joined #bitcoin-core-dev
06:57 -!- jgarzik [~jgarzik@172.85.35.242] has quit [Changing host]
06:57 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-core-dev
07:12 < GitHub33> [bitcoin] dajohi opened pull request #6902: policy:  Add new constant MAX_STANDARD_MULTISIG_KEYS (master...multisig_keys) https://github.com/bitcoin/bitcoin/pull/6902
07:32 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Quit: This computer has gone to sleep]
07:46 -!- zooko [~user@75-171-192-140.hlrn.qwest.net] has joined #bitcoin-core-dev
07:48 -!- mcelrath [~bsm117532@static-108-21-236-13.nycmny.fios.verizon.net] has quit [Disconnected by services]
07:48 -!- bsm1175321 is now known as mcelrath
07:48 < morcos> sipa: what does the 25-50% of the cache number that's used for nCoinDBCache represent?
07:49 -!- bsm117532 [~mcelrath@static-108-21-236-13.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
07:53 -!- testing-tape [~testing-t@cpe-172-73-230-228.carolina.res.rr.com] has joined #bitcoin-core-dev
08:01 < mcelrath> Hmm I can't assign this to myself: https://github.com/bitcoin/bitcoin/issues/6903
08:02 -!- zooko [~user@75-171-192-140.hlrn.qwest.net] has quit [Ping timeout: 265 seconds]
08:03 < sipa> morcos: leveldb cache
08:03 < morcos> sipa: you mean its internal caching?
08:03 < sipa> yes
08:04 < morcos> oh i see, ha, i thought that local variable wasn't used anywhere, i didn't think to look in init
08:08 < GitHub195> [bitcoin] LordOfTheCoin opened pull request #6904: LevelDB Fixes and Enhancements (master...2015_sqlite) https://github.com/bitcoin/bitcoin/pull/6904
08:09 < mcelrath> Why is someone other than jgarzik making PR's from his repo?
08:11 < sipa> heh, i didn't even realize that by seeing github's email
08:22 -!- ParadoxSpiral [~ParadoxSp@p508B8BF6.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
08:22 < mcelrath> FYI, replacing auto_ptr -> unique_ptr (C++11) in the 5 places it appears does not introduce any new compiler errors or warnings due to the slightly different assignment semantics.  So making this replacement should be fine to switch to C++11.
08:27 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
08:30 -!- testing-tape [~testing-t@cpe-172-73-230-228.carolina.res.rr.com] has quit [Remote host closed the connection]
08:30 -!- testing-tape [~testing-t@cpe-172-73-230-228.carolina.res.rr.com] has joined #bitcoin-core-dev
08:34 -!- testing-tape [~testing-t@cpe-172-73-230-228.carolina.res.rr.com] has quit [Remote host closed the connection]
08:40 -!- mcelrath [~bsm117532@38.121.165.30] has quit [Remote host closed the connection]
08:46 -!- danielsocials [~quassel@45.32.248.113] has quit [Remote host closed the connection]
08:48 -!- bsm1175321 [~bsm117532@38.121.165.30] has joined #bitcoin-core-dev
08:48 -!- bsm1175321 is now known as mcelrath
08:57 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-core-dev
08:57 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has quit [Changing host]
08:57 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
09:10 < GitHub101> [bitcoin] LordOfTheCoin closed pull request #6904: LevelDB Fixes and Enhancements (master...2015_sqlite) https://github.com/bitcoin/bitcoin/pull/6904
09:10 < GitHub8> [bitcoin] LordOfTheCoin reopened pull request #6904: LevelDB Fixes and Enhancements (master...2015_sqlite) https://github.com/bitcoin/bitcoin/pull/6904
09:10 < GitHub5> [bitcoin] LordOfTheCoin closed pull request #6904: LevelDB Fixes and Enhancements (master...2015_sqlite) https://github.com/bitcoin/bitcoin/pull/6904
09:20 -!- testing-tape [~testing-t@cpe-172-73-230-228.carolina.res.rr.com] has joined #bitcoin-core-dev
09:22 -!- MarcoFalke [8af602f2@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.242] has joined #bitcoin-core-dev
09:25 -!- MarcoFalke [8af602f2@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.242] has quit [Client Quit]
09:26 -!- MarcoFalke [8af602f2@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.242] has joined #bitcoin-core-dev
09:40 -!- ParadoxSpiral [~ParadoxSp@p508B8BF6.dip0.t-ipconnect.de] has quit [Quit: cya]
09:50 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
09:54 -!- testing-tape [~testing-t@cpe-172-73-230-228.carolina.res.rr.com] has quit [Ping timeout: 252 seconds]
09:54 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Ping timeout: 272 seconds]
10:14 < morcos> sipa: ok this might be a bit obscure, so i'll just look into if you have no idea off the top off your head.  but if I have a bunch of entries cached in a pcoinsTip and then I call TestBlockValidity on a block that accesses only those entries
10:15 < morcos> TBV will build a CCoinsViewCache on top of pcoinsTip, which cache will be passed to ConnectBlock which will build yet another on top.  modify the top most cache, and flush to the intermediate cache, then return to TBV which will just dump the intermediate cache on the ground
10:15 < morcos> any reason that would be FASTER if some of the entries in the pcoinsTip cache had FRESH or DIRTY flags as opposed to if they all had no flags.
10:24 < sipa> so pcoinsTip > TBV-Cache > ConnectBlock-Cache
10:25 < sipa> and it's in pcoinsTip that pre-existing flags would matter?
10:28 -!- BashCo [BashCo@gateway/vpn/mullvad/x-dictdpyvardghlpn] has quit [Remote host closed the connection]
11:02 -!- testing-tape [~testing-t@cpe-172-73-230-228.carolina.res.rr.com] has joined #bitcoin-core-dev
11:04 < MarcoFalke> cfields, would you mind if I rebase trivial-next?
11:06 < cfields> MarcoFalke: sorry i missed your pm the other day. you could, but it's kinda a pain. i'd prefer to take care of it this week. I think the separate repo turned out to not make things any easier.
11:08 < MarcoFalke> Ok, then. I will leave it to you to take care of it.
11:19 -!- testing-tape [~testing-t@cpe-172-73-230-228.carolina.res.rr.com] has quit [Remote host closed the connection]
11:19 -!- testing-tape [~testing-t@cpe-172-73-230-228.carolina.res.rr.com] has joined #bitcoin-core-dev
11:28 -!- zander [~quassel@kde/zander] has left #bitcoin-core-dev ["http://quassel-irc.org - Chat comfortably. Anywhere."]
11:28 -!- rubensayshi [~ruben@91.206.81.13] has quit [Ping timeout: 256 seconds]
11:28 < GitHub129> [bitcoin] MarcoFalke opened pull request #6905: Use constants and minor fixes by luke-jr (master...lukejr-constants-no-mergeConf) https://github.com/bitcoin/bitcoin/pull/6905
11:29 < GitHub81> [bitcoin] gmaxwell opened pull request #6906: Reject invalid pubkeys when reading ckey items from the wallet. (master...ckey_pubkey_check) https://github.com/bitcoin/bitcoin/pull/6906
11:31 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
11:33 -!- BashCo_ [BashCo@gateway/vpn/mullvad/x-ommhhcmwkatrtcxe] has joined #bitcoin-core-dev
11:35 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 250 seconds]
11:42 < morcos> sipa: yeah thats what i meant, but maybe thats not the issue.  i'll dig into it.  but i really like this idea of keeping the hot items in the cache.  then you can flush it much more regularly and don't have to worry about it growing too big.
11:53 < GitHub171> [bitcoin] MarcoFalke closed pull request #6905: Use constants and minor fixes by luke-jr (master...lukejr-constants-no-mergeConf) https://github.com/bitcoin/bitcoin/pull/6905
11:53 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has quit [Ping timeout: 260 seconds]
11:58 -!- jgarzik [~jgarzik@172.85.35.242] has joined #bitcoin-core-dev
11:58 -!- jgarzik [~jgarzik@172.85.35.242] has quit [Changing host]
11:58 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-core-dev
12:02 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
12:03 < morcos> sipa: oh i lied about that anywya,  there is no extra cache in ConnectBlock.  it just uses the TBV cache, or in the normal case the cache on pcoinsTip is added in ConnectTip before ConnectBlock
12:04 -!- zooko [~user@c-73-14-173-69.hsd1.co.comcast.net] has joined #bitcoin-core-dev
12:04 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: This computer has gone to sleep]
12:04 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-core-dev
12:04 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has quit [Changing host]
12:04 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
12:44 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
12:44 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Read error: No route to host]
12:53 -!- testing-tape [~testing-t@cpe-172-73-230-228.carolina.res.rr.com] has quit [Remote host closed the connection]
12:53 -!- testing-tape [~testing-t@cpe-172-73-230-228.carolina.res.rr.com] has joined #bitcoin-core-dev
12:56 -!- zooko [~user@c-73-14-173-69.hsd1.co.comcast.net] has quit [Ping timeout: 272 seconds]
13:00 < MarcoFalke> Any thoughts on the clang-format thing?
13:01 < mcelrath> FYI: https://github.com/andrewseidl/githook-clang-format "Warning: Do not use this on an existing codebase that isn't already in your desired style. Doing so will lead to a string a dirty commits where your code changes are intermixed with clang-format's formatting changes. Furthermore, every developer will need to install this hook. If they don't, you will again end up with commits with a mixture of code and formatting changes."
13:01 -!- testing-tape [~testing-t@cpe-172-73-230-228.carolina.res.rr.com] has quit [Remote host closed the connection]
13:01 < jgarzik> already covered in #bitcoin-dev meeting
13:01 -!- testing-tape [~testing-t@cpe-172-73-230-228.carolina.res.rr.com] has joined #bitcoin-core-dev
13:02 < MarcoFalke> Do those channels have different scopes? I remember bitcoin-dev is deprecated?
13:11 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Quit: airport]
13:19 < wumpus> this channel has a very narrow scope: code changes to the bitcoin core project
13:20 < sipa> clang format discussion would be very ontopic here IMHO
13:20 < sipa> but it was somehow part of the wider bitcoin irc meeting, which took place in #bitcoin-dev an hour ago
13:28 < davec> Is it intentional that the "minRelayTxFee" is not actually a minimum?  I suspect the answer is yes and the variable simply wasn't renamed.
13:29 < MarcoFalke> It's a minimum per node basis to get into that nodes mempool.
13:30 < davec> Well, the code is doing https://github.com/bitcoin/bitcoin/blob/master/src/amount.cpp#L22-L27
13:31 < davec> so if you have a tx of say 250 bytes, the will result in 250 * 1000 (the default "minRelayTxFee") / 1000 = 250 which is clearly < 1000
13:31 < MarcoFalke> yes, it's per kB
13:33 < wumpus> right it's the minimum *per KB*, all fees in bitcoin core are per kB
13:34 < wumpus> all fee settings at least
13:34 < MarcoFalke> wumpus, not paytxfee ;)
13:34 < MarcoFalke> not yet at least
13:36 < davec> alright thanks for confirming.  The naming and description made it seem like it was an absolute minumum, so I wanted to confirm.
13:36 < davec> because that's obviously not what the code is doing
13:37 < wumpus> MarcoFalke: hmm
13:47 -!- zooko [~user@c-73-217-96-13.hsd1.co.comcast.net] has joined #bitcoin-core-dev
13:54 -!- zooko [~user@c-73-217-96-13.hsd1.co.comcast.net] has quit [Ping timeout: 240 seconds]
13:58 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
13:58 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-core-dev
13:59 < MarcoFalke> Does src/qt require a different .clang-format style file?
14:09 -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-core-dev
14:11 < GitHub71> [bitcoin] jtimon opened pull request #6907: Chainparams: Use a regular factory for creating chainparams (master...chainparams-factory-0.12.99) https://github.com/bitcoin/bitcoin/pull/6907
14:23 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Ping timeout: 260 seconds]
14:25 < GitHub107> [bitcoin] jtimon opened pull request #6908: Chainparams: DRY: Make qt/guiutil.cpp fit BIP70 chain name strings (master...chainparams-bip70-0.12.99) https://github.com/bitcoin/bitcoin/pull/6908
14:30 < sipa> heh, a rebase with master jumps to 300-600% CPU usage immediately
14:30 < sipa> *reindex
14:31 < gmaxwell> thats because reindex checks all the signatures.
14:31 < sipa> not historical ones?
14:31 < gmaxwell> yes, historical ones.
14:32 < sipa> oh, because we don't have the header yet for the chainpoint it is an ancestor of
14:36 -!- daniel___ [~quassel@106.120.101.38] has quit [Ping timeout: 268 seconds]
14:36 -!- daniel___ [~quassel@106.120.101.38] has joined #bitcoin-core-dev
16:25 < GitHub7> [bitcoin] MarcoFalke reopened pull request #6905: Use constants and minor fixes by luke-jr (master...lukejr-constants-no-mergeConf) https://github.com/bitcoin/bitcoin/pull/6905
16:27 < phantomcircuit> sipa, :)
16:27 -!- BashCo_ [BashCo@gateway/vpn/mullvad/x-ommhhcmwkatrtcxe] has quit [Remote host closed the connection]
16:28 -!- BashCo [BashCo@gateway/vpn/mullvad/x-ikqmrheudagnhndi] has joined #bitcoin-core-dev
16:38 -!- MarcoFalke [8af602f2@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.242] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
16:53 < gmaxwell> Can someone build me windows binaries for https://github.com/bitcoin/bitcoin/pull/6906 ?   (oh I miss the testers that produced binaries as a side effect...)
17:05 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
17:07 < gmaxwell> sipa: ^ are you setup to produce windows binaries right now?
17:07 < warren> gmaxwell: here?
17:08 < gmaxwell> right.
17:08 < warren> gmaxwell: sorry the split wasn't entirely clear to me.
17:08 -!- BashCo [BashCo@gateway/vpn/mullvad/x-ikqmrheudagnhndi] has quit [Ping timeout: 240 seconds]
17:08 < gmaxwell> warren: this channel should be for bitcoin core exclusive discussion.
17:08 < gmaxwell> no one else gives a hoot at how our rpc auth works. :)
17:09 < Luke-Jr> Fedora does apparently
17:09  * Luke-Jr hides
17:09 < sipa> gmaxwell: do i get 30 minutes to find a bug? :)
17:10 < gmaxwell> sipa: hahah
17:10 < gmaxwell> sipa: I don't want it merged; there is a user that manged to get pubkey "" in his wallet on bct, and I want to give him a binary to see if it rejects it.
17:11 < gmaxwell> warren: as far as selinux policy, I think it's unfortunate that you cannot confine bitcoin core to have no access outside of its own directory.
17:12 < gmaxwell> though maybe that should be a boolean.
17:12 < gmaxwell> since its only needed for the walletimport/backup stuff.
17:13 < warren> Would it be bad if the system-level systemd service were named something like bitcoinsys.service, with a selinux context bitcoinsys_t, and a bitcoin-cli wrapper named something like /usr/bin/bitcoinsys_cli that only adds the --datadir /path/to/system/datadir/
17:13 < Luke-Jr> and what if the user wants bitcoind run per-user? :P
17:16 < gmaxwell> warren: what happens if a second datadir is specified to bitcoin-cli?
17:16 < gmaxwell> warren: it's all ugly, bitcoin core is currently not intended for system level operation. 
17:17 < warren> gmaxwell: hence why i'm against shipping a .service file at all
17:20 < gmaxwell> in any case that doesn't sound too horrible but the wrapper would need to not prevent you from overriding the datadir, and it needs to be tested with e.g. super long inputs.
17:21 < gmaxwell> better perhaps would be a compile time setting to adjust the default datadir. Do we have one of those?
17:22 -!- testing-tape [~testing-t@cpe-172-73-230-228.carolina.res.rr.com] has quit [Ping timeout: 252 seconds]
17:23 < sipa> not afaik
17:23 < sipa> gmaxwell: bug found, will build
17:23 < gmaxwell> lol okay.
17:24 < Luke-Jr> warren: doesn't systemd support per-user services?
17:24 < sipa> Luke-Jr: systemd would be a great operating system, if it only contained a service manager
17:24 < sipa> s/if it only/if only it/
17:24 < Luke-Jr> don't get me wrong, I hate systemd. but I thought this was one of the few benefits to it.
17:26 -!- pavel_ [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-core-dev
17:26 < gmaxwell> Seperate subject; https://github.com/bitcoin/bitcoin/pull/6902  I feel that changes like this make the software more opaque.  Now to understand whats being done there you must read two places instead of one.  If you only look at policy.h you will likely erroniously believe it applies to p2sh somehow.
17:27 < warren> Luke-Jr: yes it's possible
17:28 < gmaxwell> It's of a class of change where I purposfully try to keep my opinion to myself to avoid amplifying bikeshedding, because it fundimentally does not matter.
17:28 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Ping timeout: 250 seconds]
17:32 < sipa> gmaxwell: 32-bit or 64-bit?
17:33 < sipa> gmaxwell: will take a while to build dependencies
17:34 < gmaxwell> user say "or" so 64-bit I guess.
17:50 < GitHub198> [bitcoin] nathanimpact opened pull request #6909: 0.8 (master...0.8) https://github.com/bitcoin/bitcoin/pull/6909
17:50 < GitHub180> [bitcoin] gmaxwell closed pull request #6909: 0.8 (master...0.8) https://github.com/bitcoin/bitcoin/pull/6909
17:50 < GitHub190> [bitcoin] nathanimpact opened pull request #6910: 0.9 (master...0.9) https://github.com/bitcoin/bitcoin/pull/6910
17:51 < GitHub40> [bitcoin] nathanimpact opened pull request #6911: 0.10 (master...0.10) https://github.com/bitcoin/bitcoin/pull/6911
17:51 < GitHub112> [bitcoin] gmaxwell closed pull request #6910: 0.9 (master...0.9) https://github.com/bitcoin/bitcoin/pull/6910
17:51 < GitHub69> [bitcoin] nathanimpact opened pull request #6912: 0.11 (master...0.11) https://github.com/bitcoin/bitcoin/pull/6912
17:51 < gmaxwell> I wish github would let you block these.
17:51 < GitHub93> [bitcoin] gmaxwell closed pull request #6911: 0.10 (master...0.10) https://github.com/bitcoin/bitcoin/pull/6911
17:52 < GitHub198> [bitcoin] gmaxwell closed pull request #6912: 0.11 (master...0.11) https://github.com/bitcoin/bitcoin/pull/6912
17:52 < GitHub45> [bitcoin] nathanimpact opened pull request #6913: 0.11 (master...0.11) https://github.com/bitcoin/bitcoin/pull/6913
17:54 < belcher> you can block them(!) on the settings panel somewhere in github you can configure these to happen or not
17:54 < gmaxwell> belcher: what specifically does it block?
17:54 < belcher> turns off or on these bots
17:55 < sipa> belcher: we want to block the PRs, not the reporting here :)
17:55 < belcher> i see, im not sure thats possible
17:55 < belcher> if you know they're coming you could set the channel mode +n (i think) which stops them being able to message without joining
17:56 < petertodd> gmaxwell: ACK re your thoughts on #6902 - this isn't a constant that you can change after all!
17:57 < gmaxwell> the bots we want, just not the pointless PRs to merge entire (sometimes altcoin) branches into master.
17:59 < sipa> gmaxwell: building qt failed, sorry
17:59 < petertodd> gmaxwell: er, scrap that, no policy, not script, dumb of me...
17:59 < sipa> not going to spend time investigating
18:20 -!- testing-tape [~testing-t@cpe-172-73-230-228.carolina.res.rr.com] has joined #bitcoin-core-dev
18:25 -!- testing-tape [~testing-t@cpe-172-73-230-228.carolina.res.rr.com] has quit [Ping timeout: 272 seconds]
18:29 < GitHub139> [bitcoin] sipa opened pull request #6914: [WIP] Add pre-allocated vector type and use it for CScript (master...prevector) https://github.com/bitcoin/bitcoin/pull/6914
18:31 < gmaxwell> sipa: why doesn't it bounds check?
18:31 < sipa> gmaxwell: because i'm lazy
18:32 < gmaxwell> sipa: 13% faster with script checking enabled?!
18:32 < sipa> gmaxwell: disabled
18:32 < gmaxwell> oh disabled good.
18:32 < gmaxwell> okay. Yea, missed that on first read.
18:33 < GitHub7> [bitcoin] sdaftuar opened pull request #6915: [Mempool] Improve removal of invalid transactions after reorgs (master...fix-reorg-handling) https://github.com/bitcoin/bitcoin/pull/6915
18:34 < sipa> the only place where we actually use ::at() is in CScript::IsPayToScriptHash(), and it's prefixed with a size check there
18:35 < gmaxwell> maybe just get rid of the at and make it not compile if its used? Rationale: providing something thats almost vector but less safe in some subtle way will be forgotten. :)
18:37 < gmaxwell> sipa: did you fix the scriptcheck on reindex generally or just patch it out? if the former can you PR the fix?
18:37 < sipa> i just patched it out
18:37 < gmaxwell> (that particular misbehavior is a beautiful interaction with the always need to reindex issue in windows I bet. :-/ )
18:57 < sipa> gmaxwell: building 6906 (+6900, since windows building is broken on modern mingw without 6900)
18:58 < CodeShark> are you guys trying to reproduce the windows db corruption issues? :)
18:58 < gmaxwell> not at the moment.
18:58 < gmaxwell> CodeShark: warren was talking about that earlier.
18:59 < gmaxwell> I'm trying to debug a wallet that ended up with a corrupted pubkey in it.
18:59 < gmaxwell> which is in possession of an end user who is helpful but needed a binary.
18:59 < CodeShark> ah
19:01 -!- daniel___ [~quassel@106.120.101.38] has quit [Ping timeout: 252 seconds]
19:01 -!- daniel___ [~quassel@106.120.101.38] has joined #bitcoin-core-dev
19:03 < gmaxwell> As an aside, same user is running a 0.8GB wallet with hundreds of thousands of transactions, on windows.
19:04 < CodeShark> hah
19:04 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-dadfgdahjgxjrqfs] has quit [Quit: Connection closed for inactivity]
19:04 < CodeShark> doesn't sound very pleasant on multiple fronts :p
19:19 < dcousens> sipa: around?
19:19 < sipa> yes
19:20 < dcousens> sipa: 23% less memory, sounds like its simply a matter of the allocator being more exact instead of allocating more generously etc
19:20 < sipa> ?
19:21 < dcousens> sipa: conceptually, how does https://github.com/bitcoin/bitcoin/pull/6914 save memory, except that in some cases it is allocated on the stack?
19:21 < sipa> dcousens: well it uses 32-bit instead of 64-bit sizes
19:21 < dcousens> (and ignoring the 4/8 byte pointer)
19:21 < sipa> so it always saves 4 to 8 bytes
19:21 < sipa> apart from that, the only way it saves is by not allocating on the heap
19:22 < sipa> which has a 16-32 byte overhead
19:22 < dcousens> and the hunch is that takes up 23% of available memory?
19:22 < sipa> so the old structure is on average 40 + N bytes storage
19:23 < sipa> sorry, 48 + N
19:23 < sipa> the new one is 32 for N<=28, and 56 + N for N > 28
19:24 < sipa> since almost all CScripts in memory are P2PKH or P2SH, which are less than 28 bytes, this is an improvement
19:25 < gmaxwell> sipa: aren't the N objects seperately heap allocated?
19:27 < dcousens> sipa: any reason not to just use union a std::array and std::vector?
19:27 < sipa> gmaxwell: no
19:28 < sipa> dcousens: that would be much larger
19:28 < sipa> the trick here is to share the size variable between the two approaches
19:28 < sipa> which you can't do if you use the standard std::vector
19:30 < gmaxwell> sipa: hm for some reason I thought it was, so that the removal of objects could be supported without invalidating pointers.
19:30 < dcousens> sipa: could the same memory savings be achieved by just abstracting a CScript specialised for smaller sizes?
19:31 < dcousens> Eh, that'd be as bad nvm
19:31 < sipa> dcousens: perhaps i failed to highlihght the largest advantage: reducing load on the heap
19:31 < sipa> which results in worse memory locality and memory fragmentation :)
19:31 < sipa> gmaxwell: you're thinking about a linked list...
19:31 < dcousens> indeed, probably where the 13% speedup came from
19:32 < sipa> dcousens: and simpler copying
19:32 < sipa> gmaxwell: a vector can't delete elements without invalidating iterators
19:33 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
19:35 < dcousens> sipa: is push_back used at all?
19:35 < sipa> no clue
19:36 < dcousens> just wondering, maybe drop the capacity functionality if we don't need it
19:36 < dcousens> I feel like we' wouldn't be re-allocating these vectors very often
19:36 < sipa> well i wanted something API compatible :)
19:36 < sipa> so it's not a huge burden to go review whether it can be used or not
19:37 < sipa> if you just want a compact vector, there are other changes you can make
19:37 < dcousens> sipa: I guess if you're looking for public compatibility
19:37 < dcousens> sipa: IMHO for a change like this, we should start with the smallest subset of changes, optimize on that, then introduce public API compatibility
19:38 < sipa> the subset of changes is as small as it can be
19:38 < sipa> the PR contains a few not-strictly necessary changes to just break the assumption that CScript is a vector
19:42 < dcousens> ooi, why free vs new?
19:42 < sipa> because i need realloc
19:43 < sipa> and this works at a lower level: it's allocating memory, not objects
19:43 < sipa> new is for allocating objects
19:43 < dcousens> ? you have a clear type though
19:43 < sipa> which?
19:43 < dcousens> the realloc might not be necessary if you don't need the push_back/change_capacity etc
19:44 < dcousens> T
19:44 < sipa> no, that would call T's constructor
19:44 < sipa> the reserved but unused memory doesn't contain constructed T objects
19:44 < dcousens> True, but isn't T in this case always a char*?
19:44 < sipa> i don't plan to just use this for char
19:45 < dcousens> hmmm, well, code looks good, tentativee ACK simply cause I'm still not sure its the best way, but, it is a solution, and it exists :) wd
19:49 < gmaxwell> sipa: did the prior stl instrumentation you did before allow you to easily measure vector overhead in a useful way to go find the biggest offenders?
19:49 < dcousens> if we broke the API compatibility, I feel like we could just use managed pointers [at the CSCript level] quite easily with a pooled stack allocator for small scripts, but, if this might be easier if you have other future plans for other areas
19:50 < sipa> dcousens: that would indeed by an improvement; CBlock could have its own pool for example, and CTransaction could couple a pool too
19:50 < sipa> dcousens: but it's a much more invasive change to do well
19:50 < dcousens> indeed
19:50 < sipa> gmaxwell: define offender?
19:51 < dcousens> sipa: I guess the benefit of this change, with API compatibility, is it doesn't hinder that path in any (except maybe making it look less attractive haha)
19:51 < gmaxwell> I do not see why we'd want _any_ overhead of having constant allocation indirection for data where 99.999% of the time its a fixed size. even having the extra pointer is overhead we don't need.
19:53 < dcousens> gmaxwell: as mentioned above, to do that (I assume you mean using fixed size CScripts), it'd be a more invasive change
19:53 < gmaxwell> sipa: places where many vectors with a total amount of data them that is almost always small with respect to 40 bytes.
19:53 < sipa> gmaxwell: vectors have 40 byte overhead on average (including the malloc overhead) per vector
19:53 < dcousens> gmaxwell: or by extra pointer did you mean cap?
19:54 < gmaxwell> dcousens: what sipa is doing now is almost a fixed size cscript, no-- only when its an exceptional cscript does it fail over to using an allocation.
19:55 < sipa> i'm using 28 bytes as cutoff; there are many scripts larger (nearly every scriptSig)
19:55 < sipa> but in places where storage matters, more than 28 is a minority
19:56 < sipa> i used 36 earlier, and that was still a net benefit, but a smaller one
19:56 < gmaxwell> ah, I did forget this was used for ScriptSig too.
19:58 < phantomcircuit> it's kind of amusing how we can optimize for the current set of data and have that not be a huge issue... since it will never change
19:58 < sipa> if we'd switch to a P3SH with a 256-bit hash, we may need to change it :)
19:59 < sipa> we could use this for valtype inside the script evaluator too, set to 72 bytes (as we rarely have larger script elements), or to 520 (as we don't support larger at all)
19:59 < phantomcircuit> heh
19:59 < phantomcircuit> sipa, sure but like if block_height < 350000 then vectortype = x else vectortype = y
20:00 < gmaxwell> obviously it needs to be autoadaptive. :P
20:00 < phantomcircuit> :)
20:02 < gmaxwell> Another obvious thing to try is to breakpoint at the validation of block X, then breakpoint at malloc/new  and catch every place it hits the heap allocator during verification of that block.
20:10 < dcousens> ignoring memory, I wonder if you just fixed size it to 520 bytes
20:10 < gmaxwell> dcousens: it can be larger than 520 bytes.
20:11 < phantomcircuit> gmaxwell, how?
20:11 < gmaxwell> 0_o
20:11 < sipa> CScript can be larger than 520 bytes
20:11 < sipa> script stack elements can;t
20:11 < gmaxwell> phantomcircuit: this is the full script pubkey in a transaction or a full scriptsig in a transaction.
20:12 < gmaxwell> scriptsigs larger than that are probably not even all that uncommon. 
20:12 -!- zooko [~user@2601:281:8001:26aa:1006:12d4:5519:6f16] has joined #bitcoin-core-dev
20:12 < phantomcircuit> ohh
20:13 < phantomcircuit> i thought you were just optimizing for the push data
20:48 < warren> gmaxwell: a safe wrapper that passes all parameters to some other program is simple like: http://pkgs.fedoraproject.org/cgit/couchdb.git/tree/couchdb.temporary.sh
20:48 < warren> https://fedoraproject.org/wiki/BITCOIN  
20:50 < warren> I wrote down what I think would be good for the two different ways in which people want to use bitcoind, as a user and as a system service.  Both would need separate SELinux contexts, and a wrapper like http://pkgs.fedoraproject.org/cgit/couchdb.git/tree/couchdb.temporary.sh  to launch the system service under the different context.
21:12 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has quit [Ping timeout: 260 seconds]
21:14 -!- zooko [~user@2601:281:8001:26aa:1006:12d4:5519:6f16] has quit [Ping timeout: 240 seconds]
21:23 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
21:43 -!- NLNico [~NLNico@unaffiliated/nlnico] has joined #bitcoin-core-dev
22:18 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Quit: .]
22:19 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
22:35 -!- PaulCape_ [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
22:37 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Ping timeout: 240 seconds]
23:00 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
23:03 -!- PaulCape_ [~PaulCapes@204.28.124.82] has quit [Ping timeout: 252 seconds]
23:17 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has quit [Quit: Later.]
23:26 -!- challisto [~challisto@c-76-16-149-33.hsd1.il.comcast.net] has joined #bitcoin-core-dev
23:26 -!- challisto [~challisto@c-76-16-149-33.hsd1.il.comcast.net] has quit [Changing host]
23:26 -!- challisto [~challisto@unaffiliated/challisto] has joined #bitcoin-core-dev
23:26 -!- PaulCape_ [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
23:29 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Ping timeout: 264 seconds]