1 2012-08-30 00:00:42 <sebicas> Yes, it worked fine with send many
  2 2012-08-30 00:00:43 <sebicas> https://gist.github.com/734c130decbb8f63bcfd
  3 2012-08-30 00:01:23 <sebicas> BlueMatt: but still not working with createrawtransaction
  4 2012-08-30 00:01:48 <sebicas> At least for one address as output
  5 2012-08-30 00:02:17 <gmaxwell> sebicas: okay does it work if you have a vector of dictionaries instead of a vector with a string in it?
  6 2012-08-30 00:03:14 <sebicas> Let me check..
  7 2012-08-30 00:06:49 <sebicas> gmaxwell: Is this correct? b = {'1AACtZp65EtF4mZ2fDHC2Fj5h1dGc8zu91':2000000, '17GsLk2Um9cZWaJSFeM7EpT4yYxtcB7SN5':2000000}
  8 2012-08-30 00:07:17 <sebicas> With that I still get "value is type str, expected obj"
  9 2012-08-30 00:07:23 <gmaxwell> I was referring to the first argument.
 10 2012-08-30 00:07:38 <sebicas> Ahh.ok
 11 2012-08-30 00:07:51 <sebicas> First works ok..
 12 2012-08-30 00:08:00 <sebicas> The problem is with the second argument..
 13 2012-08-30 00:08:37 <sebicas> If I change the first argument..
 14 2012-08-30 00:08:47 <sebicas> It tell me that is expecting an array
 15 2012-08-30 00:09:26 <sebicas> At first I was sending an String, but worked fine when I replace with with a list
 16 2012-08-30 00:10:16 <sebicas> Here is the code: https://gist.github.com/322b66dadd0b3a620d55
 17 2012-08-30 00:10:59 <kreal> "Internal HTTP server is now thread-per-connection, rather than a single-threaded queue that would stall on network I/O." <-- Me liky.
 18 2012-08-30 00:12:13 <BlueMatt> the locks are still global in all methods
 19 2012-08-30 00:12:38 <gmaxwell> sebicas: I realize thats an RFC1918 address, but you really should avoid pastebinning your rpcpassword. FWIW.
 20 2012-08-30 00:13:04 <Luke-Jr> XD
 21 2012-08-30 00:13:10 <gmaxwell> sebicas: your first argument is ['string'] this is almost certantly wrong.
 22 2012-08-30 00:13:30 <sebicas> ok
 23 2012-08-30 00:13:38 <gmaxwell> it should probably be a = [{"txid":"4abe438bbdea5d367dac3f58d9f9b6551d86568c5d5e02b81d76ce17bb8f11a8","vout":0}]
 24 2012-08-30 00:13:41 <kreal> I fear the "smart" times for transactions a bit though. But lets see how it works out on my dev.
 25 2012-08-30 00:14:13 <gmaxwell> kreal: really easy to OOM yourself that way by spinning up a zillion threads.
 26 2012-08-30 00:14:45 <BlueMatt> oh, we merged the block timestamp tx stuff? nice!
 27 2012-08-30 00:14:49 <BlueMatt> ive been waiting for that
 28 2012-08-30 00:15:03 <BlueMatt> no to go find an old wallet and rescan up instead of having rescan times for all my txn...
 29 2012-08-30 00:15:04 <kreal> gmaxwell, sorry a bit tired, did not comprehend that.
 30 2012-08-30 00:15:51 <gmaxwell> kreal: for i in {1..1000} ; do bitcoind listtransactions 2
 31 2012-08-30 00:16:05 <gmaxwell> >/dev/null & ); done
 32 2012-08-30 00:16:07 <BlueMatt> may need a few more than 1000
 33 2012-08-30 00:16:13 <BlueMatt> while [ true ]; ...
 34 2012-08-30 00:16:41 <gmaxwell> er I messed that up.. for i in {1..1000} ; do ( bitcoind listtransactions >/dev/null & ); done  will cause about 5gb memory usage.
 35 2012-08-30 00:16:45 <kreal> gmaxwell right
 36 2012-08-30 00:17:23 <BlueMatt> wait...we actually use that much mem per request? that sounds like something is fairly broken...
 37 2012-08-30 00:17:47 <kreal> FYI, had to give walletbit 12GB ram.
 38 2012-08-30 00:17:50 <gmaxwell> well, vm, it's from thread stacks.
 39 2012-08-30 00:18:12 <BlueMatt> still...5mb/thread (not incl the other stuff)
 40 2012-08-30 00:18:23 <BlueMatt> that still sounds very broken...
 41 2012-08-30 00:18:30 <kreal> used: 5382  free: 6635   aww not so bad afterall.
 42 2012-08-30 00:19:07 <gmaxwell> kreal: bitcoin's memory usage shouldn't be anywhere near that high.
 43 2012-08-30 00:19:40 <kreal> with 1000 users on one instance of bitcoind, and 1000 on another ?
 44 2012-08-30 00:19:56 <gmaxwell> kreal: what is a user?
 45 2012-08-30 00:20:06 <sebicas> BlueMatt: Thxs! It worked!
 46 2012-08-30 00:20:30 <kreal> gmaxwell a user is a script doing JSON-RPC getbalance for instance.
 47 2012-08-30 00:20:49 <BlueMatt> sebicas: why do you keep tagging me?
 48 2012-08-30 00:20:58 <kreal> simplified
 49 2012-08-30 00:20:59 <gmaxwell> kreal: all those should have been serialized before. hm. odd.
 50 2012-08-30 00:21:15 <gmaxwell> BlueMatt: because you have Blue in your name, it makes you sound more helpful than me.
 51 2012-08-30 00:21:27 <BlueMatt> uhhh...ok?
 52 2012-08-30 00:21:28 <sebicas> I was just thanking you??? sorry
 53 2012-08-30 00:21:50 <BlueMatt> sebicas: its no big deal, I just found it odd, its not even a tab-complete
 54 2012-08-30 00:22:18 <kreal> well to extend, it also implies doing sendfrom, getnewaddress and so on.
 55 2012-08-30 00:22:23 <sebicas> I am new in IRC
 56 2012-08-30 00:22:44 <kreal> whatever an ewallet does.
 57 2012-08-30 00:22:57 <gmaxwell> sebicas: bluematt is confused because it was me helping you, I think.
 58 2012-08-30 00:23:14 <gmaxwell> kreal: sure sure.. perhaps its just the wallet stuff.
 59 2012-08-30 00:23:19 <gmaxwell> I wish we had a heap profiler.
 60 2012-08-30 00:23:34 <sebicas> Sorry! :)
 61 2012-08-30 00:23:49 <sebicas> lol Thx gmaxwell!
 62 2012-08-30 00:23:57 <gmaxwell> 
ACTION wonders what massif would do with bitcoin

 63 2012-08-30 00:24:01 <kreal> gmaxwell, 0.6.3 helped alot on mem usage.
 64 2012-08-30 00:24:09 <kreal> cannot wait to try 0.7.0
 65 2012-08-30 00:24:36 <gmaxwell> kreal: 0.7.0 should help except for multithreading potentially increasing it.
 66 2012-08-30 00:24:51 <BlueMatt> gmaxwell: a ton, Id think
 67 2012-08-30 00:25:03 <gmaxwell> depends on how many connections you have.
 68 2012-08-30 00:26:09 <kreal> gmaxwell the reason for my bitcoind's mem usage could very well be because of the cron job running every minute, checking for new deposits.
 69 2012-08-30 00:26:29 <kreal> so 5GB is very good.
 70 2012-08-30 00:27:00 <kreal> in retrospect
 71 2012-08-30 00:29:28 <Luke-Jr> ???
 72 2012-08-30 00:29:46 <gmaxwell> Well, it's managable in any case.
 73 2012-08-30 00:29:51 <gmaxwell> kreal: how big are your wallet files?
 74 2012-08-30 00:30:20 <kreal> sec
 75 2012-08-30 00:30:26 <Luke-Jr> [02:13:41] <kreal> I fear the "smart" times for transactions a bit though. But lets see how it works out on my dev. <-- so don't use them, the blocktime and timereceived are still there
 76 2012-08-30 00:30:36 <kreal> Luke-Jr, ok good
 77 2012-08-30 00:31:08 <kreal> gmaxwell they are 30MB and up.
 78 2012-08-30 00:31:16 <gmaxwell> hm. yea, 5gb is broken then.
 79 2012-08-30 00:31:48 <gmaxwell> once I figure out how to get good heap profiles of bitcoin I might ask you to collect a bit of data.  Though I suppose it would be interesting to hear what happens after you go to 0.7.0
 80 2012-08-30 00:32:00 <gmaxwell> kreal: do they grow at all ? e.g. is it obviously leaking?
 81 2012-08-30 00:32:21 <kreal> they do, around 1MB a day now a days.
 82 2012-08-30 00:33:19 <gmaxwell> yea, hm. It would be good to kill that leak if it isn't already dead. Though 1mb/day doesn't explain 5gGB.
 83 2012-08-30 00:33:39 <BlueMatt> nothing explains 5g, thats a pretty big leak!
 84 2012-08-30 00:33:46 <BlueMatt> s/big/huge/
 85 2012-08-30 00:34:02 <kreal> wouldnt know, I did not make bitcoind neither do I contribute to it's development because I not that good at c++ or c
 86 2012-08-30 00:34:10 <kreal> I'm*
 87 2012-08-30 00:34:27 <gmaxwell> kreal: Thats what were here for. You keep running it and reporting weird behavior, and we'll fix it sooner or later.
 88 2012-08-30 00:34:48 <gmaxwell> Finding the problems is half the work.
 89 2012-08-30 00:34:49 <kreal> always, while promoting bitcoin to the general public.
 90 2012-08-30 00:34:50 <kreal> :)
 91 2012-08-30 00:35:42 <kreal> oh and more information, I had to point debug.log to /dev/null it was eating my space in hours.
 92 2012-08-30 00:36:25 <gmaxwell> kreal: any idea which entries were killing you? We log on some of the RPCs which is probably why.
 93 2012-08-30 00:36:37 <kreal> no sorry.
 94 2012-08-30 00:36:42 <kreal> just needed a quick fix
 95 2012-08-30 00:36:54 <gmaxwell> We support proper rotation now. You can mv debug.log debug.log.1  then kill -HUP bitcoind and it will make a new debug.log
 96 2012-08-30 00:37:15 <kreal> gmaxwell ok awesome.
 97 2012-08-30 00:37:22 <kreal> never shutdown bitcoind though.
 98 2012-08-30 00:37:42 <kreal> probably one of the reasons for the insane mem usage.
 99 2012-08-30 00:37:44 <gmaxwell> so you could rotate out your logs every hour and then at least you'd have some record if it blows up. And if you identify the overly chatty messages it may be something we can shut up easily.
