1 2012-12-27 00:19:45 <gmaxwell> sipa: "This was generated by BlockChain Wallet.  Last time I used it was the 24th with my iPad app.  Hope this helps."
  2 2012-12-27 00:20:07 <gmaxwell> (wrt 1Pq7zKpZHLaT9yheWyHqQp8XUtvTmt7VTm)
  3 2012-12-27 00:26:07 <BlueMatt> ;;later tell TD i may have put a bit too much in one commit (sorry...poor workflow...) but any chance i could get the "Make FullPrunedBlockStore/Chain upgrade-friendly" commit from https://code.google.com/r/bluemattme-bitcoinj/source/list?name=headersfirstsync merged?
  4 2012-12-27 00:26:08 <gribble> The operation succeeded.
  5 2012-12-27 02:42:40 <ssm2017> hello
  6 2012-12-27 02:42:53 <ssm2017> do you knwo the max length of an address label ?
  7 2012-12-27 02:43:09 <ssm2017> 256 chars ?
  8 2012-12-27 03:43:34 <tcatm> Who is behind http://bitcoincard.org and is he on IRC?
  9 2012-12-27 03:44:06 <Luke-Jr> dunno
 10 2012-12-27 03:45:19 <tcatm> Looks like that device generates the bad signatures.
 11 2012-12-27 03:46:32 <Luke-Jr> facepalm
 12 2012-12-27 03:47:12 <tcatm> So in the future: Have one bitcoincard user send two transactions to you, recover private key and take the rest? :)
 13 2012-12-27 03:47:41 <Luke-Jr> :o
 14 2012-12-27 03:49:22 <tcatm> ah fsck. It's even worse. All their cards seem to use the same fixed R!
 15 2012-12-27 03:50:15 <Luke-Jr> wtf
 16 2012-12-27 03:51:10 <gmaxwell> fixed _R_?  you mean fixed K?
 17 2012-12-27 03:52:04 <gmaxwell> thats exactly the kind of device where needing a source of randomness is most problematic.
 18 2012-12-27 03:52:04 <tcatm> fixed R implies fixed K. I've only looked at scriptSigs so only compared R.
 19 2012-12-27 03:52:14 <gmaxwell> tcatm: okay, just checking.
 20 2012-12-27 03:52:38 <Luke-Jr> tcatm: so how many Bitcoins can you loot?
 21 2012-12-27 03:53:27 <tcatm> probably < 1 BTC until someone puts more on one of his cards
 22 2012-12-27 03:53:31 <Luke-Jr> :P
 23 2012-12-27 03:53:47 <gmaxwell> well there may be more but you can't tell because you just haven't seen the duplicate signature yet.
 24 2012-12-27 03:54:36 <tcatm> That's true. However, now all I have to look for is the specific R.
 25 2012-12-27 03:54:58 <tcatm> I've notified them using their contact form. I hope they'll read it.
 26 2012-12-27 04:27:38 <gmaxwell> tcatm: so, I see repeated r values used 6,4,3,3, and 2 times and I've only scanned to height 160k or so.
 27 2012-12-27 04:29:27 <tcatm> The bitcoincard R value was been used 57 times until yesterday.
 28 2012-12-27 04:32:12 <gmaxwell> yea, haven't gotten up to that one yet I guess.
 29 2012-12-27 04:37:23 <TheButterZone> heyoo
 30 2012-12-27 04:39:23 <stealth222> can't such a device have a built-in entropy source? (a ROM?)
 31 2012-12-27 04:40:05 <stealth222> hmmm...I guess that opens up a whole bunch of other issues
 32 2012-12-27 04:40:34 <tcatm> It could use an analog input for entropy.
 33 2012-12-27 04:41:26 <phantomcircuit> tcatm, iirc it's a programmable mesh network device that they bought already assembled
 34 2012-12-27 04:41:27 <phantomcircuit> so no
 35 2012-12-27 04:41:35 <phantomcircuit> there is probably no good entropy source
 36 2012-12-27 04:41:42 <gmaxwell> ... it could just do the ed25519 thing.
 37 2012-12-27 04:41:46 <phantomcircuit> make people mash on the keyboard for a long time could work
 38 2012-12-27 04:42:30 <stealth222> that's very, very slow
 39 2012-12-27 04:42:42 <gmaxwell> ... it could just do the ed25519 thing.
 40 2012-12-27 04:42:47 <tcatm> If it has a radio, there'll be registers for checking signal strength and noise floor. They could use that (might make signing pretty slow, though)
 41 2012-12-27 04:43:06 <phantomcircuit> gmaxwell, which is?
 42 2012-12-27 04:43:38 <tcatm> k = hash of secret and message
 43 2012-12-27 04:43:41 <gmaxwell> This is a solved problem. Hocus pocus with the radio is a good way to make more failures.??? someone flips it into airplane mode and you're back to constant R or the like.
 44 2012-12-27 04:44:14 <gmaxwell> phantomcircuit: as tcatm says. k=H(message||secret)  (secret might be your private key)
 45 2012-12-27 04:45:10 <phantomcircuit> hmm
 46 2012-12-27 04:45:44 <gmaxwell> and of course, boost has a bloom filter...
 47 2012-12-27 04:46:07 <gmaxwell> (I'm surprised C++ STL didn't have one!)
 48 2012-12-27 04:46:09 <gmaxwell> :P
 49 2012-12-27 04:46:19 <phantomcircuit> lol
 50 2012-12-27 04:48:09 <MC1984> good morning gentlemen
 51 2012-12-27 04:48:30 <phantomcircuit> lies
 52 2012-12-27 04:51:57 <Luke-Jr> gmaxwell: meh, boost might as well be C++ now
 53 2012-12-27 04:57:11 <stealth222> I remember the good ole days when every C++ program had its own string library :)
 54 2012-12-27 04:59:23 <Luke-Jr> stealth222: ???
 55 2012-12-27 04:59:29 <Luke-Jr> std::string
 56 2012-12-27 04:59:44 <gmaxwell> Luke-Jr: std::string was added later.
 57 2012-12-27 04:59:51 <gmaxwell> It wasn't originally there.
 58 2012-12-27 04:59:52 <stealth222> it almost seems too easy now
 59 2012-12-27 04:59:57 <Luke-Jr> gmaxwell: srsly? :o
 60 2012-12-27 04:59:58 <stealth222> everything was char* :)
 61 2012-12-27 05:00:12 <gmaxwell> stealth222: yea, that was too reasonable.
 62 2012-12-27 05:01:13 <tcatm> I've found a total of 1.4301 BTC in bitcoincards.
 63 2012-12-27 05:01:25 <stealth222> char* is perfectly reasonable for statically allocated buffers. But dynamic structures were a serious pain
 64 2012-12-27 05:03:15 <gmaxwell> Should I refrain from sharing some of the txids with duplicate Rs?
 65 2012-12-27 05:04:54 <tcatm> I don't know. K is encoded in the blockchain and can't be removed anyway.
 66 2012-12-27 05:06:16 <gmaxwell> well here are some of the old ones: http://pastebin.com/D8XYuWXX
 67 2012-12-27 05:08:49 <gmaxwell> by vout there it really means vin.
 68 2012-12-27 05:09:06 <tcatm> Interesting. Some of them are from 2011
 69 2012-12-27 05:10:06 <gmaxwell> all mine now are old because I'm getting them by reindexing the chain without checkpoints. (I changed the script validation code to log the R values)
 70 2012-12-27 05:10:57 <gmaxwell> results in quite a large logfile. :P
 71 2012-12-27 05:11:45 <tcatm> I've written a pretty dumb parser for raw blk*dat in python. It basically looked at the offsets where Rs in send-to-address scripts would appear.
 72 2012-12-27 05:12:00 <tcatm> Didn't really expect it to work anyway :D
 73 2012-12-27 05:12:19 <MC1984> people actually have those bitcoincards?
 74 2012-12-27 05:12:46 <tcatm> At least 7 of those cards exist.
 75 2012-12-27 05:13:10 <MC1984> wow
 76 2012-12-27 05:13:34 <MC1984> http://bitcoincard.org/earth/
 77 2012-12-27 05:13:46 <MC1984> theyve got a really unweildy website
 78 2012-12-27 05:14:45 <gmaxwell> https://people.xiph.org/~greg/dupr.html < here are addresses which were desinations used as txins in the transactions containing signatures with repeated R vales.
 79 2012-12-27 05:14:48 <gmaxwell> er values.
 80 2012-12-27 05:15:02 <gmaxwell> for the early bit of the chain I was looking at.
 81 2012-12-27 05:15:58 <gmaxwell> Interesting: https://bitcointalk.org/?topic=7584.0
 82 2012-12-27 05:19:15 <tcatm> Hrm, might be worth getting a copy of his bitcoin.exe
 83 2012-12-27 05:19:39 <gmaxwell> Last Active: January 07, 2012, 02:34:56 AM
 84 2012-12-27 05:20:05 <gmaxwell> might be interesting if there were malware that patched your bitcoin to use a determinstic K.
 85 2012-12-27 05:20:16 <gmaxwell> Bet you could manage it with a single byte changed.
 86 2012-12-27 05:21:59 <tcatm> The public keys for two of his transactions are different, yet the same k is used. Bad rng?
 87 2012-12-27 05:22:52 <gmaxwell> I wouldn't think that was a general problem in the reference client considering how _few_ duplicates I'm seeing.
 88 2012-12-27 05:23:42 <tcatm> K could still be deterministic in some way.
 89 2012-12-27 05:24:20 <gmaxwell> I'm suspecting that he was doing something hacky and custom??? notices the comments below about non-standard scripts and such.
 90 2012-12-27 05:24:45 <gmaxwell> oh.. see also: https://bitcointalk.org/index.php?topic=35518.msg439736#msg439736
 91 2012-12-27 05:28:16 <tcatm> mkay, so that is solved.
 92 2012-12-27 05:30:43 <gmaxwell> sipa: another one of the people I contacted today about the non-standard transactions said they were using blockchain.info, with chrome, no pinning extensions or anything like that.
 93 2012-12-27 05:30:53 <gmaxwell> perhaps some kind of caching bug.
 94 2012-12-27 05:33:45 <gmaxwell> I'm up to 126 unique repeated Rs now.
 95 2012-12-27 05:37:25 <gmaxwell> none of them appear to be ascii, :(
 96 2012-12-27 05:38:12 <phantomcircuit> gmaxwell, where does bc.info get entropy from?
 97 2012-12-27 05:47:31 <gmaxwell> window.crypto.random.
 98 2012-12-27 05:48:31 <gmaxwell> Though ... I should note, that it's not especially picky and I expect in a sufficiently old browser (e.g. old IE) it could probably fail.
 99 2012-12-27 05:48:39 <gmaxwell> Though you'd also end up with insecure private keys.
100 2012-12-27 05:48:54 <gmaxwell> IIRC I complained about this before so perhaps they changed in more recently.
101 2012-12-27 05:50:43 <HandleX> Hi to all! Have someone used comments in "move" API calls? I've try but comments can appear distorted... Is unicode strings support in HTTP JSON RPC incorrect in bitcoin/bitcoind?
102 2012-12-27 05:51:26 <Luke-Jr> "incorrect"?
103 2012-12-27 05:51:34 <Luke-Jr> does JSON even support Unicode? :|
104 2012-12-27 05:52:17 <HandleX> Yes, UTF8 MUST support ??)
105 2012-12-27 05:52:40 <Luke-Jr> anyhow, pretty sure bitcoind just stores it as-is <.<
106 2012-12-27 05:53:02 <HandleX> I've post an issue to https://github.com/bitcoin/bitcoin/issues/2127
107 2012-12-27 05:53:28 <HandleX> nobody interrested
108 2012-12-27 05:54:00 <phantomcircuit> i would strongly advice against using anything but ascii with the api
109 2012-12-27 05:54:08 <phantomcircuit> *strongly*
110 2012-12-27 05:54:48 <jgarzik> EBCDIC is more compatible with mainframe and ckermit users
111 2012-12-27 05:54:52 <HandleX> UTF8 is an 8-byte coded, like ASCII
112 2012-12-27 05:55:05 <tcatm> Is anyone of you going to 29c3 today?
113 2012-12-27 05:55:09 <phantomcircuit> HandleX, still a bad idea
114 2012-12-27 05:55:14 <Luke-Jr> HandleX: UTF-8 is variable byte
115 2012-12-27 05:55:15 <phantomcircuit> jgarzik, lol
116 2012-12-27 05:55:28 <Luke-Jr> HandleX: ASCII is technically 7 bit, btw
117 2012-12-27 05:57:16 <HandleX> What about another languages? Moreother, JSON can support UTF8 (javascript has nothing against UTF8)
118 2012-12-27 05:57:36 <Luke-Jr> HandleX: JSON != Javascript
119 2012-12-27 05:57:58 <phantomcircuit> json supposedly should work with utf-8
120 2012-12-27 05:58:13 <gmaxwell> I imagine that JSON's support should depend on the content type negoiated by http, enh?
121 2012-12-27 05:58:19 <phantomcircuit> however bitcoind rpc is not strictly standards complient
122 2012-12-27 05:58:59 <Luke-Jr> RFC 4627 says the *default* encoding is UTF-8, but yeah, I imagine HTTP negotiation trumps that
123 2012-12-27 05:59:32 <phantomcircuit> Luke-Jr, actual implementation trumps that x1000
124 2012-12-27 05:59:33 <phantomcircuit> lol
125 2012-12-27 06:00:23 <gmaxwell> uh. 4046 distinct repeated R involving 8197 txins.
126 2012-12-27 06:00:43 <phantomcircuit> gmaxwell, wat
127 2012-12-27 06:00:50 <phantomcircuit> that's a lot of mistakes
128 2012-12-27 06:01:04 <gmaxwell> my node finally caught up, it seems there has been a recent burst of fail.
129 2012-12-27 06:01:23 <phantomcircuit> satoshidice?
130 2012-12-27 06:02:49 <HandleX> Are transaction comments so rare? I trying to use them... but something is wrong.
131 2012-12-27 06:03:18 <phantomcircuit> HandleX, i would strongly recommend against using the "Accounts" feature of the client
132 2012-12-27 06:03:24 <phantomcircuit> it does not work as you expect
133 2012-12-27 06:03:26 <Luke-Jr> HandleX: non-ASCII is rare
134 2012-12-27 06:03:48 <Luke-Jr> phantomcircuit: he didn't even mention accounts, and it does work as many people expect
135 2012-12-27 06:04:01 <phantomcircuit> Luke-Jr, he's using the "move' api call
136 2012-12-27 06:04:06 <phantomcircuit> so yeah he did
137 2012-12-27 06:04:13 <Luke-Jr> oh, right
138 2012-12-27 06:05:45 <HandleX> Accounts helps me to manage client's money on the site I am developing
139 2012-12-27 06:06:07 <HandleX> There are in API, so why not?
140 2012-12-27 06:06:34 <HandleX> accounts are, sorry for my english -)
141 2012-12-27 06:07:37 <phantomcircuit> HandleX, it's impossible to have an accurate backup of your wallet.dat if you use the accounts feature
142 2012-12-27 06:08:05 <Luke-Jr> phantomcircuit: not if you backup every transaction
143 2012-12-27 06:08:06 <phantomcircuit> unless you create a new backup after every api call...
144 2012-12-27 06:08:17 <Luke-Jr> (or move)
145 2012-12-27 06:08:27 <phantomcircuit> that would be ridiculousness though
146 2012-12-27 06:08:50 <Luke-Jr> not for small things
147 2012-12-27 06:08:54 <phantomcircuit> not exactly a scalable solution
148 2012-12-27 06:08:59 <Luke-Jr> and bitcoind accounts don't scale to big things anyway
149 2012-12-27 06:09:18 <Luke-Jr> heck, bitcoind doesn't scale to big things
150 2012-12-27 06:10:22 <HandleX> Accounts used many sites and services... Wallet backup is not a problem for me...
151 2012-12-27 06:10:41 <phantomcircuit> Luke-Jr, scales a lot more than you'd think if you have a dedicated server :P
152 2012-12-27 06:10:49 <gmaxwell> heh. $ du -sh kde-gmaxwell
153 2012-12-27 06:10:54 <gmaxwell> go go scrollback
154 2012-12-27 06:11:34 <Luke-Jr> gmaxwell: ? O.o
155 2012-12-27 06:11:48 <Luke-Jr> gmaxwell: oh, you set unlimited konsole buffer? :P
156 2012-12-27 06:11:57 <phantomcircuit> i always do that
157 2012-12-27 06:12:27 <Luke-Jr> that fills disk pretty fast
158 2012-12-27 06:12:56 <phantomcircuit> not when you have 2TB of free space
159 2012-12-27 06:12:57 <phantomcircuit> lol
160 2012-12-27 06:13:49 <Luke-Jr> -rw------- 1 luke-jr luke-jr 7.0M Dec 27 07:14 .bash_eternal_history
161 2012-12-27 06:14:03 <Luke-Jr> ^ I find this very handy with grep
162 2012-12-27 06:14:15 <phantomcircuit> only 7 MB
163 2012-12-27 06:14:16 <phantomcircuit> wat
164 2012-12-27 06:14:30 <Luke-Jr> goes back a few years???
165 2012-12-27 06:14:37 <Luke-Jr> every command I've ever typed since
166 2012-12-27 06:15:03 <D34TH> wat
167 2012-12-27 06:15:03 <gmaxwell> Luke-Jr: mine recently got corrupted... its like having a lobotomy.
168 2012-12-27 06:15:08 <Luke-Jr> gmaxwell: O.O
169 2012-12-27 06:15:10 <Luke-Jr> I would die
170 2012-12-27 06:15:32 <gmaxwell> I only have about 319k now. :-/
171 2012-12-27 06:15:42 <Luke-Jr> I also have my PgUp/PgDn search my recent command history
172 2012-12-27 06:15:56 <Luke-Jr> putting commands run in the current directory first
173 2012-12-27 06:16:25 <gmaxwell> oh, I have a backup!
174 2012-12-27 06:16:29 <Luke-Jr> lol
175 2012-12-27 06:16:37 <Luke-Jr> du -hs .dir_bash_history
176 2012-12-27 06:16:38 <Luke-Jr> 43M .dir_bash_history
177 2012-12-27 06:16:43 <gmaxwell> well, I lost one system's.
178 2012-12-27 06:16:46 <Luke-Jr> even apparent-size is 37 MB
179 2012-12-27 06:16:47 <Luke-Jr> odd
180 2012-12-27 06:17:00 <gmaxwell> my biggest one is 1.4mbytes.
181 2012-12-27 06:17:10 <gmaxwell> but I also have it dedupe.
182 2012-12-27 06:17:18 <Luke-Jr> ah
183 2012-12-27 06:17:32 <Luke-Jr> not sure dedupe is worth it XD
184 2012-12-27 06:17:43 <Luke-Jr> though using a database might be nice
185 2012-12-27 06:17:51 <Luke-Jr> then I could store first use time, last use time, number of times used, etc :P
186 2012-12-27 06:18:31 <gmaxwell> I also intentionally exclude stuff from my history (prefix with a space) when I know its one shot and will never be needed again.
187 2012-12-27 06:18:41 <gmaxwell> (or has keying material in it)
188 2012-12-27 06:19:07 <Luke-Jr> I have the space trick too, but I almost nevrr use it
189 2012-12-27 06:20:54 <gmaxwell> https://people.xiph.org/~greg/dupr.html < all duplicate-R implicated addresses.
190 2012-12-27 06:21:17 <gmaxwell> (these keys themselves may not have signed with a duplicate-R but they were common txins on the relevant transactions)
191 2012-12-27 06:22:03 <gmaxwell> perhaps I shouldn't have linked that.
192 2012-12-27 06:22:11 <phantomcircuit> lol you guys are very different than me
193 2012-12-27 06:22:18 <phantomcircuit> i dont have any bash history
194 2012-12-27 06:22:23 <phantomcircuit> HISTFILE=/dev/null
195 2012-12-27 06:22:40 <phantomcircuit> close a tab and the history is gone forever
196 2012-12-27 06:22:58 <gmaxwell> TD: hey, dice uses your code right? Where do you get your random numbers from?
197 2012-12-27 06:23:20 <Luke-Jr> gmaxwell: can we exploit this to take all dice funds?
198 2012-12-27 06:23:37 <gmaxwell> Leave we out of this.
199 2012-12-27 06:23:44 <phantomcircuit> lololol
200 2012-12-27 06:24:05 <stealth222> don't steal my idea! :p
201 2012-12-27 06:24:06 <phantomcircuit> Luke-Jr, go to the fbi and tell them you have a way to confiscate funds from an illegal gambling site
202 2012-12-27 06:24:14 <phantomcircuit> you'll probably get immunity from prosecution
203 2012-12-27 06:24:16 <phantomcircuit> lololol
204 2012-12-27 06:24:30 <Luke-Jr> phantomcircuit: FBI doesn't care, they ignore me telling them I have a botnet operator -.-
205 2012-12-27 06:24:47 <phantomcircuit> Luke-Jr, literally walk into the building
206 2012-12-27 06:24:58 <phantomcircuit> calling/email/letters wont get you anywhere with the govt
207 2012-12-27 06:25:29 <Luke-Jr> phantomcircuit: besides, I know crap about ECDSA; I couldn't do it myself
208 2012-12-27 06:25:58 <stealth222> that's what web searches are for :)
209 2012-12-27 06:26:13 <gmaxwell> it's not hard to implement.
210 2012-12-27 06:26:32 <gmaxwell> But I wouldn't recommend it.
211 2012-12-27 06:27:02 <Luke-Jr> implementing it, or doing it?
212 2012-12-27 06:27:20 <gmaxwell> I mean it's just some basic arithemtic on the bignums to recover the private key.
213 2012-12-27 06:27:43 <Luke-Jr> I'm sure if someone implemented it, it'd be easy to find someone else to actually use it against dice??? <.<
214 2012-12-27 06:28:02 <stealth222> is OpenSSL still subject to timing attacks.
215 2012-12-27 06:28:03 <stealth222> ?
216 2012-12-27 06:28:08 <gmaxwell> Dice wouldn't lose, their victims would.
217 2012-12-27 06:28:44 <Luke-Jr> gmaxwell: unless the person doing it implemented the same algorithms (maybe minus the lose response)
218 2012-12-27 06:28:59 <Luke-Jr> (and batching the winnings???)
219 2012-12-27 06:29:00 <gmaxwell> In any case, it might not actually be vulnerable??? I looked for duplicated Rs, not duplicated Rs with the same public key. The latter is whats requrired for an attack.
220 2012-12-27 06:29:24 <gmaxwell> Luke-Jr: hah, yea the idea of getting their private keys in order to just return all bets is amusing.
221 2012-12-27 06:30:44 <andytoshi> stealth222, no, see the wiki page on ECDSA
222 2012-12-27 06:30:51 <andytoshi> fixed in 1.0.0e, IIRC
223 2012-12-27 06:37:41 <gmaxwell> oh, whew.
224 2012-12-27 06:38:06 <Luke-Jr> ?
225 2012-12-27 06:38:12 <gmaxwell> okay. dice isn't implicated. once it got done syncing up my stupid code logged a bunch of new transactions twice, once going into the mempool once going into the chain.
226 2012-12-27 06:40:57 <gmaxwell> TD: ignore above question
227 2012-12-27 06:52:49 <gmaxwell> okay, down to 367 unique txins and 131 unique r values.
228 2012-12-27 07:01:57 <gmaxwell> revised: https://people.xiph.org/~greg/dupr.html
229 2012-12-27 07:19:37 <sipa> so, which candidates are suspect of reusing K? bitcoincard, some blockchain
230 2012-12-27 07:19:48 <sipa> .info, and dice?
231 2012-12-27 07:20:41 <sipa> gmaxwell: ^ ?
232 2012-12-27 07:21:28 <gmaxwell> bitcoincard.  Dice was a false alarm??? blond moment, I mistook txns going into the mempool then into blocks for duplicates because of how I was collecting the data.
233 2012-12-27 07:21:47 <andytoshi> i worry that it's mobile devices with low entropy
234 2012-12-27 07:21:59 <andytoshi> running standard clients
235 2012-12-27 07:22:07 <gmaxwell> Here is my complete list: https://people.xiph.org/~greg/dupr.html  it gives a txid, vin, and the R value used. Then the prevout addresses spent in that txn.
236 2012-12-27 07:22:22 <gmaxwell> andytoshi: doesn't appear to be the case.
237 2012-12-27 07:23:10 <gmaxwell> Other than the ones tcatm was saying were bitcoincard most of the remaining txn look remarkably similar.
238 2012-12-27 07:24:04 <sipa> you could recover K, and group by K instead of by R
239 2012-12-27 07:24:09 <gmaxwell> I guess D47CE4C025C35EC440BC81D99834A624875161A26BF56EF7FDC0F5D52F843AD1 is the R value tcatm was saying was bitcoin card.
240 2012-12-27 07:24:36 <gmaxwell> I could??? though I didn't print the hash and signature.
241 2012-12-27 07:27:57 <sipa> i'll try to write something for that
242 2012-12-27 07:30:42 <gmaxwell> sipa: this should save you the effort of scanning the chain: http://people.xiph.org/~greg/rvals.txt
243 2012-12-27 07:30:55 <gmaxwell> (txid, vin, r)
244 2012-12-27 07:31:29 <gmaxwell> It'll be interesting to see if there is anything neat in the K's. I was stupidly looking for ascii in th Rs. Not my brightest evening.
245 2012-12-27 07:34:15 <SomeoneWeird> whats K
246 2012-12-27 07:34:18 <SomeoneWeird> (in this context)
247 2012-12-27 07:35:31 <gmaxwell> SomeoneWeird: a number which should be random but isn't for these broken signers.
248 2012-12-27 07:37:00 <SomeoneWeird> ah
249 2012-12-27 07:40:10 <sipa> SomeoneWeird: if you want details, read the wikipedia article on ECDSA
250 2012-12-27 07:45:10 <stealth222> right now, some of the RPC methods return plain text while some return JSON - and some return one or the other at different times. might this be a problem?
251 2012-12-27 07:45:37 <stealth222> I understand that for CLI usage returning plain text is in some sense cleaner
252 2012-12-27 07:46:32 <stealth222> but it seems we should have a standard format we use internally and then convert it to whatever format is exposed
253 2012-12-27 07:47:34 <sipa> the internal format is JSON :)
254 2012-12-27 07:49:14 <stealth222> how's BIP0032 coming along, btw, sipa?
255 2012-12-27 07:49:36 <stealth222> I guess it's only been a few days and you've been doing the holiday thing
256 2012-12-27 07:49:41 <sipa> i'm waiting for feedback from Hal
257 2012-12-27 07:49:49 <stealth222> Finney?
258 2012-12-27 07:49:53 <sipa> yes
259 2012-12-27 07:52:10 <sipa> and I suppose he's also been doing the holiday thing :)
260 2012-12-27 08:08:33 <stealth222> how does BDB handle deletions?
261 2012-12-27 08:08:56 <stealth222> is the data compacted?
262 2012-12-27 08:09:20 <sipa> eventually, i guess
263 2012-12-27 08:14:29 <stealth222> what's the best strategy for writing startup options to the config file? since the file doesn't have explicit tags for sections, it's not a trivial thing
264 2012-12-27 08:14:54 <stealth222> they can always be appended at the end - but that seems kind of lame
265 2012-12-27 08:15:34 <sipa> i don't think the code should touch the config file
266 2012-12-27 08:15:59 <stealth222> then how do we get the thing to save a state so that it loads in the same configuration at next startup?
267 2012-12-27 08:16:16 <sipa> maybe at some point introduce a formatted file with a list of wallets
268 2012-12-27 08:16:28 <sipa> or have that stored in some database
269 2012-12-27 08:16:39 <stealth222> I'd like it to be manually configurable
270 2012-12-27 08:16:44 <stealth222> so a text file is probably best
271 2012-12-27 08:17:38 <stealth222> a separate file would work - but it doesn't seem ideal
272 2012-12-27 08:17:54 <sipa> meh, i don't like automatically changing config files
273 2012-12-27 08:18:05 <sipa> (but that's just me, maybe)
274 2012-12-27 08:18:11 <stealth222> yeah, I can understand.
275 2012-12-27 08:18:35 <stealth222> how does the Qt client handle this? does it have its own config file that overrides bitcoin.conf?
276 2012-12-27 08:18:47 <sipa> indeed
277 2012-12-27 08:18:47 <stealth222> it's been forever since I used it - lol
278 2012-12-27 08:19:48 <stealth222> yeah, I guess a separate wallet file it is. and probably for the better anyhow if we later want to add access controls.
279 2012-12-27 08:19:56 <stealth222> yeah, I guess a separate file for wallets it is. and probably for the better anyhow if we later want to add access controls.
280 2012-12-27 08:20:33 <stealth222> using a database just seems like total overkill here...and makes it harder to manually edit
281 2012-12-27 08:22:19 <sipa> true
282 2012-12-27 08:42:15 <stealth222> I'm a little bit concerned about file name conflicts. For instance, if someone decides to name a wallet blkindex.dat or bitcoin.conf
283 2012-12-27 08:42:40 <stealth222> I guess appending the .dat means it can't conflict with the latter
284 2012-12-27 08:43:11 <sipa> then don't allow generic names
285 2012-12-27 08:43:20 <sipa> name the files wallet-<name>.dat
286 2012-12-27 08:43:49 <stealth222> yeah, that's a good idea
287 2012-12-27 08:43:56 <t7> .wallet
288 2012-12-27 08:44:00 <stealth222> what about the valid character set?
289 2012-12-27 08:44:26 <stealth222> we need to test for that as well
290 2012-12-27 08:44:32 <sipa> good idea
291 2012-12-27 08:44:52 <sipa> [a-zA-Z0-9_] ?
292 2012-12-27 08:44:56 <sipa> that's maybe too strict
293 2012-12-27 08:45:08 <stealth222> dots and dashes should be allowed, too
294 2012-12-27 08:45:15 <stealth222> well
295 2012-12-27 08:45:18 <stealth222> single dots
296 2012-12-27 08:45:22 <stealth222> double dots are a problem
297 2012-12-27 08:45:32 <sipa> colons?
298 2012-12-27 08:45:46 <stealth222> some file systems might not like that, huh?
299 2012-12-27 08:45:58 <sipa> windows stuff, indeed
300 2012-12-27 08:46:06 <stealth222> spaces are sort of a problem, too
301 2012-12-27 08:46:19 <stealth222> it's annoying to have to put filenames in quotes all the time
302 2012-12-27 08:46:26 <stealth222> when typing at the command line
303 2012-12-27 08:46:51 <stealth222> so yeah, [a-zA-Z0-9_] sounds reasonable
304 2012-12-27 08:47:15 <sipa> better be strict at first; expanding possibilities later is easier than taking them away
305 2012-12-27 08:49:22 <stealth222> how will this work in other languages?
306 2012-12-27 08:49:37 <stealth222> and is that much of a concern right now?
307 2012-12-27 08:49:41 <stealth222> localization stuff
308 2012-12-27 08:51:03 <stealth222> ah, screw em :p
309 2012-12-27 08:51:33 <SomeoneWeird> [a-zA-Z0-9\\-_\\.] ?
310 2012-12-27 08:51:46 <stealth222> multiple dots are a problem
311 2012-12-27 08:51:48 <stealth222> ..
312 2012-12-27 08:51:56 <sipa> SomeoneWeird: not a valid regexp :)
313 2012-12-27 08:52:05 <SomeoneWeird> regexpal says otherwise
314 2012-12-27 08:52:09 <sipa> well, it won't mean what you want
315 2012-12-27 08:52:30 <sipa> you mean [a-zA-Z0-9.-], i think
316 2012-12-27 08:52:41 <SomeoneWeird> ?
317 2012-12-27 08:53:31 <stealth222> what about substituting spaces in the name presented to the user with underscores in the filename?
318 2012-12-27 08:53:34 <stealth222> and vice versa
319 2012-12-27 08:53:40 <sipa> stealth222: details!
320 2012-12-27 08:53:43 <stealth222> lol
321 2012-12-27 08:53:51 <sipa> don't worry about those now
322 2012-12-27 08:53:52 <SomeoneWeird> > (new RegExp(/[a-zA-Z0-9\\-_\\.]/)).exec("hello_-.")
323 2012-12-27 08:53:53 <SomeoneWeird> [ 'h',
324 2012-12-27 08:53:54 <SomeoneWeird> works fine
325 2012-12-27 08:54:09 <SomeoneWeird> owell
326 2012-12-27 08:54:32 <sipa> hmm, i didn't think you could escape - in character classes, but it makes sense
327 2012-12-27 08:55:16 <stealth222> then there's the default wallet, whose file should still be called wallet.dat for the sake of compatibility
328 2012-12-27 08:55:24 <sipa> indeed
329 2012-12-27 08:55:54 <stealth222> should we call it "default"? or ""
330 2012-12-27 08:55:57 <stealth222> lol
331 2012-12-27 08:56:34 <stealth222> perhaps we call it "" and require user-created wallets to have at least one character in the name
332 2012-12-27 08:57:10 <stealth222> but as you say, details :p
333 2012-12-27 08:57:31 <sipa> indeed
334 2012-12-27 09:00:28 <Luke-Jr> or "wallet"? <.<
335 2012-12-27 09:01:25 <epscy> limiting to 10 connections does seem to prevent memory errors on my openvz vm
336 2012-12-27 09:05:43 <unassigned> sipa: can you release the patch you mentioned there: https://bitcointalk.org/index.php?topic=107172.msg1333777#msg1333777
337 2012-12-27 09:07:37 <sipa> unassigned: in its current form it's not really usable (it was just something hacked onto the gettxoutinfo RPC command to dump that info in a file)
338 2012-12-27 09:07:43 <sipa> but it's trivial to write
339 2012-12-27 09:08:16 <unassigned> ok
340 2012-12-27 10:06:39 <stealth222> another idea is to automatically check for any file in the directory named wallet-[a-zA-Z0-9_]*\\.dat and try to load it
341 2012-12-27 10:07:30 <stealth222> then if you don't want that wallet to load next startup, you can either rename it to nonwallet-blah or move the file to another directory
342 2012-12-27 10:08:04 <stealth222> the config file can override this
343 2012-12-27 10:08:17 <stealth222> nousewallet=blah
344 2012-12-27 10:12:32 <stealth222> or if any usewallet clauses exist in the config file, only those stated in the config file load. otherwise, any file named wallet-[a-zA-Z0-9_]*\\.dat is loaded
345 2012-12-27 10:13:16 <stealth222> and wallet.dat is always loaded no matter what
346 2012-12-27 10:25:02 <stealth222> the access control information could be stored inside the wallet file itself
347 2012-12-27 10:43:27 <TD> gah
348 2012-12-27 10:43:28 <TD> ************************
349 2012-12-27 11:04:52 <sipa> gmaxwell, tcatm: k=0 has been reused 453 times...
350 2012-12-27 11:05:24 <stealth222> lol - someone really messed up with that device
351 2012-12-27 11:05:29 <stealth222> I hope it's only small amounts
352 2012-12-27 11:05:52 <sipa> gmaxwell, tcatm: sorry, reused for 453 keys
353 2012-12-27 11:06:11 <sipa> TD: eww
354 2012-12-27 11:06:32 <TD> oh ffs. and now i can't build the latest git anymore. the qt problem came back
355 2012-12-27 11:06:36 <TD> 
ACTION stabs qt and macos x

356 2012-12-27 11:06:57 <TD> sipa: really? wtf? any idea what is creating those keys?
357 2012-12-27 11:07:23 <TD> s/wtf?// ???. it is actually not so surprising. i told someone months ago i was expecting to see a major crypto related fail in the next year
358 2012-12-27 11:09:41 <Luke-Jr> TD: supposedly BitcoinJ ;)
359 2012-12-27 11:10:07 <TD> seriously?
360 2012-12-27 11:10:20 <Luke-Jr> I haven't been following it 100%, but I saw that thrown around a little
361 2012-12-27 11:10:30 <TD> hmm. bcj just uses bouncy castle
362 2012-12-27 11:10:40 <Luke-Jr> TD: you seen https://bitcointalk.org/index.php?topic=133122 ?
363 2012-12-27 11:10:51 <TD> yes
364 2012-12-27 11:10:53 <Luke-Jr> TD: this address happens to also be on gmaxwell's list I think
365 2012-12-27 11:13:19 <TD> i wonder if there's some kind of error in the way i'm using bouncy castle
366 2012-12-27 11:14:20 <TD> looking at the bouncy castle code, it doesn't seem like there's any issue there.
367 2012-12-27 11:14:33 <TD> at least, assuming that the jvm used follows the specs
368 2012-12-27 11:16:16 <epscy> what is k=0
369 2012-12-27 11:16:16 <TD> oh, this is code written by nyhm? he does seem remarkably keen on shipping obfuscated closed source apps
370 2012-12-27 11:16:36 <TD> i wonder what happens if you constantly drain SecureRandom of entropy in bulk.
371 2012-12-27 11:16:48 <TD> epscy: means broken crypto
372 2012-12-27 11:17:18 <epscy> right
373 2012-12-27 11:17:23 <epscy> i got that bit
374 2012-12-27 11:17:29 <epscy> where is it used in bitcoin
375 2012-12-27 11:20:16 <TD> elliptic curve cryptography requires the use of large random numbers at points
376 2012-12-27 11:20:42 <stealth222> pretty much all cryptography requires the use of large random numbers nowadays
377 2012-12-27 11:21:15 <stealth222> if a number is not random, then by definition it is easy for an attacker to guess
378 2012-12-27 11:21:21 <TD> epscy: if you don't randomize properly, you can find the private key from a public key
379 2012-12-27 11:22:15 <TD> it looks like SecureRandom uses /dev/urandom not /dev/random
380 2012-12-27 11:22:17 <TD> interesting
381 2012-12-27 11:22:18 <stealth222> yeah, in the case of ECDSA each signature requires a different k
382 2012-12-27 11:22:24 <TD> Luke-Jr: where is gmaxwells list?
383 2012-12-27 11:22:30 <TD> and/or discussion
384 2012-12-27 11:23:07 <stealth222> TD: http://people.xiph.org/~greg/rvals.txt
385 2012-12-27 11:23:40 <epscy> ECDSA is used for bitcoin addresses right?
386 2012-12-27 11:23:49 <stealth222> yes
387 2012-12-27 11:23:54 <epscy> i see
388 2012-12-27 11:24:26 <epscy> so how do you check this?
389 2012-12-27 11:24:34 <stealth222> if you use the same k in two different signatures, you're basically giving an attacker two equations which can be solved
390 2012-12-27 11:24:37 <epscy> is this on the test server?
391 2012-12-27 11:25:16 <stealth222> how do you check what?
392 2012-12-27 11:25:37 <epscy> somone said k had been zero 463 times
393 2012-12-27 11:26:38 <stealth222> search for "It is crucial to select different" here: http://en.wikipedia.org/wiki/Elliptic_Curve_DSA
394 2012-12-27 11:27:01 <stealth222> it reduces an inverse log problem to a simple algebraic one
395 2012-12-27 11:27:19 <stealth222> or a discrete log problem, rather
396 2012-12-27 11:28:33 <stealth222> or technically, the inverse of EC multiplication
397 2012-12-27 11:28:41 <stealth222> but the concept is essentially the same
398 2012-12-27 11:29:22 <TD> i can't see any way k could end up zero in bitcoinj
399 2012-12-27 11:29:32 <TD> the code in bouncy castle and the way it's used is quite straightforward
400 2012-12-27 11:30:20 <TD> sipa: the corruption was after a system freeze and kernel panic on reboot. quite messy. so i'm not totally surprised leveldb got corrupted, i think bdb would have done too.
401 2012-12-27 11:30:30 <TD> sipa: the question is, can it fix itself when we run the magic "fix yoursef" function
402 2012-12-27 11:31:16 <epscy> stealth222: i still don't understand why or where you have discovered this problem
403 2012-12-27 11:31:30 <stealth222> I didn't discover it
404 2012-12-27 11:31:36 <epscy> i can only assume you have generated a bunch of addresses and kept track of k for each one
405 2012-12-27 11:31:46 <epscy> well yeah, not you in particular
406 2012-12-27 11:31:56 <epscy> you guys generally
407 2012-12-27 11:32:03 <stealth222> no, the whole point here is that you don't need to know k a priori
408 2012-12-27 11:32:29 <sipa> TD: suspect is bitcoincard
409 2012-12-27 11:32:31 <stealth222> knowing two signatures and that they were signed with the same key and the same k is sufficient to algebraically solve for k and the private key
410 2012-12-27 11:32:43 <sipa> TD: gmaxwell suspected BCJ for a minute, but that was a mistake
411 2012-12-27 11:32:45 <TD> ok
412 2012-12-27 11:33:21 <stealth222> epscy: you could just test a bunch of signatures signed by the same key to see if it's the same k
413 2012-12-27 11:33:24 <sipa> TD: tcatm detected that several signatures reused R values; gmaxwell made an exhaustive list, and i wrote some code to find the reused K value from that
414 2012-12-27 11:33:47 <stealth222> like sipa just said :)
415 2012-12-27 11:33:55 <sipa> apparently most of them are just 0
416 2012-12-27 11:34:01 <epscy> how did tcatm detect that
417 2012-12-27 11:34:14 <epscy> sorry if i sound dumb
418 2012-12-27 11:34:18 <sipa> (though there is are some K values that are reused but look still random)
419 2012-12-27 11:34:28 <epscy> i am just trying to understand how you discovered this problem
420 2012-12-27 11:36:19 <stealth222> is tcatm running some monitoring tools on the network to detect these kinds of patterns?
421 2012-12-27 11:45:31 <sipa> i think he went looking for it specifically
422 2012-12-27 11:47:17 <sipa> TD: even when a system crashes it should end up in a recoverable state... maybe recent writes are lost, but old state shouldn't be damaged (in theory...)
423 2012-12-27 11:50:13 <sipa> stealth222: actually, in order to find K, you must find two signatures with the same R; so i wrote some code that remembers all signatures, indexed by R
424 2012-12-27 11:50:20 <sipa> and then did a -reindex
425 2012-12-27 11:51:09 <TD> yeah
426 2012-12-27 11:51:32 <TD> in theory, practice and theory are the same. in practice, they aren't
427 2012-12-27 12:00:13 <sipa> TD: i believe tcatm found out there was about 1 BTC in utxo's associated to a vulnerable address
428 2012-12-27 12:02:11 <sipa> epscy: how he detected it... by looking at them; i guess  /p
429 2012-12-27 12:12:04 <epscy> sipa: right, but then he should know which client generated the addresses no?
430 2012-12-27 12:24:07 <sipa> epscy: how so?
431 2012-12-27 12:24:48 <epscy> ok, lets go through this
432 2012-12-27 12:24:53 <epscy> i have a bitcoin address
433 2012-12-27 12:24:57 <epscy> and a private key
434 2012-12-27 12:25:04 <epscy> how do i know what k was
435 2012-12-27 12:25:19 <sipa> k is not part of the key, it's part of the signature
436 2012-12-27 12:25:39 <epscy> oh ok, so this when you sign a transaction?
437 2012-12-27 12:25:45 <sipa> so you look at the signatures in txins in the blockchain, and look for R values (a signature consists of R and S) that are repeated
438 2012-12-27 12:25:59 <sipa> yes, that's the problem with ECDSA: it requires a good RNG when _signing_
439 2012-12-27 12:26:25 <epscy> and it is possible to look at public txes and determine what k was?
440 2012-12-27 12:27:00 <sipa> if two signatures of a different message (=different transaction) are made with the same private key and the same K, K is recoverable
441 2012-12-27 12:27:32 <epscy> ok thanks, i understand now
442 2012-12-27 12:28:26 <sipa> and if you have K, the signature and the message, you can recover the private key
443 2012-12-27 12:28:54 <epscy> so k needs to be different every time
444 2012-12-27 12:28:58 <sipa> indeed
445 2012-12-27 12:29:01 <epscy> to be secure?
446 2012-12-27 12:29:18 <sipa> and one trick is to use SHA256(private key + transaction) as K
447 2012-12-27 12:29:31 <sipa> since we rely on SHA256's strength already anyway
448 2012-12-27 12:29:59 <epscy> hmmm is that random enough though?
449 2012-12-27 12:30:20 <epscy> i suppose the randomness there mostly comes from the private key
450 2012-12-27 12:30:21 <sipa> if it's not in a detectable, SHA256 is horribly broken
451 2012-12-27 12:30:50 <sipa> a cryptographic hash function has the property that given the hash you can infer nothing at all about the input
452 2012-12-27 12:31:38 <epscy> yes but obviously if you has the same thing twice you should get the same hash
453 2012-12-27 12:32:13 <epscy> same result for the hashing the same thing twice
454 2012-12-27 12:32:17 <epscy> i mean
455 2012-12-27 12:32:42 <sipa> sure
456 2012-12-27 12:33:07 <sipa> if the premise is that there is a problem if you sign two different messages with the same private key and the same K
457 2012-12-27 12:33:30 <sipa> this function guarantees that two different messages will get a different K
458 2012-12-27 12:33:39 <epscy> i see
459 2012-12-27 12:34:20 <epscy> i'm just wondering if the transaction part is always guaranteed to be unique
460 2012-12-27 12:34:31 <epscy> so say i send someone 1 bitcoin
461 2012-12-27 12:34:36 <epscy> and then i do it again
462 2012-12-27 12:34:43 <upb> why are you even bothering to understand this in this way ?
463 2012-12-27 12:34:54 <epscy> to the same address
464 2012-12-27 12:34:54 <upb> rtfspecs
465 2012-12-27 12:35:20 <sipa> epscy: es, the transction will be different, as it uses different input coins
466 2012-12-27 12:35:29 <sipa> *yes
467 2012-12-27 12:35:33 <epscy> sipa: right, i see
468 2012-12-27 12:35:46 <sipa> if it wasn't, bitcoin had a problem
469 2012-12-27 12:36:34 <sipa> that would mean if you sent coins from X to Y, i could broadcast your transaction again to have the same amount transferred a second time
470 2012-12-27 12:36:44 <sipa> that is not how it works
471 2012-12-27 12:36:57 <epscy> yes would allow double spending
472 2012-12-27 12:37:05 <t7> not the same
473 2012-12-27 12:37:06 <epscy> thanks for your help
474 2012-12-27 12:37:12 <sipa> not double spending
475 2012-12-27 12:37:29 <t7> repeat spend?
476 2012-12-27 12:37:34 <epscy> oh cos it would go to the same address
477 2012-12-27 12:37:42 <sipa> something like that, yes
478 2012-12-27 12:38:15 <sipa> no because it still wouldn't allow spending the same amount twice
479 2012-12-27 12:38:52 <t7> double receive
480 2012-12-27 12:39:03 <sipa> if i have 1 BTC, and i transfer it to you, there is no way i can transfer it again
481 2012-12-27 12:39:08 <epscy> sounds like it would bloat the blockchain
482 2012-12-27 12:40:03 <sipa> what it would allow, is of i have 2 BTC, and I send you 1 BTC, you'd repeat the transaction to get another 1 BTC from me
483 2012-12-27 12:40:29 <stealth222> should all file system utility functions go in util.h/util.cpp?
484 2012-12-27 12:40:49 <sipa> but that is why bitcoin uses "from coins", not "from addresses"
485 2012-12-27 12:40:58 <sipa> stealth222: what kind?
486 2012-12-27 12:41:29 <stealth222> well, say I want a function that returns all the files at a given path - or a function that returns all files at a given path that match a regex
487 2012-12-27 12:41:59 <t7> isnt that in boost?
488 2012-12-27 12:42:02 <sipa> boost has that, no need for a wrapper
489 2012-12-27 12:42:12 <stealth222> in a single function call?
490 2012-12-27 12:42:13 <stealth222> really?
491 2012-12-27 12:42:29 <stealth222> I'm using boost - but it takes at least a few lines of code to do that - lol
492 2012-12-27 12:42:31 <sipa> no, but it has iterators over elemwnta of a durectory
493 2012-12-27 12:42:37 <stealth222> yes, I'm using that
494 2012-12-27 12:42:42 <sipa> my god, my typing
495 2012-12-27 12:43:10 <stealth222> point is I don't want my code to be peppered with a bunch of copy(boost::filesystem::directory_iterator(p), boost::filesystem::directory_iterator(), back_inserter(vPaths));
496 2012-12-27 12:43:22 <stealth222> I'd rather call something like GetFilesAtPath(p)
497 2012-12-27 12:43:34 <sipa> meh, you can put it in util then
498 2012-12-27 12:43:38 <stealth222> :)
499 2012-12-27 12:44:17 <sipa> it's mostly for platform dependemt stuff
500 2012-12-27 12:44:33 <sipa> and some random things that ended up there
501 2012-12-27 12:45:12 <sipa> reminds me to clean it up
502 2012-12-27 12:51:05 <stealth222> I also took the liberty of adding lboost_regex to the makefiles. hope that's ok
503 2012-12-27 12:52:16 <sipa> why?
504 2012-12-27 12:52:29 <stealth222> because otherwise my code won't link :p
505 2012-12-27 12:52:45 <sipa> (not really a problem if it's needed, but in general adding dependencies - even boost things - can be a pain)
506 2012-12-27 12:53:06 <stealth222> yeah, that's why I ask. I'd rather not add dependencies...but the alternative is to implement the pattern matching from scratch
507 2012-12-27 12:53:51 <sipa> it's not particularly hard to check whether it starts with wallet_, ends with .dat, and the rest strspn()'s a list of chracters?
508 2012-12-27 12:54:11 <sipa> it's maybe even less code that using a boost regexp for that :p
509 2012-12-27 12:54:20 <stealth222> it's not particularly difficult to do - of course it isn't. but boost regexp is one line of code
510 2012-12-27 12:54:27 <sipa> ok
511 2012-12-27 12:54:44 <stealth222> boost::regex_match(strName, WALLET_NAME_REGEX);
512 2012-12-27 12:54:47 <sipa> ok
513 2012-12-27 12:54:47 <stealth222> lol
514 2012-12-27 12:55:16 <stealth222> if it were some completely unrelated library to anything we're already using, I'd be all for just writing my own pattern matcher
515 2012-12-27 12:55:17 <sipa> so you'll just load all wallets in the datadir?
516 2012-12-27 12:55:22 <stealth222> yeah
517 2012-12-27 12:55:33 <sipa> makes
518 2012-12-27 12:55:36 <sipa> makes sense
519 2012-12-27 12:55:43 <stealth222> unless overridden by config file or command line params
520 2012-12-27 12:55:56 <sipa> somehow i envisioned just putting the list of wallets you wanted in the config file
521 2012-12-27 12:56:04 <stealth222> that's what I already had
522 2012-12-27 12:56:20 <sipa> and afterwards, if there was a need, add stuff to manage it dynamically
523 2012-12-27 12:56:37 <stealth222> the stuff to manage it dynamically is practically in place
524 2012-12-27 12:56:55 <sipa> adding more features may make it harder to get it merged :)
525 2012-12-27 12:57:00 <sipa> but still, it makes sense
526 2012-12-27 13:04:55 <stealth222> another thing that would be really nice to clean up is the exception handling
527 2012-12-27 13:05:38 <sipa> hmm?
528 2012-12-27 13:05:44 <sipa> what do you suggest?
529 2012-12-27 13:06:05 <stealth222> well, some parts of the app have decent exception handling
530 2012-12-27 13:06:14 <stealth222> but others are horrendous - like init.cpp
531 2012-12-27 13:07:52 <stealth222> in trying to pull out the wallet loading stuff from InitApp2, I'm finding it a little difficult to isolate the semantics from the presentation to the user
532 2012-12-27 13:08:25 <stealth222> the debug messages are all printfs and the error messages are added to an ostringstream
533 2012-12-27 13:09:06 <sipa> right
534 2012-12-27 13:09:17 <sipa> wallet loading code should definitely be separated from the rest
535 2012-12-27 13:09:53 <sipa> i suppose you can abstract that into a InitWallet, which loads one wallet, and registers it
536 2012-12-27 13:10:12 <stealth222> I already wrote CWalletMap::LoadWallet
537 2012-12-27 13:10:14 <stealth222> which does that
538 2012-12-27 13:10:28 <stealth222> but I'm still cleaning up the I/O
539 2012-12-27 13:11:12 <stealth222> it's nice to be able to monitor it as it happens - but right now as it is the method depends on custom UI functions
540 2012-12-27 13:11:31 <stealth222> and calls printf and stuff
541 2012-12-27 13:11:54 <sipa> maybe you need to talk with wumpus about how to deal with the UI stuff
542 2012-12-27 13:12:08 <stealth222> is that what he's doing?
543 2012-12-27 13:12:29 <sipa> well he wrote the GUI and manages that part of the codebase
544 2012-12-27 13:13:04 <stealth222> I'm thinking it would be nice to be able to report events as they occur to some dispatcher which then handles pushing alerts to the GUI or writing stuff out to the log file
545 2012-12-27 13:13:05 <sipa> as a wallet used to be a per-application global, but now it becomes something separate
546 2012-12-27 13:13:34 <sipa> that's what CClientInterface exists for
547 2012-12-27 13:13:44 <sipa> but i'm not very up-to-date with the developments there
548 2012-12-27 13:14:02 <stealth222> but the wallet classes shouldn't have to know about CClientInterface
549 2012-12-27 13:14:14 <sipa> agree
550 2012-12-27 13:14:52 <sipa> there are some per-wallet signal handlers as well
551 2012-12-27 13:15:02 <sipa> but they are only for reporting changed transactions now
552 2012-12-27 13:15:55 <sipa> wallet reporting stuff should probably move there, i guess
553 2012-12-27 13:16:00 <sipa> but really, talk to wumpus
554 2012-12-27 13:16:03 <stealth222> ok
555 2012-12-27 13:18:41 <stealth222> bitcoinrpc has not-too-terrible exception handling
556 2012-12-27 13:18:54 <stealth222> I'd like to maybe add a few more error codes
557 2012-12-27 13:19:22 <sipa> if you look closer, they are a mess :)
558 2012-12-27 13:19:45 <stealth222> well, the current usage is a mess - but the framework isn't unsalvageable
559 2012-12-27 13:20:06 <JWU42> well - my earlier comments about better mem usage in 0.7.2 were a bit premature :/
560 2012-12-27 13:20:32 <JWU42> 1.3G after 4 days (maybe 5 days)
561 2012-12-27 13:20:41 <sipa> JWU42: nothing changed wrt memory usage between 0.7.1 and 0.7.2
562 2012-12-27 13:20:58 <JWU42> sipa: ok - then I should have expected noting then =)
563 2012-12-27 13:21:10 <sipa> JWU42: if you want to limit memory usage, limit the number of connections
564 2012-12-27 13:21:12 <JWU42> after 6-12 hours it seemed much better
565 2012-12-27 13:21:44 <JWU42> sipa: OK - that is what I figured drove usage.  Connections get upwards of 100 and mem usage climbs
566 2012-12-27 13:22:01 <sipa> yeah, most of the memory is just network buffers
567 2012-12-27 13:22:12 <JWU42> thank you for the response!
568 2012-12-27 13:22:18 <sipa> limit the size of the buffers and the number of connections
569 2012-12-27 13:22:37 <JWU42> and appreciate your continued efforts!
570 2012-12-27 13:22:47 <JWU42> I'll have to do some googling on that (limiting)
571 2012-12-27 13:23:06 <JWU42> found it ;)
572 2012-12-27 13:23:23 <sipa> my receive buffer is limit to 1200, send buffer is 1600, i have 83 connections and bitcoind uses 428 MB of ram
573 2012-12-27 13:23:51 <JWU42> if you are mining against the bitcoind how would that impact mem usage ?
574 2012-12-27 13:24:09 <sipa> almost nothing
575 2012-12-27 13:24:14 <JWU42> hrm
576 2012-12-27 13:24:44 <sipa> with getblocktemplate(), it should be actually 0
577 2012-12-27 13:24:57 <JWU42> using stratum ;)
578 2012-12-27 13:25:00 <sipa> with getwork(), there is some overhead as block data is kept server side
579 2012-12-27 13:25:10 <JWU42> 
ACTION nods

