--- Day changed Wed Jul 12 2017 00:00 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Remote host closed the connection] 00:01 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev 00:21 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-core-dev 00:23 -!- Cheeseo [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Read error: Connection reset by peer] 00:31 -!- coredump_ [~quassel@vpn-qld171.vpnsolutions.com.au] has quit [Ping timeout: 248 seconds] 00:32 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-jqpxbhovzydzmiiv] has joined #bitcoin-core-dev 00:38 -!- laurentmt [~Thunderbi@92.154.68.134] has joined #bitcoin-core-dev 00:41 -!- promag [~joao@2001:8a0:fe30:de01:e48d:4241:d22e:770a] has quit [Quit: Leaving.] 01:04 -!- arowser [~quassel@45.32.248.113] has quit [Remote host closed the connection] 01:09 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 01:10 -!- arowser [~quassel@45.32.248.113] has joined #bitcoin-core-dev 01:16 -!- laurentmt [~Thunderbi@92.154.68.134] has quit [Quit: laurentmt] 01:32 -!- Squidicc [~squid@pool-72-74-34-138.bstnma.fios.verizon.net] has joined #bitcoin-core-dev 01:36 -!- Squidicuz [~squid@pool-72-74-34-138.bstnma.fios.verizon.net] has quit [Ping timeout: 240 seconds] 01:53 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 01:55 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 240 seconds] 01:56 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev 01:57 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev 02:00 -!- goatpig [56f75436@gateway/web/freenode/ip.86.247.84.54] has joined #bitcoin-core-dev 02:16 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 02:17 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 02:38 -!- unholymachine [~quassel@2601:8c:c003:9f16:759a:593f:c3b3:7d73] has quit [Ping timeout: 246 seconds] 02:42 -!- unholymachine [~quassel@2601:8c:c003:9f16:28fc:ece8:8cd2:4f58] has joined #bitcoin-core-dev 02:45 < jonasschnelli> achow101: Have you reported him? 03:12 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 03:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 03:19 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 246 seconds] 03:26 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 03:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 03:46 < cdecker> I've been asked what my DNS seed policies are regarding BIP148, and I said that I will not filter non-UASF nodes 03:47 < cdecker> I guess that's the stance that the other operators will follow as well, or am I mistaken? 03:49 -!- riemann [~riemann@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev 03:49 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 04:18 < jonasschnelli> cdecker: Yes. I think the dns seed policy paper explicitly stats that... 04:18 < jonasschnelli> let me find it 04:19 < jonasschnelli> https://github.com/bitcoin/bitcoin/blob/57b34599b2deb179ff1bd97ffeab91ec9f904d85/doc/dnsseed-policy.md 04:19 < jonasschnelli> That: The DNS seed results must consist exclusively of fairly selected and functioning Bitcoin nodes from the public network to the best of the operator's understanding and capability. 04:20 < jonasschnelli> I guess if the chain splits, then you need to either have two seeds or clearly decide on what side your seed is operating... 04:20 < cdecker> Some people were arguing about the definition of functioning nodes is 04:20 < jonasschnelli> well,... until the chain split (and if), BIP148 and non BIP148 are functioning perfectly fine? not? 04:21 < cdecker> Right that's what I thought ^^ 04:21 < jonasschnelli> so.. lets don't bother with it for now. AFAIK dns-seeds can and do not check consensus.. they just look at the version message and may filter service bits 04:22 < jonasschnelli> The seeds crawler is not tied to a full node 04:25 < luke-jr> if there is a 51% attack in response to BIP148, I think it's perfectly fair to not include nodes that are vulnerable to following it 04:25 < cdecker> We might want to think about ways to differentiate once a hard fork occurs, I'm not sure one implementation will want to differentiate itself out of fear of being called non-bitcoin 04:27 < luke-jr> so I don't suggest committing to not filtering non-UASF (ie, vulnerable) nodes 04:28 < cdecker> On the other hand it's not a huge deal to return nodes from the two partitions, after all they will still gossip addresses across both forks as long as somewhere there's a bridge 04:29 < cdecker> luke-jr, I don't follow, you suggest against committing to something like this? 04:29 < luke-jr> cdecker: right 04:30 < luke-jr> in the worst case scenario, it may be necessary to protect light clients 04:30 < cdecker> I honestly don't see why, DNS seeds are infrastructure, not political tools 04:30 < cdecker> You mean having light clients flip-flop between the two forks 04:30 < luke-jr> cdecker: because light clients are inherently vulnerable 04:31 < luke-jr> they will follow any chain they see, no matter how invalid it is 04:31 < luke-jr> and unfortunately there are a lot of them 04:31 < jonasschnelli> luke-jr: not ultimatively 04:31 < luke-jr> jonasschnelli: ? 04:31 < cdecker> Ok, we might need to revisit this in the case of a fork, however I will definitely not filter depending on the presence of a UASF signal 04:32 < jonasschnelli> The light client i'm working on (based on core) does validate block size and SigOp counts, etc. 04:32 < cdecker> And that's what I'm committing to 04:32 < luke-jr> cdecker: that's the easiest way to detect vulnerable nodes 04:32 < jonasschnelli> light client with client side filtering can validate the "important" parameters 04:32 < jonasschnelli> just not with the BF stuff 04:32 < luke-jr> jonasschnelli: right, but those aren't the ones that stupidly connect to only seed nodes 04:34 < jonasschnelli> Yes. Those need protection... 04:34 < cdecker> Well, we can of course create a twin seed setup for both sides, but we would need a way to differentiate them and we need to expose the option of selecting which seed to use to light clients 04:35 < luke-jr> jonasschnelli: well, they don't strictly NEED it, since even headers can enforce, but who knows what these wallets are doing, if anything :/ 04:35 < luke-jr> they don't seem to even have BIP 9 code yet 04:45 -!- ayy1337 [~kvirc@110.140.162.56] has joined #bitcoin-core-dev 04:47 -!- ayy1337 [~kvirc@110.140.162.56] has left #bitcoin-core-dev [] 04:48 -!- ayylmao [6e8ca238@gateway/web/freenode/ip.110.140.162.56] has joined #bitcoin-core-dev 04:49 < cdecker> Ok, not making special provisions for a fork for now 05:06 -!- coredump_ [~quassel@101.165.147.38] has joined #bitcoin-core-dev 05:20 < jonasschnelli> ryanofsky: in your deque blocksToDownloadFirst approach, how could the wallet do a rescan? Assume you import a new seed/key and want to do a rescan, also the assumption is that light clients won't keep blocks (pruning) 05:21 < jonasschnelli> hmm.. maybe just refill the queue... I see 05:22 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 260 seconds] 05:24 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 255 seconds] 05:25 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 05:26 -!- Aaronvan_ is now known as AaronvanW_ 05:26 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection] 05:29 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 05:32 -!- AaronvanW_ is now known as AaronvanW 05:32 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev 05:39 -!- wbnns_ [sid105317@21/bitcoin/binns] has joined #bitcoin-core-dev 05:40 -!- CodeShark_ [sid126576@gateway/web/irccloud.com/x-egokdoxawwwlvfxt] has joined #bitcoin-core-dev 05:41 -!- spinza [~spin@196.212.164.26] has quit [Excess Flood] 05:41 -!- Guest89066 [~socrates1@li175-104.members.linode.com] has quit [Ping timeout: 260 seconds] 05:41 -!- TD--Linux [~Thomas@kyoko.thomasdaede.com] has joined #bitcoin-core-dev 05:41 -!- CodeShark [sid126576@gateway/web/irccloud.com/x-eugwmiyfnvabvufe] has quit [Ping timeout: 246 seconds] 05:41 -!- wbnns [sid105317@21/bitcoin/binns] has quit [Ping timeout: 246 seconds] 05:41 -!- TD-Linux [~Thomas@about/essy/indecisive/TD-Linux] has quit [Ping timeout: 246 seconds] 05:41 -!- CodeShark_ is now known as CodeShark 05:41 -!- wbnns_ is now known as wbnns 05:44 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 240 seconds] 05:45 -!- Guest75836 [~socrates1@li175-104.members.linode.com] has joined #bitcoin-core-dev 05:46 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev 05:52 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 06:01 -!- spinza [~spin@196.212.164.26] has joined #bitcoin-core-dev 06:08 -!- Maxime2 [~Maxime@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev 06:10 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 06:10 -!- coredump_ [~quassel@101.165.147.38] has quit [Ping timeout: 246 seconds] 06:12 -!- coredump_ [~quassel@101.165.147.38] has joined #bitcoin-core-dev 06:20 -!- Cheeseo [~Cheeseo@unaffiliated/cheeseo] has joined #bitcoin-core-dev 06:21 -!- cheese_ [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev 06:22 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has quit [Ping timeout: 255 seconds] 06:24 -!- Cheeseo [~Cheeseo@unaffiliated/cheeseo] has quit [Ping timeout: 240 seconds] 06:28 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has joined #bitcoin-core-dev 06:28 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 255 seconds] 06:28 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 06:31 -!- schnerchi [~schnerchi@static.120.187.99.88.clients.your-server.de] has quit [Ping timeout: 240 seconds] 06:35 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #bitcoin-core-dev 06:36 -!- schnerchi [~schnerchi@2a01:4f8:c0c:afe::2] has joined #bitcoin-core-dev 06:44 < bitcoin-git> [bitcoin] jnewbery opened pull request #10802: [tests] skip zapwallettxes.py (master...skip_zapwallettxes) https://github.com/bitcoin/bitcoin/pull/10802 06:54 -!- schnerchi [~schnerchi@2a01:4f8:c0c:afe::2] has quit [Ping timeout: 255 seconds] 06:59 -!- schnerchi [~schnerchi@static.120.187.99.88.clients.your-server.de] has joined #bitcoin-core-dev 07:00 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 07:01 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 07:01 < bitcoin-git> [bitcoin] pstratem opened pull request #10803: Explicitly search for bdb5.3. (master...2017-07-02-bdb5.3) https://github.com/bitcoin/bitcoin/pull/10803 07:13 -!- promag [~joao@2001:8a0:fe30:de01:140f:521d:7820:e05] has joined #bitcoin-core-dev 07:16 -!- coredump_ [~quassel@101.165.147.38] has quit [Ping timeout: 246 seconds] 07:43 -!- hydrat [~hydrat@41.216.228.242] has joined #bitcoin-core-dev 07:43 -!- hydrat [~hydrat@41.216.228.242] has left #bitcoin-core-dev [] 07:45 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has quit [Quit: .] 07:49 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has joined #bitcoin-core-dev 07:49 < jonasschnelli> Currently exploring nat traversal for a different project. Was ICE (ICE: Interactive Connectivity Establishment) or STUN ever considered for Core and if now, why? 07:57 < ryanofsky> i thought nat traversal was more for udp and tcp 07:57 < ryanofsky> udp than tcp 07:57 -!- riemann [~riemann@84-10-11-234.static.chello.pl] has quit [Quit: Leaving] 07:58 < BlueMatt> getting nat traversal to work with tcp means you need a userspace tcp impl, something we def dont want to get into 07:59 < BlueMatt> if it even works at all 08:01 < jonasschnelli> So UPnP is the best you can do without userspace tcp impl? 08:02 < BlueMatt> yes 08:02 < jonasschnelli> What about all these SIP NAT traversal solutions.. do they all have a userspace TCP implementation? 08:02 * jonasschnelli is looking at http://www.pjsip.org/pjnath/docs/html/index.htm right now 08:02 < BlueMatt> Sip does not use tcp if it needs nat traversal, no? 08:03 -!- ayylmao [6e8ca238@gateway/web/freenode/ip.110.140.162.56] has quit [Quit: Page closed] 08:03 < jonasschnelli> I though SIP is using TCP for establishing... but not sure 08:04 < BlueMatt> it may, but you're not getting incoming tcp through nat 08:04 < BlueMatt> just not gonna happen 08:05 < jonasschnelli> Okay. Thanks BlueMatt. 08:06 < jonasschnelli> ryanofsky: I started to work on your std::deque approach, but seems that a queue is not sufficient.. because you may want to dequeue when they have been downloaded and that is not in order.. 08:06 < jonasschnelli> Are there any significant downsides using a std::map? 08:07 < jonasschnelli> (and just erase the requested block when it's processed) 08:07 < ryanofsky> oh good point, yeah maybe you need a map or a list of lists 08:14 -!- Aaronvan_ is now known as AaronvanW 08:24 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #bitcoin-core-dev 08:25 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev 08:26 < BlueMatt> cfields: wait, huh, --enable-lto only adds -flto? why not also specify ar/ranlib/nm as well automatically? 08:37 < jnewbery> jonasschnelli: in my experience providers often use SBCs to resolve NAT traversal 08:38 < ryanofsky> southern baptist conventions? 08:38 < jonasschnelli> hehe 08:38 < jonasschnelli> lookin it up 08:39 < jnewbery> SIP can go over TCP or UDP. TCP is more common in my experience 08:39 < jnewbery> Session Border Controller 08:42 < jonasschnelli> Going off-topic: but what's the best approach for a direct communication channel between two devices behind NAT without a centralized server? 08:42 < jonasschnelli> Using UDP (and your own error detection, etc protocol)? 08:44 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 08:44 < bitcoin-git> [bitcoin] promag opened pull request #10804: Add histunspent RPC (master...2017-07-rpc-add-histunspent) https://github.com/bitcoin/bitcoin/pull/10804 08:45 < jnewbery> STUN/ICE I believe, although it's not something I know much about 08:46 < jonasschnelli> thanks jnewbery. 08:46 < bitcoin-git> [bitcoin] janstary opened pull request #10805: have proper manpages for bitcoin*(1) (master...master) https://github.com/bitcoin/bitcoin/pull/10805 08:49 -!- pandabull [~pandabull@2603:3005:715:c400:2547:dfad:c344:1c39] has joined #bitcoin-core-dev 08:50 < morcos> wumpus: for boost::optional, do you prefer .reset() ( which is deprecated but aligns with c++17) or =boost::none . I have no preference, and am happy to change to .reset() as ryanofsky suggests 08:53 < morcos> a tiny bit of research suggested to me that if anything reset may be undeprecated in boost now that it's in std, but it's not in the recent boost docs (ryanofsky are we sure it works with recent boost?) 08:54 < ryanofsky> i can check latest documentation, but i think all of boost::optional is deprecated now that std::optional exists 08:55 < TD--Linux> you can totally do TCP hole punching too 08:55 < TD--Linux> I don't know if ICE does it 09:01 < ryanofsky> morcos, reset is in latest release (1.64.0) and latest git version (https://github.com/boostorg/optional/blob/develop/include/boost/optional/optional.hpp#L345) 09:04 -!- promag [~joao@2001:8a0:fe30:de01:140f:521d:7820:e05] has quit [Quit: Leaving.] 09:08 < morcos> ryanofsky: but not in the documentation anywhere right? 09:08 -!- pandabull [~pandabull@2603:3005:715:c400:2547:dfad:c344:1c39] has quit [Remote host closed the connection] 09:08 < morcos> i'm fine with it if others are 09:10 < ryanofsky> it's in the documentation, too: http://www.boost.org/doc/libs/1_64_0/libs/optional/doc/html/boost_optional/reference/header__boost_optional_optional_hpp_/header_optional_optional_values.html#reference_operator_template 09:11 -!- timothy [tredaelli@redhat/timothy] has quit [Remote host closed the connection] 09:11 < phantomcircuit> jonasschnelli, some of the sip nat transversal is actually just proxying through random third party servers 09:15 < phantomcircuit> TD--Linux, iirc actually getting tcp hole punching to work is unreliable due to nat implementation variance 09:15 < phantomcircuit> you need to know the other peers report mapped source port for example 09:15 < phantomcircuit> which they may not even know 09:16 < BlueMatt> jonasschnelli: since you're here, whats up with #10650? 09:16 < gribble> https://github.com/bitcoin/bitcoin/issues/10650 | Multiwallet: add RPC endpoint support by jonasschnelli · Pull Request #10650 · bitcoin/bitcoin · GitHub 09:16 < BlueMatt> right now it looks like multiwallet is gonna miss 15 :( 09:17 < BlueMatt> or...were here 09:19 < ryanofsky> i requested a number of changes to 10650, but they're all simple, and i'd happy to help with implementation. i guess it the functionality works though and it just needs a few more acks? 09:21 < BlueMatt> there are some easy-fix issues from my review 09:27 -!- riemann [~riemann@ip-222-88.ists.pl] has joined #bitcoin-core-dev 09:28 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has quit [Read error: Connection reset by peer] 09:30 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 09:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 09:31 -!- pandabull [~pandabull@2603:3005:715:c400:2547:dfad:c344:1c39] has joined #bitcoin-core-dev 09:35 < morcos> ryanofsky: how did you even get to that webpage? I keep ending up here: http://www.boost.org/doc/libs/1_64_0/libs/optional/doc/html/optional/reference/header__boost_optional_optional_hpp_.html 09:37 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 248 seconds] 09:37 -!- Aaronvan_ is now known as AaronvanW 09:38 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev 09:52 -!- TD--Linux is now known as TD-Linux 09:52 -!- TD-Linux [~Thomas@kyoko.thomasdaede.com] has quit [Changing host] 09:52 -!- TD-Linux [~Thomas@about/essy/indecisive/TD-Linux] has joined #bitcoin-core-dev 10:02 < cfields> BlueMatt: uh, what AR/RANLIB to add? 10:03 < cfields> s/add/specify/ 10:03 -!- pandabull [~pandabull@2603:3005:715:c400:2547:dfad:c344:1c39] has quit [Remote host closed the connection] 10:06 < BlueMatt> cfields: dunno, my bash history says `which gcc-ar` 10:07 < BlueMatt> (and ranlib and nm) 10:07 < cfields> BlueMatt: and for arm? mingw? 10:07 < BlueMatt> no idea 10:07 < cfields> exactly :) 10:07 < cfields> they're per-toolchain 10:07 < BlueMatt> well at least do it for native :p 10:08 < BlueMatt> eg test $PREFIX-gcc-*, and if it fails, use $PREFIX-* 10:08 < cfields> not for clang, i believe 10:08 < sipa> my benchmark says that reindex with lto is significantly slower... 10:08 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has joined #bitcoin-core-dev 10:08 < sipa> both on -O2 and -O3 10:08 < BlueMatt> $CXX-* :p 10:09 < sipa> bitcoind-master-O2: 4977 10:09 < sipa> bitcoind-master-O3: 4815 10:09 < sipa> bitcoind-master-O2-lto: 5722 10:09 < sipa> bitcoind-master-O3-lto: 5577 10:09 < cfields> sipa: (relevant, i swear) did you ever bench the leveldb crc32 impact on reindex? 10:09 < sipa> cfields: no 10:10 < cfields> currently if you set cflags/cxxflags by hand, those end up disabled 10:10 < sipa> ugh 10:10 < cfields> pr is incoming 10:10 < BlueMatt> wtf 10:10 < sipa> that explains! 10:10 < cfields> BlueMatt: it's not clear what we should do in that case, though 10:11 < sipa> just add -msse4.2 to the CXXFLAGS for that? 10:11 < BlueMatt> cfields: i mean cant you do a two-object link test during configure? 10:11 < cfields> BlueMatt: consider: ./configure CXXFLAGS="-O2 -march=i686" 10:11 < cfields> BlueMatt: yea, that's the pr 10:11 < BlueMatt> ohoh, sorry, wrong thing 10:11 < sipa> it also means crcing is hugely significant... 10:11 < BlueMatt> sipa: didnt we know that, though? 10:12 < cfields> sipa: er no, that won't do what you want. That'll enable msse4.2 everywhere 10:12 < BlueMatt> i though i saw benchmarks from you or so that indicated the crc improvements helped a ton previously 10:12 < sipa> cfields: oh, the link-time flags are what matters? 10:13 < cfields> sipa: actually, that's a good question... 10:13 < sipa> BlueMatt: i didn't know they were 20% of our cpu usage... 10:13 < cfields> I would hope it's smart enought to remember per-object flags? 10:13 < sipa> cfields: i would hope so to, but if not, that doesn't explain why lto is slower 10:14 < BlueMatt> cfields: no? why would it be? 10:14 < cfields> sipa: anyway, please try with #10800 instead. Then you don't need to set your own flags 10:14 < gribble> https://github.com/bitcoin/bitcoin/issues/10800 | build: add lto configure option by theuni · Pull Request #10800 · bitcoin/bitcoin · GitHub 10:14 < BlueMatt> i dont think it is, i mean for some flags sure, but mostly i would expect only link-time flags to matter 10:14 < cfields> BlueMatt: so that we can enable instructions for only certain objects (after they've been cpuid checked) 10:15 < sipa> cfields: all of my numbers are with -O2/-O3 -lfo/"" set explicitly for CFLAGS/CXXFLAGS/LDFLAGS 10:15 < sipa> so if overriding flags is bad, it would be bad for all 4 benchmarks 10:15 < BlueMatt> yes, point is I'd assume that would only work on non-lto, or might otherwise confuse ld 10:16 < cfields> BlueMatt: i'd expect the opposite to avoid segfaults all over the place :) 10:16 < cfields> time to google and find out 10:16 < gmaxwell> BlueMatt: hm lto should be fine with mixed cflags. 10:16 < BlueMatt> gmaxwell: mixed clfags maybe, but mixed -march? 10:16 < gmaxwell> (w gcc you can even use pragma to change march on a function by function basis) 10:16 < BlueMatt> true 10:17 < jnewbery> wumpus: sorry for the back and forth - i think we can remove #10711 from https://github.com/bitcoin/bitcoin/projects/8 . I still want it to go in, but it's not essential for 0.15 (in fact it could probably go in after feature freeze since it doesn't touch product code) 10:17 < gribble> https://github.com/bitcoin/bitcoin/issues/10711 | [tests] Introduce TestNode by jnewbery · Pull Request #10711 · bitcoin/bitcoin · GitHub 10:17 < cfields> sipa: ok, so it's a level playing field i guess, if i understand your setup correctly 10:18 < BlueMatt> yea, i mean i could see lto being slower, but that seems like a lot slower 10:19 < BlueMatt> in other news, any other for-15 stuff that needs review? 10:19 < bitcoin-git> [bitcoin] theuni opened pull request #10806: build: verify that the assembler can handle crc32 functions (master...configure-check-asm) https://github.com/bitcoin/bitcoin/pull/10806 10:19 < cfields> sipa: also, are you using gcc-ar/ranlib-ar? Or at least verifying that you're not linking fat objects? 10:19 < sipa> COMMON="-O2"; ./configure CXXFLAGS="$COMMON" LDFLAGS="$COMMON" CFLAGS="$COMMON" AR=/usr/bin/gcc-ar NM=/usr/bin/gcc-nm RANLIB=/usr/bin/gcc-ranlib --with-incompatible-bdb --without-gui && make clean && make -j16 src/bitcoind && cp src/bitcoind src/bitcoind-master-O2 10:20 < BlueMatt> oh, #10758 needs a 15 tag 10:20 < gribble> https://github.com/bitcoin/bitcoin/issues/10758 | Fix some chainstate-init-order bugs. by TheBlueMatt · Pull Request #10758 · bitcoin/bitcoin · GitHub 10:20 < cfields> perfect, thanks 10:21 < cfields> so, thoughts on how to handle the flags overriding there? 10:21 -!- pandabull [~pandabull@2603:3005:715:c400:2547:dfad:c344:1c39] has joined #bitcoin-core-dev 10:22 < cfields> it's very unexpected imo that crc32 would be disabled simply by setting CXXFLAGS="-O3" 10:22 < gmaxwell> cfields: for the leveldb stuff it should just append -msse4.2 to whatever cflags it gets. 10:22 < sipa> cfields: i can fix that in an ugly way :) 10:22 < gmaxwell> (for the test and the file) 10:22 * sipa is a fan of inline asm 10:22 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #bitcoin-core-dev 10:22 < cfields> gmaxwell: what if cflags is "-O2 -march=i686" ? 10:23 < gmaxwell> sipa: using the byte sequences is pretty ugly, and otherwise you still need the -msse4.2 10:23 < gmaxwell> cfields: then that will fail, the test will fail, and it will turn it off. 10:23 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Remote host closed the connection] 10:23 < sipa> gmaxwell: yes indeed, that's why it's ugly :) 10:23 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Plugging out.] 10:24 < gmaxwell> Why is that ugly, it's what the test is for! 10:24 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #bitcoin-core-dev 10:24 < gmaxwell> (I mean the configure test to find out if compiling with -msse4.2) 10:24 < sipa> gmaxwell: i mean using byte sequences is ugly 10:24 < sipa> ... but it solves everything 10:25 -!- pandabull [~pandabull@2603:3005:715:c400:2547:dfad:c344:1c39] has quit [Read error: Connection reset by peer] 10:26 -!- pandabull [~pandabull@2603:3005:715:c400:2547:dfad:c344:1c39] has joined #bitcoin-core-dev 10:26 < cfields> gmaxwell: yes, that works 10:26 < gmaxwell> sipa: I'm not opposed, esp for single instructions... but ugh 10:26 < cfields> sipa: i think i agree 10:27 < sipa> FWIW, i do not find any crc instructions in disassemblies of my benchmark binaries 10:27 < sipa> so at least the comparison is fair 10:28 < sipa> ... and lto actually slows things down? :( 10:28 < cfields> strange 10:29 < gmaxwell> how are you not getting crc instructions when you were building with -march=native or does the current configure stuff just turn it off when any cflags are set 10:30 < sipa> gmaxwell: i'm not using -march=native 10:30 < sipa> just -O2" 10:30 < gmaxwell> sipa: cool so if we fix that perhaps we'll finally get it under 1hr with sha-ni. :P 10:30 < sipa> just "-O2", "-O3", "-O2 -flto", "-O3 -flto" 10:31 < cfields> gmaxwell: ^^ pr fixes -march=native 10:35 < gmaxwell> perhaps we could add some logging if crc32 instruction is in use. (and same for other accelerators later) 10:35 < gmaxwell> e.g. is leveldb's detect function exported 10:36 < cfields> no 10:36 < gmaxwell> grr 10:38 < cfields> oh that reminds me, i need to finish fixing their detection 10:50 -!- jtimon [~quassel@102.30.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 10:52 -!- marcoagner [~user@187.113.137.68] has joined #bitcoin-core-dev 10:59 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 11:03 -!- pandabull [~pandabull@2603:3005:715:c400:2547:dfad:c344:1c39] has quit [] 11:06 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Ping timeout: 240 seconds] 11:07 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 11:07 -!- JackH [~laptop@176.74.242.65] has joined #bitcoin-core-dev 11:24 < jnewbery> Does anyone know if bitcoin-cli is supposed to work with ipv6? I can't seem to make it connect when specifying an ipv6 address in -rpcconnect 11:25 < sipa> try putting [] around the ip 11:25 < jnewbery> i've tried all the permutations ::1 [::1] "::1" "[::1]" 11:30 < sipa> hmm 11:30 < jnewbery> There's #1827 but that's ancient and before libevent 11:30 < gribble> https://github.com/bitcoin/bitcoin/issues/1827 | HTTP client needs IPv6 support · Issue #1827 · bitcoin/bitcoin · GitHub 11:30 < cfields> jnewbery: sure you're listening on ipv6 too? 11:31 < jnewbery> I think so. Background is I'm trying to run rpcbind.py. It works when I use direct RPC, but not if I feed all RPC through bitcoin-cli 11:32 < jnewbery> I've added a `-usecli` option to the functional tests which makes all RPCs go through bitcoin-cli. This is the last test that I can't get to run with that option 11:34 < arubi> jnewbery, I have vague memory I also had to specify the port with ipv6, but that was a while ago.. 11:34 < arubi> not sure if you already did 11:35 < jnewbery> arubi: yes - port is specified 11:36 < jnewbery> Does that mean you were able to use bitcoin-cli with ipv6? 11:37 < cfields> jnewbery: what libevent version? 11:37 < arubi> it was a while ago, I didn't mess with it too much so might just be bitcoind related and not -cli 11:38 < arubi> it might have been -rpcbind, sorry for the confusion 11:38 < jnewbery> cfields: what's the quickest way to find out? 11:39 < jnewbery> arubi: yeah bitcoin-cli over ipv6 seems pretty niche. Can't imagine many people use it 11:40 < cfields> jnewbery: grep _EVENT_NUMERIC_VERSION /usr/include/event2/event-config.h 11:41 < bitcoin-git> [bitcoin] instagibbs opened pull request #10807: getbalance example covers at least 6 confirms (master...getbalexample) https://github.com/bitcoin/bitcoin/pull/10807 11:42 < cfields> jnewbery: I've been trying to track down when this bug was fixed, looks like it was never backported to 2.0.x :( 11:42 < cfields> jnewbery: https://github.com/libevent/libevent/commit/71e709c7829275a594f767b27468b1b52e8b5bb9 11:42 < jnewbery> #define _EVENT_NUMERIC_VERSION 0x02001500 11:47 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #bitcoin-core-dev 11:47 < cfields> hmm, looks like it should be fixed there 11:48 < bitcoin-git> [bitcoin] TheBlueMatt opened pull request #10808: Avoid some new gcc warnings in 15 (master...2017-07-15-new-warnings) https://github.com/bitcoin/bitcoin/pull/10808 11:53 < jnewbery> cfields: are you sure? https://github.com/libevent/libevent/blob/64177777165d9684bafbfa946abd126f7ebff11f/http.c#L2192 11:53 < jnewbery> That's v2.0.21 11:53 < cfields> jnewbery: I believe that 0x02001500 is 2.1.5beta 11:54 < jnewbery> Not quite. Here's 2.1.5beta: https://github.com/libevent/libevent/blob/release-2.1.5-beta/configure.ac#L17 11:55 < jnewbery> 0x02010500 11:55 < cfields> ah, heh 11:55 < cfields> i'd guess that's the problem, then 11:55 < cfields> you can try a depends build to verify 11:56 < jnewbery> I'll try that. Thanks! 11:56 < cfields> np 12:15 -!- ivan [~ivan@unaffiliated/ivan/x-000001] has quit [Quit: lp0 on fire] 12:19 -!- ula [~kvirc@b2b-78-94-9-226.unitymedia.biz] has joined #bitcoin-core-dev 12:37 -!- rhavar [uid237883@gateway/web/irccloud.com/x-vqidzwadevfnsdma] has quit [Quit: Connection closed for inactivity] 12:42 -!- lucianor [~lucianor@200.68.122.121] has joined #bitcoin-core-dev 12:50 < cfields> sipa: i'd be curious to know if --enable-reduce-exports changes your lto results any 12:50 < sipa> cfields: let's try! 12:52 < cfields> sipa: i have no idea what's going on behind the scenes, but if it uses symbol visibility to determine how aggressively it can inline, I would expect an improvement from that 12:52 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Quit: Leaving] 12:55 < sipa> cfields: rebuilding 13:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 13:04 -!- jtimon [~quassel@102.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds] 13:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 13:12 -!- promag [~joao@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 13:13 -!- promag [~joao@bl22-247-244.dsl.telepac.pt] has quit [Client Quit] 13:23 < morcos> jonasschnelli: sorry I missed that you had pinged me on #8501 and I didn't realize you'd redone it. I'm assumign that's missing 0.15 at this point? I will review post 0.15 unless you are still hoping to make it. 13:23 < gribble> https://github.com/bitcoin/bitcoin/issues/8501 | Add mempool statistics collector by jonasschnelli · Pull Request #8501 · bitcoin/bitcoin · GitHub 13:24 < jonasschnelli> morcos: no hurry. Will not be in 0.15. 13:24 < morcos> oops. sorry! 13:40 < morcos> #10235 should be tagged 0.15 please 13:40 < gribble> https://github.com/bitcoin/bitcoin/issues/10235 | Track keypool entries as internal vs external in memory by TheBlueMatt · Pull Request #10235 · bitcoin/bitcoin · GitHub 13:40 < BlueMatt> or just merged, at this point 13:40 < morcos> or tagged and merged so it looks like we are making more progress :) 13:40 < BlueMatt> lol, that too 13:43 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 248 seconds] 13:43 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Ping timeout: 276 seconds] 13:45 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds] 13:46 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev 13:46 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #bitcoin-core-dev 13:52 < bitcoin-git> [bitcoin] theuni opened pull request #10809: optim: mark a few classes final (master...final-classes) https://github.com/bitcoin/bitcoin/pull/10809 14:00 -!- jtimon [~quassel@102.30.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 14:20 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 14:21 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 14:25 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 14:25 < bitcoin-git> [bitcoin] petertodd closed pull request #8543: Use ANYONECANPAY if -spendzeroconfchange=0 (master...2016-08-anyonecanpay-if-spendzeroconfchange-disabled) https://github.com/bitcoin/bitcoin/pull/8543 14:46 < gmaxwell> cfields: how much would it make you hate life to adjust our build system so that leveldb stops getting build with -Wsign-compare 14:46 < gmaxwell> soo tired of that one warning... 14:48 < BlueMatt> lol 14:48 < BlueMatt> cant we just patch it? 14:51 < cfields> gmaxwell: heh. I'm with BlueMatt on that one :) 14:51 < BlueMatt> dont we already carry leveldb patches? 14:52 < sipa> cfields: ack, fix it in bitcoin-core/leveldb 14:54 < morcos> I think #10604 should also go in for 0.15 (needs milestone) assuming #10650 makes it 14:54 < gribble> https://github.com/bitcoin/bitcoin/issues/10604 | [wallet] [tests] Add listwallets RPC, include wallet name in `getwalletinfo` and add multiwallet test by jnewbery · Pull Request #10604 · bitcoin/bitcoin · GitHub 14:54 < gribble> https://github.com/bitcoin/bitcoin/issues/10650 | Multiwallet: add RPC endpoint support by jonasschnelli · Pull Request #10650 · bitcoin/bitcoin · GitHub 14:56 < gmaxwell> or that 14:57 < sipa> just merged https://github.com/bitcoin-core/leveldb/pull/2 14:57 < sipa> we should include that change up into the bitcoin core subtree for 0.15 14:57 < sipa> but if we get some signedness fixes in too, even better 14:58 < BlueMatt> NICE 14:58 < BlueMatt> yes, lets do that (for 15) 14:59 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 15:00 < sipa> go open a pr 15:00 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 15:02 < instagibbs> 10604 makes sense regardless, and is really easy to review 15:05 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 15:06 < bitcoin-git> [bitcoin] greenaddress opened pull request #10810: missing white space in function arg (master...missing_white_space) https://github.com/bitcoin/bitcoin/pull/10810 15:07 -!- riemann [~riemann@ip-222-88.ists.pl] has quit [Quit: Leaving] 15:07 -!- Soligor [~Soligor@unaffiliated/soligor] has quit [Ping timeout: 276 seconds] 15:09 -!- henrik_ [~henrik@62-243-108-58-static.dk.customer.tdc.net] has joined #bitcoin-core-dev 15:09 < bitcoin-git> [bitcoin] jnewbery opened pull request #10812: [utils] Allow bitcoin-cli's -rpcconnect option to be used with square brackets (master...bitcoin_cli_ipv6) https://github.com/bitcoin/bitcoin/pull/10812 15:13 < gmaxwell> sipa: plz2merge 10714 15:13 < henrik_> I think BTC is going in a wrong dirrection. We are in the process of re-inventing the banking business. Why not aim a little heigher? 15:17 < sipa> other things that need merging? 15:17 < BlueMatt> #10235 should be tagged 0.15 please 15:17 < BlueMatt> https://github.com/bitcoin/bitcoin/issues/10235 | Track keypool entries as internal vs external in memory by TheBlueMatt · Pull Request #10235 · bitcoin/bitcoin · GitHub 15:17 < BlueMatt> or just merged, at this point 15:17 < gribble> https://github.com/bitcoin/bitcoin/issues/10235 | Track keypool entries as internal vs external in memory by TheBlueMatt · Pull Request #10235 · bitcoin/bitcoin · GitHub 15:17 < gribble> https://github.com/bitcoin/bitcoin/issues/10235 | Track keypool entries as internal vs external in memory by TheBlueMatt · Pull Request #10235 · bitcoin/bitcoin · GitHub 15:17 < bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e8b95239eeb0...2a09a3891fde 15:17 < bitcoin-git> bitcoin/master 959dd87 practicalswift: Avoid printing incorrect block indexing time due to uninitialized variable... 15:17 < bitcoin-git> bitcoin/master 2a09a38 Pieter Wuille: Merge #10714: Avoid printing incorrect block indexing time due to uninitialized variable... 15:18 < bitcoin-git> [bitcoin] sipa closed pull request #10714: Avoid printing incorrect block indexing time due to uninitialized variable (master...avoid-uninitialized-nStart) https://github.com/bitcoin/bitcoin/pull/10714 15:18 < gmaxwell> sipa: danke. 15:20 < morcos> sipa: #10557 could be merged after another look 15:20 < gribble> https://github.com/bitcoin/bitcoin/issues/10557 | Make check to distinguish between orphan txs and old txs more efficient. by morcos · Pull Request #10557 · bitcoin/bitcoin · GitHub 15:21 -!- Deadhand [~deadhand@CPEf0f249a14e43-CMf0f249a14e40.cpe.net.cable.rogers.com] has quit [Ping timeout: 260 seconds] 15:22 -!- henrik_ [~henrik@62-243-108-58-static.dk.customer.tdc.net] has left #bitcoin-core-dev ["Farvel"] 15:26 -!- Deadhand [~deadhand@CPEf0f249a14e43-CMf0f249a14e40.cpe.net.cable.rogers.com] has joined #bitcoin-core-dev 15:30 -!- echonaut [~echonaut@46.101.192.134] has quit [Remote host closed the connection] 15:32 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has quit [Disconnected by services] 15:32 -!- Dizzle [~dizzle@108.171.182.16] has quit [Quit: Leaving...] 15:32 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 15:32 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 15:32 -!- echonaut [~echonaut@46.101.192.134] has joined #bitcoin-core-dev 15:34 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has joined #bitcoin-core-dev 15:35 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 251 seconds] 15:35 -!- haakonn [~haakonn@pdpc/supporter/active/haakonn] has quit [Remote host closed the connection] 15:35 -!- haakonn [~haakonn@146.185.155.218] has joined #bitcoin-core-dev 15:35 -!- asoltys [~adam@115.96.198.104.bc.googleusercontent.com] has quit [Remote host closed the connection] 15:35 -!- haakonn is now known as Guest92337 15:35 -!- asoltys [~adam@115.96.198.104.bc.googleusercontent.com] has joined #bitcoin-core-dev 15:38 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev 15:50 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 15:55 -!- Cheeseo [~Cheeseo@unaffiliated/cheeseo] has joined #bitcoin-core-dev 15:57 -!- Cheeseo [~Cheeseo@unaffiliated/cheeseo] has quit [Read error: Connection reset by peer] 15:57 -!- Cheeseo [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev 15:59 < sipa> cfields: using --enable-reduce-exports does not help 15:59 < cfields> sipa: damn, ok. thanks for trying 16:00 < sipa> COMMON="-O2 -flto"; ./configure CXXFLAGS="$COMMON" LDFLAGS="$COMMON" CFLAGS="$COMMON" AR=/usr/bin/gcc-ar NM=/usr/bin/gcc-nm RANLIB=/usr/bin/gcc-ranlib --with-incompatible-bdb --without-gui --enable-reduce-exports && make clean && make -j16 src/bitcoind && cp src/bitcoind src/bitcoind-master-O2-lto 16:00 < sipa> was the build command 16:00 < sipa> this is gcc 6.3.0 16:01 < cfields> ok 16:02 < cfields> i'll be curious to break out perf and see why it's slower 16:05 -!- kexkey [~kexkey@68.168.119.228] has joined #bitcoin-core-dev 16:06 -!- Cheeseo [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Ping timeout: 260 seconds] 16:30 -!- coredump_ [~quassel@vpn-qld171.vpnsolutions.com.au] has joined #bitcoin-core-dev 16:30 < bitcoin-git> [bitcoin] sipa pushed 13 new commits to master: https://github.com/bitcoin/bitcoin/compare/2a09a3891fde...479afa0f8486 16:30 < bitcoin-git> bitcoin/master e0451e3 Jeremy Rubin: Fix subscript[0] bug in net.cpp if GetGroup returns a 0-sized vector 16:30 < bitcoin-git> bitcoin/master 500710b Jeremy Rubin: Fix 2 subscript[0] bugs in pubkey.cpp, and eliminate one extra size check 16:30 < bitcoin-git> bitcoin/master 96f2119 Jeremy Rubin: Fix subscript[0] in compressor.cpp 16:30 < bitcoin-git> [bitcoin] sipa closed pull request #9804: Fixes subscript 0 (&var[0]) where should use (var.data()) instead. (master...fix-subscript-0) https://github.com/bitcoin/bitcoin/pull/9804 16:50 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 16:50 -!- marcoagner [~user@187.113.137.68] has quit [Ping timeout: 246 seconds] 16:51 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 16:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 16:52 -!- treebeardd [46249329@gateway/web/freenode/ip.70.36.147.41] has joined #bitcoin-core-dev 16:56 < gmaxwell> \O/ 16:57 -!- rockhouse [~rockhouse@h54110.upc-h.chello.nl] has quit [Ping timeout: 255 seconds] 17:00 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Remote host closed the connection] 17:01 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev 17:02 -!- marcoagner [~user@177.99.121.244] has joined #bitcoin-core-dev 17:05 -!- treebear_ [~treebeard@70-36-147-41.dsl.static.fusionbroadband.com] has joined #bitcoin-core-dev 17:08 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 17:35 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds] 17:38 -!- corebob [~drb@2a02:fe0:c150:1a00:8958:6277:6ca3:b2cf] has joined #bitcoin-core-dev 17:38 -!- lucianor [~lucianor@200.68.122.121] has quit [Ping timeout: 246 seconds] 17:39 -!- wasi [~wasi@gateway/tor-sasl/wasi] has quit [Ping timeout: 248 seconds] 17:42 < jtimon> random data point: as of height 475560, it takes 157.7 GB of storage (using -txindex) 17:42 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 248 seconds] 17:42 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev 17:45 -!- corebob [~drb@2a02:fe0:c150:1a00:8958:6277:6ca3:b2cf] has quit [Quit: corebob] 17:45 -!- corebob [~drb@2a02:fe0:c150:1a00:8958:6277:6ca3:b2cf] has joined #bitcoin-core-dev 17:46 -!- btcdrak [uid237747@gateway/web/irccloud.com/x-kxyfvfjpzlnglttn] has joined #bitcoin-core-dev 17:48 -!- robotpoop [~gares@94.242.249.117] has joined #bitcoin-core-dev 17:49 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 17:52 -!- robotpoop [~gares@94.242.249.117] has quit [Ping timeout: 240 seconds] 17:54 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #bitcoin-core-dev 17:59 -!- lucianor [~lucianor@200.68.122.122] has joined #bitcoin-core-dev 17:59 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com] 18:03 -!- treebeardd [46249329@gateway/web/freenode/ip.70.36.147.41] has quit [Quit: Page closed] 18:06 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 248 seconds] 18:10 -!- kexkey_ [~kexkey@173.209.61.61] has joined #bitcoin-core-dev 18:13 -!- kexkey [~kexkey@68.168.119.228] has quit [Ping timeout: 240 seconds] 18:13 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 260 seconds] 18:19 -!- jtimon [~quassel@102.30.134.37.dynamic.jazztel.es] has quit [Remote host closed the connection] 18:21 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.] 18:24 -!- robotpoop [~gares@94.242.249.117] has joined #bitcoin-core-dev 18:26 < bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/479afa0f8486...e4fcbf797ed3 18:26 < bitcoin-git> bitcoin/master 1e3a320 practicalswift: Simplify "!foo || (foo && bar)" as "!foo || bar" 18:26 < bitcoin-git> bitcoin/master e4fcbf7 Pieter Wuille: Merge #10780: Simplify "!foo || (foo && bar)" as "!foo || bar"... 18:26 < bitcoin-git> [bitcoin] sipa closed pull request #10780: Simplify "!foo || (foo && bar)" as "!foo || bar" (master...redundant-condition) https://github.com/bitcoin/bitcoin/pull/10780 18:29 -!- robotpoop [~gares@94.242.249.117] has quit [Ping timeout: 240 seconds] 18:37 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-core-dev 18:42 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 18:43 -!- jeremyru1in is now known as jeremyrubin 18:43 -!- ovovo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 18:47 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 240 seconds] 18:51 -!- ivan [~ivan@unaffiliated/ivan/x-000001] has joined #bitcoin-core-dev 18:57 -!- treebear_ [~treebeard@70-36-147-41.dsl.static.fusionbroadband.com] has quit [Remote host closed the connection] 19:03 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 19:03 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 248 seconds] 19:03 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 19:03 -!- kexkey_ is now known as kexkey 19:07 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-jqpxbhovzydzmiiv] has quit [Quit: Connection closed for inactivity] 19:20 -!- wasi [~wasi@gateway/tor-sasl/wasi] has quit [Ping timeout: 248 seconds] 19:29 -!- gielbier [~michiel@92-111-70-106.static.chello.nl] has quit [Ping timeout: 248 seconds] 19:30 -!- joelsbeard [~joel@c-24-5-163-171.hsd1.ca.comcast.net] has quit [Quit: Konversation terminated!] 19:34 -!- jtimon [~quassel@102.30.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 19:35 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #bitcoin-core-dev 19:36 -!- treebeardd [~treebeard@70-36-147-41.dsl.static.fusionbroadband.com] has joined #bitcoin-core-dev 19:42 -!- kexkey [~kexkey@173.209.61.61] has quit [Ping timeout: 246 seconds] 19:49 -!- olymagu [171efc76@gateway/web/freenode/ip.23.30.252.118] has joined #bitcoin-core-dev 19:53 -!- kexkey [~kexkey@68.168.119.230] has joined #bitcoin-core-dev 19:56 -!- olymagu [171efc76@gateway/web/freenode/ip.23.30.252.118] has quit [Ping timeout: 260 seconds] 19:59 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 20:00 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 20:17 -!- treebeardd [~treebeard@70-36-147-41.dsl.static.fusionbroadband.com] has quit [Remote host closed the connection] 20:19 -!- lucianor [~lucianor@200.68.122.122] has quit [Ping timeout: 260 seconds] 20:28 -!- neha [~narula@tbilisi.csail.mit.edu] has quit [Ping timeout: 240 seconds] 20:42 -!- jtimon [~quassel@102.30.134.37.dynamic.jazztel.es] has quit [Remote host closed the connection] 20:48 -!- lucianor [~lucianor@200.68.122.121] has joined #bitcoin-core-dev 21:07 -!- lucianor [~lucianor@200.68.122.121] has quit [Ping timeout: 255 seconds] 21:14 -!- corebob [~drb@2a02:fe0:c150:1a00:8958:6277:6ca3:b2cf] has quit [Quit: corebob] 21:15 -!- ovovo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 260 seconds] 21:19 -!- treebeardd [~treebeard@70-36-147-41.dsl.static.fusionbroadband.com] has joined #bitcoin-core-dev 21:20 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 21:29 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 255 seconds] 21:32 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev 21:50 -!- Soligor [~Soligor@unaffiliated/soligor] has joined #bitcoin-core-dev 21:54 -!- Alan_ [~textual@li1180-203.members.linode.com] has joined #bitcoin-core-dev 21:54 -!- Alan_ is now known as Guest14719 21:55 -!- Guest14719 [~textual@li1180-203.members.linode.com] has quit [Client Quit] 21:58 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Ping timeout: 260 seconds] 22:08 -!- cheese_ [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Ping timeout: 240 seconds] 22:16 -!- Giszmo [~leo@ip-225-233.219.201.nextelmovil.cl] has joined #bitcoin-core-dev 22:17 -!- Cheeseo [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev 22:18 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 22:20 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 22:24 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has quit [Ping timeout: 260 seconds] 22:30 -!- ivan [~ivan@unaffiliated/ivan/x-000001] has quit [Quit: lp0 on fire] 22:48 -!- Alan_ [~textual@li1180-203.members.linode.com] has joined #bitcoin-core-dev 22:48 -!- Alan_ is now known as Guest86032 22:49 -!- Guest86032 [~textual@li1180-203.members.linode.com] has left #bitcoin-core-dev [] 22:55 -!- Giszmo [~leo@ip-225-233.219.201.nextelmovil.cl] has quit [Ping timeout: 240 seconds] 22:56 -!- arowser [~quassel@45.32.248.113] has quit [Remote host closed the connection] 23:01 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 23:02 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 23:03 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-kndpibpfcebfxcjg] has joined #bitcoin-core-dev 23:05 -!- arowser [~quassel@45.32.248.113] has joined #bitcoin-core-dev 23:11 -!- Giszmo [~leo@ip-193-233.219.201.nextelmovil.cl] has joined #bitcoin-core-dev 23:21 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 23:25 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has quit [Ping timeout: 246 seconds] 23:38 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 260 seconds] 23:41 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev 23:49 -!- alan_baker [~alan_bake@li1180-203.members.linode.com] has joined #bitcoin-core-dev 23:52 -!- Giszmo [~leo@ip-193-233.219.201.nextelmovil.cl] has quit [Ping timeout: 248 seconds]