1 2017-07-12 01:30:23	0|bitcoin-git|[13bitcoin] 15TheBlueMatt opened pull request #10799: Prevent user from specifying conflicting parameters to fundrawtx (06master...062017-07-no-fundraw-conflicts) 02https://github.com/bitcoin/bitcoin/pull/10799
  2 2017-07-12 05:03:25	0|bitcoin-git|[13bitcoin] 15theuni opened pull request #10800: build: add lto configure option (06master...06enable-lto) 02https://github.com/bitcoin/bitcoin/pull/10800
  3 2017-07-12 05:39:33	0|achow101|someone please ban this guy: https://github.com/MIGUELWAXX he keeps spamming the repo
  4 2017-07-12 09:45:46	0|jonasschnelli|achow101: Have you reported him?
  5 2017-07-12 10:46:23	0|cdecker|I've been asked what my DNS seed policies are regarding BIP148, and I said that I will not filter non-UASF nodes
  6 2017-07-12 10:47:15	0|cdecker|I guess that's the stance that the other operators will follow as well, or am I mistaken?
  7 2017-07-12 11:18:57	0|jonasschnelli|cdecker: Yes. I think the dns seed policy paper explicitly stats that...
  8 2017-07-12 11:18:58	0|jonasschnelli|let me find it
  9 2017-07-12 11:19:12	0|jonasschnelli|https://github.com/bitcoin/bitcoin/blob/57b34599b2deb179ff1bd97ffeab91ec9f904d85/doc/dnsseed-policy.md
 10 2017-07-12 11:19:22	0|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.
 11 2017-07-12 11:20:09	0|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...
 12 2017-07-12 11:20:23	0|cdecker|Some people were arguing about the definition of functioning nodes is
 13 2017-07-12 11:20:52	0|jonasschnelli|well,... until the chain split (and if), BIP148 and non BIP148 are functioning perfectly fine? not?
 14 2017-07-12 11:21:10	0|cdecker|Right that's what I thought ^^
 15 2017-07-12 11:21:58	0|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
 16 2017-07-12 11:22:15	0|jonasschnelli|The seeds crawler is not tied to a full node
 17 2017-07-12 11:25:08	0|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
 18 2017-07-12 11:25:45	0|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
 19 2017-07-12 11:27:38	0|luke-jr|so I don't suggest committing to not filtering non-UASF (ie, vulnerable) nodes
 20 2017-07-12 11:28:30	0|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
 21 2017-07-12 11:29:30	0|cdecker|luke-jr, I don't follow, you suggest against committing to something like this?
 22 2017-07-12 11:29:40	0|luke-jr|cdecker: right
 23 2017-07-12 11:30:08	0|luke-jr|in the worst case scenario, it may be necessary to protect light clients
 24 2017-07-12 11:30:25	0|cdecker|I honestly don't see why, DNS seeds are infrastructure, not political tools
 25 2017-07-12 11:30:51	0|cdecker|You mean having light clients flip-flop between the two forks
 26 2017-07-12 11:30:53	0|luke-jr|cdecker: because light clients are inherently vulnerable
 27 2017-07-12 11:31:14	0|luke-jr|they will follow any chain they see, no matter how invalid it is
 28 2017-07-12 11:31:18	0|luke-jr|and unfortunately there are a lot of them
 29 2017-07-12 11:31:44	0|jonasschnelli|luke-jr: not ultimatively
 30 2017-07-12 11:31:50	0|luke-jr|jonasschnelli: ?
 31 2017-07-12 11:31:51	0|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
 32 2017-07-12 11:32:01	0|jonasschnelli|The light client i'm working on (based on core) does validate block size and SigOp counts, etc.
 33 2017-07-12 11:32:03	0|cdecker|And that's what I'm committing to
 34 2017-07-12 11:32:12	0|luke-jr|cdecker: that's the easiest way to detect vulnerable nodes
 35 2017-07-12 11:32:17	0|jonasschnelli|light client with client side filtering can validate the "important" parameters
 36 2017-07-12 11:32:30	0|jonasschnelli|just not with the BF stuff
 37 2017-07-12 11:32:37	0|luke-jr|jonasschnelli: right, but those aren't the ones that stupidly connect to only seed nodes
 38 2017-07-12 11:34:32	0|jonasschnelli|Yes. Those need protection...
 39 2017-07-12 11:34:33	0|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
 40 2017-07-12 11:35:25	0|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 :/
 41 2017-07-12 11:35:31	0|luke-jr|they don't seem to even have BIP 9 code yet
 42 2017-07-12 11:49:42	0|cdecker|Ok, not making special provisions for a fork for now
 43 2017-07-12 12:20:56	0|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)
 44 2017-07-12 12:21:15	0|jonasschnelli|hmm.. maybe just refill the queue... I see
 45 2017-07-12 13:44:37	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #10802: [tests] skip zapwallettxes.py (06master...06skip_zapwallettxes) 02https://github.com/bitcoin/bitcoin/pull/10802
 46 2017-07-12 14:01:39	0|bitcoin-git|[13bitcoin] 15pstratem opened pull request #10803: Explicitly search for bdb5.3. (06master...062017-07-02-bdb5.3) 02https://github.com/bitcoin/bitcoin/pull/10803
 47 2017-07-12 14:49:46	0|jonasschnelli|Currently exploring nat traversal for a different project. Was ICE (1,0ICE: Interactive Connectivity Establishment) or STUN ever considered for Core and if now, why?
 48 2017-07-12 14:57:28	0|ryanofsky|i thought nat traversal was more for udp and tcp
 49 2017-07-12 14:57:34	0|ryanofsky|udp than tcp
 50 2017-07-12 14:58:55	0|BlueMatt|getting nat traversal to work with tcp means you need a userspace tcp impl, something we def dont want to get into
 51 2017-07-12 14:59:01	0|BlueMatt|if it even works at all
 52 2017-07-12 15:01:27	0|jonasschnelli|So UPnP is the best you can do without userspace tcp impl?
 53 2017-07-12 15:02:00	0|BlueMatt|yes
 54 2017-07-12 15:02:01	0|jonasschnelli|What about all these SIP NAT traversal solutions.. do they all have a userspace TCP implementation?
 55 2017-07-12 15:02:33	0|BlueMatt|Sip does not use tcp if it needs nat traversal, no?
 56 2017-07-12 15:03:34	0|jonasschnelli|I though SIP is using TCP for establishing... but not sure
 57 2017-07-12 15:04:33	0|BlueMatt|it may, but you're not getting incoming tcp through nat
 58 2017-07-12 15:04:36	0|BlueMatt|just not gonna happen
 59 2017-07-12 15:05:27	0|jonasschnelli|Okay. Thanks BlueMatt.
 60 2017-07-12 15:06:27	0|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..
 61 2017-07-12 15:06:48	0|jonasschnelli|Are there any significant downsides using a std::map<uint256, const CBlockIndex*>?
 62 2017-07-12 15:07:04	0|jonasschnelli|(and just erase the requested block when it's processed)
 63 2017-07-12 15:07:06	0|ryanofsky|oh good point, yeah maybe you need a map or a list of lists
 64 2017-07-12 15:26:06	0|BlueMatt|cfields: wait, huh, --enable-lto only adds -flto? why not also specify ar/ranlib/nm as well automatically?
 65 2017-07-12 15:37:23	0|jnewbery|jonasschnelli: in my experience providers often use SBCs to resolve NAT traversal
 66 2017-07-12 15:38:02	0|ryanofsky|southern baptist conventions?
 67 2017-07-12 15:38:41	0|jonasschnelli|hehe
 68 2017-07-12 15:38:59	0|jonasschnelli|lookin it up
 69 2017-07-12 15:39:03	0|jnewbery|SIP can go over TCP or UDP. TCP is more common in my experience
 70 2017-07-12 15:39:11	0|jnewbery|Session Border Controller
 71 2017-07-12 15:42:05	0|jonasschnelli|Going off-topic: but what's the best approach for a direct communication channel between two devices behind NAT without a centralized server?
 72 2017-07-12 15:42:45	0|jonasschnelli|Using UDP (and your own error detection, etc protocol)?
 73 2017-07-12 15:44:39	0|bitcoin-git|[13bitcoin] 15promag opened pull request #10804: Add histunspent RPC (06master...062017-07-rpc-add-histunspent) 02https://github.com/bitcoin/bitcoin/pull/10804
 74 2017-07-12 15:45:24	0|jnewbery|STUN/ICE I believe, although it's not something I know much about
 75 2017-07-12 15:46:14	0|jonasschnelli|thanks jnewbery. </offtopic>
 76 2017-07-12 15:46:57	0|bitcoin-git|[13bitcoin] 15janstary opened pull request #10805: have proper manpages for bitcoin*(1) (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/10805
 77 2017-07-12 15:50:21	0|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
 78 2017-07-12 15:53:17	0|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?)
 79 2017-07-12 15:54:45	0|ryanofsky|i can check latest documentation, but i think all of boost::optional is deprecated now that std::optional exists
 80 2017-07-12 15:55:49	0|TD--Linux|you can totally do TCP hole punching too
 81 2017-07-12 15:55:53	0|TD--Linux|I don't know if ICE does it
 82 2017-07-12 16:01:14	0|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)
 83 2017-07-12 16:08:19	0|morcos|ryanofsky: but not in the documentation anywhere right?
 84 2017-07-12 16:08:43	0|morcos|i'm fine with it if others are
 85 2017-07-12 16:10:30	0|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
 86 2017-07-12 16:11:12	0|phantomcircuit|jonasschnelli, some of the sip nat transversal is actually just proxying through random third party servers
 87 2017-07-12 16:15:03	0|phantomcircuit|TD--Linux, iirc actually getting tcp hole punching to work is unreliable due to nat implementation variance
 88 2017-07-12 16:15:23	0|phantomcircuit|you need to know the other peers report mapped source port for example
 89 2017-07-12 16:15:29	0|phantomcircuit|which they may not even know
 90 2017-07-12 16:16:13	0|BlueMatt|jonasschnelli: since you're here, whats up with #10650?
 91 2017-07-12 16:16:16	0|gribble|https://github.com/bitcoin/bitcoin/issues/10650 | Multiwallet: add RPC endpoint support by jonasschnelli · Pull Request #10650 · bitcoin/bitcoin · GitHub
 92 2017-07-12 16:16:24	0|BlueMatt|right now it looks like multiwallet is gonna miss 15 :(
 93 2017-07-12 16:17:02	0|BlueMatt|or...were here
 94 2017-07-12 16:19:59	0|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?
 95 2017-07-12 16:21:22	0|BlueMatt|there are some easy-fix issues from my review
 96 2017-07-12 16:35:02	0|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
 97 2017-07-12 17:02:51	0|cfields|BlueMatt: uh, what AR/RANLIB to add?
 98 2017-07-12 17:03:21	0|cfields|s/add/specify/
 99 2017-07-12 17:06:52	0|BlueMatt|cfields: dunno, my bash history says `which gcc-ar`
100 2017-07-12 17:07:01	0|BlueMatt|(and ranlib and nm)
101 2017-07-12 17:07:21	0|cfields|BlueMatt: and for arm? mingw?
102 2017-07-12 17:07:29	0|BlueMatt|no idea
103 2017-07-12 17:07:36	0|cfields|exactly :)
104 2017-07-12 17:07:40	0|cfields|they're per-toolchain
105 2017-07-12 17:07:43	0|BlueMatt|well at least do it for native :p
106 2017-07-12 17:08:07	0|BlueMatt|eg test $PREFIX-gcc-*, and if it fails, use $PREFIX-*
107 2017-07-12 17:08:14	0|cfields|not for clang, i believe
108 2017-07-12 17:08:21	0|sipa|my benchmark says that reindex with lto is significantly slower...
109 2017-07-12 17:08:29	0|sipa|both on -O2 and -O3
110 2017-07-12 17:08:30	0|BlueMatt|$CXX-* :p
111 2017-07-12 17:09:17	0|sipa|bitcoind-master-O2: 4977
112 2017-07-12 17:09:17	0|sipa|bitcoind-master-O2-lto: 5722
113 2017-07-12 17:09:17	0|sipa|bitcoind-master-O3: 4815
114 2017-07-12 17:09:23	0|sipa|bitcoind-master-O3-lto: 5577
115 2017-07-12 17:09:31	0|cfields|sipa: (relevant, i swear) did you ever bench the leveldb crc32 impact on reindex?
116 2017-07-12 17:09:45	0|sipa|cfields: no
117 2017-07-12 17:10:09	0|cfields|currently if you set cflags/cxxflags by hand, those end up disabled
118 2017-07-12 17:10:15	0|cfields|pr is incoming
119 2017-07-12 17:10:15	0|sipa|ugh
120 2017-07-12 17:10:19	0|BlueMatt|wtf
121 2017-07-12 17:10:33	0|sipa|that explains!
122 2017-07-12 17:10:55	0|cfields|BlueMatt: it's not clear what we should do in that case, though
123 2017-07-12 17:11:17	0|sipa|just add -msse4.2 to the CXXFLAGS for that?
124 2017-07-12 17:11:20	0|BlueMatt|cfields: i mean cant you do a two-object link test during configure?
125 2017-07-12 17:11:21	0|cfields|BlueMatt: consider: ./configure CXXFLAGS="-O2 -march=i686"
126 2017-07-12 17:11:29	0|cfields|BlueMatt: yea, that's the pr
127 2017-07-12 17:11:30	0|BlueMatt|ohoh, sorry, wrong thing
128 2017-07-12 17:11:46	0|sipa|it also means crcing is hugely significant...
129 2017-07-12 17:11:55	0|BlueMatt|sipa: didnt we know that, though?
130 2017-07-12 17:12:02	0|cfields|sipa: er no, that won't do what you want. That'll enable msse4.2 everywhere
131 2017-07-12 17:12:08	0|BlueMatt|i though i saw benchmarks from you or so that indicated the crc improvements helped a ton previously
132 2017-07-12 17:12:36	0|sipa|cfields: oh, the link-time flags are what matters?
133 2017-07-12 17:13:13	0|cfields|sipa: actually, that's a good question...
134 2017-07-12 17:13:17	0|sipa|BlueMatt: i didn't know they were 20% of our cpu usage...
135 2017-07-12 17:13:31	0|cfields|I would hope it's smart enought to remember per-object flags?
136 2017-07-12 17:13:57	0|sipa|cfields: i would hope so to, but if not, that doesn't explain why lto is slower
137 2017-07-12 17:14:09	0|BlueMatt|cfields: no? why would it be?
138 2017-07-12 17:14:18	0|cfields|sipa: anyway, please try with #10800 instead. Then you don't need to set your own flags
139 2017-07-12 17:14:19	0|gribble|https://github.com/bitcoin/bitcoin/issues/10800 | build: add lto configure option by theuni · Pull Request #10800 · bitcoin/bitcoin · GitHub
140 2017-07-12 17:14:30	0|BlueMatt|i dont think it is, i mean for some flags sure, but mostly i would expect only link-time flags to matter
141 2017-07-12 17:14:38	0|cfields|BlueMatt: so that we can enable instructions for only certain objects (after they've been cpuid checked)
142 2017-07-12 17:15:02	0|sipa|cfields: all of my numbers are with -O2/-O3 -lfo/"" set explicitly for CFLAGS/CXXFLAGS/LDFLAGS
143 2017-07-12 17:15:18	0|sipa|so if overriding flags is bad, it would be bad for all 4 benchmarks
144 2017-07-12 17:15:23	0|BlueMatt|yes, point is I'd assume that would only work on non-lto, or might otherwise confuse ld
145 2017-07-12 17:16:15	0|cfields|BlueMatt: i'd expect the opposite to avoid segfaults all over the place :)
146 2017-07-12 17:16:20	0|cfields|time to google and find out
147 2017-07-12 17:16:30	0|gmaxwell|BlueMatt: hm lto should be fine with mixed cflags.
148 2017-07-12 17:16:44	0|BlueMatt|gmaxwell: mixed clfags maybe, but mixed -march?
149 2017-07-12 17:16:53	0|gmaxwell|(w gcc you can even use pragma to change march on a function by function basis)
150 2017-07-12 17:16:59	0|BlueMatt|true
151 2017-07-12 17:17:16	0|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)
152 2017-07-12 17:17:18	0|gribble|https://github.com/bitcoin/bitcoin/issues/10711 | [tests] Introduce TestNode by jnewbery · Pull Request #10711 · bitcoin/bitcoin · GitHub
153 2017-07-12 17:17:31	0|cfields|sipa: ok, so it's a level playing field i guess, if i understand your setup correctly
154 2017-07-12 17:18:37	0|BlueMatt|yea, i mean i could see lto being slower, but that seems like a lot slower
155 2017-07-12 17:19:02	0|BlueMatt|in other news, any other for-15 stuff that needs review?
156 2017-07-12 17:19:05	0|bitcoin-git|[13bitcoin] 15theuni opened pull request #10806: build: verify that the assembler can handle crc32 functions (06master...06configure-check-asm) 02https://github.com/bitcoin/bitcoin/pull/10806
157 2017-07-12 17:19:21	0|cfields|sipa: also, are you using gcc-ar/ranlib-ar? Or at least verifying that you're not linking fat objects?
158 2017-07-12 17:19:56	0|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
159 2017-07-12 17:20:23	0|BlueMatt|oh, #10758 needs a 15 tag
160 2017-07-12 17:20:24	0|gribble|https://github.com/bitcoin/bitcoin/issues/10758 | Fix some chainstate-init-order bugs. by TheBlueMatt · Pull Request #10758 · bitcoin/bitcoin · GitHub
161 2017-07-12 17:20:27	0|cfields|perfect, thanks
162 2017-07-12 17:21:03	0|cfields|so, thoughts on how to handle the flags overriding there?
163 2017-07-12 17:22:04	0|cfields|it's very unexpected imo that crc32 would be disabled simply by setting CXXFLAGS="-O3"
164 2017-07-12 17:22:17	0|gmaxwell|cfields: for the leveldb stuff it should just append -msse4.2 to whatever cflags it gets.
165 2017-07-12 17:22:17	0|sipa|cfields: i can fix that in an ugly way :)
166 2017-07-12 17:22:27	0|gmaxwell|(for the test and the file)
167 2017-07-12 17:22:57	0|cfields|gmaxwell: what if cflags is "-O2 -march=i686" ?
168 2017-07-12 17:23:06	0|gmaxwell|sipa: using the byte sequences is pretty ugly, and otherwise you still need the -msse4.2
169 2017-07-12 17:23:16	0|gmaxwell|cfields: then that will fail, the test will fail, and it will turn it off.
170 2017-07-12 17:23:50	0|sipa|gmaxwell: yes indeed, that's why it's ugly :)
171 2017-07-12 17:24:03	0|gmaxwell|Why is that ugly, it's what the test is for!
172 2017-07-12 17:24:24	0|gmaxwell|(I mean the configure test to find out if compiling with -msse4.2)
173 2017-07-12 17:24:28	0|sipa|gmaxwell: i mean using byte sequences is ugly
174 2017-07-12 17:24:53	0|sipa|... but it solves everything
175 2017-07-12 17:26:27	0|cfields|gmaxwell: yes, that works
176 2017-07-12 17:26:49	0|gmaxwell|sipa: I'm not opposed, esp for single instructions... but ugh
177 2017-07-12 17:26:51	0|cfields|sipa: i think i agree
178 2017-07-12 17:27:36	0|sipa|FWIW, i do not find any crc instructions in disassemblies of my benchmark binaries
179 2017-07-12 17:27:45	0|sipa|so at least the comparison is fair
180 2017-07-12 17:28:14	0|sipa|... and lto actually slows things down? :(
181 2017-07-12 17:28:46	0|cfields|strange
182 2017-07-12 17:29:51	0|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
183 2017-07-12 17:30:05	0|sipa|gmaxwell: i'm not using -march=native
184 2017-07-12 17:30:08	0|sipa|just -O2"
185 2017-07-12 17:30:16	0|gmaxwell|sipa: cool so if we fix that perhaps we'll finally get it under 1hr with sha-ni. :P
186 2017-07-12 17:30:26	0|sipa|just "-O2", "-O3", "-O2 -flto", "-O3 -flto"
187 2017-07-12 17:31:08	0|cfields|gmaxwell: ^^ pr fixes -march=native
188 2017-07-12 17:35:18	0|gmaxwell|perhaps we could add some logging if crc32 instruction is in use. (and same for other accelerators later)
189 2017-07-12 17:35:35	0|gmaxwell|e.g. is leveldb's detect function exported
190 2017-07-12 17:36:29	0|cfields|no
191 2017-07-12 17:36:59	0|gmaxwell|grr
192 2017-07-12 17:38:01	0|cfields|oh that reminds me, i need to finish fixing their detection
193 2017-07-12 18:24:41	0|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
194 2017-07-12 18:25:08	0|sipa|try putting [] around the ip
195 2017-07-12 18:25:48	0|jnewbery|i've tried all the permutations ::1 [::1] "::1" "[::1]"
196 2017-07-12 18:30:01	0|sipa|hmm
197 2017-07-12 18:30:18	0|jnewbery|There's #1827 but that's ancient and before libevent
198 2017-07-12 18:30:19	0|gribble|https://github.com/bitcoin/bitcoin/issues/1827 | HTTP client needs IPv6 support · Issue #1827 · bitcoin/bitcoin · GitHub
199 2017-07-12 18:30:37	0|cfields|jnewbery: sure you're listening on ipv6 too?
200 2017-07-12 18:31:46	0|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
201 2017-07-12 18:32:59	0|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
202 2017-07-12 18:34:36	0|arubi|jnewbery, I have vague memory I also had to specify the port with ipv6, but that was a while ago..
203 2017-07-12 18:34:36	0|arubi|not sure if you already did
204 2017-07-12 18:35:24	0|jnewbery|arubi: yes - port is specified
205 2017-07-12 18:36:13	0|jnewbery|Does that mean you were able to use bitcoin-cli with ipv6?
206 2017-07-12 18:37:05	0|cfields|jnewbery: what libevent version?
207 2017-07-12 18:37:38	0|arubi|it was a while ago, I didn't mess with it too much so might just be bitcoind related and not -cli
208 2017-07-12 18:38:39	0|arubi|it might have been -rpcbind, sorry for the confusion
209 2017-07-12 18:38:44	0|jnewbery|cfields: what's the quickest way to find out?
210 2017-07-12 18:39:13	0|jnewbery|arubi: yeah bitcoin-cli over ipv6 seems pretty niche. Can't imagine many people use it
211 2017-07-12 18:40:16	0|cfields|jnewbery: grep _EVENT_NUMERIC_VERSION /usr/include/event2/event-config.h
212 2017-07-12 18:41:43	0|bitcoin-git|[13bitcoin] 15instagibbs opened pull request #10807: getbalance example covers at least 6 confirms (06master...06getbalexample) 02https://github.com/bitcoin/bitcoin/pull/10807
213 2017-07-12 18:42:10	0|cfields|jnewbery: I've been trying to track down when this bug was fixed, looks like it was never backported to 2.0.x :(
214 2017-07-12 18:42:20	0|cfields|jnewbery: https://github.com/libevent/libevent/commit/71e709c7829275a594f767b27468b1b52e8b5bb9
215 2017-07-12 18:42:32	0|jnewbery|#define _EVENT_NUMERIC_VERSION 0x02001500
216 2017-07-12 18:47:22	0|cfields|hmm, looks like it should be fixed there
217 2017-07-12 18:48:13	0|bitcoin-git|[13bitcoin] 15TheBlueMatt opened pull request #10808: Avoid some new gcc warnings in 15 (06master...062017-07-15-new-warnings) 02https://github.com/bitcoin/bitcoin/pull/10808
218 2017-07-12 18:53:03	0|jnewbery|cfields: are you sure? https://github.com/libevent/libevent/blob/64177777165d9684bafbfa946abd126f7ebff11f/http.c#L2192
219 2017-07-12 18:53:30	0|jnewbery|That's v2.0.21
220 2017-07-12 18:53:51	0|cfields|jnewbery: I believe that 0x02001500 is 2.1.5beta
221 2017-07-12 18:54:52	0|jnewbery|Not quite. Here's 2.1.5beta: https://github.com/libevent/libevent/blob/release-2.1.5-beta/configure.ac#L17
222 2017-07-12 18:55:00	0|jnewbery|0x02010500
223 2017-07-12 18:55:23	0|cfields|ah, heh
224 2017-07-12 18:55:40	0|cfields|i'd guess that's the problem, then
225 2017-07-12 18:55:46	0|cfields|you can try a depends build to verify
226 2017-07-12 18:56:10	0|jnewbery|I'll try that. Thanks!
227 2017-07-12 18:56:49	0|cfields|np
228 2017-07-12 19:50:11	0|cfields|sipa: i'd be curious to know if --enable-reduce-exports changes your lto results any
229 2017-07-12 19:50:46	0|sipa|cfields: let's try!
230 2017-07-12 19:52:07	0|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
231 2017-07-12 19:55:45	0|sipa|cfields: rebuilding
232 2017-07-12 20:23:54	0|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.
233 2017-07-12 20:23:57	0|gribble|https://github.com/bitcoin/bitcoin/issues/8501 | Add mempool statistics collector by jonasschnelli · Pull Request #8501 · bitcoin/bitcoin · GitHub
234 2017-07-12 20:24:19	0|jonasschnelli|morcos: no hurry. Will not be in 0.15.
235 2017-07-12 20:24:36	0|morcos|oops. sorry!
236 2017-07-12 20:40:08	0|morcos|#10235 should be tagged 0.15 please
237 2017-07-12 20:40:09	0|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
238 2017-07-12 20:40:18	0|BlueMatt|or just merged, at this point
239 2017-07-12 20:40:40	0|morcos|or tagged and merged so it looks like we are making more progress  :)
240 2017-07-12 20:40:51	0|BlueMatt|lol, that too
241 2017-07-12 20:52:42	0|bitcoin-git|[13bitcoin] 15theuni opened pull request #10809: optim: mark a few classes final (06master...06final-classes) 02https://github.com/bitcoin/bitcoin/pull/10809
242 2017-07-12 21:25:32	0|bitcoin-git|[13bitcoin] 15petertodd closed pull request #8543: Use ANYONECANPAY if -spendzeroconfchange=0 (06master...062016-08-anyonecanpay-if-spendzeroconfchange-disabled) 02https://github.com/bitcoin/bitcoin/pull/8543
243 2017-07-12 21:46:34	0|gmaxwell|cfields: how much would it make you hate life to adjust our build system so that leveldb stops getting build with -Wsign-compare
244 2017-07-12 21:46:52	0|gmaxwell|soo tired of that one warning...
245 2017-07-12 21:48:48	0|BlueMatt|lol
246 2017-07-12 21:48:54	0|BlueMatt|cant we just patch it?
247 2017-07-12 21:51:44	0|cfields|gmaxwell: heh. I'm with BlueMatt on that one :)
248 2017-07-12 21:51:59	0|BlueMatt|dont we already carry leveldb patches?
249 2017-07-12 21:52:07	0|sipa|cfields: ack, fix it in bitcoin-core/leveldb
250 2017-07-12 21:54:22	0|morcos|I think #10604 should also go in for 0.15 (needs milestone) assuming #10650 makes it
251 2017-07-12 21:54:24	0|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
252 2017-07-12 21:54:25	0|gribble|https://github.com/bitcoin/bitcoin/issues/10650 | Multiwallet: add RPC endpoint support by jonasschnelli · Pull Request #10650 · bitcoin/bitcoin · GitHub
253 2017-07-12 21:56:26	0|gmaxwell|or that
254 2017-07-12 21:57:10	0|sipa|just merged https://github.com/bitcoin-core/leveldb/pull/2
255 2017-07-12 21:57:24	0|sipa|we should include that change up into the bitcoin core subtree for 0.15
256 2017-07-12 21:57:38	0|sipa|but if we get some signedness fixes in too, even better
257 2017-07-12 21:58:14	0|BlueMatt|NICE
258 2017-07-12 21:58:18	0|BlueMatt|yes, lets do that (for 15)
259 2017-07-12 22:00:05	0|sipa|go open a pr
260 2017-07-12 22:02:43	0|instagibbs|10604 makes sense regardless, and is really easy to review
261 2017-07-12 22:06:11	0|bitcoin-git|[13bitcoin] 15greenaddress opened pull request #10810: missing white space in function arg (06master...06missing_white_space) 02https://github.com/bitcoin/bitcoin/pull/10810
262 2017-07-12 22:09:59	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #10812: [utils] Allow bitcoin-cli's -rpcconnect option to be used with square brackets (06master...06bitcoin_cli_ipv6) 02https://github.com/bitcoin/bitcoin/pull/10812
263 2017-07-12 22:13:13	0|gmaxwell|sipa: plz2merge 10714
264 2017-07-12 22:13:50	0|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?
265 2017-07-12 22:17:35	0|sipa|other things that need merging?
266 2017-07-12 22:17:48	0|BlueMatt|<BlueMatt> or just merged, at this point
267 2017-07-12 22:17:48	0|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
268 2017-07-12 22:17:48	0|BlueMatt|<morcos> #10235 should be tagged 0.15 please
269 2017-07-12 22:17:49	0|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
270 2017-07-12 22:17:51	0|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
271 2017-07-12 22:17:52	0|bitcoin-git|13bitcoin/06master 14959dd87 15practicalswift: Avoid printing incorrect block indexing time due to uninitialized variable...
272 2017-07-12 22:17:52	0|bitcoin-git|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/e8b95239eeb0...2a09a3891fde
273 2017-07-12 22:17:53	0|bitcoin-git|13bitcoin/06master 142a09a38 15Pieter Wuille: Merge #10714: Avoid printing incorrect block indexing time due to uninitialized variable...
274 2017-07-12 22:18:23	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #10714: Avoid printing incorrect block indexing time due to uninitialized variable (06master...06avoid-uninitialized-nStart) 02https://github.com/bitcoin/bitcoin/pull/10714
275 2017-07-12 22:18:52	0|gmaxwell|sipa: danke.
276 2017-07-12 22:20:19	0|morcos|sipa: #10557 could be merged after another look
277 2017-07-12 22:20:20	0|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
278 2017-07-12 22:59:41	0|sipa|cfields: using --enable-reduce-exports does not help
279 2017-07-12 22:59:58	0|cfields|sipa: damn, ok. thanks for trying
280 2017-07-12 23:00:12	0|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
281 2017-07-12 23:00:22	0|sipa|was the build command
282 2017-07-12 23:00:55	0|sipa|this is gcc 6.3.0
283 2017-07-12 23:01:45	0|cfields|ok
284 2017-07-12 23:02:02	0|cfields|i'll be curious to break out perf and see why it's slower
285 2017-07-12 23:30:18	0|bitcoin-git|[13bitcoin] 15sipa pushed 13 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/2a09a3891fde...479afa0f8486
286 2017-07-12 23:30:19	0|bitcoin-git|13bitcoin/06master 14500710b 15Jeremy Rubin: Fix 2 subscript[0] bugs in pubkey.cpp, and eliminate one extra size check
287 2017-07-12 23:30:19	0|bitcoin-git|13bitcoin/06master 14e0451e3 15Jeremy Rubin: Fix subscript[0] bug in net.cpp if GetGroup returns a 0-sized vector
288 2017-07-12 23:30:20	0|bitcoin-git|13bitcoin/06master 1496f2119 15Jeremy Rubin: Fix subscript[0] in compressor.cpp
289 2017-07-12 23:30:28	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #9804: Fixes subscript 0 (&var[0]) where should use (var.data()) instead. (06master...06fix-subscript-0) 02https://github.com/bitcoin/bitcoin/pull/9804
290 2017-07-12 23:56:02	0|gmaxwell|\O/