1 2013-09-08 00:04:30 <warren> Luke-Jr: I have more additions on top of your db4 detection patch
2 2013-09-08 00:04:41 <warren> Luke-Jr: should I wait until your commit is added then do my own PR?
3 2013-09-08 00:14:25 <warren> Luke-Jr: sent pull request to your autoconf branch
4 2013-09-08 00:19:44 <Luke-Jr> warren: huh? Fedora puts headers in /usr/include/libdb4 ?
5 2013-09-08 00:20:18 <warren> Luke-Jr: yes
6 2013-09-08 00:20:22 <warren> Luke-Jr: for years now
7 2013-09-08 00:20:40 <Luke-Jr> ugly. maybe I should generate that list in a for loop or two :/
8 2013-09-08 00:21:00 <warren> I found more errors
9 2013-09-08 00:22:20 <warren> older versions of Fedora put it into /usr/include/db4
10 2013-09-08 00:22:59 <warren> checking if qt should be enabled... configure: error: "qt support requested but lrelease was not found. use --without-qt"
11 2013-09-08 00:23:31 <warren> Fedora calls it lrelease-qt4
12 2013-09-08 00:37:47 <Luke-Jr> warren: k, will check for that too..
13 2013-09-08 00:38:17 <warren> Luke-Jr: is qt5 becoming standard?
14 2013-09-08 00:38:50 <Luke-Jr> warren: meaning?
15 2013-09-08 00:39:40 <warren> Luke-Jr: is gitian moving from qt4 to qt5?
16 2013-09-08 00:45:05 <warren> /usr/include/features.h:330:4: warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp]
17 2013-09-08 00:45:05 <warren> # warning _FORTIFY_SOURCE requires compiling with optimization (-O)
18 2013-09-08 00:45:10 <warren> cfields: hmm, it doesn't build with any -O anymore?
19 2013-09-08 00:53:19 <warren> /usr/bin/ld: leveldb/libleveldb.a(db_impl.o): relocation R_X86_64_32S against `_ZTVN7leveldb6DBImplE' can not be used when making a shared object; recompile with -fPIC
20 2013-09-08 00:53:40 <warren> Luke-Jr: please add lrelease-qt5 too
21 2013-09-08 00:54:21 <warren> cfields: <warren> /usr/bin/ld: leveldb/libleveldb.a(db_impl.o): relocation R_X86_64_32S against `_ZTVN7leveldb6DBImplE' can not be used when making a shared object; recompile with -fPIC
22 2013-09-08 00:54:25 <warren> cfields: on fedora
23 2013-09-08 00:56:03 <jgarzik> warren, I don't get that
24 2013-09-08 00:56:18 <jgarzik> warren, well more correctly, I saw that then fixed it on F19
25 2013-09-08 00:56:25 <jgarzik> fixed without changing source code.
26 2013-09-08 00:56:30 <jgarzik> ACTION scratches his head for the solution
27 2013-09-08 00:57:09 <jgarzik> warren, does it build for you with 'make distclean" + ./configure --without-qt ?
28 2013-09-08 00:57:25 <warren> ACTION tries
29 2013-09-08 00:58:15 <warren> jgarzik: what about the FORTIFY_SOURCE warning? it seems to build without any -O
30 2013-09-08 00:59:07 <warren> lots of this warning, worthwhile to clean up? json/json_spirit_writer_template.h:31:50: warning: typedef âChar_typeâ locally defined but not used [-Wunused-local-typedefs]
31 2013-09-08 00:59:19 <jgarzik> warren, yeah I see that last warning too
32 2013-09-08 00:59:40 <jgarzik> warren, RE fortify I build with "CXXFLAGS=-O2 -Wall -g ./configure"
33 2013-09-08 00:59:44 <jgarzik> don't see that warning
34 2013-09-08 00:59:53 <warren> /usr/include/features.h:330:4: warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp]
35 2013-09-08 00:59:54 <warren> # warning _FORTIFY_SOURCE requires compiling with optimization (-O)
36 2013-09-08 01:00:11 <warren> jgarzik: shouldn't default ./configure have sane defaults? it has no hardening and no optimization by default
37 2013-09-08 01:00:12 <warren> ?
38 2013-09-08 01:00:29 <jgarzik> warren, AFAIK the default is -O2 -g
39 2013-09-08 01:00:33 <warren> not here
40 2013-09-08 01:00:54 <warren> I just did "./configure" as that's what most people will do.
41 2013-09-08 01:00:56 <jgarzik> warren, can you pastebin "./configure --without-qt && make V=1" ?
42 2013-09-08 01:01:14 <warren> i'm doing a build without V=1 now
43 2013-09-08 01:01:18 <warren> cancel it?
44 2013-09-08 01:01:26 <jgarzik> warren, V=1 gives make output
45 2013-09-08 01:01:31 <warren> canceling
46 2013-09-08 01:01:33 <jgarzik> baby bedtime, bbi 60min
47 2013-09-08 01:01:56 <warren> jgarzik: build success
48 2013-09-08 01:04:23 <warren> jgarzik: confirmed, plain "./configure" lacks -O or -Wall
49 2013-09-08 01:10:30 <warren> jgarzik: confirmed, plain "./configure" lacks -O or -g
50 2013-09-08 01:12:39 <Luke-Jr> warren: I'll hold off on lrelease-qt5, as I'm not sure Qt5 support is complete yet
51 2013-09-08 01:13:02 <Luke-Jr> unless you know for sure it works
52 2013-09-08 01:15:01 <warren> Luke-Jr: it works
53 2013-09-08 01:15:13 <warren> Luke-Jr: although it should prefer qt4 if that's what gitian uses
54 2013-09-08 01:15:27 <warren> Luke-Jr: if gitian switches to qt5 then prefer qt5
55 2013-09-08 01:15:28 <Luke-Jr> warren: how's rcc?
56 2013-09-08 01:15:33 <Luke-Jr> and moc etc?
57 2013-09-08 01:15:34 <warren> rcc?
58 2013-09-08 01:15:40 <Luke-Jr> the other Qt programs
59 2013-09-08 01:15:42 <warren> I don't know how qt works.
60 2013-09-08 01:15:50 <Luke-Jr> moc uic rcc lrelease
61 2013-09-08 01:16:18 <Luke-Jr> warren: if you change configure.ac to only use the qt5 variants, does it build? :p
62 2013-09-08 01:16:53 <warren> Luke-Jr: dunno
63 2013-09-08 01:16:58 <Luke-Jr> warren: try it?
64 2013-09-08 01:16:58 <warren> trying
65 2013-09-08 01:17:06 <warren> i'm doing the test build for jgarzik now
66 2013-09-08 01:17:08 <Luke-Jr> Gentoo has no Qt 5 available yet, even in unstable :/
67 2013-09-08 01:17:34 <warren> Luke-Jr: uic-qt4 uic-qt5 rcc rcc-qt5
68 2013-09-08 01:17:47 <warren> qmake-qt4 qmake-qt5
69 2013-09-08 01:25:39 <Luke-Jr> Can anyone confirm gitian determinism? http://codepad.org/RvseDiyt
70 2013-09-08 01:27:18 <warren> Luke-Jr: can you confirm this is not working? <jgarzik> warren, AFAIK the default is -O2 -g
71 2013-09-08 01:27:24 <warren> Luke-Jr: I'm testing qt5 build now
72 2013-09-08 01:31:42 <Luke-Jr> default is "-g -ggdb" with configure --enable-debug and "-O2" otherwise
73 2013-09-08 01:32:04 <warren> Luke-Jr: definitely not getting -O2 default here.
74 2013-09-08 01:32:30 <Luke-Jr> --enable-debug is also default
75 2013-09-08 01:32:58 <warren> oh
76 2013-09-08 01:33:20 <warren> json/json_spirit_writer_template.h:31:50: warning: typedef âChar_typeâ locally defined but not used [-Wunused-local-typedefs]
77 2013-09-08 01:33:20 <warren> json/json_spirit_writer_template.h: In function âString_type json_spirit::non_printable_to_string(unsigned int)â:
78 2013-09-08 01:33:20 <warren> typedef typename String_type::value_type Char_type;
79 2013-09-08 01:33:24 <warren> are we ever going to get rid of this warning?
80 2013-09-08 01:34:35 <gavinandresen> who is "we" ?
81 2013-09-08 01:34:49 <warren> the project
82 2013-09-08 01:35:07 <gavinandresen> Ok, then no, "the project" will never spontaneously get rid of that warning.
83 2013-09-08 01:35:21 <gavinandresen> if it bugs you, then fix it.
84 2013-09-08 01:36:05 <warren> /usr/bin/ccache g++ -I. -I./include -pthread -DOS_LINUX -DLEVELDB_PLATFORM_POSIX -g -ggdb -Wall -Wextra -Wformat -Wformat-security -Wno-unused-parameter -Wstack-protector -fPIE -fno-stack-protector -fstack-protector-all -DBOOST_SPIRIT_THREADSAFE -DHAVE_BUILD_INFO -D_FORTIFY_SOURCE=2
85 2013-09-08 01:36:25 <gavinandresen> (or, even better, send a patch upstream to json_spirit to fix it)
86 2013-09-08 01:36:27 <warren> not sure why it has "-fno-stack-protector"
87 2013-09-08 01:39:05 <warren> Luke-Jr: build fails with qt5 during tests, it seems tests pulls in qt4 while everything else was qt5
88 2013-09-08 01:39:25 <Luke-Jr> warren: hmm, better leave Qt5 support for another pullreq then
89 2013-09-08 01:39:50 <warren> yeah
90 2013-09-08 01:39:57 <warren> Luke-Jr: althoug please include the -qt4 variants
91 2013-09-08 01:40:24 <warren> Luke-Jr: qt5 in the client is working fine though
92 2013-09-08 01:44:55 <warren> Luke-Jr: eh, just put the -qt4 variants before -qt5 and it works just fine for now.
93 2013-09-08 01:45:17 <warren> wooo ccache
94 2013-09-08 01:46:25 <Luke-Jr> warren: that's because it's not using the -qt5 :p
95 2013-09-08 01:46:48 <warren> Luke-Jr: that's fine for now, at least someone will notice the test build needs fixing this way.
96 2013-09-08 01:55:17 <warren> hmm
97 2013-09-08 01:55:22 <warren> other problems with build
98 2013-09-08 01:55:46 <warren> bitcoind is fine. bitcoin-qt can't find libraries.
99 2013-09-08 01:57:59 <warren> cfields: Luke-Jr jgarzik: http://paste.mhanne.net/p/36131cca7fb9ba114a7e65a4ed15c51d52364158?hl=text
100 2013-09-08 01:58:12 <warren> ./bitcoin-qt: error while loading shared libraries: libboost_system-mt.so.1.50.0: cannot open shared object file: No such file or directory
101 2013-09-08 01:58:12 <warren> [warren@localhost bitcoin]$ ./bitcoin-qt -testnet
102 2013-09-08 02:05:19 <warren> Luke-Jr: https://togami.com/~warren/temp/fedora-qt4-qt5.patch
103 2013-09-08 02:05:22 <warren> Luke-Jr: please squash this in too
104 2013-09-08 02:05:27 <warren> Luke-Jr: no drawback
105 2013-09-08 02:06:11 <warren> bbl
106 2013-09-08 02:09:11 <Luke-Jr> warren: didn't you just say it wouldn't build?
107 2013-09-08 02:13:49 <Luke-Jr> did cfields leave the Mac gitian stuff anywhere to play with?
108 2013-09-08 02:29:06 <Luke-Jr> hmm, I don't see a way to skip building bitcoind :/
109 2013-09-08 02:42:43 <warren> Luke-Jr: it builds
110 2013-09-08 02:43:01 <warren> Luke-Jr: without that it won't build
111 2013-09-08 02:43:09 <Luke-Jr> warren: ?
112 2013-09-08 02:43:19 <warren> Luke-Jr: https://togami.com/~warren/temp/fedora-qt4-qt5.patch
113 2013-09-08 02:43:38 <Luke-Jr> warren: to do a valid test, you must list ONLY the *-qt5 variants
114 2013-09-08 02:43:41 <warren> Luke-Jr: the remaining problems need to be solved elsewhere, this part is correct
115 2013-09-08 02:44:54 <Luke-Jr> it's not correct until Qt5 is complete
116 2013-09-08 02:45:01 <Luke-Jr> ie, everything else must work first
117 2013-09-08 02:45:08 <warren> Luke-Jr: by that metric, qt4 isn't complete either
118 2013-09-08 02:45:17 <Luke-Jr> â¦
119 2013-09-08 02:45:21 <warren> Luke-Jr: just add this change, it will be needed eventually
120 2013-09-08 02:46:01 <warren> Luke-Jr: the qt4 build with that is fine (except for the boost problem which has nothing to do with it)
121 2013-09-08 02:46:02 <Luke-Jr> warren: if the build fails with *-qt5, then configure is required to fail upfront
122 2013-09-08 02:46:29 <warren> Luke-Jr: that change will be needed eventually, and without it, nobody else will notice the -qt5 failure
123 2013-09-08 02:46:50 <Luke-Jr> warren: the job of configure includes failing early if things are not proper
124 2013-09-08 02:47:13 <Luke-Jr> if it fails to fail, it is a bug
125 2013-09-08 02:47:13 <warren> Luke-Jr: fine, include the qt4 part now?
126 2013-09-08 02:47:15 <Luke-Jr> I did
127 2013-09-08 02:47:33 <warren> I don't see it in your commits
128 2013-09-08 02:47:51 <warren> Luke-Jr: there is no rcc-qt4
129 2013-09-08 02:48:12 <warren> at least not here
130 2013-09-08 02:48:20 <Luke-Jr> warren: doesn't hurt to check
131 2013-09-08 02:49:04 <warren> hmm, at least one OS has rcc-qt4
132 2013-09-08 02:49:06 <warren> ok fine
133 2013-09-08 02:49:20 <warren> to fix qt5 will require fixing something in the tests
134 2013-09-08 02:49:32 <warren> Luke-Jr: qt5 build and tests works fine if I remove qt4
135 2013-09-08 02:49:48 <warren> (no qt4 headers or build tools)
136 2013-09-08 02:50:15 <Luke-Jr> hmm, interesting
137 2013-09-08 03:01:21 <gmaxwell> phantomcircuit: so I had an interesting though about improving security in your shared wallet / network isolation attack model.
138 2013-09-08 03:01:54 <gmaxwell> phantomcircuit: and the idea is this: agressively prefer to spend _new_ coins (perhaps dependant on how slow the blockchain has been)
139 2013-09-08 03:01:57 <warren> Luke-Jr: better to just add the -qt5 variants now so it can be used and tested
140 2013-09-08 03:02:13 <warren> bbl dinner
141 2013-09-08 03:02:51 <gmaxwell> phantomcircuit: e.g. someone isolates you and feeds you six confirms, if you prefer to spend newly recieved coins, e.g. ones with ... 6 confirms, you're far more likely to give that person his coins back.
142 2013-09-08 03:15:16 <helo> it's nice that, depite these situations never occurring afaact, they're given some thought :)
143 2013-09-08 03:16:29 <gmaxwell> they only don't occur until they do, and if you don't think about them in advance your system doesn't survive the first incident.
144 2013-09-08 03:16:48 <gmaxwell> Attacks are only rare until they're not. :)
145 2013-09-08 04:32:10 <phantomcircuit> gmaxwell, hmm that would be a complete 180 on the current algorithm
146 2013-09-08 04:32:42 <gmaxwell> phantomcircuit: well not quite, it does cutoff at 6 now. So, e.g. trying at 6 only wouldn't be a total 180.
147 2013-09-08 04:37:14 <helo> props on the autotools build changes
148 2013-09-08 05:20:00 <jgarzik> helo, thanks to cfields
149 2013-09-08 05:41:06 <jgarzik> John Gilmore, on NSA games while he worked on IPSEC: http://www.mail-archive.com/cryptography@metzdowd.com/msg12325.html
150 2013-09-08 05:43:08 <gmaxwell> More smoking than gun there, sadly.
151 2013-09-08 05:43:48 <gmaxwell> There are all kinds of other stupid politics that explain IPSEC. SSL has a messed up history too.
152 2013-09-08 05:44:12 <phantomcircuit> jgarzik, what's more disturbing is the names they gave the programs...
153 2013-09-08 05:44:59 <phantomcircuit> "hey guys i know lets name our program after a major civil war battle"
154 2013-09-08 05:45:16 <phantomcircuit> :/
155 2013-09-08 05:45:20 <gmaxwell> phantomcircuit: IIRC all NSA codenames come sequentially out of a book of codenames and are unrelated to the projects.
156 2013-09-08 05:45:33 <gmaxwell> (in order to prevent the codenames leaking information about the projects)
157 2013-09-08 05:45:49 <phantomcircuit> gmaxwell, that's what they want you to think
158 2013-09-08 05:45:58 <phantomcircuit> </paranoia>
159 2013-09-08 05:47:03 <gmaxwell> If you've not read "The Puzzle Palace", I highly recommend it.. well at least the first half of it. The later half is bureaucratic history, and Foo begat Bar, who begat Baz who was beheded but not before giving birth to Blat.. kinda boring.
160 2013-09-08 05:47:08 <phantomcircuit> gmaxwell, it's interesting to me that even if ecdsa was massively broken it would likely still be difficult to forge a valid spend input
161 2013-09-08 05:47:31 <jgarzik> well
162 2013-09-08 05:47:36 <phantomcircuit> (if you dont reuse addresses)
163 2013-09-08 05:47:39 <gmaxwell> phantomcircuit: Yea, well, except a lot of users really heavily reuse addresses.. sooo.
164 2013-09-08 05:47:39 <jgarzik> it just means the NSA breaks SatoshiDICE
165 2013-09-08 05:47:40 <jgarzik> :)
166 2013-09-08 05:48:09 <phantomcircuit> gmaxwell, it really shows how paranoid satoshi was in constructing things
167 2013-09-08 05:48:14 <phantomcircuit> horray paranoia
168 2013-09-08 05:48:52 <gmaxwell> I like the key hashing as a security feature, but I think satoshi was actually not thinking of it that way... otherwise the blocks wouldn't have been pay to pubkey.
169 2013-09-08 05:48:59 <jgarzik> hmmm, p2sh destination script address will be the same as long as the txout script containing pubkeyhash address XYZ remains unchanged, correct?
170 2013-09-08 05:49:03 <gmaxwell> (and IP transactions were also pay to pubkey)
171 2013-09-08 05:49:18 <jgarzik> what if there was a nonce in there, to stir things, creating multiple p2sh addresses for one bitcoin address
172 2013-09-08 05:49:50 <gmaxwell> jgarzik: yes, you could do that, but: you'd have to remember the nonces (well, easy if they're a counter) and once you spend it would be trivially linkable by anyone.
173 2013-09-08 05:50:11 <gmaxwell> Better to just use BIP32 to get a sequence of pubkeys, and thats not even linkable post spending.
174 2013-09-08 05:50:31 <phantomcircuit> gmaxwell, the nonce could be derived from the private key and the input transaction
175 2013-09-08 05:50:49 <warren> gmaxwell: you still have fedora?
176 2013-09-08 05:50:53 <gmaxwell> warren: sure.
177 2013-09-08 05:50:53 <jgarzik> the sense I got at the conference from implementers is that people like BIP32, but don't fully trust it yet
178 2013-09-08 05:51:04 <warren> gmaxwell: you run into the boost linking problem with autotools master?
179 2013-09-08 05:51:10 <phantomcircuit> jgarzik, which is certainly a good thing
180 2013-09-08 05:51:22 <jgarzik> i.e. don't trust that additional, surprising attack surfaces are not lurking
181 2013-09-08 05:51:24 <gmaxwell> warren: haven't tried since it was merged. uh does the autotools not correctly link boost-mt?
182 2013-09-08 05:51:31 <jgarzik> current scheme is well understood
183 2013-09-08 05:51:46 <gmaxwell> jgarzik: funny you say that, because bitcoin-qt appears to be the only implementor not running headlong into it.
184 2013-09-08 05:52:03 <jgarzik> HD asks us to trust not just one derivation is secure (priv -> pub), but multiple derivations
185 2013-09-08 05:52:03 <phantomcircuit> gmaxwell, did you look at the whole tor 1024 rsa key thing
186 2013-09-08 05:52:05 <warren> gmaxwell: bitcoind is fine, bitcoin-qt builds ... but ....http://paste.mhanne.net/p/36131cca7fb9ba114a7e65a4ed15c51d52364158?hl=text
187 2013-09-08 05:52:12 <phantomcircuit> im not sure those keys are used long enough for being cracked to matter
188 2013-09-08 05:52:50 <warren> phantomcircuit: enough to decrypt payload later though?
189 2013-09-08 05:53:06 <phantomcircuit> also i know that various tools designed to use tor for purposes which do not require strong anonymity are based on old forks
190 2013-09-08 05:53:38 <phantomcircuit> warren, not if they're using ephemeral diffie hellman
191 2013-09-08 05:54:08 <gmaxwell> jgarzik: and yet it appears everything except bitcoin-qt is rushing into it. (I share this concern, and I was mildly pissed when armory and electrum deployed it only a couple months after my post describing that homorphism, though it's now had a lot of cryptographers look at it.)
192 2013-09-08 05:55:08 <gmaxwell> phantomcircuit: I know that tor uses 1024 bit rsa and 1024 bit dh and are in the slow process of migrating to ECC.
193 2013-09-08 05:55:56 <jgarzik> EFF should not recommend Tor until they fix packet size/timing exposure problems </OT rant>
194 2013-09-08 05:56:33 <gmaxwell> jgarzik: Timing/confirmation attacks cannot be fixed in a realtime anonymity network, they're fundimental.
195 2013-09-08 05:56:53 <gmaxwell> whats better? nothing at all? :P
196 2013-09-08 05:57:05 <jgarzik> gmaxwell, static packet size and timing
197 2013-09-08 05:57:35 <gmaxwell> jgarzik: tor has a static cell size (512 bytes).
198 2013-09-08 05:57:47 <phantomcircuit> gmaxwell, except not really because of padding
199 2013-09-08 05:57:50 <gmaxwell> But you can only hide so much information at a certian cost.
200 2013-09-08 05:58:05 <jgarzik> gmaxwell, you can run real time apps pretty much just fine, with caveats: you use maximum bandwidth at all times, and occasionally latency bites you, if timing is chosen poorly
201 2013-09-08 05:58:32 <jgarzik> yeah, Tor padding is a joke
202 2013-09-08 05:58:42 <gmaxwell> jgarzik: sadly, no. even "send CBR" doesn't work because of confirmation attacks. You _interrupt_ the thing in question and now you know who is talking to it.
203 2013-09-08 05:59:13 <gmaxwell> (thats called a confirmation attack, and someone from the tor project has told me that it's even been used to arrest people)
204 2013-09-08 05:59:25 <phantomcircuit> gmaxwell, which is why you have an irc bouncer you pay for with bitcoins
205 2013-09-08 05:59:26 <jgarzik> gmaxwell, I agree that attack is fundamental
206 2013-09-08 05:59:28 <warren> gmaxwell: any idea what happened with that bitcoin-qt? Try master + https://github.com/bitcoin/bitcoin/pull/2979
207 2013-09-08 05:59:29 <phantomcircuit> :)
208 2013-09-08 05:59:51 <jgarzik> gmaxwell, however without interference, passive observation can be made to glean much less than current Tor
209 2013-09-08 05:59:53 <phantomcircuit> gmaxwell, i assume they're talking about jeremy hammond
210 2013-09-08 06:00:04 <jgarzik> interruption is a common technique
211 2013-09-08 06:00:04 <phantomcircuit> (too be fair he would have ended up arrested regardless)
212 2013-09-08 06:00:44 <jgarzik> interruption has been used in the past for unrelated reasons, by hackers forcing a [for example] wireless renegotiation, and exploiting a weakness therein
213 2013-09-08 06:01:14 <gmaxwell> jgarzik: there are schemes which make those attacks far less useful, but they break realtimeness.
214 2013-09-08 06:01:15 <jgarzik> but interrupt alerts the subject
215 2013-09-08 06:01:22 <jgarzik> and so that is often avoided
216 2013-09-08 06:01:42 <gmaxwell> jgarzik: in a reattime system you don't alert the subject if the interruption is only on the same order of magnitude as the typical latency.
217 2013-09-08 06:01:54 <phantomcircuit> jgarzik, it's fairly easy to convince people that the underlying network is unreliable
218 2013-09-08 06:02:20 <gmaxwell> e.g. you do multiple bursts of interuption for 100ms... no tor user is going to notice that, but you rapidly get confirmation.
219 2013-09-08 06:02:40 <jgarzik> gmaxwell, that varies wildly depending on protocol used, and method of interruption
220 2013-09-08 06:02:51 <jgarzik> gmaxwell, I agree for some cases, yes
221 2013-09-08 06:02:56 <jgarzik> phantomcircuit, heh
222 2013-09-08 06:03:13 <phantomcircuit> jgarzik, for example
223 2013-09-08 06:03:18 <phantomcircuit> freenode is super unreliable
224 2013-09-08 06:03:30 <phantomcircuit> after years of being basically always online
225 2013-09-08 06:03:31 <phantomcircuit> wait
226 2013-09-08 06:03:36 <phantomcircuit> ACTION looks around suspiciously
227 2013-09-08 06:04:35 <warren> hmm, is there a git command that will replay all of these commits in one command? https://github.com/bitcoin/bitcoin/pull/2979#commits-pushed-11205fa
228 2013-09-08 06:04:53 <warren> I have all of the pull requests available to cherry-pick by git hash ...
229 2013-09-08 06:22:09 <phantomcircuit> i played eve today
230 2013-09-08 06:22:10 <phantomcircuit> mistake
231 2013-09-08 06:23:52 <warren> phantomcircuit: another soon-to-be regulated virtual currency
232 2013-09-08 06:44:44 <gmaxwell> ... bitcoin gambling site using the merkle root of a future block to determine their winner.
233 2013-09-08 06:46:21 <sipa> gmaxwell: prepare for extra random nonces!
234 2013-09-08 06:55:57 <warren> ./bitcoin-qt: error while loading shared libraries: libboost_system-mt.so.1.50.0: cannot open shared object file: No such file or directory
235 2013-09-08 06:55:57 <warren> [warren@localhost bitcoin]$ ./bitcoin-qt -testnet
236 2013-09-08 06:56:05 <warren> system has only libboost_system-mt.so.1.53.0
237 2013-09-08 06:56:30 <warren> ACTION digs around
238 2013-09-08 06:57:43 <gmaxwell> warren: I don't know how it would have finished building unless it could find it.
239 2013-09-08 06:57:57 <gmaxwell> maybe it didn't and is picking up an old bin in your directory?