1 2011-06-18 00:08:22 <jrmithdobbs> gmaxwell: what specifically in that doc are you talking about?
  2 2011-06-18 00:08:33 <ius> jimrandomh: Do you have a crypto background? Just read your blog article, IANAC(ryptographer), but I'm not sure what you're proposing
  3 2011-06-18 00:09:02 <gmaxwell> jrmithdobbs: page 48, steps 1.6.n
  4 2011-06-18 00:09:44 <jrmithdobbs> oh that's cool
  5 2011-06-18 00:10:15 <jrmithdobbs> that's very cool
  6 2011-06-18 00:10:31 <jrmithdobbs> ECC still confuses the fuck out of me
  7 2011-06-18 00:11:03 <ius> Having a homomorphic property in your signature scheme doesnt't sound desirable to me (ref. RSA blind signing)
  8 2011-06-18 00:11:26 <jrmithdobbs> gmaxwell: i wonder if openssl already has code to do it in the huge pile of undocumented EC stuff
  9 2011-06-18 00:11:39 <jrmithdobbs> it very well may
 10 2011-06-18 00:11:58 <ius> ..and doesn't seem related to the problem at hand (split keys, or requiring two parties)
 11 2011-06-18 00:12:00 <gmaxwell> jrmithdobbs: yea, so you could avoid sending the public key in the txn and just let the reciver recover it. But it takes extra computation. Another option would be to send the key with the txn but outside the signed portion, so that it can later be stripped. So it's still fast to validate when you have the key, but you can forget the keys to save storage in the future.
 12 2011-06-18 00:12:33 <gmaxwell> ius: it relates to this: https://github.com/groffer/bitcoin/commit/83707c8dd4573bb958f9e504fb6263c8fa1ef942
 13 2011-06-18 00:12:46 <gmaxwell> ius: which relates to "the problem at hand"
 14 2011-06-18 00:13:15 <jrmithdobbs> ius: it cuts down the size of the script significantly seeing as, especially in cases with multiple signers, the pubkeys are the vast majority of the storage/line data
 15 2011-06-18 00:13:36 <ius> gmaxwell: Yeah I see, I didn't mean your/jrmithdobbs' conversation though ;)
 16 2011-06-18 00:13:54 <ius> I was referring to http://lesswrong.com/lw/5rg/homomorphic_encryption_and_bitcoin
 17 2011-06-18 00:14:05 <gmaxwell> ius: oh I hadn't seen that.
 18 2011-06-18 00:14:15 <jrmithdobbs> gmaxwell: i wonder what the computation needs are of those ops in the real world
 19 2011-06-18 00:15:12 <jrmithdobbs> gmaxwell: i know recovering the pubkey from the privkey + params is less than trivial
 20 2011-06-18 00:15:34 <gmaxwell> jrmithdobbs: on the order of generating a key, a little bit worse. But all this can be made a lot faster. I was pointing out earlier that we could get a >21x validation speedup on sandybridge.
 21 2011-06-18 00:15:34 <jrmithdobbs> (computationally speaking)
 22 2011-06-18 00:16:07 <jrmithdobbs> gmaxwell: generating a key, even with all the hashing for publication that bitcoin does, is trivial computationally speaking
 23 2011-06-18 00:16:32 <jrmithdobbs> (the math is hard, obviously, but we're talking ~400ms or less for the actual keygen + hashing)
 24 2011-06-18 00:16:46 <jrmithdobbs> and that's on old p4/xeons
 25 2011-06-18 00:17:08 <phantomcircuit> http://forum.bitcoin.org/index.php?topic=18709.msg235709
 26 2011-06-18 00:17:13 <phantomcircuit> jrmithdobbs, ius fyi
 27 2011-06-18 00:17:16 <jrmithdobbs> gmaxwell: something in the bitcoin code slows it down WAY MORE than than it should
 28 2011-06-18 00:17:37 <jrmithdobbs> i think related to the bdb fsync nightmare
 29 2011-06-18 00:17:58 <gmaxwell> So yes, key recovery is slower but the slowdown should be was less than the speedup we could get from better optimized ECC code.
 30 2011-06-18 00:18:44 <jrmithdobbs> gmaxwell: and I'm not even enabling the patented alg in openssl or anything crazy
 31 2011-06-18 00:19:20 <wasabi1> So.. I think I got it. SHA256 only needs a 1 appended, and the length, if it isn't block aligned, right?
 32 2011-06-18 00:19:59 <wasabi1> So I have to do that when hashing the hash. As it's not 64 bytes long.
 33 2011-06-18 00:20:05 <jrmithdobbs> gmaxwell: seriously, 500 keys + sha256(sha256(privkey)) can do ~500 keys in 1.448s on a core2duo *serially*
 34 2011-06-18 00:20:19 <jrmithdobbs> gmaxwell: and that includes a buffer dup
 35 2011-06-18 00:20:25 <jrmithdobbs> $ time examples/genkeys 500 >/dev/null
 36 2011-06-18 00:20:29 <jrmithdobbs> real    0m1.448s
 37 2011-06-18 00:20:31 <jrmithdobbs> user    0m1.400s
 38 2011-06-18 00:20:33 <jrmithdobbs> sys     0m0.009s
 39 2011-06-18 00:20:57 <gmaxwell> jrmithdobbs: sure sure. I know, it's not slow. Validation is a bigger concern because you'll have to recover a ...few... more than 500 keys. :)
 40 2011-06-18 00:21:05 <jrmithdobbs> oh i'm sorry, that's keygen + sha256(sha256(privkey)) + base58 encoding
 41 2011-06-18 00:21:20 <gmaxwell> Though you could cache them since you'll know the addresses.
 42 2011-06-18 00:21:40 <wasabi1> jrmithdobbs: so you obviously seem to know wtf is going on. Am I right with regards to my SHA256 stuff?
 43 2011-06-18 00:22:03 <jrmithdobbs> wasabi1: the bitcoin code is misleading
 44 2011-06-18 00:22:06 <jrmithdobbs> VERY misleading
 45 2011-06-18 00:22:13 <jrmithdobbs> wasabi1: especially the comments
 46 2011-06-18 00:22:32 <jrmithdobbs> wasabi1: *all* keys pub and priv are 0 padded and stored big endian
 47 2011-06-18 00:22:34 <wasabi1> Well, I've been going over a bunch of differnet miners.
 48 2011-06-18 00:23:35 <jrmithdobbs> i've not looked at the mining code but from how things are handled i'd bet the same is true there
 49 2011-06-18 00:23:56 <wasabi1> It is very hard to figure out the specifics of how teh data stuff is encoded, it seems.
 50 2011-06-18 00:24:07 <jrmithdobbs> wasabi1: the one is a result of zero padding in the base58 alg bitcoin uses
 51 2011-06-18 00:24:08 <wasabi1> I've successfully managed to duplicate midstate, finally.
 52 2011-06-18 00:24:17 <jrmithdobbs> wasabi1: ya because some of the comments in key sections are outright LIES
 53 2011-06-18 00:24:21 <jrmithdobbs> heh
 54 2011-06-18 00:24:33 <wasabi1> Which means at least my transform algo is right.
 55 2011-06-18 00:25:02 <jrmithdobbs> wasabi1: eg, ignore that comment in base58.h that says it's swapping little endian, that's lieing, most of the data that is actuall base58 encoded (not all, ugh) is actually big endian to start with
 56 2011-06-18 00:25:08 <jrmithdobbs> err base58.cpp
 57 2011-06-18 00:25:14 <wasabi1> So, the second half of the header... SHA256 standard says that if the data should have a 0x01, and zeros, and then the size (in two bytes) appended to it.
 58 2011-06-18 00:25:32 <wasabi1> I'm not seeing that in any of this C miner code.
 59 2011-06-18 00:26:03 <ius> gmaxwell: btw, the paper mentions speedups for binary fields - I doubt it simply extends to prime fields (but I'm lacking on field theory)
 60 2011-06-18 00:27:09 <wasabi1> I'm wondering if it just ignores it.
 61 2011-06-18 00:27:21 <wasabi1> But it can't...
 62 2011-06-18 00:28:17 <wasabi1> ANd the data that comes in over RPC has some stuff at the end, but no '1' that I can see.
 63 2011-06-18 00:28:33 <wasabi1> 128,2,0,0
 64 2011-06-18 00:28:47 <ius> also, if you're extending the client to support ownership of coins by requiromg multiple signatures, that might solve the split key problem too ;)
 65 2011-06-18 00:30:39 <gmaxwell> ius: er. We use a binary curve.
 66 2011-06-18 00:31:09 <ius> secp256k1? - p for prime?
 67 2011-06-18 00:32:45 <wasabi1> That doesn't even make sense. Are you supposed to prehash the first 76 bytes of hte block header, or the first 64?
 68 2011-06-18 00:33:17 <jrmithdobbs> walletinspector.info went back to static png after my second nasty email to linode btw
 69 2011-06-18 00:33:31 <wasabi1> I got the midstate with just the first 64... but this python   version actually seems to do the first 76
 70 2011-06-18 00:34:08 <gmaxwell> ius: I thought koblitz were all characteristic-2 (over 2^m) by definition
 71 2011-06-18 00:34:42 <wasabi1> Oh... or maybe the algorithm recovers, no matter how much data you throw at it.
 72 2011-06-18 00:35:01 <wasabi1> so you could do 0-63. and then  64-127, or any combo there of.
 73 2011-06-18 00:35:05 <wasabi1> But midstate is defined as first 64.
 74 2011-06-18 00:35:37 <wasabi1> What's all the other shit in the data block? Everything after the header?
 75 2011-06-18 00:35:53 <gmaxwell> "CM-curves with good cryptographic properties" is the relevant paper I guess.
 76 2011-06-18 00:41:30 <wasabi1> So I learned that hash1 isn't useful, at least.
 77 2011-06-18 00:42:35 <wasabi1> So this python miner only builds the digest off of the 80 bytes of the header. Nothing more.
 78 2011-06-18 00:43:16 <wasabi1> I don't see how that can work, since other miners I've seen build it off of the full 128.
 79 2011-06-18 00:43:27 <wasabi1> I don't know how those two hashes can both work.
 80 2011-06-18 00:43:59 <phantomcircuit> one is a half state for sha256
 81 2011-06-18 00:44:03 <phantomcircuit> the other is the full headers
 82 2011-06-18 00:44:21 <wasabi1> You mean midstate?
 83 2011-06-18 00:44:28 <phantomcircuit> yeah that
 84 2011-06-18 00:44:45 <wasabi1> Yeah I figured out what that is.  That's the first 64 bytes of the header run through the algo once.
 85 2011-06-18 00:45:19 <wasabi1> What I'm trying to fully understand is whether you're supposed to then lay the other 64 after that, with or without the data that comes along from the RPC call.
 86 2011-06-18 00:46:12 <phantomcircuit> uh
 87 2011-06-18 00:46:13 <phantomcircuit> no
 88 2011-06-18 00:46:20 <phantomcircuit> the midstate isn't run once through
 89 2011-06-18 00:46:45 <wasabi1> Well, I have an algo that generates the mid state from the first 64. So I got that. And I can feed the midstate back into it to resume it.
 90 2011-06-18 00:46:47 <wasabi1> So I think I understand that.
 91 2011-06-18 00:47:20 <wasabi1> But what should I resume it with, the rest of the header, and then what?
 92 2011-06-18 00:47:30 <wasabi1> To bring it up to a 64 byte block size.
 93 2011-06-18 00:47:50 <jrmithdobbs> phantomcircuit: that shit is retarded re: prev topic
 94 2011-06-18 00:57:04 <lfm> wasabi1 the standard specifies what you fill it with. first an 0x80 byte then enuf zero bytes and the last 4 bytes are the total size of the input befor padding
 95 2011-06-18 00:57:40 <lfm> the size is I think a bit count and bigendian
 96 2011-06-18 00:58:38 <s3kati> can anyone point me to a bitcoin faucet thats up? im new/trying out the BC client and the faucet URL listed in all FAQs is down
 97 2011-06-18 00:59:08 <lfm> s3kati: sorry is only one faucet
 98 2011-06-18 00:59:24 <wasabi1> lfm: Sure, so what... discard the rest of the stuff in the data?
 99 2011-06-18 00:59:37 <s3kati> lfm: darn thats what i was afraid of - been trying to generate just to see *somethin* happen but seems unlikely
100 2011-06-18 00:59:45 <wasabi1> This is what's at the end of the 'data' value for me: 000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000
101 2011-06-18 00:59:58 <wasabi1> I see the 0x80 there... in what, little endian?
102 2011-06-18 01:00:00 <lfm> wasabi1 huh? dont discard anything, that stuff is just what I was describing
103 2011-06-18 01:00:11 <wasabi1> But that's too long, isn't it?
104 2011-06-18 01:00:37 <lfm> wasabi1: its been bytes swapped by the bitcoind server
105 2011-06-18 01:00:51 <wasabi1> The length at the end, 80020000 is 640.
106 2011-06-18 01:01:03 <lfm> yup 640 bits
107 2011-06-18 01:01:19 <wasabi1> Oh. Duh.
108 2011-06-18 01:01:22 <wasabi1> That's 80 bytes.
109 2011-06-18 01:01:25 <wasabi1> The size is in bits. :)
110 2011-06-18 01:01:28 <jrmithdobbs> ya was gonna say that looks right
111 2011-06-18 01:01:28 <lfm> duh
112 2011-06-18 01:03:34 <lfm> its cuz the standard is working on what is considered a bit stream, like the 0x80 is actually jjust a single stop bit
113 2011-06-18 01:07:52 <jgarzik> jrmithdobbs: can you verify that CSRF is fixed?
114 2011-06-18 01:08:58 <jrmithdobbs> someone finally got ahold of MagicalTux ?
115 2011-06-18 01:09:13 <lfm> wasabi1 note the hash1 string has the same sort of padding pre-initialized for 32 bytes
116 2011-06-18 01:09:39 <wasabi1> I see.
117 2011-06-18 01:09:41 <wasabi1> That's useful.
118 2011-06-18 01:10:15 <lfm> usefull for some, wastfull for others
119 2011-06-18 01:10:15 <wasabi1> So I can just use my SHA algorithm to dump my hash in there, and then I have two blocks waiting to hash for the hash of the has.
120 2011-06-18 01:10:26 <wasabi1> Well, it's unrequired net traffic.
121 2011-06-18 01:11:34 <lfm> wasabi1 ya and some hardware sha256 implementations do it themselves again anyway
122 2011-06-18 01:12:09 <wasabi1> For completeness, I'm going to redo it.
123 2011-06-18 01:12:14 <wasabi1> But thanks. I get it now.
124 2011-06-18 01:12:35 <lfm> wasabi1 ya you never know when some pool is gonna make a mess of it
125 2011-06-18 01:14:56 <jrmithdobbs> jgarzik: ya fixed
126 2011-06-18 01:26:45 <wasabi1> Hmm. So I am still missing on small part... 00000080.  The SHA-2 standard says 'append the bit 1 to the message'
127 2011-06-18 01:27:11 <wasabi1> Doesn't really say to append it inside an integer of a certain endianness
128 2011-06-18 01:27:23 <wasabi1> oh... unless... i get it.
129 2011-06-18 01:27:44 <wasabi1> the 'bit 1' is actually there, but it's jumbled up in the hex encoding.
130 2011-06-18 01:27:53 <wasabi1> since the hex encoding is working on byte units.
131 2011-06-18 01:28:01 <lfm> wasabiremember the message is big endian
132 2011-06-18 01:28:28 <wasabi1> So 00000080 is actually just '1' followed by a bunch of zeros.
133 2011-06-18 01:28:55 <wasabi1> most signfiicant byte being on the far right.
134 2011-06-18 01:29:08 <lfm> ya the extra byte swapping bitcoin did makes it harder to see
135 2011-06-18 01:29:41 <lfm> and the most significant byte is considered first
136 2011-06-18 01:30:07 <lfm> and the most significant bit of the most significant byte is considered first
137 2011-06-18 01:32:28 <lfm> so the 1 bit of the 0x80 is the first bit following the message
138 2011-06-18 01:51:03 <midnightmagic> what's this MtGox problem brocktice mentioned on his twitter feed?
139 2011-06-18 01:53:43 <lfm> I think its more people with poor passwords or people who got hacked
140 2011-06-18 01:54:21 <gmaxwell> lfm: midnightmagic .. er no.
141 2011-06-18 01:54:24 <gmaxwell> CSRF. :(
142 2011-06-18 01:54:57 <gmaxwell> You could rewrite the users user info for anyone logged in and take over their account.
143 2011-06-18 01:56:34 <lfm> gmaxwell: you mean if they leave their machine logged in or you mean from anywhere?
144 2011-06-18 01:56:37 <midnightmagic> Bah, lame.
145 2011-06-18 01:57:39 <gmaxwell> lfm: normal csrf. You log into mtgox.. later, while still logged in, you visit the badguy's website. He has some hidden iframe that does some mtgox fetch and you hand over control of your account to him without knowing anything happened.
146 2011-06-18 01:58:00 <gmaxwell> Its fixed now apparently.
147 2011-06-18 01:58:21 <lfm> oh ok
148 2011-06-18 01:58:35 <gmaxwell> But it sounds like a lot of people got ripped off.
149 2011-06-18 02:09:24 <wasabi1> heh. man. still struggling.
150 2011-06-18 02:15:10 <wasabi1> The end of the buffer (length in bits) is supposed to be a 8 byte integer, big-endian. That means the last bytes of the buffer should have the value. As far as I can tell.
151 2011-06-18 02:16:27 <wasabi1> I can't figure out anyway this is right, unless bitcoin is using a 32 bit integer.
152 2011-06-18 02:17:52 <jrmithdobbs> MagicalTux: you should probably look at ticket#1730 in your support queue.
153 2011-06-18 02:17:58 <jrmithdobbs> MagicalTux: just sayin
154 2011-06-18 02:21:45 <jrmithdobbs> http://home.jrbobdobbs.org/mith/lol-mtgox.png
155 2011-06-18 02:22:02 <jrmithdobbs> confirmed not showing as associated
156 2011-06-18 02:22:05 <jrmithdobbs> that's good.
157 2011-06-18 02:28:44 <wasabi1> 80020000 on the end makes no sense to me.
158 2011-06-18 02:29:00 <wasabi1> lfm: Riddle me this... the end of the data received by the node is 0000000080020000... which seems to be 0,0,0,0,128,2,0,0
159 2011-06-18 02:29:01 <wasabi1> Right?
160 2011-06-18 02:44:16 <citiz3n> for addnode, is it bitcoin.exe -addnode x.x.x.x
161 2011-06-18 02:44:23 <citiz3n> or bitcoin.exe --adnode x.x.x.x
162 2011-06-18 02:44:25 <jrmithdobbs> -addnode=
163 2011-06-18 02:44:32 <jrmithdobbs> -addnode=ip
164 2011-06-18 02:44:42 <citiz3n> thanks
165 2011-06-18 02:44:46 <citiz3n> that's for command line, right
166 2011-06-18 02:44:48 <citiz3n> not config file
167 2011-06-18 02:44:57 <jrmithdobbs> take the - off for config file
168 2011-06-18 02:46:10 <citiz3n> cool, thank you jrmithdobbs
169 2011-06-18 03:09:57 <fiverawr> When using sendfrom, it should only send from addresses that belong to the specified account? Right?
170 2011-06-18 03:35:33 <iz> wasabi1: 32-bit int, swap the byte order and you get 0x00000280 = 640 bits
171 2011-06-18 04:07:48 <bx_> Anyone here
172 2011-06-18 04:11:29 <manveru> bx_: oi
173 2011-06-18 04:14:11 <bx_> i wanna send bitcoins via peehp
174 2011-06-18 04:20:23 <wasabi1> iz: I didn't think it was supposed to be 32 bit
175 2011-06-18 04:22:42 <wasabi1> wikipedia says: append length of message (before pre-processing), in bits, as 64-bit big-endian integer
176 2011-06-18 04:25:20 <wasabi1> I'm afraid I'm reading the hex data block back incorrectly or something, or something
177 2011-06-18 04:25:59 <wasabi1> The value at the end of data does not appear to be a 64 bit big endian number equalling 640, to me.
178 2011-06-18 04:28:58 <wasabi1> It looks like it's swapped around improperly... which it might be.
179 2011-06-18 04:29:45 <gribble> {"ticker":{"high":17.2,"low":13,"vol":85350,"buy":15.5001,"sell":15.545,"last":15.5001}}
180 2011-06-18 04:29:45 <Kireji> ;;bc,mtgox
181 2011-06-18 04:39:47 <IoWn3rU_> is the mt gox api down
182 2011-06-18 04:39:53 <Guest29443> hey, my php curl call stopped working for mtgox
183 2011-06-18 04:40:09 <IoWn3rU_> guest29443: my program is hanging when trying to get a response
184 2011-06-18 04:40:19 <Guest29443> i can still wget --no-check-certificates but not with curl
185 2011-06-18 04:44:11 <Guest29443> `now mtgox is just hanging
186 2011-06-18 05:08:24 <wasabi1> Would a pool return the same timestamp for everybody for a given round?
187 2011-06-18 05:08:52 <wasabi1> Hmm. Guessing the answer is no.
188 2011-06-18 05:10:26 <spunnnn> very elite.
189 2011-06-18 05:10:34 <gmaxwell> phantomcircuit: send me some of your magic plz.
190 2011-06-18 05:10:37 <spunnnn> facebook worm that shit.
191 2011-06-18 05:11:44 <phantomcircuit> gmaxwell, my magic recipe is simple, gpg --symetci, copy everywhere
192 2011-06-18 05:11:46 <phantomcircuit> rofl
193 2011-06-18 05:13:41 <gmaxwell> phantomcircuit: in theory I have a wallet with a few hundred (I think 500?) btc from when I first heard about bitcoin. It's most likely gone though. Oh well.
194 2011-06-18 05:14:15 <phantomcircuit> gmaxwell, i actually started to do a disk recovery, the format of the privkey in bdb is pretty distinct
195 2011-06-18 05:14:23 <phantomcircuit> you might still be able to recover from disk
196 2011-06-18 05:14:24 <bx_> is windows the server of choice to run
197 2011-06-18 05:14:29 <bx_> if im making a casino based site
198 2011-06-18 05:14:33 <bx_> because i need to
199 2011-06-18 05:14:39 <phantomcircuit> especially if you have a lot of free disk space
200 2011-06-18 05:14:41 <bx_> do transactions, etc, interact with the bitcoin client
201 2011-06-18 05:14:53 <spunnnn> https://mtgox.com/users/register?username=XXXpassword=YYYY&passworda=YYYY&email=
202 2011-06-18 05:15:00 <bx_> ?
203 2011-06-18 05:15:03 <spunnnn> mtgox stores register form in GET variables? bad mojo
204 2011-06-18 05:15:06 <spunnnn> time to check their apache logs
205 2011-06-18 05:15:07 <phantomcircuit> bx_, windows is the server of choice if you enjoy going to prison when you get hacked and all the money goes missing
206 2011-06-18 05:15:09 <gmaxwell> phantomcircuit: I have pretty good secure erasure practices... and wouldn't have been likely to bother saving some role account's data.
207 2011-06-18 05:15:14 <bx_> rofl phantomcircuit exactly
208 2011-06-18 05:15:28 <bx_> so how easy is it to automate
209 2011-06-18 05:15:33 <bx_> the payout and withdrawl
210 2011-06-18 05:15:34 <phantomcircuit> gmaxwell, that's unfortunate
211 2011-06-18 05:15:41 <bx_> with nix
212 2011-06-18 05:15:42 <gmaxwell> Going to prison? I think it takes some work to automate that.
213 2011-06-18 05:15:43 <phantomcircuit> bx_, reasonably easy
214 2011-06-18 05:15:45 <bx_> which client is best
215 2011-06-18 05:16:21 <phantomcircuit> gmaxwell, it's actually fairly simple, it's hard to do well, but easy to just do
216 2011-06-18 05:16:31 <phantomcircuit> bx_, there is really only one client
217 2011-06-18 05:16:38 <bx_> explain
218 2011-06-18 05:16:54 <phantomcircuit> there is only a single complete implementation
219 2011-06-18 05:17:49 <phantomcircuit> bx_, tip, dont use the baked in account handling, assign each user an ever growing list of addresses
220 2011-06-18 05:18:01 <phantomcircuit> overtime it'll shit on your dbs performance but it's necessary
221 2011-06-18 05:20:20 <bx_> okay so
222 2011-06-18 05:20:23 <bx_> dont use windows
223 2011-06-18 05:20:24 <Gray> mongo
224 2011-06-18 05:20:25 <bx_> i see most sites are
225 2011-06-18 05:20:31 <bx_> ima get a nix
226 2011-06-18 05:20:32 <bx_> what os works best
227 2011-06-18 05:20:32 <Gray> no issues with db performance
228 2011-06-18 05:20:34 <bx_> to automate
229 2011-06-18 05:20:47 <phantomcircuit> Gray, is that a fucking joke
230 2011-06-18 05:21:04 <phantomcircuit> any site dealing with money shouldn't touch mongodb with a 1000ft pole
231 2011-06-18 05:21:27 <Gray> really :x
232 2011-06-18 05:21:31 <phantomcircuit> yes
233 2011-06-18 05:21:40 <phantomcircuit> jesus crist it doesn't guarantee writes occur at all
234 2011-06-18 05:21:47 <Diablo-D3> LOL
235 2011-06-18 05:21:48 <Diablo-D3> LOL
236 2011-06-18 05:22:09 <Gray> there's a way to fix that
237 2011-06-18 05:22:13 <phantomcircuit> web scale my ass
238 2011-06-18 05:22:19 <Diablo-D3> dude
239 2011-06-18 05:22:22 <Diablo-D3> web scale is a joke
240 2011-06-18 05:22:26 <Diablo-D3> WRITE YOUR SOFTWARE T NOT BE SHIT
241 2011-06-18 05:22:27 <Gray> easy storage
242 2011-06-18 05:22:32 <Diablo-D3> SCALES FOREVER
243 2011-06-18 05:22:35 <phantomcircuit> mongo is excellent for storing bullshit that's fine if 1% just disappears
244 2011-06-18 05:23:10 <Gray> i power a search store with it
245 2011-06-18 05:23:24 <phantomcircuit> w wat
246 2011-06-18 05:23:25 <Gray> didn't have any write errors though over 800000 documents
247 2011-06-18 05:23:28 <phantomcircuit> a wat
248 2011-06-18 05:23:50 <Gray> music search engine, all the tracks are stored in mongo
249 2011-06-18 05:24:04 <phantomcircuit> yeah how many servers is that on and how many disks
250 2011-06-18 05:24:12 <Gray> spread across 2
251 2011-06-18 05:24:19 <Gray> i mean i'm not talking using it for web scaling
252 2011-06-18 05:24:21 <phantomcircuit> servers? or disks
253 2011-06-18 05:24:25 <bx_> lets get to the task ... bit coin.. what os should i get
254 2011-06-18 05:24:35 <Gray> just as a db backend for a bitcoin site
255 2011-06-18 05:24:35 <phantomcircuit> bx_, linux of some type
256 2011-06-18 05:24:54 <bx_> yah but they say it wont work with money
257 2011-06-18 05:24:54 <phantomcircuit> Gray, just dont store bitcoin values in it
258 2011-06-18 05:25:06 <phantomcircuit> Gray, store documents or other bs that can get dropped
259 2011-06-18 05:25:23 <phantomcircuit> bx_, ok you're clearly a troll
260 2011-06-18 05:25:41 <bx_> no im not im just high as fuck
261 2011-06-18 05:25:47 <bx_> You guys tore him a new one for using mongo
262 2011-06-18 05:25:52 <bx_> :PO~
263 2011-06-18 05:26:10 <Gray> i do a lot of shit with it though it's good to know
264 2011-06-18 05:27:03 <phantomcircuit> Gray, mongo has no meaningful write guarantees or transactional support
265 2011-06-18 05:28:04 <Gray> doesn't it drop an error when a write fails though?
266 2011-06-18 05:28:25 <Gray> true. the system is designed to be pretty simple. handling money though you make a good point it would be better to go with proven tech
267 2011-06-18 05:28:58 <phantomcircuit> Gray, no it silently fails
268 2011-06-18 05:29:50 <Gray> weird, like i said i didn't notice any errors but 800000 isn't a large number of documents. could have just got lucky
269 2011-06-18 05:36:57 <bx_> so yeah
270 2011-06-18 05:37:02 <bx_> automating instant withdrawls
271 2011-06-18 05:37:04 <bx_> via php
272 2011-06-18 05:37:08 <bx_> anyone havegood dox on it for nix
273 2011-06-18 05:37:42 <Gray> its just through a json rpc
274 2011-06-18 05:37:59 <bx_> im high as fidduck
275 2011-06-18 05:38:02 <bx_> sorry.
276 2011-06-18 05:40:04 <echelon> what was the python tool gavin made that reads from the wallet and stuff?
277 2011-06-18 05:40:25 <jgarzik> bitcointools
278 2011-06-18 05:40:35 <echelon> cool, thanks
279 2011-06-18 05:41:54 <echelon> wait, does it get the data via json or by directly reading the files?
280 2011-06-18 05:42:19 <jgarzik> echelon: directly reading the files.  you must shut down bitcoin to use it.
281 2011-06-18 05:42:30 <random_cat> for your viewing pleasure: http://kimgrahamstudios.com/troll-15.html
282 2011-06-18 05:42:38 <echelon> eh, even on linux?
283 2011-06-18 05:45:22 <Kireji> ;;bc,mtgox
284 2011-06-18 05:45:23 <gribble> {"ticker":{"high":17.2,"low":13,"vol":83570,"buy":15.11,"sell":15.1503,"last":15.1101}}
285 2011-06-18 06:12:28 <wasabi1> god the byte ordering in this is nutty
286 2011-06-18 06:15:40 <phantomcircuit> wasabi, lol, you get to the point in some of the code where it flip flosp ordering multiple times?
287 2011-06-18 06:18:00 <edcba> ;;bc,mtgox
288 2011-06-18 06:18:01 <gribble> {"ticker":{"high":17.2,"low":13,"vol":82540,"buy":15.4111,"sell":15.5,"last":15.5}}
289 2011-06-18 06:18:05 <wasabi1> Naw. I found my issue.
290 2011-06-18 06:18:16 <wasabi1> I think it's shitty network ordering in the JSON-API?
291 2011-06-18 06:18:44 <wasabi1> The values are big endian. Which is correct. Except that they're not really specifically ordered.
292 2011-06-18 06:18:56 <wasabi1> It's just a big blitz on the entire string, as if it's a bunch of 4 bit words.
293 2011-06-18 06:19:34 <wasabi1> So yeah, Version comes out as 0,0,0,1... which is proper. But the hashes get reversed... not the entire has, mind you, but each int32 sized word.
294 2011-06-18 06:19:52 <wasabi1> And the padding at the end, which is supposed to be 64 bits, is flipped as if it was two 32 bit words.
295 2011-06-18 06:20:44 <edcba> isn't satoshi wrong in saying we should create more chains instead of using bitcoin's chain for alternate apps ?
296 2011-06-18 06:20:58 <sipa> no
297 2011-06-18 06:21:06 <edcba> because that weakens all the chains
298 2011-06-18 06:21:16 <sipa> it doesn't
299 2011-06-18 06:21:36 <sipa> read mike's post about alternate chains
300 2011-06-18 06:21:45 <edcba> if everybody works on same chain calc power in it is greater
301 2011-06-18 06:21:58 <edcba> if you have 2 chains it's twice easier to attack
302 2011-06-18 06:22:01 <sipa> no
303 2011-06-18 06:22:07 <edcba> where is that post ?
304 2011-06-18 06:23:08 <sipa> http://forum.bitcoin.org/index.php?topic=7219.0
305 2011-06-18 06:23:09 <pusle> not if chains have to agree, then you have to crack both
306 2011-06-18 06:25:25 <edcba> if chains have to agree that means i need to inject something into bitcoin chain ?
307 2011-06-18 06:25:33 <edcba> or just in the alternate chain ?
308 2011-06-18 06:25:49 <pusle> sorry, it was just a side note
309 2011-06-18 06:27:21 <pusle> maybe a "super hash" or something
310 2011-06-18 06:27:35 <pusle> as not to bloat the bitcoin chain with all kinds of non bitcoin related stuff
311 2011-06-18 06:27:45 <pusle> which I guess is what you're discussing
312 2011-06-18 06:28:00 <pusle> "checkpoints"
313 2011-06-18 06:32:30 <edcba> mike's post is basically saying create a tx in bitcoin then do your stuff in the other chain
314 2011-06-18 06:32:56 <sipa> no tx in main chain
315 2011-06-18 06:33:47 <sipa> unless you want to model a transaction that is partially financial
316 2011-06-18 06:35:16 <edcba> i agree with mike that bitcoin is too specific to be used as a general timestamping/proof service
317 2011-06-18 06:36:53 <edcba> ok it seems mike's solution is basically send bitcoins to non recoverable address and link that to your chain
318 2011-06-18 06:37:20 <edcba> but i don't see how that makes the alternate chain safer
319 2011-06-18 06:48:27 <sipa> edcba: forget that, that is just to illustrate the possibility of sending coins to the other chain, but there are other ways
320 2011-06-18 06:49:17 <sipa> the real magic is in putying hashes of the alternate chain in the financial chain's coinbasr
321 2011-06-18 06:49:43 <sipa> "locking" it with all its hash power
322 2011-06-18 06:49:50 <amiller> what's the marignal cost of bytes added to a block chain
323 2011-06-18 06:49:51 <edcba> but then it's quite ugly design
324 2011-06-18 06:49:53 <amiller> is that easy to estimate?
325 2011-06-18 06:50:11 <sipa> amiller: high
326 2011-06-18 06:50:45 <sipa> the block chain is and will be a very costly thing to maintain
327 2011-06-18 06:51:04 <amiller> but the only reason to allocate a lot of power to it
328 2011-06-18 06:51:05 <amiller> is security
329 2011-06-18 06:51:59 <sipa> indeed
330 2011-06-18 06:52:02 <amiller> i guess i agree with you that the magic is in putting just hashes in there
331 2011-06-18 06:52:21 <edcba> maybe we should make a chain with human-only solvable problems :p
332 2011-06-18 06:52:50 <edcba> that would stop a lot of critics about bitcoin :)
333 2011-06-18 06:53:04 <sipa> but people are willing to maintain that chain because a free electronic currency is worthwhile
334 2011-06-18 06:53:32 <amiller> well how many people would have to share a timestamp server before it was valuable
335 2011-06-18 06:53:36 <edcba> anyway we should have some generic chain for all others alternate chains imo
336 2011-06-18 06:53:44 <edcba> (because bitcoin chain is doomed)
337 2011-06-18 06:54:03 <sipa> they may not agree to do so when it's used as a file sharing service :)
338 2011-06-18 06:54:14 <amiller> like an individual block chain is a 'security pool' in a sense
339 2011-06-18 06:54:41 <edcba> something with some hashPrevBlock { guidservice, guiddata } * nb
340 2011-06-18 06:54:48 <edcba> and time etc
341 2011-06-18 06:55:26 <pigki> has anyone successfully abstracted GPU resources from CPU resources, ala hardware passthrough in VMWare
342 2011-06-18 06:55:31 <edcba> now the guiddata would be some hash of specific service chain
343 2011-06-18 06:56:42 <wumpus> a single global verification chain would be pretty cool, yes, chains would no longer compete for miners
344 2011-06-18 06:56:58 <amiller> i'd imagine a sort of meta-miner
345 2011-06-18 06:57:11 <wumpus> i'm not sure how it'd work in practice, though, as the miners would still have to decide what to include for each of the child chains
346 2011-06-18 06:57:13 <amiller> that makes it very easy to allocate a portion of your bandwidth to different block chain hashing tasks
347 2011-06-18 06:57:40 <amiller> wumpus, they'd go wherever they can collect the most in fees, however that's calculated
348 2011-06-18 06:58:04 <edcba> the meta chain would only trade blocks so it wouldn't cost much in bandwidth/disk anyway
349 2011-06-18 06:58:45 <edcba> the block i've described if you take max nb=8 by block would be like 260 bytes
350 2011-06-18 06:59:09 <edcba> you could accept them 10 a second that would be 2kB/s
351 2011-06-18 06:59:16 <edcba> max
352 2011-06-18 06:59:32 <amiller> do miners validate the whole chain
353 2011-06-18 06:59:48 <amiller> like i know it's the current practice to dowlnoad the entier block chain, even the user client does it
354 2011-06-18 07:00:30 <edcba> yes miners validate the whole chain
355 2011-06-18 07:00:49 <amiller> but if you stored hashes of Appcoin blocks in the bitcoin block chain
356 2011-06-18 07:00:50 <edcba> else their block would be rejected by others
357 2011-06-18 07:00:50 <wumpus> yes they should, that's the thing that provides security
358 2011-06-18 07:00:52 <amiller> the miners aren't validating anything about it
359 2011-06-18 07:01:15 <edcba> the meta-chain would be here just to provide timestamping
360 2011-06-18 07:01:16 <wumpus> the miners would still have to process the subchains as well, just the clients don't have to
361 2011-06-18 07:01:42 <edcba> each service would be free to reject any invalid guiddata/hash
362 2011-06-18 07:02:06 <amiller> what keeps forged timestamps from showing up
363 2011-06-18 07:02:11 <amiller> ownership of a private key i suppose
364 2011-06-18 07:02:56 <edcba> clients don't accept blocks too much further from network time
365 2011-06-18 07:24:14 <sipa> ;;bc,blocks
366 2011-06-18 07:24:24 <gribble> 131593
367 2011-06-18 07:42:07 <striklov> Hi guys. I have setup a tiny test pool using pushpool 0.5 and clients can connect + I received a small test transaction. I have a couple of questions though
368 2011-06-18 07:42:26 <striklov> the config for the bitcoin daemon should have gen=0 correct ?
369 2011-06-18 07:43:07 <striklov> paytxfee I set to 0.01
370 2011-06-18 07:43:44 <striklov> memcached I simply ignored and is not running
371 2011-06-18 07:44:00 <striklov> this is just a VM so ...
372 2011-06-18 07:44:43 <striklov> but connected miners should total a sum of around 2 GH/s at least
373 2011-06-18 07:44:55 <striklov> I left them running overnight
374 2011-06-18 07:45:29 <striklov> still no blocks found, I guess at current dificulty level this is expected ???
375 2011-06-18 07:45:55 <striklov> also is IRC really a requirement ? I kind of disabled that in the config
376 2011-06-18 07:47:25 <sipa> ;;bc,calc 2000000
377 2011-06-18 07:47:26 <gribble> The average time to generate a block at 2000000 Khps, given current difficulty of 877226.66666667 , is 3 weeks, 0 days, 19 hours, 17 minutes, and 9 seconds
378 2011-06-18 07:47:42 <sipa> striklov: pretty reasonable you didn't find any blocks overnight at 2 GH/s
379 2011-06-18 07:47:53 <striklov> ah ok :)
380 2011-06-18 07:48:08 <striklov> then my setup might be ok
381 2011-06-18 07:48:17 <gribble> 0.0151717360448
382 2011-06-18 07:48:17 <sipa> ;;bc,prob 2000000 8h
383 2011-06-18 07:48:26 <sipa> 1.5% chance to find a block in 8h time
384 2011-06-18 07:48:33 <nathan7> Du du du du
385 2011-06-18 07:48:34 <striklov> nice
386 2011-06-18 07:48:39 <nathan7> I mean, hi
387 2011-06-18 07:48:53 <striklov> ;)
388 2011-06-18 07:49:34 <striklov> regarding the other config stuff, does it look plausible to you guys ?
389 2011-06-18 07:49:45 <striklov> any gotchas I should be aware of ?
390 2011-06-18 07:51:47 <sipa> irc is not required, there are other bootstrapping mechanisms
391 2011-06-18 07:52:03 <sipa> gen=0 is fine, you don't want your pool to be cpu mining
392 2011-06-18 07:52:48 <striklov> nice :) thx sipa
393 2011-06-18 07:54:16 <gribble> 0.000640549419864
394 2011-06-18 07:54:16 <striklov> ;;bc,prob 55883 12h
395 2011-06-18 07:54:30 <fiverawr> 06:16 < luke-jr> fiverawr: addresses don't belong to accounts
396 2011-06-18 07:54:50 <fiverawr> What is the purpose of being able to assign addresses to accounts then?
397 2011-06-18 07:55:18 <amiller> it's just the bitcoin client being helpful i think
398 2011-06-18 07:55:34 <amiller> strictly a local-to-your-wallet convention
399 2011-06-18 07:56:23 <fiverawr> sendfrom <fromaccount> <tobitcoinaddress> <amount>
400 2011-06-18 07:56:33 <gribble> 0.473105351973
401 2011-06-18 07:56:33 <striklov> ;;bc,prob 55883000 12h
402 2011-06-18 07:56:35 <fiverawr> This makes it sound like the coins would only come from that account
403 2011-06-18 07:57:13 <sipa> accounts are simply separate balances
404 2011-06-18 07:57:23 <sipa> they do not 'own' transactions or coins
405 2011-06-18 07:57:38 <sipa> if you do a transaction, its input will always come from all available coins in your wallet
406 2011-06-18 07:57:54 <fiverawr> Right. But, if I "sendfrom" an account, the balance of other accounts can also decrease?
407 2011-06-18 07:58:08 <sipa> the 'fromaccount' parameter only signifies from which balance the sent amount is deducted
408 2011-06-18 07:58:11 <sipa> that's all
409 2011-06-18 07:58:54 <sipa> and you can assign incoming address to accounts, which will cause those accounts to be incremeneted with the received amount when they are addressed to that address
410 2011-06-18 07:59:11 <sipa> but it's really just a local accounting thing
411 2011-06-18 08:00:01 <striklov> does the gribble bot do namecoin calcs ?
412 2011-06-18 08:00:36 <striklov> ;;nc,prob 2000000 8h
413 2011-06-18 08:00:37 <gribble> Error: "nc,prob" is not a valid command.
414 2011-06-18 08:00:42 <sipa> not afaik
415 2011-06-18 08:00:45 <BlueMatt> dont think so
416 2011-06-18 08:00:56 <striklov> ah ok np :)
417 2011-06-18 08:01:50 <fiverawr> That still sounds like "sendfrom" doesn't really have a purpose - it can still effect the balance of other accounts ;x
418 2011-06-18 08:02:03 <sipa> no it can't
419 2011-06-18 08:02:33 <sipa> an account is just an accounting trick, and sendfrom only deducts an amount from the account you tell it to
420 2011-06-18 08:03:00 <sipa> just know that it's completely independent from which address the used coins are last sent to
421 2011-06-18 08:03:14 <sipa> *were
422 2011-06-18 08:03:36 <BlueMatt> jgarzik: you broke coding style in c02ec5
423 2011-06-18 08:03:52 <BlueMatt> someone is too used to kernel coding style ;)
424 2011-06-18 08:07:45 <sipa> BlueMatt: not more than the code was already non-conformant
425 2011-06-18 08:08:42 <BlueMatt> true, just wanted to point it out, not that I care in the least...Id love to see us switch to that bracket style as its what I tend to use on other projects
426 2011-06-18 08:08:45 <BlueMatt> but its not worth it
427 2011-06-18 08:09:03 <sipa> indeed
428 2011-06-18 08:09:38 <sipa> oh wait, it was conforming - nvm
429 2011-06-18 08:09:58 <sipa> except it should have been 'str' instead of 's' ;)
430 2011-06-18 08:10:24 <BlueMatt> also, jgarzik 6f460ba broke a ton of translations
431 2011-06-18 08:10:54 <BlueMatt> namely all of them except sv
432 2011-06-18 08:32:16 <D0han> when we will have client with reduced blockchain?
433 2011-06-18 08:32:35 <BlueMatt> not yet
434 2011-06-18 08:33:03 <D0han> i cant tell to anybody 'hey, grab this software, it will download 3gb useless for you piece of shit, then you can do anything'
435 2011-06-18 08:34:09 <BlueMatt> yea its no where near that big yet
436 2011-06-18 08:34:26 <D0han> yeah
437 2011-06-18 08:34:27 <D0han> yet
438 2011-06-18 08:34:28 <D0han> ..
439 2011-06-18 08:34:45 <D0han> its ~300mb now
440 2011-06-18 08:35:24 <mtrlt> it's gonna be that big soon tho :P
441 2011-06-18 08:37:34 <D0han> just 2 months ago i had 1Mbps internet (down, up was smth like 0.25 of that)
442 2011-06-18 08:38:04 <D0han> i fail to see downloading 1gb chain on this
443 2011-06-18 08:38:27 <mtrlt> yeah
444 2011-06-18 08:38:42 <wumpus> there are a lot of plans about reducing the  size of the downloaded chains for simple clients, but as it isn't that big yet, other things are  priority of the dev team right now (such as wallet security)
445 2011-06-18 08:38:44 <mtrlt> i think it's one of the bigger issues right now :p
446 2011-06-18 08:39:26 <wumpus> I don't think it's a big proble, -- if you don't want to download the chain, you could copy it from someone else in another way
447 2011-06-18 08:40:25 <mtrlt> from whom :)
448 2011-06-18 08:40:45 <wumpus> someone else that uses bitcoin, as you can verify the entire chain you don't even have to trust them
449 2011-06-18 08:40:59 <mtrlt> if you know no-one
450 2011-06-18 08:41:03 <D0han> it can work for me that way, but not for mortals
451 2011-06-18 08:41:14 <wumpus> D0han: for mortals it'd just need a somewhat fancier interface
452 2011-06-18 08:41:16 <mtrlt> that, too.
453 2011-06-18 08:41:25 <wumpus> work is done on that, too...
454 2011-06-18 08:41:27 <mtrlt> nobodys gonna be copying block chains from each other :p
455 2011-06-18 08:41:48 <wumpus> because 99% of people is ok with just downloading them
456 2011-06-18 08:42:03 <wumpus> heck, a large part of people streams movies these days
457 2011-06-18 08:42:18 <D0han> probably stupid & obvious question, but is chain compressed?
458 2011-06-18 08:42:49 <wumpus> I don't know, interesting question/idea though
459 2011-06-18 08:42:55 <D0han> wumpus: i know people arond using GPRS to get piece of internet
460 2011-06-18 08:43:02 <D0han> also, they have download limits
461 2011-06-18 08:43:23 <D0han> around*
462 2011-06-18 08:43:27 <Theo`> D0han: it consists mainly of public keys and hashes which do not compress very well
463 2011-06-18 08:43:28 <wumpus> D0han: yes, I don't deny it is problem, but it doesn't have the priority at the moment
464 2011-06-18 08:44:16 <Theo`> D0han: so the answer is no because it would be pointless
465 2011-06-18 08:44:37 <D0han> big entrophy, right
466 2011-06-18 08:44:59 <wumpus> it might still compress a bit though, someone should try it out :)
467 2011-06-18 08:48:53 <D0han> i just realised that reducing chain wont reduce download usage
468 2011-06-18 08:49:23 <D0han> client still need to download every block and then decide to save it to hdd or /dev/nul
469 2011-06-18 08:52:57 <wumpus> depends, with some protocol changes I guess it could only request the blocks it is interested in.. though a careless implementation of that could reduce privacy (ie, sending your public addresses)
470 2011-06-18 08:54:29 <D0han> and then we need to trust that its legit, or requesting few times same information from several sources
471 2011-06-18 08:54:34 <D0han> and still trusting..
472 2011-06-18 08:55:26 <Theo`> you need the whole block chain to do any verification
473 2011-06-18 08:55:47 <Theo`> especially to ensure that coins are not double-spent
474 2011-06-18 08:56:12 <Theo`> otherwise you need to rely on fully trusted nodes which have the block chain and perform the verification for you
475 2011-06-18 08:56:29 <wumpus> someone needs the whole blockchain, not neccesarily you (though yes, you'd be trusting other people a bit)
476 2011-06-18 08:56:40 <Theo`> a bit? fully
477 2011-06-18 08:56:43 <wumpus> for a small-footprint mobile client that could work
478 2011-06-18 08:56:51 <wumpus> but not for the main client
479 2011-06-18 08:56:55 <Theo`> yep
480 2011-06-18 08:57:01 <D0han> well, that sucks
481 2011-06-18 09:06:19 <tenbatsu> anyone know the proper json for submitting an ASK via the mtgox websocket api?
482 2011-06-18 09:41:52 <mrb_> $ bitcoind getdifficulty
483 2011-06-18 09:42:09 <gribble> 877226.66666667
484 2011-06-18 09:42:09 <mrb_> ;;bc,diff
485 2011-06-18 09:42:30 <mrb_> why the discrepancy?
486 2011-06-18 09:45:02 <gmaxwell> mrb_: rounding bug that was fixed in .22
487 2011-06-18 09:45:21 <mrb_> makes sense. .66666667 seemed to unlikely
488 2011-06-18 09:45:28 <lfm> mrb_: gribble is still using an old version that was inaccurate
489 2011-06-18 09:46:05 <gmaxwell> s/gribble/blockexplorer/
490 2011-06-18 09:46:18 <lfm> well both of em
491 2011-06-18 09:46:43 <gmaxwell> lfm: I think gribble gets most (all?) of its bitcoin data from blockexplorer
492 2011-06-18 09:47:03 <lfm> ya ok so gribble is using it indirectly
493 2011-06-18 09:47:05 <ius> !rates
494 2011-06-18 09:47:08 <ius> er
495 2011-06-18 09:55:54 <CIA-103> DiabloMiner: Patrick McFarland master * r412ce18 / (2 files in 2 dirs): One last optimization - http://bit.ly/k2rppv
496 2011-06-18 09:59:51 <D0han> where i can get source of bitcoind?
497 2011-06-18 10:04:28 <diki> why is it that i can't run two instances of bitcoin? One is in a VM the other on my host machine yet it get's 0 connections if both are running
498 2011-06-18 10:07:45 <diki> someone?
499 2011-06-18 10:08:37 <cacheson> diki: it can be hard to get connected if you don't have port forwarding enabled
500 2011-06-18 10:08:49 <Theo`> diki: did you try to change port on one of both?
501 2011-06-18 10:09:28 <luke-jr> ;;bc,blocks
502 2011-06-18 10:09:29 <gribble> 131614
503 2011-06-18 10:09:34 <diki> if the bitcoin in the vm machine can connect
504 2011-06-18 10:09:40 <diki> no reason the one on the host machine can't
505 2011-06-18 10:11:03 <Theo`> well, port can be taken
506 2011-06-18 10:11:12 <diki> the port is one and cannot be changed
507 2011-06-18 10:11:50 <Theo`> does the VM have a different IP address than the host?
508 2011-06-18 10:11:53 <erle-> how can i build bitcoin without miniupnp?
509 2011-06-18 10:12:09 <diki> theo:it uses NAT
510 2011-06-18 10:13:26 <Theo`> so host assigns port for VM and Bitcoin on host can't bind to port anymore
511 2011-06-18 10:13:51 <diki> the bitcoin program in the VM is running
512 2011-06-18 10:13:58 <gmaxwell> erle-: commnt out the usepnp line in the makefile
513 2011-06-18 10:14:01 <diki> if i try to start the one on the host
514 2011-06-18 10:14:05 <diki> there are no connections
515 2011-06-18 10:14:16 <Theo`> yes, thats what you said
516 2011-06-18 10:14:29 <Theo`> and I explained that one port can only be used by one Bitcoin instance
517 2011-06-18 10:14:36 <gmaxwell> diki: what version of bitcoin?
518 2011-06-18 10:14:40 <diki> .21
519 2011-06-18 10:14:50 <gmaxwell> Yea. Go have a cup of coffee.
520 2011-06-18 10:14:58 <diki> i dont drink coffee
521 2011-06-18 10:15:13 <erle-> gmaxwell, oh no, and I asked myself why "export USE_UPNP= " did not have any effect
522 2011-06-18 10:15:23 <gmaxwell> .21 still has the connect timeout bug. Getting connections right after startup is a matter of luck.
523 2011-06-18 10:15:39 <diki> if i stop the other bitcoin instance i will get connection right away
524 2011-06-18 10:15:48 <diki> 100 in fact
525 2011-06-18 10:15:59 <diki> but i'd rather not stop the one in the VM
526 2011-06-18 10:16:37 <luke-jr> erle-: rtfm
527 2011-06-18 10:16:52 <gmaxwell> diki: you'll get inbound connections. I assume.
528 2011-06-18 10:17:11 <diki> inbound?
529 2011-06-18 10:17:45 <gmaxwell> diki: regardless, stop running old ass bitcoin.
530 2011-06-18 10:17:47 <erle-> luke-jr, the fucking manual told me to do that
531 2011-06-18 10:18:02 <diki> gmax:i need the gui in linux
532 2011-06-18 10:18:15 <gmaxwell> diki: so?
533 2011-06-18 10:18:33 <diki> is there a compiled gui of the new version?
534 2011-06-18 10:18:33 <luke-jr> erle-: doubt it
535 2011-06-18 10:18:45 <gmaxwell> Yes, on the website.
536 2011-06-18 10:18:46 <lfm> diki ya
537 2011-06-18 10:18:58 <diki> last time i checked it was still ol' .21
538 2011-06-18 10:19:25 <lfm> sez its .32
539 2011-06-18 10:19:29 <lfm> .23 I mean
540 2011-06-18 10:19:47 <erle-> luke-jr, current git, /doc/build-unix.txt, line 45
541 2011-06-18 10:19:53 <luke-jr> erle-: nope, it says nothing about export bs
542 2011-06-18 10:19:55 <gmaxwell> diki: I can only guess your issue is something like, "VMed instance gets on IRC and people try to connect to that port but the vm port is unreachable due to nat" or something goofy like that.
543 2011-06-18 10:20:28 <diki> the bitcoin instance in the vm works...it has 9 connections though, but works
544 2011-06-18 10:21:13 <gmaxwell> Sure.
545 2011-06-18 10:21:16 <diki> .32 on windows i.e the host machine seems to give me 1 connection
546 2011-06-18 10:21:16 <luke-jr> erle-: make -f makefile.unix USE_UPNP=
547 2011-06-18 10:22:03 <diki> wait, we have movement
548 2011-06-18 10:22:09 <gmaxwell> Yep.
549 2011-06-18 10:22:51 <diki> stop writing these short words and write a couple of lines
550 2011-06-18 10:23:36 <doublec> why
551 2011-06-18 10:24:19 <gmaxwell> I probably still have the longest average line length of anyone in the channel.
552 2011-06-18 10:24:40 <doublec> and with a high signal to noise ratio
553 2011-06-18 10:24:59 <gjs278> I have the shortest
554 2011-06-18 10:25:59 <gmaxwell> Debatable.   In any case, diki is it working now?  Getting connections quickly is a little hit or miss, more miss than hit in older versions.
555 2011-06-18 10:26:56 <diki> got 18
556 2011-06-18 10:36:36 <D0han> Public channel logs: http://bit.ly/cdmwSu
557 2011-06-18 10:36:38 <D0han> i see 404 here
558 2011-06-18 11:16:45 <sprash> Hi! Could somebody tell me how pools protect against block witholding?
559 2011-06-18 11:19:06 <mtrlt> the pools give the miners work that already includes the coinbase transaction that gives the money to the pool. or wherever the pool wants it to go.
560 2011-06-18 11:19:25 <mtrlt> the miners can't change that, since they're only actually given a hash of the transactions.
561 2011-06-18 11:24:00 <sprash> Ok. Sounds reasonable. But why are all the small pay per share pools clising (like swepool and bitpenny) because of block withholding?
562 2011-06-18 11:24:10 <sprash> *closing
563 2011-06-18 11:24:24 <mtrlt> because the miner can know whether his share results in a block.
564 2011-06-18 11:24:36 <mtrlt> just by comparing the hash to the network's current target.
565 2011-06-18 11:25:40 <mtrlt> and can decide not to send the share back to the pool based on that
566 2011-06-18 11:25:48 <ius> Not submitting the solution doesn't help either party though
567 2011-06-18 11:26:49 <gmaxwell> ius: it helps you if you want to make a pool look like a cheater.
568 2011-06-18 11:28:01 <ius> How?
569 2011-06-18 11:29:08 <gmaxwell> A pool can easily steal from its members by simply inflating the share count "oh look, I got 10000 shares, so you get N/10000 payout" and taking the payout from the fake shares for itself.
570 2011-06-18 11:29:12 <mtrlt> ius: it doesn't help either party yes.
571 2011-06-18 11:29:19 <mtrlt> ius: but it anti-helps the pool
572 2011-06-18 11:29:33 <mtrlt> and the miner might get some satisfaction outta that
573 2011-06-18 11:29:51 <ius> Yes, true
574 2011-06-18 11:30:24 <ius> gmaxwell: Sure, but that's not related to witholding a block
575 2011-06-18 11:30:34 <ius> But still an easy way to cheat
576 2011-06-18 11:30:36 <gmaxwell> ius: Yes it is.
577 2011-06-18 11:30:57 <gmaxwell> Say I run pool X, and I want to make pool Y look guilty of the above.
578 2011-06-18 11:31:15 <gmaxwell> I just mine on Y (or proxy some of my users to Y) and filter good solutions.
579 2011-06-18 11:31:31 <gmaxwell> Now Y is indistinguishable from a cheater in terms of its payout.
580 2011-06-18 11:31:47 <mtrlt> and Y is gonna run out of money if it's a PPS pool :P
581 2011-06-18 11:32:05 <gmaxwell> Yup.
582 2011-06-18 11:32:32 <gmaxwell> and since you're still getting paid, it's not too expensive an attack.
583 2011-06-18 11:33:10 <ius> Oh like that. Yeah I see your point then :)
584 2011-06-18 11:34:03 <ius> Although you'd need a fair share of a total pool's capacity before you have statistically significant 'proof' of them cheating
585 2011-06-18 11:34:50 <mtrlt> and then people could accuse somebody of holding good solutions :p
586 2011-06-18 11:34:54 <mtrlt> also.
587 2011-06-18 11:37:50 <sprash> Is it possible to test if you have a cheater or not by resubmitting a solved block to all pool members and checking who responds?
588 2011-06-18 11:39:51 <mtrlt> possibly
589 2011-06-18 11:40:06 <mtrlt> but that is not cheat-proof either :p
590 2011-06-18 11:45:48 <diki> honestly....luke-jr has no sense of design...
591 2011-06-18 11:47:23 <gjs278> firing a rocket launcher at diki
592 2011-06-18 11:50:08 <sprash> mtrlt: why? how can the cheater decide if this is test work or real work?
593 2011-06-18 11:50:42 <mtrlt> sprash: at least in some cases by looking at the block chain and looking at the work gotten from the server :p
594 2011-06-18 11:54:02 <ex3ndr> Hello, all! Could anyone explain me why i couldn't request transaction by sending getdata, but i could recieve block by the same call. I could receive transaction datas which was sent to me in connection session. If i reestablish new connection then i couldn't receive transaction...
595 2011-06-18 11:54:23 <ex3ndr> Sorry for my english if this message is hard to read ;)
596 2011-06-18 11:56:58 <ex3ndr> Hmmm it start to work now
597 2011-06-18 11:57:19 <ex3ndr> but i couldn't request any transaction that could be found at blockexplorer
598 2011-06-18 12:11:26 <ex3ndr> it seems that getdata for transaction doesn't work for transaction, that already included in block. Is this true?
599 2011-06-18 12:13:54 <gmaxwell> sprash: Thats actually a pretty excellent idea.
600 2011-06-18 12:14:04 <gmaxwell> aww.
601 2011-06-18 12:24:07 <iz> that is a good idea, i agree
602 2011-06-18 12:25:48 <iz> could even periodically send work from previous blocks and find the ones that don't submit a solution
603 2011-06-18 12:26:25 <mtrlt> yes but i already said it isn't totally cheatproof
604 2011-06-18 12:26:32 <mtrlt> only requires a bit more involvement on the cheater's part.
605 2011-06-18 12:26:48 <mtrlt> and how do you know all miners check all nonces anyway? :)
606 2011-06-18 12:26:58 <iz> yeah.. cheater just has to reply for all "known" blocks
607 2011-06-18 12:27:30 <iz> mrb_: well, it's a check to see if a malicious miner is just filtering out the correct result, instead of passing it up to the pool as it should
608 2011-06-18 12:28:20 <iz> but a malicious miner could bypass that check by keeping a DB of all known solved blocks and responding properly in those cases
609 2011-06-18 12:29:00 <mtrlt> yes that's what i said.
610 2011-06-18 12:30:12 <CIA-103> bitcoin: Luke Dashjr personal * ra7b2a1bce54b poclbm-personal/BitcoinMiner.py: avoid delay between sending shares http://tinyurl.com/62wnjnl
611 2011-06-18 12:30:13 <CIA-103> bitcoin: Luke Dashjr personal * r056849565e14 poclbm-personal/BitcoinMiner.py: retry sending results http://tinyurl.com/6b4gp4s
612 2011-06-18 12:30:14 <CIA-103> bitcoin: Luke Dashjr personal * r4a2ced11e415 poclbm-personal/BitcoinMiner.py: some obvious locking optimizations http://tinyurl.com/6koyz2n
613 2011-06-18 12:30:16 <gmaxwell> iz: you use the most recent solution though, so they wouldn't have much of a way to cheat that one, though you can't test users quickly that way.
614 2011-06-18 12:30:26 <iz> yeah.. hmm.. the pool could log other shares that get CLOSE to the target difficulty.. and then use those to check for malicious miners
615 2011-06-18 12:30:42 <mtrlt> iz: that's a slightly better idea.
616 2011-06-18 12:30:51 <mtrlt> iz: but. what if the miner does not check the whole nonce rance?
617 2011-06-18 12:30:52 <mtrlt> range
618 2011-06-18 12:30:55 <gmaxwell> iz: nope, because the malicious miners will happily report the close ones.
619 2011-06-18 12:30:57 <mtrlt> that would result in a false positive
620 2011-06-18 12:31:08 <mtrlt> bah. also what gmaxwell said. :)
621 2011-06-18 12:31:37 <iz> mtrlt: well, if they don't check the whole nonce range, that's fine.. they just don't have difficulty 1 shares to submit.. it only hurts them
622 2011-06-18 12:32:04 <iz> or they have proportionally less to submit
623 2011-06-18 12:32:09 <iz> on avg
624 2011-06-18 12:32:10 <gmaxwell> iz: the point is that if they only check the first 2^31 they'll still work fine, but will false positive on some solutions.
625 2011-06-18 12:32:12 <mtrlt> nope, they might just ask for new work
626 2011-06-18 12:32:24 <mtrlt> or just increase the time every second or something
627 2011-06-18 12:32:29 <mtrlt> it results in equal amount of shares
628 2011-06-18 12:32:36 <mtrlt> but different behaviour in your scheme.
629 2011-06-18 12:32:54 <gmaxwell> darnit. No one did anything about the other IRC partitioning bug I mentioned here.
630 2011-06-18 12:34:16 <iz> mtrlt: oh, i see.. well, in the error case.. it just calls those miners cheaters, right?
631 2011-06-18 12:34:55 <gmaxwell> since non cheaters are way more common than cheaters.. thats not so good.
632 2011-06-18 12:35:11 <iz> ah
633 2011-06-18 12:35:33 <iz> there are a lot of miners that don't check the full nonce space?
634 2011-06-18 12:35:50 <gmaxwell> no cpu miner will, for example.
635 2011-06-18 12:36:18 <gmaxwell> er, well ones with longpoll might.
636 2011-06-18 12:36:36 <iz> oh, right
637 2011-06-18 12:38:12 <mtrlt> and my miner checks as much as it can in one second, then increments the time :p
638 2011-06-18 12:38:37 <iz> ah yeah.. the miners that do their own timestamp would mess that up also
639 2011-06-18 12:40:06 <coco> Hmmm, is there a miner in here that could help me a bit?
640 2011-06-18 12:41:26 <MrTiggr> Shhhh... it's a library *tumbleweed rolls across #bitcoin-dev screen*
641 2011-06-18 12:42:33 <MrTiggr> hey coco ... not much of a miner but maybe i can help since it's so quiet
642 2011-06-18 12:44:01 <krekbwoy> how does a mining server verify the hash if the mining client updates the timestamp itself?
643 2011-06-18 12:44:28 <[7]> the mining client will send the whole data to the server, not just the nonce
644 2011-06-18 12:44:32 <iz> krekbwoy: the mining client passes back the full block header it hashed to find the solution
645 2011-06-18 12:45:04 <krekbwoy> ah
646 2011-06-18 12:46:34 <krekbwoy> the whole header or just the hash of the header?
647 2011-06-18 12:46:43 <iz> the whole header
648 2011-06-18 12:47:02 <krekbwoy> alright
649 2011-06-18 12:47:05 <[7]> the hash isn't passed to the server, the server will hash the data by itself and verify that it meets the difficulty
650 2011-06-18 12:47:39 <MrTiggr> ??? [7] ...i think u guys might be chatting on a topic i wanted to talk about .....
651 2011-06-18 12:47:54 <MrTiggr> can u tell me what validation the server does against the nonce and the solution
652 2011-06-18 12:48:05 <iz> you mean pushpool?
653 2011-06-18 12:48:15 <krekbwoy> I was checking how the phoenix miner posts data
654 2011-06-18 12:48:23 <coco> anyone in here mining with 2 gpu on 1 motherboard?
655 2011-06-18 12:48:24 <krekbwoy> and what I get in wireshark is {"params": ["000000010dbb81d4c7a7588d65b39aa0994b2c5a29aa57358049f9d70000000d00000000d2af65c9afe8604b2c24fd9332009a473e3ff73f4304a4e3e33cac41549c5e3d4dfcb7f61a1321852a53d911000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"], "method": "getwork", "id": 1}
656 2011-06-18 12:48:32 <krekbwoy> coco: yes
657 2011-06-18 12:48:48 <krekbwoy> that only looks like the header
658 2011-06-18 12:49:07 <MrTiggr> my thoughts too krekbwoy
659 2011-06-18 12:49:34 <iz> krekbwoy: yeah, so the first 640 bits are the header
660 2011-06-18 12:49:40 <iz> 80 bytes
661 2011-06-18 12:50:16 <iz> and the remaining 48 bytes are like.. padding?  i think.. for the sha256 hashing.. but not 100% sure about that yet
662 2011-06-18 12:50:45 <iz> ah yeah.. that seems right though
663 2011-06-18 12:50:55 <gmaxwell> https://github.com/gmaxwell/bitcoin/commit/b1fc3250e1be42f69c595a55b517283bff910563  < fun fun
664 2011-06-18 12:51:06 <MrTiggr> the server only needs the header i thought? looks the rest up in the blockchain doesn't it ? or maybe i am waaay of topic to u
665 2011-06-18 12:51:44 <iz> all it needs is the header, it already has the block it was looking for (like all the transactions)
666 2011-06-18 12:51:55 <krekbwoy> yes
667 2011-06-18 12:52:14 <luke-jr> diki: no u
668 2011-06-18 12:52:21 <krekbwoy> but if the client keeps incrementing the timestamp the server would have to try and find the correct timestamp in order to verify the hash
669 2011-06-18 12:52:34 <iz> krekbwoy: no, it's right in there
670 2011-06-18 12:52:38 <krekbwoy> ah
671 2011-06-18 12:52:46 <gmaxwell> ::sigh::
672 2011-06-18 12:52:48 <iz> 4+32+32
673 2011-06-18 12:52:48 <krekbwoy> alright, I understand now
674 2011-06-18 12:52:50 <krekbwoy> :)
675 2011-06-18 12:53:30 <gmaxwell> Can someone else look at the pull request I just submitted (github) link above.  Unless I'm missing something I think that probably needs to be urgently fixed.
676 2011-06-18 12:54:00 <coco> anyone mining under ubuntu here??
677 2011-06-18 12:54:45 <gmaxwell> Currently bitcoin won't attempt to connect to nodes which it hasn't seen for a while and hasn't seen on IRC, assuming that if the node were working it would see it on IRC.
678 2011-06-18 12:55:02 <gmaxwell> That assumption wasn't great before the great IRC channel split, but it's certantly crap now.
679 2011-06-18 12:55:12 <[7]> coco: yes, but not with a GPU
680 2011-06-18 12:55:47 <gmaxwell> I think this will result in serious clique formation.
681 2011-06-18 12:56:25 <MrTiggr> gmaxwell ... what r ur thoughts on the exploitablilty of bitcoin because of the use of IRC ?
682 2011-06-18 12:56:57 <gmaxwell> MrTiggr: IRC doesn't present any additional hazard at all to the best of my ability to determine.
683 2011-06-18 12:57:17 <gmaxwell> MrTiggr: So far the only people I've seen arguing otherwise were misunderstanding what bitcoin was doing.
684 2011-06-18 12:57:48 <MrTiggr> ?? what if *someone* could slow down the require IRC channels (join/leave flood or something) then conduct nefarius activity in the lag
685 2011-06-18 12:58:13 <gmaxwell> MrTiggr: Okay, so you are in the misunderstanding category too. :)
686 2011-06-18 12:58:19 <jrmithdobbs> MrTiggr: WHAT IF SOMEONE COMPROMISED THE DNS ROOT
687 2011-06-18 12:58:20 <MrTiggr> we saw the main Mining sites DoS'd the other day while a significant amount of BTC was shifted ....
688 2011-06-18 12:58:26 <jrmithdobbs> or something equally dumb
689 2011-06-18 12:58:31 <gmaxwell> MrTiggr: Bitcoin only uses IRC as one way of getting a list of other bitcoin nodes.
690 2011-06-18 12:58:36 <gmaxwell> MrTiggr: IRC isn't used for anything else.
691 2011-06-18 12:58:52 <gmaxwell> MrTiggr: No BTC data is sent between nodes via IRC.
692 2011-06-18 12:59:05 <MrTiggr> ok...so polution or otherwise of that IRC would result in fake nodes being allowed on the net
693 2011-06-18 12:59:08 <MrTiggr> or something...
694 2011-06-18 12:59:10 <Namegduf> ...
695 2011-06-18 12:59:17 <MrTiggr> i'm really just brainstorming here
696 2011-06-18 12:59:23 <Namegduf> The net is open and publicly connectable anyway.
697 2011-06-18 12:59:25 <jrmithdobbs> MrTiggr: no
698 2011-06-18 12:59:36 <Namegduf> And nodes aren't trusted anyway, so fake nodes can't do anything.
699 2011-06-18 12:59:40 <gmaxwell> MrTiggr: if you want 'fake nodes' you just spin up your own 'fake' nodes. Done.
700 2011-06-18 12:59:50 <jrmithdobbs> disruption of irc services only affects brand new clients that have never connected to the p2p network before
701 2011-06-18 12:59:55 <gmaxwell> jrmithdobbs: see my above patch.
702 2011-06-18 13:00:39 <MrTiggr> fair 'nuf ..like i said ...a brainstorm ....I've done some work at looking at the "number of Bitcoin Nodes"
703 2011-06-18 13:00:46 <jrmithdobbs> gmaxwell: what's the pull number scrolling up in this terminal is slow at the moment
704 2011-06-18 13:01:13 <MrTiggr> and am seeing some odd numbers around periods of time when large # of BTC were stolen/looted
705 2011-06-18 13:01:31 <gmaxwell> MrTiggr: there is a pretty strong daily/weekly cycle.
706 2011-06-18 13:01:32 <jrmithdobbs> gmaxwell: that's hilarious because i was about to say "that's not all irc is used for" and point out that case lol
707 2011-06-18 13:01:52 <jrmithdobbs> gmaxwell: i didn't realise it used it even if -noirc was in use though
708 2011-06-18 13:01:56 <MrTiggr> gmaxwell...yes...there IS ....thats why these anomolies i see are so out of the ord
709 2011-06-18 13:02:37 <gmaxwell> MrTiggr: there being substantial variance is why different numbers are unusual?
710 2011-06-18 13:02:49 <gmaxwell> MrTiggr: So whats your data?
711 2011-06-18 13:03:13 <iz> MrTiggr: how many datapoints do you have when large # of BTC were stolen/looted?
712 2011-06-18 13:03:23 <gmaxwell> I'm very interested in seeing some active node trend data, because we currently have a impending node scaling issue...
713 2011-06-18 13:03:24 <jrmithdobbs> gmaxwell: you sure that actually solves it
714 2011-06-18 13:03:43 <MrTiggr> gmaxwell: unfortunately my data is derived from oter sources...so i don't necessarily trust it 100% ....could IRC and it's logging capability be used to gather better data is a question i have
715 2011-06-18 13:04:03 <gmaxwell> jrmithdobbs: yes/no.  It doesn't make the behavior great. It does make it better.
716 2011-06-18 13:04:07 <jrmithdobbs> MrTiggr: no because irc bootstrapping is slowly being abandonded
717 2011-06-18 13:04:13 <MrTiggr> iz: am talking about the recent movement of 17K and 250K
718 2011-06-18 13:04:31 <gmaxwell> MrTiggr: What data have you been collecting then?
719 2011-06-18 13:04:40 <MrTiggr> 250 looks like clear theft and i have my thoughts on how....doing reserch (whay am here)
720 2011-06-18 13:04:50 <gmaxwell> MrTiggr: ...
721 2011-06-18 13:04:59 <jrmithdobbs> MrTiggr: that wasn't theft
722 2011-06-18 13:05:03 <MrTiggr> gmaxwell: my data is mostly from blockexplorer
723 2011-06-18 13:05:07 <jrmithdobbs> it was mtgox recreating a wallet
724 2011-06-18 13:05:25 <MrTiggr> jrmithdobbs: which one
725 2011-06-18 13:05:31 <gmaxwell> MrTiggr: how have you obtained information about active clients via blockexplorer.
726 2011-06-18 13:05:46 <gmaxwell> MrTiggr: the only ~250k wallet motion that there has been.
727 2011-06-18 13:05:46 <jrmithdobbs> the 250K one for sure, probably the other as well
728 2011-06-18 13:05:57 <MrTiggr> gmaxwell: ...seraching for origin of my other data for you now (as in actual links)
729 2011-06-18 13:06:13 <MrTiggr> jrmithdobbs: and the 17K
730 2011-06-18 13:06:28 <gmaxwell> jrmithdobbs: in any case, it still is much less agressive about connecting to nodes it hasn't seen for a while, so there is still a problem.
731 2011-06-18 13:07:11 <jrmithdobbs> gmaxwell: i think the whole addr.dat storage code needs to be completely reworked and thought out along with the broadcasting and prioritization of received addr broadcasts
732 2011-06-18 13:07:13 <MrTiggr> jrmithdobbs: MtGoxt recreating a wallet ?? can u elabor8
733 2011-06-18 13:07:54 <jrmithdobbs> MrTiggr: wallet is a bdb file. when wallet gets HUGE bitcoin stop working. solution: start up bitcoind with empty wallet, xfer to address in it.  destroy old wallet. (back it up, don't really destroy)
734 2011-06-18 13:07:59 <iz> wait.. the 250k one that lulzsec was claiming was confirmed as a mtgox wallet consolidation?
735 2011-06-18 13:08:25 <jrmithdobbs> iz: they never "claimed" it
736 2011-06-18 13:08:28 <iz> this one? http://blockexplorer.com/t/3kQG3xmAJC
737 2011-06-18 13:08:31 <jrmithdobbs> the lolled at it
738 2011-06-18 13:08:41 <jrmithdobbs> s/the/they/
739 2011-06-18 13:08:47 <iz> well, they called attention to it and loled at it.. making it seem like they hacked a giant wallet
740 2011-06-18 13:08:58 <iz> or were manipulating the market
741 2011-06-18 13:09:03 <gmaxwell> iz: thats the 25k coin theft. Not the 250k wallet motion.
742 2011-06-18 13:09:05 <MrTiggr> jrmithdobbs: i did not know that bitcoin's performance degraded like that ....  ?? why ....doesnt the use of meerkle trees prevent the bloating of wallets ?
743 2011-06-18 13:09:13 <iz> oh, off my a scale of 10
744 2011-06-18 13:09:40 <iz> so was that connected to allinvain?  or is that a different one also?
745 2011-06-18 13:09:50 <gmaxwell> MrTiggr: this was a wallet that had thousands of accounts in it from incoming payments.
746 2011-06-18 13:09:56 <gmaxwell> iz: thats allinvain
747 2011-06-18 13:10:01 <MrTiggr> iz: the 25k one was allinvain ...thats my understanding
748 2011-06-18 13:10:05 <gmaxwell> (sort of a fitting name)
749 2011-06-18 13:10:06 <MrTiggr> :D
750 2011-06-18 13:10:07 <iz> ah, okay
751 2011-06-18 13:10:11 <MrTiggr> ..makes me suss
752 2011-06-18 13:10:53 <MrTiggr> gmaxwell: i KNOW! right...i have expended some resources in tracking the wallets...it looks kinda dodgy
753 2011-06-18 13:11:19 <doublec> how big does it get
754 2011-06-18 13:11:20 <jrmithdobbs> MrTiggr: merkle trees have nothing to do with storing huge amounts of data in a single bdb file in an app that misuses the bdb api
755 2011-06-18 13:11:21 <gmaxwell> MrTiggr: so your active node data that showing "odd numbers"?
756 2011-06-18 13:11:39 <doublec> I see my week old wallet on my pool is 27MB so I guess it grows quite fast
757 2011-06-18 13:11:50 <jrmithdobbs> doublec: it can ya
758 2011-06-18 13:12:10 <MrTiggr> gmaxwell: ...yes ...at the time that the xfer apparently took place (from what i can gather)
759 2011-06-18 13:12:26 <jrmithdobbs> so basically
760 2011-06-18 13:12:26 <MrTiggr> its hard......trustworthy info is loose on the ground
761 2011-06-18 13:12:30 <jrmithdobbs> you don't know what you're talking about
762 2011-06-18 13:12:41 <jrmithdobbs> k
763 2011-06-18 13:12:41 <MrTiggr> no need for the tone d00d
764 2011-06-18 13:13:02 <MrTiggr> either you can educate me or you can be an asshole
765 2011-06-18 13:13:10 <jrmithdobbs> i can do both
766 2011-06-18 13:13:11 <gmaxwell> MrTiggr: Gather what from what?
767 2011-06-18 13:13:24 <gmaxwell> MrTiggr: What data are you looking at, and what did it say?
768 2011-06-18 13:13:28 <iz> heh