< wumpus>
dcousens: because "As defined in W. Richard Stevens' 1990 book, Unix Network Programming (Addison-Wesley, 1990), a daemon is 'a process that executes 'in the background' (i.e., without an associated terminal or login shell)"
< wumpus>
at best, stderr is connected to nowhere, at worst, it causes some other trouble...
< dcousens>
wumpus: assuming you run bitcoind in `-daemon` mode :P
< wumpus>
obviously
< dcousens>
perhaps `-printtoconsole` should override that behaviour, allowing stderr to be meaningful
< wumpus>
(just want to put it in context besides bitcoin)
< dcousens>
haha, yeah, thanks for the ref :)
< wumpus>
and sure - something could be said for an 'error log' in addition to the 'debug log' for serious issues, which in case of printtoconsole could go to stderr
< gribble>
Error: "height" is not a valid command.
< sipa>
;;blocks
< gmaxwell>
darn it, why is my laptop saying "0 blocks received in the last 4 hours" ? It's at 386520.
< gribble>
386520
< midnightmagic>
38652
< midnightmagic>
er +0
< midnightmagic>
;;tblb
< gribble>
(tblb <interval>) -- Calculate the expected time between blocks which take at least <interval> seconds to create. To provide the <interval> argument, a nested 'seconds' command may be helpful.
< midnightmagic>
;;tslb
< gribble>
Time since last block: 13 minutes and 38 seconds
< gmaxwell>
sipa: that gribble command just queries bc.i ... perhaps we should cluestick nanotube about the rest interface in bitcond. :)
< sipa>
gmaxwell: i know, but more information is useful
< gmaxwell>
I think what might happen is that while the laptop is in my bag and offline the warning triggers and it doesn't go away when back online.
< GitHub120>
[bitcoin] laanwj closed pull request #7133: Replace setInventoryKnown with a rolling bloom filter (rebase of #7100) (master...known_bloom) https://github.com/bitcoin/bitcoin/pull/7133
< jtimon>
btcdrak: said it was fine for 0.12 too, but that didn't ended up being the case
< GitHub156>
[bitcoin] ptschip opened pull request #7164: Do not download transactions during initial blockchain sync (master...tx_getdata) https://github.com/bitcoin/bitcoin/pull/7164
< GitHub142>
[bitcoin] laanwj opened pull request #7165: WIP: build: Enable C++11 in build, require C++11 compiler (master...2015_12_c++11) https://github.com/bitcoin/bitcoin/pull/7165
< gmaxwell>
\O/
< sipa>
and the crowd goes wild
< wumpus>
hah!
< sipa>
test/scheduler_tests.cpp:31:13: warning: ‘void scheduler_tests::MicroSleep(uint64_t)’ defined but not used [-Wunused-function] static void MicroSleep(uint64_t n)
< wumpus>
sipa: yeah that function is not used pending fixing of the scheduler tests, harmles
< sipa>
i'm aware, just wasn't sure whether we were aware of the warning :)
< wumpus>
I was aware
< wumpus>
scheduler stuff really needs to be fixed, I just have no time for that right now
< sipa>
understood
< wumpus>
(this is better than having travis hang 4% of the time)
< gmaxwell>
:-/
< wumpus>
not sure even if it's a bug in the test or the implementation. Though I'm not aware of any issues with it that don't concern the test, although in practice we only use it single-threaded so whatever trips up the test is likely not an issue in practical use...
< wumpus>
if the intent is to only ever use it single-threadedly, both the implementation and the test could be simplified a lot
< wumpus>
(although it is always difficult to test something inherently time-based)
< jl2012>
Why Antpool is not upgrading to BIP65? It is the last major pool to upgrade
< jl2012>
sorry wrong group
< cfields>
oh, i hadn't seen the 0.12 branch yet. woohoo :)
< cfields>
sipa: i have a few questions about addrman when you have a min
< cfields>
sipa: for one, i'm not understanding the timing used for Connected()
< jtimon>
btcdrak: could you make me a branch with bip68 and bip112 on top of 3cd836c1 ?
< cfields>
(specifically, why it's called when a node is deleted). Is that meant to mean "this is the last time i saw that i was connected to this node" ?
< jtimon>
no hurry though, I can do it myself if you don't have time as well
< sipa>
cfields: yup
< jtimon>
would be nicer to wait for them to get merged before backporting the commits, but I'm not sure I can wait that long...
< sipa>
that's why it's done then, to not leak information beforehand about being connected to that node
< cfields>
sipa: ok. So is it reasonable to call that any time is a node is disconnected, whether done via forced disconnect/ban, shutdown, timeout, etc?
< cfields>
i assume yes?
< sipa>
yes
< sipa>
i guess it would be even better to pass along the timestamp, and send it the lastreceived timestamp of CNode
< cfields>
yes, that's what i was planning to change it to
< cfields>
well, i was intending to use the disconnect time itself. lastreceived makes more sense i guess
< sipa>
lastsent doesn't mean much, we want to know when we last saw the node
< sipa>
will look, but not now
< cfields>
the range/mask is up for bikeshed, i'm just interested in your general opinion
< cfields>
np, thanks
< cfields>
gmaxwell: would be great to get your thoughts on that as well since it was your idea :)
< jtimon>
cfields: any further thoughts on #7091 ?
< cfields>
jtimon: i haven't been keeping up with those. looking now.
< jtimon>
cfields: thanks!
< cfields>
jtimon: i really don't care for the idea of building everything twice when a helper lib can be used to avoid that. Also, as-is, that seems like a slipperly slope as everything that's lib-friendly is likely to start ending up in that last.
< jtimon>
no, only whatever is required to expose verifyblock in libconsensus should end up there
< jtimon>
but things are being built twice for libconsensus already, that doesn't change
< jtimon>
main, chain and coins should never end up there, even if they end up being lib-friendly
< cfields>
jtimon: understood. but if you're creating a helper lib, may as well use it
< jtimon>
I don't undesrtand the point about the helper lib
< jtimon>
why is it a "helper" lib?
< jtimon>
and how is the consensus package not being used?
< cfields>
by "helper" i mean a private lib that's only used for linking into public binaries
< cfields>
jtimon: i gave a patch a few days ago that shows how to link the helper directly into libconsensus.so rather than building twice
< jtimon>
oh, yes, I focused on your nits (and finding out that for some reason the packages have to be build in backards order [linking order]), but I forgot about cherry picking from your branch
< jtimon>
I'll look into that
< jtimon>
btw, you never answer that question, why autotools wants the packages to be build in the same order that is needed for linking (the opposite of what I was trying to achieve)
< jtimon>
?
< cfields>
jtimon: i responded on github
< jtimon>
cfields: but to be clear, your improvement is kind of orthogonal to mine, isn't it?
< cfields>
jtimon: no, the helper lib needs to be created one way or the other
< jtimon>
well I have been told to create a new one instead, but since "the lib syntax and usage is different" is going to be quite different anyway, who knows, maybe we do it in cfields' computer
< sipa>
ok!
< jtimon>
there's no point in have to rebase if say you do something nice like moving merkle to the consensus folder or something
< cfields>
jtimon: sipa has a point though. by all means if you think you're right, fight me on it :)
< jtimon>
cfields: but I agree with building the objects only once, I'm just not sure how much of 7091 as is, is incompatible with what you want to do, if you prefer to tell me that in person next week
< jtimon>
and I don't close it because you have objections to it, just because I'm not going to rebase it as is if it's incompatible with building only once, which I also want for bitcoin jt
< jtimon>
the code is in jtimon/libconsensus-f2 (pre-bitcoin-jt) anyway
< cfields>
ok
< GitHub29>
[bitcoin] gmaxwell opened pull request #7166: Disconnect on mempool requests from peers when over the upload limit. (master...mempool_p2p_when_overlimit) https://github.com/bitcoin/bitcoin/pull/7166
< jgarzik>
Wizards,
< jgarzik>
Has anybody written up designs for a "wallet" does not have complete control over the keys?