1 2013-09-26 01:33:55 <HaltingState> has anyone forked ripple yet?
  2 2013-09-26 01:34:08 <HaltingState> maybe wrong channel to ask :)
  3 2013-09-26 01:42:33 <gmaxwell> [OT] This is enjoyable enough to justify enduring the horiffic typesetting: https://www.usenix.org/system/files/1309_14-17_mickens.pdf (it's like Hunter S. Thompson writes about microprocessor design)
  4 2013-09-26 04:17:28 <warren> anyone know where is a list of variables available during gitian?
  5 2013-09-26 04:17:33 <warren> when it runs the script: |
  6 2013-09-26 04:17:40 <warren> devrandom: ?
  7 2013-09-26 05:10:47 <gmaxwell> :-/ why are there people who made forum accounts in 2011 responding like this to someone confused by change: https://bitcointalk.org/index.php?topic=301677.msg3236870#msg3236870 ?
  8 2013-09-26 05:12:08 <Neozonz> "Sended"
  9 2013-09-26 05:12:11 <Neozonz> 
ACTION chuckles

 10 2013-09-26 05:13:02 <gmaxwell> sended is a common misuse of english from people with .sv domain names, in my expirence.
 11 2013-09-26 05:14:44 <gangplank> you never had a friend who "got deaded" in a video game?
 12 2013-09-26 06:57:55 <warren> gmaxwell: Luke-Jr: regarding our discussion earlier today, if we built linux gitian binaries with glibc-2.12, that might mean dropping support for Ubuntu 10.04, is that too soon?
 13 2013-09-26 07:10:47 <xfers> you compromise your security when you click spamlinks with '? in it
 14 2013-09-26 07:12:08 <sipa> warren: ubuntu 10.04 desktop isn't supported anymore already
 15 2013-09-26 07:13:39 <xfers> and you invoke the all seeing eye echelon when you say n(S)a
 16 2013-09-26 07:13:56 <sipa> xfers: not here
 17 2013-09-26 07:16:01 <xfers> i see it done all the time so this is exactly where
 18 2013-09-26 07:20:59 <sipa> xfers: take it elsewhere
 19 2013-09-26 07:21:55 <warren> sipa: server is though
 20 2013-09-26 07:22:07 <warren> sipa: (whatever quality of their "support" is...)
 21 2013-09-26 07:22:39 <sipa> yeah
 22 2013-09-26 07:22:58 <warren> it's possible it doens't use any new symbols and 2.11 would work
 23 2013-09-26 07:23:04 <xfers> •sipa• want an ignore?
 24 2013-09-26 07:24:05 <sipa> xfers: take it elsewhere
 25 2013-09-26 07:25:43 <warren> ubuntu@ubuntu:~$ i686-w64-mingw32-g++ -E -dM $(mktemp --suffix=.h) |grep __VERSION__ |sed 's^\"\(.*\)*\"/^&^'
 26 2013-09-26 07:25:44 <warren> #define __VERSION__ "4.6.3"
 27 2013-09-26 07:26:00 <warren> that looks simple, but that string can be free form, whatever the toolchain packager wants to write in there
 28 2013-09-26 07:26:35 <warren> Diapolo wants me to not hardcode a cosmetic, meaningless number in boost-win32.yml.  I'm giving up.
 29 2013-09-26 07:26:45 <sipa> can't you just use g++ --version?
 30 2013-09-26 07:26:53 <warren> sipa: that's free-form too
 31 2013-09-26 07:27:11 <sipa> how so?
 32 2013-09-26 07:27:17 <warren> sipa: AFAICT there is no way to ask for just the x.y.z version
 33 2013-09-26 07:27:46 <warren> (oops, the sed above is meaningless, failed attempt to isolate the number from the quotes)
 34 2013-09-26 07:28:47 <warren> #define __VERSION__ "4.8.1 20130603 (Red Hat 4.8.1-1)"
 35 2013-09-26 07:28:47 <warren> [warren@localhost ~]$ g++ -E -dM $(mktemp --suffix=.h) |grep __VERSION__
 36 2013-09-26 07:28:50 <warren> sipa: more free form
 37 2013-09-26 07:29:07 <warren> sipa: and that BSD guy yesterday had an entirely different example
 38 2013-09-26 07:29:22 <sipa> g++ --version | head -n1 | sed -e 's/(.*)//g' -e 's/\s\+/ /g' | cut -d ' ' -f 2
 39 2013-09-26 07:29:34 <sipa> gitian is not BSD
 40 2013-09-26 07:30:31 <warren> [warren@localhost ~]$ g++ --version | head -n1 | sed -e 's/(.*)//g' -e 's/\s\+/ /g' | cut -d ' ' -f 2
 41 2013-09-26 07:30:36 <warren> blank output on Fedora
 42 2013-09-26 07:31:04 <sipa> ok, what does the output look like?
 43 2013-09-26 07:31:11 <sipa> of g++ --version
 44 2013-09-26 07:31:21 <warren> g++ (GCC) 4.8.1 20130603 (Red Hat 4.8.1-1)
 45 2013-09-26 07:31:21 <warren> [warren@localhost ~]$ g++ --version
 46 2013-09-26 07:31:52 <warren> g++ -E -dM $(mktemp --suffix=.h) |grep __VERSION__
 47 2013-09-26 07:31:55 <warren> that might be cleaner to parse
 48 2013-09-26 07:32:03 <warren> the first word is probably the x.y.z
 49 2013-09-26 07:32:59 <sipa> $ g++ -E -dM $(mktemp --suffix=.h) | grep __VERSION__ | cut -d ' ' -f 3 | cut -d '"' -f 2
 50 2013-09-26 07:33:02 <sipa> 4.7.3
 51 2013-09-26 07:33:55 <warren> our sample size of four finds the first word is x.y.z, so let's just assume this is safe
 52 2013-09-26 07:36:45 <warren> sipa: thanks, all these years and I've never looked at the cut manpage before.
 53 2013-09-26 07:44:15 <warren> https://github.com/wtogami/bitcoin/commits/win32-oldboost   <--- intermediate step, upgrading only to precise 12.04 without any dep upgrades.
 54 2013-09-26 08:29:21 <warren> michagogo|cloud: ping
 55 2013-09-26 08:30:06 <warren> michagogo|cloud: I'm going to upgrade ONLY boost for win32.  I need to work on more important things elsewhere.  Do you want to test the stability of the other library upgrades and upgrade the others yourself after my commit is accepted?
 56 2013-09-26 08:30:39 <warren> michagogo|cloud: I ask because you seem to be very interested in gitian, and you appear to want to learn.
 57 2013-09-26 09:41:21 <dizko> im seeing something about hub node patches?
 58 2013-09-26 09:41:54 <sipa> ?
 59 2013-09-26 09:42:31 <dizko> if i want to have several geographically separate bitcoind servers and basically addnode each other
 60 2013-09-26 09:42:39 <dizko> but that takes up all my 8 outbound connections
 61 2013-09-26 09:44:15 <warren> Anyone running win32 bitcoin and can help test experimental builds?
 62 2013-09-26 09:44:33 <dizko> i dont run it but i do run windows on my desk here at home
 63 2013-09-26 09:44:35 <sipa> dizko: just a few -addnode's will do fine
 64 2013-09-26 09:44:43 <sipa> no need to addnode all of them
 65 2013-09-26 09:45:02 <dizko> the rpc connections suck and i get all this iowait, something isnt sending a fin
 66 2013-09-26 09:45:17 <dizko> so i want to be able to hit all of the servers and count on that they've all seen the same transaction
 67 2013-09-26 09:45:43 <dizko> s/iowait/TIME_WAIT/
 68 2013-09-26 09:47:22 <dizko> it very well may be the python lib that's at fault
 69 2013-09-26 09:47:33 <dizko> (suspect so anyway)
 70 2013-09-26 09:48:00 <sipa> there are some known problems with RPC connections timing out
 71 2013-09-26 09:48:35 <dizko> i admittedly had some stupid code (someone else wrote!) that was calling the daemon excessively
 72 2013-09-26 09:48:56 <dizko> i fixed it mostly though sometimes it crashes because not being able to get a socket
 73 2013-09-26 09:49:29 <dizko> tuned tcp_fin_timeout =)_
 74 2013-09-26 11:58:30 <Luke-Jr> warren: Ubuntu has already dropped support for 10.04
 75 2013-09-26 11:58:52 <Luke-Jr> warren: and Ubuntu is supported by the PPA anyway
 76 2013-09-26 12:01:11 <sipa> Luke-Jr: not for servers
 77 2013-09-26 12:01:49 <Luke-Jr> sipa: still have PPA and source.
 78 2013-09-26 12:01:53 <sipa> right
 79 2013-09-26 12:02:19 <sipa> Luke-Jr, warren: ironically, i don't think that that many people run our binaries on ubuntu
 80 2013-09-26 12:02:51 <sipa> but on RHEL/CentOS/Fedora, where building locally is significantly harder, perhaps they are
 81 2013-09-26 12:03:19 <Luke-Jr> sounds more and more like we should be building Linux binaries on RHEL 6
 82 2013-09-26 12:03:28 <dizko> is ubuntu the preferred build platform?
 83 2013-09-26 12:03:49 <warren> If you REALLY want that, I can make a CentOS6 VM installer.
 84 2013-09-26 12:03:50 <sipa> Luke-Jr: RHEL6 has an even older GCC than ubuntu 10.04...
 85 2013-09-26 12:03:57 <sipa> (iirc)
 86 2013-09-26 12:04:01 <Luke-Jr> sipa: nope
 87 2013-09-26 12:04:02 <warren> sipa: far better maintained though
 88 2013-09-26 12:04:13 <Luke-Jr> sipa: wasn't that your comment?
 89 2013-09-26 12:04:50 <dizko> building anything that uses boost is always a pita on other platforms
 90 2013-09-26 12:04:55 <Luke-Jr> sipa: Ubuntu 10.04 was glibc 2.11; RHEL 6 is 2.12
 91 2013-09-26 12:05:15 <dizko> working on getting it compiled on illumos....uhg
 92 2013-09-26 12:05:20 <warren> what version of gcc is in 10.04?
 93 2013-09-26 12:06:54 <Luke-Jr> Squeeze is still maintained (for an unknown duration) and uses 2.11-ish
 94 2013-09-26 12:10:27 <kinlo> debian is usually maintained until releasedate(next)+1y
 95 2013-09-26 12:10:34 <kinlo> so 2014-05 for squeeze
 96 2013-09-26 12:11:09 <warren> hmm... I can write something that works like gitian very quickly, but actually porting gitian to manage rpm/yum VM's I don't have time.
 97 2013-09-26 12:11:20 <Luke-Jr> kinlo: I thought it was just killed when a new release comes out (after the current version)
 98 2013-09-26 12:11:38 <Luke-Jr> warren: getting rid of the Ruby deps would be nice imo :p
 99 2013-09-26 12:11:44 <kinlo> Luke-Jr: no, that would give you zero time to plan/implement your upgrade :)