100 2012-08-30 00:37:53 <gmaxwell> kreal: kill -HUP doesn't shut it down.
101 2012-08-30 00:38:11 <gmaxwell> It makes it create a new debug.log after the old one has been moved out of the way.
102 2012-08-30 00:38:28 <kreal> ok then.
103 2012-08-30 00:38:40 <kreal> great, I'
104 2012-08-30 00:38:49 <kreal> I'll see if I can provide some more info later.
105 2012-08-30 00:40:12 <gmaxwell> kreal: also, if you're setup to compile bitcoind it's very easy to turn off overly chatty log messages yourself. I can walk you through it.
106 2012-08-30 00:41:06 <kreal> thanks, I'll keep that in mind.
107 2012-08-30 00:41:24 <kreal> I know a bit c/c++ but am mostly C#
108 2012-08-30 00:42:04 <kreal> I also need to find time to try and move wallet.dat from Berkeley DB to MySQLi just for the fun of it.
109 2012-08-30 00:43:06 <gmaxwell> kreal: there is almost enough interface in the RPC now to reasonably implement a wallet externally and just use bitcoind for speaking the protocol and tracking the blockchain.
110 2012-08-30 00:43:24 <gmaxwell> We'll probably need a few more things to make that work well... but that might be an option for you in the future.
111 2012-08-30 00:44:37 <kreal> indeed
112 2012-08-30 00:48:27 <kreal> hmm
113 2012-08-30 00:48:35 <kreal> how much Ghash you think a bitcoind can handle?
114 2012-08-30 00:49:18 <kreal> was thinking at trowing 160Ghash at it
115 2012-08-30 00:49:22 <gmaxwell> mining directly? er. it behaves poorly with more than a few.  the mining rpcs are not reentrant without patches (unless that slipped in while I wasn't looking)
116 2012-08-30 00:49:33 <kreal> I have this idea that it would make transactions quicker.
117 2012-08-30 00:49:52 <gmaxwell> Just about everyone run a front end poolserver daemon with it, even when mining solo.
118 2012-08-30 00:50:01 <kreal> yes
119 2012-08-30 00:51:35 <kreal> bad idea then :)
120 2012-08-30 00:52:08 <gmaxwell> If you want faster transactions you can make a deal with an existing pool to priortize yours.
121 2012-08-30 00:52:20 <gmaxwell> Luke has provides such arrangements.
122 2012-08-30 00:52:39 <kreal> yes I read about that.
123 2012-08-30 00:52:50 <kreal> and wondered why I did not already do that.
124 2012-08-30 00:52:52 <gmaxwell> We have a patch in the pipeline to make it easiy for a miner to priority boost single transactions. It didn't quite make it in for 0.7.0.
125 2012-08-30 00:53:14 <kreal> probably because I'm not the best in the world at talking with people.
126 2012-08-30 00:53:19 <gmaxwell> kreal: I get the impression that many pool operators are not that actively engaged; other than basic upkeep its passive income.
127 2012-08-30 00:53:37 <gmaxwell> oh why you. Sorry thought you were asking why more pools didn't have facilities for that.
128 2012-08-30 00:53:52 <gmaxwell> I expect it'll be more common once the basic feature is official.
129 2012-08-30 01:06:00 <kreal> the only ones I know are Luke-Jr and Jine anyhow.
130 2012-08-30 01:08:14 <gmaxwell> kreal: I'm hoping that once the API means no patching is required someone will setup a brokering service.
131 2012-08-30 01:08:55 <kreal> oh you just invented a new service model :)
132 2012-08-30 01:09:16 <kreal> business model *
133 2012-08-30 01:09:56 <gmaxwell> I doubt its much of a money maker.
134 2012-08-30 01:10:22 <kreal> true.
135 2012-08-30 01:12:56 <kreal> 2843 MB/min pretty good for my new tape library I reckon.
136 2012-08-30 01:13:14 <keverw> Hey! Does anyone know of a client side Javascript Library to validate Bitcoin and Testnet addresses? I found one and changing Bitcoin.Address.networkVersion = 0x00 to   Bitcoin.Address.networkVersion = 0x6F; // testnet didn't seem to work??? Any well known good ones?
137 2012-08-30 01:14:06 <kreal> don't know of anyone sorry. I just use rpc.
138 2012-08-30 01:14:41 <keverw> Yeah I would use rpc but I don't know the address sent to the server. Saving it as a cookie
139 2012-08-30 01:16:57 <kreal> can you look what blockchain.info does maybe?
140 2012-08-30 01:18:53 <gmaxwell> presumably there is code in bitcoinjs for this.
141 2012-08-30 01:18:56 <keverw> I'm looking at http://pastebin.com/B5r3P5Ny this code btw
142 2012-08-30 01:20:34 <keverw> says "<!-- taken from bitcoinjs almost verbatim -->"
143 2012-08-30 01:21:58 <gmaxwell> keverw: what happens if you take out the version test?
144 2012-08-30 01:22:12 <keverw> not sure???.
145 2012-08-30 01:24:03 <keverw> I'm calling check_address('moto6bxC99T4ZSj7F77izS1YrmpWQKxnGk');
146 2012-08-30 01:25:06 <keverw> not 100% sure how to remove the check???. but I kinda wish it worked. I was going to do something like isTestnet = true or false so I can switch back and forth between dev and production
147 2012-08-30 01:25:35 <gmaxwell> keverw: just comment out the part of the code that rejects it if the version doesn't match.
148 2012-08-30 01:25:40 <gmaxwell> and see if that passes.
149 2012-08-30 01:25:51 <keverw> if (version != 0) ?
150 2012-08-30 01:26:09 <keverw> that and the throw?
151 2012-08-30 01:26:22 <keverw> yep. did it returning true now
152 2012-08-30 01:26:33 <keverw> and check_address('moto6bxC99T4ZSj7F77izS1YrmpWQKxnGs'); is false
153 2012-08-30 01:26:38 <keverw> check_address('moto6bxC99T4ZSj7F77izS1YrmpWQKxnGk'); is true
154 2012-08-30 01:27:06 <Joric> keverw, if version != 111 i believe
155 2012-08-30 01:27:10 <keverw> so seems to just be the version check! Not sure how to fix that???. any idea? Would prefer that it worked??? depending on what Bitcoin.Address.networkVersion is set to
156 2012-08-30 01:27:31 <Joric> the address version of testnet is 111 instead of 0
157 2012-08-30 01:27:37 <gmaxwell> As joric says, testnet is 111, so put that in with a switch to trigger it.
158 2012-08-30 01:27:51 <lianj> keverw: moto6bxC99T4ZSj7F77izS1YrmpWQKxnGs is false for me too
159 2012-08-30 01:27:55 <Joric> also, this is my pastebin
160 2012-08-30 01:27:58 <keverw> it's meant to :)
161 2012-08-30 01:28:01 <gmaxwell> though that code is a bummer, it doesn't correctly support p2sh addresses. You really ought to fix that.
162 2012-08-30 01:29:16 <Joric> gmaxwell, are there any clients that still doesnt support p2sh?
163 2012-08-30 01:29:44 <keverw> if (version != Bitcoin.Address.networkVersion) seems like a possible fix also
164 2012-08-30 01:29:48 <keverw> doing some more testing.
165 2012-08-30 01:29:54 <Luke-Jr> send-to-p2sh is implemented in 0.4.8rc1 fwiw
166 2012-08-30 01:30:14 <gmaxwell> Joric: I'm sure. It's more important that services implement it however.
167 2012-08-30 01:30:52 <keverw> Sweet! The version checking seems fixed!
168 2012-08-30 01:31:27 <keverw> http://pastebin.com/mD3Y8y6b
169 2012-08-30 01:31:56 <keverw> if (version != Bitcoin.Address.networkVersion) seems to work insead of a hardcoded 0 or 111.
170 2012-08-30 01:32:25 <gmaxwell> now make 2MxKEf2su6FGAUfCEAHreGFQvEYrfYNHvL7 pass for testnet
171 2012-08-30 01:32:36 <keverw> is that a p2sh address?
172 2012-08-30 01:33:32 <gmaxwell> and 3NJZLcZEEYBpxYEUGewU4knsQRn1WM5Fkt on mainnet.
173 2012-08-30 01:33:33 <gmaxwell> Yes.
174 2012-08-30 01:34:35 <keverw> oh??? how? I This stuff is kinda advance for me :) I just found this on the forums. Could someone help me? Plus others can use this same code.
175 2012-08-30 01:35:35 <gmaxwell> base58.h: * Public-key-hash-addresses have version 0 (or 111 testnet).
176 2012-08-30 01:35:36 <gmaxwell> base58.h: * Script-hash-addresses have version 5 (or 196 testnet).
177 2012-08-30 01:35:52 <lianj> if (version != Bitcoin.Address.networkVersion) || (version != Bitcoin.Address.p2shVersion)
178 2012-08-30 01:36:04 <gmaxwell> Behold, the power of OR. :)
179 2012-08-30 01:36:19 <Luke-Jr> ??? except it should be INSIDE the parenthesis :P
180 2012-08-30 01:36:58 <Joric> what is this sorcery!
181 2012-08-30 01:37:18 <gmaxwell> Luke-Jr: just add more parens. It's like pasta! more is always good!
182 2012-08-30 01:37:24 <Luke-Jr> lol
183 2012-08-30 01:37:56 <freewil> parenthesis always make comprehension easier
184 2012-08-30 01:38:23 <Joric> ppl started to bitch about bw https://bitcointalk.org/index.php?topic=104390
185 2012-08-30 01:38:49 <weex> Joric: thought bw meant bandwidth, not brainwallet
186 2012-08-30 01:38:57 <keverw> p2sh works with bit coin qt?
187 2012-08-30 01:38:58 <Luke-Jr> 
ACTION too

