1 2012-10-07 00:49:28 <CrazyMF> yeah hey. more questions
  2 2012-10-07 00:49:33 <CrazyMF> txn_count - when is it used?
  3 2012-10-07 00:49:57 <CrazyMF> there's no mention of it in 'block hashing algo', but it's in Protocol_specification#Block_Headers
  4 2012-10-07 00:50:57 <Luke-Jr> CrazyMF: it immediately follows the block header
  5 2012-10-07 00:51:02 <Luke-Jr> before all the txn data
  6 2012-10-07 00:51:38 <CrazyMF> I see
  7 2012-10-07 00:51:46 <CrazyMF> but it's not used while mining ?
  8 2012-10-07 00:51:54 <Luke-Jr> nope
  9 2012-10-07 00:52:02 <CrazyMF> ok
 10 2012-10-07 00:52:10 <CrazyMF> trying to figure out the whole miner thing
 11 2012-10-07 00:52:12 <CrazyMF> in C
 12 2012-10-07 00:53:08 <Luke-Jr> CrazyMF: check out libblkmaker source? :P
 13 2012-10-07 00:53:54 <Luke-Jr> http://gitorious.org/bitcoin/libblkmaker/trees/master
 14 2012-10-07 00:54:22 <CrazyMF> a bit difficult name to prononounce
 15 2012-10-07 00:54:41 <Diablo-D3> what is?
 16 2012-10-07 00:54:41 <Luke-Jr> lib block maker? :P
 17 2012-10-07 00:55:12 <CrazyMF> that makes sense
 18 2012-10-07 00:55:25 <Diablo-D3> who are you talking to?
 19 2012-10-07 00:55:50 <Luke-Jr> (ignore Diablo-D3, he's a troll)
 20 2012-10-07 00:56:14 <CrazyMF> \\/ignore
 21 2012-10-07 00:58:05 <CrazyMF> \tsend_json(req);
 22 2012-10-07 00:58:19 <Luke-Jr> CrazyMF: send_json is part of the example.c
 23 2012-10-07 00:58:22 <Luke-Jr> json_decref is jansson
 24 2012-10-07 00:59:08 <CrazyMF> ok, lemme read more
 25 2012-10-07 00:59:30 <Luke-Jr> the actual algorithm is in blkmaker.c
 26 2012-10-07 01:02:01 <CrazyMF> Also note that you should NOT roll ntime for data retrieved..... maxtime limits..    <-- is it the 2 hour or something thingie ?
 27 2012-10-07 01:02:58 <Luke-Jr> CrazyMF: some pools might have stricter limits on the time header, but yes
 28 2012-10-07 01:15:33 <CrazyMF> so this code went mainline?
 29 2012-10-07 01:19:30 <Luke-Jr> CrazyMF: eh, mainline what?
 30 2012-10-07 01:20:08 <Luke-Jr> CrazyMF: that *is* mainline libblkmaker
 31 2012-10-07 01:20:34 <Luke-Jr> which is used for mainline BFGMiner
 32 2012-10-07 01:35:54 <CrazyMF> I meant bitcoind getblocktemplate
 33 2012-10-07 01:37:01 <Luke-Jr> bitcoind GBT is just a minimal server-side
 34 2012-10-07 01:37:07 <Luke-Jr> libblkmaker is client-side
 35 2012-10-07 01:37:52 <CrazyMF> I never knew that server-side part existed before
 36 2012-10-07 01:37:57 <CrazyMF> makes the whole thing way easier
 37 2012-10-07 01:38:26 <CrazyMF> btw. coinbase is reward+TX_fees ?
 38 2012-10-07 01:38:34 <Luke-Jr> a more complete server-side implementation is in Eloipool: http://gitorious.org/bitcoin/eloipool/trees/master
 39 2012-10-07 01:38:40 <Luke-Jr> yes
 40 2012-10-07 01:39:41 <CrazyMF> can't speak in python :D still interesting to browse
 41 2012-10-07 01:40:17 <Luke-Jr> >_<
 42 2012-10-07 01:45:43 <CrazyMF> all the fees are listed in "Satoshis", how they are converted to BTC? x 0.0(..)1 ?
 43 2012-10-07 01:46:10 <Luke-Jr> 1 BTC = 100000000 satoshis
 44 2012-10-07 01:47:20 <CrazyMF> some big numbers
 45 2012-10-07 01:51:48 <jine> I should catch up with the mining-development again i think... Reading up on stratum and various other things.. :) Some nice progress.
 46 2012-10-07 01:55:42 <gmaxwell> CrazyMF: it's pretty important to do bitcoin math with integers. lest some rounding screw you.
 47 2012-10-07 01:59:19 <CrazyMF> yeah right, AVX extension on sandy/ivy bridge only does floats
 48 2012-10-07 01:59:41 <CrazyMF> not gonna convince me to switch into a 128 bit wide SIM registers
 49 2012-10-07 01:59:57 <CrazyMF> SIMD*
 50 2012-10-07 02:03:02 <CrazyMF> what's a SigOp ?
 51 2012-10-07 02:16:02 <gmaxwell> CrazyMF: I'm not sure if you were joking, or ... some of the ideas that show up here are so weird its hard to tell.
 52 2012-10-07 02:16:25 <gmaxwell> (wrt AVX)
 53 2012-10-07 02:17:26 <CrazyMF> lol yeah. Using vectors to calculate fees :D
 54 2012-10-07 02:17:34 <CrazyMF> but it still bugs me to no end
 55 2012-10-07 02:18:03 <CrazyMF> that intel couldn't manage to fit new integer simds into *_bridge
 56 2012-10-07 02:18:16 <CrazyMF> ...wait til haswell
 57 2012-10-07 02:25:03 <CrazyMF> noncerange - is this in the planes for being real?
 58 2012-10-07 02:25:08 <CrazyMF> plans*
 59 2012-10-07 04:14:17 <Evilmax> when it ends of falling? and why it falls so?
 60 2012-10-07 05:42:45 <Evilmax> i knows a btc address that returns back double of btc you send it
 61 2012-10-07 05:53:34 <kjj_> seems unlikely
 62 2012-10-07 13:35:08 <gmaxwell> Awesome: eldentyrell's FPGA images had an intentional undisclosed logic bomb that when the ntime because too large they started spitting out junk. Knocked out a bunch of hashpower:
 63 2012-10-07 13:35:13 <gmaxwell> https://bitcointalk.org/index.php?topic=49971.msg1247263#msg1247263
 64 2012-10-07 13:35:41 <sipa> heh?
 65 2012-10-07 13:39:38 <phantomcircuit> gmaxwell, shrug
 66 2012-10-07 13:40:13 <gmaxwell> People should hope that the asic miner's they're buying don't have similar features!
 67 2012-10-07 13:41:06 <phantomcircuit> gmaxwell, i doubt they do since it's not a DRM thing
 68 2012-10-07 13:41:23 <phantomcircuit> the reason he's doing that is because he doesn't directly sell the FPGA
 69 2012-10-07 13:41:38 <phantomcircuit> so he's getting people to mine his blocks and he takes a fee using DRM
 70 2012-10-07 13:41:54 <phantomcircuit> bfl has no incentive to do that
 71 2012-10-07 13:42:09 <phantomcircuit> indeed at this point they'd probably get called scammers
 72 2012-10-07 13:42:18 <phantomcircuit> but hey who hasn't been called a scammer?
 73 2012-10-07 13:42:53 <gmaxwell> Me.
 74 2012-10-07 13:43:01 <gmaxwell> :P
 75 2012-10-07 13:43:17 <phantomcircuit> lies
 76 2012-10-07 13:43:46 <ThomasV> gmaxwell: intentional??
 77 2012-10-07 13:44:56 <gmaxwell> As phantomcircuit said, it was for DRM purposes.
 78 2012-10-07 13:45:24 <phantomcircuit> it seems like he basically forgot that it existed
 79 2012-10-07 13:45:25 <phantomcircuit> lawl
 80 2012-10-07 14:21:07 <Luke-Jr> phantomcircuit: ironically, he's not even taking a fee yet
 81 2012-10-07 14:32:05 <sipa> jgarzik: preference for a gettxout RPC: should it include memory-pool transactions?
 82 2012-10-07 14:32:18 <jgarzik> sipa: oooh, good question
 83 2012-10-07 14:32:25 <jgarzik> sipa: I suppose it needs a confirmations fields
 84 2012-10-07 14:32:26 <sipa> and similarly, should it exclude outputs consumed by the memory pool?
 85 2012-10-07 14:32:33 <jgarzik> *field
 86 2012-10-07 14:32:34 <sipa> yes, it will have a confirmations field anyway
 87 2012-10-07 14:33:25 <jgarzik> sipa: yeah, I would include unspent mempool TXs (indicated by confirmations:0), but exclude spent ones (spent by other mempool TXs)
 88 2012-10-07 14:33:49 <sipa> that feels inconsistent
 89 2012-10-07 14:34:07 <sipa> maybe a boolean argument to include/exclude mempool?
 90 2012-10-07 14:34:32 <jgarzik> sipa: are you returning spent txout's, otherwise?
 91 2012-10-07 14:34:53 <sipa> no; spent txout don't exist
 92 2012-10-07 14:35:24 <jgarzik> sipa: good
 93 2012-10-07 14:35:33 <jgarzik> sipa: then I would follow same policy for mempool
 94 2012-10-07 14:35:59 <sipa> so you either get an object with amount, confirmations, and txout script; or you get nothing
 95 2012-10-07 14:36:34 <sipa> there is also no sound way to distinguish between spent and non-existing, so the RPC won't try to
 96 2012-10-07 14:39:00 <jgarzik> sipa: no sound way... without an additional index
 97 2012-10-07 14:39:16 <jgarzik> but yes, agree on RPC behavior
 98 2012-10-07 14:39:17 <gavinandresen> darn, have to leave just when the conversation here starts to get interesting....
 99 2012-10-07 14:39:42 <sipa> jgarzik: of course; with additional indexes everything is possible
