1 2012-01-06 00:00:54 <luke-jr> gavinandresen: what pragma?
  2 2012-01-06 00:01:21 <luke-jr> a lot are probably available as __attribute__
  3 2012-01-06 00:01:51 <gavinandresen> #pragma GCC diagnostic ignored
  4 2012-01-06 00:02:17 <gavinandresen> ... an assert() that will get optimized out is an easier workaround.  What is __attribute__ ?
  5 2012-01-06 00:02:42 <luke-jr> http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html
  6 2012-01-06 00:03:02 <luke-jr> I especially like __attribute__ ((deprecated)) :P
  7 2012-01-06 00:03:24 <gmaxwell> the pragma diagnostic stuff is really only usable in 4.6+ IIRC.
  8 2012-01-06 00:04:19 <gmaxwell> Raccoon: if you could prove that it couldn't produce all of them, you would have proven a weakness in the hashing algorithim.
  9 2012-01-06 00:04:54 <Raccoon> gmaxwell: so how many do you say is all-of-the
 10 2012-01-06 00:04:56 <Raccoon> the
 11 2012-01-06 00:05:07 <Raccoon> there's an "m" on my keyboard somewhere
 12 2012-01-06 00:05:09 <luke-jr> &
 13 2012-01-06 00:05:10 <gmaxwell> Raccoon: 'all of them' would be the complete space of addresses, 2^160.
 14 2012-01-06 00:06:27 <gavinandresen> luke-jr: I'd like to avoid compiler-specific extensions if possible, and I hate #ifdefs.
 15 2012-01-06 00:06:33 <BlueMatt> gmaxwell: when you figure the inputs of the hash algorithms are of fixed-size...
 16 2012-01-06 00:06:48 <gmaxwell> BlueMatt: yes, bigger than the outputs though...
 17 2012-01-06 00:06:58 <gmaxwell> The number of actually possible valid addresses is _probably_ smaller due to internal collisions in the hash but thats not proven.
 18 2012-01-06 00:07:00 <BlueMatt> gmaxwell: probabilistically, you cant generate all the hash space of addresses
 19 2012-01-06 00:12:22 <sipa> BlueMatt: last time i looked, keepnode was quite a bit of code, no?
 20 2012-01-06 00:12:51 <sipa> i don't mind replacing addnode if it doesn't add too much complexity
 21 2012-01-06 00:13:28 <sipa> luke-jr: i don't consider keepnode replacind addnode a bugfix, it changes well defined behaviour
 22 2012-01-06 00:14:04 <BlueMatt> sipa: https://github.com/bitcoin/bitcoin/pull/454
 23 2012-01-06 00:14:34 <BlueMatt> sipa: also, you missed the complaints period...
 24 2012-01-06 00:15:17 <gmaxwell> hah
 25 2012-01-06 00:19:03 <BlueMatt> sipa: do you feel strongly enough that I should change it...
 26 2012-01-06 00:19:58 <gmaxwell> I think he's saying it shouldn't be backported.
 27 2012-01-06 00:20:19 <BlueMatt> well that I agree with
 28 2012-01-06 00:20:31 <gmaxwell> Which was what I said too, though more weakly.
 29 2012-01-06 00:20:52 <BlueMatt> ok, so replace addnode but dont backport, sounds good to me
 30 2012-01-06 00:21:26 <luke-jr> whatever :p
 31 2012-01-06 00:22:24 <Raccoon> gmaxwell: what's the math on how many bitcoin addresses would have to be assigned (ever) before a collision could be intentionally made in N amount of time/hashrate
 32 2012-01-06 00:22:30 <Raccoon> la birthday attack
 33 2012-01-06 00:23:28 <BlueMatt> Raccoon: a lot...
 34 2012-01-06 00:25:15 <lianj> 2**160 ?
 35 2012-01-06 00:25:30 <gmaxwell> Raccoon: see wikipedia. The number of 'days' is 2^160.  Or skip the math In a space of N if you have sqrt(N) random elements, you have a 50% chance of a random collision between some pair.
 36 2012-01-06 00:25:53 <Raccoon> BlueMatt: even with known entropy of early and existing client pseudo random generators/
 37 2012-01-06 00:26:59 <gmaxwell> Raccoon: no such thing.
 38 2012-01-06 00:27:40 <gmaxwell> bitcoin has a strong random pool. It takes data from a number of sources that contain actual randomness.
 39 2012-01-06 00:29:48 <Raccoon> so 2^80 keys generated TOTAL (between bitcoin transactions + attack generated keys) before a 50% likliness of collision
 40 2012-01-06 00:30:10 <Raccoon> gmaxwell: even the early windows clients?
 41 2012-01-06 00:30:25 <gmaxwell> Yes. And in that case your collission might just be two attack keys.
 42 2012-01-06 00:30:41 <Raccoon> right
 43 2012-01-06 00:31:09 <Raccoon> but from then on, every-other key generated will expect a collision
 44 2012-01-06 00:32:05 <Raccoon> how far in before 1 in 100 keys expect a collision, or 1 in 1 million
 45 2012-01-06 00:32:33 <gmaxwell> Do I look like wolfram alpha? Go use the formulas from wikipedia.
 46 2012-01-06 00:32:43 <gmaxwell> :)
 47 2012-01-06 00:32:44 <Raccoon> since you should be able to easily hash a million keys per second?
 48 2012-01-06 00:33:05 <gmaxwell> Sures, thats not very fast.
 49 2012-01-06 00:33:10 <Raccoon> i'm curious why only 2^160 was chosen
 50 2012-01-06 00:33:50 <Raccoon> how many keys per second should a souped up machine expect?
 51 2012-01-06 00:33:55 <gmaxwell> ? 1e6*86400*365./2^160.
 52 2012-01-06 00:33:56 <gmaxwell> %1 = 2.1577806821751675365552117255190817928 E-35
 53 2012-01-06 00:34:07 <lianj> how you mean 'chosen'?
 54 2012-01-06 00:34:26 <Raccoon> chosen in design
 55 2012-01-06 00:34:28 <gmaxwell> Raccoon: to keep addresses managably small while allowing for a check value to protect against errors.
 56 2012-01-06 00:34:41 <lianj> Raccoon: so why ripemd-160 was chosen?
 57 2012-01-06 00:35:00 <Raccoon> sure, why ripemd-160 instead of 256 or 1024
 58 2012-01-06 00:35:23 <gmaxwell> Raccoon: good luck transmitting a 1024 bit address to anyone.
 59 2012-01-06 00:35:29 <lianj> hehe
 60 2012-01-06 00:35:40 <gmaxwell> You couldn't even share them on irc without running into the maximum message lenghts all the time.
 61 2012-01-06 00:35:42 <Raccoon> digital currency is done digitally
 62 2012-01-06 00:35:52 <Raccoon> gmaxwell: sure you could. easily
 63 2012-01-06 00:35:56 <gmaxwell> Raccoon: also, I think you're not thinking rationally about the numbers.
 64 2012-01-06 00:36:44 <gmaxwell> It's generally accepted that e.g. 128 bit complexity is secure against all brute force attacks on classical computers based on a simple physical argument:
 65 2012-01-06 00:36:50 <lianj> gmaxwell: irc has a line limit of less than 128 chars?
 66 2012-01-06 00:37:00 <Raccoon> 1024/6 = 171 chrs, 1024/7 = 147 chrs
 67 2012-01-06 00:37:15 <gmaxwell> 512 IIRC
 68 2012-01-06 00:37:23 <Raccoon> IRC has a length limit of 512 including nick/addr.  so 450 reasonably
 69 2012-01-06 00:37:52 <lianj> yea, so they all would fit on irc. but true, that wasnt the point though
 70 2012-01-06 00:38:06 <Raccoon> <gmaxwell> It's generally accepted that e.g. 128 bit complexity is secure against all brute force attacks on classical computers based on a simple physical argument:
 71 2012-01-06 00:38:15 <Raccoon> gmaxwell: that's with a target of ONE (1)
 72 2012-01-06 00:38:16 <gmaxwell> To increment a optimally (physical limit) efficiency counter on a non-reversable classical computer from 0-2^128-1 requires something like 240 MT of TNT worth of energy, and thats not even doing any useful computation like generating addresses, storing them, and looking them up.
 73 2012-01-06 00:38:20 <Raccoon> not a birthday attack
 74 2012-01-06 00:38:49 <gmaxwell> Raccoon: yes, but it would apply to a birthday attack of 128 bit complexity, and of course thats all ignoring the enormous storage costs.
 75 2012-01-06 00:38:53 <BlueMatt> Raccoon: but generating addresses slows down very quickly when you have to check each one against 1 million others
 76 2012-01-06 00:39:12 <Raccoon> gmaxwell: storage is cheap :p
 77 2012-01-06 00:39:19 <BlueMatt> not that cheap
 78 2012-01-06 00:39:24 <BlueMatt> nor that fast
 79 2012-01-06 00:39:29 <Raccoon> you wouldn't store the attack addresses either
 80 2012-01-06 00:39:38 <Raccoon> beyond a buffer que
 81 2012-01-06 00:39:45 <ryannathans> whats this about?
 82 2012-01-06 00:40:30 <Raccoon> so how many addresses can be generated per second?
 83 2012-01-06 00:40:34 <gmaxwell> It's OT gibberish.
 84 2012-01-06 00:40:56 <Raccoon> 2^30 per second?
 85 2012-01-06 00:41:02 <BlueMatt> not nearly that
 86 2012-01-06 00:41:10 <gmaxwell> Generated by _what_?
 87 2012-01-06 00:41:15 <BlueMatt> especially not if you are checking each against 100 million other addresses
 88 2012-01-06 00:41:33 <Raccoon> just saying generated
 89 2012-01-06 00:41:34 <gmaxwell> You were talking a million before, now a billion?
 90 2012-01-06 00:41:42 <Raccoon> lookup is easy with a hash/rainbow table
 91 2012-01-06 00:41:52 <gmaxwell> No, it really isn't.
 92 2012-01-06 00:42:03 <Raccoon> you convert the bitcoin block history into a binary tree
 93 2012-01-06 00:42:20 <BlueMatt> of huge size
 94 2012-01-06 00:42:24 <Raccoon> so
 95 2012-01-06 00:42:26 <gmaxwell> Why are you talking about bitcoin?
 96 2012-01-06 00:42:36 <gmaxwell> You were just talking about attacking a set of 2^80 addresses.
 97 2012-01-06 00:42:38 <Raccoon> we have huge mining groups
 98 2012-01-06 00:43:03 <Raccoon> gmaxwell: how many bitcoin addresses have ever been generated to date?
 99 2012-01-06 00:43:23 <Raccoon> with money put on them
