12017-07-12T00:02:54  *** AaronvanW has quit IRC
  22017-07-12T00:03:28  *** AaronvanW has joined #bitcoin-core-dev
  32017-07-12T00:05:27  *** Giszmo has quit IRC
  42017-07-12T00:14:08  *** AaronvanW has joined #bitcoin-core-dev
  52017-07-12T00:19:00  *** Murch has quit IRC
  62017-07-12T00:19:12  *** AaronvanW has quit IRC
  72017-07-12T00:23:52  *** Giszmo has joined #bitcoin-core-dev
  82017-07-12T00:37:30  *** Chris_Stewart_5 has joined #bitcoin-core-dev
  92017-07-12T00:42:40  *** chjj has quit IRC
 102017-07-12T00:49:11  *** btcdrak has quit IRC
 112017-07-12T00:55:05  *** chjj has joined #bitcoin-core-dev
 122017-07-12T01:30:22  <bitcoin-git> [bitcoin] TheBlueMatt opened pull request #10799: Prevent user from specifying conflicting parameters to fundrawtx (master...2017-07-no-fundraw-conflicts) https://github.com/bitcoin/bitcoin/pull/10799
 132017-07-12T01:39:02  *** dabura667 has joined #bitcoin-core-dev
 142017-07-12T01:44:01  *** gielbier has quit IRC
 152017-07-12T01:44:45  *** gielbier has joined #bitcoin-core-dev
 162017-07-12T01:48:13  *** chjj has quit IRC
 172017-07-12T01:49:15  *** Ylbam has quit IRC
 182017-07-12T01:50:38  *** Giszmo has quit IRC
 192017-07-12T01:51:34  *** cryptechonomics has joined #bitcoin-core-dev
 202017-07-12T01:52:11  *** cryptechonomics has left #bitcoin-core-dev
 212017-07-12T02:00:58  *** chjj has joined #bitcoin-core-dev
 222017-07-12T02:05:08  *** Giszmo has joined #bitcoin-core-dev
 232017-07-12T02:47:02  *** Murch has joined #bitcoin-core-dev
 242017-07-12T02:56:31  *** AaronvanW has joined #bitcoin-core-dev
 252017-07-12T02:56:57  *** Chris_Stewart_5 has quit IRC
 262017-07-12T02:57:50  *** chjj has quit IRC
 272017-07-12T03:01:23  *** AaronvanW has quit IRC
 282017-07-12T03:03:43  *** justanotheruser has quit IRC
 292017-07-12T03:10:51  *** chjj has joined #bitcoin-core-dev
 302017-07-12T03:28:20  *** dabura667 has quit IRC
 312017-07-12T03:36:39  *** justanotheruser has joined #bitcoin-core-dev
 322017-07-12T03:40:32  *** Giszmo has quit IRC
 332017-07-12T03:44:13  *** Murch has quit IRC
 342017-07-12T03:46:08  *** Murch has joined #bitcoin-core-dev
 352017-07-12T03:50:56  *** AaronvanW has joined #bitcoin-core-dev
 362017-07-12T03:52:55  *** chjj has quit IRC
 372017-07-12T03:55:08  *** AaronvanW has quit IRC
 382017-07-12T03:59:41  *** Giszmo has joined #bitcoin-core-dev
 392017-07-12T04:03:54  *** Giszmo has quit IRC
 402017-07-12T04:13:51  *** BashCo has quit IRC
 412017-07-12T04:14:30  *** BashCo has joined #bitcoin-core-dev
 422017-07-12T04:25:40  *** ivan has joined #bitcoin-core-dev
 432017-07-12T04:26:28  *** Murch has quit IRC
 442017-07-12T04:46:24  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 452017-07-12T04:52:35  *** Chris_Stewart_5 has quit IRC
 462017-07-12T05:03:24  <bitcoin-git> [bitcoin] theuni opened pull request #10800: build: add lto configure option (master...enable-lto) https://github.com/bitcoin/bitcoin/pull/10800
 472017-07-12T05:14:03  *** BashCo has quit IRC
 482017-07-12T05:14:38  *** BashCo has joined #bitcoin-core-dev
 492017-07-12T05:39:32  <achow101> someone please ban this guy: https://github.com/MIGUELWAXX he keeps spamming the repo
 502017-07-12T05:54:44  *** joelsbeard has joined #bitcoin-core-dev
 512017-07-12T06:33:13  *** AaronvanW has joined #bitcoin-core-dev
 522017-07-12T06:37:27  *** AaronvanW has quit IRC
 532017-07-12T06:48:05  *** jtimon has quit IRC
 542017-07-12T06:50:40  *** Dyaheon has quit IRC
 552017-07-12T06:52:14  *** Dyaheon has joined #bitcoin-core-dev
 562017-07-12T07:00:14  *** dermoth has quit IRC
 572017-07-12T07:01:35  *** dermoth has joined #bitcoin-core-dev
 582017-07-12T07:21:08  *** dabura667 has joined #bitcoin-core-dev
 592017-07-12T07:23:27  *** Cheeseo has quit IRC
 602017-07-12T07:31:45  *** coredump_ has quit IRC
 612017-07-12T07:32:06  *** Ylbam has joined #bitcoin-core-dev
 622017-07-12T07:38:35  *** laurentmt has joined #bitcoin-core-dev
 632017-07-12T07:41:22  *** promag has quit IRC
 642017-07-12T08:04:31  *** arowser has quit IRC
 652017-07-12T08:09:47  *** AaronvanW has joined #bitcoin-core-dev
 662017-07-12T08:10:44  *** arowser has joined #bitcoin-core-dev
 672017-07-12T08:16:32  *** laurentmt has quit IRC
 682017-07-12T08:32:43  *** Squidicc has joined #bitcoin-core-dev
 692017-07-12T08:36:08  *** Squidicuz has quit IRC
 702017-07-12T08:53:22  *** chjj has joined #bitcoin-core-dev
 712017-07-12T08:55:28  *** Dyaheon has quit IRC
 722017-07-12T08:56:55  *** timothy has joined #bitcoin-core-dev
 732017-07-12T08:57:26  *** Dyaheon has joined #bitcoin-core-dev
 742017-07-12T09:00:30  *** goatpig has joined #bitcoin-core-dev
 752017-07-12T09:16:52  *** BashCo has quit IRC
 762017-07-12T09:17:31  *** BashCo has joined #bitcoin-core-dev
 772017-07-12T09:38:01  *** unholymachine has quit IRC
 782017-07-12T09:42:40  *** unholymachine has joined #bitcoin-core-dev
 792017-07-12T09:45:45  <jonasschnelli> achow101: Have you reported him?
 802017-07-12T10:12:53  *** Aaronvan_ has joined #bitcoin-core-dev
 812017-07-12T10:14:04  *** AaronvanW has quit IRC
 822017-07-12T10:19:47  *** BashCo has quit IRC
 832017-07-12T10:26:22  *** Aaronvan_ has quit IRC
 842017-07-12T10:43:00  *** AaronvanW has joined #bitcoin-core-dev
 852017-07-12T10:46:23  <cdecker> I've been asked what my DNS seed policies are regarding BIP148, and I said that I will not filter non-UASF nodes
 862017-07-12T10:47:14  <cdecker> I guess that's the stance that the other operators will follow as well, or am I mistaken?
 872017-07-12T10:49:37  *** riemann has joined #bitcoin-core-dev
 882017-07-12T10:49:40  *** BashCo has joined #bitcoin-core-dev
 892017-07-12T11:18:56  <jonasschnelli> cdecker: Yes. I think the dns seed policy paper explicitly stats that...
 902017-07-12T11:18:58  <jonasschnelli> let me find it
 912017-07-12T11:19:11  <jonasschnelli> https://github.com/bitcoin/bitcoin/blob/57b34599b2deb179ff1bd97ffeab91ec9f904d85/doc/dnsseed-policy.md
 922017-07-12T11:19:21  <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.
 932017-07-12T11:20:08  <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...
 942017-07-12T11:20:23  <cdecker> Some people were arguing about the definition of functioning nodes is
 952017-07-12T11:20:51  <jonasschnelli> well,... until the chain split (and if), BIP148 and non BIP148 are functioning perfectly fine? not?
 962017-07-12T11:21:10  <cdecker> Right that's what I thought ^^
 972017-07-12T11:21:58  <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
 982017-07-12T11:22:15  <jonasschnelli> The seeds crawler is not tied to a full node
 992017-07-12T11:25:07  <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