100 2013-09-26 12:11:47 <warren> Luke-Jr: I agree actually
101 2013-09-26 12:12:00 <warren> Luke-Jr: I would do it in python and shell
102 2013-09-26 12:12:10 <Luke-Jr> kinlo: no, you'd have the whole time-until-next-release
103 2013-09-26 12:12:19 <Luke-Jr> A, B, C <-- C's release retires A
104 2013-09-26 12:12:20 <kinlo> ah
105 2013-09-26 12:12:21 <kinlo> no
106 2013-09-26 12:12:29 <kinlo> well, that's not the case
107 2013-09-26 12:12:33 <Luke-Jr> oh well
108 2013-09-26 12:12:44 <kinlo> given their release schedule of one release per 2-3 years
109 2013-09-26 12:13:00 <kinlo> that would force them to maintain such old distro's where nobody wants to use them anymore :)
110 2013-09-26 12:13:23 <warren> Luke-Jr: sipa: I would seriously ask the community if they expect the official binaries to work on Ubuntu 10.04
111 2013-09-26 12:14:11 <Luke-Jr> warren: "ask the community" isn't simple
112 2013-09-26 12:14:48 <Luke-Jr> might be easier to grab webserver logs to see how many Ubuntu 10.04 users hit the site
113 2013-09-26 12:15:15 <warren> 10.04 won't be used by desktops, only servers
114 2013-09-26 12:15:17 <warren> at this point
115 2013-09-26 12:16:21 <warren> Luke-Jr: and if folks want a single VM to build 32bit and 64bit binaries, it's quite easy on fedora or EL
116 2013-09-26 12:47:26 <runeks> I think there is some database incompatibility between the bitcoind version in the stable Ubuntu PPA and git master. I get ": Corrupted block database detected." running git master.
117 2013-09-26 12:49:01 <runeks> I was using the version from the PPA first, and then built master and ran that. After doing this and closing this version, running the bitcoind version from the Ubuntu PPA again resulted in a "database corrupted" message. Then I built sipa's branch and it worked fine. But now, when running either sipa's branch or master, I get "corrupted block database detected".
118 2013-09-26 12:49:12 <runeks> 2013-09-26 12:44:17 Verifying last 288 blocks at level 3
119 2013-09-26 12:49:12 <runeks> 2013-09-26 12:44:18 ERROR: DisconnectBlock() : outputs still spent? database corrupted
120 2013-09-26 12:49:12 <runeks> 2013-09-26 12:44:26 ERROR: VerifyDB() : *** coin database inconsistencies found (last 29 blocks, 70483 good transactions before that)
121 2013-09-26 12:49:42 <kinlo> this has passed in this channel before
122 2013-09-26 12:50:03 <kinlo> I think it's a known bug that git trunk corrupts it's database somehow
123 2013-09-26 12:50:08 <kinlo> dunno the details
124 2013-09-26 12:50:32 <runeks> Oh. I didn't know that. I've used git master before without problems.
125 2013-09-26 12:50:54 <pankkake> isn't it the bug that was fixed in 0.8.5?
126 2013-09-26 12:50:58 <kinlo> if you run git master you must anticipate these kind of problems
127 2013-09-26 12:51:10 <kinlo> pankkake: no, it has been introduced after 0.8.5
128 2013-09-26 12:51:27 <kinlo> 0.8.5 fixes negative transaction versions
129 2013-09-26 12:51:31 <kinlo> unrelated to this
130 2013-09-26 12:52:07 <runeks> kinlo: I guess you're right. I only used git master because I wanted the "getblock" hex output function. I didn't get included in 0.8.5 as far as I can see.
131 2013-09-26 12:52:28 <runeks> s/I didn't/It didn't
132 2013-09-26 12:52:41 <kinlo> runeks: you can always backport specific pieces of code, I'd recommend doing that instead if you're gonna run in production
133 2013-09-26 12:52:51 <kinlo> I do that for my wallets anyway
134 2013-09-26 12:53:12 <runeks> kinlo: It's not production. Just personal use. Wanted to create a bootstrap.dat using linearize.py so I could seed it.
135 2013-09-26 12:53:37 <kinlo> :)
136 2013-09-26 12:55:59 <warren> Luke-Jr: I might propose a radically different approach to this.  1) Pick a super long term distro that is well maintained (RHEL6 or RHEL7). 2) Make deterministic builds of entire stacks including target glibc (for Linux builds), the best mingw toolchain we can find, and cfields' mac cross compile toolchain.  3) For any of those targets, build the deps ourselves using identical library versions for all three targets.
137 2013-09-26 12:59:26 <warren> If we wait for RHEL7, its native gcc and mingw will be EXCELLENT.  mingw even provides static builds nearly all libraries we use, although we can just build our own like we currently do if we want. Then the only things we need to maintain ourselves as deterministic toolchains is the Linux target glibc and the mac cross-compile toolchain.
138 2013-09-26 13:02:16 <warren> apparently RHEL7 is in the "second half of 2013" and is based on fedora 19.
139 2013-09-26 13:03:34 <warren> So we can prototype this future solution on fedora 19 now, and use all of that code in a RHEL7-based deterministic environment
140 2013-09-26 13:13:47 <Luke-Jr> warren: static = bad
141 2013-09-26 13:14:11 <warren> Luke-Jr: static is only for mingw
142 2013-09-26 13:14:21 <warren> oh hm
143 2013-09-26 13:14:48 <warren> Luke-Jr: don't we currently make many parts of bitcoin static for linux?
144 2013-09-26 13:14:58 <Luke-Jr> warren: unfortunately
145 2013-09-26 13:15:14 <Luke-Jr> warren: and static = bad in general, especially on Windows where there's no excuse for it :P
146 2013-09-26 13:15:32 <Luke-Jr> Linux binaries have the excuse of better compatibility at least
147 2013-09-26 13:15:41 <Luke-Jr> (although dynmaically linking glibc would seem to negate that)
148 2013-09-26 13:15:53 <wumpus> so what would you propose for windows? install a slew of dlls?
149 2013-09-26 13:16:04 <Luke-Jr> wumpus: yep, in the application directory
150 2013-09-26 13:16:46 <wumpus> there's quite a few games for linux that do the same btw, just package .so's in the application directory (and a script to set LD_LIBRARY_PATH)  instead of static linking
151 2013-09-26 13:16:50 <warren> I'm suggesting we use the newest long term support distro to build everything need.  Everything will be a cross compile to an extent.
152 2013-09-26 13:17:09 <wumpus> then again, that's completely orthogonal to what distribution is used for building
153 2013-09-26 13:17:59 <sipa> if you're installing .dll's in the application directory anyway, what's the point of it?
154 2013-09-26 13:18:10 <wumpus> sharing between executables
155 2013-09-26 13:18:13 <sipa> oh
156 2013-09-26 13:18:18 <wumpus> ie, if you have bitcoind and bitcoin-qt
157 2013-09-26 13:18:19 <sipa> yeah, that makes sense
158 2013-09-26 13:19:49 <warren> OTOH, why again are we upgrading from 10.04 for linux?
159 2013-09-26 13:20:01 <sipa> newer gcc?
160 2013-09-26 13:20:18 <warren> all the problems i experienced where with mingw on 10.04.  gcc on 10.04 for linux builds were fine.
161 2013-09-26 13:20:25 <Luke-Jr> wumpus: on Windows, you don't need to do anything fancy for it :p
162 2013-09-26 13:20:29 <sipa> or because we don't want 2-3-4 images...
163 2013-09-26 13:20:42 <wumpus> also if you have any kind of plugin system that loads dynamic libraries, you'll have a hard time with statically linked everything
164 2013-09-26 13:20:44 <warren> 2-3-4 images is the least of our problems
165 2013-09-26 13:20:59 <Luke-Jr> sipa: also, if your system has other applications using the same DLLs, you could delete the ones we install to use the shared ones
166 2013-09-26 13:21:07 <Luke-Jr> (for power users)
167 2013-09-26 13:21:12 <wumpus> we'd need a 10.04 and a 12.04 image, not 3 or 4 right/
168 2013-09-26 13:21:32 <warren> two 10.04's and 12.04 currently
169 2013-09-26 13:21:43 <sipa> wumpus: currently, with warren's pullreq, 12.04 for windows, and a 32bit and a 64bit for linux
170 2013-09-26 13:22:04 <wumpus> why two 10.04? it's very much possible to build 32 and 64 bit linux from the same image right?
171 2013-09-26 13:22:12 <sipa> yes
172 2013-09-26 13:22:16 <sipa> but we currently don't :)
173 2013-09-26 13:22:16 <warren> I'm totally serious about the 1VM solution, cross compile everything.
174 2013-09-26 13:22:16 <wumpus> Luke-Jr: please don't recommend that to anyone
175 2013-09-26 13:22:46 <Luke-Jr> wumpus: if it isn't obvious, they're probably  not power user enough to do it safely ;p
176 2013-09-26 13:22:51 <sipa> warren: one 64-bit 12.04 right now ought to be enough for everyone
177 2013-09-26 13:23:03 <wumpus> Luke-Jr: imagine all the pains of bdb or leveldb interface is slightly shifted
178 2013-09-26 13:23:16 <sipa> except for dropping RHEL6 and Ubuntu Lucid support
179 2013-09-26 13:23:56 <sipa> i don't care that much about dropping lucid
180 2013-09-26 13:24:09 <Luke-Jr> sipa: and Debian
181 2013-09-26 13:24:09 <sipa> and i'm not familiar enough with the RH-based world to judge the rest
182 2013-09-26 13:24:10 <wumpus> me neither, but RHEL6 may be a bigger issue
183 2013-09-26 13:24:26 <Luke-Jr> sipa: Ubuntu 12.04 drops support for everything except Ubuntu and Gentoo
184 2013-09-26 13:25:13 <sipa> yeah :(
185 2013-09-26 13:26:19 <warren> RHEL6 support on everything is through 2020
186 2013-09-26 13:26:22 <Luke-Jr> (and Gentoo users aren't going to be using it in any case)
187 2013-09-26 13:26:25 <warren> RHEL7 through 2023
188 2013-09-26 13:27:12 <wumpus> why not just build a newer mingw-64 for ubuntu 10.04?
189 2013-09-26 13:27:41 <wumpus> that'd solve the windows issue too
190 2013-09-26 13:27:55 <wumpus> maybe it's not possible due to some other incompatible library, but heh...
191 2013-09-26 13:28:06 <sipa> wumpus: that still leaves us on an ancient gcc for linux builds
192 2013-09-26 13:28:18 <sipa> which means no C++11, no LTO, ...
193 2013-09-26 13:28:23 <Luke-Jr> wumpus: Ubuntu 10.04 is unsupportedish
194 2013-09-26 13:28:42 <wumpus> but is it using a newer gcc that drops support for older linux distrubitions? or could we use a new gcc with older glibc
195 2013-09-26 13:28:51 <warren> RHEL7 is supported until 2023,ships with awesome mingw and native gcc compiler, and there's workarounds for the glibc issue.
196 2013-09-26 13:28:54 <wumpus> what is the part that breaks compatibility?
197 2013-09-26 13:29:03 <warren> mac deterministic toolchain will be the same problem on any distro
198 2013-09-26 13:29:06 <Luke-Jr> wumpus: any part we dynamic link
199 2013-09-26 13:29:08 <sipa> wumpus: glibc is what breaks compatibility, afaik
200 2013-09-26 13:29:18 <sipa> as we statically link libgcc, afaik
201 2013-09-26 13:29:27 <warren> so picking a distro that takes care of the hardest parts for us in the long-term is likely a good idea
202 2013-09-26 13:29:28 <wumpus> ok, so only glibc
203 2013-09-26 13:29:38 <sipa> so we need old libc + new gcc :)
204 2013-09-26 13:29:53 <Luke-Jr> can we live with 10.04 until RHEL 7 is released?
205 2013-09-26 13:30:01 <wumpus> yes, we need to fi the glibc version, but keep up with gcc upgrades somehow
206 2013-09-26 13:30:04 <sipa> why would we switch to RHEL?
207 2013-09-26 13:30:13 <wumpus> I wonder how other linux binary projects handle this
208 2013-09-26 13:30:18 <sipa> or does it have an old libc?
209 2013-09-26 13:30:19 <warren> Luke-Jr: yes, although we can begin dev on Fedora 19 which is very similar to RHEL7
210 2013-09-26 13:30:28 <sipa> wumpus: i expect them not to deal with it at all
211 2013-09-26 13:30:37 <sipa> wumpus: just have binaries for each platform
212 2013-09-26 13:30:41 <Luke-Jr> warren: wait, why are we assuming RHEL 7 will have an old libc?
213 2013-09-26 13:30:48 <wumpus> would it be possible to build a old-glibc toolchain on ubuntu 12.04? like a cross compiler to old-libc?
214 2013-09-26 13:30:53 <Luke-Jr> sipa: RHEL 6 has the oldest libc of all the mainstream distros
215 2013-09-26 13:31:31 <warren> Luke-Jr: not assuming, it wlil have a new glibc, we will need to provide our own glibc (as yet another deterministic dep we build ourself)
216 2013-09-26 13:31:48 <Luke-Jr> meh, RHEL 6 seems ideal then
217 2013-09-26 13:32:00 <sipa> but RHEL6 also has an ancient gcc, no?
218 2013-09-26 13:32:04 <sipa> http://www.trevorpounds.com/blog/?p=103
219 2013-09-26 13:32:08 <warren> Luke-Jr: RHEL7 has the awesome native mingw and gcc
220 2013-09-26 13:32:13 <wumpus> so in that case at least we only have to build an old libc, not gcc and binutils and the whole shebang
221 2013-09-26 13:32:15 <Luke-Jr> warren: good for windows
222 2013-09-26 13:33:11 <wumpus> though I suppose gcc versions have a minimum compatible libc version
223 2013-09-26 13:33:15 <warren> we may not have to build our own glibc for that, just copy one from an earlier distro
224 2013-09-26 13:33:37 <wumpus> but it may be a while until we run into that...
225 2013-09-26 13:34:43 <warren> sipa: Luke-Jr: for 0.9 release 10.04 + 12.04 win32 is adequate.
226 2013-09-26 13:35:11 <wumpus> agreed, and easy to do
227 2013-09-26 13:35:19 <sipa> agree for me as well
228 2013-09-26 13:35:34 <sipa> though gavin didn't seem very keen on needing 3 VMs
229 2013-09-26 13:35:37 <Luke-Jr> ^
230 2013-09-26 13:35:42 <sipa> i don't think 2 or 3 matters that much
231 2013-09-26 13:35:48 <warren> irrelevant
232 2013-09-26 13:35:51 <wumpus> it's only temporary
233 2013-09-26 13:36:01 <Luke-Jr> not for me :P
234 2013-09-26 13:36:05 <Luke-Jr> but I don't care that much
235 2013-09-26 13:36:06 <warren> mind you, the RHEL7 VM will be larger
236 2013-09-26 13:36:14 <Luke-Jr> warren: why? :/
237 2013-09-26 13:36:30 <sipa> warren: is it possible to build with old glibc on RHEL7?
238 2013-09-26 13:36:32 <warren> Luke-Jr: you want one VM to build 32bit and 64bit?
239 2013-09-26 13:36:35 <Luke-Jr> no reason a minimal install shouldn't be like 100 MB :/
240 2013-09-26 13:36:38 <wumpus> I don't care either, what's the disadvantage of another VM? just more disk usage?
241 2013-09-26 13:36:39 <warren> sipa: yes
242 2013-09-26 13:36:42 <wumpus> meh
243 2013-09-26 13:36:52 <sipa> wumpus: i think that's it... plus the time to create it
244 2013-09-26 13:36:57 <warren> meh
245 2013-09-26 13:37:22 <warren> wumpus: review of my PR please?  I addressed everything so far.
246 2013-09-26 13:37:28 <wumpus> creating it is a one-time process
247 2013-09-26 13:37:42 <sipa> warren: but the same can be done on any ubuntu, i suppose?
248 2013-09-26 13:38:59 <wumpus> warren: I'll take a look
249 2013-09-26 13:39:49 <warren> wumpus: I stopped short of upgrading all win32 deps because lesser skilled devs in training can do that and test it.
250 2013-09-26 13:41:32 <wumpus> warren: the boost patch, is it very large? if not, could we just include it instead of making people download another dependency?
251 2013-09-26 13:41:56 <warren> wumpus: very large
252 2013-09-26 13:42:22 <wumpus> argh, maybe that's why upstream refuses it too
253 2013-09-26 13:42:29 <warren> wumpus: no
254 2013-09-26 13:42:43 <warren> wumpus: upstream refuses it because the windows dev is an ass
255 2013-09-26 13:43:16 <wumpus> okay
256 2013-09-26 13:43:35 <warren> distros are shipping it
257 2013-09-26 13:46:55 <warren> sipa: better question is which old glibc we want to target
258 2013-09-26 13:47:02 <warren> sipa: and that target can change
259 2013-09-26 13:47:29 <warren> sipa: this will also require autotools hacks that I don't know how to do.
260 2013-09-26 13:49:57 <wumpus> warren: please update the release-process.md to download the patch, too
261 2013-09-26 13:50:35 <wumpus> apart from that changes look ok
262 2013-09-26 13:51:50 <helo> is make supposed to be trying to create /src?
263 2013-09-26 13:53:11 <warren> wumpus: oops ok
264 2013-09-26 13:53:56 <warren> sipa: same can be done from ubuntu, but might as well pick a distro that is supported the longest.
265 2013-09-26 13:54:32 <wumpus> most of the devs have experience with ubuntu though, don't know about RHEL
266 2013-09-26 13:54:55 <warren> gitian is already a black box.  you hit "GO" and it spits out binaries.
267 2013-09-26 13:55:20 <wumpus> that's true to a certain extent, but we shouldn't make it even harder to support our own stuff
268 2013-09-26 13:55:52 <warren> wumpus: the parts of gitian that matter have almost nothing todo with ubntu
269 2013-09-26 13:56:16 <wumpus> it's not like using a different linux distribution is rocket science, but ie the names of dependency packages are all different for RHEL
270 2013-09-26 13:56:58 <warren> wumpus: with a single VM approach + target alt glibc + mac cross compiler, the external tool that launches it copies in all inputs, and we can have the same inputs used by all builds.  can't beat that for consensus safety.
271 2013-09-26 13:57:30 <warren> wumpus: do we want to use the distro packages at all though?
272 2013-09-26 13:57:36 <wumpus> but that'd be just as possible with ubuntu; I'm not convinced of switching to another distro, but if other devs agree it's fine with me...
273 2013-09-26 13:58:21 <wumpus> warren: yes, you don't want to build the whole thing from scratch do you?
274 2013-09-26 13:58:38 <warren> wumpus: we already do for win32
275 2013-09-26 13:58:41 <wumpus> like LFS/Gentoo instead of RHEL
276 2013-09-26 13:59:02 <wumpus> oh you mean just the libraries
277 2013-09-26 13:59:32 <wumpus> still, starting from libc/libgcc that can be a pretty big compile
278 2013-09-26 14:00:00 <warren> leading candidate for the next linux builder was RHEL6 because it is maintained until year 2020, but I suggest it isn't worth it over 10.04, nearly the same compiler and still broken mingw
279 2013-09-26 14:00:49 <wumpus> but why? if we switch to 12.04 LTS that's also supported for a long time, and if it's not supported anymore it's time to switch to the new LTS
280 2013-09-26 14:01:14 <warren> wumpus: 12.04 built linux binaries can't run on RHEL6
281 2013-09-26 14:01:19 <KillYourTV> as an outsider: If you don't want to use the distro packages I don't see why the distro switch would help anything. If you're using your own source tarballs for the libraries, "supported the longest" doesn't really change very much, does it?
282 2013-09-26 14:01:35 <wumpus> it's not necessary to use a distribution that's maintained until the year 2525
283 2013-09-26 14:01:38 <wumpus> KillYourTV: exactly!
284 2013-09-26 14:02:37 <warren> wumpus: looking at the desires of "least amount of stuff to maintain" and "we want fewer VM's", RHEL7 has excellent toolchains and the least amount of extra crap to maintain
285 2013-09-26 14:03:34 <sipa> if things continue the way they're going, i'm inclined to use gentoo/lfs as a host :D
286 2013-09-26 14:03:42 <wumpus> sipa: yep
287 2013-09-26 14:03:56 <sipa> and just build using the oldest libc possible, and the most recent (stable) gcc
288 2013-09-26 14:04:02 <sipa> and maybe update once a year
289 2013-09-26 14:06:26 <helo> why VM, and not just chroot?
290 2013-09-26 14:06:43 <KillYourTV> IMHO, as long as the host distro with the old-as-hell libc can still be installled, "it's fine". It's not like you're using $ancient_host_distro's $ancient_dependencies.
291 2013-09-26 14:07:08 <sipa> helo: we should try that, and see how deterministic it is
292 2013-09-26 14:07:23 <KillYourTV> and indeed, why not chroot or lxc with VM as a option.
293 2013-09-26 14:07:29 <warren> helo: there's security isolation reasons
294 2013-09-26 14:07:30 <sipa> lxc already works
295 2013-09-26 14:07:38 <warren> helo: gitian VM's aren't allowed network access
296 2013-09-26 14:08:10 <wumpus> helo: you shouldn't even need a chroot; a cross-toolchain doesn't have to be based in the root
297 2013-09-26 14:08:59 <helo> why shouldn't the VM be allowed network access?
298 2013-09-26 14:09:22 <helo> not that it needs it... but presumably the VM can be trusted
299 2013-09-26 14:09:39 <wumpus> as long as you build *everything* including your toolchain (ie, something like buildroot)
300 2013-09-26 14:09:48 <wumpus> helo: determinism
301 2013-09-26 14:09:57 <wumpus> networks are always non-deterministic
302 2013-09-26 14:10:04 <sipa> well, presumably the host doesn't access network anyway
303 2013-09-26 14:10:16 <sipa> but why rely on trusting that it doesn't, rather than making sure you don't need trust
304 2013-09-26 14:10:21 <sipa> trust is easy
305 2013-09-26 14:10:40 <wumpus> having all inputs ready on the file system is what you want
306 2013-09-26 14:10:50 <warren> wumpus: added the patch to release-process.md
307 2013-09-26 14:10:55 <wumpus> warren: cool
308 2013-09-26 14:11:45 <warren> I can very easily limit a RHEL-like VM to only yum access, like gitian limits to only apt
309 2013-09-26 14:12:13 <warren> a squid recipe can act as reverse proxy cache like apt-cacher-ng
310 2013-09-26 14:18:41 <warren> wumpus: anyhow, moving to a single VM to build everything probably isn't worthwhile until we have the mac crosscompile. cfields really deserves to be paid for that work.  I hope we can get the community to support this goal.
311 2013-09-26 14:20:23 <warren> sipa: hmm... "Modern g++, so we can start using for example C++11 features and -flto"
312 2013-09-26 14:20:32 <warren> sipa: will that require a new libstdc++ ABI?
313 2013-09-26 14:21:07 <sipa> warren: not familiar enough with that
314 2013-09-26 14:21:30 <warren> sipa: there's ways of building things that target old glibc without having old glibc, but I think people will hate the ugly code in bitcoin
315 2013-09-26 14:22:06 <warren> if the libstdc++ ABI needs to break, we're stuck on the single linux build thing
316 2013-09-26 14:22:29 <sipa> but again... i care much more about windows gitian builds than linux ones
317 2013-09-26 14:23:19 <warren> sleep
318 2013-09-26 15:39:07 <runeks> Anyone have the txid of that transaction that contains code for a javascript alert() in its output, which wasn't escaped by blockchain.info?
319 2013-09-26 15:45:07 <runeks> Cause it seems like blockchain.info fixed this issue, but failed to simultaneously add support for properly escaping block coinbases: http://www.reddit.com/r/Bitcoin/comments/1n57uj/im_attempting_to_reach_a_security_contact_at/ccfq8k5
320 2013-09-26 15:46:25 <Luke-Jr> runeks: blockchain.info is kinda off-topic here
321 2013-09-26 15:46:35 <runeks> Luke-Jr: Fair enough.
322 2013-09-26 15:46:58 <runeks> Luke-Jr: Is there any place more suited for this besides #bitcoin?'
323 2013-09-26 15:47:06 <runeks> Should we have #bitcoin-security?
324 2013-09-26 15:47:10 <Luke-Jr> there used to be a channel, but it apparently disappeared :/
325 2013-09-26 15:47:27 <Luke-Jr> security issues are usually discussed in private
326 2013-09-26 15:47:40 <Luke-Jr> I'd suggest emailing PiUK unless it's just educational
327 2013-09-26 15:47:44 <kinlo> also, this is a security issue for a specific cloud service
328 2013-09-26 15:48:00 <kinlo> so talk to piuk, he's the only one who can help
329 2013-09-26 15:48:35 <Luke-Jr> there are likely people reading logs of this channel just waiting to jump on anything exploitable
330 2013-09-26 15:49:01 <runeks> Blockchain.info is aware of the exploit.
331 2013-09-26 15:49:06 <Luke-Jr> k
332 2013-09-26 15:49:08 <runeks> And actually disclosed it themselves.
333 2013-09-26 15:49:15 <runeks> They don't consider it a problem.
334 2013-09-26 15:49:20 <runeks> But yeah, OT :)
335 2013-09-26 15:50:06 <gmaxwell> "and since since coinbase scripts are limited to 100 bytes the exploit would have to be less than 100 characters" ...
336 2013-09-26 15:50:31 <kinlo> gmaxwell: I think you can do a remote include of a file in 100 bytes :)
337 2013-09-26 15:50:33 <runeks> gmaxwell: <script src="http://t.co/short">
338 2013-09-26 15:50:45 <gmaxwell> Yes, thats what I was remarking.
339 2013-09-26 15:50:52 <runeks> gmaxwell: Oh, I see :)
340 2013-09-26 15:51:12 <gmaxwell> I considered doing that in my example.
341 2013-09-26 15:51:15 <kinlo> runeks: you will need a a document.write, but still, not 100 chars
342 2013-09-26 15:51:33 <Luke-Jr> should I have Eligius mine a block that sources an arbitrary script from our webserver? <.<
343 2013-09-26 15:51:35 <runeks> gmaxwell: Did you create the alert() example?
344 2013-09-26 15:51:40 <gmaxwell> Yes.
345 2013-09-26 15:51:48 <Luke-Jr> who was that "yes" to? :p
346 2013-09-26 15:51:49 <runeks> Luke-Jr: Yes! Do one with a scary javascript popup :)
347 2013-09-26 15:51:54 <gmaxwell> runeks
348 2013-09-26 15:52:00 <gmaxwell> I'd warned them about it previously.
349 2013-09-26 15:52:13 <Luke-Jr> runeks: otoh, it would make our webserver a useful target for crackers..
350 2013-09-26 15:52:19 <gmaxwell> I decided to not remote load a script just so I couldn't be accused of serving different ones to different people.
351 2013-09-26 15:52:40 <Luke-Jr> ^ that too
352 2013-09-26 15:52:44 <runeks> gmaxwell: Plus, the operators of the short-url service could change the content.
353 2013-09-26 15:53:09 <gmaxwell> They really need to move the mywallet domain to something that doesn't display random content from elsewhere...
354 2013-09-26 15:53:22 <runeks> True.
355 2013-09-26 15:53:32 <gmaxwell> runeks: .. uh you'd have to be mad to use a URL shortener for something like that. :P
356 2013-09-26 15:54:15 <runeks> Perhaps. 100 chars should be enough.
357 2013-09-26 15:54:16 <Luke-Jr> you could use an onion address.. and then realise nobody with tor support uses an online wallet
358 2013-09-26 15:54:18 <Luke-Jr> :P
359 2013-09-26 15:54:34 <runeks> Are subdomains included in the same-site origin policy?
360 2013-09-26 15:55:37 <runeks> I'll answer my own question: it's sufficient to put user content on a different subdomain.
361 2013-09-26 15:56:16 <gmaxwell> runeks: document.write('\x3Cscript type="text/javascript" src="/eligius.st/a">\x3C/script>');  is only 79 bytes.
362 2013-09-26 16:44:54 <michagogo> cloud|"<gmaxwell> Luke-Jr: I think what warren is pointing out is that gitian downloads stuff at runtime from untrusted/unsecured sources. So if someone compromises one of those you get a mystery binary, but it'll all match."
363 2013-09-26 16:45:31 <michagogo> cloud|It doesn't, unless you count the github repo. (Still scrolled up, will take a while to see responses)
364 2013-09-26 16:46:02 <gmaxwell> michagogo|cloud: IIRC the procedure has you apply updates before starting.
365 2013-09-26 16:59:53 <gmaxwell> runeks: http://www.reddit.com/r/Bitcoin/comments/1n57uj/im_attempting_to_reach_a_security_contact_at/ccfus83
366 2013-09-26 17:03:29 <runeks> gmaxwell: Wow. I think I'll stay on the Bitcoin wallet by Andreas Schildbach after this. BTW, what KDF does BC.i use, and what does Bitcoin Qt use?
367 2013-09-26 17:05:12 <runeks> I initially thought Javascript cryptography in the browser was brilliant, but after reading this I'm not so sure: http://www.matasano.com/articles/javascript-cryptography/
368 2013-09-26 17:05:21 <runeks> That just adds to the already existing issues of BC.i
369 2013-09-26 17:05:58 <tgs3> javascript usually has insecure implemntation, however that might change
370 2013-09-26 17:06:11 <tgs3> e.g. #mempo secure linux aims to fix that
371 2013-09-26 17:06:31 <helo> 
ACTION upvotes

