--- Log opened Tue Jul 31 00:00:26 2018
00:01 -!- ken2812221 [~User@180.217.140.78] has joined #bitcoin-core-dev
00:02 -!- elkalamar [~elkalamar@unaffiliated/elkalamar] has quit [Ping timeout: 256 seconds]
00:06 -!- elkalamar [~elkalamar@unaffiliated/elkalamar] has joined #bitcoin-core-dev
00:15 -!- Guest43893 [~elkalamar@unaffiliated/elkalamar] has joined #bitcoin-core-dev
00:18 -!- elkalamar [~elkalamar@unaffiliated/elkalamar] has quit [Ping timeout: 264 seconds]
00:25 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev
00:29 -!- elkalamar [~elkalamar@unaffiliated/elkalamar] has joined #bitcoin-core-dev
00:30 -!- Guest43893 [~elkalamar@unaffiliated/elkalamar] has quit [Ping timeout: 244 seconds]
00:38 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev
00:41 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:82:b84:d414:bb83] has quit [Remote host closed the connection]
00:45 -!- go1111111 [~go1111111@199.231.240.191] has quit [Ping timeout: 248 seconds]
00:56 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
00:58 -!- go1111111 [go1111111@gateway/vpn/privateinternetaccess/go1111111] has joined #bitcoin-core-dev
01:00 -!- elkalamar [~elkalamar@unaffiliated/elkalamar] has quit [Read error: Connection reset by peer]
01:01 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 244 seconds]
01:39 -!- no_input_found [no_input_f@gateway/vpn/privateinternetaccess/noinputfound/x-24977668] has quit [Remote host closed the connection]
01:40 -!- no_input_found [no_input_f@gateway/vpn/privateinternetaccess/noinputfound/x-24977668] has joined #bitcoin-core-dev
01:42 -!- elkalamar [~elkalamar@unaffiliated/elkalamar] has joined #bitcoin-core-dev
01:44 -!- elkalamar [~elkalamar@unaffiliated/elkalamar] has quit [Read error: Connection reset by peer]
01:48 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has quit [Ping timeout: 268 seconds]
01:50 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has joined #bitcoin-core-dev
02:03 -!- face [~face@80.72.82.160.coresnet.bg] has quit [Ping timeout: 260 seconds]
02:08 -!- elkalamar [~elkalamar@unaffiliated/elkalamar] has joined #bitcoin-core-dev
02:13 -!- elkalamar [~elkalamar@unaffiliated/elkalamar] has quit [Ping timeout: 244 seconds]
02:26 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
02:38 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
02:41 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
02:46 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev
02:46 < fanquake> wumpus: heh, I saw that "loss" as well. Got emailed twice for some reason
02:48 < wumpus> fanquake: well I didn't see my comment so I posted another one, then suddenly they both appeared
02:49 < fanquake> wumpus GH playing tricks on you
02:51 < fanquake> Also please don't merge 13809 yet, few things to be fixed up first, to avoid lots of followups
03:02 < wumpus> OK, please comment that there so anyone else won't merge it either
03:54 < mryandao> typically most linux distribution follow XDG specification for looking up config files, would this be preferable in Core? I know there was a previous closed issue which mentioned this, but we could keep the datadir cache separate in ~/.bitcoin as is
03:55 < mryandao> the upside of this is that daemon configuration can be easier to backup for users who just scoop the entire XDG_BASE_DIR
04:05 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
04:08 < harding> mryandao: do you think there's lots of people who backup just .config/ and not their whole home directories?  The stuff in my .config represents perhaps a few hours of tweaking over years, but the stuff in the rest of my home directory represents many hours of work each day over the same number of years.
04:08 < mryandao> harding: personally, i only backup my .config directory since my homedir would have accumulated a bunch of unwanted stuff in new installations.
04:10 < mryandao> especially when it comes to hidden directories in home :/
04:15 < harding> mryandao: ok.  I guess I have a different backup philosophy than you do.  I use cheap external HDs, and so I just grab everything indiscriminately.  I think there probably is an advantage to fully separating stuff we really want users to backup (e..g bitcoin.conf and wallets) from stuff that's just nice to backup (e.g. old blocks), but I personally don't think that's enough of an advantage to make them have to go looking around 
04:15 < harding> various places in their home directory for different Bitcoin-related resources.
04:23 -!- arubi_ [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev
04:25 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 250 seconds]
04:31 < fanquake> wumpus I was looking at the wrong things before. Feel free to ignore my nit on 13809 and merge it.
04:37 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
04:38 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
04:38 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev
04:43 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Ping timeout: 265 seconds]
04:47 -!- Soligor [~Soligor@unaffiliated/soligor] has quit [Ping timeout: 245 seconds]
04:56 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
04:59 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
05:00 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev
05:00 -!- farmerwampum [~farmerwam@88.202.178.98] has joined #bitcoin-core-dev
05:14 -!- Soligor [~Soligor@unaffiliated/soligor] has joined #bitcoin-core-dev
06:00 -!- elkalamar [~elkalamar@unaffiliated/elkalamar] has joined #bitcoin-core-dev
06:05 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit []
06:14 < bitcoin-git> [bitcoin] scravy opened pull request #13816: travis: build and run tests on os: osx (master...run-functional-tests-on-macos) https://github.com/bitcoin/bitcoin/pull/13816
06:22 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
06:32 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
06:40 -!- sturles [~sturles@unaffiliated/sturles] has quit [Ping timeout: 240 seconds]
06:46 -!- JackH [~laptop@2a01:4c8:103d:e041:891a:ea6a:dc66:3f99] has joined #bitcoin-core-dev
06:50 -!- Amuza [~amuza@85.159.207.5] has joined #bitcoin-core-dev
07:16 -!- nodweber [~nodweber@unaffiliated/nodweber] has joined #bitcoin-core-dev
07:21 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
07:22 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
07:23 < bitcoin-git> [bitcoin] Sjors opened pull request #13818: More intuitive GUI settings behavior when -proxy is set (master...2018/07/gui-proxy) https://github.com/bitcoin/bitcoin/pull/13818
07:35 -!- Amuza [~amuza@85.159.207.5] has quit [Ping timeout: 268 seconds]
07:36 -!- michaelsdunn1 [~michaelsd@38.126.31.226] has joined #bitcoin-core-dev
08:05 < bitcoin-git> [bitcoin] chipstar opened pull request #13820: Replace Bitcoin to XPChain (master...replace-botcoin-to-xpchain) https://github.com/bitcoin/bitcoin/pull/13820
08:06 < gmaxwell> sipa: ^ plz close
08:07 < gmaxwell> actually, he PRed from his master, so you could also helpfully remove his repository too... :-/
08:08 < bitcoin-git> [bitcoin] chipstar closed pull request #13820: Replace Bitcoin to XPChain (master...replace-botcoin-to-xpchain) https://github.com/bitcoin/bitcoin/pull/13820
08:14 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
08:15 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
08:39 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has joined #bitcoin-core-dev
08:48 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has quit [Quit: esoteric nonsense]
08:50 -!- satwo [~textual@2602:306:378a:6fb0:9d96:a15a:7769:a52b] has quit [Ping timeout: 245 seconds]
08:50 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has joined #bitcoin-core-dev
08:52 -!- esotericnonsens_ [~esotericn@unaffiliated/esotericnonsense] has joined #bitcoin-core-dev
08:52 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has quit [Read error: Connection reset by peer]
08:52 -!- esotericnonsens_ is now known as esotericnonsense
08:57 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev
08:57 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]
08:57 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8ce55df70d31...77168f766f15
08:57 < bitcoin-git> bitcoin/master fa0e1e2 MarcoFalke: contrib: Remove debian and rpm subfolders
08:57 < bitcoin-git> bitcoin/master 77168f7 MarcoFalke: Merge #13809: contrib: Remove debian and rpm subfolder...
08:59 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #13809: contrib: Remove debian and rpm subfolder (master...Mf1808-debianContrib) https://github.com/bitcoin/bitcoin/pull/13809
09:06 -!- bsm117532 [~mcelrath@c-24-61-245-53.hsd1.ma.comcast.net] has joined #bitcoin-core-dev
09:19 < bitcoin-git> [bitcoin] MarcoFalke pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/77168f766f15...230652cafc51
09:19 < bitcoin-git> bitcoin/master 04ce0d8 Pieter Wuille: Report when unknown config file options are ignored
09:19 < bitcoin-git> bitcoin/master 247d574 Pieter Wuille: Ignore unknown config file options for now
09:19 < bitcoin-git> bitcoin/master 230652c MarcoFalke: Merge #13799: Ignore unknown config file options; warn instead of error...
09:20 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #13799: Ignore unknown config file options; warn instead of error (master...201807_warnunknown) https://github.com/bitcoin/bitcoin/pull/13799
09:31 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:a48a:103:284a:a8b5] has joined #bitcoin-core-dev
09:37 -!- csknk [~csknk@unaffiliated/csknk] has joined #bitcoin-core-dev
09:51 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #13821: qa: Re-enable test for unknown arg in conf file (master...Mf1808-qaConfWarn) https://github.com/bitcoin/bitcoin/pull/13821
09:55 -!- no_input_found [no_input_f@gateway/vpn/privateinternetaccess/noinputfound/x-24977668] has quit [Ping timeout: 248 seconds]
09:56 -!- no_input_found [no_input_f@gateway/vpn/privateinternetaccess/noinputfound/x-24977668] has joined #bitcoin-core-dev
09:56 -!- arubi_ is now known as arubi
09:58 -!- csknk [~csknk@unaffiliated/csknk] has quit [Quit: leaving]
10:07 -!- Aaronvan_ is now known as AaronvanW
10:11 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #13821: qa: Re-enable test for unknown arg in conf file (master...Mf1808-qaConfWarn) https://github.com/bitcoin/bitcoin/pull/13821
10:20 -!- rex4539 [~rex4539@ppp-2-87-178-187.home.otenet.gr] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
10:38 -!- sturles [~sturles@unaffiliated/sturles] has joined #bitcoin-core-dev
10:56 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]
10:56 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev
11:04 -!- keymone [~keymone@ip1f13761c.dynamic.kabel-deutschland.de] has quit [Ping timeout: 244 seconds]
11:11 -!- keymone [~keymone@ip1f13761c.dynamic.kabel-deutschland.de] has joined #bitcoin-core-dev
11:32 < bitcoin-git> [bitcoin] achow101 opened pull request #13822: bench: Make CoinSelection output groups pass eligibility filter (master...fix-out-groups-bench) https://github.com/bitcoin/bitcoin/pull/13822
11:48 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/230652cafc51...7d3623794a10
11:48 < bitcoin-git> bitcoin/master 2fb0066 practicalswift: net: Add missing verification of IPv6 address in CNetAddr::GetIn6Addr(...)
11:48 < bitcoin-git> bitcoin/master 7d36237 Wladimir J. van der Laan: Merge #13776: net: Add missing verification of IPv6 address in CNetAddr::GetIn6Addr(...)...
11:49 < bitcoin-git> [bitcoin] laanwj closed pull request #13776: net: Add missing verification of IPv6 address in CNetAddr::GetIn6Addr(...) (master...call-IsIPv6-in-GetIn6Addr) https://github.com/bitcoin/bitcoin/pull/13776
12:06 -!- Orion3k [~Orion3k@66.133.74.90] has quit [Ping timeout: 240 seconds]
12:19 < ossifrage> This is a curious error: " dropped: non-selectable socket"
12:20 < ossifrage> They seem to happen in runs over several minutes
12:22 -!- Orion3k [~Orion3k@24-176-200-142.static.mtpk.ca.charter.com] has joined #bitcoin-core-dev
12:23 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #13823: qa: quote path in authproxy for external multiwallets (master...Mf1808-qaAuthProxyQuotePath) https://github.com/bitcoin/bitcoin/pull/13823
12:27 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7d3623794a10...0fb9c87815d1
12:27 < bitcoin-git> bitcoin/master 494634a Andrew Chow: bench: Make CoinSelection output groups pass eligibility filter...
12:27 < bitcoin-git> bitcoin/master 0fb9c87 MarcoFalke: Merge #13822: bench: Make CoinSelection output groups pass eligibility filter...
12:27 < ossifrage> I didn't think bitcoin would be using select(), I thought it would be using epoll() and friends?
12:28 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #13822: bench: Make CoinSelection output groups pass eligibility filter (master...fix-out-groups-bench) https://github.com/bitcoin/bitcoin/pull/13822
12:34 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
12:41 < ossifrage> it looks like bitcoin-qt is using up 800 FDs for open files (chainstate, txindex, etc...)
12:43 < ossifrage> 509 for txindex and 288 for chainstate
12:43 < sipa> ossifrage: longer term we'll probably switch to libevent
12:44 < sipa> which uses the most efficient polling mechanism on every platfor.
12:46 < ossifrage> sipa, any suggestions on reducing the number of FDs used by txindex?
12:49 < sipa> ossifrage: don't use txindex
12:49 < sipa> :)
12:50 < ossifrage> I wonder how painful of a project it would be to make the move to libevent?
12:51 < Dizzle> We're already using it for RPC and some other networking, right?
12:54 < ossifrage> Hmm, I wonder what bounds the number of FDs used by the txindex ldb files
12:57 < sipa> leveldb has a max open fileslimit
12:58 < sipa> how many connwctions do you have?
13:01 < ossifrage> sipa, 160
13:01 < ossifrage> (right now, but it looks like has been having troubles with new connections for a while due to the number of ldb files open)
13:02 < sipa> bitcoind tries to raise its max fd limit at startup
13:03 < ossifrage> sipa, the problem is with the FD_SET size which is 1024 :-(
13:03 < sipa> yes
13:04 < ossifrage> it looks like ldb is using 1000 fds (as per comment)
13:06 < ossifrage> I think I'll try rebuilding with the default set to 500 or so (I wonder if that is global or per database)
13:06 < ossifrage> However, I suspect it will take another month of runtime to accumulate that many open ldb files to test...
13:06 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]
13:07 < sipa> ossifrage: no, it's a runtime testing
13:07 -!- Krellan [~Krellan@50.242.94.241] has joined #bitcoin-core-dev
13:25 < jimpo> Is there an option for shared (read/write) locks w/o C++ 14?
13:26 < jimpo> looks like sigcache uses boost::shared_lock. is that acceptable or discouraged?
13:27 < sipa> i think as long as we don't have c++14, boost::shared_lock looks like a good solution
13:28 < gmaxwell> Is there really no read/write lock before C++14?!  Posix has had them for like 20 years!
13:28 -!- JackH [~laptop@2a01:4c8:103d:e041:891a:ea6a:dc66:3f99] has quit [Ping timeout: 256 seconds]
13:29 < gmaxwell> BlueMatt: See above FD_SET stuff. Is there any way I could bribe you to PR the patch that changes the net to use poll on Linux?
13:29 < gmaxwell> We have 1001 windows specific things in the codebase,  having a linux+bsd specific thing wouldn't be the end of the world.
13:30 < gmaxwell> And we've delayed doing the simple thing for eons, in favor of a grand change that has been slow in coming.
13:30 < gmaxwell> IIRC the patchs that you and patrick had done were like a dozen lines of code, and except for the fact that they added platform IFdefs, were totally clean.
13:30 < sipa> gmaxwell: before c++11, c++ didn't have any form of threading or synchronization primitives at all :)
13:31 < gmaxwell> sipa: I know but why the heck didn't C++11 catch up with basic features from decades ago? :(
13:31 < sipa> gmaxwell: my guess is that c++11 was already an enormous change
13:32 < gmaxwell> aside, <3 RW locks
13:32 < sipa> yes!
13:36 < sipa> the c++14 shared mutex doesn't support upgradable locking
13:37 < gmaxwell> I can see why upgradability would be useful for us, but I don't recall ever using it in my own code.
13:37 < gmaxwell> (maybe posix rw locks aren't even upgradable?)
13:37 < sipa> ah!
13:37 < sipa> https://stackoverflow.com/questions/34993983/upgrading-read-lock-to-write-lock-without-releasing-the-first-in-c11
13:38 < sipa> you can implement upgradable locks on top of shared and exclusive locks
13:38 < gmaxwell> for us I think the big win for rw locks is that we can make all the things that just need readonly access to the blockchain not block each other...
13:38 < gmaxwell> info-rpcs, wallet, P2P get* messages...
13:39 < gmaxwell> and that doesn't need an upgradable lock.
13:39 < sipa> upgradable locks would be nice in that they let us lock/unlock exclusive access during block validation
13:39 < gmaxwell> block processing could in theory use one, e.g. take a read lock to decide if the incoming block is already known to us, then promote to write if it isn't... but thats rare, might as well take the write lock.
13:40 < sipa> at times when the chainstate is consistent but not done
13:40 < gmaxwell> okay thats a point.
13:40 < sipa> basically you just need to upgrade when flushing the per-block utxo cache to the chainstate cache
13:41 < gmaxwell> I'm always a little warry about peppering the code with a lot of fine locking, since they're slow (potentially very slow if contended)
13:42 < gmaxwell> (and it's hard to tell that it's slow)
13:43 < sipa> uncontended locks are really fast (at least on linux)
13:44 < gmaxwell> It's all relative. I think they're always as slow as a cache line bounce, so equal to probably thousands of multiplies.
13:44 < sipa> the number i had in my mind was 100 cpu cycles for an uncontended loc
13:44 < sipa> but i can't remember actually ever validating that number
13:45 < gmaxwell> hm. okay so an order of magnitude between our beliefs.
13:45 < gmaxwell> I don't see how 100 is physically possible though.
13:45 < gmaxwell> not without doing some kind of transactional crazyness that can rollback the cpu on conflicts.
13:46 < sipa> http://ithare.com/infographics-operation-costs-in-cpu-clock-cycles/
13:47 < sipa> i think an uncontended lock is a few compare-and-swaps
13:48 < gmaxwell> so per that a few hundred cycles, seems fast to me, though thinking more about it, I guess it no longer strikes me as physically impossible to take a lock in 100 cycles IF you are the same core that last had the lock.
13:51 < gmaxwell> If you aren't then I don't think it's physically possible, another core could take the lock at the same time, and at 100 cycles, it's potentially outside of your lightcone. (13 cm)
13:53 < sipa> just wrote a small c++11 benchmark that creates a single thread which grabs a mutex, and increments a variable, and releases again
13:53 < sipa> 14 ns per iteration
13:53 < sipa> agreed, "always on the same thread" is a stronger condition than just "uncontended"
13:55 < gmaxwell> makes sense. yea, 14ns is just not physically possible if it has to consult with a far away core. but I guess it doesn't in common cases.
13:57 < sipa> now trying the same with 2 simultaneous threads
13:58 < sipa> just 100 ns per iteration?
13:58 < sipa> wtf
13:58 < sipa> i was expected several orders of magnitudes more
13:58 < gmaxwell> well, hyperthreading? :)
13:59 < gmaxwell> use taskset to force it into different sockets. :P
14:01 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:a48a:103:284a:a8b5] has quit [Ping timeout: 265 seconds]
14:05 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #13824: doc: Remove outdated net comment (master...Mf1808-docNetCritSec) https://github.com/bitcoin/bitcoin/pull/13824
14:09 -!- booyah [~bb@193.25.1.157] has quit [Ping timeout: 256 seconds]
14:09 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 256 seconds]
14:13 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:a48a:103:284a:a8b5] has joined #bitcoin-core-dev
14:25 -!- goatpig [56eece80@gateway/web/freenode/ip.86.238.206.128] has joined #bitcoin-core-dev
14:25 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
14:26 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
14:45 -!- Amuza [~amuza@93.176.180.166] has joined #bitcoin-core-dev
14:51 -!- rex4539 [~rex4539@ppp-2-87-178-187.home.otenet.gr] has joined #bitcoin-core-dev
14:54 < bitcoin-git> [bitcoin] jnewbery opened pull request #13825: [wallet] [Do not merge until v0.18] Kill accounts (master...kill_accounts) https://github.com/bitcoin/bitcoin/pull/13825
14:54 -!- Amuza [~amuza@93.176.180.166] has quit [Ping timeout: 248 seconds]
14:59 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]
15:00 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev
15:09 -!- no_input_found [no_input_f@gateway/vpn/privateinternetaccess/noinputfound/x-24977668] has quit [Remote host closed the connection]
15:09 -!- no_input_found [no_input_f@gateway/vpn/privateinternetaccess/noinputfound/x-24977668] has joined #bitcoin-core-dev
15:20 -!- michaelsdunn1 [~michaelsd@38.126.31.226] has quit [Remote host closed the connection]
15:21 -!- Orion3k [~Orion3k@24-176-200-142.static.mtpk.ca.charter.com] has quit [Ping timeout: 268 seconds]
15:33 -!- Orion3k [~Orion3k@185.236.200.212] has joined #bitcoin-core-dev
15:47 -!- Krellan [~Krellan@50.242.94.241] has quit [Ping timeout: 240 seconds]
15:49 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
16:07 -!- JackH [~laptop@213.205.240.238] has joined #bitcoin-core-dev
16:09 -!- jtimon [~quassel@213.28.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
16:12 -!- JackH [~laptop@213.205.240.238] has quit [Ping timeout: 256 seconds]
16:21 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 248 seconds]
16:22 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
16:29 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds]
16:30 -!- Dizzle [~dizzle@108.171.182.16] has quit [Quit: Leaving...]
16:35 -!- timothy [~tredaelli@redhat/timothy] has quit [Remote host closed the connection]
16:54 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
16:55 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
16:58 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:a48a:103:284a:a8b5] has quit [Ping timeout: 265 seconds]
17:04 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:a48a:103:284a:a8b5] has joined #bitcoin-core-dev
17:04 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
17:08 < BlueMatt> gmaxwell: the fd_set 1024 limit stuff shouldn't cause that kind of problem, ldb shouldnt use almost any fds on 64 bit and should use a low-ish count on 32 bit, no?
17:08 < BlueMatt> I thought that's where we landed (as mmap doesnt need to use an fd)
17:08 < sipa> ossifrage: are you on a 32-bit system?
17:08 < BlueMatt> fwiw I think I have a branch with a rdwr lock implemented somewhere, though I never ended up using it
17:11 < sipa> can you implement a shared lock without support from underlying primitives?
17:11 -!- nodweber [~nodweber@unaffiliated/nodweber] has quit [Ping timeout: 260 seconds]
17:11 < sipa> seems yes, after short googling
17:11 < BlueMatt> sipa: sure? with atomics and condvars, ofc
17:12 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Ping timeout: 248 seconds]
17:13 < sipa> yeah
17:13 < sipa> with just locks and condition variables you can implement any synchronization primitive, i believe
17:13  * sipa forgot
17:14 < BlueMatt> well, or s/atomics//
17:17 < BlueMatt> my old commit, no idea if its right but... https://github.com/TheBlueMatt/bitcoin/commit/8c5dc5e0ae19120fc79a6e4f7a56d60bbbacf348
17:24 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
17:24 -!- grubles [~grubles@unaffiliated/grubles] has quit [Ping timeout: 260 seconds]
17:25 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev
17:26 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
17:31 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 256 seconds]
17:38 -!- michaelsdunn1 [~michaelsd@208.59.170.5] has joined #bitcoin-core-dev
17:41 < ossifrage> sipa, no x86_64
17:41 < sipa> ossifrage: what OS?
17:42 < ossifrage> linux 4.16.5-300
17:43 < gmaxwell> ossifrage: why did you say above that ldb was using lots of FDs?
17:43 < ossifrage> That was from the output of lsof and some counting
17:44 < BlueMatt> that seems...surprising, given its supposed to do mmap and then close the fd
17:44 < sipa> i have a number of chainstate files open by bitcoind as well - most are mmaped, but not all
17:44 < BlueMatt> so it may still show up in lsof but not use an fd?
17:44 < ossifrage> I was counting file descriptors not maps
17:45 < sipa> i have 30 chainstate files open with an FD, and 999 with mmap
17:45 < ossifrage> The node has been up for >30 days if that makes any difference
17:45 < gmaxwell> come on, why can't we just take the not-many-line-change to use poll?  I know libevent future ra ra ra... but we have held off this simple fix for years. :(
17:46 < sipa> gmaxwell: we totally should
17:46 < ossifrage> I'm willing to test :-)
17:46 < BlueMatt> its super trivial to write
17:46 < BlueMatt> would take me longer to dig it up than someone rewrite it
17:46 < gmaxwell> I could dig up an old copy, but I know that phantomcircuit and BlueMatt run nodes with it.
17:46 < sipa> but i've also basically never encountered anyone actually seeing the "FD above 1024" error resulting in actually closed connections
17:46 < sipa> so i wonder what is special about ossifrage's setup
17:47 < sipa> or maybe just nobody ever paid attention to it
17:47 < gmaxwell> more fragmentation of databases?  You do see a bunch of files open.
17:47 < gmaxwell> It also can be caused by RPC connections using up FDs.
17:47 < BlueMatt> I dont bother running mine with it anymore, and regularly have 500+ connections
17:47 < BlueMatt> at least that's usually when one asshat makes 100 connections, but usually that asshat is me
17:47 < sipa> having hundreds of files would certainly explain fd<1024 shortage
17:48 < BlueMatt> and I have a ton of scripts that poll rpc regularly, but not constant, sooo
17:48 < ossifrage> I have txindex and sadly my bitcoin data is on a btrfs filesystem (a mistake I won't make again)
17:48 < BlueMatt> both of those are also true on my seednodes
17:48 < gmaxwell> I think we have had other complaints about fd shortage... but I think we were chalking them up to rpc.
17:48 < BlueMatt> I *know* there are issues with rpc
17:48 < ossifrage> The only reason I noticed a problem was I was dropping a ton of connection due to select()
17:49 < gmaxwell> ossifrage: and the problem remained after restarting the node?
17:49 < ossifrage> gmaxwell, I haven't restarted the node
17:49 < gmaxwell> I wonder if this is a high uptime + txindex + only guy in that config who is watching the logs  problem?
17:50 < gmaxwell> it would be nice to better understand why leveldb is leaving the files open... but ... switching to poll eliminates all these problems.
17:50 < ossifrage> both txindex and chainstate are gobbling up file descriptors (let me count the maps)
17:51 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]
17:51 < BlueMatt> ossifrage: are you sure its using an fd, or just mmap, cause mmap *shouldnt* at least for ldb
17:51 < sipa> BlueMatt: i confirm that lsof shows both fd-ful opened files and mmapped ones 
17:52 < BlueMatt> that...sucks
17:52 < ossifrage> 685 maps of chainstate/*.ldb and 268 maps of txindex (odd)
17:52 < sipa> example of an fd one:
17:52 < sipa> bitcoind 11155   pw  mem       REG              252,1    2173885 783231 /home/pw/.bitcoin/chainstate/864555.ldb
17:52 < sipa> and another:
17:52 < sipa> bitcoind 11155   pw   40r      REG              252,1    2173957 779300 /home/pw/.bitcoin/chainstate/864998.ldb
17:52 < sipa> (sorry, swapped them; the first is mmap'ed, the other is with fd)
17:52 < ossifrage> the 40r is a fd map and the mem line is a mmapped one
17:52 < ossifrage> (fd open not fd map)
17:53 < BlueMatt> hmm, I wonder if ldb has tunables for that shit?
17:53 < sipa> though i only have 30 open files
17:53 < sipa> with fd
17:53 < ossifrage> There is a tunable to use 1024 fds, but is that per database?
17:53 < bitcoin-git> [bitcoin] MarcoFalke pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/0fb9c87815d1...e83d82a85c53
17:53 < bitcoin-git> bitcoin/master 9994d01 Jesse Cohen: Add Unit Test for SingleThreadedSchedulerClient...
17:53 < bitcoin-git> bitcoin/master b296b42 Jesse Cohen: Update documentation for SingleThreadedSchedulerClient() to specify the memory model
17:53 < bitcoin-git> bitcoin/master cbeaa91 Jesse Cohen: Update ValidationInterface() documentation to explicitly specify threading and memory model
17:53 < sipa> ossifrage: yes
17:53 < BlueMatt> MarcoFalke: wat
17:54 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #13247: Add tests to SingleThreadedSchedulerClient() and document the memory model (master...scheduler-tests) https://github.com/bitcoin/bitcoin/pull/13247
17:54 < BlueMatt> oh, it did get rewritten to be r-a, nvm
17:54 -!- grubles [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev
17:55 < BlueMatt> no, it wasnt
17:55 < BlueMatt> https://github.com/bitcoin/bitcoin/compare/0fb9c87815d1...e83d82a85c53#diff-ff632a82ae2fed5941a9dae2c725ad9bR113
17:55 < BlueMatt> MarcoFalke: plz2fix comment broken ^
17:55 < gmaxwell> sipa: also even if the issue didn't exist on x86_64 (though it seems it does), we'd still have it on 32 bit.
17:55 < sipa> how do i find the uptime of by bitcoind?
17:56 < gmaxwell> there is a starttime in node info or something?
17:56 < ken2812221> uptime?
17:56 < ossifrage> Oh, in my case it was bitcoin-qt not bitcoind
17:56 < ken2812221> rpc
17:56 < sipa> ah, i tried getnodeinfo and getuptime
17:56 < sipa> seems it's just 'uptime'
17:57 < sipa> 10 days, apparently
17:57 < ossifrage> 32 days, currently with ~160 connections (which seems to be the most I can get, and I think it has been shrinking as more fds are used)
17:58 < ossifrage> I was going to build a new version, is it useful to reduce the max fd open count for leveldb?
17:59 < sipa> it may impact performance
17:59 < sipa> gmaxwell: on 32-bit systems we limit the max open files to 64
18:01 < ossifrage> I've mmapped >10k pgm files on this box at one point, not sure why leveldb wouldn't just mmap all of the ldb files?
18:03 < gmaxwell> ossifrage: oh you've increased your max connections over default.
18:03 < gmaxwell> so that might be one reason you're seeing this and we are not getting other reports.
18:06 < ossifrage> gmaxwell, yeah I have a gbit connection, figured I might as well get the most out of the blood money I pay verizon
18:07 < ossifrage> But if leveldb where to use 1024 fds, there would be nothing left for sockets
18:07 < gmaxwell> interesting to me that you're actually ending up with that many peers.
18:07 < ossifrage> gmaxwell, it takes a while, but the connection count slowly increases over time
18:08 < ossifrage> Before I had a UPS on my ONT, I'd change IPs ever power failure and then it would take a long time before the connection count would go back up (with the new address)
18:09 < sipa> i have 148 connections
18:09 < gmaxwell> cool.
18:09 < gmaxwell> some months back, on my long running nodes I was unable to break 125. must be more inbound right now.
18:09 < ossifrage> The txindex has been useful a few (rare) times, but just turning that off would delay the problem
18:09 < gmaxwell> (well, or spies, mine blocked spies really agressively)
18:10 < ossifrage> that is ~160 connections (with your block list)
18:10 < gmaxwell> yea, though I haven't updated the blocklist for a while
18:10 < sipa> ossifrage: txindex on or off wouldn't affect the behaviour w.r.t the chainstate ldb files
18:10 < gmaxwell> (right now I hav no nodes with public inbound)
18:10 < gmaxwell> sipa: yes but he is also losing a bunch of fds to txindex.
18:10 < sipa> and your number for those is on itself pretty high
18:10 < ossifrage> sipa, yeah but it was the chainstate + txindex that pushed the fd count >1024
18:10 -!- michaelsdunn1 [~michaelsd@208.59.170.5] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
18:11 < gmaxwell> Poll is also good because its faster.
18:11 < ossifrage> I'd happily test a patch :-)
18:12 < sipa> do we require Vista or later?
18:12 < sipa> because windows introduced a poll equivalent in Vista
18:12 < achow101> yes, xp support was removed a few versions ago
18:12 < gmaxwell> I think we don't formally support older versions but they still work.
18:12 < gmaxwell> ?
18:13 < sipa> xp certainly doesn't work anymore
18:13 < gmaxwell> Also at least in theory we might work on some other platform that doesn't have poll.  We could try switching to only poll and see if someone complains.
18:13 < achow101> "Microsoft ended support for Windows XP on April 8th, 2014, No attempt is made to prevent installing or running the software on Windows XP, you can still do so at your own risk but be aware that there are known instabilities and issues. Please do not report issues about Windows XP to the issue tracker." <-- from 0.14 release notes
18:14 < ossifrage> I use XP to do my taxes, amazingly the tax software works on it
18:16 < gmaxwell> hm, I thought poll was faster than select, https://monkey.org/~provos/libevent/libevent-benchmark.jpg  then again, maybe I don't understand that graph, because how did they manage 25000 FDs with select?
18:17 < gmaxwell> sipa: in windows select doesn't have the 1024 fd limit thing
18:17 < gmaxwell> it's implemented as a linked list or something.
18:19 < luke-jr> array of fd numbers IIRC
18:19 < luke-jr> and it does have a limit
18:19 < luke-jr> just not for the fd numbers themselves
18:19 < luke-jr> defaults to 64
18:20 -!- nodweber [~nodweber@unaffiliated/nodweber] has joined #bitcoin-core-dev
18:21 < ossifrage> I thought on linux you could call select() with larger fdsets and it would work, but the libc fd_set is a fixed size?
18:21 < ossifrage> But it is not exactly efficient, especially with sparce sets
18:21 < luke-jr> you're supposed to be able to #define FD_SETSIZE before including stuff, to get more, but last I checked that was broken in glibc
18:22 < ossifrage> I've used epoll() for so long, using select() just makes me sad
18:22 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
18:25 < gmaxwell> ossifrage: indeed, but unfortunately BSDs and linux solved "life beyond poll" differently.
18:25 < ossifrage> gmaxwell, yeah that was never a concern for the stuff I was writing
18:26 < ossifrage> Sure it's portable, you can port it to any linux you like
18:26 < gmaxwell> we manage few enough connections that poll is fine anyways.
18:28 < phantomcircuit> gmaxwell, think you're looking at that graph wrong
18:28 < phantomcircuit> smaller is better
18:28 < phantomcircuit> or did you mean that poll() is the same as select() ?
18:30 < phantomcircuit> select and poll do basically the same thing just with a much better api for poll
18:30 < phantomcircuit> both pass the entire list to the kernel in every call
18:33 < ossifrage> epoll() was a big win for high connection count, low traffic
18:37 < Dave18> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
18:37 < Dave18> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
18:37 < Dave18> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
18:37 < Dave18> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
18:39 < ken2812221> spam again
18:42 < phantomcircuit> gmaxwell, epoll and kqueue are virtually identical
18:42 < phantomcircuit> it's really silly
18:46 -!- michaelsdunn1 [~michaelsd@208.59.170.5] has joined #bitcoin-core-dev
18:56 -!- mode/#bitcoin-core-dev [+o sipa] by ChanServ
18:56 -!- mode/#bitcoin-core-dev [+n] by sipa
18:56 -!- mode/#bitcoin-core-dev [-o sipa] by sipa
18:56 -!- nodweber [~nodweber@unaffiliated/nodweber] has quit [Ping timeout: 264 seconds]
18:57 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 260 seconds]
18:58 < midnightmagic> I think there's something even more different in NetBSD too..  kevent()?  kfilter_register()? I forget now.
18:58 < gmaxwell> phantomcircuit: yes, I was saying I thought poll was somewhat faster, but apparently not.
18:58 < gmaxwell> phantomcircuit: go PR that poll patch.
18:59 < midnightmagic> There are faster things than poll if you use whatever they provide natively.
19:00 < gmaxwell> yes, but faster is not generally our issue, max connections = 100,  or at most a few hundred.
19:02 < midnightmagic> (also no limitations a la select()'s irritating problems) -- and with a usage of the native event'ing things get very scaleable. But..  not like anyone but somoene like me is going to run a larger-scale system with NetBSD anyway.
19:02 -!- elkalamar [~elkalamar@unaffiliated/elkalamar] has quit [Ping timeout: 260 seconds]
19:04 < phantomcircuit> midnightmagic, the issue is that epoll and kqeueue and whatever windows uses are all platform specific
19:04 < phantomcircuit> there's some work being done to move to libevent but that's not done
19:04 < phantomcircuit> the poll() thing is pretty trivial iirc
19:04 < phantomcircuit> 80% solution for 10% the effort
19:05 < gmaxwell> phantomcircuit: open the PR!
19:05 < gmaxwell> I know you have had a patch.
19:06 < phantomcircuit> it's like 3 years old now but should be trivial to rewrite
19:08 < midnightmagic> using things like kevent natively isn't hard, it just needs to be clean and people on those platforms will look after it.
19:09 < gmaxwell> true but not obviously of any real value.
19:13 -!- nodweber [~nodweber@unaffiliated/nodweber] has joined #bitcoin-core-dev
19:13 < phantomcircuit> midnightmagic, under thousands of fds it doesn't much matter
19:15 < gmaxwell> phantomcircuit: PR PR PR
19:17 < phantomcircuit> gmaxwell, yeah yeah
19:17 -!- nodweber [~nodweber@unaffiliated/nodweber] has quit [Ping timeout: 240 seconds]
19:21 < phantomcircuit> gmaxwell, i remember
19:21 < phantomcircuit> windows is WSAPoll not poll
19:21 < phantomcircuit> and all the types are insane
19:21 < phantomcircuit> like it's virtually identical
19:21 < phantomcircuit> but not
19:30 < phantomcircuit> but i guess that codes already full of hacks for that anyways
19:34 -!- nodweber [~nodweber@unaffiliated/nodweber] has joined #bitcoin-core-dev
19:39 -!- nodweber [~nodweber@unaffiliated/nodweber] has quit [Ping timeout: 256 seconds]
19:55 -!- nodweber [~nodweber@unaffiliated/nodweber] has joined #bitcoin-core-dev
19:58 -!- michaelsdunn1 [~michaelsd@208.59.170.5] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
20:00 -!- nodweber [~nodweber@unaffiliated/nodweber] has quit [Ping timeout: 268 seconds]
20:03 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
20:12 < gmaxwell> phantomcircuit: windows can keep using select, it doesn't hae the same limit.
20:15 < sipa> yes, but its fdset implementation is a linked list with horrendous performance
20:15 < gmaxwell> so?  I mean, we only need it to support max-connections. and it already does. 
20:15 -!- nodweber [~nodweber@unaffiliated/nodweber] has joined #bitcoin-core-dev
20:16 < gmaxwell> or is it so bad that its noticably slow even for 125 connections?
20:16 < sipa> probably not
20:21 -!- nodweber [~nodweber@unaffiliated/nodweber] has quit [Ping timeout: 256 seconds]
20:21 < luke-jr> last time I checked, the only better alternative Windows had required significantly re-architecturing most programs to use it
20:21 < luke-jr> something along the lines of async IO, rather than write-ready notification/checking
20:36 -!- nodweber [~nodweber@unaffiliated/nodweber] has joined #bitcoin-core-dev
20:41 -!- nodweber [~nodweber@unaffiliated/nodweber] has quit [Ping timeout: 240 seconds]
20:57 -!- nodweber [~nodweber@unaffiliated/nodweber] has joined #bitcoin-core-dev
21:02 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:a48a:103:284a:a8b5] has quit [Ping timeout: 256 seconds]
21:02 -!- nodweber [~nodweber@unaffiliated/nodweber] has quit [Ping timeout: 256 seconds]
21:15 -!- ossifrage [~ossifrage@unaffiliated/ossifrage] has quit [Ping timeout: 260 seconds]
21:17 -!- booyah [~bb@193.25.1.157] has joined #bitcoin-core-dev
21:18 -!- nodweber [~nodweber@unaffiliated/nodweber] has joined #bitcoin-core-dev
21:22 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:a48a:103:284a:a8b5] has joined #bitcoin-core-dev
21:23 -!- nodweber [~nodweber@unaffiliated/nodweber] has quit [Ping timeout: 260 seconds]
21:25 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection]
21:26 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
21:27 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev
21:28 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:a48a:103:284a:a8b5] has quit []
21:31 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:54b9:59f3:47c8:efdf] has joined #bitcoin-core-dev
21:36 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:54b9:59f3:47c8:efdf] has quit []
21:39 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:49d8:e704:23d9:f525] has joined #bitcoin-core-dev
21:39 -!- nodweber [~nodweber@unaffiliated/nodweber] has joined #bitcoin-core-dev
21:44 -!- nodweber [~nodweber@unaffiliated/nodweber] has quit [Ping timeout: 240 seconds]
21:45 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:49d8:e704:23d9:f525] has quit []
21:47 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:c4a3:c9d0:9a8d:85bf] has joined #bitcoin-core-dev
22:00 -!- nodweber [~nodweber@unaffiliated/nodweber] has joined #bitcoin-core-dev
22:01 -!- grubles_ [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev
22:02 -!- grubles [~grubles@unaffiliated/grubles] has quit [Ping timeout: 264 seconds]
22:05 -!- nodweber [~nodweber@unaffiliated/nodweber] has quit [Ping timeout: 265 seconds]
22:11 -!- Amuza [~amuza@93.176.180.166] has joined #bitcoin-core-dev
22:14 -!- bsm117532 [~mcelrath@c-24-61-245-53.hsd1.ma.comcast.net] has quit [Ping timeout: 268 seconds]
22:19 -!- Amuza [~amuza@93.176.180.166] has quit [Ping timeout: 265 seconds]
22:21 -!- nodweber [~nodweber@unaffiliated/nodweber] has joined #bitcoin-core-dev
22:26 -!- nodweber [~nodweber@unaffiliated/nodweber] has quit [Ping timeout: 260 seconds]
22:35 -!- rex4539 [~rex4539@ppp-2-87-178-187.home.otenet.gr] has quit [Quit: Textual IRC Client: www.textualapp.com]
22:40 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
22:42 -!- nodweber [~nodweber@unaffiliated/nodweber] has joined #bitcoin-core-dev
22:45 -!- grubles_ [~grubles@unaffiliated/grubles] has quit [Ping timeout: 256 seconds]
22:46 -!- nodweber [~nodweber@unaffiliated/nodweber] has quit [Ping timeout: 240 seconds]
23:03 -!- nodweber [~nodweber@unaffiliated/nodweber] has joined #bitcoin-core-dev
23:08 -!- nodweber [~nodweber@unaffiliated/nodweber] has quit [Ping timeout: 264 seconds]
23:12 -!- Krellan [~Krellan@2601:640:4000:9258:3cf4:9188:ecd2:e19e] has joined #bitcoin-core-dev
23:23 -!- murrayn [~dafuq@unaffiliated/murrayn] has quit [Ping timeout: 256 seconds]
23:24 -!- nodweber [~nodweber@unaffiliated/nodweber] has joined #bitcoin-core-dev
23:29 -!- nodweber [~nodweber@unaffiliated/nodweber] has quit [Ping timeout: 256 seconds]
23:45 -!- nodweber [~nodweber@unaffiliated/nodweber] has joined #bitcoin-core-dev
23:49 -!- nodweber [~nodweber@unaffiliated/nodweber] has quit [Ping timeout: 248 seconds]
23:54 -!- ossifrage [~ossifrage@unaffiliated/ossifrage] has joined #bitcoin-core-dev
23:58 -!- jtimon [~quassel@213.28.134.37.dynamic.jazztel.es] has quit [Ping timeout: 264 seconds]
--- Log closed Wed Aug 01 00:00:27 2018