< gmaxwell>
"hint : create manually "banlist.dat" in "blockchain" folder if bitcoin-qt.exe crash after the check of the local blockchain." <- cargo cult fixes due to spurrious log entries that we've never fixed?
< phantomcircuit>
ha
< phantomcircuit>
gmaxwell, the failure rate is going to skyrocket as the utxo db grows and cpu load increases
< phantomcircuit>
we're already shaking loose unstable hardware all over the place
< GitHub46>
bitcoin/master 93fc58c Jorge Timón: Consensus: Remove calls to error() and FormatStateMessage() from some consensus code in main
< GitHub46>
bitcoin/master 31ec14b Wladimir J. van der Laan: Merge #7287: Consensus: Remove calls to error() and FormatStateMessage()...
< GitHub158>
[bitcoin] laanwj closed pull request #7287: Consensus: Remove calls to error() and FormatStateMessage() (master...consensus-decouple-util-0.13.99) https://github.com/bitcoin/bitcoin/pull/7287
< wumpus>
Rebroad: what compile error do you get?
< wumpus>
gmaxwell: right, a missing banlist.dat should be harmless. The only non-condiational log message I can find relating to it is "Invalid or missing banlist.dat; recreating\n", which is given when it doesn't exist yet and is being created
< wumpus>
the other banlist.dat related messages all go to category net
< gmaxwell>
Did we fix it so that it actually got created.
< GitHub51>
[bitcoin] laanwj closed pull request #7438: Do not absolutely protect local peers; decide group ties based on time. (0.12...dont_protect_local) https://github.com/bitcoin/bitcoin/pull/7438
< GitHub83>
bitcoin/0.12 46dbcd4 Gregory Maxwell: Do not absolutely protect local peers from eviction....
< GitHub83>
bitcoin/0.12 8e09f91 Gregory Maxwell: Decide eviction group ties based on time....
< GitHub83>
bitcoin/0.12 e2d9a58 Wladimir J. van der Laan: Merge #7438: Do not absolutely protect local peers; decide group ties based on time....
< wumpus>
well my nodes have a banlist.dat and I haven't created it manually so I guess so
< wumpus>
oh not all of them, I guess only the ones that have banlists
< wumpus>
strange. you knew this was a problem? why isn't there an issue open for it
< wumpus>
2016-01-13 09:35:05 ERROR: Read: Failed to open file /home/orion/.bitcoin/banlist.dat / 2016-01-13 09:35:05 Invalid or missing banlist.dat; recreating
< wumpus>
appears every time
< gmaxwell>
I thought there was. Sorry, so many things going on.
< wumpus>
no problem, it's hardly critical, but especialy minor things like this should have an issue so that they don't get lost. I'll open one, np
< gmaxwell>
I'm sure its some trivial fix; I'm not prone to whine about things that I think I ought to just go fix.
< gmaxwell>
I think I whined to pieter about it in person and he already knew about it; or something like that.
< gmaxwell>
I'm sorry. I'm not operating very effectively these days.
< wumpus>
no need to fix it yourself, these are the right kind of issues for someone just getting into the code
< gmaxwell>
point.
< wumpus>
I want to wrap up rc3 soon; any opinions on https://github.com/bitcoin/bitcoin/pull/7431 / Rename permitrbf to replacebyfee and provide minimal string-list forward compatibility ?
< gmaxwell>
I don't have any objection there. I do think replacebyfee= is better named. Though if it's pluggable policy for luke I wonder why he didn't call it -mempoolreplace
< wumpus>
good point
< wumpus>
if it's general, why stick to replacing by fee
< gmaxwell>
I want replace by moon.. uses a lunar calandar to select transactions.
< wumpus>
to at least make centuries of superstition about lunar phases concrete
< petertodd>
wumpus: I have no opinion on the names
< wumpus>
petertodd: me neither, but if we're going to change it then it helps if people actually agree on it, so we don't get yet another pull request changing it to yet something else
< petertodd>
wumpus: fine then, -replacebyfee or I kill you all with fire
< wumpus>
lol
< petertodd>
wumpus: -permitrbf is the type of name only bad people, incapable of love, would come up with
< gmaxwell>
fee is just an acronym. Function Evaluating Everything.
< wumpus>
-replacebyfreedom
< gmaxwell>
petertodd: ^ you're an idiot for not calling it that to begin with.
< gmaxwell>
or replacementfreedom
< petertodd>
gmaxwell: hey, not too late to release my own Bitcoin Freedom Edition fork
< petertodd>
or Bitcoin Objectivism... free in every box of Ayn Bran!
< gmaxwell>
wumpus: is there anything else needed for the next RC?
< MarcoFalke>
I think travis is failing due to missing doc
< MarcoFalke>
one sec...
< wumpus>
MarcoFalke: strange, I can't fin this in the output at least
< MarcoFalke>
gmaxwell, I assume you need to add the arg to the blacklist in check-doc.py as well
< gmaxwell>
oh interesting.
< MarcoFalke>
I am using regex to collect all args, so there are some false positives
< wumpus>
I think we should revert the argument checking for now - it's not apparent in the travis output at all
< MarcoFalke>
The command "if [ "$RUN_TESTS" = "true" ]; then contrib/devtools/check-doc.py; fi" exited with 1.
< gmaxwell>
I can try just pushing the check-doc update that suggested.
< MarcoFalke>
wumpus, ^
< wumpus>
this will confuse lots of people
< gmaxwell>
I do as you command. Just tell me what to do.
< wumpus>
gmaxwell: sure, but this is just not clear, we don't want tests where people have to guess what they have to change
< gmaxwell>
oh you mean the test.
< MarcoFalke>
gmaxwell, vim contrib/devtools/check-doc.py , Then add it in the line where 'benchmark' is.
< wumpus>
MarcoFalke: it needs a more clear message
< wumpus>
people don't expect the tests to fail because of this
< wumpus>
certainly not on all platforms
< MarcoFalke>
wumpus, This is with all travis checks? You need to grep for the exit status in the output to find out what failed
< wumpus>
for other failures, say while building or running the RPC tests there will be an actual error message
< wumpus>
I've never had to "grep for an exit status"
< wumpus>
also I think it'd make sense to do this check first
< wumpus>
so people don't have to wait for all the other, more time-consuming tests, before failing on something silly like this
< MarcoFalke>
it is first
< MarcoFalke>
Right after make distdir
< wumpus>
then why does e.g. "32-bit+dash" only fail after 19 minutes?
< MarcoFalke>
wumpus, actually two pulls missed master. ^
< wumpus>
HUH
< wumpus>
wait, one of those is #7082
< wumpus>
but don't know about "Get rid of inaccurate ScriptSigArgsExpected"
< wumpus>
the other one is #7387
< wumpus>
which has no master counterpart, good catch
< MarcoFalke>
Would it make sense to merge #7438 into master as well? (To make the #7082-diff smaller?)
< wumpus>
depends on how different the 0.12 and master solution are, the 0.12 one is supposed to be a much simplified version that can go in quickly, in master we don't have so much of a hurry
< wumpus>
but this is exactly why I prefer things to be in master first, this makes sure a major version upgrade is never a reversion
< wumpus>
the only time I deviate from that is right before releases, for last minute changes
< Rebroad>
quick question.. does bitcoin core check block headers when it receives the headers AND when it receives the block?
< helo>
surely
< Rebroad>
and does the checking of the header take much time? if so, can it skip doing it upon receiving the block since it already did it when it received the header?
< instagibbs>
I believe so since headers can be received out of order.
< instagibbs>
you have to check it meets the correct PoW target once it's in the correct order
< helo>
it can't all of the block (the merkle root) until it receives the block
< instagibbs>
^ that too
< helo>
all of the block *header
< Rebroad>
helo, yes, it would still need to check the merkle, but it wouldn't need to check the header again, right?
< helo>
it could verify it matched the header it had retrieved instead
< instagibbs>
you'd probably have to read the code to figure it out. The block validation timeline is a bit fuzzy for me. There are various stages.
< Rebroad>
helo, yes... although would that save CPU doing it that way?
< wumpus>
I don't think it will save CPU/time, verifying the header is neglible compared to the rest of block verification
< Rebroad>
helo, and anyway, surely the hash of the block would be enough to be sure it was the same header, wouldn't it?
< helo>
the header is the only part that is hashed afaik.
< wumpus>
helo: right; all the transactions are hashed in a merkle tree, the result is put in the header, then the header is hashed. THe block as a whole is never hashed.
< GitHub4>
[bitcoin] MarcoFalke opened pull request #7455: [travis] Exit early when check-doc.py fails (master...Mf1601-travisCheckDoc) https://github.com/bitcoin/bitcoin/pull/7455
< sdaftuar>
instagibbs: while blocks can be received out of order, headers are not (we make sure we have the header for hashPrev when accepting a new block header)
< instagibbs>
derp, DoS risk, right
< instagibbs>
I only know the ConnectBlock code intimately
< MarcoFalke>
wumpus, > if [a command] returns an exit code of 1, the following command [...] is still run, but the build will result in a failure. (cited from the travis doc)
< MarcoFalke>
I don't think we can exit early
< MarcoFalke>
At least right now, we are not doing an early exit
< MarcoFalke>
Let's say `make` fails. Travis will still run the rpc test suite
< wumpus>
MarcoFalke: right, you need to explicitly exit, unless you use 'set -e' to terminate the script on every failed command
< MarcoFalke>
Good enough for our current .travis.yml ...
< helo>
"set -e" has some side effects
< wumpus>
helo: side effects?
< helo>
you probably are aware, but just wanted to mention... e.g. you can't check the value of $? with "set -e"
< wumpus>
that's, imo, the main effect, not a side effect :) any non-zero return value will terminate your script so you'll never get to the $? check unless it was 0
< Tasoshi>
"[T]his channel shall be retagged buttcoin-core-dev". Lol, I can imagine people taking that out of context
< wumpus>
well that channel is still empty so apparently no one did
< Tasoshi>
Some people do wonder whether the prevalent thought here is that bitcoin does not work though...
< wumpus>
if it didn't work, why would people bother to keep working on it... anyhow, off topic
< Tasoshi>
because they have their own ideas of how to "fix it"
< AngryInca>
hah, lol, well, thats embarrassing! No offence. I'm just looking around different builds.
< gmaxwell>
k, brought my laptop to current 0.12 and rpc is no longer binding to IPv4. I'm not sure when I last tested 0.12 branch on this host.
< gmaxwell>
2016-02-01 20:00:39 Binding RPC on address ::1 port 8332
< gmaxwell>
2016-02-01 20:00:39 Binding RPC on address 127.0.0.1 port 8332
< gmaxwell>
2016-02-01 20:00:39 libevent: getaddrinfo: address family for nodename not supported
< gmaxwell>
2016-02-01 20:00:39 Binding RPC on address 127.0.0.1 port 8332 failed.
< gmaxwell>
any idea what might have broken this?
< OxADADA>
is another process running on that port?
< gmaxwell>
No.
< helo>
dns failed, apparently?
< gmaxwell>
Git master works. 0.12 fails.
< gmaxwell>
well crap, working now. wtf was that.
< gmaxwell>
(means my master vs 0.12 differential test is likely broken)
< Luke-Jr>
jonasschnelli: <jonas.schnelli@include7.ch>: host mail.include7.ch[80.74.145.70] said: 554 5.7.1 Service unavailable; Client host [192.3.11.21] blocked using zen.spamhaus.org; https://www.spamhaus.org/sbl/query/SBL281118 (in reply to RCPT TO command)
< OxADADA>
uh oh.
< Luke-Jr>
your email host sucks. fix it? :P (Spamhaus abuses their position to blackmail datacentres)