580 2012-12-27 13:25:15 <sipa> stratum... against slush's pool?
581 2012-12-27 13:25:32 <JWU42> sipa: nope - solo mining with stratum-mining
582 2012-12-27 13:25:34 <sipa> because then you don't need a bitcoind at all
583 2012-12-27 13:25:36 <sipa> ah, ok
584 2012-12-27 13:25:41 <JWU42> not all the time but the pool is running
585 2012-12-27 13:25:44 <sipa> the stratum proxy uses getblocktemplate() afaik
586 2012-12-27 13:25:49 <sipa> so the memory overhead should be 0
587 2012-12-27 13:25:58 <JWU42> yeah - not running the proxy...
588 2012-12-27 13:26:03 <sipa> well, proxy, or whatever it's called
589 2012-12-27 13:26:14 <JWU42> https://github.com/generalfault/stratum-mining
590 2012-12-27 13:26:19 <sipa> yeah, that :)
591 2012-12-27 13:26:20 <JWU42> just FYI
592 2012-12-27 13:26:34 <JWU42> it is slush's pool stuff with DB things added
593 2012-12-27 13:26:55 <JWU42> will tyr the send/recv buffer tweaks and see how that works
594 2012-12-27 13:26:58 <JWU42> thks again
595 2012-12-27 14:29:25 <MC1984> who runs that testnet faucet?
596 2012-12-27 14:30:03 <MC1984> its only supposed to give away 50 coin but i just got another 50 by refreshing the page.......
597 2012-12-27 14:30:13 <MC1984> someone could empty it relly easy
598 2012-12-27 14:31:06 <MC1984> http://tpfaucet.appspot.com/ that one
599 2012-12-27 14:41:43 <TD> sipa: ping
600 2012-12-27 14:42:08 <TD> sipa: negative S/R values in signatures.  i thought openssl always interprets these values as positive, in violation of the spec
601 2012-12-27 14:42:15 <TD> so what does that mean exactly?
602 2012-12-27 14:42:45 <gmaxwell> TD: It means they're positive, in violation of the spec.
603 2012-12-27 14:43:07 <gmaxwell> More importantly it means that third parties can modify your transactions.
604 2012-12-27 14:43:36 <TD> i'm confused. the page says the transactions have negative S/R values. you just said it means they're positive. what are you referring to?
605 2012-12-27 14:43:57 <TD> oh, i see
606 2012-12-27 14:43:58 <gmaxwell> TD: they're encoded with negative values. Openssl is broken and treats them as positive.
607 2012-12-27 14:44:04 <gmaxwell> So they still work.
608 2012-12-27 14:44:06 <TD> http://r6.ca/blog/20111119T211504Z.html
609 2012-12-27 15:18:47 <TD> oh ffs. i can't believe the stupid build has broken for me again
610 2012-12-27 15:19:05 <MC1984> umm the testnet is confirming really fast
611 2012-12-27 15:36:04 <kjj> so...  I'm trying to make sense of the binary format of the signatures.
612 2012-12-27 15:41:14 <kjj> the tangled mess of encoding schemes kinda sucks, but I think I understand it now
613 2012-12-27 15:44:03 <kjj> the signature seems to be a DER encoding of R and S, but I can make no sense of the final 0x01 byte tacked onto the end
614 2012-12-27 15:44:45 <TD> sighash flag
615 2012-12-27 15:44:48 <TD> see the code
616 2012-12-27 15:45:47 <kjj> ok, so the sighash flag is just appended after the end of the DER part?
617 2012-12-27 15:48:31 <TD> yeah
618 2012-12-27 15:49:31 <sipa> TD: it basically means the R or S values miss the padding zero byte in front
619 2012-12-27 15:49:54 <sipa> TD: but OpenSSL interprets everything as positive anyway, so it works, in violation of the spec
620 2012-12-27 15:50:07 <TD> yeah
621 2012-12-27 15:50:19 <kjj> ahh.  now it makes sense
622 2012-12-27 15:51:21 <TD> sipa: from the error message i'm getting, it seems like a part of the logfile went missing from the middle
623 2012-12-27 15:51:34 <TD> i wonder if it's safe to just blow away the logfile
624 2012-12-27 15:51:43 <sipa> yeah, log truncation is a bitch
625 2012-12-27 15:51:54 <sipa> i frequently run with -debug to avoid that
626 2012-12-27 15:52:15 <TD> what does -debug do
627 2012-12-27 15:52:19 <TD> it doesn't seem to be truncation
628 2012-12-27 15:52:24 <TD> literally, bits went missing from the middle
629 2012-12-27 15:52:41 <sipa> oh
630 2012-12-27 15:52:47 <sipa> -debug disables log truncation
631 2012-12-27 15:53:00 <sipa> but truncation is dropping the first part, not stuff in the middle
632 2012-12-27 15:53:37 <kjj> so, basically in DER, the correct encoding for 255 is 020200FF, because 0201FF is -1
633 2012-12-27 15:53:49 <sipa> correct
634 2012-12-27 15:54:39 <TD> actually, i just renamed the LOG and LOG.old files, and got the same error
635 2012-12-27 15:54:55 <TD> so maybe it says that even when truncation/deletion has occurred
636 2012-12-27 15:55:08 <stealth222> in order to make dynamic wallet loading/unloading thread-safe, do we need to place locks around each and every wallet method?
637 2012-12-27 15:55:23 <TD> yeah the LOG files are empty
638 2012-12-27 15:55:43 <TD> hm
639 2012-12-27 15:56:34 <sipa> stealth222: the goal is to push down the locking into the appropriate public methods of wallet/blockchain/... interfaces, but right now, the RPC system takes the locks on inner structures (cs_main and cs_wallet) as necessary (and over-eagerly)
640 2012-12-27 15:57:03 <sipa> stealth222: multi wallet shouldn't change that - RPCs will just lock cs_main plus the cs of the selected wallet
641 2012-12-27 15:57:07 <stealth222> that's what I was noticing. So the RPC is the only way that these methods can be invoked, yes?
642 2012-12-27 15:57:23 <stealth222> other than the init stuff
643 2012-12-27 15:57:31 <sipa> not necessarily, but other places should takes locks as necessary, so don't worry
644 2012-12-27 15:57:47 <sipa> callbacks from main, for example
645 2012-12-27 15:58:05 <stealth222> so as long as I lock all wallet deletes with cs of wallet everything should be ok?
646 2012-12-27 15:58:12 <stealth222> err
647 2012-12-27 15:58:14 <stealth222> I mean
648 2012-12-27 15:58:18 <stealth222> with cs_main
649 2012-12-27 15:58:54 <sipa> you'll probably want a CS on CWalletList or hoz did you call it, that is takes to make changes to the _list_ of wallets
650 2012-12-27 15:58:54 <stealth222> can't use a critical section in an object that's being deleted :p
651 2012-12-27 15:59:04 <TD> hm
652 2012-12-27 15:59:11 <TD> RepairDB() did indeed do something
653 2012-12-27 15:59:26 <stealth222> ok, makes sense, sipa
654 2012-12-27 15:59:30 <sipa> TD: i plan to write coindb error checking one of the next days
655 2012-12-27 15:59:59 <sipa> TD: did it do something, or did it do what you hoped? :)
656 2012-12-27 16:02:34 <TD> well
657 2012-12-27 16:02:37 <TD> it worked
658 2012-12-27 16:02:44 <TD> i'm not sure it's safe in the general case though
659 2012-12-27 16:02:48 <TD> RepairDB can delete data
660 2012-12-27 16:02:58 <TD> if you delete data from the coinsdb then it will appear coins are spent when they are not
661 2012-12-27 16:03:37 <TD> it might be better to rebuild the databases from the blk files if there are ever any problems
662 2012-12-27 16:04:04 <sipa> the idea i have about coindb checking is doing an in-memory rollback of the database (using undo data, disconnecting the last few blocks), with paranoid checks on the consistency
663 2012-12-27 16:04:31 <sipa> perhaps if repairdb is needed, it could be attempted, but automatically force a much larger rollback during checking
664 2012-12-27 16:04:55 <MC1984> what does it mean when a payee address box turns red
665 2012-12-27 16:05:04 <MC1984> does it mean malformed address?
666 2012-12-27 16:05:27 <sipa> i suppose
667 2012-12-27 16:06:04 <TD> probably best to just reindex from scratch and play it safe
668 2012-12-27 16:07:24 <MC1984> oh that guy has a mainnet address asking to donate testnet coins :/
669 2012-12-27 16:09:54 <sipa> TD: well leveldb does have checksums... the chance for getting actually corrupted data is small imho - compared to the risk of getting trimmed or outdated data
670 2012-12-27 16:10:17 <sipa> and those should be easier to detect, especially as you expect those to happen on stuff that was recently written??
671 2012-12-27 16:11:14 <sipa> sure, reindexing is safer, and maybe should be recommended, but not everyone will accept the time that takes, afaik
672 2012-12-27 16:11:16 <gmaxwell> Right now just deleting parts of the coins databases can cause it to just get stuck, which is quite perplexing. :)
673 2012-12-27 16:12:02 <sipa> yeah; that shouldn't happen, but i suppose a rollback check will catch that quickly
674 2012-12-27 16:15:00 <sipa> TD: partly as a hack, if you just delete the coins subdir, it will rebuild it at startup (not in the background, but it's faster than -reindex)
675 2012-12-27 16:15:39 <sipa> afk
676 2012-12-27 16:22:45 <stealth222> when should I use LOCK and when should I use LOCK2?
677 2012-12-27 16:23:49 <stealth222> there's some documentation on it in coding.txt - just want to make sure I understand it correctly
678 2012-12-27 16:25:49 <stealth222> nvm, I think I get it
679 2012-12-27 16:45:38 <TD> i wasn't able to reproduce negative signature values with froyo. at least not on an emulator
680 2012-12-27 19:04:26 <r2p2> hey, not sure if I'm right here... started bitcoin-qt 3 days ago and since then it is syncronizing with network. and it seems to become exponential slower and slower while my hdd io from that process gets higher and higher. I that normal?
681 2012-12-27 19:13:35 <maaku> r2p2: unfortunately yes
682 2012-12-27 19:13:40 <maaku> this will be mostly fixed in 0.8
683 2012-12-27 19:15:15 <r2p2> ah I see, looking forward...
684 2012-12-27 21:08:35 <StarenseN> where & how bitcoin network will find its GH/s when all 21M BTC will be mined ?
685 2012-12-27 21:09:48 <sipa> fees
686 2012-12-27 21:10:56 <Joric> StarenseN, approx year 2140
687 2012-12-27 21:11:10 <StarenseN> my question was long term view Joric
688 2012-12-27 21:11:24 <StarenseN> so in 2140 is my question
689 2012-12-27 21:11:27 <StarenseN> :)
690 2012-12-27 21:11:38 <sipa> your question is why miners would keep mining if there is no subsidy left?
691 2012-12-27 21:11:45 <StarenseN> yes
692 2012-12-27 21:11:51 <sipa> the answer is: transaction fees, probably
693 2012-12-27 21:12:32 <StarenseN> core code is editable ?
694 2012-12-27 21:12:45 <upb> nope, it's read only
695 2012-12-27 21:12:53 <Joric> edible
696 2012-12-27 21:12:56 <sipa> you can see the source code, and you can submit patches
697 2012-12-27 21:13:15 <StarenseN> so is it possible to add transaction fees ?
698 2012-12-27 21:13:28 <sipa> "add" ?
699 2012-12-27 21:13:33 <JWU42> I love me some source code with gravy ;)
700 2012-12-27 21:13:35 <sipa> and you can verify (though it's a rather complicated process) that the released binaries are compiled from the published source code
701 2012-12-27 21:14:10 <StarenseN> add transaction fees for the miners in the code
702 2012-12-27 21:14:20 <sipa> it's been there since day one
703 2012-12-27 21:14:26 <sipa> it's part of the design
704 2012-12-27 21:14:27 <StarenseN> alright
705 2012-12-27 21:14:32 <StarenseN> didn't know that
706 2012-12-27 21:14:48 <Luke-Jr> StarenseN: you might want to read the paper before asking questions ;)
707 2012-12-27 21:14:51 <kjj> just out of curiosity, where did you learn about mining that didn't mention that?
708 2012-12-27 21:15:27 <StarenseN> i will but my english is not perfect to understand that technical paper
709 2012-12-27 21:16:09 <StarenseN> i didn't learned about mining, i wanted to understand globaly the dynamic
710 2012-12-27 21:16:25 <StarenseN> thanks
711 2012-12-27 21:20:20 <Joric> theres really no any rules everything can be changed over time just look at all those BIPs correct me if i'm wrong
712 2012-12-27 21:20:55 <sipa> Joric: some changes require a hard fork, which hasn't ever happened
713 2012-12-27 21:21:27 <sipa> but if near-everyone agrees on something, and there's enough time to roll it out, sure everything can change
714 2012-12-27 21:21:43 <Luke-Jr> Joric: changing the total available Bitcoins ever would be a violation of the social contract we all agreed to
715 2012-12-27 21:21:53 <Luke-Jr> sipa: that Feb change was a hardfork
716 2012-12-27 21:22:27 <sipa> Luke-Jr: meh, p2p level, not block validity level
717 2012-12-27 21:22:47 <Luke-Jr> true
718 2012-12-27 21:22:51 <sipa> in a way that's a hardfork, but it's hardly as dangerous as a block validity change
719 2012-12-27 21:23:10 <sipa> all that is needed is one client that is compatible with old and new nodes, and the network would have remained connected
720 2012-12-27 21:23:12 <andytoshi> sipa, how can you verify that the source matches the binary?
721 2012-12-27 21:23:33 <sipa> andytoshi: gitian; you can redo the deterministic build, to obtain a byte-for-byte identical binary
722 2012-12-27 21:23:36 <Joric> StarenseN, especially the policy about fees 0.0005 is totally random and will be changed thats for sure
723 2012-12-27 21:23:41 <andytoshi> oh, thanks
724 2012-12-27 21:23:43 <Luke-Jr> anyhow, IMO it'd be unjust to change the final Bitcoin count without unanimous agreement from all coin-holders
725 2012-12-27 21:24:12 <sipa> Luke-Jr: i assume that's something almost everyone agrees about, indeed
726 2012-12-27 21:25:16 <kjj> even if a large majority of the world wanted that, they'd have a hell of a time with it.  Most of the early adopters are of a libertarian-ish bent, and we would dump our holdings in their crappy fork the next day
727 2012-12-27 21:25:37 <kjj> and keep using the one true blockchain
728 2012-12-27 21:28:54 <Joric> one true blockchain to rule them all one blockchain to find them
729 2012-12-27 21:29:43 <D34TH> one blockchain to pay them all and in satoshi bind them
730 2012-12-27 21:30:05 <D34TH> s/satoshi/getwork ?
731 2012-12-27 21:31:57 <Joric> i honestly thought it's all 'mathematically sealed' or something finds out nope it's not
732 2012-12-27 21:32:16 <kjj> which part?
733 2012-12-27 21:32:25 <Luke-Jr> D34TH: getwork is deprecated by GBT
734 2012-12-27 21:32:36 <D34TH> Luke-Jr, it is too long
735 2012-12-27 21:32:40 <D34TH> to type
736 2012-12-27 21:32:45 <Luke-Jr> O.o
737 2012-12-27 21:32:59 <Luke-Jr> GBT <-- 4 keys
738 2012-12-27 21:33:25 <D34TH> len("GetBlockTemplate") != 4
739 2012-12-27 21:33:36 <Luke-Jr> that's what abbreviations are for
740 2012-12-27 21:33:57 <Eliel_> Luke-Jr: I see no problem changing the final bitcoin count, as long as it's implemented as scaling everyone's amounts equally :P
741 2012-12-27 21:34:17 <Luke-Jr> Eliel_: that's not changing the final amount, just making it divisible differently ;)
742 2012-12-27 21:35:13 <Joric> yeah there's no real need in that while bitcoin is divisible
743 2012-12-27 21:35:14 <Eliel_> yes, that's why it's acceptable. It doesn't effectively make any real changes.
744 2012-12-27 21:35:48 <Joric> yet some ppl apparently believe it's not
745 2012-12-27 21:37:13 <Joric> http://www.youtube.com/watch?feature=player_detailpage&v=FPebAr7ST-E#t=1577s <- "it has a deflationist nature because money tend to dissapear from bitcoin so it cannot work in the long run" :)
746 2012-12-27 21:37:23 <Joric> they all look so serious
747 2012-12-27 21:37:43 <kjj> meh.  I haven't seen even a single good argument in support of the "deflation is bad" theory
748 2012-12-27 21:42:07 <Luke-Jr> me either, it seems those people are always socialist in some way
749 2012-12-27 21:42:20 <Luke-Jr> comes down to some "saving money is bad" idea
750 2012-12-27 21:43:13 <Luke-Jr> (and if you punish the guy saving money, you basically enforce wage slavery and government welfare)
751 2012-12-27 21:43:23 <sipa> well "it discourages spending" is a reasonable argument, in my opinion
752 2012-12-27 21:43:37 <andytoshi> it discourages consumption, you mean?
753 2012-12-27 21:43:39 <sipa> doesn't mean it's right or weighs up against other things
754 2012-12-27 21:43:56 <Joric> haha well said andytoshi
755 2012-12-27 21:43:56 <sipa> i'm no economist and try to avoid making economic statements
756 2012-12-27 21:44:00 <andytoshi> 
ACTION goes looking up that 'hayek triangle' paper

