< achow101> why were there no commit messages in IRC?
< gmaxwell> they don't show up on other branches?
< sipa> i assume that's it
< bitcoin-git> [bitcoin] TheBlueMatt opened pull request #11604: [net] Remove ForNode/ForEachNode (master...2017-11-no-foreachnode) https://github.com/bitcoin/bitcoin/pull/11604
< 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> @wxss thanks
< bitcoin-git> [bitcoin] Sjors opened pull request #11605: [Qt] Enable RBF by default (master...rbf-default) https://github.com/bitcoin/bitcoin/pull/11605
< Provoostenator> ^ that was me
< Provoostenator> I'm trying to make a Gitian build. Installing Virtual Box and Debian was easy, but this part of the instructions is confusing: https://github.com/bitcoin-core/docs/blob/master/gitian-building.md
< Provoostenator> (VirtualBox running on OSX)
< Provoostenator> bitcoin/contrib/gitian-build.sh --setup --lxc -b signer v0.15.1rc1
< Provoostenator> (or with 0.15.1 instead of v0.15.1rc1)
< MarcoFalke> What is the issue?
< Provoostenator> It starts with a bunch of errors:
< Provoostenator> Cannot build for OSX, SDK does not exist. Will build for other OSes
< Provoostenator> v-b
< Provoostenator> Reading package lists... Done
< Provoostenator> Building dependency tree
< Provoostenator> Reading state information... Done
< Provoostenator> E: Unable to locate package python-vm-builder
< Provoostenator> fatal: destination path 'gitian.sigs' already exists and is not an empty directory.
< Provoostenator> fatal: destination path 'bitcoin-detached-sigs' already exists and is not an empty directory.
< Provoostenator> fatal: destination path 'gitian-builder' already exists and is not an empty directory.
< Provoostenator> ~/gitian-builder ~ ~
< Provoostenator> Then it seems to move along happily, e.g.:
< Provoostenator> I: Configuring initramfs-tools...
< Provoostenator> I: Configuring ureadahead...
< Provoostenator> I: Base system installed successfully.
< Provoostenator> 1+0 records in
< Provoostenator> 1+0 records out
< Provoostenator> 1048576 bytes (1.0 MB) copied, 0.00145623 s, 720 MB/s
< Provoostenator> mke2fs 1.42.12 (29-Aug-2014)
< Provoostenator> Discarding device blocks: done
< Provoostenator> Creating filesystem with 2621440 4k blocks and 656640 inodes
< Provoostenator> Filesystem UUID: 7b433e1a-b962-473d-8192-3c78d20ec64a
< Provoostenator> Superblock backups stored on blocks:
< Provoostenator> 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
< Provoostenator> Allocating group tables: done
< Provoostenator> Writing inode tables: done
< Provoostenator> Creating journal (32768 blocks): done
< Provoostenator> Writing superblocks and filesystem accounting information: done
< Provoostenator> And then it fails:
< eck> plz
< Provoostenator> ~ ~
< eck> no flooding
< Provoostenator> ~/bitcoin ~ ~
< Provoostenator> error: pathspec 'v-b' did not match any file(s) known to git.
< Apocalyptic> have you heard of pastebin ?
< Provoostenator> Oops, I'll use a gist
< MarcoFalke> You'd need to fetch the osx sdk somewhere
< Provoostenator> My IRC client split the message up in 100 parts, that wasn't the plan.
< eck> yes, that is how IRC works
< MarcoFalke> I think they are hosted on some apple developer website
< MarcoFalke> Also, random people might have uploaded them to GitHub somewhere
< MarcoFalke> You can also skip the osx build for now
< Provoostenator> I have an Apple developer account, so that should be doable. Do I need to get the old MaxOSX10.11 stuff?
< Provoostenator> Skipping it is probably better for now, I'd like to see ifI can get the other builds to work.
< MarcoFalke> Refer to https://github.com/bitcoin/bitcoin/blob/master/doc/README_osx.md for instructions to download the apple sdk
< 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?
< achow101> yes
< achow101> I suggest signing on your machine
< Provoostenator> debian@debian:~$ bitcoin/contrib/gitian-build.sh -b sjors 0.15.1rc1 --detached-sign
< Provoostenator> lxcbr0: ERROR while getting interface flags: No such device
< Provoostenator> SIOCSIFADDR: No such device
< sipa> you don't have lxc
< Provoostenator> Switching bitcoin repo to master first did the trick. This might be related: https://github.com/bitcoin/bitcoin/pull/11391
< 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
< Provoostenator> Hopefully this isn't a problem:
< Provoostenator> ./bin/gsign:52:in `<main>': invalid option: --detach-sign (OptionParser::InvalidOption)
< 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.
< bitcoin-git> [bitcoin] Sjors opened pull request #11607: Add Gitian PGP key: Sjors (master...gitian-sjors) https://github.com/bitcoin/bitcoin/pull/11607
< ossifrage> :-( ./libtool: line 1720: 10983 Segmentation fault (core dumped) /usr/bin/gcc-ar cru .libs/libsecp256k1.a src/libsecp256k1_la-secp256k1.o
< gmaxwell> ossifrage: hurray compiler bug.. or cpu overheating
< ossifrage> I was trying (again) to get a flto compile with the current tree. I'm assuming it is a toolchain bug
< ossifrage> ./libtool: line 1720: 1040 Segmentation fault (core dumped) /usr/bin/gcc-ranlib .libs/libsecp256k1.a
< gmaxwell> which gcc version
< ossifrage> gcc is 7.2.1, gcc-ar is 2.27-24
< 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
< esotericnonsense> ossifrage: ryzen gcc segfault bug ?
< ossifrage> esotericnonsense, this is an old xeon (with ecc) and it is repeatable (so not some thermal silliness)
< esotericnonsense> ah
< cfields> gitian builders: v0.15.1rc1 codesigs are _finally_ pushed
< sava_> hello,
< sava_> can anyone tell me command to create new wallet address in linux please
< sipa> sava_: #bitcoin
< sava_> its BTCGPU for bitcoin gold i installed
< sipa> sava_: not here, #bitcoin
< sipa> oh, it's for an altcoin - in that case, no idea
< sava_> cheers
< windsok> #bitcoin-forks
< fanquake> cfields lagging as per usual :p
< fanquake> Have pushed some signed sigs up.