1 2011-11-28 00:24:26 <Diablo-D3> https://www.google.com/trends?q=bitcoin&ctab=0&geo=all&date=ytd&sort=0
  2 2011-11-28 00:24:31 <Diablo-D3> http://bitcoincharts.com/charts/mtgoxUSD#rg360zvztgSzm1g10zm2g25
  3 2011-11-28 00:24:35 <Diablo-D3> huh.
  4 2011-11-28 00:25:20 <upb> yeah..
  5 2011-11-28 00:25:40 <gmaxwell> but whats the cause and whats the effect.
  6 2011-11-28 00:25:54 <gmaxwell> Bitcoins being $30 sure makes them more interesting to search for!
  7 2011-11-28 00:26:21 <the_batman> we need a bitcoin pr team
  8 2011-11-28 00:26:25 <the_batman> to get that price back up to $30
  9 2011-11-28 00:26:39 <Diablo-D3> gmaxwell: ooh didnt think of that
 10 2011-11-28 00:26:54 <gmaxwell> Oh noes! they be stealing my thoughts!
 11 2011-11-28 00:27:00 <gmaxwell> the_batman: bubbles are bad.
 12 2011-11-28 00:27:19 <gmaxwell> We need a PR team to get bitcoin adoption up. The value will follow (hopefully slowly)
 13 2011-11-28 00:27:31 <upb> someone needs to find that gay guy :)
 14 2011-11-28 00:27:33 <upb> again
 15 2011-11-28 00:27:34 <the_batman> adoption by whom?
 16 2011-11-28 00:27:42 <upb> bruce or whatever he was
 17 2011-11-28 00:27:47 <the_batman> bitcoin got hella pr and then was adpoted by finance nerds
 18 2011-11-28 00:27:53 <the_batman> and the price went up to $30
 19 2011-11-28 00:28:00 <the_batman> that's what it got from mainstream pr*
 20 2011-11-28 00:28:03 <gmaxwell> Preferably people who are not the finance nerds.
 21 2011-11-28 00:28:07 <the_batman> no other adoption, that is to say
 22 2011-11-28 00:28:16 <the_batman> lol
 23 2011-11-28 00:29:04 <the_batman> I dunno. I like the finance nerd crowd.
 24 2011-11-28 00:29:22 <the_batman> they're pretty intelligent and down-to-earth \n2242745
 25 2011-11-28 00:29:39 <gmaxwell> sure but they don't add a lot to the ecosystem that attracts anyone else.
 26 2011-11-28 00:30:03 <gmaxwell> We need them too, but they're the easiest to win.. they'll go wherever there is money to be made.
 27 2011-11-28 00:30:11 <the_batman> dont they give a palpable degree of price stability?
 28 2011-11-28 00:30:34 <the_batman> yah we need a real use for the bitcoin
 29 2011-11-28 00:30:38 <the_batman> indeed, this old discussion
 30 2011-11-28 00:30:49 <gmaxwell> They do except when they don't.
 31 2011-11-28 00:30:52 <the_batman> with the only conclusion "hold bitcoins and wait [for magic]"
 32 2011-11-28 00:31:02 <the_batman> lol
 33 2011-11-28 00:31:34 <gmaxwell> There are people using bitcoin every day, using it to tranfer value between countries without exchange inefficiency, etc.. we just need more of it.
 34 2011-11-28 00:31:43 <the_batman> ??? really? who
 35 2011-11-28 00:31:54 <Diablo-D3> [08:26:54] <gmaxwell> Oh noes! they be stealing my thoughts!
 36 2011-11-28 00:31:55 <Diablo-D3> hn needs them!
 37 2011-11-28 00:32:35 <gmaxwell> the_batman: e.g. apparently it's attractive to the aussies for this.
 38 2011-11-28 00:33:05 <gmaxwell> Though china should be even better due to the government dorked exchange rates... but I've not heard of big adoption in china yet.
 39 2011-11-28 00:33:08 <the_batman> very interesting
 40 2011-11-28 00:33:30 <the_batman> that's the first I've ever heard of solid uses :o
 41 2011-11-28 00:33:44 <the_batman> why do the aussies prefer it? what's making their exchange rates bad?
 42 2011-11-28 00:35:03 <gmaxwell> No clue, I just noticed people on the forum saying this. They don't have to be particularly bad... especially if you get a whole circle of bitcoin using people on it so that most of the value can stay in the form of bitcoin.
 43 2011-11-28 00:35:32 <gmaxwell> There is certantly a critical mass factor involved in that kind of tradeoff, but it's not unique to bitcoin.
 44 2011-11-28 00:36:41 <coderrr> http://www.avc.com/a_vc/2011/11/bitcoin.html
 45 2011-11-28 00:36:50 <gmaxwell> See e.g. how hawala is used  bitcoin serves some of the same legitimate needs: http://www.treasury.gov/resource-center/terrorist-illicit-finance/Documents/FinCEN-Hawala-rpt.pdf
 46 2011-11-28 00:39:15 <Diablo-D3> coderrr: see the hn thread
 47 2011-11-28 00:39:25 <Diablo-D3> http://news.ycombinator.com/item?id=3282793
 48 2011-11-28 00:39:28 <Diablo-D3> epic stupidity abound
 49 2011-11-28 00:40:09 <coderrr> i think thast the first semi-pro bitcoin post on HN that actually got a lot of votes
 50 2011-11-28 00:40:40 <Diablo-D3> nope, Ive seen higher
 51 2011-11-28 00:42:10 <coderrr> but werent most of those anti bitcoin posts?
 52 2011-11-28 00:42:24 <gmaxwell> "The only thing in the bitcoin protocol which facilitates this is an alert"  thats not true, the fact that all the relevant messages have version numbers is also prepration for upgrades.
 53 2011-11-28 00:42:57 <gmaxwell> The other thing is that you can change, e.g. the commonly used transaction types without upgrading all the clients.
 54 2011-11-28 00:43:27 <Diablo-D3> coderrr: theres been a few positive ones
 55 2011-11-28 00:43:38 <Diablo-D3> the problem is you have fucking idiots who grandstand on HN to bitch about bitcoin
 56 2011-11-28 00:43:40 <coderrr> ah k, probly jsut forgot
 57 2011-11-28 00:43:42 <Diablo-D3> which is rather inappropriate
 58 2011-11-28 00:43:45 <coderrr> so much hate everywhere
 59 2011-11-28 00:43:46 <gmaxwell> E.g. if we were to find some ECDSA weakness today we could roll out a new signature type using OP_EVAL style compatiblity (using a NOP).
 60 2011-11-28 00:43:47 <Diablo-D3> I mean as comments, not posts
 61 2011-11-28 00:43:52 <Diablo-D3> but dont worry!
 62 2011-11-28 00:43:56 <Diablo-D3> guess what!
 63 2011-11-28 00:44:03 <Diablo-D3> I have enough hn karma to downvote comments!
 64 2011-11-28 00:44:16 <coderrr> lol
 65 2011-11-28 00:44:47 <coderrr> when i finally got enough to downvote they increased the downvote requirement :/
 66 2011-11-28 00:44:48 <Diablo-D3> I have a screenshot of my karma of 666 <3
 67 2011-11-28 00:44:57 <Diablo-D3> it doesnt "increase"
 68 2011-11-28 00:45:01 <Diablo-D3> theres a math formula for it
 69 2011-11-28 00:45:08 <Diablo-D3> I just dont know what it is
 70 2011-11-28 00:45:12 <Diablo-D3> its near 500
 71 2011-11-28 00:45:15 <Diablo-D3> atm I mean
 72 2011-11-28 00:45:21 <coderrr> ah, ic
 73 2011-11-28 00:45:30 <coderrr> i thought that was a manual change
 74 2011-11-28 00:47:12 <Diablo-D3> nope, pretty sure its in the code
 75 2011-11-28 00:47:16 <Diablo-D3> also, did hn just go down?
 76 2011-11-28 00:49:33 <gmaxwell> damnit!
 77 2011-11-28 00:50:20 <gmaxwell> Anyone want to proofread my post (responding to the comment that bitcoin can't be upgraded)
 78 2011-11-28 00:50:23 <gmaxwell> http://pastebin.com/65auAt32
 79 2011-11-28 00:50:30 <gmaxwell> oops stupid spellcheck
 80 2011-11-28 00:50:35 <gmaxwell> biodegradability wtf. hah
 81 2011-11-28 00:51:00 <coderrr> lol
 82 2011-11-28 00:52:00 <vrs> i thought it was a nice metaphor
 83 2011-11-28 00:52:14 <vrs> along with code rot
 84 2011-11-28 00:57:51 <gmaxwell> https://news.ycombinator.com/item?id=3284091  < feel free to give me all your upvotes.
 85 2011-11-28 01:05:01 <Diablo-D3> [08:52:00] <vrs> i thought it was a nice metaphor
 86 2011-11-28 01:05:11 <Diablo-D3> I need to write a post involving that metaphor now
 87 2011-11-28 01:07:05 <vrs> biodegradable protocols?
 88 2011-11-28 03:10:30 <the_batman> biodegradable protocols? we gonna start a protocol compost box?
 89 2011-11-28 03:11:43 <Diablo-D3> see what I mean? its perfect
 90 2011-11-28 07:18:17 <Lolcust_Backup> !seen orange-hand
 91 2011-11-28 07:18:18 <gribble> orange-hand was last seen in #bitcoin-dev 4 weeks, 4 days, 3 hours, 4 minutes, and 38 seconds ago: <orange-hand> good talking to you
 92 2011-11-28 07:18:18 <spaola> orange-hand (~orange-ha@gateway/tor-sasl/orange-hand) was last seen quitting from #namecoin 3 days, 17 hours, 48 minutes ago stating (Ping timeout: 248 seconds).
 93 2011-11-28 09:04:08 <Cairo> interesting
 94 2011-11-28 10:19:34 <CIA-100> bitcoinj: hearn@google.com * r273 /wiki/GettingStarted.wiki: Update for changes in 0.3
 95 2011-11-28 13:28:21 <sipa> ;;later tell justmoon I'm afraid the Bloom filter idea will not help preventing db writes; consider: txout gets spent, bits are marked, nothing is written to disk. Now a double spend arrives; all bits are said, meaning "probably spent" - there is however no way to verify this
 96 2011-11-28 13:28:22 <gribble> The operation succeeded.
 97 2011-11-28 13:30:11 <gribble> The operation succeeded.
 98 2011-11-28 13:30:11 <sipa> ;;later tell justmoon so, there is no way to guarantee in advance whether a future filter lookup will provide certainty
 99 2011-11-28 13:48:47 <TD> sipa: what was the idea?
100 2011-11-28 13:49:28 <sipa> TD: using a Bloom filter of spent txouts to quickly verify whether all txouts in a transaction were still available
101 2011-11-28 13:50:20 <sipa> and additionally, only store the cases where the Bloom filter fails (false positives) to disk
102 2011-11-28 13:50:25 <sipa> but that last part is not possiblre
103 2011-11-28 13:50:39 <TD> i think it'd be easier to just host the DB in ram or on an SSD
104 2011-11-28 13:50:54 <TD> is anyone actually going to bottleneck on db writes anytime soon?
105 2011-11-28 13:51:19 <phantomcircuit> bitcoin is currently calling fsync pretty often
106 2011-11-28 13:51:30 <sipa> I believe the DB reads/writes are the bottleneck when downloading the blockchain in the satoshi client, right now.
107 2011-11-28 13:51:49 <TD> oh, right. well, but lightweight mode is the solution to that :-)
108 2011-11-28 13:51:53 <phantomcircuit> it's not so much a bottleneck as it is added latency
109 2011-11-28 13:52:06 <TD> somebody could try swapping out berkleydb for leveldb and see if it helps much
110 2011-11-28 13:52:07 <phantomcircuit> the #1 issue in the current client is the latency of each step
111 2011-11-28 13:53:33 <gmaxwell> Lightweight isn't the only thing needed there.
112 2011-11-28 13:53:53 <gmaxwell> It's not okay for full nodes to suck just because there are lightweight nodes too.
113 2011-11-28 13:54:00 <sipa> gmaxwell: exactly
114 2011-11-28 13:55:11 <gmaxwell> But considering that there are checkpoints already.. a lot of things are possible. e.g. using a different format for blockchain storage below the highest checkpoint.. (e.g. once that multiple people could independantly generate and sign, and which could be distributed in a secure manner without demanding the node validate all of it, perhaps)
115 2011-11-28 13:55:44 <TD> a full db could be included with the downloaded client
116 2011-11-28 13:55:57 <TD> this was brought up several times before. i don't recall the rationale for not doing it.
117 2011-11-28 13:56:34 <makomk> TD: requires excessive trust in the developers, I think.
118 2011-11-28 13:57:15 <TD> you already trust the developers implicitly
119 2011-11-28 13:57:28 <TD> if you are downloading a binary instead of compiling from source, you don't know what the code might do. it could do anything.
120 2011-11-28 13:57:38 <TD> if you compile from source, the db would not be included.
121 2011-11-28 13:58:17 <PK> something's odd. My BTC client has 47 connections into the network but the newest block is 1 hour old?
122 2011-11-28 13:58:36 <phantomcircuit> https://privatepaste.com/download/691d4b5040
123 2011-11-28 13:58:43 <phantomcircuit> just to give people an idea of what im talking about
124 2011-11-28 13:59:29 <phantomcircuit> fdatasync takes on average 1.8 ms
125 2011-11-28 13:59:45 <phantomcircuit> add that into the rtt time for the networking stuff
126 2011-11-28 13:59:51 <phantomcircuit> and you have a fairly slow process
127 2011-11-28 13:59:59 <phantomcircuit> it's the latency that's killing performance
128 2011-11-28 14:00:01 <phantomcircuit> not throughput
129 2011-11-28 14:00:46 <TD> this only matters when you're downloading the chain for the first time though, right.
130 2011-11-28 14:01:01 <phantomcircuit> no
131 2011-11-28 14:01:05 <phantomcircuit> this keeps mattering
132 2011-11-28 14:01:13 <phantomcircuit> the latency continues to be an issue
133 2011-11-28 14:13:47 <sipa> some statistics from a custom blockchain compressor i wrote: http://pastebin.com/7iKJkuqh
134 2011-11-28 14:14:00 <sipa> (it doesn't do any attempt to compress coinbases or scripts)
135 2011-11-28 14:31:25 <davout> TD: you also trust the source with the hardcoded checkpoints
136 2011-11-28 14:31:44 <TD> indeed
137 2011-11-28 14:32:11 <sipa> davout: however, even with hardcoded checkpoints, the block chain must still exist and contain the claimed amount of proof-of-work
138 2011-11-28 14:32:42 <davout> sipa: oh yeah, definitely
139 2011-11-28 14:32:45 <makomk> Yeah. An incorrect checkpoint would tend to break stuff.
140 2011-11-28 14:33:21 <sipa> if you include the blocks directly in the distribution, without any checking at import, you could set people off with even a fake/invalid block chain
141 2011-11-28 14:33:40 <sipa> the difference is mostly psychological though :)
142 2011-11-28 14:33:48 <davout> sipa: i argued a while ago that the hardcoded checkpoints were unnecessary and actually conveyed a wrong idea that the blockchain's PoW security mechanism was somehow not enough
143 2011-11-28 14:34:05 <roconnor> I don't understand why you cannot ship the blockchain with the code; it doesn't matter where you find the longest block chain; whether it is from the network, or from disk, or from aliens directly trasmitting into your brain that you trascribe into your hex editor; the longest chain wins no matter where it comes from (note: longest chain means chain with most work)
144 2011-11-28 14:34:15 <roconnor> davout: I would agree with you
145 2011-11-28 14:34:27 <sipa> roconnor: if you ship it, and still process it at import: sure
146 2011-11-28 14:34:36 <davout> anyway, it does not really matter does it
147 2011-11-28 14:34:41 <roconnor> sipa: isn't that what we are talking about?
148 2011-11-28 14:34:55 <davout> maybe the best of both worlds would be to torrent the chain
149 2011-11-28 14:35:13 <sipa> roconnor: that doesn't have that much advantage over just downloading it
150 2011-11-28 14:35:28 <sipa> the time for processing it would remain
151 2011-11-28 14:35:55 <davout> yea, unless you skip it altogether by also shipping a BDB snapshot :D
152 2011-11-28 14:36:12 <sipa> if you go as far as shipping the block chain, i suppose it would be in the form of a pre-loaded database, including database of spent txouts
153 2011-11-28 14:36:16 <davout> e-wallets are the future for general ppl
154 2011-11-28 14:36:27 <sipa> davout: or at least lightweight clients
155 2011-11-28 14:36:32 <davout> yea
156 2011-11-28 14:36:36 <davout> btw
157 2011-11-28 14:36:46 <davout> nvm
158 2011-11-28 14:36:53 <sipa> lol
159 2011-11-28 14:36:58 <davout> XD
160 2011-11-28 14:37:04 <roconnor> sipa: oh, how long does it take to process the block chain?  I thought it was just a few minutes; though I haven't tried lately.
161 2011-11-28 14:37:10 <davout> lol
162 2011-11-28 14:37:11 <davout> no
163 2011-11-28 14:37:15 <sipa> roconnor: 8 hours?
164 2011-11-28 14:37:17 <davout> first download is a few hours
165 2011-11-28 14:37:31 <roconnor> davout: I mean if you have the chain locally on your computer
166 2011-11-28 14:37:43 <davout> and unless you've got a SSD your HD will scream
167 2011-11-28 14:37:55 <sipa> roconnor: disk access is the problem
168 2011-11-28 14:37:57 <roconnor> oh
169 2011-11-28 14:38:10 <sipa> purecoin still does everything in RAM?
170 2011-11-28 14:38:15 <roconnor> yep
171 2011-11-28 14:38:20 <davout> whats purecoin?
172 2011-11-28 14:38:32 <roconnor> but is is even slower since it doesn't use ASM for sha
173 2011-11-28 14:38:48 <sipa> how long does it take to import the entire chain?
174 2011-11-28 14:38:53 <roconnor> though the SHA module could be replaced with as ASM version
175 2011-11-28 14:39:21 <roconnor> sipa: many hours;  I'm not sure how long since I run out of memory on my laptop (I have no swap)
176 2011-11-28 14:42:14 <roconnor> Most of the reason it is slow is due to the garbage collector trying to squeeze every ounce of space out of my 2 or 3 GB memory
177 2011-11-28 14:42:29 <roconnor> I'd be curious to see how it runs on a 16 or 32 GB machine
178 2011-11-28 14:42:38 <roconnor> copumpkin: Have you run purecoin on such a machine?
179 2011-11-28 14:44:29 <copumpkin> I wish I had one :(
180 2011-11-28 14:46:13 <roconnor> anyhow purecoin tries to be as simiple an implementation as I can get away with.  The idea is more for documentation than for real use.
181 2011-11-28 14:58:27 <eps> i think we need blockchain pruning
182 2011-11-28 14:58:54 <eps> many hours on first startup is going to put people off
183 2011-11-28 14:59:14 <gmaxwell> eps: it wouldn't solve that.
184 2011-11-28 14:59:49 <TD> pruning is a disk space savings
185 2011-11-28 14:59:58 <TD> lightweight modes are the solution to the startup time issues
186 2011-11-28 15:00:04 <TD> for instance, MultiBit starts much faster
187 2011-11-28 15:00:14 <TD> of course lightweight mode in bitcoin c++ would be great
188 2011-11-28 15:00:23 <davout> running a node is not for everyone
189 2011-11-28 15:00:23 <TD> but it's a bit complicated. done wrong it could starve the network of full nodes
190 2011-11-28 15:00:29 <gmaxwell> roconnor: I could loan you a shell if you wanted to try it.
191 2011-11-28 15:00:43 <roconnor> gmaxwell: does it have ghc installed?
192 2011-11-28 15:01:00 <gmaxwell> roconnor: (on a machine with 64 gig)
193 2011-11-28 15:01:01 <gmaxwell> Glasgow Haskell Compiler, Version 6.12.3, for Haskell 98, stage 2 booted by GHC version 6.12.3
194 2011-11-28 15:01:12 <eps> when the chain is downloaded does it start at the beginning?
195 2011-11-28 15:01:25 <gmaxwell> eps: Yes.
196 2011-11-28 15:01:25 <roconnor> gmaxwell: :O
197 2011-11-28 15:01:38 <eps> is it possible to start at the end, work backwards and not download blocks that are fully spent?
198 2011-11-28 15:01:45 <eps> kind like pruning on the fly
199 2011-11-28 15:01:48 <gmaxwell> No.
200 2011-11-28 15:02:21 <gmaxwell> The whole point of downloading the chain is to validate the history of bitcoin, to confirm for yourself that gavin isn't secretly giving himself a million bitcoin.
201 2011-11-28 15:02:29 <gmaxwell> You can't do that operation backwards.
202 2011-11-28 15:02:34 <eps> i see
203 2011-11-28 15:02:51 <gmaxwell> Also, I've seen no evidence that the actual _download_ time is problematic for pretty much everyone.
204 2011-11-28 15:03:03 <roconnor> gmaxwell: I'd like to try that some day in the future.
205 2011-11-28 15:03:17 <gmaxwell> (well I suppose there is someone in the desert with a satlink as their only internet that might care...)
206 2011-11-28 15:03:34 <gmaxwell> roconnor: sure. my hosts are super busy at the moment anyways. But I'm around...
207 2011-11-28 15:03:43 <roconnor> thanks
208 2011-11-28 15:08:44 <gmaxwell> TD: getting the incentives right is hard... especially with the mining pool situation. In theory there are only a few dozen people who are overtly and directly incented to run full nodes, assuming that there was a really good line client that could drop in.
209 2011-11-28 15:11:02 <roconnor> line client?
210 2011-11-28 15:15:58 <gmaxwell> lite.
211 2011-11-28 15:18:52 <wereHamster> roconnor: in which language are you writing purecoin?
212 2011-11-28 15:19:29 <roconnor> wereHamster: Haskell
213 2011-11-28 15:23:41 <TD> gmaxwell: i'd like to see the satoshi client start out as lightweight, then upgrade itself to full in the background
214 2011-11-28 15:23:45 <TD> that's quite some tricky coding though
215 2011-11-28 15:24:02 <luke-jr> TD: that would be neat
216 2011-11-28 15:24:18 <luke-jr> too bad Gavin added all that anti-"DoS" nonsense tho
217 2011-11-28 15:24:19 <TD> otherwise i agree, finding the right balance is tough
218 2011-11-28 15:24:31 <luke-jr> that stuff means you can't relay anything until you're a full client
219 2011-11-28 15:24:32 <TD> running a full node is fairly cheap though
220 2011-11-28 15:24:43 <wereHamster> roconnor: cool, a friend of mine is constatnly trying to convince me to learn haskell. Where can I see the source?
221 2011-11-28 15:24:57 <gavinandresen> TD: lightweight-to-full shouldn't be that hard... that's my plan for the headers-only branch
222 2011-11-28 15:25:11 <TD> i'd hope that a combination of "public service announcements" and a decent website would be enough reason for enthusiastic supporters to run a nide
223 2011-11-28 15:25:16 <TD> gavinandresen: cool
224 2011-11-28 15:25:20 <luke-jr> gavinandresen: maybe the anti-DoS rules need reconsideration to allow lightweight relays?
225 2011-11-28 15:25:45 <TD> well
226 2011-11-28 15:25:47 <roconnor> wereHamster: if you install darcs, you can run the command "darcs get http://r6.ca/Purecoin"
227 2011-11-28 15:25:53 <TD> relaying without validating adds latency but also adds sockets
228 2011-11-28 15:26:00 <gavinandresen> luke-jr: how do the anti-DoS rules affect lightweight relays?  You mean being dinged for relaying invalid transactions/blocks ?
229 2011-11-28 15:26:02 <TD> i'm not sure it's a great idea for lightweight clients to relay. bitcoinj does not.
230 2011-11-28 15:26:07 <luke-jr> gavinandresen: right
231 2011-11-28 15:26:22 <gavinandresen> luke-jr: if you're relaying invalid crap then you're not helping the network, imho
232 2011-11-28 15:26:35 <luke-jr> gavinandresen: you are, so long as you also relay valid crap
233 2011-11-28 15:26:47 <lianj> hehe
234 2011-11-28 15:27:30 <TD> i think in future lightweight clients won't be running for a long time
235 2011-11-28 15:27:38 <TD> the model would be "start up, spend/check receipts, shut down"
236 2011-11-28 15:27:51 <TD> so relaying or not is unlikely to make a huge difference
237 2011-11-28 15:28:00 <TD> certainly, mobile clients won't relay
238 2011-11-28 15:28:05 <gavinandresen> I agree with TD.  That's actually the way I run bitcoin-- startup if I need to spend or move coins, then shutdown.
239 2011-11-28 15:33:00 <wereHamster> roconnor: ah, the haskell people just love darcs, don't they? :)
240 2011-11-28 15:33:29 <roconnor> naturally
241 2011-11-28 15:38:41 <wereHamster> roconnor: does your project have a web/homepage?
242 2011-11-28 15:41:07 <roconnor> nope
243 2011-11-28 15:41:59 <roconnor> last thing we need are people running incompatible clients
244 2011-11-28 15:42:45 <copumpkin> prove it compatible
245 2011-11-28 15:43:05 <sipa> yes, lets feed it every possible block chain
246 2011-11-28 15:43:28 <roconnor> sipa: that's not necessarly
247 2011-11-28 15:43:43 <roconnor> all we need is formal semantics for C++ and Haskell and prove that the two programs are the same.
248 2011-11-28 15:43:50 <copumpkin> proof by exhaustive search is the best kind of proof
249 2011-11-28 15:43:59 <wereHamster> for haskell I imagine it already exists, but for C++?
250 2011-11-28 15:44:20 <copumpkin> even haskell isn't really well specified
251 2011-11-28 15:48:15 <sipa> unsafePerformIO and FFI ahoy
252 2011-11-28 15:49:54 <luke-jr> speaking of which, bitcoin.org should provide downloads for wxBitcoin, Bitcoin-Qt, and MultiBit. discuss. :P
253 2011-11-28 15:50:23 <TD> wxbitcoin is obsolete and ugy, no. bitcoin-qt is already there. multibit .... ~no. bitcoinj isn't robust enough for serious real-world usage yet.
254 2011-11-28 15:50:37 <TD> also it's kind of confusing to present users with multiple clients and no advice on which to choose
255 2011-11-28 15:51:17 <gavinandresen> Is StrongCoin or one of the trust-no-one web-based solutions far enough along to recommend?
256 2011-11-28 15:52:10 <gavinandresen> ... actually, I guess any of the web-based solutions require you trust them to serve up the code that they claim they're serving up...
257 2011-11-28 15:52:22 <TD> i don't know. i think there's a problem with recommending anything that isn't bitcoin-qt  right now
258 2011-11-28 15:52:28 <Eliel> gavinandresen: unless you package up the client portion to be loaded from local system.
259 2011-11-28 15:52:31 <TD> we should maybe link to them
260 2011-11-28 15:52:40 <TD> with the caveat that they are "there for exploration and experimentation" or something
261 2011-11-28 15:52:43 <luke-jr> TD: wxBitcoin isn't quite obsolete until there's a need for 0.4.2 that isn't fulfilled. ;)
262 2011-11-28 15:53:00 <phantomcircuit> gavinandresen, yeah exactly fundamentally flawed
263 2011-11-28 15:53:00 <TD> so regular users who read about bitcoin in Wired or whatever just use the satoshi client, and people who get a bit more adventurous can try out others (+devs)
264 2011-11-28 15:53:26 <luke-jr> TD: wxBitcoin is more appropriate recommendation for users who don't want a whole UI change
265 2011-11-28 15:53:33 <TD> gavinandresen: i think justmoon was talking about some tricks that would avoid that, basically implementing client-side type update procedures on top of the web
266 2011-11-28 15:53:43 <luke-jr> and Bitcoin-Qt has been reported to corrupt wallets, still, yet with no reproducability
267 2011-11-28 15:53:51 <TD> gavinandresen: ultimately, you have to trust the provider of your software. there is no way to avoid that, unless you're a dev and can read the code thoroughly.
268 2011-11-28 15:54:25 <TD> the issue with alt implementations is they're all very new, and mostly written by people who are also new to the community
269 2011-11-28 15:54:39 <gavinandresen> TD: yep.  Ideally, I'd like the bitcoin.org homepage to get out of the distributing software business entirely
270 2011-11-28 15:54:42 <luke-jr> MultiBit supposedly is fully functional
271 2011-11-28 15:54:51 <TD> i can vouch for the BitCoinJ based clients and i was playing with bitcoin since 2009, so i've got a track record. the strongcoin guys .... they seem to be doing a great job, but building trust takes time
272 2011-11-28 15:54:57 <luke-jr> wxBitcoin obviously is, and much more well-tested than Bitcoin-Qt
273 2011-11-28 15:55:08 <TD> luke-jr: it "works" but there's some non-ideal stuff in there (not in jims code, in mine). for instance the fees implementation is a hack
274 2011-11-28 15:55:16 <sipa> luke-jr: and which UI are you using yourself?
275 2011-11-28 15:55:24 <roconnor> I guarentee that purecoin is not entirely compatible with bitcoin
276 2011-11-28 15:55:28 <luke-jr> TD: the fee implementation in the original codebase is a hack too
277 2011-11-28 15:55:32 <luke-jr> sipa: Bitcoin-Qt
278 2011-11-28 15:55:41 <lianj> last time i checked bitcoinj didnt implement the signature check tho
279 2011-11-28 15:55:43 <TD> gavinandresen: i guess Electrum represents a reasonable tradeoff, the key issue there being what if their server goes away
280 2011-11-28 15:55:49 <TD> lianj: it's a lightweight client
281 2011-11-28 15:55:52 <TD> lianj: that's intentioanl
282 2011-11-28 15:55:55 <sipa> roconnor: where precisely?
283 2011-11-28 15:56:34 <lianj> TD: hm, the functions were there, yes just returned true :D
284 2011-11-28 15:56:37 <roconnor> well it doesn't handle OP_IF, but I'm pretty sure there are many more unknown incompatibilities.
285 2011-11-28 15:56:50 <TD> lianj: yes, obsolete code. it should be deleted. i thought i had deleted it actually
286 2011-11-28 15:56:58 <TD> yeah i did
287 2011-11-28 15:57:01 <TD> maybe you read an old version
288 2011-11-28 15:57:13 <lianj> yea, didnt look at it for some month :)
289 2011-11-28 15:57:23 <lianj> oh the code is by you?
290 2011-11-28 15:57:54 <TD> yeah
291 2011-11-28 15:58:08 <lianj> thank you. it really helped me understand some parts of bitcoin. reading it was more enjoyable then the c++ client
292 2011-11-28 15:58:33 <lianj> good code quality :)
293 2011-11-28 15:58:48 <roconnor> sipa: also I don't think I filter out signatures from scripts
294 2011-11-28 15:59:54 <ThomasV> TD: there will soon be more than  one server; ovidiusoft is setting up another one
295 2011-11-28 16:01:08 <TD> lianj: thanks!
296 2011-11-28 16:01:10 <sipa> roconnor: hmm, but you can verify everything currently in the main and testnet chains?
297 2011-11-28 16:01:21 <TD> ThomasV: cool
298 2011-11-28 16:02:07 <roconnor> sipa: ya, because the verfication runs on the public key scripts, but the signature is always on the signature script in standard transactions.
299 2011-11-28 16:02:19 <roconnor> sipa: so there is nothing to filter for normal transactions.
300 2011-11-28 16:02:44 <roconnor> sipa: actually I can't think of any sane script where filtering would do anything
301 2011-11-28 16:03:20 <roconnor> I actually suspect this is simply a bit of junk code that is a hold-over from previous versions.
302 2011-11-28 16:03:26 <TD> what code is that ?
303 2011-11-28 16:04:07 <roconnor> TD: the code that filters out signatures in a script before validating the signature
304 2011-11-28 16:04:16 <TD> yeah
305 2011-11-28 16:04:27 <TD> that always foxed me too. agreed it's probably left over from work in progress
306 2011-11-28 16:04:33 <TD> maybe OP_CODESEPARATOR is the same
307 2011-11-28 16:04:41 <roconnor> ya
308 2011-11-28 16:05:15 <roconnor> like junk DNA :D
309 2011-11-28 16:06:13 <TD> it's too bad there's no flag that allows the signature to not cover the outpoint
310 2011-11-28 16:06:31 <TD> it might be useful to be able to sign properties of a tx that can be connected to arbitrary inputs
311 2011-11-28 16:07:41 <TD> "The design supports a tremendous variety of possible transaction types that I designed years ago.  Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc."
312 2011-11-28 16:07:59 <TD> i think we got all of those, right. it may be there aren't a whole lot of contracts left to 'discover' (i hesitate to say invent)
313 2011-11-28 16:08:08 <TD> though i'm not sure what a bonded contract is, in this context
314 2011-11-28 16:08:16 <roconnor> TD: doesn't SIGHASH_NONE not cover any outpoints?
315 2011-11-28 16:08:32 <TD> SIGHASH_NONE clears the outPUTs not outPOINTs
316 2011-11-28 16:08:37 <TD> outpoints are a property of the input
317 2011-11-28 16:09:07 <roconnor> doesn't AnyoneCanPay not cover any inputs?
318 2011-11-28 16:09:23 <TD> it still covers the output being checked
319 2011-11-28 16:09:25 <TD> sorry
320 2011-11-28 16:09:26 <TD> outpoint
321 2011-11-28 16:09:35 <TD> it clears the other inputs, not all inputs
322 2011-11-28 16:10:06 <roconnor> I'm pretty sure that AnyoneCanPay clears all inputs
323 2011-11-28 16:10:23 <roconnor> it is normal transactions that clears the other inputs
324 2011-11-28 16:10:41 <TD> https://github.com/bitcoin/bitcoin/blob/master/src/script.cpp#L924
325 2011-11-28 16:10:47 <roconnor> either that or I have more mistakes in my code
326 2011-11-28 16:10:49 <TD> // Blank out other inputs completely, not recommended for open transactions
327 2011-11-28 16:10:50 <TD> {
328 2011-11-28 16:11:43 <roconnor> oh right
329 2011-11-28 16:11:46 <roconnor> I see now
330 2011-11-28 16:11:58 <roconnor> and in fact, my code does that; I was just misreading it.
331 2011-11-28 16:12:07 <TD> yeah it's tricky, even when you've implemented it :-)
332 2011-11-28 16:12:23 <TD> it would have been useful if there was a way to do this for network speed assurance contracts
333 2011-11-28 16:12:48 <TD> they're something i'm still designing but didn't succeed in a totally low-trust solution yet
334 2011-11-28 16:44:28 <devrandom> hey TD
335 2011-11-28 16:44:38 <TD> hey devrandom
336 2011-11-28 16:47:51 <TD> devrandom: any idea if/when you'll have time to do the git conversion?
337 2011-11-28 16:48:08 <devrandom> I'll do it right now
338 2011-11-28 16:49:00 <topi`> 0.5.0 claims to be faster at downloading the block chain. but how can it be downloaded faster?
339 2011-11-28 16:49:20 <topi`> downloading a 80K block requires 80k bytes to be received thru the 'net...
340 2011-11-28 16:49:53 <nanotube> topi`: probably has to do with verification rather than network
341 2011-11-28 16:50:11 <nanotube> the bottleneck in blockchain dl is not bandwidth, but all the cpu-intensive verification of all the blocks and transactions
342 2011-11-28 16:51:09 <topi`> but it only has to hash the data once, and calculate the merkel tree
343 2011-11-28 16:51:21 <topi`> where's the cpu intensivity?
344 2011-11-28 16:51:26 <TD> nope
345 2011-11-28 16:51:39 <TD> it has to verify all the signatures as well (at least, it did, until gavin changed it)
346 2011-11-28 16:51:40 <nanotube> well first, it has to verify that for every block, but also ecdsa sigs
347 2011-11-28 16:51:43 <TD> and update the on-disk db
348 2011-11-28 16:52:18 <nanotube> TD: so gavin made it not check the sigs on all transactions?
349 2011-11-28 16:52:34 <topi`> what signatures?
350 2011-11-28 16:52:40 <TD> right. not until some period before the last checkpoint
351 2011-11-28 16:52:47 <nanotube> TD: ah ic.
352 2011-11-28 16:52:56 <topi`> like, who transferred the coin to whom?
353 2011-11-28 16:53:11 <TD> yeah. to transfer value you have to sign for it
354 2011-11-28 16:53:19 <TD> and everyone who sees that transaction, has to check (unless they are lightweight)
355 2011-11-28 16:53:50 <nanotube> topi`: a transaction is a signed data packet, signed by the private key of the public key that hashes to the address(es) that received the input(s)
356 2011-11-28 16:54:06 <nanotube> s/key/key(s)/g
357 2011-11-28 16:54:33 <topi`> ah, indeed
358 2011-11-28 16:55:02 <topi`> gpg takes some time in verifying sigs
359 2011-11-28 16:55:15 <upb> gpg ?
360 2011-11-28 16:55:28 <nanotube> well yes, it's a similar idea to gpg signatures
361 2011-11-28 16:55:35 <topi`> i don't have any benchmarks.
362 2011-11-28 16:55:37 <nanotube> they're both asymmetric keys
363 2011-11-28 16:56:17 <nanotube> last i saw gavin mention it, it takes something like 0.3s to verify an ecdsa sig? TD is that right or am i off by a few orders of magnitude :)
364 2011-11-28 16:56:47 <sipa> nanotube: you're off by 3 orders of magintude
365 2011-11-28 16:56:47 <TD> that's wrong by orders of magnitude :)
366 2011-11-28 16:56:49 <nanotube> either 3millisec, or 300millisec... is what i recall.
367 2011-11-28 16:56:49 <TD> 3msec
368 2011-11-28 16:56:51 <nanotube> hehe ok
369 2011-11-28 16:57:15 <nanotube> sipa: that's 2 orders, not 3 :P
370 2011-11-28 16:57:16 <topi`> :)
371 2011-11-28 16:57:55 <sipa> nanotube: oh, i define an order of magnitude as about a factor 4.64 ;)
372 2011-11-28 16:58:12 <sipa> ok ok, you're right
373 2011-11-28 16:58:15 <nanotube> sipa: lol
374 2011-11-28 16:59:56 <topi`> an average of 20 sigs per block is only 0.06 s
375 2011-11-28 17:00:42 <nanotube> topi`: well, later blocks have more tx
376 2011-11-28 17:01:18 <nanotube> note also that each tx is as likely as not to have more than one sig
377 2011-11-28 17:01:35 <topi`> right now, 243 tx per hour.
378 2011-11-28 17:01:36 <roconnor> sipa: It'd be funny if my Haskell implementation ran faster than the standard client on a 64 GB machine. :)
379 2011-11-28 17:01:50 <sipa> roconnor: I expect it to be faster
380 2011-11-28 17:02:06 <roconnor> sipa: well, maybe if I replace the SHA module with one that calls C
381 2011-11-28 17:02:13 <sipa> the standard client loses most of its time synchronizing to disk
382 2011-11-28 17:02:21 <topi`> roconnor: you've implemented some handling in haskell? very interesting!
383 2011-11-28 17:02:40 <roconnor> topi`: I have almost the entire verification protocol impelmented.
384 2011-11-28 17:02:41 <topi`> i haven't touched haskell in many months...
385 2011-11-28 17:03:04 <topi`> cool, very cool
386 2011-11-28 17:03:15 <roconnor> :) I'm glad you think so
387 2011-11-28 17:04:16 <topi`> haskell is absolutely wonderful
388 2011-11-28 17:04:32 <topi`> very concise:)
389 2011-11-28 17:04:33 <gribble> Error: "hi5" is not a valid command.
390 2011-11-28 17:04:33 <sipa> !hi5
391 2011-11-28 17:04:45 <topi`> except with a ton of boilerplate ;)
392 2011-11-28 17:05:07 <roconnor> topi`: There are several libraries for boilerplate removal :)
393 2011-11-28 17:05:58 <sipa> 1932456 txs, 4476972 txouts, 3265935 txins
394 2011-11-28 17:06:03 <sipa> (current blockchain stats)
395 2011-11-28 17:06:41 <sipa> that means with 3ms per signature verification, the client spends 2.7h for verifying the block chain
396 2011-11-28 17:06:42 <Edward_Black> Hey, could someone with good knowledge of how btc "nonstandard" transactions work (and don't work), the upcoming mulisign does not allow you to explicitly specify (when "creating" it) to which address should it go when all signatures are in place ?
397 2011-11-28 17:06:55 <nanotube> sipa: so 2.7 hours to verify all the sigs, assuming absolutely no other overhead eh. :)
398 2011-11-28 17:07:14 <Edward_Black> oh bother, missed "please clarify"...for shame :~(
399 2011-11-28 17:07:25 <gmaxwell> Edward_Black: I thought I answered this for you before. It doesn't. You specify that in the transaction which spends it, the one with many signatures.
400 2011-11-28 17:07:42 <gmaxwell> 3ms sounds slow
401 2011-11-28 17:07:55 <sipa> in practice it's a lot less on modern cpu's
402 2011-11-28 17:08:07 <sipa> i've seen 0.6ms on my desktop, i believe
403 2011-11-28 17:08:40 <Edward_Black> gmaxwell thanks
404 2011-11-28 17:09:05 <gmaxwell> Edward_Black: weird, someone must have asked a similar question a couple days ago.
405 2011-11-28 17:09:27 <gmaxwell> Edward_Black: of course the people doing the signing can all see where the funds go, and so they can decide to refuse to sign unless they like the outputs.
406 2011-11-28 17:09:27 <sipa> Edward_Black: call a transaction output a "coin", and transactions destroy coins and create new ones
407 2011-11-28 17:09:42 <sipa> Edward_Black: these new coins are then owner by someone the transaction specifies
408 2011-11-28 17:09:56 <sipa> complex transactions allow you to create a coin that is owned by multiple people
409 2011-11-28 17:10:08 <sipa> who must e.g. both agree what to do with it
410 2011-11-28 17:10:30 <sipa> but the complex transaction doesn't specify *what* to do with it next - that's up to the next transaction
411 2011-11-28 17:12:11 <Edward_Black> sipa what I am  having on my mind is a nonstandard TX that does (unlike multisign-as-proposed) specify possible "destination" addresses, but can only become spendable when 2 parties agree (so that it gets hung in "limbo" in the blockchain untill they agree).
412 2011-11-28 17:12:22 <Edward_Black> Is such a monster at all possible ?
413 2011-11-28 17:12:31 <sipa> read TD's text about contracts
414 2011-11-28 17:12:59 <TD> not only is it possible, work is being done to implement it
415 2011-11-28 17:13:04 <TD> so you can have 2-factor coins
416 2011-11-28 17:14:19 <Edward_Black> TD well, that sounds quite awesome. Gotta tell lolcust
417 2011-11-28 17:14:54 <sipa> afaik you can't have a complex transaction determine what to do next with the outputs
418 2011-11-28 17:15:43 <Edward_Black> sipa awwww, is that a fundamental scripting language limit ?
419 2011-11-28 17:15:55 <Edward_Black> That would be sad :~(
420 2011-11-28 17:16:06 <sipa> i'm not sure why you'd need it?
421 2011-11-28 17:16:16 <TD> sometimes there are ways around the limitations
422 2011-11-28 17:16:25 <sipa> (i'm not stating that there are no applications for that, but i current don't see one)
423 2011-11-28 17:16:26 <TD> for your use case, you'd sign a bunch of different transactions, one for each possible output address
424 2011-11-28 17:16:41 <TD> and not broadcast them, until one was selected+signed
425 2011-11-28 17:16:47 <TD> anyway, need to go
426 2011-11-28 17:16:57 <Edward_Black> Bye, TD
427 2011-11-28 17:18:06 <Edward_Black> sipa basically, what I want is, send a TX to A's address, and have it "struck in the stone of blockchain" that it was sent to that very address) but not let him spend them as long as we reach an agreement of sorts
428 2011-11-28 17:18:43 <sipa> why do you need it in the block chain?
429 2011-11-28 17:19:46 <gmaxwell> If it's a matter of proving that a contract existed.. the parties could just use their addresses to sign a message with a statement of intent.
430 2011-11-28 17:20:41 <Edward_Black> sipa to ensure that a third party could see that 1) there is this TX to this address 2) it is not yet spent 3) there is a certain comment oppdropped into it, formated in accordance to a certain specification
431 2011-11-28 17:21:15 <Edward_Black> It's basically "this address has a comment on it, and the party who placed the comment has not deemed it worthy of being "no longer valid""
432 2011-11-28 17:21:29 <sipa> a) comments to not belong in the block chain
433 2011-11-28 17:21:53 <sipa> they are something between the spender and the receiver, and nobody else needs it to verify the integrity of the transaction
434 2011-11-28 17:22:30 <Edward_Black> Well, as you might know, it's not Bitcoin's chain I want add  comments to ;~)
435 2011-11-28 17:22:31 <sipa> b) why does it need to be to a particular address?
436 2011-11-28 17:22:50 <sipa> right, you do what you want of course, but i don't consider it the best solution
437 2011-11-28 17:23:40 <Edward_Black> Because I want the comment to "stick" to that particular address, but I also want there to be a mechanism for parties to agree to "mark that comment as no longer relevant"
438 2011-11-28 17:24:11 <Edward_Black> If there was a way to send a custom TX to a specific address that would only be spendable after both sender and reciever agree, that would be trivial to do
439 2011-11-28 17:24:38 <sipa> if the TX is custom, it won't be just "to a specific address" anymore
440 2011-11-28 17:25:24 <Edward_Black> Oh, ok, and that is a strict limit of the scripting logic employed, right ?
441 2011-11-28 17:25:34 <sipa> it's a matter of terminology
442 2011-11-28 17:26:01 <sipa> an address corresponds to a) an identifier for a public key and b) a specific template for a transaction output script
443 2011-11-28 17:26:38 <sipa> if you call any transaction that requires the use of a particular key as being "to that address", then you may be right, but it's not possible in general anyway
444 2011-11-28 17:28:41 <luke-jr> any objections to an IRC bot that inserts the last thing it sees in coinbases?
445 2011-11-28 17:30:02 <Edward_Black> I propose a better idea (originally proposed by Lolcust), make an aucton in BTC where visitors of a page will be able to bid on what phrase to insert into blockchain, and submit their own phrases to the auction (also for BTC)
446 2011-11-28 17:30:12 <Edward_Black> More cryptocoins for your pool that way
447 2011-11-28 17:30:56 <luke-jr> that's more difficult :o
448 2011-11-28 17:31:05 <Edward_Black> But profitable
449 2011-11-28 17:31:56 <Edward_Black> it is of course mildly amusing to have random chunks of our discussions immortalized like that, but with Lol's proposal, you will actually get compensated for the labor
450 2011-11-28 17:34:00 <Edward_Black> users pay to submit, and pool in additional coins for every submission (you can "bid" on your own phrase, too), and the most profitable phrase gets carried into the blockchain. The auction "ends" every time the pool finds a new block (which immortalizes the previous winner), the pool caches the current winning phrase for inclusion in next block
451 2011-11-28 17:34:25 <Edward_Black> and people proceed to fight each other with BTC for which phrase will become immortal after that
452 2011-11-28 17:35:09 <Edward_Black> And you know what is the beauty of it ? The lower is BTC price, the more coins you will get from silliness like this, so consider it a really odd hedging strategy :~)
453 2011-11-28 17:35:18 <luke-jr> XD
454 2011-11-28 17:36:37 <luke-jr> problem is, right now I'll do it free of charge and nobody much is interested
455 2011-11-28 17:37:42 <Edward_Black> Because it is not very interesting to immortalize random IRC chat chunks ?
456 2011-11-28 17:38:24 <luke-jr> on demand, not from IRC :P
457 2011-11-28 17:39:09 <Edward_Black> Ah, so you "take comissions" ?
458 2011-11-28 17:40:52 <luke-jr> no, I just take suggestions :P
459 2011-11-28 17:41:04 <luke-jr> if there's no reason NOT to include it, it goes in
460 2011-11-28 17:41:55 <Edward_Black> Well, people might be afraid of your harsh judgement ;~)
461 2011-11-28 17:42:06 <sipa> you have permission from all people that may be logged?
462 2011-11-28 17:42:42 <Edward_Black> I thought this channel is logged and displayed publicly as matter of policy...
463 2011-11-28 17:43:51 <sipa> he may not need to legally (ianal), but i'd prefer not to have comments i make eternalized without context in the block chain
464 2011-11-28 17:44:41 <Edward_Black> Yeah, that might end up hillariously wrong.
465 2011-11-28 17:46:03 <luke-jr> lol
466 2011-11-28 17:46:05 <luke-jr> QOOC
467 2011-11-28 17:56:46 <topi`> bitcoins sent last 24h is around 4 MILLION btc, this is a whopping 50% of total BTC that exists today
468 2011-11-28 17:57:08 <topi`> I wonder what kind of back-and-forth transactions make the bulk of this
469 2011-11-28 17:57:32 <topi`> and how many coins are completely stationary and do not move anywhere
470 2011-11-28 17:57:43 <topi`> (my coins are)
471 2011-11-28 17:58:51 <ThomasV> tcatm: "Latest Price
472 2011-11-28 17:59:07 <ThomasV> http://bitcoincharts.com/markets/
473 2011-11-28 18:00:09 <tcatm> ThomasV: yes, 24h avergage
474 2011-11-28 18:00:34 <ThomasV> tcatm: so you don't show the previous close?
475 2011-11-28 18:00:52 <tcatm> there's not "previous close" anymore
476 2011-11-28 18:01:10 <ThomasV> how confusing
477 2011-11-28 18:01:27 <tcatm> it was pretty arbitary anyway
478 2011-11-28 18:01:44 <tcatm> there's just no good way to have a "previous close" with 24/7 markets
479 2011-11-28 18:01:47 <ThomasV> but the bars are still arbitrary
480 2011-11-28 18:02:00 <ThomasV> at least it was consistent
481 2011-11-28 18:02:31 <tcatm> you can still view the raw data used to render the chart
482 2011-11-28 18:06:14 <roconnor> topi`: how many bitcoindays destroyed?
483 2011-11-28 18:09:03 <eueueue> how to know how many address with any amount of coins already exist?
484 2011-11-28 18:10:17 <sipa> eueueue: walk the block chain, and tick each address that is identifiable as destination in a txout script
485 2011-11-28 18:10:48 <eueueue> I mean: is there any service that show automatically this info?
486 2011-11-28 18:44:09 <Diablo-D3> http://www.reddit.com/r/ReverseEngineering/comments/ms4yp/iama_request_fsecure_employee_attempting_to/
487 2011-11-28 18:44:11 <Diablo-D3> oh fuck you
488 2011-11-28 18:56:33 <ThomasV> tcatm: the volume too is 24hourized?
489 2011-11-28 18:58:26 <jgarzik> ThomasV: should be...
490 2011-11-28 18:58:47 <tcatm> ThomasV: yes, but there's a column for 30d volume, too
491 2011-11-28 19:15:53 <sipa> jgarzik: in case you still remember: https://github.com/sipa/bitcoin/tree/joke
492 2011-11-28 19:17:36 <ThomasV> how does the bitcoin client encrypt its wallet? with ECC ?
493 2011-11-28 19:17:52 <sipa> ThomasV: AES-256-CBC, with a randomly generated key
494 2011-11-28 19:18:06 <ThomasV> why not ECC ?
495 2011-11-28 19:18:21 <sipa> because it doesn't need assymetric encryption
496 2011-11-28 19:19:06 <ThomasV> yes but it could have used it, becaise it already has elliptic curves implemented
497 2011-11-28 19:19:12 <sipa> no
498 2011-11-28 19:19:18 <ThomasV> why not?
499 2011-11-28 19:19:23 <sipa> EC can't encrypt by itself, but you can use it to derive a shared secret that can be used for a symmetric cipher like AES anyway
500 2011-11-28 19:19:52 <sipa> look for EC-IEC or ECDH for more information
501 2011-11-28 19:20:08 <sipa> EC-IES, that is
502 2011-11-28 19:21:51 <jgarzik> sipa: don't remember / get the joke
503 2011-11-28 19:21:55 <jgarzik> it's Monday, so...
504 2011-11-28 19:22:00 <roconnor> sipa: presumable there is some sort of EC elgamal?
505 2011-11-28 19:22:10 <sipa> jgarzik: you once told me i could put my phd thesis in a git commit :)
506 2011-11-28 19:22:16 <jgarzik> sipa: ah ;)
507 2011-11-28 19:22:55 <roconnor> ``ElGamal encryption can be defined over any cyclic group G'' -- http://en.wikipedia.org/wiki/ElGamal_encryption
508 2011-11-28 19:24:21 <roconnor> but anyhow, sipa is right; no use using public key crypto on the wallet.
509 2011-11-28 19:24:56 <sipa> it would have been possible, by the way - i even suggested it - as it would allow adding keys to the wallet without unlocking it
510 2011-11-28 19:25:13 <sipa> but that held a risk of an attacker "contaminating" a wallet
511 2011-11-28 19:25:31 <roconnor> ThomasV: bitcoin doesn't directly implement EC; it calls into openssl, and openssl provides symetric encryption functionality.
512 2011-11-28 19:25:48 <roconnor> sipa: how does an attacker contaminate a wallet?
513 2011-11-28 19:26:17 <sipa> if he has write access to your disk, he could add his own keys as reserve keys to your wallet
514 2011-11-28 19:26:20 <gavinandresen> sipa : no second thoughts on making the OP_EVAL bitcoin address 'version' byte 2 on mainnet, 109 (111^2) on testnet ?
515 2011-11-28 19:26:49 <sipa> gavinandresen: yes, i plan to, been a bit busy since returning from the conference
516 2011-11-28 19:26:51 <roconnor> sipa: I don't really see how that harms you.
517 2011-11-28 19:26:59 <ThomasV> sipa: is there something wrong with using assymetric encryption for encrypting one's own wallet?
518 2011-11-28 19:27:02 <upb> Diablo-D3: you work for f-secure ?
519 2011-11-28 19:27:21 <gavinandresen> sipa: I'm committing that change to my OP_EVAL branch.
520 2011-11-28 19:27:29 <Diablo-D3> upb: no
521 2011-11-28 19:27:36 <roconnor> sipa: an attacker can already use xor to potentially change your keys to other keys.
522 2011-11-28 19:27:40 <Diablo-D3> upb: why would you ask that?
523 2011-11-28 19:27:44 <sipa> roconnor: sure, but not to his own
524 2011-11-28 19:27:52 <roconnor> sipa: encryption doesn't ensure integrety
525 2011-11-28 19:28:02 <Diablo-D3> if I worked for a company that makes virus scanners, there would never be another virus ever again
526 2011-11-28 19:28:07 <copumpkin> lol
527 2011-11-28 19:28:15 <sipa> roconnor: and his own keys in your wallet would mean he would get your change
528 2011-11-28 19:28:43 <gavinandresen> roconnor: the attack is:  remove all the keypool keys, replace them with known-to-the-attacker keys.
529 2011-11-28 19:28:46 <roconnor> sipa: okay, but still, encryption doesn't ensure integrity
530 2011-11-28 19:29:02 <roconnor> they can do that right now with AES encrypted wallets (and a bit of luck
531 2011-11-28 19:29:10 <gavinandresen> no, they can't.
532 2011-11-28 19:29:21 <sipa> roconnor: nope - the wallet contains the pubkey unencrypted and the private key encrypted
533 2011-11-28 19:29:38 <sipa> when decrypting, afaik a check is done whether they match
534 2011-11-28 19:31:10 <roconnor> still, as a general rule, encryption doesn't ensure integrity; it isn't designed to stop attacks like this.
535 2011-11-28 19:31:23 <roconnor> you guys are playing with fire
536 2011-11-28 19:31:43 <sipa> well, i think an attacker having write access to your disk is already a pretty damned situation
537 2011-11-28 19:31:54 <sipa> i don't consider it part of the threat model we defend against
538 2011-11-28 19:32:05 <gavinandresen> yup, you're already screwed.  That's why I'm big on multi-device transaction authorization.
539 2011-11-28 19:32:07 <roconnor> so your proposal was rejected for no good reason
540 2011-11-28 19:32:16 <roconnor> too bad
541 2011-11-28 19:33:32 <roconnor> but I guess it doesn't matter too much
542 2011-11-28 19:33:56 <roconnor> gmaxwell's idea of generated multiple keys from a single key seems far more interesting to me :)
543 2011-11-28 19:34:39 <gmaxwell> The loss of automagic unstealing is unfortunate though.
544 2011-11-28 19:35:01 <roconnor> gmaxwell: what is automagic unstealing?
545 2011-11-28 19:35:29 <gavinandresen> yes, what is automagic unstealing?
546 2011-11-28 19:35:37 <gmaxwell> roconnor: right now if I steal your wallet from 6 months ago (e.g. on a discarded harddisk), and you're a good little bitcoin user and don't reuse addresses.. then I probably stole nothing.
547 2011-11-28 19:35:53 <Eliel> roconnor: if you add an encrypted checksum, you could verify it hasn't been tampered by anyone who doesn't know the password.
548 2011-11-28 19:35:56 <sipa> ThomasV: if you read the above: using assymetric encryption for the wallet has the advantage of filling up the keypool without unlocking, and the disadvantage of being slower and opening a potential vulnerability where an attacker can put his own keys in your wallet
549 2011-11-28 19:36:06 <gmaxwell> and if you suspect a leak you can just drop your keypool and become unstolen fast.
550 2011-11-28 19:36:25 <gmaxwell> Eliel: but then you couldn't add keys!
551 2011-11-28 19:36:30 <Eliel> oh true
552 2011-11-28 19:37:51 <ThomasV> sipa: ok, but I was asking for another client, where AES creates an extra dependency
553 2011-11-28 19:38:10 <roconnor> gmaxwell: the advantages of key generation seem to outweight that loss.
554 2011-11-28 19:38:36 <gmaxwell> you could compose keys for this, using the type-2 scheme or whatever I called it.. e.g. you don't generate a whole key, you just generate a whole new public key and a new half private key. ... and you save all the haves so your wallet still gets unstolen (and still has annoying backup issues).  But then you're secure against that key insertion attack, I guess.
555 2011-11-28 19:38:43 <sipa> ThomasV: and again - you can't encrypt using EC itself - you can only use it to derive a session key
556 2011-11-28 19:38:55 <sipa> you would still need AES or something similar for the actual encryption
557 2011-11-28 19:38:57 <gmaxwell> roconnor: yes, I personally think the determinstic behavior is worth the cost. Opinions differ though.
558 2011-11-28 19:39:22 <ThomasV> sipa: I can derive a keypair from the password, no?
559 2011-11-28 19:39:34 <sipa> yes
560 2011-11-28 19:39:37 <sipa> you could
561 2011-11-28 19:39:40 <roconnor> ThomasV: if EC could be used to encrypt, it would only be able to encrypt tiny messages, you need something like cipher-block-chaining to encrypt arbitrarily large data.
562 2011-11-28 19:40:24 <sipa> roconnor: in the ElGamal encryption you need to convert your data to a group element
563 2011-11-28 19:40:38 <gmaxwell> I think it's inadvisable to let anything other than mostly-random-data near any asymmetric scheme. (e.g. there are awesome chosen ciphertext vulns in RSA).
564 2011-11-28 19:40:38 <sipa> i'm not sure how to convert bytes to a point on a curve
565 2011-11-28 19:41:24 <roconnor> sipa: g^m for a generator g and a (small) message m
566 2011-11-28 19:41:49 <sipa> roconnor: in a reversible way
567 2011-11-28 19:41:57 <roconnor> ah oops
568 2011-11-28 19:42:21 <sipa> i suppose putting the data in the x coordinate, and using key decompression to find y
569 2011-11-28 19:42:30 <roconnor> that would work half the time :)
570 2011-11-28 19:42:35 <sipa> how so?
571 2011-11-28 19:42:49 <sipa> define the conversion to always use even y
572 2011-11-28 19:42:50 <roconnor> not every x point has a y point on the curve
573 2011-11-28 19:42:57 <sipa> almost all do, no?
574 2011-11-28 19:43:04 <roconnor> only about half of them
575 2011-11-28 19:43:08 <roconnor> a little less than half
576 2011-11-28 19:43:08 <sipa> really?
577 2011-11-28 19:43:17 <roconnor> yep
578 2011-11-28 19:43:28 <sipa> you must be right
579 2011-11-28 19:43:29 <roconnor> the order of the curve is almost the size of the field
580 2011-11-28 19:43:36 <sipa> there are less than 2^256 valid points on the curve
581 2011-11-28 19:43:39 <roconnor> and every point on the curve has an opposite point
582 2011-11-28 19:44:03 <sipa> ok, fine
583 2011-11-28 19:44:15 <sipa> 255 bits go in the x coordinate, 1 bit in the y coordinate
584 2011-11-28 19:44:35 <roconnor> sipa: I've run key recovery on random inputs and it feels that about half the time I get no keys recovered
585 2011-11-28 19:44:54 <roconnor> sipa: ya, something like this will work I think
586 2011-11-28 19:45:15 <roconnor> maybe
587 2011-11-28 19:46:14 <sipa> anyway - EC isn't intended for bulk data compression :)
588 2011-11-28 19:47:05 <roconnor> also elgamal double the size of the data when encrypting
589 2011-11-28 19:47:08 <roconnor> *doubles
590 2011-11-28 19:47:22 <ThomasV> roconnor: care to have a look at http://www.google.fr/url?sa=t&rct=j&q=ecc%20encryption&source=web&cd=4&ved=0CEQQFjAD&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.116.215%26rep%3Drep1%26type%3Dpdf&ei=FunTTrXFNoGg-AbIxczhDg&usg=AFQjCNFotknd1BshlU1O3pR39H9Wg1D8SA&sig2=wf8K9de5N64Qjidpi4wljg&cad=rja
591 2011-11-28 19:48:18 <ThomasV> is it reasonable to use this method with CBC?
592 2011-11-28 19:49:20 <sipa> ThomasV: really - do not use EC for encryption
593 2011-11-28 19:49:40 <sipa> if you have a need for assymetric encryption of data, use ECDH to derive a shared key, and use that for AES
594 2011-11-28 19:49:49 <sipa> it's much faster and probably safer
595 2011-11-28 19:50:07 <roconnor> what sipa said
596 2011-11-28 19:50:17 <ThomasV> ok, but why?
597 2011-11-28 19:50:33 <ThomasV> what is wrong with it?
598 2011-11-28 19:50:38 <sipa> you can at most encrypt 256 bits of data per encryption
599 2011-11-28 19:50:51 <roconnor> and it is very slow
600 2011-11-28 19:51:08 <sipa> around a millisec for each 256-bit block
601 2011-11-28 19:51:35 <sipa> and it will expand your data
602 2011-11-28 19:52:09 <sipa> and you probably don't need the advantages of separate public/private keys, if you just derive them from a password
603 2011-11-28 19:52:39 <ThomasV> I know, but if I do that I don't need AES
604 2011-11-28 19:52:49 <sipa> it's not worth the effort
605 2011-11-28 19:53:08 <sipa> getting it to work right will be much much more work than just linking to a library that can do AES
606 2011-11-28 19:54:11 <ThomasV> sipa: in python installing the pycrypto library deters users. in contrast, I have a pure python implementation of ecdsa
607 2011-11-28 19:54:27 <ThomasV> that's the reason why
608 2011-11-28 19:54:38 <ThomasV> it would remove a dependency
609 2011-11-28 19:54:49 <sipa> ThomasV: http://code.google.com/p/slowaes/source/browse/trunk/python/aes.py
610 2011-11-28 19:55:17 <ThomasV> sipa: hey, I did not know that one. thanks!
611 2011-11-28 19:55:33 <sipa> that will probably still be massively faster than EC
612 2011-11-28 19:55:43 <roconnor> heh
613 2011-11-28 19:55:45 <roconnor> probably
614 2011-11-28 19:55:46 <ThomasV> yeah
615 2011-11-28 19:55:58 <ThomasV> I should have looked for that first
616 2011-11-28 19:56:07 <ThomasV> sorry for the trouble