1 2011-09-24 00:00:42 <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.
  2 2011-09-24 00:01:51 <lfm> well if they want to be stupid, I cant see how we prevent them other than not joining in they're stupidity
  3 2011-09-24 00:02:01 <lfm> their
  4 2011-09-24 00:02:24 <gmaxwell> Not joining is important. It's the only defense we have against stupid.
  5 2011-09-24 00:03:11 <lfm> or if we are evil, encourage them and exploit them
  6 2011-09-24 00:06:47 <roconnor> Interesting to see that this bug of ignoring one block when calcuating difficulty is exploitable.
  7 2011-09-24 00:07:07 <slimm609> anyone here help out with bit-len a few months back?
  8 2011-09-24 00:07:20 <lfm> bit-len?
  9 2011-09-24 00:07:37 <roconnor> I guess clients need to count not confirmations but amount of work in order to determine how confirmed a transaction is.
 10 2011-09-24 00:08:05 <slimm609> http://pastebin.com/raw.php?i=BUB3dygQ  bit-len
 11 2011-09-24 00:08:52 <lfm> roconnor: ya, that would be something to keep in mind for bitcoin alternative currencies (forks).
 12 2011-09-24 00:09:06 <sipa> that doesn't need any change
 13 2011-09-24 00:09:15 <sipa> confirmations is purely a local client issue
 14 2011-09-24 00:09:39 <roconnor> sipa: I think that is what I said :)
 15 2011-09-24 00:10:39 <lfm> significant for stuf like realcoins that do more frequent blocks
 16 2011-09-24 00:10:59 <lfm> slimm609: what about it?
 17 2011-09-24 00:11:12 <roconnor> sipa: I just read about this time-stamping attack.  Are there any plans to fix the code to not ignore blocks?
 18 2011-09-24 00:11:30 <sipa> roconnor: it has been suggested on the dev list, yes
 19 2011-09-24 00:12:15 <sipa> but it would require a incompatible update, so other solutions are looked at first
 20 2011-09-24 00:13:03 <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.
 21 2011-09-24 00:13:26 <sipa> how could that be?
 22 2011-09-24 00:13:55 <sipa> nBits in block N is a pure function of the timestamps in blocks 0 though N-1
 23 2011-09-24 00:14:38 <sipa> any change that takes more into account needs to have the ability to result in a different number
 24 2011-09-24 00:15:23 <lfm> or needs to recognize a fixed cut-over point that is supported by the majority
 25 2011-09-24 00:15:43 <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.
 26 2011-09-24 00:15:53 <roconnor> *upto now
 27 2011-09-24 00:16:04 <sipa> that's not enough
 28 2011-09-24 00:16:22 <sipa> it also needs to give the same value for any possible new block using the old code
 29 2011-09-24 00:16:28 <sipa> if you want backward compatibility
 30 2011-09-24 00:16:31 <lfm> roconnor: there is no way to have that give "the same value as the existing nBits functions"
 31 2011-09-24 00:16:34 <sipa> but maybe, just maybe
 32 2011-09-24 00:16:38 <roconnor> true, there could be blockchain splits in the future.
 33 2011-09-24 00:16:58 <sipa> there is an ability to fix the timestamps in the 2016*N-blocks algorithmically
 34 2011-09-24 00:17:33 <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.
 35 2011-09-24 00:17:40 <sipa> hey, wait
 36 2011-09-24 00:17:43 <sipa> a bit hacky
 37 2011-09-24 00:17:59 <gmaxwell> only impose the other rule if the timestamps indicate an exploit?
 38 2011-09-24 00:18:07 <roconnor> lfm: why is there no way to give the same value as the existing nBits function *on the current blockchain*?
 39 2011-09-24 00:18:11 <gmaxwell> ... no, then people can still trigger a split on demand. alas.
 40 2011-09-24 00:18:23 <lfm> roconnor: but that would mean the difficulty would lag the actual bitcoin mining rate even more than now
 41 2011-09-24 00:18:23 <sipa> but what about just forcing blocks 2016*N to have the same timestamp as block 2016*N-1 ?
 42 2011-09-24 00:18:55 <gmaxwell> it can't be the same, you mean the same +1?
 43 2011-09-24 00:18:56 <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
 44 2011-09-24 00:19:00 <sipa> gmaxwell: yes
 45 2011-09-24 00:19:04 <sipa> +1
 46 2011-09-24 00:19:27 <sipa> and as soon as a majority of the miners update, the network is updated
 47 2011-09-24 00:19:33 <gmaxwell> (by can't I mean can't be in all cases.. e.g. when the other was already at the median limit)
 48 2011-09-24 00:19:45 <luke-jr> easy solution = clients lock-in blocks after 120 confirms
 49 2011-09-24 00:19:46 <gmaxwell> That ... sounds okay to me, actually.
 50 2011-09-24 00:20:30 <luke-jr> might cause chaos on testnet, though
 51 2011-09-24 00:20:36 <gmaxwell> luke-jr: so we get a 24 hour transatlatnic internet outage and bitcoin is over?
 52 2011-09-24 00:21:09 <luke-jr> gmaxwell: yep. lots of stuff already assumes 6 confirmations is secure
 53 2011-09-24 00:21:10 <roconnor> luke-jr: unfortunately isolated and spoofed clients need the ability to reset
 54 2011-09-24 00:21:18 <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
 55 2011-09-24 00:22:27 <luke-jr> gmaxwell: clients could give users a manual override function too
 56 2011-09-24 00:22:40 <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.
 57 2011-09-24 00:22:52 <lfm> they have a manual override now! ctrl-c or exit
 58 2011-09-24 00:23:22 <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 ...
 59 2011-09-24 00:23:24 <roconnor> oh wait
 60 2011-09-24 00:24:02 <luke-jr> gmaxwell: how about manual override required to invalidate blocks over 120 heights old, that also revoke confirmed funds you received? ;)
 61 2011-09-24 00:24:02 <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)
 62 2011-09-24 00:24:29 <luke-jr> roconnor: you can always do that with over 50% hashpower
 63 2011-09-24 00:24:36 <luke-jr> except for lock-ns
 64 2011-09-24 00:24:38 <luke-jr> ins*
 65 2011-09-24 00:24:38 <roconnor> true
 66 2011-09-24 00:24:45 <lfm> ya any "fix" that has to go that far back will be serious with consequenses
 67 2011-09-24 00:25:00 <gmaxwell> Hush.
 68 2011-09-24 00:25:05 <gmaxwell> Sipa had a good idea.
 69 2011-09-24 00:25:07 <luke-jr> I'm not really sure I understand the problem.
 70 2011-09-24 00:25:08 <gmaxwell> We should do that.
 71 2011-09-24 00:25:21 <luke-jr> Bitcoin is basically doomed if anyone malicious gets >50% hashpower anyway
 72 2011-09-24 00:25:28 <gmaxwell> (well, we should think hard about it until we figure out why we shouldn't)
 73 2011-09-24 00:25:43 <roconnor> gmaxwell: the setting of the timestamps for N-1 and N to be the same?
 74 2011-09-24 00:26:00 <gmaxwell> luke-jr: it allows someone with <50% to eventually make a longer chain by fudging the timestmaps.
 75 2011-09-24 00:26:02 <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
 76 2011-09-24 00:26:11 <gmaxwell> roconnor: not the same, the same plus 1.
 77 2011-09-24 00:26:11 <sipa> right?
 78 2011-09-24 00:26:26 <roconnor> plus 1 second?
 79 2011-09-24 00:26:32 <gmaxwell> no. I didn't understand it what way.
 80 2011-09-24 00:26:41 <lfm> sipa sure, there is several ways to do that tho of course, dont even need any timestamp exploits
 81 2011-09-24 00:26:57 <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
 82 2011-09-24 00:26:58 <luke-jr> gmaxwell: that's only because clients will accept "historical data" without checking the timestamps at all
 83 2011-09-24 00:27:02 <roconnor> plus 1 um nanosecond?
 84 2011-09-24 00:27:08 <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.
 85 2011-09-24 00:27:17 <diki> i think its high time i built bitcoin on windows
 86 2011-09-24 00:27:22 <diki> oh boy....
 87 2011-09-24 00:27:30 <gmaxwell> luke-jr: they won't take timestaps from the far future, which is normally all thats required.
 88 2011-09-24 00:27:41 <gmaxwell> They also won't take timestamps violating the median rule.
 89 2011-09-24 00:27:54 <lfm> if you have 51% you can ignore all other miners and manipulate the difficulty with ease
 90 2011-09-24 00:28:10 <gmaxwell> But this goofs it up because you can stick crazy timestamps in and break the median rules application because it's not ignored.
 91 2011-09-24 00:28:47 <gmaxwell> lfm: no you can't.
 92 2011-09-24 00:29:08 <gmaxwell> lfm: if you make the timestamps wrong enough (needed to manipulate the difficulty) your blocks will get ignored.
 93 2011-09-24 00:30:18 <sipa> hmmm 4:30 am
 94 2011-09-24 00:37:00 <roconnor> funny, I noticed this skipped block when computing timestamp thing months ago, but I wasn't smart enough to engineer an exploit. :(
 95 2011-09-24 00:37:21 <roconnor> I guess the sticking point it that you still need 50%+1 attack power
 96 2011-09-24 00:38:19 <lfm> ya ignoreing one block outa 2016 is not real big hole to exploit
 97 2011-09-24 00:39:02 <sipa> tell that to the solidcoin people :p
 98 2011-09-24 00:39:16 <sipa> oh no, the geistgeld people
 99 2011-09-24 00:39:50 <sipa> which admittedly had different constants that made this attack way more powerful
100 2011-09-24 00:41:21 <lfm> sipa yup, if you wanna update difficulty more often it is relativly bigger hole
101 2011-09-24 00:41:52 <lfm> sipa I thot you went -> sleep? grin
102 2011-09-24 00:42:07 <sipa> right, i almost forgot
103 2011-09-24 01:20:45 <CIA-101> bitcoin: Kano * rafe03c630253 cgminer/main.c: Hash is 32 bytes (64 nibbles)
104 2011-09-24 01:20:46 <CIA-101> bitcoin: Con Kolivas * r7c26948e453e cgminer/main.c: Merge pull request #50 from kanoi/kano
105 2011-09-24 02:50:27 <dikidera> i'd like to know, is the merkle root used when generating a getwork from ALL the PENDING transactions
106 2011-09-24 02:50:38 <dikidera> or just those my client will include IF it finds a block?
107 2011-09-24 05:34:01 <ThomasV> please update topic
108 2011-09-24 07:34:52 <d33tah> sipa: you here by any chance?
109 2011-09-24 07:35:22 <d33tah> i need help implementing ECDSA_verify test code.
110 2011-09-24 07:35:58 <d33tah> (anyone else would be fine as well actually)
111 2011-09-24 07:40:48 <d33tah> i have no idea how to get an EC_KEY instance
112 2011-09-24 08:05:58 <d33tah> atm i have it like this:
113 2011-09-24 08:05:59 <d33tah> EC_KEY *pkey = EC_KEY_new_by_curve_name(NID_secp256k1);
114 2011-09-24 08:06:06 <d33tah> but now I dunno how to get a privkey outta a public key
115 2011-09-24 08:06:17 <sipa> you can't
116 2011-09-24 08:06:31 <d33tah> so how can I verify if the signature is correct?
117 2011-09-24 08:06:37 <d33tah> (mind looking at my code?)
118 2011-09-24 08:06:55 <sipa> you verify it using the public key
119 2011-09-24 08:07:30 <d33tah> is the public key given in a normal transaction?
120 2011-09-24 08:07:58 <sipa> yes
121 2011-09-24 08:08:06 <d33tah> hm
122 2011-09-24 08:08:25 <d33tah> so to verify a signature, i need a public key and the message?
123 2011-09-24 08:08:36 <d33tah> only that?
124 2011-09-24 08:08:45 <sipa> and a signature, obviously
125 2011-09-24 08:08:53 <d33tah> alright
126 2011-09-24 08:09:15 <d33tah> the message is 'hash', the signature being 'pchSig', right?
127 2011-09-24 08:09:22 <sipa> yes
128 2011-09-24 08:09:39 <d33tah> so now I need the pubkey
129 2011-09-24 08:09:42 <d33tah> damnit :P
130 2011-09-24 08:09:52 <sipa> and the key is in a CKey object
131 2011-09-24 08:09:58 <d33tah> no way to extract it from the privkey, right?
132 2011-09-24 08:10:10 <sipa> sure is
133 2011-09-24 08:10:24 <d33tah> mind helping me to patch my code up?
134 2011-09-24 08:10:40 <sipa> k, show me
135 2011-09-24 08:10:52 <d33tah> http://wklej.org/id/598784/
136 2011-09-24 08:11:04 <d33tah> i know i put the privkey here, it's testnet
137 2011-09-24 08:13:47 <sipa> what is privkey?
138 2011-09-24 08:14:05 <sipa> which format?
139 2011-09-24 08:14:29 <d33tah> HexStr(vchSecret.begin(), vchSecret.end()).c_str())
140 2011-09-24 08:14:32 <d33tah> as you advised me
141 2011-09-24 08:15:32 <d33tah> i'm not sure the UnHex is perfect, but I hope so ;)
142 2011-09-24 08:16:06 <sipa> have you looked at what SetSecret() needs to do to c
143 2011-09-24 08:16:31 <sipa> to get it into an EC_KEY object?
144 2011-09-24 08:16:56 <d33tah> hmmm
145 2011-09-24 08:17:02 <d33tah> what I can see there is not optimistic
146 2011-09-24 08:17:24 <d33tah> for some reason the result of UnHex on privkey is 33, not 32 bytes long
147 2011-09-24 08:17:36 <d33tah> is BN_bin2bn OpenSSLish?
148 2011-09-24 08:18:30 <sipa> yes
149 2011-09-24 08:18:34 <d33tah> okay
150 2011-09-24 08:18:37 <d33tah> i didn't cast this one
151 2011-09-24 08:18:52 <d33tah> and does EC_KEY_regenerate_key get the pubkey from privkey?
152 2011-09-24 08:18:57 <sipa> no
153 2011-09-24 08:19:17 <sipa> it creates an ec_key from just the secret
154 2011-09-24 08:19:37 <sipa> which you can use for everything
155 2011-09-24 08:19:45 <d33tah> hm, i'll try.
156 2011-09-24 08:20:02 <sipa> but to make things easy for you
157 2011-09-24 08:20:37 <sipa> use the full serialized private key (CPrivKey) instead of just the secret
158 2011-09-24 08:23:25 <d33tah> zsh: segmentation fault  ./verify
159 2011-09-24 08:23:36 <d33tah> Program received signal SIGSEGV, Segmentation fault.
160 2011-09-24 08:23:37 <d33tah> 0xb7edae99 in BN_bin2bn () from /usr/lib/i686/cmov/libcrypto.so.0.9.8
161 2011-09-24 08:23:52 <d33tah> const char* c_privkey = privkey.c_str();
162 2011-09-24 08:23:53 <d33tah> BIGNUM *bn = BN_bin2bn((const unsigned char*)c_privkey[0],32,BN_new());
163 2011-09-24 08:24:04 <d33tah> guess I messed the pointers up?
164 2011-09-24 08:24:34 <d33tah> hm, i fixed it
165 2011-09-24 08:25:22 <d33tah> ok, it doesn't return -1 anymore
166 2011-09-24 08:25:32 <d33tah> but now it doesn't seem to care if I mess the privkey or not
167 2011-09-24 08:25:37 <d33tah> mess up*
168 2011-09-24 08:25:54 <d33tah> i changed a random character inside of it and it still seems to pass
169 2011-09-24 08:26:13 <sipa> what does it return?
170 2011-09-24 08:27:01 <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).
171 2011-09-24 08:27:04 <d33tah> it returned 0
172 2011-09-24 08:27:10 <d33tah> so it looks like i'm prematurely happy
173 2011-09-24 08:27:14 <d33tah> want to see the code now?
174 2011-09-24 08:28:45 <sipa> 0 = incorrect signature
175 2011-09-24 08:28:54 <d33tah> yeah
176 2011-09-24 08:29:01 <d33tah> but i copied it from my debug code
177 2011-09-24 08:29:05 <d33tah> it sure is correct
178 2011-09-24 08:29:08 <d33tah> bitcoin accepted it
179 2011-09-24 08:29:10 <sipa> show me
180 2011-09-24 08:29:15 <d33tah> the debug code?
181 2011-09-24 08:29:31 <sipa> whatever code you have
182 2011-09-24 08:29:42 <d33tah> i hacked key.h like this:
183 2011-09-24 08:29:43 <d33tah> http://wklej.org/id/598789/
184 2011-09-24 08:29:52 <d33tah> and I copied the values from there to unhex
185 2011-09-24 08:29:57 <sipa> no, your own
186 2011-09-24 08:30:21 <d33tah> the one verifying?
187 2011-09-24 08:30:25 <sipa> yes
188 2011-09-24 08:30:29 <d33tah> http://wklej.org/id/598790/
189 2011-09-24 08:32:22 <sipa> why do you still call set private key yourself?
190 2011-09-24 08:32:35 <sipa> regenerate does that
191 2011-09-24 08:32:46 <d33tah> damnit
192 2011-09-24 08:32:50 <d33tah> i found another error as well :d
193 2011-09-24 08:32:57 <d33tah> unsigned long ret won't ever store -1
194 2011-09-24 08:33:21 <sipa> true
195 2011-09-24 08:33:25 <d33tah> let's try now...
196 2011-09-24 08:33:37 <d33tah> > make verify LDFLAGS="-lcrypto" && ./verify
197 2011-09-24 08:34:00 <d33tah> yet
198 2011-09-24 08:34:12 <d33tah> not good :p
199 2011-09-24 08:34:55 <sipa> ecdsa_verify returns an int btw
200 2011-09-24 08:35:09 <d33tah> fixed it now
201 2011-09-24 08:35:14 <d33tah> and commented the set privkey
202 2011-09-24 08:35:46 <d33tah> anyway
203 2011-09-24 08:35:53 <d33tah> the privkey shouldn't be 33 bytes, right?
204 2011-09-24 08:36:08 <sipa> your privkey variable?
205 2011-09-24 08:36:25 <d33tah> yeah
206 2011-09-24 08:36:46 <sipa> no
207 2011-09-24 08:37:05 <sipa> in unhex
208 2011-09-24 08:37:14 <sipa> you need <length
209 2011-09-24 08:37:19 <sipa> not <=
210 2011-09-24 08:37:53 <d33tah> now it's 32 bytes
211 2011-09-24 08:37:55 <d33tah> still not there
212 2011-09-24 08:40:36 <d33tah> privkey.length()=32; hash.length()=32; pchSig.length()=71
213 2011-09-24 08:40:58 <d33tah> want the current copy of my code?
214 2011-09-24 08:49:07 <d33tah> sipa: still any hope?
215 2011-09-24 09:26:44 <d33tah> sigh.
216 2011-09-24 09:26:53 <d33tah> looks like i have no chances :/
217 2011-09-24 09:38:36 <FellowTraveler> Hi all.
218 2011-09-24 09:48:47 <d33tah> sipa: if you find anything, PM user 'DeeTah', it's on my shell account
219 2011-09-24 09:48:55 <d33tah> i'd really love to set it running
220 2011-09-24 09:49:14 <sipa> d33tah: what's the current version of the code?
221 2011-09-24 10:31:24 <dikidera> if bitcoin 0.4.0 uses bdb 4.8 does that mean i have to upgrade my libraries to compile?
222 2011-09-24 10:35:28 <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
223 2011-09-24 10:35:47 <Optimo> whoops wrong channel, sorries
224 2011-09-24 10:49:27 <luke-jr> dikidera: it uses whatever bdb you link it with
225 2011-09-24 10:49:37 <luke-jr> dikidera: they just built their official binaries with 4.8
226 2011-09-24 10:59:05 <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
227 2011-09-24 11:03:18 <sipa> iddo: i think the double sha256 was indeed just satoshi being cautious
228 2011-09-24 11:05:46 <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
229 2011-09-24 11:06:20 <iddo> more secure against non-bruteforce attack, if anyone ever discovers such attack
230 2011-09-24 11:06:51 <iddo> for brute force attacks i think that double-hash shouldn't matter, the difficulty would just adjust...
231 2011-09-24 11:07:00 <cjdelisle> Some people think multi iteration hashing is more prone to collisions
232 2011-09-24 11:07:09 <cjdelisle> Some people don't know what they're talking about.
233 2011-09-24 11:08:21 <iddo> as i wrote, collisions aren't relevant for bitcoin
234 2011-09-24 11:08:36 <iddo> but i don't think that argument was true anyway
235 2011-09-24 11:09:19 <cjdelisle> It would be true if the hash function itself was badly designed (IE it was not collision resistant to start with)
236 2011-09-24 11:10:40 <iddo> basically the question is how many preimages (of bounded size) exist, depending on the number of rounds of sha256
237 2011-09-24 11:10:56 <iddo> i don't think that more rounds imply more preimages
238 2011-09-24 11:11:42 <cjdelisle> btw I tried to optimize the sha implementation and I can say quite certainly that 2 rounds make optimization/cracking attempts suck.
239 2011-09-24 11:12:30 <iddo> what do you mean by cracking ? something other than brute-force ?
240 2011-09-24 11:13:24 <cjdelisle> http://pastebay.com/138988
241 2011-09-24 11:15:28 <iddo> looks like brute-force, nonce always increased by 1
242 2011-09-24 11:15:45 <cjdelisle> That's mining code
243 2011-09-24 11:15:55 <cjdelisle> What I did was work on trying to make it faster
244 2011-09-24 11:16:01 <mtrlt> the same optimizations have been in place in all miners for months.
245 2011-09-24 11:16:05 <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
246 2011-09-24 11:16:31 <mtrlt> yep
247 2011-09-24 11:16:40 <cjdelisle> I had a few other optimizations which I ripped out because they used too much memory
248 2011-09-24 11:16:55 <iddo> still not sure what the word 'cracking' refers to
249 2011-09-24 11:17:24 <mtrlt> cjdelisle: what kind of optimizations?
250 2011-09-24 11:17:28 <cjdelisle> Cracking means making an attack easier than it was before.
251 2011-09-24 11:18:14 <iddo> ok but in this case you simply meant easier because it's more optimized brute-force ?
252 2011-09-24 11:18:31 <cjdelisle> That's what a crack is.
253 2011-09-24 11:18:43 <cjdelisle> If you can brute faster
254 2011-09-24 11:19:35 <iddo> for md5 for example there are better attacks than brute force
255 2011-09-24 11:20:36 <cjdelisle> mtrlt: I was precalculating work[16] and work[17] since they only depend on mercle and ntime
256 2011-09-24 11:22:13 <cjdelisle> mtrlt: here's the more optimized version http://pastebay.com/139221
257 2011-09-24 11:23:15 <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.
258 2011-09-24 11:24:30 <samthetechie> Talk on Bitcoin live from London Hackspace: http://www.ustream.tv/channel/bitcoin-weekend
259 2011-09-24 11:24:33 <iddo> i wonder if some people keep their optimized miner private?
260 2011-09-24 11:25:06 <cjdelisle> some do
261 2011-09-24 11:25:19 <cjdelisle> I don't much care, I am not interested in mining per se
262 2011-09-24 11:26:11 <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
263 2011-09-24 11:26:47 <cjdelisle> why do you keep it secret?
264 2011-09-24 11:27:25 <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?
265 2011-09-24 11:27:31 <mtrlt> nope
266 2011-09-24 11:27:32 <iddo> cjdelisle: what are you interested in?
267 2011-09-24 11:27:36 <mtrlt> as i said, it's not any faster than other miners
268 2011-09-24 11:28:07 <iddo> samthetechie: who is the girl talking?
269 2011-09-24 11:28:11 <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.
270 2011-09-24 11:28:25 <mtrlt> it'd just be a PITA to release it in a form that even stupid people could use
271 2011-09-24 11:28:51 <cjdelisle> I don't care about stupid people, that's why I release my optimizations with pastebay :)
272 2011-09-24 11:28:51 <jix_> cjdelisle: now if you have a 50% faster mining code and use watercooling + overclocking.....
273 2011-09-24 11:29:09 <mtrlt> and it has some bugs left :P
274 2011-09-24 11:29:17 <mtrlt> threads dying for no reason etc.
275 2011-09-24 11:29:23 <samthetechie> @iddo the girl is lumos
276 2011-09-24 11:29:32 <sipa> cjdelisle: double hashing does increase the chance for collisions
277 2011-09-24 11:29:35 <cjdelisle> So does the second paste, it returns bad values sometimes.
278 2011-09-24 11:29:36 <sipa> but only slightly
279 2011-09-24 11:30:00 <samthetechie> we are hanging out at #bitcoinweekend
280 2011-09-24 11:30:11 <mtrlt> cjdelisle: well at least that's easily fixable
281 2011-09-24 11:30:28 <mtrlt> i know SHA-256 in and out but am a rookie in multithreading :P
282 2011-09-24 11:30:42 <cjdelisle> I just made a mistake somewhere and/or I don't understand how cuda works
283 2011-09-24 11:30:45 <iddo> samthetechie: not mentioned here? http://wiki.london.hackspace.org.uk/view/Project:Bitcoin/Bitcoin_Weekend_2011
284 2011-09-24 11:30:52 <iddo> samthetechie: is she talking about bitcoin?
285 2011-09-24 11:30:59 <cjdelisle> I find that whenever I try to return when I find the hash, it breaks it.
286 2011-09-24 11:31:03 <iddo> ah yes talking about bitcoin now
287 2011-09-24 11:31:17 <mtrlt> use opencl. problem solved
288 2011-09-24 11:31:21 <cjdelisle> heh
289 2011-09-24 11:31:28 <cjdelisle> I have an nshittia card
290 2011-09-24 11:31:35 <mtrlt> that does not support opencl?
291 2011-09-24 11:31:43 <cjdelisle> Actually I think it does.
292 2011-09-24 11:31:53 <mtrlt> i thought opencl just uses cuda internally
293 2011-09-24 11:32:06 <cjdelisle> and I don't care about mining so I just fool around with it like this
294 2011-09-24 11:32:07 <sipa> opencl on nvidia does
295 2011-09-24 11:32:14 <mtrlt> yeah
296 2011-09-24 11:32:22 <mtrlt> cjdelisle: i care because it gives me monies
297 2011-09-24 11:32:37 <cjdelisle> Maybe I'll mine this winter if I get cold :)
298 2011-09-24 11:32:53 <mtrlt> heh
299 2011-09-24 11:32:55 <iddo> sipa: why more collisions? isn't it simply sha256 with more rounds?
300 2011-09-24 11:33:01 <mtrlt> too bad i don't pay for heating, i'd mine otherwise :p
301 2011-09-24 11:33:09 <cjdelisle> I like making things fast and I like attacking and understanding crypto.
302 2011-09-24 11:33:11 <sipa> iddo: noagendamarket
303 2011-09-24 11:33:13 <sipa> eh
304 2011-09-24 11:33:14 <sipa> iddo: no
305 2011-09-24 11:33:29 <sipa> iddo: because there are only 2^256 possible inputs to the second hashing step
306 2011-09-24 11:33:46 <sipa> and they are again mapped to 2^256 possible outputs
307 2011-09-24 11:33:55 <sipa> but there is some chance for collisions there
308 2011-09-24 11:34:10 <sipa> and as long as two inputs in that 2^256 space hash to the same value
309 2011-09-24 11:34:20 <sipa> that means one output can't occur anymore
310 2011-09-24 11:34:24 <iddo> sipa: so you don't claim more collisions assuming the original input is bounded by 256 bits ?
311 2011-09-24 11:34:30 <mtrlt> but are there two inputs like that?
312 2011-09-24 11:34:38 <cjdelisle> The reason why it introduces more collisions is because any non-perfect hash has fewer than 2^256 possible outputs.
313 2011-09-24 11:34:39 <sipa> mtrlt: statistically, some
314 2011-09-24 11:34:48 <mtrlt> yes but have any been found
315 2011-09-24 11:34:50 <sipa> cjdelisle: even a perfect one
316 2011-09-24 11:34:54 <sipa> mtrlt: irrelevant
317 2011-09-24 11:35:03 <mtrlt> why?
318 2011-09-24 11:35:13 <mtrlt> i know it's hard to find one :P
319 2011-09-24 11:35:13 <sipa> you can calculate it
320 2011-09-24 11:35:29 <cjdelisle> f(x) { return x }  has an equal number of outputs as inputs.
321 2011-09-24 11:35:30 <mtrlt> and what assumptions does the calculation make?
322 2011-09-24 11:35:37 <mtrlt> that sha-256 is random?
323 2011-09-24 11:35:41 <mtrlt> which is a stupid assumption
324 2011-09-24 11:35:53 <sipa> on average, assuming a perfect hash function, there will be (1-1/e)*2^256 possible outputs
325 2011-09-24 11:36:06 <sipa> if it's less then perfect, there will probably be less
326 2011-09-24 11:36:08 <mtrlt> so it _does_ assume sha-256 is random.
327 2011-09-24 11:36:08 <vegard> mtrlt: why?
328 2011-09-24 11:36:15 <mtrlt> because it is not random :P
329 2011-09-24 11:36:21 <Diablo-D3> sha256 isnt random
330 2011-09-24 11:36:23 <iddo> sha256 takes 512 bits input block and outputs 256 bits digest, right?
331 2011-09-24 11:36:24 <sipa> mtrlt: no, sha256 being perfect is the best case
332 2011-09-24 11:36:35 <sipa> so it's safe to analyse using that assumption
333 2011-09-24 11:36:38 <vegard> it is indistinguishable from random
334 2011-09-24 11:36:41 <Diablo-D3> iddo: no, 256 in 256 out
335 2011-09-24 11:36:45 <mtrlt> sipa: [16:35:34] <cjdelisle>  f(x) { return x }  has an equal number of outputs as inputs.
336 2011-09-24 11:36:50 <Diablo-D3> iddo: well, 256 in per block
337 2011-09-24 11:37:01 <sipa> mtrlt: yes, but that's a very bad hash funcion :)
338 2011-09-24 11:37:08 <sipa> mtrlt: there is always a destructive step inside
339 2011-09-24 11:37:13 <iddo> Diablo-D3: but block is 512, no?
340 2011-09-24 11:37:15 <sipa> your function doesn't have one
341 2011-09-24 11:37:17 <sipa> iddo: yes
342 2011-09-24 11:37:20 <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.
343 2011-09-24 11:37:24 <Diablo-D3> iddo: no, the input isnt, the internal state is
344 2011-09-24 11:37:37 <mtrlt> sipa: and the destructive step always causes not all outputs to be used
345 2011-09-24 11:37:38 <mtrlt> ?
346 2011-09-24 11:37:43 <iddo> Diablo-D3: i think it's the other way around
347 2011-09-24 11:37:47 <sipa> Diablo-D3: input blocks to sha256 are 512 bits
348 2011-09-24 11:37:51 <Diablo-D3> iddo: I wrote a miner.
349 2011-09-24 11:37:54 <sipa> the state is 256 bits
350 2011-09-24 11:37:58 <Diablo-D3> Are you _really_ sure you want to argue this?
351 2011-09-24 11:38:25 <Diablo-D3> mtrlt: and thats not true, if theres ANY entropy lost, its a bad hash function
352 2011-09-24 11:38:25 <vegard> Diablo-D3: wikipedia says so :-P
353 2011-09-24 11:38:31 <wumpus> hash functions can be built from a block cipher too, which has no destructive step
354 2011-09-24 11:38:41 <mtrlt> Diablo-D3: yea
355 2011-09-24 11:38:44 <sipa> Diablo-D3: a hash function MUST decrease entropy
356 2011-09-24 11:38:53 <mtrlt> um
357 2011-09-24 11:38:54 <cjdelisle> ^not true
358 2011-09-24 11:38:55 <Diablo-D3> sipa: no
359 2011-09-24 11:39:04 <Diablo-D3> decreasing bits != decreasing entropy
360 2011-09-24 11:39:10 <sipa> i know what entropy means
361 2011-09-24 11:39:17 <Diablo-D3> as long as every bit effects every bit in the output, no entropy has been lost
362 2011-09-24 11:39:21 <wumpus> it does reduce the maximum entropy possible, with less bits you can have less entropy
363 2011-09-24 11:39:22 <sipa> wrong
364 2011-09-24 11:39:37 <sipa> that's avalanche effect, and it definitely causes loss of entropy
365 2011-09-24 11:39:40 <Diablo-D3> wumpus: depends how you define less
366 2011-09-24 11:39:44 <iddo> hash functions is defined as compressing the input, i think
367 2011-09-24 11:39:51 <cjdelisle> wrong
368 2011-09-24 11:39:55 <wumpus> Diablo-D3: 32 bits can have maximum 32 bits of entropy
369 2011-09-24 11:39:58 <Diablo-D3> iddo: irrecoverably compressing it, yes
370 2011-09-24 11:40:09 <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
371 2011-09-24 11:40:15 <sipa> Diablo-D3: if i feed 2^256 possible inputs to sha256, i will get less that 2^256 different outputs
372 2011-09-24 11:40:15 <wumpus> Diablo-D3: otherwise you could say that reducing things to 1 bit can still maintain all the entropy :p
373 2011-09-24 11:40:21 <sipa> than
374 2011-09-24 11:40:22 <mtrlt> sipa: are you sure?
375 2011-09-24 11:40:25 <Diablo-D3> sipa: prove it.
376 2011-09-24 11:40:25 <sipa> yes
377 2011-09-24 11:40:27 <cjdelisle> Hash function means irreversable. Collision resistance and compression are just interesting properties of some hashes.
378 2011-09-24 11:40:29 <mtrlt> why are you sure?
379 2011-09-24 11:40:36 <mtrlt> because of the calculation that assumes sha-256 is random?
380 2011-09-24 11:40:40 <mtrlt> which is bunk
381 2011-09-24 11:40:42 <Diablo-D3> find sha256 collisions for trivial inputs.
382 2011-09-24 11:40:42 <sipa> well, i can't prove it without an example
383 2011-09-24 11:40:53 <sipa> but it would be excessively unlikely to be so
384 2011-09-24 11:40:59 <mtrlt> so you are not sure
385 2011-09-24 11:41:04 <mtrlt> 100% != 99.9%
386 2011-09-24 11:41:08 <sipa> ok, i am not sure
387 2011-09-24 11:41:17 <Diablo-D3> there is no evidence that sha256 has collisions for trivial inputs.
388 2011-09-24 11:41:20 <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?
389 2011-09-24 11:41:26 <Gekz> it's mathematically improbable that sha256 will have 0 collisions
390 2011-09-24 11:41:34 <Gekz> have some asymptotes.
391 2011-09-24 11:41:36 <mtrlt> Gekz: but not impossible
392 2011-09-24 11:41:45 <sipa> assume each input is mapped to an arbitrary and independent output
393 2011-09-24 11:41:53 <sipa> in that case the birthday paradox applies
394 2011-09-24 11:41:58 <mtrlt> sipa: that assumption is bunk, i already told you
395 2011-09-24 11:42:03 <vegard> it is impossible that it has 0 collisions, due to the pidgeonhole principle
396 2011-09-24 11:42:15 <mtrlt> vegard: talking about 2^256 inputs mapping to 2^256 outputs
397 2011-09-24 11:42:40 <sipa> mtrlt: it's excessively unlikely that it makes a difference
398 2011-09-24 11:42:45 <sipa> yes sha256 is not random
399 2011-09-24 11:42:46 <wumpus> if you use a block cipher as hash, you're sure that each 256 bits input maps to a different 256 bit output
400 2011-09-24 11:42:48 <mtrlt> yes but not impossible :P
401 2011-09-24 11:43:07 <sipa> so what are you arguing about?
402 2011-09-24 11:43:16 <mtrlt> arguing for the sake of arguing
403 2011-09-24 11:43:19 <mtrlt> i like it
404 2011-09-24 11:43:25 <sipa> that the chance exist that sha256 maps 2^256 inputs to 2^256 different outputs?
405 2011-09-24 11:43:30 <mtrlt> yeah
406 2011-09-24 11:43:31 <sipa> yes, that may be so
407 2011-09-24 11:43:37 <mtrlt> it's not impossible.
408 2011-09-24 11:43:42 <sipa> but not for all possible sets of 2^256 inputs
409 2011-09-24 11:43:52 <mtrlt> obviously
410 2011-09-24 11:44:17 <iddo> so what about the 2^256 inputs with double-sha256, any argument why it implies more collisions?
411 2011-09-24 11:44:37 <mtrlt> if there is 1 collision with 1 sha256, there are more in double-sha256
412 2011-09-24 11:44:55 <sipa> iddo: ready to assume with me, that for the context of this reasoning, that sha256 is approximated by a random function?
413 2011-09-24 11:45:02 <mtrlt> :P
414 2011-09-24 11:45:08 <iddo> sipa: ok
415 2011-09-24 11:45:12 <sipa> because mtrlt apparently isn't, which makes any reasoning useless
416 2011-09-24 11:45:19 <sipa> ok, you know the birthday paradox?
417 2011-09-24 11:45:21 <mtrlt> you don't have to assume that. you can assume there are collisions, for whatever reason
418 2011-09-24 11:45:27 <iddo> sipa: yes
419 2011-09-24 11:45:53 <sipa> so, after 2^128 different inputs, there will be a 50% chance to have found one collision already in the output
420 2011-09-24 11:46:08 <iddo> right
421 2011-09-24 11:46:15 <sipa> can you estimate how many you'll have found after 2^256 inputs?
422 2011-09-24 11:46:21 <vegard> mtrlt: oh right
423 2011-09-24 11:46:39 <sipa> the result is that there are more like 2^255 different outputs than 2^256
424 2011-09-24 11:46:49 <iddo> 2^128 collisions?
425 2011-09-24 11:46:57 <sipa> approximately
426 2011-09-24 11:47:16 <sipa> iirc you get on average (1-1/e)*2^256 different outputs
427 2011-09-24 11:47:38 <sipa> which is 2^255.33
428 2011-09-24 11:48:04 <sipa> so double-sha256 is (probably...) more a 255.33 bit hash function than a 256-bit one
429 2011-09-24 11:48:14 <wumpus> how many times to hash before you have approx 1 output left ? :)
430 2011-09-24 11:48:16 <iddo> i see
431 2011-09-24 11:48:29 <sipa> wumpus: the third hashing step decreases a lot less
432 2011-09-24 11:48:51 <sipa> and so on
433 2011-09-24 11:49:00 <mtrlt> i want to see a function with the amount of bits after hashing step x
434 2011-09-24 11:49:19 <sipa> so i don't it matters much if you do 100 or 1000000 hashing steps
435 2011-09-24 11:49:22 <sipa> in practice
436 2011-09-24 11:49:41 <mtrlt> how would you calculate the bits after hashing step 3?
437 2011-09-24 11:49:57 <sipa> mtrlt: i tried to calculate it, but never got to a closed formula :)
438 2011-09-24 11:49:58 <iddo> yeah it's at least 2^256-100 etc.
439 2011-09-24 11:50:08 <mtrlt> heh
440 2011-09-24 11:50:52 <cjdelisle> 512 bits of input mapped to 256 bits of output must have collisions due to the butthole principle
441 2011-09-24 11:51:13 <sipa> indeed
442 2011-09-24 11:51:18 <mtrlt> yea
443 2011-09-24 11:51:28 <cjdelisle> but 256 bits of input and 256 bits of constant input mapped to 256 bits of output do not have that characteristic.
444 2011-09-24 11:51:38 <mtrlt> they don't have it necessarily
445 2011-09-24 11:51:54 <mtrlt> they can have it.
446 2011-09-24 11:52:11 <cjdelisle> unless the hash function has collisions within 256 bits and in that case the hash function sucks
447 2011-09-24 11:52:24 <mtrlt> why does it suck?
448 2011-09-24 11:52:41 <sipa> cjdelisle: on the contrary
449 2011-09-24 11:53:17 <sipa> if it doesn't have collisions in a known set of 2^256 inputs, it has a massive (and i assume exploitable) structure
450 2011-09-24 11:53:49 <vegard> not necessarily, I think
451 2011-09-24 11:53:52 <iddo> why?
452 2011-09-24 11:54:20 <vegard> you can make one-way permutations based on public-key ciphers, right
453 2011-09-24 11:54:31 <sipa> true
454 2011-09-24 11:54:36 <sipa> yes i may be wrong
455 2011-09-24 11:54:37 <iddo> sipa: what do you mean by known set?
456 2011-09-24 11:54:56 <iddo> sha256 takes 512 bit block and outputs 256 bits
457 2011-09-24 11:55:53 <iddo> known set means 2^256 values padded with 256 const bits?
458 2011-09-24 11:56:04 <sipa> that would be a known set yes
459 2011-09-24 11:56:18 <iddo> and why would it imply weakness?
460 2011-09-24 11:56:18 <sipa> but again, i may be wrong
461 2011-09-24 11:57:41 <iddo> ahh because random function should collisions in that set due to birthday paradox?
462 2011-09-24 11:58:13 <iddo> i see
463 2011-09-24 11:58:34 <iddo> s/should/should have
464 2011-09-24 12:04:50 <luke-jr> O.o
465 2011-09-24 12:08:10 <Optimo> how can I trick people into spending btc on a 'jukebox' webapp
466 2011-09-24 12:08:21 <mtrlt> make the app really good
467 2011-09-24 12:08:29 <sipa> call yourself 'apple'
468 2011-09-24 12:10:17 <dikidera> i wonder if someone will make a company like Banana or Orange
469 2011-09-24 12:10:33 <dikidera> the products, obviously, will start with 'i'
470 2011-09-24 12:11:45 <Eliel> iBanana! :)
471 2011-09-24 12:12:06 <b4epoche_> I guess you're all too young to remember Bloom County
472 2011-09-24 12:12:34 <b4epoche_> Optimo:  Bloom County?
473 2011-09-24 12:15:01 <Optimo> bananaTV is software for streaming files to your AppleTV device
474 2011-09-24 12:15:03 <Optimo> ;p
475 2011-09-24 12:15:10 <Optimo> b4epoche what is bloom county?
476 2011-09-24 12:19:00 <b4epoche_> http://en.wikipedia.org/wiki/Bloom_County
477 2011-09-24 12:20:00 <Optimo> wasn't in my sunday funnies
478 2011-09-24 12:20:29 <b4epoche_> http://toastytech.com/guis/banana2.html
479 2011-09-24 12:32:13 <cjdelisle> http://www.betabeat.com/2011/07/28/another-midtown-restaurant-hudson-eatery-now-accepts-bitcoin/
480 2011-09-24 12:37:12 <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?
481 2011-09-24 12:37:45 <n5> i mean about server admin or smth who see source of shop
482 2011-09-24 12:38:07 <cjdelisle> With wallet crypto, nobody can send money without the key.
483 2011-09-24 12:38:29 <cjdelisle> As far as someone stealing the wallet.dat file and attacking that directly, that is a more difficult matter.
484 2011-09-24 12:38:50 <cjdelisle> It's all about math and how hard it is to crack, how hard the password is, etc.
485 2011-09-24 12:39:25 <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.
486 2011-09-24 12:40:24 <n5> yes, but i can keep on difrent server runing client
487 2011-09-24 12:40:58 <n5> ok, thanks you, i got answer i was looking for :)
488 2011-09-24 13:05:16 <semb> right now what script forms are propagated - obviously transaction to bitcoin address, but are transactions to a public key also allowed?
489 2011-09-24 13:05:34 <semb> i.e. scriptPubKey: <pubKey> OP_CHECKSIG
490 2011-09-24 13:06:01 <semb> by 'allowed' i mean will these tx be propagated?
491 2011-09-24 13:07:50 <tcatm> semb: yes
492 2011-09-24 13:08:10 <semb> is it just the 2 forms?
493 2011-09-24 13:08:22 <tcatm> that's how "IP transactions" worked
494 2011-09-24 13:08:50 <semb> i'm thinking of a way for bitcoin URIs to be used to receive money
495 2011-09-24 13:10:14 <tcatm> how would that work?
496 2011-09-24 13:10:31 <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.
497 2011-09-24 13:10:57 <semb> next encode into the URI the hash of the public key, and the private key
498 2011-09-24 13:11:23 <semb> voila, the recipient now can find the tx, and accept the money
499 2011-09-24 13:11:36 <semb> and the URI is not too long.
500 2011-09-24 13:12:15 <tcatm> so the sender generates the private key?
501 2011-09-24 13:12:20 <semb> yes
502 2011-09-24 13:12:31 <semb> sender generates a keypair
503 2011-09-24 13:12:52 <semb> obviously if the recipient wants to be sure the money is theirs they need to spend it immediately
504 2011-09-24 13:13:07 <semb> standard tx to an address owned by themselves will do
505 2011-09-24 13:13:36 <tcatm> there must be a more elegant solution. this would essentially require two bitcoin transactions
506 2011-09-24 13:13:37 <semb> or another 'send to ip address' tx
507 2011-09-24 13:13:52 <semb> one to send the money, another to 'claim' it
508 2011-09-24 13:14:48 <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
509 2011-09-24 13:15:32 <semb> this scheme would be useful to be able to send money via a web link, email or sms
510 2011-09-24 13:15:34 <tcatm> sure. the url can return an address/public key
511 2011-09-24 13:16:29 <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.
512 2011-09-24 13:16:49 <semb> I'll document this on the wiki
513 2011-09-24 13:17:18 <tcatm> have you read this https://gist.github.com/1237788 ?
514 2011-09-24 13:19:36 <semb> reading it now
515 2011-09-24 13:54:55 <samthetechie> Vladimir Marchenko of bitcoin.org talking about mining  rigs. http://www.ustream.tv/channel/bitcoin-weekend
516 2011-09-24 13:59:53 <Joric> this one? http://en.wikipedia.org/wiki/Vladimir_Marchenko
517 2011-09-24 14:00:42 <samthetechie> yes
518 2011-09-24 14:00:46 <Joric> naah too old
519 2011-09-24 14:01:11 <samthetechie> oh lol
520 2011-09-24 14:01:16 <samthetechie> hahah no he is not 90!
521 2011-09-24 14:01:21 <samthetechie> :p
522 2011-09-24 14:02:08 <k9quaint> oh god, is vlad trying to sell gold plated mining rigs for millions of $?
523 2011-09-24 14:03:13 <Joric> "runs Marchenko Ltd which sells mining contracts, previously developed the figator.org search engine."
524 2011-09-24 14:06:26 <samthetechie> lol
525 2011-09-24 14:06:40 <samthetechie> @k9quaint yeah thats about right
526 2011-09-24 14:06:41 <samthetechie> lol
527 2011-09-24 14:07:06 <samthetechie> @Joric, that sounds like the guy
528 2011-09-24 14:07:18 <k9quaint> I would call that guy a used car salesman, except that would be an insult to used car salesman
529 2011-09-24 14:07:25 <k9quaint> *men
530 2011-09-24 14:09:12 <CIA-101> bitcoinjs/node-bitcoin-p2p: Stefan Thomas master * rfcc26dd / wscript : Fixed pkg-config detection. - http://git.io/3lfyKw
531 2011-09-24 14:12:10 <samthetechie> @k9quaint that is mean but it made me LOL
532 2011-09-24 14:13:06 <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
533 2011-09-24 14:23:41 <tany000> I had a transfer that I should've recived at 160 000 blocks
534 2011-09-24 14:23:55 <tany000> I got to 120 000 but power went down
535 2011-09-24 14:25:12 <tany000> then when I opened the client again,the block chain count started again
536 2011-09-24 14:25:30 <tany000> what should I do in order to get my bcs ?
537 2011-09-24 14:27:06 <sipa> ;;bc,blocks
538 2011-09-24 14:27:07 <gribble> 146723
539 2011-09-24 14:27:14 <sipa> there are only 146723 blocks
540 2011-09-24 14:27:40 <sipa> and just let it download, maybe there was a disk problem that caused corruption of your block database
541 2011-09-24 14:27:43 <sipa> that doesn't matter
542 2011-09-24 14:30:35 <tany000> oh
543 2011-09-24 14:35:59 <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.
544 2011-09-24 14:40:02 <sipa> casascius: i had been thinking about something like that as an alternative for importprivkey
545 2011-09-24 14:41:09 <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
546 2011-09-24 14:41:53 <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
547 2011-09-24 14:42:30 <sipa> i use importprivkey to move funds from one wallet to another
548 2011-09-24 14:42:43 <sipa> that's hardly useless, but it's definitely advanced usage
549 2011-09-24 14:43:02 <sipa> sweepprivkey as you call it is somewhat safer to use
550 2011-09-24 14:43:30 <casascius> agreed, at least with respect to the wallet and whatever is already in it
551 2011-09-24 14:44:01 <casascius> if sweepprivkey were standard, i almost wouldn't care if importprivkey were only available as a patch
552 2011-09-24 14:44:13 <casascius> because the functionality useful to "joe" would be there in a relatively low risk package
553 2011-09-24 14:44:29 <sipa> i am not convinced though whether deposits as private keys are such a good idea
554 2011-09-24 14:45:02 <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)
555 2011-09-24 14:45:05 <sipa> it's certainly useful for scratchcards or other physical containers for bitcoins (like your coins)
556 2011-09-24 14:45:31 <sipa> no, i love that idea :)
557 2011-09-24 14:45:36 <casascius> That's the vast majority of the useful application... that and offline paper wallets
558 2011-09-24 14:47:03 <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
559 2011-09-24 14:47:07 <casascius> it a year later, I think I'd want it back.
560 2011-09-24 14:47:26 <sipa> though i considered transferring just a private key flawed
561 2011-09-24 14:47:30 <sipa> *consider
562 2011-09-24 14:47:37 <sipa> as it requires a full rescan of the block chain
563 2011-09-24 14:47:51 <casascius> I propose a hashtable so that the rescan only happens once
564 2011-09-24 14:47:51 <sipa> which will in time not be feasible - certainly not for an end user
565 2011-09-24 14:48:10 <sipa> a hashtable of what? of all used addresses?
566 2011-09-24 14:48:29 <casascius> the prefix of all used addresses, referencing all the blocks that contain them
567 2011-09-24 14:48:41 <casascius> maybe 32 bits worth of prefix (so a few extra blocks will get scanned, no big deal)
568 2011-09-24 14:49:14 <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
569 2011-09-24 14:49:18 <imsaguy> allows for a quicker rescan/verify balance
570 2011-09-24 14:49:57 <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.
571 2011-09-24 14:50:17 <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
572 2011-09-24 14:50:25 <imsaguy> part of the reason people don't use it is because people haven't really been importing keys
573 2011-09-24 14:50:35 <Joric> casascius, i'm working on... sweep :) in a java applet http://img831.imageshack.us/img831/9914/bitcointool201109242250.png
574 2011-09-24 14:50:44 <imsaguy> but as things like bitbills become more popular, it'll be needed
575 2011-09-24 14:50:45 <sipa> is easier, and viable for lightweight clients
576 2011-09-24 14:50:47 <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)
577 2011-09-24 14:51:16 <imsaguy> there is a way to rebuild blkindex.dat... delete it :P
578 2011-09-24 14:51:25 <Joric> unfortunately bitcoinj is too well designed everything is either private or package-only :) it's hard to construct custom transaction there
579 2011-09-24 14:51:42 <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
580 2011-09-24 14:52:17 <sipa> casascius: as i said, it's relatively easy now: create new wallet, import key, rescan, query balance, transfer
581 2011-09-24 14:53:08 <sipa> but the entire second-wallet-in-memory think is completely untested for now
582 2011-09-24 14:53:12 <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
583 2011-09-24 14:53:22 <sipa> casascius: ?
584 2011-09-24 14:53:26 <casascius> It is certainly good enough for me...
585 2011-09-24 14:53:32 <sipa> completely in memory, temporarily
586 2011-09-24 14:53:40 <sipa> no wallet.dat or anything
587 2011-09-24 14:53:50 <Joric> casascius, bitcoinj maintainer just added that 'sweep' http://code.google.com/p/bitcoinj/source/browse/trunk/src/com/google/bitcoin/examples/PrivateKeys.java
588 2011-09-24 14:54:04 <sipa> hmm, nice
589 2011-09-24 14:54:17 <Joric> but it doesnt allow to do that without the blockchain i'm trying to implement it myself
590 2011-09-24 14:54:30 <sipa> casascius: but again, i consider requiring a full rescan flawed
591 2011-09-24 14:54:57 <sipa> even if you can build such a table to speed it up somewhat, it's not feasible for lightweight nodes
592 2011-09-24 14:55:09 <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
593 2011-09-24 14:55:11 <sipa> unless they can query that table somewhere
594 2011-09-24 14:55:40 <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
595 2011-09-24 14:55:41 <sipa> so i think distributing the block id or txid along with it more useful
596 2011-09-24 14:55:50 <casascius> I will definitely look at the bitcoinj sweep fairly soon
597 2011-09-24 14:56:19 <Joric> casascius, i assure you java is a way better than c# :)
598 2011-09-24 14:56:36 <casascius> joric: i always say c# is a ripoff of java, so won't complain there
599 2011-09-24 14:56:59 <casascius> I have to go afk for a while.  See you guys later
600 2011-09-24 15:03:38 <Joric> sipa, do i absolutely need to know the hash of the source tx to build the spending transaction?
601 2011-09-24 15:08:29 <devrandom> ;;later tell BlueMatt I am not getting the same build for wxwidgets that you have as input in your bitcoin build report
602 2011-09-24 15:08:29 <gribble> The operation succeeded.
603 2011-09-24 15:09:37 <devrandom> ;;later tell BlueMatt you have     dfaa22b4780db1bea3b2ecb64c65109648454b9f594fa460106716d188fbec77  wxWidgets-2.9.2-x64-gitian.zip and I have 21cf67e8b45febc3536d848a1427b4dd7d3065c90c8cc8899d2c075c8c3cf69b consistently (32 bit is different too)
604 2011-09-24 15:09:37 <gribble> The operation succeeded.
605 2011-09-24 15:15:17 <devrandom> ;;later tell BlueMatt my build report is at https://github.com/devrandom/wxWidgets-release/tree/master/2.9.2/devrandom
606 2011-09-24 15:15:17 <gribble> The operation succeeded.
607 2011-09-24 15:16:19 <sipa> Joric: yes
608 2011-09-24 15:16:29 <sipa> Joric: how else would you reference is?
609 2011-09-24 15:16:32 <sipa> it
610 2011-09-24 15:19:28 <Joric> bummer, it needs blockchain to rescan knowing private key/balance is not enough
611 2011-09-24 15:22:32 <sipa> Joric: that's why i say you really want the block id or txid that credited the key
612 2011-09-24 15:22:55 <sipa> so you can request those from the network
613 2011-09-24 17:30:03 <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?
614 2011-09-24 17:41:01 <Diablo-D3> http://occupywallstreet.tumblr.com/post/10606910256/ows-update-march-to-union-square-reports-of-kettling
615 2011-09-24 17:50:04 <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
616 2011-09-24 17:53:19 <tany000> ''
617 2011-09-24 17:53:28 <gribble> I do not know about 'bitcoin', but I do know about these similar topics: 'freebitcoins'
618 2011-09-24 17:53:28 <tany000> ;;bitcoin
619 2011-09-24 17:53:41 <gribble> Error: "blocks" is not a valid command.
620 2011-09-24 17:53:41 <tany000> ;;blocks
621 2011-09-24 17:53:50 <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/
622 2011-09-24 17:53:50 <tany000> ;;help
623 2011-09-24 17:53:52 <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)
624 2011-09-24 17:53:52 <lfm> ;;bc,help
625 2011-09-24 17:53:55 <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)
626 2011-09-24 17:53:55 <lfm> ;;more
627 2011-09-24 17:53:58 <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
628 2011-09-24 17:53:58 <lfm> ;;more
629 2011-09-24 17:54:01 <tany000> right thanks
630 2011-09-24 17:54:20 <gribble> Error: "blocks" is not a valid command.
631 2011-09-24 17:54:20 <tany000> ;;blocks
632 2011-09-24 17:54:24 <devrandom> also /query gribble
633 2011-09-24 17:54:30 <gribble> 146741
634 2011-09-24 17:54:30 <lfm> ;;bc,blocks
635 2011-09-24 17:55:35 <tany000> is there a way to get just the last 10k blocks ?
636 2011-09-24 17:55:45 <lfm> tany000: note also you can /msg gribble commands privatly
637 2011-09-24 17:56:12 <lfm> tany000: only if you already have the rest
638 2011-09-24 17:56:32 <tcatm> tany000: you can download a snapshot from here http://eu1.bitcoincharts.com/blockchain/
639 2011-09-24 17:57:48 <tany000> right..
640 2011-09-24 17:58:00 <tany000> i got to 110k and it started getting them really slow
641 2011-09-24 17:58:24 <lfm> ya thats prolly normal cuz they blocks get a lot bigger about then
642 2011-09-24 17:58:36 <imsaguy> another think you can always try is connecting to the fallback nodes, they typically have faster connections
643 2011-09-24 17:58:40 <imsaguy> thing*
644 2011-09-24 18:02:33 <lfm> tany000: I agree it is a good idea to download the snapshot
645 2011-09-24 18:18:40 <Keefe> is there any problem using the blockchain snapshots from BC with v0.4, since i think the db version changed?
646 2011-09-24 18:19:32 <tcatm> Keefe: there shouldn't be but I'd appreciate if someone tries that
647 2011-09-24 18:20:15 <Keefe> what's the worst case scenario?
648 2011-09-24 18:20:27 <Keefe> if it's not loss of wallet, i'll try
649 2011-09-24 18:21:23 <imsaguy> It was fine when I did it a few weeks ago
650 2011-09-24 18:21:34 <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
651 2011-09-24 18:21:35 <imsaguy> 2 weeks or so when they asked for people to try the beta
652 2011-09-24 18:21:58 <Keefe> did they change db versions since then imsaguy?
653 2011-09-24 18:22:45 <tcatm> I've switched from bdb 4.7 to 4.8 (with 0.4) and it worked fine with the existing wallet and blockchain
654 2011-09-24 18:23:19 <imsaguy> the .4 beta
655 2011-09-24 18:23:38 <imsaguy> so basically the same thing you're gonna try minus any last minute code changes
656 2011-09-24 18:25:12 <imsaguy> Mine was on windows though
657 2011-09-24 18:25:49 <imsaguy> but as far as I could tell, the installer doesn't touch the blockchain file, its only after you start the client
658 2011-09-24 18:33:47 <Keefe> thanks for the info guys :)
659 2011-09-24 19:02:02 <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?
660 2011-09-24 19:05:09 <lfm> dikidera: usually the txn available is the same as the txn included in the block
661 2011-09-24 19:06:18 <lfm> I mean like usually the client will include all the txn in the block
662 2011-09-24 19:08:29 <tcatm> is anyone working on compacting the blockchain (= removing spent transactions and that stuff)?
663 2011-09-24 19:08:41 <[Tycho]> Hello, tcatm.
664 2011-09-24 19:08:57 <sipa> tcatm: i don't know of anyone who is
665 2011-09-24 19:09:00 <phantomcircuit> tcatm, i dont think so
666 2011-09-24 19:09:07 <[Tycho]> "OLD VERSIONS HARM THE NETWORK" - how ?
667 2011-09-24 19:09:18 <phantomcircuit> they dont really
668 2011-09-24 19:09:24 <lfm> I have a report that counts the number of txn that could be removed
669 2011-09-24 19:10:06 <phantomcircuit> lfm, can i see that?
670 2011-09-24 19:10:28 <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).
671 2011-09-24 19:10:47 <sipa> tcatm: that's already useful indeed
672 2011-09-24 19:10:54 <sipa> but i doubt it will have any significant effect
673 2011-09-24 19:10:58 <lfm> greatest chain length: 146744 blocks
674 2011-09-24 19:11:13 <lfm> Number of spent transactions: 1144548
675 2011-09-24 19:11:34 <lfm> ;;bc,blocks
676 2011-09-24 19:11:34 <[Tycho]> Do someone works on headers-only version ?
677 2011-09-24 19:11:35 <gribble> 146748
678 2011-09-24 19:11:53 <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).
679 2011-09-24 19:12:04 <lfm> Total number of transactions: 1573692
680 2011-09-24 19:12:52 <sipa> tcatm: once you don't have the entire blockchain anymore, you can't claim being a full client anymore
681 2011-09-24 19:13:21 <lfm> so you could drop 1144548 of 1573692 txn according to my calculation
682 2011-09-24 19:13:31 <sipa> lfm: that's significant indeed
683 2011-09-24 19:13:56 <dikidera> [Tycho]:what do you mean headers only?
684 2011-09-24 19:13:58 <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
685 2011-09-24 19:14:07 <sipa> tcatm: definitely
686 2011-09-24 19:14:16 <[Tycho]> dikidera, i'm talking about light client.
687 2011-09-24 19:14:18 <sipa> the whole way bitcoin handles addresses needs to be revised
688 2011-09-24 19:14:32 <sipa> ip addresses, that is
689 2011-09-24 19:14:44 <tcatm> yep and we should get rid of bdb or figure out what's making it so slow
690 2011-09-24 19:15:18 <sipa> there's no point in keeping more than a few thousand IP's along
691 2011-09-24 19:15:38 <tcatm> reading those 4MB still takes 1.5s + 0.6s for transforming them into mapAddresses
692 2011-09-24 19:15:48 <gmaxwell> using bdb for addresses is kinda silly in any case.
693 2011-09-24 19:15:49 <dikidera> [Tycho]:i also wish a lighter client
694 2011-09-24 19:15:53 <dikidera> ever seen Crysis 1?
695 2011-09-24 19:15:54 <sipa> indeed
696 2011-09-24 19:15:57 <dikidera> It uses 1GB of ram
697 2011-09-24 19:15:58 <[Tycho]> No.
698 2011-09-24 19:16:00 <dikidera> Bitcoin is near it
699 2011-09-24 19:16:16 <dikidera> lately the windows client starts faster, but...
700 2011-09-24 19:16:20 <sipa> if we keep using bdb for addresses, i'd just store them in one single record
701 2011-09-24 19:16:33 <dikidera> If someone actually improves that
702 2011-09-24 19:16:34 <[Tycho]> I heard that Windows Vista or Seven wants 15 Gb of disk space to install.
703 2011-09-24 19:16:38 <dikidera> then i can import addresses faster
704 2011-09-24 19:16:44 <dikidera> [Tycho]:true
705 2011-09-24 19:16:51 <[Tycho]> That's just insane.
706 2011-09-24 19:16:52 <tcatm> sipa: or use ip+port as the key?
707 2011-09-24 19:17:08 <dikidera> i feel its ok
708 2011-09-24 19:17:10 <[Tycho]> I can't imagine WHAT can be in those 15 Gbs.
709 2011-09-24 19:17:11 <sipa> tcatm: do you ever need to look them up based on ip+port?
710 2011-09-24 19:17:18 <sipa> i don't think so
711 2011-09-24 19:17:36 <[Tycho]> dikidera, "light client" is the one that doesn't store/needs full chain to operate.
712 2011-09-24 19:17:37 <dikidera> [Tycho]:DLLs
713 2011-09-24 19:17:47 <dikidera> [Tycho]:im also in for that
714 2011-09-24 19:17:52 <tcatm> yes. when you receive new addresses you need to check whether you know about it already and maybe update nTime
715 2011-09-24 19:17:55 <dikidera> but i mostly need a faster wallet updater
716 2011-09-24 19:18:00 <sipa> right, true
717 2011-09-24 19:18:02 <dikidera> when i import thousands of addresses its slow
718 2011-09-24 19:18:20 <[Tycho]> Hmm, I should make some improvements to my bitcoinds, btw...
719 2011-09-24 19:18:32 <dikidera> do you know C++?
720 2011-09-24 19:18:33 <dikidera> i dont :D
721 2011-09-24 19:18:39 <[Tycho]> No, only C.
722 2011-09-24 19:18:46 <dikidera> ...then how?
723 2011-09-24 19:18:52 <dikidera> bitcoin is c++
724 2011-09-24 19:18:53 <gmaxwell> [Tycho]: Are you still running .21 based bitcoinds that randomly hang up on nodes?
725 2011-09-24 19:19:20 <[Tycho]> gmaxwell, my bitcoinds aren't hanging.
726 2011-09-24 19:19:35 <sipa> 0.3.20-0.3.23 drop connections when nodes download too much
727 2011-09-24 19:19:51 <gmaxwell> [Tycho]: I didn't say 'hanging' I said "hang up on".
728 2011-09-24 19:19:52 <sipa> which most likely happens for anyone doing an initial block chain db
729 2011-09-24 19:20:24 <gmaxwell> Which is a bit opaque, I should have said frequently close connections.
730 2011-09-24 19:20:40 <[Tycho]> Didn't checked that.
731 2011-09-24 19:21:02 <sipa> i believe that is what the topic refers to primarily
732 2011-09-24 19:21:50 <[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.
733 2011-09-24 19:22:00 <dikidera> what?
734 2011-09-24 19:22:04 <dikidera> how do you purge a wallet?
735 2011-09-24 19:22:13 <gmaxwell> sipa: that and the old fee rules that make new low priority txn with 0.0005 fees somewhat less reliable.
736 2011-09-24 19:22:22 <sipa> gmaxwell: oh, sure, of course
737 2011-09-24 19:22:58 <[Tycho]> dikidera, delete it and create a new one.
738 2011-09-24 19:23:16 <[Tycho]> So now I want to resolve this issue.
739 2011-09-24 19:23:39 <gmaxwell> I'm not quite sure how your wallet.dat is getting that big.
740 2011-09-24 19:23:54 <gmaxwell> I had a wallet with every bitcoin txn in it, and I think it wasn't much bigger than that.
741 2011-09-24 19:24:04 <[Tycho]> gmaxwell, do you imagine HOW many payments deepbit does daily ? :)
742 2011-09-24 19:24:31 <sipa> and as gmaxwell said, he had a wallet with *ALL* transactions in it, so that includes all of deepbit's
743 2011-09-24 19:24:40 <[Tycho]> Well, it grows.
744 2011-09-24 19:24:56 <tcatm> also every transaction from the wallet ends up in the blockchain so it can not be that much bigger
745 2011-09-24 19:25:11 <sipa> well, wallet transaction keep quite some more information
746 2011-09-24 19:25:27 <sipa> including dependencies