188 2012-08-30 01:39:04 <Luke-Jr> keverw: not really
189 2012-08-30 01:39:23 <sebicas> Made a mistake by sending http://blockchain.info/tx-index/18514628/fddec3a75b7dd7293b1c1dc68d0daf528da5be8ee2bb5e98a9241bc9d01bada1
190 2012-08-30 01:39:24 <Joric> i actually wanted to make it like wolfram-alpha for bitcoin but it's useless without https and github pages don't support https at all
191 2012-08-30 01:39:24 <keverw> oh??? my software uses BitcoinQT/the BitcoinD???..
192 2012-08-30 01:39:27 <Luke-Jr> technically, "yes, to an extent", but for practical purposes???
193 2012-08-30 01:39:30 <sebicas> Will it confirm?
194 2012-08-30 01:39:35 <Luke-Jr> keverw: bitcoind is workable with 0.7+
195 2012-08-30 01:39:47 <keverw> oh. ok so I guess I could support it
196 2012-08-30 01:39:58 <Luke-Jr> sebicas: likely. why wouldn't it?
197 2012-08-30 01:40:01 <weex> sebicas: probably quite quickly
198 2012-08-30 01:40:07 <weex> lots of fees
199 2012-08-30 01:40:14 <Luke-Jr> keverw: well, sending TO p2sh is easy, and should work everywhere..
200 2012-08-30 01:40:28 <sebicas> Because the input amount is more than the output
201 2012-08-30 01:40:38 <sebicas> Shouldn't both be the same?
202 2012-08-30 01:40:38 <weex> sebicas: the rest will be spent as fees
203 2012-08-30 01:40:42 <Joric> wolfram alpha should add support for bitcoin already )
204 2012-08-30 01:40:48 <sebicas> Ahh..
205 2012-08-30 01:40:49 <Luke-Jr> sebicas: no, excess is what makes transaction fees
206 2012-08-30 01:41:06 <weex> that is kind of tricky
207 2012-08-30 01:41:19 <keverw> http://pastebin.com/GbEudm8E
208 2012-08-30 01:41:24 <sebicas> So I gave 3.5BTC by mistake.
209 2012-08-30 01:41:31 <sebicas> Thanks
210 2012-08-30 01:41:33 <keverw> the p2shVersion seems to not work??? hmm
211 2012-08-30 01:41:40 <Luke-Jr> sebicas: no, thank you!
212 2012-08-30 01:41:42 <weex> sebicas: how did you built that tx?
213 2012-08-30 01:42:03 <weex> second time i've heard of this in the last week
214 2012-08-30 01:42:05 <sebicas> Yep, I am testing the new sendrawtransaction in 0.7.0
215 2012-08-30 01:42:50 <sebicas> It should be a warning on the documentation..
216 2012-08-30 01:43:00 <sebicas> I was lucky is just 3.5BTC
217 2012-08-30 01:43:07 <weex> sebicas: which documentation would you have been checking?
218 2012-08-30 01:43:28 <sebicas> https://en.bitcoin.it/wiki/Raw_Transactions
219 2012-08-30 01:44:43 <keverw> maybe it has something to do with  this.version = Bitcoin.Address.networkVersion;???. hmm
220 2012-08-30 01:46:07 <keverw> any ideas?
221 2012-08-30 01:51:27 <keverw> added isTestnet var just missing p2shVersion now. http://pastebin.com/1QcMyHdX
222 2012-08-30 02:20:12 <freewil> gmaxwell, are all addresses including p2sh 25 bytes
223 2012-08-30 02:21:07 <gmaxwell> freewil: no.
224 2012-08-30 02:23:32 <freewil> https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses
225 2012-08-30 02:23:43 <freewil> step 8 - this is the 25-byte binary address
226 2012-08-30 02:25:17 <gmaxwell> freewil: oh you mean the base 58 decoded. Yes. All current ones at least.
227 2012-08-30 02:25:39 <freewil> ok thank you
228 2012-08-30 02:40:10 <Luke-Jr> hahahahaha
229 2012-08-30 02:40:19 <Luke-Jr> "Funds are on their way (bitcoin transaction: cf41fc6f26dc8973b9fa5650da64cc26bbbb60d09b0a80c0cc0be62abc6948a8) i sent0.2 i know it not to much but this all i got"
230 2012-08-30 02:40:34 <Luke-Jr> change for that transaction: 24 BTC
231 2012-08-30 02:41:44 <gmaxwell> hahah
232 2012-08-30 02:41:48 <gmaxwell> could be a webwallet. :)
233 2012-08-30 02:42:23 <Luke-Jr> gmaxwell: I kinda doubt it.
234 2012-08-30 02:42:33 <Luke-Jr> gmaxwell: this is someone who I have strong evidence is operating a botnet
235 2012-08-30 02:42:40 <Luke-Jr> and the fool sent me his postal address
236 2012-08-30 02:43:13 <Luke-Jr> I told him I would only help him build a CPU miner if he confirmed his address by me sending him mail
237 2012-08-30 02:43:15 <Luke-Jr> lol
238 2012-08-30 02:43:33 <gmaxwell> Did you get a picture of him with a shoe on his head too?
239 2012-08-30 02:43:49 <Luke-Jr> no
240 2012-08-30 02:43:53 <gmaxwell> aww
241 2012-08-30 02:43:54 <Luke-Jr> why won't Coin Control work? :/
242 2012-08-30 02:44:00 <Luke-Jr> I want to quarantine this coin
243 2012-08-30 02:44:30 <Luke-Jr> Error: Transaction creation failed.
244 2012-08-30 02:45:16 <keverw> back. Should I worry about adding p2sh to that or ??? I'm sorta a noob when adding it.
245 2012-08-30 02:46:03 <gmaxwell> keverw: you should add it, its easy.
246 2012-08-30 02:46:19 <keverw> oh??? how? http://pastebin.com/1QcMyHdX
247 2012-08-30 02:46:20 <gmaxwell> it's an OR and another version for each master and testnet.
248 2012-08-30 02:46:30 <keverw> I think two parts need change??? not sure.
249 2012-08-30 02:46:48 <keverw> like this.version = Bitcoin.Address.networkVersion;
250 2012-08-30 02:46:52 <Luke-Jr> gmaxwell: what would be an easy way to use the raw tx stuff to quarantine it?
251 2012-08-30 02:46:57 <keverw> and if (version != Bitcoin.Address.networkVersion)
252 2012-08-30 02:47:43 <gmaxwell> if ((version != Bitcoin.Address.networkVersion)&&(version != Bitcoin.Address.p2shVersion))
253 2012-08-30 02:48:16 <keverw> ok. cool. what about this.version = Bitcoin.Address.networkVersion; also?
254 2012-08-30 02:48:18 <gmaxwell> Luke-Jr: there is no quarantine. The only way to 'quarantine' it using rawtx is to spend it to something outside your wallet.
255 2012-08-30 02:48:30 <keverw> in the Bitcoin.Address = function (bytes) { it says that
256 2012-08-30 02:48:52 <Luke-Jr> gmaxwell: that'd be fine
257 2012-08-30 02:49:54 <keverw> check_address('3NJZLcZEEYBpxYEUGewU4knsQRn1WM5Fkt'); is true! on main
258 2012-08-30 02:49:57 <gmaxwell> keverw: you can just take that out if your caller doesn't use it.
259 2012-08-30 02:50:31 <gmaxwell> Luke-Jr: listunspent [addr]  to find it. createrawtx [it] [where-you-want-it]
260 2012-08-30 02:50:37 <gmaxwell> Luke-Jr: then sign and send.
261 2012-08-30 02:51:41 <keverw> okay. deleting that line seems to be no diff. Sweet!
262 2012-08-30 02:51:59 <Luke-Jr> gmaxwell: ironically, my listunspent is too old for the address argument, but using coin control's filter it only shows it >_<
263 2012-08-30 02:52:15 <keverw> http://pastebin.com/1JRcD5TN
264 2012-08-30 02:52:19 <keverw> seems great?
265 2012-08-30 02:52:20 <Luke-Jr> ugh, I don't have createrawtx either
266 2012-08-30 02:52:21 <Luke-Jr> :/
267 2012-08-30 02:53:12 <gmaxwell> keverw: yea that line just set a version field on the returned address object.
268 2012-08-30 02:53:15 <keverw> you know  Bitcoin.Address.p2shVersion = 5; and  Bitcoin.Address.p2shVersion = 196; can those be converted to hex? like 0x6F and 0x00 so they can be constant with the Bitcoin.Address.networkVersion ones?
269 2012-08-30 02:53:28 <gmaxwell> more useful than version would be a isP2SH field, but even that isn't important.
270 2012-08-30 02:53:42 <gmaxwell> 196 in hex is 0xc4
271 2012-08-30 02:53:53 <gmaxwell> 5 in hex is 0x05
272 2012-08-30 02:54:15 <keverw> dang. Thanks! How are you guys so dang smart?
273 2012-08-30 02:54:26 <kreal> They stole it!
274 2012-08-30 02:54:28 <Luke-Jr> is there a web tx decompiler? <.<\\
275 2012-08-30 02:54:31 <gmaxwell> It's the beard.
276 2012-08-30 02:54:42 <gmaxwell> Luke-Jr: web? fwh. decoderawtransaction
277 2012-08-30 02:54:45 <Luke-Jr> >_<
278 2012-08-30 02:54:54 <kreal> I'm not allowed to grow my beard, because of my gf... so I'm not so smart.
279 2012-08-30 02:54:59 <kreal> she says it iches...
280 2012-08-30 02:55:05 <Luke-Jr> ???
281 2012-08-30 02:55:12 <gmaxwell> my girlfriend likes mine, and has kept me from removing it when I would have otherwise.
282 2012-08-30 02:55:15 <Luke-Jr> gmaxwell: did the raw tx stuff get in using BTC units? -.-
283 2012-08-30 02:55:27 <kreal> meh.
284 2012-08-30 02:55:39 <gmaxwell> Luke-Jr: bleh
285 2012-08-30 02:55:41 <keverw> thanks guys! This is like prefect.
286 2012-08-30 02:55:50 <gmaxwell> Luke-Jr: well, thats a mixed bag.
287 2012-08-30 02:56:00 <Luke-Jr> 
ACTION facepalms

288 2012-08-30 02:56:29 <gmaxwell> Luke-Jr: IIRC our formating is always such that you can get the integer by .replace('.','')
289 2012-08-30 02:56:55 <Luke-Jr> gmaxwell: no library is going to allow that..
290 2012-08-30 02:57:01 <Luke-Jr> sigh
291 2012-08-30 03:02:49 <devrandom> sipa: great
292 2012-08-30 03:03:26 <gmaxwell> oh crap. devrandom is caught in a time vortex. Run away!
293 2012-08-30 03:05:12 <Luke-Jr> lol
294 2012-08-30 03:07:28 <devrandom> !ton ma I
295 2012-08-30 03:07:29 <gribble> Error: "ton" is not a valid command.
296 2012-08-30 03:08:37 <gmaxwell> crap, if he is conjugate as well as time reverse we're hosed!
297 2012-08-30 03:09:34 <devrandom> ?sdrawkcab gnipyt ydobyreve si yhw
298 2012-08-30 03:14:11 <Luke-Jr> gmaxwell: btw, in case you missed it:
299 2012-08-30 03:14:13 <Luke-Jr> [22:18:54] <Luke-Jr> -rw-r--r-- 1 bitcoinpool bitcoinpool 118G Aug 29 22:18 debug.log
300 2012-08-30 03:14:32 <kreal> hehe my point :)
301 2012-08-30 03:14:33 <gmaxwell> hehe I saw earlier.
302 2012-08-30 04:00:34 <MC-Eeepc> ok so guys
303 2012-08-30 04:00:58 <MC-Eeepc> if everyone moves to ultraprune because its awesome
304 2012-08-30 04:01:09 <MC-Eeepc> who exactly has the actual real chain anymore
305 2012-08-30 04:01:23 <kreal> I'll ultrapurge you if you want.
306 2012-08-30 04:01:40 <kreal> ;)
307 2012-08-30 04:02:16 <MC-Eeepc> wat
308 2012-08-30 04:03:16 <Luke-Jr> MC-Eeepc: whoever doesn't delete blocks
309 2012-08-30 04:03:20 <MC-Eeepc> how is a new nodes supposed to prune the chain itself if no one has the fat chain anymore
310 2012-08-30 04:03:34 <Luke-Jr> MC-Eeepc: ultraprune doesn't delete the chain
311 2012-08-30 04:04:09 <MC-Eeepc> yes it does, rplaces it with something smaller
312 2012-08-30 04:04:32 <Luke-Jr> MC-Eeepc: just the index
313 2012-08-30 04:04:50 <MC-Eeepc> eh?
314 2012-08-30 04:05:02 <MC-Eeepc> but the index isnt the huge file
315 2012-08-30 04:05:40 <Luke-Jr> the huge file is split up, and you can delete some of them
316 2012-08-30 04:06:10 <MC-Eeepc> yeah its essentially lossy compression
317 2012-08-30 04:06:19 <Luke-Jr> ???no
318 2012-08-30 04:06:19 <MC-Eeepc> so who has the full file anymore
319 2012-08-30 04:06:38 <Luke-Jr> everyone who doesn't manually delete any parts of it
320 2012-08-30 04:07:23 <MC-Eeepc> if you do not then you get no benefits of ultraprune
321 2012-08-30 04:08:00 <Luke-Jr> wrong
322 2012-08-30 04:08:05 <Luke-Jr> the main benefits are the pruned index
323 2012-08-30 04:08:06 <MC-Eeepc> the data is gone, thats the point
324 2012-08-30 04:10:46 <gmaxwell> ultraprune is not lossy.
325 2012-08-30 04:11:07 <gmaxwell> it's blind people arguing about the colors of flowers.
326 2012-08-30 04:11:15 <gmaxwell> Ultraprune removes _no_ information.
327 2012-08-30 04:11:40 <gmaxwell> It's structured in a way that information can be removed, but thats not implemented and probably won't be soon.
328 2012-08-30 04:11:52 <gmaxwell> It gets big performance improvements due to reducing the working set size.
329 2012-08-30 04:12:47 <gmaxwell> (by avoiding a bunch of redundant, needless data in the index)
330 2012-08-30 04:13:06 <MC-Eeepc> but not database size currently?
331 2012-08-30 04:13:12 <MC-Eeepc> the blk dats
332 2012-08-30 04:13:23 <gmaxwell> MC-Eeepc: In english?
333 2012-08-30 04:13:51 <MC-Eeepc> can you sync a full node from an ultraprune node
334 2012-08-30 04:14:16 <gmaxwell> Yes.
335 2012-08-30 04:14:30 <gmaxwell> A ultraprune node _IS_ a full node.
336 2012-08-30 04:14:37 <gmaxwell> And it can bootstrap new ones.
337 2012-08-30 04:14:46 <MC-Eeepc> oh, well thats good
338 2012-08-30 04:15:10 <gmaxwell> It's functionally identical (er, well except for looking up not-yours txn randomly at least right now), just a ton faster.
339 2012-08-30 04:15:33 <MC-Eeepc> ok so how do i put this
340 2012-08-30 04:15:38 <MC-Eeepc> whats the catch?
341 2012-08-30 04:16:26 <gmaxwell> The code is new, largely untested, and almost certantly buggy.
342 2012-08-30 04:17:03 <MC-Eeepc> ok but thats not a huge problem
343 2012-08-30 04:17:20 <gmaxwell> It's also in theory less robust against disk corruption, at least as written now. Although the current code has basically no corruption robustness although it could.
344 2012-08-30 04:17:24 <gmaxwell> It is a huge problem.
345 2012-08-30 04:17:50 <gmaxwell> And ultimately it may prevent ultraprune from actually being available for people for a long time.
346 2012-08-30 04:17:57 <MC-Eeepc> ok its not a small problem but its fixable eventually
347 2012-08-30 04:19:36 <MC-Eeepc> i mean whats the catch in terms of the bitcoin network itself, how it operates etc. Does it reduce decentralisation in some way
348 2012-08-30 04:19:44 <gmaxwell> Well everything is fixable. But bugs in chain handling have enormous risk to the network. It probably can not be adopted without more rigorous testing than we've had for anything else, and even then it will be risky: because _fixing_ chain handling bugs has risks too; so the fact that it fixes something the old code got wrong may burn us.
349 2012-08-30 04:20:24 <Joric> that major announcement in september is it still secret?
350 2012-08-30 04:20:26 <gmaxwell> MC-Eeepc: Do you get the impression that I'd be advocating anything that reduces decentralization?
351 2012-08-30 04:20:58 <gmaxwell> (esp after I've driven TD and justmoon absolutely nuts in here by dogmatically arguing against any behavior that hurts decentralization...)
352 2012-08-30 04:21:01 <MC-Eeepc> well no, but there is much talk of compromises and stuff
353 2012-08-30 04:21:27 <MC-Eeepc> if it doesnt then thats great
354 2012-08-30 04:21:36 <Luke-Jr> MC-Eeepc: the end goal is to have nodes that work before being complete, but still eventually complete
355 2012-08-30 04:22:14 <MC-Eeepc> ok
356 2012-08-30 04:22:29 <MC-Eeepc> wouldnt that impinge somewhat on the zero trust model?
357 2012-08-30 04:23:09 <Luke-Jr> temporarily
358 2012-08-30 04:23:45 <Luke-Jr> besides, you can never have *complete* zero trust in that sense: if you reject the accepted history, nobody will do business with you who does
359 2012-08-30 04:24:09 <MC-Eeepc> ah theres the catch
360 2012-08-30 04:24:15 <MC-Eeepc> but it dosnt sound too bad
361 2012-08-30 04:24:28 <Luke-Jr> so eventually, no matter what anyone does, you *have* to trust that the ancient history of the blockchain is legit
362 2012-08-30 04:24:35 <gmaxwell> MC-Eeepc: what are you talking about?
363 2012-08-30 04:24:39 <Luke-Jr> because to not do so, means you're not using the same Bitcoin as everyone else
364 2012-08-30 04:25:10 <Luke-Jr> MC-Eeepc: that's the case today, even if you can prove the ancient history took place a certain way
365 2012-08-30 04:25:17 <Luke-Jr> you still don't have a real choice but to accept it
366 2012-08-30 04:25:25 <gmaxwell> MC-Eeepc: what luke is talking about has nothing to do with ultraprune.
367 2012-08-30 04:25:52 <Luke-Jr> gmaxwell: I suspect ultraprune wasn't really ever the topic :p
368 2012-08-30 04:26:09 <MC-Eeepc> um yes it was
369 2012-08-30 04:26:55 <gmaxwell> MC-Eeepc: well half of what you're saying has nothing to do with it. There is no "talk of compromises" with ultraprune.
370 2012-08-30 04:28:24 <Luke-Jr> nor any significant disk space reduction
371 2012-08-30 04:29:05 <gmaxwell> Luke-Jr: the the index is enormously smaller.
372 2012-08-30 04:29:23 <Luke-Jr> gmaxwell: now you're confusing me too :P
373 2012-08-30 04:29:27 <gmaxwell> The blocks could be smaller too, if it compressed them, but for right now people wanted binary compatiblity of the blockfiles 'meh'.
374 2012-08-30 04:30:54 <MC-Eeepc> so ultraprune doesnt reduce disk space usage that much?
375 2012-08-30 04:31:40 <Luke-Jr> MC-Eeepc: if you mean blk000n.dat files, not as-is today; if you mean blkindex.dat, somewhat.
376 2012-08-30 04:31:58 <gmaxwell> It makes the about a 100 megs instead of a gig.
377 2012-08-30 04:32:03 <gmaxwell> er the index.
378 2012-08-30 04:32:46 <gmaxwell> and it makes the software enormously faster because that 100 megs is all it needs to access in normal operation.
379 2012-08-30 04:32:54 <Joric> i badly want index by addresses... just in case
380 2012-08-30 04:33:03 <gmaxwell> (the blk files are only used for reorgs and for feeding peers)
381 2012-08-30 04:33:14 <Luke-Jr> Joric: just in case of ??? what? O.o
382 2012-08-30 04:34:05 <Joric> for graphs )
383 2012-08-30 04:34:12 <gmaxwell> well I want that too, to support external wallets mostly. But I'm waiting for etotheipi to port armory to the rpc and say he needs it before I start trying to convince everyone else that its worth the space.
384 2012-08-30 04:34:21 <gmaxwell> Joric: dumb reason for a default behavior.
385 2012-08-30 04:34:26 <MC-Eeepc> well, the main purpose of the blk files it to keep everyone else honest and with no power to take over the netowrk is it not
386 2012-08-30 04:35:03 <gmaxwell> MC-Eeepc: the purpose of the blk files is to store the blocks. geesh.
387 2012-08-30 04:35:08 <Luke-Jr> LOL
388 2012-08-30 04:36:34 <gmaxwell> ulra prune just makes is so that the regular operations isn't constantly accessing them or constantly accessing a huge index... this decreases the working set size, so everything ends up cached and its very fast.
389 2012-08-30 04:40:06 <MC-Eeepc> The working set can be cached in ram then?
390 2012-08-30 04:42:33 <MC-Eeepc> and initial sync from blk 0 times will be much reduced right?
391 2012-08-30 04:42:41 <osmosis> does the  USE_QRCODE  compile flag apply to bitcoind?
392 2012-08-30 04:55:09 <Luke-Jr> osmosis: bitcoind doesn't use qr codes
393 2012-08-30 04:56:25 <osmosis> Luke-Jr, correct...ive updated build-unix.txt accordingly  https://github.com/bitcoin/bitcoin/pull/1755
394 2012-08-30 05:31:29 <libcoin> Strange Transaction: bd1715f1abfdc62bea3f605bdb461b3ba1f2cca6ec0d73a18a548b7717ca8531 in block 196294
395 2012-08-30 05:31:52 <libcoin> scriptPubKey: OP_HASH160 ce5e5d5792ff236e8b6bc52e1702b6906ba459dd OP_EQUAL
396 2012-08-30 05:32:00 <libcoin> scriptSig: OP_FALSE
397 2012-08-30 05:32:21 <libcoin> so Hash160(0x00) == ce5e5d5792ff236e8b6bc52e1702b6906ba459dd
398 2012-08-30 05:32:46 <libcoin> Problem is that I cannot get it to evaluate to this ...
399 2012-08-30 05:33:15 <libcoin> Seems like there is something fishy in the Solver script
400 2012-08-30 05:33:18 <libcoin> Thoughts ?
401 2012-08-30 06:12:51 <libcoin> Sorry - Hash160(vector_of_size_0)  -  but it still does not evaluate correctly
402 2012-08-30 06:36:32 <sipa> libcoin: doesnt OP_FALSE push the empty byte sequence?
403 2012-08-30 06:40:23 <libcoin> sipa: yes
404 2012-08-30 06:40:35 <libcoin> vector_of_size_0 as I corrected it to
405 2012-08-30 06:40:48 <libcoin> but still it does not evaluate to ce5e5d5792ff236e8b6bc52e1702b6906ba459dd
406 2012-08-30 06:41:04 <libcoin> but b472a266d0bd89c13706a4132ccfb16f7c3b9fcb
407 2012-08-30 06:41:46 <libcoin> and my libcoin daemon hangs on block 196294 due to a verifysignature
408 2012-08-30 06:42:37 <libcoin> as I see it from blockchain.info: http://blockchain.info/tx-index/18479989/bd1715f1abfdc62bea3f605bdb461b3ba1f2cca6ec0d73a18a548b7717ca8531
409 2012-08-30 06:42:59 <libcoin> it should indeed not verify
410 2012-08-30 06:46:15 <libcoin> (beginning to think it is the output from blockchain that is buggy...)
411 2012-08-30 06:46:59 <sipa> that is certainly possible
412 2012-08-30 06:47:27 <sipa> i'll have a look later today
413 2012-08-30 06:47:41 <TD> hey
414 2012-08-30 06:48:38 <libcoin> sipa: thanks
415 2012-08-30 07:09:35 <sipa> gmaxwell: i should really change ultraprune's name; for some odd reason everyone seems to think that it prunes!
416 2012-08-30 07:12:27 <sipa> MC-Eeepc: please try it, it should be significanly faster yes
417 2012-08-30 07:14:01 <sipa> gmaxwell: not entirely far to compare ultraprune's disk usage by comparing chain.dat + coins.dat to blkindex.dat; you also need the undo data from blocks
418 2012-08-30 07:18:48 <MC-Eeepc> i would like to try it
419 2012-08-30 07:19:15 <MC-Eeepc> waiting on a windows build
420 2012-08-30 07:22:32 <sipa> if you follow the link posted by bluematt's build tester on the pull request, you should find a .exe
421 2012-08-30 07:23:19 <sipa> otherwise i can do you a deterministic build with gpg signed checksums (like official releases)
422 2012-08-30 07:26:39 <libcoin> sipa: debugging so far: blockchain.info buggy - signature is not OP_FALSE - debugging continues...
423 2012-08-30 07:27:26 <sipa> libcoin: bitcoind 0.7 has a getrawtransaction
424 2012-08-30 07:27:45 <sipa> libcoin: shouldn't be hard to get the real txin that way
425 2012-08-30 07:29:23 <sipa> gmaxwell: undo data plus chain.dat plus coins.dat is already 450 MB or so
426 2012-08-30 07:37:16 <MC-Eeepc> i have no idea what you said sipa
427 2012-08-30 07:46:14 <ErnestoJuarell> Was that new wallet breaking format before 8/2011?
428 2012-08-30 07:48:10 <ErnestoJuarell> I guess testnet doesn't require a new wallet like the real client?
429 2012-08-30 07:50:51 <TD> sipa: i'm running two nodes now on two different machines, one ultraprune and one leveldb
430 2012-08-30 07:51:35 <TD> oh, i patched ultraprune to give the tx/sec rate in ProcessBlock. receiving single blocks doesn't seem much different in speed, oddly, but leveldb was really slow to sync the last part of the chain
431 2012-08-30 07:51:54 <TD> 
ACTION should have added more instrumentation