100 2012-10-07 14:41:39 <gavinandresen> ... having RPC features that only work if you run with optional indexing turned on might make sense.  Could be a testing nightmare, though.
101 2012-10-07 14:42:40 <sipa> gavinandresen: first want to get basic guaranteed behaviour right
102 2012-10-07 14:42:51 <sipa> optional indexes can do cool stuff, but it shouldn't be essential
103 2012-10-07 14:44:13 <jgarzik> distinguishing between spent and non-existing is not super-important, in this case
104 2012-10-07 14:44:41 <jgarzik> just disagreeing with "no sound way"...  because it is very easy to do in pynode, with its all-tx index ;p
105 2012-10-07 14:45:12 <jgarzik> but let's not get sidetracked.  proposed is OK
106 2012-10-07 14:46:14 <phantomcircuit> sipa, cool stuff like what?
107 2012-10-07 14:46:38 <gmaxwell> certantly adding common network calls that need extra indexes is not a good thing where it can be avoided.
108 2012-10-07 14:46:58 <sipa> phantomcircuit: things i think should be discouraged, like an address->txid map
109 2012-10-07 14:49:42 <phantomcircuit> sipa, hmm
110 2012-10-07 14:51:48 <Eliel_> sipa: how about a script hash -> txid map?
111 2012-10-07 14:52:23 <sipa> Eliel_: same thing
112 2012-10-07 14:52:27 <Eliel_> why?
113 2012-10-07 14:52:58 <sipa> because i think it's a bad idea of infrastructure starts relying on such indexes, while they're not necessary
114 2012-10-07 14:53:34 <sipa> as i'd like the guaranteed service provided by bitcoin nodes to be as lightweight as possible
115 2012-10-07 14:53:39 <gmaxwell> Eliel_: keep in mind this is for network facing calls.
116 2012-10-07 14:53:49 <gmaxwell> For RPC facing calls it's a different question.
117 2012-10-07 14:54:05 <Eliel_> ah, ok, now I get it
118 2012-10-07 14:55:42 <Eliel_> although, that makes me wonder how will light clients deal with it if there's days worth of blocks since that last time they were online. Download all blocks and transactions and discard the ones that are not in their own wallets?
119 2012-10-07 14:56:52 <sipa> Eliel_: that's exactly how they work
120 2012-10-07 14:57:08 <sipa> and in the future, they'll ask their peers to filter out anything they're not interested in
121 2012-10-07 14:57:36 <Eliel_> isn't that an even heavier operation than a address -> txid mapping?
122 2012-10-07 14:57:46 <sipa> no
123 2012-10-07 14:57:56 <sipa> all you need for that is the blocks
124 2012-10-07 14:58:06 <sipa> without any index
125 2012-10-07 14:58:07 <sipa> and some nodes need the blocks anyway
126 2012-10-07 14:58:32 <sipa> (sure you can speed up disk access by having an index, but that isn't required for correct operation)
127 2012-10-07 15:00:03 <gmaxwell> What we want to avoid doing is creating infrastructure where people can assume random peers will happily carry expensive indexes for them so they can have no storage at all with their wallets.
128 2012-10-07 15:00:29 <gmaxwell> e.g. if we want to assume any storage that nodes must have, it should be storage thats required for the security properties of the network
129 2012-10-07 15:01:40 <kjj_> are you thinking of a very light client, like a phone app?
130 2012-10-07 15:02:49 <gmaxwell> Like electrum. And we should make it possible for the reference client to support electrum like clients (all we need is an script->txid index and the right proxy), but not via the default p2p port.
131 2012-10-07 15:03:18 <Eliel_> gmaxwell: so, what's the prevent someone from using the filtered block query as a substitute for address -> txid query?
132 2012-10-07 15:03:38 <sipa> Eliel_: why should that be prevented?
133 2012-10-07 15:03:52 <sipa> it will be slow to do that for the entire history anyway
134 2012-10-07 15:04:03 <gmaxwell> Eliel_: nothing. Other than that it'll be much slower for them than using a proper service for it.
135 2012-10-07 15:04:17 <kjj_> gmaxwell: my minimal hardware wallet idea would use RPC
136 2012-10-07 15:04:29 <gmaxwell> kjj_: yea, we're not talking about RPC here.
137 2012-10-07 15:05:01 <Eliel_> gmaxwell: well, let's hope no-one creates a popular application that misuses it that way since a proper address -> txid doesn't exist.
138 2012-10-07 15:05:23 <gmaxwell> Eliel_: whats to hope about there?
139 2012-10-07 15:05:28 <gmaxwell> It's not like the world ends if they do.
140 2012-10-07 15:05:32 <sipa> Eliel_: if someone does, i'm sure it will be so slow that an actual SPV node will be more useful
141 2012-10-07 15:05:34 <kjj_> gmaxwell: you are talking about ways for devices without the blockchain to get the information they need to do transactions
142 2012-10-07 15:05:37 <sipa> which i certainly encourage
143 2012-10-07 15:06:30 <gmaxwell> It's self limiting. ... and if it turns out to be a bad decision it's always much easier to _add_ functionality than remove it, as removing it will break working things.
144 2012-10-07 15:09:14 <Eliel_> well, the filter feature will likely end up optimized through an address/script hash -> txid map structure, so I guess a more limited direct query is not necessary.
145 2012-10-07 15:38:01 <jgarzik> amiller: pushed out some DHT fixes to pybond.git
146 2012-10-07 15:38:06 <jgarzik> *poof*
147 2012-10-07 15:38:49 <sipa> jgarzik: there you go; ultraprune branch updated with gettxout and gettxoutsetinfo RPCs
148 2012-10-07 15:45:05 <MC1984> sipa any new builds of your ultraprune stuff recently?
149 2012-10-07 15:50:18 <sipa> i can do a new one if you like
150 2012-10-07 15:50:45 <sipa> there shouldn't be any spectacular improvements lately, but maybe improved stability
151 2012-10-07 16:54:13 <StupadFaktard> 
ACTION thinks the time has come to ban Luke-jr.

152 2012-10-07 16:56:34 <BlueMattBot> Yippie, build fixed!
153 2012-10-07 17:01:29 <StupadFaktard> Can someone send me a bitcoin?
154 2012-10-07 17:02:55 <StupadFaktard> send me bitcoins
155 2012-10-07 17:02:56 <StupadFaktard> 1HjECoF8r6QKCvZD6gmLbLpWx4rKbCQXME
156 2012-10-07 17:02:57 <StupadFaktard> 1HjECoF8r6QKCvZD6gmLbLpWx4rKbCQXME
157 2012-10-07 17:02:58 <StupadFaktard> 1HjECoF8r6QKCvZD6gmLbLpWx4rKbCQXME
158 2012-10-07 17:02:59 <StupadFaktard> 1HjECoF8r6QKCvZD6gmLbLpWx4rKbCQXME
159 2012-10-07 17:03:00 <StupadFaktard> 1HjECoF8r6QKCvZD6gmLbLpWx4rKbCQXME
160 2012-10-07 17:03:01 <StupadFaktard> 1HjECoF8r6QKCvZD6gmLbLpWx4rKbCQXME
161 2012-10-07 17:03:02 <StupadFaktard> 1HjECoF8r6QKCvZD6gmLbLpWx4rKbCQXME
162 2012-10-07 17:03:06 <StupadFaktard> please send me bitcoins
163 2012-10-07 17:03:07 <StupadFaktard> 1HjECoF8r6QKCvZD6gmLbLpWx4rKbCQXME
164 2012-10-07 17:03:11 <lianj> 3.. 2... 1..
165 2012-10-07 17:03:41 <StupadFaktard> Everyone should send bitcoins to:
166 2012-10-07 17:03:42 <StupadFaktard> Everyone should send bitcoins to:
167 2012-10-07 17:03:43 <StupadFaktard> Everyone should send bitcoins to:
168 2012-10-07 17:03:44 <StupadFaktard> Everyone should send bitcoins to:
169 2012-10-07 17:03:45 <StupadFaktard> 1HjECoF8r6QKCvZD6gmLbLpWx4rKbCQXME
170 2012-10-07 17:03:46 <StupadFaktard> Everyone should send bitcoins to:
171 2012-10-07 17:04:00 <StupadFaktard> Everyone should send bitcoins to:
172 2012-10-07 17:04:01 <StupadFaktard> Everyone should send bitcoins to:
173 2012-10-07 17:11:05 <Joric> $11.7 shit
174 2012-10-07 17:12:05 <Joric> oh i'm sorry wrong channel it was so messy i confused it with bitcoin-otc
175 2012-10-07 17:25:49 <Diapolo> After reading a comment on a pull from gmaxwell, who pointed me to this site: http://luke.dashjr.org/programs/bitcoin/files/charts/ I'm asking myself, what needs to happen to send an Alert to users to upgrade. Are the vulnerabilities no severe enough to do so? Seems many did not yet update.
176 2012-10-07 17:27:27 <Luke-Jr> Diapolo: the more recent vulns aren't a huge deal; you'll note the big-deal vulns are mostly upgraded
177 2012-10-07 17:27:32 <Luke-Jr> and alerts went out for those
178 2012-10-07 17:28:44 <Diapolo> that is fine, I just noticed your nice graphs :)
179 2012-10-07 17:28:49 <Diapolo> and wanted to ask
180 2012-10-07 18:29:46 <sipa> the number of IPv6 nodes seems steadily rising; my crawler has already found 189, of which around 70 are currently or very recently reachable
181 2012-10-07 20:00:19 <xisalty> http://www.kclug.org/wiki/images/Luke_Jr0.jpg < ?
182 2012-10-07 20:00:28 <xisalty> https://bitcointalk.org/index.php?topic=117068.0
183 2012-10-07 20:01:56 <edcba> he looks a bit stoned...
184 2012-10-07 20:02:52 <Diablo-D3> lol
185 2012-10-07 20:03:09 <gmaxwell> xisalty: Whats that have to do with #bitcoin-dev?
186 2012-10-07 20:03:27 <edcba> i guess Luke-Jr
187 2012-10-07 20:03:32 <xisalty> he is a developer of bitcoin ?
188 2012-10-07 20:04:22 <edcba> he is in the chan now of course that doesn't mean you should post anything relating to anyone in this chan :)
189 2012-10-07 20:13:21 <Luke-Jr> it's interesting how people think pictures are big secrets
190 2012-10-07 20:15:14 <edcba> this one should :)
191 2012-10-07 20:26:37 <B0g4r7> Does look a little blazed...or sleepless.
192 2012-10-07 20:28:14 <edcba> yeah just bad timing
193 2012-10-07 20:28:35 <edcba> lugs don't do drugs
194 2012-10-07 22:03:22 <Diablo-D3> http://imgur.com/gallery/jdKRy
195 2012-10-07 22:12:23 <jaxtr> crystal octogon
196 2012-10-07 22:41:15 <Diablo-D3> gmaxwell: ever have code that you know should work perfectly because you've written code like it thousands of times, yet its not right?
197 2012-10-07 22:47:30 <Joric> like, when you think you know how compiler works but you really don't?
198 2012-10-07 22:49:17 <Diablo-D3> well, get this
199 2012-10-07 22:49:25 <Diablo-D3> /home/diablo/Workspace/libugh/src/libugh/concurrent/mutex.h|135 col 16 error| cannot initialize a variable of type 'lugh_mutex_t *' (aka 'pthread_mutex_t *') with an rvalue of type 'void *'
200 2012-10-07 22:49:35 <Diablo-D3> \tlugh_mutex_t *mutex = malloc(sizeof(lugh_mutex_t));
201 2012-10-07 22:49:41 <Diablo-D3> thats line 135.
202 2012-10-07 22:51:39 <Arnavion> What was the rule about autocasting void* to T* again?
203 2012-10-07 22:51:58 <Diablo-D3> Arnavion: how the hell else would you use malloc?
204 2012-10-07 22:52:04 <Diablo-D3> I can see casting from non-mallocs, but wtf
205 2012-10-07 22:53:40 <Arnavion> Ah yes, it's only automatic in C
206 2012-10-07 22:53:42 <Arnavion> Not in C++
207 2012-10-07 22:53:48 <Arnavion> So C++ needs a cast
208 2012-10-07 22:53:56 <Diablo-D3> this isnt c++ though
209 2012-10-07 22:54:01 <Diablo-D3> ....
210 2012-10-07 22:54:11 <Diablo-D3> goddamnit
211 2012-10-07 22:54:32 <Diablo-D3> why does vim think .h is filetype cpp
212 2012-10-07 22:58:03 <gmaxwell> 17:47 < Joric> like, when you think you know how compiler works but you really don't?
213 2012-10-07 22:58:06 <gmaxwell> 17:47 < Joric> like, when you think you know how compiler works but you really don't?
214 2012-10-07 22:58:21 <gmaxwell> thats happened to me in the past, but after a few couple times I went and carefully read the spec.
215 2012-10-07 22:58:51 <gmaxwell> Mostly I just assume that I'm stupid and know nothing; I'm seldom disappointed.
216 2012-10-07 23:00:01 <gmaxwell> Diablo-D3: you have to cast it; on some arches not all pointers are compatible because of segment or alignment requirements.
217 2012-10-07 23:00:20 <Diablo-D3> gmaxwell: its a malloc!
218 2012-10-07 23:01:30 <Diablo-D3> whats screwed up is this is only popping up if I load the header in vim by itself
219 2012-10-07 23:01:38 <Diablo-D3> if its included by a C file, it doesnt do it
220 2012-10-07 23:01:43 <Diablo-D3> and if I actually build it, it doesnt do it
221 2012-10-07 23:02:08 <Arnavion> Your vim gives you compile errors?
222 2012-10-07 23:02:13 <Diablo-D3> yeah
223 2012-10-07 23:02:16 <Arnavion> ???_???
224 2012-10-07 23:02:19 <Diablo-D3> syntastic + clang_complete
225 2012-10-07 23:03:49 <gmaxwell> Diablo-D3: yes, a void * returned my malloc is safe for all the primitive types at least, but there aren't seperate kinds of void * for "safe to coerce silently" thus the cast.
226 2012-10-07 23:04:06 <gmaxwell> Diablo-D3: go code for a bit on arm and you'll be thankful for the behavior.
227 2012-10-07 23:04:57 <Diablo-D3> gmaxwell: okay so
228 2012-10-07 23:05:03 <Diablo-D3> why does that trigger it and NOTHING ELSE
229 2012-10-07 23:05:36 <Diablo-D3> Arnavion: and yes, I realize syntastic and clang_complete's quickfix window functionality overlaps
230 2012-10-07 23:05:47 <Diablo-D3> but gcc and clang give different shit sometimes
231 2012-10-07 23:05:50 <Diablo-D3> its worth having both
232 2012-10-07 23:06:12 <Arnavion> I use clang myself
233 2012-10-07 23:07:39 <Diablo-D3> its not about like
234 2012-10-07 23:07:45 <Diablo-D3> its about maximum bullshit coverage
235 2012-10-07 23:08:06 <Diablo-D3> Arnavion: https://github.com/Diablo-D3/dot_vim
236 2012-10-07 23:12:31 <Joric> Diablo-D3, what ide are you using btw?
237 2012-10-07 23:12:57 <Joric> i can't decide between vc2008 and vs2010
238 2012-10-07 23:18:20 <Diablo-D3> vim!
239 2012-10-07 23:18:34 <Diablo-D3> you goddamned jackass
240 2012-10-07 23:19:04 <pjorrit> 
ACTION snickers

241 2012-10-07 23:21:23 <Joric> Diablo-D3, hows your business on glbse?
242 2012-10-07 23:22:25 <Diablo-D3> 
ACTION smacks Joric 

243 2012-10-07 23:27:41 <Diablo-D3> gmaxwell: okay, I still dont understand what you meant
244 2012-10-07 23:27:58 <Diablo-D3> gmaxwell: I malloc something, why should I give a shit about address space bullshit