--- Day changed Tue Feb 13 2018
00:01 -!- jonasschnelli [~jonasschn@bitcoinsrv.jonasschnelli.ch] has quit [Changing host]     
00:01 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has joined #bitcoin-core-dev     
00:04 -!- murrayn [~dafuq@S01061cabc0b054b3.ok.shawcable.net] has joined #bitcoin-core-dev     
00:04 -!- murrayn [~dafuq@S01061cabc0b054b3.ok.shawcable.net] has quit [Changing host]     
00:04 -!- murrayn [~dafuq@unaffiliated/murrayn] has joined #bitcoin-core-dev     
00:05 -!- merehap [~sean@c-73-239-115-62.hsd1.wa.comcast.net] has quit [Ping timeout: 255 seconds]     
00:09 -!- merehap [~sean@c-73-239-115-62.hsd1.wa.comcast.net] has joined #bitcoin-core-dev     
00:25 -!- dongcarl [~dongcarl@c-24-5-70-69.hsd1.ca.comcast.net] has quit [Quit: leaving]     
00:29 -!- baldur [~baldur@pool-100-2-154-254.nycmny.btas.verizon.net] has quit [Ping timeout: 248 seconds]     
00:49 -!- n1bor [~n1bor@185.9.34.66] has quit [Read error: No route to host]     
00:50 -!- n1bor [~n1bor@185.9.34.66] has joined #bitcoin-core-dev     
01:00 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
01:18 -!- timothy [tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]     
01:24 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
01:32 < bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/c997f8808256...2dbc4a4740cd
01:32 < bitcoin-git> bitcoin/master cc046f6 John Newbery: [tests] Reduce NodeConn connection logging from info to debug
01:32 < bitcoin-git> bitcoin/master c32cf9f John Newbery: [tests] Add P2PDataStore class...
01:32 < bitcoin-git> bitcoin/master 359d067 John Newbery: [tests] Fix flake8 warnings in invalidtxrequest
01:32 < bitcoin-git> [bitcoin] laanwj closed pull request #11771:  [tests] Change invalidtxrequest to use BitcoinTestFramework (master...refactor_invalidtxrequest) https://github.com/bitcoin/bitcoin/pull/11771
01:59 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2dbc4a4740cd...f4f4f51f1a94
01:59 < bitcoin-git> bitcoin/master a71c56a Luke Dashjr: clientversion: Use full commit hash for commit-based version descriptions...
01:59 < bitcoin-git> bitcoin/master f4f4f51 Wladimir J. van der Laan: Merge #11966: clientversion: Use full commit hash for commit-based version descriptions...
02:00 < bitcoin-git> [bitcoin] laanwj closed pull request #11966: clientversion: Use full commit hash for commit-based version descriptions (master...ver_full_commit_hash) https://github.com/bitcoin/bitcoin/pull/11966
02:02 -!- timothy [tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]     
02:17 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
02:28 -!- dabura667_ [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection]     
02:37 -!- Scrat [~herp@unaffiliated/scrat] has joined #bitcoin-core-dev     
02:37 -!- baldur [~baldur@pool-100-2-154-254.nycmny.btas.verizon.net] has joined #bitcoin-core-dev     
02:39 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
02:40 < wumpus> hmmm
02:40 < wumpus> util.cpp:384:121: note: in instantiation of template class 'std::__1::pair<const std::__1::basic_string<char>, boost::interprocess::file_lock>' requested here
02:40 < wumpus>         boost::interprocess::file_lock& lock = locks.emplace(pathLockFile.string(), pathLockFile.string().c_str()).first->second;
02:41 < wumpus> full error here: https://github.com/bitcoin/bitcoin/issues/12413
02:41 < wumpus> anyone have an idea what can cause this c++ error monstriosity?
02:46 -!- larafale [~larafale@ax213-1-82-66-157-194.fbx.proxad.net] has joined #bitcoin-core-dev     
02:53 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
02:54 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
03:03 < wumpus> so it looks like "static std::map<std::string, boost::interprocess::file_lock> locks;" is illegal with openbsd's clang + boost version combo
03:03 < bitcoin-git> [bitcoin] Sjors opened pull request #12421: [qt] navigate to  transaction history page after send (master...2018/02/qt-goto-transactions-after-send) https://github.com/bitcoin/bitcoin/pull/12421
03:04 < Lauda> Will there be rc4?
03:05 -!- epic [sid37137@gateway/web/irccloud.com/x-hyzczrwbabuyzctz] has quit []     
03:05 -!- epic [sid37137@gateway/web/irccloud.com/x-sgubypzjiplwyclm] has joined #bitcoin-core-dev     
03:08 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev     
03:11 < provoostenator> Lauda: there's two open PR's which I suspect need to be fixed before rc4: https://github.com/bitcoin/bitcoin/milestone/30
03:12 < Lauda> Alright, thanks. I'll wait for those.
03:17 < bitcoin-git> [bitcoin] laanwj opened pull request #12422: util: Use unique_ptr in locks map (master...2018_01_openbsd_util_fix) https://github.com/bitcoin/bitcoin/pull/12422
03:18 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
03:24 < gmaxwell> wumpus: can you explain why it works inside a unique ptr? (I am just curious)
03:26 < wumpus> gmaxwell: no, I have no idea why it fails in the first place
03:26 < wumpus> tbh this is really over my limit of understanding C++
03:27 < wumpus> well, the point of having pointers in a map instead of whole objects makes it 'simpler' to work with layout in memory I suppose
03:28 < wumpus> as for some reason the whole lock objects can't be moved
03:28 < wumpus> and pointers, obviously, can
03:28 < gmaxwell> yea, I was wondering if values in maps had to be relocatable, but quick googling didn't answer the question for me.
03:29 < wumpus> it must be some edge case that was solved in either a newer version of clang, or in a different version of boost, as I've not seen the issue on other platforms
03:30 < wumpus> the 'map' here is used to avoid locking a directory multiple times I guess? this structure is write-only, no lookups are ever done in this map, so there should be no performance difference whatsoever
03:31 < wumpus> gah     
03:31 < goatpig> from the look of the error log
03:31 < goatpig> this has to do with the ctor
03:31 < goatpig> not the map itself
03:31 < wumpus> so emplace returns the current record if one already exists, right?
03:31 -!- hsmiths [uid95325@gateway/web/irccloud.com/x-ypcjvvqcpdfzyqtu] has quit []     
03:32 -!- hsmiths [uid95325@gateway/web/irccloud.com/x-khcqgezqeozrdktu] has joined #bitcoin-core-dev     
03:32 < wumpus> I dont' think this construction even accomplishes what it is meant to accomplish
03:32 < goatpig> emplace is like insert afaik, returns a pair of <iter, bool>
03:33 < goatpig> the iterator points at the inserted element or the already existing one, the bool tells you if it was added (true) or fetched (false)
03:34 < wumpus> ok that depends on what does lock->try_lock does on a lock that is already locked
03:34 < goatpig> you mean within the same thread?
03:34 < goatpig> or another one?
03:34 < wumpus> within the same process
03:34 < goatpig> i think it throws
03:34 < goatpig> not sure
03:34 < wumpus> this is a per-process lock, not per-thread
03:35 -!- timothy [tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]     
03:35 < wumpus> I wonder what the intent is for LockDirectory being called on the same directory multiple times
03:35 < goatpig> but that wouldnt have anything to do compile, that would just be runtime error
03:35 < wumpus> I know.
03:35 < wumpus> I'm just doubting that this code does what it is meant to do, at all
03:35 < goatpig> typically that's to make sure you got the lock
03:35 < wumpus> separate from what it takes to compile it
03:36 < goatpig> now if the same threads is trying to get a lock multiple times
03:36 < goatpig> it presupposes the methods that are accessed can be used on their own
03:36 < wumpus> it should probably at least check the boolean it gets back from emplace
03:36 < wumpus> whether the lock already exists
03:36 < wumpus> otherwise it will lock an old lock another time
03:36 < goatpig> that part is like
03:36 < goatpig> idk id have to look at the code
03:37 < goatpig> but it seems pointless
03:37 < goatpig> why hold a reference to the lock in the scope? that's usless, the map perpetuates it
03:37 < wumpus> either that's a no-op, or it throws, but it's pointless
03:37 < goatpig> and that could be your compile issue
03:37 < goatpig> that these locks are not copiable
03:37 < goatpig> ie just get rid of the referencing altgother
03:37 < wumpus> defining the map itself causes the compile issue
03:37 < wumpus> referencing is not the problem
03:37 < goatpig> boost::interprocess::file_lock& lock = locks.emplace(pathLockFile.string(), pathLockFile.string().c_str()).first->second;
03:38 < goatpig> get rid of the reference and try
03:38 < gmaxwell> in general I wouldn't expect a lock to be copyable.
03:38 < goatpig> if that doesnt bork other stuff
03:38 < wumpus> goatpig: I tried, see discussion in https://github.com/bitcoin/bitcoin/issues/12413
03:38 < goatpig> i.e. just do locks.emplace(pathLockFile.string(), pathLockFile.string().c_str());
03:38 < gmaxwell> what the heck is this doing?
03:38 < gmaxwell> anyways?
03:38 < wumpus> goatpig: as I said above, defining the map itself already causes the error, even if you don't access it at all!
03:39 < wumpus> gmaxwell: that was also my question, what is the semantics supposed to be
03:39 < goatpig> you could just ninja that my making it a map of shared_ptr<lock>
03:39 < goatpig> by*     
03:39 < gmaxwell> maybe we can remove it all entirely? thats always the best fix when possible. :P
03:39 < wumpus> goatpig: that's what I did in #12322 (but with unique_lock)
03:39 < gribble> https://github.com/bitcoin/bitcoin/issues/12322 | Docs: Remove step making cloned repository world-writable for Windows build. by murrayn · Pull Request #12322 · bitcoin/bitcoin · GitHub
03:40 < wumpus> eh #12422
03:40 < gribble> https://github.com/bitcoin/bitcoin/issues/12422 | util: Use unique_ptr in locks map (fix OpenBSD 6.2 build) by laanwj · Pull Request #12422 · bitcoin/bitcoin · GitHub
03:40 -!- jl2012 [sid133844@gateway/web/irccloud.com/x-abyxswqabcudhbfl] has quit []     
03:40  * gmaxwell channels some contributor and considers just submitting a PR to remove stuff he doesn't understand
03:40 -!- jl2012 [sid133844@gateway/web/irccloud.com/x-piwrikbqogxrkygm] has joined #bitcoin-core-dev     
03:40 < goatpig> wumpus: sure, dunno what the code really intents. i'd prefer unique_ptr when possible
03:40 < goatpig> but if it's trying to reference the lock, then it should be using shared_ptrs
03:41 < wumpus> no, shared_ptre is not necessary
03:41 -!- wacawacawaca [~user@wsip-66-210-9-178.dc.dc.cox.net] has quit [Quit: Leaving]     
03:41 < wumpus> the lock does not leave the scope at all
03:41 < goatpig> the lock exists within the map
03:41 < wumpus> yes     
03:41 < wumpus> and after the change, it exists inside a unique pointer
03:41 < goatpig> if you kill the map, if there is a thread with the ptr/reference, it will blow up
03:41 < wumpus> which is unique, inside the map
03:42 < wumpus> no one has a reference to it
03:42 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
03:42 < wumpus> please read the code
03:42 < wumpus> no reference leaves the function
03:43 < goatpig> checking
03:43 < wumpus> the destructor will be called when the process has shut down, after the main function, by automatic cleanup
03:43 < wumpus> by that time no one will be using the data dir anymore
03:43 < wumpus> the map exists to hold on to the objects until the process shuts down
03:45 < goatpig> so the locks persist the process?
03:46 < goatpig> or rather
03:46 < goatpig> no method tries to clean them up
03:46 < wumpus> as I said, they'll be automatically cleaned up by the runtime framework
03:47 < wumpus> <gmaxwell> in general I wouldn't expect a lock to be copyable. <- they are; it's only moving them at most, not copying
03:50 < goatpig> wumpus: is it assumed that code gets accessed by only a single thread?
03:50 < gmaxwell> goatpig: this isn't an ordinary lock
03:50 < gmaxwell> it's a file locking thing
03:50 < wumpus> goatpig: yes, it's only used during initialization, by the init thread
03:50 < gmaxwell> used to keep seperate processes from muckign about with the same data directories.
03:50 < wumpus> goatpig: oh... I'm actually not sure anymore
03:50 < goatpig> i understand that much, but it's not thread safe, so im assuming this is every hit once
03:51 < goatpig> err     
03:51 -!- dgy_ [~dgy@202.125-240-81.adsl-dyn.isp.belgacom.be] has quit [Quit: Leaving]     
03:51 < wumpus> wallet directories complicated this
03:51 < goatpig> hit ever once
03:51 < goatpig> i mean the semantics of the method suggest this is accessed just to check the lock is held at all
03:51 < wumpus> as soon as dynamic opening of wallets is supported, this can be called from the RPC thread
03:51 < wumpus> but right now it's only used from init
03:52 < wumpus> it's a good question, the function as it is is certainly not thread safe
03:52 < goatpig> you are adding elements to a map. ideally it should check the map has the element, otherwise grab a mutex, add the element, then go back to regular execution
03:52 -!- timothy [tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]     
03:53 < wumpus> it should grab a mutex before accessing the map at all
03:53 < gmaxwell> ^     
03:53 < wumpus> *if* it's supposed to be thread safe
03:53 < goatpig> ok, sure
03:53 < gmaxwell> and its trivial here in any case.. since the purpose of the map is just lifetime management for the contained objects.
03:53 < wumpus> yes     
03:54 < goatpig> that would be if the method was not meant to return state of the lock
03:54 < goatpig> the semantics just suggest to me that it could be accessed by another thread
03:54 < wumpus> I think the intent is to return true if the process has a lock on the directory, whether it's new or not. Not sure the code matches that intent, at the moment.
03:54 < gmaxwell> nah its just init only now. though wumpus is right that dynamic wallet opening/closing will cause accesses from rpc.
03:55 < wumpus> I've asked meshcollider (who wrote the code) in the issue just in case
03:55 < gmaxwell> for wallet opening we probably want it to return true if it takes a lock and false if it already has it or can't take it.
03:56 < meshcollider> wumpus: I think ryanofsky suggested the currently used approach as a comment on the PR
03:56 < wumpus> gmaxwell:  it's a lock on a directory, not on the wallet, bdb takes care of not opening the same wallet multiple times
03:56 < wumpus> gmaxwell: there can be multiple wallets in a directory
03:57 < gmaxwell> wumpus: ah point.
03:57 < gmaxwell> Carry on then.
03:59 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
04:06 < wumpus> we could certainly use unit tests for that function
04:08 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 248 seconds]     
04:08 -!- rodarmor [sid210835@gateway/web/irccloud.com/x-rcgcavgpmfcwnrgt] has quit []     
04:09 -!- rodarmor [sid210835@gateway/web/irccloud.com/x-tghtfpupftxepgpz] has joined #bitcoin-core-dev     
04:10 < wumpus> meshcollider: ok adding jnewbery to reviewers
04:12 < meshcollider> jnewbery or ryanofsky?
04:13 < meshcollider> wumpus: your PR looks good to me
04:13 < wumpus> eh, sorry, yes ryanofsky, added the wrong one
04:13 -!- jamesob [~jamesob@172.56.35.18] has joined #bitcoin-core-dev     
04:15 < meshcollider> wumpus: didn't even think about the dynamic loading/unloading case / thread safety when I wrote it, apologies
04:15 < meshcollider> Was just trying to fix the issue for 0.16
04:15 < wumpus> meshcollider: no worries, we found that issue before it became a problem at least
04:21 -!- cryptojanitor [uid278088@gateway/web/irccloud.com/x-vnnpjmvdcgnakiak] has joined #bitcoin-core-dev     
04:32  * wumpus working on a unit test for LockDataDirectory - part of it will only work on UNIX because fork()
04:46 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
04:50 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]     
05:05 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
05:11 < provoostenator> You have got to be kidding... anyone had to jump through these hoops before? http://htmlpreview.github.io/?https://github.com/JKSH/QtSdkRepoChooser/blob/master/doc/index.html
05:14 -!- Pavle [~pavle_@unaffiliated/pavle/x-4679000] has joined #bitcoin-core-dev     
05:15 < wumpus> no, not really, though I've had to build qt for embedded devices, the source code is huge, it takes a long time and it's a pain to configure for cross compile
05:15 < wumpus> it pretty much regards itself as an operating system in itself
05:19 -!- lnostdal [~lnostdal@gateway/tor-sasl/lnostdal] has joined #bitcoin-core-dev     
05:21 -!- Pavle [~pavle_@unaffiliated/pavle/x-4679000] has quit [Quit: Leaving]     
05:22 < wumpus> we can be really happy that linux distributions simply package that stuff pre-built
05:28 -!- jtimon [~quassel@41.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds]     
05:34 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
05:56 -!- jamesob [~jamesob@172.56.35.18] has quit [Ping timeout: 276 seconds]     
05:58 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev     
06:09 -!- jamesob [~jamesob@172.56.35.18] has joined #bitcoin-core-dev     
06:18 < midnightmagic> /w/w 59
06:18 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Remote host closed the connection]     
06:19 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev     
06:20 < cfields> wumpus: seems it's moot now, but I think std::piecewise_construct might be what's missing for the emplace
06:20 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
06:22 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 248 seconds]     
06:23 < cfields> as usual, spoke too soon. Red herring. Nevermind.
06:25 < wumpus> I'll look at that one, never heard of it
06:26 < cfields> wumpus: see for example: https://github.com/bitcoin/bitcoin/blob/master/src/net_processing.cpp#L574
06:27 -!- timothy [tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]     
06:31 -!- rex_4539 [~textual@2a02:587:3508:900:3194:7b7:5c1c:b0f9] has joined #bitcoin-core-dev     
06:36 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
06:37 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
06:38 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
06:39 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
06:40 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
06:42 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-wifyelvjempnbhnw] has quit [Quit: Connection closed for inactivity]     
06:49 -!- jamesob [~jamesob@172.56.35.18] has quit [Ping timeout: 260 seconds]     
06:50 -!- ken2812221 [~User@133-203.dorm.ncu.edu.tw] has quit [Read error: Connection reset by peer]     
06:50 -!- ken2812221 [~User@133-203.dorm.ncu.edu.tw] has joined #bitcoin-core-dev     
06:50 -!- ossifrage [~ossifrage@unaffiliated/ossifrage] has quit [Remote host closed the connection]     
06:51 -!- ossifrage [~ossifrage@unaffiliated/ossifrage] has joined #bitcoin-core-dev     
06:56 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Remote host closed the connection]     
06:56 -!- mmgen [~mmgen@gateway/tor-sasl/mmgen] has quit [Read error: Connection reset by peer]     
06:56 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Write error: Connection reset by peer]     
06:56 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev     
06:57 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev     
06:57 -!- mmgen [~mmgen@gateway/tor-sasl/mmgen] has joined #bitcoin-core-dev     
06:58 -!- rex_4539 [~textual@2a02:587:3508:900:3194:7b7:5c1c:b0f9] has quit [Quit: Textual IRC Client: www.textualapp.com]     
07:01 -!- rex_4539 [~textual@2a02:587:3508:900:34fe:e738:2b1c:67bb] has joined #bitcoin-core-dev     
07:02 < hkjn0> a bit lazy q: am I reading depends/ docs right that there's currently no way to use other platforms than x86_64 to build e.g. bdb?
07:02 -!- alfa [uid11513@gateway/web/irccloud.com/x-ulzhkfmrkyxljwva] has joined #bitcoin-core-dev     
07:03 < hkjn0> so if I'm compiling code on armv7l and want wallet support, best thing to do is to get on x86_64 instead, and crosscompile towards arm as necessary?
07:03 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]     
07:03 < hkjn0> (I did get bdb4.8 compiled from source on armv7l outside of the depends system, but had trouble getting it to be noticed by the build system..)
07:04 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev     
07:06 < wumpus> hkjn0: the depends system assumes it's building on x86_64, however if you want to build db4 outside the depends system there's the script  contrib/install_db4.sh and the flags  BDB_LIBS="-L${BDB_PREFIX}/lib -ldb_cxx-4.8" BDB_CFLAGS="-I${BDB_PREFIX}/include"
07:07 < wumpus> would be nice if the depends system also supported building *from* other architectures, though
07:10 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has joined #bitcoin-core-dev     
07:10 < hkjn0> ah, great, I bet I was just misisng BDB_LIBS or somesuch.. will try out the contrib/ script
07:10 < wumpus> esp. at some point we'd like to do gitian builds from other architectures
07:11 < hkjn0> right. I've been setting up these weird build environments already, would be happy to try to contribute to gitian work or otherwise support other build platforms, just need to understand more of how current system hangs together first.. :)
07:18 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 256 seconds]     
07:44 -!- jamesob [~jamesob@172.56.35.118] has joined #bitcoin-core-dev     
07:46 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 255 seconds]     
07:49 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Remote host closed the connection]     
07:51 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev     
07:51 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
07:55 -!- grafcaps [~haroldbr@50.90.83.229] has quit [Ping timeout: 265 seconds]     
08:05 -!- jamesob [~jamesob@172.56.35.118] has quit [Ping timeout: 248 seconds]     
08:07 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 255 seconds]     
08:10 -!- lnostdal [~lnostdal@gateway/tor-sasl/lnostdal] has quit [Ping timeout: 255 seconds]     
08:11 -!- grafcaps [~haroldbr@104.137.194.255] has joined #bitcoin-core-dev     
08:22 < cfields> depends doesn't assume build is x86_64. It's the only arch that really gets tested, though
08:23 < cfields> but, all of the machinery is there to auto-detect the build platform and try to cope.
08:24 < cfields> hkjn0: if you try building native on arm and run into issues, feel free to ping me
08:27 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
08:28 < hkjn0> cfield, thanks! building with contrib/install_db4.sh + BDB_LIBS it suggested for ./configure as wumpus suggested seems to work fine so far
08:29 < hkjn0> (before that I tried a plain `make` in depends/ and it failed on armv7l, but it is possible I am missing some packages)
08:34 < cfields> hkjn0: well if you'd be willing, I'd be happy to step through the depends with you and try to get it patched to build
08:35 < cfields> like wumpus said, it'd be nice to have several working build arches
08:44 < hkjn0> cfields: sure, let me know how you'd like to proceed.. do we take it off the main channel to not clutter it up too much?
08:45 < cfields> hkjn0: sure, #bitcoin-build
08:52 -!- Randolf [~randolf@96.53.47.42] has quit [Ping timeout: 264 seconds]     
08:54 < michagogo> wumpus/cfields: Do you remember (on a describe-in-a-couple-sentences-off-the-top-of-your-head level) what the actual issue is with Xenial and why it's broken?
08:55 < michagogo> And does Artful(/Bionic) just work?
08:55 < michagogo> (with cross-compilation for Windows, I mean)
08:56 < michagogo> I tried looking through the issues on GitHub and got confused by the various different threads and things people tried and experienced
08:56 < cfields> michagogo: by default, the toolchain is configured for win threads rather than posix, which don't exist (at least with that gcc version)
08:56 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
08:56 < cfields> further, the ssp is busted
08:57 < michagogo> And were those fixed in later versions, e.g. Artful?
08:58 < cfields> I believe so. But we should be switching to our own toolchains for 0.17 anyway. Or if not a full switch, probably at least for mingw.
08:59 < michagogo> That sounds like it would be a good thing
09:00 < michagogo> I ask because last night and today I spent a bunch of hours trying to see how hard it would be to just backport the version of mingw-w64 that's in artful/bionic to xenial
09:01 < michagogo> I tried the straightforward "`backportpackage` into a PPA", but ran into chains of missing dependencies
09:02 < michagogo> I won't bore you with everything I tried and looked at, but at this point I've come to the realization that I don't know enough about Ubuntu packaging and how all that works, and beyond that, more important stuff
09:02 < cfields> michagogo: I can upload a stand-alone mingw toolchain soon, if it would help
09:02 < michagogo> Like, what is mingw-w64, vs what is gcc, vs what is gcc-mingw-w64
09:02 < cfields> heh     
09:02 < michagogo> and how do all those interact
09:02 < cfields> right
09:02 < cfields> well, in case it helps...
09:03 < michagogo> In #ubuntu-devel someone said: 18:34:22 <rbasak> michagogo: I would step back and consider your approach. I don't know what problem you're solving, but there might be an easier way.
09:04 < michagogo> I explained that the version in xenial was broken, and they said this: 18:39:39 <rbasak> Also, if the reason it doesn't work in Xenial is due to a bug, we're quite happy in general to cherry-pick the fix for all Xenial users to benefit.
09:04 < michagogo> But somehow I suspect if it were that simple it would have already happened...
09:04 < cfields> to build a mingw-w64 toolchain, you need: mingw-w64 headers (think kernel headers), mingw-64 runtime (think glibc), gcc, and binutils. And obviously they need to be built in a way that lets them play nicely.
09:05 < michagogo> Right. So the thing is, I don't actually know the difference between mingw-w64 and gcc
09:05 < michagogo> Well, that's not entirely true
09:05 < michagogo> I sort of know what gcc is
09:05 < michagogo> What I don't know is, what is mingw-w64, and how does it interact with/based on/use gcc
09:06 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev     
09:07 < cfields> mingw-w64 is a shim that allows for posix-y code to work on windows.
09:08 < michagogo> So what is gcc-mingw-w64?
09:09 < cfields> so you can build a compiler (gcc) that's able to produce win32 code, but it wouldn't do much good if you couldn't use standard unixy apis.
09:10 < cfields> so, for example, mingw-w64 can use either win or pthread threading models. Configured without pthread support, you'll have trouble with lots of applications. That's one of our issues.
09:13 < michagogo> So gcc-mingw-64, say, is a version of GCC that builds the mingw-w64 layer into the binaries it produces?
09:13 < cfields> it's probably easiest to just think of mingw-w64 as a libc for windows.
09:14 < michagogo> I guess at this point the knowledge that I'm missing is: 1) what _exactly_ the term "toolchain" refers to and how you build one
09:14 < michagogo> 2) How Ubuntu packages work together to make up a toolchain
09:15 < michagogo> And all kinds of other things related to those, like how exactly Ubuntu packaging works
09:15 < cfields> well, the packaging is an entirely different beast
09:16 < michagogo> I'm thinking I'll drop the issue for now, since I don't really have a ton of time and I suspect it would take me at least a few days to sort all these things out
09:16 < michagogo> I mean, regarding what rbasak said over in #ubuntu-devel, are the problems we have simple bugs with focused fixes that can be cherry-picked, or more fundamental problems that can't really be fixed without a wholesale upgrade to a newer version of MinGW? 
09:17 < cfields> a toolchain is the group of progs that are required to produce a working binary. Typically that's target kernel/os headers in some form, target libc, host compiler, other host apps (in linux, binutils provides ar/ranlib/etc.), and a linker (also provided by binutils on linux)
09:17 < jcorgan> michagogo: it's been a little while since i've used gcc-mingw-w64 but i recall in ubuntu that installing that package pulls in all the accessories (runtime, binutils, etc.) that cfields mentioned
09:17 < michagogo> And actually, is the issue just with the MinGW component? Meaning, say one were to rebuild the gcc-mingw-w64 packages with the same GCC version and just an upgraded MinGW, would that work?
09:19 < jcorgan> in late to the conversation here, so not sure you're exact goal
09:19 < cfields> michagogo: the thread thing is just a config option. There's also the stack issue, which I haven't looked into for a while, but afaik that's no longer an issue in newer ubuntu versions. So it was either an upstream bug that's been fixed, or a config problem that ubuntu has fixed
09:19 < michagogo> jcorgan: Well, at the end of the day, here's my big-picture goal
09:20 < michagogo> Make https://github.com/bitcoin/bitcoin/blob/master/doc/build-windows.md#building-for-64-bit-windows die in a fire
09:20 < michagogo> Specifically, the lines telling you to sudo add-apt-repository "deb http://archive.ubuntu.com/ubuntu zesty universe"; sudo apt update;sudo apt upgrade
09:20 < michagogo> Because besides that not working, because zesty is EOL, that's just going to hose your system
09:21 < jcorgan> ah, i only have experience going from LTS to LTS, never use the ones in between
09:21 < michagogo> Even doing that, you never ever just add the newer repository like that
09:21 < michagogo> There's an upgrader
09:22 < michagogo> So my thought was, well, can I get the packages from the newer version brought back to xenial?
09:23 < jcorgan> it might be possible, but that way lies madness
09:23 < michagogo> So it seems.
09:23 < michagogo> I tried just naively `backportpackage`ing into a PPA
09:24 < jcorgan> you're on zesty and need packages that only exist later than that?
09:24 < cfields> michagogo: yea, I'm not sure it's worth the trouble. We already have a plan for resolving this, and it means that we don't have to rely on Ubuntu anymore
09:24 < michagogo> I’m not on zesty
09:25 < michagogo> I’m actually not an active Ubuntu (or Linux) user day to day
09:25 < jcorgan> you could see if the packages you need are in the 'backports' repo
09:25 < michagogo> Nah     
09:25 < michagogo> My idea was to *get* a newer mingw-w64 into -backports
09:26 < michagogo> I filed the “please backport” bugs
09:26 < cfields> michagogo: well, that certainly wouldn't be a bad thing. It's definitely not just us.
09:26 < jcorgan> i expect that would require specialized knowledge of how gcc/binutils/etc are packaged that a typical user wouldn't normally need to know
09:27 < jcorgan> and personally i'd look for an alternative way to solve whatever problem
09:27 < michagogo> I had the naive thought that, well, it should be easy to backport, because it’s a cross-compiler, not anything that the system uses
09:28 < michagogo> jcorgan: AIUI “whatever problem” is “mingw-w64 on Xenial is very broken”
09:30 -!- Pavle [~pavle_@unaffiliated/pavle/x-4679000] has joined #bitcoin-core-dev     
09:31 < jcorgan> personally i'd see if the must-be-xenial constraint can be relaxed. but if you wanted a challenge you could learn enough about how it works to help fix the issue. that may not be worth your time, but it could also be fun and very educational. 
09:31 < jcorgan> (depends on you)
09:31 -!- mrannanay [uid222022@gateway/web/irccloud.com/x-oljlqkjnmvfimlnt] has joined #bitcoin-core-dev     
09:31 < michagogo> A no-changes backport failed, firstly, because it build-depends on gcc-7
09:32 < michagogo> Which must-be-Xenial constraint?
09:32 < michagogo> The thing is, 1) that’s the latest LTS
09:32 < jcorgan> right, i use that extensively
09:32 < michagogo> And 2) that’s the version that you get with WSL, and as far as I know trying to upgrade just breaks it
09:33 < jcorgan> ah, another piece of the picture i was unaware of
09:34 < michagogo> So the “constraint” is that we really want to let users on Xenial cross-compile is
09:34 < jcorgan> you're in a maze of twisty passages, all alike
09:34 < michagogo> cross-compile us*
09:36 < michagogo> I mean, it’s possible that if I knew Ubuntu packaging and had enough time I could try just reverting the changes that made it build with gcc 7
09:36 < jcorgan> so, getting a backport made of mingw does seem like the right way to go, but the number of people who are likely to know how to do that is probably small
09:36 < michagogo> And bring it back to 5.whatever
09:36 < michagogo> For all I know it might be just changing the build-depends line back to point at the gcc version that’s in Xenial
09:37 < jcorgan> sure
09:38 < jcorgan> but there could also be some specific bug in gcc5 that caused gcc7 to be needed.
09:38 < michagogo> I doubt it
09:38 < michagogo> I mean, I shouldn’t t say that
09:38 < jcorgan> that does sound like a (relatively) easy first thing to try, and you might get lucky
09:39 < michagogo> But I’m pretty sure that the upgrade to gcc 6 in... yakkety or zesty, I think? And to 7 in bionic, was just part of a wholesale upgrade to those versions
09:39 < jcorgan> i'm going to be in pain when i start looking at migrating everything to 18.04, aren't I?
09:40 < michagogo> But besides not knowing even the basics of Ubuntu packaging, I’d need the ability to go over all the other changes to the gcc-mingw-w64 source package and figure out which ones are related to the gcc 5/7 stuff, vs which ones should be there anyway
09:40 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
09:40 < bitcoin-git> [bitcoin] ryanofsky opened pull request #12424: Fix rescan test failure due to unset g_address_type, g_change_type (master...pr/scang) https://github.com/bitcoin/bitcoin/pull/12424
09:41 < michagogo> jcorgan: define “everything”
09:41 < jcorgan> most of the systems i use/support are 16.04, some still 14.04
09:41 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
09:41 < jcorgan> it sounds like a lot of changes are coming in 18.04
09:41 < michagogo> No idea
09:42 < jcorgan> anyway, this is straying a bit from coredev
09:42 < michagogo> I mean, it’s 2 years of progress in the overall Linux ecosystem
09:42 < michagogo> Bringing everything up to date
09:42 < michagogo> So yeah, some things may break…
09:42 < jcorgan> well, the older LTS versions get new packages for everything that isn't a fundamental system change
09:43 < jcorgan> and the backports repo even lets you run newer kernels and video drivers
09:44 < jcorgan> it's usually the lower-level stuff like sysvinit/upstart/systemd that causes me pain
09:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
09:47 < michagogo> Get new packages? What do you mean?
09:48 < michagogo> My understanding is that -updates only has bug fixes, ~never new wholesale versions of software that have features
09:48 -!- farmerwampum [~farmerwam@173.244.200.116] has quit [Ping timeout: 248 seconds]     
09:49 < jcorgan> maybe i'm thinking of PPAs, where authors make recent versions of their software for several different ubuntu releases
09:49 < michagogo> Yep     
09:50 < michagogo> With a PPA you can give people who decide to use you whatever you want, whenever you want
09:50 < michagogo> (Including installing a backdoor on their systems. It’s important that you trust the owners of PPAs you use.)
09:51 < jcorgan> well, i hope you figure out how to get teh mingw/WSL stuff working
09:51 -!- Pavle [~pavle_@unaffiliated/pavle/x-4679000] has quit [Ping timeout: 240 seconds]     
09:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
09:51 < michagogo> Yeah, I think I'm just going to drop the issue at this point
09:52 < michagogo> cfields said that we're going to be using our own toolchain at some point (soon? ish?)
09:52 -!- alfa [uid11513@gateway/web/irccloud.com/x-ulzhkfmrkyxljwva] has quit [Quit: Connection closed for inactivity]     
09:52 < cfields> michagogo: yes. Ubuntu versions/packages won't matter for gitian/travis after that.
09:53 < michagogo> cfields: I'm thinking mostly about the case of someone wanting to cross-build binaries for themselves
09:53 < michagogo> Either just not wanting to go through the hassle of setting up gitian, or with something like WSL
09:54 < michagogo> I really don't like the fact that we're giving users broken instructions, especially ones that (were they to work) have them completely mess up their system
09:54 < cfields> michagogo: sure. None of the new stuff will be required, ofc.
09:54 < michagogo> (https://github.com/bitcoin/bitcoin/blob/master/doc/build-windows.md#building-for-64-bit-windows)
09:54 -!- ProfMac [~ProfMac@2001:470:b8ac:0:e5b9:1189:600:a4fd] has quit [Ping timeout: 240 seconds]     
09:55 < michagogo> And of course, there's the fact that mingw is broken for everyone else
09:56 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds]     
09:56 -!- S3RVO [cf94b64a@gateway/web/freenode/ip.207.148.182.74] has joined #bitcoin-core-dev     
10:04 -!- timothy [tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]     
10:04 -!- harrymm [~harrymm@104.207.83.58] has quit [Ping timeout: 256 seconds]     
10:05 -!- Randolf [~randolf@96.53.47.42] has joined #bitcoin-core-dev     
10:07 -!- PaulCapestany [~PaulCapes@ip72-209-228-50.dc.dc.cox.net] has quit [Quit: .]     
10:10 -!- PaulCapestany [~PaulCapes@ip72-209-228-50.dc.dc.cox.net] has joined #bitcoin-core-dev     
10:18 -!- harrymm [~harrymm@104.207.83.30] has joined #bitcoin-core-dev     
10:21 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds]     
10:25 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
10:26 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
10:27 -!- ProfMac [~ProfMac@2001:470:b8ac:0:65d7:5d8:cbec:b9d3] has joined #bitcoin-core-dev     
10:28 -!- sengehest [~sengehest@188.81-166-37.customer.lyse.net] has joined #bitcoin-core-dev     
10:29 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
10:29 -!- S3RVO [cf94b64a@gateway/web/freenode/ip.207.148.182.74] has quit [Quit: Page closed]     
10:32 -!- ProfMac [~ProfMac@2001:470:b8ac:0:65d7:5d8:cbec:b9d3] has quit [Ping timeout: 265 seconds]     
10:33 -!- PaulCape_ [~PaulCapes@ip72-209-228-50.dc.dc.cox.net] has joined #bitcoin-core-dev     
10:34 -!- PaulCapestany [~PaulCapes@ip72-209-228-50.dc.dc.cox.net] has quit [Ping timeout: 256 seconds]     
10:35 -!- shesek [~shesek@bzq-84-110-235-225.cablep.bezeqint.net] has joined #bitcoin-core-dev     
10:35 -!- shesek [~shesek@bzq-84-110-235-225.cablep.bezeqint.net] has quit [Changing host]     
10:35 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev     
10:39 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
10:42 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
10:45 < bitcoin-git> [bitcoin] richardkiss opened pull request #12425: Add some script tests (master...feature/bool_tests) https://github.com/bitcoin/bitcoin/pull/12425
10:47 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
10:49 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
10:50 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
10:51 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
10:53 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
11:10 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
11:11 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
11:11 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
11:16 -!- sengehest [~sengehest@188.81-166-37.customer.lyse.net] has quit [Ping timeout: 264 seconds]     
11:19 -!- mirese [~mirese@2a02:1205:507c:3710:19f7:563c:8714:141] has joined #bitcoin-core-dev     
11:22 -!- mirese_ [~mirese@2a02:1205:507c:3710:dc5c:e51f:b82c:93b] has quit [Ping timeout: 252 seconds]     
11:23 -!- ProfMac [~ProfMac@2001:470:b8ac:0:65d7:5d8:cbec:b9d3] has joined #bitcoin-core-dev     
11:27 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
11:31 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
11:36 -!- Julie73Donnelly [~Julie73Do@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 256 seconds]     
11:37 -!- mirese_ [~mirese@2a02:1205:507c:3710:6581:40f3:fecb:9358] has joined #bitcoin-core-dev     
11:37 -!- mirese__ [~mirese@2a02:1205:507c:3710:8419:c73:5056:dfda] has joined #bitcoin-core-dev     
11:40 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
11:40 -!- mirese___ [~mirese@2a02:1205:507c:3710:a5a2:de4a:5b6b:86f8] has joined #bitcoin-core-dev     
11:40 -!- mirese [~mirese@2a02:1205:507c:3710:19f7:563c:8714:141] has quit [Ping timeout: 252 seconds]     
11:41 -!- mirese [~mirese@2a02:1205:507c:3710:4026:56c6:958:f3d2] has joined #bitcoin-core-dev     
11:41 -!- mirese_ [~mirese@2a02:1205:507c:3710:6581:40f3:fecb:9358] has quit [Ping timeout: 256 seconds]     
11:43 -!- dcousens [~dcousens@101.188.141.174] has quit [Ping timeout: 256 seconds]     
11:44 -!- mirese__ [~mirese@2a02:1205:507c:3710:8419:c73:5056:dfda] has quit [Ping timeout: 256 seconds]     
11:44 -!- dcousens [~dcousens@CPE-101-160-3-159.lnse6.lon.bigpond.net.au] has joined #bitcoin-core-dev     
11:44 -!- mirese___ [~mirese@2a02:1205:507c:3710:a5a2:de4a:5b6b:86f8] has quit [Ping timeout: 256 seconds]     
11:46 -!- jtimon [~quassel@41.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
11:48 -!- dcousens [~dcousens@CPE-101-160-3-159.lnse6.lon.bigpond.net.au] has quit [Ping timeout: 240 seconds]     
11:49 -!- dcousens [~dcousens@101.188.147.134] has joined #bitcoin-core-dev     
11:50 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
11:52 -!- Tobin19Abernathy [~Tobin19Ab@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev     
11:55 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev     
11:55 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
11:57 -!- Randolf [~randolf@96.53.47.42] has quit [Ping timeout: 260 seconds]     
11:58 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
12:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
12:01 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]     
12:04 -!- tli [6836f103@gateway/web/freenode/ip.104.54.241.3] has joined #bitcoin-core-dev     
12:08 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
12:08 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
12:08 -!- neha [~narula@tbilisi.csail.mit.edu] has quit [Ping timeout: 260 seconds]     
12:10 -!- Tobin19Abernathy [~Tobin19Ab@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 240 seconds]     
12:13 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 248 seconds]     
12:15 -!- neha [~narula@tbilisi.csail.mit.edu] has joined #bitcoin-core-dev     
12:22 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
12:23 -!- tli [6836f103@gateway/web/freenode/ip.104.54.241.3] has quit [Quit: Page closed]     
12:24 < gmaxwell> Note: if anyone here uses bitmessage, it has a remote code execution bug. (deserializing using eval)
12:25 < sipa> what is it written in?
12:26 < gmaxwell> Python.
12:26 < contrapumpkin> is today national facepalm security day or something
12:29 < esotericnonsense> deserializing using eval ???
12:30 < esotericnonsense> -_-.
12:31 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
12:35 < instagibbs> the vulnerability is being exploited in the wild as well
12:35 < instagibbs> not sure about success, but trying to run windows executables, grab electrum wallets, the like
12:37 < gmaxwell> esotericnonsense: deserializing using eval is a thing I've seen many times w/ javascript, php, and python.
12:37 < contrapumpkin> java does its own version of that too, if you use their native serialization
12:38 -!- tli [6836f103@gateway/web/freenode/ip.104.54.241.3] has joined #bitcoin-core-dev     
12:38 -!- jamesob [~jamesob@172.56.35.233] has joined #bitcoin-core-dev     
12:39 < esotericnonsense> gmaxwell: oh sure it's a thing. i just feel like it's one of the most famous 'don't do this' footguns
12:39 < esotericnonsense> evidently not
12:44 -!- jamesob_ [~jamesob@67.251.193.154] has joined #bitcoin-core-dev     
12:47 -!- jamesob [~jamesob@172.56.35.233] has quit [Ping timeout: 256 seconds]     
12:48 < mmgen> wouldn't use of the json module protect against this?
12:49 < mmgen> first json.loads(), then deserialize?
12:52 < reardencode> mmgen: yes.
12:52 < mmgen> strange they didn't do that
12:52 -!- Marcia15Hilpert [~Marcia15H@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev     
12:55 -!- Randolf [~randolf@S0106c8fb26572f40.vc.shawcable.net] has joined #bitcoin-core-dev     
12:59 < mmgen> the fix: https://github.com/Bitmessage/PyBitmessage/commit/3a8016d31f517775d226aa8b902480f4a3a148a9
13:00 -!- Randolf [~randolf@S0106c8fb26572f40.vc.shawcable.net] has quit [Ping timeout: 248 seconds]     
13:00 -!- tli [6836f103@gateway/web/freenode/ip.104.54.241.3] has quit [Quit: Page closed]     
13:02 < contrapumpkin> that still seems like an iffy fix, even though the scope for mischief is far more limited
13:03 < contrapumpkin> it'll basically call an arbitrary method specified by untrusted data on the specified class
13:03 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-nqjcirqgczsodmak] has joined #bitcoin-core-dev     
13:03 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #12426: qt: Initialize members in WalletModel (master...Mf1802-qtInitializeMembersWalletModel) https://github.com/bitcoin/bitcoin/pull/12426
13:05 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
13:07 < mmgen> contrapumpkin: hopefully just an emergency fix. far better than nothing in any case
13:07 < contrapumpkin> yup :)
13:13 -!- harrymm [~harrymm@104.207.83.30] has quit [Ping timeout: 256 seconds]     
13:17 < mmgen> seems like try: assert data[""
13:18 < mmgen> seems like try: assert data[""] in ('message','vote') would have been safer
13:19 < contrapumpkin> the hoops people go through to avoid writing a proper parser... 😢
13:19 < mmgen> since 'message' and 'vote' are the only permissible values
13:19 < sipa> it's getting a bit off topic for this channel
13:19 < contrapumpkin> sorry :) I'll shut up
13:21 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
13:21 < mmgen> sipa: sorry
13:21 < sipa> np!     
13:22 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
13:22 < mmgen> sipa: though it **was** gmaxwell who brought up the topic
13:23 < sipa> i'm aware, and i participated too; no blame here
13:23 < sipa> just noting that the discussion is getting too far removed from the topic here
13:24 < mmgen> mmgen: i know, i'll really shut up now ;)
13:27 -!- harrymm [~harrymm@104.207.83.29] has joined #bitcoin-core-dev     
13:27 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
13:29 < bitcoin-git> [bitcoin] sipa opened pull request #12427: Make signrawtransaction accept P2SH-P2WSH redeemscripts (master...201802_signrawp2shp2wsh) https://github.com/bitcoin/bitcoin/pull/12427
13:30 < gmaxwell> doh, how'd we miss that
13:32 < grafcaps> hah     
13:38 -!- mmgen [~mmgen@gateway/tor-sasl/mmgen] has quit [Quit: (https://github.com/mmgen) leaving]     
13:38 < sipa> gmaxwell: it was actually partially being addressed in #11708
13:38 < gribble> https://github.com/bitcoin/bitcoin/issues/11708 | Add P2SH-P2WSH support to signrawtransaction and listunspent RPC by MeshCollider · Pull Request #11708 · bitcoin/bitcoin · GitHub
13:39 -!- tsunami_86 [~kaiebeer@dhcp-077-249-019-142.chello.nl] has joined #bitcoin-core-dev     
13:41 < promag> sipa: is it possible to add a test for #12427?
13:41 < gribble> https://github.com/bitcoin/bitcoin/issues/12427 | Make signrawtransaction accept P2SH-P2WSH redeemscripts by sipa · Pull Request #12427 · bitcoin/bitcoin · GitHub
13:41 < sipa> promag: yes, will look into that
13:41 < sipa> just wanted to have the PR visible as soon as possible
13:42 -!- tsunami_86 [~kaiebeer@dhcp-077-249-019-142.chello.nl] has quit [Remote host closed the connection]     
13:46 -!- Cogito_Ergo_Sum [~Myself@ppp-94-64-157-186.home.otenet.gr] has joined #bitcoin-core-dev     
13:46 -!- Cogito_Ergo_Sum [~Myself@ppp-94-64-157-186.home.otenet.gr] has quit [Changing host]     
13:46 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has joined #bitcoin-core-dev     
13:51 < Chris_Stewart_5> sipa: Is the basic idea that if we can sign the p2sh redeem script, we should be able to sign P2SH(P2WSH())?
13:51 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
13:54 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
13:58 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Client Quit]     
14:00 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
14:01 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
14:03 -!- cheese_ [Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev     
14:04 -!- harrymm [~harrymm@104.207.83.29] has quit []     
14:05 -!- Cheeseo [Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Ping timeout: 240 seconds]     
14:10 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
14:10 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has quit []     
14:11 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]     
14:13 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
14:14 -!- mrannanay [uid222022@gateway/web/irccloud.com/x-oljlqkjnmvfimlnt] has quit [Quit: Connection closed for inactivity]     
14:15 -!- jamesob_ [~jamesob@67.251.193.154] has quit [Ping timeout: 256 seconds]     
14:15 -!- Randolf [~randolf@72.143.234.246] has joined #bitcoin-core-dev     
14:17 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
14:19 -!- Randolf [~randolf@72.143.234.246] has quit [Read error: Connection reset by peer]     
14:21 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
14:25 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer]     
14:25 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev     
14:27 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
14:48 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 264 seconds]     
14:51 < eklitzke> this is kind of cool, i got a build of bitcoind working with systemtap markers (in this case I'm marking CCoinsViewCache flushes): https://gist.github.com/eklitzke/8bf6957fe886ddec36cde737d69ac6f5
14:56 -!- PaulCape_ [~PaulCapes@ip72-209-228-50.dc.dc.cox.net] has quit [Ping timeout: 255 seconds]     
14:59 -!- PaulCapestany [~PaulCapes@ip72-209-228-50.dc.dc.cox.net] has joined #bitcoin-core-dev     
14:59 -!- dongcarl [~dongcarl@c-24-5-70-69.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
15:00 < gmaxwell> eklitzke: whats the advantage of that?
15:04 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
15:05 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
15:13 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 264 seconds]     
15:13 < eklitzke> i'm going to add more probes and then use that to measure some work i'm trying to do to the ccoinscacheview, e.g. i want to make the cache into a real writeback cache and get cache hit statistics out of it
15:14 < eklitzke> today if you wanted to get cache hit statistics from CCoinCacheView::GetCoin you'd have to hack up some existing rpc to dump the information (or dump it to a log), with stap/dtrace probes that would be much easier and less invasive
15:16 < warren> Does anyone have working gitian with qemu-kvm instead of lxc? I want to compare notes.
15:18 < gmaxwell> eklitzke: you'll defeat its purpose entirely
15:20 -!- larafale [~larafale@ax213-1-82-66-157-194.fbx.proxad.net] has quit [Remote host closed the connection]     
15:20 < gmaxwell> eklitzke: the cache's purpose for existing is not to act as a cache, it's purpose is to act as a buffer to prevent writes from hitting the database entirely. And also to allow atomic updates to keep the database consistent with the chain at a block level (this is not as important since we now use a replay for consistency).  It also satisfies reads, but if you defeat that it doesn't make a huge p
15:20 < gmaxwell> erformance difference in IBD.
15:20 -!- larafale [~larafale@ax213-1-82-66-157-194.fbx.proxad.net] has joined #bitcoin-core-dev     
15:20 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev     
15:21 < gmaxwell> okay maybe on a non-SSD the read cache matters somewhat more, to be fair I haven't benchmarked it with defeated read caching on a spinning disk.
15:21 < eklitzke> i have thought through these issues, you can increase the amount of coins in memory during ibd in a way that's safe and still batches disk writes
15:21 < eklitzke> yes this is primarily for spinning disks
15:22 < eklitzke> or worse, people's cloud vm instances
15:22 < sipa> eklitzke: i've experimented with various cache flushing strategies before which try to predict which entries will be more useful in the near future, and keep them longer
15:22 < gmaxwell> eklitzke: the purpose of the replay stuff we did in 0.15.x was in part to enable incremental flushing, so yes, I also see advantages there.
15:23 < sipa> in practice, anything that reduced the ability to avoid writes slowed things down
15:23 < gmaxwell> but what we did find is that trying to achieve a higher read hit rate is mostly pointless.
15:23 < gmaxwell> (on a SSD at least)
15:24 < gmaxwell> I fear we've more or less given up on performance on non-SSDs :(  esp since many large spinning disks are shingled now and have horrifying performance.
15:24 < gmaxwell> Incremenal flushing would also give the advantage of getting rid of flushing latency spikes and perhaps better overlap IO and validation.
15:24 -!- larafale [~larafale@ax213-1-82-66-157-194.fbx.proxad.net] has quit [Ping timeout: 240 seconds]     
15:24 < eklitzke> the flushing code right now is pretty inefficient, anyway databases like mysql do this by having a dirty buffer pool watermark that causes them to flush (potentially a large amount of data), and then they retaing data in memory that was flushed to disk if it's not dirty
15:25 < eklitzke> if you kept exactly the same semantics wrt flushing a large amount of data but didn't automatically expire the old coins from memory that would be an improvement (in my opinion)
15:25 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
15:26 < eklitzke> would love to chat with you about it next week, as i'm participating in the chaincode labs hacker residency program
15:26 < gmaxwell> eklitzke: We've measured that, it doesn't help.
15:26 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
15:26 < eklitzke> i've also measured it and shown that it does
15:26 < gmaxwell> Thats the whole reason I brought the subject up-- so you don't assume read caching is important.
15:27 < gmaxwell> eklitzke: Interesting, I'd love to see those results.
15:27 < eklitzke> if there are any writeups or mailing list posts about experiments in this area i'd be interested to read them
15:27 < gmaxwell> eklitzke: probably in the PR introducing the replay on start there are some of them.
15:27 < eklitzke> ok, i'll take a look
15:28 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
15:29 < sipa> eklitzke: i'll be at the residency on 22nd and 23rd
15:29 < gmaxwell> I'd offer you the specific code I benchmarked but I don't have access to the system with it anymore.
15:29 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
15:30 -!- jojeyh [~delphi@2602:306:b8b6:b970:9998:324b:a5a3:1e2c] has quit [Ping timeout: 276 seconds]     
15:31 < sipa> eklitzke: the bitcoin utxo set is pretty unique as a data set in that a very large number of newly written entries are almost immediately after deleted again
15:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
15:31 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 276 seconds]     
15:31 < gmaxwell> We tested many configurations.  For an example, one of the specific cases we tested was having flush leave the entries in but marking them as non-dirty and existing in the backing store, and seperately removing non-dirty entries when full.  What appeared to be the case is that avoiding the read hit seemed basically irrelevant, because if i got read, that means it is getting spent, which means th
15:31 < gmaxwell> ere is going to be an erasure which must hit the disk. 
15:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
15:32 < TD-Linux> since many large spinning disks are shingled now and have horrifying performance. <- these are still really uncommon
15:32 < gmaxwell> TD-Linux: they seem to be 100% of people showing up and talking about their node performance on spinning disks, but now that I say that outloud...
15:32 < sipa> eklitzke: but we should talk more about this
15:33 < eklitzke> i would like to change some of the leveldb settings too, but that's another matter entirely; for instance leveldb is configured to only open 64 files at once, so during ibd or a reindex you see the process thrashing a lot in a pattern where it opens an lbd file, mmaps it, munmaps it, and closes it
15:33 < eklitzke> that's another matter entirely though
15:33 < gmaxwell> eklitzke: by all means if you have results, great. 
15:33 -!- TheRec_ is now known as TheRec     
15:33 < gmaxwell> eklitzke: we suffer from FD exhaustion issues currently. :( 
15:34 < eklitzke> yeah I talked to BlueMatt about it a bit yesterday, the thing is you can mmap a file, close the fd, and the mmap mapping is still valid
15:34 < gmaxwell> ah, cute.
15:34 < eklitzke> so if you didn't mind the extra memory overhead from the PTEs, you could potentially mmap all of the ldb files at once and not actually have 1000+ ldb files open
15:35 < eklitzke> doing *all* of them is probably too agressive
15:35 < gmaxwell> leveldb doesn't use mmap on 32 bit hosts.
15:35 < gmaxwell> and on 64-bit the only harm is the PTE as you note, which is pretty minor.
15:36 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]     
15:36 -!- rex_4539 [~textual@2a02:587:3508:900:34fe:e738:2b1c:67bb] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
15:37 < gmaxwell> eklitzke: if you want to get into leveldb internals there are probably a lot of other gains. E.g. our keys are almost uniformly random, and so bisections in leveldb can probably be replaced with a secant search.  (and if our keys aren't random enough, we could fix that)   leveldb block size is tunable too
15:37 < gmaxwell> I think I found larger blocks to be a loss, but that might not be as true with a secant search.
15:38 < eklitzke> yeah I was actually surprised that leveldb itself wasn't doing the mmap trick I just described (or at least have it as a tuneable parameter), I want to dig deeper into their code
15:39 < promag> ryanofsky: friendly ping https://github.com/bitcoin/bitcoin/pull/11687#pullrequestreview-94272991
15:40 < gmaxwell> eklitzke: I have a believe which I've not been able to validate yet, that a lot of the performance limitations of the current dbcache is all the malloc activity... that often doesn't show up too clearly in profiles. We'd talked about changing the main dbcache to an open hashtable with fixed size entries (and some special indirection to an exception map for unusually large entries).. but it's a l
15:40 < gmaxwell> ot of work to just try it and see if it helps.  
15:42 < eklitzke> interesting because glibc malloc already has systemtap probes bulitin, since 2.24 i think, so that would go well with my systemtap branch because you could write stap scripts that correlated activity in malloc with events in bitcoind
15:42 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-nqjcirqgczsodmak] has quit [Quit: Connection closed for inactivity]     
15:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
15:55 -!- vicenteH [~user@35.233.15.37.dynamic.jazztel.es] has quit [Ping timeout: 248 seconds]     
15:58 -!- Madscotslad [0543ebb0@gateway/web/freenode/ip.5.67.235.176] has joined #bitcoin-core-dev     
15:58 < Madscotslad> Wow nice to see a full IRC room its been a while :) hey folks.
15:58 < luke-jr> if you think this is full, you should see #bitcoin
16:00 -!- Emcy_ [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev     
16:00 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 240 seconds]     
16:03 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has quit [Quit: Leaving.]     
16:08 < Madscotslad> ooft :P
16:09 < Madscotslad> and i thought IRC was dead years ago :P
16:09 < Madscotslad> bored waiting on my node syncing lol
16:09 -!- Randolf [~randolf@96.53.47.42] has joined #bitcoin-core-dev     
16:13 -!- dongcarl [~dongcarl@c-24-5-70-69.hsd1.ca.comcast.net] has quit [Ping timeout: 276 seconds]     
16:14 -!- dongcarl [~dongcarl@c-24-5-70-69.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
16:22 -!- Dizzle [~dizzle@108.171.182.16] has quit [Quit: Leaving...]     
16:23 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
16:25 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-iyvbnyfmezhindvl] has joined #bitcoin-core-dev     
16:43 < bitcoin-git> [bitcoin] 251Labs opened pull request #12430: [rpc] Fix issue: "Negative version of transaction using json-rpc" (master...patch/11561/fix-negative-json-rpc-version) https://github.com/bitcoin/bitcoin/pull/12430
16:52 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
16:59 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-core-dev     
17:03 < gmaxwell> :(     
17:03 < gmaxwell> but the transaction version number there really is negative.
17:03 < gmaxwell> the distinction isn't irrelevant too, because there are <= rules on transaction versions.
17:04 -!- dongcarl [~dongcarl@c-24-5-70-69.hsd1.ca.comcast.net] has quit [Quit: leaving]     
17:20 -!- Madscotslad [0543ebb0@gateway/web/freenode/ip.5.67.235.176] has quit [Quit: Page closed]     
17:33 -!- n1bor [~n1bor@185.9.34.66] has quit [Ping timeout: 268 seconds]     
17:35 < bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f4f4f51f1a94...252ae7111cbf
17:35 < bitcoin-git> bitcoin/master b7f6002 Russell Yanofsky: Fix rescan test failure due to unset g_address_type, g_change_type...
17:35 < bitcoin-git> bitcoin/master 252ae71 Pieter Wuille: Merge #12424: Fix rescan test failure due to unset g_address_type, g_change_type...
17:36 < bitcoin-git> [bitcoin] sipa closed pull request #12424: Fix rescan test failure due to unset g_address_type, g_change_type (master...pr/scang) https://github.com/bitcoin/bitcoin/pull/12424
17:39 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has joined #bitcoin-core-dev     
17:43 -!- contrapumpkin [~copumpkin@haskell/developer/copumpkin] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]     
17:44 -!- n1bor [~n1bor@185.9.34.66] has joined #bitcoin-core-dev     
17:46 -!- contrapumpkin [~copumpkin@haskell/developer/copumpkin] has joined #bitcoin-core-dev     
17:49 -!- jojeyh [~delphi@99-59-126-62.lightspeed.irvnca.sbcglobal.net] has joined #bitcoin-core-dev     
17:50 < instagibbs> gmaxwell, was looking at that exact section of signraw, i thought something was off but bamboozled myself into thinking it was ok, oops
17:51 -!- cryptojanitor [uid278088@gateway/web/irccloud.com/x-vnnpjmvdcgnakiak] has quit [Quit: Connection closed for inactivity]     
17:52 -!- n1bor [~n1bor@185.9.34.66] has quit [Ping timeout: 260 seconds]     
17:54 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []     
17:55 -!- grafcaps [~haroldbr@104.137.194.255] has quit [Ping timeout: 268 seconds]     
18:01 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
18:02 -!- murrayn [~dafuq@unaffiliated/murrayn] has quit [Quit: Adios mofos]     
18:04 -!- n1bor [~n1bor@185.9.34.66] has joined #bitcoin-core-dev     
18:11 -!- Randolf [~randolf@96.53.47.42] has quit [Read error: Connection reset by peer]     
18:13 -!- grafcaps [~haroldbr@50.90.83.229] has joined #bitcoin-core-dev     
18:14 -!- n1bor [~n1bor@185.9.34.66] has quit [Ping timeout: 264 seconds]     
18:17 -!- n1bor [~n1bor@185.9.34.66] has joined #bitcoin-core-dev     
18:17 -!- dongcarl [~dongcarl@c-24-5-70-69.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
18:30 -!- dongcarl_ [~dongcarl@c-24-5-70-69.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
18:30 -!- dongcarl_ [~dongcarl@c-24-5-70-69.hsd1.ca.comcast.net] has quit [Client Quit]     
18:31 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]     
18:32 -!- booyah [~bb@193.25.1.157] has quit [Ping timeout: 240 seconds]     
18:32 -!- jojeyh [~delphi@99-59-126-62.lightspeed.irvnca.sbcglobal.net] has quit [Ping timeout: 248 seconds]     
18:35 -!- sanada` [~bitktn@36-2-119-80.chiba.ap.gmo-isp.jp] has joined #bitcoin-core-dev     
18:37 -!- sanada [~bitktn@36-2-119-80.chiba.ap.gmo-isp.jp] has quit [Ping timeout: 252 seconds]     
18:37 -!- twoken [~twoken@110.177.216.172] has quit [Ping timeout: 268 seconds]     
18:37 -!- cysm [cysm@gateway/shell/elitebnc/x-xgrkvrnvzyxonoss] has quit [Ping timeout: 260 seconds]     
18:38 -!- jimpo [~jimpo@ec2-52-42-179-84.us-west-2.compute.amazonaws.com] has quit [Ping timeout: 240 seconds]     
18:39 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
18:40 -!- jimpo [~jimpo@ec2-52-42-179-84.us-west-2.compute.amazonaws.com] has joined #bitcoin-core-dev     
18:41 -!- dongcarl [~dongcarl@c-24-5-70-69.hsd1.ca.comcast.net] has quit [Quit: leaving]     
18:42 -!- cysm [cysm@gateway/shell/elitebnc/x-sxmaxrmmbtkswkxx] has joined #bitcoin-core-dev     
18:42 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-iyvbnyfmezhindvl] has quit [Quit: Connection closed for inactivity]     
18:43 -!- twoken [~twoken@110.177.216.172] has joined #bitcoin-core-dev     
19:09 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
19:19 -!- jamesob_ [~jamesob@2604:2000:ee11:8700:2839:49a2:2dbc:318a] has joined #bitcoin-core-dev     
19:26 -!- cryptojanitor [uid278088@gateway/web/irccloud.com/x-abuixrfbbtffjmui] has joined #bitcoin-core-dev     
19:30 -!- twoken [~twoken@110.177.216.172] has quit []     
19:44 -!- murrayn [~dafuq@unaffiliated/murrayn] has joined #bitcoin-core-dev     
19:48 < bitcoin-git> [bitcoin] jamesob opened pull request #12431: Only call NotifyBlockTip when chainActive changes (master...jamesob/2018-02-prevent-bad-latestblock) https://github.com/bitcoin/bitcoin/pull/12431
19:52 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
20:05 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-odcczcjvsbaxzrkx] has joined #bitcoin-core-dev     
20:15 -!- jojeyh [~delphi@2602:306:b8b6:b970:b4ab:2df2:581f:7ebf] has joined #bitcoin-core-dev     
20:20 -!- DougieBot5000_ [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-core-dev     
20:23 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Ping timeout: 240 seconds]     
20:51 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has quit [Quit: Leaving.]     
20:54 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has joined #bitcoin-core-dev     
20:55 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has quit [Client Quit]     
21:15 -!- grafcaps [~haroldbr@50.90.83.229] has quit [Ping timeout: 248 seconds]     
21:17 -!- jamesob_ [~jamesob@2604:2000:ee11:8700:2839:49a2:2dbc:318a] has quit [Ping timeout: 276 seconds]     
21:34 -!- Randolf [~randolf@96.53.47.42] has joined #bitcoin-core-dev     
21:45 -!- jarthur [~jarthur@2605:6000:1019:42b6:bcb8:bf5a:cf57:ea7] has joined #bitcoin-core-dev     
22:03 -!- sengehest [~sengehest@188.81-166-37.customer.lyse.net] has joined #bitcoin-core-dev     
22:05 -!- cryptojanitor [uid278088@gateway/web/irccloud.com/x-abuixrfbbtffjmui] has quit [Quit: Connection closed for inactivity]     
22:10 -!- rex_4539 [~textual@ppp-2-87-180-48.home.otenet.gr] has joined #bitcoin-core-dev     
22:18 -!- instagibbs [~instagibb@pool-100-15-116-35.washdc.fios.verizon.net] has quit [Ping timeout: 264 seconds]     
22:19 -!- instagibbs [~instagibb@pool-100-15-116-35.washdc.fios.verizon.net] has joined #bitcoin-core-dev     
22:23 -!- sengehest [~sengehest@188.81-166-37.customer.lyse.net] has quit [Ping timeout: 268 seconds]     
22:37 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection]     
22:52 -!- booyah [~bb@193.25.1.157] has joined #bitcoin-core-dev     
22:54 -!- grafcaps [~haroldbr@50.90.83.229] has joined #bitcoin-core-dev     
23:04 -!- jtimon [~quassel@41.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]