1 2017-11-04 00:15:04	0|achow101|why were there no commit messages in IRC?
  2 2017-11-04 00:19:24	0|gmaxwell|they don't show up on other branches?
  3 2017-11-04 00:24:27	0|sipa|i assume that's it
  4 2017-11-04 00:31:42	0|bitcoin-git|[13bitcoin] 15TheBlueMatt opened pull request #11604: [net] Remove ForNode/ForEachNode (06master...062017-11-no-foreachnode) 02https://github.com/bitcoin/bitcoin/pull/11604
  5 2017-11-04 00:31:52	0|bitcoin-git|[13bitcoin] 15TheBlueMatt closed pull request #10697: Do not hold cs_vNodes when making ForEachNode Callbacks (06master...062017-06-cnodestateaccessors-5) 02https://github.com/bitcoin/bitcoin/pull/10697
  6 2017-11-04 05:18:07	0|ossifrage|Should linearize-data.py still work? It fails sometime after 486000 with "Invalid magic: 00000000", from blk01005.dat (dated Sept 22, 2017)
  7 2017-11-04 05:19:02	0|ossifrage|The resulting .dat file then fails to load with --loadblock
  8 2017-11-04 05:26:14	0|gmaxwell|ossifrage: you need to go add segwit support to it, would be my guess.
  9 2017-11-04 08:19:53	0|wumpus|* [new tag]         v0.15.1rc1 -> v0.15.1rc1
 10 2017-11-04 08:24:53	0|meshcollider|\o/
 11 2017-11-04 08:26:27	0|meshcollider|will start gitian building now then
 12 2017-11-04 10:10:38	0|fanquake|I've PR some sigs if anyone wants to compare.
 13 2017-11-04 10:12:37	0|meshcollider|linux looks good, still building windows and mac atm
 14 2017-11-04 11:05:57	0|Lauda|ping wumpus
 15 2017-11-04 12:34:23	0|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?
 16 2017-11-04 12:35:01	0|Provoostenator|And also, is it useful if I run Gitian on this?
 17 2017-11-04 12:42:11	0|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
 18 2017-11-04 12:42:43	0|Provoostenator|@wxss thanks
 19 2017-11-04 13:01:10	0|bitcoin-git|[13bitcoin] 15Sjors opened pull request #11605: [Qt] Enable RBF by default (06master...06rbf-default) 02https://github.com/bitcoin/bitcoin/pull/11605
 20 2017-11-04 13:07:37	0|Provoostenator|^ that was me
 21 2017-11-04 14:53:41	0|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
 22 2017-11-04 14:53:56	0|Provoostenator|(VirtualBox running on OSX)
 23 2017-11-04 14:54:03	0|Provoostenator|bitcoin/contrib/gitian-build.sh --setup --lxc -b signer v0.15.1rc1
 24 2017-11-04 14:54:23	0|Provoostenator|(or with 0.15.1 instead of v0.15.1rc1)
 25 2017-11-04 14:54:58	0|MarcoFalke|What is the issue?
 26 2017-11-04 14:55:53	0|Provoostenator|Cannot build for OSX, SDK does not exist. Will build for other OSes
 27 2017-11-04 14:55:53	0|Provoostenator|It starts with a bunch of errors:
 28 2017-11-04 14:55:55	0|Provoostenator|Reading package lists... Done
 29 2017-11-04 14:55:55	0|Provoostenator|v-b
 30 2017-11-04 14:55:57	0|Provoostenator|Building dependency tree
 31 2017-11-04 14:55:57	0|Provoostenator|Reading state information... Done
 32 2017-11-04 14:55:59	0|Provoostenator|E: Unable to locate package python-vm-builder
 33 2017-11-04 14:55:59	0|Provoostenator|fatal: destination path 'gitian.sigs' already exists and is not an empty directory.
 34 2017-11-04 14:56:01	0|Provoostenator|fatal: destination path 'bitcoin-detached-sigs' already exists and is not an empty directory.
 35 2017-11-04 14:56:01	0|Provoostenator|fatal: destination path 'gitian-builder' already exists and is not an empty directory.
 36 2017-11-04 14:56:03	0|Provoostenator|~/gitian-builder ~ ~
 37 2017-11-04 14:56:03	0|Provoostenator|Then it seems to move along happily, e.g.:
 38 2017-11-04 14:56:05	0|Provoostenator|I: Configuring initramfs-tools...
 39 2017-11-04 14:56:05	0|Provoostenator|I: Configuring ureadahead...
 40 2017-11-04 14:56:07	0|Provoostenator|1+0 records in
 41 2017-11-04 14:56:07	0|Provoostenator|I: Base system installed successfully.
 42 2017-11-04 14:56:09	0|Provoostenator|1048576 bytes (1.0 MB) copied, 0.00145623 s, 720 MB/s
 43 2017-11-04 14:56:09	0|Provoostenator|1+0 records out
 44 2017-11-04 14:56:11	0|Provoostenator|Discarding device blocks: done
 45 2017-11-04 14:56:11	0|Provoostenator|mke2fs 1.42.12 (29-Aug-2014)
 46 2017-11-04 14:56:13	0|Provoostenator|Creating filesystem with 2621440 4k blocks and 656640 inodes
 47 2017-11-04 14:56:13	0|Provoostenator|Filesystem UUID: 7b433e1a-b962-473d-8192-3c78d20ec64a
 48 2017-11-04 14:56:15	0|Provoostenator|32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
 49 2017-11-04 14:56:15	0|Provoostenator|Superblock backups stored on blocks:
 50 2017-11-04 14:56:17	0|Provoostenator|Allocating group tables: done
 51 2017-11-04 14:56:17	0|Provoostenator|Writing inode tables: done
 52 2017-11-04 14:56:19	0|Provoostenator|Creating journal (32768 blocks): done
 53 2017-11-04 14:56:19	0|Provoostenator|Writing superblocks and filesystem accounting information: done
 54 2017-11-04 14:56:21	0|eck|plz
 55 2017-11-04 14:56:21	0|Provoostenator|~ ~
 56 2017-11-04 14:56:21	0|Provoostenator|And then it fails:
 57 2017-11-04 14:56:23	0|Apocalyptic|have you heard of pastebin ?
 58 2017-11-04 14:56:23	0|eck|no flooding
 59 2017-11-04 14:56:23	0|Provoostenator|~/bitcoin ~ ~
 60 2017-11-04 14:56:23	0|Provoostenator|error: pathspec 'v-b' did not match any file(s) known to git.
 61 2017-11-04 14:56:25	0|Provoostenator|Oops, I'll use a gist
 62 2017-11-04 14:56:42	0|MarcoFalke|You'd need to fetch the osx sdk somewhere
 63 2017-11-04 14:56:42	0|Provoostenator|My IRC client split the message up in 100 parts, that wasn't the plan.
 64 2017-11-04 14:56:54	0|eck|yes, that is how IRC works
 65 2017-11-04 14:57:08	0|MarcoFalke|I think they are hosted on some apple developer website
 66 2017-11-04 14:57:25	0|MarcoFalke|Also, random people might have uploaded them to GitHub somewhere
 67 2017-11-04 14:57:47	0|MarcoFalke|You can also skip the osx build for now
 68 2017-11-04 14:57:55	0|Provoostenator|I have an Apple developer account, so that should be doable. Do I need to get the old MaxOSX10.11 stuff?
 69 2017-11-04 14:58:35	0|Provoostenator|Skipping it is probably better for now, I'd like to see ifI can get the other builds to work.
 70 2017-11-04 15:02:04	0|MarcoFalke|Refer to https://github.com/bitcoin/bitcoin/blob/master/doc/README_osx.md for instructions to download the apple sdk
 71 2017-11-04 15:03:18	0|Provoostenator|I've seen those instructions; they're not really clear, but I'll give it a shot.
 72 2017-11-04 15:03:50	0|Provoostenator|(I'll make some PR's to improve them once I manage to do a succesfull build)
 73 2017-11-04 15:23:35	0|achow101|Provoostenator: it should be 0.15.1rc1 not v0.15.1rc1
 74 2017-11-04 15:26:02	0|achow101|Provoostenator: there's no --lxc option
 75 2017-11-04 15:26:15	0|achow101|lxc is what it uses by default
 76 2017-11-04 15:26:40	0|Provoostenator|Ok and "signer" needs to be my email (for the PGP key)?
 77 2017-11-04 15:26:48	0|achow101|yes
 78 2017-11-04 15:27:34	0|achow101|does not necessarily need to be your email, could just be your username or some name that GPG recognizes
 79 2017-11-04 15:28:11	0|Provoostenator|Github username?
 80 2017-11-04 15:28:16	0|achow101|yeah
 81 2017-11-04 15:29:29	0|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
 82 2017-11-04 15:30:21	0|Provoostenator|So I should either move my GPG key onto the VM, or just do the actual signing on my machine?
 83 2017-11-04 15:31:06	0|achow101|yes
 84 2017-11-04 15:31:15	0|achow101|I suggest signing on your machine
 85 2017-11-04 15:33:55	0|Provoostenator|debian@debian:~$ bitcoin/contrib/gitian-build.sh -b sjors 0.15.1rc1 --detached-sign
 86 2017-11-04 15:33:55	0|Provoostenator|lxcbr0: ERROR while getting interface flags: No such device
 87 2017-11-04 15:33:57	0|Provoostenator|SIOCSIFADDR: No such device
 88 2017-11-04 15:34:10	0|sipa|you don't have lxc
 89 2017-11-04 15:34:55	0|Provoostenator|I didn't see any obvious errors while doing this: https://github.com/bitcoin-core/docs/blob/master/gitian-building/gitian-building-setup-gitian-debian.md#setting-up-debian-for-gitian-building
 90 2017-11-04 15:51:55	0|Provoostenator|Switching bitcoin repo to master first did the trick. This might be related: https://github.com/bitcoin/bitcoin/pull/11391
 91 2017-11-04 16:34:02	0|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
 92 2017-11-04 16:34:22	0|sipa|what does that mean?
 93 2017-11-04 16:34:23	0|donaloconnor|(FYI - I'm learning the protocol and stepping through the code)
 94 2017-11-04 16:34:34	0|sipa|as in, what do you mean by valid?
 95 2017-11-04 16:35:04	0|donaloconnor|the hash the miners generate for a block
 96 2017-11-04 16:35:30	0|sipa|which validity rule, i mean? difficulty, pow, merkle root commitment, ...?
 97 2017-11-04 16:37:49	0|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
 98 2017-11-04 16:37:58	0|sipa|by definition the hash itself is always valid
 99 2017-11-04 16:38:14	0|sipa|of course, there are many rules that the block has to satisfy
100 2017-11-04 16:38:33	0|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)
101 2017-11-04 16:38:50	0|sipa|it does not verify that anywhere
102 2017-11-04 16:38:56	0|sipa|nobody claims a block has a certain hash
103 2017-11-04 16:39:17	0|sipa|the block itself is propagated
104 2017-11-04 16:39:29	0|sipa|and to be valid, its hash has to satisfy PoW
105 2017-11-04 16:39:48	0|sipa|(but that's only one out of dozens of validity criteria)
106 2017-11-04 16:44:50	0|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?
107 2017-11-04 16:45:02	0|donaloconnor|I guess i'm missing something here, sorry if I'm sounding silly ;)
108 2017-11-04 16:45:15	0|sipa|well then the block will be invalid
109 2017-11-04 16:45:28	0|donaloconnor|well that's what I mean... where does it check that
110 2017-11-04 16:45:35	0|sipa|perhaps we're arguing semantics
111 2017-11-04 16:45:59	0|sipa|but there is no need to check whether the block matches its claimed hash - nobody ever claims it has a particular hash
112 2017-11-04 16:46:08	0|sipa|the hash is computed from the block
113 2017-11-04 16:46:27	0|sipa|the rule is _for a block to be valid_ that its hash is below the target implied by the difficulty
114 2017-11-04 16:46:39	0|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.
115 2017-11-04 16:46:39	0|sipa|and you've already found where that is checked
116 2017-11-04 16:46:49	0|aj|donaloconnor: nodes don't communicate the hashes directly, the communicate the headers (and blocks) and then work out what the hash is
117 2017-11-04 16:46:53	0|sipa|the hash is always the hash of the block contents
118 2017-11-04 16:46:57	0|donaloconnor|ahhh
119 2017-11-04 16:46:58	0|sipa|it is defined as such
120 2017-11-04 16:47:01	0|donaloconnor|maybe that's it
121 2017-11-04 16:47:03	0|donaloconnor|sorry
122 2017-11-04 16:47:19	0|donaloconnor|now I understand...
123 2017-11-04 16:48:07	0|donaloconnor|uint256 hash = block.GetHash(); << this is calculated by the nodes and not transmitted over the wire
124 2017-11-04 16:49:56	0|sipa|exactly
125 2017-11-04 16:50:20	0|donaloconnor|sipa/aj - thanks for the information.
126 2017-11-04 17:03:29	0|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.
127 2017-11-04 17:03:51	0|sipa|sounds like your CPU is overheating
128 2017-11-04 17:03:58	0|fobban|I've got a i7-6700k. Never got these hardware errors before and I only get them once I start bitcoin core again
129 2017-11-04 17:04:25	0|sipa|bitcoin core tends to stress CPUs far more than usual desktop software
130 2017-11-04 17:06:49	0|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
131 2017-11-04 17:09:12	0|fobban|is v0.15 much harder on the cpu than 0.14 was?
132 2017-11-04 17:13:48	0|sipa|yes, it needs to wait much less on memory
133 2017-11-04 17:16:13	0|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.
134 2017-11-04 17:17:03	0|donaloconnor|could be PSU not providing enough power for CPU
135 2017-11-04 17:22:30	0|fobban|Hm, might be temp after all, started to spike to 75C now o_O
136 2017-11-04 17:24:24	0|donaloconnor|maybe, though 75 is not uncommon under high load
137 2017-11-04 17:47:13	0|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?
138 2017-11-04 18:07:45	0|jouke|w/win 14
139 2017-11-04 18:08:50	0|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
140 2017-11-04 18:09:29	0|Provoostenator|./bin/gsign:52:in `<main>': invalid option: --detach-sign (OptionParser::InvalidOption)
141 2017-11-04 18:09:29	0|Provoostenator|Hopefully this isn't a problem:
142 2017-11-04 19:11:40	0|meshcollider|Provoostenator: you can also look at the build logs as it's building, to see how it's going
143 2017-11-04 19:12:01	0|meshcollider|And check for errors
144 2017-11-04 19:22:39	0|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?
145 2017-11-04 19:30:45	0|meshcollider|Provoostenator: hmm I don't think it checks the hashes, just checks the signatures are valid
146 2017-11-04 19:31:53	0|Provoostenator|So how do I check that my hashes match what others found? I compared a few manually and they match.
147 2017-11-04 19:38:46	0|bitcoin-git|[13bitcoin] 15Sjors opened pull request #11607: Add Gitian PGP key: Sjors (06master...06gitian-sjors) 02https://github.com/bitcoin/bitcoin/pull/11607
148 2017-11-04 20:22:50	0|ossifrage|:-( ./libtool: line 1720: 10983 Segmentation fault      (core dumped) /usr/bin/gcc-ar cru .libs/libsecp256k1.a src/libsecp256k1_la-secp256k1.o
149 2017-11-04 21:16:22	0|gmaxwell|ossifrage: hurray compiler bug.. or cpu overheating
150 2017-11-04 21:18:11	0|ossifrage|I was trying (again) to get a flto compile with the current tree. I'm assuming it is a toolchain bug
151 2017-11-04 21:18:35	0|ossifrage|./libtool: line 1720:  1040 Segmentation fault      (core dumped) /usr/bin/gcc-ranlib .libs/libsecp256k1.a
152 2017-11-04 21:19:06	0|gmaxwell|which gcc version
153 2017-11-04 21:20:23	0|ossifrage|gcc is 7.2.1, gcc-ar is 2.27-24
154 2017-11-04 21:21:50	0|ossifrage|Initially I was getting "plugin needed to handle lto object" from /usr/bin/ranlib, so I switched to gcc-{ranlib,ar,nm}
155 2017-11-04 21:23:37	0|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)
156 2017-11-04 21:25:43	0|ossifrage|gmaxwell, I'm compiling the entire tree with lto, it just happened to go boom on libsecp256k1
157 2017-11-04 21:28:17	0|gmaxwell|ossifrage: in any case, I'm jealous, not that often that you get to report a GCC bug. :P
158 2017-11-04 21:38:45	0|esotericnonsense|ossifrage: ryzen gcc segfault bug ?
159 2017-11-04 21:42:44	0|ossifrage|esotericnonsense, this is an old xeon (with ecc) and it is repeatable (so not some thermal silliness)
160 2017-11-04 21:42:54	0|esotericnonsense|ah
161 2017-11-04 22:43:23	0|cfields|gitian builders: v0.15.1rc1 codesigs are _finally_ pushed
162 2017-11-04 22:47:17	0|sava_|hello,
163 2017-11-04 22:47:39	0|sava_|can anyone tell me command to create new wallet address in linux please
164 2017-11-04 22:48:46	0|sipa|sava_: #bitcoin
165 2017-11-04 22:51:02	0|sava_|its BTCGPU for bitcoin gold i installed
166 2017-11-04 22:53:01	0|sipa|sava_: not here, #bitcoin
167 2017-11-04 22:53:24	0|sipa|oh, it's for an altcoin - in that case, no idea
168 2017-11-04 22:53:51	0|sava_|cheers
169 2017-11-04 22:55:06	0|windsok|#bitcoin-forks
170 2017-11-04 23:49:23	0|fanquake|cfields lagging as per usual :p
171 2017-11-04 23:52:19	0|fanquake|Have pushed some signed sigs up.