372 2013-09-26 17:06:42 <gcX46> it still amazes me that people with significant amounts of Bitcoins would use a web wallet
373 2013-09-26 17:06:48 <gmaxwell> runeks: It "claims" to use PBKDF2 (I think with sha256), but ... it only applies 10 iterations and it's "salted" by just the hash of the passowrd or something like that. (so not salted at all).
374 2013-09-26 17:08:05 <gmaxwell> runeks: Bitcoin-qt uses a PBKDF2 like iteration which is part of openssl with SHA2-512 and as many iterations as the user can do in 100ms (subject to a minimum of 25,000) and stores a real random salt.
375 2013-09-26 17:09:05 <runeks> gmaxwell: Cool. Yeah salting with a hash of the password is pointless. Makes it seem like they don't understand the purpose of a salt in the first place.
376 2013-09-26 17:09:21 <Luke-Jr> 
ACTION wouldn't be surprised <.<

377 2013-09-26 17:09:23 <michagogo> cloud|<cfields> http://pastebin.com/raw.php?i=a89Hvm7Q <-- I didn't know that you can share git commits out of band like that... How do you export/import that? (Still scrolled up)
378 2013-09-26 17:09:36 <runeks> I think Armory uses scrypt, with a 250 ms target.
379 2013-09-26 17:09:45 <Luke-Jr> michagogo|cloud: git am
380 2013-09-26 17:09:59 <Luke-Jr> michagogo|cloud: but it isn't as good as pull/push
381 2013-09-26 17:10:06 <Luke-Jr> more like cherry-picking
382 2013-09-26 17:10:12 <gmaxwell> runeks: we decided not to because it was pretty new and required a bunch of additional third party code. But we left in a byte to let us add it later.
383 2013-09-26 17:10:16 <Luke-Jr> (well, git's "cherry picking")
384 2013-09-26 17:10:57 <Luke-Jr> gmaxwell: relatively speaking, isn't scrypt *still* pretty new? :P
385 2013-09-26 17:11:17 <gmaxwell> runeks: in practice what we have seems basically good enough. I think for a new wallet format I'd prefer to migrate to cantina... but yet again, a new function. (though it's very derrivitave of scrypt)
386 2013-09-26 17:11:44 <gmaxwell> Luke-Jr: it has had a lot more attention on it since then, as evidenced by the existance of cantina fixing flaws in it.
387 2013-09-26 17:11:50 <Luke-Jr> gmaxwell: finding cantina on google is hard :/
388 2013-09-26 17:12:25 <Luke-Jr> even 'cantina scrypt' gets google doing a non-optional rewrite to star wars terms :|
389 2013-09-26 17:13:49 <runeks> What about PBKDF(scrypt(cantina()))? Is that silly?
390 2013-09-26 17:14:07 <gmaxwell> helps if I spell it right! Catena http://eprint.iacr.org/2013/525
391 2013-09-26 17:14:25 <gmaxwell> runeks: no, that would actually undo some of catena's fixes arguably.
392 2013-09-26 17:14:29 <phantomcircuit> gmaxwell, :)
393 2013-09-26 17:15:20 <phantomcircuit> i like how just dice relies on the result of HMAC-SHA512(client_nonce + counter, server_key) being a surprise to the client
394 2013-09-26 17:15:21 <gmaxwell> runeks: it fixes two things: scrypt allows a bit too much computation / memory tradeoff, and it leaks information about its input data in a cache side channel.
395 2013-09-26 17:15:29 <phantomcircuit> something tells me that's no a great idea
396 2013-09-26 17:16:21 <runeks> So catena(PBKDF(scrypt()))? :)
397 2013-09-26 17:16:59 <runeks> But perhaps that's just making it too complicated, even if it would help somewhat.
398 2013-09-26 17:17:01 <gmaxwell> runeks: in all cases if you use scrypt another process on your system (e.g. js in another tab perhaps!) can learn some data about your password by observing timings.
399 2013-09-26 17:17:48 <runeks> gmaxwell: Oh, doh. So crypt should be the last function to be executed. But I guess it doesn't make sense to use scrypt if catena is scrypt+something extra.
400 2013-09-26 17:19:04 <gmaxwell> catena is just a restructuring of scrypt pretty much.
401 2013-09-26 17:22:45 <runeks> Right. But as far as I can tell, nesting (memory-hard) hash functions gives the security of the strongest function in the chain for pre-image attacks.
402 2013-09-26 17:23:09 <runeks> But again, it's not necessarily worth it, because of added complexity.
403 2013-09-26 17:24:09 <gmaxwell> runeks: plus it reduces their memory hardness, and it exposes you to the timing attack weaknesses of the weakest one.
404 2013-09-26 17:24:40 <phantomcircuit> gmaxwell, shouldn't the timing attack information only help you find the hash which the hash is hashing
405 2013-09-26 17:24:45 <phantomcircuit> unless it's the inner most hash
406 2013-09-26 17:25:29 <phantomcircuit> so something that's fairly side channel hard like the sha functions which operate in essentially constant time at the core followed by whatever
407 2013-09-26 17:25:30 <runeks> gmaxwell: Right. As for timing attacks, I guess you need to put the weakest/newest function last in the chain, since this would only allow you to find the output of the other, presumably stronger, functions.
408 2013-09-26 17:25:40 <phantomcircuit> as long as whatever isn't more vulnerable to a pre image?
409 2013-09-26 17:27:30 <runeks> gmaxwell: What do you mean by it reducing their memory hardness though?
410 2013-09-26 17:28:01 <gmaxwell> phantomcircuit: no, even if its the outer most hash its a sieve that speeds up your search.
411 2013-09-26 17:28:47 <runeks> ;;blocks
412 2013-09-26 17:28:48 <gribble> 260263
413 2013-09-26 17:28:54 <gmaxwell> runeks: makes the security less dependant on the cost of having lots of fast transistors, because you could reuse the same memory for each step.
414 2013-09-26 17:28:56 <Luke-Jr> runeks: the more CPU time spent, the less memory-hard it is
415 2013-09-26 17:29:49 <Luke-Jr> IMO, an ideal memory-as-POW algorithm would need to use near zero CPU time
416 2013-09-26 17:30:02 <Luke-Jr> (slightly shifting topic with that tho)
417 2013-09-26 17:30:42 <Luke-Jr> (and of course this doesn't solve the problem of memoryhard algorithms not being POW-capable yet)
418 2013-09-26 17:31:29 <runeks> I don't see why we would even want to use memory-hard POW algorithms.
419 2013-09-26 17:31:57 <Luke-Jr> runeks: at this point, probably not need
420 2013-09-26 17:32:07 <Luke-Jr> if it were possible, however, it would have made ASICs available from day 1
421 2013-09-26 17:32:42 <phantomcircuit> gmaxwell, how? i mean beyond reducing the effect of the outer hash of course
422 2013-09-26 17:33:00 <phantomcircuit> ie scrypt(sha256()) becomes more like sha256()
423 2013-09-26 17:33:14 <gmaxwell> phantomcircuit: right, if the other hash is 1/3rd of your cpu time, you can get a speedup vs the honest user using side information that lets you sieve at that step.
424 2013-09-26 17:33:34 <runeks> I mean, Bitcoin ASICs use enough resources as it is, no reason for them to also need fast memory. Then again, it could, perhaps, accelerate the development of faster memory, because you'd have a large advantage in mining.
425 2013-09-26 17:33:46 <gmaxwell> phantomcircuit: right and what you care about is the time ratio tolerance between the honest user and the attacker, so any speedup the attacker gets is a direct reduction in your security margin... as the honest user is doing computation that does them no good.
426 2013-09-26 17:34:25 <Luke-Jr> runeks: bitcoin ASICs had to be developed. if we had a memory-based POW, every PC would have had the ASICs in 2009
427 2013-09-26 17:34:29 <phantomcircuit> gmaxwell, except the attacker would need to have an open side channel which is arguably much more actual work :)
428 2013-09-26 17:34:43 <runeks> Luke-Jr: GPU?
429 2013-09-26 17:35:16 <phantomcircuit> gmaxwell, for most applications an attacker getting a 2-3x improvement over honest users isn't a big deal
430 2013-09-26 17:35:24 <phantomcircuit> especially for password comparisons
431 2013-09-26 17:35:50 <phantomcircuit> since realistically an attacker is usually going to have a GPU and the users just will use their CPU
432 2013-09-26 17:36:23 <Luke-Jr> runeks: RAM
433 2013-09-26 17:36:32 <gmaxwell> phantomcircuit: yea, but why add complexity to create that weakness.
434 2013-09-26 17:37:33 <runeks> Luke-Jr: Well, yeah, but that's not specific enough. Specialized ASICs would undoubtedly appear, even if only 10x as fast, and make CPU mining unprofitable.
435 2013-09-26 17:38:01 <Luke-Jr> runeks: that's the point. specialised ASICs for a memory-based POW is RAM itself
436 2013-09-26 17:38:01 <phantomcircuit> :)
437 2013-09-26 17:38:01 <phantomcircuit> gmaxwell, as a precaution against the hash function being used being completely broken, then again for bitcoin purposes everything might as well be sha256 since if that's significantly broken at least we'll all know about it really quickly
438 2013-09-26 17:38:05 <Luke-Jr> runeks: everyone already has it
439 2013-09-26 17:38:13 <runeks> Only these ASICs would also need a lot of RAM, and thus probably require even more power than SHA256 ASICs, and also remove a lot of RAM from other uses, thus increasing prices.
440 2013-09-26 17:38:33 <Luke-Jr> runeks: there wouldn't be anything besides RAM
441 2013-09-26 17:39:00 <runeks> Luke-Jr: RAM comes in different speeds though. I'm sure someone would be able to develop RAM with faster access times than DRAM.
442 2013-09-26 17:39:11 <Luke-Jr> great, faster RAM is normal
443 2013-09-26 17:39:16 <phantomcircuit> Luke-Jr, RAM is actually extremely slow, memory hard functions need to fit all of their memory usage into cache to be as fast as asics except different cpus have different cache sizes so all bets are off
444 2013-09-26 17:39:36 <runeks> Is anything faster than SRAM?
445 2013-09-26 17:39:49 <phantomcircuit> gmaxwell, unless there's a general solution to the cpu cache problems that im missing
446 2013-09-26 17:40:39 <Luke-Jr> phantomcircuit: well, a memory-based POW doesn't exist, so who knows how fast/slow it might be if it did
447 2013-09-26 17:41:22 <phantomcircuit> Luke-Jr, it's definitely possible to construct a memory hard pow function which couldn't be significantly improved with an asic
448 2013-09-26 17:41:33 <phantomcircuit> except that would only be true when it ran on a specific model of cpu
449 2013-09-26 17:41:35 <phantomcircuit> :)
450 2013-09-26 17:41:46 <gmaxwell> phantomcircuit: what do you mean by significantly?
451 2013-09-26 17:41:52 <runeks> phantomcircuit: But less than "significantly improved" is enough to make the point moot.
452 2013-09-26 17:41:55 <Luke-Jr> phantomcircuit: is it?
453 2013-09-26 17:42:00 <michagogo> cloud|<warren> michagogo|cloud: I'm going to upgrade ONLY boost for win32.  I need to work on more important things elsewhere.  Do you want to test the stability of the other library upgrades and upgrade the others yourself after my commit is accepted?
454 2013-09-26 17:42:05 <michagogo> cloud|<warren> michagogo|cloud: I ask because you seem to be very interested in gitian, and you appear to want to learn.
455 2013-09-26 17:42:05 <phantomcircuit> gmaxwell, 100x improvement
456 2013-09-26 17:42:17 <michagogo> cloud|warren: ping
457 2013-09-26 17:42:18 <Luke-Jr> phantomcircuit: keep in mind a POW would need to be easier to verify than to run, so you'd have to use less memory for the verification somehow
458 2013-09-26 17:42:27 <gmaxwell> phantomcircuit: maybe. 10x I agree. it's harder than you might think.
459 2013-09-26 17:42:39 <runeks> phantomcircuit: The barrier to entry in mining is so low that margins will be tiny, so even small improvements in efficiency would rule out mining on PCs.
460 2013-09-26 17:42:54 <gmaxwell> and what runeks said.
461 2013-09-26 17:43:12 <phantomcircuit> runeks, you're forgetting capital costs
462 2013-09-26 17:43:53 <phantomcircuit> it took almost 2 years for ASICs to show up in bitcoin where the improvement is much greater than 100x
463 2013-09-26 17:43:59 <gmaxwell> I think 10x is a "devastating" efficiency improvement in the context of mining, especially if its dual capital and power costs, considering the thin margins. And I don't think it's possible to preclude 10x.
464 2013-09-26 17:44:23 <gmaxwell> phantomcircuit: partially because we had a bunch of improvements along the way which were each 10x.
465 2013-09-26 17:44:41 <runeks> phantomcircuit: Capital costs are mostly NRE for ASICs. So I don't think that's so important.
466 2013-09-26 17:44:43 <gmaxwell> cpu - 10x > gpu - 10x > fpga - 10x > first gen asics.
467 2013-09-26 17:45:14 <phantomcircuit> gmaxwell, essentially if you could construct a pow function which used 100% of the L1 cache and never cache missed or missed a branch prediction you would have a function which would be exceptionally difficult to improve on with an asic
468 2013-09-26 17:45:25 <phantomcircuit> however it would only work on that one cpu efficiently
469 2013-09-26 17:45:48 <gmaxwell> phantomcircuit: you can get your 10x from pure peripheral costs though.
470 2013-09-26 17:46:01 <phantomcircuit> gmaxwell, hmm
471 2013-09-26 17:46:20 <gmaxwell> and from deoptimizing the cpu for serial speed and recovering the space for more parallelism.
472 2013-09-26 17:47:40 <gmaxwell> most of the gates on a modern cpu (ignoring cache) are for ooo pipeline stuff, and its actually quite hard to design a function that requires that logic.  I'd imagine that you could get 10x from peripheral costs, and 2x from deoptimizing.
473 2013-09-26 17:49:14 <gribble> The operation succeeded.
474 2013-09-26 17:49:14 <michagogo> cloud|;;later tell warren The idea does interest me, and I'm also interested in (at least partially) understanding how it works. However, I don't really have that much knowledge when it comes to software development and/or building. How much would be involved in testing those upgrades, both in terms of skills/knowledge needed to do so, and in terms of how much and
475 2013-09-26 17:49:14 <michagogo> cloud|what kind of testing is needed and the skills/knowledge needed for that?
476 2013-09-26 17:49:17 <maaku> gmaxwell: sounds like a return of risc
477 2013-09-26 17:49:39 <michagogo> cloud|Damn, too long for one line
478 2013-09-26 17:50:22 <michagogo> cloud|Does gribble let you do more than one later tell to the same person, or will the second one replace the first?
479 2013-09-26 17:51:54 <Luke-Jr> maaku: everything is RISC
480 2013-09-26 17:52:08 <maaku> Luke-Jr: I mean like the R3000
481 2013-09-26 17:53:05 <maaku> I bet with modern chip factories you could create a chip with 64 R3000 cores each running double-digit gigahertz
482 2013-09-26 17:53:19 <maaku> i'm not sure how you'd scale memory access though
483 2013-09-26 17:53:37 <maaku> of course you go down that route, it starts to sound a lot like Cell...
484 2013-09-26 17:54:28 <michagogo> cloud|;;help later tell
485 2013-09-26 17:54:29 <gribble> (later tell <nick> <text>) -- Tells <nick> <text> the next time <nick> is in seen. <nick> can contain wildcard characters, and the first matching nick will be given the note.
486 2013-09-26 17:54:42 <midnightmagic> michagogo|cloud: not secure, by the way.
487 2013-09-26 17:54:49 <michagogo> cloud|midnightmagic: hmm?
488 2013-09-26 17:55:03 <michagogo> cloud|As in, /nick warren; hi?
489 2013-09-26 17:55:04 <midnightmagic> michagogo|cloud: if you want the message to be private, don't use later tell
490 2013-09-26 17:55:13 <michagogo> cloud|midnightmagic: yeah, ik
491 2013-09-26 17:55:17 <midnightmagic> k
492 2013-09-26 17:55:53 <michagogo> cloud|midnightmagic: do you know if it allows multiple messages queues for one user?
493 2013-09-26 17:56:35 <michagogo> cloud|
ACTION tries to remember what midnightmagic does, since there are too many services out there with too many operators to keep track of

