1 2012-12-03 00:01:55 <gmaxwell> sipa: I'm assuming the 40% speedup hal version there.
  2 2012-12-03 00:02:19 <gmaxwell> Perhaps I'm wrong??? it's certantly in the same order of magnitude in any case.
  3 2012-12-03 00:04:08 <gmaxwell> jgarzik: I think that thread has been a significant public service??? I've noticed that a number of the less reasonable sounding people have had their ignores go bright gold in the time since the thread started.
  4 2012-12-03 00:06:35 <jgarzik> gmaxwell: hehe, now if only we can convince theymos that those with such ignore colors just need to be kicked
  5 2012-12-03 00:06:46 <jgarzik> baby bedtime, bbiab
  6 2012-12-03 00:09:42 <Impaler> did Bitcoin dependencies change with 0.7.1?
  7 2012-12-03 00:10:12 <Impaler> I'm trying to compile and have an unfound reference to boost/signal2 headers
  8 2012-12-03 00:27:14 <etotheipi_> anyone know of a good way to examine RAM usage of C++ containers?
  9 2012-12-03 00:27:15 <etotheipi_> anyone know of a good way to examine RAM usage of C++ containers?
 10 2012-12-03 00:27:48 <etotheipi_> Armory is using quite a bit more RAM than I think it should, but I can't seem to isolate it:  and clearing maps doesn't affect the process usage in the system monitor (I assume, until something else needs the RAM and claims it)
 11 2012-12-03 00:43:13 <gmaxwell> sipa:
 12 2012-12-03 00:43:14 <gmaxwell> sipa:
 13 2012-12-03 00:43:17 <gmaxwell> 12/03/12 01:34:25 SetBestChain: new best=000000000000048b95347e83192f69cf0366076336c639f9b7228e9ba171342e  height=210000  work=628963747775700992096  tx=9344662  date=11/28/12 15:24:38
 14 2012-12-03 00:43:56 <gmaxwell> thats par8 with it set to pull 2-min(16, N/threads). ... so yea.. seems I was wrong about that helping.
 15 2012-12-03 02:15:11 <_andyj_> Anyone tried putting a sha256 core on a cpld?  I know they don't have the same gate count but tend to be cheaper and more reliable delays
 16 2012-12-03 02:34:51 <jgarzik> hum
 17 2012-12-03 02:34:54 <jgarzik> I have a DNS seeder?
 18 2012-12-03 02:34:57 <jgarzik> I didn't know that.
 19 2012-12-03 02:47:57 <Diablo-D3> heh
 20 2012-12-03 02:48:07 <Diablo-D3> _andyj_: less than a sx150? not enough
 21 2012-12-03 02:48:08 <Diablo-D3> _andyj_: less than a sx150? not enough
 22 2012-12-03 02:48:38 <Diablo-D3> ALTHOUGH
 23 2012-12-03 02:48:48 <Diablo-D3> rolled up cores work a shitload better on constrained ships like spartan 6s
 24 2012-12-03 02:48:56 <Diablo-D3> so it might not be so bad on whatever your fpga is
 25 2012-12-03 02:55:51 <_andyj_> Diablo-D3, I am still trying to find a metric to convert logic gates to macro cells equivalently.  I am wondering if loading up the open core sha256 in use we black will tell me macro cells needed
 26 2012-12-03 02:55:52 <_andyj_> Diablo-D3, I am still trying to find a metric to convert logic gates to macro cells equivalently.  I am wondering if loading up the open core sha256 in use we black will tell me macro cells needed
 27 2012-12-03 02:56:27 <Diablo-D3> you cant
 28 2012-12-03 02:56:30 <_andyj_> Err ise webpack
 29 2012-12-03 02:56:34 <Diablo-D3> each arch is different, even from the same vendor
 30 2012-12-03 02:56:59 <Diablo-D3> and some archs have stuff like easily accessable adders
 31 2012-12-03 02:57:03 <Diablo-D3> which further complicate things
 32 2012-12-03 02:57:22 <_andyj_> But maybe at least for xilinx cpld's then
 33 2012-12-03 05:20:36 <dust-otc> is there a way with the standard bitcoind to get the balance of addresses I do not own?
 34 2012-12-03 05:21:02 <dust-otc> I can add them to accounts but the balance is 0
 35 2012-12-03 05:29:49 <jgarzik> gmaxwell: we linux kernel types get bored if we don't have a good flamewar every now and again
 36 2012-12-03 05:29:50 <jgarzik> gmaxwell: we linux kernel types get bored if we don't have a good flamewar every now and again
 37 2012-12-03 05:30:27 <jgarzik> gmaxwell: Linus has great flames that typically start off "fuck you, you're just stupid"
 38 2012-12-03 05:30:46 <jgarzik> and then he explains why, backing it up with hard facts ;p
 39 2012-12-03 05:30:47 <jgarzik> and then he explains why, backing it up with hard facts ;p
 40 2012-12-03 05:31:01 <gmaxwell> dust-otc: you can't, it doesnt maintain an address index that would allow it to lookup the transactions for an address...
 41 2012-12-03 05:31:02 <gmaxwell> dust-otc: you can't, it doesnt maintain an address index that would allow it to lookup the transactions for an address...
 42 2012-12-03 05:31:03 <jgarzik> I'm nowhere near as good
 43 2012-12-03 05:31:13 <jgarzik> but it is very cathartic
 44 2012-12-03 05:31:36 <gmaxwell> I've got the "fuck you, you're just stupid" part down pat.  :-/
 45 2012-12-03 05:31:37 <gmaxwell> I've got the "fuck you, you're just stupid" part down pat.  :-/
 46 2012-12-03 05:31:58 <dust-otc> gmaxwell: is there any easy way to do so without relying on third party services?
 47 2012-12-03 05:32:28 <gmaxwell> dust-otc: you can run something like abe, but I don't think I'd call that easy.
 48 2012-12-03 05:33:50 <dust-otc> gmaxwell: ok, thanks
 49 2012-12-03 05:34:51 <ThomasV> dust-otc: you can run an electrum server without abe
 50 2012-12-03 05:35:07 <ThomasV> (with leveldb)
 51 2012-12-03 05:38:20 <MC1984> http://cryptome.org/2012/12/assange-crypto-arms.htm this is the foreword to assanges new book
 52 2012-12-03 05:38:46 <MC1984> he argues encryption is the only thing that will save us from ourselves
 53 2012-12-03 05:39:36 <MC1984> written like a wise (senile) old man telling stories around the fire though
 54 2012-12-03 05:40:18 <eennaam> meh
 55 2012-12-03 05:40:19 <eennaam> meh
 56 2012-12-03 05:40:22 <gmaxwell> OT for bitcoin-dev, but interesting.. Move it to #bitcoin and I'll comment there.
 57 2012-12-03 05:40:25 <eennaam> im getting assange-tired
 58 2012-12-03 05:42:06 <MC1984> woops i thought this was bticoin
 59 2012-12-03 06:59:31 <andrew12-> going to try to crack casacasius' code
 60 2012-12-03 07:00:32 <Diablo-D3> er?
 61 2012-12-03 07:00:38 <Diablo-D3> you do realize those are valid keys, right?
 62 2012-12-03 07:00:51 <andrew12-> ?
 63 2012-12-03 07:01:22 <andrew12-> the key he gives is encrypted
 64 2012-12-03 07:01:23 <andrew12-> the key he gives is encrypted
 65 2012-12-03 07:01:59 <Diablo-D3> no, it IS the key
 66 2012-12-03 07:02:38 <andrew12-> then why hasn't someone stolen it yet
 67 2012-12-03 07:02:48 <Diablo-D3> because you have to destroy the coin to get it
 68 2012-12-03 07:02:49 <Diablo-D3> because you have to destroy the coin to get it
 69 2012-12-03 07:03:18 <Diablo-D3> [01:30:28] <jgarzik> gmaxwell: Linus has great flames that typically start off "fuck you, you're just stupid"
 70 2012-12-03 07:03:41 <Diablo-D3> jgarzik: someone needs to do one of those throw away blog things people do just doing a list of his greatest posts
 71 2012-12-03 07:05:51 <abrkn> how does SD know where the btc comes from (in order to return it)?
 72 2012-12-03 07:06:23 <abrkn> (how could i figure out the same using getrawtransaction and decoderawtransaction of bitcoind?)
 73 2012-12-03 07:07:26 <sipa> yes, but don't
 74 2012-12-03 07:07:27 <sipa> yes, but don't
 75 2012-12-03 07:08:33 <abrkn> why is that?
 76 2012-12-03 07:08:34 <abrkn> why is that?
 77 2012-12-03 07:08:49 <xIsalty> because you were told not to
 78 2012-12-03 07:12:08 <abrkn> http://bitcoin.stackexchange.com/questions/4604/how-to-return-bitcoins-to-sender-through-bitcoin-api <- the only reason i see why you wouldnt do that is because of people using managed wallets
 79 2012-12-03 07:14:52 <MC1984> everyone likes linus
 80 2012-12-03 07:14:59 <MC1984> hes an asshole because he earned it
 81 2012-12-03 07:16:20 <jgarzik> abrkn: it's not guaranteed to work, and you don't know it failed until money gets sent off into space
 82 2012-12-03 07:17:49 <abrkn> jgarzik: ok, im just trying to work out a way to put money into my game without having to wait an hour for confirmations
 83 2012-12-03 07:18:53 <jgarzik> abrkn: That's a full six confirmations.  Just reduce the confirmation count, to lower that number.
 84 2012-12-03 07:20:25 <abrkn> jgarzik: maybe i could let them play from 0 conf but not take anything out before X conf?
 85 2012-12-03 07:20:59 <jgarzik> abrkn: deposit 0 conf + withdraw 0 conf is incredibly risky
 86 2012-12-03 07:21:00 <jgarzik> abrkn: deposit 0 conf + withdraw 0 conf is incredibly risky
 87 2012-12-03 07:21:26 <jgarzik> abrkn: plus, do you really want to be on the hook for a reversed 1000 BTC deposit?
 88 2012-12-03 07:21:56 <abrkn> jgarzik: but you wouldnt be able to withdraw anything unless i have X conf on every deposit you ever made
 89 2012-12-03 07:21:57 <abrkn> jgarzik: but you wouldnt be able to withdraw anything unless i have X conf on every deposit you ever made
 90 2012-12-03 07:22:26 <jgarzik> abrkn: it's a business decision what level of risk to accept, but think about amounts as well as just confirmations.  ask yourself how much risk you can accept, if a 0-conf gets never-confirmed (possible!) or reversed in a double-spend.
 91 2012-12-03 07:22:47 <jgarzik> abrkn: you might accept 1 BTC 0-conf, but 1000 BTC requires 6-conf
 92 2012-12-03 07:23:12 <abrkn> jgarzik: i think the issue is that i dont understand well how common these double spends are - or how easy they are to execute
 93 2012-12-03 07:23:35 <jgarzik> abrkn: up to 1 confirmation is worth it and doable for 100 BTC
 94 2012-12-03 07:24:13 <jgarzik> abrkn: (or 1 BTC x 100 deposits, etc.)
 95 2012-12-03 07:26:59 <abrkn> jgarzik: would there be any downside to letting people play with 0 conf but not allowing them to withdraw anything unless all deposits have 3 conf etc?
 96 2012-12-03 07:27:35 <jgarzik> abrkn: well, consider the economics.  what makes economic sense to a cheater?
 97 2012-12-03 07:27:44 <jgarzik> abrkn: if you win, wait out the confirmations before withdrawal
 98 2012-12-03 07:27:53 <jgarzik> abrkn: if you lose, double-spend the deposits elsewhere and move on
 99 2012-12-03 07:28:01 <abrkn> jgarzik: right, that was my concern
