1 2013-09-23 00:00:00 <gmaxwell> Luke-Jr: ah, at least a dead battery you can get someone to jumpstart you.
2 2013-09-23 00:00:15 <jgarzik> x32 is fun
3 2013-09-23 00:00:16 <gmaxwell> I don't suppose its a stickshift? :P pushstarting is always fun.
4 2013-09-23 00:00:18 <Luke-Jr> we have another car right here, but no jumper cables
5 2013-09-23 00:00:39 <Luke-Jr> tried using a DC->AC inverter + AC->DC car charger, but I think I fried one or both of them..
6 2013-09-23 00:00:43 <jgarzik> jumpstart with phone battery ;p
7 2013-09-23 00:00:44 <Luke-Jr> apparently 300 W is not enough
8 2013-09-23 00:01:47 <gmaxwell> I jumpstarted a car once by popping the battery out of another car, matching up the terminals, started the car, then put the other one back.
9 2013-09-23 00:01:56 <gmaxwell> and I managed this with no tools. :P
10 2013-09-23 00:02:10 <Luke-Jr> the other car's battery also has no red wire/terminal..
11 2013-09-23 00:02:13 <gmaxwell> careful with a non-sealed battery.. acid no fun. :P
12 2013-09-23 00:02:15 <Luke-Jr> so nfc which side is positive
13 2013-09-23 00:02:29 <gmaxwell> battery itself should be labed. also the negative is connected to the chassis.
14 2013-09-23 00:02:40 <gmaxwell> labled*
15 2013-09-23 00:12:21 <nsh> Luke-Jr, there should be a + - engraved on the terminals or nearby
16 2013-09-23 00:13:02 <nsh> i can't imagine a battery shipping that didn't indicate polarity somehow relatively unambiguously
17 2013-09-23 00:13:09 <Luke-Jr> it's pitch dark out
18 2013-09-23 00:13:12 <nsh> :(
19 2013-09-23 00:13:13 <Luke-Jr> :/
20 2013-09-23 00:13:28 <Luke-Jr> and the battery was too dirty when it was barely light
21 2013-09-23 00:13:35 <nsh> ACTION checks google images for convention
22 2013-09-23 00:13:44 <xenland> unless its alien tech. There are no polars its all relative really.
23 2013-09-23 00:14:04 <gmaxwell> Did I mention that when I did the move the battery trick it was 4am? and my only light was a old industructable nokia phone backlight.
24 2013-09-23 00:14:24 <nsh> seems about equal on left/right :(
25 2013-09-23 00:14:38 <nsh> you could check with a wire to the ground
26 2013-09-23 00:14:39 <nsh> for sparking
27 2013-09-23 00:14:48 <nsh> *arcing
28 2013-09-23 00:15:01 <nsh> (or car body)
29 2013-09-23 00:15:23 <gcX46> take a wire put one end on a terminal and tap the other end on an unpainted part of the chassis, if it sparks it's positive if not it's negative or the battery is dead
30 2013-09-23 00:23:54 <prophet10x> i'm not sure if this is the right place to ask, but whatever happened to the color coins concept? or is some group developing something open source for creating shares, assets etc
31 2013-09-23 00:25:18 <xenland> prophet10x, moneychanger and bitshares are into digital assets
32 2013-09-23 00:25:26 <Luke-Jr> any idea to know how much "peak-amps" my vehicle needs to start?
33 2013-09-23 00:25:45 <xenland> as for colored coins and think they are working out the math.
34 2013-09-23 00:26:04 <xenland> Juke-lr: about 9.15 gigawatts.
35 2013-09-23 00:26:20 <Luke-Jr> prophet10x: I'm not sure there's a use case for colored coins
36 2013-09-23 00:26:23 <gmaxwell> Luke-Jr: cranking amps is a lot.. e.g. over 100a ... the actual value depends on the engine.
37 2013-09-23 00:26:23 <xenland> and half a ton of plutoneum and a coka-cola (opened)
38 2013-09-23 00:26:39 <Luke-Jr> gmaxwell: bleh, no idea on engine
39 2013-09-23 00:26:50 <Luke-Jr> my choices appaear to be 400 vs 750
40 2013-09-23 00:27:04 <gcX46> bigger == better
41 2013-09-23 00:27:16 <gcX46> especially since winter is coming
42 2013-09-23 00:27:19 <gmaxwell> Luke-Jr: oh, for picking a new battery? whever you're buying it from should have a database.
43 2013-09-23 00:27:23 <gmaxwell> gcX46: he lives in florida.
44 2013-09-23 00:27:26 <Luke-Jr> gcX46: winter? what's that?
45 2013-09-23 00:27:31 <gcX46> oh
46 2013-09-23 00:27:44 <Luke-Jr> gmaxwell: http://www.walmart.com/ip/Schumacher-Electric-750-Peak-Amp-Jump-Starter/25955561
47 2013-09-23 00:27:55 <prophet10x> if the car is a big car or sports car i would go with the latter
48 2013-09-23 00:28:36 <Luke-Jr> Mercury VIllager 2001
49 2013-09-23 00:29:56 <gcX46> 3.3L v6 won't need much amps
50 2013-09-23 00:31:00 <gmaxwell> Luke-Jr: larger won't hurt, would perhaps be more generally useful to start other stuff in the future.. googling is showing battery pickers that have 300 CCA batteries for that car.
51 2013-09-23 00:36:26 <xenland> DCC Chat?
52 2013-09-23 00:36:43 <prophet10x> xenland: who is running mneychanger?
53 2013-09-23 00:36:58 <prophet10x> sorry not familiar with this interface
54 2013-09-23 00:37:14 <xenland> Monetas company
55 2013-09-23 00:37:26 <xenland> But its supposed to be decent.
56 2013-09-23 00:37:29 <xenland> decentrilized*
57 2013-09-23 00:37:36 <xenland> #opentransactions
58 2013-09-23 00:37:44 <xenland> FellowTraveler
59 2013-09-23 00:37:49 <xenland> is who runs it.
60 2013-09-23 00:38:57 <prophet10x> and bistshares is proprietary?
61 2013-09-23 00:42:56 <Luke-Jr> if someone is "running" it, why does it need a blockchain..?
62 2013-09-23 00:43:13 <Luke-Jr> blockchain only makes sense for decentralised stuff
63 2013-09-23 00:43:30 <Cusipzzz> to look cool/bitcoin related?
64 2013-09-23 00:43:31 <nsh> orchestration is not necessarily incompatible with decentralisation
65 2013-09-23 00:43:44 <nsh> arpanet was "run" and also designed to be decentralised
66 2013-09-23 00:45:09 <Luke-Jr> nsh: networking is decentralised; the internet is not
67 2013-09-23 00:45:38 <Luke-Jr> p2p, yes - but not decentralised
68 2013-09-23 00:45:48 <nsh> hmm
69 2013-09-23 00:46:03 <nsh> where's the center?
70 2013-09-23 00:47:06 <gmaxwell> in ##bitcoin-dev-offtopic
71 2013-09-23 00:47:59 <Luke-Jr> nsh ^
72 2013-09-23 00:48:08 <nsh> (where all the best car-battery chat happens)
73 2013-09-23 00:48:43 <coingenuity> haha
74 2013-09-23 00:49:28 <gmaxwell> nsh: yea, so when you get stranded someplace an want some tips from your associates on IRC I'll be sure to kick your ass on sight, sound fair?
75 2013-09-23 00:49:56 <nsh> i don't drive, so joke's on you :)
76 2013-09-23 00:50:37 <Luke-Jr> actually, I took it in to walmart for warranty on the battery Friday and they insisted it was good and refused to replace it -.-
77 2013-09-23 02:34:37 <warren> fewer_fee_footguns
78 2013-09-23 02:47:12 <warren> anyone have Ubuntu 12.04 installed? what version of gcc is mingw-w64 based on?
79 2013-09-23 02:47:26 <Luke-Jr> warren: afaik, isn't mingw's gcc mainline now
80 2013-09-23 02:47:27 <Luke-Jr> ?
81 2013-09-23 02:47:50 <warren> Luke-Jr: I dunno, 12.04 is old already too, so asking
82 2013-09-23 02:47:52 <warren> I don't have the distro
83 2013-09-23 02:58:33 <warren> Anyone downloaded protobuf-2.5.0.tar.bz2 from <someplace random>? Let's compare sha256sums.
84 2013-09-23 02:58:42 <Luke-Jr> warren: OH! you mean the specific version with the OS, now I get it :D
85 2013-09-23 02:59:25 <warren> Luke-Jr: I'm upgrading gitian win32 to 12.04, which among other things fixes compiler bugs and allows the use of more hardening flags
86 2013-09-23 03:00:09 <warren> Luke-Jr: also allows for a win64 build
87 2013-09-23 03:00:16 <Luke-Jr> neat
88 2013-09-23 03:01:50 <warren> hmm, I need to rename these deps .zip files
89 2013-09-23 03:08:27 <warren> protobuf-win32-2.5.0-gitian-r2.zip
90 2013-09-23 03:08:36 <warren> r2 refers to bitcoin's revision, not upstream right?
91 2013-09-23 03:09:00 <Luke-Jr> yes
92 2013-09-23 03:09:07 <Luke-Jr> -r* is always downstream
93 2013-09-23 03:09:27 <warren> boost-win32-1.50.0-gitian3.zip
94 2013-09-23 03:09:30 <warren> how wonderfully consistent
95 2013-09-23 03:10:09 <warren> bitcoin-deps-0.0.7.zip more consistent
96 2013-09-23 03:10:41 <warren> I'm renaming boost to r3
97 2013-09-23 03:25:31 <gavinandresen> warren: why a win64 build? performance increase for litecoin/scrypt?
98 2013-09-23 03:28:30 <gavinandresen> warren: I ask because I'll NACK shipping both win32 and win64 binaries unless there is a demonstrable benefit to bitcoin users
99 2013-09-23 03:31:20 <warren> gavinandresen: 64bit is much faster for secp256k1 in particular. Not suggesting shipping 64bit bitcoin until there's a demonstrable benefit.
100 2013-09-23 03:31:37 <Luke-Jr> gavinandresen: I think sipa has said for a while that x86_64 has huge performance improvements for ECDSA
101 2013-09-23 03:32:07 <Luke-Jr> not sure if that applies to Windows as well though
102 2013-09-23 03:32:10 <warren> gavinandresen: gmaxwell also mentioned runtime detection of cpu features could allow other parts of bitcoin to be faster. I have semi-finished runtime cpu features detection right now.
103 2013-09-23 03:32:15 <warren> Luke-Jr: sure it can
104 2013-09-23 03:32:21 <Luke-Jr> can != does âº
105 2013-09-23 03:32:27 <gavinandresen> we are IO bound on consumer hardware last I checked
106 2013-09-23 03:32:51 <gavinandresen> Fast SSDs might be different, and might be common enough nowdays to matter
107 2013-09-23 03:33:10 <Luke-Jr> gavinandresen: doesn't mean users want to run software that eats up a lot of CPU time either *shrug*
108 2013-09-23 03:33:23 <gavinandresen> In any case, dropping support for 32-bit machines and supporting only 64-bit is what I'd vote for. Multiple downloads, with the user having to choose, sucks.
109 2013-09-23 03:33:46 <warren> gavinandresen: on mac, coryfields can make future builds 32bit/64bit in the same binary
110 2013-09-23 03:34:13 <gavinandresen> warren: how much bigger are they? Downloading twice as many megabytes also sucks....
111 2013-09-23 03:34:20 <Luke-Jr> gavinandresen: speaking of which, did anyone get your opinion on dropping OS X 10.5 support?
112 2013-09-23 03:34:35 <warren> gavinandresen: dunno, let's support his work and see how awesome it gets.
113 2013-09-23 03:34:43 <gavinandresen> Luke-Jr: I think we should drop 10.5 support in the 0.9 release.
114 2013-09-23 03:34:48 <warren> I just saw yesterday 10.6 got a security update.
115 2013-09-23 03:34:51 <Luke-Jr> I think 10.6 only runs with 64-bit kernels anyway
116 2013-09-23 03:35:06 <warren> really? then great
117 2013-09-23 03:35:13 <Luke-Jr> lemme verify
118 2013-09-23 03:35:32 <warren> I was told to assume all Intel Macs have SSE2.
119 2013-09-23 03:35:34 <gavinandresen> Luke-Jr: thanks, I was about to say "I think" isn't helpful
120 2013-09-23 03:36:02 <Luke-Jr> ah, no, that was 10.7
121 2013-09-23 03:36:08 <gavinandresen> Luke-Jr: my old MacBook Pro Intel Core Duo is running 10.6.8⦠32-bit....
122 2013-09-23 03:36:08 <Luke-Jr> 10.6 just uses 64-bit when available
123 2013-09-23 03:36:55 <Luke-Jr> oh well, a few more years I guess
124 2013-09-23 03:37:22 <warren> Luke-Jr: 12.04 mingw is gcc-4.6
125 2013-09-23 03:37:42 <Luke-Jr> warren: sounds like a good choice; that's also Gentoo stable FWIW
126 2013-09-23 03:37:51 <warren> hmm
127 2013-09-23 03:37:57 <warren> bbl dinner
128 2013-09-23 03:38:24 <warren> gavinandresen: FWIW, a 30% bigger download is nothing compared to block sync
129 2013-09-23 03:39:05 <gavinandresen> Mmm. and when we get headers-first running, that should not be a bid deal any more.
130 2013-09-23 03:39:17 <warren> gavinandresen: the way you brought up this topic was rather kneejerk. Please relax.
131 2013-09-23 03:39:25 <gavinandresen> ⦠so I'd much rather you spent time helping test headers-first
132 2013-09-23 03:40:05 <gavinandresen> RE: kneejerk: sorry, you just poked a spot that has been poked many times before-- lots of people have complained about lack of 64-bit builds without data ton WHY
133 2013-09-23 03:40:09 <warren> gavinandresen: the new mingw allows more hardening flags on win32, this is low hanging fruit, I choose to work on this.
134 2013-09-23 03:40:26 <gavinandresen> "okey dokey"
135 2013-09-23 03:40:57 <warren> gavinandresen: if I propose win64 it will be with benchmarks, but I am guessing it won't help much until CPU features and/or secp256k1
136 2013-09-23 03:58:04 <warren> toffoo: hey, tried that bitcoin build with the macosx fix?
137 2013-09-23 04:00:46 <warren> wumpus: g++-mingw-w64 is needed too
138 2013-09-23 05:02:04 <warren> Luke-Jr: hmm, I could be wrong, during builds I see things like bin.v2/libs/timer/build/gcc-mingw-4.4
139 2013-09-23 05:08:08 <warren> Luke-Jr: #define __VERSION__ "4.6.3"
140 2013-09-23 05:09:19 <warren> Luke-Jr: <compiler> -E -dM <blankfile.h>
141 2013-09-23 05:11:28 <warren> Luke-Jr: so 4.6 .. good I guess
142 2013-09-23 05:34:53 <warren> gavinandresen: Luke-Jr: any objections to making a deps.zip for linux too? it will allow linux builds to be faster
143 2013-09-23 05:35:37 <Luke-Jr> warren: I'm not sure why we're not just using Ubuntu packages there O.o
144 2013-09-23 05:45:34 <warren> Luke-Jr: maybe too old version or no static?
145 2013-09-23 05:46:10 <Luke-Jr> warren: maybe; perhaps the new Ubuntu has it good?
146 2013-09-23 05:57:12 <warren> Luke-Jr: can't upgrade the linux gitian version unless we want to drop older linux distros
147 2013-09-23 05:57:23 <warren> Luke-Jr: 10.04 was from 2010, not that old yet
148 2013-09-23 05:57:32 <Luke-Jr> we can't? O.o
149 2013-09-23 05:57:44 <Luke-Jr> warren: pretty sure 10.04 is losing support soon
150 2013-09-23 05:58:01 <warren> well, not like Ubuntu support has ever been good...
151 2013-09-23 05:58:08 <Luke-Jr> but they're static binaries in any case..
152 2013-09-23 05:58:13 <Luke-Jr> shouldn't matter which version builds then
153 2013-09-23 05:58:15 <Luke-Jr> them*
154 2013-09-23 05:58:44 <Luke-Jr> yeah, Canonical dropped 10.04 for desktops on May 9
155 2013-09-23 05:58:44 <warren> Luke-Jr: it needs the glibc that it is built on. there's probably a way to force it to use an older ABI, but I've never used that before.
156 2013-09-23 05:59:10 <Luke-Jr> we're not static linking glibc?
157 2013-09-23 05:59:57 <warren> hmm, the gitian qt is built with SSE-SSE4, I wonder if it is actually used
158 2013-09-23 06:00:07 <warren> Luke-Jr: nope
159 2013-09-23 06:00:27 <warren> Luke-Jr: aside from qt, bitcoind appears to be fully BSD
160 2013-09-23 06:00:46 <Luke-Jr> warren: fully BSD? O.o
161 2013-09-23 06:02:19 <warren> Luke-Jr: or at least not tainted by LGPL
162 2013-09-23 06:02:53 <Luke-Jr> LGPL doesn't taint.
163 2013-09-23 06:02:59 <Luke-Jr> that's why it's Lesser
164 2013-09-23 06:03:19 <Luke-Jr> warren: and you mean old-BSD, which is actually a taint :P
165 2013-09-23 06:03:45 <Luke-Jr> warren: we *couldn't* use "tainting" GPL in Bitcoin-Qt, because of the old-BSD taint
166 2013-09-23 06:06:16 <warren> Luke-Jr: static linked LGPL
167 2013-09-23 06:06:26 <warren> Luke-Jr: currently as shipped in gitian builds
168 2013-09-23 06:06:40 <Luke-Jr> ah, true
169 2013-09-23 06:07:06 <Luke-Jr> hmm, I wonder if that's technically infringing then
170 2013-09-23 06:07:36 <warren> Luke-Jr: only infringing if source is not provided
171 2013-09-23 06:07:55 <Luke-Jr> warren: source for the entire binary though; IIRC LGPL taints if static linked, as you mention..
172 2013-09-23 06:08:37 <Luke-Jr> not sure how it interacts with old-BSD's incompatibility
173 2013-09-23 06:09:08 <Luke-Jr> I guess if a Qt copyright holder warns us we can worry about it then (assuming LGPL 3)
174 2013-09-23 06:09:51 <Luke-Jr> we don't really need to worry about being unable to distribute binaries for old versions right now
175 2013-09-23 06:11:46 <warren> Luke-Jr: I'm semi-wrong, the linux build dynamic links qt. mac build dynamic links everything and ships it along with the .app installed by the .dmg. Only the windows build static links everything, probably to avoid the hassle of .dll's.
176 2013-09-23 06:13:00 <Luke-Jr> warren: DLLs aren't really a hassle if you just ship them alongside <.<
177 2013-09-23 06:13:35 <warren> Luke-Jr: I started dev in May. I didn't design any of this.
178 2013-09-23 06:14:45 <Luke-Jr> I know :p
179 2013-09-23 06:15:25 <warren> grrr
180 2013-09-23 06:15:36 <warren> checking for exit in -lboost_system-mt... no
181 2013-09-23 06:15:36 <warren> checking for exit in -lboost_system-mt-s... no
182 2013-09-23 06:15:36 <warren> configure: error: Could not link against boost_system-mt !
183 2013-09-23 06:15:43 <warren> I might need help from coryfields on this.
184 2013-09-23 06:17:02 <warren> checking for i686-w64-mingw32-pkg-config... no
185 2013-09-23 06:17:03 <warren> checking for pkg-config... /usr/bin/pkg-config
186 2013-09-23 06:17:03 <warren> configure: WARNING: using cross tools not prefixed with host triplet
187 2013-09-23 06:17:06 <warren> this is probably not good either
188 2013-09-23 06:17:31 <Luke-Jr> that one looks like a bug with our automake imo
189 2013-09-23 06:17:35 <Luke-Jr> pkg-config shouldn't need a prefix
190 2013-09-23 06:17:52 <Luke-Jr> nevermind, mine does so I guess it is normal
191 2013-09-23 06:17:57 <warren> well, it shouldn't use the standard pkg-config here
192 2013-09-23 06:18:10 <Luke-Jr> I was thinking it'd be the same binary with an env var
193 2013-09-23 06:18:42 <warren> I guess the pre-autotools bitcoin didn't use pkgconfig at all
194 2013-09-23 06:20:02 <Luke-Jr> nope
195 2013-09-23 06:20:51 <Luke-Jr> yay for supporting platforms without shared objects? XD
196 2013-09-23 06:21:49 <Belxjander> Luke-Jr: "Shared Objects" or "Shared Libraries" ?
197 2013-09-23 06:22:08 <Luke-Jr> Belxjander: same thing.
198 2013-09-23 06:22:21 <Belxjander> not really
199 2013-09-23 06:22:39 <Luke-Jr> â¦
200 2013-09-23 06:23:18 <Luke-Jr> http://en.wikipedia.org/wiki/Shared_object
201 2013-09-23 06:23:56 <Belxjander> Shared Objecfs and Shared Lbiraries are not always the same thing
202 2013-09-23 06:25:37 <Luke-Jr> in this context they are
203 2013-09-23 06:30:12 <Belxjander> okay...
204 2013-09-23 06:30:19 <Belxjander> POSIX?
205 2013-09-23 08:00:19 <BlueMatt> ;;later tell TD pong, though usually better to avoid the ping/pong latency and just send what you meant to ask to begin with :)
206 2013-09-23 08:00:19 <gribble> The operation succeeded.
207 2013-09-23 08:06:15 <michagogo> cloud|In what form and at what time does gribble tell things later?
208 2013-09-23 08:19:17 <warren> if anyone is available and knows autotools, I'm very close to getting 12.04-based gitian working for gitiain-win32.yml
209 2013-09-23 08:19:36 <warren> https://github.com/wtogami/bitcoin/tree/gitianwtogami
210 2013-09-23 08:20:23 <warren> https://togami.com/~warren/temp/build.log see where it fails in configure. It could be related to the pkg-config thing before it fails to find boost.
211 2013-09-23 08:20:38 <warren> PM me if you want the pre-built deps so you can reproduce this faster.
212 2013-09-23 08:25:18 <michagogo> cloud|warren: I don't know much about the tools, but if you want more testing on a different system, let me know
213 2013-09-23 08:26:41 <warren> michagogo|cloud: well, this is trying to fix win32 gitian in particular, so there are no other systems for this.
214 2013-09-23 08:27:03 <michagogo> cloud|I mean, different host systems
215 2013-09-23 08:27:29 <michagogo> cloud|(Though I guess that's not likely to make any significant differences)
216 2013-09-23 08:47:15 <davout> is there a way in the stock client to fetch details about an arbitrary TX ?
217 2013-09-23 08:47:30 <davout> last time I checked it was only possible to pull TXes related to your own wallet
218 2013-09-23 08:47:48 <davout> (fetch details as in JSON)
219 2013-09-23 08:48:15 <michagogo> cloud|davout: like what you get from getrawtransaction txid 1?
220 2013-09-23 08:50:17 <warren> davout: txindex=1 reindex=1 I think will allow that?
221 2013-09-23 09:22:24 <davout> i'll try that, thanks!
222 2013-09-23 09:23:00 <michagogo> cloud|davout: Don't put that in your config file
223 2013-09-23 09:23:30 <michagogo> cloud|Just run it with those command line arguments
224 2013-09-23 09:24:20 <michagogo> cloud|You only need to do it once, and while it won't hurt to have txindex in conf, reindex in conf will reindex every start
225 2013-09-23 09:24:30 <michagogo> cloud|Which you probably don't want
226 2013-09-23 09:36:56 <davout> michagogo|cloud: exactly what I needed, thanks a lot!
227 2013-09-23 09:46:07 <warren> grrr
228 2013-09-23 09:46:17 <warren> I had to manually do: i686-w64-mingw32-ranlib /home/ubuntu/staging/lib/libboost*.a
229 2013-09-23 09:46:34 <warren> perhaps it was fine pre-autotools?
230 2013-09-23 09:48:42 <wumpus> warren: probably; the autotools build system is still a bit experimental
231 2013-09-23 09:49:05 <wumpus> it's generally working fine, but there may be some rough edges still
232 2013-09-23 09:49:31 <warren> wumpus: i'm stuck on another error
233 2013-09-23 09:49:31 <wumpus> though I doubt autotools has anthing to do with building boost
234 2013-09-23 09:49:41 <sipa> gavinandresen: even without win64 builds, i'm in favor of moving away from mingw32 in favor of mingw-w64 (as the latter uses a much more recent gcc, is better maintained, and also supports win32 builds)
235 2013-09-23 09:49:46 <sipa> warren: ^
236 2013-09-23 09:49:48 <wumpus> that ranlib line should be in the gitian script somewhere IIRC
237 2013-09-23 09:49:56 <wumpus> sipa: +1
238 2013-09-23 09:50:03 <warren> wumpus: yeah 'im adding it
239 2013-09-23 09:50:18 <warren> wumpus: please PM me your e-mail? I'll forward you all details.
240 2013-09-23 09:50:27 <wumpus> mingw-w64 is a really confusing name, as it can build for either 32 bit or 64 bit windows, but it's better than mingw32 in all aspects
241 2013-09-23 09:50:47 <warren> ACTION adds ranlib
242 2013-09-23 09:51:32 <wumpus> warren: maybe it got removed accidentally, in older version it should be there IIRC
243 2013-09-23 09:52:03 <wumpus> the boost build was a bit strange, I never entirely understood why the manual ranlib line was neede
244 2013-09-23 09:52:18 <wumpus> but it worked so yeah...
245 2013-09-23 09:52:55 <warren> wumpus: sent mail, the branch is lacking ranlib line, adding now
246 2013-09-23 09:53:13 <michagogo> If there are 2 transactions, forming a double-spend of the same input, with outputs to 2 different addresses in the same bitcoin-qt wallet, how does the client handle that?
247 2013-09-23 09:58:17 <sipa> the first one gets into the mempool
248 2013-09-23 09:58:25 <sipa> the second is ignored
249 2013-09-23 09:59:18 <warren> falling asleep
250 2013-09-23 09:59:22 <michagogo> sipa: And if the second gets confirmed?
251 2013-09-23 09:59:30 <warren> wumpus: coryfields; falling asleep, will work more on this tomorrow
252 2013-09-23 10:00:00 <wumpus> ok, later
253 2013-09-23 11:14:06 <xfers> Operating System Platform:«Windows 7» UpTime:«1 Week 15 Hours 13 Minutes 27 Seconds» Record UpTime:«1 Week 15 Hours 12 Minutes 17 Seconds» ÂI-n-v-i-s-i-o-nÂ
254 2013-09-23 11:15:02 <xfers> Current System Configuration ÂI-n-v-i-s-i-o-nÂ
255 2013-09-23 11:15:03 <xfers> CPU/MEM: Intel P4 3.6GHz with Hyperthreading with Currently 559 of 2048MB in use which is 27.29%
256 2013-09-23 11:15:03 <xfers> Display System: n/a using a n/a monitor at 1280 by 1024 32bit color 60Hz refresh
257 2013-09-23 11:15:03 <xfers> Operating System: Unknown Windows NT Kernel OS up for 1 weeks, 15 hours, 13 minutes 13 seconds
258 2013-09-23 11:15:03 <xfers> Storage System: n/a Internet Connection: n/a
259 2013-09-23 11:17:29 <xfers> ACTION is running ÂI-n-v-i-s-i-o-n 2.0 Build 3515 with Advanced File Serving features by cRYOa on mIRC v7.19 32bit obtained from:« http://www.i-n-v-i-s-i-o-n.com »
260 2013-09-23 11:28:12 <K1773R> +b xfers
261 2013-09-23 11:28:53 <xfers> mind your business douche
262 2013-09-23 11:29:56 <DiabloD3> gmaxwell: ban xfers
263 2013-09-23 11:30:27 <xfers> what you just woke up kiddys
264 2013-09-23 11:33:10 <xfers> im on a desktop even a kban is ineffective
265 2013-09-23 11:33:31 <michagogo> ...sure.
266 2013-09-23 11:47:11 <xfers> buy my nick for 1 btc
267 2013-09-23 12:31:41 <sipa> michagogo: then the second is confirmed, and the first us removed from the mempool
268 2013-09-23 12:33:03 <michagogo> sipa: And if a transaction is double-spent to a wallet address and to another address, and the transaction to the non-wallet address confirms, how long will it take for Bitcoin-Qt to forget about the transaction sent to it that will never confirm?
269 2013-09-23 12:33:35 <michagogo> (or will it hold on to that impossible-to-confirm transaction forever?)
270 2013-09-23 12:43:27 <sipa> michagogo: the wallet never forgets
271 2013-09-23 12:43:44 <michagogo> Yikes.
272 2013-09-23 12:43:57 <sipa> yeah, that needs fixing
273 2013-09-23 12:44:07 <michagogo> Shouldn't there be some mechanism for getting rid of a wallet transaction that is known will never confirm?
274 2013-09-23 12:44:08 <sipa> it should be able to detect conflicts with the blockchain
275 2013-09-23 12:44:12 <michagogo> Indeed.
276 2013-09-23 12:44:32 <sipa> and even if not, a way to mark a transaction as 'deceased' or something after some time of non-confirming
277 2013-09-23 13:09:42 <TD> sipa: for your block blacklisting change, did you ever get a chance to look at my last comment?
278 2013-09-23 13:12:56 <sipa> TD: just commented
279 2013-09-23 13:13:17 <sipa> i'll see how much is still relevant after the headers-first changes and add some comments
280 2013-09-23 13:14:09 <TD> i was wanting to use it to build a wallet re-org regression test for bitcoinj, but i can just merge it locally and do one by hand for now
281 2013-09-23 15:51:31 <jgarzik> Random thought,
282 2013-09-23 15:51:40 <jgarzik> Does the payment protocol support payouts?
283 2013-09-23 15:51:55 <jgarzik> It would be nice to have an alternative channel for /receiving/ funds from a website
284 2013-09-23 16:00:26 <TD> jgarzik: payouts?
285 2013-09-23 16:00:33 <TD> what do you mean?
286 2013-09-23 16:00:37 <gmaxwell> jgarzik: sure, just get yourself an SSL cert, and setup a webserver, and get everyone you want to pay you to add support for the payment protocol. :)
287 2013-09-23 16:01:53 <TD> i'm thinking the right way to go is have an icon inside gui wallets that you can drag to wherever you want (e.g. an email compose editor to send via email, IM window for file transfer, USB stick for sneakernet, etc)
288 2013-09-23 16:01:53 <TD> jgarzik: you'd generate an unsigned request for that, obviously ;)
289 2013-09-23 16:02:49 <michagogo> Does the bitcoind/bitcoin-qt debug window's createrawtransaction know about multisigs?
290 2013-09-23 16:03:21 <michagogo> (i.e. if you give it an output to a multisig in the first parameter, will it know what to do?)
291 2013-09-23 16:03:54 <jgarzik> TD, real world example: just-dice returning my investment to me. End users should not need to set up a web server for something like that.
292 2013-09-23 16:03:56 <jgarzik> gmaxwell, ^
293 2013-09-23 16:04:11 <TD> well both the protocol and implementation support refund addresses
294 2013-09-23 16:04:15 <TD> so .... that sounds like a refund to me?
295 2013-09-23 16:04:20 <jgarzik> with no payment
296 2013-09-23 16:05:05 <TD> so you're the one requesting payment in that case. you'd give just-dice a payment request of course. gavin's current code doesn't support doing that, but the whole reason the payment protocol is designed the way it is, is exactly so you _don't_ need a web server
297 2013-09-23 16:05:30 <TD> remember that the original proposals all required you to use a regular web server because they assumed "identity == web server name"
298 2013-09-23 16:05:47 <TD> i lobbied for the identity to be inside the payment request itself so you can attach them to emails, etc, and it's still fully functional
299 2013-09-23 16:06:25 <TD> for the just-dice case, again, you'd want drag/drop from the wallet to the web page
300 2013-09-23 16:06:32 <TD> identity isn't required for that use case.
301 2013-09-23 16:09:12 <TD> ideally the entire UI could be "enter email address, copy/paste pubkey into web page, press go" and then you get your cert delivered in an attachment
302 2013-09-23 16:09:12 <TD> most CA's make it super complicated for no good reason. but there are probably a few CA's out there that don't have a sucky enrollment procedure.
303 2013-09-23 16:09:12 <TD> still, even if it was, there's no law that says CA's have to suck at issuing email certs
304 2013-09-23 16:09:49 <jgarzik> Tangent: I want websites to support login via bitcoin ECDSA challenge -> signed response
305 2013-09-23 16:10:00 <TD> well, SSL already supports that. it's called client certificates.
306 2013-09-23 16:10:06 <jgarzik> tired of passwords and NSA-compromised root CAs
307 2013-09-23 16:10:07 <TD> it's not using "bitcoin keys" i.e. secp256k1
308 2013-09-23 16:10:12 <TD> but it's basically the same idea
309 2013-09-23 16:10:38 <jgarzik> yes, SSL is questionable crap I don't trust at this point ;p
310 2013-09-23 16:10:44 <TD> it's actually a PITA because you end up having to make sure you copy your cert to any device that is going to log in, passwords are much more convenient. however, most devices/browsers do have decent support for it
311 2013-09-23 16:10:53 <TD> why? it's just a container for crypto with some algorithm negotiation
312 2013-09-23 16:11:01 <TD> SSL itself is fine. you aren't going to do a better job by yourself.
313 2013-09-23 16:11:56 <sipa> SSL is a mess, but it's a mess mostly because it's a hard problem
314 2013-09-23 16:11:58 <TD> it basically means you open up a file and agree to install it into the local keychain
315 2013-09-23 16:12:04 <TD> then browsers can use it when the server requests a challenge
316 2013-09-23 16:12:11 <jgarzik> The CA infrastructure is problematic, implementations have had many security flaws, and it's likely others are lurking unknown. the zlib thing was a huge mistake.
317 2013-09-23 16:12:11 <TD> it can be entirely transparent in the best case
318 2013-09-23 16:12:35 <TD> it's not really "problematic" except in the sense that it's the best the world has got, and it's not as good as people would like. certificate transparency is going to be a huge upgrade to that
319 2013-09-23 16:12:43 <TD> but it'll take a long time to roll out just because the CA infrastructure is huge
320 2013-09-23 16:13:49 <TD> at that point CA's will no longer need to be so trusted
321 2013-09-23 16:13:53 <TD> so, big improvement.
322 2013-09-23 16:14:18 <TD> as to the others, "crypto software is hard" - yes it is, which is why there's safety in numbers :)
323 2013-09-23 16:15:56 <TD> ACTION -> out for the evening
324 2013-09-23 17:00:35 <muhoo> oh for fuck's sake. multibit will not let me enter an amount into the amount box to send coins.
325 2013-09-23 17:00:39 <muhoo> fucking java
326 2013-09-23 17:01:42 <muhoo> it's a text box, and it won't accept a mouse click to get a cursor. it's stuck at 0.525 BTC for some reason, i didn't enter it, and that's not the amount i want to send
327 2013-09-23 17:02:03 <jgarzik> <tab> ?
328 2013-09-23 17:05:09 <gmaxwell> muhoo: oh. I thought that was just me! I think I got it working by tabbing like jgarzik suggests.
329 2013-09-23 17:06:30 <muhoo> tabbing ain't doing it either
330 2013-09-23 17:09:00 <muhoo> haha, i restarted multibit, it worked. once. then it stopped
331 2013-09-23 17:09:12 <muhoo> so, i had a cursor, for like a second. then nothing.
332 2013-09-23 17:09:20 <muhoo> ACTION prepares to defenestrate multibit
333 2013-09-23 17:09:45 <muhoo> this is why web wallets are popular. they work.
334 2013-09-23 17:10:35 <pankkake> no, this is why java isn't popular. it doesn't work.
335 2013-09-23 17:10:38 <muhoo> just for fun, got a cursor, but paste dosn't work.
336 2013-09-23 17:10:50 <muhoo> java ui is just clown shoes.
337 2013-09-23 17:20:00 <Luke-Jr> :|
338 2013-09-23 17:20:15 <kjj> jgarzik: regarding decentralized stock exchange, have you considered models other than the one you quote from March?
339 2013-09-23 17:27:37 <phantomcircuit> tbh im not sure multibits problems have much to do with java
340 2013-09-23 17:27:50 <phantomcircuit> the main issue would seem to be that there's only one person working on it
341 2013-09-23 17:31:11 <jgarzik> kjj, other models exist and are valid but I think it is a healthy and resilient system to break up things into pieces, making them auditable and massively replicated
342 2013-09-23 17:31:33 <jgarzik> kjj, I was going to write a blog post, so your input is welcome
343 2013-09-23 17:36:36 <warren> wumpus: ranlib was removed from gitian-win32.yml during the autotools commits, coryfields probably thought it was needed.
344 2013-09-23 17:36:50 <warren> wumpus: I'm stuck, need to wait for him
345 2013-09-23 17:36:51 <sipa> + didn't ?
346 2013-09-23 17:37:02 <warren> oops, yes.
347 2013-09-23 17:37:49 <warren> I haven't tried restoring that for loop
348 2013-09-23 17:37:55 <warren> maybe I should
349 2013-09-23 17:38:33 <wumpus> warren: yes, he probably thought so, can't you just restore it?
350 2013-09-23 17:38:43 <sipa> i'd try that
351 2013-09-23 17:38:51 <wumpus> he has the cut first think later approach :)
352 2013-09-23 17:39:21 <sipa> it's probably true that it shouldn't be in gitian descriptors directly, but rather done from within autotools if it's actually necessary
353 2013-09-23 17:39:30 <sipa> but it can always be moved there later
354 2013-09-23 17:40:05 <wumpus> why would it need to be done in autotools? I think the autotools should just assume that boost is installed properly, and not include strange gitian specific hacks
355 2013-09-23 17:40:25 <sipa> right, i may have too little context
356 2013-09-23 17:40:31 <sipa> but why is that ranlib call necessary?
357 2013-09-23 17:40:55 <wumpus> IIRC because somehow gitian doesn't install boost properly before packing it up
358 2013-09-23 17:41:03 <sipa> ah, ic
359 2013-09-23 17:41:10 <wumpus> it just packages up the compiled directory
360 2013-09-23 17:41:18 <sipa> maybe it should do an actual install then
361 2013-09-23 17:41:22 <sipa> and then pack up
362 2013-09-23 17:41:30 <wumpus> yeah that'd be better, just no one ever bothered
363 2013-09-23 17:48:45 <kjj> jgarzik: the idea I've been kicking around for the last year is a namecoin-like chain for shares
364 2013-09-23 17:52:05 <jgarzik> kjj, For many types of stocks or bonds, the issuer is the one that gives the issue its value. If no dividends are paid or operations performed, value rapidly goes to zero. Therefore, for the majority of cases, you necessarily have a de facto central authority for each issue.
365 2013-09-23 17:52:48 <jgarzik> kjj, One of the nice things about the pybond scheme -- attaching metadata to a normal bitcoin transaction -- is that the central authority's ability to inflate the [presumably] audited metadata is reduced
366 2013-09-23 17:53:04 <jgarzik> That was namecoin-like
367 2013-09-23 17:53:17 <gmaxwell> There are plenty of things you could do to improve transparency in that model (e.g. having them maintain a public ledger that users copy)â but simply mixing in a blockchain reduces security rather than improving it.
368 2013-09-23 17:53:35 <kjj> why do I need the issuer's permission to transfer shares to someone else?
369 2013-09-23 17:53:42 <jgarzik> The main questions are: (a) where is the shareholder registry stored, and (b) how to enable third party -> third party transfers, without inflating the share count (== double spending)
370 2013-09-23 17:54:12 <jgarzik> kjj, you don't /need/ it per se, but you do need a mechanism to prevent share inflation
371 2013-09-23 17:54:32 <kjj> if the issuer has veto power over all transfers, the shares are not fungible
372 2013-09-23 17:54:52 <jgarzik> The issuer in most cases has de facto veto power anyway
373 2013-09-23 17:54:52 <phantomcircuit> jgarzik, you still have the fundamental problem that a security is ultimately only worth what the underwriter will actually produce
374 2013-09-23 17:54:55 <gmaxwell> kjj: the issuer _always_ has veto power.
375 2013-09-23 17:54:59 <jgarzik> nod
376 2013-09-23 17:55:03 <gmaxwell> kjj: because they could just not honor those transfers.
377 2013-09-23 17:55:05 <phantomcircuit> which in the case of anonymously held securities is probably nothing
378 2013-09-23 17:55:11 <jgarzik> or not pay dividends
379 2013-09-23 17:55:11 <kjj> only globally, not with granularity
380 2013-09-23 17:55:22 <gmaxwell> kjj: with whatever granularity they like.
381 2013-09-23 17:55:57 <jgarzik> you can certainly selectively withhold dividends
382 2013-09-23 17:56:08 <gmaxwell> or pay them to other people.
383 2013-09-23 17:56:15 <kjj> which would be regarded as a default
384 2013-09-23 17:56:23 <jgarzik> not if 99% still get paid
385 2013-09-23 17:56:36 <jgarzik> or perceive the withholding to be virtuous in some regard
386 2013-09-23 17:56:37 <kjj> even a single share that isn't paid is a default
387 2013-09-23 17:56:43 <gmaxwell> kjj: then you could also equally regard denying a trade as a default. They're equivalent.
388 2013-09-23 17:56:57 <gmaxwell> kjj: they can happily show who they paid instead.
389 2013-09-23 17:57:22 <kjj> how would you prove that a transfer was ignored?
390 2013-09-23 17:57:39 <phantomcircuit> jgarzik, i know that the primary reason people want decentralized securities is to avoid the exchange/clearinghouse/title company shutdown issue that happened with GLBSE and now with BTC-TC
391 2013-09-23 17:57:40 <kjj> you show your signed sales ticket, they say they never got it
392 2013-09-23 17:58:06 <phantomcircuit> jgarzik, but that ignores the fundamental issue that those securities were largely only valuable when actively traded on such a site
393 2013-09-23 17:58:24 <kjj> the point I usually get down to is that we don't accept ANY of that bullshit in bitcoin, so why do we accept it for other systems?
394 2013-09-23 17:59:08 <phantomcircuit> kjj, the issue is more that even if you have a signed sales receipt, you cant really prove that it doesn't belong to someone else
395 2013-09-23 17:59:25 <phantomcircuit> even if the signed received contains a signed message from a private key you hold
396 2013-09-23 17:59:48 <jgarzik> phantomcircuit, no, it doesn't ignore the issue, precisely the opposite: it creates an atmosphere/incentives where it is easier for another market to spring up. people will inevitably forum shop from there.
397 2013-09-23 17:59:49 <gmaxwell> kjj: because you can't actually remove it in "something" else that is predicated on the idea of a centeral issuer.
398 2013-09-23 17:59:56 <phantomcircuit> kjj, with bitcoin the bitcoins themselves are the thing of value
399 2013-09-23 18:00:13 <phantomcircuit> with a security the value is based on something else
400 2013-09-23 18:00:26 <gmaxwell> kjj: it's pretty easy to establish if they're ignoring an order or notâ no harder than establishing that they're mispaying a dividend.
401 2013-09-23 18:00:49 <phantomcircuit> jgarzik, i understand the idea, but my point is that most of the issued securities on those sites have a true market value of roughly zero
402 2013-09-23 18:00:56 <kjj> gmaxwell: it is in fact MUCH harder to prove
403 2013-09-23 18:01:04 <phantomcircuit> jgarzik, a decentralized securities holding system would likely bear that out
404 2013-09-23 18:01:30 <phantomcircuit> example, even after GLBSE shutdown nefario made it possible for asset holders to prove their ownership
405 2013-09-23 18:01:31 <kjj> if the shares are controlled by a globally distributed system, the dividend payment can be matched automatically to the shares held
406 2013-09-23 18:01:35 <Cusipzzz> phantomcircuit: ++ most exist solely for the speculation and gambling aspect - remove the liquid marketplace and poof
407 2013-09-23 18:01:39 <gmaxwell> kjj: it's not. You can just use whatever jamming resistant channel you would have used in one in the other.
408 2013-09-23 18:01:40 <phantomcircuit> but most of the people who issued assets simply ignored it
409 2013-09-23 18:01:51 <phantomcircuit> and yelled as loudly as possible that he was stealing
410 2013-09-23 18:01:56 <phantomcircuit> to cover their own thefts
411 2013-09-23 18:02:22 <kjj> jamming resistant? I'm not sure we are talking about the same thing at all
412 2013-09-23 18:02:34 <gmaxwell> kjj: E.g. if the issuer doesn't voluntarily take the transfer you can do the transfer just as you would have done in your lame ass world spamming blockchain bullshit system, and then it's the same.
413 2013-09-23 18:02:36 <kjj> the problem is that if there is a central issuer, they can claim they never saw your order
414 2013-09-23 18:02:59 <kjj> ok, so your system requires that my system exist. good system
415 2013-09-23 18:03:15 <phantomcircuit> jgarzik, i think my point is that the lesson from bitcoin is that the technical and economic factors need to line up, with decentralized securities issued by ??? the economic incentive for them will always be to cheat
416 2013-09-23 18:03:28 <gmaxwell> kjj: Don't be a dickwad, that isn't waht I'm saying.
417 2013-09-23 18:03:45 <kjj> I'm the dickwad? you may want to read your recent replies
418 2013-09-23 18:03:47 <jgarzik> phantomcircuit, it depends on the issuer
419 2013-09-23 18:03:56 <jgarzik> phantomcircuit, ASICMINER is an interesting example
420 2013-09-23 18:03:58 <gmaxwell> kjj: wtf?
421 2013-09-23 18:04:42 <kjj> your lame ass totally centralized fully trusted bullshit system is useless if it requires a fallback to a trustless system. what am I missing?
422 2013-09-23 18:05:22 <phantomcircuit> jgarzik, sure, but the point is that the technical details of how asset ownership was collected/traded/whatever was largely irrelevant except so far as to provide the appearance of a liquid marketplace
423 2013-09-23 18:05:47 <phantomcircuit> jgarzik, to have that appearance more or less requires that the assets be held by the exchange
424 2013-09-23 18:06:28 <phantomcircuit> although i would be interested in a decentralized exchange system in which participants were required to prove ownership of the asset they were selling
425 2013-09-23 18:06:43 <jgarzik> phantomcircuit, yes, I agree there
426 2013-09-23 18:06:47 <gmaxwell> kjj: not at allâ I'm pointing out that at a minimum you can have a system which creates no blockchain load or bloat (and thus isn't subject to censorship by miners), and still can't be censored by the issuer so long as any jamming resistant communications channel actually exists at all.
427 2013-09-23 18:06:55 <phantomcircuit> im fairly certain a btc/ltc exchange is technically possible without a third party holding anything
428 2013-09-23 18:07:40 <jgarzik> phantomcircuit, yes
429 2013-09-23 18:07:52 <kjj> gmaxwell: I'm not sure that is really possible. if the issuer of a share is responsible for publishing a list of all transactions or holdings, I'm not sure how you can force them to accept something they don't want to accept, other than by having humans ponder the situation
430 2013-09-23 18:07:59 <phantomcircuit> effectively have an order selling btc (make sure the format of the order definitely never looks like a bitcoin transaction :P ) and sign it with the private keys in question
431 2013-09-23 18:08:21 <phantomcircuit> the hard part is the actual exchange though since who goes first, or maybe nobody even has to go first
432 2013-09-23 18:08:25 <jgarzik> All this back and forth nonwithstanding, I do think there is value in having a property registry (share registry) chain, kjj
433 2013-09-23 18:08:35 <phantomcircuit> (im sure someone has an idea how nobody has to go first)
434 2013-09-23 18:08:38 <jgarzik> But the issuer holds all the cards
435 2013-09-23 18:08:41 <jgarzik> in the end
436 2013-09-23 18:08:47 <kjj> gmaxwell: and my idea is for a second chain dedicated to share ownership. the only bloat in the currency chain would be the standard merged mining load
437 2013-09-23 18:09:05 <warren> jgarzik: an exodus address manually operated by someone? =)
438 2013-09-23 18:09:16 <gmaxwell> kjj: The issuer is _always_ responsible to abide by the rules. If they don't all bets are off. If you want to make sure that you can always catch them when they don't, you can always invoke whatever jamming resistant channel you _think_ you have only in the exceptional case that they are being dishonest in the very specific way that might be helped by that.
439 2013-09-23 18:09:16 <phantomcircuit> jgarzik, right and it's an interesting concept, but i suspect it would be a lot of effort for something that would be largely unused
440 2013-09-23 18:09:26 <phantomcircuit> (but maybe im misjudging the market..?)
441 2013-09-23 18:09:36 <kjj> jgarzik: the issuer holds some of the cards. having a fully decentralized system greatly reduces their options.
442 2013-09-23 18:10:11 <phantomcircuit> kjj, "what contract? what's a private key? WHO ARE YOU PEOPLE GET OFF MY LAWN"
443 2013-09-23 18:10:28 <jgarzik> kjj, you can prove they are cheating, but they still have control
444 2013-09-23 18:10:31 <gmaxwell> kjj: and then in your second chain, which hardly has any miners because who is interested in that? things are freely reorganized and all your shares get stolen, even when the issuer themself is not dishonest. This is a bad idea. The issuer must be honest or the shares are _worthless_, so now that you have a trusted point why make a system which is less secure?
445 2013-09-23 18:11:00 <kjj> gmaxwell: by that logic, bitcoin never took off either
446 2013-09-23 18:11:51 <kjj> jgarzik: if they are not in charge of transactions with the shares they issued, they won't know who they are cheating if they don't pay all shares properly
447 2013-09-23 18:12:15 <phantomcircuit> kjj, you're missing a keypoint, bitcoins are valuable by themselves, those securities are worthless without the issuer following the contract
448 2013-09-23 18:12:24 <gmaxwell> kjj: bitcoin has spent most of its life not terribly secure. And you predicate a system with far less interest in it would be secure? go look at all the altcoins that have been throughly exploited.
449 2013-09-23 18:12:28 <kjj> jgarzik: which means they effectively have zero control over who they pay, just if they pay or not
450 2013-09-23 18:12:30 <phantomcircuit> kjj, otherwise you're just running a very complicated altcoin...
451 2013-09-23 18:12:47 <gmaxwell> And in bitcoin the argument doesn't apply, there is no trusted party that you could reduce things to.
452 2013-09-23 18:13:02 <kjj> phantomcircuit: bitcoins have value because they are useful. you don't think this would be useful too?
453 2013-09-23 18:13:26 <gmaxwell> If bitcoin was closed source I would agree "why bother with the blockchain, just trust the closed source developer guy to sign the valid transactions".
454 2013-09-23 18:13:45 <kjj> gmaxwell: why do you assume it will be less popular than bitcoin? the last time I checked, currency was a wart on the face of the bond market
455 2013-09-23 18:14:22 <kjj> if we assume that bitcoins are better money than money, why wouldn't these new things be better shares than shares?
456 2013-09-23 18:14:22 <phantomcircuit> kjj, actually no i dont since i cant see it adding value beyond the issuer just giving out signed receipts with your name on it
457 2013-09-23 18:14:39 <phantomcircuit> especially since in almost all cases an issuer is allowed to issue infinitely more shares
458 2013-09-23 18:15:01 <kjj> phantomcircuit: issuance could be locked in up front, much like it is in bitcoin
459 2013-09-23 18:15:26 <jgarzik> kjj, Why would issuers prefer that over the more flexible approach?
460 2013-09-23 18:15:35 <gmaxwell> kjj: bitcoin a _different_ money, better is objectively false now. Go pay your rent in bitcoin. :P For money like goods we have a different set of problems, e.g. the scarcity is a fraud that largely doesn't exist for shares and can be audited away.
461 2013-09-23 18:15:36 <phantomcircuit> they wouldn't
462 2013-09-23 18:15:41 <kjj> even better, dilution could be voted by protocol, with the terms set in advance
463 2013-09-23 18:16:03 <jgarzik> investors might like that, but issuers will choose preferable, more flexible terms
464 2013-09-23 18:16:34 <kjj> jgarzik: neither side exists in a vacuum. do you think merchants pay 3% credit card fees because they like paying fees?
465 2013-09-23 18:17:38 <gmaxwell> kjj: again, what have you added by adding this huge, costly, globally visable shared fate system, which has ambigious (or at least unsettled) security properties? You don't gain security against a misbehaving issuer.
466 2013-09-23 18:18:24 <gmaxwell> At most you gain making some kinds of misbehavior more visible, but you can achieve that without using that system in the common case, and just using it to announce misbehavior.
467 2013-09-23 18:18:30 <kjj> gmaxwell: as I've explained several times already, you limit the mischeif that an issuer can perform
468 2013-09-23 18:18:48 <kjj> er, mischief. one of those
469 2013-09-23 18:19:34 <gmaxwell> And if you take its purpose as just announcing misbehavior you can adopt a radically different design that has better scaling properties and does a better job at actually acheving that goal. For example, you could have something which can never be reorged where any future state update your node accepts must include everything in your current state.
470 2013-09-23 18:19:52 <warren> wumpus: restoring it won't work, the boost-win32.yml appears to package a lot less than it used to, I'm looking at fixing it there now.
471 2013-09-23 18:21:41 <kjj> gmaxwell: that isn't the only goal, just the most obvious practical benefit
472 2013-09-23 18:22:37 <kjj> the main goal is to provide a decentralized system for registering ownership of fractions of things
473 2013-09-23 18:23:18 <gmaxwell> kjj: except you failed in that goal when the thing is a centeralized thing. :P
474 2013-09-23 18:23:52 <kjj> gmaxwell: only if you are using a very non-standard meaning of one of your words
475 2013-09-23 18:24:12 <warren> wumpus: yeah, the old boost-win32*.zip stored all the .o files, then relied upon gitian-win32.yml to use ranlib to stuff it into .a files.
476 2013-09-23 18:24:19 <cfields> warren: hmm, yes ranlib is needed
477 2013-09-23 18:24:20 <kjj> for example, if "failed" means "succeeded", then you would be right
478 2013-09-23 18:24:54 <cfields> ranlib doesn't create .a files, it adds an index inside already-created ones
479 2013-09-23 18:24:57 <warren> cfields: i'll insert a ranlib loop in boost-win32.yml similar to the old gitian-win32.yml
480 2013-09-23 18:25:03 <warren> hm
481 2013-09-23 18:25:06 <cfields> no, that's a nasty hack
482 2013-09-23 18:25:19 <cfields> installing it should be enough. what's the problem?
483 2013-09-23 18:25:31 <warren> cfields: the problem was sent to you via email
484 2013-09-23 18:26:25 <cfields> multiple definition of `__tls_used'
485 2013-09-23 18:26:26 <cfields> that one?
486 2013-09-23 18:28:16 <warren> cfields: the previous one
487 2013-09-23 18:28:41 <warren> cfields: the second mail was after configure succeeded after I blindly ranlib on every .a
488 2013-09-23 18:29:10 <cfields> warren: please point me to a log somewhere, i don't know what i'm supposed to be looking at
489 2013-09-23 18:29:31 <warren> cfields: https://togami.com/~warren/temp/build.log
490 2013-09-23 18:30:08 <warren> cfields: https://github.com/wtogami/bitcoin/tree/gitianwin32 gbuild of this gitian-win32.yml results in that build.log
491 2013-09-23 18:30:23 <cfields> could you please post the config.log to go with it?
492 2013-09-23 18:31:08 <warren> hmm, know how to get arbitrary files out of the gitian VM?
493 2013-09-23 18:31:55 <cfields> on-target cat foo.txt
494 2013-09-23 18:32:52 <warren> building again to get the log
495 2013-09-23 18:37:19 <warren> cfields: https://togami.com/~warren/temp/config.log
496 2013-09-23 18:39:41 <cfields> mmm, can i see the boost build output as well?
497 2013-09-23 18:40:11 <warren> grr, doing that again now
498 2013-09-23 18:40:15 <warren> cfields: var/build.log ?
499 2013-09-23 18:40:29 <cfields> yea, for boost
500 2013-09-23 18:40:41 <warren> building
501 2013-09-23 18:40:42 <cfields> my guess is that boost finds and incompatible ranlib and refuses to run it on the .a
502 2013-09-23 18:40:56 <cfields> *finds an
503 2013-09-23 18:43:09 <cfields> yep
504 2013-09-23 18:43:12 <cfields> warren: https://github.com/wtogami/bitcoin/commit/da42ae9e8b3d575ded653c23a543a421d3f6cd78#L0R24
505 2013-09-23 18:44:12 <cfields> hmm nm, that's valid
506 2013-09-23 18:45:02 <cfields> oh, you don't have mingw binutils installed for the boost build, though
507 2013-09-23 18:45:20 <warren> isn't that only a compat symlink package?
508 2013-09-23 18:45:27 <warren> I tried installing it but it doens't contain anything
509 2013-09-23 18:48:47 <cfields> http://packages.ubuntu.com/precise/amd64/binutils-mingw-w64-i686/filelist
510 2013-09-23 18:49:50 <warren> cfields: /usr/bin/i686-w64-mingw32-ranlib exists in the boost build environment
511 2013-09-23 18:50:44 <cfields> ok. will wait for log
512 2013-09-23 18:51:28 <michagogo> ACTION wishes he knew more about the inner workings of software building
513 2013-09-23 18:51:47 <michagogo> Basically, it's (mostly) a black box to me :-/
514 2013-09-23 18:52:38 <cfields> michagogo: dev on an obscure arch for a while and you'll be forced to figure it all out
515 2013-09-23 18:52:44 <michagogo> My skills are limited to "run the command (make or whatever), google or apt-get if anything appears to be missing"
516 2013-09-23 18:53:36 <warren> cfields: want an alpha? =)
517 2013-09-23 18:53:57 <cfields> warren: heh, just a log :)
518 2013-09-23 18:54:00 <warren> cfields: https://togami.com/~warren/temp/boost-build.log
519 2013-09-23 18:54:04 <cfields> i don't have a win32 install
520 2013-09-23 18:54:19 <michagogo> cfields: I don't really dev much -- I don't really know much coding, and what I do know is mostly interpreted and not compiled
521 2013-09-23 18:59:35 <warren> cfields: do you have a gitian capable machine?
522 2013-09-23 19:00:35 <cfields> warren: yea, building now
523 2013-09-23 19:04:25 <Luke-Jr> cfields: is your Mac gitian stuff published anywhere?
524 2013-09-23 19:05:20 <cfields> Luke-Jr: no, it was done by hand. i put it on pause until i can determine if it's worth the time or not
525 2013-09-23 19:11:32 <michagogo> Question: would a gitian build in LXC work and be deterministic?
526 2013-09-23 19:12:59 <michagogo> s/in LXC/using LXC and not KVM/
527 2013-09-23 19:13:04 <Luke-Jr> should
528 2013-09-23 19:13:32 <michagogo> Also: if LXC is not a full virtualization, would that mean that the host needs to be running lucid?
529 2013-09-23 19:14:45 <Ry4an> michagogo: LXC containers dont' have to match the distro of the host, but the host does have to be a relatively recent kernel
530 2013-09-23 19:14:54 <michagogo> Hmm, okay
531 2013-09-23 19:15:53 <michagogo> I was starting to look into a way to get gitian to work on Windows, but then stumbled upon a reference to LXC, and saw that it doesn't need hardware virtualization
532 2013-09-23 19:16:00 <michagogo> Which means that I could run it in a VM
533 2013-09-23 19:16:55 <Ry4an> we run 12.04 for our servers, but had to make the hosts 12.10 to please lxc/docker, so we host 12.04 in 12.10 now.
534 2013-09-23 19:17:07 <Ry4an> very impressed w/ it so far though, fwiw
535 2013-09-23 19:17:52 <DiabloD3> michagogo: docker isnt an virtual machine
536 2013-09-23 19:17:54 <DiabloD3> its a container
537 2013-09-23 19:18:01 <michagogo> docker?
538 2013-09-23 19:18:14 <DiabloD3> docker wraps lxc
539 2013-09-23 19:18:39 <DiabloD3> docker isnt virtualization at all
540 2013-09-23 19:18:46 <DiabloD3> its identical in use to bsd jails and solaris containers
541 2013-09-23 19:18:50 <michagogo> Anyway, if LXC hosts can be different from what runs in the container, that's nice
542 2013-09-23 19:18:56 <DiabloD3> single kernel, namespaced userlands
543 2013-09-23 19:19:04 <michagogo> because it means I can use my existing raring VM
544 2013-09-23 19:19:07 <DiabloD3> michagogo: no, because thats a virtual machine
545 2013-09-23 19:19:15 <michagogo> DiabloD3: Oh
546 2013-09-23 19:19:18 <DiabloD3> containers mean you have _one_ OS
547 2013-09-23 19:19:35 <michagogo> So to gitian-build bitcoin, I'd need to install a VM running lucid?
548 2013-09-23 19:19:45 <DiabloD3> no
549 2013-09-23 19:19:56 <DiabloD3> you can do it with an ubuntu image in docker fine
550 2013-09-23 19:20:07 <DiabloD3> gitian wouldnt care about the kernel
551 2013-09-23 19:20:15 <DiabloD3> but you could also do this in a standard jail too
552 2013-09-23 19:20:17 <warren> brb
553 2013-09-23 19:24:52 <cfields> warren: as i suspected, boost is using the wrong ranlib
554 2013-09-23 19:25:10 <sipa> bad bad boost
555 2013-09-23 19:25:31 <cfields> warren: <ranlib>i686-w64-mingw32-ranlib
556 2013-09-23 19:25:33 <cfields> that fixes
557 2013-09-23 19:25:39 <michagogo> What version of 10.04 does gitian use?
558 2013-09-23 19:25:41 <warren> cfields: thanks
559 2013-09-23 19:25:48 <michagogo> 10.04, or 10.04.something?
560 2013-09-23 19:26:01 <sipa> latest, i assume
561 2013-09-23 19:26:14 <michagogo> 10.04.4?
562 2013-09-23 19:28:06 <warren> cfields: does this boost build have hardening flags?
563 2013-09-23 19:28:20 <warren> we weren't able to use it before
564 2013-09-23 19:28:37 <cfields> warren: boost build imo should pretty much be left alone
565 2013-09-23 19:30:52 <cfields> if you enable verbose building, you'll see that they enable stuff on their own. not for us mere mortals to be second-guessing
566 2013-09-23 19:30:57 <cfields> my opinion, anyway
567 2013-09-23 19:33:05 <cfields> warren: also fyi, you can remove lots of the ar/ranlib hacks if you're bumping up to a more recent toolchain. deterministic options were added/fixed there.
568 2013-09-23 19:33:39 <sipa> cfields: is 12.04 sufficient for "more recent toolchain" ?
569 2013-09-23 19:33:58 <cfields> sipa: yea, should be
570 2013-09-23 19:34:21 <sipa> i think for 0.9 we could upgrade all things gitian to 12.04
571 2013-09-23 19:34:55 <sipa> only reason not to is 1) some testing overhead to see whether everything still works and 2) dropping support for pre-Precise linux systems
572 2013-09-23 19:36:43 <cfields> sipa: why would that mean dropping support?
573 2013-09-23 19:37:18 <sipa> cfields: i suppose binaries built on 12.04 may rely on libc features or other libraries that don't exist on 10.04-era systems
574 2013-09-23 19:37:42 <sipa> or is everything statically linked?
575 2013-09-23 19:37:56 <wumpus> qt is not statically linked on linux afaik
576 2013-09-23 19:38:04 <sipa> (i haven't touched precompiled binaries for a while)
577 2013-09-23 19:38:06 <wumpus> and glibc certainly not
578 2013-09-23 19:38:39 <cfields> yikes, i didn't realize lucid's glibc was so old
579 2013-09-23 19:38:44 <cfields> wumpus: qt is, libc isn't
580 2013-09-23 19:38:46 <wumpus> and statically linking glibc is very much discouraged
581 2013-09-23 19:39:29 <warren> static linking glibc might actually use LESS memory on fedora due to whatever bug exists
582 2013-09-23 19:39:37 <wumpus> it removed the buffer zone between user space and the kernel
583 2013-09-23 19:39:39 <warren> ACTION waits for gmaxwell to yell
584 2013-09-23 19:39:55 <cfields> warren: huh?
585 2013-09-23 19:40:12 <warren> cfields: there's some kind of bug where gitian binaries on fedora use as much as 200MB more RAM
586 2013-09-23 19:40:25 <warren> maybe 300MB more ram
587 2013-09-23 19:40:28 <warren> it gets bad
588 2013-09-23 19:40:36 <wumpus> ie, system call interface is suddenly fixed
589 2013-09-23 19:41:22 <wumpus> warren: maybe that's solved too when building on 12.04?
590 2013-09-23 19:41:52 <warren> wumpus: haven't tried upgrading the gitian linux because we don't want to drop older linux distros?
591 2013-09-23 19:42:11 <wumpus> I think the single set of binaries approach is broken for linux anyway, we really need per-distribution packages
592 2013-09-23 19:42:14 <sipa> meh, 10.04 desktop isn't supported anymore anyway
593 2013-09-23 19:42:20 <wumpus> (which we have for ubuntu of course)
594 2013-09-23 19:42:56 <wumpus> sipa: yeah...
595 2013-09-23 19:42:57 <warren> gitian binary aleady doesn't work on RHEL5. works on RHEL6. dunno if 12.04 giitan will break RHEL6.
596 2013-09-23 19:43:10 <warren> RHEL6 still has 200 years of support remaining
597 2013-09-23 19:43:41 <sipa> that may be an interesting consideration
598 2013-09-23 19:43:50 <wumpus> I have pity for the people that will still be supporting the same bugs in 200 years :)
599 2013-09-23 19:43:58 <sipa> that binary isn't for ubuntu client systems on;y
600 2013-09-23 19:44:05 <gmaxwell> Esp a consideration since you can't easily build bitcoin there.
601 2013-09-23 19:44:24 <warren> make secp256k1 standard and you can =)
602 2013-09-23 19:44:26 <warren> brb
603 2013-09-23 19:46:49 <jgarzik> yah, let's add libsecp256k1 to the repo similar to leveldb
604 2013-09-23 19:46:54 <jgarzik> default it to off, for now
605 2013-09-23 19:47:01 <jgarzik> but get it into the tree and building as an option
606 2013-09-23 19:47:35 <sipa> jgarzik: i have a branch that integrates libsecp256k1 into master
607 2013-09-23 19:47:35 <warren> jgarzik: +1
608 2013-09-23 19:48:03 <sipa> i can pullreq it, but i hoped to work on tests more before doing that
609 2013-09-23 19:48:06 <cfields> sipa: mind linking?
610 2013-09-23 19:48:18 <sipa> cfields: hmm?
611 2013-09-23 19:48:31 <warren> sipa: I still need to rebase all my gitian stuff onto your libsecp256k1 branch
612 2013-09-23 19:48:42 <sipa> warren: yes, please :)
613 2013-09-23 19:48:54 <cfields> sipa: can you link the branch? If it's headed into master, i'd like to have a look at the build side of things
614 2013-09-23 19:49:12 <michagogo> cfields: Guessing https://github.com/sipa/bitcoin/tree/secp256k1
615 2013-09-23 19:49:18 <sipa> https://github.com/sipa/bitcoin/commits/secp256k1
616 2013-09-23 19:49:19 <sipa> indeed
617 2013-09-23 19:49:26 <warren> sipa: although if cfields is doing that, I'll wait ...
618 2013-09-23 19:49:32 <cfields> you kept saying it was going to be a while, so i pushed that off my stack :)
619 2013-09-23 19:49:52 <warren> cfields: secp256k1 needs auditing and testing ...
620 2013-09-23 19:50:06 <sipa> cfields: i don't want to be responsible for wallet theft or chain forks because of my self-implemented crypto
621 2013-09-23 19:50:41 <cfields> it's intended to be optional and defaulted off to start, correct?
622 2013-09-23 19:50:56 <sipa> i'm sure people will use it nonetheless :)
623 2013-09-23 19:51:00 <sipa> (i would...)
624 2013-09-23 19:51:17 <warren> Litecoin has two builds, one standard, one with secp256k1
625 2013-09-23 19:51:32 <warren> we don't recommend people use the latter for mining or production
626 2013-09-23 19:51:57 <cfields> sipa: nice job on that, it really doesn't need much other than making it optional
627 2013-09-23 19:52:36 <sipa> cfields: anyway, opinions about what is required for merging differ maybe, and i'm conservative i guess
628 2013-09-23 19:52:56 <sipa> cfields: but getting a decent build system is welcome nonetheless :)
629 2013-09-23 19:53:07 <cfields> sipa: oh, i can't speak for the implementation in the slightest. i only meant from builder's perspective
630 2013-09-23 19:53:29 <sipa> it's just -DUSE_SECP256K1
631 2013-09-23 19:53:59 <sipa> the key.cpp implementation should probably just be split in two files, rather than something riddled with #ifdef's
632 2013-09-23 19:54:24 <cfields> sipa: i can autotools'ify it now if you'd like, looks like it shouldn't take too long.
633 2013-09-23 19:54:47 <sipa> cfields: that would be nice :)
634 2013-09-23 19:54:55 <cfields> ok, on it
635 2013-09-23 19:55:09 <sipa> i guess the current configure script pretty much follows the logic already
636 2013-09-23 19:55:19 <sipa> but you'd do it with macro's instead of hardcoded tests
637 2013-09-23 19:55:30 <gmaxwell> Unfortunately libsecp256k1 has had fairly little review. It's also a lot of code, with multiple parallel implementations. There are relatively few people who are even qualified to review it. :(
638 2013-09-23 19:56:16 <sipa> some implementations can probably be thrown away
639 2013-09-23 19:56:17 <michagogo> Hmm... where does gitian-builder/bin/make-base-vm get the OS from?
640 2013-09-23 19:57:02 <sipa> cfields: the libsecp256k1 repo itself (rather than the bitcoin integration) is in sipa/secp256k1; so if you'd change the build system, send pullreqs there :)
641 2013-09-23 19:57:55 <sipa> gmaxwell: yeah, i should do something about that, and talk to people
642 2013-09-23 19:58:05 <sipa> but i haven't had the time to work on it myself either
643 2013-09-23 20:00:52 <sipa> gmaxwell, cfields: perhaps it makes sense to only consider a subset of the number/field implementations "stable", and require a --with-experimental-code to enable those
644 2013-09-23 20:01:18 <sipa> and prevent passing that flag when building bitcoin
645 2013-09-23 20:01:36 <sipa> then again... right now they're really all experimental
646 2013-09-23 20:01:40 <michagogo> Does anyone know where the OS comes from when using gitian-builder/bin/make-base-vm?
647 2013-09-23 20:01:57 <sipa> michagogo: ubuntu, i guess
648 2013-09-23 20:02:08 <sipa> we should know that, actually
649 2013-09-23 20:02:09 <michagogo> I mean, where the source is defined
650 2013-09-23 20:02:19 <sipa> ?
651 2013-09-23 20:02:29 <sipa> i think it uses vmbuilder
652 2013-09-23 20:05:12 <michagogo> Also, something I noticed
653 2013-09-23 20:05:36 <michagogo> release-process.md says "from the directory containing bitcoin source, gitian.sigs and gitian-builder" or something to that effect
654 2013-09-23 20:06:00 <michagogo> But unless I misunderstand, the bitcoin source isn't needed at all, because gitian fetches it itself
655 2013-09-23 20:06:07 <michagogo> You only need the 2 descriptor files.
656 2013-09-23 20:06:26 <sipa> that's correct i think
657 2013-09-23 20:06:41 <sipa> though i use a wrapper script around gitian that gets the source from a local directory
658 2013-09-23 20:06:55 <michagogo> sipa: Hmm?
659 2013-09-23 20:07:15 <sipa> i often want to build from a local modified repository
660 2013-09-23 20:07:35 <sipa> and modifying the descriptor files to pull stuff from another repo is a pain
661 2013-09-23 20:07:48 <sipa> i just want to say "use that git commit, from that directory" when building
662 2013-09-23 20:08:00 <michagogo> Ah
663 2013-09-23 20:08:09 <sipa> hardcoding the repository in the descriptor files seems weird to me
664 2013-09-23 20:08:12 <michagogo> So does the script modify the descriptor file for you?
665 2013-09-23 20:08:25 <sipa> no, i use an undocumented trick in gitian
666 2013-09-23 20:08:37 <sipa> namely creating the directory it fetches things into myself before calling it
667 2013-09-23 20:09:28 <michagogo> Interesting.
668 2013-09-23 20:09:38 <michagogo> BTW, how do you ask Ubuntu if it's 32 or 64 bit?
669 2013-09-23 20:11:00 <sipa> uname -m
670 2013-09-23 20:12:01 <michagogo> i686?
671 2013-09-23 20:12:04 <michagogo> Is that 32-bit?
672 2013-09-23 20:12:09 <sipa> yes
673 2013-09-23 20:12:11 <michagogo> And: would that be the cause for http://paste.ubuntu.com/6147155/ ?
674 2013-09-23 20:12:48 <michagogo> If so: damn, looks like I do need to install a new VM after all
675 2013-09-23 20:13:03 <sipa> is your host system 32-bit?
676 2013-09-23 20:13:39 <michagogo> I'm running Windows 7 64-bit
677 2013-09-23 20:13:52 <sipa> and inside of that
678 2013-09-23 20:13:53 <sipa> ?
679 2013-09-23 20:14:11 <michagogo> Running Ubuntu in virtualbox, and that's what that paste is from
680 2013-09-23 20:14:17 <michagogo> Ubuntu raring, i686
681 2013-09-23 20:14:25 <sipa> ok, so your gitian host is 32-bit
682 2013-09-23 20:14:28 <michagogo> right
683 2013-09-23 20:14:37 <sipa> you can use lxc to go from 32-bit host to 64-bit guest
684 2013-09-23 20:14:40 <michagogo> Does it need to be 64, or was that error caused by something else?
685 2013-09-23 20:14:44 <sipa> as it uses the same kernel
686 2013-09-23 20:14:51 <michagogo> Okay...
687 2013-09-23 20:14:56 <sipa> *can't
688 2013-09-23 20:14:57 <michagogo> ACTION wonders what the problem is, then
689 2013-09-23 20:15:00 <michagogo> Ah
690 2013-09-23 20:15:05 <michagogo> That'd do it :-P
691 2013-09-23 20:15:19 <michagogo> ACTION checks if he has the raring amd64 iso
692 2013-09-23 20:15:26 <sipa> yeah, you need to run a 64-bit ubuntu in the virtualbox
693 2013-09-23 20:15:33 <michagogo> Damn.
694 2013-09-23 20:15:35 <sipa> and then lxc inside that shouldn't be a problem
695 2013-09-23 20:15:44 <michagogo> (I'm assuming there's no way to upgrade from 32 to 64, right?)
696 2013-09-23 20:15:55 <sipa> unsure
697 2013-09-23 20:15:59 <sipa> maybe there is
698 2013-09-23 20:17:59 <cfields> sipa: sorry, phone
699 2013-09-23 20:18:28 <michagogo> Looks like it's ~possible, but not easy or supported
700 2013-09-23 20:20:45 <cfields> sipa: mind quickly going over what options should be available? maybe quick PM discussion?
701 2013-09-23 20:22:34 <michagogo> At least I already have the ISO -- and it'll be worth it to be able to gbuild without having to get my external HD and reboot into Ubuntu