1 2015-09-25 00:02:01 <gartenzwerg> I'm trying to compile bitcoind from github on Debian, any idea how to fix this: "chainparams.cpp:137: error: too many initializers for 'CCheckpointData'" ?
  2 2015-09-25 00:03:42 <sipa> gartenzwerg: what compiler?
  3 2015-09-25 00:04:02 <gartenzwerg> I think gcc 4.4.5
  4 2015-09-25 00:04:37 <sipa> that sounds pretty old, but i think we should not be using any features that are incompatible with it
  5 2015-09-25 00:05:30 <phantomcircuit> gartenzwerg, what's the commit id?
  6 2015-09-25 00:05:35 <phantomcircuit> git log will show you
  7 2015-09-25 00:06:11 <gartenzwerg> first line shows 34dc03d8e05fa1429d6d543fdb8ee76f28f436ac
  8 2015-09-25 00:06:50 <phantomcircuit> gartenzwerg, have you made any changes?
  9 2015-09-25 00:07:37 <gartenzwerg> no, but I had to install boost and libevent manually, because it was too old, too
 10 2015-09-25 00:09:22 <gartenzwerg> maybe the easiest would be to update my Debian, it's a Debian 6, current version is Debian 8
 11 2015-09-25 00:10:42 <phantomcircuit> gartenzwerg, my guess would be something to do with boost::assign::map_list_of
 12 2015-09-25 00:10:52 <phantomcircuit> sipa, ^
 13 2015-09-25 00:12:12 <sipa> old boost? boost not compatible with gcc?
 14 2015-09-25 00:16:04 <gartenzwerg> maybe, it is the latest boost release, 1.59, now upgrading to Debian Jessie with newer GCC etc.
 15 2015-09-25 00:18:50 <sipa> 1.59 is d
 16 2015-09-25 00:18:55 <sipa> certainly recent enough
 17 2015-09-25 00:19:40 <phantomcircuit> 1.59? that's newer than wheezy
 18 2015-09-25 00:19:52 <sipa> indeed
 19 2015-09-25 00:19:58 <sipa> maybe too recent :p
 20 2015-09-25 01:23:28 <rusty> gmaxwell: OK, I'm confused.  BIP 0001 says "Copyright/public domain -- Each BIP must either be explicitly labelled  as placed in the public domain (see this BIP as an example) or licensed  under the Open Publication License.".  But I can't see where it says it's PD.  And I can't find it for any BIP I glanced at...
 21 2015-09-25 01:24:07 <rusty> btcdrak noted it...
 22 2015-09-25 01:24:39 <gmaxwell> ::sigh::
 23 2015-09-25 01:25:05 <Luke-Jr> rusty: just MITL it :P
 24 2015-09-25 01:26:45 <rusty> gmaxwell, petertodd, sipa: Am assuming PD is OK with everyone for versionbits.  Am appending "copyright" section, and taking your implied permission.
 25 2015-09-25 01:27:10 <gmaxwell> ACK
 26 2015-09-25 01:27:47 <Luke-Jr> annoyingly PD is invalid someplaces
 27 2015-09-25 01:29:05 <rusty> Luke-Jr: Yes, I usually use CC0.  But as a lawyer once explained to me, if you're spending a significant amount of your time on legal issues, you're doing it wrong :)
 28 2015-09-25 01:32:55 <sipa> ACK on PD
 29 2015-09-25 01:48:15 <rusty> gmaxwell: updated PR, did you want me to squash that commit or happy as two commits?
 30 2015-09-25 01:48:24 <phantomcircuit> gmaxwell, 49 GB of blocks reindexed with fScriptChecks = false took 6843 seconds
 31 2015-09-25 01:48:32 <phantomcircuit> so roughly 58mbps
 32 2015-09-25 01:48:59 <phantomcircuit> that's ~75% merkle tree root calculations
 33 2015-09-25 01:50:54 <sipa> phantomcircuit: wut
 34 2015-09-25 01:51:21 <sipa> phantomcircuit: what dbcache?
 35 2015-09-25 01:51:42 <sipa> phantomcircuit: how did you profile merkle tree calculation percentage?
 36 2015-09-25 01:53:12 <phantomcircuit> sipa, 4096
 37 2015-09-25 01:53:35 <phantomcircuit> sipa, about two weeks ago i did it with perf
 38 2015-09-25 01:55:27 <sipa> seems hard to believe... even if sha256 is the bottleneck, transaction hashing would be more work that the internal nodes in the merkle.tree
 39 2015-09-25 01:55:58 <sipa> unless we're computing the merkle tree multiple times for the same block
 40 2015-09-25 01:56:09 <phantomcircuit> sipa, i believe we are still
 41 2015-09-25 01:56:17 <phantomcircuit> i can check that also
 42 2015-09-25 01:57:41 <sipa> phantomcircuit: the merkle computation is cached
 43 2015-09-25 01:58:00 <gmaxwell> if you're seeing 'hashing' high in perf, I wouldn't be surprised if it were actually the heap allocator.
 44 2015-09-25 01:58:53 <sipa> so even if we'd be recreating a CBlock multiple times, we'd still end up spending more sha256 work on transaction hashing (which would need to be repeated in that case too)
 45 2015-09-25 01:59:12 <sipa> gmaxwell: the merkle computation should do one single malloc...
 46 2015-09-25 02:00:41 <phantomcircuit> sipa, hmm possibly the perf result was screwy
 47 2015-09-25 02:00:45 <phantomcircuit> it's certainly happened before
 48 2015-09-25 02:01:30 <sipa> gmaxwell: and my constant-space one is around 1-2% faster (and does no heap things at all)
 49 2015-09-25 02:02:10 <sipa> 1-2% at current block sizes; for massively larger ones, the difference becomes more apparent
 50 2015-09-25 02:02:49 <gmaxwell> but here is an intution... there is 50 gb of data. It's hashed using sha256^2, so 2x over head, then another 2x from hash trees.. is 58mbp/s * 4 a reasonable speed? even for a single core? no.  around 250mbps (*4) is.
 51 2015-09-25 02:03:23 <sipa> gmaxwell: wrong!
 52 2015-09-25 02:04:19 <sipa> there are 4 hashes: 1) tx size 2) 32 bytes 3) 64 bytes 4) 32 bytes
 53 2015-09-25 02:04:23 <phantomcircuit> oh the block data has a checksum on disk also right?
 54 2015-09-25 02:05:28 <sipa> only the first is dominated by that 50GB, the rest is just 4 sha256 transforms per transaction
 55 2015-09-25 02:07:14 <gmaxwell> sipa: sure thats why I thought those numbers were super conservative.
 56 2015-09-25 02:07:20 <sipa> ok
 57 2015-09-25 02:07:33 <sipa> phantomcircuit: hmm, i think so?
 58 2015-09-25 02:07:40 <sipa> not sure
 59 2015-09-25 02:08:44 <sipa> phantomcircuit: nope, no checksum
 60 2015-09-25 02:09:03 <sipa> just magic, length, header, transactions
 61 2015-09-25 02:16:31 <gartenzwerg> ok, Debian is updated, gcc is now 4.9.2, recompiled boost 1.59 with it, now bitcoind compiles and works (and "ldd bitcoind" confirms, that it uses some boost 1.59.0 libs). Looks like gcc 4.4.5 was the problem
 62 2015-09-25 02:17:09 <gartenzwerg> I hate updating Debian live systems :-)
 63 2015-09-25 02:18:45 <sipa> i wonder what in gcc 4.4 is not compatible with bitcoin
 64 2015-09-25 02:21:57 <gartenzwerg> probably some template magic corner case
 65 2015-09-25 02:22:33 <sipa> likely
 66 2015-09-25 02:24:52 <gartenzwerg> C++ is too complex
 67 2015-09-25 02:25:00 <gartenzwerg> someone implemented Snake with template meta programming :-) (so at compile time) http://blog.mattbierner.com/stupid-template-tricks-snake/
 68 2015-09-25 02:25:10 <sipa> lol
 69 2015-09-25 02:27:55 <sipa> http://en.blockchaindownload.nl/all_downloads
 70 2015-09-25 02:28:10 <sipa> ^ can someone check whether those include the chainstate...?
 71 2015-09-25 02:28:41 <gmaxwell> lol ... the bigger question is what malware they include! :P
 72 2015-09-25 02:29:09 <sipa> uh... if they include the binaries too, yeah
 73 2015-09-25 02:33:49 <gmaxwell> sipa: torrent contains a single big rar file.
 74 2015-09-25 02:34:11 <phantomcircuit> that's not a good sign
 75 2015-09-25 02:35:04 <gmaxwell> http://en.blockchaindownload.nl/how_it_works
 76 2015-09-25 02:36:45 <sipa> ugh
 77 2015-09-25 02:43:21 <dstadulis> mailman rejects RTF/html emails, correct?
 78 2015-09-25 10:59:46 <jonasschnelli> I'd like to continue with the bip32 PR and wanted to ask about gmaxwells concerns of public key derivation. If a wallet follows bip44 (m/44'/0'/0'/0/0), the last two levels are unhardened (.../0/0/). Generating external keys (/0/0, /0/1, /0/n) will be non-hardened. Does it mater if it uses public or private key derivation for that level? I assume no.
 79 2015-09-25 11:00:42 <jonasschnelli> i understand the advantage of hardened private key derivation for wallet following a keypath like m/44'/0'/n'
 80 2015-09-25 13:10:06 <moa> wumpus
 81 2015-09-25 13:10:29 <moa> https://github.com/bitcoin/bitcoin/issues/4997 can be closed
 82 2015-09-25 13:34:52 <wumpus> thanks!
 83 2015-09-25 13:56:54 <OxADADA> does bitcoin-core include the bitcoin-cli?
 84 2015-09-25 14:02:55 <wumpus> of the bitcoin.org binary packages, .tar.gz/zips include everything including -tx and -cli
 85 2015-09-25 16:08:22 <sipa> jonasschnelli: you can't use public derivation for hardened levels
 86 2015-09-25 16:09:30 <sipa> jonasschnelli: for non-hardened levels, private derivation or public derivation always result in the same
 87 2015-09-25 16:30:06 <jonasschnelli> sipa: Okay. I see that point. But following bip44 means always use public key derivation. Right?
 88 2015-09-25 16:30:47 <jonasschnelli> if i derive with a keypath of m/44'/0'/0'/0/0, ... it doesn't matter if i derive from master private key of from the last >0</n?
 89 2015-09-25 16:32:03 <sipa> jonasschnelli: every key path corresponds to a single keypair
 90 2015-09-25 16:32:12 <sipa> regardless of how you compute it
 91 2015-09-25 16:33:17 <jonasschnelli> sipa: Okay. Thanks. I just want to make sure i'm understanding it correctly. That means, bip44 is ALWAYS public key derivation because of the last two elements in the keypath 0/0?
 92 2015-09-25 16:33:34 <jonasschnelli> *keypath are 0/0
 93 2015-09-25 16:34:15 <sipa> ?
 94 2015-09-25 16:34:31 <sipa> public derivation only gives you the public key
 95 2015-09-25 16:34:42 <sipa> private derivation gives you bith
 96 2015-09-25 16:34:45 <sipa> both
 97 2015-09-25 16:34:56 <sipa> public derivation doesn't work for hardened paths
 98 2015-09-25 16:35:43 <sipa> and you can choose to use private derivation for one part of the path, and public for another
 99 2015-09-25 16:36:07 <jonasschnelli> sipa: gmaxwell did point out that my Bip32 patch uses always public key derivation for receiving addresses. But does it matter when i derive m/44'/0'/0'/0/0... i can keep the last external chain key pub ext key />0</0 and drive receiving addresses from them?. Private key/signing is clear, i need to derive these over the ext private key.
