1 2013-07-11 00:00:04 <gmaxwell> The_Fly: and if you glitch your wallet and restore from a backup you'll be giving out user A's address to user C.
  2 2013-07-11 00:00:04 <turboroot> The_Fly: i would not use bitcoin's accounts for accounting
  3 2013-07-11 00:00:06 <The_Fly> it behaved as you just described last time i checked
  4 2013-07-11 00:00:22 <gmaxwell> phantomcircuit: it does, but see my comment.
  5 2013-07-11 00:00:27 <phantomcircuit> yeah it does
  6 2013-07-11 00:00:37 <phantomcircuit> gmaxwell, yup that's exactly the issue
  7 2013-07-11 00:00:39 <The_Fly> yeah, so avoiding that case would be good gmaxwell
  8 2013-07-11 00:00:52 <The_Fly> and i was hoping not to need to use bitcoind's for accounting at all
  9 2013-07-11 00:01:02 <gmaxwell> The_Fly: so don't.
 10 2013-07-11 00:01:07 <The_Fly> i wont.
 11 2013-07-11 00:01:52 <phantomcircuit> The_Fly, do as i said, emulate the behavior of the getaccountaddress rpc call but maintain the user -> address mapping in a proper database
 12 2013-07-11 00:02:30 <phantomcircuit> it's really not that hard to do
 13 2013-07-11 00:02:30 <The_Fly> yeah that works fine if i want to avoid dead/useless keys in my wallet
 14 2013-07-11 00:02:42 <The_Fly> i know, the issue is just the rate i can import them
 15 2013-07-11 00:02:48 <phantomcircuit> The_Fly, believe me that is your #1 goal performance wise
 16 2013-07-11 00:02:57 <The_Fly> i do believe you
 17 2013-07-11 00:03:03 <phantomcircuit> The_Fly, import what?
 18 2013-07-11 00:03:03 <The_Fly> i asked about removing keys
 19 2013-07-11 00:03:11 <The_Fly> the coldstorage keys
 20 2013-07-11 00:03:16 <phantomcircuit> why would you be removing keys
 21 2013-07-11 00:03:17 <The_Fly> sorry... just addresses
 22 2013-07-11 00:03:53 <phantomcircuit> i still dont get what the issue is
 23 2013-07-11 00:04:14 <phantomcircuit> you pull a ton of keys into your db with the user -> address mapping and keep the user field NULL
 24 2013-07-11 00:04:14 <The_Fly> that via the rpc call the rate i can import addresses is slow
 25 2013-07-11 00:04:26 <phantomcircuit> then assign addresses to users when they need one from the pool in the db
 26 2013-07-11 00:04:30 <phantomcircuit> without touching rpc
 27 2013-07-11 00:04:34 <The_Fly> ok, so thats the pregeneration solution
 28 2013-07-11 00:04:39 <The_Fly> which i mentioned
 29 2013-07-11 00:04:45 <gmaxwell> The_Fly: again, if you're running into problems where 50 transactions per second is an issue for you, you can afford some hardware where it isn't.
 30 2013-07-11 00:04:45 <The_Fly> and am considering
 31 2013-07-11 00:04:50 <phantomcircuit> your peak load might be 30/second
 32 2013-07-11 00:04:55 <The_Fly> right now i am not running into that issue
 33 2013-07-11 00:05:02 <phantomcircuit> but your sustained average load will me more like 30/hour if you're lucky
 34 2013-07-11 00:05:03 <The_Fly> but with what id like to set up, maybe i could
 35 2013-07-11 00:05:25 <The_Fly> true, very true
 36 2013-07-11 00:05:31 <The_Fly> it's at least good to think about these problems though
 37 2013-07-11 00:05:39 <phantomcircuit> often not really
 38 2013-07-11 00:05:46 <gmaxwell> or you could just run bitcoin with eatmydata or whatever and it'll probably be fast, though any crash will corrupt your wallet.
 39 2013-07-11 00:05:56 <phantomcircuit> if it's actually an issue you'll be able to simply run multiple bitcoind instances
 40 2013-07-11 00:06:09 <gmaxwell> phantomcircuit: well, less not reall when you're just outsourcing the thinking to suckers on IRC. :P
 41 2013-07-11 00:06:24 <phantomcircuit> gmaxwell, shrug
 42 2013-07-11 00:06:31 <phantomcircuit> the hard part is implementing it correctly
 43 2013-07-11 00:06:39 <phantomcircuit> bugs bugs everywhere
 44 2013-07-11 00:06:43 <The_Fly> gmaxwell: oi, im consulting with experts :P
 45 2013-07-11 00:06:56 <The_Fly> yes phantomcircuit multiple instances is another solution, not a nice one
 46 2013-07-11 00:07:01 <The_Fly> and hopefully not necessary for long
 47 2013-07-11 00:07:02 <phantomcircuit> anyways im just sitting here waiting for stuff to compile
 48 2013-07-11 00:07:26 <phantomcircuit> gmaxwell, lol it's 7pm i was about to say "shouldn't you be at work" but no
 49 2013-07-11 00:08:09 <gmaxwell> I am, you note that I've only commented a bit... and mostly to say "didn't I tell you before what your issue is." :P
 50 2013-07-11 00:08:44 <The_Fly> i think if microtransactions are supposed to be a big use-case for bitcoin those kinds of rates should be considered, perhaps not for a single project... but im experimenting with building merchant tools
 51 2013-07-11 00:08:52 <gmaxwell> The_Fly: running multiple daemons is a perfectly reasonable thing to do generally.
 52 2013-07-11 00:09:00 <The_Fly> if you want to scale to an arbitrary number of merchants it may have to scale to 50/sec
 53 2013-07-11 00:09:18 <phantomcircuit> microtransactions on the network just dont work very well
 54 2013-07-11 00:09:26 <The_Fly> ok sure, but even still
 55 2013-07-11 00:09:36 <phantomcircuit> but most people are ok with risking $10 to some third party they dont really trust
 56 2013-07-11 00:10:00 <phantomcircuit> microtransactions dont really require the kind of trust that bitcoin builds at relatively high expense
 57 2013-07-11 00:10:16 <The_Fly> now thing is i was running the rpc calls in serial...
 58 2013-07-11 00:10:41 <gmaxwell> my laptop does 125 getnewaddresses per second over the rpc.
 59 2013-07-11 00:11:11 <phantomcircuit> The_Fly, always run the rpc calls in serial against bitcoind
 60 2013-07-11 00:11:21 <gmaxwell> The_Fly: thats fast enough that I don't consider it a concern. At all. If its something that matters to you, ??? well, we accept patches. Though you're not going to achieve high rates on something with slow IO.
 61 2013-07-11 00:11:40 <sipa> gmaxwell: you should start a bitcoin-server-on-a-laptop selling business
 62 2013-07-11 00:11:59 <pigeons> what's your site The_Fly?
 63 2013-07-11 00:12:02 <gmaxwell> sipa: hah. "10x faster than the cloud!"
 64 2013-07-11 00:12:09 <The_Fly> lol
 65 2013-07-11 00:12:28 <The_Fly> pigeons: it's not complete, as you can see :)
 66 2013-07-11 00:12:33 <sipa> gmaxwell: btw, technically we don't need a sync for every new address
 67 2013-07-11 00:13:00 <phantomcircuit> sipa, is there something that detects whether keypool addresses have been used?
 68 2013-07-11 00:13:02 <sipa> gmaxwell: that can happen in the background after the keypool is topped up afaim
 69 2013-07-11 00:13:07 <gmaxwell> sipa: If we're to have zero risk of double issuing after a crash, though god knows??? I dunno if we even provide that now.
 70 2013-07-11 00:13:33 <gmaxwell> I suppose we could prereserve and just lose those addresses if we crash.
 71 2013-07-11 00:13:37 <sipa> gmaxwell: i doubt we can provide that
 72 2013-07-11 00:13:45 <The_Fly> it seems reasonable
 73 2013-07-11 00:13:46 <sipa> phantomcircuit: not afaik
 74 2013-07-11 00:13:54 <gmaxwell> The_Fly: what seems reasonable?
 75 2013-07-11 00:14:09 <sipa> but for bip32 we'll need that
 76 2013-07-11 00:14:23 <The_Fly> not syncing just address import
 77 2013-07-11 00:14:49 <The_Fly> and getnewaddress
 78 2013-07-11 00:15:11 <gmaxwell> The_Fly: well it means that if bitcoin crashes you may think it has things imported which it doesn't. And it's not obvious that it doesn't. So you'll miss transactions.
 79 2013-07-11 00:15:30 <michagogo> sipa: "afaim"? I think that's a new one for me.
 80 2013-07-11 00:15:34 <michagogo> What does it mean?
 81 2013-07-11 00:15:37 <The_Fly> if it's already gone to the user yes
 82 2013-07-11 00:15:46 <The_Fly> phantomcircuit: yes but running in serial means im waiting for rpc connections to open and close
 83 2013-07-11 00:15:50 <sipa> it's a typo for afaik
 84 2013-07-11 00:15:51 <gmaxwell> The_Fly: likewise for getnewaddress??? you'll give out the same address multiple times. Meaning you'll need an accounting layer on top to filter that out, and if you've done that, the performance should be irrelevant since you could just precompute and have it do the assignment.
 85 2013-07-11 00:15:54 <michagogo> Ah
 86 2013-07-11 00:15:56 <michagogo> lol
 87 2013-07-11 00:16:04 <phantomcircuit> The_Fly, rpc supports keep-alive
 88 2013-07-11 00:16:10 <The_Fly> ah...
 89 2013-07-11 00:16:32 <phantomcircuit> gmaxwell, which is exactly what i suggested he do :)
 90 2013-07-11 00:16:41 <The_Fly> i shall try using a client rather than from bitcoind on the shell
 91 2013-07-11 00:16:42 <phantomcircuit> it's a lot easier to keep something like postgresql consistent
 92 2013-07-11 00:16:48 <gmaxwell> yea, good advice.
 93 2013-07-11 00:17:04 <gmaxwell> well the databases actually have formal support for replication and such, so yea. duh. :P
 94 2013-07-11 00:17:26 <The_Fly> id be fine with keeping addresses in postgres, ive been experimenting with that
 95 2013-07-11 00:17:37 <The_Fly> but had been pulling them out, importing them to bitcoind, then issuing
 96 2013-07-11 00:18:07 <The_Fly> prepopulating a database from getnewaddress is good, that works
 97 2013-07-11 00:19:33 <The_Fly> and i can repeat that with the cold storage addresses also
 98 2013-07-11 00:19:49 <The_Fly> preload them into the wallet
 99 2013-07-11 00:23:30 <The_Fly> unless there's a cost to keeping large numbers of unused keys in the wallet