432 2012-08-30 07:53:04 <sipa> TD: with sig checking disabled or not?
433 2012-08-30 07:53:22 <TD> nope, not disabled. it's just regular copies of the branches, downloading from the network
434 2012-08-30 07:53:33 <TD> the rate calculated in ProcessBlock is obviously not inclusive of network time
435 2012-08-30 07:53:39 <TD> it's a per block rate
436 2012-08-30 08:09:19 <libcoin> sipa: fixed - had left a check for transactions bigger than 200 in IsPushOnly and was now hit by that :/
437 2012-08-30 08:09:43 <sipa> libcoin: i c
438 2012-08-30 08:11:12 <libcoin> but there was indeed a bug in blockchain.info showing a multisig signature as OP_FALSE
439 2012-08-30 08:14:46 <sipa> TD: i noticed that at the end of the chain, the messages about committing changed transactions to the database tended to take longer than actually processing the blocks
440 2012-08-30 08:34:29 <eennaam> i can only ask if nobody is here?
441 2012-08-30 08:35:04 <Joric> no meta-asking
442 2012-08-30 08:35:21 <eennaam> ah , i read it wrong
443 2012-08-30 08:43:30 <quellhorst> does anyone know of code that i can use to check when a transfer has completed?
444 2012-08-30 08:43:35 <quellhorst> like i want to make a website where i take bitcoin payments and activate accounts once payment is recvd
445 2012-08-30 08:44:39 <sipa> quellhorst: listtransactions RPC with a specificied minimum number of confirmations?
446 2012-08-30 08:45:10 <quellhorst> sipa: ok, then what about making a new unique address for people to send the deposit to?
447 2012-08-30 08:45:19 <sipa> of course
448 2012-08-30 08:45:37 <sipa> otherwise you won't know which transaction corresponds to which payment
449 2012-08-30 08:45:52 <quellhorst> is it possible to do this from a system that doesn't have the wallet?
450 2012-08-30 08:45:59 <quellhorst> for security
451 2012-08-30 08:46:03 <ErnestoJuarell> yes
452 2012-08-30 08:46:07 <sipa> you can encrypt the wallet
453 2012-08-30 08:46:19 <sipa> and not bring the passphrase to the systen that checks for incoming payment
454 2012-08-30 08:46:23 <quellhorst> didn't know that was wallet encryption now
455 2012-08-30 08:46:33 <ErnestoJuarell> the site can run on a web server while the wallet is on another server (or even ur home computer)
456 2012-08-30 08:46:42 <quellhorst> ErnestoJuarell: that is what i was thinking
457 2012-08-30 08:47:00 <sipa> don't do that
458 2012-08-30 08:47:09 <quellhorst> so i just need to run bitcoind and send rpc to it?
459 2012-08-30 08:47:11 <quellhorst> sipa: why?
460 2012-08-30 08:47:26 <sipa> because that means an attacker which gets access to your web server, gets access to your wallet
461 2012-08-30 08:47:39 <quellhorst> how so?
462 2012-08-30 08:47:43 <quellhorst> if the wallet isn't even on the server
463 2012-08-30 08:47:51 <ErnestoJuarell> They can get the rpc login
464 2012-08-30 08:47:54 <sipa> as the webserver gets RPC access to the node with the wallet
465 2012-08-30 08:48:01 <sipa> they can use it to send money too
466 2012-08-30 08:48:08 <sipa> of course you can filter the RPC connection
467 2012-08-30 08:48:12 <sipa> that's one viable way
468 2012-08-30 08:48:19 <quellhorst> ok, so back to my first question
469 2012-08-30 08:48:26 <sipa> but imho it's easier to copy the wallet without passphrase to the server
470 2012-08-30 08:48:32 <sipa> as that is perfectly safe
471 2012-08-30 08:48:35 <quellhorst> how do i check without a wallet on the server that i have the right number of confirmations?
472 2012-08-30 08:48:41 <ErnestoJuarell> use rpc
473 2012-08-30 08:48:49 <sipa> don't use RPC, unless you filter it
474 2012-08-30 08:49:00 <quellhorst> right, so rpc to a different bitcoind than has my wallet?
475 2012-08-30 08:49:00 <sturles> df
476 2012-08-30 08:49:03 <sturles> Bah.
477 2012-08-30 08:49:07 <sipa> you put the wallet on the web server, but don't ever transfer the passphrase to the webserver
478 2012-08-30 08:49:12 <sipa> so it cannot ever send money
479 2012-08-30 08:49:18 <sipa> but it can observe incoming transactions
480 2012-08-30 08:49:30 <quellhorst> but if they get the wallet.dat they could try to brute force it?
481 2012-08-30 08:49:34 <sipa> yes
482 2012-08-30 08:49:41 <sipa> so use a strong randomly-generated passphrase
483 2012-08-30 08:50:07 <sipa> if it has 256 bits of entropy, it's as good as the encryption algorithm itself
484 2012-08-30 08:50:10 <quellhorst> i don't see why you can't check confirmations on transactions without even having a wallet
485 2012-08-30 08:50:18 <quellhorst> they blockchain and confirmations are public
486 2012-08-30 08:50:25 <ErnestoJuarell> you could modify bitcoind as well to increase safety
487 2012-08-30 08:50:27 <sipa> you HAVE the wallet
488 2012-08-30 08:50:40 <quellhorst> should also be able to make a big list of addresses for deposits and store those
489 2012-08-30 08:50:47 <sipa> yup
490 2012-08-30 08:51:01 <sipa> we don't have support for watch-only addresses yet, unfortunately
491 2012-08-30 08:51:10 <quellhorst> so then... that would be much more secure
492 2012-08-30 08:51:17 <quellhorst> no wallet.dat to get on the server to crack
493 2012-08-30 08:51:51 <sipa> well wallet.dat is addresses+keys+transactions
494 2012-08-30 08:52:00 <sipa> you want the addresses+transactions part, without the key
495 2012-08-30 08:52:11 <sipa> but the keys are encrypted, in an encrypted wallet
496 2012-08-30 08:52:19 <sipa> so without the decryption key, it's equivalent
497 2012-08-30 08:52:22 <ErnestoJuarell> https://en.bitcoin.it/wiki/Lazy_API
498 2012-08-30 08:52:27 <ErnestoJuarell> No wallet needed?
499 2012-08-30 08:52:39 <ErnestoJuarell> uses blockexplorer
500 2012-08-30 08:52:58 <sipa> do you want to rely on BBE for checkinging incoming payments?
501 2012-08-30 08:53:07 <quellhorst> it isn't about being lazy, it is about being safe
502 2012-08-30 08:53:10 <sipa> what if they are down, or when they lie to you?
503 2012-08-30 08:53:12 <quellhorst> no, i can't trust that
504 2012-08-30 08:53:27 <quellhorst> i'd rather setup my own block explorer type webservice
505 2012-08-30 08:54:09 <ErnestoJuarell> just do the secure wallet way.
506 2012-08-30 08:54:24 <ErnestoJuarell> Because of all the features u get with interacting with the wallet
507 2012-08-30 08:54:44 <quellhorst> thanks for the suggestion
508 2012-08-30 08:55:02 <quellhorst> maybe 2 wallets
509 2012-08-30 08:55:14 <quellhorst> hot and cold storage
510 2012-08-30 08:55:32 <quellhorst> hot wallet would have max BTC and transfer to the cold one
511 2012-08-30 08:55:42 <quellhorst> both with encryption
512 2012-08-30 08:57:25 <ErnestoJuarell> u could also make ur own limited RPC like service
513 2012-08-30 08:57:54 <sipa> yes, filtering the RPC connection is also possible
514 2012-08-30 08:57:58 <sipa> there are tools for that, afaik
515 2012-08-30 08:58:24 <ErnestoJuarell> pre-generate a bunch of deposit addresses offline. The site has that list and will show 1 to the user.
516 2012-08-30 08:58:54 <ErnestoJuarell> then informs wallet via and waits for a confirmation count response.
517 2012-08-30 09:03:42 <Joric> if only bitcoind supported callbacks...
518 2012-08-30 10:38:13 <gmaxwell> 02:48 < ErnestoJuarell> I guess testnet doesn't require a new wallet like the real client?
519 2012-08-30 10:38:32 <gmaxwell> er, the mainnet doesn't require a new wallet either.
520 2012-08-30 10:38:42 <ErnestoJuarell> Why not tho? Isn't it the same client with a diff chain?
521 2012-08-30 10:38:49 <gmaxwell> So I'm not sure what you're asking about.
522 2012-08-30 10:38:54 <ErnestoJuarell> I thought it did. It forced migration
523 2012-08-30 10:39:08 <ErnestoJuarell> Had to make a new 1 to support the passphrase
524 2012-08-30 10:39:50 <gmaxwell> Mirgration ??? yes, if you're using encryption it rebuilds the wallet in order to correct the leaked private key bug.
525 2012-08-30 10:40:07 <gmaxwell> but thats just to get leaked private keys out of the wallet.
526 2012-08-30 10:41:37 <gmaxwell> (and testnet and mainnet are no different in their wallet handling)
527 2012-08-30 11:34:24 <JFK911> how did we leak private keys
528 2012-08-30 11:34:35 <gmaxwell> huh?
529 2012-08-30 11:35:00 <JFK911> 16:39 <@gmaxwell>  ....to correct the leaked private key bug.
530 2012-08-30 11:35:41 <gmaxwell> JFK911: because bdb doesn't actually delete records when you delete them. So if you encrypted a preexisting wallet (some of) the unencrypted keys could remain in the file.
531 2012-08-30 11:35:54 <JFK911> Oh okay.
532 2012-08-30 11:36:09 <JFK911> I was almost angry that private keys were once available via network connections and I didn't get any.
533 2012-08-30 11:36:22 <gmaxwell> ...
534 2012-08-30 11:44:29 <sipa> ?
535 2012-08-30 11:56:03 <gmaxwell> sipa: Almost??? https://people.xiph.org/~greg/bitcoin_coverage/coverage3/coverage/home/gmaxwell/src/bcm/bax/src/script.cpp.gcov.html  see line 289/291.
536 2012-08-30 11:56:36 <gmaxwell> (also the pubkey failures are untested)
537 2012-08-30 11:57:30 <sipa> hmm, strange
538 2012-08-30 11:57:48 <gmaxwell> Is the case you intended to hit that really failing at the initial length perhaps?
539 2012-08-30 11:58:23 <gmaxwell> oh look at the failure counts.
540 2012-08-30 11:58:57 <sipa> 9 times too short...?
541 2012-08-30 11:59:04 <sipa> eh, 5 times
542 2012-08-30 11:59:17 <sipa> and 1 S misplaced
543 2012-08-30 11:59:45 <sipa> i should weaken that S len misplaced test just to make sure the later one gets tested :)
544 2012-08-30 12:01:31 <helo> 
ACTION is disappointed that he deleted his blocks trying to get around 0.7rc1 'DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery'