100 2015-09-25 16:36:43 <jonasschnelli> sipa: i don't see the need for a keypool for bip44... maybe for m/0'/n'
101 2015-09-25 16:37:26 <sipa> jonasschnelli: my guess is that gmaxwell complained about using non-hardened paths, not about how you derive
102 2015-09-25 16:37:50 <jonasschnelli> sipa: okay. So then he indirectly complains about bip44?
103 2015-09-25 16:40:35 <sipa> jonasschnelli: maybe; but using a new account for each new getnewaddress would also avoid the problem
104 2015-09-25 16:40:44 <sipa> gmaxwell: can you comment?
105 2015-09-25 16:41:49 <jonasschnelli> sipa: i think i can easly fix this. The keypath is flexible in my patch... so you could use m/0'/n',.. at the moment only m/0/n (non hardened) is supported, which is bad.
106 2015-09-25 16:42:14 <sipa> jonasschnelli: that wouldn't be bip44 anymore
107 2015-09-25 16:42:36 <jonasschnelli> right...
108 2015-09-25 16:42:49 <sipa> having non-hardened paths at the end is very useful in some use cases
109 2015-09-25 16:42:52 <jonasschnelli> The PR just uses bip44 as standard (if no custom keypath is given)
110 2015-09-25 16:43:11 <sipa> but you can have bip44 with a new account for every address
111 2015-09-25 16:43:13 <jonasschnelli> sipa: agreed,.. it would eliminate also the need for keypools.
112 2015-09-25 16:43:31 <sipa> you still want a keypool to be able to scan
113 2015-09-25 16:43:46 <sipa> but you can generate it on the fly and deterministically
114 2015-09-25 16:43:55 <jonasschnelli> ok.
115 2015-09-25 16:44:36 <sipa> non-hardened paths are very useful in some cases
116 2015-09-25 16:44:57 <jonasschnelli> And i think i keep the separation between hd and non hd keys by having "hdgetaddress" and "hdsend*" rpc commands
117 2015-09-25 16:45:16 <jonasschnelli> would allow smooth transitions for already existing wallets.
118 2015-09-25 16:45:45 <sipa> but using non-hardened paths by default are not something you want to do, especially when you support exporting private keys
119 2015-09-25 16:46:03 <sipa> because one private key leak will leak the whole non-hardened tree
120 2015-09-25 16:46:41 <sipa> so you should just aim to only have one non-hardened path used per hardened parent
121 2015-09-25 16:47:51 <jonasschnelli> sipa: thanks!
122 2015-09-25 17:05:40 <morcos> sipa: sdaftuar and i are going to end up squashing all the tweaks to mempool limiting into your original commit.   i'm happy to leave you as author unless you would prefer us to change it, so questions dont get directed at you in the future (assuming it gets merged)
123 2015-09-25 17:07:32 <sipa> morcos: i don't care, you can change author too and just put something that it was based on my code in the commit message
124 2015-09-25 17:07:56 <morcos> okey doke
125 2015-09-25 17:10:32 <jgarzik> +1
126 2015-09-25 17:10:44 <jgarzik> that's the normal procedure when taking up someone else's work
127 2015-09-25 17:19:31 <jonasschnelli> jgarzik: cfields had some NACK about the univalue stuff. He wrote some commits: https://github.com/theuni/univalue/commits/build-changes
128 2015-09-25 17:19:56 <cfields> jonasschnelli: whoops, forgot to comment there yesterday. will do in just a sec
129 2015-09-25 17:20:05 <jonasschnelli> cfields: np. no hurry
130 2015-09-25 17:22:12 <jgarzik> jonasschnelli, all of those look good to me
131 2015-09-25 17:22:17 <jgarzik> cfields, ^
132 2015-09-25 17:22:33 <cfields> jgarzik: roger, will PR
133 2015-09-25 17:22:38 <jonasschnelli> jgarzik: yes. Looks nice... but let cfields open a PR when he's happy with it
134 2015-09-25 17:22:51 <cfields> jgarzik: stupid nit that i hate to bring up
135 2015-09-25 17:23:00 <cfields> lib/ -> src/ ?
136 2015-09-25 17:23:24 <jgarzik> meh
137 2015-09-25 17:23:25 <jonasschnelli> cfields: it's a lib! :)
138 2015-09-25 17:23:38 <sipa> and the lib has a source!
139 2015-09-25 17:23:44 <cfields> jonasschnelli: heh, src is a convention!
140 2015-09-25 17:23:52 <jonasschnelli> cfields: hah. True. I don't care.
141 2015-09-25 17:23:55 <cfields> and my fingers just want to go there :)
142 2015-09-25 17:24:01 <sipa> let's use more exclamation marks!
143 2015-09-25 17:24:26 <jonasschnelli> cfields: https://github.com/jgarzik/univalue/pull/8/files was this okay? I was trying to avoid m4
144 2015-09-25 17:24:35 <cfields> i only bring it up because i figure if it doesn't change now it never well
145 2015-09-25 17:24:48 <cfields> jonasschnelli: yea, that's the one i intended to nack
146 2015-09-25 17:25:03 <cfields> jonasschnelli: that's very unexpected default behavior
147 2015-09-25 17:25:04 <jonasschnelli> cfields: so better go with AX_CHECK_LINK_FLAG?
148 2015-09-25 17:25:29 <jonasschnelli> *AX_CHECK_LINK_FLAG([[-static]]
149 2015-09-25 17:25:47 <cfields> jonasschnelli: what's the reasoning behind it?
150 2015-09-25 17:26:19 <jonasschnelli> cfields: mingw builds where not possible. UniValue did not support mingw because mingw needs static linking to libc*?
151 2015-09-25 17:27:17 <cfields> jonasschnelli: hmm? works fine without, you just need libgcc/libstdc++ in your env
152 2015-09-25 17:27:35 <jonasschnelli> cfields: https://travis-ci.org/bitcoin/bitcoin/jobs/81928986
153 2015-09-25 17:27:57 <jonasschnelli> no.. wait. wrong one
154 2015-09-25 17:28:33 <cfields> where did the  --all-static come from?
155 2015-09-25 17:28:33 <jonasschnelli> cfields: here: https://travis-ci.org/bitcoin/bitcoin/jobs/81780737#L2613
156 2015-09-25 17:28:34 <cfields> ok
157 2015-09-25 17:28:53 <jonasschnelli> cfields: don't look at /81928986 .. a stupid change that i tried.
158 2015-09-25 17:30:49 <cfields> jonasschnelli: ok, will have a look
159 2015-09-25 17:31:00 <jonasschnelli> cfields: nice. Thanks a lot.
160 2015-09-25 17:31:52 <jgarzik> travis-OSX crunches slowly
161 2015-09-25 17:32:21 <jonasschnelli> Btw: what do you think about removing the "sudo apt-get install" from travis and try to use the new environment with addons: -> apt: -> packages:
162 2015-09-25 17:33:06 <jgarzik> jonasschnelli, (1) yes, (2) you don't need to ditch sudo:required to use addons/apt
163 2015-09-25 17:33:18 <jgarzik> thus you can stage the transition
164 2015-09-25 17:33:42 <sipa> jgarzik: what is travis-OSX?
165 2015-09-25 17:33:48 <sipa> native osx builds?
166 2015-09-25 17:33:52 <jonasschnelli> jgarzik: not sure if removing sudo stuff would allow us to get more cpu horsepower for travis builds?
167 2015-09-25 17:34:08 <jonasschnelli> sipa: travis supports native linux and native osx builds.
168 2015-09-25 17:34:40 <sipa> jgarzik: ideally, for libsecp256k1 we'd just reuse bitcoin's depends for compiling too
169 2015-09-25 17:34:51 <sipa> but native osx builds should work too
170 2015-09-25 17:35:10 <sipa> oh, depends crosscompile won't be able to run tests, i guess
171 2015-09-25 17:35:46 <cfields> jgarzik: why not use depends for the osx build?
172 2015-09-25 17:35:58 <jonasschnelli> sipa: native osx compile would allow to run the tests on native osx. Only Win test would then require wine or another emu.
173 2015-09-25 17:38:28 <jgarzik> cfields, sipa: bitcoin native OSX build: https://github.com/jgarzik/bitcoin/tree/2015_travis_osx
174 2015-09-25 17:38:40 <cfields> jgarzik: yes, i've seen. that's great
175 2015-09-25 17:38:40 <gmaxwell> jonasschnelli: it's strange though to test a binary compiled in a totally different way than the one we'd ship. Not harmful to do as an extra but not really a replacement for testing what we'd actually ship.
176 2015-09-25 17:38:48 <jgarzik> as jonasschnelli says... build & test on native OSX
177 2015-09-25 17:39:12 <Luke-Jr> … do both
178 2015-09-25 17:39:14 <cfields> jgarzik: as above though, why not use depends?
179 2015-09-25 17:39:24 <jgarzik> it's mildly more relevant to univalue as a general lib
180 2015-09-25 17:39:43 <jonasschnelli> gmaxwell: I agree. I also slightly follow a project where i'd like to setup a CI that uses gitian as build source: https://bitcoin.jonasschnelli.ch
181 2015-09-25 17:39:49 <jgarzik> cfields, you mean avoid homebrew?
182 2015-09-25 17:39:57 <jonasschnelli> nightly builds are working... it would require running some tests on vms.
183 2015-09-25 17:40:07 <cfields> jgarzik: yes. That would use our exact shipping config
184 2015-09-25 17:40:24 <sipa> cfields: that doesn't alow running tests, righ
185 2015-09-25 17:40:26 <jgarzik> cfields, short answer, depends didn't work and homebrew did.
186 2015-09-25 17:40:37 <cfields> sipa: it would
187 2015-09-25 17:40:37 <jgarzik> tests worked
188 2015-09-25 17:40:51 <cfields> jgarzik: let's get depends fixed up, then. They should work fine
189 2015-09-25 17:41:09 <sipa> cfields: oh, you mean using depends on OSX to build for OSX?
190 2015-09-25 17:41:18 <jonasschnelli> homebrew often uses patches to mac it osx compatible.
191 2015-09-25 17:41:22 <cfields> sipa: yea. that's a supported config
192 2015-09-25 17:41:38 <sipa> cfields: that's still not the shipped result :)
193 2015-09-25 17:41:39 <cfields> we use depends for osx for our releases anyway
194 2015-09-25 17:42:15 <jgarzik> that's a highly normal config to test
195 2015-09-25 17:42:16 <cfields> sipa: in theory if we grabbed clang from llvm.org rather than using the system toolchain, we could get really close to the shipped result
196 2015-09-25 17:42:35 <cfields> jgarzik: sure, but it's a highly unused result
197 2015-09-25 17:42:52 <sipa> jgarzik: well it's not how releases are built... though people compile natively as well. i think we need both
198 2015-09-25 17:43:23 <sipa> cfields: would that allow us to get rid of gitian? :)
199 2015-09-25 17:43:26 <cfields> sipa: it'd be interesting to see actually how build results compared
200 2015-09-25 17:43:26 <Luke-Jr> both is harmless
201 2015-09-25 17:43:38 <cfields> sipa: the osx build in linux is already deterministic without gitian
202 2015-09-25 17:43:49 <cfields> er, can trivially be made to be, anyway
203 2015-09-25 17:43:49 <jgarzik> with travis we can do all the configs
204 2015-09-25 17:44:08 <sipa> jgarzik: yeah, let's test all the things
205 2015-09-25 17:44:26 <Luke-Jr> BFGMiner currently has 61 builds in Travis. :p
206 2015-09-25 17:44:35 <sipa> 1) osx build on linux, because it's what we actually ship (but we can't test it)
207 2015-09-25 17:45:00 <sipa> 2) osx builds on osx without depends, because it can test what self compiling people get
208 2015-09-25 17:45:10 <Luke-Jr> hmm
209 2015-09-25 17:45:24 <cfields> sipa: docker+travis is interesting and could potentially replace gitian imo
210 2015-09-25 17:45:32 <sipa> 3) osx builds on osx with depends, because it's the closest testable thing we that to what is actually shipped
211 2015-09-25 17:45:33 <Luke-Jr> could we viably do the Linux build in a VM, so we can still test afterward?
212 2015-09-25 17:45:51 <jgarzik> native build > cross build, IMO
213 2015-09-25 17:45:51 <Luke-Jr> does KVM work on Mac?
214 2015-09-25 17:46:16 <cfields> jgarzik: you're not providing any reasons, i'm having trouble following your arguments
215 2015-09-25 17:46:18 <jgarzik> higher Just Works(tm) value
216 2015-09-25 17:46:21 <sipa> jgarzik: you mean for releases or for testing?
217 2015-09-25 17:46:34 <jgarzik> both
218 2015-09-25 17:46:54 <cfields> jgarzik: i'd argue the opposite. it makes it much easier to test a config that's not what you think you're testing
219 2015-09-25 17:47:00 <sipa> jgarzik: for testing, i would argue that we should test what people actually get, and right now what they get is a cross build
220 2015-09-25 17:47:22 <jgarzik> both necessarily implies changing what people get for release
221 2015-09-25 17:47:48 <sipa> regarding native cross build for releases: it's the only way to give people deterministic results currently
222 2015-09-25 17:49:33 <cfields> it's also the only way to get anywhere near a static config on OSX. There, everything revolves around what version of XCode you have installed. For ex, updating to 10.10.6 has the potential to break builds.
223 2015-09-25 17:50:03 <sipa> jgarzik: how do you mean "changing"? current bitcoin releases for osx are cross build from linux... moving away from that would be a change
224 2015-09-25 17:50:08 <sipa> *built
225 2015-09-25 17:50:19 <Luke-Jr> jgarzik: native implies trusting Apple more, and trusting builders more (since fewer people can build)
226 2015-09-25 17:51:14 <sipa> jgarzik: i do think that testing native builds in addition makes a lot of sense though
227 2015-09-25 17:51:57 <cfields> agreed, with the caveat that it only makes sense if we're testing our own build config and not whatever homebrew happens to be shipping
228 2015-09-25 17:52:31 <sipa> cfields: both make sense... one for testing something close to releases, one for testing what likely self-compilers get
229 2015-09-25 17:52:47 <cfields> sipa: sure
230 2015-09-25 18:05:23 <OxADADA> hmm
231 2015-09-25 18:06:20 <OxADADA> cfields: tangentially related i noticed (this mornign) that the bitcoin-core homebrew package is failing. i may create PR later today to fix.
232 2015-09-25 18:09:42 <cfields> jonasschnelli: we advised against it and as far as i was aware there wasn't one
233 2015-09-25 18:10:01 <jonasschnelli> hmm... it looks like it uses the "official" binaries. https://github.com/caskroom/homebrew-cask/blob/master/Casks/bitcoin-core.rb
234 2015-09-25 18:27:00 <OxADADA> jonasschnelli: homebrew uses the official package, and homebrew itself uses the sha256 hash of the package to verify its veracity.
235 2015-09-25 18:27:16 <OxADADA> jonasschnelli: if the hash doesn't match, it wont even unzip the package.
236 2015-09-25 18:27:36 <OxADADA> FWIW
237 2015-09-25 18:29:32 <jonasschnelli> OxADADA: Agreed. Looks good. You just add another layer of trust (you trust homebrew and its formula), which some people could see as risk.
238 2015-09-25 18:30:43 <cfields> OxADADA: ah, that's great
239 2015-09-25 18:31:41 <cfields> jonasschnelli: yep, true. Though i'd say that's very reasonable, considering that without a homebrew package they'd be likely to engage in something riskier
240 2015-09-25 18:32:25 <jonasschnelli> cfields: you could download over bitcoin.org, check sha256 (maybe do a gverify),...
241 2015-09-25 18:33:11 <sipa> they'd still trust the homebrew package to.do.all that :p
242 2015-09-25 18:33:43 <cfields> sure. I was just making the point that for someone who's going to type "brew install bitcoin", homebrew grabbing the verified binaries is a very reasonable outcome imo
243 2015-09-25 18:34:19 <cfields> compared to what they could do instead
244 2015-09-25 18:34:53 <jonasschnelli> agreed.
245 2015-09-25 18:35:28 <jonasschnelli> off-topic: is there no way to ssh-auth with the 256k1 curve?
246 2015-09-25 18:35:39 <jonasschnelli> not supported by openssl/openssh?
247 2015-09-25 18:36:17 <cfields> wasn't it added in one of the latest versions?
248 2015-09-25 18:38:51 <jonasschnelli> cfields: i think only the nistp256, nistp384 and nistp521 curves
249 2015-09-25 18:39:12 <sipa> nistp256 = secp256r1
250 2015-09-25 18:39:18 <sipa> r, not k
251 2015-09-25 18:39:50 <cfields> hmm. I thought i read the announce and made a note to myself to play with coins
252 2015-09-25 18:39:55 <cfields> must've misread at the time
253 2015-09-25 18:40:34 <OxADADA> you can view the homebrew cask package here: https://github.com/caskroom/homebrew-cask/blob/master/Casks/bitcoin-core.rb
254 2015-09-25 18:41:19 <jonasschnelli> OxADADA: i just search a way for displaying the actual formula over the "brew" command line interface... seems not possible.
255 2015-09-25 18:41:48 <OxADADA> jonasschnelli: brew-cask cat bitcoin-core
256 2015-09-25 18:42:17 <jonasschnelli> OxADADA: nice. Thanks
257 2015-09-25 18:42:52 <OxADADA> its actually a "cask", which is an extension for homebrew for installing GUI applications with GUI installers.
258 2015-09-25 18:43:06 <OxADADA> so instead of brew, its easier to use brew-cask
259 2015-09-25 18:43:16 <OxADADA> https://github.com/caskroom/homebrew-cask
260 2015-09-25 18:48:50 <jonasschnelli> cfields: UniValue: is it not common to place the exposed headers in /include?
261 2015-09-25 18:49:08 <jonasschnelli> cfields: similar to https://github.com/bitcoin/secp256k1/tree/master/include
262 2015-09-25 18:49:23 <cfields> jonasschnelli: yes. I was wanting to do that as well
263 2015-09-25 18:52:27 <cfields> jonasschnelli: to be clear, did you have some issue with the headers in that pull req?
264 2015-09-25 18:52:33 <cfields> or just wanted the include path change on top?
265 2015-09-25 18:52:35 <cfields> ok, cya
266 2015-09-25 19:02:59 <jgarzik> cfields, what is glibtoolize?  I don't see that on my Travis VM (Ubu 12) or main dev box
267 2015-09-25 19:03:38 <cfields> jgarzik: it's an osx/bsd thing
268 2015-09-25 19:06:14 <cfields> maybe just osx. IIRC it comes down to darwin having its own "libtool" for dinking with dylibs. The name conflicts with gnu libtool, so it's installed as 'glibtool' there. I believe glibtoolize tracks down the correct tools
269 2015-09-25 19:07:23 <cfields> (if it helps you rest easier, that was ripped from the bitcoin autogen.sh)
270 2015-09-25 20:02:16 <OxADADA> best emoji: ?
271 2015-09-25 20:15:25 <kanzure> does statoshi keep track of how long bitcoind takes until rpc server is available and ready for action?
272 2015-09-25 20:15:34 <kanzure> er, since booting
273 2015-09-25 20:45:14 <OxADADA> this is me IRL: https://youtu.be/o6K8xy7suGo?t=74
274 2015-09-25 21:24:42 <cfields> jgarzik: wrt PR 10, that reverts #8 as discussed here with jonasschnelli. It was merged before I got it fixed up as we discussed
275 2015-09-25 23:36:36 <maaku> sipa: dang I missed a great chance to pre-commit to something to be found in review
276 2015-09-25 23:36:49 <maaku> yeah I made the same observation. safe as long as genesis is not spendable
277 2015-09-25 23:44:18 <sipa> maaku: you should precommit before people start reviewing :)
278 2015-09-25 23:45:01 <maaku> sipa: didn't think of it at the time
279 2015-09-25 23:45:11 <maaku> I don't htink there's anything else in there though, so let me know if you find something!