1002017-07-12T11:25:44  <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
1012017-07-12T11:27:37  <luke-jr> so I don't suggest committing to not filtering non-UASF (ie, vulnerable) nodes
1022017-07-12T11:28:29  <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
1032017-07-12T11:29:30  <cdecker> luke-jr, I don't follow, you suggest against committing to something like this?
1042017-07-12T11:29:39  <luke-jr> cdecker: right
1052017-07-12T11:30:07  <luke-jr> in the worst case scenario, it may be necessary to protect light clients
1062017-07-12T11:30:24  <cdecker> I honestly don't see why, DNS seeds are infrastructure, not political tools
1072017-07-12T11:30:50  <cdecker> You mean having light clients flip-flop between the two forks
1082017-07-12T11:30:52  <luke-jr> cdecker: because light clients are inherently vulnerable
1092017-07-12T11:31:13  <luke-jr> they will follow any chain they see, no matter how invalid it is
1102017-07-12T11:31:17  <luke-jr> and unfortunately there are a lot of them
1112017-07-12T11:31:44  <jonasschnelli> luke-jr: not ultimatively
1122017-07-12T11:31:49  <luke-jr> jonasschnelli: ?
1132017-07-12T11:31:51  <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
1142017-07-12T11:32:01  <jonasschnelli> The light client i'm working on (based on core) does validate block size and SigOp counts, etc.
1152017-07-12T11:32:03  <cdecker> And that's what I'm committing to
1162017-07-12T11:32:11  <luke-jr> cdecker: that's the easiest way to detect vulnerable nodes
1172017-07-12T11:32:16  <jonasschnelli> light client with client side filtering can validate the "important" parameters
1182017-07-12T11:32:30  <jonasschnelli> just not with the BF stuff
1192017-07-12T11:32:36  <luke-jr> jonasschnelli: right, but those aren't the ones that stupidly connect to only seed nodes
1202017-07-12T11:34:31  <jonasschnelli> Yes. Those need protection...
1212017-07-12T11:34:33  <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
1222017-07-12T11:35:24  <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 :/
1232017-07-12T11:35:30  <luke-jr> they don't seem to even have BIP 9 code yet
1242017-07-12T11:45:10  *** ayy1337 has joined #bitcoin-core-dev
1252017-07-12T11:47:11  *** ayy1337 has left #bitcoin-core-dev
1262017-07-12T11:48:13  *** ayylmao has joined #bitcoin-core-dev
1272017-07-12T11:49:41  <cdecker> Ok, not making special provisions for a fork for now
1282017-07-12T12:06:59  *** coredump_ has joined #bitcoin-core-dev
1292017-07-12T12:20:55  <jonasschnelli> ryanofsky: in your deque<const CBlockIndex*> 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)
1302017-07-12T12:21:14  <jonasschnelli> hmm.. maybe just refill the queue... I see
1312017-07-12T12:22:32  *** chjj has quit IRC
1322017-07-12T12:24:04  *** belcher has quit IRC
1332017-07-12T12:25:43  *** Aaronvan_ has joined #bitcoin-core-dev
1342017-07-12T12:26:27  *** Aaronvan_ is now known as AaronvanW_
1352017-07-12T12:26:47  *** dabura667 has quit IRC
1362017-07-12T12:29:33  *** AaronvanW has quit IRC
1372017-07-12T12:32:20  *** AaronvanW_ is now known as AaronvanW
1382017-07-12T12:32:54  *** Guyver2 has joined #bitcoin-core-dev
1392017-07-12T12:39:38  *** wbnns_ has joined #bitcoin-core-dev
1402017-07-12T12:40:36  *** CodeShark_ has joined #bitcoin-core-dev
1412017-07-12T12:41:11  *** spinza has quit IRC
1422017-07-12T12:41:13  *** Guest89066 has quit IRC
1432017-07-12T12:41:19  *** TD--Linux has joined #bitcoin-core-dev
1442017-07-12T12:41:22  *** CodeShark has quit IRC
1452017-07-12T12:41:23  *** wbnns has quit IRC
1462017-07-12T12:41:23  *** TD-Linux has quit IRC
1472017-07-12T12:41:26  *** CodeShark_ is now known as CodeShark
1482017-07-12T12:41:32  *** wbnns_ is now known as wbnns
1492017-07-12T12:44:07  *** Dyaheon has quit IRC
1502017-07-12T12:45:06  *** Guest75836 has joined #bitcoin-core-dev
1512017-07-12T12:46:48  *** Dyaheon has joined #bitcoin-core-dev
1522017-07-12T12:52:09  *** belcher has joined #bitcoin-core-dev
1532017-07-12T13:01:26  *** spinza has joined #bitcoin-core-dev
1542017-07-12T13:08:15  *** Maxime2 has joined #bitcoin-core-dev
1552017-07-12T13:10:55  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1562017-07-12T13:10:56  *** coredump_ has quit IRC
1572017-07-12T13:12:09  *** coredump_ has joined #bitcoin-core-dev
1582017-07-12T13:20:25  *** Cheeseo has joined #bitcoin-core-dev
1592017-07-12T13:21:19  *** cheese_ has joined #bitcoin-core-dev
1602017-07-12T13:22:07  *** davec has quit IRC
1612017-07-12T13:24:50  *** Cheeseo has quit IRC
1622017-07-12T13:28:39  *** davec has joined #bitcoin-core-dev
1632017-07-12T13:28:55  *** AaronvanW has quit IRC
1642017-07-12T13:28:58  *** Aaronvan_ has joined #bitcoin-core-dev
1652017-07-12T13:31:05  *** schnerchi has quit IRC
1662017-07-12T13:35:51  *** wasi has joined #bitcoin-core-dev
1672017-07-12T13:36:33  *** schnerchi has joined #bitcoin-core-dev
1682017-07-12T13:44:36  <bitcoin-git> [bitcoin] jnewbery opened pull request #10802: [tests] skip zapwallettxes.py (master...skip_zapwallettxes) https://github.com/bitcoin/bitcoin/pull/10802
1692017-07-12T13:54:34  *** schnerchi has quit IRC
1702017-07-12T13:59:49  *** schnerchi has joined #bitcoin-core-dev
1712017-07-12T14:00:38  *** BashCo has quit IRC
1722017-07-12T14:01:37  *** BashCo has joined #bitcoin-core-dev
1732017-07-12T14:01:38  <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
1742017-07-12T14:13:55  *** promag has joined #bitcoin-core-dev
1752017-07-12T14:16:23  *** coredump_ has quit IRC
1762017-07-12T14:43:00  *** hydrat has joined #bitcoin-core-dev
1772017-07-12T14:43:55  *** hydrat has left #bitcoin-core-dev
1782017-07-12T14:45:12  *** PaulCapestany has quit IRC
1792017-07-12T14:49:01  *** PaulCapestany has joined #bitcoin-core-dev
1802017-07-12T14:49:46  <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?
1812017-07-12T14:57:27  <ryanofsky> i thought nat traversal was more for udp and tcp
1822017-07-12T14:57:33  <ryanofsky> udp than tcp
1832017-07-12T14:57:51  *** riemann has quit IRC
1842017-07-12T14:58:54  <BlueMatt> getting nat traversal to work with tcp means you need a userspace tcp impl, something we def dont want to get into
1852017-07-12T14:59:00  <BlueMatt> if it even works at all
1862017-07-12T15:01:26  <jonasschnelli> So UPnP is the best you can do without userspace tcp impl?
1872017-07-12T15:02:00  <BlueMatt> yes
1882017-07-12T15:02:00  <jonasschnelli> What about all these SIP NAT traversal solutions.. do they all have a userspace TCP implementation?
1892017-07-12T15:02:21  * jonasschnelli is looking at http://www.pjsip.org/pjnath/docs/html/index.htm right now
1902017-07-12T15:02:32  <BlueMatt> Sip does not use tcp if it needs nat traversal, no?
1912017-07-12T15:03:07  *** ayylmao has quit IRC
1922017-07-12T15:03:33  <jonasschnelli> I though SIP is using TCP for establishing... but not sure
1932017-07-12T15:04:32  <BlueMatt> it may, but you're not getting incoming tcp through nat
1942017-07-12T15:04:35  <BlueMatt> just not gonna happen
1952017-07-12T15:05:26  <jonasschnelli> Okay. Thanks BlueMatt.
1962017-07-12T15:06:26  <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..
1972017-07-12T15:06:47  <jonasschnelli> Are there any significant downsides using a std::map<uint256, const CBlockIndex*>?
1982017-07-12T15:07:03  <jonasschnelli> (and just erase the requested block when it's processed)
1992017-07-12T15:07:05  <ryanofsky> oh good point, yeah maybe you need a map or a list of lists
2002017-07-12T15:14:05  *** Aaronvan_ is now known as AaronvanW
2012017-07-12T15:24:59  *** Giszmo has joined #bitcoin-core-dev
2022017-07-12T15:25:51  *** Dizzle has joined #bitcoin-core-dev
2032017-07-12T15:26:05  <BlueMatt> cfields: wait, huh, --enable-lto only adds -flto? why not also specify ar/ranlib/nm as well automatically?
2042017-07-12T15:37:22  <jnewbery> jonasschnelli: in my experience providers often use SBCs to resolve NAT traversal
2052017-07-12T15:38:02  <ryanofsky> southern baptist conventions?
2062017-07-12T15:38:41  <jonasschnelli> hehe
2072017-07-12T15:38:58  <jonasschnelli> lookin it up
2082017-07-12T15:39:02  <jnewbery> SIP can go over TCP or UDP. TCP is more common in my experience
2092017-07-12T15:39:11  <jnewbery> Session Border Controller
2102017-07-12T15:42:04  <jonasschnelli> Going off-topic: but what's the best approach for a direct communication channel between two devices behind NAT without a centralized server?
2112017-07-12T15:42:44  <jonasschnelli> Using UDP (and your own error detection, etc protocol)?
2122017-07-12T15:44:08  *** Murch has joined #bitcoin-core-dev
2132017-07-12T15:44:39  <bitcoin-git> [bitcoin] promag opened pull request #10804: Add histunspent RPC (master...2017-07-rpc-add-histunspent) https://github.com/bitcoin/bitcoin/pull/10804
2142017-07-12T15:45:23  <jnewbery> STUN/ICE I believe, although it's not something I know much about
2152017-07-12T15:46:13  <jonasschnelli> thanks jnewbery. </offtopic>
2162017-07-12T15:46:56  <bitcoin-git> [bitcoin] janstary opened pull request #10805: have proper manpages for bitcoin*(1) (master...master) https://github.com/bitcoin/bitcoin/pull/10805
2172017-07-12T15:49:22  *** pandabull has joined #bitcoin-core-dev
2182017-07-12T15:50:21  <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
2192017-07-12T15:53:16  <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?)
2202017-07-12T15:54:44  <ryanofsky> i can check latest documentation, but i think all of boost::optional is deprecated now that std::optional exists
2212017-07-12T15:55:48  <TD--Linux> you can totally do TCP hole punching too
2222017-07-12T15:55:52  <TD--Linux> I don't know if ICE does it
2232017-07-12T16:01:14  <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)
2242017-07-12T16:04:49  *** promag has quit IRC
2252017-07-12T16:08:18  <morcos> ryanofsky: but not in the documentation anywhere right?
2262017-07-12T16:08:36  *** pandabull has quit IRC
2272017-07-12T16:08:42  <morcos> i'm fine with it if others are
2282017-07-12T16:10:29  <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
2292017-07-12T16:11:01  *** timothy has quit IRC
2302017-07-12T16:11:11  <phantomcircuit> jonasschnelli, some of the sip nat transversal is actually just proxying through random third party servers
2312017-07-12T16:15:03  <phantomcircuit> TD--Linux, iirc actually getting tcp hole punching to work is unreliable due to nat implementation variance
2322017-07-12T16:15:22  <phantomcircuit> you need to know the other peers report mapped source port for example
2332017-07-12T16:15:28  <phantomcircuit> which they may not even know
2342017-07-12T16:16:13  <BlueMatt> jonasschnelli: since you're here, whats up with #10650?
2352017-07-12T16:16:15  <gribble> https://github.com/bitcoin/bitcoin/issues/10650 | Multiwallet: add RPC endpoint support by jonasschnelli · Pull Request #10650 · bitcoin/bitcoin · GitHub
2362017-07-12T16:16:23  <BlueMatt> right now it looks like multiwallet is gonna miss 15 :(
2372017-07-12T16:17:02  <BlueMatt> or...were here
2382017-07-12T16:19:58  <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?
2392017-07-12T16:21:21  <BlueMatt> there are some easy-fix issues from my review
2402017-07-12T16:27:08  *** riemann has joined #bitcoin-core-dev
2412017-07-12T16:28:27  *** PaulCapestany has quit IRC
2422017-07-12T16:30:14  *** Aaronvan_ has joined #bitcoin-core-dev
2432017-07-12T16:31:01  *** AaronvanW has quit IRC
2442017-07-12T16:31:40  *** pandabull has joined #bitcoin-core-dev
2452017-07-12T16:35:01  <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
2462017-07-12T16:37:21  *** Dyaheon has quit IRC
2472017-07-12T16:37:34  *** Aaronvan_ is now known as AaronvanW
2482017-07-12T16:38:04  *** Dyaheon has joined #bitcoin-core-dev
2492017-07-12T16:52:53  *** TD--Linux is now known as TD-Linux
2502017-07-12T16:52:54  *** TD-Linux has joined #bitcoin-core-dev
2512017-07-12T17:02:51  <cfields> BlueMatt: uh, what AR/RANLIB to add?
2522017-07-12T17:03:21  <cfields> s/add/specify/
2532017-07-12T17:03:56  *** pandabull has quit IRC
2542017-07-12T17:06:52  <BlueMatt> cfields: dunno, my bash history says `which gcc-ar`
2552017-07-12T17:07:01  <BlueMatt> (and ranlib and nm)
2562017-07-12T17:07:21  <cfields> BlueMatt: and for arm? mingw?
2572017-07-12T17:07:28  <BlueMatt> no idea
2582017-07-12T17:07:35  <cfields> exactly :)
2592017-07-12T17:07:39  <cfields> they're per-toolchain
2602017-07-12T17:07:42  <BlueMatt> well at least do it for native :p
2612017-07-12T17:08:06  <BlueMatt> eg test $PREFIX-gcc-*, and if it fails, use $PREFIX-*
2622017-07-12T17:08:13  <cfields> not for clang, i believe
2632017-07-12T17:08:20  <sipa> my benchmark says that reindex with lto is significantly slower...
2642017-07-12T17:08:22  *** PaulCapestany has joined #bitcoin-core-dev
2652017-07-12T17:08:29  <sipa> both on -O2 and -O3
2662017-07-12T17:08:29  <BlueMatt> $CXX-* :p
2672017-07-12T17:09:16  <sipa> bitcoind-master-O2: 4977
2682017-07-12T17:09:16  <sipa> bitcoind-master-O3: 4815
2692017-07-12T17:09:16  <sipa> bitcoind-master-O2-lto: 5722
2702017-07-12T17:09:22  <sipa> bitcoind-master-O3-lto: 5577
2712017-07-12T17:09:30  <cfields> sipa: (relevant, i swear) did you ever bench the leveldb crc32 impact on reindex?
2722017-07-12T17:09:45  <sipa> cfields: no
2732017-07-12T17:10:08  <cfields> currently if you set cflags/cxxflags by hand, those end up disabled
2742017-07-12T17:10:14  <sipa> ugh
2752017-07-12T17:10:15  <cfields> pr is incoming
2762017-07-12T17:10:18  <BlueMatt> wtf
2772017-07-12T17:10:32  <sipa> that explains!
2782017-07-12T17:10:55  <cfields> BlueMatt: it's not clear what we should do in that case, though
2792017-07-12T17:11:16  <sipa> just add -msse4.2 to the CXXFLAGS for that?
2802017-07-12T17:11:19  <BlueMatt> cfields: i mean cant you do a two-object link test during configure?
2812017-07-12T17:11:20  <cfields> BlueMatt: consider: ./configure CXXFLAGS="-O2 -march=i686"
2822017-07-12T17:11:28  <cfields> BlueMatt: yea, that's the pr
2832017-07-12T17:11:29  <BlueMatt> ohoh, sorry, wrong thing
2842017-07-12T17:11:45  <sipa> it also means crcing is hugely significant...
2852017-07-12T17:11:54  <BlueMatt> sipa: didnt we know that, though?
2862017-07-12T17:12:01  <cfields> sipa: er no, that won't do what you want. That'll enable msse4.2 everywhere
2872017-07-12T17:12:07  <BlueMatt> i though i saw benchmarks from you or so that indicated the crc improvements helped a ton previously
2882017-07-12T17:12:35  <sipa> cfields: oh, the link-time flags are what matters?
2892017-07-12T17:13:12  <cfields> sipa: actually, that's a good question...
2902017-07-12T17:13:16  <sipa> BlueMatt: i didn't know they were 20% of our cpu usage...
2912017-07-12T17:13:30  <cfields> I would hope it's smart enought to remember per-object flags?
2922017-07-12T17:13:56  <sipa> cfields: i would hope so to, but if not, that doesn't explain why lto is slower
2932017-07-12T17:14:08  <BlueMatt> cfields: no? why would it be?
2942017-07-12T17:14:17  <cfields> sipa: anyway, please try with #10800 instead. Then you don't need to set your own flags
2952017-07-12T17:14:18  <gribble> https://github.com/bitcoin/bitcoin/issues/10800 | build: add lto configure option by theuni · Pull Request #10800 · bitcoin/bitcoin · GitHub
2962017-07-12T17:14:30  <BlueMatt> i dont think it is, i mean for some flags sure, but mostly i would expect only link-time flags to matter
2972017-07-12T17:14:37  <cfields> BlueMatt: so that we can enable instructions for only certain objects (after they've been cpuid checked)
2982017-07-12T17:15:02  <sipa> cfields: all of my numbers are with -O2/-O3 -lfo/"" set explicitly for CFLAGS/CXXFLAGS/LDFLAGS
2992017-07-12T17:15:17  <sipa> so if overriding flags is bad, it would be bad for all 4 benchmarks
3002017-07-12T17:15:22  <BlueMatt> yes, point is I'd assume that would only work on non-lto, or might otherwise confuse ld
3012017-07-12T17:16:14  <cfields> BlueMatt: i'd expect the opposite to avoid segfaults all over the place :)
3022017-07-12T17:16:19  <cfields> time to google and find out
3032017-07-12T17:16:29  <gmaxwell> BlueMatt: hm lto should be fine with mixed cflags.
3042017-07-12T17:16:43  <BlueMatt> gmaxwell: mixed clfags maybe, but mixed -march?
3052017-07-12T17:16:52  <gmaxwell> (w gcc you can even use pragma to change march on a function by function basis)
3062017-07-12T17:16:58  <BlueMatt> true
3072017-07-12T17:17:15  <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)
3082017-07-12T17:17:17  <gribble> https://github.com/bitcoin/bitcoin/issues/10711 | [tests] Introduce TestNode by jnewbery · Pull Request #10711 · bitcoin/bitcoin · GitHub
3092017-07-12T17:17:31  <cfields> sipa: ok, so it's a level playing field i guess, if i understand your setup correctly
3102017-07-12T17:18:36  <BlueMatt> yea, i mean i could see lto being slower, but that seems like a lot slower
3112017-07-12T17:19:01  <BlueMatt> in other news, any other for-15 stuff that needs review?
3122017-07-12T17:19:04  <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
3132017-07-12T17:19:20  <cfields> sipa: also, are you using gcc-ar/ranlib-ar? Or at least verifying that you're not linking fat objects?
3142017-07-12T17:19:56  <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
3152017-07-12T17:20:23  <BlueMatt> oh, #10758 needs a 15 tag
3162017-07-12T17:20:24  <gribble> https://github.com/bitcoin/bitcoin/issues/10758 | Fix some chainstate-init-order bugs. by TheBlueMatt · Pull Request #10758 · bitcoin/bitcoin · GitHub
3172017-07-12T17:20:27  <cfields> perfect, thanks
3182017-07-12T17:21:02  <cfields> so, thoughts on how to handle the flags overriding there?
3192017-07-12T17:21:50  *** pandabull has joined #bitcoin-core-dev
3202017-07-12T17:22:03  <cfields> it's very unexpected imo that crc32 would be disabled simply by setting CXXFLAGS="-O3"
3212017-07-12T17:22:16  <gmaxwell> cfields: for the leveldb stuff it should just append -msse4.2 to whatever cflags it gets.
3222017-07-12T17:22:17  <sipa> cfields: i can fix that in an ugly way :)
3232017-07-12T17:22:27  <gmaxwell> (for the test and the file)
3242017-07-12T17:22:36  * sipa is a fan of inline asm
3252017-07-12T17:22:48  *** RubenSomsen has joined #bitcoin-core-dev
3262017-07-12T17:22:56  <cfields> gmaxwell: what if cflags is "-O2 -march=i686" ?
3272017-07-12T17:23:05  <gmaxwell> sipa: using the byte sequences is pretty ugly, and otherwise you still need the -msse4.2
3282017-07-12T17:23:15  <gmaxwell> cfields: then that will fail, the test will fail, and it will turn it off.
3292017-07-12T17:23:37  *** RubenSomsen has quit IRC
3302017-07-12T17:23:49  <sipa> gmaxwell: yes indeed, that's why it's ugly :)
3312017-07-12T17:23:58  *** Murch has quit IRC
3322017-07-12T17:24:02  <gmaxwell> Why is that ugly, it's what the test is for!
3332017-07-12T17:24:04  *** RubenSomsen has joined #bitcoin-core-dev
3342017-07-12T17:24:23  <gmaxwell> (I mean the configure test to find out if compiling with -msse4.2)
3352017-07-12T17:24:27  <sipa> gmaxwell: i mean using byte sequences is ugly
3362017-07-12T17:24:52  <sipa> ... but it solves everything
3372017-07-12T17:25:35  *** pandabull has quit IRC
3382017-07-12T17:26:10  *** pandabull has joined #bitcoin-core-dev
3392017-07-12T17:26:27  <cfields> gmaxwell: yes, that works
3402017-07-12T17:26:48  <gmaxwell> sipa: I'm not opposed, esp for single instructions... but ugh
3412017-07-12T17:26:50  <cfields> sipa: i think i agree
3422017-07-12T17:27:35  <sipa> FWIW, i do not find any crc instructions in disassemblies of my benchmark binaries
3432017-07-12T17:27:44  <sipa> so at least the comparison is fair
3442017-07-12T17:28:14  <sipa> ... and lto actually slows things down? :(
3452017-07-12T17:28:46  <cfields> strange
3462017-07-12T17:29:50  <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
3472017-07-12T17:30:04  <sipa> gmaxwell: i'm not using -march=native
3482017-07-12T17:30:08  <sipa> just -O2"
3492017-07-12T17:30:16  <gmaxwell> sipa: cool so if we fix that perhaps we'll finally get it under 1hr with sha-ni. :P
3502017-07-12T17:30:26  <sipa> just "-O2", "-O3", "-O2 -flto", "-O3 -flto"
3512017-07-12T17:31:08  <cfields> gmaxwell: ^^ pr fixes -march=native
3522017-07-12T17:35:17  <gmaxwell> perhaps we could add some logging if crc32 instruction is in use. (and same for other accelerators later)
3532017-07-12T17:35:34  <gmaxwell> e.g. is leveldb's detect function exported
3542017-07-12T17:36:28  <cfields> no
3552017-07-12T17:36:58  <gmaxwell> grr
3562017-07-12T17:38:00  <cfields> oh that reminds me, i need to finish fixing their detection
3572017-07-12T17:50:31  *** jtimon has joined #bitcoin-core-dev
3582017-07-12T17:52:27  *** marcoagner has joined #bitcoin-core-dev
3592017-07-12T17:59:27  *** laurentmt has joined #bitcoin-core-dev
3602017-07-12T18:03:02  *** pandabull has quit IRC
3612017-07-12T18:06:07  *** Giszmo has quit IRC
3622017-07-12T18:07:20  *** laurentmt has quit IRC
3632017-07-12T18:07:30  *** JackH has joined #bitcoin-core-dev
3642017-07-12T18:24:40  <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
3652017-07-12T18:25:07  <sipa> try putting [] around the ip
3662017-07-12T18:25:47  <jnewbery> i've tried all the permutations ::1 [::1] "::1" "[::1]"
3672017-07-12T18:30:00  <sipa> hmm
3682017-07-12T18:30:17  <jnewbery> There's #1827 but that's ancient and before libevent
3692017-07-12T18:30:18  <gribble> https://github.com/bitcoin/bitcoin/issues/1827 | HTTP client needs IPv6 support · Issue #1827 · bitcoin/bitcoin · GitHub
3702017-07-12T18:30:36  <cfields> jnewbery: sure you're listening on ipv6 too?
3712017-07-12T18:31:45  <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
3722017-07-12T18:32:58  <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
3732017-07-12T18:34:35  <arubi> jnewbery, I have vague memory I also had to specify the port with ipv6, but that was a while ago..
3742017-07-12T18:34:35  <arubi> not sure if you already did
3752017-07-12T18:35:24  <jnewbery> arubi: yes - port is specified
3762017-07-12T18:36:12  <jnewbery> Does that mean you were able to use bitcoin-cli with ipv6?
3772017-07-12T18:37:04  <cfields> jnewbery: what libevent version?
3782017-07-12T18:37:37  <arubi> it was a while ago, I didn't mess with it too much so might just be bitcoind related and not -cli
3792017-07-12T18:38:38  <arubi> it might have been -rpcbind, sorry for the confusion
3802017-07-12T18:38:43  <jnewbery> cfields: what's the quickest way to find out?
3812017-07-12T18:39:12  <jnewbery> arubi: yeah bitcoin-cli over ipv6 seems pretty niche. Can't imagine many people use it
3822017-07-12T18:40:15  <cfields> jnewbery: grep _EVENT_NUMERIC_VERSION /usr/include/event2/event-config.h
3832017-07-12T18:41:42  <bitcoin-git> [bitcoin] instagibbs opened pull request #10807: getbalance example covers at least 6 confirms (master...getbalexample) https://github.com/bitcoin/bitcoin/pull/10807
3842017-07-12T18:42:09  <cfields> jnewbery: I've been trying to track down when this bug was fixed, looks like it was never backported to 2.0.x :(
3852017-07-12T18:42:19  <cfields> jnewbery: https://github.com/libevent/libevent/commit/71e709c7829275a594f767b27468b1b52e8b5bb9
3862017-07-12T18:42:31  <jnewbery> #define _EVENT_NUMERIC_VERSION 0x02001500
3872017-07-12T18:47:18  *** Giszmo has joined #bitcoin-core-dev
3882017-07-12T18:47:21  <cfields> hmm, looks like it should be fixed there
3892017-07-12T18:48:12  <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
3902017-07-12T18:53:03  <jnewbery> cfields: are you sure? https://github.com/libevent/libevent/blob/64177777165d9684bafbfa946abd126f7ebff11f/http.c#L2192
3912017-07-12T18:53:30  <jnewbery> That's v2.0.21
3922017-07-12T18:53:50  <cfields> jnewbery: I believe that 0x02001500 is 2.1.5beta
3932017-07-12T18:54:52  <jnewbery> Not quite. Here's 2.1.5beta: https://github.com/libevent/libevent/blob/release-2.1.5-beta/configure.ac#L17
3942017-07-12T18:55:00  <jnewbery> 0x02010500
3952017-07-12T18:55:23  <cfields> ah, heh
3962017-07-12T18:55:39  <cfields> i'd guess that's the problem, then
3972017-07-12T18:55:46  <cfields> you can try a depends build to verify
3982017-07-12T18:56:09  <jnewbery> I'll try that. Thanks!
3992017-07-12T18:56:48  <cfields> np
4002017-07-12T19:15:03  *** ivan has quit IRC
4012017-07-12T19:19:54  *** ula has joined #bitcoin-core-dev
4022017-07-12T19:37:39  *** rhavar has quit IRC
4032017-07-12T19:42:47  *** lucianor has joined #bitcoin-core-dev
4042017-07-12T19:50:10  <cfields> sipa: i'd be curious to know if --enable-reduce-exports changes your lto results any
4052017-07-12T19:50:45  <sipa> cfields: let's try!
4062017-07-12T19:52:07  <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
4072017-07-12T19:52:40  *** RubenSomsen has quit IRC
4082017-07-12T19:55:44  <sipa> cfields: rebuilding
4092017-07-12T20:01:55  *** AaronvanW has quit IRC
4102017-07-12T20:04:37  *** jtimon has quit IRC
4112017-07-12T20:05:25  *** AaronvanW has joined #bitcoin-core-dev
4122017-07-12T20:12:51  *** promag has joined #bitcoin-core-dev
4132017-07-12T20:23:53  <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.
4142017-07-12T20:23:56  <gribble> https://github.com/bitcoin/bitcoin/issues/8501 | Add mempool statistics collector by jonasschnelli · Pull Request #8501 · bitcoin/bitcoin · GitHub
4152017-07-12T20:24:18  <jonasschnelli> morcos: no hurry. Will not be in 0.15.
4162017-07-12T20:24:35  <morcos> oops. sorry!
4172017-07-12T20:40:07  <morcos> #10235 should be tagged 0.15 please
4182017-07-12T20:40:09  <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
4192017-07-12T20:40:17  <BlueMatt> or just merged, at this point
4202017-07-12T20:40:40  <morcos> or tagged and merged so it looks like we are making more progress  :)
4212017-07-12T20:40:50  <BlueMatt> lol, that too
4222017-07-12T20:43:45  *** Dyaheon has quit IRC
4232017-07-12T20:43:52  *** Giszmo has quit IRC
4242017-07-12T20:45:07  *** Chris_Stewart_5 has quit IRC
4252017-07-12T20:46:24  *** Dyaheon has joined #bitcoin-core-dev
4262017-07-12T20:46:39  *** Giszmo has joined #bitcoin-core-dev
4272017-07-12T20:52:41  <bitcoin-git> [bitcoin] theuni opened pull request #10809: optim: mark a few classes final (master...final-classes) https://github.com/bitcoin/bitcoin/pull/10809
4282017-07-12T21:00:07  *** jtimon has joined #bitcoin-core-dev
4292017-07-12T21:20:24  *** BashCo has quit IRC
4302017-07-12T21:21:01  *** BashCo has joined #bitcoin-core-dev
4312017-07-12T21:25:25  *** abpa has joined #bitcoin-core-dev
4322017-07-12T21:25:31  <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
4332017-07-12T21:46:34  <gmaxwell> cfields: how much would it make you hate life to adjust our build system so that leveldb stops getting build with -Wsign-compare
4342017-07-12T21:46:51  <gmaxwell> soo tired of that one warning...
4352017-07-12T21:48:47  <BlueMatt> lol
4362017-07-12T21:48:54  <BlueMatt> cant we just patch it?
4372017-07-12T21:51:43  <cfields> gmaxwell: heh. I'm with BlueMatt on that one :)
4382017-07-12T21:51:58  <BlueMatt> dont we already carry leveldb patches?
4392017-07-12T21:52:07  <sipa> cfields: ack, fix it in bitcoin-core/leveldb
4402017-07-12T21:54:21  <morcos> I think #10604 should also go in for 0.15 (needs milestone) assuming #10650 makes it
4412017-07-12T21:54:23  <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
4422017-07-12T21:54:24  <gribble> https://github.com/bitcoin/bitcoin/issues/10650 | Multiwallet: add RPC endpoint support by jonasschnelli · Pull Request #10650 · bitcoin/bitcoin · GitHub
4432017-07-12T21:56:26  <gmaxwell> or that
4442017-07-12T21:57:09  <sipa> just merged https://github.com/bitcoin-core/leveldb/pull/2
4452017-07-12T21:57:23  <sipa> we should include that change up into the bitcoin core subtree for 0.15
4462017-07-12T21:57:38  <sipa> but if we get some signedness fixes in too, even better
4472017-07-12T21:58:14  <BlueMatt> NICE
4482017-07-12T21:58:17  <BlueMatt> yes, lets do that (for 15)
4492017-07-12T21:59:54  *** BashCo has quit IRC
4502017-07-12T22:00:05  <sipa> go open a pr
4512017-07-12T22:00:31  *** BashCo has joined #bitcoin-core-dev
4522017-07-12T22:02:43  <instagibbs> 10604 makes sense regardless, and is really easy to review
4532017-07-12T22:05:35  *** chjj has joined #bitcoin-core-dev
4542017-07-12T22:06:10  <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
4552017-07-12T22:07:21  *** riemann has quit IRC
4562017-07-12T22:07:43  *** Soligor has quit IRC
4572017-07-12T22:09:33  *** henrik_ has joined #bitcoin-core-dev
4582017-07-12T22:09:58  <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
4592017-07-12T22:13:12  <gmaxwell> sipa: plz2merge 10714
4602017-07-12T22:13:50  <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?
4612017-07-12T22:17:34  <sipa> other things that need merging?
4622017-07-12T22:17:47  <BlueMatt> <morcos> #10235 should be tagged 0.15 please
4632017-07-12T22:17:47  <BlueMatt> <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
4642017-07-12T22:17:47  <BlueMatt> <BlueMatt> or just merged, at this point
4652017-07-12T22:17:48  <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
4662017-07-12T22:17:50  <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
4672017-07-12T22:17:51  <bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e8b95239eeb0...2a09a3891fde
4682017-07-12T22:17:51  <bitcoin-git> bitcoin/master 959dd87 practicalswift: Avoid printing incorrect block indexing time due to uninitialized variable...
4692017-07-12T22:17:52  <bitcoin-git> bitcoin/master 2a09a38 Pieter Wuille: Merge #10714: Avoid printing incorrect block indexing time due to uninitialized variable...
4702017-07-12T22:18:23  <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
4712017-07-12T22:18:51  <gmaxwell> sipa: danke.
4722017-07-12T22:20:18  <morcos> sipa: #10557 could be merged after another look
4732017-07-12T22:20:19  <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
4742017-07-12T22:21:16  *** Deadhand has quit IRC
4752017-07-12T22:22:07  *** henrik_ has left #bitcoin-core-dev
4762017-07-12T22:26:49  *** Deadhand has joined #bitcoin-core-dev
4772017-07-12T22:30:16  *** echonaut has quit IRC
4782017-07-12T22:34:01  *** lightningbot has joined #bitcoin-core-dev
4792017-07-12T22:35:03  *** Dyaheon has quit IRC
4802017-07-12T22:35:18  *** haakonn has quit IRC
4812017-07-12T22:35:25  *** haakonn has joined #bitcoin-core-dev
4822017-07-12T22:35:35  *** asoltys has quit IRC
4832017-07-12T22:35:48  *** haakonn is now known as Guest92337
4842017-07-12T22:35:50  *** asoltys has joined #bitcoin-core-dev
4852017-07-12T22:38:00  *** Dyaheon has joined #bitcoin-core-dev
4862017-07-12T22:50:29  *** Murch has joined #bitcoin-core-dev
4872017-07-12T22:55:12  *** Cheeseo has joined #bitcoin-core-dev
4882017-07-12T22:57:20  *** Cheeseo has quit IRC
4892017-07-12T22:57:36  *** Cheeseo has joined #bitcoin-core-dev
4902017-07-12T22:59:40  <sipa> cfields: using --enable-reduce-exports does not help
4912017-07-12T22:59:57  <cfields> sipa: damn, ok. thanks for trying
4922017-07-12T23:00:12  <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
4932017-07-12T23:00:21  <sipa> was the build command
4942017-07-12T23:00:55  <sipa> this is gcc 6.3.0
4952017-07-12T23:01:44  <cfields> ok
4962017-07-12T23:02:01  <cfields> i'll be curious to break out perf and see why it's slower
4972017-07-12T23:05:04  *** kexkey has joined #bitcoin-core-dev
4982017-07-12T23:06:32  *** Cheeseo has quit IRC
4992017-07-12T23:30:09  *** coredump_ has joined #bitcoin-core-dev
5002017-07-12T23:30:17  <bitcoin-git> [bitcoin] sipa pushed 13 new commits to master: https://github.com/bitcoin/bitcoin/compare/2a09a3891fde...479afa0f8486
5012017-07-12T23:30:18  <bitcoin-git> bitcoin/master e0451e3 Jeremy Rubin: Fix subscript[0] bug in net.cpp if GetGroup returns a 0-sized vector
5022017-07-12T23:30:18  <bitcoin-git> bitcoin/master 500710b Jeremy Rubin: Fix 2 subscript[0] bugs in pubkey.cpp, and eliminate one extra size check
5032017-07-12T23:30:19  <bitcoin-git> bitcoin/master 96f2119 Jeremy Rubin: Fix subscript[0] in compressor.cpp
5042017-07-12T23:30:27  <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
5052017-07-12T23:50:06  *** Aaronvan_ has joined #bitcoin-core-dev
5062017-07-12T23:50:58  *** marcoagner has quit IRC
5072017-07-12T23:51:25  *** Guyver2 has quit IRC
5082017-07-12T23:51:40  *** AaronvanW has quit IRC
5092017-07-12T23:52:46  *** treebeardd has joined #bitcoin-core-dev
5102017-07-12T23:56:01  <gmaxwell> \O/
5112017-07-12T23:57:54  *** rockhouse has quit IRC