757 2012-12-27 21:44:19 <andytoshi> ditto sipa, but i think i have a good argument about that spending comment
758 2012-12-27 21:44:31 <sipa> bitcoin is technology, and as such it may or may not provide a benefit to society, and i like working on that technology
759 2012-12-27 21:44:32 <andytoshi> if i can find it..
760 2012-12-27 21:44:43 <etotheipi_> and the current system discourages savings... yet we always tout the value of savings
761 2012-12-27 21:44:49 <etotheipi_> yet people still save
762 2012-12-27 21:44:52 <Luke-Jr> "it discourages spending" is only a problem for getting Bitcoin adopted IMO :P
763 2012-12-27 21:44:59 <etotheipi_> and consume
764 2012-12-27 21:45:08 <Joric> by a strange coincedence i have a bachelor degree in economics + a cs masters degree )
765 2012-12-27 21:45:12 <Luke-Jr> and in theory, we're supposed to be inflationary during adoption
766 2012-12-27 21:45:35 <Luke-Jr> (obviously that doesn't seem to be working out quite that way)
767 2012-12-27 21:46:08 <andytoshi> on "investment versus consumption",
768 2012-12-27 21:46:09 <andytoshi> http://www.auburn.edu/~garriro/b3beyond.htm
769 2012-12-27 21:46:28 <andytoshi> with the usual caveats about economists drawing straight lines and pretending they represent economic things..
770 2012-12-27 21:49:24 <andytoshi> that article is a bit hard to read..essentially it says that there is a continuum between capital goods (with long-term payoff) and consumption goods (with immediate payoff), and the effect of monetary policy is to shift the distribution of economic activity along that continuum
771 2012-12-27 21:49:52 <andytoshi> so the interest rate represents "how forward-looking society is"
772 2012-12-27 21:51:22 <andytoshi> once you frame the argument that way, you can then claim that a forward-looking society will tend to do research and infrastructure, and therefore become much wealthier than a consumption-based society
773 2012-12-27 21:51:46 <kjj> but that's making a silly assumption.  the symptom is not the cause
774 2012-12-27 21:52:19 <Luke-Jr> yeah, that reasoning sounds suspect to me too .<
775 2012-12-27 21:52:34 <andytoshi> well, if you're controlling the interest rate, you switch cause and effect
776 2012-12-27 21:53:20 <andytoshi> or rather, the interest rate is always correlated to the investment-vs-consumption continuum -- naturally, the rate would appear as a price indicator
777 2012-12-27 21:53:23 <andytoshi> "a symptom"
778 2012-12-27 21:53:37 <andytoshi> but if you control it, you can force the investment-vs-consumption continuum
779 2012-12-27 21:54:14 <kjj> only if you assume that the interest rate is the only (or at leat the dominant) factor in society's time-preference
780 2012-12-27 21:54:39 <andytoshi> kjj, right, that's an austrian thing
781 2012-12-27 21:54:44 <Luke-Jr> 
ACTION notes Catholics and Muslims assume interest is immoral.

782 2012-12-27 21:55:31 <andytoshi> that's what austrians say the interest rate -is- --- the price of delayed consumption
783 2012-12-27 21:56:14 <andytoshi> so the higher a price you charge for delayed consumption (i.e., the less you want to save), the shorter-term your time-preference
784 2012-12-27 21:57:03 <andytoshi> but maybe i'm way off-base -- like sipa, i'm into bitcoin for the technology, and it's been a long while since i cared about economics enough to study it
785 2012-12-27 21:58:20 <kjj> I'm a big fan of epistemology.  I tend to roll my eyes a lot when I talk to real economists
786 2012-12-27 21:58:32 <wizkid057> is there a way to tell bitcoind to rebuild it's index without pruning?
787 2012-12-27 21:58:46 <Luke-Jr> wizkid057: I don't think master even supports an unpruned index???
788 2012-12-27 21:59:14 <wizkid057> 
ACTION grumbles

789 2012-12-27 21:59:41 <wizkid057> going to have to write my own blkxxxx.dat parser... heh
790 2012-12-27 22:01:27 <sipa> current head has no index whatsoever
791 2012-12-27 22:01:45 <sipa> it has a pruned *copy* of the UTXO set
792 2012-12-27 22:02:08 <sipa> well, there is a block index (disk position for each block), but that's it
793 2012-12-27 22:03:39 <wizkid057> sipa: well, was just making a script that gathered some data from some old transactions, but, it seems some I cant fetch with getrawtransaction
794 2012-12-27 22:04:08 <sipa> i plan to add an (optional) transaction index for people who need that
795 2012-12-27 22:05:02 <wizkid057> hmm
796 2012-12-27 22:05:06 <wizkid057> that'd be nice :D
797 2012-12-27 22:06:14 <Joric> http://tinyurl.com/geobtc still not claimed %)
798 2012-12-27 22:06:44 <Joric> a whole 0.2 BTC
799 2012-12-27 22:14:34 <D34TH> Joric, brainwallet right?
800 2012-12-27 22:15:43 <kjj> who made that puzzle?
801 2012-12-27 22:20:18 <Joric> D34TH, i'd link to https://github.com/bitcoinjs but seems theres no direct link to js
802 2012-12-27 22:20:22 <D34TH> Joric, i keep getting a different btc addr than the one it says
803 2012-12-27 22:20:50 <Joric> kjj, the buriedkeys guy
804 2012-12-27 22:21:22 <Joric> D34TH, prob 5 across is wrong idk really
805 2012-12-27 22:22:22 <Joric> it won't load from https://raw.github.com/bitcoinjs/bitcoinjs-lib/master/build/bitcoinjs-min.js i tried
806 2012-12-27 22:22:29 <kjj> if you are confident about the S, then there are only about 2^33 possible other values...
807 2012-12-27 22:24:47 <Joric> tried bruteforcing with 5m geo database no luck
808 2012-12-27 22:24:59 <kjj> how about the ordering?
809 2012-12-27 22:25:06 <D34TH> holy crap
810 2012-12-27 22:25:10 <D34TH> i accidentally 1337addr
811 2012-12-27 22:26:12 <kjj> by ordering, I mean, are you sure that the sequence is the clue sequence, and not the sequence the answers are found from top down?
812 2012-12-27 22:29:44 <Joric> kjj, yeah, i guess, author said theres a few wrong words https://bitcointalk.org/index.php?topic=80115.20
813 2012-12-27 22:32:02 <kjj> he's not kidding about world-class hard.  the matrix is sparse, and the clues are ambiguous
814 2012-12-27 23:11:03 <gmaxwell> 14:22 < sipa> Luke-Jr: meh, p2p level, not block validity level
815 2012-12-27 23:11:12 <gmaxwell> ^ I ran bridge nodes for that for a while.
816 2012-12-27 23:11:22 <gmaxwell> You can't bridge a real hard fork. :P
817 2012-12-27 23:11:22 <lianj> someone at 29c3?
818 2012-12-27 23:34:16 <sipa> weird, -flto gitian build works for bitcoin-qt, but not for bitcoind
819 2012-12-27 23:34:26 <sipa> complains about some boost stuff that's defined twice
820 2012-12-27 23:35:13 <jgarzik> ditto here
821 2012-12-27 23:35:24 <jgarzik> (at least the bitcoind-not-working bit)
822 2012-12-27 23:35:52 <sipa> ?