< bitcoin-git>
[bitcoin] TheBlueMatt closed pull request #10697: Do not hold cs_vNodes when making ForEachNode Callbacks (master...2017-06-cnodestateaccessors-5) https://github.com/bitcoin/bitcoin/pull/10697
< ossifrage>
Should linearize-data.py still work? It fails sometime after 486000 with "Invalid magic: 00000000", from blk01005.dat (dated Sept 22, 2017)
< ossifrage>
The resulting .dat file then fails to load with --loadblock
< gmaxwell>
ossifrage: you need to go add segwit support to it, would be my guess.
< wumpus>
* [new tag] v0.15.1rc1 -> v0.15.1rc1
< meshcollider>
\o/
< meshcollider>
will start gitian building now then
< fanquake>
I've PR some sigs if anyone wants to compare.
< meshcollider>
linux looks good, still building windows and mac atm
< Lauda>
ping wumpus
< Provoostenator>
Is v0.15.1 simply what was called v0.15.0.2 before? I.e. some tweaks to deal with the upcoming fork, but not full SegWit support?
< Provoostenator>
And also, is it useful if I run Gitian on this?
< wxss>
Provoostenator: to your first question, v0.15.1 (previously called v0.15.0.2) is the extra release to better deal with the 2X shitshow. Segwit support had to be delayed because of this to the next release, likely to be called v0.15.2
< Provoostenator>
I've seen those instructions; they're not really clear, but I'll give it a shot.
< Provoostenator>
(I'll make some PR's to improve them once I manage to do a succesfull build)
< achow101>
Provoostenator: it should be 0.15.1rc1 not v0.15.1rc1
< achow101>
Provoostenator: there's no --lxc option
< achow101>
lxc is what it uses by default
< Provoostenator>
Ok and "signer" needs to be my email (for the PGP key)?
< achow101>
yes
< achow101>
does not necessarily need to be your email, could just be your username or some name that GPG recognizes
< Provoostenator>
Github username?
< achow101>
yeah
< achow101>
if that doesn't match your PGP key, you can use --detach-sign and sign it later. the signer name is used to organize the sigs into folders with each signer's name so having something like github username for that is better
< Provoostenator>
So I should either move my GPG key onto the VM, or just do the actual signing on my machine?
< donaloconnor>
Can anyone point to me where in the code bitcoin core checks if the block hash is valid? - I can see it checks POW in CheckBlockHeader
< sipa>
what does that mean?
< donaloconnor>
(FYI - I'm learning the protocol and stepping through the code)
< sipa>
as in, what do you mean by valid?
< donaloconnor>
the hash the miners generate for a block
< sipa>
which validity rule, i mean? difficulty, pow, merkle root commitment, ...?
< sipa>
and i can be a bit pedantic: the hash is computed - it's not that miners "claim" it has a certain hash; it's just how we identify blocks
< sipa>
by definition the hash itself is always valid
< sipa>
of course, there are many rules that the block has to satisfy
< donaloconnor>
I guess it's pow? - I'm not entirely sure... apologies I'm learning. Miners generate the block hash to find one that satisfies the difficulty. I mean, where does bitcoin core check that this hash is actually valid (ie: hashing the block again results int he same hash)
< sipa>
it does not verify that anywhere
< sipa>
nobody claims a block has a certain hash
< sipa>
the block itself is propagated
< sipa>
and to be valid, its hash has to satisfy PoW
< sipa>
(but that's only one out of dozens of validity criteria)
< donaloconnor>
my understanding was miners modified parts of the coinbase text + nonce in order to find something that will result in a hash that satisfies pow/difficulty (blocks start with 0000000000000000003) now. I guess i'm asking, what's stopping someone generating a hash that begins with enough zeros that isn't actually the hash of the block header?
< donaloconnor>
I guess i'm missing something here, sorry if I'm sounding silly ;)
< sipa>
well then the block will be invalid
< donaloconnor>
well that's what I mean... where does it check that
< sipa>
perhaps we're arguing semantics
< sipa>
but there is no need to check whether the block matches its claimed hash - nobody ever claims it has a particular hash
< sipa>
the hash is computed from the block
< sipa>
the rule is _for a block to be valid_ that its hash is below the target implied by the difficulty
< donaloconnor>
maybe. I'm looking at ProcessNewBlock and trying to find out where it validates that the hash is infact a valid hash of the block contents.
< sipa>
and you've already found where that is checked
< aj>
donaloconnor: nodes don't communicate the hashes directly, the communicate the headers (and blocks) and then work out what the hash is
< sipa>
the hash is always the hash of the block contents
< donaloconnor>
ahhh
< sipa>
it is defined as such
< donaloconnor>
maybe that's it
< donaloconnor>
sorry
< donaloconnor>
now I understand...
< donaloconnor>
uint256 hash = block.GetHash(); << this is calculated by the nodes and not transmitted over the wire
< sipa>
exactly
< donaloconnor>
sipa/aj - thanks for the information.
< fobban>
I'm running (or trying to run) bitcoin-core on arch linux but ever since v0.15 I get a CPU hardware error after a few minutes which causes the computer to reboot. I redownloaded the blockchain but a few seconds after it was complete I got the error again.
< sipa>
sounds like your CPU is overheating
< fobban>
I've got a i7-6700k. Never got these hardware errors before and I only get them once I start bitcoin core again
< sipa>
bitcoin core tends to stress CPUs far more than usual desktop software
< fobban>
ok, let me monitor the temp. I don't think it has to do with that though cause the fans don't really spin up more than usual, but hang on, will probably time out soon :P
< fobban>
is v0.15 much harder on the cpu than 0.14 was?
< sipa>
yes, it needs to wait much less on memory
< fobban>
I see now that I didn't get the crash when the blockchain was complete, I managed to download 91% before it crashed. But temp is steady between 23-30C on all cores.
< donaloconnor>
could be PSU not providing enough power for CPU
< fobban>
Hm, might be temp after all, started to spike to 75C now o_O
< donaloconnor>
maybe, though 75 is not uncommon under high load
< Provoostenator>
Gitian has been diligently working for the past few hours... Is there any way to spot check if the work in progress is correct?
< jouke>
w/win 14
< Provoostenator>
To answer my own q: once all linux versions finish building, it spits out a summary with hashes. You can compare that with e.g. gitian.sigs/0.15.1rc1-linux/laanwj/bitcoin-linux-0.15-build.assert
< meshcollider>
Provoostenator: you can also look at the build logs as it's building, to see how it's going
< meshcollider>
And check for errors
< Provoostenator>
@meshcollider those are fun to watch. When I run ./bin/gverify, I assume it checks both the signatures of the other signers as well as that they have the same hashes in their assert files?
< meshcollider>
Provoostenator: hmm I don't think it checks the hashes, just checks the signatures are valid
< Provoostenator>
So how do I check that my hashes match what others found? I compared a few manually and they match.
< ossifrage>
Initially I was getting "plugin needed to handle lto object" from /usr/bin/ranlib, so I switched to gcc-{ranlib,ar,nm}
< gmaxwell>
fwiw, there should be no LTO benefit from libsecp256k1 itself, it's a single .c file. (the modules are all in seperate header files, specifically so it gets all the inlining gains possible, without using LTO)
< ossifrage>
gmaxwell, I'm compiling the entire tree with lto, it just happened to go boom on libsecp256k1
< gmaxwell>
ossifrage: in any case, I'm jealous, not that often that you get to report a GCC bug. :P