494 2013-09-26 17:57:08 <michagogo> cloud|midnightmagic: (also, it's not private anyway because bitcoinstats.com)
495 2013-09-26 17:58:50 <cfields> michagogo|cloud: wget file && git am file
496 2013-09-26 17:58:51 <midnightmagic> michagogo|cloud: I'm not sure, I never use it.
497 2013-09-26 17:59:04 <cfields> wrt out-of-band git commits
498 2013-09-26 17:59:20 <midnightmagic> midnightmagic: What do you mean, what do I do? like, for work? or what am I doing in here? Or what am I doing this morning?
499 2013-09-26 17:59:34 <midnightmagic> er..  michagogo|cloud ^^
500 2013-09-26 18:01:34 <michagogo> cloud|midnightmagic: as in, which site/service(s) do you own/run, if any? I recognize your name, but I'm not sure from what
501 2013-09-26 18:03:10 <Luke-Jr> midnightmagic is just awesome without running anything <.< (afaiK)
502 2013-09-26 18:06:42 <midnightmagic> :-)
503 2013-09-26 18:07:33 <midnightmagic> michagogo|cloud: I've been here since ~ Nov 2010. I am a private miner. I know how to grok a stackdump..  and I guess I'm an op all over the place. At least in terms of public bitcoin-related stuff.
504 2013-09-26 18:07:43 <midnightmagic> that's pretty much it. :)
505 2013-09-26 18:07:53 <sipa> nov 2010 :o
506 2013-09-26 18:08:01 <sipa> that's one month before me!
507 2013-09-26 18:08:53 <midnightmagic> -ish. That's when artforz convinced me in less than two days with his insight and logical consistency that bitcoin was something I wanted to help with.
508 2013-09-26 18:09:04 <sipa> ha
509 2013-09-26 18:09:27 <sipa> i think i joined slush's pool when it jad solved 2 blocks
510 2013-09-26 18:09:33 <midnightmagic> he was pretty persuasive.
511 2013-09-26 18:09:53 <midnightmagic> i remember when slush was trying to deal with pool-hoppers.
512 2013-09-26 18:09:59 <sipa> yeah
513 2013-09-26 18:10:02 <sipa> damn
514 2013-09-26 18:10:06 <Cusipzzz> nov 2010 here as well, but i do even less than midnightmagic :)
515 2013-09-26 18:10:06 <michagogo> cloud|midnightmagic: Hmm, interesting -- I wonder why I thought that, then.
516 2013-09-26 18:10:13 <sipa> that's almost 3 years ago
517 2013-09-26 18:10:31 <midnightmagic> michagogo|cloud: I talk with more officious-ness than is probably actually due.
518 2013-09-26 18:10:35 <sipa> 
ACTION = stating the obvious since 1984