100 2013-07-11 00:23:43 <phantomcircuit> there is
101 2013-07-11 00:23:45 <The_Fly> (ignoring load times)
102 2013-07-11 00:23:57 <The_Fly> yes, you said
103 2013-07-11 00:25:41 <The_Fly> so, as a way to avoid having to even import or getnewaddress im fine for watching for transactions
104 2013-07-11 00:25:47 <The_Fly> (with walletnotify or zmq)
105 2013-07-11 00:26:51 <The_Fly> but im wondering how i can (on each block) compute the number of transactions. is it the case that i can just walk the chain from the first block the transaction is mined into?
106 2013-07-11 00:27:12 <The_Fly> (instead of RPC gettransaction for each open transaction on each block)
107 2013-07-11 00:29:12 <The_Fly> or am i going to end up in trouble that way?
108 2013-07-11 00:29:22 <The_Fly> with any reorg
109 2013-07-11 00:30:59 <The_Fly> as rare as they are...
110 2013-07-11 00:31:06 <gmaxwell> hm, this is going much more slowly than the last time I tried it... https://people.xiph.org/~greg/2013.06.09.sync.tor.svg
111 2013-07-11 00:31:36 <gmaxwell> The_Fly: reorgs happen every day, they are not rare.
112 2013-07-11 00:32:01 <The_Fly> sorry, forks
113 2013-07-11 00:32:51 <The_Fly> reorgs are happening because some chains grow longer
114 2013-07-11 00:33:07 <gmaxwell> there is always a fork when there is a reorg.
115 2013-07-11 00:33:24 <The_Fly> so transaction #confs can change
116 2013-07-11 00:33:57 <The_Fly> and if im just keeping a list of blocks i see from bitcoind im not sure how to detect that
117 2013-07-11 00:34:08 <The_Fly> there's the schema posted here https://bitcointalk.org/index.php?topic=38246.0
118 2013-07-11 00:34:18 <The_Fly> https://bitcointalk.org/index.php?topic=38246.msg979542#msg979542
119 2013-07-11 00:34:42 <The_Fly> he's just using a view to look at the chain length
120 2013-07-11 00:35:04 <The_Fly> so i guess i can see if a tx is on a block on the longest chain
121 2013-07-11 00:38:23 <nanotube> by the way, people drop by on #multibit more often to ask questions, now that it's the default recommended client. and most of the time nobody's there to answer.
122 2013-07-11 00:38:47 <nanotube> so... anyone who knows a few things about that client is invited to idle on #multibit
123 2013-07-11 00:39:28 <turboroot> nanotube: sorry, I left when you said "knows a few things about that client".
124 2013-07-11 00:39:46 <nanotube> turboroot: lol well, "or is interested in helping out in any capacity" :)
125 2013-07-11 00:39:53 <nanotube> "or learning more about it"
126 2013-07-11 00:40:09 <nanotube> or really just to lurk
127 2013-07-11 00:41:19 <nanotube> just saddens me to see people drop by, ask, then leave when nobody answers...
128 2013-07-11 00:41:40 <da2ce7> yeah, just eveyone who knows anything about multibit, please lurk in #multibit
129 2013-07-11 00:41:43 <The_Fly> they just need to lurk harder
130 2013-07-11 00:41:54 <zw> whats multibit
131 2013-07-11 00:42:05 <The_Fly> https://multibit.org/index.html
132 2013-07-11 00:42:28 <nanotube> zw: it's a bitcoin client, that is now the 'recommended' client for newcomers.
133 2013-07-11 00:42:34 <nanotube> at least on the bitcoin.org website
134 2013-07-11 00:50:28 <[\\\\\\]> holy dust: https://blockchain.info/address/1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T
135 2013-07-11 00:50:42 <michagogo> What was my quit message just now?
136 2013-07-11 00:50:53 <phantomcircuit> ????????? Quits: michagogo (~Michagogo@wikia/Michagogo) (Remote host closed the connection)
137 2013-07-11 00:50:58 <michagogo> [\\\\\\]: Correct horse battery staple?
138 2013-07-11 00:51:34 <[\\\\\\]> I don't know.  I didn't tag it. I merely stumbled upon the address.
139 2013-07-11 00:51:40 <The_Fly> brainwallet
140 2013-07-11 00:52:20 <[\\\\\\]> Fees\t0.01264 BTC
141 2013-07-11 00:52:20 <[\\\\\\]> Total Input\t0.01998 BTC
142 2013-07-11 00:52:20 <[\\\\\\]> Total Output\t0.00734 BTC
143 2013-07-11 00:52:26 <[\\\\\\]> how's that for making sense?
144 2013-07-11 00:53:01 <pigeons> yeah didnt mnemonicode
145 2013-07-11 00:59:40 <sipa> [\\\\\\]: what doesn't make sense?
146 2013-07-11 01:00:01 <sipa> inputs = outputs + fees
147 2013-07-11 01:04:23 <gmaxwell> sort of a bit surprised to see that listtransactions on a wallet with generated coins shows them as orphan when it hasn't caught up to the blocks containing them.
148 2013-07-11 01:06:27 <sipa> gmaxwell: hmm, what would you suggest?
149 2013-07-11 01:10:10 <gmaxwell> I would not have expected _orphan blocks_ to hit the wallet. Extinct ones (with orphan coinbases). There is actually a DOS attack here, I think.
150 2013-07-11 01:10:53 <gmaxwell> e.g. I could send you orphan diff 1 blocks with 1mb coinbase txns paying you and add data to your wallet.
151 2013-07-11 01:11:07 <gmaxwell> er I'd expect extinct ones to hit it but not unconnected ones.
152 2013-07-11 01:11:31 <gmaxwell> Not a serious DOS attack, at least.
153 2013-07-11 01:13:26 <nsh> hmm
154 2013-07-11 01:13:52 <nsh> it could be used to game sites that rely on wallet amounts for business logic
155 2013-07-11 01:13:58 <nsh> possibly
156 2013-07-11 01:30:54 <sipa> gmaxwell: "orphan" for transactions means that the generating transaction is not in the best chain
157 2013-07-11 01:31:18 <sipa> gmaxwell: that is the cause for the confusing in terminology
158 2013-07-11 01:31:40 <sipa> the blocks are not orphan, but their coinbases are
159 2013-07-11 01:32:06 <sipa> orphan blocks (in the proper meaning of orphan) never hit the wallet
160 2013-07-11 01:32:51 <gmaxwell> sipa: but these are orphan blocks, afaict.
161 2013-07-11 01:33:23 <gmaxwell> I'm resyncing a node from 0, and there are some totally valid new generations from today that are orphan blocks because I haven't caught up to them yet
162 2013-07-11 01:33:31 <gmaxwell> and they were added to the wallet as "orphan"
163 2013-07-11 01:34:36 <gmaxwell> "blocks" : 224197,
164 2013-07-11 01:34:48 <gmaxwell> "category" : "orphan",
165 2013-07-11 01:34:52 <gmaxwell> "txid" : "6900ce2c2f106d7187818f0bb226fb5ab3311fe5c8df7618bca2d538e5b9d1a5",
166 2013-07-11 01:35:03 <gmaxwell> which is block 245900
167 2013-07-11 01:37:52 <gmaxwell> This surprised me, I expected that an not yet connected block (currently orphan) would not exist from the perspective of the wallet code.
168 2013-07-11 01:54:51 <sipa> gmaxwell: well that's one way to look at it
169 2013-07-11 01:55:06 <sipa> but it's just a block that doesn't exist at all
170 2013-07-11 01:55:15 <sipa> yet the transaction is in the wallet
171 2013-07-11 01:55:26 <sipa> so the transaction is orphaned
172 2013-07-11 01:55:40 <sipa> regardless of the reason why the block can't be found
173 2013-07-11 01:57:57 <sipa> but real orphan blocks (lone received blocks) are not processed until their oarents are connected, so won't trigger an add to fhe wallet
174 2013-07-11 01:58:47 <gmaxwell> Then how did this transaction end up added to my wallet? My node has only synced to 224197. That txn is block 245900??? its parents aren't connected yet.
175 2013-07-11 01:59:38 <sipa> i assume the wallet has seen a later blockchain db
176 2013-07-11 02:01:32 <gmaxwell> It had seen later than 224197.  But it had not seen 245900 or 245899 unless I'm timezone confused.
177 2013-07-11 02:01:56 <sipa> i see no other explanation
178 2013-07-11 02:05:21 <gmaxwell> ah. indeed. I thought it was only the 10th in UTC.
179 2013-07-11 02:05:33 <gmaxwell> (my US upgrade broke my clock it seems)
180 2013-07-11 02:07:56 <bigz> hey guys question, I am using .8.3 bitcoin QT and sent a transaction "to myself" (sent all coins to one address in wallet), and this TX hasn't showed up yet, 3 hours later, and basically none of my other transactions are going through either
181 2013-07-11 02:08:01 <bigz> and by not showed up , I mean, unconfirmed but also literally not on blockchain.info
182 2013-07-11 02:08:35 <IanCormac> This is not really a question for #bitcoin-dev
183 2013-07-11 02:08:47 <IanCormac> You already asked in #bitcoin; keep it there
184 2013-07-11 02:30:03 <TradeFortress> Would there be any conflicts if I ran multiple bitcoind that contain the same addresses
185 2013-07-11 02:30:11 <TradeFortress> To load balance bitcoind and make it scale.
186 2013-07-11 02:30:44 <Scrat> TradeFortress: yes
187 2013-07-11 02:31:14 <TradeFortress> Scrat, okay. so I'll have to shard it then.
188 2013-07-11 02:34:57 <Scrat> or use something that handles big wallets better (bitsofproof, bitcoinj)
189 2013-07-11 02:40:44 <TradeFortress> BOP enterprise == community, just hosted?
190 2013-07-11 02:43:54 <Scrat> looks like it
191 2013-07-11 02:44:17 <Scrat> you can always throw more hardware at bitcoind though
192 2013-07-11 02:44:28 <Scrat> I have found IO latency to be the single biggest contributor
193 2013-07-11 02:45:37 <gjs278> wtf
194 2013-07-11 02:45:42 <gjs278> what do you need multiple instances of bitcoind for
195 2013-07-11 02:45:53 <sipa> huge wallets
196 2013-07-11 02:46:01 <sipa> unfortunately
197 2013-07-11 02:46:53 <gjs278> so if I gen like 1m vanity addresses on my personal wallet, I'd have major issues keeping up with rpc commands?
198 2013-07-11 02:47:00 <TradeFortress> Scrat, yeah, I'm going to do that until it's no longer feasible. I'll then start sharding
199 2013-07-11 02:47:19 <gjs278> and what holds it back, cpu or io at that point
200 2013-07-11 02:47:23 <TradeFortress> somehow I corrupted a wallet.dat copied between servers. hmm.
201 2013-07-11 02:47:24 <sipa> gjs278: that'll mostly just slowdown startup
202 2013-07-11 02:47:40 <sipa> TradeFortress: different versions?
203 2013-07-11 02:47:40 <TradeFortress> it's transactions that matter apparently
204 2013-07-11 02:48:02 <TradeFortress> sipa, all v0.8.3 through I did accidently run v0.3 something once on that wallet.dat. will copy it again
205 2013-07-11 02:48:03 <sipa> TradeFortress:was the source bitcoind running?
206 2013-07-11 02:48:10 <TradeFortress> no, shut it down first
207 2013-07-11 02:48:12 <sipa> ok
208 2013-07-11 02:48:24 <gjs278> what kills the performance, cpu or io for the huge wallets
209 2013-07-11 02:48:45 <TradeFortress> gjs278, pretty sure IO. cause it's just looking things up
210 2013-07-11 02:48:53 <sipa> well rpc itself is limited because of tcp connection setup
211 2013-07-11 02:49:15 <gjs278> if it's io... how big can a wallet.dat even get
212 2013-07-11 02:49:28 <sipa> anything balance related is O(n) in the number of transactions
213 2013-07-11 02:49:48 <gjs278> how big does your wallet.dat have to be filesize wise to give you trouble
214 2013-07-11 02:50:01 <sipa> and any wallet modification needs a sync of the wallet to disk, limited by io speed
215 2013-07-11 02:50:14 <sipa> the size of the wallet doesn't really matter for that
216 2013-07-11 02:50:36 <sipa> it's more that intensive use is a problem
217 2013-07-11 02:50:49 <gjs278> because the disk can't keep up
218 2013-07-11 02:50:52 <sipa> not really the wallet being large itself
219 2013-07-11 02:51:23 <sipa> though at some point
220 2013-07-11 02:51:27 <Scrat> sipa: as wallet outputs get spent does n get smaller?
221 2013-07-11 02:51:37 <sipa> which n?
222 2013-07-11 02:51:56 <gjs278> well... if it's really disk stuff there are ways around that, like raiding1 mdadm to a ramdisk and delaying the write on the hard disk for a good minute
223 2013-07-11 02:52:12 <Scrat> sipa: you know what i meant!
224 2013-07-11 02:52:21 <sipa> Scrat: i do not
225 2013-07-11 02:52:49 <sipa> gjs278: which will destroy the durability property that makes it slow in the first place
226 2013-07-11 02:52:58 <gjs278> I don't see how multiple bitcoinds will help with scaling if the problem truly disk problems
227 2013-07-11 02:53:41 <Scrat> sharding would complicate everything including hot wallet management
228 2013-07-11 02:53:43 <gjs278> if the disk is slammed for 1 it will be slammed for all, more people trying to access a hard drive can't really help
229 2013-07-11 02:53:49 <Scrat> sipa: the whole deal with linear transaction scaling
230 2013-07-11 02:54:02 <sipa> Scrat: all depends on whcih operation is limited
231 2013-07-11 02:54:17 <sipa> for coin selection, only unspent outputs count
232 2013-07-11 02:54:28 <sipa> for balance calculations, all transactions count
233 2013-07-11 02:54:39 <Scrat> ah thats good
234 2013-07-11 02:54:46 <Scrat> you shouldnt be spamming balance anyway
235 2013-07-11 02:54:48 <sipa> which is ridiculous
236 2013-07-11 03:03:55 <TradeFortress> i wonder how exchanges and pools are getting bitcoind to scale
237 2013-07-11 03:05:36 <Scrat> well for one, they dont use bitcoind
238 2013-07-11 03:08:33 <Scrat> TradeFortress: is it locking up when sending?
239 2013-07-11 03:08:55 <TradeFortress> Scrat, I've had 3 deadlocks after sending
240 2013-07-11 03:09:05 <TradeFortress> I'm resetting up the bitcoind instance to see if that's the problem
241 2013-07-11 03:10:44 <Scrat> is the server being used for anything else? IOwait kills bitcoind
242 2013-07-11 03:10:53 <Scrat> also SSDs will provide a _HUGE_ boost
243 2013-07-11 03:11:53 <TradeFortress> good idea
244 2013-07-11 03:12:38 <TradeFortress> Scrat, you run coinroll.it right?
245 2013-07-11 03:12:47 <Scrat> yes
246 2013-07-11 03:19:29 <TradeFortress> you need bigger max bets.
247 2013-07-11 03:20:02 <gjs278> bigger max bets = bank goes broke
248 2013-07-11 03:21:36 <TradeFortress> not if the house has more bank
249 2013-07-11 04:24:32 <bigz> guys my jsonrpc keeps throwing exception on dumpprivkey
250 2013-07-11 04:24:40 <bigz> and walletpassphrase
251 2013-07-11 04:25:51 <bigz> im even trying locking it and reentering passphrase
252 2013-07-11 04:29:50 <sipa> which exception
253 2013-07-11 04:31:09 <turboroot> sipa: he's just providing a failure stacktrace given by the client, which doesn't help
254 2013-07-11 04:31:21 <turboroot> [01:23:12] <bigz>\t Stack trace: #0 /var/www/bak/dump_priv_keys.php(36): jsonRPCClient->__call('dumpprivkey', Array) #1 /var/www/bak/dump_priv_keys.php(36): jsonRPCClient->dumpprivkey('1
255 2013-07-11 04:33:59 <sipa> the actual rpc error would be more useful
256 2013-07-11 04:34:06 <bigz> where can I grab that from
257 2013-07-11 04:34:08 <bigz> I am using the php jsonrpc
258 2013-07-11 04:34:16 <bigz> CLI is just throwing stack trace
259 2013-07-11 04:34:33 <sipa> try using bitcoind instwead
260 2013-07-11 04:34:48 <sipa> or some library that correctly deals with exceptions
261 2013-07-11 04:34:53 <SomeoneWeird> lolll
262 2013-07-11 04:53:21 <phantomcircuit> tradeafter sending?
263 2013-07-11 04:53:27 <phantomcircuit> oh he left
264 2013-07-11 04:54:18 <phantomcircuit> pretty sure he was hitting the IsConfirmed issue
265 2013-07-11 05:08:23 <nsh> ?
266 2013-07-11 05:08:23 <nsh> phantomcircuit, is your cache for IsConfirmed not ack'd yet
267 2013-07-11 05:10:45 <phantomcircuit> nsh, i dont think i actually submitted a pull request
268 2013-07-11 05:10:51 <phantomcircuit> effort
269 2013-07-11 05:11:11 <nsh> yeah, most of my best code contributions remain in the hypothetical branch
270 2013-07-11 05:11:29 <nsh> i find the github interface in my imagination to be much more efficient
271 2013-07-11 05:11:40 <phantomcircuit> heh
272 2013-07-11 09:17:50 <Moo-_-> what's policy regarding bitcoin.it wiki updates?
273 2013-07-11 09:19:21 <BlueMatt> if you fuck up, the bitcoin central bank will seize all your coins
274 2013-07-11 09:19:27 <BlueMatt> (but, seriously, we dont have one...)
275 2013-07-11 09:27:42 <phantomcircuit> BlueMatt, hola
276 2013-07-11 09:27:49 <The_Fly> lol
277 2013-07-11 09:28:12 <BlueMatt> hi?
278 2013-07-11 09:28:44 <SomeoneWeird> BlueMatt, lold
279 2013-07-11 11:12:38 <asdsdqqwe> ???????? ???????????? ????????????
280 2013-07-11 11:22:09 <asdsdqqwe> <asdsdqqwe> AlexNagy: you can't apply the same logic to bitcoin as you can for physical commodities
281 2013-07-11 11:22:11 <asdsdqqwe> <asdsdqqwe> AlexNagy: i totally agree lost coins increase the value of non lost coins
282 2013-07-11 11:22:13 <asdsdqqwe> <asdsdqqwe> BTC has value because it has a limit on the amount of BTC. A limit which will never increase. Through lost coins, the total amount available for transactions will decrease, therefore increasing the value of the remaining supply. As long as BTC is a currency demand will remain the same or go up (or go down depending on the mood of the market) but the value will continue to increase as they become rarer.
283 2013-07-11 11:22:15 <asdsdqqwe> <asdsdqqwe> AlexNagy: i just don't see how lost coins are a "problem" that need to be "worried about", in short, they don't matter
284 2013-07-11 11:22:18 <asdsdqqwe> <asdsdqqwe> hidio
285 2013-07-11 11:22:20 <asdsdqqwe> <asdsdqqwe> epscy: I didn't say lost coins were a problem per say, but in the end their could be so little left as to make them too expensive for the every-man to use them.
286 2013-07-11 11:22:22 <asdsdqqwe> <asdsdqqwe> AlexNagy: bitcoin is also theoretically infinitely divisable
287 2013-07-11 11:22:24 <asdsdqqwe> <asdsdqqwe> AlexNagy: so its not like if too many get lost the whole thing will freeze up
288 2013-07-11 11:22:26 <asdsdqqwe> <asdsdqqwe> spreelanka: yes, you can. // epscy this is true but currently are only divisable into 100,000,000 units, right?
289 2013-07-11 11:22:29 <asdsdqqwe> <asdsdqqwe> ???????? ???????????? ????????????
290 2013-07-11 11:22:31 <asdsdqqwe> <asdsdqqwe> epscy: I think eventually that will be the case, though.
291 2013-07-11 11:28:34 <jgarzik> mornin'
292 2013-07-11 11:36:19 <TD> good morning
293 2013-07-11 11:50:07 <Michhell> i habe a question: which ist the bitcoind beta version
294 2013-07-11 11:52:13 <sipa> 0.8.3
295 2013-07-11 11:56:19 <Michhell> sipa on the link it comes only such signs:
296 2013-07-11 11:56:21 <Michhell> ????????????
297 2013-07-11 12:00:37 <Michhell> dev onlin?
298 2013-07-11 12:01:44 <sipa> i don't speak arabian
299 2013-07-11 12:02:04 <TD> arabic
300 2013-07-11 12:02:41 <sipa> see, i don't speak it!
301 2013-07-11 12:02:49 <sipa> TD: thanks :)
302 2013-07-11 12:02:52 <michagogo> Arabiyeh
303 2013-07-11 12:02:58 <TD> :)
304 2013-07-11 12:03:09 <gribble> 246040
305 2013-07-11 12:03:09 <michagogo> ;;bc,blocks
306 2013-07-11 12:03:28 <michagogo> Grr, I hate when the client sync just freezes
307 2013-07-11 12:03:47 <Michhell> lokote_jones: -*- Ascendion stuffs lolita997711 head first into a jar of vaseline and screws the lid on
308 2013-07-11 12:03:54 <michagogo> There should be a way to see who you're currently syncing from
309 2013-07-11 12:04:14 <michagogo> And cut them loose (or at least have the client switch away from them for initial sync)
310 2013-07-11 12:05:02 <sipa> Michhell: do you have any idea what you're pasting?
311 2013-07-11 12:05:32 <michagogo> Also: I should really get around to figuring out how to best fine-tune my pings
312 2013-07-11 12:06:56 <Michhell> sipa: thats wrote Ascendion
313 2013-07-11 12:07:42 <sipa> Michhell: that was not my question
314 2013-07-11 12:07:56 <Michhell> whats your question
315 2013-07-11 12:08:12 <sipa> whether you know what you're pasting
316 2013-07-11 12:09:02 <Michhell> sipa: i know it. and you? i found it here from some ape
317 2013-07-11 12:09:38 <sipa> don't paste such things please, even if you're just copy pasting
318 2013-07-11 12:09:53 <sipa> now, what is your question?
319 2013-07-11 12:10:20 <Michhell> ???? ?????? ???? ?????? ???????????? ??????????????
320 2013-07-11 12:10:26 <Michhell> translate this
321 2013-07-11 12:10:41 <Michhell> ??? ???????????????????????? ??????????????? racists ?????????????????????
322 2013-07-11 12:10:58 <Michhell> ok i stop it
323 2013-07-11 12:11:43 <sipa> Michhell: do you have an actual question?
324 2013-07-11 12:11:52 <Michhell> yes
325 2013-07-11 12:13:15 <Michhell> can i sync the client over 3G on sea?
326 2013-07-11 12:13:24 <Michhell> or in an Iarplane?
327 2013-07-11 12:13:33 <sipa> in theory, yes, but it will be very slow
328 2013-07-11 12:14:08 <Michhell> if i print out the privat key. how many pages ar this?
329 2013-07-11 12:14:40 <michagogo> Michhell: A bitcoin private key can be printed on a small strip of paper
330 2013-07-11 12:14:52 <Michhell> ok.
331 2013-07-11 12:15:15 <michagogo> A raw private key looks something like 0C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D
332 2013-07-11 12:15:41 <michagogo> While a Wallet Import Format private key, the more common form for private keys, looks like 5HueCGU8rMjxEXxiPuD5BDku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ
333 2013-07-11 12:16:25 <Michhell> if i would build a bomb howmany btc did i neet for c4?
334 2013-07-11 12:17:25 <Michhell> whcih is the better target? nsa , cia or hsa or  fbi
335 2013-07-11 12:17:34 <sipa> can you stay on-topic?
336 2013-07-11 12:17:36 <michagogo> Michhell: That's off-topic for both #bitcoin-dev and freenode. Please stop.
337 2013-07-11 12:17:57 <michagogo> Michhell: Also, please don't spam #bitcoin
338 2013-07-11 12:41:02 <Michhell> rumpel
339 2013-07-11 14:39:51 <midnightmagic> I have two bitcoin nodes, A and B. They are fairly distant from one another--as far apart as east and west coast U.S. I would like to understand what's going on with the network between the two of them. Is there a single tool which semi-automatically measures the network characteristics between two endpoints? Say, exercises MTU, fiddles with TCP parameters, traceroutes to examine per-hop latencies (as much as possible) including
340 2013-07-11 14:39:57 <midnightmagic> TCP, does icmp echo, tries to measure for buffer bloat issues, that sort of thing?
341 2013-07-11 14:42:08 <Ry4an> mtr isn't bad
342 2013-07-11 14:42:14 <Ry4an> https://en.wikipedia.org/wiki/MTR_(Software)
343 2013-07-11 14:42:36 <gmaxwell> midnightmagic: the closest I'm aware of to what you're asking for??? in terms of benchmarking??? is http://www.uperf.org/ or http://code.google.com/p/iperf/
344 2013-07-11 14:43:26 <gmaxwell> Yea, mtr is pretty handy. Also, if you want long term latency/loss graphs??? I'm fond of smokeping.
345 2013-07-11 14:44:17 <Ry4an> ooh, I run ping in a loop on a few links about which I worry.  I'll have to look into that.
346 2013-07-11 14:45:42 <gmaxwell> Ry4an: fping (which I think smokeping uses in the background) is pretty useful for "ping N things I care about"
347 2013-07-11 14:46:52 <Ry4an> usually I'm fighting w/ ISPs about packetloss, so I do 10 pings every 2 minutes forever and graph the loss, but doing that w/ bash/grep feels like reinventing the wheel
348 2013-07-11 14:47:27 <Ry4an> not that it's a complex wheel of course, but still nice to have something that handles the history/graphing for me.
349 2013-07-11 15:03:42 <midnightmagic> gmaxwell, Ry4an: Thanks.
350 2013-07-11 15:30:16 <xavier23> ..
351 2013-07-11 16:09:50 <DoctorBTC> so, every 2 weeks or so I fire up bitcoin-qt on osx, only to find something corrupted or a crash on launch.  I am now in the habit of backing up the entire 'Bitcoin' folder from 'Application Support'.  Is this normal user behaviour?
352 2013-07-11 16:10:28 <DoctorBTC> This morning it happened.  I do recall that the client was catching up when I had to quit out of it a few days ago....
353 2013-07-11 16:11:18 <DoctorBTC> btw, restoring my backup of the blockchain and all those files works like a charm, it just has to resync.
354 2013-07-11 16:15:58 <gmaxwell> DoctorBTC: There is an intermittent leveldb corruption problem on OSX (at least). Most reported incidents seem to be from systems that have gone into hybernate but not come back from it.
355 2013-07-11 16:17:59 <gwillen> DoctorBTC: As a data point, I'm on OS X and don't have this issue
356 2013-07-11 16:18:08 <DoctorBTC> gmaxwell: interesting.  I know for sure that the last time I ran qt, it was syncing 2 days behind.  I did 'File > quit' and it looked like it closed down nice.
357 2013-07-11 16:19:08 <gmaxwell> Well, I did say 'most'. We don't know the cause and so there may be other cases. Its hard to get good information??? I assume most people don't report it.
358 2013-07-11 16:19:26 <DoctorBTC> gwillen: lucky you. I just make it a habit to backup the entire directory whenever I quit, but only if it is currently synced
359 2013-07-11 16:19:46 <DoctorBTC> gmaxwell: i'll report it next time ;)
360 2013-07-11 16:19:56 <gwillen> DoctorBTC: well, I have systemwide backups, too, so if it explodes I'll restore
361 2013-07-11 16:20:05 <gwillen> (you probably should have backups too :-)
362 2013-07-11 16:20:06 <ll> it happens to me almost every time i quit and relaunch :/
363 2013-07-11 16:20:18 <gmaxwell> ll: What hardware, what OS/version ?
364 2013-07-11 16:20:42 <ll> 13" mbp, 10.8.4
365 2013-07-11 16:21:23 <DoctorBTC> 27" imac, i5 (2009) running 10.6.x
366 2013-07-11 16:22:37 <DoctorBTC> ll: on mac as well?
367 2013-07-11 16:23:46 <ll> yes that is the m in mbp
368 2013-07-11 16:41:03 <DoctorBTC> ll: sorry, i have a reading disorder.
369 2013-07-11 16:41:22 <DoctorBTC> i thought that was gwillen replying
370 2013-07-11 16:42:32 <gwillen> DoctorBTC: yeah I'm on a 15" mbp
371 2013-07-11 16:42:39 <gwillen> on 10.6.x
372 2013-07-11 18:43:17 <midnightmagic> There used to be treatises on the subject, but damned if I can find them now. Is there a list somewhere of all the different interesting classes of attacks that are commonly used, and explanations of typical defenses? There seems to be a tremendous amount of expertise rolled up in openssl, for example, but the expertise itself, while coded in the source, doesn't seem to be explicitly described.
373 2013-07-11 18:44:07 <gmaxwell> attacks against what??
374 2013-07-11 18:44:10 <midnightmagic> By attacks I mean "buffer overflow," "off-by-1", "signed integer"..
375 2013-07-11 18:45:32 <midnightmagic> gmaxwell: unverified input variables, kernel memory recovery, ptrace+friends, cpu undefined behaviour exploits (as described by theo deraadt and matt dillon in that slashdot story all that time ago..)
376 2013-07-11 18:45:52 <midnightmagic> timing attacks, race conditions blah blah
377 2013-07-11 18:46:19 <gmaxwell> midnightmagic: openssl is not particularly hardened against the things you've listed, except for timing attacks. In fact, it intentionally used undefined behavior.
378 2013-07-11 18:47:02 <gmaxwell> In any case, you probably want the stuff listed on securecoding.cert.org
379 2013-07-11 18:47:37 <gmaxwell> E.g. https://www.securecoding.cert.org/confluence/display/seccode/CERT+C+Secure+Coding+Standard
380 2013-07-11 18:47:45 <midnightmagic> gmaxwell: But the exploits that it's corrected in its own code, encode some of the expertise required to fix them. But short of slogging slowly through external secunia/etc advisories, .. I think too many projects fix the issue and then sweep it under the rug, where people have a harder time learning from it when designing other software..
381 2013-07-11 18:47:56 <midnightmagic> oo  that's nice.
382 2013-07-11 18:48:40 <gmaxwell> OpenSSL isn't the last place I'd recommend people look for defensive programming, but its close to it.
383 2013-07-11 18:49:17 <midnightmagic> The OpenBSD team has developed a tremendous pool of expertise and collected it in one place, but it's just a collective knowledge in their heads.
384 2013-07-11 18:51:24 <midnightmagic> gmaxwell: So far an excellent collection of summarized exploits and classes of exploit exists in the pkgsrc vulnerabilities database, but.. it just *lists* the problems. It only implies where the solutions are.
385 2013-07-11 18:51:54 <gmaxwell> huh, it's mostly _concrete recommendations_.
386 2013-07-11 18:52:17 <k9quaint_> luke is mean!
387 2013-07-11 18:52:19 <gmaxwell> E.g. https://www.securecoding.cert.org/confluence/display/seccode/INT04-C.+Enforce+limits+on+integer+values+originating+from+untrusted+sources
388 2013-07-11 18:52:33 <gmaxwell> title tells you what to do, it gives an example of it done wrong, and an example of doing it right.
389 2013-07-11 18:53:06 <k9quaint_> I just call Atoi and throw semi-colons and curly braces at it
390 2013-07-11 18:53:11 <gmaxwell> k9quaint_: hm?
391 2013-07-11 18:53:12 <midnightmagic> gmaxwell: So, more disconnected knowledge except for the "Related Vulnerabilities" link. That's pretty awesome.
392 2013-07-11 18:53:50 <midnightmagic> https://www.kb.cert.org/vulnotes/bymetric?searchview&query=FIELD+KEYWORDS+contains+INT04-C   booo no results found
393 2013-07-11 18:53:51 <k9quaint_> gmaxwell: when I get numbers in JSON from zee internets
394 2013-07-11 18:54:03 <gmaxwell> midnightmagic: people aren't super diligent at identifying these things.
395 2013-07-11 18:56:00 <midnightmagic> Ooo there's a book.
396 2013-07-11 18:57:48 <midnightmagic> MEM08-C. Use realloc() only to resize dynamically allocated arrays || whoah I didn't even know that was possible.
397 2013-07-11 18:58:40 <midnightmagic> POS33-C. Do not use vfork()     629 hahaha I love it.
398 2013-07-11 19:02:50 <gmaxwell> vfork is "we were too lame to implement copy on write in our kernel, but too stubborn to implement a non-forking exec model"
399 2013-07-11 19:05:47 <nsh> <burns> it was the blurst of both worlds. what?! blurst?! someone fire these monkeys...
400 2013-07-11 20:06:03 <Luke-Jr> 2013-07-11 21:59:31 keypool added key 858, size=858
401 2013-07-11 20:06:05 <Luke-Jr> terminate called after throwing an instance of 'std::runtime_error'
402 2013-07-11 20:06:06 <Luke-Jr> what():  CWallet::GenerateNewKey() : AddKey failed
403 2013-07-11 20:06:08 <Luke-Jr> :/
404 2013-07-11 20:06:24 <sipa> wut
405 2013-07-11 20:08:33 <Luke-Jr> sipa: I think the wallet locked itself while it was refilling lol
406 2013-07-11 20:08:42 <Luke-Jr> then segfault
407 2013-07-11 20:10:38 <saivann> Someone rebooted BlueMatt virtual servers? The jekyll machine seems to be stopped
408 2013-07-11 20:11:27 <saivann> Most virtual machines are stopped actually
409 2013-07-11 20:12:58 <Luke-Jr> hmm
410 2013-07-11 20:13:04 <Luke-Jr> did it again, after another 700-800 keys
411 2013-07-11 20:13:11 <Luke-Jr> this time I had it unlocked infinite
412 2013-07-11 20:27:45 <maaku> anyone have a pointer to the DER format of a compressed public key?
413 2013-07-11 20:42:48 <sipa> maaku: why DER?
414 2013-07-11 20:43:07 <sipa> bitcoin doesn't use DER for public keys
415 2013-07-11 20:43:40 <sipa> (except inside private keys are stored in unencrypted wallets)
416 2013-07-11 21:01:10 <eruadan> hi, i'm curious about btc code base)i just know some js), and i notice it has a lot of typescript. is there any particular reason that this language was chosen?
417 2013-07-11 21:02:16 <lianj> typescript? WHERE
418 2013-07-11 21:02:30 <lianj> ups, didn't want to capslock
419 2013-07-11 21:03:49 <eruadan> https://github.com/bitcoin/bitcoin
420 2013-07-11 21:04:11 <eruadan> says typescript 66,4%
421 2013-07-11 21:06:37 <lianj> eruadan: prolly an error
422 2013-07-11 21:06:54 <lianj> the core of bitcoin is all c++
423 2013-07-11 21:07:15 <eruadan> ahh, ok
424 2013-07-11 21:07:19 <lianj> maybe the github stats are wrong due to https://github.com/bitcoin/bitcoin/tree/master/src/qt/locale
425 2013-07-11 21:08:02 <gmaxwell> lol.
426 2013-07-11 21:10:15 <eruadan> ok, so i need a crash course in c++
427 2013-07-11 21:21:40 <K1773R> if i set the keypool to 1000 and find 1000 blocks, a backup would also work? ie does finding new blocks use an address from the keypool?
428 2013-07-11 21:21:50 <K1773R> it should AFAIK
429 2013-07-11 21:27:28 <gmaxwell> K1773R: yes.
430 2013-07-11 21:28:01 <K1773R> gmaxwell: ty
431 2013-07-11 21:31:16 <Luke-Jr> err
432 2013-07-11 21:31:22 <Luke-Jr> depends on your mining server lol
433 2013-07-11 21:31:34 <Luke-Jr> getwork is deprecated, but behaves like that
434 2013-07-11 21:31:42 <Luke-Jr> and bitcoind's GBT doesn't coordinate the payout at all