< gmaxwell>
Perhaps when we add these ifdefs we should set them up so if nothing is set at all we #error with a reconfigure you knucklehead? :P
< wumpus>
that wouldn't be a bad idea, actually
< wumpus>
that same path would trigger for people building without HAVE_CONFIG_H, e.g. people trying to build with custom-rolled build systems, such as adding everyting into a MSVC project
< wumpus>
currently one'd get a whole slew of unrealistic defaults (although the windows one would work out)
< wumpus>
would fork out for HAVE_DAEMON I mean. Not for other config.h options
< wumpus>
its the same silly mess as in the 90's with icq, msn, aol etc all over again, until programs like pidgin came along
< btcdrak>
fully agree. it's annoying.
< kinlo>
wumpus: bitlbee with libpurple can act as a gateway between telegram and irc. I have my telegram contacts just in my ircclient like all others
< wumpus>
kinlo: there's a libpurple backend for telegram? that's awesome. Hadn't expected so, for some reason, usually those things try very hard to be closed down to third-party applications.
< wumpus>
btcdrak: nice, web is preferable to phone at least :)
< sipa>
all my contacts are hangouts or irc, both work fine in bitlbee
< kinlo>
wumpus: telegram is afaik an "open standard", not a good one, but they are not closed minded like whatsapp
< sipa>
eh, irc doesn't even need bitlbee
< wumpus>
you're lucky. Some of mine insist on whatsapp, others on signal, others on telegram, others on skype, others on ricochet, ...
< sipa>
never heard about ricochet
< kinlo>
whatsapp is a bitch, dont assume you'll be able to handle that w/o official client, but telegram, skype, ricochet all have bitlbee options afaik
< sipa>
oh, i have signal too, but only with people i can reach in other ways
< wumpus>
ricochet is chat over tor hidden services, it's an open source protocol, however I don't think e.g. libpurple integrates it
< wumpus>
cfields_: did you know that ssh is set up to pass through LC_* environment variables by default on debian and derivatives? I never knew, just found out with a weird issue. I guess gitian already takes this into account.
< achow101>
what are these nodes with 52.x IPs?
< wumpus>
achow101: no one knows, guesses range from spy nodes to a (slow) DoS
< wumpus>
it's starting to look more and more like a DoS with the sheer number of connections opened, though opening all those connections could also be a way to deceive the trickle logic
< wumpus>
(and hence spy more effectively. I've never seen a spy that was so conspicious though...)
< sipa>
seems those stopped connecting to me
< achow101>
have you tried iptables to block those connections? I am about to do that.
< luke-jr>
I suspect a human is watching us and filtering out our IPs when they figure out who we are
< wumpus>
achow101: yes you can use iptables based blocking, or bitcoind's ban functionality, getting rid of them is quite easy
< wumpus>
otherwise they leech quite some bandwith. "inv": 383977 * 45 connections, in 3 hours on one of my nodes
< wumpus>
if it's a DoS it's a sneaky kind of DoS because they don't have to send you data, they don't send anything besides pong,verack and version, but they can just wait for you to send them tons of invs
< sipa>
damn, since last thursday i've uploaded 250 GB worth of blocks
< wumpus>
wow
< sipa>
.. or my statistics patch is wrong
< wumpus>
luke-jr: it's very possible for their operators to listen in here, yes
< sipa>
or just notice they're getting banned and stop trying
< achow101>
those are all Amazon IPs so we could report them to Amazon and see if they will stop them
< wumpus>
yes, we should.
< wumpus>
I've been too lazy to report them up to now, but we certainly should, there more people do the better
< wumpus>
apparently they all suddenly reconnected about 300-400 seconds ago
< sipa>
here as well
< wumpus>
they're as conspicious as one can get, either this is some extremely unethical research project, or a troll action explicitly set up to provoke a response
< sipa>
about half my bandwidth goes to blocks up to depth 35000
< sipa>
a quarter goes to blocks up to depth 5200
< wumpus>
well with two service bits it could in principle support three ranges, maybe that would be another threshold
< sipa>
one eight goes to blocks up to depth 300
< sipa>
next week or so i'll make some graphs
< wumpus>
yes it would be interesting to see this plotted out
< GitHub138>
[bitcoin] luke-jr closed pull request #8386: mining: Optimise for typical mining use with blockmaxsize (master...blockmaxsize_opti) https://github.com/bitcoin/bitcoin/pull/8386
< BlueMatt>
sipa: re: https://github.com/bitcoin/bitcoin/pull/8393#discussion_r81563418 is there anything stopping us from switching GetFetchFlags to just return (LocalServices() & NODE_WITNESS) && State(pfrom->GetId())->fHaveWitness instead of checking IsWitnessEnabled?
< BlueMatt>
or is that a big change to fix that small bug?
< sipa>
that looks safe to me
< sipa>
i'm unable to fix things now... just spilled coffee over my laptop
< Chris_Stewart_5>
What file(s) does the logic reside to maintain the utxo set in Bitcoin Core?
< sipa>
$DATADIR/chainstate/*
< sipa>
ah, the logic
< sipa>
coins.h/cpp
< sipa>
and main
< sipa>
BlueMatt: but that change will cause some logic to switch immediately in .13.1 rather than only after segwit activates
< sipa>
maybe that's safer
< sipa>
i can't check now
< BlueMatt>
sipa: I'm aware its not a trivial change, indeed
< sipa>
BlueMatt: i think in general that it's fine to switch things based on segwit being defined rather than active
< sipa>
as it will expose problems with relay earlier, and not all at once on the network
< BlueMatt>
sipa: ok, I'll open a pr that does just that since it would be weird to have that in a compact block-related pr
< BlueMatt>
fwiw, a brief glance indicates this same bug might exist in INV processing
< sipa>
BlueMatt: we should have made inv-based announcements obsolete for cb and/or segwit
< BlueMatt>
sipa: yea, I was just looking at that code, I really dont like it
< BlueMatt>
sipa: i really want to rip out the request there and only respond with getheaders, but too late for 0.13.1
< sipa>
agree
< sipa>
(both on ripping it out, and it being too late)
< GitHub49>
[bitcoin] TheBlueMatt opened pull request #8871: Make GetFetchFlags always request witness objects from witness peers (master...fetchflags) https://github.com/bitcoin/bitcoin/pull/8871
< gmaxwell>
Anyone know who 66.180.32.186:18333 (testnet) is?
< BlueMatt>
roasbeef: ping
< BlueMatt>
roasbeef: does btcd do sendheaders announcements?
< Chris_Stewart_5>
Is there a BIP for the serialization/unserialization for coins.h?
< gmaxwell>
no, bips are for interoperability. the internal encoding is purely internal and could change freely from version to version.
< roasbeef>
BlueMatt: yeah, although we don't fully utilize the new feature when receiving (only if we're still in checkpoint sync realm do we fetch blocks immedately from headers)
< GitHub86>
[bitcoin] TheBlueMatt opened pull request #8872: Remove block-request logic from INV message processing (master...fetchflags2) https://github.com/bitcoin/bitcoin/pull/8872
< BlueMatt>
roasbeef: just asking in the context of https://github.com/bitcoin/bitcoin/pull/8872 ie can bitcoin core stop requesting directly on INVs and only request on headers messages
< BlueMatt>
sdaftuar: noticed another reason why this is good "Finally, this removes the one place we MarkBlockAsInFlight (ie will forcibly store the block on disk in AcceptBlock) without having seen the header first."
< sipa>
ah, good
< Chris_Stewart_5>
Thanks for the explanation gmaxwell
< gmaxwell>
Np.
< gmaxwell>
What remaining OpenSSL dependencies do we have in bitcoind? I am aware of the RNG, though its now far less critical due to the just in time urandom usage for key generation.
< gmaxwell>
and tests.
< sipa>
i believe that is the only openssl dependency for bitcoind
< roasbeef>
BlueMatt: gotcha, yeah that change should be fine from btcd's PoV
< instagibbs>
isn't it used for payment protocol?
< instagibbs>
or is that extra-bitcoind(i dont know that stuff)
< sipa>
bitcoind does not support the payment protocol
< sipa>
it's only in qt
< instagibbs>
kk
< gmaxwell>
yea my bitcoind qualification was intentional.
< GitHub48>
[bitcoin] ryanofsky opened pull request #8873: Add microbenchmarks to profile more code paths. (master...issue-7883-benchmarks) https://github.com/bitcoin/bitcoin/pull/8873
< meowzus>
could someone tell me an easy way to start contributing towards the project?
< luke-jr>
meowzus: strictly easy, or as a good first stepping stone?
< meowzus>
good first stepping stone most probably
< achow101>
report bugs
< meowzus>
i meant in terms of getting my hands with with developing
< sipa>
what experience do you have?
< meowzus>
just general development skills, used to do app development in silicon valley
< meowzus>
looking to get into blockchain dev
< sipa>
do you know c++?
< meowzus>
yeah
< achow101>
meowzus: you can review open PRs
< luke-jr>
meowzus: write new unit tests
< luke-jr>
review is also helpful, yes
< sipa>
luke-jr: that's a really boring task if you don't know what about