1 2012-08-06 00:22:12 <gribble> New news from bitcoinrss: gmaxwell opened issue 1654 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1654>
  2 2012-08-06 00:47:43 <amiller> another advantage of that skip list thing is that if someone wanted to prove that a supposed fork had an invalid work somewhere, it would be easy provide a proof of exactly where that occurs
  3 2012-08-06 00:48:56 <amiller> yeah i'm splitting hairs at this point... i'm pretty much done with this whole train of thought since i found what i wanted.
  4 2012-08-06 01:06:54 <Diablo-D3> Curiosity coverage starts on NASA TV in 24 minutes: http://www.ustream.tv/nasahdtv
  5 2012-08-06 01:07:17 <Diablo-D3> Curiosity lands on Mars in 2 hours and 24 minutes.
  6 2012-08-06 01:16:37 <Joric> what's so special it's just the 13th artificial object on mars
  7 2012-08-06 01:16:56 <jgarzik> neat.  my by-height index makes finding the common root of two chains trivial.
  8 2012-08-06 01:17:06 <jgarzik> that makes reorg pretty easy
  9 2012-08-06 01:59:38 <amiller> roconnor, go on?
 10 2012-08-06 02:03:47 <roconnor> amiller: Oh; I store blocks in an off the shelf priority search queue. The priority of a block is the total work it builds on, the search key is the block Id.
 11 2012-08-06 02:04:10 <roconnor> amiller: therefor the block with the most work is alway at the top of the priority queue
 12 2012-08-06 02:04:33 <amiller> i see
 13 2012-08-06 02:04:37 <roconnor> each block stores its previous block
 14 2012-08-06 02:04:56 <amiller> are you talking about actually building that structure into the block protocol
 15 2012-08-06 02:04:58 <roconnor> so you can pull the latest n blocks by lookup up each previous block
 16 2012-08-06 02:05:00 <amiller> meaning that structure gets hashed
 17 2012-08-06 02:05:42 <amiller> the 'block chain' is just the bottom row of a skip list
 18 2012-08-06 02:05:53 <roconnor> no; I'm just talking about how purecoin represents the blocks it knows about internally
 19 2012-08-06 02:05:57 <amiller> each level of the skip list is for another of difficulty
 20 2012-08-06 02:05:58 <amiller> oh okay
 21 2012-08-06 02:06:08 <roconnor> there is no "reorg" code in purecoin
 22 2012-08-06 02:06:20 <amiller> it's just a pure function
 23 2012-08-06 02:06:39 <roconnor> the priority queue gives access to the block with the most work automatically.
 24 2012-08-06 02:06:55 <amiller> you can bisect search to find a fork point then
 25 2012-08-06 02:07:02 <roconnor> no matter how it got there.
 26 2012-08-06 02:07:08 <roconnor> nope
 27 2012-08-06 02:07:18 <roconnor> no fork points needed
 28 2012-08-06 02:07:28 <jgarzik> well "reorg" is only necessary if you are maintaining a tx-spent index for only a single chain
 29 2012-08-06 02:08:01 <jgarzik> if you don't care about tx-spent or you index multiple forks, no reorg necessary
 30 2012-08-06 02:08:13 <roconnor> jgarzik: that's true; purecoin keeps a tx-spend index for every chain which I admit is a huge waste.
 31 2012-08-06 02:08:47 <amiller> even a tx spend index has mostly redundant data if you store it as a tree
 32 2012-08-06 02:09:48 <jgarzik> roconnor: that is arguably superior to satoshi client behavior, which simply gets stuck if it meets a block containing spent tx's during reorg.
 33 2012-08-06 02:10:00 <amiller> hrm
 34 2012-08-06 02:10:23 <jgarzik> it gets un-stuck when a stronger chain comes along, of course
 35 2012-08-06 02:27:36 <amiller> okay so i used to hate on merged mining
 36 2012-08-06 02:27:46 <amiller> this new work-gobbling stuff has great implications for merged mining
 37 2012-08-06 02:29:09 <amiller> if a subset of miners are interested in a merged chain, even if the main chain pulls them in by recommitting their transactions in a different block
 38 2012-08-06 02:29:34 <amiller> there will be a record in the main chain of the merging-event, which will include the alt-chain-specific proofs of work
 39 2012-08-06 02:29:50 <gmaxwell> um. That isn't making sense to me.
 40 2012-08-06 02:30:08 <gmaxwell> Merged mining isn't.
 41 2012-08-06 02:30:30 <gmaxwell> (The 'merged' chains don't read the main chain at all)
 42 2012-08-06 02:32:18 <amiller> so merged chains rely on the blockchain to function as a general purpose timestamp service
 43 2012-08-06 02:32:28 <amiller> the blockchain might also function as a general purpose work-validation service
 44 2012-08-06 02:33:37 <amiller> meh it probably has no practical use
 45 2012-08-06 02:41:17 <luke-jr> amiller: "merged mining" amounts to "proof of work is not SHA256(SHA256(block header)), but SHA256(SHA256(80 bytes with 36-68 being a merkle root with index 0 containing the hash of this block's header))"
 46 2012-08-06 02:41:29 <gmaxwell> 21:32 < amiller> so merged chains rely on the blockchain to function as a general purpose timestamp service
 47 2012-08-06 02:41:32 <gmaxwell> no. no timestamping
 48 2012-08-06 02:42:02 <gmaxwell> Which is important, because it means that some merged chain can implement your crazy ideas while still sharing work with bitcoin.
 49 2012-08-06 02:43:08 <amiller> i suppose that's the greater relief.
 50 2012-08-06 02:44:55 <gribble> New news from bitcoinrss: gmaxwell opened pull request 1655 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1655>
 51 2012-08-06 02:45:21 <gmaxwell> The telemetry visualizer for the mars landing looks like bzflag. 0_o
 52 2012-08-06 02:45:29 <amiller> you said that merged chains don't read the blockchain
 53 2012-08-06 02:45:41 <gmaxwell> They don't.
 54 2012-08-06 02:45:43 <amiller> what happens if someone gets an alt-chain header into a block and no one notices
 55 2012-08-06 02:45:51 <amiller> but later it is revealed that it came first
 56 2012-08-06 02:46:17 <amiller> or it has absolutely nothing to do with the blockchain
 57 2012-08-06 02:46:22 <gmaxwell> amiller: what happens if you mine a bitcoin block and forget to announce it until later? Same thing.
 58 2012-08-06 02:46:29 <gmaxwell> Absolutely nothing.
 59 2012-08-06 02:46:35 <amiller> there can be a different logical order then
 60 2012-08-06 02:46:47 <gmaxwell> It really has nothing to do with the blockchain. See what luke said above.
 61 2012-08-06 02:47:02 <amiller> so it shares work but absolutely nothing else
 62 2012-08-06 02:47:11 <amiller> hmm okay i always thought there was something more complicated going on
 63 2012-08-06 02:47:58 <gmaxwell> bitcoin's POW is sha256^2(header), merged chain's POW is sha256^2(bunch of ignored garbage... tree root.. garbage), and the real header is committed in the tree root.
 64 2012-08-06 02:48:40 <amiller> it still bugs me that a bunch of main-chain miners could decide they dislike a merged chain and wage war on it without even interfering with their profit on the main chain
 65 2012-08-06 02:49:13 <amiller> if you want to attack a chain, there should be an opportunity cost
 66 2012-08-06 02:50:21 <theymos> Alt chains could require a small fixed proof-of-work of their own in addition to merged mining.
 67 2012-08-06 02:50:46 <gmaxwell> amiller: the opportunity cost is the cost of defecting from legit behavior on the merged chain. Or as theymos says it could be a staged POW.
 68 2012-08-06 02:50:50 <amiller> theymos, then there's no use of being merged unless there's some other benefit, such as logical time stamping or work checking
 69 2012-08-06 02:51:04 <amiller> gmaxwell, but it's legit behavior on the merged chain
 70 2012-08-06 02:51:26 <amiller> er it's legit behavior on the main chain
 71 2012-08-06 02:51:53 <amiller> it's antagonistic fork-ing or black-out behavior only to the merged chain
 72 2012-08-06 02:51:59 <gmaxwell> amiller: they lose the benefit of particpating on the merged chain of course' it's _also_ possible for a merged chain to use things like time from the main chain to prevent some attacks.
 73 2012-08-06 02:52:03 <gmaxwell> P2pool does that.
 74 2012-08-06 02:52:24 <amiller> then you are using the main-chain's logical order for something
 75 2012-08-06 02:52:47 <gmaxwell> Yes, indeed. Thats the tradeoff.
 76 2012-08-06 02:52:56 <gmaxwell> The way namecoin uses it is maximally independant.
 77 2012-08-06 02:53:13 <amiller> so it would be considered invalid in the merge chain if you had a block that went logically backwards in the main chain
 78 2012-08-06 02:53:16 <gmaxwell> Which has perks including e.g. if the main chain fails it doesn't hurt merged chains at all.
 79 2012-08-06 02:53:25 <amiller> but you would have to monitor the main-chain in order to see that
 80 2012-08-06 02:53:50 <gmaxwell> amiller: well, only the minimum data required to achieve that. E.g. if you're only taking the time then you already have that data.
 81 2012-08-06 02:54:59 <jgarzik> theymos: any chance you could update http://blockexplorer.com/testnet to git HEAD?
 82 2012-08-06 02:55:26 <theymos> jgarzik: OK, I'll do it tomorrow.
 83 2012-08-06 02:55:47 <jgarzik> theymos: thanks
 84 2012-08-06 02:57:31 <gmaxwell> theymos: Thanks!
 85 2012-08-06 02:58:00 <gmaxwell> theymos: you might want to set aside a bit of time to fix bugs that it'll trigger in your software. :)
 86 2012-08-06 02:58:15 <theymos> What bugs will it trigger?
 87 2012-08-06 02:59:46 <gmaxwell> Who knows!
 88 2012-08-06 02:59:55 <gmaxwell> theymos: there are a lot of testcases in the testnet3 chain however.
 89 2012-08-06 03:00:12 <gmaxwell> Including a bunch of strange transactions, maximum sized blocks, etc.
 90 2012-08-06 03:01:40 <theymos> I use Bitcoin's internal data structures directly and its own toString stuff, so I think bugs are unlikely. Maybe I'll be surprised, though. :)
 91 2012-08-06 03:01:55 <gmaxwell> Good then.
 92 2012-08-06 03:02:16 <gmaxwell> theymos: some of your patches may not be needed anymore too, which should be nice.
 93 2012-08-06 03:04:42 <luke-jr> (but you'll need to learn JSON-RPC 2.0 batching&)
 94 2012-08-06 03:05:45 <copumpkin> we're landing on mars soon!
 95 2012-08-06 03:05:56 <copumpkin> I hear the probe has a bitcoin client on it
 96 2012-08-06 03:06:03 <copumpkin> but the blockchain sync will take forever
 97 2012-08-06 03:06:13 <theymos> gmaxwell: Yeah, I saw that getblock was changed to be more complete. Pretty nice. Patches have always been a pain.
 98 2012-08-06 03:07:17 <gmaxwell> theymos: so, in theory you should be able to work now with an entirely unpatched bitcoind, but I may be missing something.
 99 2012-08-06 03:07:47 <gmaxwell> (but as far as I know we have the complete blockexplorer functionality internally except index-by-address and the balance sheets that go with it)
100 2012-08-06 03:10:37 <copumpkin> you'd need way more database on disk though
101 2012-08-06 03:10:42 <copumpkin> or a very slow UI :)
102 2012-08-06 03:12:14 <Joric> #nasa unable to join channel (channel is full)
103 2012-08-06 03:12:29 <theymos> gmaxwell: I think it is enough for the current functionality. In the future I was hoping to add pages for memory pool transactions and detailed info on addresses, alerts, etc. Patches will probably be necessary for this stuff.
104 2012-08-06 03:12:45 <gmaxwell> theymos: we can dump the memory pool too.
105 2012-08-06 03:13:14 <gmaxwell> Alerts .. yea, don't get detailed information... though I think we'd take a getalerts upstream if someone wanted to offer one.
106 2012-08-06 03:13:58 <gmaxwell> (in particular you getrawmempool then getrawtransaction [id] 1 on each thing it returns)
107 2012-08-06 03:14:55 <theymos> Ah, cool. Might be nice for bitcoind to send each new memory pool transaction somewhere for immediate processing, though.
108 2012-08-06 03:18:04 <luke-jr> it already does&
109 2012-08-06 03:18:07 <luke-jr> all its peers
110 2012-08-06 03:27:33 <amiller> the coolest thing about bitcoin is that the hard part is related to consensus, the conceptually easier part is the whole gossip network
111 2012-08-06 03:27:39 <amiller> i just found this neat paper about anonymous publish/subscribe
112 2012-08-06 03:27:40 <amiller> http://enstb.org/~gsimon/Resources/ipdps03-pubsub.pdf
113 2012-08-06 03:27:55 <amiller> it basically functions as a directed acyclic graph, which is exactly what all of these chains and trees and skip lists are
114 2012-08-06 03:28:26 <amiller> full nodes basically have all of their storage
115 2012-08-06 03:28:54 <amiller> but it would be really efficient and scalable to distributed the storage and if you wanted to download e.g. the whole blockchain, you could automatically load balance kind of like in bittorrent
116 2012-08-06 03:31:21 <amiller> bitcoin is totally prepared for interplanetary information dissemination.
117 2012-08-06 03:31:29 <amiller> it's so sexy
118 2012-08-06 03:32:54 <Diablo-D3> CURIOSITY HAS LANDED
119 2012-08-06 03:32:55 <amiller> we'll be able to tweak it and scale it past any challenge you could throw at it.
120 2012-08-06 03:33:02 <amiller> man i wish there was a bitcoin miner on mars
121 2012-08-06 03:33:08 <amiller> that is so gonna be a kickstarter soon
122 2012-08-06 03:33:16 <amiller> that would be a nice awareness-raiser
123 2012-08-06 03:33:26 <amiller> you could put a bitcoin miner on mars
124 2012-08-06 03:33:29 <amiller> and it pays itself bitcoins
125 2012-08-06 03:33:34 <amiller> eventually when astronauts get to mars
126 2012-08-06 03:33:40 <amiller> they'll be able to take the private key and buy porn with it
127 2012-08-06 03:33:48 <amiller> or drugs
128 2012-08-06 03:34:37 <gmaxwell> amiller: dude CURIOSITY HAS LANDED. stop with your drug key worries!
129 2012-08-06 03:35:37 <amiller> anyway the last time a mining operation began on mars it didn't end so well http://free.pages.at/hbredel/dateien/Descent.gif
130 2012-08-06 03:43:20 <Joric> mining operation? )
131 2012-08-06 03:57:10 <jgarzik> Scanned 942 tx, height 4033 (0 failures), 143.89 sec
132 2012-08-06 03:57:46 <jgarzik> replace deepcopy with a manual copy, bringing script eval time down to 144 sec, from ~820 sec or so
133 2012-08-06 03:59:14 <jgarzik> still painful for large numbers of inputs
134 2012-08-06 03:59:36 <jgarzik> For 3,000 inputs, SignatureHash winds up creating 3,000 CTransaction copies, each with 3,000 inputs
135 2012-08-06 04:00:32 <copumpkin> is Maged able to view private messages on the forum?
136 2012-08-06 04:00:44 <copumpkin> as a global moderator?
137 2012-08-06 04:01:19 <Maged> No. Only theymos can, and only in specific circumstances.
138 2012-08-06 04:01:26 <copumpkin> ah, okay
139 2012-08-06 04:32:14 <weex> with 14 mins of delay between earth and mars, how many blocks per day would you set for an earth-mars coin so as not too have too many orphans/mining waste?
140 2012-08-06 04:33:02 <amiller> weex, what matters is that no more than half of your work gets wasted on orphaned forks
141 2012-08-06 04:33:46 <amiller> of course that's easy to do - it happens when the average time to find a block is at least 14 minutes
142 2012-08-06 04:34:13 <weex> oh so it doesn't have to be 1 blk per day or anything that slow
143 2012-08-06 04:34:18 <amiller> not at all
144 2012-08-06 04:34:36 <amiller> it could even be faster if you were willing to tolerate only a 20% attacker instead of 33% or something
145 2012-08-06 04:34:50 <amiller> of course we're running bitcoin right now as though we were already spread out half way to mars :3
146 2012-08-06 04:35:55 <weex> lol, nice
147 2012-08-06 04:35:58 <amiller> our computers are so fast that we keep the difficulty high just because we don't even have enough transactions to warrant going faster so there's actually plenty of slack for the network to get worse
148 2012-08-06 04:37:23 <gmaxwell> amiller: validation takes a lot of time on top of propagation.
149 2012-08-06 04:37:49 <gmaxwell> amiller: we're seeing e.g. 2 minute propagation times in practice.
150 2012-08-06 04:38:07 <amiller> we'll eventually be able to validate while we propagate
151 2012-08-06 04:38:13 <amiller> since validation only requires local information
152 2012-08-06 04:38:40 <amiller> validation and propagation both essentially scale
153 2012-08-06 04:38:50 <amiller> but yeah if propagation is 2 minutes then i suppose you add that to the 14 minutes
154 2012-08-06 04:39:32 <gmaxwell> amiller: also if you're at the edge of latency you'll sometimes have big reorgs from races if the hashrate is well split.
155 2012-08-06 04:40:02 <weex> so gmaxwell you say less blocks per day?
156 2012-08-06 04:41:13 <amiller> as long as the difficulty to propagation ratio is at least 1:1 then basically there's a 50/50% chance that the next block will be found and propagated before the second bock is found
157 2012-08-06 04:41:24 <amiller> so reorgs still resolve exponentially quick
158 2012-08-06 04:42:15 <weex> is that 2 min propogation time from miners who seem not to be updated or from some other measurement?
159 2012-08-06 04:42:19 <gmaxwell> amiller: something like 1 in 100 race events would result in a six block reorg in that case.
160 2012-08-06 04:42:48 <amiller> yeah
161 2012-08-06 04:43:01 <amiller> well i suppose it's always safer to set the difficulty as high as you can tolerate
162 2012-08-06 04:43:37 <gmaxwell> actually 2.25% would be 6 or longer, at the mean = propagation, and 50% on each side.
163 2012-08-06 04:44:12 <amiller> i bet we can super streamline propagation
164 2012-08-06 04:44:59 <gmaxwell> Yes, working on it.. but you can't streamline the speed of light.. so you really do need a healty margin over the part you can't improve. :)
165 2012-08-06 04:45:05 <amiller> mm
166 2012-08-06 04:45:07 <amiller> yeah
167 2012-08-06 04:45:08 <gmaxwell> (pratically, to make the system sanely usable... )
168 2012-08-06 04:46:24 <amiller> well i wonder at what point it's preferable just to wait for more blocks and cope with the reorgs
169 2012-08-06 04:46:46 <amiller> like you can't double the difficulty and then trust 3 block confirmations
170 2012-08-06 04:47:19 <amiller> if you want the most safety in the fastest time
171 2012-08-06 04:47:21 <amiller> you'll hit 1:1
172 2012-08-06 04:53:22 <gmaxwell> amiller: True, but I think the question people are usually asking there is "how long must I wait to consider a transaction settled".
173 2012-08-06 04:53:39 <gmaxwell> And certantly including mars makes that a honking big number.
174 2012-08-06 04:54:00 <amiller> yeah. definitely that time will increase quite a bit
175 2012-08-06 04:54:22 <amiller> so it's misleading for me to say 'oh you just increase the difficulty a bit' because more than that changes too
176 2012-08-06 04:55:01 <phantomcircuit> gmaxwell, it's a hard technical question but a relatively easy economic question
177 2012-08-06 04:55:02 <weex> people have a concept that a confirmation is a confirmation is a confirmation
178 2012-08-06 04:55:19 <amiller> i've changed my focus from 'byzantine consensus' to 'self stabilizing systems'
179 2012-08-06 04:55:25 <amiller> it eventually converges
180 2012-08-06 04:55:41 <amiller> but it's not totally defined how long that will take
181 2012-08-06 04:55:57 <amiller> the odds get exponentially better in your favor the longer you wait
182 2012-08-06 04:56:04 <amiller> i think there will ultimately end up being some kind of risk analysis to do
183 2012-08-06 04:56:15 <amiller> maybe you'll be able to purchase fork insurance
184 2012-08-06 05:06:24 <midnightmagic> well it isn't hard to calculate the odds of a tx being overwritten. it's right there in satoshi's paper. mapping your comfort level to the calculation is a bit harder..
185 2012-08-06 05:08:26 <gmaxwell> midnightmagic: we're talking about attacker free reorg risks when the network is split in half with a communication delay equal to mean block time.
186 2012-08-06 05:08:41 <midnightmagic> like perfectly in half?
187 2012-08-06 05:08:47 <gmaxwell> sure. Thats the worst case.
188 2012-08-06 05:09:30 <gmaxwell> e.g. if half the hashpower is on mars, 14 lightminutes away, and the mean block time is 14 minutes.
189 2012-08-06 05:09:51 <midnightmagic> you mean amiller's research topics?
190 2012-08-06 05:10:37 <gmaxwell> weex asked about block times for mining on mars.
191 2012-08-06 05:10:43 <Gladamas> Libertarians talking about how a NASA Mars rover can mine their digital currency... what has this world come to?
192 2012-08-06 05:10:51 <amiller> :>
193 2012-08-06 05:11:04 <weex> oh, i never thought about the rover itself mining
194 2012-08-06 05:11:10 <weex> nice Gladamas
195 2012-08-06 05:11:22 <Gladamas> lol
196 2012-08-06 05:11:24 <amiller> imagine if we prepare a little colony on mars
197 2012-08-06 05:11:26 <weex> maybe at night
198 2012-08-06 05:11:27 <Gladamas> lmao
199 2012-08-06 05:11:28 <amiller> and we esatablish its economy first
200 2012-08-06 05:11:38 <gmaxwell> Gladamas: I'm not a libertarian. Or rather, I might be, but I'm certantly not what most of the crazy internet people calling themselves libertarians are.
201 2012-08-06 05:11:52 <amiller> we're all cypherpunks
202 2012-08-06 05:11:55 <amiller> better living through cryptography
203 2012-08-06 05:11:59 <Gladamas> No offense intended to anyone.
204 2012-08-06 05:12:15 <luke-jr> gmaxwell: LOL
205 2012-08-06 05:13:57 <weex> oh, the delay to mars varies from 8-42 minutes!
206 2012-08-06 05:14:18 <amiller> oh shit.
207 2012-08-06 05:14:21 <amiller> i forgot about the darkside!
208 2012-08-06 05:14:30 <amiller> and the elliptical orbit
209 2012-08-06 05:14:36 <weex> i think we're assuming a global network over there first
210 2012-08-06 05:14:48 <Diablo-D3> there isnt one
211 2012-08-06 05:14:52 <gmaxwell> yea, I gave all these figures in #bitcoin a few days ago.
212 2012-08-06 05:14:55 <Diablo-D3> we really need two or three communications sats
213 2012-08-06 05:15:00 <Diablo-D3> well, really, spy sats
214 2012-08-06 05:15:09 <amiller> is it easy to compute in space
215 2012-08-06 05:15:21 <Diablo-D3> amiller: no
216 2012-08-06 05:15:25 <amiller> heat sinks don't work well do they
217 2012-08-06 05:15:28 <Diablo-D3> well, "yeS"
218 2012-08-06 05:15:30 <amiller> space doesn't conduct heat away very well
219 2012-08-06 05:15:30 <Diablo-D3> but you cant dump heat
220 2012-08-06 05:15:36 <amiller> damn
221 2012-08-06 05:15:40 <Diablo-D3> its not that they dont work well... its that they dont work at all
222 2012-08-06 05:15:56 <amiller> that's a pretty big problem
223 2012-08-06 05:16:15 <amiller> maybe you'd have to wrap your gpu in a giant heat diaper and then occasionally send someone out to change the warm diaper
224 2012-08-06 05:16:51 <amiller> maybe you can collect space debris and just pour heat into it
225 2012-08-06 05:16:58 <midnightmagic> or just long threads of copper spread out wide to maximize thermal radiation
226 2012-08-06 05:17:08 <weex> c'mon let's be serious, there are no repairmen in space!
227 2012-08-06 05:17:10 <midnightmagic> giant infrared heat sinks.
228 2012-08-06 05:17:16 <amiller> that's interesting
229 2012-08-06 05:17:24 <amiller> you could easily spread wire out in all dimensions
230 2012-08-06 05:17:24 <midnightmagic> with a shield on the sun side.
231 2012-08-06 05:17:40 <weex> yeah black body radiation is pretty much all you've got out there
232 2012-08-06 05:17:59 <amiller> what an interesting set of problems.
233 2012-08-06 05:18:41 <amiller> there's gotta be a spacecoin bounty
234 2012-08-06 05:18:56 <midnightmagic> there's someone out one step from someone I know who apparently wants to launch millions of small foil-looking compute cluster devices into orbit for solar supercomputing.
235 2012-08-06 05:18:58 <weex> new rule: thin clients only, in space
236 2012-08-06 05:19:16 <luke-jr> weex: those probably would work even worse
237 2012-08-06 05:19:24 <luke-jr> weex: just as long as no miners in space, should be fine
238 2012-08-06 05:19:25 <amiller> actually
239 2012-08-06 05:19:31 <amiller> space would be a great place to put the propagation network
240 2012-08-06 05:19:40 <midnightmagic> luke-jr: like an infrared laser or something?  only if you could convert the heat into energy really really efficiently.
241 2012-08-06 05:19:46 <amiller> you can gossip efficiently using minimal cpu power
242 2012-08-06 05:19:58 <amiller> that way when the data gets to mars it's already sorted and indexed for quick traversal
243 2012-08-06 05:20:04 <luke-jr> midnightmagic: like how heat gets from Sol to everywhere else
244 2012-08-06 05:20:15 <amiller> space sucks for mining, any mining operation is going to be consolidated on the planets
245 2012-08-06 05:20:30 <Gladamas> Guys, convection and conduction doesnt work well, so you have to BEAM the infrared rays away! derp
246 2012-08-06 05:20:30 <midnightmagic> luke-jr: But if you could convert heat efficiently into energy you could just use it as a power-assist..
247 2012-08-06 05:20:58 <amiller> if you could convert heat efficiently into energy you could unwind the entire universe and uninstall god
248 2012-08-06 05:21:07 <amiller> or at least fork before god
249 2012-08-06 05:21:07 <luke-jr> no
250 2012-08-06 05:21:20 <luke-jr> there is no such thing as before God
251 2012-08-06 05:21:34 <Gladamas> uninstall god lol. like someone ever did sudo apt-get install god
252 2012-08-06 05:21:40 <amiller> luke-jr, of course you're right, but only because we can't convert heat efficinetly
253 2012-08-06 05:22:09 <amiller> luke-jr, you might like the following thought
254 2012-08-06 05:22:16 <Gladamas> If we could create electricity out of excess heat, we could solve the world's energy crisis AND global warming.
255 2012-08-06 05:22:36 <midnightmagic> well, we can convert heat into electricity actually.
256 2012-08-06 05:22:38 <amiller> the reason why it's possibel to have bitcoin between here and mars is that we are basically keeping time by rare events such that one of them occurs on earth and news of it travels before mars finds a redundant block
257 2012-08-06 05:22:43 <midnightmagic> just not super efficiently
258 2012-08-06 05:22:46 <luke-jr> Gladamas: nah, global warming can't be solved by non-political means
259 2012-08-06 05:22:49 <amiller> in a way we're marking time by partitioning it according to rare events
260 2012-08-06 05:22:57 <amiller> the most well established thing like this in civilization is how we indicate time by bc/ad
261 2012-08-06 05:23:09 <gmaxwell> http://prl.aps.org/abstract/PRL/v108/i9/e097403 < it needs lots of these.
262 2012-08-06 05:23:13 <midnightmagic> millions of foil compute satellites could reduce solar radiation and help cool the planet.
263 2012-08-06 05:23:23 <amiller> jesus being reincarcerated is the most rare event that we can all pretty much agree on which side of it we live
264 2012-08-06 05:23:28 <amiller> not reincarcerated, something else
265 2012-08-06 05:24:09 <midnightmagic> "Above unit efficiency"?!
266 2012-08-06 05:24:37 <gmaxwell> midnightmagic: it pumps its internal heat away into light.
267 2012-08-06 05:24:37 <weex> let's have a block more often than every 2012 years please
268 2012-08-06 05:24:47 <gmaxwell> amiller: "byzantine consensus by immaculate conception"
269 2012-08-06 05:24:58 <amiller> damn straight
270 2012-08-06 05:25:15 <amiller> that's pretty much equivalent to the 'common random string' assumption in non-interactive zero knowledge proofs
271 2012-08-06 05:25:35 <amiller> the genesis block was immaculately conceived
272 2012-08-06 05:25:38 <amiller> no parents
273 2012-08-06 05:25:43 <gmaxwell> amiller: tell those people to please stop adding jibberish to the blockchain for their stupid voting systems.
274 2012-08-06 05:26:19 <amiller> i like to think that there's a block chain out there underneath satoshi's genesis block
275 2012-08-06 05:26:36 <amiller> someday a huge fork will come down and we will have to unwind all of our blocks to yield to the superior fork
276 2012-08-06 05:26:38 <amiller> it will be the bitcoin rapture
277 2012-08-06 05:26:41 <midnightmagic> gmaxwell: Yeah, but "above unity efficiency"?!
278 2012-08-06 05:27:28 <gmaxwell> midnightmagic: because it steals its own heat. It's not really above unity efficiency. It's above unity if you have an accounting problem due to only counting the electrical input.
279 2012-08-06 05:27:44 <weex> amiller: that huge fork would need to surpass "ours" cumultaive difficulty though right?
280 2012-08-06 05:28:02 <midnightmagic> gmaxwell: Where does the extra heat energy come from except the wall plug?
281 2012-08-06 05:28:31 <amiller> and behold, god did invert the prophet satoshi's truly random and pure genesis block, and the miners did succumb to the blinding and indisputable light of the fork larger than any mortal machines could ever compute
282 2012-08-06 05:28:51 <amiller> god doesn't play satoshidice
283 2012-08-06 05:29:53 <midnightmagic> booo! hiss!
284 2012-08-06 05:29:58 <amiller> midnightmagic, the point is you can fill that think up with head
285 2012-08-06 05:30:14 <amiller> and then power it with electricity and it actually radiates your heat outwards
286 2012-08-06 05:30:21 <midnightmagic> ah "A heated semiconductor light-emitting diode"
287 2012-08-06 05:30:36 <amiller> so it's dissipating your waste heat for you
288 2012-08-06 05:30:41 <midnightmagic> stupid slow internet.
289 2012-08-06 05:31:04 <amiller> you're losing energy in the process so it's not overunity production, but it is more efficient than blockbody radiation
290 2012-08-06 05:31:06 <amiller> that's pretty cool
291 2012-08-06 05:31:24 <gmaxwell> thats why I said you need it for your space miners.
292 2012-08-06 05:31:30 <amiller> do you think it's viable?
293 2012-08-06 05:31:36 <gmaxwell> For that? no.
294 2012-08-06 05:31:53 <amiller> disappointing :( why not?
295 2012-08-06 05:32:37 <gmaxwell> I mean perhaps something could be made.. but there is a lot of enegineering along the way.
296 2012-08-06 05:33:21 <weex> maybe we should add something to the Bitcoin system requirements: an atmosphere
297 2012-08-06 05:33:32 <amiller> hah
298 2012-08-06 05:44:13 <Gladamas> FTFY: -*- midnightmagic slowly downloads that research pdf from the Odyssey probe.
299 2012-08-06 05:45:43 <midnightmagic> "Black-body radiation with extra dimensions"
300 2012-08-06 05:57:49 <midnightmagic> Ah cool! "Thermal radiation
301 2012-08-06 05:57:50 <midnightmagic> 2012, Heat Transfer, Pages 189-213"
302 2012-08-06 05:58:17 <midnightmagic> "Emission coefficients of technical surfaces" table!
303 2012-08-06 07:04:37 <ageis> interesting discussion, guys
304 2012-08-06 07:04:51 <mistfpga> hopefully so...
305 2012-08-06 07:45:08 <diki> After a few hours I was finally able to create a bitcoin address generator for Android(not sure if others exist).
306 2012-08-06 07:46:09 <diki> Although at this point it is fairly limited, till I port PCRE and allow for regex.
307 2012-08-06 10:37:00 <BlueMatt> does rawtxn creation stuff let you play with non-SIGHASH_ALL txn?
308 2012-08-06 10:37:12 <gmaxwell> Yes.
309 2012-08-06 11:28:54 <sipa> TD: did a benchmark yesterday for importing 188k blocks with sigchecking enabled and disabled; 5m40s vs 1h35m21s
310 2012-08-06 11:29:13 <TD> cool
311 2012-08-06 11:29:16 <sipa> which corresponds to a sig check speed of 1735/s, in practice
312 2012-08-06 11:29:41 <sipa> on one core of my i7 2670 at 2.2GHz
313 2012-08-06 11:30:52 <sipa> there are some 9-10 million sig checks in the main chain right now
314 2012-08-06 11:33:54 <jgarzik> pynode can load a chain in maybe 1 hour, sans sigchecks
315 2012-08-06 11:34:11 <jgarzik> my database setup is awful, so that slows it down a bit
316 2012-08-06 11:35:51 <TD> sipa: that's very good indeed
317 2012-08-06 11:36:08 <TD> i feel that 0.8 should have all the perf improvements we can do merged as a matter of priority and then released
318 2012-08-06 11:36:22 <TD> so we can get transactions and blocks flowing smoothly again
319 2012-08-06 11:37:28 <sipa> if we'd have multithreaded sig verification, a lot more can be gained
320 2012-08-06 11:38:01 <sipa> but upon re-import of an existing blk0001.dat/blkindex.dat, you can walk the existing best chain with sigchecking disabled
321 2012-08-06 11:38:11 <sipa> contrary to normal -loadblock
322 2012-08-06 11:38:16 <TD> yes
323 2012-08-06 11:38:41 <TD> the leveldb pull req adds a conversion path with progress updates in the gui and disabled sig checking for the whole process
324 2012-08-06 11:38:59 <sipa> oh, didn't know that
325 2012-08-06 11:39:01 <sipa> nice
326 2012-08-06 11:39:38 <TD> pull it and try it out ;)
327 2012-08-06 11:44:07 <gmaxwell> On the subject of performance: the long chain scanning times on startup are somewhat out of control.
328 2012-08-06 11:44:17 <TD> the re-validation?
329 2012-08-06 11:44:18 <TD> yes
330 2012-08-06 11:44:53 <TD> it's only strictly necessary after upgrades, right
331 2012-08-06 11:45:13 <gmaxwell> The revalidation part is only a few seconds, at least in my test, but the reading in the index is much of the time.
332 2012-08-06 11:45:25 <sipa> without PoW check on startup, you can do really nasty things if someone trusts you enough to accept a forged blkindex.dat file
333 2012-08-06 11:45:40 <sipa> gmaxwell: there's a very simple fix for that
334 2012-08-06 11:45:49 <sipa> store multiple blocks in one index entry
335 2012-08-06 11:45:50 <gmaxwell> TD: ironically the revalidation doesn't check deeply enough to matter for upgrades.
336 2012-08-06 11:46:16 <sipa> gmaxwell: that also allows reduction of the block index by a factor 3 or so
337 2012-08-06 11:46:22 <sipa> in size
338 2012-08-06 11:46:52 <gmaxwell> The revalidation would be useful for unclean shutdowns leaving torn blocks or such, but it's not because we'll just fall over if any part of the index points past the end of the blockfile.
339 2012-08-06 11:47:13 <Diablo-D3> gmaxwell: random question time
340 2012-08-06 11:47:24 <Diablo-D3> whats the fastest malloc impl for highly threaded apps out there
341 2012-08-06 11:47:38 <gmaxwell> Diablo-D3: don't malloc if you want fast, of course.
342 2012-08-06 11:47:55 <Diablo-D3> yes, thus my question
343 2012-08-06 11:48:08 <Diablo-D3> cant allocate everything on the stack ;)
344 2012-08-06 11:48:12 <sipa> tcmalloc?
345 2012-08-06 11:48:36 <Diablo-D3> facebook claims very specific usage of jemalloc is
346 2012-08-06 11:48:37 <gmaxwell> Diablo-D3: you can just allocate a big hunk of heap to begin with though! Without knowing what you're doing I can't say more.
347 2012-08-06 11:48:41 <TD> Diablo-D3: tcmalloc is designed for that
348 2012-08-06 11:48:56 <Diablo-D3> well, an engineer at facebook
349 2012-08-06 11:49:01 <Diablo-D3> gmaxwell: yes, but you have to manage it
350 2012-08-06 11:49:06 <TD> gmaxwell: i don't see any way to avoid reading all the block headers. possibly, inserting the headers into the database and iterating over them is faster than seeking over all of blk0000?.dat
351 2012-08-06 11:49:07 <Diablo-D3> gmaxwell: thus supplying your own malloc impl
352 2012-08-06 11:49:29 <Diablo-D3> https://www.facebook.com/notes/facebook-engineering/scalable-memory-allocation-using-jemalloc/480222803919
353 2012-08-06 11:49:38 <Diablo-D3> also, why the fuck does facebook use such a useless font size
354 2012-08-06 11:49:46 <sipa> TD: reading a few megabytes of data from a db shouldn't take long
355 2012-08-06 11:49:48 <Diablo-D3> Im not a facebook user, but Im even gladder Im not
356 2012-08-06 11:49:54 <gmaxwell> TD: It's all of 15 megs of data or so so there should be some way of making it fast.
357 2012-08-06 11:49:57 <gmaxwell> :)
358 2012-08-06 11:50:04 <Diablo-D3> scroll to the graph at the bottom
359 2012-08-06 11:50:10 <Diablo-D3> tcmalloc isnt the fastest, although its close
360 2012-08-06 11:50:23 <Diablo-D3> Im just trying to figure out if theres anything else I should pay attention to
361 2012-08-06 11:50:32 <sipa> gmaxwell: it fits in less than 10 MiB, with some tricks
362 2012-08-06 11:50:44 <TD> oh, ignore me
363 2012-08-06 11:50:54 <TD> the headers are already in the database. in fact, i converted that very code to use leveldb.
364 2012-08-06 11:50:57 <TD> apparently i'm not awake yet
365 2012-08-06 11:51:14 <TD> sipa: try the leveldb branch and see if it's any faster. i don't know if it would be or not, but at least the code is different
366 2012-08-06 11:51:25 <TD> otherwise later i'll try comparing the times on my own builds
367 2012-08-06 11:56:07 <Diablo-D3> oh damnit TD
368 2012-08-06 11:56:15 <Diablo-D3> TD is an asshole.
369 2012-08-06 11:56:21 <Diablo-D3> guess who wrote tcmalloc
370 2012-08-06 11:56:22 <Diablo-D3> google
371 2012-08-06 11:56:26 <Diablo-D3> guess what TD is
372 2012-08-06 11:56:29 <Diablo-D3> a googlite.
373 2012-08-06 11:59:48 <gmaxwell> Diablo-D3: really those results suggest to me that faster malloc isn't worth worrying about... they're only showing a little better than 2x performance from what is probably a best case example. Maybe the overhead win is bigger.
374 2012-08-06 12:00:07 <Diablo-D3> gmaxwell: well, I told you about lugh, right?
375 2012-08-06 12:00:18 <Diablo-D3> its supposed to make writing highly complex massive applications in C easier
376 2012-08-06 12:00:33 <Diablo-D3> something that you can write failsafeness in
377 2012-08-06 12:00:41 <gmaxwell> (I mean, obviously worth it for them, as they've probably optimized everything else... but not generally)
378 2012-08-06 12:00:42 <Diablo-D3> without just going to erlang and ending it all
379 2012-08-06 12:01:11 <gmaxwell> Diablo-D3: link?
380 2012-08-06 12:01:16 <Diablo-D3> isnt one yet.
381 2012-08-06 12:01:30 <Diablo-D3> and the only part of that really exists is the stm impl
382 2012-08-06 12:02:13 <Diablo-D3> the rest of it is either dummy framework or stuff I havent committed because its crap
383 2012-08-06 12:03:19 <Diablo-D3> gmaxwell: see pm, but dont show other people
384 2012-08-06 12:03:34 <Diablo-D3> the license obviously doesnt prohibit you, but I want to show the world when its done and I github it
385 2012-08-06 12:05:33 <Diablo-D3> gmaxwell: its kind of shit code in places though
386 2012-08-06 12:22:18 <jgarzik> *leveldb
387 2012-08-06 12:22:37 <jgarzik> doc/table_format.txt says it is a list of sorted blocks
388 2012-08-06 12:22:41 <jgarzik> *always-sorted
389 2012-08-06 12:22:53 <jgarzik> wonder how often that file gets rewritten?
390 2012-08-06 12:26:04 <jgarzik> it sounds similar to a database engine I once pondered writing:  maintain an always-ordered flat file F1, plus a log L1 of changes.  at log-flush time (once every 24 hours or whatever), open a new log L2, freeze L1, write new flat file F2 from scratch using background thread, such that F2==F1+L1
391 2012-08-06 12:26:31 <jgarzik> the question -- will the rewrite traffic be more costly than the win gained from locality?
392 2012-08-06 12:26:37 <sipa> jgarzik: did you read the leveldb paper?
393 2012-08-06 12:26:42 <sipa> eh, bigtable
394 2012-08-06 12:27:03 <jgarzik> sipa: I read bigtable-osdi06.pdf
395 2012-08-06 12:27:08 <Diablo-D3> >bigtable
396 2012-08-06 12:27:12 <sipa> yeah, thatone
397 2012-08-06 12:27:13 <jgarzik> sipa: if there are others, would like to read them
398 2012-08-06 12:27:20 <Diablo-D3> see, people worry that google will take over the world
399 2012-08-06 12:27:23 <Diablo-D3> their fears are unfounded
400 2012-08-06 12:27:28 <Diablo-D3> google already did.
401 2012-08-06 12:27:31 <Diablo-D3> >_>
402 2012-08-06 12:27:34 <sipa> :D
403 2012-08-06 12:28:32 <jgarzik> sipa: at the time I read the paper, I thought to myself that google's data needs tended to be such that a rewrite-entire-db scheme would not be overly costly.  They have big data generation processes, then their data sits largely static after that.
404 2012-08-06 12:28:37 <jgarzik> kinda like bitcoin :)
405 2012-08-06 12:28:46 <Diablo-D3> I have to admit one thing
406 2012-08-06 12:28:56 <Diablo-D3> bigtable's optimizations are somewhat clever
407 2012-08-06 12:31:52 <sipa> 16:26:32 < jgarzik> the question -- will the rewrite traffic be more costly than the win gained from locality?    -->  i doubt many databases *constantly* saturate the write throughput
408 2012-08-06 12:32:54 <Diablo-D3> sipa: yes they do.
409 2012-08-06 12:33:17 <Diablo-D3> trust me, add mysql to any forum or blog
410 2012-08-06 12:33:20 <jgarzik> sipa: agreed, but _rewrite_ also means you might saturate your own write throughput, if you have a lot of static data to rewrite, e.g. rewriting the block chain database every night, for example
411 2012-08-06 12:36:23 <jgarzik> interesting: "Transactions are not supported. Writes (including batches) are atomic.  Consistency is up to you.  There is limited isolation support.  Durability is a configurable option.  Full blown ACID transactions require a layer on top of LevelDB"
412 2012-08-06 12:37:30 <jgarzik> ah hah, this is how they avoid rewriting many gigabytes: "LevelDB keeps a separate file for every couple of MB of data, and these are all in one directory.  Depending on the underlying file system, this might start causing trouble at some point."
413 2012-08-06 12:37:36 <jgarzik> makes sense
414 2012-08-06 12:43:57 <sipa> jgarzik: yes, all writes in one batch
415 2012-08-06 12:44:22 <sipa> and reads read from the batch being constructed
416 2012-08-06 12:54:34 <t7> is the database code abstracted now?
417 2012-08-06 13:03:36 <OneEyed> The mixer at blockchain.info generates so many fee-less 0 confirmation transactions that getting a confirmation on an outgoing transaction takes *hours*
418 2012-08-06 13:05:17 <gmaxwell> OneEyed: why would it do that when they're charging 1.5% _plus_ 2x the actual minfee?
419 2012-08-06 13:08:09 <OneEyed> gmaxwell: they're not charging anything right now, they're even offering a 0.5% chargeback because they need fresh coins
420 2012-08-06 13:09:27 <OneEyed> ed262adf56566c5454e54079277daf867bb27de2c791a38679315f74e562ba35 has been generated almost 3 hours ago, and it belongs to a chain of 2-0-0-0 confirmations
421 2012-08-06 13:09:46 <gmaxwell> OneEyed: My understanding is thats only because they have a surplus of people who have already paid 1.5% and they need fresh suckers to take the crime connected outputs they have in excess.
422 2012-08-06 13:10:41 <OneEyed> gmaxwell: yes, I agree, they do make money. I wonder why they don't include a fee.
423 2012-08-06 13:11:03 <gmaxwell> It's not bad news though
424 2012-08-06 13:11:22 <gmaxwell> I'm happy they don't simply because it means these mixer transactions aren't getting priority over people who have provided a fee.
425 2012-08-06 13:11:36 <gmaxwell> I think its fairly reasonable that these would take a while to confirm.
426 2012-08-06 13:12:23 <gmaxwell> kinda unfortunate they're making redundant transactions apparently to resize inputs.
427 2012-08-06 13:13:45 <OneEyed> gmaxwell: and the proposed change to bitcoind which takes the previous transaction cost into account will not help this chaining to go forward without transaction fees
428 2012-08-06 13:14:30 <yellowhat> feature request: it freaks me totally out if i am starting up bitcoin-qt and it is not fully loaded. it displays 0 BTC and 0 transactions. it would be much better if it said nothing.
429 2012-08-06 13:14:53 <yellowhat> shall i file an issue on github on this one?
430 2012-08-06 13:20:31 <gmaxwell> yellowhat: Sure.
431 2012-08-06 13:20:40 <gmaxwell> I didn't think it did that.
432 2012-08-06 13:21:29 <gmaxwell> (I thought both the RPC and gui were unresponsive until the wallet was loaded)
433 2012-08-06 13:21:57 <yellowhat> it is unresponsive it just renders the UI already
434 2012-08-06 13:22:59 <yellowhat> https://github.com/bitcoin/bitcoin/issues/1656
435 2012-08-06 13:23:11 <gmaxwell> Thanks!
436 2012-08-06 13:26:16 <gribble> New news from bitcoinrss: apetersson opened issue 1656 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1656>
437 2012-08-06 13:30:14 <t7> whats the advantage of a finite number of bitcoin?
438 2012-08-06 13:30:31 <BlueMatt> generates early adoption
439 2012-08-06 13:30:34 <quintopia> ^
440 2012-08-06 13:34:00 <gmaxwell> s/early //  basically it removes one whole degree of freedom from my 'is bitcoin worth messing with' formula, also removes a degree of freedom from the potential unadjustable economic parameters.
441 2012-08-06 13:36:08 <BlueMatt> s/early /pre-max-hit /
442 2012-08-06 13:56:47 <gribble> New news from bitcoinrss: apetersson opened issue 1656 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1656> || gmaxwell opened pull request 1655 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1655>
443 2012-08-06 14:35:55 <BlueMatt> TD[gone]: in the bitcoinj block gen + compare acceptance results to bitcoind tool, it requires a very minimal patch to bitcoind (different genesis block, lower mindiff/etc), do you mind if I check that patch into bitcoinj?
444 2012-08-06 14:44:02 <OneEyed> I witnessed a funny bug with armory, where one of my unconfirmed incoming transaction was included in a block that went orphaned later. Armory lost any trace of the transaction altogether. That's surprising :)
445 2012-08-06 15:20:24 <Joric> blockchain.info just added brainwallet support at my request :P i close the ticket
446 2012-08-06 15:21:39 <Joric> see https://blockchain.info/wallet import section
447 2012-08-06 15:37:06 <gmaxwell> Joric: Thats unfortunate.
448 2012-08-06 15:37:59 <Joric> not HD just sha256 of the passphrase
449 2012-08-06 15:38:08 <gmaxwell> Yes, thats what makes it unfortunate.
450 2012-08-06 15:38:46 <gmaxwell> Did you disclose that your first development related to brainwallets was performing a dictionary attack and then taking the resulting coins?
451 2012-08-06 15:40:48 <gmaxwell> Or that the developers of every other piece of client software have avoided implementing the functionality have intentionally omitted this functionality because of the extreme insecurity, the difficulty for users to assess the insecurity, and that alternative methods are significantly more secure?
452 2012-08-06 15:40:54 <Joric> no! it's unethical! (unless it's a sha256 of 'fuckyou') i only tried 5 mln of most used passwords without permutations
453 2012-08-06 15:41:27 <Joric> didn't really get anything, like literally, 0 except this 'fuckyou' passphrase :)
454 2012-08-06 15:41:49 <sipa> how many coins did it have?
455 2012-08-06 15:41:58 <Joric> 0.025
456 2012-08-06 15:43:32 <gmaxwell> Seriously, SHA256 of some user provided string is a joke.  People call websites incompetent for having password hashing which is 500x stronger than that and their hashed password's aren't published for the world or directly valuable.
457 2012-08-06 15:44:13 <gmaxwell> Most password advice, even good advice, isn't accounting for attackers which can do millions of attempts per second.
458 2012-08-06 15:44:16 <TD> somebody did a dictionary attack and found 7btc
459 2012-08-06 15:44:57 <gmaxwell> And certantly isn't for attackers that get huge precomputation and multiple-unsalted-target speedup.
460 2012-08-06 15:45:14 <Joric> TD, where?
461 2012-08-06 15:45:14 <Tykling> TD: what, by just generating new addresses until they found one that had some btc on it ?
462 2012-08-06 15:45:19 <TD> yes
463 2012-08-06 15:45:21 <TD> it was on the forums
464 2012-08-06 15:45:21 <Tykling> lol
465 2012-08-06 15:45:43 <gmaxwell> Tykling: No, by generating addresses based on 'passwords'.
466 2012-08-06 15:45:46 <sipa> not uniformly random addresses, i suppose
467 2012-08-06 15:45:57 <gmaxwell> (thus "dictionary")
468 2012-08-06 15:46:06 <BlueMatt> TD: in the bitcoinj block gen + compare acceptance results to bitcoind tool, it requires a very minimal patch to bitcoind (different genesis block, lower mindiff/etc), do you mind if I check that patch into bitcoinj?
469 2012-08-06 15:46:25 <TD> not at all
470 2012-08-06 15:46:35 <TD> you mean put a .patch file into git?
471 2012-08-06 15:46:39 <BlueMatt> yea
472 2012-08-06 15:46:39 <Tykling> gmaxwell: I dont understand, based on passwords how ?
473 2012-08-06 15:47:05 <Joric> https://bitcointalk.org/index.php?topic=97147.0 <- Results of dictionary attack on SHA256 hashed keys
474 2012-08-06 15:47:33 <TD> sure
475 2012-08-06 15:47:47 <gmaxwell> Tykling: joric and some others promote people genrating private keys based on SHA256 of some user provided passwords/phrases. Most people aren't aware of how powerful the attacks against this sort of thing are.
476 2012-08-06 15:48:51 <TD> it's less risky if you use a very intense hash, like a 5 second scrypt run
477 2012-08-06 15:48:54 <TD> but still risky
478 2012-08-06 15:49:17 <TD> especially if there's nothing beyond the user-chosen password
479 2012-08-06 15:49:18 <jgarzik> TD: is there a leveldb architecture or design paper anywhere?
480 2012-08-06 15:49:19 <Tykling> what lol, that seems pretty dumb given, well, what you said
481 2012-08-06 15:49:33 <jgarzik> TD: I've read bigtable-osdi06.pdf, but that's about it.
482 2012-08-06 15:49:41 <TD> http://leveldb.googlecode.com/svn/trunk/doc/impl.html
483 2012-08-06 15:49:54 <gmaxwell> TD: yes, something like a 5 second scrypt run should be the minimum. Unforunately, thats incompatible with goofy JS tools.
484 2012-08-06 15:49:58 <TD> yeah there are some format docs
485 2012-08-06 15:50:08 <TD> for general design thoughts the bigtable paper is the right thing
486 2012-08-06 15:50:09 <gmaxwell> because that 5 second scrypt run is either uselessly weak, or it takes an hour.
487 2012-08-06 15:50:18 <TD> leveldb is just a "core of tabletserver in a library" more or less
488 2012-08-06 15:50:22 <Joric> i proposed a scary warning like one on bitaddress.org but puik didn't really add anything about password strength
489 2012-08-06 15:50:52 <Joric> well, it's 15 chars min
490 2012-08-06 15:50:56 <TD> Joric: fail.
491 2012-08-06 15:51:00 <gmaxwell> 15 chars min doesn't make it secure.
492 2012-08-06 15:51:05 <TD> it helps
493 2012-08-06 15:51:18 <TD> but not if the 15 char password is a word, or something
494 2012-08-06 15:51:25 <TD> brute forcing all possibilities with video cards starts to break at about 8-9 iirc
495 2012-08-06 15:51:53 <gmaxwell> It doesn't really help much because users are quite likely to repeat a short password twice to meet the criteria.
496 2012-08-06 15:54:57 <BlueMatt> heh, yay! bitcoin-qt unit tests are faling on master and no one noticed, guess jenkins might just have been good for something
497 2012-08-06 15:56:53 <TD> jgarzik: ok, it's not exactly tabletserver in a box. tablet servers have no concept of levels
498 2012-08-06 15:57:21 <TD> their tablet structure is a little simpler
499 2012-08-06 15:58:25 <jgarzik> TD: one of my long term projects/desires is for an embedded table API, of which key/value may be a common case subset.  multi-column, index any columns you like with hash or btree, etc.
500 2012-08-06 15:58:43 <jgarzik> _not_ SQL, which imposes data type and other unwanted constraints
501 2012-08-06 15:58:43 <TD> ok. sounds like sqlite
502 2012-08-06 15:59:12 <TD> ok
503 2012-08-06 15:59:16 <jgarzik> TD: I might be able to hack leveldb into something like what I want, which is neat
504 2012-08-06 15:59:20 <TD> bigtable supports indexes and other things in later versions
505 2012-08-06 15:59:33 <TD> so i guess it's possible. it supports write batches that are atomically committed
506 2012-08-06 15:59:35 <jgarzik> TD: yeah... basically a bit like an embedded bigtable.
507 2012-08-06 15:59:37 <TD> so i guess you'd do it that way
508 2012-08-06 16:00:53 <gribble> New news from bitcoinrss: TheBlueMatt opened issue 1657 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1657>
509 2012-08-06 16:01:16 <Joric> even 'I l0ve Bitcoin soo0 very much!!!1' is very vulnerable i guess, not really sure though
510 2012-08-06 16:03:39 <Joric> maybe not, if 'correct horse battery staple' considered secure
511 2012-08-06 16:05:19 <BlueMatt> 'correct horse battery staple' is considered secure for a remote website assuming brute forcing over http, if you get the db, correct horse battery staple really isnt all that secure
512 2012-08-06 16:20:57 <Cryo> ooh invoked xkcd
513 2012-08-06 16:23:27 <gmaxwell> Joric: it's "considered secure" assuming an attacker bounded at something like 1000 requests per second. (and assuming an RNG picked the words, not the user)
514 2012-08-06 16:23:51 <gmaxwell> For an offline attack that can run at a billion attempts per second you'd find one from that space in a couple of hours.
515 2012-08-06 16:31:55 <gmaxwell> I'm fixing a bunch of stuff in listaddressgroupings.
516 2012-08-06 16:31:55 <Joric> with a trilion attempts (new BFL rig?) it'd be 7 seconds ;)
517 2012-08-06 16:32:22 <gmaxwell> It currently ignores unconfirmed transactions. I'm thinking it shouldn't do this. Thoughts?
518 2012-08-06 17:10:48 <luke-jr> gmaxwell: I agree
519 2012-08-06 17:20:57 <sipa> gmaxwell: http://bitcoin.sipa.be/shatest/test.html
520 2012-08-06 17:21:10 <sipa> that's the algorithm we've been discussion with etotheipi
521 2012-08-06 17:21:40 <sipa> but lower complexity than proposed (10,11,12,13,... bits instead of 16,18,20,...)
522 2012-08-06 17:41:35 <roconnor> sipa: every passphrase I've tried there is invalid
523 2012-08-06 17:46:26 <sipa> roconnor: that's intentional
524 2012-08-06 17:46:35 <sipa> they are not to be generated by humans
525 2012-08-06 17:46:43 <sipa> intended
526 2012-08-06 17:50:42 <roconnor> sipa: passphrases are not intended to be generated by humans?
527 2012-08-06 17:51:10 <roconnor> ah
528 2012-08-06 17:51:12 <roconnor> I see
529 2012-08-06 17:51:15 <roconnor> there is a generate button
530 2012-08-06 17:52:00 <jgarzik> w00t!  pynode full validates mainnet and testnet3 chains.
531 2012-08-06 17:52:05 <jgarzik> *fully
532 2012-08-06 17:52:10 <roconnor> sipa: BTW, diceware recommends not having spaces in a passphrase because the space bar usually makes a disctinctive click on keyboards.
533 2012-08-06 17:52:29 <roconnor> sipa: the loss of entropy due to losing spaces is persumably very small.
534 2012-08-06 17:52:34 <ersi> jgarzik: Yay! Good job!
535 2012-08-06 17:54:35 <sipa> roconnor: it's intended to have the iterations compensate the loss of entropy entirely
536 2012-08-06 17:54:58 <sipa> so at 10 bit strength, the "checksum" is 5 bits, and one passphrase in 32 is valid
537 2012-08-06 17:55:15 <sipa> but there will also be 32 iterations before finding out whether it's correct
538 2012-08-06 17:55:29 <roconnor> sipa: okay; but the larger point is that passphrases shouldn't have spaces.
539 2012-08-06 17:56:02 <roconnor> or at least the spaces shouldn't count when deriving the key material
540 2012-08-06 17:56:22 <sipa> roconnor: i suppose i'll make it space and case insensitive
541 2012-08-06 17:56:53 <roconnor> :)
542 2012-08-06 18:12:46 <sipa> roconnor: there is some math behind it though, if you're interested (very dense, i fear): https://gist.github.com/2731997
543 2012-08-06 18:15:26 <BlueMatt> jgarzik: congrats, well done
544 2012-08-06 18:16:14 <sipa> jgarzik: nice one, indeed!
545 2012-08-06 18:21:44 <luke-jr> someone want to pull gmp_bip finally? -.-
546 2012-08-06 19:29:00 <OneEyed> This is the address corresponding to private key 1 (in hexa): http://blockchain.info/address/1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm
547 2012-08-06 19:29:11 <OneEyed> I'm surprised that noone played with it before January 2012 :)
548 2012-08-06 19:29:33 <sipa> that's not hexadecimal
549 2012-08-06 19:29:40 <OneEyed> 0000000&0001
550 2012-08-06 19:29:53 <sipa> oooh; apologies, i misunderstood
551 2012-08-06 19:30:12 <OneEyed> And to put 0.0666 BTC, I guess this was not someone who stumbled upon it by chance :)
552 2012-08-06 19:30:34 <BlueMatt> OneEyed: that doesnt indicate people playing with it, it indicates coding issues
553 2012-08-06 19:30:39 <BlueMatt> (at least one of them my fault)
554 2012-08-06 19:30:45 <BlueMatt> (though not my coins)
555 2012-08-06 19:31:06 <BlueMatt> oh, wait, no that was pubkeyhash 1
556 2012-08-06 19:31:11 <BlueMatt> or pubkey 1
557 2012-08-06 19:31:19 <BlueMatt> anyway, I bet those are coding errors
558 2012-08-06 19:31:25 <OneEyed> BlueMatt: and it was fixed in 9 blocks (time between deposit and withdrawal)?
559 2012-08-06 19:31:54 <BlueMatt> having a coding issue which adds 1 to your wallet doesnt mean you cant spend it
560 2012-08-06 19:32:14 <OneEyed> Oh, sure
561 2012-08-06 19:32:23 <OneEyed> But I know I was going to play with this address if it had been empty :)
562 2012-08-06 19:32:32 <OneEyed> So I guess someone must have done so too.
563 2012-08-06 19:39:01 <Joric> "<gmaxwell> For an offline attack that can run at a billion attempts per second you'd find one from that space in a couple of hours." how many ecdsa keys per second you may get?
564 2012-08-06 19:40:16 <Joric> i just tried got less than 1000 keys per second on my celeron, and the only operation is EC_POINT_mul from openssl
565 2012-08-06 19:41:32 <BlueMatt> a gpu could run pretty significantly faster
566 2012-08-06 19:41:50 <BlueMatt> or a custom fgpa
567 2012-08-06 19:42:01 <BlueMatt> s/custom fgpa/fpga/
568 2012-08-06 19:42:02 <luke-jr> or a standard fpga <.<
569 2012-08-06 19:42:24 <BlueMatt> wrote custom asic, then ^H'd to fpga...
570 2012-08-06 19:42:40 <sipa> iirc, vanitygen does several million per second
571 2012-08-06 19:42:50 <sipa> but it only does an EC_POINT_add
572 2012-08-06 19:43:01 <sipa> multiplying is several hundred adds
573 2012-08-06 19:43:09 <Joric> yeah, the point is it's really not that easy
574 2012-08-06 19:43:34 <sipa> easy doesn't really matter; only one person needs to implement it
575 2012-08-06 19:43:36 <Joric> thousands, not billions/trillions
576 2012-08-06 19:43:50 <BlueMatt> and a thousand separate computers in a botnet?
577 2012-08-06 19:44:05 <BlueMatt> or a thousand computers of a thousand individuals doing their own tests?
578 2012-08-06 19:44:11 <sipa> still, using human-generated passphrases as seed for keys is looking for trouble
579 2012-08-06 19:44:41 <jgarzik> sipa: that compromise is and always will be present and inevitable
580 2012-08-06 19:44:50 <BlueMatt> "what, 'Th1$I$$3cure' isnt a secure passphrase?"
581 2012-08-06 19:44:53 <jgarzik> sipa: you're working with humans, and it's fundamentally a human UI
582 2012-08-06 19:45:12 <sipa> and?
583 2012-08-06 19:45:27 <jgarzik> if blah is computer-generated passphrase, then the human has to put in extra work to store it
584 2012-08-06 19:46:12 <BlueMatt> there are cases where its a fair compromise, and there are cases where it doesnt make that much sense
585 2012-08-06 19:46:23 <sipa> sure some people know enough about information theory to come up with secure seeds
586 2012-08-06 19:47:07 <sipa> but if you allow human-generated passphrases, you're exposing them to attacks
587 2012-08-06 19:47:25 <sipa> you can't prevent people from being stupid, but you can make it hard to do so
588 2012-08-06 19:48:09 <gmaxwell> It's all a question of setting the right paths of least resistance.
589 2012-08-06 19:48:38 <gmaxwell> Joric: With GPU code here I get 14 million per second per 5830.
590 2012-08-06 19:49:02 <sipa> gmaxwell: if that's vanitygen, it's only doing an EC addition + hashing per key
591 2012-08-06 19:49:10 <Joric> gmaxwell, 14 million bignum multiplications a second? really?
592 2012-08-06 19:49:29 <gmaxwell> Ah, as sipa points out it only periodically does the increments.
593 2012-08-06 19:49:31 <sipa> and EC multiplications are a few hundred times slower
594 2012-08-06 19:49:54 <Joric> gmaxwell, yeah, i just tried that in the wild, got 1000 keys/s on CPU
595 2012-08-06 19:50:12 <gmaxwell> But it's still irrelevant because an FPGA implementation can do the EC multiply with less gatecount than sha256 assuming routing doesn't hate it for so many xors.
596 2012-08-06 19:50:52 <sipa> still, i expect a GPU to easily do 20k keys/s
597 2012-08-06 19:51:35 <Joric> i have a really lousy cpu here though, celeron 550, 1 core
598 2012-08-06 19:52:29 <meelu> anyone know how to setup bitcoind on ubuntu, i couldn't find no make file :S
599 2012-08-06 19:52:32 <gmaxwell> Joric: right, and an attacker can potentially buy resources cheaply to build nice rainbow tables for this function... because the databases are reusable.
600 2012-08-06 19:53:36 <sipa> meelu: cd src; make -f makefile.unix
601 2012-08-06 19:54:40 <meelu> sipa, thank you so much
602 2012-08-06 19:56:27 <meelu> sipa
603 2012-08-06 19:56:29 <meelu> g++: Internal error: Killed (program cc1plus)
604 2012-08-06 19:56:38 <sipa> how much RAM do you have?
605 2012-08-06 19:56:45 <meelu> 256 :D
606 2012-08-06 19:57:07 <meelu> mb
607 2012-08-06 19:57:09 <gmaxwell> Add swap then.
608 2012-08-06 19:57:17 <gmaxwell> And hopefully you're very patient.
609 2012-08-06 19:57:43 <meelu> can't add more ram
610 2012-08-06 19:58:09 <gmaxwell> If you can't add ram and you can't add swap, then you can't compile bitcoin.
611 2012-08-06 19:58:11 <Joric> that's so cute, just like my celeron
612 2012-08-06 19:58:44 <meelu> its a little cloud vps im going to order more ram just developing at the moment
613 2012-08-06 19:58:52 <gmaxwell> meelu: go compile it on another computer. Also, with that small an amount of ram you'll want to limit it to one or two connections.
614 2012-08-06 19:59:57 <meelu> sudo apt-get install bitcoind
615 2012-08-06 19:59:59 <meelu> no problems
616 2012-08-06 20:00:21 <meelu> i hope
617 2012-08-06 20:01:06 <BlueMatt> meelu: the version of bitcoind in ubuntu and debian is very, very old and vulnerable to several security issues
618 2012-08-06 20:01:20 <meelu> how do i check version?
619 2012-08-06 20:01:36 <BlueMatt> meelu: if you're on ubuntu: apt-add-repository ppa:bitcoin/bitcoin; apt-get update; apt-get install bitcoind
620 2012-08-06 20:01:40 <meelu> Setting up bitcoind (0.6.3-natty2) .
621 2012-08-06 20:01:43 <meelu> :D not so old
622 2012-08-06 20:01:56 <BlueMatt> oh, thats the ppa version already
623 2012-08-06 20:02:33 <meelu> last time i came to this chan about a week ago everyone told me to sod off as its for bitcoin dev, glad i got some help thanks
624 2012-08-06 20:02:43 <meelu> i thought it was for bitcoin related dev too
625 2012-08-06 20:02:47 <BlueMatt> thats rare...
626 2012-08-06 20:02:56 <meelu> maybe i dreamt it
627 2012-08-06 20:03:11 <BlueMatt> usually you just get ignored if there are there are other discussions going on
628 2012-08-06 20:03:19 <BlueMatt> or, if not, then you get ignored because no one's here
629 2012-08-06 20:03:43 <meelu> thanks anyway because i'm working on a big project
630 2012-08-06 20:03:58 <meelu> lots of bitcoin transactions
631 2012-08-06 20:04:46 <BlueMatt> please appropriately use sendmulti
632 2012-08-06 20:04:53 <BlueMatt> dont be another satoshidice
633 2012-08-06 20:05:16 <meelu> im going to chek that out
634 2012-08-06 20:05:48 <meelu> oh
635 2012-08-06 20:05:51 <meelu> ok will do
636 2012-08-06 20:06:03 <BlueMatt> thanks
637 2012-08-06 20:06:13 <meelu> whats the disadvantage? optimisation?
638 2012-08-06 20:06:33 <meelu> i mean i should use it for optimisation right
639 2012-08-06 20:06:35 <meelu> sorry
640 2012-08-06 20:06:38 <sipa> fewer but larger transactions
641 2012-08-06 20:06:42 <sipa> and you have to use it
642 2012-08-06 20:06:54 <BlueMatt> it takes a bit more effort to code for sendmulti, but it puts less load on your personal bitcoind, as well as the entire network
643 2012-08-06 20:07:29 <meelu> i can't find much info on sendmulti even 9on google
644 2012-08-06 20:07:30 <luke-jr> sendmany*
645 2012-08-06 20:07:42 <BlueMatt> eh, yea, sendmany
646 2012-08-06 20:07:45 <meelu> oh
647 2012-08-06 20:08:28 <luke-jr> meelu: and if you don't use sendmany, the network will react as if you are attacking ;)
648 2012-08-06 20:08:49 <meelu> is this for recieving payments
649 2012-08-06 20:08:53 <BlueMatt> sending
650 2012-08-06 20:08:55 <luke-jr> for sending
651 2012-08-06 20:09:11 <meelu> alright, i'l mostly be recieving at the moment till i launch affiliate program
652 2012-08-06 20:09:20 <meelu> but thanks
653 2012-08-06 20:09:44 <luke-jr> I like that. "I only receive money, never send it"
654 2012-08-06 20:09:46 <luke-jr> :p
655 2012-08-06 20:10:01 <meelu> :D
656 2012-08-06 20:12:12 <meelu> is the rpc secure against brute force attacks?
657 2012-08-06 20:12:26 <sipa> you shouldn't expose your RPC interface to the internet
658 2012-08-06 20:13:10 <meelu> il use -rpcallowip= for now
659 2012-08-06 20:23:32 <luke-jr> meelu: in short, no
660 2012-08-06 20:24:28 <meelu> no?
661 2012-08-06 20:30:00 <midnightmagic> meelu: I guess it depends on your definition of "secure". For most peoples' definitions, the rpc port bitcoind accepts commands on is not "secure" against brute force attacks.
662 2012-08-06 20:30:17 <BlueMatt> I would hate to call it secure against anything, really
663 2012-08-06 20:30:46 <BlueMatt> its not gonna fall over against nothing, but dont expose it to the internet
664 2012-08-06 20:31:09 <midnightmagic> well it's hard to make blanket statements, so i try to avoid doing that when they've asked a specific question..
665 2012-08-06 20:31:23 <midnightmagic> ^authoritatively make^
666 2012-08-06 20:32:16 <BlueMatt> that wasnt an authoritative statement, I was a statement that Id prefer to not make any positive statements supporting the rpc system's security at all
667 2012-08-06 20:32:20 <BlueMatt> ;)
668 2012-08-06 20:32:54 <midnightmagic> no, yea, that's what I mean. We can fairly authoritatively state that it's not secure against brute force "attacks" but it's hard to do the same as a generic statement of security :)
669 2012-08-06 20:36:06 <meelu> isn't -rpcallowip= safe enough
670 2012-08-06 20:36:32 <BlueMatt> better question: why cant you just bind to a local address?
671 2012-08-06 20:37:30 <luke-jr> BlueMatt: because he wants to access it from another machine obviously :P
672 2012-08-06 20:37:50 <luke-jr> meelu: be sure to at least enable SSL, and verify the cert on the client end
673 2012-08-06 20:37:51 <BlueMatt> luke-jr: but that doesnt preclude listening on a local-net address
674 2012-08-06 20:38:05 <luke-jr> meelu: otherwise, the password can be sniffed by anyone*
675 2012-08-06 20:38:16 <luke-jr> BlueMatt: there are no local-net addresses anymore ;)
676 2012-08-06 20:38:37 <BlueMatt> ?
677 2012-08-06 20:38:54 <luke-jr> BlueMatt: since IPv6, basically all addresses are globally routable
678 2012-08-06 20:38:59 <luke-jr> IP-based authentication is stupid anyway
679 2012-08-06 20:39:02 <BlueMatt> uhh...no
680 2012-08-06 20:39:04 <BlueMatt> fe80?
681 2012-08-06 20:39:21 <luke-jr> BlueMatt: link-local doesn't traverse routers, and I don't think bitcoind supports it
682 2012-08-06 20:39:27 <luke-jr> since you need to specify an interface explicitly
683 2012-08-06 20:39:36 <BlueMatt> yes, it is, but my point is you shouldnt listen on anything that will pass a router
684 2012-08-06 20:39:47 <BlueMatt> oh, we cant listen per-address?
685 2012-08-06 20:39:58 <luke-jr> BlueMatt: per-address isn't enough
686 2012-08-06 20:40:06 <luke-jr> you need to explicitly bind by the interface
687 2012-08-06 20:40:10 <luke-jr> eg, eth0 or whatever
688 2012-08-06 20:40:20 <luke-jr> since the same address is valid on any interface
689 2012-08-06 20:40:30 <BlueMatt> yes, and we cant do that?
690 2012-08-06 20:40:41 <luke-jr> not afaik
691 2012-08-06 20:40:50 <BlueMatt> darn...so use ipv4
692 2012-08-06 20:40:51 <luke-jr> I'm not sure there's even a platform-independent way to do it yet?
693 2012-08-06 20:41:31 <Dagger2> there is always the option of using a firewall
694 2012-08-06 20:42:53 <luke-jr> true
695 2012-08-06 20:43:16 <luke-jr> but anyhow, I'd guess meelu wants something across the WAN
696 2012-08-06 20:43:22 <luke-jr> so SSL with client cert check should work
697 2012-08-06 20:43:55 <meelu> i was actually just going to connect to localhost for now and do stuff later
698 2012-08-06 20:43:59 <luke-jr> XD
699 2012-08-06 20:44:06 <BlueMatt> heh, clever, libpng uses DO_NOT_READ_ME, seems like that should get a lot more reads
700 2012-08-06 20:44:44 <Dagger2> there's always IPsec... :)
701 2012-08-06 20:44:59 <Dagger2> which I discovered is actually fairly easy to use on Linux
702 2012-08-06 20:45:20 <sipa> BlueMatt: hmm?
703 2012-08-06 20:45:36 <BlueMatt> sipa: s/README.txt/DO_NOT_README.txt/
704 2012-08-06 20:45:45 <sipa> ah!
705 2012-08-06 20:47:28 <meelu> HASH(0x2a27d38) When i output getinfo is this normal?
706 2012-08-06 20:48:44 <sipa> which language is that?
707 2012-08-06 20:49:04 <luke-jr> Perl
708 2012-08-06 20:49:09 <luke-jr> meelu: use Data::Dumper
709 2012-08-06 20:49:17 <meelu> alright thanks
710 2012-08-06 20:49:53 <sipa> indeed, you can't print a hash directly in perl
711 2012-08-06 21:04:48 <midnightmagic> Data::Dumper, how do I love thee, let me count the ways..
712 2012-08-06 21:06:29 <jgarzik> sadly, I think python has won me over from Perl
713 2012-08-06 21:06:51 <jgarzik> for a decade, anything not in C was written in Perl, here