100 2012-01-06 00:43:43 <tcatm> IIRC around 700k
101 2012-01-06 00:43:47 <Raccoon> so *circulated to date
102 2012-01-06 00:43:50 <ryannathans> at any time or still on them
103 2012-01-06 00:43:55 <tcatm> with about 160k unique identities
104 2012-01-06 00:44:31 <Raccoon> so about 2^20 addresses circulated?
105 2012-01-06 00:45:14 <ryannathans> currently i dont see anything wrong with our current 'address' system, however, i do see a nessasary change down the road as technology advances and more people start taking up bitcoin and the use of digital currencies
106 2012-01-06 00:45:21 <Raccoon> what's the math if 2^80 means 50% chance of collision PER new address generated, if 2^20
107 2012-01-06 00:45:47 <Raccoon> 50/60 ?
108 2012-01-06 00:45:50 <gmaxwell> ryannathans: the system already accomidate it.
109 2012-01-06 00:46:14 <ryannathans> gmaxwell: whats the next adress system planned?
110 2012-01-06 00:46:17 <gmaxwell> ryannathans: you'd obviously have to update client to generate and accept the new addresses, but the system will process them.
111 2012-01-06 00:46:26 <ryannathans> yup im aware
112 2012-01-06 00:46:36 <gmaxwell> ryannathans: it's not, because credible people don't share your concern right now.
113 2012-01-06 00:47:10 <gmaxwell> Raccoon: please stop wasting my time if you won't even go pull the formulas from wikipedia.
114 2012-01-06 00:47:32 <Raccoon> gmaxwell: wikipedia doesnt mention applied math toward these conclusions
115 2012-01-06 00:47:41 <gmaxwell> (or can't bother to calculate log2() on your own)
116 2012-01-06 00:47:55 <ryannathans> so credible people are not concerned they will ever need to change the address hash regardless of how technology advances or how many people use bitcoin
117 2012-01-06 00:47:56 <gmaxwell> http://en.wikipedia.org/wiki/Birthday_problem#Calculating_the_probability
118 2012-01-06 00:48:15 <Raccoon> but if 2^80 addresses were in circulation, there would be a 50% chance any new address created would cause a collision.
119 2012-01-06 00:48:19 <cyphur> sheez I goto sleep for 6 hours and the price jumps a dollar
120 2012-01-06 00:48:22 <ryannathans> it's not an issue now and im aware of that, one day there will need to be a change
121 2012-01-06 00:48:26 <gmaxwell> ryannathans: no, the system is designed to accomidate upgrades. (and e.g. inclues a 256 bit hash OP_CODE)
122 2012-01-06 00:48:26 <Raccoon> 2^79 addresses were in circulation, there would be a 25% chance any new address created would cause a collision.
123 2012-01-06 00:48:40 <Raccoon> 2^78 addresses were in circulation, there would be a 12.5% chance any new address created would cause a collision.
124 2012-01-06 00:48:42 <gmaxwell> ryannathans: but you can't plan for a change when there _currently_ is no reason for one.
125 2012-01-06 00:48:55 <ryannathans> gmaxwell: yeah, is kinda what im saying
126 2012-01-06 00:48:57 <Raccoon> 2^20 addresses were in circulation, there would be a 0.833333% chance any new address created would cause a collision.
127 2012-01-06 00:49:12 <Raccoon> so about 1 in 100 new addresses creates a collision
128 2012-01-06 00:49:15 <gmaxwell> nah, you're off in space.
129 2012-01-06 00:49:22 <gmaxwell> I'm ignoring you now.
130 2012-01-06 00:49:23 <ryannathans> mmm space
131 2012-01-06 00:49:56 <Raccoon> gmaxwell: i'm pretty sure that at least 20 people in this channel share the same birthdate.
132 2012-01-06 00:49:57 <cyphur> hey guys
133 2012-01-06 00:50:06 <cyphur> whats volatility been like for the last few hours?
134 2012-01-06 00:50:22 <ryannathans> orgasmic
135 2012-01-06 00:50:29 <gmaxwell> Raccoon: I have no clue what you're calculating, but I'm sure its not what you think you're calculating. :)
136 2012-01-06 00:50:31 <nanotube> cyphur: check bitcoincharts.com
137 2012-01-06 00:50:43 <ryannathans> i"m off, got a plane to get ready for
138 2012-01-06 00:50:45 <cyphur> yeah Im looking at it
139 2012-01-06 00:50:51 <gmaxwell> Raccoon: I think you're confusing the count of people vs count of days.
140 2012-01-06 00:50:57 <Raccoon> gmaxwell: I'm sure I'm calculating the weakness of bitcoin address space
141 2012-01-06 00:51:05 <gmaxwell> Raccoon: you're failing to do so.
142 2012-01-06 00:51:18 <Raccoon> i'm sure i'm not
143 2012-01-06 00:51:20 <nanotube> Raccoon: look up the birthday paradox math
144 2012-01-06 00:51:31 <Raccoon> nanotube: no need to
145 2012-01-06 00:51:34 <BlueMatt> cyphur: thats fairly ot, maybe ask on #bitcoin-otc ?
146 2012-01-06 00:51:34 <cyphur> someones peoples comments are interesting as well though
147 2012-01-06 00:51:35 <nanotube> k
148 2012-01-06 00:56:46 <Raccoon> i still think my math looks good, unfortunately
149 2012-01-06 00:56:57 <gmaxwell> Raccoon: what you're actually asking isn't a 'birthday paradox' question, e.g. you have 2^20 in a space of 2^160. What is the chance that adding one more collides? It's 2^20/2^160 since the selection is uniform or 7.17e-43.
150 2012-01-06 00:58:21 <gmaxwell> Intutively stated you have 2^160 possible values, and 2^20 are 'bad'. The odds of getting a bad one with one selection is just the portion of the bad in the space.
151 2012-01-06 00:58:58 <cyphur> oh sheez I only just realised I was typing in bitcoin-dev
152 2012-01-06 00:59:01 <cyphur> sorry about that guys :)
153 2012-01-06 00:59:29 <BlueMatt> cyphur: np
154 2012-01-06 00:59:44 <gmaxwell> Raccoon: and this really should move into #bitcoin, it's not development related.
155 2012-01-06 00:59:51 <gmaxwell> I'll respond to you there if you show up there.
156 2012-01-06 01:00:29 <Raccoon> what if i wanted to develop efficient attack code
157 2012-01-06 01:01:04 <gmaxwell> Raccoon: if you're so convinced you can do this, there are 400k bitcoins waiting for you on some mtgox address. have fun.
158 2012-01-06 01:01:50 <Raccoon> btw, what is 7.17e-43 in base 2?
159 2012-01-06 01:02:24 <gmaxwell> ??
160 2012-01-06 01:02:45 <Raccoon> 2^??
161 2012-01-06 01:02:59 <BlueMatt> 2^pi
162 2012-01-06 01:03:18 <gmaxwell> Raccoon: 2^-140 or so.
163 2012-01-06 01:04:01 <gmaxwell> (well not 'or so')
164 2012-01-06 01:05:05 <Raccoon> so you're saying odds of hitting a 'bad' value are 2^(space-bad) %?
165 2012-01-06 01:05:12 <Raccoon> er
166 2012-01-06 01:05:15 <Raccoon> 1 in
167 2012-01-06 01:05:28 <Raccoon> that just seems unreasonable
168 2012-01-06 01:05:53 <roconnor> Raccoon: with 2^20 addresses in circulate each new address has a 0.00000000000000009% of colliding.
169 2012-01-06 01:06:07 <roconnor> er
170 2012-01-06 01:06:08 <roconnor> wait
171 2012-01-06 01:06:13 <roconnor> even that isn't true
172 2012-01-06 01:08:57 <roconnor> more like 0.00000000000000000000000000000000000000007%
173 2012-01-06 01:13:56 <gmaxwell> roconnor: right. 43 of dem there zeerros.
174 2012-01-06 01:14:26 <roconnor> Raccoon: stick to playing the lottery
175 2012-01-06 01:14:37 <gmaxwell> heh
176 2012-01-06 01:15:09 <gmaxwell> Raccoon: thats why I've been so dismissive. The actual figures are mindbogglingly tiny.
177 2012-01-06 01:15:47 <lianj> "i won the address collision lottery and all i got was a 0.00001 btc address"
178 2012-01-06 01:16:00 <gmaxwell> hah
179 2012-01-06 01:16:17 <gmaxwell> I wish it were easier, I could have better vanity addresses!
180 2012-01-06 01:17:27 <k9quaint> how can something so tiny boggle something so large as your mind?
181 2012-01-06 01:18:03 <gmaxwell> k9quaint: does it help the its reciprocal is enormous?
182 2012-01-06 01:18:43 <k9quaint> so if I stand on my head it will blow my mind
183 2012-01-06 01:21:04 <roconnor> gmaxwell: you can have DrGoss's address
184 2012-01-06 01:22:16 <gmaxwell> I have some okay ones, such as 1AGMAXWELLayCyS1vkLXEszESHEcB3LWqa
185 2012-01-06 02:18:31 <amiller> roconnor, are you working on a haskell bitcoin?
186 2012-01-06 02:27:18 <copumpkin> amiller: he is
187 2012-01-06 02:27:45 <amiller> i'm still searching for it and can't find any trail
188 2012-01-06 02:32:38 <MC1984> so the address space is like 2^160
189 2012-01-06 02:33:00 <MC1984> shouldnt someone write some shit about the number of atoms in the universe and get it over with
190 2012-01-06 02:33:10 <BlueMatt> heh
191 2012-01-06 02:35:17 <MC1984> remains to be seen how quantum computation changes things though
192 2012-01-06 02:35:31 <MC1984> i herd theyre good at factoring, whatever the hell that is
193 2012-01-06 02:40:38 <nanotube> herd factoring eh :)
194 2012-01-06 02:47:20 <gmaxwell> MC1984: it doesn't remain to be seen.
195 2012-01-06 02:48:01 <MC1984> care to expand on that
196 2012-01-06 02:48:08 <gmaxwell> MC1984: at best you get a general speedup of sqrt(n) on non-linear search. And thats a tight bound.
197 2012-01-06 02:48:13 <gmaxwell> MC1984: http://en.wikipedia.org/wiki/Grover%27s_algorithm
198 2012-01-06 02:48:14 <BlueMatt> when quantum computers with the ability to calculate on enough bits are created, bitcoin transactions are trivially stealable
199 2012-01-06 02:48:35 <MC1984> in english
200 2012-01-06 02:48:39 <gmaxwell> BlueMatt: if it's physically possible to construct QC's that large.
201 2012-01-06 02:48:46 <BlueMatt> exactly
202 2012-01-06 02:49:02 <gmaxwell> MC1984: hash functions lose half their bits of effective security, at worse, if you're able to build QC's that big.
203 2012-01-06 02:49:23 <MC1984> only half?
204 2012-01-06 02:49:30 <gmaxwell> MC1984: which is one of the motivations behind switching to hash's of double size in more recent years.
205 2012-01-06 02:49:32 <BlueMatt> gmaxwell: but ecdsa loses more iirc?
206 2012-01-06 02:49:41 <gmaxwell> Yes, ecdsa loses more.
207 2012-01-06 02:50:35 <gmaxwell> BlueMatt: oddly enough you can implement QC resistant signatures as a script if you're sufficiently crazy (well, the size limits might not allow it), and then pay to scripthash them.
208 2012-01-06 02:50:51 <BlueMatt> gmaxwell: thats true...
209 2012-01-06 02:51:08 <gmaxwell> (http://en.wikipedia.org/wiki/Lamport_signature)
210 2012-01-06 02:51:42 <MC1984> ok so ecdsa is pretty fucked
211 2012-01-06 02:51:46 <gmaxwell> MC1984: yea, only half. So 256 bit hashes become 128 bit ones.
212 2012-01-06 02:51:53 <gmaxwell> MC1984: well, no. Not quite.
213 2012-01-06 02:52:13 <MC1984> how many bits does bitcoin use
214 2012-01-06 02:52:47 <gmaxwell> MC1984: you still need to build a honking big QC machine. like 4kilobits to crack ecdsa with a few billion operations or something like that.
215 2012-01-06 02:52:53 <luke-jr> anyone know how to oprofile a specific thread?
216 2012-01-06 02:53:13 <gmaxwell> luke-jr: hm .. no.
217 2012-01-06 02:53:46 <gmaxwell> MC1984: if you google around there is a nice paper giving estimates of QC complexity for ecc cracking.
218 2012-01-06 02:54:16 <MC1984> ok
219 2012-01-06 02:54:38 <gmaxwell> It's enormous enough that we may eventually discover that its not possible to build quantum systems that big (because of noise breaking coherence)
220 2012-01-06 02:55:44 <gmaxwell> It's hard to even ask the question because we're so far away from it.. We can build systems with like 1 or 2 bits and do a couple operations. Nothing like the quantum Turing machine that exist in mathematicians dreams. :)
221 2012-01-06 02:56:29 <gmaxwell> also, if you use one shot addresses, your pubkey isn't exposed until right when you spend, which limits the attack exposure.
222 2012-01-06 02:59:51 <luke-jr> gmaxwell: please help :<
223 2012-01-06 02:59:55 <luke-jr> https://github.com/luke-jr/cgminer/commit/a8f742d58a445f3cd61b814489cbdd2d0602e56c
224 2012-01-06 03:00:05 <luke-jr> I can't figure out why, but this makes cgminer eat a lot of CPU time
225 2012-01-06 03:00:17 <luke-jr> profilers tell me it's in gpuminer_thread, but I barely touched it
226 2012-01-06 03:01:01 <MC1984> gmaxwell duly noted
227 2012-01-06 03:01:27 <gmaxwell> luke-jr: darn you, I'm watching a movie right now.
228 2012-01-06 03:01:35 <luke-jr> gmaxwell: LOL, while arguing
229 2012-01-06 03:02:16 <gmaxwell> had it on pause for a minute for drinks and such.
230 2012-01-06 03:58:45 <BlueMatt> did anyone else see the "Bitcoin - An Analysis" talk at 28c3?
231 2012-01-06 04:07:54 <plato> BlueMatt: nope, what's that?
232 2012-01-06 04:08:14 <BlueMatt> a poorly-researched analysis of bitcoin that was presented at the ccc
233 2012-01-06 04:09:48 <BlueMatt> quite a few things he did were smart and cool, but then he had quite a few arguments that had no arguments and were just false statements
234 2012-01-06 04:10:07 <BlueMatt> s/he/they/
235 2012-01-06 04:10:21 <TuxBlackEdo> BlueMatt, personally i think if you look like you are in your late 20s you shouldn't be balding
236 2012-01-06 04:10:24 <TuxBlackEdo> :)
237 2012-01-06 04:10:50 <BlueMatt> TuxBlackEdo: ?
238 2012-01-06 04:10:55 <BlueMatt> oh...
239 2012-01-06 04:11:05 <TuxBlackEdo> :D
240 2012-01-06 04:13:07 <BlueMatt> if you are going to do a presentation analyzing bitcoin, you should bother to see if anyone else has done previous research before you make false statements...
241 2012-01-06 04:13:14 <luke-jr> game over for Coiledcoin
242 2012-01-06 04:13:50 <BlueMatt> heh wtf makomk?>
243 2012-01-06 04:14:43 <luke-jr> that was fun
244 2012-01-06 04:17:01 <copumpkin> TuxBlackEdo: that seems like a completely irrelevant statement about the talk
245 2012-01-06 04:18:13 <TuxBlackEdo> yeah it's all i could think about -_-
246 2012-01-06 04:19:58 <gmaxwell> BlueMatt: need to have a panel at a bitcoin conference which reviews bitcoin talks elsewhere and where the participants talk about their favorite misinformation
247 2012-01-06 04:20:42 <BlueMatt> yea, though its just really sad when two professors come out with blatantly false information that they would know was false if they just used google...
248 2012-01-06 04:21:26 <diki> the bitcoin client's transaction details which are viewed by double-clicking on a transaction has a bug
249 2012-01-06 04:21:36 <diki> the field which displays the information is editable
250 2012-01-06 04:21:42 <BlueMatt> tell wumpus
251 2012-01-06 04:25:02 <wumpus> huh, sounds like a minor bug indeed, doesn't make sense to edit it though, changes won't propagate back to the transactions
252 2012-01-06 04:25:24 <luke-jr> wumpus: is "About Qt" a bugfix?
253 2012-01-06 04:26:36 <wumpus> dunno, it helps with diagnostics ("what version of qt did you build against")
254 2012-01-06 04:27:27 <luke-jr> wumpus: do you want it backported to 0.5.x?
255 2012-01-06 04:27:50 <wumpus> it can't hurt anything, a pure ui-feature.. so, yes
256 2012-01-06 04:28:24 <luke-jr> k
257 2012-01-06 04:28:28 <wumpus> it's completely outside bitcoin versioning I guess...
258 2012-01-06 04:29:50 <gmaxwell> BlueMatt: unfortunately new areas are fertile ground for people to spout nonsense, since there isn't an established community to call them out on it.
259 2012-01-06 04:29:55 <BlueMatt> wow they cant even google to find firstbits...
260 2012-01-06 04:30:09 <wumpus> diki: heh I just reproduced that, it's funny
261 2012-01-06 04:30:50 <luke-jr> BlueMatt: I found it via some Bitcoin promotion saying firstbits was going to  be in the next version
262 2012-01-06 04:30:54 <luke-jr> I'm like "wtf, never heard of"
263 2012-01-06 04:32:03 <BlueMatt> they clearly didnt ask anyone for input who knew something about bitcoin, they ask if firstbits is a DoS attack with no purpose...
264 2012-01-06 04:32:09 <gmaxwell> BlueMatt: whats this with firstbarf?
265 2012-01-06 04:32:15 <gmaxwell> oh hah they saw the firstbits transactions.
266 2012-01-06 04:32:41 <gmaxwell> Well, yea, they're pretty obnoxious, but geesh.
267 2012-01-06 04:33:03 <BlueMatt> ok, to be fair, firstbits IS a DoS attack, but seriously google to figure out whats going on...
268 2012-01-06 04:33:13 <wumpus> it's very hip to pretend that you found "vulnerabilities" in bitcoin, even if they were known for ages and don't really affect much...
269 2012-01-06 04:33:24 <gmaxwell> BlueMatt: It's not an intentional one at least.
270 2012-01-06 04:33:33 <BlueMatt> exactly
271 2012-01-06 04:34:19 <gmaxwell> wumpus: we have this problem with wikipedia. "researchers" who publish absolute gibberish.  E.g. they are constantly discovering that recently created articles have fallen enormously in quality an approiateness of subject matter.
272 2012-01-06 04:34:20 <BlueMatt> just to see how the "researchers" respond..
273 2012-01-06 04:34:28 <luke-jr> BlueMatt: I just 51%'d CoiledCoin FWIW
274 2012-01-06 04:34:42 <gmaxwell> "Yea, no shit. We delete or improve the crap but it takes time, so the most recent is always bad."
275 2012-01-06 04:34:51 <BlueMatt> luke-jr: heh...
276 2012-01-06 04:35:40 <BlueMatt> "even though the claim its anonymous" who the fuck who had any sanity claimed bitcoin is anonymous????
277 2012-01-06 04:35:47 <BlueMatt> s/the/they/
278 2012-01-06 04:35:48 <wumpus> gmaxwell: yes that's very typical, they just don't understand how the filter works and look at the unfiltered information
279 2012-01-06 04:36:47 <wumpus> BlueMatt: claiming "they" claim something isn't decent research anyway, it's more like gossip
280 2012-01-06 04:37:07 <gmaxwell> Weasel words.
281 2012-01-06 04:37:09 <BlueMatt> exactly
282 2012-01-06 04:37:11 <gmaxwell> Some people say.
283 2012-01-06 04:37:27 <gmaxwell> And indeed, some people say bitcoin is anonymous. We call these people idiots.
284 2012-01-06 04:37:28 <wumpus> yes, manipulative weasel words
285 2012-01-06 04:38:23 <gmaxwell> I'll give you an experiment. Join #bitcoin at a random time, and say "bitcoin is anonymous!" and count the seconds before people pile on explaining that its not.
286 2012-01-06 04:38:35 <wumpus> then again, it's good that people are attacking the bitcoin protocol from all directions, that's the only way to find real vulnerabilities... but please find real ones :-)
287 2012-01-06 04:38:57 <gmaxwell> wumpus: yea, but good work is hard.
288 2012-01-06 04:39:09 <gmaxwell> Vomiting up your initial impressions is easy.
289 2012-01-06 04:39:16 <gmaxwell> Good work has the risk of a null result.
290 2012-01-06 04:39:21 <nanotube> luke-jr: what's coiledcoin?
291 2012-01-06 04:39:26 <gmaxwell> Which no one wants to publish.
292 2012-01-06 04:39:27 <wumpus> agreed, it IS very hard
293 2012-01-06 04:39:30 <BlueMatt> NO CHEATING
294 2012-01-06 04:39:36 <doublec> nanotube: https://bitcointalk.org/index.php?topic=56675.0
295 2012-01-06 04:39:51 <doublec> nanotube: luke-jr merge mined it and attacked it
296 2012-01-06 04:40:08 <doublec> luke-jr: so are you going to do the same with the other alt coins?
297 2012-01-06 04:40:09 <gmaxwell> asymmetric difficulty. fail power.
298 2012-01-06 04:40:15 <luke-jr> doublec: undecided.
299 2012-01-06 04:40:24 <luke-jr> doublec: let's see how this goes
300 2012-01-06 04:41:37 <gmaxwell> oh it's not asym. it's factor of two clamped. Actually thats pretty good considering the reduced time.
301 2012-01-06 04:42:41 <luke-jr> doublec: tbh, if I realized makomk was behind CoiledCoin, I'd have talked to him about it first
302 2012-01-06 04:42:46 <luke-jr> but I didn't really look at the names
303 2012-01-06 04:43:43 <gmaxwell> Pretty good trial by fire there.
304 2012-01-06 04:44:00 <gmaxwell> wtf it had btc-e support already?
305 2012-01-06 04:44:10 <luke-jr> yeah
306 2012-01-06 04:44:11 <gmaxwell> That really does make it sound like a scam.
307 2012-01-06 04:44:15 <diki> got some cash off of it
308 2012-01-06 04:45:08 <nanotube> luke-jr: haha nice
309 2012-01-06 04:45:28 <nanotube> gmaxwell: in the thread, mako says he was as surprised as anyone that btc-e added support for it so soon
310 2012-01-06 04:45:58 <wumpus> it's probably very easy for them to support additional chains
311 2012-01-06 04:46:00 <gmaxwell> yea, kinda interesting when you have decenteralized scamming.
312 2012-01-06 04:46:22 <gmaxwell> e.g. where you get a system that is a scam, but with all of the agents operating independantly and mostly honestly.
313 2012-01-06 04:46:25 <wumpus> more trade is better if you are an exchange, so quickly adding new hot chains somehow is rational
314 2012-01-06 04:47:07 <wumpus> heh
315 2012-01-06 04:47:14 <gmaxwell> that chat thing on btc-e is kinda embarassing.
316 2012-01-06 04:47:37 <gmaxwell> (I don't mean right now, but in general it's like listening to an xbox video game most of the time)
317 2012-01-06 04:47:48 <wumpus> yes a casino chat
318 2012-01-06 04:51:25 <luke-jr> I think BTC-E disabled CLC deposits
319 2012-01-06 04:52:38 <gmaxwell> The exchange price graph there is kinda funny.
320 2012-01-06 04:52:53 <gmaxwell> "whoppie, new cryptocoin.. ohh.. pooft"
321 2012-01-06 04:53:59 <BlueMatt> luke-jr: your gitian script is fucked up
322 2012-01-06 04:54:01 <BlueMatt> "error: 503 while accessing https://git.gitorious.org/+bitcoin-stable-developers/bitcoin/bitcoind-stable.git/info/refs"
323 2012-01-06 04:54:18 <luke-jr> BlueMatt: I haven't changed it O.o
324 2012-01-06 04:54:26 <BlueMatt> have you ever tested it?
325 2012-01-06 04:54:32 <luke-jr> I can't  use gitian
326 2012-01-06 04:54:41 <BlueMatt> ok, so its always had a bad url...
327 2012-01-06 04:56:20 <luke-jr> BlueMatt: didn't you build it before?
328 2012-01-06 04:56:25 <luke-jr> also, that URL responds to me
329 2012-01-06 04:56:33 <BlueMatt> no
330 2012-01-06 04:56:36 <BlueMatt> is it a private url?
331 2012-01-06 04:56:40 <luke-jr> no
332 2012-01-06 04:56:42 <luke-jr> 200 OK
333 2012-01-06 04:59:28 <wumpus> diki: https://github.com/bitcoin/bitcoin/pull/746
334 2012-01-06 05:00:40 <gribble> New news from bitcoinrss: laanwj opened pull request 746 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/746>
335 2012-01-06 05:20:23 <BlueMatt> luke-jr: hmm, nfc why I got a 503, maybe gitorious was overloaded...anyway it appears to be working now
336 2012-01-06 05:20:35 <luke-jr> >_<
337 2012-01-06 05:49:10 <BlueMatt> luke-jr: linux build http://dl.dropbox.com/u/29653426/bitcoin-0.5.2rc1.tar.bz2
338 2012-01-06 05:50:10 <BlueMatt> (gitian signed)
339 2012-01-06 05:50:23 <BlueMatt> (and yes you can verify it without gitian...)
340 2012-01-06 06:23:52 <justmoon> looking for clean-looking example bitcoin 0.5.1 or later screenshot (any os)
341 2012-01-06 06:24:57 <BlueMatt> whats the difference between 0.5.1 and 0.5?
342 2012-01-06 06:25:11 <justmoon> 0.5 is fine too
343 2012-01-06 06:25:25 <justmoon> i used 0.5.1 as in "current release or later"
344 2012-01-06 06:29:19 <justmoon> anyone?
345 2012-01-06 06:29:22 <justmoon> 1 BTC bounty
346 2012-01-06 06:30:01 <luke-jr> justmoon: O.o
347 2012-01-06 06:30:05 <justmoon> (can't take one myself because I run xface on cygwin-x, so mine is a weird windows/linux hybrid)
348 2012-01-06 06:30:14 <luke-jr> oh, fullscreen?
349 2012-01-06 06:30:16 <luke-jr> not just the window?
350 2012-01-06 06:30:20 <justmoon> just the window
351 2012-01-06 06:30:38 <justmoon> but with window decoration if poss.
352 2012-01-06 06:30:42 <Diablo-D3> well
353 2012-01-06 06:30:49 <Diablo-D3> who uses windows lawlz
354 2012-01-06 06:33:02 <BlueMatt> justmoon: http://i39.tinypic.com/2hye1zq.jpg
355 2012-01-06 06:33:18 <justmoon> BlueMatt: great, thx
356 2012-01-06 06:33:21 <justmoon> BlueMatt: address?
357 2012-01-06 06:34:07 <BlueMatt> justmoon: Ill trade you, ack https://github.com/bitcoin/bitcoin/pull/593 (or be lazy and send it to 1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c )
358 2012-01-06 06:34:28 <BlueMatt> (obv only ack after testing)
359 2012-01-06 06:35:16 <justmoon> BlueMatt: you mean test it on my cygwin setup? I wouldn't hold my breath lol :P
360 2012-01-06 06:35:41 <BlueMatt> justmoon: or build it on linux and test...
361 2012-01-06 06:36:35 <justmoon> alright, I'll give it a go
362 2012-01-06 06:37:15 <BlueMatt> luke-jr: second one http://dl.dropbox.com/u/29653426/bitcoin-0.5.2rc1-win32.tar.bz2
363 2012-01-06 06:37:22 <BlueMatt> (also signed)
364 2012-01-06 10:38:38 <Ukto> anyone familiar with the EXCEPTION: 11DbException, DbEnv::close: Invalid argument,  bitcoin in ProcessMessage() bug? whats causing it?
365 2012-01-06 11:36:02 <epscy> !ticker
366 2012-01-06 11:36:03 <gribble> Best bid: 6.92215, Best ask: 6.9302, Bid-ask spread: 0.00805, Last trade: 6.9303, 24 hour volume: 220833, 24 hour low: 6.06016, 24 hour high: 7.22
367 2012-01-06 11:42:03 <makomk> Well, I guess that's the end of Bitcoin clones then.
368 2012-01-06 11:48:10 <Ken`> @gold
369 2012-01-06 11:48:18 <Ken`> oops
370 2012-01-06 12:19:46 <UukGoblin> bitstamp is still reporting trade times in the future
371 2012-01-06 12:20:03 <UukGoblin> about 5 minutes in future
372 2012-01-06 12:20:55 <Raccoon> so you know exactly when to buy and sell
373 2012-01-06 12:21:11 <UukGoblin> lol
374 2012-01-06 13:05:28 <finway> piuk have a quiestion, If this script was included in the blockchain then validation would fail for new clients during the initial blockchain download.?  https://bitcointalk.org/index.php?topic=56823.0;topicseen
375 2012-01-06 14:10:50 <finway> So, a new altchain with OP_EVAL born and dead in one day? Interesting...
376 2012-01-06 14:20:14 <imsaguy2> coiledcoin?
377 2012-01-06 14:20:52 <finway> yeah, just find out
378 2012-01-06 14:21:02 <terrytibbs> we should all extend our gratitude to mr. luke-jr
379 2012-01-06 14:21:11 <Diablo-D3> dude
380 2012-01-06 14:21:13 <Diablo-D3> Im going to make one
381 2012-01-06 14:21:24 <Diablo-D3> bitits
382 2012-01-06 14:21:47 <terrytibbs> sounds legit
383 2012-01-06 14:22:44 <Diablo-D3> crypto keys will involve images of boobs
384 2012-01-06 14:22:55 <imsaguy2> Diablo-D3: don't forget to premine a couple million
385 2012-01-06 14:23:13 <Diablo-D3> bwhahaha
386 2012-01-06 14:23:15 <Diablo-D3> dude
387 2012-01-06 14:23:17 <Diablo-D3> if I encrypt images
388 2012-01-06 14:23:18 <Diablo-D3> guess what
389 2012-01-06 14:23:28 <Diablo-D3> those texture units on your gpu will be suddenly useful again
390 2012-01-06 14:25:04 <finway> mining power is the real power in bitcoin world.
391 2012-01-06 14:25:35 <jgarzik> slush: I like the stratum overlay protocol spec.  Just read it in-depth.  Good stuff.
392 2012-01-06 14:25:54 <slush> thanks :)
393 2012-01-06 14:26:05 <imsaguy2> url?
394 2012-01-06 14:26:10 <slush> stratum.bitcoin.cz
395 2012-01-06 14:27:16 <imsaguy2> thanks
396 2012-01-06 14:28:17 <slush> it needs some better homepage, but at this time, it's still under heavy development
397 2012-01-06 14:28:32 <imsaguy2> meh, the homepage can come later
398 2012-01-06 14:29:16 <slush> I tried to install mediawiki on the server, but there is dependency hell, it's pretty old debian...
399 2012-01-06 14:30:29 <imsaguy2> lol
400 2012-01-06 14:32:12 <jgarzik> as long as the source code is working and the spec is there, who needs a website?  :)
401 2012-01-06 14:34:03 <imsaguy2> jgarzik: well, at some point you have to have somehting that educates new users. word of mouth is good, but you still need documentation :)
402 2012-01-06 14:35:18 <jgarzik> if the first two are there, and the system is good, people will arise spontaneously to do that work for you
403 2012-01-06 14:37:43 <CIA-100> bips: genjix master * rb4281db / bip-0016.md : BIP 0016: Pay to Script Hash by Gavin - http://git.io/Ri5QhA https://github.com/genjix/bips/commit/b4281db71d81a87c2a97bb26fdb325b2d4217189
404 2012-01-06 14:39:26 <slush> well, stratum is mainly for developers, users will come in touch with stratum probably only because of node selection.
405 2012-01-06 14:39:33 <slush> jgarzik: did you read also the server source code?
406 2012-01-06 14:43:14 <sipa> jgarzik: did you have alook at pull #735 ?
407 2012-01-06 14:52:56 <finway> Competetion between Currency  is good!
408 2012-01-06 14:53:39 <finway> According to Hayek
409 2012-01-06 15:00:17 <jgarzik> sipa: what is CService?  netaddr + port pair?
410 2012-01-06 15:00:33 <jgarzik> slush: not seen source code yet
411 2012-01-06 15:01:01 <sipa> jgarzik: yes
412 2012-01-06 15:01:04 <jgarzik> slush: I like to read API docs first, where possible.  This gives best picture of what service is -supposed- to do.  Sometimes server implementation does not match desired outcome :)
413 2012-01-06 15:01:40 <finway> So your Bitcoin2.0 needs persuade more than 50% users and miners to support it, or it will die like CLC
414 2012-01-06 15:01:57 <finway> I hate 2.0
415 2012-01-06 15:02:23 <slush> jgarzik: agree, finally somebody with reasonable approach.
416 2012-01-06 15:02:31 <sipa> 2.0 does not exist, no need to hate it
417 2012-01-06 15:03:02 <slush> jgarzik: I discussed the protocol with main developer of Electrum and he told me that he don't understand any documentation and he wants to see the code
418 2012-01-06 15:03:12 <slush> and only then he can tell me if he likes my idea or not
419 2012-01-06 15:03:54 <k9quaint> slush: that is a bad sign
420 2012-01-06 15:04:06 <slush> k9quaint: don't tell *me* :-)
421 2012-01-06 15:04:26 <k9quaint> either you are talking with the wrong person, or you can't document a protocol (which bodes ill for designing the method by which two things communicate) :)
422 2012-01-06 15:04:56 <k9quaint> there is a third possibility
423 2012-01-06 15:05:16 <k9quaint> it could be that the myans were right, and we are all trapped in a movie with terrible writing
424 2012-01-06 15:05:19 <jgarzik> slush: heh
425 2012-01-06 15:05:31 <slush> k9quaint: lol
426 2012-01-06 15:05:55 <sipa> myans? mayans?
427 2012-01-06 15:07:01 <sipa> jgarzik: hmm, do you suggest a CSocket, which wraps SOCKET, and contains the connect() logic?
428 2012-01-06 15:07:17 <slush> well, I still hope that Electrum client will use Stratum backends at some point. I started the project becuase I think it is missing piece of bitcoin infrastructure, but I don't like splitting efforts (like implementing mostly the same code for Electrum backend and for Stratum(
429 2012-01-06 15:07:22 <slush> ovidiusoft: hi ;)
430 2012-01-06 15:07:32 <k9quaint> sipa: what is a vowel bewteen people who have slept with your sister :)
431 2012-01-06 15:07:51 <sipa> that would rewuire a lot of code changes
432 2012-01-06 15:08:11 <sipa> k9quaint: i have no sister!
433 2012-01-06 15:09:05 <k9quaint> sipa: that is one of those insults that plays the odds and does well when they are in favor
434 2012-01-06 15:10:20 <k9quaint> so what did luke do to litecoin?
435 2012-01-06 15:12:18 <gmaxwell> k9quaint: ignored it. dum dum dum clc isn't litecoin.
436 2012-01-06 15:12:20 <jgarzik> sipa: that seems logical
437 2012-01-06 15:12:36 <jgarzik> sipa: for #735 just maybe leave it outside CService
438 2012-01-06 15:12:55 <sipa> ok, fair enough
439 2012-01-06 15:13:21 <gmaxwell> k9quaint: (er, I'm not calling you dumb there, the dum dum dum was supposted to be dramatic sound effects like a mystery being revealed I just realized that could be misunderstood)
440 2012-01-06 15:13:37 <Diablo-D3> that'd be dun dun dun
441 2012-01-06 15:14:06 <k9quaint> I didn't know you wrote lisp
442 2012-01-06 15:14:49 <ovidiusoft> slush: hi :)
443 2012-01-06 15:18:10 <k9quaint> oh god, I feel so much dumber having read the thread about CLC on the alt currency forums
444 2012-01-06 15:18:29 <k9quaint> afk while my brain leaks from my ears
445 2012-01-06 15:26:44 <jgarzik> sipa: fundamentally a "socket", speaking generally, encapsulates two CServce's (local and remote addr/port)
446 2012-01-06 15:27:14 <jgarzik> and "connect" operation occurs on a socket, not an addr/port pair
447 2012-01-06 15:31:16 <makomk> Any pools in here mining using an OP_EVAL capable version of bitcoin?
448 2012-01-06 15:37:13 <makomk> Hmmm. It looks like luke-jr is really lucky I don't hold much of a grudge right now.
449 2012-01-06 15:37:36 <JFK911> why?  can you ruin him?
450 2012-01-06 15:39:03 <[Tycho]> makomk: almost. But evaluation is not enabled before 1.02.2012
451 2012-01-06 15:39:38 <makomk> [Tycho]: don't think it matters.
452 2012-01-06 15:39:50 <[Tycho]> `why ?
453 2012-01-06 15:40:23 <[Tycho]> But looks like I'll withdraw this support if no agreement on the future will arise
454 2012-01-06 15:44:29 <makomk> [Tycho]: there seems to be a really lovely denial of service attack against OP_EVAL enabled pools and miners that doesn't actually require it to be enabled or even used in the attack.
455 2012-01-06 15:45:10 <jgarzik> slush: do you ack the "coinbaser" pull request, https://github.com/bitcoin/bitcoin/pull/719 ?
456 2012-01-06 15:45:25 <jgarzik> slush: trying to verify that luke-jr is not the only person who wants this
457 2012-01-06 15:45:28 <jgarzik> gmaxwell: ^^
458 2012-01-06 15:46:26 <sipa> slush doesn't use generation-based payouts iirc
459 2012-01-06 15:47:04 <slush> I don't need that, but I don't have anything against that patch
460 2012-01-06 15:48:00 <makomk> [Tycho]: http://pastebin.ca/2100481 - the sigop counting in the mining code is bugged and can be tricked into mining blocks that will never validate, I think.
461 2012-01-06 15:48:20 <slush> I'm trying to implement block creation completely outside bitcoind, so I hope that I won't need any patches like this anymore
462 2012-01-06 15:49:56 <makomk> I think the transactions required should pass IsStandard too.
463 2012-01-06 15:50:37 <[Tycho]> Hmm.
464 2012-01-06 15:51:47 <makomk> Quite evil; in my tests with testnet in a box it chugs along normally but all the solved blocks are rejected.
465 2012-01-06 15:52:16 <gavinandresen> That's my backported OP_EVAL patches?
466 2012-01-06 15:52:25 <gavinandresen> Or something else?
467 2012-01-06 15:53:04 <gavinandresen> (I implemented correct sigop counting for pay-to-script-hash yesterday, haven't backported it yet)
468 2012-01-06 15:53:05 <makomk> gavinandresen: this is in git head, I still haven't got around to digging up and compiling your patches.
469 2012-01-06 15:54:20 <gavinandresen> makomk: latest code is https://github.com/gavinandresen/bitcoin-git/tree/pay_to_script_hash
470 2012-01-06 15:54:49 <gavinandresen> It'll be a pull request as soon as I generate and spend and validate a few transactions on testnet
471 2012-01-06 15:58:18 <makomk> gavinandresen: ah, I think that fixes it by checking both sigops limits in CreateNewBlock?
472 2012-01-06 15:58:23 <gavinandresen> yes
473 2012-01-06 15:58:41 <makomk> Ah good.
474 2012-01-06 15:58:45 <gavinandresen> (or should, anyway-- I'll test on testnet)
475 2012-01-06 16:04:41 <gavinandresen> Did somebody generate a really long from-the-genesis-block chain on testnet to play with valid-block spamming?
476 2012-01-06 16:35:25 <UukGoblin> hm, is there a list of major (network-rules) changes between 0.3.22 and 0.5.1?
477 2012-01-06 16:35:44 <UukGoblin> I know the fee was decreased from 0.01 to 0.0005, but looking if there's more stuff like that?
478 2012-01-06 16:36:35 <sipa> no network rules changed
479 2012-01-06 16:37:14 <gmaxwell> UukGoblin: An attack related to the propagation of a particular kind of never-confirmable transactions was closed.
480 2012-01-06 16:37:15 <UukGoblin> the fee is something less than a network rule... is that a network standard or sth like that?
481 2012-01-06 16:38:10 <gavinandresen> what do you mean by "network rules" ?
482 2012-01-06 16:38:28 <UukGoblin> yeah exactly ;-) not sure myself, stuff like the fee change ;-)
483 2012-01-06 16:38:42 <[Tycho]> My nodes still use 0.01 as minimal fee.
484 2012-01-06 16:39:01 <gavinandresen> That would be an "I'm willing to relay transactions that satisfy these properties" rule.  Need a good name for that.... "relay rules" ?
485 2012-01-06 16:39:33 <gavinandresen> ... and "I'm willing to put transactions that satisfy these rules into blocks I mine" rules.
486 2012-01-06 16:39:47 <UukGoblin> there'd be relay rules, block-acceptance rules, and "hard" (?) rules
487 2012-01-06 16:39:53 <gmaxwell> Yea, we've had this discussion before.. also rules that fork and don't fork are different.
488 2012-01-06 16:39:59 <gavinandresen> Sounds good.
489 2012-01-06 16:40:13 <gmaxwell> Relay-rules, protocol-rules, and 'bitcoin algorithim' (the part you can't change)
490 2012-01-06 16:40:20 <gavinandresen> I don't think there is a list of relay or block-acceptance rule changes.  We have been careful not to make any hard rule changes.
491 2012-01-06 16:40:24 <UukGoblin> mined-block-acceptance and others-block-acceptance
492 2012-01-06 16:41:03 <UukGoblin> i.e. 1MB blocksize limit would be "bitcoin algorithm" by gmaxwell's terms
493 2012-01-06 16:41:28 <UukGoblin> (or "hard" rule by mine)
494 2012-01-06 16:41:42 <UukGoblin> the txn fee would be a relay-rule
495 2012-01-06 16:41:49 <UukGoblin> well, not necessarily...
496 2012-01-06 16:42:07 <UukGoblin> there's a difference between relaying, accepting in a self-mined block, and accepting in someone else's block :-P
497 2012-01-06 17:35:20 <gavinandresen> Interesting: transaction spam in another context:  "Regulators might be able to combat this by imposing a fee on traders who introduce excessive messages into the data stream."
498 2012-01-06 17:35:27 <gavinandresen> http://www.businessweek.com/magazine/bloomberg-view-greeces-least-bad-option-trading-and-regulating-at-light-speed-01052012_page_2.html
499 2012-01-06 18:00:13 <luke-jr> gavinandresen: is http://pastebin.ca/2100481 a real threat? if so, do you have a fix?
500 2012-01-06 18:01:27 <gavinandresen> luke-jr: yes, it is a real threat.
501 2012-01-06 18:01:54 <gavinandresen> luke-jr: ... and I'm testing the latest pay-to-script-hash code on testnet right now to make sure it isn't vulnerable.
502 2012-01-06 18:02:11 <luke-jr> gavinandresen: so & fix for OP_EVAL, or shall I just revert OP_EVAL out?
503 2012-01-06 18:02:17 <gavinandresen> revert OP_EVAL out
504 2012-01-06 18:11:24 <BlueMatt> luke-jr: how is that a threat, as I read it it creates a multisend of 1000xCENT/100 sends to a multisig script which has one pubkey
505 2012-01-06 18:11:30 <BlueMatt> am I reading it wrong?
506 2012-01-06 18:12:36 <makomk> BlueMatt: that transaction exceeds MAX_BLOCK_SIGOPS by the old algorithm. No block containing it can possibly be valid.
507 2012-01-06 18:12:54 <BlueMatt> ahhh, ofc
508 2012-01-06 18:13:47 <makomk> Unfortunately, the OP_EVAL version of the mining code doesn't realise this when deciding which transactions to include; it only checks against the new way of computing sigops.
509 2012-01-06 18:14:01 <BlueMatt> mmm, ok
510 2012-01-06 18:14:02 <BlueMatt> makes sense then
511 2012-01-06 18:14:44 <roconnor> BlueMatt: what's the difference between old and "new" methods of counting?
512 2012-01-06 18:16:29 <luke-jr> FWIW: Eligius no longer supports OP_EVAL per Gavin's recommendation
513 2012-01-06 18:16:57 <BlueMatt> good
514 2012-01-06 18:25:56 <makomk> I wonder how long it would've taken for someone to notice that being exploited in the wild, actually.
515 2012-01-06 18:26:29 <gavinandresen> makomk: it was on my list to fix when we switched from OP_EVAL to pay-to-script-hash....
516 2012-01-06 18:27:01 <makomk> gavinandresen: yeah, figured as much from the fact you had a fix ready already.
517 2012-01-06 18:27:12 <gavinandresen> And it couldn't be exploited on main net unless the miner was mining non-standard transactions
518 2012-01-06 18:27:26 <makomk> Ah, I see. Curious.
519 2012-01-06 18:28:28 <gavinandresen> makomk: can you generate a malicious transaction or three on testnet right now?
520 2012-01-06 18:28:53 <gavinandresen> (so I can be lazy and don't have to compile your code...)
521 2012-01-06 18:29:21 <makomk> OK, done, no idea if they'll get broadcast though.
522 2012-01-06 18:29:52 <gavinandresen> makomk: thanks.  If I don't see them I'll compile a bitcoind and -connect directly to myself
523 2012-01-06 18:30:01 <luke-jr> makomk: no hard feelings i hope, I didn't actually realize you were behind Coiledcoin when I started
524 2012-01-06 18:30:27 <BlueMatt> what was the point of Coiledcoin?
525 2012-01-06 18:30:36 <makomk> (Also, it looked to me like 1-of-1 multisig transactions *should* in theory pass IsStandard at least in git head.)
526 2012-01-06 18:31:20 <luke-jr> makomk: testnet shouldn't be checking IsStandard
527 2012-01-06 18:31:23 <gavinandresen> Does BIP 11 say 1-of-1 isn't IsStandard?  (... goes to look....)
528 2012-01-06 18:31:49 <makomk> BlueMatt: mostly it was intended as a way to try things based on multi-signature transactions in the wild.
529 2012-01-06 18:31:59 <luke-jr> IMO, BIPs should not deal with IsStandard&
530 2012-01-06 18:32:03 <gavinandresen> BIP 11 says m-of-n where n is less than 3.  so 1-of-1 should be IsStandard.
531 2012-01-06 18:32:12 <luke-jr> IsStandard is a draconian bitcoind rule, not network rules :p
532 2012-01-06 18:32:29 <luke-jr> makomk: why not just build OP_EVAL-enabled testnet then?
533 2012-01-06 18:32:35 <gavinandresen> I think it is useful to define cross-implementation "this is how we are going to do it" transaction forms.
534 2012-01-06 18:33:01 <luke-jr> gavinandresen: sure, but thanks to OP_EVAL/P2SH semantics, it doesn't matter
535 2012-01-06 18:33:05 <gavinandresen> Because otherwise we'll get fourteen different ways of doing something, and different clients will recognize different forms....
536 2012-01-06 18:33:13 <luke-jr> so?
537 2012-01-06 18:33:46 <gavinandresen> luke-jr: sure it matters, if there are three different ways to do a 2-of-3 escrow transaction, and I want my client to have a category of "coins in escrow", then it needs to recognize the transaction form for "2-of-3 escrow"
538 2012-01-06 18:33:48 <luke-jr> the recipient uses a script the recipient recognizes
539 2012-01-06 18:35:16 <jgarzik> pay-to-script-hash is really nice
540 2012-01-06 18:35:31 <gavinandresen> If I coded the client to trust that some arbitrary hash is a 2-of-3 escrow then that opens up all sorts of possible nasty hacks
541 2012-01-06 18:35:50 <luke-jr> gavinandresen: you're missing the part that the recipient chooses what script in the first place
542 2012-01-06 18:36:03 <luke-jr> so each receiver can make up their own templates and not need to worry about other receivers
543 2012-01-06 18:36:10 <gavinandresen> 2-of-3 escrow there is no recipient, that's the point
544 2012-01-06 18:36:31 <gavinandresen> (well, there is no recipient until the escrow completes)
545 2012-01-06 18:36:42 <luke-jr> good point
546 2012-01-06 18:36:42 <makomk> Yeah, all three parties need to be able to trust that the transaction does what it's meant to do.
547 2012-01-06 18:36:50 <gavinandresen> exactly
548 2012-01-06 18:36:59 <gavinandresen> ... hence the need for some standard way of representing it
549 2012-01-06 18:37:25 <BlueMatt> it also makes script solving a shitton easier
550 2012-01-06 18:38:46 <gavinandresen> Yup, digging out the public keys involved, and figuring out how they are involved, is really hard if you have to execute the script to find out.
551 2012-01-06 18:39:14 <gavinandresen> (and maybe impossible, since you can do bizarre stuff like    CHECKSIG   IF ... do something ELSE ...do something else ENDIF
552 2012-01-06 18:39:44 <helo> does OP_EVAL not "pay to script hash"?
553 2012-01-06 18:40:08 <gavinandresen> OP_EVAL is a superset of pay-to-script-hash
554 2012-01-06 18:40:34 <gavinandresen> or maybe: pay-to-script-hash is OP_EVAL beaten into submission.
555 2012-01-06 18:40:43 <gavinandresen> neutered
556 2012-01-06 18:40:48 <gavinandresen> rendered mostly harmless
557 2012-01-06 18:41:34 <luke-jr> pay-to-script-hash is OP_EVAL
558 2012-01-06 18:42:06 <luke-jr> current "P2SH" is a magic special-cased alternative to OP_EVAL, to eliminate scriptPubKey in a compatible way instead of extending it
559 2012-01-06 18:44:51 <gavinandresen> I don't see why special-casing  HASH160 <> EQUAL NOP1   is any better than special-casing HASH160 <> EQUAL
560 2012-01-06 18:45:20 <gavinandresen> And I can clearly see why it is worse (one byte longer, uses up a NOP opcode)
561 2012-01-06 18:45:49 <luke-jr> gavinandresen: not special-casing it, but making it the new action
562 2012-01-06 18:46:04 <makomk> It's slightly more obvious that something magic is going on with the former; the latter looks like a simple easy to understand transaction but does something magic.
563 2012-01-06 18:46:08 <BlueMatt> because if you have an OP_NOP1 its clearly something that has been added
564 2012-01-06 18:46:10 <gavinandresen> ?? making what the new action ??  making NOP1 do the OP_EVAL thing?
565 2012-01-06 18:47:44 <gavinandresen> makomk: is slightly-more-obvious worth the extra byte?  I vote no.
566 2012-01-06 18:48:01 <BlueMatt> one byte?
567 2012-01-06 18:48:10 <luke-jr> gavinandresen: making "NOP1" do the new action: run the script
568 2012-01-06 18:48:25 <BlueMatt> luke-jr: then you are back at OP_EVAL...
569 2012-01-06 18:48:29 <luke-jr> exactly
570 2012-01-06 18:48:34 <BlueMatt> no
571 2012-01-06 18:49:35 <gavinandresen> yes, no, we had that argument and the consensus is full OP_EVAL is too much for now.
572 2012-01-06 19:14:36 <BlueMatt> gavinandresen: imo it just comes down to do you want the scripting stuff to be cleaner, or do you want the scripting stuff to save a byte on each txout
573 2012-01-06 19:14:57 <gavinandresen> HASH160 <> EQUAL looks cleaner to me.
574 2012-01-06 19:15:00 <BlueMatt> I would say if we are that crazy about bytes, there are other ways to save, so we might as well be consistent
575 2012-01-06 19:15:11 <luke-jr> special-case is not clean
576 2012-01-06 19:15:12 <BlueMatt> but its still magic crap
577 2012-01-06 19:15:33 <gavinandresen> .... and either way is magic crap....
578 2012-01-06 19:15:36 <luke-jr> except as a "scriptPubKey no longer allowed; this exists only for compatibility"
579 2012-01-06 19:15:43 <BlueMatt> OP_NOP1 is less magic
580 2012-01-06 19:16:09 <BlueMatt> if you want to save a byte, make everyone use ptsh and just drop HASH160 + EQUAL
581 2012-01-06 19:16:13 <gavinandresen> How is it any less magic?  What if I send a HASH <> EQUAL NOP1 NOP1 ?
582 2012-01-06 19:16:41 <BlueMatt> if a client sees NOP1, it can safely assume something is going on that is above its head
583 2012-01-06 19:16:44 <luke-jr> gavinandresen: becuase you're adding new behaviour via the defined mechanism for extension
584 2012-01-06 19:16:47 <gavinandresen> BlueMatt: that'll be a good option if/when there is universal support for p2sh
585 2012-01-06 19:16:49 <luke-jr> not special-casing existing behaviour
586 2012-01-06 19:17:22 <gavinandresen> BlueMatt: you didn't answer my question:  what should the code do if it gets a scriptPubKey that has two NOP1's on the end?
587 2012-01-06 19:17:56 <BlueMatt> its not a question of what it should do; it should obv ignore the NOP1 and treat it as a non-ptsh tx
588 2012-01-06 19:18:05 <BlueMatt> its a question of how clean it looks
589 2012-01-06 19:18:25 <gavinandresen> Again, no wonky NOP-at-the-end looks cleaner to me.
590 2012-01-06 19:18:37 <luke-jr> &
591 2012-01-06 19:18:43 <BlueMatt> (also, HASH <> EQUAL NOP1 in your existing implementation should treat it as a non-ptsh, correct?)
592 2012-01-06 19:18:47 <luke-jr> BlueMatt: that's even worse than gavinandresen's
593 2012-01-06 19:19:04 <BlueMatt> luke-jr: what is?
594 2012-01-06 19:19:12 <luke-jr> special-casing it with a NOP1 at the end
595 2012-01-06 19:19:14 <gavinandresen> BlueMatt: yes, the BIP says that the bytes must be exactly:  HASH160 then 0x14 then twenty hash bytes then EQUAL
596 2012-01-06 19:19:19 <gavinandresen> 23 bytes in all
597 2012-01-06 19:19:21 <luke-jr> but not treating NOP1 as a new action
598 2012-01-06 19:19:28 <gavinandresen> First two and last one defines p2sh
599 2012-01-06 19:19:50 <gavinandresen> No using PUSHDATA4 to push the hash....
600 2012-01-06 19:20:24 <gavinandresen> I just don't see the reason to make the rules "24 bytes in all, first two must be this, last two must be that...."
601 2012-01-06 19:21:08 <gavinandresen> And I'd really rather stop arguing over what color to paint this bike shed.  Does it matter?
602 2012-01-06 19:21:15 <BlueMatt> because, as luke points out, in that way you are extending scripts in the previously-defined method for extension, instead of extending it using some special-case crap
603 2012-01-06 19:21:37 <luke-jr> OP_EVAL should just have restrictions added&
604 2012-01-06 19:21:45 <gavinandresen> BlueMatt: again, it will be special-case-crap in any case-- the code is going to look for a particular pattern of bytes in the scriptPubKey
605 2012-01-06 19:21:49 <luke-jr> "script must have been pushed by a simple OP_PUSHDATA" for example
606 2012-01-06 19:22:15 <BlueMatt> luke-jr: still too hard to prove correctness
607 2012-01-06 19:22:29 <luke-jr> BlueMatt: then a CODESEP version
608 2012-01-06 19:22:43 <luke-jr> gavinandresen: that's the problme
609 2012-01-06 19:24:11 <gavinandresen> testnet block with BIP 16 transactions in it, by the way:  http://blockexplorer.com/testnet/block/000000000182cc0764d6c6b2b43a009fc9dc0cb03e9002249e7e865b7189acf8
610 2012-01-06 19:26:18 <BlueMatt> ;;seen gmaxwell
611 2012-01-06 19:26:18 <gribble> gmaxwell was last seen in #bitcoin-dev 2 hours, 46 minutes, and 4 seconds ago: <gmaxwell> Relay-rules, protocol-rules, and 'bitcoin algorithim' (the part you can't change)
612 2012-01-06 19:26:37 <BlueMatt> gmaxwell: what would you recommend for single-thread profiling?
613 2012-01-06 19:28:50 <luke-jr> gavinandresen: btw, did you start the 0.5.2 builds?
614 2012-01-06 19:29:20 <luke-jr> slush: you changed your mind about using coinbaser?
615 2012-01-06 19:29:23 <gavinandresen> luke-jr: no, been busy arguing with people about issues I thought had already reached consensus
616 2012-01-06 19:29:31 <gmaxwell> BlueMatt: luke-jr asked me that a day ago. I'm not sure, never actually cared to just profile a single thread except via strace (which is actually a useful profiling tool with the -c / -t / etc timing options)
617 2012-01-06 19:30:10 <luke-jr> slush: would you like to collaborate on eloipool with me? https://gitorious.org/bitcoin/eloipool
618 2012-01-06 19:31:25 <gribble> New news from bitcoinrss: gavinandresen opened issue 747 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/747>
619 2012-01-06 19:34:41 <makomk> gavinandresen: by the way, what exactly made those transactions non-standard anyway?
620 2012-01-06 19:35:51 <gavinandresen> makomk: CHECKMULTISIG is non-standard for most of the network right now
621 2012-01-06 19:36:32 <gavinandresen> I'll edit the issue to be more precise, you're right if you're running git head they would be standard
622 2012-01-06 19:37:05 <makomk> Ah. Did your backports of OP_EVAL not change IsStandard at the same time then?
623 2012-01-06 19:37:59 <gavinandresen> fine, recent git head OR backported OP_EVAL....
624 2012-01-06 19:40:44 <makomk> Yeah. Those were the ones I was most worried about; even if nodes without OP_EVAL tried to include the transaction the worst that could happen is that they'd stop processing other transactions IIRC.
625 2012-01-06 19:41:26 <luke-jr> to clarify: Eligius is no longer treating OP_EVAL special, but is still advertising its support for OP_EVAL in coinbases
626 2012-01-06 19:58:01 <slush> luke-jr: I want to implement pool as a service for Stratum server. Feel free to join the effort :). Actually I want to implement pool on top of Twisted, because I have very good experience with longpolling daemon in twisted already
627 2012-01-06 19:58:30 <luke-jr> no idea what Stratum is, I dislike Twisted, and Eloipool is Python
628 2012-01-06 19:58:48 <slush> luke-jr: I have improved mining interface already in my mind, which can be even backward compatible with getwork interface with some local proxy on miner side
629 2012-01-06 19:59:02 <slush> luke-jr: twisted is asynchronous python
630 2012-01-06 19:59:04 <luke-jr> slush: Eloipool is modular and mostly working
631 2012-01-06 19:59:09 <slush> luke-jr: and stratum is my project: stratum.bitcoin.cz
632 2012-01-06 19:59:26 <slush> luke-jr: but written with threads, so no significant improvement against my current code
633 2012-01-06 19:59:50 <slush> luke-jr: pool does not need to be modular. It must be fast and stable :)
634 2012-01-06 19:59:59 <luke-jr> slush: it is fast :p
635 2012-01-06 20:00:10 <luke-jr> the JSON-RPC module is not stable, but everything else seems to be
636 2012-01-06 20:00:48 <luke-jr> I prefer pure-Python async ;)
637 2012-01-06 20:02:04 <luke-jr> but the JSON-RPC module in Eloipool right now is just a multithreaded hack
638 2012-01-06 20:02:12 <luke-jr> I threw it together basically just for testing :p
639 2012-01-06 20:04:25 <BlueMatt> gmaxwell: you can do per-thread stuff in oprofile, see tid profile specification and --separate
640 2012-01-06 20:04:46 <luke-jr> BlueMatt: I tried that and it didn't work
641 2012-01-06 20:04:52 <slush> luke-jr: I'm reading the code...
642 2012-01-06 20:05:02 <BlueMatt> luke-jr: is working for me...
643 2012-01-06 20:05:27 <slush> not bad, but I don't want to use standard getwork interface anyway
644 2012-01-06 20:05:49 <luke-jr> BlueMatt: watch --interval=1 "opcontrol --dump && opreport -l tid:7819 | head -30 ; opcontrol --reset"
645 2012-01-06 20:05:58 <luke-jr> slush: so write another module for the interface you want :P
646 2012-01-06 20:06:10 <luke-jr> slush: the network interface is intentionally abstracted away
647 2012-01-06 20:06:36 <luke-jr> BlueMatt: that doesn't work
648 2012-01-06 20:06:58 <slush> luke-jr: what's the licence?
649 2012-01-06 20:07:10 <luke-jr> slush: I was thinking AGPL. Would that be ok?
650 2012-01-06 20:07:19 <BlueMatt> luke-jr: it appears to be very poorly written and most of the code ignores it, but its there and is working for me...
651 2012-01-06 20:07:32 <luke-jr> BlueMatt: huh?
652 2012-01-06 20:07:58 <BlueMatt> (not your commands obv)
653 2012-01-06 20:09:04 <slush> luke-jr: nice, I'll at least use some code from you, like merkle generation. I'll opensource my code as well.
654 2012-01-06 20:09:43 <luke-jr> slush: well, I'm more looking to collaborate than for someone to borrow/use my code <.<
655 2012-01-06 20:10:13 <slush> :)
656 2012-01-06 20:12:07 <slush> luke-jr: then some more restrictive licence will do the work
657 2012-01-06 20:12:16 <luke-jr> slush: you are familiar with the AGPL terms? ;)
658 2012-01-06 20:12:32 <slush> luke-jr: seriously. I have already concept in my head, after more than year of running pool on current core
659 2012-01-06 20:12:40 <slush> a little :)
660 2012-01-06 20:12:48 <luke-jr> what's wrong with Eloipool concept?
661 2012-01-06 20:15:07 <slush> luke-jr: don't take it personally, but there's more threads and global variables than expected :)
662 2012-01-06 20:15:40 <luke-jr> slush: pretty sure all the global variables are in the eloipool.py that I haven't really written yet :P
663 2012-01-06 20:16:02 <slush> actually it's my bad that I don't understand this type of code
664 2012-01-06 20:16:03 <luke-jr> the threads are necessary to utilize multiple cores at all
665 2012-01-06 20:16:15 <slush> luke-jr: if you're familiar with python....
666 2012-01-06 20:16:23 <slush> ...then you know how much you're wrong ;)
667 2012-01-06 20:16:34 <luke-jr> I know Python has terrible thread support *right now* ;)
668 2012-01-06 20:16:40 <luke-jr> I also know it doesn't matter yet
669 2012-01-06 20:16:55 <luke-jr> and that making it single-threaded wouldn't gain anything
670 2012-01-06 20:18:11 <slush> the GIL is so deep in the interpreter that I don't think we ever see really parallel interpreter of CPython
671 2012-01-06 20:18:12 <phantomcircuit> luke-jr, cpython has terrible thread support
672 2012-01-06 20:18:20 <luke-jr> anyhow, the *real* code is strictly in modular components that (in theory) are more or less isolated from each other
673 2012-01-06 20:18:25 <phantomcircuit> jython (which is terrible) has mediocre thread support
674 2012-01-06 20:18:26 <luke-jr> phantomcircuit: I just said I know that :P
675 2012-01-06 20:18:29 <phantomcircuit> oh
676 2012-01-06 20:18:37 <phantomcircuit> im too lazy to read full sentences
677 2012-01-06 20:18:42 <slush> phantomcircuit: jython is slow as hell
678 2012-01-06 20:18:53 <phantomcircuit> slush, yeah it's terrible
679 2012-01-06 20:19:05 <phantomcircuit> its so slow for a ton of reasons
680 2012-01-06 20:19:23 <luke-jr> also, if it became an issue, I could always port it to C ;p
681 2012-01-06 20:19:24 <phantomcircuit> not the least of which is that the python interpreter actually compiles to byte code anyways
682 2012-01-06 20:19:27 <slush> well, then python is de-facto single threaded, why bloat the code with threads? they're only overcomplicating things
683 2012-01-06 20:19:36 <luke-jr> slush: threads simplify things, actually
684 2012-01-06 20:19:40 <luke-jr> and don't bloat
685 2012-01-06 20:19:49 <luke-jr> unless you do one thread per connection
686 2012-01-06 20:19:50 <phantomcircuit> what are we talking about here?
687 2012-01-06 20:19:55 <luke-jr> phantomcircuit: Eloipool
688 2012-01-06 20:19:58 <phantomcircuit> oh
689 2012-01-06 20:20:18 <phantomcircuit> thread per connect actually works reasonably well if you can judge how much stack each thread will need in advance
690 2012-01-06 20:20:22 <slush> luke-jr: did you play with twisted before?
691 2012-01-06 20:20:32 <phantomcircuit> and of course each connection is truly independent
692 2012-01-06 20:20:34 <luke-jr> never had a need for it
693 2012-01-06 20:20:44 <luke-jr> phantomcircuit: https://gitorious.org/bitcoin/eloipool
694 2012-01-06 20:20:47 <phantomcircuit> twisted is a giant pile of crap
695 2012-01-06 20:20:50 <phantomcircuit> seriously
696 2012-01-06 20:20:54 <phantomcircuit> it doesn't even support ipv6
697 2012-01-06 20:20:57 <luke-jr> wtf
698 2012-01-06 20:21:17 <phantomcircuit> i dont think so
699 2012-01-06 20:21:19 <phantomcircuit> but it might
700 2012-01-06 20:21:22 <slush> lol "it does not have ipv6, it's a crap"
701 2012-01-06 20:21:29 <luke-jr> slush: that's totally true
702 2012-01-06 20:21:41 <luke-jr> it's like not supporting IPv4 in 2000
703 2012-01-06 20:21:53 <slush> twisted is completely different paradigm than standard python
704 2012-01-06 20:22:03 <luke-jr> = fail
705 2012-01-06 20:22:05 <Backburn2> ipv4 address exhaustion this year
706 2012-01-06 20:22:11 <phantomcircuit> twisted is just a giant ridiculous wrapper around epoll and friends
707 2012-01-06 20:22:16 <slush> sometimes I think twisted is more like separate language
708 2012-01-06 20:22:28 <graingert> www.google.co.uk/search?q="it+does+not+have+ipv6%2C+it's+a+crap"
709 2012-01-06 20:23:05 <luke-jr> slush: you say that as if it's a good thing
710 2012-01-06 20:23:47 <slush> luke-jr: well, I'm not sure yet. I don't have so much experience with twisted as with standard python
711 2012-01-06 20:23:52 <slush> but so far I'm really satisfied
712 2012-01-06 20:24:12 <slush> I'm not surprised that you don't like it, anyway.
713 2012-01-06 20:24:24 <helo> (flask is awesome for python web pages)
714 2012-01-06 20:30:00 <luke-jr> BlueMatt: ping
715 2012-01-06 20:33:32 <BlueMatt> luke-jr: pong
716 2012-01-06 20:36:28 <luke-jr> BlueMatt: did you update the PPA?
717 2012-01-06 20:36:57 <BlueMatt> oh, thanks for the reminder
718 2012-01-06 20:37:33 <BlueMatt> wait, yea the ppa is on 0.5.1
719 2012-01-06 20:37:39 <luke-jr> 0.5.2rc1 I mean
720 2012-01-06 20:37:44 <luke-jr> or does PPA not have RCs?
721 2012-01-06 20:37:52 <BlueMatt> graingert signed up to manage that
722 2012-01-06 20:37:59 <luke-jr> ?
723 2012-01-06 20:38:02 <graingert> hello
724 2012-01-06 20:38:05 <graingert> eep
725 2012-01-06 20:38:16 <BlueMatt> graingert is the one who wanted an rc ppa, so he does that...
726 2012-01-06 20:38:16 <graingert> *points at dissertation ganttchart*
727 2012-01-06 20:38:20 <BlueMatt> maybe if I get around to it...
728 2012-01-06 20:38:47 <graingert> I'll be free Summer 2012
729 2012-01-06 20:39:31 <luke-jr> BlueMatt: can you build 0.5.0.3 and 0.4.3 as well?
730 2012-01-06 20:40:25 <graingert> luke-jr: there is structure available for those
731 2012-01-06 20:40:32 <luke-jr> graingert: ?
732 2012-01-06 20:40:51 <graingert> ie on launchpad
733 2012-01-06 20:41:13 <graingert> the big "plan" is to get auto builds from github working
734 2012-01-06 20:42:20 <BlueMatt> luke-jr: arg, yea when I have the time to reset my branch, Im working now...
735 2012-01-06 20:42:53 <luke-jr> k
736 2012-01-06 20:43:06 <luke-jr> graingert: no idea about LP BC stuff
737 2012-01-06 20:43:38 <graingert> BC = Bitcoin?
738 2012-01-06 20:44:30 <luke-jr> &yes
739 2012-01-06 20:59:49 <luke-jr> jgarzik: FWIW, here is Eclipse's pool-op on coinbaser (followed by slush, who apparently moved on due to the delay) https://bitcointalk.org/index.php?topic=46927.msg638500#msg638500
740 2012-01-06 21:02:54 <slush> luke-jr: but with the eloipool, you don't need this patch anymore, right?
741 2012-01-06 21:03:40 <luke-jr> slush: correct, this is more for improving bitcoind at this point
742 2012-01-06 21:03:50 <gmaxwell> My own interest in it has been removed by the fact that I don't think I'll solo anymore without p2pool.
743 2012-01-06 21:04:11 <luke-jr> also, lately I've thought I might not finish Eloipool if there's nobody to collaborate with
744 2012-01-06 21:04:14 <luke-jr> too  much time
745 2012-01-06 21:17:00 <[Tycho]> What's wrong with TX 8fc327a474792108e3c8c05f05e288c84b7458cf2cc73eab5ff25257dc55f767 and why it was stuck ?
746 2012-01-06 21:22:06 <BlueMatt> [Tycho]: tx isnt on bitcoincharts or bbe
747 2012-01-06 21:22:27 <[Tycho]> That's why I'm asking :)
748 2012-01-06 21:22:39 <BlueMatt> has it  been announced?
749 2012-01-06 21:23:10 <[Tycho]> I'm logging TXes received by my monitoring nodes, but not confirmed for a long time, to find out what's wrong with them.
750 2012-01-06 21:24:06 <[Tycho]> So it was announced by someone.
751 2012-01-06 21:24:13 <luke-jr> maybe only to [Tycho]?
752 2012-01-06 21:24:16 <luke-jr> double spend attempt?
753 2012-01-06 21:24:36 <[Tycho]> It's a third stuck TX in a couple of weeks.
754 2012-01-06 21:24:48 <luke-jr> [Tycho]: doesn't your bitcoind log say why?
755 2012-01-06 21:25:03 <gmaxwell> I put a bet on it using the same input twice.
756 2012-01-06 21:25:12 <[Tycho]> I think it's accepted in memorypool.
757 2012-01-06 21:25:32 <[Tycho]> gmaxwell guessed correctly :)
758 2012-01-06 21:25:43 <[Tycho]> Where did those originate from ?
759 2012-01-06 21:25:52 <gmaxwell> 01/06/12 04:47:04 sending getdata: tx 8fc327a474792108e3c8
760 2012-01-06 21:25:53 <gmaxwell> 01/06/12 04:47:04 ERROR: AcceptToMemoryPool() : CheckTransaction failed
761 2012-01-06 21:26:03 <[Tycho]> Some online wallet constructor ?
762 2012-01-06 21:26:09 <gmaxwell> [Tycho]: it's someone attempting to attack old clients.
763 2012-01-06 21:26:18 <[Tycho]> Cool.
764 2012-01-06 21:26:45 <[Tycho]> All 3 have this in common.
765 2012-01-06 21:26:52 <[Tycho]> But this one has 3 inputs.
766 2012-01-06 21:27:39 <BlueMatt> (IIRC)
767 2012-01-06 21:28:37 <sipa> flooding memory pool?
768 2012-01-06 21:29:09 <BlueMatt> no, duplicate inputs
769 2012-01-06 21:30:10 <sipa> no, a possible reason to create such transaction is in order flood someone[ memory pool
770 2012-01-06 21:30:21 <BlueMatt> oh, yea
771 2012-01-06 21:30:24 <gmaxwell> I've never seen that many of them.
772 2012-01-06 21:30:26 <[Tycho]> http://savepic.su/1141438.gif
773 2012-01-06 21:30:51 <BlueMatt> sipa: would need to be more of them though...
774 2012-01-06 21:31:03 <sipa> what is .su?
775 2012-01-06 21:31:03 <[Tycho]> How old should be the client ?
776 2012-01-06 21:31:11 <[Tycho]> sipa: Soviet Union
777 2012-01-06 21:31:16 <gmaxwell> I suspect there are people accepting 0 confirms (e.g. for otc/forum trades, or maybe some websites) ... and someone is exploting them / attempting to.
778 2012-01-06 21:33:16 <jrmithdobbs> ya i've seen them too
779 2012-01-06 21:34:14 <roconnor> gmaxwell: that sounds clever
780 2012-01-06 21:35:14 <[Tycho]> So old client will show it as received/unconfirmed ?
781 2012-01-06 21:35:29 <gmaxwell> Yes. It'll be accepted to memory pool and show as received/unconfirmed.
782 2012-01-06 21:35:33 <gmaxwell> and relayed.
783 2012-01-06 21:35:46 <gmaxwell> Newer nodes drop them on ingress.
784 2012-01-06 21:36:47 <roconnor> I guess telling people that 0 confirm transactions are probably okay wasn't such a hot idea after all.
785 2012-01-06 21:36:56 <gmaxwell> another possibility is that they're not attacks at all.. but just memory errors in old nodes.
786 2012-01-06 21:37:21 <gmaxwell> e.g. coinselection gets a bitflip and picks the same input twice.
787 2012-01-06 21:37:28 <BlueMatt> who ever said that 0 confirm txes are probably ok?
788 2012-01-06 21:37:38 <BlueMatt> 0 confirm txes can be ok, if you do enough work
789 2012-01-06 21:37:47 <[Tycho]> I see those from time to time and wondering who creates them.
790 2012-01-06 21:37:54 <gmaxwell> If you know the counterparty for example, or don't care if you get ripped off.
791 2012-01-06 21:38:15 <BlueMatt> ok, well yea but in that case, a unconfirmable tx wont matter either
792 2012-01-06 21:38:33 <BlueMatt> at that point, you might as well take no tx and just an ioweyou
793 2012-01-06 21:38:34 <gmaxwell> What case?
794 2012-01-06 21:38:47 <BlueMatt> either one
795 2012-01-06 21:38:50 <[Tycho]> 0 confirm TXes are almost OK if all inputs are correct, no DS-TXes are known and the TX in question is accepted by my mining nodes.