< GitHub64> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/6013c73b3312...6f3ef551fa0f
< GitHub64> bitcoin/master 1c80386 Wladimir J. van der Laan: rpc: Generate auth cookie in hex instead of base64...
< GitHub64> bitcoin/master 6f3ef55 Wladimir J. van der Laan: Merge #8858: rpc: Generate auth cookie in hex instead of base64...
< GitHub183> [bitcoin] laanwj closed pull request #8858: rpc: Generate auth cookie in hex instead of base64 (master...2016_10_01_moar_cookies) https://github.com/bitcoin/bitcoin/pull/8858
< gmaxwell> "Error: -daemon is not supported on this operating system"
< gmaxwell> wumpus: I am guessing that I shouldn't be seeing that on debian testing... and that I probably need to autogen.
< gmaxwell> (checks)
< gmaxwell> So I expect we're likely to get reports... :P
< wumpus> gmaxwell: hah, already preempted that days ago: https://github.com/bitcoin/bitcoin/pull/8813#issuecomment-250788185 :)
< gmaxwell> wumpus: comfirmed, autogen/configure fixed.
< 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
< gmaxwell> libsecp256k1 does this.
< GitHub182> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/6f3ef551fa0f...eafc5f4fae52
< GitHub182> bitcoin/master 2ca7faa MarcoFalke: Squashed 'src/univalue/' changes from daf1285..16a1f7f...
< GitHub182> bitcoin/master e757115 MarcoFalke: Merge commit '2ca7faab4205822b06dc2ab2bbda0a9a70fce7e0' into HEAD
< GitHub182> bitcoin/master eafc5f4 Wladimir J. van der Laan: Merge #8863: univalue: Pull subtree...
< GitHub123> [bitcoin] laanwj closed pull request #8863: univalue: Pull subtree (master...Mf1610-univalue) https://github.com/bitcoin/bitcoin/pull/8863
< wumpus> jonasschnelli: looks like your testnet DNS seed is failing again
< wumpus> if it keeps running and reporting to logs but not serving requests it seems a deeper issue
< gmaxwell> "connections": 124,
< gmaxwell> thats not good.
< wumpus> time for the ban hammer?
< gmaxwell> yea, looks like that amazon spy thing is back.. on new IPs.
< luke-jr> they seem to have given up on me still
< wumpus> arghh
< wumpus> https://github.com/bitcoin/bitcoin/issues/8864 we just have to add a targeting mark to them and it'd be a fun whack-a-mole minigame
< gmaxwell> hm. rm my debuglog and kill -HUP appears to have not freed the disk space. (on 0.13.x back a few weeks)
< wumpus> if not the debug log, what is using your disk space?
< gmaxwell> I mean, I had a 20gb debug.log, and 2gb free. Deleted the log. kill -HUP the daemon.. still 2gb free.
< wumpus> oh or is it still holding a reference to the deleted file
< gmaxwell> that.
< wumpus> there's probably some lsof trick to get rid of that
< wumpus> it indicates that there is some fd leak
< gmaxwell> yea, actually I can probably figure out which thread it is.
< wumpus> yes and then you can find the fd in /proc and trunacte it
< gmaxwell> wumpus: false alarm here, had another process holding it.
< da2ce7> hello, I have a build error on macOS; bitcoin/master: https://paste.fedoraproject.org/442517/75481833/
< da2ce7> ./autogen.sh ; ./configure ; make -j8
< da2ce7> macOS sierra: 10.12 (16A323)
< GitHub76> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/eafc5f4fae52...76f3c02fb01a
< GitHub76> bitcoin/master fa7c35c MarcoFalke: [qa] util: Move wait_bitcoinds() into stop_nodes()
< GitHub76> bitcoin/master 76f3c02 MarcoFalke: Merge #8860: [qa] util: Move wait_bitcoinds() into stop_nodes()...
< GitHub108> [bitcoin] MarcoFalke closed pull request #8860: [qa] util: Move wait_bitcoinds() into stop_nodes() (master...Mf1610-qaUtilWait) https://github.com/bitcoin/bitcoin/pull/8860
< wumpus> da2ce7: that looks non-trivial, better to open an issue I think
< wumpus> you may be the first trying to build this on 10.12
< wumpus> gah, every time I try to respond to jtimon's PMs he's offline
< wumpus> and he should be in the same timezone. At least geographically.
< GitHub47> [bitcoin] MarcoFalke opened pull request #8866: [0.13] Backports (0.13...Mf1610-013backp) https://github.com/bitcoin/bitcoin/pull/8866
< btcdrak> wumpus: he is on Telegram reliably.
< wumpus> I really dislike using my phone to chat. But I'll consider it
< wumpus> if only all those zillions of new phone chat programs had an IRC interface, or, even a publically documented API
< btcdrak> wumpus: you can use https://web.telegram.org
< 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
< da2ce7> wumpus: thank you, I've created an issue: https://github.com/bitcoin/bitcoin/issues/8869
< 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> there's a topic on btctalk about it here: https://bitcointalk.org/index.php?topic=1478418.0
< 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
< btcdrak> [segwitcb] https://github.com/bitcoin/bitcoin/pull/8393 was updated. needs final review (segwitcb)
< btcdrak> also please review https://github.com/bitcoin/bitcoin/pull/8499 regarding segwit policy limits
< GitHub157> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/76f3c02fb01a...a7e5cbb209d4
< GitHub157> bitcoin/master 3450c18 Jorge Timón: Globals: Decouple GetConfigFile and ReadConfigFile from global mapArgs
< GitHub157> bitcoin/master a7e5cbb Wladimir J. van der Laan: Merge #8856: Globals: Decouple GetConfigFile and ReadConfigFile from global mapArgs...
< GitHub100> [bitcoin] laanwj closed pull request #8856: Globals: Decouple GetConfigFile and ReadConfigFile from global mapArgs (master...0.13-globals-utils-configfile) https://github.com/bitcoin/bitcoin/pull/8856
< GitHub54> [bitcoin] czzarr opened pull request #8870: Add p2sh segwit options to bitcoin tx (master...add-p2sh-segwit-options-to-bitcoin-tx) https://github.com/bitcoin/bitcoin/pull/8870
< GitHub95> [bitcoin] czzarr closed pull request #8870: Add p2sh segwit options to bitcoin tx (master...add-p2sh-segwit-options-to-bitcoin-tx) https://github.com/bitcoin/bitcoin/pull/8870
< 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 (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
< sipa> meowzus: i suggest looking at the issue tracker (https://github.com/bitcoin/bitcoin/issues) and filtering for things with the 'easy' label
< luke-jr> sipa: perhaps, but boring and easy tend to overlap a lot, and tests and review help one learn the codebase well
< meowzus> sipa: "Easy to implement" right?
< meowzus> luke-jr: how do i find out what unit tests are needed?
< luke-jr> meowzus: can either look over what exists already, or break things at random until something doesn't get detected
< meowzus> haha i see
< luke-jr> note some are in qa/rpc-tests/, some in src/tests/ and some in src/qt/tests/
< meowzus> cool
< sipa> luke-jr: i generally believe that good unit tests require a thorough understanding of the behaviour that is being tested
< sipa> though it is true that it may help getting used to the codebase
< luke-jr> sipa: yes, I agree
< luke-jr> that's part of learning the codebase IMO
< achow101> None of the context menu stuff for peers seems to be working for me