< 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
< bitcoin-git> [bitcoin] theuni opened pull request #10800: build: add lto configure option (master...enable-lto) https://github.com/bitcoin/bitcoin/pull/10800
< achow101> someone please ban this guy: https://github.com/MIGUELWAXX he keeps spamming the repo
< jonasschnelli> achow101: Have you reported him?
< cdecker> I've been asked what my DNS seed policies are regarding BIP148, and I said that I will not filter non-UASF nodes
< cdecker> I guess that's the stance that the other operators will follow as well, or am I mistaken?
< jonasschnelli> cdecker: Yes. I think the dns seed policy paper explicitly stats that...
< jonasschnelli> let me find it
< 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.
< 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...
< cdecker> Some people were arguing about the definition of functioning nodes is
< jonasschnelli> well,... until the chain split (and if), BIP148 and non BIP148 are functioning perfectly fine? not?
< cdecker> Right that's what I thought ^^
< 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
< jonasschnelli> The seeds crawler is not tied to a full node
< 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
< 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
< luke-jr> so I don't suggest committing to not filtering non-UASF (ie, vulnerable) nodes
< 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
< cdecker> luke-jr, I don't follow, you suggest against committing to something like this?
< luke-jr> cdecker: right
< luke-jr> in the worst case scenario, it may be necessary to protect light clients
< cdecker> I honestly don't see why, DNS seeds are infrastructure, not political tools
< cdecker> You mean having light clients flip-flop between the two forks
< luke-jr> cdecker: because light clients are inherently vulnerable
< luke-jr> they will follow any chain they see, no matter how invalid it is
< luke-jr> and unfortunately there are a lot of them
< jonasschnelli> luke-jr: not ultimatively
< luke-jr> jonasschnelli: ?
< 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
< jonasschnelli> The light client i'm working on (based on core) does validate block size and SigOp counts, etc.
< cdecker> And that's what I'm committing to
< luke-jr> cdecker: that's the easiest way to detect vulnerable nodes
< jonasschnelli> light client with client side filtering can validate the "important" parameters
< jonasschnelli> just not with the BF stuff
< luke-jr> jonasschnelli: right, but those aren't the ones that stupidly connect to only seed nodes
< jonasschnelli> Yes. Those need protection...
< 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
< 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 :/
< luke-jr> they don't seem to even have BIP 9 code yet
< cdecker> Ok, not making special provisions for a fork for now
< 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)
< jonasschnelli> hmm.. maybe just refill the queue... I see
< bitcoin-git> [bitcoin] jnewbery opened pull request #10802: [tests] skip zapwallettxes.py (master...skip_zapwallettxes) https://github.com/bitcoin/bitcoin/pull/10802
< 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
< 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?
< ryanofsky> i thought nat traversal was more for udp and tcp
< ryanofsky> udp than tcp
< BlueMatt> getting nat traversal to work with tcp means you need a userspace tcp impl, something we def dont want to get into
< BlueMatt> if it even works at all
< jonasschnelli> So UPnP is the best you can do without userspace tcp impl?
< BlueMatt> yes
< jonasschnelli> What about all these SIP NAT traversal solutions.. do they all have a userspace TCP implementation?
< * jonasschnelli> is looking at http://www.pjsip.org/pjnath/docs/html/index.htm right now
< BlueMatt> Sip does not use tcp if it needs nat traversal, no?
< jonasschnelli> I though SIP is using TCP for establishing... but not sure
< BlueMatt> it may, but you're not getting incoming tcp through nat
< BlueMatt> just not gonna happen
< jonasschnelli> Okay. Thanks BlueMatt.
< 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..
< jonasschnelli> Are there any significant downsides using a std::map<uint256, const CBlockIndex*>?
< jonasschnelli> (and just erase the requested block when it's processed)
< ryanofsky> oh good point, yeah maybe you need a map or a list of lists
< BlueMatt> cfields: wait, huh, --enable-lto only adds -flto? why not also specify ar/ranlib/nm as well automatically?
< jnewbery> jonasschnelli: in my experience providers often use SBCs to resolve NAT traversal
< ryanofsky> southern baptist conventions?
< jonasschnelli> hehe
< jonasschnelli> lookin it up
< jnewbery> SIP can go over TCP or UDP. TCP is more common in my experience
< jnewbery> Session Border Controller
< jonasschnelli> Going off-topic: but what's the best approach for a direct communication channel between two devices behind NAT without a centralized server?
< jonasschnelli> Using UDP (and your own error detection, etc protocol)?
< bitcoin-git> [bitcoin] promag opened pull request #10804: Add histunspent RPC (master...2017-07-rpc-add-histunspent) https://github.com/bitcoin/bitcoin/pull/10804
< jnewbery> STUN/ICE I believe, although it's not something I know much about
< jonasschnelli> thanks jnewbery. </offtopic>
< bitcoin-git> [bitcoin] janstary opened pull request #10805: have proper manpages for bitcoin*(1) (master...master) https://github.com/bitcoin/bitcoin/pull/10805
< 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
< 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?)
< ryanofsky> i can check latest documentation, but i think all of boost::optional is deprecated now that std::optional exists
< TD--Linux> you can totally do TCP hole punching too
< TD--Linux> I don't know if ICE does it
< 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)
< morcos> ryanofsky: but not in the documentation anywhere right?
< morcos> i'm fine with it if others are
< phantomcircuit> jonasschnelli, some of the sip nat transversal is actually just proxying through random third party servers
< phantomcircuit> TD--Linux, iirc actually getting tcp hole punching to work is unreliable due to nat implementation variance
< phantomcircuit> you need to know the other peers report mapped source port for example
< phantomcircuit> which they may not even know
< BlueMatt> jonasschnelli: since you're here, whats up with #10650?
< gribble> https://github.com/bitcoin/bitcoin/issues/10650 | Multiwallet: add RPC endpoint support by jonasschnelli · Pull Request #10650 · bitcoin/bitcoin · GitHub
< BlueMatt> right now it looks like multiwallet is gonna miss 15 :(
< BlueMatt> or...were here
< 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?
< BlueMatt> there are some easy-fix issues from my review
< 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
< cfields> BlueMatt: uh, what AR/RANLIB to add?
< cfields> s/add/specify/
< BlueMatt> cfields: dunno, my bash history says `which gcc-ar`
< BlueMatt> (and ranlib and nm)
< cfields> BlueMatt: and for arm? mingw?
< BlueMatt> no idea
< cfields> exactly :)
< cfields> they're per-toolchain
< BlueMatt> well at least do it for native :p
< BlueMatt> eg test $PREFIX-gcc-*, and if it fails, use $PREFIX-*
< cfields> not for clang, i believe
< sipa> my benchmark says that reindex with lto is significantly slower...
< sipa> both on -O2 and -O3
< BlueMatt> $CXX-* :p
< sipa> bitcoind-master-O2: 4977
< sipa> bitcoind-master-O3: 4815
< sipa> bitcoind-master-O2-lto: 5722
< sipa> bitcoind-master-O3-lto: 5577
< cfields> sipa: (relevant, i swear) did you ever bench the leveldb crc32 impact on reindex?
< sipa> cfields: no
< cfields> currently if you set cflags/cxxflags by hand, those end up disabled
< sipa> ugh
< cfields> pr is incoming
< BlueMatt> wtf
< sipa> that explains!
< cfields> BlueMatt: it's not clear what we should do in that case, though
< sipa> just add -msse4.2 to the CXXFLAGS for that?
< BlueMatt> cfields: i mean cant you do a two-object link test during configure?
< cfields> BlueMatt: consider: ./configure CXXFLAGS="-O2 -march=i686"
< cfields> BlueMatt: yea, that's the pr
< BlueMatt> ohoh, sorry, wrong thing
< sipa> it also means crcing is hugely significant...
< BlueMatt> sipa: didnt we know that, though?
< cfields> sipa: er no, that won't do what you want. That'll enable msse4.2 everywhere
< BlueMatt> i though i saw benchmarks from you or so that indicated the crc improvements helped a ton previously
< sipa> cfields: oh, the link-time flags are what matters?
< cfields> sipa: actually, that's a good question...
< sipa> BlueMatt: i didn't know they were 20% of our cpu usage...
< cfields> I would hope it's smart enought to remember per-object flags?
< sipa> cfields: i would hope so to, but if not, that doesn't explain why lto is slower
< BlueMatt> cfields: no? why would it be?
< cfields> sipa: anyway, please try with #10800 instead. Then you don't need to set your own flags
< gribble> https://github.com/bitcoin/bitcoin/issues/10800 | build: add lto configure option by theuni · Pull Request #10800 · bitcoin/bitcoin · GitHub
< BlueMatt> i dont think it is, i mean for some flags sure, but mostly i would expect only link-time flags to matter
< cfields> BlueMatt: so that we can enable instructions for only certain objects (after they've been cpuid checked)
< sipa> cfields: all of my numbers are with -O2/-O3 -lfo/"" set explicitly for CFLAGS/CXXFLAGS/LDFLAGS
< sipa> so if overriding flags is bad, it would be bad for all 4 benchmarks
< BlueMatt> yes, point is I'd assume that would only work on non-lto, or might otherwise confuse ld
< cfields> BlueMatt: i'd expect the opposite to avoid segfaults all over the place :)
< cfields> time to google and find out
< gmaxwell> BlueMatt: hm lto should be fine with mixed cflags.
< BlueMatt> gmaxwell: mixed clfags maybe, but mixed -march?
< gmaxwell> (w gcc you can even use pragma to change march on a function by function basis)
< BlueMatt> true
< 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)
< gribble> https://github.com/bitcoin/bitcoin/issues/10711 | [tests] Introduce TestNode by jnewbery · Pull Request #10711 · bitcoin/bitcoin · GitHub
< cfields> sipa: ok, so it's a level playing field i guess, if i understand your setup correctly
< BlueMatt> yea, i mean i could see lto being slower, but that seems like a lot slower
< BlueMatt> in other news, any other for-15 stuff that needs review?
< 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
< cfields> sipa: also, are you using gcc-ar/ranlib-ar? Or at least verifying that you're not linking fat objects?
< 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
< BlueMatt> oh, #10758 needs a 15 tag
< gribble> https://github.com/bitcoin/bitcoin/issues/10758 | Fix some chainstate-init-order bugs. by TheBlueMatt · Pull Request #10758 · bitcoin/bitcoin · GitHub
< cfields> perfect, thanks
< cfields> so, thoughts on how to handle the flags overriding there?
< cfields> it's very unexpected imo that crc32 would be disabled simply by setting CXXFLAGS="-O3"
< gmaxwell> cfields: for the leveldb stuff it should just append -msse4.2 to whatever cflags it gets.
< sipa> cfields: i can fix that in an ugly way :)
< gmaxwell> (for the test and the file)
< * sipa> is a fan of inline asm
< cfields> gmaxwell: what if cflags is "-O2 -march=i686" ?
< gmaxwell> sipa: using the byte sequences is pretty ugly, and otherwise you still need the -msse4.2
< gmaxwell> cfields: then that will fail, the test will fail, and it will turn it off.
< sipa> gmaxwell: yes indeed, that's why it's ugly :)
< gmaxwell> Why is that ugly, it's what the test is for!
< gmaxwell> (I mean the configure test to find out if compiling with -msse4.2)
< sipa> gmaxwell: i mean using byte sequences is ugly
< sipa> ... but it solves everything
< cfields> gmaxwell: yes, that works
< gmaxwell> sipa: I'm not opposed, esp for single instructions... but ugh
< cfields> sipa: i think i agree
< sipa> FWIW, i do not find any crc instructions in disassemblies of my benchmark binaries
< sipa> so at least the comparison is fair
< sipa> ... and lto actually slows things down? :(
< cfields> strange
< 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
< sipa> gmaxwell: i'm not using -march=native
< sipa> just -O2"
< gmaxwell> sipa: cool so if we fix that perhaps we'll finally get it under 1hr with sha-ni. :P
< sipa> just "-O2", "-O3", "-O2 -flto", "-O3 -flto"
< cfields> gmaxwell: ^^ pr fixes -march=native
< gmaxwell> perhaps we could add some logging if crc32 instruction is in use. (and same for other accelerators later)
< gmaxwell> e.g. is leveldb's detect function exported
< cfields> no
< gmaxwell> grr
< cfields> oh that reminds me, i need to finish fixing their detection
< 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
< sipa> try putting [] around the ip
< jnewbery> i've tried all the permutations ::1 [::1] "::1" "[::1]"
< sipa> hmm
< jnewbery> There's #1827 but that's ancient and before libevent
< gribble> https://github.com/bitcoin/bitcoin/issues/1827 | HTTP client needs IPv6 support · Issue #1827 · bitcoin/bitcoin · GitHub
< cfields> jnewbery: sure you're listening on ipv6 too?
< 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
< 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
< arubi> jnewbery, I have vague memory I also had to specify the port with ipv6, but that was a while ago..
< arubi> not sure if you already did
< jnewbery> arubi: yes - port is specified
< jnewbery> Does that mean you were able to use bitcoin-cli with ipv6?
< cfields> jnewbery: what libevent version?
< arubi> it was a while ago, I didn't mess with it too much so might just be bitcoind related and not -cli
< arubi> it might have been -rpcbind, sorry for the confusion
< jnewbery> cfields: what's the quickest way to find out?
< jnewbery> arubi: yeah bitcoin-cli over ipv6 seems pretty niche. Can't imagine many people use it
< cfields> jnewbery: grep _EVENT_NUMERIC_VERSION /usr/include/event2/event-config.h
< bitcoin-git> [bitcoin] instagibbs opened pull request #10807: getbalance example covers at least 6 confirms (master...getbalexample) https://github.com/bitcoin/bitcoin/pull/10807
< cfields> jnewbery: I've been trying to track down when this bug was fixed, looks like it was never backported to 2.0.x :(
< jnewbery> #define _EVENT_NUMERIC_VERSION 0x02001500
< cfields> hmm, looks like it should be fixed there
< 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
< jnewbery> That's v2.0.21
< cfields> jnewbery: I believe that 0x02001500 is 2.1.5beta
< jnewbery> 0x02010500
< cfields> ah, heh
< cfields> i'd guess that's the problem, then
< cfields> you can try a depends build to verify
< jnewbery> I'll try that. Thanks!
< cfields> np
< cfields> sipa: i'd be curious to know if --enable-reduce-exports changes your lto results any
< sipa> cfields: let's try!
< 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
< sipa> cfields: rebuilding
< 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.
< gribble> https://github.com/bitcoin/bitcoin/issues/8501 | Add mempool statistics collector by jonasschnelli · Pull Request #8501 · bitcoin/bitcoin · GitHub
< jonasschnelli> morcos: no hurry. Will not be in 0.15.
< morcos> oops. sorry!
< morcos> #10235 should be tagged 0.15 please
< 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
< BlueMatt> or just merged, at this point
< morcos> or tagged and merged so it looks like we are making more progress :)
< BlueMatt> lol, that too
< bitcoin-git> [bitcoin] theuni opened pull request #10809: optim: mark a few classes final (master...final-classes) https://github.com/bitcoin/bitcoin/pull/10809
< 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
< gmaxwell> cfields: how much would it make you hate life to adjust our build system so that leveldb stops getting build with -Wsign-compare
< gmaxwell> soo tired of that one warning...
< BlueMatt> lol
< BlueMatt> cant we just patch it?
< cfields> gmaxwell: heh. I'm with BlueMatt on that one :)
< BlueMatt> dont we already carry leveldb patches?
< sipa> cfields: ack, fix it in bitcoin-core/leveldb
< morcos> I think #10604 should also go in for 0.15 (needs milestone) assuming #10650 makes it
< 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
< gribble> https://github.com/bitcoin/bitcoin/issues/10650 | Multiwallet: add RPC endpoint support by jonasschnelli · Pull Request #10650 · bitcoin/bitcoin · GitHub
< gmaxwell> or that
< sipa> we should include that change up into the bitcoin core subtree for 0.15
< sipa> but if we get some signedness fixes in too, even better
< BlueMatt> NICE
< BlueMatt> yes, lets do that (for 15)
< sipa> go open a pr
< instagibbs> 10604 makes sense regardless, and is really easy to review
< 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
< 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
< gmaxwell> sipa: plz2merge 10714
< 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?
< sipa> other things that need merging?
< BlueMatt> <morcos> #10235 should be tagged 0.15 please
< 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
< BlueMatt> <BlueMatt> or just merged, at this point
< 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
< 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
< bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e8b95239eeb0...2a09a3891fde
< bitcoin-git> bitcoin/master 959dd87 practicalswift: Avoid printing incorrect block indexing time due to uninitialized variable...
< bitcoin-git> bitcoin/master 2a09a38 Pieter Wuille: Merge #10714: Avoid printing incorrect block indexing time due to uninitialized variable...
< 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
< gmaxwell> sipa: danke.
< morcos> sipa: #10557 could be merged after another look
< 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
< sipa> cfields: using --enable-reduce-exports does not help
< cfields> sipa: damn, ok. thanks for trying
< 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
< sipa> was the build command
< sipa> this is gcc 6.3.0
< cfields> ok
< cfields> i'll be curious to break out perf and see why it's slower
< bitcoin-git> [bitcoin] sipa pushed 13 new commits to master: https://github.com/bitcoin/bitcoin/compare/2a09a3891fde...479afa0f8486
< bitcoin-git> bitcoin/master e0451e3 Jeremy Rubin: Fix subscript[0] bug in net.cpp if GetGroup returns a 0-sized vector
< bitcoin-git> bitcoin/master 500710b Jeremy Rubin: Fix 2 subscript[0] bugs in pubkey.cpp, and eliminate one extra size check
< bitcoin-git> bitcoin/master 96f2119 Jeremy Rubin: Fix subscript[0] in compressor.cpp
< 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
< gmaxwell> \O/