1 2013-01-09 00:42:58 <gmaxwell> da2ce7: that would be a totally broken way to go about it, and also unnecessary.
  2 2013-01-09 00:43:44 <gmaxwell> da2ce7: as soon as there was one violation in bitcoin it would slowly taint all the coins so that they were in violation of your rule.
  3 2013-01-09 00:44:03 <gmaxwell> (because they were descendants of your violated rule.
  4 2013-01-09 00:44:05 <gmaxwell> )
  5 2013-01-09 00:44:25 <gmaxwell> And in any case, restrictions can be added to bitcoin, they just can't be removed.
  6 2013-01-09 00:44:50 <gmaxwell> We have a whole set of NOP instructions in script as well as block and transaction versions precisely for the purpose.
  7 2013-01-09 00:45:42 <MobGod> can anyone answer a question about the android app (wallet)
  8 2013-01-09 00:46:13 <MobGod> can i add more than one wallet to the app so i can transfer coin's act??? on the go
  9 2013-01-09 01:36:45 <zapsoda> Anyone used that JSONtoAmount function in PHP please msg me :)
 10 2013-01-09 01:37:59 <gmaxwell> I think you missed #bitcoin-mining and #bitcoin-otc  you might also want to ask in #hardware
 11 2013-01-09 01:38:19 <Luke-Jr> lol
 12 2013-01-09 01:39:04 <upb> hahahaha
 13 2013-01-09 01:49:01 <zapsoda> gmaxwell, I didnt miss OTC :p
 14 2013-01-09 01:49:49 <gmaxwell> Oh, and I suppose you got #hardware too?
 15 2013-01-09 01:50:54 <zapsoda> Ooops i missed them
 16 2013-01-09 04:04:07 <zapsoda> Does this look good for converting the satoshi into BTC? http://pastebin.com/ebQ2TEZC
 17 2013-01-09 04:40:31 <vazakl> http://csr.bu.edu/sns/
 18 2013-01-09 04:43:29 <gmaxwell> vazakl: the word 'attack' doesn't show up in their paper, not a great sign.
 19 2013-01-09 04:43:58 <zapsoda> Does this look good for converting the satoshi into BTC? http://pastebin.com/ebQ2TEZC
 20 2013-01-09 05:21:02 <vazakl> sup
 21 2013-01-09 05:25:02 <vazakl> oops wrong window
 22 2013-01-09 07:46:40 <chmod755> guys, can i use sendmany without the from-account?
 23 2013-01-09 10:49:13 <Dzia> Hello everyone. Maybe I`m thinking to lunch bitcoin exchange in Lithuania, someone maybe already runs exhangers and would willing to talk true with me?
 24 2013-01-09 11:44:23 <leotreasure> i'm going to build bitcoind for mac and i encountered this instruction: 2a. (for 10.7 Lion)
 25 2013-01-09 11:44:24 <leotreasure> Edit /opt/local/etc/macports/macports.conf and uncomment "build_arch i386"
 26 2013-01-09 11:44:34 <leotreasure> does this also apply for mountain lion?
 27 2013-01-09 12:16:50 <kinlo> I guess it does... it does make sense to build 64 bit only
 28 2013-01-09 12:17:11 <kinlo> why o why is most software still 32 bit :/
 29 2013-01-09 12:22:55 <UukGoblin> any rails users - UPGRADE NAO
 30 2013-01-09 12:52:08 <Luke-Jr> kinlo: I switched from 64-bit to 32-bit last year, despite having been an early adopter of 64-bit
 31 2013-01-09 13:18:05 <_dr> phew, what's an ETA on initial sync with the blockchain? two days? :(
 32 2013-01-09 13:18:33 <_dr> is the MB count on .bitcoin a good progress indicator?
 33 2013-01-09 13:18:54 <sipa> which version?
 34 2013-01-09 13:19:05 <MobPhone> _dr could take days
 35 2013-01-09 13:19:13 <_dr> 0.7.2 release
 36 2013-01-09 13:19:38 <MobPhone> took me days
 37 2013-01-09 13:19:50 <sipa> after block 193000, signature checks are enabled, so there it becomes slower
 38 2013-01-09 13:20:08 <MobPhone> _dr what block are you on
 39 2013-01-09 13:20:25 <_dr> ~78483 blocks remaining
 40 2013-01-09 13:20:57 <sipa> most of the delay before that is 1) crappy block fetching algorithm (sometimes it gets confused and stops doing anything for several minutes)  2) the database/verification engine does a massive amount of unnecessary I/O
 41 2013-01-09 13:20:59 <MobPhone> I believe that will take the longest
 42 2013-01-09 13:21:28 <sipa> 1) is improved by -connect='ing to a good peer
 43 2013-01-09 13:21:33 <sipa> 2) will be improved a lot in 0.8
 44 2013-01-09 13:21:45 <MobPhone> sipa did gmaxwell ever show you my log
 45 2013-01-09 13:21:56 <sipa> don't think so
 46 2013-01-09 13:21:59 <MobPhone> took me almost 5 days
 47 2013-01-09 13:22:16 <sipa> with 0.8 code?
 48 2013-01-09 13:22:18 <_dr> is there a release date in sight for 0.8 yet? i've lost track of bitcoin developments over the holidays :)
 49 2013-01-09 13:22:38 <sipa> _dr: a few weeks at least, i'd say
 50 2013-01-09 13:22:44 <sipa> maybe more
 51 2013-01-09 13:22:52 <_dr> doesn't sound too bad
 52 2013-01-09 13:23:09 <sipa> (no guarantees; there are still a few things to tackle)
 53 2013-01-09 13:27:29 <Luke-Jr> sipa: maybe you could mentor a GSoC student for HD wallet impl?
 54 2013-01-09 13:28:42 <petertodd> anyone have some testnet btc you could send? n3wNRtT8ieMwZ7HAwHEFYyx8KvtrJudrT3
 55 2013-01-09 13:29:11 <petertodd> oh, never mind, the testnet faucet finally sent me some
 56 2013-01-09 13:30:30 <sipa> Luke-Jr: maybe i'm naive, but i hope we have HD wallets merged before GSoC projects are supposed to start :)
 57 2013-01-09 13:30:59 <Luke-Jr> sipa: oh, great. I was worried you were overworked and had no time XD
 58 2013-01-09 13:32:14 <sipa> yes, that's why i'm perhaps naive :p
 59 2013-01-09 13:32:45 <sipa> (at least, the crypto code for BIP32 is already implemented, so the rest is integration with the wallet, and i already did that once)
 60 2013-01-09 16:02:29 <nanotube> gavinandresen: looks like gsoc has not yet even been announced for 2013. so i'll try to remember to keep my eye out for this year's announcement.
 61 2013-01-09 16:17:30 <gmaxwell> nanotube: if people want to make it successful, I suggest they start soon making a list of candidate applications and _qualification_ tasks. The ffmpeg/vlc/libav communities have had good success with qualification tasks, and I think we should probably use them too.
 62 2013-01-09 16:18:25 <gmaxwell> The idea is that before accepting a student (I initially typoed 'stupid') you make them do some small task that shows that they're (1) willing to do work, (2) can program and build the relevant software. This seems to have a surprisingly big effect.
 63 2013-01-09 16:19:04 <gmaxwell> Otherwise what you do is get a lot of people who sign up and vanish, or sign up and just get the first payment and vanish. (Something I've expirenced with xiph and wikimedia projects)
 64 2013-01-09 16:22:23 <gmaxwell> Having a bunch of stuff well setup is critical to getting accepted by google too.
 65 2013-01-09 16:23:21 <MC-Eeepc> good evening
 66 2013-01-09 16:23:47 <helo> were there any bitcoin gsoc projects last year?
 67 2013-01-09 16:23:51 <nanotube> gmaxwell: ah thanks for sharing your experience. i don't suppose you'd be willing to rough some stuff in? i don't really know anything about this, neither from the 'what gsoc-sized tasks need to be done for bitcoin' nor 'how to make them look good for google' ...
 68 2013-01-09 16:23:54 <nanotube> helo: no
 69 2013-01-09 16:24:30 <helo> will the foundation be paying the bounties?
 70 2013-01-09 16:25:29 <gmaxwell> nanotube: I'm a bit cycle limited, but I'll contribute to roughing stuff in if some other people want to. I can also throw up some pointers to approches which I've seen which have been successful.
 71 2013-01-09 16:25:29 <nanotube> dunno if any have been claimed
 72 2013-01-09 16:34:14 <BlueMatt> sipa: ping
 73 2013-01-09 16:34:50 <gmaxwell> gavinandresen: We might want to mediate on https://wiki.mozilla.org/Security_Severity_Ratings some... in particular, Mozilla doesn't consider "malicious content can use up all your memory" to be vulnerabilities.  Our situation is somewhat different, but it might give some more food for how we think about some of that DoS stuff.
 74 2013-01-09 16:42:13 <helo> we want the client to run all the time while using convenient amounts of resources
 75 2013-01-09 16:44:40 <gmaxwell> helo: sure. But we also don't want to send out OMG UPGRADE NOW FEAR FEAR FEAR for issues where an attacker can connect to you and slow down your node... simply because such attacks can't be prevented no matter what we do.
 76 2013-01-09 16:44:51 <gmaxwell> (an attacker could always exahaust your network pipe)
 77 2013-01-09 16:45:17 <gmaxwell> I can look at things and say "this isn't worth an alert" but I dunno how to articulate the exact criteria.
 78 2013-01-09 16:45:26 <Luke-Jr> gmaxwell: well, eating a ton of memory can be worse than that ;)
 79 2013-01-09 16:45:44 <Luke-Jr> gmaxwell: Linux systems crawl - for ALL apps - when swap is heavily used
 80 2013-01-09 16:46:05 <gmaxwell> Luke-Jr: Yea, well as I said, I don't know the exact criteria. Firefox doesn't consider using a ton of memory to be a sec-crit.
 81 2013-01-09 16:46:15 <Luke-Jr> gmaxwell: Firefox isn't a p2p application
 82 2013-01-09 16:46:26 <Luke-Jr> someone random can't just connect to Firefox and feed it data
 83 2013-01-09 16:46:28 <Luke-Jr> :P
 84 2013-01-09 16:46:45 <gmaxwell> Luke-Jr: p2p isn't the criteria, but perhaps inbound is.
 85 2013-01-09 16:47:12 <gmaxwell> (and the browsers are all becoming p2p to a degree with webrtc)
 86 2013-01-09 16:47:35 <Luke-Jr> O.o
 87 2013-01-09 16:47:57 <gmaxwell> Perhaps for non-listening nodes we should remember who we were connected to last, and if we crash, we blacklist them for 24 hours. Then run with ulimits and auto restart.
 88 2013-01-09 16:48:22 <gmaxwell> Then our behavior starts becoming more like a web browser and resource exaustion attacks cause less harm.
 89 2013-01-09 16:50:03 <gmaxwell> Luke-Jr: webrtc gives browsers a p2p SCTP in DTLS in UDP data path, with STUN/TURN firewall hole punching and ICE so that you can only send (lots of) packets to peers that consent to connct with you.  This will let them do all kinds of realtime peer to peer communication including chat and voice.
 90 2013-01-09 16:50:08 <gavinandresen> the best fix would be to limit the size of the memory pool, and evict transactions based on the same default criteria for deciding what transactions go into a block.
 91 2013-01-09 16:50:50 <gavinandresen> (best fix for this particular case... in general, limiting the size of your in-memory data structures is something we should continue doing)
 92 2013-01-09 16:51:12 <gmaxwell> gavinandresen: yea, I'm thinking more generally than this specific concern, since we keep finding peer resource exhastion attacks and it seems like we'll keep doing that. Culling the memory pool has some crappy implications because it'll create orphans.
 93 2013-01-09 16:51:21 <Luke-Jr> gavinandresen: even that, probably needs some thought - sounds liable to lose transactions entirely too easily
 94 2013-01-09 16:51:34 <gavinandresen> if they get lost they'll get re-sent.
 95 2013-01-09 16:51:49 <gmaxwell> gavinandresen: I'd also proposed (in PM) to sipa that we add a network rule: the maximum size of a transaction plus its input txouts is the maximum block size.
 96 2013-01-09 16:52:47 <gavinandresen> gmaxwell: that could easily be an IsStandard rule.
 97 2013-01-09 16:53:37 <gmaxwell> Yep. though if it's not a network rule a block violating it could still blow up a node. IsStandard would be a first step of course.
 98 2013-01-09 17:00:26 <gmaxwell> An IsStandard would at least prevent you from using high memory peers as bloat-transaction force multipliers.
 99 2013-01-09 17:19:09 <sipa> BlueMatt: pang
100 2013-01-09 17:22:13 <jgarzik> pung
101 2013-01-09 17:25:18 <BlueMatt> sipa: nvm, my question was pre-answered in a comment that i somehow missed....
102 2013-01-09 17:25:29 <sipa> eh, ok?
103 2013-01-09 18:17:22 <TD> BlueMatt: thanks
104 2013-01-09 18:17:27 <TD> will try the latest code tonight
105 2013-01-09 19:30:56 <BlueMatt> TD: I believe the only thing left i want to do is rework PeerGroup api stuff
106 2013-01-09 19:31:04 <BlueMatt> well, plus the new update flag
107 2013-01-09 19:32:01 <sipa> BlueMatt: how is the flag encoded?
108 2013-01-09 19:32:45 <BlueMatt> i would think throw it as a boolean in the bloom filter
109 2013-01-09 19:32:48 <BlueMatt> nFlags or something
110 2013-01-09 19:33:08 <BlueMatt> maybe just byteFlags
111 2013-01-09 19:33:37 <TD> sure
112 2013-01-09 19:33:46 <TD> BlueMatt: what api changes?
113 2013-01-09 19:33:58 <sipa> BlueMatt: sounds good
114 2013-01-09 19:34:31 <BlueMatt> TD: nothing, the serialized form of BloomFilter changes
115 2013-01-09 19:34:38 <BlueMatt> TD: oh, you mean PeerGroup
116 2013-01-09 19:34:39 <TD> yeah
117 2013-01-09 19:34:52 <BlueMatt> TD: I meant the changes to how to tell PeerGroup what fp rate to use
118 2013-01-09 19:34:58 <BlueMatt> (which needs tweaked with the new flag anyway)
119 2013-01-09 19:35:40 <TD> ah yes
120 2013-01-09 19:35:42 <TD> got it
121 2013-01-09 19:36:33 <Turingi> what are alternatives to proof-of-work in a bitcoin-like system?
122 2013-01-09 19:41:40 <gmaxwell> Turingi: there have basically been none suggested which are not strawman weak. The alternatives people suggest all suffer the common failing that if you don't expend something scarce when trying to produce a block then there is no system incentive to not concurrently attempt to be dishonest.
123 2013-01-09 19:50:25 <Turingi> I was thinking that given public availability of transactions, bitcoin may be acceptable to tax authorities
124 2013-01-09 19:50:44 <Turingi> since any coins you spend are traceable to some addresses
125 2013-01-09 19:51:07 <TD> by itself, obviously that's not enough
126 2013-01-09 19:51:13 <TD> because addresses aren't traceable to anything
127 2013-01-09 19:51:14 <Turingi> and whenever you try to exchange it for cash, or advertise one of your addresses
128 2013-01-09 19:51:19 <Turingi> you are traceable
129 2013-01-09 19:51:22 <TD> but you can build tax systems on top of bitcoin with some extensions
130 2013-01-09 19:51:55 <Turingi> people did some data mining with publicly available addresses (say on the bitcoin forum)
131 2013-01-09 19:51:58 <gmaxwell> Turingi: in the US the tax authorities have pretty much no care about serialized goods or the like. So I suspect that you're over thinking it.
132 2013-01-09 19:52:24 <Turingi> gmaxwell: serialized goods?
133 2013-01-09 19:52:27 <TD> yeah but if you're trying to dodge tax you obviously won't advertise your address
134 2013-01-09 19:53:13 <gmaxwell> (like most law enforcement they're generally to make it reactive instead of proactive and just make the penalties high enough that even with low odds of catching someone its still unwise to do)
135 2013-01-09 19:54:04 <TD> i think you could probably build a very accurate and efficient tax system on top of bitcoin, if one was so inclined
136 2013-01-09 19:54:48 <gmaxwell> Turingi: there is no pressure from tax authorities, generally, to register all transactions or to track all goods. They don't need to. They capture some information where it can be captured non-invasively, but its not a primary enforcement mechanism... presumably because its too easily evaded without a totalitarian state.
137 2013-01-09 19:55:29 <gmaxwell> TD: I'm pretty skeptical, but I think we're getting pretty far afield of technology there.
138 2013-01-09 19:55:29 <Turingi> most transactions in the west are via banks and all that is transparent to authorities
139 2013-01-09 19:55:30 <gmaxwell> TD: I'm pretty skeptical, but I think we're getting pretty far afield of technology there.
140 2013-01-09 19:55:30 <Turingi> most transactions in the west are via banks and all that is transparent to authorities
141 2013-01-09 19:55:45 <TD> Turingi: not quite as simple as it looks actually
142 2013-01-09 19:55:56 <Turingi> the point being, bitcoin is not necessarily an enemy of the financial system
143 2013-01-09 19:56:18 <TD> it's a different financial system, that's all. i don't think it needs to be anyone/anythings enemy
144 2013-01-09 19:56:19 <TD> it's a different financial system, that's all. i don't think it needs to be anyone/anythings enemy
145 2013-01-09 19:56:26 <gmaxwell> Turingi: not necessarily??  ... I think people who suggest that it is are confused in any case!
146 2013-01-09 19:56:53 <sipa> well it competes with certain parts of the existing financial system
147 2013-01-09 19:57:08 <sipa> but traditionally we consider competition a good thing :)
148 2013-01-09 19:57:26 <gmaxwell> It's just an alternative. Alternatives make the world richer and more adaptive.
149 2013-01-09 19:57:31 <gmaxwell> Right.
150 2013-01-09 19:57:46 <gmaxwell> (and currently, an almost irrelevantly obsecure alternative)
151 2013-01-09 19:57:55 <ThomasV> "we come in peace"
152 2013-01-09 19:58:12 <ThomasV> "and we will soon replace you"
153 2013-01-09 20:25:15 <helo> 
ACTION negates all claims in the license disclaimer, and uses it in his infinite loop brainfuck program

154 2013-01-09 20:25:16 <helo> 
ACTION negates all claims in the license disclaimer, and uses it in his infinite loop brainfuck program

155 2013-01-09 20:59:26 <grau> what was the longest time span without a block you recall ?
156 2013-01-09 21:04:34 <sipa> grau: before the difficulty increased for the first time, probably days (though i wasn't around to remember that)
157 2013-01-09 21:05:42 <sipa> there were 4 blocks that took more than a day, the last one being 16564
158 2013-01-09 21:05:43 <sipa> there were 4 blocks that took more than a day, the last one being 16564
159 2013-01-09 21:06:03 <grau> i am not regularly following just stumbled upon as I checked my server that there was not block since over an hour and am curious how often this happen, statistics or probability calculations somewhere ?
160 2013-01-09 21:06:04 <grau> i am not regularly following just stumbled upon as I checked my server that there was not block since over an hour and am curious how often this happen, statistics or probability calculations somewhere ?
161 2013-01-09 21:06:15 <gmaxwell> In modern times people have started to howl at 2 hours??? I'd try grepping my logs, but sometimes people howl about >2 hours when really they're looking a blockchain.info and blockchain.info is stuck.
162 2013-01-09 21:06:16 <gmaxwell> In modern times people have started to howl at 2 hours??? I'd try grepping my logs, but sometimes people howl about >2 hours when really they're looking a blockchain.info and blockchain.info is stuck.
163 2013-01-09 21:06:20 <sipa> ;;bc,tblb 2h
164 2013-01-09 21:06:21 <gribble> 1 year, 39 weeks, 5 days, 2 hours, 59 minutes, and 44 seconds
165 2013-01-09 21:06:22 <gribble> 1 year, 39 weeks, 5 days, 2 hours, 59 minutes, and 44 seconds
166 2013-01-09 21:06:42 <sipa> grau: ^ we expect a block that takes >2h once that often
167 2013-01-09 21:07:24 <sipa> 155290 took over 3h
168 2013-01-09 21:07:51 <gmaxwell> sipa: assuming the times on the blocks are right...
169 2013-01-09 21:07:53 <grau> makes weak case for point of sales :(
170 2013-01-09 21:07:54 <grau> makes weak case for point of sales :(
171 2013-01-09 21:08:07 <gmaxwell> (I know for example, luke has at least once produced a block awful close to two hours in the future.)
172 2013-01-09 21:08:08 <sipa> grau: point of sale shouldn't depend on block confirmations
173 2013-01-09 21:08:09 <sipa> grau: point of sale shouldn't depend on block confirmations
174 2013-01-09 21:08:19 <sipa> gmaxwell: yeah
175 2013-01-09 21:08:20 <sipa> gmaxwell: yeah
176 2013-01-09 21:08:36 <TD> 8 minutes 20 seconds to download all chain headers. sigh. need to implement partial chains and starting from checkpoints.
177 2013-01-09 21:08:37 <TD> 8 minutes 20 seconds to download all chain headers. sigh. need to implement partial chains and starting from checkpoints.
178 2013-01-09 21:09:21 <gmaxwell> jgarzik: didn't you have some insanly fast figures to pull all the headers?
179 2013-01-09 21:09:30 <MC-Eeepc> checkpoints suck
180 2013-01-09 21:09:31 <MC-Eeepc> checkpoints suck
181 2013-01-09 21:09:57 <gmaxwell> MC-Eeepc: you can always start from a checkpoint and pull the rest in the background. e.g. make it soft.
182 2013-01-09 21:09:59 <sipa> ;;bc,tblb 1h26m
183 2013-01-09 21:10:00 <gribble> Error: '1h26m' is not a valid argument.
184 2013-01-09 21:10:01 <gribble> Error: '1h26m' is not a valid argument.
185 2013-01-09 21:10:02 <sipa> ;;bc,tblb 1h 26m
186 2013-01-09 21:10:03 <sipa> ;;bc,tblb 1h 26m
187 2013-01-09 21:10:04 <gribble> 3 weeks, 4 days, 13 hours, 27 minutes, and 3 seconds
188 2013-01-09 21:10:14 <TD> well, 8m was off some random network peer
189 2013-01-09 21:10:18 <TD> i'm sure it's less if i pull from localhost
190 2013-01-09 21:10:19 <TD> i'm sure it's less if i pull from localhost
191 2013-01-09 21:10:20 <MC-Eeepc> would suck less
192 2013-01-09 21:10:49 <gmaxwell> sipa: can headers requests be satisfied entirely out of the index in ultraprune?
193 2013-01-09 21:10:59 <MC-Eeepc> ever since i learned about checkpoints though it always seemed like cheating
194 2013-01-09 21:11:00 <MC-Eeepc> ever since i learned about checkpoints though it always seemed like cheating
195 2013-01-09 21:11:03 <sipa> gmaxwell: out of RAM, even
196 2013-01-09 21:11:10 <TD> the code assumes all headers are in a hashmap
197 2013-01-09 21:11:11 <TD> the code assumes all headers are in a hashmap
198 2013-01-09 21:11:25 <jgarzik> gmaxwell: they are fast; no good numbers though
199 2013-01-09 21:11:29 <jgarzik> out of RAM, as sipa notes
200 2013-01-09 21:11:30 <jgarzik> out of RAM, as sipa notes
201 2013-01-09 21:11:31 <gmaxwell> dur.
202 2013-01-09 21:11:45 <sipa> well, i should say: out of main memory
203 2013-01-09 21:11:46 <sipa> well, i should say: out of main memory
204 2013-01-09 21:11:53 <grau> TD: try being eager. My node potentially uses all pers to download in parallel
205 2013-01-09 21:12:04 <sipa> the fact that it is backed by physical RAM pages isn't guaranteed :)
206 2013-01-09 21:12:19 <gmaxwell> yea yea, blonde moment.
207 2013-01-09 21:12:34 <TD> well, you can download in parallel but you still have to connect and verify serially
208 2013-01-09 21:12:43 <TD> the real solution is to not sync from the genesis block. it doesn't scale.
209 2013-01-09 21:12:44 <gmaxwell> dunno why some peer would be so slow.
210 2013-01-09 21:12:44 <TD> the real solution is to not sync from the genesis block. it doesn't scale.
211 2013-01-09 21:13:02 <grau> but chain heads only validate POW thats fast
212 2013-01-09 21:13:03 <grau> but chain heads only validate POW thats fast
213 2013-01-09 21:13:30 <jgarzik> 'getheaders' is nice, too, because the answer comes in a large message, rather than a bunch of messages with no terminator
214 2013-01-09 21:13:32 <gmaxwell> TD: it's 40 megabytes for 10 years of headers. "does not scale" .. well actually it's scales perfectly linearly with time.
215 2013-01-09 21:13:33 <gmaxwell> TD: it's 40 megabytes for 10 years of headers. "does not scale" .. well actually it's scales perfectly linearly with time.
216 2013-01-09 21:14:01 <sipa> gmaxwell: but but... 40 megabytes is the size of my first hard drive!
217 2013-01-09 21:14:04 <TD> that's what i mean
218 2013-01-09 21:14:05 <TD> that's what i mean
219 2013-01-09 21:14:17 <jgarzik> a Lego Mindstorms v3 only has 16MB RAM
220 2013-01-09 21:14:38 <sipa> TD: there are things is bitcoin that scale much worse :)
221 2013-01-09 21:14:53 <TD> grau: you have to commit them to disk as well
222 2013-01-09 21:14:54 <TD> grau: you have to commit them to disk as well
223 2013-01-09 21:14:55 <gmaxwell> Not that pulling from a checkpoint is objectionable, but please don't exaggerate it. I predict there will be no point in which the headers grows slower than your device ram, storage, or operating system size. :P
224 2013-01-09 21:15:06 <TD> anyway, i haven't profiled. it's not a big deal.
225 2013-01-09 21:15:07 <TD> anyway, i haven't profiled. it's not a big deal.
226 2013-01-09 21:15:28 <sipa> the reference client still starts up in seconds
227 2013-01-09 21:15:29 <gmaxwell> er s/slower/faster/ dunno why I get the sign of these things wrong.
228 2013-01-09 21:15:38 <sipa> and it validates PoW of the entire chain at startup
229 2013-01-09 21:16:16 <grau> writing to disk is async you do not realy care
230 2013-01-09 21:16:17 <grau> writing to disk is async you do not realy care
231 2013-01-09 21:16:31 <grau> at download
232 2013-01-09 21:16:32 <grau> at download
233 2013-01-09 21:16:38 <sipa> you can't do it entirely async if you want consistency guarantees
234 2013-01-09 21:16:39 <sipa> you can't do it entirely async if you want consistency guarantees
235 2013-01-09 21:16:49 <sipa> but for a few megabytes, nobody cares :)
236 2013-01-09 21:16:50 <sipa> but for a few megabytes, nobody cares :)
237 2013-01-09 21:17:06 <gmaxwell> TD: I mean my point is that because it is linear with respect to time, the cost releative to avilable resources should be shrinking. This is good scalablity.
238 2013-01-09 21:17:23 <jgarzik> 
ACTION was thinking about a non-storing mode of brd ("block relay daemon", in picocoin.git, uses libccoin) that downloads 100% of headers over network at startup

239 2013-01-09 21:17:24 <jgarzik> 
ACTION was thinking about a non-storing mode of brd ("block relay daemon", in picocoin.git, uses libccoin) that downloads 100% of headers over network at startup

240 2013-01-09 21:17:25 <grau> I store the chain I download with leveld that writes asyn, I use the batch func of it to garantee its atomic
241 2013-01-09 21:17:40 <grau> if I loose a full block I do not care download again
242 2013-01-09 21:17:41 <grau> if I loose a full block I do not care download again
243 2013-01-09 21:18:00 <sipa> grau: right, if that is your only storage you're fine
244 2013-01-09 21:18:01 <sipa> grau: right, if that is your only storage you're fine
245 2013-01-09 21:18:09 <grau> it is
246 2013-01-09 21:18:10 <grau> it is
247 2013-01-09 21:18:22 <sipa> you store block data also in leveldb?
248 2013-01-09 21:18:28 <sipa> the actual transactions, i mean
249 2013-01-09 21:18:39 <grau> everithyng
250 2013-01-09 21:18:53 <grau> everything i mean
251 2013-01-09 21:18:59 <sipa> hmm, ok
252 2013-01-09 21:19:00 <sipa> hmm, ok
253 2013-01-09 21:19:11 <grau> its convinient and fast
254 2013-01-09 21:19:12 <grau> its convinient and fast
255 2013-01-09 21:19:13 <sipa> i experimented with that (in BDB, though...) and it was extremely slow
256 2013-01-09 21:19:23 <sipa> it sure is convenient
257 2013-01-09 21:19:52 <jgarzik> leveldb definitely beats BDB if build up ~200k+ of atomic data, to be written in one batch
258 2013-01-09 21:19:53 <jgarzik> leveldb definitely beats BDB if build up ~200k+ of atomic data, to be written in one batch
259 2013-01-09 21:20:11 <grau> I use the wire format as data and the hash extended with type as key
260 2013-01-09 21:20:13 <gmaxwell> jgarzik: an intresting variation would be for BRD to only fetch headers for the first block it gets given from the network. "Oh, you're gonna give me a block? fine. Prove it connects"
261 2013-01-09 21:20:13 <jgarzik> *if you