1 2011-09-24 00:00:26 marf_away has quit (Ping timeout: 260 seconds)
2 2011-09-24 00:01:53 gribble has quit (Remote host closed the connection)
3 2011-09-24 00:02:14 gribble has joined
4 2011-09-24 00:03:14 Gekz_ has quit (Read error: Operation timed out)
5 2011-09-24 00:04:55 Gekz has joined
6 2011-09-24 00:05:20 tcoppi has quit (Ping timeout: 244 seconds)
7 2011-09-24 00:06:52 tcoppi has joined
8 2011-09-24 00:13:22 theorb has joined
9 2011-09-24 00:13:38 theorbtwo has quit (Ping timeout: 256 seconds)
10 2011-09-24 00:13:44 theorb is now known as theorbtwo
11 2011-09-24 00:14:18 <gmaxwell> sipa: are you really thinking about taking the minikey format?
12 2011-09-24 00:15:21 num1 has joined
13 2011-09-24 00:15:27 <sipa> gmaxwell: i wish it had resulted from more discussion
14 2011-09-24 00:16:03 <gmaxwell> I commented: https://github.com/bitcoin/bitcoin/pull/220
15 2011-09-24 00:16:18 <gmaxwell> I'm trying to not be mr. naysayer, but I'm really not enthused with it.
16 2011-09-24 00:16:46 <sipa> if you calculate how many different private keys it can reach (the 26-character version), it's 58^26/2^16, or about 2^126
17 2011-09-24 00:16:51 <sipa> eh, 2^136
18 2011-09-24 00:16:59 <gmaxwell> I don't think we should take anything with less collision resistance than our current addresses.
19 2011-09-24 00:17:38 <sipa> well, technically 256-bit EC keys only have 128-bit security anyway
20 2011-09-24 00:18:37 <gmaxwell> Going low on the collission resistance starts making it hard to convince people that there isn't peril from someone accidently generating the same key as someone else.
21 2011-09-24 00:19:10 <sipa> indeed, i wished it had at least +- the same keyspace size
22 2011-09-24 00:19:21 <sipa> but i'm not sure whether it actually decreases security
23 2011-09-24 00:19:37 <sipa> given that more than 2^128 keys are possible
24 2011-09-24 00:20:11 <sipa> so an attacker who has a public key, still needs 2^128 steps to generate a matching private key
25 2011-09-24 00:20:41 <gmaxwell> A _particular_ matching private key.
26 2011-09-24 00:20:53 <sipa> no, any
27 2011-09-24 00:21:21 <gmaxwell> You still have the "what are the chances any two users end up with the same private key" and that gives you sqrt() the space.
28 2011-09-24 00:21:44 <sipa> yes, that is relevant, but a different issue
29 2011-09-24 00:22:20 <sipa> and above 2^64 i'm not so much concerned about collisions
30 2011-09-24 00:22:27 <gmaxwell> Also, factoring a reversing ECC key is not the same task as your 2^128 operations, as you mention, doing 2^128 operations for this will break every minikey, but it would break one ecc key.
31 2011-09-24 00:22:44 <gmaxwell> sipa: length 22 is 2^58
32 2011-09-24 00:23:00 <sipa> yes, length 22 is too weak, agree
33 2011-09-24 00:24:37 <sipa> if i do 2^136 calculations (well, 2^136 EC pubkey calculations, and 717*2^136 SHA256 steps), i can build a table that cracks every mini key
34 2011-09-24 00:24:40 <sipa> true
35 2011-09-24 00:25:06 Guest54266 has quit (Read error: Operation timed out)
36 2011-09-24 00:25:57 <gmaxwell> Yea, just pointing out that the 26 character is really not limited by ECC security. (Though I agree with your view that it .. might. be okayish)
37 2011-09-24 00:26:29 <sipa> indeed, i'm definitely not arguing it is the same security level as a regular private key
38 2011-09-24 00:26:35 <gmaxwell> The strengthening is subject to internal sha256 collissions and reduces the space further, though we don't know how to make use of that at the moment it's a possible path for attack if these things are widely used.
39 2011-09-24 00:26:45 BTCTrader_ has joined
40 2011-09-24 00:26:53 <sipa> but maybe some comprimise may be acceptable (temporarily) in favor of user-friendlyness
41 2011-09-24 00:27:10 BTCTrader_ is now known as Guest82719
42 2011-09-24 00:29:10 <gmaxwell> Oh, I'd misread the code initially, it's not actually using the strenghtened version for the keygen, only the CRC check.
43 2011-09-24 00:29:58 <sipa> indeed
44 2011-09-24 00:30:16 <gmaxwell> That makes collision hunting much cheaper. I don't think it should stay that way.
45 2011-09-24 00:30:57 <da2ce7> we have 22*8 bit's of entropy for the mini-key atm, rite?
46 2011-09-24 00:31:18 <sipa> there are approximately 2^136 valid mini keys
47 2011-09-24 00:31:30 <sipa> (i'm only talking about the 26-character ones)
48 2011-09-24 00:31:49 <gmaxwell> da2ce7: no, you wish.
49 2011-09-24 00:31:50 <da2ce7> ah.. ok... maybe we should use a strong hash for the CRC check
50 2011-09-24 00:33:11 <gmaxwell> da2ce7: only 116 bits of entropy for the 22 character ones.
51 2011-09-24 00:33:20 <da2ce7> ah.
52 2011-09-24 00:33:24 <da2ce7> 26 characters at 58 possiblities per caracter?
53 2011-09-24 00:33:30 <da2ce7> *22
54 2011-09-24 00:33:35 <sipa> yes, of which 1/65536 is valid
55 2011-09-24 00:33:46 <da2ce7> oh! :(
56 2011-09-24 00:33:48 <da2ce7> that is bad.
57 2011-09-24 00:33:54 <sipa> oh wait, it's 58^25 and 58^21
58 2011-09-24 00:34:00 <sipa> the first character is S
59 2011-09-24 00:34:19 <sipa> so 107 bits of entropy or 130
60 2011-09-24 00:34:37 karnac has joined
61 2011-09-24 00:35:00 <da2ce7> 128bit strong entropy should 'be enougth' afaik.
62 2011-09-24 00:35:31 <gmaxwell> oh I thought it was 7 bits of typo-resistance.
63 2011-09-24 00:35:44 <sipa> not sure where he gets that
64 2011-09-24 00:36:01 <sipa> the first test checks for a 0-byte after one SHA256 round
65 2011-09-24 00:36:13 <sipa> the second test checks for a 0-byte after 717 SHA256 rounds
66 2011-09-24 00:36:26 <gmaxwell> right you are.
67 2011-09-24 00:36:30 <sipa> that's (slightly more than) one in 65536 that succeeds
68 2011-09-24 00:36:48 <gmaxwell> wow, and the first one fails so fast too.. ugh.
69 2011-09-24 00:37:12 <gmaxwell> that also means its checking that keys have a particular form.
70 2011-09-24 00:37:22 <sipa> not really
71 2011-09-24 00:37:35 <sipa> the key is SHA256(base)
72 2011-09-24 00:38:00 <sipa> the condition is SHA256(base+'?')[0] = 0, and SHA256^717(base+'?')[0] = 0
73 2011-09-24 00:38:00 <da2ce7> why don't we just take the first 4 characters of the 1000th round of the sha256 of the first 22 character?
74 2011-09-24 00:38:07 <da2ce7> then make a 26 character address?
75 2011-09-24 00:38:40 <gmaxwell> sipa: oh it's not because of the '?' okay.
76 2011-09-24 00:38:41 <da2ce7> *min-private key
77 2011-09-24 00:39:04 <gmaxwell> Still, that still cuts 8 bits off the search space fast.
78 2011-09-24 00:39:54 <sipa> anyway, if you try all 58^25 (=2^146) keys, and one SHA256 for each, you have a table that cracks every minikey
79 2011-09-24 00:39:58 <sipa> that is not a problem
80 2011-09-24 00:40:01 erus` has quit (Remote host closed the connection)
81 2011-09-24 00:40:10 <sipa> 2^146 is more than enough
82 2011-09-24 00:40:34 surikator has joined
83 2011-09-24 00:40:55 <sipa> right?
84 2011-09-24 00:41:02 <da2ce7> we should be aiming for a mini-private key of (128 bit entropy) + (xyz key check)
85 2011-09-24 00:41:29 <gmaxwell> da2ce7: there simply isn't room for that, otherwise you wouldn't need any mini at all.
86 2011-09-24 00:41:32 <sipa> i'm not convinced a slow validness checks helps for anything
87 2011-09-24 00:43:07 <sipa> in that case, i'd do PBKDF2 for keygen - 21 characters code @ base58, plus let's say a base58 3-character CRC
88 2011-09-24 00:43:14 <sipa> that's 24 characters
89 2011-09-24 00:43:52 <da2ce7> 22 char base58, + as many characters you want check.
90 2011-09-24 00:44:03 <sipa> 22, indeed
91 2011-09-24 00:44:27 <da2ce7> aka, if you have 26 characters it takes the first 4 characters of the 1000th round of the sha256 of the fist 22.
92 2011-09-24 00:44:27 <sipa> the problem is that casascius is already producing his coins using his mini-key format
93 2011-09-24 00:44:56 <gmaxwell> sipa: with 26 character, once there are at 4.3e19 keys in existance the chance of a random hit becomes 50% ... Thats really not all that great.
94 2011-09-24 00:45:00 <sipa> so there may be alternatives, but going for the same format will only be confusing
95 2011-09-24 00:45:06 <gmaxwell> sipa: he's also producing then with the 22 digit version, no?
96 2011-09-24 00:45:11 <sipa> yes
97 2011-09-24 00:45:18 <gmaxwell> I think we agree that the 22 digit version is outright unacceptable.
98 2011-09-24 00:45:54 <da2ce7> how many digets in base 58 do you need to get 128 bit entropy?
99 2011-09-24 00:46:17 <sipa> there are two issues: the chance for random occuring collisions
100 2011-09-24 00:46:36 <sipa> and the amount of work it takes to build a table to crack them all
101 2011-09-24 00:47:13 karnac has quit (Quit: karnac)
102 2011-09-24 00:47:23 <sipa> even the 22 character version takes almost 2^128 iterations to build that table
103 2011-09-24 00:47:32 <sipa> (of SHA256 steps)
104 2011-09-24 00:47:58 <sipa> that is no issue
105 2011-09-24 00:48:26 <da2ce7> the other symple option is to provide a 'prefix option'
106 2011-09-24 00:48:27 <gmaxwell> There is the issue half way between the two, which is that as more keys exist a partial table has more chances of success.
107 2011-09-24 00:48:42 <da2ce7> aka a mini key can be something like Cameron:(22chars)
108 2011-09-24 00:49:09 <da2ce7> or (BitBill1:(22char code):CRC
109 2011-09-24 00:49:20 <gmaxwell> da2ce7: 22, but his 22 version loses a digit to constant value and 16 bits of entropy due to checking for errors.
110 2011-09-24 00:49:22 <da2ce7> where the prefix is included in the hash
111 2011-09-24 00:49:31 <sipa> so the problem is random collisions, which will (for the 22 character version) start occuring after 2^107 generated keys
112 2011-09-24 00:49:41 <sipa> tbh, i don't think that's a problem either
113 2011-09-24 00:49:47 <sipa> eh
114 2011-09-24 00:49:55 <sipa> 2^53
115 2011-09-24 00:50:00 <gmaxwell> You're doing the math wrong. 50% on random hits is sqrt(space)
116 2011-09-24 00:50:03 <gmaxwell> right.
117 2011-09-24 00:50:05 <sipa> yes, i know
118 2011-09-24 00:50:39 <sipa> hmmm
119 2011-09-24 00:51:26 Guest82719 has quit (Quit: Guest82719)
120 2011-09-24 00:51:42 <gmaxwell> I don't think we should want bitcoin to be associated with security that weak. :-/
121 2011-09-24 00:51:46 <da2ce7> well, just have a mini-key that don't loose entropy from the CRC. make the CRC just an truncated hash of the mini-key.
122 2011-09-24 00:52:03 <gmaxwell> da2ce7: you're asking for the impossible.
123 2011-09-24 00:52:12 <da2ce7> hmmm?
124 2011-09-24 00:52:12 <gmaxwell> You always lose entropy from a check value no matter how you do it.
125 2011-09-24 00:52:23 <gmaxwell> The way it's being done here is somewhat smart, in fact.
126 2011-09-24 00:52:35 <da2ce7> no... the check ADDS characters, it dosn't replace them
127 2011-09-24 00:52:36 <gmaxwell> (though it's few enough iterations to hardly matter!)
128 2011-09-24 00:52:44 <da2ce7> aka 22, characters without check.
129 2011-09-24 00:52:52 <da2ce7> 26 with a 4character check.
130 2011-09-24 00:53:01 <da2ce7> that wouldn't reduce the entropy.
131 2011-09-24 00:53:02 <gmaxwell> da2ce7: thats less secure than 26 with no check.
132 2011-09-24 00:53:21 <da2ce7> gmaxwell, of-course, but it is a tradeoff.
133 2011-09-24 00:53:45 <gmaxwell> Right, it's always a reduction over the space you could have without one. It doesn't matter how you get it.
134 2011-09-24 00:53:57 <da2ce7> providing we always have a 22 character high-entropy base, it should be fine.
135 2011-09-24 00:54:09 <sipa> generating 2^53 minikeys requires: (65536*1 + 256*717 + 1)*2^53 SHA256 steps, and 2^53 EC multiplications
136 2011-09-24 00:54:42 imsaguy has quit (Ping timeout: 260 seconds)
137 2011-09-24 00:55:24 <sipa> the bitcoin network at its current speed does that amount of SHA256 steps in 5 years
138 2011-09-24 00:56:15 <gmaxwell> the ec multiples are costly on current processors, but they're not bad in terms of gates.
139 2011-09-24 00:56:15 <da2ce7> sipa, we need to expect that there is going to be fast asic miners in the future... maybe the network will get 1000x faster.
140 2011-09-24 00:56:16 <da2ce7> or more.
141 2011-09-24 00:56:38 <gmaxwell> (cheaper than sha-256)
142 2011-09-24 00:57:01 <sipa> but i'm not sure this is a fair calculation either
143 2011-09-24 00:57:07 <gmaxwell> (then again, everything in cheaper than sha256 in terms of gates, bastard algorithim)
144 2011-09-24 00:57:23 <gmaxwell> It's not, you'll mostly be hitting yourselfâ
145 2011-09-24 00:57:31 asuk has quit (Ping timeout: 248 seconds)
146 2011-09-24 00:57:36 <gmaxwell> which _is_ an attack, but not a super terrible one.
147 2011-09-24 00:57:40 <sipa> you'd need a way of exploiting having two minikeys that result in the same private key
148 2011-09-24 00:57:49 <gmaxwell> Right.
149 2011-09-24 00:57:52 <sipa> which is, afaik, useless
150 2011-09-24 00:58:09 <da2ce7> I say we make a prefix, that would solve most of the issues.
151 2011-09-24 00:58:27 <da2ce7> it means that we are salting all of the mini-keys.
152 2011-09-24 00:58:41 <gmaxwell> But what happens if there are 2^30 minikeys in existance (because this schmem becomes very popular)... then you generate 2^50, what are the odds you hit someone elses minikey?
153 2011-09-24 00:58:42 <sipa> that's not more useful then making them longer
154 2011-09-24 00:58:58 <gmaxwell> da2ce7: if you have the room to make them longer then for goddsake, make them longer! :)
155 2011-09-24 00:59:07 <sipa> gmaxwell: 1-exp(2*d/m^2)
156 2011-09-24 00:59:10 pointbiz has joined
157 2011-09-24 00:59:20 <sipa> wait
158 2011-09-24 00:59:40 <sipa> that formula won't help you
159 2011-09-24 01:00:21 <da2ce7> gmaxwell, as the prefix can be easly remembered, and not seceret, it is very different.
160 2011-09-24 01:00:25 imsaguy has joined
161 2011-09-24 01:00:49 <sipa> you're talking about the scratchcard problem
162 2011-09-24 01:01:00 <sipa> where the space under the scratch area is limited
163 2011-09-24 01:01:13 <sipa> there is makes sense to put part of it outside of the scratch area
164 2011-09-24 01:01:29 <sipa> here the problem is really just the available space for everything
165 2011-09-24 01:02:04 <gmaxwell> Which will probably lose its problem status faster than we'll be able to abandon the keys. :-/
166 2011-09-24 01:02:27 <sipa> if there are 2^30 minikeys in existance (out of 2^123 possible ones), each key you generate has a chance of (2^-93) of matching an existing one
167 2011-09-24 01:02:39 <da2ce7> it means that if bitbill had a golbal prefix of 'bitbill' then gobal attacks aganst the min-keys would have to just focus on 'one group of the keys'
168 2011-09-24 01:02:47 <gmaxwell> I meanâ you can already make QR codes that hold the full 256 bits+check just fine....
169 2011-09-24 01:03:31 <sipa> generating 2^50 of those, gets you 1-(1-2^-93)^50 chance of finding a match
170 2011-09-24 01:04:17 <gmaxwell> yea, so about 9e-13 ... not bleeding awful, but not great either.
171 2011-09-24 01:04:43 <sipa> heh what am i saying
172 2011-09-24 01:04:43 <gmaxwell> Though funny, if you remove the strenghtening it's a lot worseâ as 2^64 tries would be more reasonable.
173 2011-09-24 01:04:56 <sipa> 1-(1-2^-93)^(2^50)
174 2011-09-24 01:06:55 da2ce7_ has joined
175 2011-09-24 01:06:55 <da2ce7_> ok... I'm off to sleep. good work guys
176 2011-09-24 01:07:09 zapnap has quit (Remote host closed the connection)
177 2011-09-24 01:08:46 <da2ce7_> gotta come up with min-key format that is 'secure enougth' maybe just something as making it rarther expencive to hash, aka, make a 1MB aes psudo random number from the min-key, then hash that 1000 times... or something. is the best option to make a short key 'strong-ish'
178 2011-09-24 01:09:12 <sipa> that's 1.1e-13 if my math is right
179 2011-09-24 01:09:31 da2ce7 has quit (Ping timeout: 260 seconds)
180 2011-09-24 01:09:39 da2ce7_ is now known as da2ce7
181 2011-09-24 01:10:47 <sipa> if you want it strong, use pbkdf2 or bcrypt or scrypt for key derivation, derive 256+16 bits, and require that the last 16 ones are zero
182 2011-09-24 01:12:19 <da2ce7> ya
183 2011-09-24 01:13:39 <gmaxwell> thats what I'd prefer, though I like the idea of making it two step: N iterations for the check, M for the actual key. because of generation times you can't just afford to make it N+M to begin with.
184 2011-09-24 01:15:13 <da2ce7> well... define a format in one of those BIP things. :)
185 2011-09-24 01:15:27 <gmaxwell> No.
186 2011-09-24 01:15:32 <da2ce7> :(
187 2011-09-24 01:15:33 <da2ce7> ok
188 2011-09-24 01:15:46 <gmaxwell> I oppose formats with less than 128 bits of real entropy, and they need one smaller than that.
189 2011-09-24 01:16:14 <gmaxwell> (and I'd strongly prefer 160 bits, so we have the same collission resistance as the current addresses)
190 2011-09-24 01:16:28 <gmaxwell> so nothing I'd attach my name to would be acceptable to the people proposing this.
191 2011-09-24 01:17:09 <da2ce7> maybe we should define a 'medium private-key' aka, like a bitcoin address, but for a private key.
192 2011-09-24 01:17:52 Titeuf_87 has quit (Quit: Ex-Chat)
193 2011-09-24 01:17:52 <gmaxwell> The full private keys fit just about _everwhere_, the places they don't fit likely can't fit something with obviously safe security.
194 2011-09-24 01:18:02 <lfm> why not just give your bitcoins outright to the hackers that will find the exploits in your candy ass encryption
195 2011-09-24 01:20:31 <da2ce7> I would still like some sort of standard for 'enter entropy here' format, where I can define my own (memorized) string for my bitcoins.
196 2011-09-24 01:20:52 <da2ce7> that would be very usefull, it is easy to memorize a sill pome that you write yourself.
197 2011-09-24 01:20:56 <da2ce7> *silly
198 2011-09-24 01:21:05 <sipa> a 29x29 pixel QR code can encode a 50-character base36 string
199 2011-09-24 01:21:08 <sipa> that's 256 bits of entropy
200 2011-09-24 01:21:18 <gmaxwell> sipa: thanks for correcting by dyslexic exponents.
201 2011-09-24 01:21:51 <sipa> s/by/my/ ? ;)
202 2011-09-24 01:21:57 <gmaxwell> sipa: ::sigh:: thats what we should be using then.
203 2011-09-24 01:22:04 <gmaxwell> I speak good. No?
204 2011-09-24 01:22:06 <gmaxwell> ;)
205 2011-09-24 01:22:09 <da2ce7> lol
206 2011-09-24 01:22:27 <copumpkin> nothing wrong with sydlexia
207 2011-09-24 01:23:10 <sipa> a 25x25 pixel QR code suffices for 160 bits
208 2011-09-24 01:24:21 <sipa> and a 21x21 pixel QR code for 128 bits
209 2011-09-24 01:25:25 <gmaxwell> what about 176 bits? (160+16 bits of check)
210 2011-09-24 01:25:39 <sipa> QR codes already have reed-solomon error correction
211 2011-09-24 01:26:12 <gmaxwell> Yes, though if someone transcribes one they might typo it which could be a disaster.
212 2011-09-24 01:26:43 <gmaxwell> Hm, actually on that point, really 16 bits of check isn't enough considering how bad typoing it could be for some usecases.
213 2011-09-24 01:27:19 <gmaxwell> Though I suppose you could always ad 32bits of check when converting a QR form to a text form.
214 2011-09-24 01:27:39 karnac has joined
215 2011-09-24 01:27:43 <sipa> 25x25 suffices for 176 bits
216 2011-09-24 01:27:47 Backburn has joined
217 2011-09-24 01:28:00 <gmaxwell> and actually, typos of private keys aren't as bad as typos of addresses... since you could actually search the space of likely typos of a given key to recover coin lost to it.
218 2011-09-24 01:28:14 <gmaxwell> Cool.
219 2011-09-24 01:28:27 Cablesaurus has joined
220 2011-09-24 01:28:27 Cablesaurus has quit (Changing host)
221 2011-09-24 01:28:27 Cablesaurus has joined
222 2011-09-24 01:30:12 random_cat has quit (Remote host closed the connection)
223 2011-09-24 01:31:57 random_cat has joined
224 2011-09-24 01:33:32 ByronJohnson has joined
225 2011-09-24 01:34:21 karnac has quit (Ping timeout: 260 seconds)
226 2011-09-24 01:37:13 Cusipzzz has quit (Quit: KVIrc 4.1.1 Equilibrium http://www.kvirc.net/)
227 2011-09-24 01:40:29 <sipa> gmaxwell: if we ever move to dynamically negotiated txouts, i'd argue for using SHA256(pubkey)=X scripts, which has 256 bits of security :)
228 2011-09-24 01:40:37 <sipa> well, slightly less...
229 2011-09-24 01:42:16 <mabus> why would anybody type out a to address anyway?
230 2011-09-24 01:43:10 <sipa> no idea
231 2011-09-24 01:46:23 <gmaxwell> to copy it off paper or from a document image
232 2011-09-24 01:46:51 <gmaxwell> and even ignoring typing it, you wouldn't want a dropped or overcopied character to corrupt it.
233 2011-09-24 01:48:44 <sipa> i believe casacius is right in his comment, gmaxwell :)
234 2011-09-24 01:48:53 <sipa> our collision argument is completely wrong
235 2011-09-24 01:49:37 <sipa> we're hashing into a space of 2^256 large, so you need 2^128 attempts for a collision
236 2011-09-24 01:50:55 <gmaxwell> I don't agree.
237 2011-09-24 01:51:07 <gmaxwell> This has nothing to do with the hash operation at all.
238 2011-09-24 01:51:26 <sipa> explain
239 2011-09-24 01:51:32 <gmaxwell> How many possible keys are there? 21^58. The chance of two people getting the same key depends only on that and how many people there are.
240 2011-09-24 01:51:45 <gmaxwell> You can insert as many steps in the middle as you like.
241 2011-09-24 01:51:49 <sipa> bah
242 2011-09-24 01:51:51 <sipa> i need sleep
243 2011-09-24 01:52:07 <sipa> i forgot what we were calculating in the first place
244 2011-09-24 01:52:17 <gmaxwell> His argument is like saying that because there are 86400 seconds in the day that the normal birthday paradox example doesn't apply.
245 2011-09-24 01:52:21 <gmaxwell> :)
246 2011-09-24 01:52:43 <sipa> no, he was assuming we were talking about using a collision to attack the resulting real private keys
247 2011-09-24 01:53:03 <sipa> that is a valid attack, but unfeasible
248 2011-09-24 01:53:43 <gmaxwell> Right (well, I do wonder if there is some special structure that might arise from sha256(x+'?)[0]=0 but thats weird enough to be unlikely.
249 2011-09-24 01:53:51 <gmaxwell> )
250 2011-09-24 01:53:57 _W_ has quit (Read error: Connection reset by peer)
251 2011-09-24 01:54:13 <gmaxwell> I'll let you respond. :)
252 2011-09-24 01:54:22 <sipa> as sha256 consumes 64 bytes each round, everything goes into the same step anyway
253 2011-09-24 01:54:34 <sipa> i don't think any length extension trick is ever going to work for that
254 2011-09-24 01:59:27 <lfm> um base 58 with 21 chars would be 58^21 wouldnt it?
255 2011-09-24 02:00:28 <lfm> just 123 bits
256 2011-09-24 02:00:45 SomeoneWeirdzzzz is now known as SomeoneWeird
257 2011-09-24 02:03:10 <gmaxwell> lfm: it loses 16 bits due to error checking. (or a bit less if you're willing to make some assumptions about the cost of the hash operations)
258 2011-09-24 02:03:44 <lfm> so what is 21^58?
259 2011-09-24 02:05:00 <sipa> gmaxwell: only 7 bits
260 2011-09-24 02:05:20 <sipa> it is apparently either a 0-byte after 1 sha round, OR after 717 rounds
261 2011-09-24 02:05:25 <sipa> not both
262 2011-09-24 02:05:57 diki has joined
263 2011-09-24 02:06:13 <sipa> that corresponds to a loss of 7.00282 bits, if you calculate it precisely
264 2011-09-24 02:06:15 <gmaxwell> lfm: me typing backwards.
265 2011-09-24 02:06:16 <diki> i'd like to know what would happen if for a while, ntime was static>
266 2011-09-24 02:06:17 <lfm> if we're talking about btc addresses they are 58^34 -> 199 bits - 16 bits -> 182 bits == hash160 plus a bit
267 2011-09-24 02:06:48 <sipa> lfm: but btc addresses have less than 58^34 possibilities, and 32 bits of checking
268 2011-09-24 02:07:10 <lfm> ah ok
269 2011-09-24 02:07:10 <sipa> there's exactly 2^160 valid addresses, no need to calculate via the base58 form
270 2011-09-24 02:07:11 duck1123_ has joined
271 2011-09-24 02:07:21 <lfm> if we're talking about btc addresses they are 58^34 -> 199 bits - 32 bits -> 167 bits == hash160 plus a bit
272 2011-09-24 02:07:34 <gmaxwell> sipa: why not just take the 717 rounds &127=0? ..
273 2011-09-24 02:07:40 <gmaxwell> the two checks thing is screwey
274 2011-09-24 02:07:58 <gmaxwell> it makes reasoning about the complexity boosting harder.
275 2011-09-24 02:08:19 <sipa> it hardly helps, you'd just try all those that hash to 0 after 1 step first
276 2011-09-24 02:08:40 <sipa> but he is right that it only loses you 7 bits of entropy
277 2011-09-24 02:09:17 TransistOrg has quit (Remote host closed the connection)
278 2011-09-24 02:09:30 <gmaxwell> right, but if he only wants 7 bits of checking, why not just sha256^717(key)[0]&127==0 ?
279 2011-09-24 02:09:32 TransistOrg has joined
280 2011-09-24 02:09:42 <gmaxwell> (and 717? geesh thats a low number)
281 2011-09-24 02:09:46 <lfm> so encoding standard btc address is just as good?
282 2011-09-24 02:10:30 <gmaxwell> lfm: they want something stupidly small, otherwise there wouldn't be any issue... they'd just use >=160 bits and I wouldn't have any reason to whine.
283 2011-09-24 02:11:33 Cablesaurus has quit (Quit: Always try to be modest, and be proud about it!)
284 2011-09-24 02:11:39 <lfm> well if they want to be stupid, I cant see how we prevent them other than not joining in they're stupidity
285 2011-09-24 02:11:49 <lfm> their
286 2011-09-24 02:12:12 <gmaxwell> Not joining is important. It's the only defense we have against stupid.
287 2011-09-24 02:12:59 <lfm> or if we are evil, encourage them and exploit them
288 2011-09-24 02:13:28 Cablesaurus has joined
289 2011-09-24 02:13:28 Cablesaurus has quit (Changing host)
290 2011-09-24 02:13:28 Cablesaurus has joined
291 2011-09-24 02:14:37 slimm609 has joined
292 2011-09-24 02:15:09 roconnor has joined
293 2011-09-24 02:16:35 <roconnor> Interesting to see that this bug of ignoring one block when calcuating difficulty is exploitable.
294 2011-09-24 02:16:56 <slimm609> anyone here help out with bit-len a few months back?
295 2011-09-24 02:17:09 <lfm> bit-len?
296 2011-09-24 02:17:12 SomeoneWeird is now known as SomeoneWeirdAFK
297 2011-09-24 02:17:25 <roconnor> I guess clients need to count not confirmations but amount of work in order to determine how confirmed a transaction is.
298 2011-09-24 02:17:53 <slimm609> http://pastebin.com/raw.php?i=BUB3dygQ bit-len
299 2011-09-24 02:18:40 <lfm> roconnor: ya, that would be something to keep in mind for bitcoin alternative currencies (forks).
300 2011-09-24 02:18:54 <sipa> that doesn't need any change
301 2011-09-24 02:19:04 <sipa> confirmations is purely a local client issue
302 2011-09-24 02:19:27 <roconnor> sipa: I think that is what I said :)
303 2011-09-24 02:20:27 <lfm> significant for stuf like realcoins that do more frequent blocks
304 2011-09-24 02:20:47 <lfm> slimm609: what about it?
305 2011-09-24 02:21:00 <roconnor> sipa: I just read about this time-stamping attack. Are there any plans to fix the code to not ignore blocks?
306 2011-09-24 02:21:05 Zarutian has joined
307 2011-09-24 02:21:19 <sipa> roconnor: it has been suggested on the dev list, yes
308 2011-09-24 02:22:04 <sipa> but it would require a incompatible update, so other solutions are looked at first
309 2011-09-24 02:22:11 ByronJohnson has quit ()
310 2011-09-24 02:22:51 <roconnor> sipa: I conjecture with careful tweeking of some constants you could patch this in a way that happens to be backwards compatible with the existing chain.
311 2011-09-24 02:23:15 <sipa> how could that be?
312 2011-09-24 02:23:24 ByronJohnson has joined
313 2011-09-24 02:23:43 <sipa> nBits in block N is a pure function of the timestamps in blocks 0 though N-1
314 2011-09-24 02:24:27 <sipa> any change that takes more into account needs to have the ability to result in a different number
315 2011-09-24 02:25:12 <lfm> or needs to recognize a fixed cut-over point that is supported by the majority
316 2011-09-24 02:25:31 <roconnor> I'm thinking that you rediffne it to be a function of N-1 through 2N-1 (instead of the current N through 2N-1) but in such a way that it gives the same value as the existing nBits functions on the current blockchain unto now.
317 2011-09-24 02:25:41 <roconnor> *upto now
318 2011-09-24 02:25:52 <sipa> that's not enough
319 2011-09-24 02:26:11 <sipa> it also needs to give the same value for any possible new block using the old code
320 2011-09-24 02:26:16 <sipa> if you want backward compatibility
321 2011-09-24 02:26:20 <lfm> roconnor: there is no way to have that give "the same value as the existing nBits functions"
322 2011-09-24 02:26:22 <sipa> but maybe, just maybe
323 2011-09-24 02:26:26 <roconnor> true, there could be blockchain splits in the future.
324 2011-09-24 02:26:46 <sipa> there is an ability to fix the timestamps in the 2016*N-blocks algorithmically
325 2011-09-24 02:27:21 <roconnor> I guess a more conservative approach would be to change to mesure N-1 through 2N-1 starting at some flag block that should occur in a few months, giving a transition period for people to update.
326 2011-09-24 02:27:29 <sipa> hey, wait
327 2011-09-24 02:27:32 <sipa> a bit hacky
328 2011-09-24 02:27:47 <gmaxwell> only impose the other rule if the timestamps indicate an exploit?
329 2011-09-24 02:27:55 <roconnor> lfm: why is there no way to give the same value as the existing nBits function *on the current blockchain*?
330 2011-09-24 02:27:59 <gmaxwell> ... no, then people can still trigger a split on demand. alas.
331 2011-09-24 02:28:11 <lfm> roconnor: but that would mean the difficulty would lag the actual bitcoin mining rate even more than now
332 2011-09-24 02:28:12 <sipa> but what about just forcing blocks 2016*N to have the same timestamp as block 2016*N-1 ?
333 2011-09-24 02:28:43 <gmaxwell> it can't be the same, you mean the same +1?
334 2011-09-24 02:28:45 <sipa> so new clients would ignore blocks generated by old clients for blocks 2016*N, as their timestamp doesn't match that of the previous block
335 2011-09-24 02:28:49 <sipa> gmaxwell: yes
336 2011-09-24 02:28:52 <sipa> +1
337 2011-09-24 02:29:15 <sipa> and as soon as a majority of the miners update, the network is updated
338 2011-09-24 02:29:21 <gmaxwell> (by can't I mean can't be in all cases.. e.g. when the other was already at the median limit)
339 2011-09-24 02:29:33 <luke-jr> easy solution = clients lock-in blocks after 120 confirms
340 2011-09-24 02:29:34 <gmaxwell> That ... sounds okay to me, actually.
341 2011-09-24 02:30:18 <luke-jr> might cause chaos on testnet, though
342 2011-09-24 02:30:24 <gmaxwell> luke-jr: so we get a 24 hour transatlatnic internet outage and bitcoin is over?
343 2011-09-24 02:30:57 <luke-jr> gmaxwell: yep. lots of stuff already assumes 6 confirmations is secure
344 2011-09-24 02:30:58 <roconnor> luke-jr: unfortunately isolated and spoofed clients need the ability to reset
345 2011-09-24 02:31:07 <lfm> if anyone ever actually tries a timestamp exploit it would be pretty obvious and we could prolly patch to fix it or at least work around it pretty easy
346 2011-09-24 02:32:15 <luke-jr> gmaxwell: clients could give users a manual override function too
347 2011-09-24 02:32:28 <gmaxwell> luke-jr: 6 is still secure with a long split in the absence of malice and ~50% of the time with malice... plus you can stop/delay accepting payments. A lock in would make it all just stop working in the event of a big split.
348 2011-09-24 02:32:41 <lfm> they have a manual override now! ctrl-c or exit
349 2011-09-24 02:33:10 <roconnor> just to clairfy, this exploit is really aimed at devaluing how much a confirmation is worth, right? You can produce a lot of block, but each ...
350 2011-09-24 02:33:12 <roconnor> oh wait
351 2011-09-24 02:33:49 <roconnor> with this exploit someone could build a new chain to get all the valuable initial coins as well. (but it still requires 50%+1 of the network power)
352 2011-09-24 02:33:50 <luke-jr> gmaxwell: how about manual override required to invalidate blocks over 120 heights old, that also revoke confirmed funds you received? ;)
353 2011-09-24 02:34:17 <luke-jr> roconnor: you can always do that with over 50% hashpower
354 2011-09-24 02:34:24 <luke-jr> except for lock-ns
355 2011-09-24 02:34:26 <luke-jr> ins*
356 2011-09-24 02:34:27 <roconnor> true
357 2011-09-24 02:34:33 <lfm> ya any "fix" that has to go that far back will be serious with consequenses
358 2011-09-24 02:34:48 <gmaxwell> Hush.
359 2011-09-24 02:34:53 <gmaxwell> Sipa had a good idea.
360 2011-09-24 02:34:55 <luke-jr> I'm not really sure I understand the problem.
361 2011-09-24 02:34:56 <gmaxwell> We should do that.
362 2011-09-24 02:35:09 <luke-jr> Bitcoin is basically doomed if anyone malicious gets >50% hashpower anyway
363 2011-09-24 02:35:16 <gmaxwell> (well, we should think hard about it until we figure out why we shouldn't)
364 2011-09-24 02:35:31 <roconnor> gmaxwell: the setting of the timestamps for N-1 and N to be the same?
365 2011-09-24 02:35:48 <gmaxwell> luke-jr: it allows someone with <50% to eventually make a longer chain by fudging the timestmaps.
366 2011-09-24 02:35:51 <sipa> the only real problem with this exploit is that someone with 51% hashing power can do slightly more, namely decrease the difficulty, increasing his own mining income
367 2011-09-24 02:35:59 <sipa> right?
368 2011-09-24 02:35:59 <gmaxwell> roconnor: not the same, the same plus 1.
369 2011-09-24 02:36:14 <roconnor> plus 1 second?
370 2011-09-24 02:36:20 <gmaxwell> no. I didn't understand it what way.
371 2011-09-24 02:36:29 <lfm> sipa sure, there is several ways to do that tho of course, dont even need any timestamp exploits
372 2011-09-24 02:36:46 <luke-jr> gmaxwell: that's only because clients will accept "historical data" without checking the timestamps at all
373 2011-09-24 02:36:46 <sipa> or the same plus 5 minutes, i don't know - you need to make sure that in every case it also matches all possible previous checks
374 2011-09-24 02:36:50 <roconnor> plus 1 um nanosecond?
375 2011-09-24 02:36:55 * roconnor forgets the units used
376 2011-09-24 02:36:56 <gmaxwell> My understanding was that you can mine a fork, driving the difficutly to low low levels as you go, but still be the longer chain, and not have wacked out timestamps.
377 2011-09-24 02:37:05 <diki> i think its high time i built bitcoin on windows
378 2011-09-24 02:37:10 <diki> oh boy....
379 2011-09-24 02:37:18 <gmaxwell> luke-jr: they won't take timestaps from the far future, which is normally all thats required.
380 2011-09-24 02:37:29 <gmaxwell> They also won't take timestamps violating the median rule.
381 2011-09-24 02:37:43 <lfm> if you have 51% you can ignore all other miners and manipulate the difficulty with ease
382 2011-09-24 02:37:58 <gmaxwell> But this goofs it up because you can stick crazy timestamps in and break the median rules application because it's not ignored.
383 2011-09-24 02:38:35 <gmaxwell> lfm: no you can't.
384 2011-09-24 02:38:56 <gmaxwell> lfm: if you make the timestamps wrong enough (needed to manipulate the difficulty) your blocks will get ignored.
385 2011-09-24 02:39:53 * gmaxwell out
386 2011-09-24 02:40:06 <sipa> hmmm 4:30 am
387 2011-09-24 02:40:12 * sipa -> sleep
388 2011-09-24 02:41:54 da2ce7 has quit (Ping timeout: 244 seconds)
389 2011-09-24 02:45:13 da2ce7 has joined
390 2011-09-24 02:46:48 <roconnor> funny, I noticed this skipped block when computing timestamp thing months ago, but I wasn't smart enough to engineer an exploit. :(
391 2011-09-24 02:47:09 <roconnor> I guess the sticking point it that you still need 50%+1 attack power
392 2011-09-24 02:48:07 <lfm> ya ignoreing one block outa 2016 is not real big hole to exploit
393 2011-09-24 02:48:51 <sipa> tell that to the solidcoin people :p
394 2011-09-24 02:49:05 <sipa> oh no, the geistgeld people
395 2011-09-24 02:49:38 <sipa> which admittedly had different constants that made this attack way more powerful
396 2011-09-24 02:50:48 duck1123_ has quit (Quit: duck1123_)
397 2011-09-24 02:51:09 <lfm> sipa yup, if you wanna update difficulty more often it is relativly bigger hole
398 2011-09-24 02:51:40 <lfm> sipa I thot you went -> sleep? grin
399 2011-09-24 02:51:55 <sipa> right, i almost forgot
400 2011-09-24 02:52:59 karnac has joined
401 2011-09-24 02:53:33 HaltingState has left ("Leaving")
402 2011-09-24 02:56:45 TheSeven has quit (Disconnected by services)
403 2011-09-24 02:56:58 [7] has joined
404 2011-09-24 02:57:27 surikator has quit (Quit: Scientific discovery is just maximal compression of strings. Nothing more, nothing less.)
405 2011-09-24 03:01:53 semb has joined
406 2011-09-24 03:02:24 Kolky has quit (Quit: Bye bye!)
407 2011-09-24 03:03:22 FellowTraveler has joined
408 2011-09-24 03:05:53 Zarutian has quit (Quit: Zarutian)
409 2011-09-24 03:08:59 kjj has quit (Read error: Operation timed out)
410 2011-09-24 03:12:36 c_k has quit (Read error: Operation timed out)
411 2011-09-24 03:16:11 dikidera has joined
412 2011-09-24 03:16:14 wasabi1 has joined
413 2011-09-24 03:16:44 lfm has quit (Ping timeout: 260 seconds)
414 2011-09-24 03:17:16 devrandom has quit (Ping timeout: 248 seconds)
415 2011-09-24 03:18:29 Fairuser has joined
416 2011-09-24 03:18:54 mercora has joined
417 2011-09-24 03:19:03 mac-mini has joined
418 2011-09-24 03:19:44 vrs has joined
419 2011-09-24 03:19:50 sshc has joined
420 2011-09-24 03:22:23 wboy1 has joined
421 2011-09-24 03:22:38 huk has joined
422 2011-09-24 03:22:47 dstien has joined
423 2011-09-24 03:23:13 kjj has joined
424 2011-09-24 03:23:22 aldiyen has joined
425 2011-09-24 03:24:04 casascius has joined
426 2011-09-24 03:24:11 skeledrew has quit (Quit: Instantbird 1.1a1pre)
427 2011-09-24 03:24:27 cosurgiBL has joined
428 2011-09-24 03:26:17 cjdelisle has joined
429 2011-09-24 03:27:08 kabo69 has joined
430 2011-09-24 03:28:55 roconnor has quit (Ping timeout: 244 seconds)
431 2011-09-24 03:30:33 <CIA-101> bitcoin: Kano * rafe03c630253 cgminer/main.c: Hash is 32 bytes (64 nibbles)
432 2011-09-24 03:30:35 <CIA-101> bitcoin: Con Kolivas * r7c26948e453e cgminer/main.c: Merge pull request #50 from kanoi/kano
433 2011-09-24 03:31:03 Firefly007 has joined
434 2011-09-24 03:31:42 devrandom has joined
435 2011-09-24 03:32:45 lfm has joined
436 2011-09-24 03:33:11 sacarlson has joined
437 2011-09-24 03:38:34 roconnor has joined
438 2011-09-24 03:43:13 EvanR has joined
439 2011-09-24 03:49:35 dvide has quit ()
440 2011-09-24 03:52:22 semb has quit (Remote host closed the connection)
441 2011-09-24 03:52:46 semb has joined
442 2011-09-24 03:53:00 pickett has quit (Ping timeout: 248 seconds)
443 2011-09-24 03:56:24 [detached] has quit (Ping timeout: 260 seconds)
444 2011-09-24 03:57:48 Cory has quit (Ping timeout: 248 seconds)
445 2011-09-24 04:00:25 Cory has joined
446 2011-09-24 04:00:51 Cory is now known as Guest36073
447 2011-09-24 04:01:14 pickett has joined
448 2011-09-24 04:01:36 zamgo has joined
449 2011-09-24 04:04:34 roconnor has quit (Ping timeout: 244 seconds)
450 2011-09-24 04:12:29 cacheson has quit (Read error: Connection reset by peer)
451 2011-09-24 04:13:23 cacheson has joined
452 2011-09-24 04:26:38 ThomasV has joined
453 2011-09-24 04:30:24 Mad7Scientist has quit (Ping timeout: 244 seconds)
454 2011-09-24 04:30:37 cut has quit (Remote host closed the connection)
455 2011-09-24 04:31:14 cut has joined
456 2011-09-24 04:31:57 Mad7Scientist has joined
457 2011-09-24 04:35:55 Nesetalis has quit (Quit: <+shponka> how does one scissor with four people <+shponka> hypercube tribadism)
458 2011-09-24 04:40:28 pointbiz has left ()
459 2011-09-24 04:42:12 clr_ has quit (Ping timeout: 260 seconds)
460 2011-09-24 04:43:40 WakiMiko has quit (Ping timeout: 248 seconds)
461 2011-09-24 04:44:28 ThomasV has quit (Read error: Operation timed out)
462 2011-09-24 04:44:32 gjs278 has quit (Ping timeout: 260 seconds)
463 2011-09-24 04:47:27 Mad7Scientist has quit (Ping timeout: 244 seconds)
464 2011-09-24 04:48:23 cut has quit (Ping timeout: 260 seconds)
465 2011-09-24 04:48:33 ymirhotfoot has joined
466 2011-09-24 04:48:55 cut has joined
467 2011-09-24 04:49:36 Mad7Scientist has joined
468 2011-09-24 04:54:26 ThomasV has joined
469 2011-09-24 04:58:26 eoss has quit (Quit: Leaving)
470 2011-09-24 04:59:59 larsivi has quit (Ping timeout: 245 seconds)
471 2011-09-24 05:00:16 <dikidera> i'd like to know, is the merkle root used when generating a getwork from ALL the PENDING transactions
472 2011-09-24 05:00:27 <dikidera> or just those my client will include IF it finds a block?
473 2011-09-24 05:10:01 BurtyB has quit (Ping timeout: 256 seconds)
474 2011-09-24 05:11:56 BurtyB has joined
475 2011-09-24 05:14:52 karnac has quit (Ping timeout: 260 seconds)
476 2011-09-24 05:16:12 btc4paypaldotcom has quit (Ping timeout: 258 seconds)
477 2011-09-24 05:17:38 btc4paypaldotcom has joined
478 2011-09-24 05:18:02 TransistOrg has quit ()
479 2011-09-24 05:22:58 Nightblade has quit (Quit: leaving)
480 2011-09-24 05:23:36 tcoppi has quit (Read error: Operation timed out)
481 2011-09-24 05:28:04 Blitzboom has quit (Remote host closed the connection)
482 2011-09-24 05:28:34 Blitzboom has joined
483 2011-09-24 05:28:35 Blitzboom has quit (Changing host)
484 2011-09-24 05:28:35 Blitzboom has joined
485 2011-09-24 05:29:11 tcoppi has joined
486 2011-09-24 05:30:00 Nightblade has joined
487 2011-09-24 05:33:16 random_cat has quit (Ping timeout: 248 seconds)
488 2011-09-24 05:35:07 copumpkin is now known as Daaan__
489 2011-09-24 05:35:20 Daaan__ is now known as Daaaan_
490 2011-09-24 05:35:31 Daaaan_ is now known as Daaaaan
491 2011-09-24 05:36:16 Daaaaan is now known as daaaaaaaaaaaan
492 2011-09-24 05:39:08 imsaguy has quit (Ping timeout: 248 seconds)
493 2011-09-24 05:39:30 daaaaaaaaaaaan is now known as copumpkin
494 2011-09-24 05:40:16 t3a_ is now known as t3a
495 2011-09-24 05:46:55 random_cat has joined
496 2011-09-24 05:53:24 clr_ has joined
497 2011-09-24 06:00:50 ThomasV has quit (Ping timeout: 245 seconds)
498 2011-09-24 06:02:26 ThomasV has joined
499 2011-09-24 06:04:11 ymirhotfoot has quit (Remote host closed the connection)
500 2011-09-24 06:04:28 BurtyB has quit (Ping timeout: 260 seconds)
501 2011-09-24 06:06:14 BurtyB has joined
502 2011-09-24 06:10:54 ThomasV has quit (Read error: Operation timed out)
503 2011-09-24 06:15:28 Lopuz has joined
504 2011-09-24 06:23:41 FellowTraveler has quit (Ping timeout: 256 seconds)
505 2011-09-24 06:27:09 copumpkin has quit (Ping timeout: 248 seconds)
506 2011-09-24 06:27:35 copumpkin has joined
507 2011-09-24 06:29:16 fnord0 has joined
508 2011-09-24 06:35:24 LightRider has quit (Read error: Connection reset by peer)
509 2011-09-24 06:36:29 LightRider has joined
510 2011-09-24 06:45:38 Guest9137 has joined
511 2011-09-24 06:45:43 Guest9137 is now known as Keefe
512 2011-09-24 06:48:03 EPiSKiNG has quit (Ping timeout: 256 seconds)
513 2011-09-24 07:00:13 BurtyB has quit (Ping timeout: 248 seconds)
514 2011-09-24 07:02:16 KArmitt has joined
515 2011-09-24 07:02:37 BurtyB has joined
516 2011-09-24 07:05:43 semb has quit (Ping timeout: 260 seconds)
517 2011-09-24 07:06:37 random_cat has quit (Ping timeout: 248 seconds)
518 2011-09-24 07:13:18 clr_ has quit (Ping timeout: 260 seconds)
519 2011-09-24 07:16:48 jimb0 has quit (Ping timeout: 260 seconds)
520 2011-09-24 07:20:29 cacheson has quit (Ping timeout: 248 seconds)
521 2011-09-24 07:23:37 jimb0 has joined
522 2011-09-24 07:26:08 random_cat has joined
523 2011-09-24 07:34:46 iocor has joined
524 2011-09-24 07:36:05 cacheson has joined
525 2011-09-24 07:36:49 amtal has quit (Quit: Lost terminal)
526 2011-09-24 07:38:11 dorje has joined
527 2011-09-24 07:42:50 ThomasV has joined
528 2011-09-24 07:43:50 <ThomasV> please update topic
529 2011-09-24 07:50:56 iocor has quit (Quit: Computer has gone to sleep.)
530 2011-09-24 07:53:10 c_k has joined
531 2011-09-24 07:59:25 EvanR has quit (Ping timeout: 248 seconds)
532 2011-09-24 07:59:57 Veladon has joined
533 2011-09-24 08:00:09 Veladon has quit (Remote host closed the connection)
534 2011-09-24 08:04:47 TD is now known as TD[gone]
535 2011-09-24 08:06:13 EvanR has joined
536 2011-09-24 08:06:40 EvanR is now known as Guest70624
537 2011-09-24 08:14:11 Guest70624 has quit (Ping timeout: 256 seconds)
538 2011-09-24 08:17:47 LightRider has quit (Ping timeout: 255 seconds)
539 2011-09-24 08:18:35 LightRider has joined
540 2011-09-24 08:18:58 SomeoneWeirdAFK is now known as SomeoneWeird
541 2011-09-24 08:20:52 EvanR_ has joined
542 2011-09-24 08:22:05 Backburn has quit (Ping timeout: 245 seconds)
543 2011-09-24 08:24:32 abragin has joined
544 2011-09-24 08:24:46 abragin has quit (Changing host)
545 2011-09-24 08:24:46 abragin has joined
546 2011-09-24 08:24:49 MobiusL has quit (Quit: Leaving)
547 2011-09-24 08:27:41 wolfspra1l has quit (Ping timeout: 248 seconds)
548 2011-09-24 08:28:29 Turingi has joined
549 2011-09-24 08:31:53 Backburn has joined
550 2011-09-24 08:35:08 AStove has joined
551 2011-09-24 08:35:08 EPiSKiNG- has joined
552 2011-09-24 08:35:08 WakiMiko has joined
553 2011-09-24 08:35:08 [detached] has joined
554 2011-09-24 08:35:08 ajp6 has joined
555 2011-09-24 08:37:43 wolfspraul has joined
556 2011-09-24 08:45:44 mosimo has joined
557 2011-09-24 08:47:25 MobiusL has joined
558 2011-09-24 08:47:25 MobiusL has quit (Changing host)
559 2011-09-24 08:47:25 MobiusL has joined
560 2011-09-24 08:50:06 asuk has joined
561 2011-09-24 08:56:20 dorje has quit (Quit: dorje)
562 2011-09-24 08:57:16 ThomasV has quit (Ping timeout: 256 seconds)
563 2011-09-24 08:58:03 Fuehrer has joined
564 2011-09-24 08:58:04 Fuehrer has quit (Changing host)
565 2011-09-24 08:58:04 Fuehrer has joined
566 2011-09-24 08:58:15 abragin has quit (Read error: No route to host)
567 2011-09-24 08:58:50 ThomasV has joined
568 2011-09-24 08:59:12 Fuehrer is now known as abragin
569 2011-09-24 09:07:49 EvanR_ is now known as EvanR
570 2011-09-24 09:07:55 EvanR has quit (Changing host)
571 2011-09-24 09:07:55 EvanR has joined
572 2011-09-24 09:19:50 zeiris has joined
573 2011-09-24 09:20:16 zeiris has quit (Client Quit)
574 2011-09-24 09:22:11 iocor has joined
575 2011-09-24 09:22:47 zeiris has joined
576 2011-09-24 09:31:25 iocor has quit (Quit: Computer has gone to sleep.)
577 2011-09-24 09:35:01 iocor has joined
578 2011-09-24 09:41:08 larsivi has joined
579 2011-09-24 09:41:09 larsivi has quit (Read error: Connection reset by peer)
580 2011-09-24 09:41:14 da2ce7 has quit (Ping timeout: 240 seconds)
581 2011-09-24 09:41:39 da2ce7 has joined
582 2011-09-24 09:44:13 marf_away has joined
583 2011-09-24 09:44:37 d33tah has joined
584 2011-09-24 09:44:41 <d33tah> sipa: you here by any chance?
585 2011-09-24 09:45:12 <d33tah> i need help implementing ECDSA_verify test code.
586 2011-09-24 09:45:48 <d33tah> (anyone else would be fine as well actually)
587 2011-09-24 09:46:42 gjs278 has joined
588 2011-09-24 09:50:37 <d33tah> i have no idea how to get an EC_KEY instance
589 2011-09-24 09:58:19 larsivi has joined
590 2011-09-24 09:59:12 piotrp has joined
591 2011-09-24 10:00:06 Daniel0108 has joined
592 2011-09-24 10:03:32 KArmitt has quit ()
593 2011-09-24 10:05:21 iocor has quit (Quit: Computer has gone to sleep.)
594 2011-09-24 10:05:39 Desala` has joined
595 2011-09-24 10:08:02 n5 has quit (Ping timeout: 255 seconds)
596 2011-09-24 10:08:14 iocor has joined
597 2011-09-24 10:11:38 Desala` has quit (Ping timeout: 255 seconds)
598 2011-09-24 10:15:48 <d33tah> atm i have it like this:
599 2011-09-24 10:15:49 <d33tah> EC_KEY *pkey = EC_KEY_new_by_curve_name(NID_secp256k1);
600 2011-09-24 10:15:56 <d33tah> but now I dunno how to get a privkey outta a public key
601 2011-09-24 10:16:07 <sipa> you can't
602 2011-09-24 10:16:21 <d33tah> so how can I verify if the signature is correct?
603 2011-09-24 10:16:27 <d33tah> (mind looking at my code?)
604 2011-09-24 10:16:46 <sipa> you verify it using the public key
605 2011-09-24 10:17:20 <d33tah> is the public key given in a normal transaction?
606 2011-09-24 10:17:48 <sipa> yes
607 2011-09-24 10:17:56 <d33tah> hm
608 2011-09-24 10:18:15 <d33tah> so to verify a signature, i need a public key and the message?
609 2011-09-24 10:18:23 _W_ has joined
610 2011-09-24 10:18:25 <d33tah> only that?
611 2011-09-24 10:18:35 <sipa> and a signature, obviously
612 2011-09-24 10:18:38 datagutt has joined
613 2011-09-24 10:18:43 <d33tah> alright
614 2011-09-24 10:19:05 <d33tah> the message is 'hash', the signature being 'pchSig', right?
615 2011-09-24 10:19:13 <sipa> yes
616 2011-09-24 10:19:29 <d33tah> so now I need the pubkey
617 2011-09-24 10:19:32 <d33tah> damnit :P
618 2011-09-24 10:19:42 <sipa> and the key is in a CKey object
619 2011-09-24 10:19:47 <d33tah> no way to extract it from the privkey, right?
620 2011-09-24 10:20:00 <sipa> sure is
621 2011-09-24 10:20:14 <d33tah> mind helping me to patch my code up?
622 2011-09-24 10:20:30 <sipa> k, show me
623 2011-09-24 10:20:42 <d33tah> http://wklej.org/id/598784/
624 2011-09-24 10:20:54 <d33tah> i know i put the privkey here, it's testnet
625 2011-09-24 10:23:37 <sipa> what is privkey?
626 2011-09-24 10:23:55 <sipa> which format?
627 2011-09-24 10:24:19 <d33tah> HexStr(vchSecret.begin(), vchSecret.end()).c_str())
628 2011-09-24 10:24:22 <d33tah> as you advised me
629 2011-09-24 10:25:22 <d33tah> i'm not sure the UnHex is perfect, but I hope so ;)
630 2011-09-24 10:25:56 <sipa> have you looked at what SetSecret() needs to do to c
631 2011-09-24 10:26:21 <sipa> to get it into an EC_KEY object?
632 2011-09-24 10:26:46 <d33tah> hmmm
633 2011-09-24 10:26:52 <d33tah> what I can see there is not optimistic
634 2011-09-24 10:27:14 <d33tah> for some reason the result of UnHex on privkey is 33, not 32 bytes long
635 2011-09-24 10:27:25 <d33tah> is BN_bin2bn OpenSSLish?
636 2011-09-24 10:28:20 <sipa> yes
637 2011-09-24 10:28:24 <d33tah> okay
638 2011-09-24 10:28:27 <d33tah> i didn't cast this one
639 2011-09-24 10:28:42 <d33tah> and does EC_KEY_regenerate_key get the pubkey from privkey?
640 2011-09-24 10:28:48 <sipa> no
641 2011-09-24 10:29:08 <sipa> it creates an ec_key from just the secret
642 2011-09-24 10:29:25 zeiris is now known as amtal
643 2011-09-24 10:29:27 <sipa> which you can use for everything
644 2011-09-24 10:29:35 <d33tah> hm, i'll try.
645 2011-09-24 10:29:52 <sipa> but to make things easy for you
646 2011-09-24 10:30:28 <sipa> use the full serialized private key (CPrivKey) instead of just the secret
647 2011-09-24 10:31:47 sprash has joined
648 2011-09-24 10:33:15 <d33tah> zsh: segmentation fault ./verify
649 2011-09-24 10:33:26 <d33tah> Program received signal SIGSEGV, Segmentation fault.
650 2011-09-24 10:33:26 <d33tah> 0xb7edae99 in BN_bin2bn () from /usr/lib/i686/cmov/libcrypto.so.0.9.8
651 2011-09-24 10:33:42 <d33tah> const char* c_privkey = privkey.c_str();
652 2011-09-24 10:33:42 <d33tah> BIGNUM *bn = BN_bin2bn((const unsigned char*)c_privkey[0],32,BN_new());
653 2011-09-24 10:33:42 <d33tah> EC_KEY_regenerate_key(pkey,bn);
654 2011-09-24 10:33:54 <d33tah> guess I messed the pointers up?
655 2011-09-24 10:34:24 <d33tah> hm, i fixed it
656 2011-09-24 10:35:12 <d33tah> ok, it doesn't return -1 anymore
657 2011-09-24 10:35:22 <d33tah> but now it doesn't seem to care if I mess the privkey or not
658 2011-09-24 10:35:27 <d33tah> mess up*
659 2011-09-24 10:35:44 <d33tah> i changed a random character inside of it and it still seems to pass
660 2011-09-24 10:35:55 da2ce7_ has joined
661 2011-09-24 10:36:03 <sipa> what does it return?
662 2011-09-24 10:36:27 da2ce7 has quit (Ping timeout: 240 seconds)
663 2011-09-24 10:36:50 <d33tah> ECDSA_verify() and ECDSA_do_verify() return 1 for a valid signature, 0 for an invalid signature and -1 on error. The error codes can be obtained by ERR_get_error(3).
664 2011-09-24 10:36:54 <d33tah> it returned 0
665 2011-09-24 10:37:00 <d33tah> so it looks like i'm prematurely happy
666 2011-09-24 10:37:04 <d33tah> want to see the code now?
667 2011-09-24 10:38:35 <sipa> 0 = incorrect signature
668 2011-09-24 10:38:44 <d33tah> yeah
669 2011-09-24 10:38:51 <d33tah> but i copied it from my debug code
670 2011-09-24 10:38:55 <d33tah> it sure is correct
671 2011-09-24 10:38:58 <d33tah> bitcoin accepted it
672 2011-09-24 10:39:00 <sipa> show me
673 2011-09-24 10:39:05 <d33tah> the debug code?
674 2011-09-24 10:39:21 <sipa> whatever code you have
675 2011-09-24 10:39:32 <d33tah> i hacked key.h like this:
676 2011-09-24 10:39:33 <d33tah> http://wklej.org/id/598789/
677 2011-09-24 10:39:42 <d33tah> and I copied the values from there to unhex
678 2011-09-24 10:39:47 <sipa> no, your own
679 2011-09-24 10:40:11 <d33tah> the one verifying?
680 2011-09-24 10:40:15 <sipa> yes
681 2011-09-24 10:40:19 <d33tah> http://wklej.org/id/598790/
682 2011-09-24 10:42:13 <sipa> why do you still call set private key yourself?
683 2011-09-24 10:42:26 <sipa> regenerate does that
684 2011-09-24 10:42:36 <d33tah> damnit
685 2011-09-24 10:42:40 <d33tah> i found another error as well :d
686 2011-09-24 10:42:47 <d33tah> unsigned long ret won't ever store -1
687 2011-09-24 10:43:11 <sipa> true
688 2011-09-24 10:43:15 <d33tah> let's try now...
689 2011-09-24 10:43:27 <d33tah> > make verify LDFLAGS="-lcrypto" && ./verify
690 2011-09-24 10:43:27 <d33tah> g++ -lcrypto verify.cpp -o verify
691 2011-09-24 10:43:27 <d33tah> Privkey is 33 bytes long.
692 2011-09-24 10:43:27 <d33tah> Woohoo! 0
693 2011-09-24 10:43:49 <d33tah> yet
694 2011-09-24 10:44:02 <d33tah> not good :p
695 2011-09-24 10:44:45 <sipa> ecdsa_verify returns an int btw
696 2011-09-24 10:44:59 <d33tah> fixed it now
697 2011-09-24 10:45:02 abragin has quit (Read error: Connection reset by peer)
698 2011-09-24 10:45:04 <d33tah> and commented the set privkey
699 2011-09-24 10:45:35 <d33tah> anyway
700 2011-09-24 10:45:42 <d33tah> the privkey shouldn't be 33 bytes, right?
701 2011-09-24 10:45:58 <sipa> your privkey variable?
702 2011-09-24 10:46:04 abragin has joined
703 2011-09-24 10:46:04 abragin has quit (Changing host)
704 2011-09-24 10:46:04 abragin has joined
705 2011-09-24 10:46:15 <d33tah> yeah
706 2011-09-24 10:46:37 <sipa> no
707 2011-09-24 10:46:55 <sipa> in unhex
708 2011-09-24 10:47:04 <sipa> you need <length
709 2011-09-24 10:47:09 <sipa> not <=
710 2011-09-24 10:47:43 <d33tah> now it's 32 bytes
711 2011-09-24 10:47:45 <d33tah> still not there
712 2011-09-24 10:50:02 rdponticelli has joined
713 2011-09-24 10:50:20 Kolky has joined
714 2011-09-24 10:50:26 <d33tah> privkey.length()=32; hash.length()=32; pchSig.length()=71
715 2011-09-24 10:50:48 <d33tah> want the current copy of my code?
716 2011-09-24 10:51:10 ThomasV has quit (Ping timeout: 248 seconds)
717 2011-09-24 10:53:44 noagendamarket has joined
718 2011-09-24 10:54:42 da2ce7_ has quit (Ping timeout: 260 seconds)
719 2011-09-24 10:57:02 Backburn has quit (Remote host closed the connection)
720 2011-09-24 10:57:13 Backburn has joined
721 2011-09-24 10:57:22 Rennex has left ()
722 2011-09-24 10:58:57 <d33tah> sipa: still any hope?
723 2011-09-24 11:00:40 abragin has quit (Read error: No route to host)
724 2011-09-24 11:00:49 abragin has joined
725 2011-09-24 11:00:49 abragin has quit (Changing host)
726 2011-09-24 11:00:49 abragin has joined
727 2011-09-24 11:02:30 noagendamarket has quit (Ping timeout: 256 seconds)
728 2011-09-24 11:05:10 sprash has quit (Quit: Ex-Chat)
729 2011-09-24 11:08:46 noagendamarket has joined
730 2011-09-24 11:20:34 ThomasV has joined
731 2011-09-24 11:25:18 erus` has joined
732 2011-09-24 11:30:05 piotrp has quit (Quit: piotrp)
733 2011-09-24 11:32:04 huk has quit ()
734 2011-09-24 11:33:49 piotrp has joined
735 2011-09-24 11:34:58 iocor has quit (Quit: Computer has gone to sleep.)
736 2011-09-24 11:36:34 <d33tah> sigh.
737 2011-09-24 11:36:43 <d33tah> looks like i have no chances :/
738 2011-09-24 11:37:34 gjs278 has quit (Ping timeout: 260 seconds)
739 2011-09-24 11:38:17 gjs278 has joined
740 2011-09-24 11:41:35 piotrp has quit (Quit: piotrp)
741 2011-09-24 11:47:47 mtrlt has joined
742 2011-09-24 11:48:18 FellowTraveler has joined
743 2011-09-24 11:48:27 <FellowTraveler> Hi all.
744 2011-09-24 11:49:42 SomeoneWeird is now known as SomeoneWeirdBRB
745 2011-09-24 11:58:37 <d33tah> sipa: if you find anything, PM user 'DeeTah', it's on my shell account
746 2011-09-24 11:58:45 <d33tah> i'd really love to set it running
747 2011-09-24 11:59:04 <sipa> d33tah: what's the current version of the code?
748 2011-09-24 12:00:30 Daniel0108 has quit (Ping timeout: 248 seconds)
749 2011-09-24 12:01:27 iocor has joined
750 2011-09-24 12:03:35 SomeoneWeirdBRB is now known as SomeoneWeird
751 2011-09-24 12:04:09 iocor has quit (Client Quit)
752 2011-09-24 12:06:57 iocor has joined
753 2011-09-24 12:06:58 iocor has quit (Changing host)
754 2011-09-24 12:06:58 iocor has joined
755 2011-09-24 12:09:29 KArmitt has joined
756 2011-09-24 12:12:16 iocor has quit (Ping timeout: 276 seconds)
757 2011-09-24 12:13:26 abragin has quit (Read error: Connection reset by peer)
758 2011-09-24 12:14:16 Nightblade has quit (Quit: Computer has gone to sleep.)
759 2011-09-24 12:14:36 abragin has joined
760 2011-09-24 12:14:39 iocor has joined
761 2011-09-24 12:14:48 abragin has quit (Changing host)
762 2011-09-24 12:14:48 abragin has joined
763 2011-09-24 12:14:49 iocor has quit (Changing host)
764 2011-09-24 12:14:49 iocor has joined
765 2011-09-24 12:15:24 glitch-mod has quit (Read error: Connection reset by peer)
766 2011-09-24 12:17:14 glitch-mod has joined
767 2011-09-24 12:19:16 Diablo-D3 has joined
768 2011-09-24 12:23:59 CaptDDL has joined
769 2011-09-24 12:24:53 abragin has quit (Read error: Connection reset by peer)
770 2011-09-24 12:25:06 CaptainDDL has quit (Ping timeout: 260 seconds)
771 2011-09-24 12:25:39 abragin has joined
772 2011-09-24 12:25:39 abragin has quit (Changing host)
773 2011-09-24 12:25:39 abragin has joined
774 2011-09-24 12:28:00 Lopuz has quit (Ping timeout: 255 seconds)
775 2011-09-24 12:32:36 ThomasV has quit (Ping timeout: 256 seconds)
776 2011-09-24 12:33:34 Sedra has quit (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com ))
777 2011-09-24 12:34:30 Sedra has joined
778 2011-09-24 12:38:27 Lopuz has joined
779 2011-09-24 12:40:59 Sedra has quit (Quit: ( Quit ))
780 2011-09-24 12:41:15 <dikidera> if bitcoin 0.4.0 uses bdb 4.8 does that mean i have to upgrade my libraries to compile?
781 2011-09-24 12:42:02 Sedra has joined
782 2011-09-24 12:43:44 ThomasV has joined
783 2011-09-24 12:44:22 FellowTraveler has quit (Quit: Leaving.)
784 2011-09-24 12:45:19 <Optimo> I was convinced before that friday sell-of dumping was a real effect previously, but in recent weeks less so. I think this might corelate with more stability overalls - a good thing. I'm not seeing friday dumping by miners any more, but maybe that's because mining became that much hard since last diff
785 2011-09-24 12:45:37 <Optimo> whoops wrong channel, sorries
786 2011-09-24 12:49:48 Daniel0108 has joined
787 2011-09-24 12:51:24 wolfspraul has quit (Ping timeout: 255 seconds)
788 2011-09-24 12:52:39 wolfspraul has joined
789 2011-09-24 12:59:18 <luke-jr> dikidera: it uses whatever bdb you link it with
790 2011-09-24 12:59:28 <luke-jr> dikidera: they just built their official binaries with 4.8
791 2011-09-24 13:07:24 agent-x has joined
792 2011-09-24 13:08:52 wardearia has quit (Ping timeout: 256 seconds)
793 2011-09-24 13:08:56 <iddo> if i wrote nonsense regarding Hash() in forum and someone wants to correct me, please do... https://bitcointalk.org/index.php?topic=45456.0
794 2011-09-24 13:09:47 Sthebig has quit (Quit: /quit)
795 2011-09-24 13:13:09 <sipa> iddo: i think the double sha256 was indeed just satoshi being cautious
796 2011-09-24 13:13:58 ThomasV has quit (Ping timeout: 256 seconds)
797 2011-09-24 13:15:37 <iddo> yeah in the old thread the posts about double-hash being less secure are wrong, i think, i.e. it's pretty much sha256 with more rounds, which should be more secure
798 2011-09-24 13:16:11 Sthebig has joined
799 2011-09-24 13:16:11 <iddo> more secure against non-bruteforce attack, if anyone ever discovers such attack
800 2011-09-24 13:16:42 <iddo> for brute force attacks i think that double-hash shouldn't matter, the difficulty would just adjust...
801 2011-09-24 13:16:51 <cjdelisle> Some people think multi iteration hashing is more prone to collisions
802 2011-09-24 13:17:00 <cjdelisle> Some people don't know what they're talking about.
803 2011-09-24 13:18:11 <iddo> as i wrote, collisions aren't relevant for bitcoin
804 2011-09-24 13:18:27 <iddo> but i don't think that argument was true anyway
805 2011-09-24 13:19:10 <cjdelisle> It would be true if the hash function itself was badly designed (IE it was not collision resistant to start with)
806 2011-09-24 13:20:31 <iddo> basically the question is how many preimages (of bounded size) exist, depending on the number of rounds of sha256
807 2011-09-24 13:20:46 <iddo> i don't think that more rounds imply more preimages
808 2011-09-24 13:21:32 <cjdelisle> btw I tried to optimize the sha implementation and I can say quite certainly that 2 rounds make optimization/cracking attempts suck.
809 2011-09-24 13:22:21 <iddo> what do you mean by cracking ? something other than brute-force ?
810 2011-09-24 13:23:15 <cjdelisle> http://pastebay.com/138988
811 2011-09-24 13:24:50 wardearia has joined
812 2011-09-24 13:25:18 <iddo> looks like brute-force, nonce always increased by 1
813 2011-09-24 13:25:35 <cjdelisle> That's mining code
814 2011-09-24 13:25:46 <cjdelisle> What I did was work on trying to make it faster
815 2011-09-24 13:25:52 <mtrlt> the same optimizations have been in place in all miners for months.
816 2011-09-24 13:25:55 <iddo> i don't claim to understand all of that source code, i was just saying that bitcoin difficulty will adjust according to most optimized miners
817 2011-09-24 13:26:21 <mtrlt> yep
818 2011-09-24 13:26:30 agent-x has left ()
819 2011-09-24 13:26:31 <cjdelisle> I had a few other optimizations which I ripped out because they used too much memory
820 2011-09-24 13:26:46 <iddo> still not sure what the word 'cracking' refers to
821 2011-09-24 13:27:14 <mtrlt> cjdelisle: what kind of optimizations?
822 2011-09-24 13:27:18 <cjdelisle> Cracking means making an attack easier than it was before.
823 2011-09-24 13:28:04 <iddo> ok but in this case you simply meant easier because it's more optimized brute-force ?
824 2011-09-24 13:28:22 <cjdelisle> That's what a crack is.
825 2011-09-24 13:28:34 <cjdelisle> If you can brute faster
826 2011-09-24 13:29:26 <iddo> for md5 for example there are better attacks than brute force
827 2011-09-24 13:29:38 brunner has quit (Ping timeout: 260 seconds)
828 2011-09-24 13:30:27 <cjdelisle> mtrlt: I was precalculating work[16] and work[17] since they only depend on mercle and ntime
829 2011-09-24 13:31:02 abragin has quit (Read error: Connection reset by peer)
830 2011-09-24 13:31:43 Kardos_ has joined
831 2011-09-24 13:31:56 abragin has joined
832 2011-09-24 13:31:56 abragin has quit (Changing host)
833 2011-09-24 13:31:56 abragin has joined
834 2011-09-24 13:32:03 <cjdelisle> mtrlt: here's the more optimized version http://pastebay.com/139221
835 2011-09-24 13:33:06 <cjdelisle> I broke something in that version though because it was kicking out wrong results sometimes. I think I broke part down at the bottom in the if statement.
836 2011-09-24 13:34:11 samthetechie has joined
837 2011-09-24 13:34:11 Kardos has quit (Ping timeout: 245 seconds)
838 2011-09-24 13:34:21 <samthetechie> Talk on Bitcoin live from London Hackspace: http://www.ustream.tv/channel/bitcoin-weekend
839 2011-09-24 13:34:24 <iddo> i wonder if some people keep their optimized miner private?
840 2011-09-24 13:34:57 <cjdelisle> some do
841 2011-09-24 13:35:10 <cjdelisle> I don't much care, I am not interested in mining per se
842 2011-09-24 13:36:01 <mtrlt> mine is optimized as far as i can optimize, and it's private. it's not any faster than any other miner tho :P
843 2011-09-24 13:36:38 <cjdelisle> why do you keep it secret?
844 2011-09-24 13:37:16 <cjdelisle> Are you afraid that someone will see it and find a way to build on your optimizations which will make them way faster than you?
845 2011-09-24 13:37:22 <mtrlt> nope
846 2011-09-24 13:37:22 <iddo> cjdelisle: what are you interested in?
847 2011-09-24 13:37:27 <mtrlt> as i said, it's not any faster than other miners
848 2011-09-24 13:37:57 <iddo> samthetechie: who is the girl talking?
849 2011-09-24 13:38:02 <cjdelisle> And who cares about 10% or 20% or even 50% faster? You can get that by runing water over your video card and overclocking it to hell anyway.
850 2011-09-24 13:38:16 <mtrlt> it'd just be a PITA to release it in a form that even stupid people could use
851 2011-09-24 13:38:42 <jix_> cjdelisle: now if you have a 50% faster mining code and use watercooling + overclocking.....
852 2011-09-24 13:38:42 <cjdelisle> I don't care about stupid people, that's why I release my optimizations with pastebay :)
853 2011-09-24 13:39:00 <mtrlt> and it has some bugs left :P
854 2011-09-24 13:39:08 <mtrlt> threads dying for no reason etc.
855 2011-09-24 13:39:14 <samthetechie> @iddo the girl is lumos
856 2011-09-24 13:39:23 <sipa> cjdelisle: double hashing does increase the chance for collisions
857 2011-09-24 13:39:26 <cjdelisle> So does the second paste, it returns bad values sometimes.
858 2011-09-24 13:39:27 <sipa> but only slightly
859 2011-09-24 13:39:51 <samthetechie> we are hanging out at #bitcoinweekend
860 2011-09-24 13:40:02 <mtrlt> cjdelisle: well at least that's easily fixable
861 2011-09-24 13:40:19 <mtrlt> i know SHA-256 in and out but am a rookie in multithreading :P
862 2011-09-24 13:40:33 <cjdelisle> I just made a mistake somewhere and/or I don't understand how cuda works
863 2011-09-24 13:40:35 <iddo> samthetechie: not mentioned here? http://wiki.london.hackspace.org.uk/view/Project:Bitcoin/Bitcoin_Weekend_2011
864 2011-09-24 13:40:43 <iddo> samthetechie: is she talking about bitcoin?
865 2011-09-24 13:40:50 <cjdelisle> I find that whenever I try to return when I find the hash, it breaks it.
866 2011-09-24 13:40:54 <iddo> ah yes talking about bitcoin now
867 2011-09-24 13:41:08 <mtrlt> use opencl. problem solved
868 2011-09-24 13:41:12 <cjdelisle> heh
869 2011-09-24 13:41:24 <cjdelisle> I have an nshittia card
870 2011-09-24 13:41:25 <mtrlt> that does not support opencl?
871 2011-09-24 13:41:34 <cjdelisle> Actually I think it does.
872 2011-09-24 13:41:43 <mtrlt> i thought opencl just uses cuda internally
873 2011-09-24 13:41:57 <cjdelisle> and I don't care about mining so I just fool around with it like this
874 2011-09-24 13:41:58 <sipa> opencl on nvidia does
875 2011-09-24 13:42:05 <mtrlt> yeah
876 2011-09-24 13:42:13 <mtrlt> cjdelisle: i care because it gives me monies
877 2011-09-24 13:42:28 <cjdelisle> Maybe I'll mine this winter if I get cold :)
878 2011-09-24 13:42:44 <mtrlt> heh
879 2011-09-24 13:42:46 <iddo> sipa: why more collisions? isn't it simply sha256 with more rounds?
880 2011-09-24 13:42:51 <mtrlt> too bad i don't pay for heating, i'd mine otherwise :p
881 2011-09-24 13:43:01 <cjdelisle> I like making things fast and I like attacking and understanding crypto.
882 2011-09-24 13:43:02 <sipa> iddo: noagendamarket
883 2011-09-24 13:43:04 <sipa> eh
884 2011-09-24 13:43:05 <sipa> iddo: no
885 2011-09-24 13:43:20 <sipa> iddo: because there are only 2^256 possible inputs to the second hashing step
886 2011-09-24 13:43:37 <sipa> and they are again mapped to 2^256 possible outputs
887 2011-09-24 13:43:46 <sipa> but there is some chance for collisions there
888 2011-09-24 13:44:27 <sipa> and as long as two inputs in that 2^256 space hash to the same value
889 2011-09-24 13:44:27 <sipa> that means one output can't occur anymore
890 2011-09-24 13:44:27 <iddo> sipa: so you don't claim more collisions assuming the original input is bounded by 256 bits ?
891 2011-09-24 13:44:27 <mtrlt> but are there two inputs like that?
892 2011-09-24 13:44:29 <cjdelisle> The reason why it introduces more collisions is because any non-perfect hash has fewer than 2^256 possible outputs.
893 2011-09-24 13:44:30 <sipa> mtrlt: statistically, some
894 2011-09-24 13:44:38 <mtrlt> yes but have any been found
895 2011-09-24 13:44:40 <sipa> cjdelisle: even a perfect one
896 2011-09-24 13:44:45 <sipa> mtrlt: irrelevant
897 2011-09-24 13:44:53 <mtrlt> why?
898 2011-09-24 13:45:04 <sipa> you can calculate it
899 2011-09-24 13:45:04 <mtrlt> i know it's hard to find one :P
900 2011-09-24 13:45:20 <cjdelisle> f(x) { return x } has an equal number of outputs as inputs.
901 2011-09-24 13:45:21 <mtrlt> and what assumptions does the calculation make?
902 2011-09-24 13:45:28 <mtrlt> that sha-256 is random?
903 2011-09-24 13:45:32 <mtrlt> which is a stupid assumption
904 2011-09-24 13:45:44 <sipa> on average, assuming a perfect hash function, there will be (1-1/e)*2^256 possible outputs
905 2011-09-24 13:45:57 <sipa> if it's less then perfect, there will probably be less
906 2011-09-24 13:45:58 <mtrlt> so it _does_ assume sha-256 is random.
907 2011-09-24 13:45:59 <vegard> mtrlt: why?
908 2011-09-24 13:46:05 <mtrlt> because it is not random :P
909 2011-09-24 13:46:11 erus` has quit (Remote host closed the connection)
910 2011-09-24 13:46:13 <Diablo-D3> sha256 isnt random
911 2011-09-24 13:46:13 <iddo> sha256 takes 512 bits input block and outputs 256 bits digest, right?
912 2011-09-24 13:46:15 <sipa> mtrlt: no, sha256 being perfect is the best case
913 2011-09-24 13:46:26 <sipa> so it's safe to analyse using that assumption
914 2011-09-24 13:46:29 <vegard> it is indistinguishable from random
915 2011-09-24 13:46:32 <Diablo-D3> iddo: no, 256 in 256 out
916 2011-09-24 13:46:36 <mtrlt> sipa: [16:35:34] <cjdelisle> f(x) { return x } has an equal number of outputs as inputs.
917 2011-09-24 13:46:41 <Diablo-D3> iddo: well, 256 in per block
918 2011-09-24 13:46:52 <sipa> mtrlt: yes, but that's a very bad hash funcion :)
919 2011-09-24 13:46:59 <sipa> mtrlt: there is always a destructive step inside
920 2011-09-24 13:47:04 <iddo> Diablo-D3: but block is 512, no?
921 2011-09-24 13:47:06 <sipa> your function doesn't have one
922 2011-09-24 13:47:08 <sipa> iddo: yes
923 2011-09-24 13:47:11 <cjdelisle> But sipa the whole thing about more collisions from multi iterations is something that needs to be treated carefully because more iterations *is* better and people will take that to mean they should not use multi iteration hashing on passwords.
924 2011-09-24 13:47:15 <Diablo-D3> iddo: no, the input isnt, the internal state is
925 2011-09-24 13:47:27 <mtrlt> sipa: and the destructive step always causes not all outputs to be used
926 2011-09-24 13:47:29 <mtrlt> ?
927 2011-09-24 13:47:33 <iddo> Diablo-D3: i think it's the other way around
928 2011-09-24 13:47:38 <sipa> Diablo-D3: input blocks to sha256 are 512 bits
929 2011-09-24 13:47:42 <Diablo-D3> iddo: I wrote a miner.
930 2011-09-24 13:47:45 <sipa> the state is 256 bits
931 2011-09-24 13:47:49 <Diablo-D3> Are you _really_ sure you want to argue this?
932 2011-09-24 13:48:16 <Diablo-D3> mtrlt: and thats not true, if theres ANY entropy lost, its a bad hash function
933 2011-09-24 13:48:16 <vegard> Diablo-D3: wikipedia says so :-P
934 2011-09-24 13:48:22 <wumpus> hash functions can be built from a block cipher too, which has no destructive step
935 2011-09-24 13:48:31 <mtrlt> Diablo-D3: yea
936 2011-09-24 13:48:35 <sipa> Diablo-D3: a hash function MUST decrease entropy
937 2011-09-24 13:48:44 <mtrlt> um
938 2011-09-24 13:48:45 <cjdelisle> ^not true
939 2011-09-24 13:48:45 <Diablo-D3> sipa: no
940 2011-09-24 13:48:54 <Diablo-D3> decreasing bits != decreasing entropy
941 2011-09-24 13:49:01 <sipa> i know what entropy means
942 2011-09-24 13:49:08 <Diablo-D3> as long as every bit effects every bit in the output, no entropy has been lost
943 2011-09-24 13:49:12 <wumpus> it does reduce the maximum entropy possible, with less bits you can have less entropy
944 2011-09-24 13:49:13 <sipa> wrong
945 2011-09-24 13:49:28 <sipa> that's avalanche effect, and it definitely causes loss of entropy
946 2011-09-24 13:49:30 <Diablo-D3> wumpus: depends how you define less
947 2011-09-24 13:49:34 <iddo> hash functions is defined as compressing the input, i think
948 2011-09-24 13:49:42 <cjdelisle> wrong
949 2011-09-24 13:49:46 <wumpus> Diablo-D3: 32 bits can have maximum 32 bits of entropy
950 2011-09-24 13:49:49 <Diablo-D3> iddo: irrecoverably compressing it, yes
951 2011-09-24 13:50:01 <vegard> hash functions decrease entropy by definition, don't they? since there are an infinite number of inputs and only a finite number of possible outputs
952 2011-09-24 13:50:05 <wumpus> Diablo-D3: otherwise you could say that reducing things to 1 bit can still maintain all the entropy :p
953 2011-09-24 13:50:06 <sipa> Diablo-D3: if i feed 2^256 possible inputs to sha256, i will get less that 2^256 different outputs
954 2011-09-24 13:50:12 <sipa> than
955 2011-09-24 13:50:13 <mtrlt> sipa: are you sure?
956 2011-09-24 13:50:16 <sipa> yes
957 2011-09-24 13:50:17 <Diablo-D3> sipa: prove it.
958 2011-09-24 13:50:18 <cjdelisle> Hash function means irreversable. Collision resistance and compression are just interesting properties of some hashes.
959 2011-09-24 13:50:20 <mtrlt> why are you sure?
960 2011-09-24 13:50:27 <mtrlt> because of the calculation that assumes sha-256 is random?
961 2011-09-24 13:50:30 <mtrlt> which is bunk
962 2011-09-24 13:50:33 <Diablo-D3> find sha256 collisions for trivial inputs.
963 2011-09-24 13:50:33 <sipa> well, i can't prove it without an example
964 2011-09-24 13:50:44 <sipa> but it would be excessively unlikely to be so
965 2011-09-24 13:50:50 <mtrlt> so you are not sure
966 2011-09-24 13:50:54 <mtrlt> 100% != 99.9%
967 2011-09-24 13:50:59 <sipa> ok, i am not sure
968 2011-09-24 13:51:08 <Diablo-D3> there is no evidence that sha256 has collisions for trivial inputs.
969 2011-09-24 13:51:11 <dikidera> i'd like to know, is the merkle root used when generating a getwork from ALL the PENDING transactions or just those my client will include IF it finds a block?
970 2011-09-24 13:51:17 <Gekz> it's mathematically improbable that sha256 will have 0 collisions
971 2011-09-24 13:51:25 <Gekz> have some asymptotes.
972 2011-09-24 13:51:26 <mtrlt> Gekz: but not impossible
973 2011-09-24 13:51:36 <sipa> assume each input is mapped to an arbitrary and independent output
974 2011-09-24 13:51:44 <sipa> in that case the birthday paradox applies
975 2011-09-24 13:51:49 <mtrlt> sipa: that assumption is bunk, i already told you
976 2011-09-24 13:51:54 <vegard> it is impossible that it has 0 collisions, due to the pidgeonhole principle
977 2011-09-24 13:52:05 <mtrlt> vegard: talking about 2^256 inputs mapping to 2^256 outputs
978 2011-09-24 13:52:08 abragin has quit (Read error: Connection reset by peer)
979 2011-09-24 13:52:31 <sipa> mtrlt: it's excessively unlikely that it makes a difference
980 2011-09-24 13:52:36 <sipa> yes sha256 is not random
981 2011-09-24 13:52:37 <wumpus> if you use a block cipher as hash, you're sure that each 256 bits input maps to a different 256 bit output
982 2011-09-24 13:52:39 <mtrlt> yes but not impossible :P
983 2011-09-24 13:52:58 <sipa> so what are you arguing about?
984 2011-09-24 13:53:07 <mtrlt> arguing for the sake of arguing
985 2011-09-24 13:53:10 <mtrlt> i like it
986 2011-09-24 13:53:14 abragin has joined
987 2011-09-24 13:53:14 abragin has quit (Changing host)
988 2011-09-24 13:53:15 abragin has joined
989 2011-09-24 13:53:16 <sipa> that the chance exist that sha256 maps 2^256 inputs to 2^256 different outputs?
990 2011-09-24 13:53:21 <mtrlt> yeah
991 2011-09-24 13:53:22 <sipa> yes, that may be so
992 2011-09-24 13:53:28 <mtrlt> it's not impossible.
993 2011-09-24 13:53:33 <sipa> but not for all possible sets of 2^256 inputs
994 2011-09-24 13:53:43 <mtrlt> obviously
995 2011-09-24 13:54:07 <iddo> so what about the 2^256 inputs with double-sha256, any argument why it implies more collisions?
996 2011-09-24 13:54:27 <mtrlt> if there is 1 collision with 1 sha256, there are more in double-sha256
997 2011-09-24 13:54:46 <sipa> iddo: ready to assume with me, that for the context of this reasoning, that sha256 is approximated by a random function?
998 2011-09-24 13:54:52 <mtrlt> :P
999 2011-09-24 13:54:59 <iddo> sipa: ok
1000 2011-09-24 13:55:03 <sipa> because mtrlt apparently isn't, which makes any reasoning useless
1001 2011-09-24 13:55:10 <sipa> ok, you know the birthday paradox?
1002 2011-09-24 13:55:12 <mtrlt> you don't have to assume that. you can assume there are collisions, for whatever reason
1003 2011-09-24 13:55:18 <iddo> sipa: yes
1004 2011-09-24 13:55:44 <sipa> so, after 2^128 different inputs, there will be a 50% chance to have found one collision already in the output
1005 2011-09-24 13:55:58 <iddo> right
1006 2011-09-24 13:56:06 <sipa> can you estimate how many you'll have found after 2^256 inputs?
1007 2011-09-24 13:56:12 <vegard> mtrlt: oh right
1008 2011-09-24 13:56:30 <sipa> the result is that there are more like 2^255 different outputs than 2^256
1009 2011-09-24 13:56:39 <iddo> 2^128 collisions?
1010 2011-09-24 13:56:48 <sipa> approximately
1011 2011-09-24 13:57:07 <sipa> iirc you get on average (1-1/e)*2^256 different outputs
1012 2011-09-24 13:57:29 <sipa> which is 2^255.33
1013 2011-09-24 13:57:55 <sipa> so double-sha256 is (probably...) more a 255.33 bit hash function than a 256-bit one
1014 2011-09-24 13:58:05 <wumpus> how many times to hash before you have approx 1 output left ? :)
1015 2011-09-24 13:58:07 <iddo> i see
1016 2011-09-24 13:58:20 <sipa> wumpus: the third hashing step decreases a lot less
1017 2011-09-24 13:58:42 <sipa> and so on
1018 2011-09-24 13:58:51 <mtrlt> i want to see a function with the amount of bits after hashing step x
1019 2011-09-24 13:59:10 <sipa> so i don't it matters much if you do 100 or 1000000 hashing steps
1020 2011-09-24 13:59:14 <sipa> in practice
1021 2011-09-24 13:59:32 <mtrlt> how would you calculate the bits after hashing step 3?
1022 2011-09-24 13:59:48 <sipa> mtrlt: i tried to calculate it, but never got to a closed formula :)
1023 2011-09-24 13:59:49 <iddo> yeah it's at least 2^256-100 etc.
1024 2011-09-24 13:59:59 <mtrlt> heh
1025 2011-09-24 14:00:43 <cjdelisle> 512 bits of input mapped to 256 bits of output must have collisions due to the butthole principle
1026 2011-09-24 14:01:04 <sipa> indeed
1027 2011-09-24 14:01:09 <mtrlt> yea
1028 2011-09-24 14:01:19 <cjdelisle> but 256 bits of input and 256 bits of constant input mapped to 256 bits of output do not have that characteristic.
1029 2011-09-24 14:01:29 <mtrlt> they don't have it necessarily
1030 2011-09-24 14:01:44 <mtrlt> they can have it.
1031 2011-09-24 14:02:02 <cjdelisle> unless the hash function has collisions within 256 bits and in that case the hash function sucks
1032 2011-09-24 14:02:14 <mtrlt> why does it suck?
1033 2011-09-24 14:02:32 <sipa> cjdelisle: on the contrary
1034 2011-09-24 14:03:08 <sipa> if it doesn't have collisions in a known set of 2^256 inputs, it has a massive (and i assume exploitable) structure
1035 2011-09-24 14:03:40 <vegard> not necessarily, I think
1036 2011-09-24 14:03:42 <iddo> why?
1037 2011-09-24 14:04:11 <vegard> you can make one-way permutations based on public-key ciphers, right
1038 2011-09-24 14:04:22 <sipa> true
1039 2011-09-24 14:04:27 <sipa> yes i may be wrong
1040 2011-09-24 14:04:28 <iddo> sipa: what do you mean by known set?
1041 2011-09-24 14:04:47 <iddo> sha256 takes 512 bit block and outputs 256 bits
1042 2011-09-24 14:05:44 <iddo> known set means 2^256 values padded with 256 const bits?
1043 2011-09-24 14:05:55 <sipa> that would be a known set yes
1044 2011-09-24 14:06:09 <iddo> and why would it imply weakness?
1045 2011-09-24 14:06:09 <sipa> but again, i may be wrong
1046 2011-09-24 14:07:19 Lopuz has quit (Ping timeout: 276 seconds)
1047 2011-09-24 14:07:32 <iddo> ahh because random function should collisions in that set due to birthday paradox?
1048 2011-09-24 14:08:04 <iddo> i see
1049 2011-09-24 14:08:24 <iddo> s/should/should have
1050 2011-09-24 14:14:07 Titeuf_87 has joined
1051 2011-09-24 14:14:40 b4epoche_ has joined
1052 2011-09-24 14:14:41 <luke-jr> O.o
1053 2011-09-24 14:15:46 * b4epoche_ hates when he comes in and sees a O.o
1054 2011-09-24 14:18:01 <Optimo> how can I trick people into spending btc on a 'jukebox' webapp
1055 2011-09-24 14:18:12 <mtrlt> make the app really good
1056 2011-09-24 14:18:20 <sipa> call yourself 'apple'
1057 2011-09-24 14:19:23 semb has joined
1058 2011-09-24 14:19:38 semb has quit (Remote host closed the connection)
1059 2011-09-24 14:20:03 semb has joined
1060 2011-09-24 14:20:08 <dikidera> i wonder if someone will make a company like Banana or Orange
1061 2011-09-24 14:20:24 <dikidera> the products, obviously, will start with 'i'
1062 2011-09-24 14:21:36 <Eliel> iBanana! :)
1063 2011-09-24 14:21:57 <b4epoche_> I guess you're all too young to remember Bloom County
1064 2011-09-24 14:21:58 abragin has quit (Read error: Connection reset by peer)
1065 2011-09-24 14:22:04 * Eliel imagines a white banana-shaped phone.
1066 2011-09-24 14:22:25 <b4epoche_> Optimo: Bloom County?
1067 2011-09-24 14:22:39 abragin has joined
1068 2011-09-24 14:22:39 abragin has quit (Changing host)
1069 2011-09-24 14:22:39 abragin has joined
1070 2011-09-24 14:24:52 <Optimo> bananaTV is software for streaming files to your AppleTV device
1071 2011-09-24 14:24:54 <Optimo> ;p
1072 2011-09-24 14:25:01 <Optimo> b4epoche what is bloom county?
1073 2011-09-24 14:26:29 Lopuz has joined
1074 2011-09-24 14:26:39 abragin has quit (Read error: Connection reset by peer)
1075 2011-09-24 14:27:24 abragin has joined
1076 2011-09-24 14:27:25 abragin has quit (Changing host)
1077 2011-09-24 14:27:25 abragin has joined
1078 2011-09-24 14:28:51 <b4epoche_> http://en.wikipedia.org/wiki/Bloom_County
1079 2011-09-24 14:29:51 <Optimo> wasn't in my sunday funnies
1080 2011-09-24 14:30:19 <b4epoche_> http://toastytech.com/guis/banana2.html
1081 2011-09-24 14:31:32 robblesz has quit (Ping timeout: 252 seconds)
1082 2011-09-24 14:33:28 robblesz has joined
1083 2011-09-24 14:41:22 TransistOrg has joined
1084 2011-09-24 14:41:23 twmz-otg has joined
1085 2011-09-24 14:42:04 <cjdelisle> http://www.betabeat.com/2011/07/28/another-midtown-restaurant-hudson-eatery-now-accepts-bitcoin/
1086 2011-09-24 14:42:33 Burgundy has joined
1087 2011-09-24 14:45:19 n5 has joined
1088 2011-09-24 14:47:03 <n5> if i have a bitcoin runing with wallet encryptio, and useing api to give all my users address to transfer fund. Without encryption if anyone else saw my config file, they where able to transfer btc trough api, is it with wallet encryption i can protect it?
1089 2011-09-24 14:47:36 <n5> i mean about server admin or smth who see source of shop
1090 2011-09-24 14:47:58 <cjdelisle> With wallet crypto, nobody can send money without the key.
1091 2011-09-24 14:48:01 Joric has joined
1092 2011-09-24 14:48:21 <cjdelisle> As far as someone stealing the wallet.dat file and attacking that directly, that is a more difficult matter.
1093 2011-09-24 14:48:42 <cjdelisle> It's all about math and how hard it is to crack, how hard the password is, etc.
1094 2011-09-24 14:49:06 wolfspra1l has joined
1095 2011-09-24 14:49:16 <cjdelisle> If your server admin is evil, then you have pretty much no chance since he can sniff passwords right off the wire as people are entering them.
1096 2011-09-24 14:50:15 <n5> yes, but i can keep on difrent server runing client
1097 2011-09-24 14:50:49 <n5> ok, thanks you, i got answer i was looking for :)
1098 2011-09-24 14:51:38 iddo has quit (Ping timeout: 252 seconds)
1099 2011-09-24 14:52:35 wolfspraul has quit (Ping timeout: 256 seconds)
1100 2011-09-24 14:57:18 karnac has joined
1101 2011-09-24 14:57:23 zapnap has joined
1102 2011-09-24 15:00:04 semb has quit (Remote host closed the connection)
1103 2011-09-24 15:00:45 semb has joined
1104 2011-09-24 15:01:46 iddo has joined
1105 2011-09-24 15:02:55 iocor has quit (Ping timeout: 248 seconds)
1106 2011-09-24 15:04:44 imsaguy has joined
1107 2011-09-24 15:04:50 imsaguy has quit (Changing host)
1108 2011-09-24 15:04:50 imsaguy has joined
1109 2011-09-24 15:06:20 iocor has joined
1110 2011-09-24 15:07:35 Lopuz has quit (Ping timeout: 260 seconds)
1111 2011-09-24 15:15:07 <semb> right now what script forms are propagated - obviously transaction to bitcoin address, but are transactions to a public key also allowed?
1112 2011-09-24 15:15:25 <semb> i.e. scriptPubKey: <pubKey> OP_CHECKSIG
1113 2011-09-24 15:15:25 <semb> scriptSig: <sig>
1114 2011-09-24 15:15:52 <semb> by 'allowed' i mean will these tx be propagated?
1115 2011-09-24 15:17:41 <tcatm> semb: yes
1116 2011-09-24 15:18:01 <semb> is it just the 2 forms?
1117 2011-09-24 15:18:13 <tcatm> that's how "IP transactions" worked
1118 2011-09-24 15:18:41 <semb> i'm thinking of a way for bitcoin URIs to be used to receive money
1119 2011-09-24 15:18:50 iddo has quit (Changing host)
1120 2011-09-24 15:18:50 iddo has joined
1121 2011-09-24 15:20:05 <tcatm> how would that work?
1122 2011-09-24 15:20:22 <semb> here's how it works - to send someone money via a URI create a new keypair, make a tx sending the money to the keypair using the "ip transaction' form.
1123 2011-09-24 15:20:48 <semb> next encode into the URI the hash of the public key, and the private key
1124 2011-09-24 15:21:03 twmz-otg has quit (Quit: twmz-otg)
1125 2011-09-24 15:21:08 piuk has joined
1126 2011-09-24 15:21:15 <semb> voila, the recipient now can find the tx, and accept the money
1127 2011-09-24 15:21:27 <semb> and the URI is not too long.
1128 2011-09-24 15:22:05 <tcatm> so the sender generates the private key?
1129 2011-09-24 15:22:11 <semb> yes
1130 2011-09-24 15:22:22 <semb> sender generates a keypair
1131 2011-09-24 15:22:43 <semb> obviously if the recipient wants to be sure the money is theirs they need to spend it immediately
1132 2011-09-24 15:22:55 zamgo has left ()
1133 2011-09-24 15:22:58 <semb> standard tx to an address owned by themselves will do
1134 2011-09-24 15:23:06 roconnor has joined
1135 2011-09-24 15:23:27 <tcatm> there must be a more elegant solution. this would essentially require two bitcoin transactions
1136 2011-09-24 15:23:28 <semb> or another 'send to ip address' tx
1137 2011-09-24 15:23:43 <semb> one to send the money, another to 'claim' it
1138 2011-09-24 15:24:39 <semb> the only other way is to communicate the address to send to to the sender, but the URI cannot do that alone without external help
1139 2011-09-24 15:25:21 piuk has quit (Ping timeout: 252 seconds)
1140 2011-09-24 15:25:23 <semb> this scheme would be useful to be able to send money via a web link, email or sms
1141 2011-09-24 15:25:25 <tcatm> sure. the url can return an address/public key
1142 2011-09-24 15:26:20 <semb> in addition the sender can reclaim the money if the recipient does not, say after a given time period, to avoid losses due to failure of communication.
1143 2011-09-24 15:26:40 <semb> I'll document this on the wiki
1144 2011-09-24 15:27:00 piuk has joined
1145 2011-09-24 15:27:09 <tcatm> have you read this https://gist.github.com/1237788 ?
1146 2011-09-24 15:29:27 <semb> reading it now
1147 2011-09-24 15:30:13 Cablesaurus has quit (Quit: Say What?)
1148 2011-09-24 15:30:26 iocor has quit (Quit: Computer has gone to sleep.)
1149 2011-09-24 15:31:32 karnac has quit (Quit: karnac)
1150 2011-09-24 15:31:58 piotrp has joined
1151 2011-09-24 15:32:46 noagendamarket has quit (Quit: Leaving)
1152 2011-09-24 15:33:18 piuk has quit (Quit: Page closed)
1153 2011-09-24 15:36:08 Internet13 has quit (Read error: Connection reset by peer)
1154 2011-09-24 15:37:41 samthetechie has left ()
1155 2011-09-24 15:38:06 Internet13 has joined
1156 2011-09-24 15:40:17 roconnor has quit (Ping timeout: 276 seconds)
1157 2011-09-24 15:42:36 btc4paypaldotcom has quit (Ping timeout: 258 seconds)
1158 2011-09-24 15:42:41 ThomasV has joined
1159 2011-09-24 15:47:58 freewil has quit (Quit: Leaving)
1160 2011-09-24 15:47:59 btc4paypaldotcom has joined
1161 2011-09-24 15:51:04 wpl has quit (Read error: Operation timed out)
1162 2011-09-24 15:51:20 marf_away has quit (Ping timeout: 260 seconds)
1163 2011-09-24 15:52:00 abragin has quit (Read error: Connection reset by peer)
1164 2011-09-24 15:52:58 abragin has joined
1165 2011-09-24 15:52:58 abragin has quit (Changing host)
1166 2011-09-24 15:52:58 abragin has joined
1167 2011-09-24 15:55:33 wpl has joined
1168 2011-09-24 15:57:41 abragin has quit (Read error: Connection reset by peer)
1169 2011-09-24 15:58:13 abragin has joined
1170 2011-09-24 15:58:13 abragin has quit (Changing host)
1171 2011-09-24 15:58:13 abragin has joined
1172 2011-09-24 16:00:02 amtal has quit (Ping timeout: 245 seconds)
1173 2011-09-24 16:00:11 amtal has joined
1174 2011-09-24 16:04:45 samthetechie has joined
1175 2011-09-24 16:04:46 <samthetechie> Vladimir Marchenko of bitcoin.org talking about mining rigs. http://www.ustream.tv/channel/bitcoin-weekend
1176 2011-09-24 16:06:13 bobke_ has joined
1177 2011-09-24 16:09:28 bobke has quit (Ping timeout: 260 seconds)
1178 2011-09-24 16:09:44 <Joric> this one? http://en.wikipedia.org/wiki/Vladimir_Marchenko
1179 2011-09-24 16:10:34 <samthetechie> yes
1180 2011-09-24 16:10:37 <Joric> naah too old
1181 2011-09-24 16:11:02 <samthetechie> oh lol
1182 2011-09-24 16:11:08 <samthetechie> hahah no he is not 90!
1183 2011-09-24 16:11:12 <samthetechie> :p
1184 2011-09-24 16:11:43 robblesz has quit (Ping timeout: 248 seconds)
1185 2011-09-24 16:12:00 <k9quaint> oh god, is vlad trying to sell gold plated mining rigs for millions of $?
1186 2011-09-24 16:12:47 random_cat has quit (Ping timeout: 248 seconds)
1187 2011-09-24 16:13:04 <Joric> "runs Marchenko Ltd which sells mining contracts, previously developed the figator.org search engine."
1188 2011-09-24 16:13:19 fnord0 has quit (Ping timeout: 248 seconds)
1189 2011-09-24 16:16:18 <samthetechie> lol
1190 2011-09-24 16:16:32 <samthetechie> @k9quaint yeah thats about right
1191 2011-09-24 16:16:32 <samthetechie> lol
1192 2011-09-24 16:16:57 <samthetechie> @Joric, that sounds like the guy
1193 2011-09-24 16:17:10 <k9quaint> I would call that guy a used car salesman, except that would be an insult to used car salesman
1194 2011-09-24 16:17:16 <k9quaint> *men
1195 2011-09-24 16:17:32 sacarlson has quit (Ping timeout: 245 seconds)
1196 2011-09-24 16:18:14 sacarlson has joined
1197 2011-09-24 16:19:03 <CIA-101> bitcoinjs/node-bitcoin-p2p: Stefan Thomas master * rfcc26dd / wscript : Fixed pkg-config detection. - http://git.io/3lfyKw
1198 2011-09-24 16:20:49 abragin has quit (Read error: Connection reset by peer)
1199 2011-09-24 16:21:24 abragin has joined
1200 2011-09-24 16:22:02 <samthetechie> @k9quaint that is mean but it made me LOL
1201 2011-09-24 16:22:57 <k9quaint> I suppose I should watch the vid before I judge, but I just ate breakfast and don't want to vomit it all over my keyboard
1202 2011-09-24 16:24:28 abragin has quit (Read error: Connection reset by peer)
1203 2011-09-24 16:24:39 abragin has joined
1204 2011-09-24 16:24:50 abragin has quit (Changing host)
1205 2011-09-24 16:24:50 abragin has joined
1206 2011-09-24 16:25:03 piotrp has quit (Quit: piotrp)
1207 2011-09-24 16:26:15 roconnor has joined
1208 2011-09-24 16:26:22 fnord0 has joined
1209 2011-09-24 16:26:46 p0s has joined
1210 2011-09-24 16:27:45 marf_away has joined
1211 2011-09-24 16:27:46 random_cat has joined
1212 2011-09-24 16:28:05 Sedra has quit (Quit: ( Quit ))
1213 2011-09-24 16:28:06 TransistOrg has quit (Remote host closed the connection)
1214 2011-09-24 16:28:24 TransistOrg has joined
1215 2011-09-24 16:30:00 Fuehrer has joined
1216 2011-09-24 16:30:00 Fuehrer has quit (Changing host)
1217 2011-09-24 16:30:00 Fuehrer has joined
1218 2011-09-24 16:30:02 twmz-otg has joined
1219 2011-09-24 16:30:11 Cusipzzz has joined
1220 2011-09-24 16:30:12 abragin has quit (Read error: No route to host)
1221 2011-09-24 16:32:14 roconnor has quit (Ping timeout: 244 seconds)
1222 2011-09-24 16:32:22 robblesz has joined
1223 2011-09-24 16:32:24 robblesz has quit (Excess Flood)
1224 2011-09-24 16:33:05 tany000 has joined
1225 2011-09-24 16:33:29 robblesz has joined
1226 2011-09-24 16:33:32 <tany000> I had a transfer that I should've recived at 160 000 blocks
1227 2011-09-24 16:33:46 <tany000> I got to 120 000 but power went down
1228 2011-09-24 16:35:03 <tany000> then when I opened the client again,the block chain count started again
1229 2011-09-24 16:35:22 <tany000> what should I do in order to get my bcs ?
1230 2011-09-24 16:36:58 <sipa> ;;bc,blocks
1231 2011-09-24 16:36:58 <gribble> 146723
1232 2011-09-24 16:37:06 <sipa> there are only 146723 blocks
1233 2011-09-24 16:37:32 <sipa> and just let it download, maybe there was a disk problem that caused corruption of your block database
1234 2011-09-24 16:37:35 <sipa> that doesn't matter
1235 2011-09-24 16:37:50 Fuehrer has quit (Read error: Connection reset by peer)
1236 2011-09-24 16:38:34 abragin has joined
1237 2011-09-24 16:38:34 abragin has quit (Changing host)
1238 2011-09-24 16:38:34 abragin has joined
1239 2011-09-24 16:40:27 <tany000> oh
1240 2011-09-24 16:42:50 tany000 has quit (Quit: Page closed)
1241 2011-09-24 16:45:51 <casascius> I published draft proposal for RPC command "sweepprivkey" at https://en.bitcoin.it/wiki/Sweepprivkey . Purpose of this command is to allow merchants to accept private keys as deposits, and this function generates and broadcasts a transaction to sweep it to the wallet or another bitcoin address in real time, without touching the local wallet or transaction history. Comments requested. If liked, this might be my next project.
1242 2011-09-24 16:46:31 abragin has quit (Read error: Connection reset by peer)
1243 2011-09-24 16:47:09 abragin has joined
1244 2011-09-24 16:47:09 abragin has quit (Changing host)
1245 2011-09-24 16:47:09 abragin has joined
1246 2011-09-24 16:49:54 <sipa> casascius: i had been thinking about something like that as an alternative for importprivkey
1247 2011-09-24 16:51:01 <sipa> that was part of the motivation for writing cwallet: allowing a second temporary wallet to be created, in which some private key(s) are imported, followed by a normal bitcoin transaction of the balance to the real wallet
1248 2011-09-24 16:51:01 ThomasV has quit (Ping timeout: 256 seconds)
1249 2011-09-24 16:51:45 <casascius> I suppose it would make importprivkey somewhat unnecessary (though I like it and use it all the time)... in the places where importprivkey makes sense, it is useful because it avoids an intermediate transaction (and fee) (and a confirmation wait) if you are just going to spend again
1250 2011-09-24 16:52:22 <sipa> i use importprivkey to move funds from one wallet to another
1251 2011-09-24 16:52:35 <sipa> that's hardly useless, but it's definitely advanced usage
1252 2011-09-24 16:52:54 <sipa> sweepprivkey as you call it is somewhat safer to use
1253 2011-09-24 16:53:22 <casascius> agreed, at least with respect to the wallet and whatever is already in it
1254 2011-09-24 16:53:52 <casascius> if sweepprivkey were standard, i almost wouldn't care if importprivkey were only available as a patch
1255 2011-09-24 16:54:05 <casascius> because the functionality useful to "joe" would be there in a relatively low risk package
1256 2011-09-24 16:54:21 <sipa> i am not convinced though whether deposits as private keys are such a good idea
1257 2011-09-24 16:54:54 <casascius> I am curious... do you consider bitbills and physical coins to be a bad idea? (they are sort of married to the ability to deposit private keys)
1258 2011-09-24 16:54:56 <sipa> it's certainly useful for scratchcards or other physical containers for bitcoins (like your coins)
1259 2011-09-24 16:55:22 <sipa> no, i love that idea :)
1260 2011-09-24 16:55:28 <casascius> That's the vast majority of the useful application... that and offline paper wallets
1261 2011-09-24 16:56:18 piotrp has joined
1262 2011-09-24 16:56:54 <casascius> As another application, it allows someone to give away bitcoins without the worry that if no one accepts them, they are gone. Example, I might leave a bitcoin on a QR code as a geocaching item (if I geocached), but if no one claimed
1263 2011-09-24 16:56:58 <casascius> it a year later, I think I'd want it back.
1264 2011-09-24 16:57:18 <sipa> though i considered transferring just a private key flawed
1265 2011-09-24 16:57:22 <sipa> *consider
1266 2011-09-24 16:57:29 <sipa> as it requires a full rescan of the block chain
1267 2011-09-24 16:57:43 <sipa> which will in time not be feasible - certainly not for an end user
1268 2011-09-24 16:57:43 <casascius> I propose a hashtable so that the rescan only happens once
1269 2011-09-24 16:58:02 <sipa> a hashtable of what? of all used addresses?
1270 2011-09-24 16:58:20 <casascius> the prefix of all used addresses, referencing all the blocks that contain them
1271 2011-09-24 16:58:32 <casascius> maybe 32 bits worth of prefix (so a few extra blocks will get scanned, no big deal)
1272 2011-09-24 16:59:06 <casascius> I believe I have one other big idea that has major real-world practical value that would also rely on that index, but will focus on that later
1273 2011-09-24 16:59:09 <imsaguy> allows for a quicker rescan/verify balance
1274 2011-09-24 16:59:49 <casascius> the way I look at it, that hashtable should be part of blkindex.dat... though I can understand not maintaining it for the 99% of people who won't use it.
1275 2011-09-24 17:00:09 <sipa> for the real-life coin issue, i believe distributing the block number that credits them (or if there is place: the txid that does) along with the key
1276 2011-09-24 17:00:16 <imsaguy> part of the reason people don't use it is because people haven't really been importing keys
1277 2011-09-24 17:00:26 <Joric> casascius, i'm working on... sweep :) in a java applet http://img831.imageshack.us/img831/9914/bitcointool201109242250.png
1278 2011-09-24 17:00:35 <imsaguy> but as things like bitbills become more popular, it'll be needed
1279 2011-09-24 17:00:37 <sipa> is easier, and viable for lightweight clients
1280 2011-09-24 17:00:39 <casascius> in-memory hashtable isn't the best long term solution either.... probably the cleanest would be a command line option that rebuilds blkindex.dat to include that index (there should already be a way to rebuild blkindex.dat anyway)
1281 2011-09-24 17:01:08 <imsaguy> there is a way to rebuild blkindex.dat... delete it :P
1282 2011-09-24 17:01:16 <Joric> unfortunately bitcoinj is too well designed everything is either private or package-only :) it's hard to construct custom transaction there
1283 2011-09-24 17:01:33 <casascius> I would be way excited to see a working sweep. Of course that's going to depend on being able to query something for all unspent transactions given an address, but from your screenshot looks you're maintaining the whole blockchain
1284 2011-09-24 17:02:09 <sipa> casascius: as i said, it's relatively easy now: create new wallet, import key, rescan, query balance, transfer
1285 2011-09-24 17:02:16 maikmerten has joined
1286 2011-09-24 17:03:00 <sipa> but the entire second-wallet-in-memory think is completely untested for now
1287 2011-09-24 17:03:04 <casascius> sipa: I agree... but mtgox isn't going to implement that on their server any time soon. If they have to create a new wallet each time joe enters a code for deposit, the complexity will ensure they never do it
1288 2011-09-24 17:03:14 <sipa> casascius: ?
1289 2011-09-24 17:03:18 <casascius> It is certainly good enough for me...
1290 2011-09-24 17:03:24 <sipa> completely in memory, temporarily
1291 2011-09-24 17:03:32 <sipa> no wallet.dat or anything
1292 2011-09-24 17:03:42 <Joric> casascius, bitcoinj maintainer just added that 'sweep' http://code.google.com/p/bitcoinj/source/browse/trunk/src/com/google/bitcoin/examples/PrivateKeys.java
1293 2011-09-24 17:03:56 <sipa> hmm, nice
1294 2011-09-24 17:04:08 <Joric> but it doesnt allow to do that without the blockchain i'm trying to implement it myself
1295 2011-09-24 17:04:22 <sipa> casascius: but again, i consider requiring a full rescan flawed
1296 2011-09-24 17:04:49 <sipa> even if you can build such a table to speed it up somewhat, it's not feasible for lightweight nodes
1297 2011-09-24 17:05:00 <casascius> if joe could go to a pawn shop and buy what amounts to a "gift card for the market place of his choice", or could easily remit to his family in Mexico etc., the world of pawn shops and check cashing places would suddenly have a huge compelling reason to sell bitcoins
1298 2011-09-24 17:05:03 <sipa> unless they can query that table somewhere
1299 2011-09-24 17:05:31 <casascius> yes, a rescan of the block chain is flawed and reason enough not to pull importprivkey into the main client in its current form in my view
1300 2011-09-24 17:05:33 <sipa> so i think distributing the block id or txid along with it more useful
1301 2011-09-24 17:05:42 <casascius> I will definitely look at the bitcoinj sweep fairly soon
1302 2011-09-24 17:06:11 <Joric> casascius, i assure you java is a way better than c# :)
1303 2011-09-24 17:06:27 <casascius> joric: i always say c# is a ripoff of java, so won't complain there
1304 2011-09-24 17:06:51 <casascius> I have to go afk for a while. See you guys later
1305 2011-09-24 17:06:56 ThomasV has joined
1306 2011-09-24 17:09:00 CaptDDL is now known as CaptainDDL
1307 2011-09-24 17:10:16 erus` has joined
1308 2011-09-24 17:12:57 copumpkin has quit (Ping timeout: 245 seconds)
1309 2011-09-24 17:13:23 copumpkin has joined
1310 2011-09-24 17:13:30 <Joric> sipa, do i absolutely need to know the hash of the source tx to build the spending transaction?
1311 2011-09-24 17:16:24 Sedra has joined
1312 2011-09-24 17:18:21 <devrandom> ;;later tell BlueMatt I am not getting the same build for wxwidgets that you have as input in your bitcoin build report
1313 2011-09-24 17:18:21 <gribble> The operation succeeded.
1314 2011-09-24 17:19:28 <devrandom> ;;later tell BlueMatt you have dfaa22b4780db1bea3b2ecb64c65109648454b9f594fa460106716d188fbec77 wxWidgets-2.9.2-x64-gitian.zip and I have 21cf67e8b45febc3536d848a1427b4dd7d3065c90c8cc8899d2c075c8c3cf69b consistently (32 bit is different too)
1315 2011-09-24 17:19:28 <gribble> The operation succeeded.
1316 2011-09-24 17:25:09 <devrandom> ;;later tell BlueMatt my build report is at https://github.com/devrandom/wxWidgets-release/tree/master/2.9.2/devrandom
1317 2011-09-24 17:25:09 <gribble> The operation succeeded.
1318 2011-09-24 17:26:11 <sipa> Joric: yes
1319 2011-09-24 17:26:21 <sipa> Joric: how else would you reference is?
1320 2011-09-24 17:26:24 <sipa> it
1321 2011-09-24 17:27:48 piotrp has quit (Quit: piotrp)
1322 2011-09-24 17:28:03 TransistOrg has quit (Remote host closed the connection)
1323 2011-09-24 17:28:16 TransistOrg has joined
1324 2011-09-24 17:28:24 tany000 has joined
1325 2011-09-24 17:29:20 <Joric> bummer, it needs blockchain to rescan knowing private key/balance is not enough
1326 2011-09-24 17:31:53 normanrichards has joined
1327 2011-09-24 17:32:24 <sipa> Joric: that's why i say you really want the block id or txid that credited the key
1328 2011-09-24 17:32:27 tcoppi has quit (Read error: Operation timed out)
1329 2011-09-24 17:32:47 tcoppi has joined
1330 2011-09-24 17:32:47 <sipa> so you can request those from the network
1331 2011-09-24 17:33:05 tcoppi has quit (Remote host closed the connection)
1332 2011-09-24 17:33:23 d33tah has quit (Ping timeout: 276 seconds)
1333 2011-09-24 17:34:20 d33tah has joined
1334 2011-09-24 17:37:29 abragin has quit (Ping timeout: 256 seconds)
1335 2011-09-24 17:39:53 manifold_ has joined
1336 2011-09-24 17:41:28 abragin has joined
1337 2011-09-24 17:41:28 abragin has quit (Changing host)
1338 2011-09-24 17:41:28 abragin has joined
1339 2011-09-24 17:42:28 freewil has joined
1340 2011-09-24 17:42:28 freewil has quit (Changing host)
1341 2011-09-24 17:42:28 freewil has joined
1342 2011-09-24 17:42:29 Lopuz has joined
1343 2011-09-24 17:42:43 tcoppi has joined
1344 2011-09-24 17:50:20 t3a has quit (Ping timeout: 260 seconds)
1345 2011-09-24 17:50:32 caedes has joined
1346 2011-09-24 17:50:32 caedes has quit (Changing host)
1347 2011-09-24 17:50:32 caedes has joined
1348 2011-09-24 17:51:08 MobiusL has quit (Read error: Connection reset by peer)
1349 2011-09-24 17:54:39 devrandom has quit (Ping timeout: 248 seconds)
1350 2011-09-24 17:57:52 abragin has quit (Read error: Connection reset by peer)
1351 2011-09-24 17:58:08 MobiusL has joined
1352 2011-09-24 17:58:22 dorje has joined
1353 2011-09-24 17:58:26 abragin has joined
1354 2011-09-24 18:00:26 devrandom has joined
1355 2011-09-24 18:01:29 semb has quit (Ping timeout: 255 seconds)
1356 2011-09-24 18:16:23 piotrp has joined
1357 2011-09-24 18:18:49 abragin has quit (Read error: Connection reset by peer)
1358 2011-09-24 18:18:57 abragin has joined
1359 2011-09-24 18:18:58 abragin has quit (Changing host)
1360 2011-09-24 18:18:58 abragin has joined
1361 2011-09-24 18:21:34 tany000 has quit (Quit: Page closed)
1362 2011-09-24 18:28:27 rdponticelli_ has joined
1363 2011-09-24 18:29:24 rdponticelli has quit (Read error: Connection reset by peer)
1364 2011-09-24 18:30:11 danbri has joined
1365 2011-09-24 18:31:11 twmz-otg has quit (Quit: twmz-otg)
1366 2011-09-24 18:33:09 Joric has quit ()
1367 2011-09-24 18:40:32 Lopuz has quit (Ping timeout: 248 seconds)
1368 2011-09-24 18:40:43 Joric has joined
1369 2011-09-24 18:46:27 karnac has joined
1370 2011-09-24 18:50:42 manifold_ has quit (Remote host closed the connection)
1371 2011-09-24 18:51:11 Guest36073 is now known as Cory
1372 2011-09-24 18:51:20 Cory has quit (Changing host)
1373 2011-09-24 18:51:20 Cory has joined
1374 2011-09-24 18:51:23 caedes has quit (Ping timeout: 276 seconds)
1375 2011-09-24 18:52:52 karnac has quit (Quit: karnac)
1376 2011-09-24 18:53:52 karnac has joined
1377 2011-09-24 19:05:58 semb has joined
1378 2011-09-24 19:06:10 asselinpaul has joined
1379 2011-09-24 19:11:14 abragin has quit (Read error: Connection reset by peer)
1380 2011-09-24 19:11:17 Fuehrer has joined
1381 2011-09-24 19:11:17 Fuehrer has quit (Changing host)
1382 2011-09-24 19:11:17 Fuehrer has joined
1383 2011-09-24 19:15:47 Joric has quit ()
1384 2011-09-24 19:18:24 Fuehrer has quit (Read error: No route to host)
1385 2011-09-24 19:19:05 Etlase has quit (Read error: Connection reset by peer)
1386 2011-09-24 19:19:36 Etlase has joined
1387 2011-09-24 19:21:34 abragin has joined
1388 2011-09-24 19:21:34 abragin has quit (Changing host)
1389 2011-09-24 19:21:34 abragin has joined
1390 2011-09-24 19:23:54 iddo has quit (Ping timeout: 276 seconds)
1391 2011-09-24 19:28:21 Andrevan has joined
1392 2011-09-24 19:32:17 asselinpaul has quit (Remote host closed the connection)
1393 2011-09-24 19:33:16 iddo has joined
1394 2011-09-24 19:39:56 <dikidera> i'd like to know, is the merkle root used when generating a getwork from ALL the PENDING transactions or just those my client will include IF it finds a block?
1395 2011-09-24 19:40:27 danbri has quit (Remote host closed the connection)
1396 2011-09-24 19:41:59 normanrichards has quit (Quit: normanrichards)
1397 2011-09-24 19:42:23 sytse has quit (Ping timeout: 244 seconds)
1398 2011-09-24 19:43:06 iocor has joined
1399 2011-09-24 19:50:54 <Diablo-D3> http://occupywallstreet.tumblr.com/post/10606910256/ows-update-march-to-union-square-reports-of-kettling
1400 2011-09-24 19:56:12 t3a has joined
1401 2011-09-24 19:59:56 <lfm> dikidera: usually that is the same but if it is different then it would only be the txn which would be included if you find a block
1402 2011-09-24 20:03:07 tany000 has joined
1403 2011-09-24 20:03:11 <tany000> ''
1404 2011-09-24 20:03:20 <tany000> ;;bitcoin
1405 2011-09-24 20:03:20 <gribble> I do not know about 'bitcoin', but I do know about these similar topics: 'freebitcoins'
1406 2011-09-24 20:03:33 <tany000> ;;blocks
1407 2011-09-24 20:03:34 <gribble> Error: "blocks" is not a valid command.
1408 2011-09-24 20:03:42 <tany000> ;;help
1409 2011-09-24 20:03:43 <gribble> The bot responds when you start a line with the ! character. A good starting point for exploring the bot is the !facts command. You can also visit the bot's website for a list of help topics and documentation: http://gribble.sourceforge.net/
1410 2011-09-24 20:03:44 <lfm> ;;bc,help
1411 2011-09-24 20:03:44 <gribble> Alias bc,24hprc, Alias bc,altprofit, Alias bc,avgprc, Alias bc,bcm, Alias bc,bitpenny, Alias bc,blocks, Alias bc,bounty, Alias bc,btceur, Alias bc,btcgbp, Alias bc,btcguild, Alias bc,btcrub, Alias bc,btcto, Alias bc,calc, Alias bc,calcd, Alias bc,channels, Alias bc,convert, Alias bc,deepbit, Alias bc,diff, Alias bc,diffchange, Alias bc,eligius, Alias bc,estimate, Alias bc,exchb, Alias bc,fx, (2 more messages)
1412 2011-09-24 20:03:47 <lfm> ;;more
1413 2011-09-24 20:03:48 <gribble> Alias bc,gen, Alias bc,gend, Alias bc,help, Alias bc,hextarget, Alias bc,intersango, Alias bc,interval, Alias bc,mtgox, Alias bc,mtgoxask, Alias bc,mtgoxbid, Alias bc,mtgoxlast, Alias bc,nethash, Alias bc,nexttarget, Alias bc,ozcoin, Alias bc,p2pool, Alias bc,p2pooldiff, Alias bc,p2poolnmc, Alias bc,p2poolsc, Alias bc,price, Alias bc,prob, Alias bc,probd, Alias bc,slushpool, Alias (1 more message)
1414 2011-09-24 20:03:50 <lfm> ;;more
1415 2011-09-24 20:03:50 <gribble> bc,spotestimate, Alias bc,stats, Alias bc,swepool, Alias bc,timetonext, Alias bc,totalbc, Alias bc,tradehill, Alias bc,wiki, and Alias bc,xau
1416 2011-09-24 20:03:54 <tany000> right thanks
1417 2011-09-24 20:04:13 <tany000> ;;blocks
1418 2011-09-24 20:04:13 <gribble> Error: "blocks" is not a valid command.
1419 2011-09-24 20:04:16 <devrandom> also /query gribble
1420 2011-09-24 20:04:22 <lfm> ;;bc,blocks
1421 2011-09-24 20:04:23 <gribble> 146741
1422 2011-09-24 20:05:27 <tany000> is there a way to get just the last 10k blocks ?
1423 2011-09-24 20:05:37 <lfm> tany000: note also you can /msg gribble commands privatly
1424 2011-09-24 20:06:04 <lfm> tany000: only if you already have the rest
1425 2011-09-24 20:06:24 <tcatm> tany000: you can download a snapshot from here http://eu1.bitcoincharts.com/blockchain/
1426 2011-09-24 20:07:40 <tany000> right..
1427 2011-09-24 20:07:52 <tany000> i got to 110k and it started getting them really slow
1428 2011-09-24 20:08:16 <lfm> ya thats prolly normal cuz they blocks get a lot bigger about then
1429 2011-09-24 20:08:28 <imsaguy> another think you can always try is connecting to the fallback nodes, they typically have faster connections
1430 2011-09-24 20:08:32 <imsaguy> thing*
1431 2011-09-24 20:12:25 <lfm> tany000: I agree it is a good idea to download the snapshot
1432 2011-09-24 20:21:54 wboy1 has quit ()
1433 2011-09-24 20:23:10 iddo has quit (Changing host)
1434 2011-09-24 20:23:10 iddo has joined
1435 2011-09-24 20:27:09 clr_ has joined
1436 2011-09-24 20:28:32 <Keefe> is there any problem using the blockchain snapshots from BC with v0.4, since i think the db version changed?
1437 2011-09-24 20:28:58 Joric has joined
1438 2011-09-24 20:29:24 <tcatm> Keefe: there shouldn't be but I'd appreciate if someone tries that
1439 2011-09-24 20:30:07 <Keefe> what's the worst case scenario?
1440 2011-09-24 20:30:19 <Keefe> if it's not loss of wallet, i'll try
1441 2011-09-24 20:31:15 <imsaguy> It was fine when I did it a few weeks ago
1442 2011-09-24 20:31:26 <Keefe> you're probably going to say i should simply backup the wallet first. but i was looking at this for a friend who is about to install bitcoin for the first time, creating a new wallet
1443 2011-09-24 20:31:27 <imsaguy> 2 weeks or so when they asked for people to try the beta
1444 2011-09-24 20:31:51 <Keefe> did they change db versions since then imsaguy?
1445 2011-09-24 20:32:37 <tcatm> I've switched from bdb 4.7 to 4.8 (with 0.4) and it worked fine with the existing wallet and blockchain
1446 2011-09-24 20:33:11 <imsaguy> the .4 beta
1447 2011-09-24 20:33:31 <imsaguy> so basically the same thing you're gonna try minus any last minute code changes
1448 2011-09-24 20:34:08 sacarlson has quit (Ping timeout: 248 seconds)
1449 2011-09-24 20:34:45 iocor has quit (Quit: Computer has gone to sleep.)
1450 2011-09-24 20:35:04 <imsaguy> Mine was on windows though
1451 2011-09-24 20:35:41 <imsaguy> but as far as I could tell, the installer doesn't touch the blockchain file, its only after you start the client
1452 2011-09-24 20:36:33 Joric has quit ()
1453 2011-09-24 20:38:14 maikmerten has quit (Quit: Leaving)
1454 2011-09-24 20:40:06 normanrichards has joined
1455 2011-09-24 20:43:39 <Keefe> thanks for the info guys :)
1456 2011-09-24 20:47:57 Fuehrer has joined
1457 2011-09-24 20:47:58 Fuehrer has quit (Changing host)
1458 2011-09-24 20:47:58 Fuehrer has joined
1459 2011-09-24 20:47:58 abragin has quit (Read error: Connection reset by peer)
1460 2011-09-24 20:49:03 sacarlson has joined
1461 2011-09-24 20:51:01 copumpkin has quit (Remote host closed the connection)
1462 2011-09-24 20:51:56 copumpkin has joined
1463 2011-09-24 20:53:06 iocor has joined
1464 2011-09-24 20:55:45 [Tycho] has joined
1465 2011-09-24 21:01:19 Xunie has joined
1466 2011-09-24 21:01:24 ThomasV has quit (Read error: Operation timed out)
1467 2011-09-24 21:10:33 clr_ has quit (Quit: Ex-Chat)
1468 2011-09-24 21:11:54 <dikidera> [22:50:12] <lfm> dikidera: usually that is the same but if it is different then it would only be the txn which would be included if you find a block <- what is the same?
1469 2011-09-24 21:15:02 <lfm> dikidera: usually the txn available is the same as the txn included in the block
1470 2011-09-24 21:16:10 <lfm> I mean like usually the client will include all the txn in the block
1471 2011-09-24 21:18:21 <tcatm> is anyone working on compacting the blockchain (= removing spent transactions and that stuff)?
1472 2011-09-24 21:18:33 <[Tycho]> Hello, tcatm.
1473 2011-09-24 21:18:49 <sipa> tcatm: i don't know of anyone who is
1474 2011-09-24 21:18:53 <phantomcircuit> tcatm, i dont think so
1475 2011-09-24 21:18:56 Blitzboom has quit (Read error: Connection reset by peer)
1476 2011-09-24 21:19:00 <[Tycho]> "OLD VERSIONS HARM THE NETWORK" - how ?
1477 2011-09-24 21:19:10 <phantomcircuit> they dont really
1478 2011-09-24 21:19:16 <lfm> I have a report that counts the number of txn that could be removed
1479 2011-09-24 21:19:59 <phantomcircuit> lfm, can i see that?
1480 2011-09-24 21:20:20 <tcatm> I'm working on a python script that can read blk0001.dat and blkindex.dat and output a new one with only the longest chain (my blk0001.dat currently has 25 chains in it).
1481 2011-09-24 21:20:40 <sipa> tcatm: that's already useful indeed
1482 2011-09-24 21:20:47 <sipa> but i doubt it will have any significant effect
1483 2011-09-24 21:20:51 <lfm> greatest chain length: 146744 blocks
1484 2011-09-24 21:21:05 <lfm> Number of spent transactions: 1144548
1485 2011-09-24 21:21:27 <lfm> ;;bc,blocks
1486 2011-09-24 21:21:27 <[Tycho]> Do someone works on headers-only version ?
1487 2011-09-24 21:21:27 <gribble> 146748
1488 2011-09-24 21:21:46 <tcatm> sipa: I want to extend it to remove older transactions so we could use it to test the client against "incomplete" blockchains (once it knows how to handle them).
1489 2011-09-24 21:21:57 <lfm> Total number of transactions: 1573692
1490 2011-09-24 21:22:13 Blitzboom has joined
1491 2011-09-24 21:22:13 Blitzboom has quit (Changing host)
1492 2011-09-24 21:22:13 Blitzboom has joined
1493 2011-09-24 21:22:44 <sipa> tcatm: once you don't have the entire blockchain anymore, you can't claim being a full client anymore
1494 2011-09-24 21:23:14 <lfm> so you could drop 1144548 of 1573692 txn according to my calculation
1495 2011-09-24 21:23:24 <sipa> lfm: that's significant indeed
1496 2011-09-24 21:23:48 <dikidera> [Tycho]:what do you mean headers only?
1497 2011-09-24 21:23:50 <tcatm> I also noticed addr.dat should be pruned from time to time. I've removed addresses with now() - nTime > 7d and it went from 24M to about 4M greatly reducing startup time
1498 2011-09-24 21:24:00 <sipa> tcatm: definitely
1499 2011-09-24 21:24:08 <[Tycho]> dikidera, i'm talking about light client.
1500 2011-09-24 21:24:11 <sipa> the whole way bitcoin handles addresses needs to be revised
1501 2011-09-24 21:24:25 <sipa> ip addresses, that is
1502 2011-09-24 21:24:36 <tcatm> yep and we should get rid of bdb or figure out what's making it so slow
1503 2011-09-24 21:25:11 <sipa> there's no point in keeping more than a few thousand IP's along
1504 2011-09-24 21:25:30 <tcatm> reading those 4MB still takes 1.5s + 0.6s for transforming them into mapAddresses
1505 2011-09-24 21:25:41 <gmaxwell> using bdb for addresses is kinda silly in any case.
1506 2011-09-24 21:25:42 <dikidera> [Tycho]:i also wish a lighter client
1507 2011-09-24 21:25:46 <dikidera> ever seen Crysis 1?
1508 2011-09-24 21:25:46 <sipa> indeed
1509 2011-09-24 21:25:50 <dikidera> It uses 1GB of ram
1510 2011-09-24 21:25:51 <[Tycho]> No.
1511 2011-09-24 21:25:53 <dikidera> Bitcoin is near it
1512 2011-09-24 21:26:08 <dikidera> lately the windows client starts faster, but...
1513 2011-09-24 21:26:13 <sipa> if we keep using bdb for addresses, i'd just store them in one single record
1514 2011-09-24 21:26:26 <dikidera> If someone actually improves that
1515 2011-09-24 21:26:27 <[Tycho]> I heard that Windows Vista or Seven wants 15 Gb of disk space to install.
1516 2011-09-24 21:26:31 <dikidera> then i can import addresses faster
1517 2011-09-24 21:26:37 <dikidera> [Tycho]:true
1518 2011-09-24 21:26:44 <[Tycho]> That's just insane.
1519 2011-09-24 21:26:44 <tcatm> sipa: or use ip+port as the key?
1520 2011-09-24 21:27:01 <dikidera> i feel its ok
1521 2011-09-24 21:27:03 <[Tycho]> I can't imagine WHAT can be in those 15 Gbs.
1522 2011-09-24 21:27:03 <sipa> tcatm: do you ever need to look them up based on ip+port?
1523 2011-09-24 21:27:11 <sipa> i don't think so
1524 2011-09-24 21:27:29 <[Tycho]> dikidera, "light client" is the one that doesn't store/needs full chain to operate.
1525 2011-09-24 21:27:30 <dikidera> [Tycho]:DLLs
1526 2011-09-24 21:27:40 <dikidera> [Tycho]:im also in for that
1527 2011-09-24 21:27:44 <tcatm> yes. when you receive new addresses you need to check whether you know about it already and maybe update nTime
1528 2011-09-24 21:27:48 <dikidera> but i mostly need a faster wallet updater
1529 2011-09-24 21:27:53 <sipa> right, true
1530 2011-09-24 21:27:55 <dikidera> when i import thousands of addresses its slow
1531 2011-09-24 21:28:13 <[Tycho]> Hmm, I should make some improvements to my bitcoinds, btw...
1532 2011-09-24 21:28:25 <dikidera> do you know C++?
1533 2011-09-24 21:28:26 <dikidera> i dont :D
1534 2011-09-24 21:28:32 <[Tycho]> No, only C.
1535 2011-09-24 21:28:39 <dikidera> ...then how?
1536 2011-09-24 21:28:45 <gmaxwell> [Tycho]: Are you still running .21 based bitcoinds that randomly hang up on nodes?
1537 2011-09-24 21:28:45 <dikidera> bitcoin is c++
1538 2011-09-24 21:29:08 piotrp has quit (Quit: piotrp)
1539 2011-09-24 21:29:12 <[Tycho]> gmaxwell, my bitcoinds aren't hanging.
1540 2011-09-24 21:29:28 <sipa> 0.3.20-0.3.23 drop connections when nodes download too much
1541 2011-09-24 21:29:43 <gmaxwell> [Tycho]: I didn't say 'hanging' I said "hang up on".
1542 2011-09-24 21:29:45 <sipa> which most likely happens for anyone doing an initial block chain db
1543 2011-09-24 21:30:16 <gmaxwell> Which is a bit opaque, I should have said frequently close connections.
1544 2011-09-24 21:30:33 <[Tycho]> Didn't checked that.
1545 2011-09-24 21:30:55 <sipa> i believe that is what the topic refers to primarily
1546 2011-09-24 21:31:42 <[Tycho]> The thing that I don't like currently is how bitcoind starts working SLOWLY after wallet.dat goes over 1 Gb and I have to purge it.
1547 2011-09-24 21:31:52 <dikidera> what?
1548 2011-09-24 21:31:57 <dikidera> how do you purge a wallet?
1549 2011-09-24 21:32:05 <gmaxwell> sipa: that and the old fee rules that make new low priority txn with 0.0005 fees somewhat less reliable.
1550 2011-09-24 21:32:14 <sipa> gmaxwell: oh, sure, of course
1551 2011-09-24 21:32:51 <[Tycho]> dikidera, delete it and create a new one.
1552 2011-09-24 21:33:09 <[Tycho]> So now I want to resolve this issue.
1553 2011-09-24 21:33:32 <gmaxwell> I'm not quite sure how your wallet.dat is getting that big.
1554 2011-09-24 21:33:46 <gmaxwell> I had a wallet with every bitcoin txn in it, and I think it wasn't much bigger than that.
1555 2011-09-24 21:33:57 <[Tycho]> gmaxwell, do you imagine HOW many payments deepbit does daily ? :)
1556 2011-09-24 21:34:24 <sipa> and as gmaxwell said, he had a wallet with *ALL* transactions in it, so that includes all of deepbit's
1557 2011-09-24 21:34:32 <[Tycho]> Well, it grows.
1558 2011-09-24 21:34:48 <tcatm> also every transaction from the wallet ends up in the blockchain so it can not be that much bigger
1559 2011-09-24 21:35:04 <sipa> well, wallet transaction keep quite some more information
1560 2011-09-24 21:35:20 <sipa> including dependencies
1561 2011-09-24 21:35:27 <gmaxwell> [Tycho]: I had _every_ transaction from the bitcoin network in that wallet, including all of yours.
1562 2011-09-24 21:35:35 <[Tycho]> Last time I purged it at 918 Mbs
1563 2011-09-24 21:35:40 <gmaxwell> So something sounds broken.
1564 2011-09-24 21:35:50 <[Tycho]> May be something is broken.
1565 2011-09-24 21:36:03 <tcatm> [Tycho]: would you mind sending it to me before you delete it again?
1566 2011-09-24 21:36:38 <[Tycho]> I still have backups for last months.
1567 2011-09-24 21:36:39 <sipa> if you don't want tcatm having the private keys, maybe you can load it in a 0.4 client and encrypt it first
1568 2011-09-24 21:36:42 <gmaxwell> In any case, there are some exponential time algorithims in bitcoin coin selection related to there being large numbers of change transactions that you might be suffering from.
1569 2011-09-24 21:36:44 <lfm> when you have other people's txn you only have addr not keys in the wallet
1570 2011-09-24 21:37:15 <sipa> gmaxwell: exponential, sure?
1571 2011-09-24 21:37:27 <[Tycho]> I think that it's the keys.
1572 2011-09-24 21:37:53 <[Tycho]> May be I should return change to one of already existing addresses instead of a new one.
1573 2011-09-24 21:38:30 <tcatm> are you using sendmany?
1574 2011-09-24 21:38:37 <sipa> how many transactions do you do per day?
1575 2011-09-24 21:38:40 <[Tycho]> No.
1576 2011-09-24 21:39:31 <[Tycho]> Currently I don't have stats on transaction number, only amounts.
1577 2011-09-24 21:40:08 Sedra has quit (Quit: ( Quit ))
1578 2011-09-24 21:40:13 <[Tycho]> Should be more than 2000 per day, but not sure how many exactly.
1579 2011-09-24 21:41:09 <[Tycho]> What can possibly go wrong if I'll be returning change to same old addresses ?
1580 2011-09-24 21:41:24 <tcatm> So you could easily group 20 tx in one sendmany tx.
1581 2011-09-24 21:41:44 <gmaxwell> Wow, you're not using sendmany? Thats terrible.
1582 2011-09-24 21:41:51 <tcatm> [Tycho]: nothing if you make sure you still have the private key
1583 2011-09-24 21:42:22 <sipa> somewhat decreased anonymity
1584 2011-09-24 21:42:34 <[Tycho]> Is it better to return to some other old address or it's OK to send back to the one from which this tx is sent ?
1585 2011-09-24 21:42:42 Fuehrer is now known as abragin
1586 2011-09-24 21:43:03 <[Tycho]> Yes, I know about anonymity, but those funds are already known to be sent from deepbit because of open stats.
1587 2011-09-24 21:43:10 <sipa> right
1588 2011-09-24 21:43:15 <tcatm> both options should work fine
1589 2011-09-24 21:43:19 <gmaxwell> I'd reuse the source address.
1590 2011-09-24 21:43:24 <tcatm> but consider using sendmany first
1591 2011-09-24 21:44:05 <[Tycho]> I'm including sendmany in my blocks, but not yet want to create them.
1592 2011-09-24 21:44:06 <tcatm> it also saves a lot of diskspace on other users computers
1593 2011-09-24 21:44:39 <gmaxwell> I can't believe you're not using sendmany. Thats really unfortunate. Send many will easily improve things for you.
1594 2011-09-24 21:45:22 <gmaxwell> The case where I know bitcoind gets very slow is where you're selecting a new coin to spend and you have many unconfirmed self-inputs from change.
1595 2011-09-24 21:45:37 <gmaxwell> And thats what you get when you send lots at once without using sendmany.
1596 2011-09-24 21:45:56 Joric has joined
1597 2011-09-24 21:46:19 <gmaxwell> Sendmany also reduces the data volume in the blockchain significantly, which is good for bitcoin's health overall.
1598 2011-09-24 21:46:46 <sipa> every wallet key currently requires >350 bytes in the wallet
1599 2011-09-24 21:47:24 Andrevan has quit (Ping timeout: 256 seconds)
1600 2011-09-24 21:47:40 <gmaxwell> (You also ought to be limiting user's payouts to 1/day, or at least 1/day unless they have >1btc, or something like that if you aren't alreadyâ¦)
1601 2011-09-24 21:47:51 <[Tycho]> No.
1602 2011-09-24 21:48:01 <[Tycho]> Minimum payment is 0.01 BTC
1603 2011-09-24 21:48:36 <[Tycho]> Total maximum number of payments per day is somewhere near 4
1604 2011-09-24 21:49:16 <[Tycho]> I don't want users to spam the network with unlimited number of 0.01 transactions.
1605 2011-09-24 21:49:27 <sipa> i think that's fine
1606 2011-09-24 21:49:36 <gmaxwell> I guess I should be glad you're limiting it in some way, though thats still a bit unfortunate from a network load perspective, especially since you're not using sendmany.
1607 2011-09-24 21:49:53 <sipa> indeed, sendmany would help a lot
1608 2011-09-24 21:50:57 <dikidera> [Tycho]:atm my Windows folder which has existed for over a year and a half is 13.3GB
1609 2011-09-24 21:50:57 Sedra has joined
1610 2011-09-24 21:50:59 piotrp has joined
1611 2011-09-24 21:51:03 <dikidera> however i havent updated in a year or so
1612 2011-09-24 21:51:10 <dikidera> that drains your HDD space fast
1613 2011-09-24 21:51:10 <[Tycho]> Defauld automatic payment threshold was 10 BTC initially, but later i changed it to 0.01 to prevent users from accidentally storing their bitcoins in the pool.
1614 2011-09-24 21:51:50 brunner has joined
1615 2011-09-24 21:51:52 <sipa> it's automatic? as soon as someone has over 0.01, you send it?
1616 2011-09-24 21:52:09 brunner has quit (Client Quit)
1617 2011-09-24 21:52:37 <[Tycho]> Once per 24hours, if user's address is valid and if there were no manual payments in last 24h.
1618 2011-09-24 21:52:48 <sipa> ok
1619 2011-09-24 21:52:55 <[Tycho]> It's the default threshold, users can set it to any value.
1620 2011-09-24 21:54:15 <phantomcircuit> [Tycho], is there a list of which blocks deepbit found
1621 2011-09-24 21:54:41 <phantomcircuit> im going to change the way bitcoin transfers are handled on intersango so that it's "smarter"
1622 2011-09-24 21:54:48 <phantomcircuit> and that would help
1623 2011-09-24 21:54:56 AStove has quit ()
1624 2011-09-24 21:54:59 <[Tycho]> Initially I wanted to provide some payment functionality - like ability to pay any amount to any user-provided address, like a online wallet, but later decided that this is a bad idea because they will keep more BTC in the pool.
1625 2011-09-24 21:55:06 <[Tycho]> What's intersango &
1626 2011-09-24 21:55:07 <CIA-101> bitcoin: Luke Dashjr * r856c4d196214 gentoo/dev-util/amd-adl-sdk/ (Manifest amd-adl-sdk-3.0.ebuild): dev-util/amd-adl-sdk-3.0
1627 2011-09-24 21:55:07 <[Tycho]> ?
1628 2011-09-24 21:55:25 <[Tycho]> phantomcircuit, do you need the FULL list ?
1629 2011-09-24 21:55:25 <phantomcircuit> britcoin has been moved to intersango.com
1630 2011-09-24 21:55:30 Etlase has quit (Ping timeout: 255 seconds)
1631 2011-09-24 21:55:31 <marf_away> you could become biggest nlinewallet tycho!
1632 2011-09-24 21:55:34 piotrp has quit (Client Quit)
1633 2011-09-24 21:55:35 <marf_away> onlinewallet
1634 2011-09-24 21:55:37 <phantomcircuit> nah just the latest blocks
1635 2011-09-24 21:55:48 <[Tycho]> marf_away, which I certainly don't want to.
1636 2011-09-24 21:55:50 <phantomcircuit> marf_away, that's not a nice place to be
1637 2011-09-24 21:56:02 Etlase has joined
1638 2011-09-24 21:56:04 <phantomcircuit> trust me handling proper backup procedures is annoying as fuck
1639 2011-09-24 21:56:28 <marf_away> but bind more users
1640 2011-09-24 21:56:52 <marf_away> and more noobfrendly experience
1641 2011-09-24 21:56:58 <[Tycho]> Of course I'm keeping most bitcoins in an offline vaults in separate countries, but I don't want to bear that responsibility.
1642 2011-09-24 21:57:25 <[Tycho]> phantomcircuit, latest blocks are listed on the pool's stats page.
1643 2011-09-24 21:57:28 karnac has quit (Quit: karnac)
1644 2011-09-24 21:57:46 minimoose has joined
1645 2011-09-24 21:57:49 <phantomcircuit> [Tycho], yeah i have a wallet on a flash drive in a safe deposit box
1646 2011-09-24 21:57:50 <phantomcircuit> :|
1647 2011-09-24 21:57:53 <phantomcircuit> srsbiz
1648 2011-09-24 21:58:00 <semb> why not keep user's bitcoins backed up on their browsers using HTML5 client storage
1649 2011-09-24 21:58:08 <phantomcircuit> haha no
1650 2011-09-24 21:58:15 <Diablo-D3> semb: thats retarded.
1651 2011-09-24 21:58:17 <semb> (encrypted of course)
1652 2011-09-24 21:58:18 <sipa> i trust users way less than myself :)
1653 2011-09-24 21:58:22 <gmaxwell> [Tycho]: in any case, your first move should be to use sendmanyâ it'll greatly reduce your problems... cutting your wallet growth by a signficant factor, and also be good for the bitcoin network overall.
1654 2011-09-24 21:58:23 <phantomcircuit> "I CLEARED MY CACHE WHERE ARE MY BITCOINS!!!"
1655 2011-09-24 21:58:46 <[Tycho]> I had an idea of safe online vault that can't steal user's bitcoins too :)
1656 2011-09-24 21:58:49 <sipa> semb: or you mean, use html5 storage as backup for [Tycho]'s wallet?
1657 2011-09-24 21:59:01 <semb> encrypted under the users password and a master password
1658 2011-09-24 21:59:05 <gmaxwell> thats a cute and crazy idea.
1659 2011-09-24 21:59:05 <phantomcircuit> semb, i trust myself a lot more than users...
1660 2011-09-24 21:59:07 <phantomcircuit> well
1661 2011-09-24 21:59:08 <phantomcircuit> most users
1662 2011-09-24 21:59:12 <Diablo-D3> the linux torvalds back up method: let everyone else mirror your shit
1663 2011-09-24 21:59:18 rdponticelli_ has quit (Ping timeout: 256 seconds)
1664 2011-09-24 21:59:19 <Diablo-D3> er, linus
1665 2011-09-24 21:59:23 <semb> i mean keep each user's addess's private keys backed up on that user's clients
1666 2011-09-24 21:59:38 <sipa> Diablo-D3: i'm sure if someone put [Tycho]'s wallet online, a lot of people would 'backup' it :D
1667 2011-09-24 21:59:49 <Diablo-D3> sipa: "back it up", noob
1668 2011-09-24 21:59:53 <semb> in the event of catastrophic loss the users can log back in, and the pks are restored.
1669 2011-09-24 21:59:54 <k9quaint> I had an idea of a safe online vault that can't steal my bitcoins from the users
1670 2011-09-24 22:00:07 <sipa> Diablo-D3: be nice, english is not my native language
1671 2011-09-24 22:00:17 Zarutian has joined
1672 2011-09-24 22:00:33 <Diablo-D3> sipa: ENGLISH MOTHERFUCKER, DO YOU SPEAK IT?!
1673 2011-09-24 22:00:43 piotrp has joined
1674 2011-09-24 22:00:53 <sipa> please
1675 2011-09-24 22:00:56 <phantomcircuit> im gonna say "kind of"
1676 2011-09-24 22:00:57 <[Tycho]> A special mobile/PC client can be created that downloads encrypted key from online wallet, decrypts is with user's password and sends the TX to network (or via the service).
1677 2011-09-24 22:01:12 Joric has quit (Ping timeout: 276 seconds)
1678 2011-09-24 22:01:23 <phantomcircuit> [Tycho], yup that's definitely possible
1679 2011-09-24 22:01:30 <phantomcircuit> just would require a substantial amount of work
1680 2011-09-24 22:01:30 <sipa> [Tycho]: instawallet you mean?
1681 2011-09-24 22:01:35 <[Tycho]> This way both online wallet owner can't steal funds and noone can steal them from the user himself.
1682 2011-09-24 22:01:37 <sipa> wait, no
1683 2011-09-24 22:01:48 <sipa> i mean bitcoinjs
1684 2011-09-24 22:01:50 <Diablo-D3> bitpenis dildocoin assdynamics.
1685 2011-09-24 22:01:57 <[Tycho]> Decryption at user's side.
1686 2011-09-24 22:02:39 <[Tycho]> I hate it that many monts have passed and nothing was created to provide user-friendly functionality.
1687 2011-09-24 22:02:57 <Diablo-D3> mmm porn
1688 2011-09-24 22:02:59 rdponticelli has joined
1689 2011-09-24 22:03:04 <Diablo-D3> nothing better than lesbian porn
1690 2011-09-24 22:03:06 <[Tycho]> Even if noone can program things, there are enough funds to hire a programmer and interface designer.
1691 2011-09-24 22:03:09 <tcatm> you could do that in javascript but I wouldn't trust a users computer without a secure hardware device to authenticate the transaction
1692 2011-09-24 22:03:24 <phantomcircuit> [Tycho], i was working on vibanko.com actually but got side tracked with intersango.com
1693 2011-09-24 22:03:56 <phantomcircuit> actually writing a program to blindly send transactions onto the network wouldn't be very hard to write
1694 2011-09-24 22:04:24 forrestv` is now known as forrestv
1695 2011-09-24 22:04:28 forrestv has quit (Changing host)
1696 2011-09-24 22:04:28 forrestv has joined
1697 2011-09-24 22:04:32 <[Tycho]> I think that the most important thing now is to create a light client for android/WM/blackberry/windows platforms.
1698 2011-09-24 22:04:51 <phantomcircuit> it's really a question of how light of a client are you talking about
1699 2011-09-24 22:05:01 num1 has quit (Quit: Textual IRC Client: http://www.textualapp.com/)
1700 2011-09-24 22:05:07 <CIA-101> bitcoin: Luke Dashjr * rb9235e154b3e gentoo/app-misc/cgminer/ (Manifest cgminer-2.0.3.ebuild cgminer-2.0.4.ebuild): app-misc/cgminer: symlink system ADL to work dir
1701 2011-09-24 22:05:09 <phantomcircuit> a client that just blindly connects to random peers and sends a transaction would be fairly simple
1702 2011-09-24 22:05:15 <sipa> a light client already exists for android
1703 2011-09-24 22:05:16 <[Tycho]> Not storing more than chain's headers.
1704 2011-09-24 22:05:19 Joric has joined
1705 2011-09-24 22:05:20 Joric has quit (Changing host)
1706 2011-09-24 22:05:20 Joric has joined
1707 2011-09-24 22:05:23 <phantomcircuit> a proper headers only client would be far more complicated
1708 2011-09-24 22:05:39 <phantomcircuit> sipa, link?
1709 2011-09-24 22:06:17 <sipa> you'll find it on the forums, it's based on bitcoinj
1710 2011-09-24 22:06:22 <sipa> but i believe it's not that stable yet
1711 2011-09-24 22:07:02 <sipa> https://bitcointalk.org/index.php?topic=4384.0
1712 2011-09-24 22:07:28 <[Tycho]> Semi-online client would be even better because it wouldn't require user to wait for new blocks after each startup. But it's a bit bad for decentralyzing stuff.
1713 2011-09-24 22:08:07 <phantomcircuit> well
1714 2011-09-24 22:08:23 <[Tycho]> It's very bad that we still have only one functional client, which is not really user-friendly.
1715 2011-09-24 22:08:40 <phantomcircuit> actually thinking about it for a minute the only reason you need to wait before sending a transaction is to make sure that the transaction hasn't been spent
1716 2011-09-24 22:08:50 <phantomcircuit> but with normal standard transactions that isn't an issue
1717 2011-09-24 22:09:09 <phantomcircuit> so there isn't really a reason to wait for the block chain, if you send it and the network rejects it well too bad
1718 2011-09-24 22:09:09 <[Tycho]> You also need to see if you have received something.
1719 2011-09-24 22:09:21 <abragin> In my opinion, libbitcoin would be a logical decision in order to have more clients.
1720 2011-09-24 22:09:40 <gmaxwell> abragin: that would _not_ be an improvement.
1721 2011-09-24 22:09:53 <gmaxwell> abragin: we don't need a bunch of different skins on the same code.
1722 2011-09-24 22:10:12 <abragin> that would not be skins
1723 2011-09-24 22:10:13 <gmaxwell> Having that would just make it even less likely that there would be widely used alternatives for the core code.
1724 2011-09-24 22:10:14 <sipa> i suppose he's talking about genjix' libbitcoin?
1725 2011-09-24 22:10:21 <abragin> the library should include core functionality
1726 2011-09-24 22:10:28 <[Tycho]> If someone send something to you, you should wait for all those blocks to be downloaded (via cellular network, which can be expensive is some places).
1727 2011-09-24 22:10:35 <tcatm> a document containing *all* information needed to rewrite the client from scratch would help a lot more than libbitcoin
1728 2011-09-24 22:10:37 <gmaxwell> abragin: We desperately need independant implementations of the core functionality.
1729 2011-09-24 22:10:53 <abragin> gmaxwell - may I ask why?
1730 2011-09-24 22:10:59 <abragin> and what if someone implements it wrong?
1731 2011-09-24 22:11:00 <gmaxwell> [Tycho]: you've seen the java light client, no?
1732 2011-09-24 22:11:11 <[Tycho]> gmaxwell, no, but i heard about it.
1733 2011-09-24 22:11:21 <gmaxwell> abragin: exactly.
1734 2011-09-24 22:11:34 <gmaxwell> (what if the one library everyone uses is wrong)
1735 2011-09-24 22:12:18 <gmaxwell> Having only a single major implementation makes a lie of our claim of decentarlization, and leaves us more exposed to coding errors.
1736 2011-09-24 22:13:03 zomtec has quit (Ping timeout: 255 seconds)
1737 2011-09-24 22:13:35 <gmaxwell> While the only advantage of having multiple front ends is some improved usability innovation (along with even more fradulent clients)
1738 2011-09-24 22:13:43 <abragin> Having more implementations would just bring in more different coding errors, I'm afraid.
1739 2011-09-24 22:13:44 <[Tycho]> Also it would be nice to enable more of those commands to allow some funny blockchain scripts :)
1740 2011-09-24 22:14:23 <abragin> And the most used bitcoin client now is far from being user-friendly really, and that affects bitcoin adoption
1741 2011-09-24 22:14:28 <gmaxwell> abragin: having coding errors isn't all that fatal so long as the same error doesn't exist in 50% of the forwarding / mining capacity.
1742 2011-09-24 22:14:43 <gmaxwell> abragin: then submit patches.
1743 2011-09-24 22:14:59 <sipa> well, bitcoin-qt is going to be merged soon
1744 2011-09-24 22:14:59 <gmaxwell> Though I boggle at people saying it's not user friendly. I think it's quite user friendly.
1745 2011-09-24 22:15:04 <abragin> Or fork :-)
1746 2011-09-24 22:15:07 <sipa> i think that's a step forward in user-friendlyness
1747 2011-09-24 22:15:13 <[Tycho]> If we had user-frendly client, there wouldn't be so many mybitcoin users.
1748 2011-09-24 22:15:21 <[Tycho]> i mean, victims
1749 2011-09-24 22:15:21 <sipa> disagree
1750 2011-09-24 22:15:51 <[Tycho]> It's not the only reasong to use online wallet, but one of.
1751 2011-09-24 22:15:52 datagutt has quit (Quit: kthxbai)
1752 2011-09-24 22:15:53 <gmaxwell> The software can't be as "user friendly" as a website you visit and then in 5 seconds you have an account. Thats not a reasonable goal for local client software.
1753 2011-09-24 22:15:55 <sipa> a full native client has certain disadvantages over an online wallet
1754 2011-09-24 22:16:08 <sipa> in terms of user-friendlyness
1755 2011-09-24 22:16:22 piotrp has quit (Quit: piotrp)
1756 2011-09-24 22:16:41 <[Tycho]> Yes, but this in one of the reasons.
1757 2011-09-24 22:16:59 <[Tycho]> Anyway, we need more clients, especially mobile and instant ones.
1758 2011-09-24 22:17:02 <sipa> i'm sure it plays a role
1759 2011-09-24 22:17:16 * luke-jr bets Chrome supports a local wallet without a "special" download
1760 2011-09-24 22:17:26 <sipa> ?
1761 2011-09-24 22:18:12 <[Tycho]> I think that many users even think that initial blockchain downloading process looks like something goes wrong and they need to kill the app because of CPU and HDD usage.
1762 2011-09-24 22:19:09 <gmaxwell> Thats an argument for a lite client for joe-blow users, not a particular flaw in full node software.
1763 2011-09-24 22:19:23 * luke-jr thinks the block download needs to be hidden better
1764 2011-09-24 22:19:31 <[Tycho]> What is Inaba's pool ?
1765 2011-09-24 22:19:42 <luke-jr> ie, start downloading at the most recent block, and assume the sigs are valid until proven otherwise
1766 2011-09-24 22:19:44 <gmaxwell> luke-jr: kinda hard with bdb calling fsync constantly.
1767 2011-09-24 22:20:10 <luke-jr> maybe display all transactions as "Unknown" status until then
1768 2011-09-24 22:20:17 pecket has joined
1769 2011-09-24 22:20:34 peck has quit (Read error: Connection reset by peer)
1770 2011-09-24 22:20:44 <gmaxwell> luke-jr: I'd have an awesome time setting up nodes that hand out bullshit blocks to folks.
1771 2011-09-24 22:20:48 <luke-jr> even a "Please wait, loading (this will take a day)" would be better
1772 2011-09-24 22:21:25 <tcatm> Isn't that what bitcoin-qt does?
1773 2011-09-24 22:21:28 <casascius> I think the core development team should focus on being the custodians of the platform-neutral "bitcoind" and provide appropriate hooks so that people can add their own front ends that are platform specific
1774 2011-09-24 22:21:32 <luke-jr> not to mention shipping with a copy of the block chain up to the last checkpoint
1775 2011-09-24 22:21:55 <casascius> I say that because I think there are a lot of things that would fit well in, say, a "Windows" bitcoin client
1776 2011-09-24 22:21:57 <luke-jr> casascius: I think there should be multiple devteams working on multiple core componetns
1777 2011-09-24 22:22:00 <abragin> casascius - that's what I just told about, and that was being criticized
1778 2011-09-24 22:22:17 <luke-jr> casascius: I suggested the split up months ago-- see the Wallet protocol wiki page
1779 2011-09-24 22:22:33 <casascius> luke-jr: I'm familiar with the page, I've contributed to it
1780 2011-09-24 22:22:40 <luke-jr> casascius: genjix et al are working on a library implementation, which could be used for experimental protocols ;)
1781 2011-09-24 22:23:16 zomtec has joined
1782 2011-09-24 22:23:23 <luke-jr> *hopefully* they are abstracting node and wallet from each other too
1783 2011-09-24 22:23:24 <casascius> The fact that bitcoind is already easily compiled as a headless daemon is pretty good. There are only a few little RPC calls it would need and someone else could completely skin it and still use the core bitcoind as the p2p and block validation engine
1784 2011-09-24 22:23:48 <luke-jr> casascius: a fully functional wallet really needs bidirectional communication though
1785 2011-09-24 22:23:51 <gmaxwell> casascius: that would not be a major improvement in the diversity of the bitcoin software.
1786 2011-09-24 22:24:05 <luke-jr> client*
1787 2011-09-24 22:24:27 <gmaxwell> luke-jr: blocking bidi communication, in fact. Since you need to block any updates to the available inputs if you are to get a user to approve a fee.
1788 2011-09-24 22:25:11 da2ce7 has joined
1789 2011-09-24 22:25:17 <luke-jr> gmaxwell: or rather, you need to lock the coins/outputs being used, and IF they get an update, act on it specially
1790 2011-09-24 22:25:24 <gmaxwell> Sure.
1791 2011-09-24 22:25:27 <luke-jr> ie, tell the GUI it's no longer valid
1792 2011-09-24 22:25:31 <casascius> the level of abstraction I would implement would be to have user wallets in the UI side, and also the construction of transactions in the UI side. And let bitcoind deal with interacting with peers and validating blocks.
1793 2011-09-24 22:25:42 <luke-jr> which can then tell the user "whoa, someone just spent that! new fee is ____"
1794 2011-09-24 22:25:51 <casascius> Kind of how SMTP is used for delivering mail and communicating with other mail servers, but mail clients are used to read and compose messages.
1795 2011-09-24 22:25:55 <gmaxwell> But then you get crap like "the gui locked some inputs so that it could give a stable fee, then crashed, now you can't spend those inputs without restarting an invisible daemon" ugh.
1796 2011-09-24 22:26:20 <sipa> gmaxwell: well the locking would be in-memory only i guess
1797 2011-09-24 22:26:39 <sipa> just a set of "preliminarily spent txins"
1798 2011-09-24 22:26:43 <gmaxwell> sipa: right, but if the UI crashes you'll still need to restart bitcoind to free the locks.
1799 2011-09-24 22:26:48 <[Tycho]> "Running ANYTHING java based, having to use Java based junk in the enterprise, I can tell you I have never once seen a java based program that was worth anything in high availability/heavy load environments. Couple that with the fact that without some severe tweaks, the memory limits of the java VM leave a LOT to be desired. I'll stick with native code, thanks. That said, it's usually the interface that is complete FAIL with java crap,
1800 2011-09-24 22:26:49 <phantomcircuit> rofl
1801 2011-09-24 22:26:51 <[Tycho]> so maybe Poolserverj doesn't suffer from this, since there's no need for an interface to speak of. But there are so many other problems with java scalability wise that it's just too unstable and problematic to build a business off of"
1802 2011-09-24 22:26:51 <gmaxwell> (assuming they're seperate processes)
1803 2011-09-24 22:26:59 <gmaxwell> but what casascius said makes sense enough to me.
1804 2011-09-24 22:26:59 <phantomcircuit> innotribe
1805 2011-09-24 22:27:02 <[Tycho]> - I'm really LOLing at this part
1806 2011-09-24 22:27:14 <phantomcircuit> these people are so socially retarded they've never watched office space
1807 2011-09-24 22:28:02 <gmaxwell> [Tycho]: it's best if you imagine them sitting in their underwear in their mother's basement pounding on the keyboard with great fury.
1808 2011-09-24 22:28:36 <[Tycho]> gmaxwell, it's a pool owner's post on the forum :)
1809 2011-09-24 22:29:36 <gmaxwell> That isn't doing anything to shake my mental imageâ¦
1810 2011-09-24 22:29:58 <casascius> in my fantasy world, the UI produces transactions that the "user" intends to do, and submits them to bitcoind. It doesn't need to lock any wallet in bitcoind, because the UI would manage the user's private keys and wouldn't have anything competing to spend those same transaction
1811 2011-09-24 22:30:07 <[Tycho]> Still can't find which pool he owns.
1812 2011-09-24 22:30:22 peck has joined
1813 2011-09-24 22:30:22 <sipa> casascius: wallet can be inside or outside of bitcoind, doesn't really matter
1814 2011-09-24 22:30:33 <sipa> the code should be more or less independent, even if it is inside
1815 2011-09-24 22:30:54 <sipa> but wallet management is not a trivial task
1816 2011-09-24 22:30:59 <gmaxwell> It would simplify the locking concerns I raised.... thought it brings other issues.
1817 2011-09-24 22:31:10 <[Tycho]> Oh, it's EMC pool.
1818 2011-09-24 22:31:16 <casascius> sipa: I would need a way to query bitcoind to ask it: "OK, the following addresses are all mine: <list>. Please give me the txids and contents of all unspent transactions for all my addresses."
1819 2011-09-24 22:31:26 pecket has quit (Read error: Connection reset by peer)
1820 2011-09-24 22:31:32 <gmaxwell> E.g. it would be nice if only the bitcoind had to be long running, but if it doesn't know about your addresses it won't know about what txn it has to set aside to tell the UI about when it comes online.
1821 2011-09-24 22:31:37 <casascius> Then my UI would present to the user his balance.
1822 2011-09-24 22:32:04 <sipa> casascius: i see it as: "Hi, I'm a wallet, i'd like to know about any incoming transactions. kthxbye"
1823 2011-09-24 22:32:20 <gmaxwell> casascius: forever tracking all addresses or scanning the whole block chain frequently are both not nice activities.
1824 2011-09-24 22:32:23 <casascius> If User wanted to spend his funds, my UI would construct the transaction based on that information, and feed bitcoind an RPC call that says, "OK here is a signed transaction...please relay to peers!" and process it as though it had come from a peer
1825 2011-09-24 22:32:42 <luke-jr> [18:16:02] <gmaxwell> But then you get crap like "the gui locked some inputs so that it could give a stable fee, then crashed, now you can't spend those inputs without restarting an invisible daemon" ugh. <-- good reason not to use anything HTTP-like\
1826 2011-09-24 22:33:00 <tcatm> casascius: you need to duplicate all transactions in the wallet. scanning the whole blockchain would take too much time
1827 2011-09-24 22:33:02 <casascius> gmaxwell: They are not nice activities until an appropriate index is builty
1828 2011-09-24 22:33:04 <Joric> does anyone have prebuilt win32 bitcoin-qt? want to check out its beauty
1829 2011-09-24 22:33:16 <Joric> i've seen only screenshots so far
1830 2011-09-24 22:33:29 <gmaxwell> casascius: an index of all ever observed addresses would currently be several hundred megabytes.
1831 2011-09-24 22:33:30 <Joric> it was godawful
1832 2011-09-24 22:33:56 <sipa> and it gets really complicated when complex transactions are allowed
1833 2011-09-24 22:34:45 <casascius> gmaxwell: My understanding is that there are 15 million transactions, so an index consisting of just a hashtable that associated each address's 32-bit prefix with a list of blocks that reference them couldn't possibly be more than 1/5 the size of the blockchain
1834 2011-09-24 22:35:05 <gmaxwell> casascius: some transactions reference dozens of addresses.
1835 2011-09-24 22:35:42 <casascius> gmaxwell: then those dozens of entries would nominally take up about 8 bytes each in an index... four bytes to identify part of the address hash, and four to identify part of the block hash
1836 2011-09-24 22:36:03 <gmaxwell> hm, indeed, you could do that though.
1837 2011-09-24 22:36:12 <gmaxwell> It still seems rather pointless to me.
1838 2011-09-24 22:36:52 <sipa> i also believe in txouts of the form "<hash> OP_HASH256 OP_NUMEQUAL", that bypass all public-key business
1839 2011-09-24 22:36:59 <casascius> Indexes are always pointless unless you have a workload that benefits from them, and allowing other developers to create their own UI's is a benefit that is worth considering adding an (optional) index... the index doesn't have to be built for those who won't benefit from it
1840 2011-09-24 22:37:24 <casascius> sipa: so they are basically sending bitcoins to passphrases
1841 2011-09-24 22:37:25 <gmaxwell> sipa: you mean miner payments?
1842 2011-09-24 22:37:46 <gmaxwell> (because any competent miner will just take those for themselves if they become widely usedâ¦)
1843 2011-09-24 22:37:59 <sipa> gmaxwell: hmm?
1844 2011-09-24 22:38:07 <luke-jr> sipa: FAIL
1845 2011-09-24 22:38:25 <gmaxwell> The purpose of that style txn is a bit more subtle, it should be ANDed with an actual key.
1846 2011-09-24 22:38:26 <casascius> Passphrases that get published on the block chain when redeemed that is.... That would suggest to me a risk, as those passphrases might both identify the user as well as give clues as to how that user forms passphrases
1847 2011-09-24 22:38:43 <sipa> right
1848 2011-09-24 22:38:47 <gmaxwell> The idea of being able to hash lock a txn is that I can lock payment to you which is only good if I also tell you the passpharse.
1849 2011-09-24 22:38:48 <sipa> forget what i said :)
1850 2011-09-24 22:38:57 * sipa needs sleep
1851 2011-09-24 22:38:59 <luke-jr> IMO, if anyone does that, they deserve to have miners "steal" the money
1852 2011-09-24 22:39:33 <casascius> You can already kind of accomplish that, simply by taking sha256 of a string, using it as a private key, and sending bitcoins to the corresponding address.
1853 2011-09-24 22:39:43 <gmaxwell> If, externally to bitcoin, I prove to use that this passphrase is valuable to you then you can pay me plus the lock.. so that the payment is only useful if I've disclosed the passphrase on the block chain.
1854 2011-09-24 22:39:58 <sipa> yeah
1855 2011-09-24 22:40:12 <casascius> by using sha256(string) as passphrase you avoid disclosing the passphrase on the block chain, as well as its hash (so it cant be bruteforced)
1856 2011-09-24 22:40:23 <casascius> *sha256(string) as privkey, not passphrase
1857 2011-09-24 22:40:30 marf_away has quit (Ping timeout: 255 seconds)
1858 2011-09-24 22:40:32 <gmaxwell> but, in any case, there are non-trivial transaction types which complicate the index modeling. (Who's wallet should show escrow inputs?)
1859 2011-09-24 22:41:22 <gmaxwell> casascius: you also don't disclose the string which defeats the purpose of the model I was descrbing.
1860 2011-09-24 22:41:28 <casascius> with respect to the index i have in mind, the index should serve only to denote that address X is referenced on block Y. It doesn't have to be concerned with what kind of transactions those addresses are involved in, the addresses don't even have to be present anyway
1861 2011-09-24 22:41:32 <gmaxwell> (the zero-knoweldge-proof payment)
1862 2011-09-24 22:41:46 <casascius> (the index is subject to hash collisions anyway if it's only keyed on 4 bytes out of the object id's)....
1863 2011-09-24 22:42:01 <gmaxwell> casascius: yea, that index would be fine. Also a pointless waste of disk space given the design of current clients.
1864 2011-09-24 22:42:02 <casascius> the purpose of the index would simply be to narrow down the number of blocks that must be scanned to find all transactions that reference an address.
1865 2011-09-24 22:42:48 <Lolcust> What are the chances of encountering Jeff Garzik here ?
1866 2011-09-24 22:42:57 <sipa> jgarzik: are you here?
1867 2011-09-24 22:43:15 imsaguy has quit (Read error: Connection reset by peer)
1868 2011-09-24 22:43:45 abragin has quit ()
1869 2011-09-24 22:44:06 <sipa> casascius: and i believe that those purposes where a rescan of the blockchain is required, should be accompagnied with a list of txids or at least block ids to rescan
1870 2011-09-24 22:44:21 <sipa> the only case where a real rescan is necessary is when restoring a backup
1871 2011-09-24 22:44:22 <casascius> If the job of producing transactions were delegated to the UI, the UI's of the world could could be niche clients that produce certain kinds of multi-party transactions, and the bitcoind development team wouldn't have to be burdened with the rigorous kind of testing that would have to go into supporting them with the existing UI
1872 2011-09-24 22:45:00 imsaguy has joined
1873 2011-09-24 22:45:08 iocor has quit (Quit: Computer has gone to sleep.)
1874 2011-09-24 22:45:20 <sipa> i think it would be a horrible thing to ask from UI designers to reimplement the wallet functionality
1875 2011-09-24 22:45:21 <Joric> casascius, btw blockexplorer can show all transactions for the given address in a json form eg http://blockexplorer.com/q/mytransactions/1AJ3vE2NNYW2Jzv3fLwyjKF1LYbZ65Ez64
1876 2011-09-24 22:45:40 <sipa> either they want it inside bitcoind, or they'll use a library which has the wallet functionality
1877 2011-09-24 22:45:55 <Joric> unfortunately blockexplorer isn't very reliable
1878 2011-09-24 22:45:59 <sipa> if the codebases for these are reasonably independent, it doesn't really matter
1879 2011-09-24 22:46:15 <gmaxwell> casascius: they're still a burden, â the validation needs to be well tested, moreover all of bitcoin suffers if some incompentently written UI causes people to lose money. Finally, how do you get your existing inputs into one of those special payment UIs if they're all seperate?
1880 2011-09-24 22:46:57 <casascius> sipa: Why would reimplementing the wallet be horrible? There's more than one way to look at a wallet. Yes it might be horrible to implement it the way bitcoin does it now, but if I were to implement it, it would look much different and wouldn't horrify me one bit
1881 2011-09-24 22:47:17 <casascius> By "doing it now", I mean all the hoops it jumps through to do things like...for example...include change sent to invisible addresses etc.
1882 2011-09-24 22:47:18 <sipa> casascius: good for you
1883 2011-09-24 22:47:54 <sipa> but my point is that managing a wallet remains non-trivial, and there is a lot of common functionality that would be stupid to reimplement over and over
1884 2011-09-24 22:48:35 <gmaxwell> well, especially stupid when your goal is "implement this one little feature" and not "create a whole bitcoin client"
1885 2011-09-24 22:48:42 <casascius> Right now, the burden is even higher than that....someone who wants to implement a full bitcoin client must, right now, implement not only the wallet, but the p2p and the block validation stuff and all the logic that manages chain reorgs and all.
1886 2011-09-24 22:49:16 <gmaxwell> the p2p code is stupid simple. ::shrugs:: fair enough on the rest.
1887 2011-09-24 22:49:20 <casascius> plus as a client maintainer, I would have to promptly keep up with all the changes
1888 2011-09-24 22:49:42 <gmaxwell> Why? no one else does. it seems
1889 2011-09-24 22:49:53 <casascius> the p2p code indeed IS stupid simple, but why would I want to rewrite it from scratch and spend all the time debugging my own version, when a perfectly good platform independent version is already in front of me
1890 2011-09-24 22:50:44 <gmaxwell> "perfectly good" haha
1891 2011-09-24 22:50:55 <gmaxwell> (I know what you meant though)
1892 2011-09-24 22:50:57 <casascius> what i would rather do is distribute (for example - I would never call it this) - WinCoins - which is a windows specific application that contains the features I consider to be average-joe friendly and consistent with average-joe keeping his bitcoins secure.
1893 2011-09-24 22:51:07 <casascius> And I would bundle it with bitcoind, which would do all the p2p and block validation.
1894 2011-09-24 22:51:40 <sipa> i'm quite sure that even disregarding the p2p and block db code, you'd need 80% of the current wallet code
1895 2011-09-24 22:51:50 <sipa> even if you do change handling differently
1896 2011-09-24 22:51:54 <sipa> and many other things
1897 2011-09-24 22:51:56 imsaguy has quit (Ping timeout: 260 seconds)
1898 2011-09-24 22:51:57 mosimo has quit (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com ))
1899 2011-09-24 22:52:05 <luke-jr> IMO, BCCAPI is a good idea
1900 2011-09-24 22:52:19 <casascius> You know, I think bitcoind IS "perfectly good". Yeah there are things that need to be improved, but if it were designed in such a way that it would _welcome_ being bundled with someone else's UI, all the focus could go into the architecture.
1901 2011-09-24 22:52:39 <luke-jr> casascius: except bitcoind is not usable for a UI
1902 2011-09-24 22:52:45 roconnor has joined
1903 2011-09-24 22:52:56 <casascius> luke-jr: Exactly. It would be the daemon that runs behind the UI I'd provide from scratch
1904 2011-09-24 22:53:02 <sipa> luke-jr: casascius is talking about the p2p and blockdb part of bitcoind, not the wallet part
1905 2011-09-24 22:53:06 <sipa> (i think)
1906 2011-09-24 22:53:15 <casascius> sipa: you are right
1907 2011-09-24 22:53:19 <luke-jr> I'm lost. :D
1908 2011-09-24 22:53:40 <sipa> we all are
1909 2011-09-24 22:54:13 <casascius> bitcoind only needs a couple things to make that vision a reality... that (apparently scorned) index so it can quickly list transactions belonging to an address... a way to push realtime notifications to the UI...and a way for the UI to submit signed transactions to the network.... that is all!
1910 2011-09-24 22:54:36 <gmaxwell> casascius: just because I think it would be pointless doesn't mean that its "scorned"
1911 2011-09-24 22:54:44 <casascius> =)
1912 2011-09-24 22:55:07 <casascius> that index would be infrastructure to support my ideal client. Would the client be pointless as well?
1913 2011-09-24 22:55:19 <casascius> *client = UI client
1914 2011-09-24 22:55:35 <gmaxwell> Also, my view on it is tainted because it would mostly be used to increase the user-friendlyness of unaccetably insecure 22 character mini private keys. :)
1915 2011-09-24 22:56:07 <gmaxwell> casascius: if you want to work on improving the UI running in front of the official bitcoin backend, please send patches!
1916 2011-09-24 22:56:07 <casascius> gmaxwell: Yes, it would support that. Would you consider PBKDF2-based keys to be unacceptably insecure?
1917 2011-09-24 22:56:29 <casascius> I don't know the first thing about WxWidgets, so I'm not likely to help on teh UI anytime soon
1918 2011-09-24 22:56:30 <gmaxwell> casascius: PBKDF2-based would be a big improvement, but you really need more entropy in total.
1919 2011-09-24 22:56:48 <casascius> gmaxwell: I have already implemented PBKDF2...I did that about 12 hours ago
1920 2011-09-24 22:56:51 <Disposition> UI isn't exactly a major concern at the moment...
1921 2011-09-24 22:57:04 <gmaxwell> casascius: ah, I haven't rechecked that thread yet.
1922 2011-09-24 22:57:15 <casascius> I forked the client last night and pushed those changes there.
1923 2011-09-24 22:57:19 <sipa> casascius: the UI will switch to QT soon :)
1924 2011-09-24 22:57:23 <Disposition> ^
1925 2011-09-24 22:57:32 <casascius> How many rounds of PBKDF2 would make you feel comfortable with a 22-character key?
1926 2011-09-24 22:57:38 <casascius> infinity?
1927 2011-09-24 22:57:40 <gmaxwell> casascius: at 128 bits of entropy I'd stop feeling that it was simply broken, at 160 bits of entropy I'd have no reason to complain any more.
1928 2011-09-24 22:57:42 <casascius> a million?
1929 2011-09-24 22:57:42 cjdelisl1 has joined
1930 2011-09-24 22:58:03 <Disposition> honestly satoshi originally probably picked Wxwidgets due to it's cross platform compatbility.
1931 2011-09-24 22:58:18 <casascius> In my codebase I turned on 30 character keys, which exceed 160 bits.
1932 2011-09-24 22:58:24 <gmaxwell> casascius: I'll think never be completely comfortable with a 21 character (effective) key.
1933 2011-09-24 22:58:48 <Disposition> I don't think we should even worry about that, if we provide good api in bitcoind other people will write pretty UI with Ux :3
1934 2011-09-24 22:59:18 therealnanotube has joined
1935 2011-09-24 22:59:37 <casascius> Just as a heads up, the way I designed the PBKDF2 support is so that the number of rounds needed to derive the key is actually indirectly specified in the key. You can choose any number from 1 to, well, pretty much whatever limit has to be hardcoded to prevent a DoS on the CPU
1936 2011-09-24 23:00:01 <casascius> You know how I am hashing sha256(string + '?') and, I was originally looking for 00
1937 2011-09-24 23:00:11 <gmaxwell> casascius: so we're losing more key entropy for that ? bleh
1938 2011-09-24 23:00:29 <casascius> No 7 or 8 bits! Same as before :p
1939 2011-09-24 23:00:33 <sipa> casascius: please explain
1940 2011-09-24 23:00:38 <gmaxwell> (because we can reasonable assume DOS-level PBKDF2 to be an unlikely choice)
1941 2011-09-24 23:00:53 <casascius> OK, I have chucked the 717 stuff. (Haven't issued any keys with it, so it can go)
1942 2011-09-24 23:01:19 <casascius> Redefined the "simple" version to just be: sha256(string+'?')[0]==0 means use sha256... but then...
1943 2011-09-24 23:01:34 <casascius> if sha256(string+'?')[0]==0x01 then use PBKDF2, and...
1944 2011-09-24 23:01:55 <casascius> the number of rounds is determined as: take sha256(string+'?')[1] as n,
1945 2011-09-24 23:01:58 <casascius> and use: 2 ^ (n/4)
1946 2011-09-24 23:02:14 <gmaxwell> casascius: what are the real physical space limits you're up against?
1947 2011-09-24 23:02:29 <casascius> so for example a string whose sha256(string+'?') starts with 0x0128 means take 4096 rounds since 0x28 is 40, that's 2^10
1948 2011-09-24 23:02:42 <casascius> gmaxwell: Stuffing them as printable characters inside the center of a coin
1949 2011-09-24 23:02:50 <casascius> on a circle
1950 2011-09-24 23:03:16 <sipa> casascius: so you have 58^N / 65536 valid keys for each class of iteration counts?
1951 2011-09-24 23:03:25 MBS has joined
1952 2011-09-24 23:03:58 <casascius> sipa: yes. and there is no hard and fast rule that says anyone has to use a specific one. (if I want "about 8192 rounds", I can accept the one that selects 8192 plus or minus quite a few)
1953 2011-09-24 23:04:09 <gmaxwell> casascius: that above scheme loses entropy. E.g. we can assume that no one is going to use 2^64 iteration keys.
1954 2011-09-24 23:04:53 <sipa> right, but if 58^N / 65335 > 2^160, there is no argument to complain
1955 2011-09-24 23:05:16 <sipa> i.e., it loses no more than 16 bits
1956 2011-09-24 23:05:20 <sipa> and probably less
1957 2011-09-24 23:05:38 <gmaxwell> What do you mean by N there?
1958 2011-09-24 23:05:40 <casascius> As defined, valid keys are ones whose first 16 bits are from 0x0000 thru 0x0140, about 1 in 206 random strings are valid. That's between 7 and 8 bits
1959 2011-09-24 23:06:08 <sipa> gmaxwell: key length
1960 2011-09-24 23:06:24 <gmaxwell> adding strengenthening rounds does nothing to increase the totally number of possible keys, in fact the crazy round counts still shrinks it. 22 characters is really not obviously enough.
1961 2011-09-24 23:06:27 <sipa> casascius: entropy is more than which keys are possible
1962 2011-09-24 23:06:28 <gmaxwell> ohhh.
1963 2011-09-24 23:06:28 <gmaxwell> Fine sure.
1964 2011-09-24 23:06:43 <gmaxwell> if N is big enough to give us reasonable key spaces than I have absolutely zero complaint.
1965 2011-09-24 23:06:49 <casascius> further, if I go issue keys that require tens of thousands of PBKDF2 iterations just to derive the key (which is a necessary step in determining if it has bitcoins), how is anyone going to exhaust even a meaningful percentage of the key space?
1966 2011-09-24 23:07:18 rdponticelli has quit (Ping timeout: 256 seconds)
1967 2011-09-24 23:08:00 <gmaxwell> If N is only just big enough and the error correction takes it below then my concern can be reduced through good use of strengthening. And if it's clearly too low, then I don't really care about strenghtening because all the strenghtening in the world doesn't prevent accidental collissions (which need to be so unlikely that no one sane can say they aren't effective impossible)
1968 2011-09-24 23:08:53 <gmaxwell> casascius: it's an issue if the total number of possible keys is too small, the chances that too legit users eventually collide becomes not-infinitesmal-enough.
1969 2011-09-24 23:09:11 <casascius> for accidental collisions to be a practical problem, every bitcoin in existence would need to be divided down to the satoshi and each satoshi sent to a unique address. The hard drive space needed to hold the block chain would be a more practical concern than the possibility that 2 people might unknowingly be holding the same satoshi
1970 2011-09-24 23:09:34 Diablo-D3 has joined
1971 2011-09-24 23:09:54 <sipa> casascius: if you have a keyspace of 2^100 valid minikeys
1972 2011-09-24 23:10:02 <sipa> and 2^50 minikeys are created
1973 2011-09-24 23:10:11 <sipa> there will likely be a collision already
1974 2011-09-24 23:11:11 <casascius> sipa: that assumes that 2^100 minikeys hash into a 2^100 keyspace rather than a 2^256 one. If I have a keyspace of 2^4 minikeys and create 2^2 of them, a collision would only be likely if I were creating them into a 2^4 keyspace rather than 2^256
1975 2011-09-24 23:11:29 rdponticelli has joined
1976 2011-09-24 23:11:51 <sipa> casascius: with collision we mean: the *same* minikey being generated
1977 2011-09-24 23:12:01 <sipa> not a different minikey that hashes to the same privkey
1978 2011-09-24 23:12:14 <casascius> sipa: just so I understand you correctly, minikey being generated also implies, or does not imply, funds being sent to that address?
1979 2011-09-24 23:12:21 <sipa> yes
1980 2011-09-24 23:12:29 <casascius> funds sent?
1981 2011-09-24 23:12:43 <sipa> just in the general sense, used
1982 2011-09-24 23:12:50 <casascius> are there enough bitcoins in existence to even send 1 satoshi to 2^50 addresses?
1983 2011-09-24 23:12:51 <gmaxwell> And, moreover to be bluntâ for all sorts of reasons (some good, some bad) people who look into cryptosystem security will immediately dismiss anything with less than 128 bits of keyspace as problematic. We'd have to have a REALLY good justification there, and having to type a few characters less off a casascius-brand-coin is not one.
1984 2011-09-24 23:13:20 <gmaxwell> 2^50 is only ~1e15.
1985 2011-09-24 23:13:21 <casascius> gmaxwell: OK, I will accept that, accept nothing less than 128 bit security. Here is an alternate idea.
1986 2011-09-24 23:13:46 <luke-jr> casascius: what stops me from "mining" mini keys just to steal moneys?
1987 2011-09-24 23:14:07 <casascius> 1. Forget the need for the client to redeem casascius coins. (if I ever get a privkey sweep function, I can just implement that on my website.)
1988 2011-09-24 23:14:12 dub has quit (Changing host)
1989 2011-09-24 23:14:12 dub has joined
1990 2011-09-24 23:14:31 <casascius> 2. Allow a mini private key format that is at least 26 characters. (this will definitely exceed 128 bits)
1991 2011-09-24 23:14:37 <casascius> 3. disallow SHA256 and all PBKDF2 under 4096 rounds
1992 2011-09-24 23:14:43 <lfm> 21 million btc is less than 2^51 satoshi
1993 2011-09-24 23:15:19 <luke-jr> casascius: is there a reason a 25x25 privkey won't fit on your coins?
1994 2011-09-24 23:15:26 <casascius> 25x25 is a QR code?
1995 2011-09-24 23:15:41 <Joric> casascius, you can't build the 'sweep' transaction without knowing the source tx hash (assuming there was only one source)
1996 2011-09-24 23:15:51 <luke-jr> casascius: IIRC, 25x25 QR code can contain a full private key
1997 2011-09-24 23:15:57 <sipa> Joric: that's why he wants an index for that
1998 2011-09-24 23:16:01 <sipa> luke-jr: 29x29 iirc
1999 2011-09-24 23:16:03 <casascius> joric: if I modify my own bitcoind to have an index that finds that quickly, i will have no problem forming the sweep transaction
2000 2011-09-24 23:16:16 <luke-jr> sipa: maybe depends on amount of error correction
2001 2011-09-24 23:16:20 semb has quit (Quit: Leaving.)
2002 2011-09-24 23:16:21 <gmaxwell> casascius: Rather than disallow, design the encoding so that only more than that is possible.
2003 2011-09-24 23:16:27 <sipa> luke-jr: with minimum amount of error correction
2004 2011-09-24 23:16:32 <luke-jr> hm
2005 2011-09-24 23:16:39 <luke-jr> still 29x29 isn't too bad
2006 2011-09-24 23:16:41 <sipa> but let me try again
2007 2011-09-24 23:16:46 <casascius> luke-jr: on my coins, i insist on my privkeys being human readable. I would accept qr codes for the pub keys, but...qr codes when they get torn or worn or damaged are very difficult to read.....human eyes can correct errors much better
2008 2011-09-24 23:16:52 newsbad_com has joined
2009 2011-09-24 23:17:01 <casascius> gmaxwell: I have already designed the encoding so MUCH more is possible
2010 2011-09-24 23:17:20 <casascius> right now on my fork you can have a 30-character mini private key htat needs 1048576 rounds to derive
2011 2011-09-24 23:17:31 <lfm> bitcoin address are 33 char
2012 2011-09-24 23:17:34 <luke-jr> casascius: how about a failsafe that requires melting the coin down in case of QR-code failure?
2013 2011-09-24 23:17:34 <gmaxwell> Thats actually not a good thing.
2014 2011-09-24 23:17:37 samthetechie has quit (Ping timeout: 260 seconds)
2015 2011-09-24 23:17:49 <luke-jr> wait
2016 2011-09-24 23:18:11 <luke-jr> how is the privkey qr-code goign to get worn/damaged without it being "redeemed"?
2017 2011-09-24 23:18:13 <gmaxwell> casascius: I'm not keen on the extensive selectivity, because you lose entropy to it because the users will obviously select some kinds more than others.
2018 2011-09-24 23:18:22 <casascius> luke-jr: how many people can scan a QR code anyway? (besides using their cellphone , meaning they have to type it off their screen anyway)
2019 2011-09-24 23:18:50 <casascius> gmaxwell: I kind of tend to agree with you, which is why I would consider making the poor choices either not selectable, or just not the easiest to select
2020 2011-09-24 23:19:07 <sipa> luke-jr: 29x29 is necessary is you use base36 encoding (and i don't think there is anything more efficient in QR)
2021 2011-09-24 23:19:08 <casascius> if you're a microcontroller generating a throwaway address, you NEED the easy choice
2022 2011-09-24 23:19:48 <casascius> For me,scanning QR into my computer is no problem, I own a Wasp handheld 2D laser barcode scanner plugged into my USB port. I'm not typical joe though
2023 2011-09-24 23:19:49 <sipa> what use case do you see for slow microcontrollers?
2024 2011-09-24 23:20:14 <sipa> that require transferring a private key
2025 2011-09-24 23:20:15 <casascius> sipa: tabletop POS machine at a check cashing shop who accepts cash and sells bitcoins on receipt tape
2026 2011-09-24 23:21:02 <sipa> receipt tape that anyone can see?
2027 2011-09-24 23:21:14 <casascius> verifone vx570 with 400mhz arm processor and 2 or 6 megabytes of RAM, often running a slow-ass interpreted language that can't do complex functions
2028 2011-09-24 23:21:49 tany000 has quit (Quit: Page closed)
2029 2011-09-24 23:21:52 <casascius> sipa; well the check cashing shop could see it, but presumably if joe sees the clerk copying his register tape down and his bitcoins go missing, he proably won't be going there much
2030 2011-09-24 23:22:16 <lfm> casascius: "can't do complex functions"? what language would that be?
2031 2011-09-24 23:22:22 <casascius> check cashing shop already sells prepaid phone cards that way
2032 2011-09-24 23:22:28 <gmaxwell> casascius: just use a single bit to select 'slow' or 'fast'... or leave out the choice entirely, if (after taking away the error checking loss) you still have >=128 bits, then I don't care that much if you have 1024 rounds of pdbk2 or 1024^3 rounds.
2033 2011-09-24 23:22:46 <casascius> lfm: example would include "TCL" (Terminal Control Language) by VeriFone, a proprietary interpreted language that has nothing to do with tcl
2034 2011-09-24 23:24:36 samthetechie has joined
2035 2011-09-24 23:24:37 <sipa> gmaxwell: his current design provides that with 26-character keys
2036 2011-09-24 23:24:46 <sipa> 58^25 / 65536 > 2^128
2037 2011-09-24 23:24:53 <casascius> gmaxwell: You sure? You don't see much value in having pbkdf2 be scalable into the millions as computing power advances?
2038 2011-09-24 23:25:52 <sipa> casascius: the worst case scenario is that everyone will standardize on one particular iteration count
2039 2011-09-24 23:26:07 <sipa> even in that case, gmaxwell would prefer to see 2^128 possible minikeys
2040 2011-09-24 23:26:34 <Joric> casascius, why 716 sha256 rounds btw? :)
2041 2011-09-24 23:26:52 <phantomcircuit> what is this about minikeys?
2042 2011-09-24 23:27:01 <sipa> so giving more possibilities for iteration counts, decreases the number of keys per iteration count, and thus potentially decreases entropy
2043 2011-09-24 23:27:08 <Joric> phantomcircuit, https://en.bitcoin.it/wiki/Mini_private_key_format
2044 2011-09-24 23:27:15 <sipa> anyway, your current design is fine i think
2045 2011-09-24 23:27:53 <casascius> sipa: just curious, what would encourage people to standardize on one iteration count? it would be difficult for them to even see what others are doing in order to imitate it. It is not as though they can see the iteration count by looking at the key
2046 2011-09-24 23:28:15 <gmaxwell> Because someone bakes it into one piece of software.
2047 2011-09-24 23:28:35 <sipa> though i think you're overestimating the use cases of private key transfer
2048 2011-09-24 23:28:38 <gmaxwell> I also worry about weird DOS attacks. Eg. I try to import a key with 2^64 iterations. What happens?
2049 2011-09-24 23:28:53 <sipa> gmaxwell: that;s why he has a hard limit now
2050 2011-09-24 23:29:04 <gmaxwell> Does the software now need error handling code to cope with that? how long before it aborts? who will ever test that condition?
2051 2011-09-24 23:29:35 <gmaxwell> sipa: ah.
2052 2011-09-24 23:29:37 <gmaxwell> Okay.
2053 2011-09-24 23:30:18 <casascius> sipa: with respect to the technology literate community, yes, i definitely am overestimating it. but we are a pretty small subset of the world population
2054 2011-09-24 23:30:42 <gmaxwell> Soâ it has 2^128 entropy even in the worst case. There are artificial limits to prevent DDOS.. sounds pretty good. I'd still change it to make number below the current limits (we're never likely to decrease them) totally unreachable rather than rejected.
2055 2011-09-24 23:30:53 <casascius> gmaxwell: the condition is already tested, it imposes a limit of 1048576 (and my recommendation is to limit it at 16384)
2056 2011-09-24 23:31:45 <sipa> bitcoin shines in electronic payment and (hopefully in the future) complex transactions, imho
2057 2011-09-24 23:31:57 <sipa> not in physical payment
2058 2011-09-24 23:32:01 <casascius> Bitcoin will only be a way for the most skilled at computers to send money to others who are most skilled at computers until they are put into a format that average joe can understand and see the value in.
2059 2011-09-24 23:32:13 rdponticelli has quit (Read error: Connection reset by peer)
2060 2011-09-24 23:32:23 <sipa> that format will be smartphones, imho
2061 2011-09-24 23:32:47 <Joric> casascius, are those coins real, not a render? http://3.bp.blogspot.com/-1va3MohK7DU/Tm0tQBo_T7I/AAAAAAAAAzk/aZOiDSHKcac/s1600/bitcoin-casascius-3.jpg
2062 2011-09-24 23:33:02 <casascius> I am talking about the average joe who can barely see his way through "only 2 payments of $19.95!" (=$39.90), who can't afford a smartphone, and who is completely incapable of understanding, you know, the federal reserve etc.
2063 2011-09-24 23:33:15 <casascius> Yes real photo
2064 2011-09-24 23:33:32 <Joric> looks stunning :D
2065 2011-09-24 23:33:39 <sipa> i agree, they look awesome
2066 2011-09-24 23:33:43 <[Tycho]> What metal is this ?
2067 2011-09-24 23:33:43 <gmaxwell> e.g. make it 2^(n/8+12) iterations instead of 2^(n/4)
2068 2011-09-24 23:33:47 <casascius> thanks they turned out well
2069 2011-09-24 23:34:03 <sipa> casascius: but how would that joe use bitcoin?
2070 2011-09-24 23:34:07 <casascius> gmaxwell: I could definitely accommodate that. The n/4 was truly arbitrary
2071 2011-09-24 23:34:25 asuk has quit (Ping timeout: 248 seconds)
2072 2011-09-24 23:34:26 <casascius> sipa: joe would buy bitcoins at check-n-go, go to his favorite porn or gambling site, hit redeem just like he had a gift card, and go
2073 2011-09-24 23:34:42 <phantomcircuit> that's interesting
2074 2011-09-24 23:34:42 <sipa> "hit" redeem?
2075 2011-09-24 23:34:44 <sipa> on what?
2076 2011-09-24 23:34:49 Burgundy has quit (Ping timeout: 276 seconds)
2077 2011-09-24 23:34:59 <[Tycho]> casascius, is it silver or what ?
2078 2011-09-24 23:35:01 <casascius> sipa: his favorite porn site or his favorite non-anonymous marketplace... the "redeem bitcoin code" button
2079 2011-09-24 23:35:05 <gmaxwell> casascius: it would simplify selection too because you'd have far fewer values randomly being 'too low to be accepted'
2080 2011-09-24 23:35:09 <casascius> the casascius coins are brass
2081 2011-09-24 23:35:25 <sipa> casascius: and get a new one that represents a refund?
2082 2011-09-24 23:35:28 <[Tycho]> I remember seeing somewhere more shining bitcoin coins...
2083 2011-09-24 23:36:00 <Joric> more coin porn https://www.casascius.com/photos.aspx
2084 2011-09-24 23:36:11 <[Tycho]> Isn't it bad having coins that are cheaper than their value ?
2085 2011-09-24 23:36:14 * gmaxwell looks forward to a great feture in selling pre-depleted casascius bitcoins.
2086 2011-09-24 23:36:37 <sipa> [Tycho]: isn't it bad having sequences of bytes that are cheaper than their value ?
2087 2011-09-24 23:36:58 roconnor has quit (Ping timeout: 244 seconds)
2088 2011-09-24 23:36:58 <[Tycho]> sipa, sequences of bytes can't be forged
2089 2011-09-24 23:37:07 <casascius> sipa: ideally he'd have printed himself a paper wallet (or safely acquired one otherwise) and would simply withdraw his coins to an address he controls so he doesnt have to worry about the merchant taking back his code... but even if he got a code, it would be no worse than a "mtgox code"
2090 2011-09-24 23:37:08 <sipa> [Tycho]: i'm talking about private keys
2091 2011-09-24 23:37:09 <gmaxwell> < [Tycho]> sipa, sequences of bytes can't be forged
2092 2011-09-24 23:37:18 <gmaxwell> ^ I just forged tycho's bytes!
2093 2011-09-24 23:37:26 <jgarzik> Lolcust: ?
2094 2011-09-24 23:37:28 <jgarzik> sipa: ?
2095 2011-09-24 23:37:35 <Joric> i wonder about that hologram is it really impossible to rip it off without damaging
2096 2011-09-24 23:37:40 <Lolcust> hi jgarzik
2097 2011-09-24 23:38:14 <Lolcust> I was trying to compile your reference miner for a side project, and fail horribly
2098 2011-09-24 23:38:17 <sipa> casascius: here is how i see it: any representation in the real world that is backed by bitcoins, is worth as much as the trust in the ability to recover the bitcoins behind it
2099 2011-09-24 23:38:29 <Lolcust> It compiles, but a DLL is broke
2100 2011-09-24 23:38:38 <casascius> gmaxwell: What do you think of using 3 bits to select the iteration, so 8 choices: 4096, 16384, 65536, 262144, 1048576, 4M, 16M, and 256M
2101 2011-09-24 23:39:07 <casascius> sipa: you are one hundred percent right, but joe probably trusts his check-n-go...there are more things that can be trusted besides just the numbers themselves
2102 2011-09-24 23:39:19 <sipa> casascius: my point exactly
2103 2011-09-24 23:39:26 <casascius> if a person has recourse against another, they need to be less concerned that they will get burned by that person
2104 2011-09-24 23:39:32 <sipa> average joe won't care that the numbers correspond to actual bitcoins
2105 2011-09-24 23:39:36 <gmaxwell> casascius: since sipa pointed out the free selection still leaves 128 bits, I don't mind much either way. I'd rather leave out values that we know will never be used but I'm not too picky anymore.
2106 2011-09-24 23:39:58 <gmaxwell> The three bits sounds good to me, and is simple to explain.
2107 2011-09-24 23:40:31 <gmaxwell> (also fairly few you'd currently have to exclude as too hard)
2108 2011-09-24 23:40:33 <sipa> that would mean no less than 135 bits of entropy
2109 2011-09-24 23:40:51 <casascius> so example...first 10 bits of sha256()...the first seven have to be zero (typo check)...the last three select the difficulty of pbkdf2
2110 2011-09-24 23:41:34 <sipa> casascius: otherwise said, the real-world succes of your redeem codes would be based on how trusted the system was that created them
2111 2011-09-24 23:41:45 * [Tycho] checked local minting prices...
2112 2011-09-24 23:42:14 <casascius> sipa: agreed...though which party do you think would do the least trusting? if i sell a machine to check cashing outfit A that verifiably produces valid bitcoin receipts, he has recourse against me if that's not the case...
2113 2011-09-24 23:42:23 <sipa> casascius: i think people trust bank cards more than printed sequences of numbers
2114 2011-09-24 23:42:30 <casascius> and when party B visits A to buy some bitcoins, he probably trusts them just on the fact that they are still in business
2115 2011-09-24 23:42:32 <[Tycho]> Nice. I should order minting some :)
2116 2011-09-24 23:43:03 <gmaxwell> casascius: it would be somewhat better if it were a bit more expensive to do the error checking, but I think I'm done nitpicking mostly. :)
2117 2011-09-24 23:43:07 <casascius> sipa: People in the unbanked world top up their prepaid cell phones every day using activation codes purchased at the register and printed on register tape. I know this because I was hired by a company to write POS firmware to do exactly that, way back when, and they've done millions of tx with it
2118 2011-09-24 23:43:34 <sipa> hmm, you may be right
2119 2011-09-24 23:43:42 <casascius> gmaxwell: if it can be assumed the address has bitcoins, the error checking can be as simple as...if there's no bitcoins, it's an error
2120 2011-09-24 23:43:58 <gmaxwell> Yet at the same time, lottery scratch tickets are engineered to resist x-ray and other kinds of exotic attacks.
2121 2011-09-24 23:44:48 <lfm> gmaxwell: they need it more
2122 2011-09-24 23:45:03 <gmaxwell> casascius: I mean your 7 bits zero check... it would steal less effective entropy if it were more expensive, but I can't complain much because you still have an adequate amount in the worst case.
2123 2011-09-24 23:45:14 <casascius> sipa: what do you mean by a "bank card"? a private key printed on a stiff piece of plastic? something issued by a bank? visa or mastercard?
2124 2011-09-24 23:45:15 <Diablo-D3> gmaxwell: Ive decided something
2125 2011-09-24 23:45:21 <Diablo-D3> gmaxwell: the people in #btcguold are retarded
2126 2011-09-24 23:45:42 <dikidera> damn
2127 2011-09-24 23:45:45 <gmaxwell> casascius: I can't get over how attractive your coins are.
2128 2011-09-24 23:46:03 <casascius> Would you like to know a couple more products I have on the way?
2129 2011-09-24 23:46:11 <dikidera> i never knew the algorithm for inserting blocks in the db and whatnot be so hard...tons of stuff to do and the simplecoin one just doesnt cut it
2130 2011-09-24 23:46:19 <luke-jr> [19:31:29] <lolenheimer> I have this urge to use the restroom. But I'm not going to. Because my bladder is not my boss.
2131 2011-09-24 23:46:54 <casascius> One is a 25 BTC gold plated coin. 44.5mm diameter 3mm thick with some paint on it.
2132 2011-09-24 23:47:20 <sipa> pictures!
2133 2011-09-24 23:47:23 <sipa> oh... on the way
2134 2011-09-24 23:47:24 <casascius> Back side has a hologram surrounded by four rings of zeroes and ones, which in ascii spell "YOU ASKED FOR " "CHANGE" "WE GAVE YOU " "COINS"
2135 2011-09-24 23:47:47 <casascius> And then I am planning on doing a 100 BTC gold plated bullion brick
2136 2011-09-24 23:47:57 <casascius> and also a non-denominated bullion brick.
2137 2011-09-24 23:48:01 <[Tycho]> Isn't 44.5mm too much ? :)
2138 2011-09-24 23:48:08 <casascius> It is a large coin
2139 2011-09-24 23:48:24 <[Tycho]> They aren't mean for circulation ?
2140 2011-09-24 23:48:25 <lfm> fills up your pocket real quick
2141 2011-09-24 23:48:45 <casascius> the bullion brick is 8cm x 4cm x 0.6cm meant for sticking in a safe. It is supposed to "look valuable". (It says on it, "gold plated bearer bar" and the bitcoin logo)
2142 2011-09-24 23:49:25 <lfm> the trouble is they still look valuable after they are spent
2143 2011-09-24 23:49:35 <casascius> lfm: They will be lacking a hologram
2144 2011-09-24 23:49:43 <Joric> it would be cooler if they were hollow with a paper with a private key inside :D
2145 2011-09-24 23:49:54 <casascius> joric: they are
2146 2011-09-24 23:50:23 <sipa> can you open them without destroying them?
2147 2011-09-24 23:50:28 <lfm> the hologram need not be destroyed
2148 2011-09-24 23:50:40 <casascius> I am planning on also selling 0 BTC bearer bars (the hologram explicitly saying "zero btc") so that they don't have to be shipped with btc on them, and owner can load whatever quantity he wants
2149 2011-09-24 23:50:52 newsbad_com has quit (Ping timeout: 260 seconds)
2150 2011-09-24 23:51:11 <casascius> sipa: It's pretty unlikely the hologram can be removed without obvious destruction... it is designed so the holographic layer literally comes apart as you peel it
2151 2011-09-24 23:51:23 <casascius> you get this honeycomb appearance you can't get rid of
2152 2011-09-24 23:51:32 <sipa> ok, nice
2153 2011-09-24 23:51:37 <lfm> make a new hole somewhere else
2154 2011-09-24 23:51:37 <casascius> the "cells" stick to the coin, and the "bees" stick to the sticker
2155 2011-09-24 23:51:44 <Joric> funny thing you can either spend from them or make a deposit to them
2156 2011-09-24 23:52:02 <[Tycho]> I don't like that they are one-time-use only :(
2157 2011-09-24 23:52:17 <gmaxwell> Is the address visible without breaking the seal? e.g. could I keep depositing to one without voiding it?
2158 2011-09-24 23:52:20 newsbad_com has joined
2159 2011-09-24 23:52:25 <casascius> I would likely offer to reload 25 and 100 BTC items and return them
2160 2011-09-24 23:52:28 <casascius> for a small fee
2161 2011-09-24 23:52:33 <casascius> much smaller than buying a new coin
2162 2011-09-24 23:53:01 <casascius> because if you have 100 btc in yoru safe but feel you can't spend them because you don't want to shred your coins that's no fun
2163 2011-09-24 23:53:14 <casascius> gmaxwell: yes, first 8 characters of address printed outside coin
2164 2011-09-24 23:54:12 <[Tycho]> In small batches 23mm Al coin costs ~0.7 BTC, Cu coin costs ~0.93 BTC and silver one is ~7.45 BTC
2165 2011-09-24 23:54:15 <casascius> One option I thought might be an acceptable alternative for importprivkey would be to eliminate all sha256 "minicodes", but then accept "sha256:anystringgoeshere" as being an acceptable way to import a key.
2166 2011-09-24 23:54:27 <casascius> (in addition to a 64-character hex string, perhaps in addition to some sort of QR-friendly base36 format)
2167 2011-09-24 23:55:01 <gmaxwell> casascius: yuck.
2168 2011-09-24 23:55:05 <[Tycho]> So only silver ones do make sense.
2169 2011-09-24 23:55:09 <casascius> but ideally, i am imagining that my personal copy of bitcoind will get "flushprivkey" before the UI ever gets an "import priv key" on the menu bar, so it's almost moot: I may as well offer redemption on my website
2170 2011-09-24 23:56:23 <gmaxwell> casascius: I don't have any issue with inputs in alternative bases. But the sha256(anystringhere). Encourages password like usage with pratically zero entropy, which is a bad thing.
2171 2011-09-24 23:56:34 <casascius> gmaxwell: yuck, but for example, base36 means you can fit a full privkey in 29x29 QR. so which is the yuckiest: forcing people to use bigger QR codes, or forcing them to use less entropy, or having to look at about 50 lines in the code to support a practical feature... (I will probably never personally create many QR codes so I don't so much care)
2172 2011-09-24 23:57:07 <casascius> gmaxwell: point accepted, and I can always offer redemption on my website and a separate utility
2173 2011-09-24 23:57:15 <gmaxwell> casascius: no no, I'm totally fine with supporting representations in other bases. You can use your current code for that, just support something to flag and convert the base.
2174 2011-09-24 23:57:20 normanrichards has quit (Quit: normanrichards)
2175 2011-09-24 23:58:05 <casascius> the other base should auto-detect if it has a crc of some sort
2176 2011-09-24 23:58:19 * sipa -> bed
2177 2011-09-24 23:58:20 <sipa> gn
2178 2011-09-24 23:58:24 <casascius> night
2179 2011-09-24 23:58:50 <gmaxwell> casascius: it should be reliably detectable based on the length.
2180 2011-09-24 23:59:00 <casascius> gmaxwell: agreed
2181 2011-09-24 23:59:21 <casascius> the same base58 scheme could be used, just with 36 symbols instead of 58
2182 2011-09-24 23:59:28 p0s has quit (Remote host closed the connection)
2183 2011-09-24 23:59:55 <gmaxwell> I think thats a fine idea. Just so long as it doesn't overtly encourage password like strings (your validity checking made me very happy in that regard), and has enough entropy.