100 2012-12-03 07:29:13 <jgarzik> abrkn: for a person whose total wager is 1 BTC, it's probably not worth it to reverse a 1BTC loss
101 2012-12-03 07:29:21 <jgarzik> abrkn: if the wager is larger, it is worth it
102 2012-12-03 07:30:18 <jgarzik> abrkn: that's why mtgox waits 6 confirmations, but a music download site doesn't care :)
103 2012-12-03 07:30:30 <jeremias> bitpay says that they haven't had a single double spend attempt, they accept zero-confirmation payments
104 2012-12-03 07:30:31 <jeremias> bitpay says that they haven't had a single double spend attempt, they accept zero-confirmation payments
105 2012-12-03 07:30:58 <abrkn> are there any stats on double spends? (when, how much, targets, etc)
106 2012-12-03 07:30:59 <abrkn> are there any stats on double spends? (when, how much, targets, etc)
107 2012-12-03 07:31:19 <jeremias> http://blockchain.info/double-spends
108 2012-12-03 07:32:28 <abrkn> wow, that's rare
109 2012-12-03 07:32:29 <abrkn> wow, that's rare
110 2012-12-03 07:32:41 <jeremias> I think many of those might just be erronous
111 2012-12-03 07:32:42 <jeremias> I think many of those might just be erronous
112 2012-12-03 07:33:09 <jeremias> it doesn't make much sense to try scamming people with double spends
113 2012-12-03 07:33:10 <jeremias> it doesn't make much sense to try scamming people with double spends
114 2012-12-03 07:33:18 <jeremias> traditional scams work way better
115 2012-12-03 07:33:50 <jeremias> like social engineering
116 2012-12-03 07:34:26 <abrkn> indeed
117 2012-12-03 07:34:32 <abrkn> i remember when i briefly played eve online. whoa!
118 2012-12-03 07:34:36 <abrkn> that place is scam school
119 2012-12-03 07:35:15 <abrkn> they'd be like: im selling 100 lemons for 10 each and the total would be 10000 on the price tag
120 2012-12-03 07:35:26 <abrkn> you think wow 10 is cheap and you click buy :P
121 2012-12-03 07:35:44 <abrkn> (obviously they'd use way more confusing quantities and unit prices)
122 2012-12-03 07:50:50 <MC1984> greg seems to think that accepting zero conf = lose the shirt off your back within 10 mins
123 2012-12-03 07:50:58 <MC1984> i wonder what he thinks of the wordpress thing
124 2012-12-03 07:51:14 <MC1984> i suppose if youre selling a service you can just withdraw the service
125 2012-12-03 07:52:06 <jeremias> yes, and with selling physical product online you just don't send the stuff
126 2012-12-03 07:53:09 <MC1984> selling digital goods is riskier
127 2012-12-03 07:53:24 <MC1984> but then they can be copied anyway, no dicking around needed
128 2012-12-03 07:53:25 <jeremias> usually digital goods are very low-cost in every case
129 2012-12-03 07:53:38 <jeremias> the actual fraud rate matters, not theoretical
130 2012-12-03 07:54:01 <jeremias> based on current experiences, I would recommend to start with zero-conf, if problems arise, then switch to some other model
131 2012-12-03 08:01:39 <abrkn> what would a double spend look like when speaking to bitcoind? would the block at the top of the chain change?
132 2012-12-03 08:01:40 <abrkn> what would a double spend look like when speaking to bitcoind? would the block at the top of the chain change?
133 2012-12-03 08:09:21 <jaromil> re all (ya all jeff's bitches now!) :^))) (@op joke)
134 2012-12-03 08:10:02 <jaromil> jgarzik: picocoin is NEAT and CUDDLY. filed a pull req on minor glib <2.28 compat issue, hanging out just in case you like to get in touch about it
135 2012-12-03 08:53:44 <jgarzik> jaromil: thanks, commented
136 2012-12-03 08:53:55 <jgarzik> jaromil: someone else found the same issue the other day
137 2012-12-03 08:55:32 <jaromil> its easy to spot if one uses debian stable
138 2012-12-03 09:06:19 <sipa> haha
139 2012-12-03 09:06:28 <sipa> hi there jaromil!
140 2012-12-03 09:06:29 <sipa> hi there jaromil!
141 2012-12-03 09:06:38 <Diablo-D3> [03:50:52] <MC1984> greg seems to think that accepting zero conf = lose the shirt off your back within 10 mins
142 2012-12-03 09:06:44 <Diablo-D3> I love how this line makes zero sense out of context
143 2012-12-03 09:09:39 <da2ce7> what is the resonable limits on m of n tx's?
144 2012-12-03 09:09:40 <da2ce7> what is the resonable limits on m of n tx's?
145 2012-12-03 09:09:48 <da2ce7> like 10 / 20 or 100 / 200
146 2012-12-03 09:09:55 <da2ce7> or 2000 / 10000
147 2012-12-03 09:09:56 <da2ce7> or 2000 / 10000
148 2012-12-03 09:10:06 <da2ce7> at what point will the fee get too large?
149 2012-12-03 09:11:18 <Diablo-D3> da2ce7: I dont think the client can process anything that big
150 2012-12-03 09:11:40 <da2ce7> hmm... if we had a modifed client?
151 2012-12-03 09:11:42 <Diablo-D3> I remember sipa or gmaxwell talking about it
152 2012-12-03 09:11:53 <Diablo-D3> no I mean, like, they should be able to they just dont
153 2012-12-03 09:15:08 <da2ce7> becasue if the fees were small (like less than a few btc), then having MANY signtures on a P2SH would be quite usefull for our coloured coin OT. (when we use the bitcoin network to enforce some issuance rules).
154 2012-12-03 09:15:09 <da2ce7> becasue if the fees were small (like less than a few btc), then having MANY signtures on a P2SH would be quite usefull for our coloured coin OT. (when we use the bitcoin network to enforce some issuance rules).
155 2012-12-03 09:15:21 <jaromil> sipa: hi :^)
156 2012-12-03 09:15:33 <da2ce7> If you are issueing thousands of BTC worth of coloured coins.... then paying a 10 btc fee is fine.
157 2012-12-03 09:15:54 <jaromil> jgarzik: compat.h makes more sense, i've refiled the pull req with less lines changed
158 2012-12-03 09:15:55 <jaromil> jgarzik: compat.h makes more sense, i've refiled the pull req with less lines changed
159 2012-12-03 09:16:37 <sipa> da2ce7: 20 sigops is maximum for a standard tx
160 2012-12-03 09:16:56 <sipa> da2ce7: 20k sigops per block is hard limit
161 2012-12-03 09:17:51 <da2ce7> so having a 2000 / 10000 would be possible.... unless we hit into the 1mb limit.
162 2012-12-03 09:20:50 <jgarzik> jaromil: pulled, thanks
163 2012-12-03 09:23:13 <jaromil> thankyou for picocoin, finally some code that doesn't gives me the shivers :)
164 2012-12-03 09:23:51 <jgarzik> jaromil: heh, well, it's still under construction.  plenty of time to give you shivers ;p
165 2012-12-03 09:25:31 <jaromil> i'll do what I can to help. have you read my issue/suggestion about polarSSL? not sure what you think about it
166 2012-12-03 09:25:42 <jaromil> so far I've seen you are using very little from openssl
167 2012-12-03 09:25:46 <jaromil> but I haven't read it all yet
168 2012-12-03 09:26:46 <jaromil> oh I see you commented it
169 2012-12-03 09:26:58 <jgarzik> jaromil: using: sha1, sha256, ripemd160, BIGNUM, ECDSA
170 2012-12-03 09:27:10 <jaromil> ok that helps. I'll have a look, using polarSSL already on some openvpn implementations myself
171 2012-12-03 09:27:45 <jgarzik> jaromil: does polarssl do ecdsa?
172 2012-12-03 09:27:46 <jgarzik> jaromil: does polarssl do ecdsa?
173 2012-12-03 09:28:26 <sipa> gmaxwell: i think there's one more improvement i can do to the parallellization: only have N-1 worker threads, and make the block processing thread take the role of the Nth one when connection has finished
174 2012-12-03 09:28:27 <sipa> gmaxwell: i think there's one more improvement i can do to the parallellization: only have N-1 worker threads, and make the block processing thread take the role of the Nth one when connection has finished
175 2012-12-03 09:28:46 <sipa> so the block processing doesn't fight with the workers for CPU time
176 2012-12-03 09:28:47 <sipa> so the block processing doesn't fight with the workers for CPU time
177 2012-12-03 09:30:27 <jgarzik> jaromil: Looks like PolarSSL lacks ECDSA and RIPEMD160, but has SHA1, SHA256 and BIGNUM
178 2012-12-03 09:30:37 <jgarzik> ACTION pastes into issue
179 2012-12-03 09:31:07 <jaromil> yea :/
180 2012-12-03 09:31:08 <jaromil> yea :/
181 2012-12-03 09:31:17 <sipa> hmm, gavin doesn't like halcode :(
182 2012-12-03 09:33:29 <sipa> da2ce7: 2000/10000 is theoretically feasible, but it would (or at least should) be ridiculously expensive, as it would be almost the only transaction in a block
183 2012-12-03 09:34:17 <sipa> da2ce7: also you'll need a complex own script, as the standard opcode only supports up to 20 keys
184 2012-12-03 09:34:31 <jgarzik> sipa: :(
185 2012-12-03 09:34:45 <jaromil> jgarzik: cyaSSL could be another candidate
186 2012-12-03 09:34:46 <jaromil> jgarzik: cyaSSL could be another candidate
187 2012-12-03 09:36:00 <jaromil> but there is no openssl compat layer so part of the code needs refactoring then
188 2012-12-03 09:36:00 <sipa> jgarzik: well - he has a point in that the code is not really obvious... i suppose if i can factor out the fast multiplication code (which at least will require understanding it), it can be more easily written as "an obvious ECDSA implementation"
189 2012-12-03 09:36:56 <jgarzik> jaromil: mind you, picocoin is licensed MIT/X11, not GPL
190 2012-12-03 09:36:57 <jgarzik> jaromil: mind you, picocoin is licensed MIT/X11, not GPL
191 2012-12-03 09:37:24 <jaromil> yes, still openssl is a licensing PITA for everyone AFAIK
192 2012-12-03 09:37:35 <jgarzik> sipa: solve everybody's problems by creating libecdsa_bignum
193 2012-12-03 09:37:56 <jgarzik> sipa: that solves the side problem of fedora openssl lacking ecdsa </bias>
194 2012-12-03 09:38:49 <jgarzik> jaromil: I don't mind abstracting out stuff, to work with another lib
195 2012-12-03 09:39:00 <jgarzik> jaromil: The problem is finding a lib that does ECDSA I think :)
196 2012-12-03 09:39:07 <sipa> jgarzik: i'm not going to maintain such a thing, and if the problem is peer review, that's not going to help either
197 2012-12-03 09:39:10 <jaromil> yes that is the missing part most of the time
198 2012-12-03 09:39:30 <jaromil> the nice thing of cyassl and polarssl is that they really work well on embedded stuff
199 2012-12-03 09:40:01 <jgarzik> jaromil: if you have ecdsa and bignum, the rest are just simple hashing algorithms, easy enough to directly import into the codebase
200 2012-12-03 09:42:24 <jaromil> i find it neat https://polarssl.org/api/bignum_8h.html
201 2012-12-03 09:42:49 <jaromil> i don't know ECDSA but RIPEMD160 should be fairly easy to implement?
202 2012-12-03 09:43:11 <jaromil> sha is relatively trivial
203 2012-12-03 09:43:14 <jgarzik> jaromil: cya has ripemd160
204 2012-12-03 09:43:25 <sipa> RIPEMD160 shouldn't be more code than SHA2
205 2012-12-03 09:43:26 <sipa> RIPEMD160 shouldn't be more code than SHA2
206 2012-12-03 09:43:27 <jgarzik> jaromil: yes, hashing is always easy to implement.
207 2012-12-03 09:43:31 <sipa> ECDSA is significantly more
208 2012-12-03 09:43:32 <sipa> ECDSA is significantly more
209 2012-12-03 09:43:43 <jgarzik> jaromil: and there is no need to implement -- you can google around and find a suitably licensed implementation
210 2012-12-03 09:43:46 <jaromil> yea so that's the tough guy
211 2012-12-03 09:43:50 <jgarzik> jaromil: steal from crypto++ if nothing else
212 2012-12-03 09:45:04 <jgarzik> jaromil: Yes.  For example, it would make no sense to import or wrap sha1/sha256/ripemd160 right now, as long as ECDSA still requires OpenSSL
213 2012-12-03 09:45:26 <jgarzik> jaromil: but once ECDSA does not require OpenSSL, it is ok to import or wrap the hash algorithms
214 2012-12-03 09:45:34 <jaromil> ACTION nods
215 2012-12-03 09:45:45 <sipa> hmm.... https://github.com/joyent/node/blob/master/deps/openssl/openssl/crypto/ec/ecp_nistp256.c
216 2012-12-03 09:46:01 <sipa> oh, nist P
217 2012-12-03 09:46:27 <sipa> not secp k
218 2012-12-03 09:47:37 <jaromil> well i think its this one http://tools.ietf.org/html/rfc6605
219 2012-12-03 09:47:38 <jaromil> well i think its this one http://tools.ietf.org/html/rfc6605
220 2012-12-03 09:48:21 <sipa> yes, but that's not the curve bitcoin usus
221 2012-12-03 09:48:23 <jgarzik> that's curve P-256
222 2012-12-03 09:49:00 <sipa> i think P-256 == secp256r1
223 2012-12-03 09:49:03 <jgarzik> http://tools.ietf.org/html/rfc6090 is neat though
224 2012-12-03 09:49:04 <jgarzik> http://tools.ietf.org/html/rfc6090 is neat though
225 2012-12-03 09:49:17 <jgarzik> nice to have that out in the open in an RFC
226 2012-12-03 09:50:55 <abrkn> what would a double spend look like when speaking to bitcoind? would the block at the top of the chain change?
227 2012-12-03 09:50:56 <abrkn> what would a double spend look like when speaking to bitcoind? would the block at the top of the chain change?
228 2012-12-03 09:51:11 <jaromil> well, IETF is OK :^)
229 2012-12-03 09:51:52 <sipa> abrkn: that's just a reorganisation, which happens all the time, and is harmless and expected
230 2012-12-03 09:52:11 <sipa> abrkn: it's only an attempted double spend if the old and the new chain contain conflicting transactions
231 2012-12-03 09:53:52 <jgarzik> you might not see a double spend until it appears in a block, FWIW
232 2012-12-03 09:54:20 <jaromil> what about OpenECC?
233 2012-12-03 09:54:39 <jaromil> https://github.com/OpenECC/OpenECC/blob/master/ECDSA.c
234 2012-12-03 09:55:07 <sipa> not secp256k1
235 2012-12-03 10:47:31 <slush> How is possible that ./bitcoind getbalance and ./bitcoind getbalance "" displays different amounts?
236 2012-12-03 10:47:35 <slush> Second one much bigger
237 2012-12-03 11:00:26 <Jouke> slush: neggative accounts?
238 2012-12-03 11:00:32 <Jouke> "" is an account
239 2012-12-03 11:00:41 <slush> Jouke: no, just bigger balance
240 2012-12-03 11:00:52 <slush> it is on pool, so maybe these are unmatured blocks
241 2012-12-03 11:01:23 <slush> but I expected that "getbalance" counts only spendable coins (so confirmations are counted since maturation)
242 2012-12-03 11:55:27 <kinlo> slush: getbalance shows your entire wallets balance, getbalance "" only the balance of the "" account...
243 2012-12-03 11:55:39 <kinlo> do you use multiple accounts?
244 2012-12-03 11:55:51 <kinlo> the answer to that question should be yes given your results
245 2012-12-03 11:55:52 <kinlo> the answer to that question should be yes given your results
246 2012-12-03 11:57:27 <kinlo> slush: you should run the listaccounts command and see
247 2012-12-03 15:08:46 <Pucilowski> Does an SSL connection secure me from a rogue network admin? I'm assuming my machine is clean
248 2012-12-03 15:09:38 <gmaxwell> Pucilowski: to some extent.
249 2012-12-03 15:11:12 <upb> depends on your client :)
250 2012-12-03 15:11:13 <gmaxwell> so long as you never click past certificate warnings, and so long as he's not also the rogue admin of the server's network or not willing to spend a lot of time and money setting up to monitor a single site, and assuming he hasn't gotten you to install his own CA cert, or gotten a subca cert from a greedy/dishonest CA.
251 2012-12-03 15:11:13 <upb> depends on your client :)
252 2012-12-03 15:11:34 <gmaxwell> and indeed, so long as your client actually enforces the rules! not all ssl using software does. (though browsers do)
253 2012-12-03 15:12:22 <gavinandresen> Pucilowski: ... unless your rogue network admin is working for the NSA or you do something stupid, yes, a SSL connection will protect you.
254 2012-12-03 15:13:06 <gavinandresen> ACTION wonders what Pucilowski needs protecting from....
255 2012-12-03 15:13:07 <gavinandresen> ACTION wonders what Pucilowski needs protecting from....
256 2012-12-03 15:13:24 <Pucilowski> school
257 2012-12-03 15:14:12 <Pucilowski> I receive interest in bitcoins during the day but can't tend to them until I get home
258 2012-12-03 15:14:29 <Pucilowski> Looking at the blockchain.info wallet app
259 2012-12-03 15:14:35 <epscy> interest?
260 2012-12-03 15:15:04 <Pucilowski> as in, offers
261 2012-12-03 15:15:12 <Pucilowski> on localbitcoins
262 2012-12-03 15:15:13 <Pucilowski> on localbitcoins
263 2012-12-03 15:24:08 <BlueMatt> yay, more people asking to fork the chain to deal with sd spam...
264 2012-12-03 15:24:26 <BlueMatt> yet when proposals come up to deal with it in other prioritization ways, they are immediately rejected
265 2012-12-03 15:27:21 <BlueMatt> so which core dev wants to sign up to manage a 24/7 testnet (+mining?) node?
266 2012-12-03 15:28:04 <BlueMatt> (and/or also https served binary downloads)
267 2012-12-03 15:28:20 <gavinandresen> ACTION points to jgarzik
268 2012-12-03 15:31:06 <gmaxwell> If jeff's not willing I guess I am. (as I already maintain a couple).
269 2012-12-03 15:31:29 <gavinandresen> https downloads might be better served from Amazon EC2... I think you can setup your own domain/SSL cert ...
270 2012-12-03 15:35:12 <BlueMatt> gavinandresen: fair enough
271 2012-12-03 15:35:58 <gavinandresen> speaking of binary downloads... what's up with 0.7.2  ?
272 2012-12-03 15:36:21 <gavinandresen> Luke-Jr: ping?
273 2012-12-03 16:19:03 <Luke-Jr> gavinandresen: pong
274 2012-12-03 16:19:30 <gavinandresen> Luke-Jr: where we at with 0.7.2 ?
275 2012-12-03 16:19:58 <Luke-Jr> gavinandresen: rc2; sipa did a build, I'll have one shortly, but no third person has stepped up to build yet
276 2012-12-03 16:20:34 <Luke-Jr> apparently we're starving for gitian-capable people these days
277 2012-12-03 16:21:31 <Luke-Jr> gavinandresen: AFAIK you're still the only one who can build Mac binaries
278 2012-12-03 16:21:32 <gavinandresen> I saw a debian (or was it freebsd...) maintainer complaining about hosting at gitorious; is there a real issue there?
279 2012-12-03 16:21:32 <Luke-Jr> gavinandresen: AFAIK you're still the only one who can build Mac binaries
280 2012-12-03 16:21:33 <gavinandresen> I saw a debian (or was it freebsd...) maintainer complaining about hosting at gitorious; is there a real issue there?
281 2012-12-03 16:22:06 <Luke-Jr> I haven't heard of any issue. link?
282 2012-12-03 16:22:07 <Luke-Jr> I haven't heard of any issue. link?
283 2012-12-03 16:22:36 <drizztbsd> gitorious maintainer are asses, but the platform works greatly
284 2012-12-03 16:22:37 <drizztbsd> gitorious maintainer are asses, but the platform works greatly
285 2012-12-03 16:22:45 <Luke-Jr> I could always move or mirror it to github if that's needed or wanted. Or someone could just copy the tag to the master repo.
286 2012-12-03 16:23:24 <gavinandresen> tag should definitely be copied, but the issue was that the gitian builder scripts point to the gitorious repo.
287 2012-12-03 16:23:42 <gavinandresen> (I don't have the link and don't remember what the issue was)
288 2012-12-03 16:26:33 <gavinandresen> RE: mac builds:  I'm "recompiling the world" on an old 32-bit laptop that I plan on using for builds (I've had chronic issues building 32-bit binaries on my main 64-bit machine)
289 2012-12-03 16:26:34 <gavinandresen> RE: mac builds:  I'm "recompiling the world" on an old 32-bit laptop that I plan on using for builds (I've had chronic issues building 32-bit binaries on my main 64-bit machine)
290 2012-12-03 16:29:09 <jgarzik> BlueMatt: If you gotta Fedora VM, yo I'll manage it
291 2012-12-03 16:29:17 <jgarzik> Check out the beat, while the DJ revolves it
292 2012-12-03 16:30:29 <gavinandresen> "Check out the beat while the DJ revolves it" ???  <-- you're not about to go bezerk again, are you ?
293 2012-12-03 16:35:24 <Luke-Jr> jgarzik's lyrics sound like that Chinese food song
294 2012-12-03 16:35:41 <jgarzik> hehehehe
295 2012-12-03 16:43:08 <BlueMatt> jgarzik: I just finished installing debian...
296 2012-12-03 16:43:13 <BlueMatt> jgarzik: let me go grab a fedora iso...
297 2012-12-03 16:43:30 <sipa> gmaxwell: i should probably turn on parallellism in the unit tests
298 2012-12-03 16:43:31 <sipa> gmaxwell: i should probably turn on parallellism in the unit tests
299 2012-12-03 16:43:41 <sipa> as they probably only use the single-threaded verification now
300 2012-12-03 16:47:23 <sipa> gmaxwell: also because you didn't have enough combinations to test already, i added a commit that could improve things a bit further
301 2012-12-03 16:51:41 <BlueMatt> so apparently there is no fedora server iso, what if I dont want a damn gui to install a server os?
302 2012-12-03 16:51:42 <BlueMatt> so apparently there is no fedora server iso, what if I dont want a damn gui to install a server os?
303 2012-12-03 16:52:03 <jgarzik> Luke-Jr: That's Ice Ice Baby :)
304 2012-12-03 16:52:05 <jgarzik> a classic
305 2012-12-03 16:52:24 <jgarzik> BlueMatt: kickstart is the standard method
306 2012-12-03 16:52:52 <BlueMatt> ACTION knows nothing about fedora...kickstart?
307 2012-12-03 16:52:52 <Luke-Jr> jgarzik: Rice Rice *
308 2012-12-03 16:52:53 <Luke-Jr> jgarzik: Rice Rice *
309 2012-12-03 16:52:59 <BlueMatt> how does one get to kickstart?
310 2012-12-03 16:53:23 <jgarzik> BlueMatt: google search string "fedora kickstart"
311 2012-12-03 16:53:42 <BlueMatt> ACTION was hoping for a more simple cntl-alt-f2 + kickstart
312 2012-12-03 16:53:50 <jgarzik> Luke-Jr: I was trying to think of a bitcoin-related permutation, but failed
313 2012-12-03 16:54:24 <Luke-Jr> jgarzik: check out the bits while the miners hash them?
314 2012-12-03 16:54:25 <Luke-Jr> jgarzik: check out the bits while the miners hash them?
315 2012-12-03 16:55:36 <jgarzik> Luke-Jr: pretty good :)
316 2012-12-03 16:55:42 <jgarzik> need a chorus though
317 2012-12-03 16:55:49 <jgarzik> hash hash baby?
318 2012-12-03 16:57:25 <Luke-Jr> hm
319 2012-12-03 16:58:07 <Luke-Jr> is it just me, or does 1 round of badblocks non-destructive r/w test take longer than 4 rounds of the destructive r/w test? :/
320 2012-12-03 16:59:04 <BurtyB> BlueMatt, if you want a server why not just install something like centos rather than a desktop distro?
321 2012-12-03 16:59:23 <BlueMatt> BurtyB: I dunno, jgarzik is the one who asked for fedora...
322 2012-12-03 16:59:53 <jgarzik> Luke-Jr: badblocks is pointless on modern hard drives
323 2012-12-03 17:00:08 <Luke-Jr> jgarzik: crap, I just wasted the last 3 days then
324 2012-12-03 17:00:09 <Luke-Jr> jgarzik: crap, I just wasted the last 3 days then
325 2012-12-03 17:00:10 <jgarzik> Luke-Jr: just "dd if=/dev/zero of=/dev/HARD_DRIVE bs=1M"
326 2012-12-03 17:00:19 <jgarzik> Luke-Jr: that will force replacement of any bad sectors
327 2012-12-03 17:00:33 <Luke-Jr> jgarzik: I wanted to know if there *were* any so I know which NAS to ship  back to NewEgg
328 2012-12-03 17:01:16 <Luke-Jr> (also, that will definitely be destructive???)
329 2012-12-03 17:01:29 <jgarzik> Luke-Jr: smartctl -d ata -a /dev/HARD_DRIVE
330 2012-12-03 17:01:41 <jgarzik> Luke-Jr: possibly after a: smartctl -d ata -t long /dev/HARD_DRIVE
331 2012-12-03 17:10:49 <Luke-Jr> jgarzik: what bytes-per-inode do you recommend? :P
332 2012-12-03 17:10:50 <Luke-Jr> jgarzik: what bytes-per-inode do you recommend? :P
333 2012-12-03 17:11:07 <jgarzik> Luke-Jr: the default that mkfs gives you :)
334 2012-12-03 17:11:27 <Luke-Jr> eh, that's always way too many inodes <.<
335 2012-12-03 17:14:23 <BlueMatt> jgarzik: fuck it, Ill send you a vnc booted into a fedora iso...
336 2012-12-03 17:15:39 <Luke-Jr> lol
337 2012-12-03 17:15:40 <Luke-Jr> lol
338 2012-12-03 17:15:45 <jgarzik> BlueMatt, gavinandresen: Am I setting up testnet and mainnet nodes, or just testnet?  And, is CPU mining permitted?
339 2012-12-03 17:15:56 <BlueMatt> whatever, and yes
340 2012-12-03 17:16:28 <jgarzik> gavinandresen: RE flaming the trolls...  this is why I am not a board member or project leader.  So that I can have a cathartic flamewar every now and again :)
341 2012-12-03 17:16:29 <gavinandresen> jgarzik: I'd say don't CPU mine with more than one core, though.
342 2012-12-03 17:16:30 <gavinandresen> jgarzik: I'd say don't CPU mine with more than one core, though.
343 2012-12-03 17:16:35 <jgarzik> gavinandresen: agreed
344 2012-12-03 17:16:37 <BlueMatt> the vm only has one core
345 2012-12-03 17:16:45 <jgarzik> us4.exmulti.net (my testnet node) only mines on 1 core
346 2012-12-03 17:16:46 <jgarzik> us4.exmulti.net (my testnet node) only mines on 1 core
347 2012-12-03 17:16:57 <gavinandresen> jgarzik: flame on!
348 2012-12-03 17:16:58 <gavinandresen> jgarzik: flame on!
349 2012-12-03 17:17:45 <jgarzik> BlueMatt: if I'm mining, I'd say you would want 2 cores?
350 2012-12-03 17:17:45 <sipa> gmaxwell: any further benchmark results?
351 2012-12-03 17:17:53 <gavinandresen> BlueMatt: did you give the jenkins VM more than one core?
352 2012-12-03 17:18:00 <BlueMatt> jenkins has 12
353 2012-12-03 17:18:01 <BlueMatt> jenkins has 12
354 2012-12-03 17:18:12 <gavinandresen> cool.
355 2012-12-03 17:18:14 <Luke-Jr> gavinandresen: btw, how serious do you consider the "test_bitcoin overwrites start of blk0001.dat with genesis block" bug in 0.7.x? sometime to do a rc3 for?
356 2012-12-03 17:18:15 <Luke-Jr> gavinandresen: btw, how serious do you consider the "test_bitcoin overwrites start of blk0001.dat with genesis block" bug in 0.7.x? sometime to do a rc3 for?
357 2012-12-03 17:18:21 <BlueMatt> jgarzik: fair enough, 2 it is
358 2012-12-03 17:18:21 <Luke-Jr> something*
359 2012-12-03 17:18:29 <sipa> Luke-Jr: that bug does not exist in 0.7.x
360 2012-12-03 17:18:30 <sipa> Luke-Jr: that bug does not exist in 0.7.x
361 2012-12-03 17:18:40 <Luke-Jr> sipa: oh, I thought you said it did <.<
362 2012-12-03 17:18:40 <sipa> Luke-Jr: in 0.7.x it was *append* to the last block file
363 2012-12-03 17:18:58 <sipa> which i also consider a bug, but not a particularly worrysome one
364 2012-12-03 17:19:10 <Luke-Jr> ah
365 2012-12-03 17:19:11 <Luke-Jr> ah
366 2012-12-03 17:22:21 <gmaxwell> sipa: I ran a w/o hal run last night and posted on the hal pull request, but nothing since.
367 2012-12-03 17:22:22 <gmaxwell> sipa: I ran a w/o hal run last night and posted on the hal pull request, but nothing since.
368 2012-12-03 17:22:30 <gmaxwell> ACTION goes to look at your latest pulls.
369 2012-12-03 17:22:31 <gmaxwell> ACTION goes to look at your latest pulls.
370 2012-12-03 17:25:15 <Pucilowski> What's the purpose of the WIF?
371 2012-12-03 17:25:27 <jgarzik> to smell
372 2012-12-03 17:52:30 <gmaxwell> sipa: oh.. it's crashing now.
373 2012-12-03 17:54:04 <gmaxwell> but I think not due to the latest change, but due to corruption during my stops and restarts.
374 2012-12-03 17:54:05 <gmaxwell> but I think not due to the latest change, but due to corruption during my stops and restarts.
375 2012-12-03 17:54:27 <gmaxwell> yea...
376 2012-12-03 17:54:28 <gmaxwell> LoadBlockIndexDB () at main.cpp:2484
377 2012-12-03 17:54:41 <gmaxwell> (gdb) p pindexBest
378 2012-12-03 17:55:03 <gmaxwell> last thing in the debug.log is
379 2012-12-03 17:55:41 <gmaxwell> I'm not sure how the blockfile stuff got screwed up.. that was synced all the way last night. :-/
380 2012-12-03 17:56:27 <gmaxwell> Unfortunately I deleted the log before trying the test run, so I don't have any evidence of how the corruption happened, but the segfault is probably worth fixing. :P
381 2012-12-03 17:56:28 <gmaxwell> Unfortunately I deleted the log before trying the test run, so I don't have any evidence of how the corruption happened, but the segfault is probably worth fixing. :P
382 2012-12-03 17:56:52 <gmaxwell> out of time now???
383 2012-12-03 18:07:00 <sipa> gmaxwell: bug in -reindex, but harmless, except for that message
384 2012-12-03 18:07:48 <gmaxwell> hm? I'm not reindexing now. And a segfault isn't harmless! :P
385 2012-12-03 18:08:00 <sipa> gmaxwell: and that segfault probably means you're not running the nocoins patch
386 2012-12-03 18:08:01 <sipa> gmaxwell: and that segfault probably means you're not running the nocoins patch
387 2012-12-03 18:08:48 <gmaxwell> oh crap. sorry. this is what I get when trying to slip in something between projects.
388 2012-12-03 18:08:49 <gmaxwell> oh crap. sorry. this is what I get when trying to slip in something between projects.
389 2012-12-03 18:09:56 <gmaxwell> yes, that was the case. You can ignore me now.
390 2012-12-03 18:20:46 <sipa> gmaxwell: anyway, so far no evidence to support the theory that batch processing per thread slows down?
391 2012-12-03 18:21:37 <sipa> because on other OS'es, switching overhead may be higher, in which case it may be useful still
392 2012-12-03 18:21:38 <sipa> because on other OS'es, switching overhead may be higher, in which case it may be useful still
393 2012-12-03 18:28:12 <gmaxwell> No, nothing suggests to me that it slows it down. Interesting point wrt other OSes.
394 2012-12-03 18:32:02 <sipa> essentially what this mechanism should cause, is all threads doing 16-job batches, then 1 8-job batch, 1 4, 1 2, 1 1
395 2012-12-03 18:32:30 <sipa> so you get smaller jobs at the end of the queue, hopefully causing all jobs to stop approximately simultaneously
396 2012-12-03 18:32:31 <sipa> so you get smaller jobs at the end of the queue, hopefully causing all jobs to stop approximately simultaneously
397 2012-12-03 18:33:02 <sipa> *all threads
398 2012-12-03 18:37:30 <owowo> !diff
399 2012-12-03 18:37:31 <BCBot2`> owowo: Error: "diff" is not a valid command.
400 2012-12-03 18:37:31 <gribble> 3438908.9601591383
401 2012-12-03 18:37:51 <owowo> ups, wrong channel ;o)
402 2012-12-03 18:58:26 <Pucilowski> Is any 256 bit value a valid bitcoin private key?
403 2012-12-03 18:58:58 <gmaxwell> No. Not quite.
404 2012-12-03 18:58:59 <gmaxwell> No. Not quite.
405 2012-12-03 19:01:23 <sipa> Well, almost.
406 2012-12-03 19:01:37 <forrestv> Pucilowski, i believe anything in the range [1, 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141] is valid
407 2012-12-03 19:02:22 <sipa> which means that any randomly generated 256-bit number has a chance of around 1 in 2^128 to not be valid
408 2012-12-03 19:02:23 <sipa> which means that any randomly generated 256-bit number has a chance of around 1 in 2^128 to not be valid
409 2012-12-03 19:03:21 <Pucilowski> so thats half as many keys?
410 2012-12-03 19:03:40 <Pucilowski> not half, but 2^128 fewer
411 2012-12-03 19:04:05 <gmaxwell> sipa: ::nods:: though I expect that among people wondering if any value is valid the density of parties using uniform RNGs is lower and the density of people potentially sending 0 is higher. :P
412 2012-12-03 19:05:02 <gmaxwell> Pucilowski: uh no. 2^255 is half of 2^256.
413 2012-12-03 19:05:06 <sipa> gmaxwell: and people trying 2^256-1 (also invalid) is maybe higher as well
414 2012-12-03 19:05:22 <Pucilowski> yeah, I correct myself the line below
415 2012-12-03 19:06:07 <Pucilowski> thats a lot smaller of a number than 2^256
416 2012-12-03 19:06:08 <Pucilowski> thats a lot smaller of a number than 2^256
417 2012-12-03 19:06:48 <sipa> quite so :D
418 2012-12-03 19:07:21 <sipa> so: the vast majority of all 256-bit numbers are valid keys, but not all of them
419 2012-12-03 19:07:22 <sipa> so: the vast majority of all 256-bit numbers are valid keys, but not all of them
420 2012-12-03 19:08:10 <gmaxwell> 12/03/12 19:10:19 SetBestChain: new best=00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048  height=1  work=8590065666  tx=2  date=01/09/09 02:54:25
421 2012-12-03 19:08:11 <gmaxwell> 12/03/12 19:10:19 SetBestChain: new best=00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048  height=1  work=8590065666  tx=2  date=01/09/09 02:54:25
422 2012-12-03 19:08:13 <gmaxwell> 12/03/12 19:47:27 SetBestChain: new best=000000000000048b95347e83192f69cf0366076336c639f9b7228e9ba171342e  height=210000  work=628963747775700992096  tx=9344662  date=11/28/12 15:24:38
423 2012-12-03 19:08:14 <gmaxwell> 12/03/12 19:47:27 SetBestChain: new best=000000000000048b95347e83192f69cf0366076336c639f9b7228e9ba171342e  height=210000  work=628963747775700992096  tx=9344662  date=11/28/12 15:24:38
424 2012-12-03 19:08:34 <sipa> 37:08...
425 2012-12-03 19:08:50 <gmaxwell> thats par8/hal/latest parallel/coins
426 2012-12-03 19:08:51 <gmaxwell> thats par8/hal/latest parallel/coins
427 2012-12-03 19:09:26 <topace> what GUI client supports multi-sig transactions?
428 2012-12-03 19:10:05 <gmaxwell> sipa: seems like its the same/very slightly faster than the prior parallel patch. (again, probably better on hosts with slower sync primitives)
429 2012-12-03 19:10:06 <gmaxwell> sipa: seems like its the same/very slightly faster than the prior parallel patch. (again, probably better on hosts with slower sync primitives)
430 2012-12-03 19:10:27 <gmaxwell> topace: bitcoin-qt supports them, but you need to use the integrated console. It doesn't have a GUI for them.
431 2012-12-03 19:10:40 <gmaxwell> It's a little hard to write a gui for them before people are actually using them.
432 2012-12-03 19:10:50 <topace> heh
433 2012-12-03 19:10:51 <topace> heh
434 2012-12-03 19:11:28 <topace> the console just lets you issue rpc commands? so it'd be the same as running -daemon (or -server ) and doing it from the command line?
435 2012-12-03 19:11:29 <topace> the console just lets you issue rpc commands? so it'd be the same as running -daemon (or -server ) and doing it from the command line?
436 2012-12-03 19:11:42 <sipa> yes
437 2012-12-03 19:11:55 <sipa> and the console even works without -server
438 2012-12-03 19:12:08 <topace> right, but its essentially the same thing
439 2012-12-03 19:12:09 <gmaxwell> yea, it's just a little easier to get to for most gui users.
440 2012-12-03 19:12:09 <topace> right, but its essentially the same thing
441 2012-12-03 19:12:10 <gmaxwell> yea, it's just a little easier to get to for most gui users.
442 2012-12-03 19:12:13 <sipa> -daemon has nothing to do with it, that just bavkgrounds the process
443 2012-12-03 19:12:14 <sipa> -daemon has nothing to do with it, that just bavkgrounds the process
444 2012-12-03 19:12:43 <gmaxwell> (try talking a random windows users through getting to the CLI... takes about 30 minutes before you even get to actually doing something with it)
445 2012-12-03 19:16:55 <sipa> gmaxwell: well, 2 seconds isn't really significant, but the code uses one thread less, so i see no reason not to use it
446 2012-12-03 19:16:56 <sipa> gmaxwell: well, 2 seconds isn't really significant, but the code uses one thread less, so i see no reason not to use it
447 2012-12-03 19:18:28 <sipa> it would also be good to know that having a thread for every HT unit doesn't hurt, as it makes autoconfig easier
448 2012-12-03 19:18:47 <sipa> on your system it even seems to help
449 2012-12-03 19:19:36 <sipa> i wonder whether changing the max batch size to let's say 1000 would have a measurable impact
450 2012-12-03 19:19:38 <gmaxwell> Yea. I can do another par=4 run to see if it still acts that way esp now that we have a worker in the waiting thread.
451 2012-12-03 19:20:20 <gmaxwell> Shall I try that now, or a par=4 run first?
452 2012-12-03 19:20:21 <gmaxwell> Shall I try that now, or a par=4 run first?
453 2012-12-03 19:21:16 <sipa> try the 1000, that's less similar to what we've already done?
454 2012-12-03 19:22:15 <sipa> in theory, it shouldn't hurt, as the exponentially decreasing job sizes at the end of the queue should prevent large variances
455 2012-12-03 19:24:09 <gmaxwell> Running.
456 2012-12-03 19:24:10 <gmaxwell> Running.
457 2012-12-03 19:29:56 <midnightmagic> hah I just explained the core nature of the blockchain to someone inside of about 15 minutes and he grokked it instantly.
458 2012-12-03 19:30:08 <midnightmagic> in IM.
459 2012-12-03 19:30:09 <midnightmagic> in IM.
460 2012-12-03 19:30:17 <midnightmagic> new record.
461 2012-12-03 19:30:18 <midnightmagic> new record.
462 2012-12-03 19:32:54 <sipa> gmaxwell: 1000 is practically unlimited, as i don't think there are blocks with more than 3-4 thousand (actual) sigops, and it would be divided by a number between 8 and 16
463 2012-12-03 20:22:22 <Tykling> does anyone know if this error in db.log can be fixed or if I have to delete everything (except wallet.dat) and download again ?
464 2012-12-03 20:22:23 <Tykling> does anyone know if this error in db.log can be fixed or if I have to delete everything (except wallet.dat) and download again ?
465 2012-12-03 20:22:33 <Tykling> the error: http://pastebin.com/K8xkkPRY
466 2012-12-03 20:23:14 <Tykling> the server was shut down unexpectedly due to power issues and since then I've been unable to start bitcoind
467 2012-12-03 20:26:56 <helo> ouch :/
468 2012-12-03 20:27:38 <helo> you can probably salvage blk????.dat and just -loadblock them
469 2012-12-03 20:28:02 <helo> that will still take hours to recover though
470 2012-12-03 20:30:35 <jgarzik> Tykling: it is possible to recover
471 2012-12-03 20:31:25 <jgarzik> Tykling: but as helo indicates, it is probably easiest to simply delete blkindex.dat, and re-import with -loadblock
472 2012-12-03 20:31:39 <jgarzik> make sure to rename blk000?.dat to something else first
473 2012-12-03 20:33:06 <Tykling> I have backups, so I am considering importing one from the previous day
474 2012-12-03 20:33:10 <Tykling> might be faster
475 2012-12-03 20:33:20 <helo> definitely
476 2012-12-03 20:42:33 <Luke-Jr> yay, 22 GB extra from mkfs.ext3 -i 32768 :P
477 2012-12-03 20:54:00 <EasyAt> Heya, how bad is it to have a wallet copied onto two hard drives?  I made some tx's a few days ago with one machine.  Now, I am looking at the wallet on the other machine, would my account balence be updated(from scanning) even though txs were made on another machine?
478 2012-12-03 20:54:01 <EasyAt> Heya, how bad is it to have a wallet copied onto two hard drives?  I made some tx's a few days ago with one machine.  Now, I am looking at the wallet on the other machine, would my account balence be updated(from scanning) even though txs were made on another machine?
479 2012-12-03 20:56:07 <sipa> you can do this, but it's not supported
480 2012-12-03 20:56:21 <sipa> it *should* be safe, but if things go wrong, it may corrupt your wallet
481 2012-12-03 20:57:41 <EasyAt> Well, my wallet appears to be fine. qt is showing a list of past trtansaction and a balence that is larger than I expected.  When I tried to transfer all the coins out of it, the transaction doesn't appear to have broadcasted(blockchain doesn't have the tx hash)
482 2012-12-03 20:57:50 <gmaxwell> 12/03/12 20:24:10 SetBestChain: new best=00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048  height=1  work=8590065666  tx=2  date=01/09/09 02:54:25
483 2012-12-03 20:57:53 <gmaxwell> 12/03/12 21:01:16 SetBestChain: new best=000000000000048b95347e83192f69cf0366076336c639f9b7228e9ba171342e  height=210000  work=628963747775700992096  tx=9344662  date=11/28/12 15:24:38
484 2012-12-03 20:57:55 <EasyAt> I also checked double spends and did not see it there
485 2012-12-03 20:58:09 <sipa> gmaxwell: 37:06, new record!
486 2012-12-03 20:58:10 <sipa> gmaxwell: 37:06, new record!
487 2012-12-03 20:59:01 <sipa> EasyAt: the basic rule is this: if you spend from one wallet, and wait until all transactions made are shown by the other client, there is no problem
488 2012-12-03 20:59:11 <EasyAt> Hm, that should be the case
489 2012-12-03 20:59:25 <EasyAt> Perhaps I should backup and then try and remove all transactions from the wallet?
490 2012-12-03 20:59:34 <sipa> you can't remove transactions
491 2012-12-03 20:59:35 <sipa> you can't remove transactions
492 2012-12-03 20:59:45 <EasyAt> I thought the wallet caches txs
493 2012-12-03 20:59:52 <EasyAt> the one's that it displays
494 2012-12-03 21:01:09 <sipa> yes
495 2012-12-03 21:01:10 <sipa> yes
496 2012-12-03 21:02:07 <sipa> gmaxwell: so... i think the N/(1+total+idle) rule works very well :)
497 2012-12-03 21:02:45 <EasyAt> So, its calcing my balence based off of those.  Since one of the transaction appears not to be broadcasting, it'd be nice to remove it from the wallet so I can try and reissue it
498 2012-12-03 21:02:55 <EasyAt> err.. right?
499 2012-12-03 21:02:56 <EasyAt> err.. right?
500 2012-12-03 21:03:07 <sipa> why does it seem not to be broadcasting?
501 2012-12-03 21:03:08 <sipa> why does it seem not to be broadcasting?
502 2012-12-03 21:03:25 <sipa> ah, blockchain.info doesn't know about
503 2012-12-03 21:03:35 <sipa> it will rebroadcast automatically +- once every half hour
504 2012-12-03 21:04:20 <EasyAt> Okay, thank you
505 2012-12-03 21:25:56 <jgarzik> w00t
506 2012-12-03 21:25:57 <jgarzik> w00t
507 2012-12-03 21:26:09 <jgarzik> libccoin now signs transactions
508 2012-12-03 21:26:10 <jgarzik> libccoin now signs transactions
509 2012-12-03 21:26:32 <jgarzik> handling reorgs is the last big todo
510 2012-12-03 21:26:42 <sipa> gmaxwell: anything else we should try?
511 2012-12-03 21:27:43 <gmaxwell> I still need to try goofing with the caching stuff. I guess I'll test that next.
512 2012-12-03 21:27:44 <gmaxwell> I still need to try goofing with the caching stuff. I guess I'll test that next.
513 2012-12-03 21:27:57 <sipa> caching stuff?
514 2012-12-03 21:27:58 <sipa> caching stuff?
515 2012-12-03 21:28:04 <gmaxwell> the signature caching.
516 2012-12-03 21:28:08 <sipa> oh, yes
517 2012-12-03 21:28:22 <gmaxwell> Also, this needs to be wired up to cpu detection??? don't we have that for mining?
518 2012-12-03 21:28:23 <gmaxwell> Also, this needs to be wired up to cpu detection??? don't we have that for mining?
519 2012-12-03 21:29:19 <sipa> yup boost:thread::hardware_concurrency()
520 2012-12-03 21:30:22 <jgarzik> ACTION wonder how that fares WRT HyperThreading
521 2012-12-03 21:30:25 <jgarzik> *wonders
522 2012-12-03 21:30:44 <sipa> jgarzik: gmaxwell so far has been seeing better performance with 8 verifier threads than 4
523 2012-12-03 21:35:15 <jgarzik> IIRC HT means you have N execution units with N*2 hardware states/register sets
524 2012-12-03 21:35:29 <sipa> correct
525 2012-12-03 21:35:30 <sipa> correct
526 2012-12-03 21:36:14 <sipa> and boost::thread::hardware_concurrency() returns 2*N then
527 2012-12-03 21:36:53 <sipa> and at least in case of gmaxwell's CPU (where N=4), 8 verifier threads seems (slightly) faster then 4
528 2012-12-03 21:37:39 <gmaxwell> well thats on some of the latest intel stuff, which has HT which sucks less than their last attempt.
529 2012-12-03 21:38:02 <gmaxwell> so it still might be horrible on something out there, but oh well.
530 2012-12-03 21:39:53 <sipa> ACTION things we will very quickly see requests for CPU throttling...
531 2012-12-03 21:40:04 <sipa> *thinks
532 2012-12-03 21:40:56 <jgarzik> a max threads CLI option is common and seems fair
533 2012-12-03 21:40:57 <jgarzik> a max threads CLI option is common and seems fair
534 2012-12-03 21:41:06 <jgarzik> people with VMs might care
535 2012-12-03 21:41:27 <phantomcircuit> sipa, nice
536 2012-12-03 21:41:28 <phantomcircuit> lawl
537 2012-12-03 21:41:31 <sipa> jgarzik: currently there is just -par=N in the pull request, and the default is 1
538 2012-12-03 21:45:40 <sipa> gmaxwell: any chance to run it on your 32-core system? :p
539 2012-12-03 21:53:49 <Impaler> anyone have the link for dependencies for bitcoin?
540 2012-12-03 21:54:35 <Impaler> their are packages of all the neassary dependencies someware but its impossible to google for them
541 2012-12-03 21:55:31 <doublec> Impaler: they're listed in the docs directory of the source
542 2012-12-03 21:55:32 <doublec> Impaler: they're listed in the docs directory of the source
543 2012-12-03 21:55:41 <gmaxwell> sipa: eventually par should default to zero which means auto. :)
544 2012-12-03 21:55:46 <sipa> gmaxwell: ack
545 2012-12-03 21:55:47 <sipa> gmaxwell: ack
546 2012-12-03 21:55:49 <Impaler> listed but is their a download?
547 2012-12-03 21:56:02 <sipa> for which OS?
548 2012-12-03 21:56:03 <sipa> for which OS?
549 2012-12-03 21:56:11 <sipa> and just binarier, or their sources?
550 2012-12-03 21:56:12 <sipa> and just binarier, or their sources?
551 2012-12-03 21:56:22 <gmaxwell> doublec: debian/ubuntu package names are listed IIRC. little annoying if you're not on those and don't know that "ssl" is "openssl" elsewhere, etc.
552 2012-12-03 21:56:23 <gmaxwell> doublec: debian/ubuntu package names are listed IIRC. little annoying if you're not on those and don't know that "ssl" is "openssl" elsewhere, etc.
553 2012-12-03 21:56:24 <sipa> and for compilation, or just runtime dependencies?
554 2012-12-03 21:56:53 <doublec> gmaxwell: true, I'm not running debian/ubuntu so I can relate to that
555 2012-12-03 21:57:00 <Impaler> I'm sure their is a consolidated dependency package made for bitcoin
556 2012-12-03 21:57:10 <gmaxwell> doublec: what do you run, in any case?
557 2012-12-03 21:57:11 <Impaler> compilation
558 2012-12-03 21:57:12 <Impaler> compilation
559 2012-12-03 21:57:18 <doublec> gmaxwell: gentoo
560 2012-12-03 21:57:38 <gmaxwell> doublec: I like that on my itanium. I expect that I'll end up there on my desktop eventually.
561 2012-12-03 21:57:55 <Impaler> I'm using Qt Creator on Windows
562 2012-12-03 21:57:57 <doublec> gmaxwell: I wanted a rolling distro - or as close to one as possible - and gentoo seemed the choice there
563 2012-12-03 21:58:00 <sipa> gmaxwell: any reason to assume the current parallel code is not the best yet?
564 2012-12-03 21:58:19 <gmaxwell> sipa: current meaning with or without the 16 -> 1000 change?
565 2012-12-03 21:58:20 <gmaxwell> sipa: current meaning with or without the 16 -> 1000 change?
566 2012-12-03 21:58:41 <sipa> without, but i think i'll increase the limit if it doesn't hurt
567 2012-12-03 21:58:42 <sipa> without, but i think i'll increase the limit if it doesn't hurt
568 2012-12-03 21:58:58 <gmaxwell> yea, didn't seem to hurt, may help on windows/mac.
569 2012-12-03 21:59:14 <sipa> i mean, this is the 3rd version of the parallel code, and afaik there have been slight improvements in performance each time, but never significant
570 2012-12-03 22:00:00 <sipa> 128 would correspond to +- 0.1s on common systems; i don't think work units longer than that make any sense
571 2012-12-03 22:00:01 <sipa> 128 would correspond to +- 0.1s on common systems; i don't think work units longer than that make any sense
572 2012-12-03 22:01:26 <sipa> gmaxwell: by the way, what CPU% usage do you see?
573 2012-12-03 22:01:47 <gmaxwell> sipa: looks like htop is normally claiming somehting like 85% which sounds rather low.
574 2012-12-03 22:02:31 <sipa> well all the time spent reading blocks from disk, and synchronizing runs single-threaded
575 2012-12-03 22:02:50 <sipa> though i wouldn't expect those to be very slow on tmpfs :D
576 2012-12-03 22:03:40 <sipa> still, each time waiting until all threads are stopped, and then restarting must have its cost
577 2012-12-03 22:06:52 <sipa> anyway, no point in trying to optimizing the last 1% out of this; no way we can reach optimum performance with scheme, but it's certainly a vast improvement for a relatively easy change
578 2012-12-03 22:21:52 <jgarzik> sipa: is the reading of transaction dependencies also parallel?
579 2012-12-03 22:22:16 <sipa> jgarzik: no, but reading the transaction dependencies is parallel with verifying those that have been read
580 2012-12-03 22:26:05 <etotheipi_> so it sounds like I should update Armory coin selection:  on load, it should cluster your wallet into groups of addresses that have already been associated, and then treat all those as one pool for evaluating the "input anonymity" of the tx
581 2012-12-03 22:26:42 <optimator> when submitting a block I get "hashMerkleRoot mismatch" can this error be caused by a submitting a "stale" block, or is it saying I calculated something wrong?
582 2012-12-03 22:27:48 <gmaxwell> etotheipi_: probably. Thats basically what I suggested and was thinking about doing before I merged the grouping stuff into bitcoin. After doing it and benchmarking it, I'm less convinced wrt the performance. I suppose if you periodically precalculated that would work.
583 2012-12-03 22:28:31 <etotheipi_> so how do you penalize merging of groups?  if you have a group of 3 and a group of 4 addresses, and a transaction would link one from each, it would effectively merge those two groups of addresses, and I guess you'd say that the solution should be penalized for adding the smaller number to the bigger one
584 2012-12-03 22:28:42 <etotheipi_> i.e. - you already have a cluster of 4, now you have made it a cluster of 7
585 2012-12-03 22:29:08 <etotheipi_> gmaxwell: I would cluster the addresses on load, probably not each transaction
586 2012-12-03 22:30:52 <etotheipi_> gmaxwell: though I don't know why the performance would be poor if you were just std::set<> operations
587 2012-12-03 22:31:09 <etotheipi_> I would think it would actually be quite fast... on the order of how many transactions there are relevant to your wallet
588 2012-12-03 22:31:10 <etotheipi_> I would think it would actually be quite fast... on the order of how many transactions there are relevant to your wallet
589 2012-12-03 22:31:13 <gmaxwell> etotheipi_: I burned up some brain cells thinking of that.   My thinking eventually said that minimizing the Lp norm (for some p) over the resulting groups (e.g. after the txn happens) is probably a good thing.
590 2012-12-03 22:31:24 <gmaxwell> er. Lp norm of the resulting group sizes.
591 2012-12-03 22:31:40 <sipa> should amounts be taken into account?
592 2012-12-03 22:32:09 <gmaxwell> sipa: the problem is that the publicness of an address is not uniform, and its often not related to the values.
593 2012-12-03 22:32:26 <sipa> i.e. is linking two groups that each represent a high amount worse than linking two groups with low amount? (all other things being equal)
594 2012-12-03 22:32:34 <gmaxwell> E.g. someone paying in a constant spray of 1e-8 inputs to 1GMaxwell  (even if thats the only user of 1Gmaxwell ever) should not get linked.
595 2012-12-03 22:33:09 <gmaxwell> I'd think you'd want to make groups more uniform in value all things equal.
596 2012-12-03 22:33:10 <etotheipi_> gmaxwell: wouldn't you want to *increase* Lp norm?
597 2012-12-03 22:33:48 <etotheipi_> ideally all your addresses are unlinked, and your LP norm is just pth-root of the number of addresses
598 2012-12-03 22:34:05 <etotheipi_> oh wait
599 2012-12-03 22:35:08 <etotheipi_> nm, I got it
600 2012-12-03 22:35:22 <etotheipi_> so evaluate the LP norm of the entire address set?
601 2012-12-03 22:35:50 <gmaxwell> well you can compute a change in lp norm without recalculating everything.
602 2012-12-03 22:35:57 <etotheipi_> agreed
603 2012-12-03 22:35:58 <etotheipi_> agreed
604 2012-12-03 22:36:25 <etotheipi_> so why is that slow?
605 2012-12-03 22:36:39 <etotheipi_> I would think that would be very fast... unless you're talking about finding optimal solutions
606 2012-12-03 22:37:10 <gmaxwell> etotheipi_: the norm stuff isn't, doing the recursive grouping to get the groups is potentially slow. esp if the wallet has been dos attacked with thousands of tiny inputs.
607 2012-12-03 22:37:50 <sipa> union-find algorithm can be implemented with time O(n*alpha(n)), with alpha = inverse ackerman function
608 2012-12-03 22:38:07 <sipa> which is O(n) for all practically feasible values of n
609 2012-12-03 22:38:45 <etotheipi_> I'm thinking you have a set of sets, and each operation either adds an element to a set, creates a new set, or merges a set
610 2012-12-03 22:38:52 <etotheipi_> *merges two sets
611 2012-12-03 22:39:03 <sipa> etotheipi_: look up union-find
612 2012-12-03 22:39:47 <etotheipi_> sipa: thanks
613 2012-12-03 22:39:54 <sipa> it's very easy to implement
614 2012-12-03 22:40:38 <sipa> you keep a map from elements to (pointers to) elements, and each set becomes represented by a root of a tree, and all other elements in the tree point upwards
615 2012-12-03 22:41:58 <D34TH> sipa: if you know what SPDY is what is your opinion on it?
616 2012-12-03 22:42:27 <sipa> D34TH: yes, i know SPDY... but i know little about its details
617 2012-12-03 22:42:36 <sipa> it works nicely though
618 2012-12-03 22:42:52 <D34TH> do you think it would be worth implementing into a pool software?
619 2012-12-03 22:43:12 <D34TH> no miners support it yet
620 2012-12-03 22:43:27 <D34TH> but it would be kinda cool
621 2012-12-03 22:43:31 <sipa> i don't know enough about the complexity of implementation
622 2012-12-03 22:43:50 <D34TH> i was going to use it to serve work from bitcoind
623 2012-12-03 23:00:27 <optimator> any one familiar with the "hashMerkleRoot mismatch" in debug.log?
624 2012-12-03 23:04:33 <sipa> optimator: "familiar" is a strong statement, but i'm quite sure it means the merkle root provided in the block header doesn't match the merkle root calculated from the transaction list
625 2012-12-03 23:08:59 <optimator> sipa: ok, thanks