545 2012-08-30 12:02:27 <gmaxwell> helo: deleted? :( you could have used loadblock to recover, at a minimum. Although, how'd you end up in that state? Did you cleanly shut down before upgrading?
546 2012-08-30 12:03:06 <helo> i closed the old bitcoin-qt, and then waited until the process was gone, did a 'sync', and then started 0.7rc1
547 2012-08-30 12:03:21 <sipa> did you build either yourself?
548 2012-08-30 12:03:25 <helo> nope
549 2012-08-30 12:03:32 <sipa> what OS?
550 2012-08-30 12:03:40 <helo> i have a backup of my ~/.bitcoin i can retrieve
551 2012-08-30 12:03:58 <helo> ubuntu 12.04
552 2012-08-30 12:04:28 <sipa> you may need to use -detachdb before upgrading
553 2012-08-30 12:04:31 <sipa> god i hate BDB
554 2012-08-30 12:04:36 <helo> yeah, apparently
555 2012-08-30 12:05:20 <gmaxwell> it would be quite helpful to know if this is reproducable, and for the sake of getting you going??? on the copy with the deleted blockchain, if you totally delete the chain and index then ./bitcoin(-qt) -loadblock=/path/to/good/blk000.dat  it will rapidly import the chain.
556 2012-08-30 12:05:53 <helo> it will be unfun for people using apt to learn they should have ran -detachdb before upgrading
557 2012-08-30 12:06:03 <sipa> indeed
558 2012-08-30 12:06:05 <helo> let me grab the backup
559 2012-08-30 12:06:26 <kinlo> isn't there an pre-install script
560 2012-08-30 12:06:26 <sipa> even if ultraprune doesn't get into the next release, i really want to get rid of BDB
561 2012-08-30 12:06:42 <kinlo> apt-packages should use the pre-install script to detach
562 2012-08-30 12:06:48 <sipa> kinlo: nope
563 2012-08-30 12:06:53 <sipa> as the database is stored in user data
564 2012-08-30 12:06:59 <sipa> not in a system location
565 2012-08-30 12:07:12 <kinlo> mmmz, true, which marks the 2nd problem
566 2012-08-30 12:07:22 <kinlo> not every user should have their own copy of the blockchain
567 2012-08-30 12:07:26 <sipa> indeed
568 2012-08-30 12:07:38 <kinlo> something setgroupid and a shared location
569 2012-08-30 12:07:45 <sipa> ideally, blockchain/node service running system-wide
570 2012-08-30 12:07:47 <kinlo> I know, it sounds scary :p
571 2012-08-30 12:07:53 <sipa> and wallet services connecting to it
572 2012-08-30 12:08:10 <gmaxwell> sipa: I'm wondering if we shouldn't perhaps do a release cycle which is advertised 'for clients only, not miners or services' which has leveldb+ultraprune; ... chain corruption risk is not that big a deal for end clients.
573 2012-08-30 12:08:39 <kinlo> the ultraprune - besides making your client unable to bootstrap other clients - what will be the disk savings?
574 2012-08-30 12:08:41 <sipa> gmaxwell: i wouldn't mind doing that
575 2012-08-30 12:08:51 <sipa> kinlo: a few hundred MB at least
576 2012-08-30 12:09:06 <sipa> kinlo: after actual pruning is implemented... a lot
577 2012-08-30 12:09:08 <gmaxwell> kinlo: ultraprune does not making your client unable to bootstrap other clients.
578 2012-08-30 12:09:25 <kinlo> oh, the ultrapruning is just to prune indexes?
579 2012-08-30 12:09:33 <sipa> not really
580 2012-08-30 12:09:51 <gmaxwell> it replaces the index with something which is always pruned and which is by itself sufficient to validate blocks.
581 2012-08-30 12:10:12 <gmaxwell> (but not reord or serve old blocks; but it keeps blocks and undo logs which allow these things)
582 2012-08-30 12:10:12 <sipa> it still needs full blocks, but only for serving/rescanning/reorganising
583 2012-08-30 12:10:16 <kinlo> I'd like to see pruning implemented by just deleting all blocks that are older then 1KK blocks, much easier
584 2012-08-30 12:10:27 <sipa> kinlo: that's exactly what ultraprune supports
585 2012-08-30 12:10:43 <kinlo> but that would radically change the way bitcoin works
586 2012-08-30 12:10:44 <gmaxwell> Except for the whole absolutely no network support for that yet.
587 2012-08-30 12:11:34 <sipa> gmaxwell: how do you mean?
588 2012-08-30 12:11:36 <gmaxwell> in any case, I don't think disk storage is the major concern right now; almost everyone who has complained about it has either done so in the context of sync times, or because they're trying to put the chain on a truecrypt volume or usb stick.
589 2012-08-30 12:11:47 <kinlo> sipa: so you would also delete valid unspended transactions? or was my "just delete all blocks older then" not clear?
590 2012-08-30 12:12:02 <gmaxwell> sipa: I mean if you take ultraprunt and delete old blocks, and do this on many nodes you'll break everything.
591 2012-08-30 12:12:14 <sipa> kinlo: ultraprune effectively stores unspent txouts twice
592 2012-08-30 12:12:28 <sipa> kinlo: once in the blocks it keeps, and once in the txout database
593 2012-08-30 12:12:32 <kinlo> oic
594 2012-08-30 12:12:41 <kinlo> well, I was talking about just deleting all of it
595 2012-08-30 12:12:53 <kinlo> transactions not spent in 10 years will probably never be spent at all
596 2012-08-30 12:13:02 <sipa> i might add that the txout set database is 88 Mib right now
597 2012-08-30 12:13:10 <kinlo> it is?
598 2012-08-30 12:13:24 <kinlo> only 88Mib for all unspent transactions?
599 2012-08-30 12:13:26 <sipa> in BDB format is it's twice that, but it contains 88 MB of useful data
600 2012-08-30 12:13:34 <sipa> yes
601 2012-08-30 12:13:43 <kinlo> hmmmz, a lot less then I was expecting
602 2012-08-30 12:13:59 <sipa> in a custom specifically-designed-to-be-compact format
603 2012-08-30 12:14:31 <kinlo> hmmmz, every database format is not going to be compact, if one spends a transaction, there will be a gap
604 2012-08-30 12:14:51 <kinlo> and unless you re-write the file, or have a new transaction that exactly fills the gap...
605 2012-08-30 12:14:56 <sipa> yes but the database takes care of that
606 2012-08-30 12:15:25 <kinlo> you'll need to rewrite stuff then
607 2012-08-30 12:15:29 <sipa> yes but the database takes care of that
608 2012-08-30 12:15:40 <kinlo> you said custom-format :)
609 2012-08-30 12:15:49 <sipa> the data in the database is custom
610 2012-08-30 12:15:58 <kinlo> ic
611 2012-08-30 12:16:08 <kinlo> did you guys choose a database already?
612 2012-08-30 12:16:22 <kinlo> I've seen some discussion about the google bigtables and so on
613 2012-08-30 12:17:30 <gmaxwell> kinlo: leveldb unless it turns out to not work out.
614 2012-08-30 12:18:42 <gmaxwell> We have patches implementing leveldb now, from TD, but ultraprune is not yet integrated with that.
615 2012-08-30 12:18:42 <kinlo> ic
616 2012-08-30 12:20:11 <TD> sipa is rebasing leveldb on top of ultraprune, i think
617 2012-08-30 12:22:47 <t7> ultraprune; immediate relief from constipation
618 2012-08-30 12:24:16 <gmaxwell> I hate it when I titter at sophmoric jokes like that, but 'tehe'.
619 2012-08-30 12:25:57 <helo> boo, my backup is not in a good state :/
620 2012-08-30 12:26:18 <helo> good for me, bad for reproducing my error
621 2012-08-30 12:26:39 <gmaxwell> bad in what way?  you can't change the location of the database unless you first ran with detatch.
622 2012-08-30 12:27:12 <helo> loading up the old client using the backup gives "Db::get: DB_PAGE_NOTFOUND: Requested page not found", and then terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::lock_error> >'
623 2012-08-30 12:28:13 <gmaxwell> helo: are you trying to load it with the same FS path as it originally had?
624 2012-08-30 12:28:52 <helo> yes. i think the problem is that the backup was made while bitcoin-qt was running
625 2012-08-30 12:35:02 <gmaxwell> oh. yea, can't do that.
626 2012-08-30 12:37:32 <helo> i should probably quit bitcoin-qt before i leave for the weekend, so it won't be running when my unattended backup runs
627 2012-08-30 12:38:26 <helo> but i like to think i'm helping the network a little by leaving it up all the time
628 2012-08-30 12:41:11 <gmaxwell> helo: you probably are. Perhaps make your backup script shut it down?
629 2012-08-30 12:45:58 <helo> not a bad idea
630 2012-08-30 12:53:53 <Cryo> Diablo-D3, is there a way that -g would also apply to the retry delay if a server drops connection?  I'm getting 5 per second reconnect attempts which is probably blacklisting me
631 2012-08-30 13:09:32 <Diablo-D3> Cryo: the server shouldnt drop a connection
632 2012-08-30 13:09:44 <Cryo> it's down :)
633 2012-08-30 13:09:52 <Diablo-D3> and this is also the behavior every other miner uses
634 2012-08-30 13:09:56 <Diablo-D3> also, setup a backup pool
635 2012-08-30 13:10:03 <Diablo-D3> theres zero reason why you dont have one
636 2012-08-30 13:10:24 <sipa> helo: or use the backupwallet RPC
637 2012-08-30 13:13:33 <Cryo> yeh, just that 5x/s * huge number of clients makes socket build/destroy on a server sad, just because the miner port is disconnecting
638 2012-08-30 13:14:49 <Cryo> I get not wasting cycles on the client part, just seems rude doing a ddos-like hammer.
639 2012-08-30 13:17:21 <Diablo-D3> Cryo: well thats the problem
640 2012-08-30 13:17:24 <Diablo-D3> if the pool is down
641 2012-08-30 13:17:28 <Diablo-D3> then no connection is actually made
642 2012-08-30 13:17:37 <Diablo-D3> and you must have several gpus to do 5x/s
643 2012-08-30 13:19:18 <Cryo> http://pastebin.com/ZUsdwQXu
644 2012-08-30 13:19:41 <Cryo> try not to laugh too hard at the card. it's sensitive.
645 2012-08-30 13:19:47 <Diablo-D3> thats just 3 a second
646 2012-08-30 13:19:53 <Diablo-D3> thats normal
647 2012-08-30 13:20:48 <Diablo-D3> Cryo: but yes, trying to change the timeout is wrong
648 2012-08-30 13:21:26 <Diablo-D3> what you really need to do is just choose a second pool and set it as your backup
649 2012-08-30 13:22:24 <Diablo-D3> if the server is actually down, then theres no server load you have to worry about
650 2012-08-30 13:22:29 <Diablo-D3> you just have to worry about lost mining
651 2012-08-30 13:24:07 <Cryo> ok.  what is -g for then?
652 2012-08-30 13:24:40 <Diablo-D3> delay between getworks.... but its ignored on any pool that uses longpoll
653 2012-08-30 13:24:50 <Diablo-D3> including mtred
654 2012-08-30 13:25:13 <sipa> MC-Eeepc: see http://bitcoin.sipa.be/builds/ultraprune/0.7.0rc1-25-gef6d9e2/ -> ultraprune builds for windows; warning: use at your own risk; the database format is incompatible, so it will work as if no blockchain was downloaded before, though you can use -loadblock to import the old blk0001.dat file
655 2012-08-30 13:25:23 <Cryo> ok. thanks
656 2012-08-30 13:27:10 <Eliel> sipa: I think I'll test that as well. I'm not using my windows system for bitcoin otherwise :)
657 2012-08-30 13:27:31 <sipa> Eliel: there's a linux build there too, and obviously you can build from source
658 2012-08-30 13:29:03 <Eliel> it's running :)
659 2012-08-30 13:37:38 <keverw> "left the chat room. (*.net *.split)" ??? Everyroom i am in got like 20 of those...
660 2012-08-30 13:40:06 <Eliel> sipa: it's a netsplit, those happen sometimes.
661 2012-08-30 13:40:08 <BlueMatt> just means one of the irc servers on the network split off, they'll rejoin eventually
662 2012-08-30 13:40:13 <Eliel> oops, not sipa, keverw
663 2012-08-30 13:40:46 <keverw> o
664 2012-08-30 13:41:19 <Eliel> first 70k blocks took 12 minutes :)
665 2012-08-30 13:41:39 <gmaxwell> Eliel: er, thats really slow
666 2012-08-30 13:41:47 <gmaxwell> Are you syncing from some random peer?
667 2012-08-30 13:42:01 <Eliel> random peers, yes
668 2012-08-30 13:42:11 <gmaxwell> s/peers/peer/ it only pulls from one.
669 2012-08-30 13:42:14 <gmaxwell> OKAY.
670 2012-08-30 13:42:55 <Eliel> it does advertise 8 connections though.
671 2012-08-30 13:43:10 <gmaxwell> Sure.
672 2012-08-30 13:43:17 <BlueMatt> working on it
673 2012-08-30 13:43:18 <Eliel> only pulls from one of them? can I switch it on the fly?
674 2012-08-30 13:43:32 <BlueMatt> no
675 2012-08-30 13:43:39 <BlueMatt> well, yes and no
676 2012-08-30 13:43:52 <BlueMatt> only one; cant switch
677 2012-08-30 13:43:54 <gmaxwell> Eliel: it only pulls from one. No, you can't switch. (and if that one goes away it will stop completely until it gets triggered by the next block)
678 2012-08-30 13:44:08 <Eliel> it seems to be accelerating :P
679 2012-08-30 13:44:20 <Eliel> 100k blocks done now
680 2012-08-30 13:51:58 <Eliel> sipa: I closed it while it was syncing and it crashed on shutdown.
681 2012-08-30 13:54:29 <gmaxwell> hm. crap. I might have seen a crash on shutdown in rc1 while I was chasing the plussed port problem, and ignored it due to tunnel vision on the issue I was chasing.
682 2012-08-30 13:54:48 <Eliel> well, I saved the debug.log from the run
683 2012-08-30 13:55:20 <Eliel> EnvShutdown exception: DbEnv::close: Invalid Argument (22)
684 2012-08-30 13:55:40 <Eliel> (this is a build from sipa's link)
685 2012-08-30 13:57:33 <gmaxwell> okay that sounds like it would be something new.
686 2012-08-30 13:59:58 <Eliel> ok, it happened again. Same error, this time with fresh db (I wiped it before restart) and no blocks downloaded (I think I typoed the -connect parameter)
687 2012-08-30 14:01:16 <Eliel> ok, restarted from a node on my LAN now.
688 2012-08-30 14:01:23 <Eliel> going to time this :)
689 2012-08-30 14:02:05 <Eliel> by the way, is 0.7 going to get ultraprune or is this just testing everything works out with other 0.7 changes?
690 2012-08-30 14:10:59 <Eliel> doesn't seem noticeably faster even from a local node.
691 2012-08-30 14:11:14 <Eliel> for the first 70k blocks that is
692 2012-08-30 14:11:38 <Eliel> well, ok, 3 minutes faster
693 2012-08-30 14:40:03 <sipa> Eliel: hmm, that shouldn't happen
694 2012-08-30 14:42:25 <sipa> Eliel: a crash is quite possible if you don't have a clean database env before start, though
695 2012-08-30 14:43:30 <Eliel> sipa: the first run was started on top a data dir left behind by 0.6.3 I think.
696 2012-08-30 14:43:40 <Eliel> the second one from an empty directory
697 2012-08-30 14:45:42 <sipa> Eliel: how long did it take for 70k blocks?
698 2012-08-30 14:46:24 <sipa> the first blocks are very cheap, so there's little to be gained compared to network overhead
699 2012-08-30 14:47:28 <sipa> i always test from an empty directory; compatibility/upgrading from the old database scheme is for later
700 2012-08-30 14:47:35 <sipa> though i would have expected it to work
701 2012-08-30 14:49:17 <sipa> Eliel: here it takes 37s to import 70k blocks, so i wouldn't expect any noticable speedup when network downloading already takes minutes
702 2012-08-30 14:50:54 <Eliel> sipa: around 9 minutes downloading them from LAN
703 2012-08-30 14:51:18 <Eliel> this is the windows version on a Win XP system
704 2012-08-30 14:51:54 <MC-Eeepc> thanks sipa
705 2012-08-30 14:52:00 <MC-Eeepc> this should be good
706 2012-08-30 14:54:14 <helo> 
ACTION finds the 0.7 console window :D :D