519 2013-09-26 18:10:36 <midnightmagic> sipa: long time..
520 2013-09-26 18:12:34 <midnightmagic> sipa: er..  3 years is a long time to be monkeying around with btc. :)
521 2013-09-26 18:13:14 <sipa> that's the word!
522 2013-09-26 18:14:32 <gmaxwell> sipa: oh. my commentary about refund protocols being destroyed by malleability. P2SH actually can rescue them.
523 2013-09-26 18:14:56 <midnightmagic> i don't suppose anybody has a link to the video of applebaum talking to the UN recently?
524 2013-09-26 18:15:01 <gmaxwell> If the escrow that the refund is being computed for is P2SH then I can get you to sign a refund while you still can't identify the escrow payment.
525 2013-09-26 18:25:54 <phantomcircuit> gmaxwell, boo
526 2013-09-26 18:26:15 <phantomcircuit> ca regulators say i have to be a licensed escrow agent if i operate in the state even if i dont have any clients in the state
527 2013-09-26 18:26:16 <phantomcircuit> :(
528 2013-09-26 18:26:50 <phantomcircuit> amazing this raspberrypi is still running apt-get upgrade
529 2013-09-26 18:27:33 <phantomcircuit> oh wait no maybe it's just crashed
530 2013-09-26 18:27:40 <phantomcircuit> yeah that one
531 2013-09-26 18:27:42 <phantomcircuit> >.>
532 2013-09-26 18:31:49 <gmaxwell> sipa: https://bitcointalk.org/index.php?topic=303088.0
533 2013-09-26 18:32:46 <midnightmagic> rpi crashes a lot for me too.
534 2013-09-26 18:33:55 <midnightmagic> the 512MB version so far has not, even under load. three 256MB versions, however, crash constantly.
535 2013-09-26 18:44:41 <phantomcircuit> midnightmagic, this doesn't have any swap
536 2013-09-26 18:44:47 <phantomcircuit> i think sshd was just oom killed
537 2013-09-26 18:45:45 <gcX46> can I ask a question on stratum here? no one on #stratum is answering
538 2013-09-26 18:46:31 <Luke-Jr> gcX46: sure, if it's development-related
539 2013-09-26 18:46:52 <gcX46> ok nvm someone answered
540 2013-09-26 19:04:34 <warren> michagogo|cloud: I was suggesting that you work on one of the easier tasks, seeing if those builds work stable before and after the dep upgrade.
541 2013-09-26 19:13:35 <midnightmagic> holy crap https://www.youtube.com/watch?v=7ra2JA7PL2Y
542 2013-09-26 19:19:47 <edcba> michagogo|cloud: tldw ?
543 2013-09-26 19:19:56 <edcba> midnightmagic
544 2013-09-26 19:21:51 <phantomcircuit> hey guys
545 2013-09-26 19:22:01 <phantomcircuit> i just bought myself a 1080p microSDHC card
546 2013-09-26 19:22:04 <phantomcircuit> you jealous
547 2013-09-26 19:22:40 <DiabloD3> uh, okay? what does resolution have to do with storage capacity or throughput?
548 2013-09-26 19:23:31 <phantomcircuit> DiabloD3, i have no idea
549 2013-09-26 19:24:07 <phantomcircuit> the sandisk 8gb card is clearly labeled FULL HD 1080P
550 2013-09-26 19:24:39 <DiabloD3> its probably just a HS class 1 or whatever they're calling them now
551 2013-09-26 19:24:53 <phantomcircuit> UHS-1
552 2013-09-26 19:25:03 <DiabloD3> yeah that
553 2013-09-26 19:25:13 <DiabloD3> is it one?
554 2013-09-26 19:25:29 <phantomcircuit> DiabloD3, there is only one UHS level
555 2013-09-26 19:25:35 <phantomcircuit> it's a hilarious marketing gimmick
556 2013-09-26 19:25:44 <DiabloD3> phantomcircuit: nope
557 2013-09-26 19:25:52 <DiabloD3> UHS-II was done in SDXC spec version 4
558 2013-09-26 19:25:54 <phantomcircuit> DiabloD3, they vary in speed wildly but are all UHS-1
559 2013-09-26 19:26:05 <phantomcircuit> DiabloD3, i've literally never seen one ever
560 2013-09-26 19:26:10 <DiabloD3> goes from 208mhz clock speed to 312
561 2013-09-26 19:26:12 <DiabloD3> well, you wont for awhile
562 2013-09-26 19:26:15 <DiabloD3> it adds another row of pins
563 2013-09-26 19:26:36 <phantomcircuit> oh
564 2013-09-26 19:26:46 <DiabloD3> UHS-I is maximum of 832 mbit/sec
565 2013-09-26 19:27:01 <phantomcircuit> DiabloD3, the minimum is what really counts
566 2013-09-26 19:27:07 <phantomcircuit> and the minimum they public is nonsense
567 2013-09-26 19:27:11 <DiabloD3> or 104? MB/sec (did it in head, probably wrong)
568 2013-09-26 19:27:27 <phantomcircuit> DiabloD3, it's right
569 2013-09-26 19:27:35 <DiabloD3> wow, Im surprised
570 2013-09-26 19:27:36 <phantomcircuit> iirc the advertised minimum is 10MB/s reads
571 2013-09-26 19:27:48 <DiabloD3> yeah, its up entirely to the speed of the flash
572 2013-09-26 19:28:21 <DiabloD3> but UHS is just the bus specification
573 2013-09-26 19:28:24 <DiabloD3> its not a speed grade
574 2013-09-26 19:28:36 <DiabloD3> problem is, the original class system doesnt work anymore
575 2013-09-26 19:28:56 <DiabloD3> class 10 is like 15MB/sec or some shit
576 2013-09-26 19:29:09 <phantomcircuit> DiabloD3, USH has speed ratings also
577 2013-09-26 19:29:13 <DiabloD3> and specifying cdrom speeds is pretty fucked up too
578 2013-09-26 19:29:20 <DiabloD3> we're like, past 500
579 2013-09-26 19:31:19 <michagogo> cloud|<phantomcircuit> the sandisk 8gb card is clearly labeled FULL HD 1080P
580 2013-09-26 19:31:40 <michagogo> If I had to guess, I'd say it's fast enough to support recording of 1080p
581 2013-09-26 19:32:06 <michagogo> As in, put it in a video camera, and it can be written to in real time
582 2013-09-26 19:32:24 <michagogo> warren: did you see the second half of the message that gribble didn't get?
583 2013-09-26 19:32:44 <DiabloD3> yeah, it only needs to support 25mbps video
584 2013-09-26 19:33:12 <DiabloD3> which, really, isnt hard anymore
585 2013-09-26 19:33:54 <michagogo> also...
586 2013-09-26 19:33:56 <warren> michagogo: run all the tests, see if the client behaves as expected
587 2013-09-26 19:33:59 <michagogo> looks like the logs don't like | in nicks
588 2013-09-26 19:34:01 <michagogo> http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/09/26#l1380217660
589 2013-09-26 19:34:18 <michagogo> warren: As in the test scripts that come with bitcoin?
590 2013-09-26 19:34:37 <michagogo> 
ACTION has actually never looked at those

591 2013-09-26 19:35:15 <phantomcircuit> michagogo, 1080p H.264 is like 12mbps
592 2013-09-26 19:35:27 <phantomcircuit> or 1.5 MB/s sequential writes
593 2013-09-26 19:35:33 <DiabloD3> depends on the camera
594 2013-09-26 19:35:41 <midnightmagic> edcba: hard to summarize. :-(
595 2013-09-26 19:35:57 <DiabloD3> but like, sandisk's newest extreme pro does 90 MB/sec writes
596 2013-09-26 19:36:12 <DiabloD3> or 720mbit
597 2013-09-26 19:36:34 <phantomcircuit> DiabloD3, the slowest part about this is archive.raspberrypi.org artificially limiting individual http requests to 300 KB/s
598 2013-09-26 19:36:42 <DiabloD3> lolwat
599 2013-09-26 19:36:55 <phantomcircuit> yeah
600 2013-09-26 19:37:07 <phantomcircuit> 30MB individual file download and it's chillin at 300 KB/s
601 2013-09-26 19:37:12 <phantomcircuit> thanks guys
602 2013-09-26 19:37:16 <DiabloD3> yeah but like
603 2013-09-26 19:37:19 <michagogo> phantomcircuit: if you search google, there are some command-line things that will download over multiple connection
604 2013-09-26 19:37:20 <michagogo> s
605 2013-09-26 19:37:23 <DiabloD3> thats about what I get on my SDL =/
606 2013-09-26 19:37:25 <DiabloD3> er DSL
607 2013-09-26 19:37:26 <michagogo> also...
608 2013-09-26 19:37:32 <michagogo> 30MB individual file download and it's chillin at 300 KB/s
609 2013-09-26 19:37:40 <warren> michagogo: upgrade deps to "widely distributed, not bleeding edge" versions used by the leading Linux distributions, build it in gitian, see if you find any problems with the binary.
610 2013-09-26 19:37:50 <michagogo> you're talking a couple mins
611 2013-09-26 19:37:52 <phantomcircuit> DiabloD3, im thinking someone thought limiting individual downloads throughput would improve performance
612 2013-09-26 19:38:09 <warren> michagogo: we don't expect any problems given devs build it against distro libraries all the time
613 2013-09-26 19:38:13 <phantomcircuit> michagogo, yeah which is super annoying when you're on 100/20
614 2013-09-26 19:38:18 <michagogo> "used by the leading Linux distributions"
615 2013-09-26 19:38:30 <phantomcircuit> 2 seconds vs several minutes
616 2013-09-26 19:38:37 <michagogo> phantomcircuit: <2
617 2013-09-26 19:38:57 <michagogo> 300 KB/s, 3 MB/10s, 30 MB/100s
618 2013-09-26 19:39:40 <phantomcircuit> michagogo, lol
619 2013-09-26 19:39:43 <phantomcircuit> ok
620 2013-09-26 19:40:00 <michagogo> warren: How do you define "leading", by "using" do you mean "in the repos as stable", and how extensively would testing need to be done?
621 2013-09-26 19:40:17 <phantomcircuit> it's annoying being artificially limited to 2.4% of the lines capacity
622 2013-09-26 19:40:47 <phantomcircuit> i understand the goal is to prevent bandwidth starvation attacks by limiting throughput per connection and then concurrent connections
623 2013-09-26 19:40:52 <phantomcircuit> but it's still super annoying
624 2013-09-26 19:41:43 <warren> michagogo: has Ubuntu, Fedora, SuSE, Arch or whatever shipped that library
625 2013-09-26 19:42:09 <warren> michagogo: just upgrade them all to a version that it seems many are using
626 2013-09-26 19:42:19 <warren> michagogo: download the source from multiple places and make sure it matches
627 2013-09-26 19:42:20 <michagogo> and, how hard is it to do the upgrade? is it just a matter of downloading new tar.*z files and changing the file names in the gitian descriptor for windows deps?
628 2013-09-26 19:42:27 <warren> maybe
629 2013-09-26 19:42:52 <warren> just do it, see if it works, ask for help if you get stuck
630 2013-09-26 19:43:06 <michagogo> Also: what about the version? Am I looking for "ships in lucid" or "ships in raring", for Ubuntu, for example?
631 2013-09-26 19:43:45 <warren> michagogo: doesn't matter
632 2013-09-26 19:44:58 <warren> michagogo: first apply my 3 commits, then try to upgrade the deps-win32.yml
633 2013-09-26 19:45:42 <michagogo> Well, I think I might want to see if I can figure out how to get gitian working with LXC in a VM before I get started with that
634 2013-09-26 19:46:36 <michagogo> warren: (oh, and did you get enough responses for http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/09/26#l1380188655? I'm on Windows, if you still need.)
635 2013-09-26 19:47:22 <warren> michagogo: how were you doing gitian builds before?
636 2013-09-26 19:47:34 <michagogo> rebooting into an Ubuntu install on an external harddrive
637 2013-09-26 19:51:34 <swulf--> How can I devise a transaction such that the output goes entirely to address A or B depending on the outcome of some challenge?  Ex: over of A challenges owner of B that he can't prime factor P within 5 minutes... is there a way to do this without 3rd party trust?
638 2013-09-26 19:51:46 <swulf--> s/over/owner*
639 2013-09-26 19:51:57 <michagogo> swulf--: sure
640 2013-09-26 19:52:12 <swulf--> is there a name for this?
641 2013-09-26 19:52:17 <michagogo> swulf--: make a transaction from A to B with nlocktime 5 minutes in the future, and give that transaction to B
642 2013-09-26 19:52:36 <michagogo> In other words, the transaction won't be possible to mine for 5 minutes
643 2013-09-26 19:52:42 <swulf--> right
644 2013-09-26 19:53:00 <swulf--> but in this case, regardless of whether B finds the factors or not, the tx gets mined in 5 minutes
645 2013-09-26 19:53:11 <michagogo> Any time before then, A can create a transaction sending those coins back to himself
646 2013-09-26 19:53:22 <michagogo> Also, no need to broadcast it
647 2013-09-26 19:53:27 <michagogo> A can give it to B
648 2013-09-26 19:53:34 <swulf--> michagogo: now add in the requirement that B cannot trust A
649 2013-09-26 19:54:04 <michagogo> Maybe a multisig?
650 2013-09-26 19:54:08 <michagogo> Oh
651 2013-09-26 19:54:11 <swulf--> would require a 3rd party
652 2013-09-26 19:54:15 <michagogo> yeah
653 2013-09-26 19:54:29 <michagogo> 
ACTION thinks

654 2013-09-26 19:54:33 <swulf--> are there decentralized "oracle" solutions?
655 2013-09-26 19:55:01 <michagogo> (also, I'm not sure nlocktime is effective with such small lengths of time)
656 2013-09-26 19:55:32 <swulf--> sure
657 2013-09-26 19:55:37 <swulf--> it's the point that matters
658 2013-09-26 19:55:47 <michagogo> Since it relies on the block timestamp, so if B had hashpower he could mine a block with a timestamp 5 mins in the future
659 2013-09-26 19:56:01 <swulf--> yeah
660 2013-09-26 19:56:45 <swulf--> what i'm actually curious to know if there's either distributed or decentralized escrow or oracle protocols that can work in low trust environments to arbitrate challenges like this ...
661 2013-09-26 19:56:47 <michagogo> Actually, that would mean that a time-based nlocktime (as opposed to block height) would be ineffective at times up to several few hours
662 2013-09-26 19:57:07 <swulf--> of course
663 2013-09-26 19:57:17 <michagogo> hmm
664 2013-09-26 19:57:31 <michagogo> Well, if the challenge is one that can be solved within the script system...
665 2013-09-26 19:57:48 <swulf--> hrm
666 2013-09-26 19:57:56 <swulf--> is there a script limit? :P
667 2013-09-26 19:58:01 <swulf--> size limit*
668 2013-09-26 19:58:05 <michagogo> Well, there's IsStandard
669 2013-09-26 19:58:18 <swulf--> right, it would definitely be a nonstandard tx
670 2013-09-26 19:58:37 <michagogo> In that case, you could make a 2-of-2 or 2-of-3 multisig
671 2013-09-26 19:58:50 <michagogo> send to there, and first sign an nlocktimed refund transaction
672 2013-09-26 19:59:15 <michagogo> (refund signed before sending-in transaction is broadcast)
673 2013-09-26 19:59:40 <michagogo> and then have both parties sign a transaction that pays to the solution of the challenge
674 2013-09-26 20:00:00 <swulf--> unfortunately I don't think I can use the script system to determine the outcome
675 2013-09-26 20:00:01 <sipa> swulf--: it would be possible if you could encode the challenge in bitcoin's script language
676 2013-09-26 20:00:06 <michagogo> or perhaps solution of the challenge + sig
677 2013-09-26 20:00:10 <swulf--> sipa: yeah..
678 2013-09-26 20:00:16 <michagogo> sipa: Just said that :-P
679 2013-09-26 20:00:34 <sipa> sorry, TL;DR
680 2013-09-26 20:00:34 <swulf--> sipa: but the difficulty of the solution is on the order of checking the outcome of a chess game given a list of moves
681 2013-09-26 20:00:53 <swulf--> which I think is possible within the system as defined, but it would be a rather large script..
682 2013-09-26 20:01:03 <sipa> nah
683 2013-09-26 20:02:31 <swulf--> you'd need to verify every players move as valid (and their signature for that move) and then check for a winner at each turn
684 2013-09-26 20:03:52 <michagogo> yeah, not possile
685 2013-09-26 20:04:08 <michagogo> +b
686 2013-09-26 20:38:15 <michagogo> devrandom: around, by any chance?
687 2013-09-26 20:38:21 <michagogo> .j ##michagogo-gitian
688 2013-09-26 20:38:23 <michagogo> erm
689 2013-09-26 21:24:50 <warren> https://github.com/bitcoin/bitcoin/pull/3029  upgrade gitian win32 to precise has two ACK's. If you have the ability to do gitian builds, please help test this and the resulting win32 binary.