1 2014-08-07 00:37:13 <iii> is Satoshi around? :o))
2 2014-08-07 00:38:54 <Zarutian> iii: yes?
3 2014-08-07 00:39:24 <iii> so where have you been all this time?
4 2014-08-07 00:40:10 <iii> i don't want to guard your old wallet anymore, should i send it to your email?
5 2014-08-07 00:40:16 <iii> :o))
6 2014-08-07 00:43:06 <Zarutian> iii: fractalized in secure distributed encrypted storage, why do you ask?
7 2014-08-07 00:50:41 <super3> any devs here speak russian?
8 2014-08-07 01:30:14 <jgarzik> nyet
9 2014-08-07 03:40:25 <Luke-Jr> hm
10 2014-08-07 03:41:13 <Luke-Jr> is there any possible way to create a digital signature for a HD watch-only seed, which can be specialised to a signature for a single address, in such a way that the person verifying the signature on the address cannot find out what the watch-seed is?
11 2014-08-07 03:41:16 <Luke-Jr> sipa: ^
12 2014-08-07 04:52:53 <jgarzik> Let the bikeshedding begin.
13 2014-08-07 04:59:49 <Luke-Jr> jgarzik: ok, should I go first?
14 2014-08-07 04:59:50 <Luke-Jr> :P
15 2014-08-07 05:51:28 <atian> hello yawll
16 2014-08-07 05:52:26 <atian> anybody know of any maintained projects that could be added here: http://whatcanidoforbitcoin.org/projects
17 2014-08-07 05:52:58 <atian> is Eloipool still alive Luke-Jr
18 2014-08-07 05:53:11 <Luke-Jr> atian: yes
19 2014-08-07 05:53:54 <Luke-Jr> atian: note present-day cgminer is actually a fork of BFGMiner, not vice-versa
20 2014-08-07 05:53:55 <justanotheruser> atian: brain wallet probably shouldn't be on there
21 2014-08-07 05:54:18 <atian> Luke-Jr: thanks i'll fix that
22 2014-08-07 05:54:43 <justanotheruser> I'd like to see bit-c on there
23 2014-08-07 05:54:57 <Luke-Jr> atian: btw, https://bitcoin.org/en/development already has a list
24 2014-08-07 05:56:00 <atian> justanotheruser: whats your objection to the github repo? i know the site itself is/was inconsiderate providing tha ccorrecthoursebatterystaple
25 2014-08-07 05:56:39 <justanotheruser> atian: it doesn't help bitcoin. I don't think brain wallets are a good idea, and even if they were, you should be using electrum instead of js
26 2014-08-07 05:56:52 <atian> Luke-Jr: eh I'm just updating it b/c https://github.com/bitcoin/bitcoin.org/issues/457
27 2014-08-07 05:57:53 <Luke-Jr> atian: sure, my suggestion is to make interactive the default (so it's not redundant) and include all the projects listed on bitcoin.org already
28 2014-08-07 05:58:37 <atian> Luke-Jr: ah that's what you meant. will do~
29 2014-08-07 06:00:04 <shaileshg> Hi, i just installed bitcoin-qt on mac and am getting this error
30 2014-08-07 06:00:18 <shaileshg> dyld: Library not loaded: /usr/local/lib/libboost_system-mt.dylib
31 2014-08-07 06:00:18 <shaileshg> Reason: image not found
32 2014-08-07 06:00:18 <shaileshg> Referenced from: /usr/local/bin/bitcoind
33 2014-08-07 06:00:18 <shaileshg> Trace/BPT trap: 5
34 2014-08-07 06:00:19 <justanotheruser> shaileshg: #bitcoin
35 2014-08-07 06:00:23 <Luke-Jr> shaileshg: this is not a support channel, please go to #bitcoin and use pastebin!
36 2014-08-07 06:00:30 <shaileshg> Luke-Jr:
37 2014-08-07 06:00:31 <shaileshg> hmm
38 2014-08-07 06:00:57 <shaileshg> but running bitcoind from command line is giving this error.. isn't it kind of developer related problem
39 2014-08-07 06:01:03 <shaileshg> and not support problem
40 2014-08-07 06:08:33 <Luke-Jr> shaileshg: when you're talking about running/using a program, all problems are support problems.
41 2014-08-07 06:08:55 <shaileshg> Luke-Jr: hmm. thanks
42 2014-08-07 06:13:27 <wumpus> as far as my knowledge of mac goes there isn't even a bitcoind for macosx
43 2014-08-07 06:13:58 <wumpus> just the gui
44 2014-08-07 06:15:34 <wumpus> if not, this issue should be closed https://github.com/bitcoin/bitcoin/issues/664
45 2014-08-07 09:05:47 <wumpus> whoa, contributions to documentation are very welcome, but please don't open a pull for every added '.'
46 2014-08-07 09:08:33 <wumpus> just do all your improvements then submit them as one commit in one pull request. if you want to add other changes later you can push to the same branch
47 2014-08-07 09:18:40 <Luke-Jr> lol
48 2014-08-07 09:25:00 <wumpus> I suppose having a file 'INSTALL' in a repository is a convention like 'COPYING', or is it fine to add extensions?
49 2014-08-07 09:25:36 <wumpus> ie, will distributions be assuming anything?
50 2014-08-07 09:25:40 <Luke-Jr> wumpus: extensions wouldn't be "gnu standard"
51 2014-08-07 09:25:46 <Luke-Jr> wumpus: automake assumes no extensions
52 2014-08-07 09:25:52 <wumpus> right
53 2014-08-07 09:25:56 <Luke-Jr> it can probably be hit with a hammer, but meh
54 2014-08-07 09:26:06 <wumpus> nah, I'll just keep it without extension then
55 2014-08-07 09:27:14 <Luke-Jr> wumpus: for my Windows packages, I rename them all to .txt :p
56 2014-08-07 09:27:33 <Luke-Jr> I think Bitcoin Core does too, actually
57 2014-08-07 09:28:09 <wumpus> we actually have something really strange there
58 2014-08-07 09:28:26 <wumpus> oh, not anymore
59 2014-08-07 09:28:55 <wumpus> I remember that ther were some readme files doubly, both one for windows and one for unix, with the same content but different extension :-)
60 2014-08-07 09:29:26 <wumpus> there still a README_windows.txt but it is significantly different from README.md
61 2014-08-07 09:30:59 <Luke-Jr> makes sense, as long as it doesn't replace it :p
62 2014-08-07 09:36:50 <Luke-Jr> wumpus: re OpenRC ACK: did you actually test it? :|
63 2014-08-07 09:40:07 <Luke-Jr> wumpus: a lot of people would probably be upset when it failed to load their wallet :/
64 2014-08-07 09:40:39 <wumpus> I don't think the system-wide bitcoind should load a wallet
65 2014-08-07 09:40:46 <wumpus> it's meant as a block chain service
66 2014-08-07 09:41:23 <Luke-Jr> it does.
67 2014-08-07 09:42:47 <Luke-Jr> even if we pretend it didn't, this PR would redownload it for no reason
68 2014-08-07 09:42:56 <Luke-Jr> (redownload the blockchain)
69 2014-08-07 09:43:10 <wumpus> ok agreed, that's not good
70 2014-08-07 12:07:36 <iii> with every Bitcoin block there is value for nonce, for example it is 2235732852 for block https://blockchain.info/block-index/454662/0000000000000000293988b6826b3f021ffc41be4e2e97e5b79ae27291298ff4
71 2014-08-07 12:08:06 <iii> what happens if block generator would use some random or no value for nonce?
72 2014-08-07 12:08:41 <iii> would block become invalid? e.g. is nonce value used to determine validity of generated block?
73 2014-08-07 12:10:02 <sipa> #bitcoin please
74 2014-08-07 12:10:04 <Apocalyptic> iii, no, the hash is
75 2014-08-07 13:39:22 <melvster> anyone here know when the trezor party is?
76 2014-08-07 13:48:29 <jgarzik> wumpus, sipa, any general opinions on structure, while message processing code movement is occurring? I was thinking of wrapping the code in a trivial "message processor" class, in addition to moving outside main.cpp. https://github.com/bitcoin/bitcoin/pull/4646
77 2014-08-07 13:48:51 <jgarzik> As usual, I don't want to do _too much_ code movement all at code, as that breaks patches and becomes untenable to rebase.
78 2014-08-07 13:51:05 <nomailing> Hey, does anyone know if ECDSA signature creation for a Bitcoin transaction is roughly the same as the verification speed of a transaction?
79 2014-08-07 13:51:35 <jgarzik> nomailing, it is different
80 2014-08-07 13:51:57 <nomailing> do you have some approximate ratio? that would be great
81 2014-08-07 13:52:25 <nomailing> I mean given that you already have the private key
82 2014-08-07 13:54:18 <sipa> jgarzik: i do have some ideas about that
83 2014-08-07 13:54:57 <sipa> jgarzik: though generally wrapping/moving code that logically depends together is nice for code readability, it doesn't actually help modularization
84 2014-08-07 13:55:34 <sipa> jgarzik: see the mess with net/main, which need very ugly hacks to avoid bidirectional dependencies (and ultimately, you still need to look at both to understand what the code is doing)
85 2014-08-07 13:56:16 <jgarzik> sipa, yah, that's why it's just the message processing. I mean to split out the orphan stuff into its own module, Ithink, also.
86 2014-08-07 13:56:36 <sipa> jgarzik: orhpans (at least for blocks) will be *gone* in headersfirst
87 2014-08-07 13:56:49 <jgarzik> sipa, procmsg has a lot of bi-di ties right now, but it can be modularized further once separated IMO
88 2014-08-07 13:57:13 <sipa> jgarzik: what i would want to do is have net expose a generic framework where you register message handlers (for one or a few messages) that each have their own state, with the net implementation guaranteeing locking
89 2014-08-07 13:57:18 <jgarzik> sipa, yep. makes it easy to delete. if it's easier for you, I can keep it in main.cpp, with the presumption of future deletion.
90 2014-08-07 13:57:33 <sipa> jgarzik: so you'd have a ping module, which defines its own per-peer state, and does only handling of ping and pong
91 2014-08-07 13:57:40 <sipa> jgarzik: and a block download module
92 2014-08-07 13:57:47 <sipa> and an alert module
93 2014-08-07 13:59:11 <sipa> jgarzik: and main would just be the validation rules, with those message handlers depending on it, instead of being intermingled with it (with their datastructures in net)
94 2014-08-07 14:05:38 <sipa> jgarzik: so, not really any objection to just doing such encapsulation, but i don't consider it a real solution (nor do i think it really helps towards one), and it will conflict with many things
95 2014-08-07 15:00:50 <wumpus> moving everything that doesn't have to do with validation rules out of main.cpp sounds good to me
96 2014-08-07 15:02:03 <jgarzik> dgenr8, don't worry about addressing me or ranting in this chatroom, as long as it's on-topic :)
97 2014-08-07 15:02:08 <jgarzik> on-topic rants are just fine
98 2014-08-07 15:02:21 <wumpus> and grouping similar functionality into separate implementation files makes sense, even if there are bidirectional ties between them at first
99 2014-08-07 15:02:26 <wumpus> pure code movements are easier to review in any case
100 2014-08-07 15:03:49 <wumpus> but you do know that anything that conflicts with headers-first won't get merged as that has utmost priority? *ducks*
101 2014-08-07 15:05:06 <jgarzik> wumpus, sipa: agreed! I don't want to slow that down.
102 2014-08-07 15:13:06 <jgarzik> wumpus, sipa: agreed! In general, any tiny patch we can peel off from the headers-first branch and push upstream immediately, no matter how trivial, we should do. In the kernel, for large or risky code transitions like this, sometimes you wind up commit intermediate changes, which disappear in a matter of months, once the final changes land.
103 2014-08-07 15:14:59 <jgarzik> Just like steps in an equation, kernel-land pays incredible amounts of attention to the steps taken to arrive at the end result. That really helps if making a risky change to the kernel scheduler, VM or VFS core, the most sensitive subsystems.
104 2014-08-07 15:15:12 <jgarzik> sipa has already been doing this, of course.
105 2014-08-07 15:21:56 <wumpus> jgarzik: I agree, if something more can be peeled off and already committed it should be done
106 2014-08-07 15:36:03 <gmaxwell> jgarzik: already much of headers first has been peeled off and merged, the headers first patches are now fairly small compared to the initial ones.
107 2014-08-07 16:02:03 <michagogo> Has anyone done or seen a comparison of the different iOS wallets?
108 2014-08-07 16:02:07 <michagogo> Gah, wrong channel.
109 2014-08-07 16:14:33 <cfields> wumpus: ping
110 2014-08-07 16:14:43 <iii> pong?
111 2014-08-07 16:15:41 <cfields> wumpus: are there historical reasons for our somewhat random release packing/naming scheme? If not, i'd like to sanify it as part of the gitian rework
112 2014-08-07 16:18:02 <jgarzik> cfields, what does that mean? :)
113 2014-08-07 16:18:32 <gmaxwell> I wondered that too.
114 2014-08-07 16:18:43 <gmaxwell> Was hoping to find context in the backscroll.
115 2014-08-07 16:18:47 <cfields> heh, i swear i can articulate in-person
116 2014-08-07 16:19:03 <cfields> on irc, it comes out all blurry
117 2014-08-07 16:19:12 <cfields> jgarzik: for example, we copy the sources into the windows release zip, for some reason
118 2014-08-07 16:19:52 <gmaxwell> On a general principle we've wanted people to have the sources, and they added hardly any size at all to the releases.
119 2014-08-07 16:19:59 <cfields> for linux, we combine 32+64bit releases, and put them in "32" and "64" folders respectively
120 2014-08-07 16:20:39 <gmaxwell> okay, I accept calling that random. :)
121 2014-08-07 16:20:40 <cfields> i'd just like to make it a bit more customary, so that a 'make deploy' for each platform outputs something ready to be uploaded
122 2014-08-07 16:21:43 <cfields> for ex, linux would be a tarball with bin and share folders, ready to be cp'd to your local prefix. one for 32, one for 64
123 2014-08-07 16:22:59 <cfields> i can just make the changees and we can bikeshed in the PR, was just wondering if those things were ever done purposefully
124 2014-08-07 16:26:48 <gmaxwell> inclusion of the source is purposeful, being able to execute in place (e.g. no copying required) is purposeful. I don't have anything to say against splitting up the archives or fiddling with the lay out (so long as it doesn't break execute in place)
125 2014-08-07 16:29:03 <cfields> ok
126 2014-08-07 16:29:12 <cfields> thanks
127 2014-08-07 17:26:16 <wumpus> cfields: I don't disagree, although I think it makes sense to focus on fixing one thing at a time
128 2014-08-07 17:27:51 <wumpus> cfields: let's get this travis thing working
129 2014-08-07 17:28:20 <cfields> fair enough
130 2014-08-07 17:28:25 <cfields> working on the docs now
131 2014-08-07 17:29:34 <wumpus> reorganizing the download archives means that users have to get used to the new layout, that the bitcoin.org site has to be updated to split 32/64 bit downloads for linux, no big deal but also not something that should be done willy-nilly
132 2014-08-07 17:30:23 <cfields> ok
133 2014-08-07 17:43:54 <cfields> wumpus: i'll ignore for now, but fyi: https://github.com/devrandom/gitian-builder/pull/62
134 2014-08-07 17:48:31 <wumpus> cfields: ok, nice
135 2014-08-07 18:17:41 <wumpus> cfields: btw, the windows zip (not the installer) also has both 32 and 64 executables in it https://www.bitcoin.org/en/download
136 2014-08-07 18:18:22 <cfields> ah, right
137 2014-08-07 18:19:12 <cfields> wumpus: imo, it'd be optimal for 'make deploy' to spit out the final packaging, suitable for distributing
138 2014-08-07 18:19:19 <wumpus> and all the downloads (except the ppa AFAIK) contain a copy of the source in some form
139 2014-08-07 18:19:29 <cfields> that way there's no post-processing needed
140 2014-08-07 18:20:23 <wumpus> possibly, although I do think there's a limit to all that should be stuffed into the makefile
141 2014-08-07 18:21:10 <cfields> well the makefile is aware of all build variables, so it seems the suitable place to me
142 2014-08-07 18:21:43 <wumpus> especially if there are different 'flavors' of builds, it can make sense to do that in an external script, instead of putting everything into a monolithic system
143 2014-08-07 18:22:33 <wumpus> I mean, distributions also all provide their own packaging formats, we don't want make package_debian, make package_ubuntu, make package_fedora etc
144 2014-08-07 18:23:40 <cfields> those are different though, we don't package and distribute them ourselves
145 2014-08-07 18:23:53 <cfields> (well kinda, but it's an external process)
146 2014-08-07 18:24:34 <wumpus> in principle our gitian builds are only one of the many flavors of packaging
147 2014-08-07 18:24:51 <cfields> besides, it's context-aware. Right now if you 'make deploy' in a windows build, it uses nsis to build an exe installer. For mac, it builds a dmg
148 2014-08-07 18:25:00 <wumpus> sure, but the source doesn't care what we distribute and don't distribute :)
149 2014-08-07 18:25:23 <cfields> hmm?
150 2014-08-07 18:25:44 <wumpus> IMO the build system should build the executables, then the result can be packaged in any way desired
151 2014-08-07 18:26:10 <cfields> i disagree, but i could live with it. Manual post-processing is what's out of the question, imo
152 2014-08-07 18:26:50 <gmaxwell> wumpus: annoyingly the varrious packaging systems expect to build the binaries themselves.
153 2014-08-07 18:27:02 <wumpus> cfields: a script isn't really 'manual' is it
154 2014-08-07 18:27:28 <wumpus> gmaxwell: well at most they call configure/make
155 2014-08-07 18:28:24 <cfields> wumpus: no, but a script isn't privy to build config details, so manual intervention is still likely needed
156 2014-08-07 18:28:32 <cfields> (version numbers, etc)
157 2014-08-07 18:29:05 <gmaxwell> cfields: hm? packaging build scripts should be taking a dist tarball as input.
158 2014-08-07 18:29:54 <cfields> wumpus: seems i've found myself arguing something that really isn't a big deal. We can discuss when I PR the gitian changes after the travis stuff, so we're not discussing so abstractly
159 2014-08-07 18:31:35 <wumpus> cfields: sure, making things part of the build system allows gaining some inside information, but I also think it makes things less flexible ... everytime someone wants to package in a different way, they'd want to integrate it into the build system
160 2014-08-07 18:31:37 <cfields> gmaxwell: post-processing. For example, you take the dist tarball and configure/make. Now you have bitcoin-qt.exe. But you need it packaged in bitcoin-x.y.z.zip.
161 2014-08-07 18:33:00 <wumpus> cfields: well if you get a dist-x.y.z.tar.gz as input, you know x y and z
162 2014-08-07 18:33:43 <gmaxwell> cfields: okay, we're probably talking past each other. In the example of (say) a fedora rpm, the workflow works like the rpm spec has the version number put into it and using that it fills out a template path for the dist tarball, then builds the binaries, and the package (all knowing the version number from the spec config)
163 2014-08-07 18:34:51 <gmaxwell> What I've been thinking is perhaps there should be rpm/ppa/etc setups that work by taking a binary gitian build as input, checks the gitian sigs, and repackages.
164 2014-08-07 18:34:58 <cfields> gmaxwell: yea, we're talking about different things. I'm setting aside the linux/distro issue for now, and addressing how we generate the end-result files that we actually distribute
165 2014-08-07 18:35:06 <michagogo> 21:19:16 <wumpus> and all the downloads (except the ppa AFAIK) contain a copy of the source in some form <--I think there's some kind of apt-source command, but ICBW
166 2014-08-07 18:35:21 <cfields> gmaxwell: i agree with that.
167 2014-08-07 18:36:41 <wumpus> michagogo: true
168 2014-08-07 18:37:49 <cfields> gmaxwell: unless you were using an rpm spec as an example of how we should build our end-result files, in which case, you were indeed talking directly above my head :)
169 2014-08-07 19:15:07 <Anduck> http://0bin.anduck.net/paste/tXmaFbck#9azQKGTl
170 2014-08-07 19:15:12 <Anduck> what might cause this?
171 2014-08-07 19:15:41 <sipa> Anduck: a client sending garbage
172 2014-08-07 19:15:44 <sipa> *peer
173 2014-08-07 19:15:51 <sipa> nothing to worry about
174 2014-08-07 19:15:57 <Anduck> ok, thanks
175 2014-08-07 19:59:25 <ajweiss> hmm
176 2014-08-07 20:00:21 <ajweiss> so i guess this is starting to lead towards adding a new default to GetConfigFile() that points to a systemwide config file
177 2014-08-07 20:01:29 <gmaxwell> ajweiss: context?
178 2014-08-07 20:01:39 <ajweiss> PR 4611, the init scripts
179 2014-08-07 20:02:12 <wumpus> just use -conf=...
180 2014-08-07 20:02:42 <ajweiss> right but, ideally you'd want to install the thing and be able to just run bitcoin-cli and have it just work, right?
181 2014-08-07 20:03:08 <gmaxwell> Bitcoind is still really not all that sutiable for system wide install
182 2014-08-07 20:03:15 <wumpus> ajweiss: good point...
183 2014-08-07 20:03:22 <wumpus> ajweiss: I hadn't thought about the client at all
184 2014-08-07 20:03:34 <gmaxwell> no sane way to handle the wallet. And only a portion of users want it without a wallet.
185 2014-08-07 20:03:46 <wumpus> wallet should be disabled for systemwide-install
186 2014-08-07 20:03:47 <ajweiss> well it seems to me that the real killer app
187 2014-08-07 20:04:04 <ajweiss> is making install and updating easy so people will run p2pool
188 2014-08-07 20:04:09 <wumpus> ajweiss: yep
189 2014-08-07 20:04:21 <gmaxwell> wumpus: I agree. Failing to disable it leads to weird outcomes where you don't realize where the wallet is and fail to back it up, or don't realize all the users can access it, etc.
190 2014-08-07 20:04:24 <wumpus> the point is just to run it like any other daemon
191 2014-08-07 20:04:39 <wumpus> and it provides block chain services to whatever else is running one the server
192 2014-08-07 20:04:52 <ajweiss> so i think security should be tight
193 2014-08-07 20:04:54 <wumpus> wallet should not be part of that, IMO, that's up to individual users, or applications
194 2014-08-07 20:04:59 <ajweiss> bitcoind user and group
195 2014-08-07 20:05:02 <wumpus> gmaxwell: exactly
196 2014-08-07 20:05:31 <ajweiss> ok killing the wallet sounds good
197 2014-08-07 20:06:20 <ajweiss> that wouldn't break the p2pool usecase, would it? i suspect miners probably use cold wallets for that stuff, no?
198 2014-08-07 20:06:26 <wumpus> ajweiss: but yeah for systemwide installs there should be a way to make bitcoin-cli do the right thing by default, maybe a compile-time option
199 2014-08-07 20:06:55 <gmaxwell> wumpus: I don't think there would be any harm in testing a sequence.
200 2014-08-07 20:07:19 <gmaxwell> if the -conf isn't set, try ~/.bitcoin/bitcoin then /etc/something
201 2014-08-07 20:07:27 <wumpus> gmaxwell: for the client, agreed!
202 2014-08-07 20:07:58 <wumpus> for the server I'm not so sure it should try to be intelligent about finding config files
203 2014-08-07 20:08:08 <gmaxwell> I agree, it should not.
204 2014-08-07 20:09:21 <ajweiss> hmm, that could be simple enough
205 2014-08-07 20:09:32 <gmaxwell> The current pattern of requiring a conf file to start is helpful in the sense that it makes it more likely people will get the paths right. It's not helpful because it results in users inventing their own authentication credentials, and they often do so in insecure ways.
206 2014-08-07 20:09:34 <wumpus> ajweiss: I do know miners today use 'getblocktemplate' which doesn't rely on the wallet. but apart from that I don't know how it interacts with bitcoind
207 2014-08-07 20:09:37 <Luke-Jr> killing the wallet will break existing deployments
208 2014-08-07 20:09:46 <gmaxwell> wumpus: p2pool works fine with disable wallet.
209 2014-08-07 20:09:55 <wumpus> gmaxwell: great
210 2014-08-07 20:10:01 <gmaxwell> Luke-Jr: they can just turn it back on, it's a setting.
211 2014-08-07 20:10:08 <wumpus> Luke-Jr: uhm, 'killing' is very relative here
212 2014-08-07 20:10:13 <Luke-Jr> gmaxwell: they might not know they need to
213 2014-08-07 20:10:24 <gmaxwell> Luke-Jr: they'll notice when all the wallet related rpcs do not work.
214 2014-08-07 20:10:34 <Luke-Jr> gmaxwell: keep in mind this is Gentoo. they're explicitly building it *with* wallet support in this case.
215 2014-08-07 20:10:44 <gmaxwell> Luke-Jr: in gentoo you'll news it and they'll get prompted to merge the configs or whatever.
216 2014-08-07 20:11:02 <Luke-Jr> oh, I guess if it's done via the config it'll be okay
217 2014-08-07 20:11:04 <gmaxwell> But seriously, I have only ever heard of system wide wallets ending in tears.
218 2014-08-07 20:11:19 <gmaxwell> yea, it would just be the default conf created on install.
219 2014-08-07 20:11:26 <Luke-Jr> gmaxwell: well, that problem is more of "wallet on a server" IMO
220 2014-08-07 20:11:34 <ajweiss> if there's gonna be a news item, does that mean we can /var/lib/bitcoin/.bitcoin -> /var/lib/bitcoin?
221 2014-08-07 20:11:45 <Luke-Jr> ajweiss: no point
222 2014-08-07 20:11:57 <Luke-Jr> ajweiss: -e it if you want
223 2014-08-07 20:12:05 <ajweiss> am i the only one who's bothered by it? : )
224 2014-08-07 20:12:10 <gmaxwell> default conf will be rpcuser=bitcoinrpc rpcpassword=/crapfrom/dev/urandom disablewallet=1
225 2014-08-07 20:12:11 <Luke-Jr> probably :P
226 2014-08-07 20:12:17 <wumpus> Luke-Jr: you can always enable it, but by default it should be disabled
227 2014-08-07 20:12:22 <gmaxwell> ajweiss: who'd be crazy enough to use packaged bitcoin?
228 2014-08-07 20:12:35 <gmaxwell> :P
229 2014-08-07 20:12:45 <ajweiss> fair...
230 2014-08-07 20:12:48 <wumpus> gmaxwell: well on distributions where it's up to date, why not :)
231 2014-08-07 20:13:06 <wumpus> lots of people use the PPA
232 2014-08-07 20:13:20 <gmaxwell> wumpus: because it installs in /var, where my wallet won't get backed up and where it runs the var partition out of space. :P
233 2014-08-07 20:13:25 <Luke-Jr> Gentoo ebuild is far better than multi-signed static binary IMO
234 2014-08-07 20:13:41 <Luke-Jr> gmaxwell: only if you use the init script :P
235 2014-08-07 20:13:44 <wumpus> gmaxwell: oh, sure, but like any daemon you can change the config after installing
236 2014-08-07 20:13:48 <ajweiss> i mean even if you don't want to use packages, it is nice to supply some helpers for building/installing youself
237 2014-08-07 20:13:53 <gmaxwell> Luke-Jr: proxy your gentoo host behind me and we'll see how long you repeat that claim. :P
238 2014-08-07 20:14:34 <Luke-Jr> gmaxwell: ebuilds are signed you know
239 2014-08-07 20:14:47 <gmaxwell> not usefully. but we're going off-topic.
240 2014-08-07 20:15:20 <Luke-Jr> pretty sure there's some portage option to verify the signatures..
241 2014-08-07 20:15:23 <Luke-Jr> ACTION should enable it
242 2014-08-07 20:15:32 <gmaxwell> Luke-Jr: doesn't work for me.
243 2014-08-07 20:15:38 <gmaxwell> (thus the not usefully)
244 2014-08-07 20:16:08 <Luke-Jr> I thought that was just the initial download?
245 2014-08-07 20:16:27 <wumpus> so gentoo is trivially mitm-able by default? that's not good, most other distros do verify package signatures usefully these days, as far as I know
246 2014-08-07 20:17:10 <gmaxwell> wumpus: the verification is broken in various degrees for everyone.. though some worse than others. E.g. for some (e.g. fedora) you need to intercept the inital OS download.
247 2014-08-07 20:17:41 <wumpus> intercepting the initial OS download doesn't count IMO
248 2014-08-07 20:18:02 <gmaxwell> debian appears to do best, but even there their build hosts are notoriously insecure.
249 2014-08-07 20:18:13 <pigeons> i setup a java library repository that maven uses and you have to pay to get ssl enabled when downloading the libs from their central repo
250 2014-08-07 20:18:28 <gmaxwell> wumpus: well, it shouldâ since it's certantly something an attacker with control of your network could do.
251 2014-08-07 20:18:42 <iwilcox> pigeons: Maven and all its ilk are evil in this respect, and I hate them all.
252 2014-08-07 20:18:53 <wumpus> gmaxwell: but I mean, how the user gets the initial image is up to them
253 2014-08-07 20:18:57 <hearn> pigeons: not any more
254 2014-08-07 20:19:03 <hearn> pigeons: they fixed that a few days ago
255 2014-08-07 20:19:10 <gmaxwell> wumpus: there is no safe way to obtain fedora, except maybe drive to a redhat office or something. :)
256 2014-08-07 20:19:12 <pigeons> hearn: col thanks
257 2014-08-07 20:19:17 <hearn> gmaxwell: they don't serve it via SSL?
258 2014-08-07 20:19:23 <wumpus> gmaxwell: lol, okay
259 2014-08-07 20:19:43 <ajweiss> ok, so i'm gonna test for /var/lib/bitcoin/.bitcoin and if no default to /var/lib/bitcoin. i'll also disable the wallet by default. the suggested password stuff is a little weird though...
260 2014-08-07 20:19:57 <hearn> pigeons: until there's a new maven you have to reconfigure it to use ssl though. i posted instructions to the bitcoin-development list
261 2014-08-07 20:20:12 <hearn> however security on maven central is still shitty. no two factor authentication, instead they insist on some theater involving pgp keys.
262 2014-08-07 20:20:17 <Luke-Jr> ajweiss: don't forget to make rpcuser optional again :p
263 2014-08-07 20:20:23 <hearn> luckily Central has some competitors these days. i keep meaning to upload our jars there.
264 2014-08-07 20:20:26 <gmaxwell> hearn: mirrors are all http/ftp. There probably are some what are SSL, but that does nothing against a state-level attacker, or an attacker near the mirror... and thats not the URL people are given.
265 2014-08-07 20:20:27 <ajweiss> oh yeah definitely, didn't know about that
266 2014-08-07 20:20:35 <hearn> gmaxwell: :(
267 2014-08-07 20:20:56 <wumpus> gmaxwell: also no signatures file that can be verified separately?
268 2014-08-07 20:20:58 <gmaxwell> (the iso's are PGP signed, but they're signed with a pgp key thats per release, not signed by anything tracable, and just served by the same place as the iso)
269 2014-08-07 20:21:01 <ajweiss> and i'll change the messaging to get people to run it for themselves once by hand to get a suggested password
270 2014-08-07 20:21:05 <wumpus> ohh, useful!
271 2014-08-07 20:21:08 <hearn> a pgp key per release?!
272 2014-08-07 20:21:15 <hearn> fail
273 2014-08-07 20:21:30 <ajweiss> that'll close this guy out... then i'll open a new PR for a fix to bitcoin-cli to have it check /etc for a conf file
274 2014-08-07 20:21:34 <Luke-Jr> makes sense, but only with a master key signing each one
275 2014-08-07 20:21:45 <gmaxwell> Yep. So I've complained about this, so perhaps they'll fix it for the next release. I suggest that each release key be signed by the prior release and some well known persistant keys of employees responsible for it.
276 2014-08-07 20:21:48 <Luke-Jr> ajweiss: would be good for someone to actually test that it doesn't break anything too
277 2014-08-07 20:21:56 <hearn> why does it make sense? key rotation should not be connected to release cycles, the requirements are different
278 2014-08-07 20:22:14 <ajweiss> luke-jr: bitcoin-cli or the init scripts?
279 2014-08-07 20:22:17 <hearn> well, nobody would verify the signatures anyway really.
280 2014-08-07 20:22:27 <gmaxwell> hearn: makes sure that it gets rotated, and the release cycles work in the sense that they can make the new release contain the new pubkey and the packages for that release all signed with it.
281 2014-08-07 20:22:28 <Luke-Jr> ajweiss: init scripts
282 2014-08-07 20:22:34 <pigeons> gmaxwell: wow i assumed they would do that at least, sign with the previous release key and public well-connected developers if they were doing the per-release key thing, thats nuts,
283 2014-08-07 20:23:12 <gmaxwell> hearn: seemingly not, but apparently people try and fail and just give up. After reporting it I found other people say "oh I saw that too" ... "did you do anything about it??" "no".
284 2014-08-07 20:23:25 <gmaxwell> Just having the risk that some people are doing it is protective, if not ideal.
285 2014-08-07 20:23:27 <ajweiss> luke-jr: well i've done some stuff on my gentoo box, but breakage seems that it would come from funky localisms and whatnot
286 2014-08-07 20:23:40 <gmaxwell> Of course it's a waste of time to even try because pratically everything is like this.
287 2014-08-07 20:23:55 <hearn> well, the commercial OS's get it right
288 2014-08-07 20:24:02 <hearn> linux companies should be held to at least the same standard
289 2014-08-07 20:24:16 <ajweiss> i'm not sure how to get it out into the hands of some other testers
290 2014-08-07 20:24:25 <Luke-Jr> ajweiss: I mean install the current package, let it sync, then install the new one and make sure it uses the existing data
291 2014-08-07 20:24:41 <gmaxwell> I've started doing this for everything I install, and complaining politely. Its a huge pain. E.g. portable OpenSSH ... signed with one key, key on the site that they ship along with the tarballs? it's a different key. (an old one- they rotated, never updated the file on the site)
292 2014-08-07 20:24:41 <Luke-Jr> gmaxwell: http://wiki.gentoo.org/wiki/GLEP:57 seems to be a first step
293 2014-08-07 20:24:49 <ajweiss> oh yeah, i can do that
294 2014-08-07 20:25:48 <ajweiss> i'll just use the existing ebuild, start a sync... stop it, drop in the new init script, restart and make sure it stays where it should
295 2014-08-07 20:26:35 <hearn> gmaxwell: i predict you will get tired of that
296 2014-08-07 20:27:02 <hearn> apple is meglomanic but they've succeeded at making signed software with a chain of trust back to the hardware actually work
297 2014-08-07 20:27:10 <gmaxwell> hearn: sure, but I've gotten a fair number of things fixed. After a point it just becomes a ritual in any case.
298 2014-08-07 20:27:11 <hearn> which is no small thing
299 2014-08-07 20:27:45 <gmaxwell> right now what I'm mostly doing is trying, failing, sending an email. Over time I'll crank up my level of nagging.
300 2014-08-07 20:29:09 <gmaxwell> Luke-Jr: I'd like to help get gentoo to a point where the whole system does determinstic builds, and everyone running gentoo can post gitian style signatures which should be identical for everyone with identical cflags/use flags...
301 2014-08-07 20:29:42 <Luke-Jr> gmaxwell: right. I ended up trying to hack GCC to do deterministic output, but I couldn't navigate its code :/\
302 2014-08-07 20:29:56 <Luke-Jr> gmaxwell: I wanted it to set -frandom-seed from a hash of the preprocessed code
303 2014-08-07 20:30:08 <ajweiss> is there such a thing as two gentoo people with identical cflags/use flags?
304 2014-08-07 20:30:27 <sipa> ajweiss: sure, those who have just completed installing a stage3
305 2014-08-07 20:30:32 <gmaxwell> ajweiss: sure, default installs... and multiple systems run by the same people.
306 2014-08-07 20:30:46 <Luke-Jr> ajweiss: for certain packages
307 2014-08-07 20:30:49 <hearn> this assumes you verified the binary ISO first, right?
308 2014-08-07 20:31:26 <Luke-Jr> ajweiss: in theory, you don't need to check every USE flag, just the ones actually in use
309 2014-08-07 20:31:39 <Luke-Jr> (and dependencies of course)
310 2014-08-07 20:32:42 <gmaxwell> hearn: all of free software should be rebootstrappable starting from a PDP11 yanked out of a computer museum, but it doesn't make sense to do that effort until there exist a determinsitic full distro capable of building whatever modern stuff.
311 2014-08-07 20:33:12 <Luke-Jr> gmaxwell: ._.
312 2014-08-07 20:33:13 <sipa> can we start with an abacus, please?
313 2014-08-07 20:33:59 <ajweiss> or like bletchley park, where they bootstrapped everything from memory
314 2014-08-07 20:34:34 <Luke-Jr> gmaxwell: what happens when the CPU microcode is backdoored? :P
315 2014-08-07 20:34:55 <gmaxwell> Luke-Jr: you do multiple independant bootstraps, see david wheeler's thesis.
316 2014-08-07 20:35:16 <Luke-Jr> off-topic: anyone have any ideas on how I might identify/reverse engineer a battery charging command/signal?
317 2014-08-07 20:35:36 <Luke-Jr> gmaxwell: I mean the code is deterministically matched and uninfected, but the CPU backdoor makes it behave differently
318 2014-08-07 20:35:50 <gmaxwell> oh sure, different set of problems.
319 2014-08-07 20:36:18 <gmaxwell> But that one is harder to make progress on, but is also pointless unless you can verify that the software is good.
320 2014-08-07 20:36:48 <ajweiss> luke-jr: command/signal? in where?
321 2014-08-07 20:37:33 <Luke-Jr> ajweiss: I've been working on replacing the software stack on my Nest thermostat, but found its battery just runs out and dies despite having a power source 24/7 :/
322 2014-08-07 20:37:53 <Luke-Jr> so I presume there's some way to enable/disable the battery charger, but no idea how to figure out what that is
323 2014-08-07 20:38:10 <gmaxwell> Luke-Jr: strace the process and make something that calls all the same syscalls?
324 2014-08-07 20:38:26 <Luke-Jr> gmaxwell: it's one big blob that does EVERYTHING
325 2014-08-07 20:38:33 <gmaxwell> oh. :(
326 2014-08-07 20:38:44 <sipa> "Why is it so hot in here?" - "I overclocked my Nest"
327 2014-08-07 20:38:48 <Luke-Jr> gmaxwell: there's also a 2nd CPU that is likely involved in the charging, which I've only mostly figured out the interfaces for
328 2014-08-07 20:39:14 <gmaxwell> #include <nag_about_more_productive_things_you_could_be_working_on.h>
329 2014-08-07 20:39:17 <ajweiss> i always thought that charging circuits tended to be pretty standalone since malfunctions can cause fires and stuff
330 2014-08-07 20:40:01 <Luke-Jr> gmaxwell: I know, but I don't like Google spying on and having the capability to burn my house down
331 2014-08-07 20:40:05 <ajweiss> have you checked to make sure the battery is still good?
332 2014-08-07 20:40:16 <Luke-Jr> ajweiss: with Nest's software running, it charges to full
333 2014-08-07 20:40:23 <ajweiss> hrm
334 2014-08-07 20:47:04 <ajweiss> that's actually pretty scary to think that the charging circuit is controlled by the same software that talks on the internet. i can already imagine a blackhat talk about remote controlled arson...
335 2014-08-07 20:47:47 <gmaxwell> well most likely any nonsense there just burns something out... actual fires are still not likely even with heavily overcharged batteries.
336 2014-08-07 20:48:05 <Luke-Jr> gmaxwell: turn on my heater until things just combust?
337 2014-08-07 20:48:23 <ajweiss> heaters usually have overtemp switches
338 2014-08-07 20:48:25 <Luke-Jr> or turn on my AC until I freeze to death?
339 2014-08-07 20:48:26 <gmaxwell> Luke-Jr: why not just get rid of the nest then, it'll take less time than reverse engineering it.
340 2014-08-07 20:48:48 <gmaxwell> Luke-Jr: you might notice the freezing to death in progress; unless you're too busy reverse engineering the nest to notice.
341 2014-08-07 20:48:54 <Luke-Jr> :P
342 2014-08-07 20:49:00 <ajweiss> no it would be like stuxnet... it would figure out whether you like it warm or cold, do the opposite just a little bit and lie about the temp to slowly drive you insane
343 2014-08-07 20:49:09 <gmaxwell> hah
344 2014-08-07 20:49:13 <Luke-Jr> rofl
345 2014-08-07 20:50:14 <Luke-Jr> gmaxwell: I'm so far along, it'd be a shame to give up? :p
346 2014-08-07 20:52:17 <sipa> Luke-Jr: you should never play poker
347 2014-08-07 20:52:30 <Luke-Jr> XD
348 2014-08-07 20:53:04 <gmaxwell> Luke-Jr: I've got a nice 1 Bitcoin here that I'm going to auction off, I'll even bid on it to. I bid 0.01 bitcoin. Whats your bid?
349 2014-08-07 20:53:28 <gmaxwell> (note: in this auction you pay even if you lose)
350 2014-08-07 20:53:43 <sipa> thanks for mentioning that in time
351 2014-08-07 20:54:02 <Luke-Jr> gmaxwell: I don't think I will bid.
352 2014-08-07 20:54:11 <sipa> I think you will.
353 2014-08-07 20:54:16 <Luke-Jr> lol
354 2014-08-07 20:54:32 <Luke-Jr> gmaxwell can always bid it up at no cost to himself :p
355 2014-08-07 20:54:38 <sipa> Your powers of observation continue to serve you well
356 2014-08-07 20:56:12 <Luke-Jr> anyhow, seriously. I have pretty much everything working, just no way to keep the battery topped off
357 2014-08-07 21:02:13 <ajweiss> have you thrown hexrays at it?
358 2014-08-07 21:02:28 <sipa> i read 'hexarrays'
359 2014-08-07 21:03:34 <Luke-Jr> ajweiss: http://gtvhacker.com/index.php/Nest_Hacking :p
360 2014-08-07 21:06:35 <Luke-Jr> oh, hexrays was a real suggestion XD
361 2014-08-07 21:08:09 <ajweiss> another option would be to use a hall effect sensor to figure out when its charging so you know where to look in the strace stream
362 2014-08-07 21:08:35 <sipa> i think this is getting too offtopic...
363 2014-08-07 21:11:00 <Luke-Jr> yeah, sorry
364 2014-08-07 21:15:04 <ajweiss> ok so the existing gentoo script expects the conf file to live in the datadir... i'm just going to test -e for /var/lib/bitcoin/.bitcoin and if so, default to the paths from the old script, otherwise /etc/bitcoind.conf and /var/lib/bitcoind
365 2014-08-07 21:18:05 <Luke-Jr> ajweiss: the existing gentoo script reads the conf from the datadir, but the datadir has a symlink to /etc/bitcoin/bitcoin.conf
366 2014-08-07 21:18:45 <Luke-Jr> which is where the actual file is installed
367 2014-08-07 21:19:10 <Luke-Jr> /var/lib is not config protected, so it's already broken for users to try to change the symlink out
368 2014-08-07 21:19:31 <Luke-Jr> no reason not to get rid of the symlink
369 2014-08-07 21:20:42 <ajweiss> do you think it's messy to have a mix of bitcoin and bitcoind?
370 2014-08-07 21:22:59 <ajweiss> i think it's kinda nice to draw a distinction between bitcoin (or bitcoin-qt) the gui software users run on their own and bitcoind the system service
371 2014-08-07 21:28:37 <Luke-Jr> the config file is used by both
372 2014-08-07 21:28:43 <Luke-Jr> it doesn't make sense to use separate ones for each
373 2014-08-07 21:33:12 <ajweiss> true, i suppose even with things in a more "systemy" layout it's entirely possible that people may want to fire up the gui every once in a while
374 2014-08-07 21:34:05 <ajweiss> i guess i'm just daydreaming about the day when the node backend and the gui wallet are fully separated
375 2014-08-07 21:34:32 <sipa> s/gui //
376 2014-08-07 21:34:53 <Luke-Jr> someday âº
377 2014-08-07 21:37:37 <ajweiss> ok and i'm not gonna suggest any passwords here lest they get logged and end up somewhere they shouldn't be
378 2014-08-07 21:44:50 <cfields> michagogo: ping
379 2014-08-07 22:32:49 <ahmed_> anyone here good with gitian builds?
380 2014-08-07 22:33:56 <jvv_> Fastest bitcoin miner out there 30 TH/s Free 24hours trial - www.bitcomin.com
381 2014-08-07 22:34:17 <sipa> not here
382 2014-08-07 22:34:28 <jvv_> ??
383 2014-08-07 22:34:40 <jvv_> Fastest bitcoin miner out there 30 TH/s Free 24hours trial - www.bitcomin.com
384 2014-08-07 22:35:25 <cfields> ahmed_: shoot
385 2014-08-07 22:58:31 <Luke-Jr> O.o
386 2014-08-07 23:00:44 <gmaxwell> Some of these bans are in #bitcoin-global-bans
387 2014-08-07 23:52:44 <ahmed_> cfields: getting this when compiling
388 2014-08-07 23:52:58 <ahmed_> bash: cannot set terminal process group (-1): Inappropriate ioctl for device
389 2014-08-07 23:52:58 <ahmed_> --- Building for precise amd64 ---
390 2014-08-07 23:52:58 <ahmed_> Making a new image copy
391 2014-08-07 23:52:58 <ahmed_> Stopping target if it is up
392 2014-08-07 23:53:44 <cfields> ahmed_: ah, problem with gitian itself..
393 2014-08-07 23:55:04 <cfields> ahmed_: i've not seen that one. you might ping devrandom next time he's around
394 2014-08-07 23:55:53 <ahmed_> aww maan