707 2012-08-30 14:54:31 <helo> very slick Info/Console
708 2012-08-30 15:02:02 <MC-Eeepc> hm ok this isnt as fast as i had envisaged
709 2012-08-30 15:03:04 <MC-Eeepc> oh cool this debug window
710 2012-08-30 15:03:07 <MC-Eeepc> boss
711 2012-08-30 15:04:09 <Eliel> it's been running for an hour now. 165k blocks done
712 2012-08-30 15:06:07 <MC-Eeepc> i think this usb drive is just really ahit for running bitcoin off and theres no getting around that
713 2012-08-30 15:06:40 <MC-Eeepc> is coins.dat the new index
714 2012-08-30 15:07:43 <Eliel> kind of
715 2012-08-30 15:09:16 <Diapolo> Can someone give me a working Bitcoin Proxy address for testing something?
716 2012-08-30 15:10:22 <Diapolo> jgarzik: have you a working BC proxy address by hand I could use for some tests?
717 2012-08-30 15:11:22 <sipa> MC-Eeepc: except that it's not an index, but the actual data
718 2012-08-30 15:11:41 <sipa> MC-Eeepc: chain.dat is the index for the block chain files, but it contains much less than blkindex.dat did
719 2012-08-30 15:14:07 <MC-Eeepc> ok lets try it with the ssd
720 2012-08-30 15:15:46 <Diapolo> found one
721 2012-08-30 15:17:16 <MC-Eeepc> so whats this new blk00.dat and rev.dat
722 2012-08-30 15:17:40 <jgarzik> Diapolo: I have no idea what you're talking about :)
723 2012-08-30 15:18:20 <Diapolo> jgarzik: I was seeking a proxy server for testing bitcoin-qt via proxy
724 2012-08-30 15:18:30 <sipa> Diapolo: tor, for example?
725 2012-08-30 15:18:56 <sipa> MC-Eeepc: blk*.dat contains the blocks, rev*.dat contains undo data for the corresponding blocks
726 2012-08-30 15:19:21 <Diapolo> sipa: any IPv4 SOCKS Proxy, which is known to work with bitcoin
727 2012-08-30 15:19:35 <gmaxwell> Diapolo: install tor. :) You should do that anyways.
728 2012-08-30 15:19:35 <weex> undo data?
729 2012-08-30 15:19:36 <jgarzik> Diapolo: I never mess around with proxies.  I'm too impatient for their slowness.
730 2012-08-30 15:19:49 <weex> there is no undo in btc
731 2012-08-30 15:19:54 <sipa> weex: sure there is
732 2012-08-30 15:20:06 <MC-Eeepc> so what is chain.dat
733 2012-08-30 15:20:23 <weex> ctrl-z?
734 2012-08-30 15:20:36 <Diapolo> gmaxwell: I just need a working one for doing some tests ^^. But for privacy of course Tor is the way to got, but for now thats overkill.
735 2012-08-30 15:21:21 <gmaxwell> Diapolo: you'll need tor to test the seperate tor proxy field in any case.
736 2012-08-30 15:21:41 <Diapolo> gmaxwell: indeed but that tests are way before Tor tests :)
737 2012-08-30 15:22:01 <sipa> weex: in case of reorganisation, we need to undo the effects of a block on the database state
738 2012-08-30 15:22:05 <gmaxwell> Diapolo: generally open socks proxies are hard to find because they get abused. :)
739 2012-08-30 15:22:36 <Diapolo> gmaxwell: too bad ^^ do you know how hard it is to setup Tor in the Windows world?
740 2012-08-30 15:22:37 <sipa> weex: blkindex.dat had enough data to be able to revert by itself, but coins.dat in ultraprune doesn't
741 2012-08-30 15:22:58 <sipa> MC-Eeepc: chain.dat is the block chain index
742 2012-08-30 15:23:10 <weex> oh ok, one more thing to learn a bit about
743 2012-08-30 15:23:59 <weex> as long as wallet.dat being the only file needed to be backed up to prevent coin loss is still true
744 2012-08-30 15:24:07 <weex> then that's cool
745 2012-08-30 15:24:30 <sipa> sure
746 2012-08-30 15:25:35 <sipa> Diapolo: tor will potentially even be faster than an arbitrary open socks proxy you find on the internet
747 2012-08-30 15:26:38 <weex> bitcoin's speed of development (code and culture) reminds me of an approximation made in plasma physics... electrons move so fast, atoms/ions can be assumed to be static
748 2012-08-30 15:26:40 <jgarzik> sipa: would you say our walletdb involves a lot of -rewriting- BDB records?  or mainly appending new records?
749 2012-08-30 15:26:50 <jgarzik> 
ACTION reviews walletdb.cpp

750 2012-08-30 15:27:32 <sipa> jgarzik: maybe appending
751 2012-08-30 15:27:35 <sipa> *mainly appending
752 2012-08-30 15:28:00 <sipa> only updating the spent bitvector of transactions happens afterwards
753 2012-08-30 15:28:07 <jgarzik> ok
754 2012-08-30 15:28:23 <Diapolo> How long are you core devs participating here?
755 2012-08-30 15:29:26 <sipa> Diapolo: wrote my first patch in februari 2011, joined the dev team in may 2011
756 2012-08-30 15:30:08 <Diapolo> sometimes I have the impression you guys were there, when the BTC laws were set in stone the first time by god ^^
757 2012-08-30 15:30:32 <sipa> TD was around very early
758 2012-08-30 15:30:39 <weex> Diapolo: it's surprising to see how many have come and gone
759 2012-08-30 15:30:57 <TD> the laws of bitcoin just appeared one day and were set in stone on that day
760 2012-08-30 15:31:04 <weex> also early on i think hoarding wasn't considered as much as many detractors now assume
761 2012-08-30 15:31:06 <TD> i happened to find bitcoin by chance a few months after it was released
762 2012-08-30 15:31:23 <TD> but i didn't have any impact on its development back then
763 2012-08-30 15:33:56 <Diapolo> TD: did I got that straight, you are the google guy?
764 2012-08-30 15:34:02 <TD> just a google guy
765 2012-08-30 15:34:02 <weex> from the logs -dev used to be much more of a chatroom, now it's very technical
766 2012-08-30 15:34:06 <TD> there are more than one of us
767 2012-08-30 15:34:42 <Diapolo> ^^ surprising
768 2012-08-30 15:34:55 <gavinandresen> he's being modest, when you type something in to google TD handles it.
769 2012-08-30 15:35:12 <TD> devrandom is also a googler
770 2012-08-30 15:35:15 <Diapolo> that's a nice picture in my mind now
771 2012-08-30 15:35:53 <MC-Eeepc> ddg ftw
772 2012-08-30 15:35:55 <weex> google's dirty little secret: still cpu mining
773 2012-08-30 15:36:16 <Diapolo> weex: but with their whole datacenters ;)?
774 2012-08-30 15:38:18 <jgarzik> 
ACTION found bitcoin thanks to the initial slashdotting in... 2009?  2010?  Jed (of MtGox fame) found it around the same time.

775 2012-08-30 15:38:32 <jgarzik> July of $YEAR
776 2012-08-30 15:39:19 <jgarzik> 
ACTION doesn't think he's heard the "how gavin discovered bitcoin" story

777 2012-08-30 15:39:40 <gavinandresen> Really?  I'll find the link....