1 2013-02-06 00:09:16 <wood_quinn> jgarzik: Should there be a new torrent for 210,000 or 216,116 (for 0.8.0)?
  2 2013-02-06 00:49:05 <MC1984> strange checkpoint
  3 2013-02-06 00:53:48 <wood_quinn> There's about a thousand or so orphaned blocks around 40K hehe.
  4 2013-02-06 00:55:00 <MC1984> ??
  5 2013-02-06 00:56:40 <gmaxwell> wood_quinn: yes??? though where'd you find them?
  6 2013-02-06 00:56:48 <gmaxwell> wood_quinn: you won't get copies of them on a newly started node.
  7 2013-02-06 00:57:52 <MC1984> how on eath do you orphan a thousand blocks
  8 2013-02-06 00:57:59 <MC1984> sounds like some shenanigans
  9 2013-02-06 00:58:27 <wood_quinn> I could be wrong.
 10 2013-02-06 00:58:50 <wood_quinn> I just know my client was importing about 5K blocks every two minutes, and at 40K it stopped for about four.
 11 2013-02-06 00:59:10 <wood_quinn> I looked at the debug log and saw a steady stream of nothing but orphan blocks and assumed that was why.
 12 2013-02-06 01:03:13 <wood_quinn> Looks like there are about 926 in a row somewhere in there.
 13 2013-02-06 01:05:15 <gmaxwell> wood_quinn: ah what you're seeing there is just out of order fetching, it's not actually orphaned blocks.
 14 2013-02-06 01:06:02 <jgarzik> wood_quinn: yes, there should be a new torrent with new checkpoints
 15 2013-02-06 01:06:03 <wood_quinn> Oh ok.
 16 2013-02-06 01:06:18 <gmaxwell> but there was a big fork created back around height 77k or so.
 17 2013-02-06 01:06:19 <jgarzik> wood_quinn: however, no release bitcoin version would be able to import it, due to file length bugs in 0.7.x
 18 2013-02-06 01:06:32 <wood_quinn> jgarzik: Ah.
 19 2013-02-06 01:07:01 <jgarzik> wood_quinn: 0.7.x currently fails to import 5% or so of current bootstrap.dat, iirc.  upcoming version 0.8 fixes this issue.
 20 2013-02-06 01:08:31 <wood_quinn> Perhpas that's the reason for the odd checkpoint.
 21 2013-02-06 01:09:13 <jgarzik> wood_quinn: what odd checkpoint?
 22 2013-02-06 01:09:32 <wood_quinn> 216,116
 23 2013-02-06 01:14:06 <Luke-Jr> wood_quinn: checkpoints are pretty arbitrary
 24 2013-02-06 01:14:16 <Luke-Jr> and numbers ending in 6 are even
 25 2013-02-06 01:14:25 <wood_quinn> Heh.
 26 2013-02-06 01:14:35 <MC1984> im gonna assume thats a tonal troll
 27 2013-02-06 01:14:46 <Luke-Jr> it holds true for decimal as well
 28 2013-02-06 01:14:48 <MC1984> you could have atleast made it a palindrome instead
 29 2013-02-06 01:14:56 <MC1984> 216612
 30 2013-02-06 01:15:12 <wood_quinn> I'm still waiting for the 666 blockchain dump.
 31 2013-02-06 01:16:54 <wood_quinn> 
ACTION waves

 32 2013-02-06 01:25:34 <CodeShark> jgarzik: been a little busy, haven't had a chance to finish that autotools thing...but if you have a few moments I'd like to see if we can make some progress
 33 2013-02-06 01:26:30 <CodeShark> Luke-Jr: I could also use your help :)
 34 2013-02-06 01:27:21 <Luke-Jr> CodeShark: ?
 35 2013-02-06 01:27:45 <CodeShark> ok, so the latest autotools stuff I've done is here: https://github.com/CodeShark/bitcoin/tree/autotools/src
 36 2013-02-06 01:27:52 <CodeShark> what happens if you try to run the configure file?
 37 2013-02-06 01:29:38 <Luke-Jr> CodeShark: the configure script itself isn't supposed to be in the git, but that can be cleaned up later I guess
 38 2013-02-06 01:30:03 <CodeShark> why not?
 39 2013-02-06 01:30:18 <Luke-Jr> it's generated
 40 2013-02-06 01:30:29 <gmaxwell> 0_o
 41 2013-02-06 01:30:32 <CodeShark> assuming someone clones the repo in order to install bitcoind, shouldn't they be able to just run the configure file?
 42 2013-02-06 01:30:37 <gmaxwell> Same reason you don't put the binaries in git.
 43 2013-02-06 01:30:42 <gmaxwell> CodeShark: no.
 44 2013-02-06 01:30:43 <Luke-Jr> and right now, I'd have 11,628 lines of code to review before I can safely run it :P
 45 2013-02-06 01:30:57 <Luke-Jr> CodeShark: nope
 46 2013-02-06 01:31:22 <CodeShark> so if someone wants to install it from the repo, they have to run autoconf themselves?
 47 2013-02-06 01:31:35 <Luke-Jr> (also, we aren't using GPLv3)
 48 2013-02-06 01:31:47 <Luke-Jr> CodeShark: yes, git repos are for developers who know what they're doign
 49 2013-02-06 01:32:21 <Luke-Jr> CodeShark: do I ignore the configure shell script outside src/?
 50 2013-02-06 01:32:35 <CodeShark> O
 51 2013-02-06 01:32:47 <CodeShark> I'm only focused on the /src stuff for now
 52 2013-02-06 01:33:46 <Luke-Jr> k, down to 1400 LOC, will look over and try it
 53 2013-02-06 01:35:09 <CodeShark> so if the configure file is not included in the repo, what's the format for users who want to compile it themselves? just a tarball?
 54 2013-02-06 01:35:22 <Luke-Jr> CodeShark: usually
 55 2013-02-06 01:37:35 <Luke-Jr> CodeShark: your src/leveldb/Makefile has some important bugfixes reverted
 56 2013-02-06 01:38:13 <CodeShark> I'll have to rebase later - but right now I'm just interested in getting the configure script to work
 57 2013-02-06 01:39:29 <Luke-Jr> ./configure: line 5447: syntax error near unexpected token `;;'
 58 2013-02-06 01:39:38 <CodeShark> ok, same thing is happening to me
 59 2013-02-06 01:39:51 <CodeShark> different line number
 60 2013-02-06 01:39:56 <CodeShark> 5427
 61 2013-02-06 01:40:11 <CodeShark> but you used your own autotools to generate the configure file, yes?
 62 2013-02-06 01:40:38 <Luke-Jr> yes
 63 2013-02-06 01:40:46 <Luke-Jr> also, autoconf 2.69 doesn't like it at all
 64 2013-02-06 01:40:57 <Luke-Jr> it wants leveldb to have a Makefile.in :P
 65 2013-02-06 01:44:24 <CodeShark> but that can't be what's causing the script error
 66 2013-02-06 01:44:40 <Luke-Jr> right, two separate issues
 67 2013-02-06 01:45:59 <CodeShark> I just did a rebase
 68 2013-02-06 01:47:28 <MC1984> bdq3 came though
 69 2013-02-06 01:49:44 <CodeShark> I don't even see where that case statement begins
 70 2013-02-06 01:49:55 <CodeShark> I see on line 5428 an esac
 71 2013-02-06 01:50:01 <CodeShark> but where does the case statement begin?
 72 2013-02-06 01:50:23 <CodeShark> the nearest case before that line is on line 4717
 73 2013-02-06 01:50:59 <CodeShark> is that a bug in autoconf? or is that a bug in one of the macros?
 74 2013-02-06 01:51:11 <andytoshi> it's a feature
 75 2013-02-06 01:51:13 <CodeShark> haha
 76 2013-02-06 01:51:46 <Luke-Jr> CodeShark: bug in the boost stuff afaik
 77 2013-02-06 01:55:21 <CodeShark> I commented out AX_BOOST_THREAD([1.42.1]) in configure.ac and that error went away
 78 2013-02-06 01:59:24 <jgarzik> CodeShark: pretty busy with baby bedtime, I'll review scrollback after a while :)
 79 2013-02-06 02:00:09 <CodeShark> jgarzik: baby bedtime is more important :)
 80 2013-02-06 02:08:39 <CodeShark> should I just get rid of those AX macros and use AC_CHECK_LIB and AC_CHECK_HEADERS instead?
 81 2013-02-06 02:08:49 <Luke-Jr> dunno
 82 2013-02-06 02:10:17 <CodeShark> seems like I might have better luck
 83 2013-02-06 02:10:23 <CodeShark> at least it reduces the number of places things can break
 84 2013-02-06 02:12:13 <Luke-Jr> if you do something even slightly wrong with autoconf, it explodes.
 85 2013-02-06 02:12:26 <CodeShark> yeah, so I've been noticinf
 86 2013-02-06 02:12:28 <CodeShark> yeah, so I've been noticing
 87 2013-02-06 02:13:05 <CodeShark> it's such a hideous hack. it's unfortunate it works at all since it would be nice to have it replaced once and for all :)
 88 2013-02-06 02:14:30 <CodeShark> I commented out lines like AX_BOOST_SYSTEM([1.46.1]) and replaced them with lines like AC_CHECK_LIB(boost_system,main,,AC_MSG_ERROR([boost_system library not found. Please install it.]))
 89 2013-02-06 02:14:31 <gribble> Error: "AC_MSG_ERROR" is not a valid command.
 90 2013-02-06 02:14:46 <CodeShark> lol - did I just confuse gribble?
 91 2013-02-06 02:16:05 <Luke-Jr> CodeShark: https://bitcointalk.org/?topic=141502
 92 2013-02-06 02:17:22 <CodeShark> :)
 93 2013-02-06 03:09:53 <isitreal> Hi there, may I ask what you use for blockchain data analyzing? I've used blockexplorer query a little. Any other tools like abe?
 94 2013-02-06 03:11:17 <CodeShark> I've built some of my own tools but haven't published all the source yet
 95 2013-02-06 03:11:27 <CodeShark> http://blockhawk.net/bitcoin/blocks
 96 2013-02-06 03:12:01 <moore_> I have done some useful stuff with blockparser https://github.com/znort987/blockparser
 97 2013-02-06 03:13:42 <gmaxwell> isitreal: using bitcoin itself is pretty reasonable for many things.
 98 2013-02-06 03:17:29 <CodeShark> as nice as it would be to have one single app that does everything, the requirements for a streamlined validation/relay engine and for a historical analysis tool are quite different
 99 2013-02-06 03:18:16 <gmaxwell> CodeShark: sorry, I can't hear your abstract philosophizing over the furious roar of doing things pratically. :P
100 2013-02-06 03:19:01 <gmaxwell> Trying to manually parse the blockchain data has it's own weaknesses. It can make sense for some things, but not for others. In particular, it requires you to not get thrown by orphan blocks.
101 2013-02-06 03:19:20 <gmaxwell> If the data can be extracted from the rpc without trouble thats probably a safer and simpler way to go about it.
102 2013-02-06 03:19:44 <CodeShark> thrown by orphan blocks? how is that relevant?
103 2013-02-06 03:19:48 <gmaxwell> I'm not aware of anything available from blockexplorer that you can't get via the rpc much faster and more reliably, except for index by address.
104 2013-02-06 03:20:49 <CodeShark> are you referring to moore_'s parser, gmaxwell?
105 2013-02-06 03:21:01 <moore_> with blockparcer I can run computations over the hole block chain in a few minutes
106 2013-02-06 03:21:08 <gmaxwell> CodeShark: they're in the blockchain files, any tool hoping to analize the chain has to be smart enough to find them and handle them (e.g. ignore them) or you'll get crazy results like concluding more coins exist than permitted or that txn have been double spent in the chain.
107 2013-02-06 03:21:09 <moore_> I did not write it
108 2013-02-06 03:21:25 <moore_> just modified it for my use
109 2013-02-06 03:21:38 <CodeShark> gmaxwell, for historical analysis it is preferable to build separate tables with appropriate indices
110 2013-02-06 03:21:38 <gmaxwell> CodeShark: I'm not referring to any particular tool.
111 2013-02-06 03:22:34 <CodeShark> in the process of constructing said tables, the block tree becomes a prominent structure
112 2013-02-06 03:22:44 <CodeShark> in which it is easy to prune branches
113 2013-02-06 03:22:55 <CodeShark> and to ignore nonconnected blocks
114 2013-02-06 03:22:56 <gmaxwell> CodeShark: sure??? depends on what you are doing. If you just want to know the content of blocks??? for example??? you can quite easily  pull them  out of transactions.  And you can get this right without having a sophicated understanding of bitcoin.
115 2013-02-06 03:25:04 <gmaxwell> "first you need to create a database that can model the blockchain, and the you need reimplement enough of the concensus algorithim to immitate its decisions" ... isn't a very pratical answer if someone wants to??? say??? find out how many fees are in the last 10000 blocks.  It may be a very pratical answer for something else.
116 2013-02-06 03:25:06 <isitreal_> sry my browser crashed and then os hang...anyways pity I didn't catch the name of developer for http://blockhawk.net/bitcoin/blocks.php
117 2013-02-06 03:25:51 <CodeShark> are you interested in using it for something, isitreal_?
118 2013-02-06 03:27:19 <isitreal_> yeah. first thing in mind is to track one transaction (follow the coins)
119 2013-02-06 03:27:33 <CodeShark> I'm looking to package it more nicely and publish the source code in the not-too-distant-future
120 2013-02-06 03:28:01 <isitreal_> may I ask if you built the database with abe?
121 2013-02-06 03:28:12 <CodeShark> no, I'm using my own stuff
122 2013-02-06 03:28:36 <isitreal_> cool. all php?
123 2013-02-06 03:28:48 <CodeShark> no, the php is just for rendering the web views
124 2013-02-06 03:29:02 <CodeShark> the daemon itself is C++
125 2013-02-06 03:29:24 <CodeShark> the daemon connects to the p2p network, grabs blocks and transactions, and sticks them into an SQL database
126 2013-02-06 03:29:49 <isitreal_> guess faster than python (abe), and also incremental
127 2013-02-06 03:30:17 <CodeShark> and doesn't rely on a locally running instance of bitcoind nor the internal data file formats at all
128 2013-02-06 03:30:25 <moore_> isitreal_ blockparser has a taint tool built in allready
129 2013-02-06 03:31:06 <CodeShark> can connect to any validation node
130 2013-02-06 03:32:32 <isitreal_> btw do you keep all the blockchain data locally?
131 2013-02-06 03:33:49 <isitreal_> moore_ thanks for the blockparser
132 2013-02-06 03:34:21 <moore_> if you don't have tons of memory you need to switch it to use sparse maps
133 2013-02-06 03:34:40 <CodeShark> it builds an SQL database containing the entire block chain, isitreal_...separate and independent from the data files produced by bitcoind
134 2013-02-06 03:34:47 <moore_> which is dose it a #define
135 2013-02-06 03:35:03 <moore_> done with that is
136 2013-02-06 03:35:45 <isitreal_> CodeShark thanks for the clarification
137 2013-02-06 03:35:58 <CodeShark> it's not optimized for space
138 2013-02-06 03:36:20 <isitreal_> moore_ I see. Thanks for the note.
139 2013-02-06 03:36:55 <isitreal_> Well as far as it doesn't explode to TB then fine with me :)
140 2013-02-06 03:37:24 <isitreal_> CodeShark you are talking about your method or blockparser?
141 2013-02-06 03:37:30 <CodeShark> mine
142 2013-02-06 03:37:37 <isitreal_> OK
143 2013-02-06 03:39:26 <CodeShark> isitreal_: right now the entire SQL database is in the tens of GB
144 2013-02-06 03:40:18 <isitreal_> I think abe outputs similar.
145 2013-02-06 03:40:49 <CodeShark> the schema isn't too unlike abe - but the major difference is that abe parses the block chain files generated by bitcoind
146 2013-02-06 03:41:27 <CodeShark> and abe doesn't handle mempool stuff
147 2013-02-06 03:42:28 <isitreal_> excuse me but what's the difference between files generated by bitcoind and those pulled from p2p network?
148 2013-02-06 03:42:38 <isitreal_> latter is more real-time?
149 2013-02-06 03:42:46 <CodeShark> the p2p network only deals with bitcoin messages
150 2013-02-06 03:43:09 <CodeShark> these things: https://en.bitcoin.it/wiki/Protocol_specification
151 2013-02-06 03:43:36 <moore_> Hmm I should build you a better DB CodeShark
152 2013-02-06 03:43:54 <CodeShark> if you'd like I'm fully open to that, moore_ :)
153 2013-02-06 03:43:56 <moore_> ( I my copious free time )
154 2013-02-06 03:44:15 <moore_> I will get around to it at some point
155 2013-02-06 03:44:18 <CodeShark> I've also entertained the possibility of ditching SQL, perhaps looking into graph databases or other interesting structures
156 2013-02-06 03:44:58 <weex> if one wanted to have an sql database of transactions which way would you all go?
157 2013-02-06 03:45:01 <moore_> It is my hobby and profession to write DBs some times
158 2013-02-06 03:45:10 <moore_> I have a almost really easy to use tool chain
159 2013-02-06 03:45:54 <moore_> I just need to implement a few things... I will probably have it all in place this year
160 2013-02-06 03:47:41 <weex> i basically don't want to mess with the setup much but would like to run some queries
161 2013-02-06 03:48:22 <isitreal_> weex we were talking about this and https://github.com/znort987/blockparser was mentioned
162 2013-02-06 03:48:35 <isitreal_> not sure if you want to setup the database at all
163 2013-02-06 03:49:10 <weex> i guess i'd prefer to operate from the files bitcoind already has and i have no prob with mysql
164 2013-02-06 03:49:14 <moore_> on my laptop with a SSD that code is amazingly fast
165 2013-02-06 03:49:30 <weex> so you connect it to a running bitcoind to get the blocks?
166 2013-02-06 03:49:41 <isitreal_> moore_ you mean blockparser? or your own tool chain?
167 2013-02-06 03:49:51 <moore_> blockparser
168 2013-02-06 03:50:02 <isitreal_> good to know
169 2013-02-06 03:50:09 <moore_> it is easy to modify too
170 2013-02-06 03:50:20 <moore_> I used it to look for week keys in the block chain
171 2013-02-06 03:51:22 <isitreal_> "week keys"?
172 2013-02-06 03:51:27 <weex> weak keys
173 2013-02-06 03:51:32 <weex> like a dictionary attack would find
174 2013-02-06 03:51:36 <moore_> no
175 2013-02-06 03:51:48 <isitreal_> lol
176 2013-02-06 03:52:16 <moore_> keys where k had been repeated in a signature and you could solve for the private key
177 2013-02-06 03:54:48 <isitreal_> moore_ would you enlighten me what's that for?
178 2013-02-06 03:55:43 <weex> i most certainly wouldn't understand
179 2013-02-06 03:55:47 <weex> but it sounds cool
180 2013-02-06 03:55:49 <moore_> https://plus.google.com/106313804833283549032/posts/X1TvcxNhMWz
181 2013-02-06 03:56:18 <moore_> it tuned out that tcatm beat me to it
182 2013-02-06 03:57:29 <isitreal_> weex besides parsing from the block files generated by bitcoind you can also pull data from p2p network (only deals with bitcoin messages) -- just learnt from CodeShark
183 2013-02-06 03:58:02 <weex> i've used pynode but i'm interested in some light statistics
184 2013-02-06 03:58:07 <CodeShark> that's how bitcoind gets its data, isitreal_ :p
185 2013-02-06 03:58:17 <weex> like what is the most common transaction amount
186 2013-02-06 03:58:21 <weex> or what is their distributino
187 2013-02-06 03:58:53 <weex> not hard to do for a few blocks with a little scraping but that's no fun really
188 2013-02-06 04:01:57 <CodeShark> I'm looking to opensource the entire project in the not-too-distant-future
189 2013-02-06 04:02:14 <isitreal_> Looking forward!
190 2013-02-06 04:04:50 <amiller> gmaxwell, sipa, i have finally worked out a general form for merkle-things!!
191 2013-02-06 04:04:57 <amiller> https://gist.github.com/amiller/4715508
192 2013-02-06 04:05:29 <amiller> i have basically been at this since last may
193 2013-02-06 04:06:00 <amiller> 
ACTION flips out

194 2013-02-06 04:06:18 <moore_> congratulations
195 2013-02-06 04:06:18 <weex> wb amiller
196 2013-02-06 04:06:50 <amiller> it's a generalization of a merkle tree
197 2013-02-06 04:06:52 <moore_> wish I knew haskel better
198 2013-02-06 04:06:59 <amiller> take any operation, like a lookup in a balanced search tree
199 2013-02-06 04:07:28 <amiller> i can automatically transform it into two versions - one is the Prover, it produces a sequence of just the local data (including hashes for the children) of any node it visits
200 2013-02-06 04:07:54 <amiller> the second is a Verifier - it consumes a stream of node data, simulating the original operation, and rejecting it if the data doesn't match the hashes it already has
201 2013-02-06 04:08:53 <amiller> for the sake of a proper proof, i also have a third version Extract where basically if you give it any proof object, and the original data structure, then it either gives the right result or a hash collision
202 2013-02-06 04:09:23 <amiller> so fooling the verifier is just as hard as finding a hash collision
203 2013-02-06 04:10:46 <amiller> this works for any regular datatype defined as a fixpoint of a functor, which applies to the existing block chain and tx merkle trees, as well as all the flip-the-chain proposals
204 2013-02-06 04:13:40 <andytoshi> amiller: do you have an article or something which describes this?
205 2013-02-06 04:13:50 <andytoshi> i doubt you can explain your project in IRC
206 2013-02-06 04:14:00 <andytoshi> 
ACTION follows the link..

207 2013-02-06 04:14:01 <amiller> that doesn't usually stop me from trying
208 2013-02-06 04:14:05 <andytoshi> :)
209 2013-02-06 04:14:51 <amiller> this was my first writeup about it https://bitcointalk.org/index.php?topic=101734.0
210 2013-02-06 04:16:06 <andytoshi> thanks, i bookmarked that
211 2013-02-06 04:16:07 <amiller> i made an implementation in python but it was impossible to convince anyone it works, so i had to learn about category theory and haskell and coq and stuff
212 2013-02-06 04:16:12 <andytoshi> i'm too tired and haskell-rusty to follow it now
213 2013-02-06 04:16:28 <andytoshi> sadly, i'm okay with the category theory
214 2013-02-06 04:16:41 <amiller> :)
215 2013-02-06 04:24:37 <jgarzik> 
ACTION wonders if 5.199.170.24 is a pool or relay

216 2013-02-06 04:24:47 <jgarzik> it shows up on those beloved blockchain.info stats
217 2013-02-06 04:25:56 <gmaxwell> amiller: Very cool!
218 2013-02-06 04:26:50 <gmaxwell> amiller: are many pre-existing data structures defined in a way suitable for your code?
219 2013-02-06 04:27:31 <amiller> yes, pretty much any data structure that can be described
220 2013-02-06 04:28:15 <gmaxwell> amiller: how the heck does a merkleized lookup (e.g. hash) table do an update?  do you end up with a proof for the update that is O(N)?
221 2013-02-06 04:28:23 <amiller> well, excluding ones like an array or a hash table or an array :/
222 2013-02-06 04:28:36 <amiller> s/an array//
223 2013-02-06 04:29:26 <amiller> skip lists are okay, tries are too
224 2013-02-06 04:29:42 <gmaxwell> okay. right. How about a skiplist which is randomized?
225 2013-02-06 04:29:55 <amiller> randomization is fine
226 2013-02-06 04:30:13 <amiller> you'd have to keep track of the seed and all
227 2013-02-06 04:32:10 <gmaxwell> What is the clear expression of the criteria that makes something like an array not work while a balanced tree works?  (I know intutively what will owkrk or not, I suppose, but I don't have a clear statement of it)
228 2013-02-06 04:32:35 <amiller> now that i have studied the intricate theory of datatypes, i can safely say that
229 2013-02-06 04:32:54 <amiller> the criteria that makes it work is if the datatype is expressible as the fixpoint of a functor
230 2013-02-06 04:33:20 <amiller> "inductively defined" is maybe clear enough
231 2013-02-06 04:34:24 <amiller> i think that things like arrays are considered "indexed datatypes"
232 2013-02-06 04:34:56 <andytoshi> 
ACTION is quite overwhelmed

233 2013-02-06 04:35:14 <andytoshi> how long does it take to learn the theory of datatypes? does "fixpoint of a functor" mean something concrete to you?
234 2013-02-06 04:35:27 <andytoshi> there are a lot of functors in the world..
235 2013-02-06 04:35:53 <gmaxwell> amiller: ! there you go "inductively defined"  is surpurbly clear to me!
236 2013-02-06 04:36:02 <amiller> (it's an ongoing process for me to match up my intuition with this weird set of academic theory, but the payoff is being able to put this in a proof-checker language, roconnor is my target audience)
237 2013-02-06 04:37:41 <andytoshi> do you happen to be anywhere near austin tx or vancouver bc?
238 2013-02-06 04:37:49 <amiller> heh, no
239 2013-02-06 04:38:11 <gmaxwell> well your work is fully paid off in my mind???  I don't know how long it would have taken me to realize that the key criteria for being able to do this is that it needs to have a (possibly branching and irreglar) recursive expression. There are LOTS of neat things you can express that way.
240 2013-02-06 04:43:13 <amiller> thanks! i'll take that
241 2013-02-06 04:53:07 <andytoshi> while i've got a dead channel, has anyone here done an interview with cambridge university?
242 2013-02-06 04:53:38 <andytoshi> i have one tomorrow morning to discuss my entry into an analysis PhD program
243 2013-02-06 04:56:39 <CodeShark> good luck :)
244 2013-02-06 04:57:09 <andytoshi> thx CodeShark, i'm pretty nervous
245 2013-02-06 04:57:58 <CodeShark> do you know the interviewer?
246 2013-02-06 04:58:22 <andytoshi> i know of her
247 2013-02-06 04:58:47 <andytoshi> she is friends with one of my professors
248 2013-02-06 04:59:32 <CodeShark> good, well then make sure to maintain a good relationship with said professor and just go in relaxed :)
249 2013-02-06 05:24:47 <gmaxwell> amiller: If you're interested in an application for Merkle Monads outside of bitcoin??? one thing that comes to mind for me is tor directory authorities.  Tor nodes need to download big directories before they can securely choose their own paths. Esp as the tor network grows I expect the the data needed for this may impede users who need tor the most (e.g. freedom constraints come with bandwidth constraints)
250 2013-02-06 05:25:11 <amiller> hmmm
251 2013-02-06 05:25:51 <gmaxwell> amiller: so making the required query operations, on a list of nodes??? which probably involves a prefix trie query for eligible IP blocks.. and perhaps even something to return securely random subsets might be interesting.
252 2013-02-06 05:25:55 <amiller> that's highly interesting to me - tahoe-lafs is the other project that i think will like using it to enable their new mutable file type
253 2013-02-06 05:26:11 <amiller> mm securely random subsets would work great
254 2013-02-06 05:27:09 <amiller> that would use the same basic technique as my plinko proof-of-work puzzle
255 2013-02-06 05:27:41 <amiller> which just relies on being able to annotate the tree with a 'total number of elements to the left and right'
256 2013-02-06 05:29:04 <gmaxwell> so yea, I think with a couple of basic operations you could make it so that a tor node could securely pick paths without first downloading the full directory.  It would just get signatures of the directory hash roots from the network, then have helpful peers perform queries for it.
257 2013-02-06 05:29:50 <amiller> that's outstanding, that would work just fine
258 2013-02-06 05:29:54 <amiller> they already use merkle trees, just the static kind
259 2013-02-06 05:30:03 <gmaxwell> amiller: here is another idea I had for merkleized data structures:
260 2013-02-06 05:30:15 <amiller> before you say anything else i just want to point out the git already basically supports this and no one uses it
261 2013-02-06 05:30:31 <amiller> you can retrieve a single source file from a big directory just by using the 'commit' without having to download the whole re;po
262 2013-02-06 05:31:34 <amiller> so i could probably make modified git commands that would interpret existing git datastructures this way, and you could then use ordinary scripts or whatever to keep the file system organized
263 2013-02-06 05:31:47 <amiller> ok rsume
264 2013-02-06 05:33:40 <gmaxwell> amiller: you know how you do a secure coinflip e.g. each party transmits Xn where Xn = H(Sn) to commit and then you hash the Sn? You can use merkleized
265 2013-02-06 05:33:43 <gmaxwell> datastructures to commit to performing computation correctly before you know what you're going to perform. For example, the node location swaps in freenet.
266 2013-02-06 05:33:46 <gmaxwell> E.g. you might do something trecherous but to know how to be trecherous you need to know the query first. So in those cases it's not important that
267 2013-02-06 05:33:49 <gmaxwell> the peer know the root from a trusted source, instead you're just precommitting to do whatever computation you will do.
268 2013-02-06 05:35:01 <amiller> whoa
269 2013-02-06 05:35:10 <amiller> i don't think i've quite thought of that...
270 2013-02-06 05:35:25 <amiller> i have been thinking about how to express computations/closures inside an authenticated data structure
271 2013-02-06 05:35:41 <amiller> it doesn't even matter if you try to express non-terminating loops
272 2013-02-06 05:36:13 <amiller> as long as they can make constant-resource incremental progress... people can take turns spinning the wheel
273 2013-02-06 05:36:22 <gmaxwell> (A more contrived example would be in playing a game with a small decision tree, you could precommit to your strategy before you start playing,
274 2013-02-06 05:36:25 <gmaxwell> and prove you followed it??? without actually transmitting the whole strategy)
275 2013-02-06 05:36:35 <amiller> right!
276 2013-02-06 05:36:39 <amiller> especially if your whole strategy is like an unfolded lookup table
277 2013-02-06 05:36:45 <amiller> that's awesome
278 2013-02-06 05:37:39 <amiller> you can do like partial evaluation
279 2013-02-06 05:39:02 <gmaxwell> I don't know how the root can be computed with partial evaluation, ??? but I feel like there could be some interesting zero knoweldge proofs that coluld be easier to express under this model.
280 2013-02-06 05:40:53 <amiller> yeah so
281 2013-02-06 05:41:02 <amiller> in other news, i have currently infiltrated a theoretical cryptography lab
282 2013-02-06 05:41:12 <amiller> it's great, everyone is bonkers for bitcoin already
283 2013-02-06 05:41:27 <bonks> Especially me
284 2013-02-06 05:42:13 <gmaxwell> bonks: do you highlight on 'bonk'? :)
285 2013-02-06 05:42:16 <amiller> it's interesting because the theory people have complately moved way in front as far as these things go
286 2013-02-06 05:42:42 <amiller> the red black merkle tree is 20 years old as far as they're concerned!
287 2013-02-06 05:43:02 <amiller> it's theoretically possible to do _super efficient_ authenticated data structures for all sorts of things
288 2013-02-06 05:43:22 <amiller> you need to use fancy hash functions based on lattices and scary math structures like multilinear maps
289 2013-02-06 05:43:23 <bonks> gmaxwell: Yes :P
290 2013-02-06 05:43:42 <amiller> and yet even all of THESE feature weird ad hoc merkle tree structures everywhere
291 2013-02-06 05:43:45 <gmaxwell> amiller: Does it not bothere these people that the set of practical implementations of these pretty little crystals of cryptography are members of the empty set?  Or are they content to prove things possible and move on? :P
292 2013-02-06 05:44:38 <amiller> i think they just haven't embraced the curry-howard isomorphism yet
293 2013-02-06 05:44:56 <amiller> i'm trying to simplify the implementation of these things and at the same time simplify the proofs
294 2013-02-06 05:45:07 <amiller> i think as far as they're concerned, the reason there aren't more implementations is that it's not super hyper optimal yet
295 2013-02-06 05:45:37 <amiller> rather than the simpler explanation which is that their proofs are too complicated to evaluate or formalize further
296 2013-02-06 05:45:37 <gmaxwell> 0_o  the funny thing is that being a huge order of magnitude from optimal is totally not the issue for most applications.
297 2013-02-06 05:45:50 <amiller> nonetheless, they're open minded about things like theorem prover languages
298 2013-02-06 05:46:04 <amiller> the Crypto 2011 best paper award went to a project update about some proof framework in coq
299 2013-02-06 05:46:30 <amiller> meanwhile the Programmning Language theory people are trying to look to the well-funded crypto world for interesting applications
300 2013-02-06 05:46:31 <gmaxwell> Pratical engineering considerations like "isn't trivially dos attackable" and "has an easy UI" dominate. ... but heck, we don't even have _toy grade_ implementations of lots of this stuff.
301 2013-02-06 05:46:45 <amiller> and they start themselves off by trying to model the wacky hash functions
302 2013-02-06 05:46:50 <amiller> and more complicated protocols
303 2013-02-06 05:47:24 <amiller> so all this hash graph stuff is just ridiculous low hanging fruit.... that will taste delicious to both species
304 2013-02-06 05:47:41 <gmaxwell> e.g. if I want to do a secure sealed bid action in #otc  ... nope. no software for it. Don't even care if it has to transmit 10 mb data per bid.. no tools exist. Not even crashy easily jammed up memory hungry python ones.
305 2013-02-06 05:48:16 <pre2> hello, i just had a quick question out of curiosity
306 2013-02-06 05:49:05 <gmaxwell> pre2: we're awaiting your question.
307 2013-02-06 05:49:40 <pre2> why does the bitcoin-qt store the blockchain in 3 separate .dat files, where it seems to create a new file every 2048 MB?
308 2013-02-06 05:49:56 <pre2> I notice in my roaming folder a blk0001.dat, blk0002.dat, and blk0003.dat
309 2013-02-06 05:50:02 <pre2> why not consolidate to one file?
310 2013-02-06 05:50:11 <gmaxwell> pre2: to avoid problems on operating systems that have issues seeking in files >2GiB.
311 2013-02-06 05:50:41 <gmaxwell> having fewer files doesn't improve anything in any case (at least not once you're past each file being many megabytes in size)
312 2013-02-06 05:51:53 <pre2> So is there an estimate for ultimately how many blk files will be created, after the last bitcoins are generated? or the chain would continue to grow forever as new transactions are incurred?
313 2013-02-06 05:52:06 <Luke-Jr> pre2: forever and ever
314 2013-02-06 05:52:07 <gmaxwell> pre2: The latter.
315 2013-02-06 05:52:20 <CodeShark> the block chain will continue to grow perpetually at the rate of about one block every 10 minutes (assuming bitcoin doesn't break)
316 2013-02-06 05:53:29 <pre2> If BTC continues to grow in popularity, I've noticed block sizes growing generally larger and larger with more transactions per block... If it continues to grow in perpetuity, could this theoretically cause a storage space problem in the future?
317 2013-02-06 05:53:47 <pre2> Although it's almost certain HDD space will outpace BTC block growth
318 2013-02-06 05:54:22 <MC1984> they dont seem minded to lift the cap so max is 144mb/day
319 2013-02-06 05:54:42 <pre2> Oh, I was unaware there was a cap.
320 2013-02-06 05:55:04 <pre2> Alright well thank you for answering my questions :]
321 2013-02-06 06:01:31 <MC1984> its 1mb per block and theres currently some sort of soft limit to like half that
322 2013-02-06 06:02:50 <MC1984> if they lift the cap, bitcoin loses a bit of magic for various reasons and will probably never have a working fees market
323 2013-02-06 06:03:16 <gmaxwell> Who is they?
324 2013-02-06 06:03:30 <MC1984> if they dont, bitcoin might not grow
325 2013-02-06 06:03:34 <gmaxwell> It's the same people who can change the supply of bitcoin from 21 million to 42 million.
326 2013-02-06 06:04:18 <MC1984> realistically it would be the dev team/foundation that would orchestrate such a thing
327 2013-02-06 06:04:33 <MC1984> of course its up to the users as always
328 2013-02-06 06:04:52 <MC1984> as if most of them wouldnt just go along with it though
329 2013-02-06 06:06:51 <gmaxwell> Do you think they'd go along with changing the supply of coins?  I don't.  And I do not think it's obvious that they'd go along with changing the block size limit unless it was very clear why Bitcoin would still be a viable decenteralized system after doing so. (required clearness depending on how urgent increasing the size seemed??? if there was always 4MB of fee paying txn pending, then I suppose an increase to 2MB wouldn't be ...
330 2013-02-06 06:06:57 <gmaxwell> ... terribly controversial)
331 2013-02-06 06:07:49 <petertodd> People forget that increasing the blocksize limit isn't just a problem in terms of total chain size, it's a problem in terms of bandwidth. A few KiB/s average is easy to manage on all sorts of connections, a few MiB/s not so much.
332 2013-02-06 06:08:07 <petertodd> Right now we can effectively run full nodes behind tor, 1GiB blocks won't allow that anymore.
333 2013-02-06 06:09:33 <MC1984> i like to think i take more of an interest in where bitcoin is going than the average user
334 2013-02-06 06:09:59 <MC1984> ive heard good arguments from both sides and i still dont know where i stand on the issue of the block cap
335 2013-02-06 06:10:00 <gmaxwell> Yes, there are two main and totally distinct issues with blocksize: We _must_ have transaction fees to pay for security, and a scarcity produced market for fees is a clear and philosophically compatible way to get them.  ... and the other issue is if handling and validating blocks is very expensive then Bitcoin will not be pratically decenteralized.
336 2013-02-06 06:10:15 <MC1984> i think most really would just install an update that removed the limit
337 2013-02-06 06:10:26 <MC1984> the miners/pools would prob be more engaged
338 2013-02-06 06:10:42 <petertodd> Or worse, an update that allowed for a floating limit, thinking it'd float to a reasonable amount magically...
339 2013-02-06 06:10:56 <MC1984> ^
340 2013-02-06 06:11:13 <MC1984> i have no idea i some sort of floating limit would be workable or not get gamed
341 2013-02-06 06:11:13 <petertodd> And miners/pools have incentives for as big blocks as possible, because it damages their competition. (the ones with fast net connections anyway)
342 2013-02-06 06:11:15 <gmaxwell> petertodd: or off a satellite, or over HF radio.
343 2013-02-06 06:11:27 <petertodd> gmaxwell: cloud bounce, carrier pigeon
344 2013-02-06 06:11:53 <petertodd> ...and carrier pigeon would actually be a *viable* way of transmitting the blockchain!
345 2013-02-06 06:12:02 <SomeoneWeird> on an ssd!
346 2013-02-06 06:12:03 <SomeoneWeird> lol
347 2013-02-06 06:12:16 <gmaxwell> Gavin is basically avocating the "it'd float to a reasonable amount magically" and I cannot fathom why he believes that would work... but I think I need more data before I can say more than I have an absence of evidence to suggest to me that it would work.
348 2013-02-06 06:12:33 <petertodd> SomeoneWeird: well, admittedly ssd's make GiB blocks viable with carrier pigeon. :P
349 2013-02-06 06:12:37 <MC1984> what would a floating limit even be tied to
350 2013-02-06 06:12:45 <petertodd> Gavin seems to think block verification time.
351 2013-02-06 06:12:49 <SomeoneWeird> lol
352 2013-02-06 06:13:04 <MC1984> and could that be done in a way that wouldnt amount to a poliy desicion by you guys
353 2013-02-06 06:13:15 <petertodd> But I figure fast miners with solid net connections would use that as an outright weapon - each round up the block size and watch as your tor-connected competition drops out.
354 2013-02-06 06:13:16 <SomeoneWeird> someone needs to upload a very compressed version of the blockchain
355 2013-02-06 06:13:32 <petertodd> Remember that large blocks make the orphan rate go up very fast if you are on a slow connection.
356 2013-02-06 06:14:10 <MC1984> still maybe 1mb blocks will become very silly in a few years
357 2013-02-06 06:14:21 <gmaxwell> I do see how a number of different obviously bad outcomes could regulate the size??? e.g. blockchain external miner collusion. But that seems very risky, as its a twisty road that basically means that access to the chain will be governed by a cartel with potentially opaque rules.  And maybe thats a natural endpoint for the system, but it's not one I embrace because I believe it would remove a lot of the value from the system.
358 2013-02-06 06:14:29 <MC1984> even more so in light of 10 minutes of propagtion time
359 2013-02-06 06:15:17 <MC1984> umm thats pretty nightmarish
360 2013-02-06 06:15:18 <gmaxwell> MC1984: shorter interblock times calls for smaller blocks, in fact. (well perhaps not smaller than 1MB but the general trend is that the more time you have the bigger the blocks can be before the system stops converging)
361 2013-02-06 06:15:40 <MC1984> thats what i meant
362 2013-02-06 06:16:03 <MC1984> blocks so small the system converges in seconds worldwide
363 2013-02-06 06:16:30 <petertodd> Ultimately, Bitcoin currently scales by O(n) for the individual node, O(n^2) resources for all nodes. Scaling like that is deadly, so why not do everything you can to keep the n small?
364 2013-02-06 06:16:31 <MC1984> ie to not make the 10 min blockrate a total waste, perhaps the size will have to increase somehow
365 2013-02-06 06:16:56 <petertodd> MC1984: Well, seconds is problematic, speed of light and all...
366 2013-02-06 06:17:22 <MC1984> well far less than 10minutes at any rte
367 2013-02-06 06:17:53 <gmaxwell> petertodd: Right now a lot of people haven't yet really accepted how great off chain transactions could be. They see them as a bandaid if they even realize they could exist at all. And so those people take it as axiomatic that the blocksize must go up.
368 2013-02-06 06:18:11 <MC1984> im one of those ppl tbh
369 2013-02-06 06:18:23 <MC1984> it seems a shame
370 2013-02-06 06:18:38 <gmaxwell> There is a lot of conflating of bitcoin as a currency vs bitcoin as a payment network, esp as bitcoin is compared to paypal to a lot of newbies.
371 2013-02-06 06:19:09 <MC1984> the promise was tht it was both, transparently
372 2013-02-06 06:19:25 <pre2> how would an offchain transaction work?
373 2013-02-06 06:19:33 <pre2> sorry if this is not the place for that.
374 2013-02-06 06:19:44 <pre2> i was just reading this discussion... it's fascinating
375 2013-02-06 06:19:47 <petertodd> MC1984: So, the earth is 40,000km in circumference, 20,000km optimal route. That's 66mS minimum lag, and real-world networks can probably triple that. For P2Pool that represents a 2% unavoidable orphan rate, for anyone on the wrong side of the planet.
376 2013-02-06 06:20:09 <gmaxwell> pre2: there are many different ways to accomplish them??? and they are _widely_ used today, though in a centernalized form.
377 2013-02-06 06:20:10 <petertodd> gmaxwell: Yeah, my promotions of the concept have both been terrible, and done terribly.
378 2013-02-06 06:20:25 <gmaxwell> pre2: e.g. mtgox internal transfers are a kind of off-chain bitcoin transaction.
379 2013-02-06 06:20:54 <pre2> Would mixing be a form of offchain?
380 2013-02-06 06:20:58 <MC1984> except gox can freeze your stuff i they want
381 2013-02-06 06:21:01 <gmaxwell> petertodd: people aren't going to get it until its built. I've manged to fail several times now at explaining what you've proposed.
382 2013-02-06 06:21:02 <petertodd> gmaxwell: Speaking of, I don't know if you saw it, but I wrote up fidelity bonds in detail: https://github.com/petertodd/trustbits/blob/master/fidelitybond.md
383 2013-02-06 06:21:15 <gmaxwell> MC1984: Sure, petertodd has a proposal that solves all that.
384 2013-02-06 06:21:34 <petertodd> gmaxwell: People aren't going to get it *when* it's built, but they'll see it magically works and not care, just like Bitcoin itself...
385 2013-02-06 06:21:38 <MC1984> if there was a way to do off chain tx, but without authorites, and using the chain to bookkeep
386 2013-02-06 06:21:41 <gmaxwell> (there are, in fact, several ways??? but I'm fond of the stuff petertodd has een talking about)
387 2013-02-06 06:21:56 <MC1984> that would be interesting
388 2013-02-06 06:22:40 <petertodd> MC1984: Well, there's sort of a triangle problem with payment networks, you can't have no authorities without publically announcing every tx, but you can bootstrap trust by making anonymous identities expensive to get.
389 2013-02-06 06:23:04 <gmaxwell> MC1984: what petertodd proposed gets you this:  A bank (which might be a group of mutually untrusting systems) comes into existance by creating an expensive bond.
390 2013-02-06 06:23:27 <gmaxwell> MC1984: everyone can see how much deposits the bank has and the value of the bond??? and so no deposit in excess of the bond are permitted.
391 2013-02-06 06:23:44 <petertodd> 
ACTION watches to see if gmaxwell fails to explain it for the n+1 time...

392 2013-02-06 06:24:31 <gmaxwell> Then the bank converts the bitcoins deposited to anonymous tokens. Anyone can go to the bank and anonymously exchange these tokens ... the bank can't deny service because it can't tell the users apart. The bank's only function is to keep the number of tokens matched to the amount of deposited coin.
393 2013-02-06 06:25:09 <gmaxwell> All of the exchanges of tokens between people are totally anonymous and privacy??? far more private than bitcoin transactions.. and result in no blockchain traffic.
394 2013-02-06 06:25:35 <gmaxwell> If the bank cheats ??? e.g. by issuing too many tokens, it can be proven to everyone and that proof destroys the value of their expensive bond.
395 2013-02-06 06:26:01 <gmaxwell> When you get tired of holding tokens you can exchange then back for bitcoins from the bank. (and again, if the bank won't let you withdraw, that can kill the bond too)
396 2013-02-06 06:26:23 <MC1984> but we already know the feds prints money an nobody cares
397 2013-02-06 06:26:45 <gmaxwell> MC1984: all the security for this would be baked into the software??? just like the rules for bitcoin are baked into the software.
398 2013-02-06 06:27:29 <gmaxwell> When I say proof I don't mean that one person tells another.. I mean the software does it: just like a block with the wrong subsidy is orphaned, a bank that cheats is shut down by the network.
399 2013-02-06 06:28:38 <MC1984> what if the govt shuts down the bank because its mainly used by terrorists or some shit
400 2013-02-06 06:28:59 <MC1984> i mean what if this bank entity becomes indisposed somehow
401 2013-02-06 06:29:02 <gmaxwell> It is fundimentally less secure than bitcoin itself. But it is incomprehensibly more scalable, and it is substantially more private. It's scalable in a way that bitcoin could never be no matter how big you make the blocks.
402 2013-02-06 06:30:08 <gmaxwell> MC1984: a couple points: an indealized implementation would have the bank really be a majority of N seperate computers.. it would be hard to shut down. You also wouldn't just have one of these but a great many??? they're easy to create, so low value in shutting down.
403 2013-02-06 06:30:39 <petertodd> gmaxwell: MC1984's point made me think of something... If the bank creates a fake signed token, there is no way for the recipient to know if it is or isn't backed by any funds other than getting lucky and seeing two tokens. The idea needs an audit log of issued tokens so you could check your token ID against the ones issued.
404 2013-02-06 06:30:59 <gmaxwell> I have a vague proposal that with some minor (softforking) improvements to bitcoin we might be able to make it possible for bitcoin to help facilitate recovery of funds from a bank that vanished.
405 2013-02-06 06:31:13 <petertodd> gmaxwell: I never published it, but I had an earlier idea that would put the hash of such an audit log linked to every tx the bank made.
406 2013-02-06 06:31:18 <petertodd> (that is, on blockchain tx)
407 2013-02-06 06:31:28 <gmaxwell> petertodd: good, because that audit log (needs to be a hash tree) is what you need to do chain based recovery of a shutdown bank. :P
408 2013-02-06 06:31:37 <petertodd> gmaxwell: I seem to have forgotten about that point... was a few months ago...
409 2013-02-06 06:32:01 <MC1984> i suppose right now to get a similar level of privay you have to send your coins off to god knows where iver tor anyway
410 2013-02-06 06:32:13 <petertodd> gmaxwell: Yeah... I was also thinking, for shutdown, all you really need to do is publish signatures for all the outstanding tokens, provided that the tokens are partial unsigned scripts. (likely without txins)
411 2013-02-06 06:32:35 <gmaxwell> MC1984: not even then: with bitcoin you can't hide that a transaction _happened_ unless it's e.g. entirely internal to mtgox or the like.
412 2013-02-06 06:32:41 <petertodd> gmaxwell: There is the ugly issue that many tokens could be effectively unredeemable though if blockchain tx's get expensive enough.
413 2013-02-06 06:33:25 <gmaxwell> petertodd: I have a proposal that mostly solves that too.. but it's kinda complicated and I don't know how well it fits with the bitcoin security model.
414 2013-02-06 06:33:32 <MC1984> just feels like bitcoin loses a bit more of its innocence all the time
415 2013-02-06 06:33:40 <petertodd> MC1984: Ultimately all real forms of privavy in Bitcoin involve turning the value of your Bitcoins into something off-chain, like an entry in EasyWallet's trusted books, and then turning them back into on-chain value. (real bitcoins)
416 2013-02-06 06:33:43 <MC1984> remember when most people thought it was completely anonymous
417 2013-02-06 06:33:56 <Luke-Jr> never?
418 2013-02-06 06:34:15 <MC1984> bitcoin.org stated it was anonymous in the beginnign
419 2013-02-06 06:34:17 <petertodd> gmaxwell: The redemption via merkle tree something proof idea?
420 2013-02-06 06:34:21 <gmaxwell> MC1984: Everything has compromises.  I'm much more confident about the compromises involved in having off chain transaction??? we _must_ have them in order to have instant transactions and other features??? than we'd get from trying to scale by bloating blocks forever.
421 2013-02-06 06:34:45 <gmaxwell> MC1984: I dunno when people thought that, I certantly didn't! :P
422 2013-02-06 06:34:45 <petertodd> gmaxwell: (reminds me, I was also thinking a "signature of a signed chaum token" opcode would be nice, or really, opcodes for ECC math in general as has been proposed)
423 2013-02-06 06:35:30 <petertodd> MC1984: Keep in mind that Moores law is just an observation...
424 2013-02-06 06:35:58 <MC1984> im not averse to the idea of externalities anymore, like most things in life if it seems to good to be true.....
425 2013-02-06 06:36:11 <gmaxwell> petertodd: https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas < see pruned history.  enormous scriptsigs (E.g. for chaum redeems) would be less of an issue if they only had SPV security once they were a few blocks deep.
426 2013-02-06 06:36:24 <MC1984> but that doesnt mean its totally useless or anything
427 2013-02-06 06:36:29 <MC1984> if i thought that id be selling lol
428 2013-02-06 06:37:24 <MC1984> mintchip said they could do it somehow, scalable anonymous digital tx
429 2013-02-06 06:37:39 <MC1984> but instead of whatever or whoever was backing that, the blockchain?
430 2013-02-06 06:37:45 <MC1984> mite b cool
431 2013-02-06 06:38:01 <petertodd> MC1984: mint chip relies on trusted hardward, IE central authority.
432 2013-02-06 06:38:25 <MC1984> oh
433 2013-02-06 06:38:49 <petertodd> MC1984: also, "Mintchip is designed to track you - http://news.slashdot.org/comments.pl?sid=3051283&cid=41008501 " <- rather interesting post on slashdot by a guy claiming to be an anon insider...
434 2013-02-06 06:39:43 <MC1984> you know it seems like OSS, which isnt very old as a movement, has been mainly building moduals of code for otehr future projects to plug together to make really useful stuff
435 2013-02-06 06:40:04 <MC1984> indeed bitcoin is a result of this process too, along with a lot of original thought
436 2013-02-06 06:40:12 <petertodd> gmaxwell: Pruning history like that seems reasonable enough... although I'd rather see it in an alt-chain, and keep Bitcoin as the gold standard of security. Some of the quantum crypto-resistant algo's would need such pruning too of course.
437 2013-02-06 06:40:21 <MC1984> i thought bitcoin was an end product, bu maybe its a module instead?
438 2013-02-06 06:40:49 <petertodd> Absolutely, even the blockchain itself and the PoW it represents is a very useful module on its own with merge-mining.
439 2013-02-06 06:40:51 <MC1984> and some future project will take it as a component and make something crazy cool that will take over the planet
440 2013-02-06 06:41:07 <Luke-Jr> MC1984: open source is as old as computers are
441 2013-02-06 06:41:16 <gmaxwell> petertodd: yea I mention that. I don't know what the tradeoff is those.. if we can only have chaum redeem or lamport if we have that? whats better? dunno.
442 2013-02-06 06:41:28 <Luke-Jr> MC1984: closed source is more recently popular
443 2013-02-06 06:42:00 <MC1984> well, the OSS infrastucture, associated licences etc
444 2013-02-06 06:42:16 <Luke-Jr> oh, I'd say mature then :P
445 2013-02-06 06:42:21 <MC1984> that enable rapid and fluid iterations and derivation
446 2013-02-06 06:42:51 <MC1984> i thought the OSS movement only really got rolling sometime in the 80s
447 2013-02-06 06:43:25 <gribble> The operation succeeded.
448 2013-02-06 06:43:25 <sipa> ;;later tell gavinandresen #2277 is wrong - this is exactly what CVR was about, to avoid marking a chain invalid if connection fails because of disk/database errors
449 2013-02-06 06:43:27 <andytoshi> MC1984: oss was the default before the 80's
450 2013-02-06 06:43:27 <petertodd> OSS as a *legal* movement, sure, but in spirit, right from when computers were in academia
451 2013-02-06 06:43:40 <andytoshi> proprietary software wasn't really a thing, so nobody thought about it
452 2013-02-06 06:44:09 <MC1984> oh wait lots of bsd and unix stuff is from the 70s innit
453 2013-02-06 06:44:23 <petertodd> yes, but in the 70's it wasn't open source licenses
454 2013-02-06 06:44:26 <sipa> ;;later trll gavinandreses if there is nondeterministic behaviour, it means a .Invalid or .DoS is missing
455 2013-02-06 06:44:28 <gribble> Error: The "Later" plugin is loaded, but there is no command named "trll" in it.  Try "list Later" to see the commands in the "Later" plugin.
456 2013-02-06 06:44:47 <MC1984> thats what i mean, the licence infrastructure
457 2013-02-06 06:45:24 <petertodd> ah, yeah, well GPLv1 was 1989
458 2013-02-06 06:46:17 <MC1984> i cant beleive linux didnt get rolling untill like 1996
459 2013-02-06 06:46:36 <MC1984> like, i fucking remember 1996 for christ sake
460 2013-02-06 06:47:13 <petertodd> Heh, and it still took me three more years to get my first copy of it.
461 2013-02-06 06:47:16 <MC1984> ilove how if you have a truly good idea, it can take over the world in short order
462 2013-02-06 06:47:31 <Luke-Jr> not always. just look at Tonal.
463 2013-02-06 06:47:35 <petertodd> well... "short" takes a few years at least.
464 2013-02-06 06:48:06 <petertodd> Tonal might not be a good *enough* idea...
465 2013-02-06 06:48:13 <MC1984> tonal is not taking over the world ergo its not a good idea :P
466 2013-02-06 06:48:54 <CodeShark> A => B does not imply B => A
467 2013-02-06 06:49:05 <Luke-Jr> MC1984: well, it doesn't help that governments force people to use decimal/SI :p
468 2013-02-06 06:49:22 <CodeShark> but it does imply !B => !A :)
469 2013-02-06 06:49:55 <MC1984> >implying implications
470 2013-02-06 06:51:03 <Luke-Jr> 
ACTION implies MC1984.

471 2013-02-06 06:54:09 <petertodd> So, I'm curious, is someone running a bunch of EC2 testnet nodes out there? Because the logs for my seeder show requests from what seem to be Amazon's EC2 DNS servers basically every few minutes, implying at least that often there are requests. This has been going on even before the pull req was accepted.
472 2013-02-06 06:56:02 <petertodd> (that or someone is checking to see if I can run it competently...)
473 2013-02-06 07:03:50 <gmaxwell> ;;later tell gavinandresen <sipa> if there is nondeterministic behaviour, it means a .Invalid or .DoS is missing
474 2013-02-06 07:03:52 <gribble> The operation succeeded.
475 2013-02-06 07:04:04 <gmaxwell> sipa: I did point that out to him earlier.
476 2013-02-06 07:07:33 <gmaxwell> MC1984: another point about your comment on someone shutting down a token bank: in many ways the token banks are more shutdown resistant than bitcoin itself: there can be many (wack a mole), they can be hidden (only the users must know about them, bitcoin is globally visible), they do not require conspicious energy usage (like mining) or constant global communication,  ... and unlike miners the banks, or unlike bitcoin users, can't deny ...
477 2013-02-06 07:07:39 <gmaxwell> ... transactions selectively (e.g. 'tainted coins', breaking fungability)
478 2013-02-06 07:08:30 <MC1984> tor token bank?
479 2013-02-06 07:09:22 <gmaxwell> Sure absolutely??? that would sanely be the default way of connecting to them... otherwise they're not fully private.
480 2013-02-06 07:09:31 <petertodd> tor is a must for token bank stuff so you can redeem your chaum coins without linking.
481 2013-02-06 07:09:37 <MC1984> what about
482 2013-02-06 07:09:55 <petertodd> (the other option being give the tokens to someone else as payment for something)
483 2013-02-06 07:10:09 <MC1984> when these token banks are widespread and everyone uses them and chain tx fees are ball breaking
484 2013-02-06 07:10:42 <MC1984> and i decide i inally want to cash in my modest bitcoins and buy a small island in the tropic of cancer
485 2013-02-06 07:10:42 <petertodd> That's exactly what I'm hoping to see happen.
486 2013-02-06 07:11:12 <petertodd> ...then spend give the bitcoins/tokens to someone in exchange for an island?
487 2013-02-06 07:11:26 <MC1984> i find the block fees just to get my coins to the bank wipe out my BTC holdings
488 2013-02-06 07:12:11 <petertodd> Yes, but that's the interesting thing about off-chain txs: they reduce tx fees for everyone by reducing pressure on blockchain space.
489 2013-02-06 07:12:38 <petertodd> It's also a flaw of the token bank and fidelity bonds stuff, because we might find that miners try to fight the systems...
490 2013-02-06 07:13:02 <gmaxwell> But for token<->token, you take an old unblinded token (he's never seen it before, so it's not linked) and he signs a new blinded token (and never sees that again).
491 2013-02-06 07:13:02 <gmaxwell> petertodd: I guess on the deposit/withdraw transactions it matters more.
492 2013-02-06 07:13:02 <gmaxwell> petertodd: well, technically you can avoid linking without tor. Consider, you only connect to the bank once... and he doesn't know which of the past tokens was yours.
493 2013-02-06 07:14:23 <gmaxwell> petertodd: I don't see miners having an incentive to fight it .... so long as (1) the bank bonds result in miner mayments (profits!) and (2) blocksizes are small enough that there is pressure for space regardless of it.
494 2013-02-06 07:15:21 <petertodd> gmaxwell: Good point there. It'd be worth it to have some history tracking features in the software to help users evaluate when they should or shouldn't be using tor. (assuming using tor isn't cheap enough to just do all the time)
495 2013-02-06 07:15:26 <gmaxwell> sort of a third point about small blocks being important: if you want to build other zero trust systems that use bitcoin blockchain data as proof??? ... it's pretty important that the blockchain data be small enough that those systems can afford to keep it around.
496 2013-02-06 07:16:12 <petertodd> gmaxwell: Yeah, with UXTO proposals, and especially UXTO fraud proofs you have some hope of keeping the derived systems secure, but it's much better to avoid relying on such mechanisms.
497 2013-02-06 07:16:13 <gmaxwell> petertodd: really I'd think something like this should just mandate tor. Tor doesn't really impose any terrible costs on it, and it avoids having to reason about the tradeoffs. But yea, I don't think it's strictly needed.
498 2013-02-06 07:16:36 <petertodd> gmaxwell: Tor for small bits of data seems pretty fast ultimately.
499 2013-02-06 07:17:10 <gmaxwell> petertodd: well, only so long as the derrived system is happy with just that much. It's still an issue if the derrived system needs queries which aren't UTXO-fast.
500 2013-02-06 07:17:24 <petertodd> gmaxwell: I think part of avoiding having miners have an incentive will be to get it working before there is too much pressure to increase block sizes... basically sneak it in while it's just something that occasionally gives a nice fidelity bond reward.
501 2013-02-06 07:18:04 <gmaxwell> thats important for user motivations too.. if we don't show viable alternatives like this too many people will continue that no matter how horrible they agree increasing sizes may be??? ... that it must be done.
502 2013-02-06 07:18:10 <petertodd> gmaxwell: I think everything I've written is SPV/fast-UTXO compatible provided that the UTXO is indexed by scriptPubKey or similar.
503 2013-02-06 07:18:33 <gmaxwell> I usually bludgeon people who suggest things that aren't...
504 2013-02-06 07:18:34 <petertodd> gmaxwell: (fidelity bonds themselves are pure SPV/pure-UTXO)
505 2013-02-06 07:18:47 <petertodd> Heh
506 2013-02-06 07:19:11 <petertodd> That fidelity bonds aren't pure SPV, no UTXO, annoys me, but I can't see any other way to do it.
507 2013-02-06 07:19:29 <petertodd> Sacrifices themselves are of course pure SPV.
508 2013-02-06 07:20:49 <petertodd> MC1984: Here is a fun one BTW: (25BTC * $21/BTC)/1MiB = $0.51/KiB, so about $0.25 per simple transaction. IE, that's what the mining inflation subsidy costs right now.
509 2013-02-06 07:20:56 <gmaxwell> I know how to make them a lot closer to pure SPV, I think. You make them expire and require they be renewed.
510 2013-02-06 07:21:03 <MC1984> have you considered that the mere addition of these layers of complexity helps de-democratise bitcoin?
511 2013-02-06 07:21:27 <MC1984> you could argue the financial systems are in such poor shape becuase they are so horiffically complex no one really knows how they work
512 2013-02-06 07:21:34 <MC1984> not even the people who run them
513 2013-02-06 07:21:34 <petertodd> Actually, I'm already planning on expiry anyway, as part of the fraud proof aspect. Better to avoid systems that require proofs to be kept around forever...
514 2013-02-06 07:22:33 <gmaxwell> MC1984: you can't ask that question without saying "compared to"... compared to a bitcoin where you no one can validate blocks without $30,000 in computing hardware which earns you nothing because you're honest and hope that someone else honest takes the cost for you?
515 2013-02-06 07:22:35 <petertodd> Meh, Bitcoin isn't scalable, so we have to do something. You either de-democratise by requiring access to hardware, (big-blocks) or requiring access to education. (token banks and similar ideas)
516 2013-02-06 07:23:03 <petertodd> I'd much rather take the later tradeoff. I learned to program on pencil and paper and a $20 book on Basic...
517 2013-02-06 07:23:14 <gmaxwell> MC1984: fortunately much of the software complexity can be packaged up so that it's hidden from users (and mostly even developers too)
518 2013-02-06 07:23:26 <gmaxwell> Software scales.. one line of code can feed a million minds.
519 2013-02-06 07:23:32 <MC1984> compromises sigh
520 2013-02-06 07:23:39 <gmaxwell> Hardware??? network bandwidth? not so much.
521 2013-02-06 07:25:04 <gmaxwell> It's not one extreme or another though... but having healthy off chain alternatives means that if we increase block sizes in the future we do it because we've decided its a good tradeoff and not because we know it will centeralize the system but feel we have no choice.
522 2013-02-06 07:25:17 <petertodd> I'll freely admit these protocols are bloody complex - implementing fraud proofs is going to suck - but at least we have a bunch of smart people all talking to each other. It'll result in a system significantly more complex than Bitcoin, but it won't be done by just one guy.
523 2013-02-06 07:25:45 <gmaxwell> This is especially important because in the future there will be people arguing for it not because they think it'll be okay??? but because they actually want to centeralize it because they're confident that they can come out ahead that way.
524 2013-02-06 07:25:47 <petertodd> The other thing about these meta-protocols on top of Bitcoin, is they don't suffer from the "must get everything right on day 1" consensus problem that Bitcoin has.
525 2013-02-06 07:26:25 <gmaxwell> yea, bitcoin solves the eggs-in-one-basket and how-do-you-bootstrap problems that keep these ideas from being useful on their own.
526 2013-02-06 07:26:31 <petertodd> gmaxwell: The abundance of pro-unlimited blockchain people on the forums really scare me.
527 2013-02-06 07:26:53 <petertodd> gmaxwell: I want to wade in there with some big carefully reasoned post, but I can't imagine it'll really do that much good...
528 2013-02-06 07:27:11 <MC1984> the main argument that stops me being a proponent of huge blocks is gregs observation about the fees market
529 2013-02-06 07:27:27 <gmaxwell> petertodd: it's not so bad??? there are a whole bunch of pro-unlimited-currency-supply people too.  If you think of it relative to that, it's not so bad.
530 2013-02-06 07:27:47 <gmaxwell> petertodd: well it looking like it's _me_ vs the world does not help the argument.
531 2013-02-06 07:27:59 <MC1984> the access to hardware/bandwidth stuff not so much, i think moores law mght take care of that faster than anyone realises
532 2013-02-06 07:28:19 <MC1984> hopefully asuming the developing world continues developing too
533 2013-02-06 07:28:51 <gmaxwell> MC1984: you're not also concerned that no one except government sponsored orgs would bother running validating nodes with huge blocks? (and thus those orgs get to control inflation, since no one else is checking)
534 2013-02-06 07:28:55 <petertodd> gmaxwell: Heh, reminds me, I realized there is a great analogy between large block sizes and the fight between DC and AC back in the early 1900's, but then I realized that I'd be saying Satoshi was on the side of Edison, and as for Tesla... someone else better argue that one...
535 2013-02-06 07:29:47 <gmaxwell> MC1984: maybe... but no matter how fast the hardware is there is some blocksize that makes it costly... Part of my worry here is that there is a tremendous tragidy of the commons risk: "I could afford to validate, but hey??? other people will do it"
536 2013-02-06 07:30:01 <petertodd> Moores law is an observation! It's also already showing signs of cracking... and transistors are getting scary close to having just one atom in them.
537 2013-02-06 07:30:07 <MC1984> as i said, computing power is increasing at shocking rates
538 2013-02-06 07:30:17 <MC1984> not saying im right
539 2013-02-06 07:30:17 <petertodd> No it isn't.
540 2013-02-06 07:30:34 <petertodd> Clock speed has stagnated for a decade now.
541 2013-02-06 07:30:40 <gmaxwell> petertodd: I'm still skeptical that satoshi actually believed that.. even in the example that I'd missed which gavin helpfully pointed me to??? it was a modest bump not an unlimit.
542 2013-02-06 07:31:11 <petertodd> You can't count any faster now than you could 10 years ago. Sure you can count in parallel, but not all problems are parallizable.
543 2013-02-06 07:31:12 <MC1984> well it helps that verification is highly parallelisible
544 2013-02-06 07:31:29 <MC1984> in fact id lik to see someone take a crack at a GPU verify engine
545 2013-02-06 07:31:42 <gmaxwell> petertodd: we can bump clockspeed whenever we want to switch to more costly chemistry. ... but the speed of light makes higher clockspeed not a big win (needs long pipelines) in any case.
546 2013-02-06 07:31:42 <MC1984> on the pure assumption that it would be awesome
547 2013-02-06 07:32:00 <petertodd> Yes, but as I say, we're not that far from single atom transistors, and scaling past that is going to require 3D chips, which is a nightmare due to manufacturing and cooling issues.
548 2013-02-06 07:32:24 <MC1984> intel does 3d chips now?
549 2013-02-06 07:32:46 <petertodd> The only reason Moores law has worked is because transistor density increases by the inverse square of feature size, and feature size has been getting smaller linearly.
550 2013-02-06 07:33:34 <petertodd> Well, everyone does multi-layer chips, but increases in density in the Z dimension aren't happening in a nice linear fashion.
551 2013-02-06 07:33:36 <MC1984> well when that gravy train stops bitcoin is a small consideration overall
552 2013-02-06 07:34:04 <petertodd> Sure, but all the more reason not to assume it won't stop when we plan out Bitcoin.
553 2013-02-06 07:34:32 <MC1984> bitcoin already exists by the grace of moore law
554 2013-02-06 07:34:34 <petertodd> gmaxwell: Yeah, I mean, you *can* get multi-THz transistors, but a nanosecond is about a foot so...
555 2013-02-06 07:34:44 <MC1984> i dont think it could have existed much before it did
556 2013-02-06 07:35:24 <petertodd> Yeah, if ECC crypto wasn't around, basically Bitcoin would have needed another few years of scaling so RSA signatures and keys wouldn't seem so bad.
557 2013-02-06 07:35:56 <gmaxwell> MC1984: our current protocol parameters would have worked a decade before... but we didn't have many always on PCs then... and no one would have believed that 52GiB/yr would be even remotely viable for anything (back when a big hdd was maybe 160gb)
558 2013-02-06 07:37:02 <petertodd> MC1984: Another fun one: (1MiB/10minutes * 1year)/8billion = 7bytes/person-year
559 2013-02-06 07:38:17 <MC1984> thats what i mean
560 2013-02-06 07:38:37 <MC1984> bitcoin happened pretty fast after the supporting tech substrate for it became widespread
561 2013-02-06 07:39:04 <MC1984> broadband, HDDs, crypto tech etc
562 2013-02-06 07:40:25 <gmaxwell> the crypto part isn't novel at all.. thats been around.
563 2013-02-06 07:40:32 <petertodd> gmaxwell: ...and even then, lots of people were still on dialup, so the 1.7KiB/second average would have been a big deal.
564 2013-02-06 07:40:33 <petertodd> (assuming 1MiB blocks of course, right now bitcoin is doing half a KiB/s)
565 2013-02-06 07:40:57 <MC1984> i thought the proof of work concept isnt that old?
566 2013-02-06 07:41:18 <petertodd> Well, cryptographically secure hashes that people trust aren't that old.
567 2013-02-06 07:41:23 <gmaxwell> It's a little less about what was possible wrt broadband and hdd's I think, and more about having a large enough multiple of the requirement that people didn't bother worrying about the scale.
568 2013-02-06 07:41:49 <gmaxwell> MC1984: I mean, hal created rpow several years before bitcoin existed.
569 2013-02-06 07:42:03 <MC1984> never heard of it
570 2013-02-06 07:42:05 <petertodd> It's good that Bitcoin nodes are cheap enough to run that I've got three going just in my apartment, and another 3 on virtual servers.
571 2013-02-06 07:42:10 <gmaxwell> And that was a POW-scarcity based digital currency.
572 2013-02-06 07:42:33 <petertodd> MC1984: It relied on trusted hardware, and didn't go beyond a cool proof-of-concept.
573 2013-02-06 07:43:04 <MC1984> is hal still doing bitcoin stuff
574 2013-02-06 07:43:27 <gmaxwell> we haven't heard from hal in a little bit. I expect he is, but at his own pace.
575 2013-02-06 07:43:30 <gmaxwell> http://www.finney.org/~hal/rpow/
576 2013-02-06 07:44:02 <petertodd> Which incidentally, is the great thing about Bitcoin: you can do incompatible upgrades to your fancy trusted hardware off-chain tx stuff, by moving the value to Bitcoin, changing the hardware, and moving it back to the new hardware. Without Bitcoin you need compatibility from the start, and that's very difficult to pull off in a trustworthy way with secure hardware.
577 2013-02-06 07:45:09 <gmaxwell> petertodd: yea, that was an issur for rpow??? the software could never be changed.
578 2013-02-06 07:45:16 <petertodd> As gmaxwell said before, with Bitcoin the "must get it right at the start" part is already done and works.
579 2013-02-06 07:45:17 <MC1984> i wouldnt mind seeing bitcoin become a substrate for a new world, rather than the world itself
580 2013-02-06 07:45:23 <MC1984> substrates are good
581 2013-02-06 07:45:41 <petertodd> It'd be a lot more interesting than making minor modifications to the substrate too. :P
582 2013-02-06 07:46:39 <gmaxwell> Bitcoin's strength is the global fully decenteralized by-everyones-consent nature... but thats also it's weakness. The rules that give us ultimate confidence in it are also a bit of a suicide pact.
583 2013-02-06 07:46:41 <MC1984> i suppose even if things stayed exactly the same as now, except bitcoinwas the reserve currency instead of uSD, that would be a substantial improvement
584 2013-02-06 07:47:36 <petertodd> Well, "substantial improvement" is a non-technical judgement, personally I don't have many issues with the financial system as a whole right now, but I have some, and I think Bitcoin is a nice solution to some of those issues.
585 2013-02-06 07:48:18 <gmaxwell> petertodd: I think alternatives are good even without drawing any judgements.
586 2013-02-06 07:48:18 <MC1984> bitcoins creation was political i think
587 2013-02-06 07:48:32 <MC1984> not wholly
588 2013-02-06 07:48:39 <gmaxwell> Bitcoin is one of few things which you can actually call a radically distinct alternative.
589 2013-02-06 07:48:41 <petertodd> gmaxwell: Absolutely, Bitcoin is totally unlike what came before, therefor it's worth exploring.
590 2013-02-06 07:49:19 <petertodd> gmaxwell: Same reason I think alt-coins exploring different economic rules, like freicoin, are a good thing in principle... just too bad so many have been scams.
591 2013-02-06 07:50:04 <petertodd> gmaxwell: Now, I happen to think I have more interesting things to do with my life than hack of freicoin, but I'm glad someone is giving it a go.
592 2013-02-06 07:50:34 <gmaxwell> One thing people often don't appreciate is how much a minority alternative can move the middle.  There mere existance of Vorbis cut MP3 licensing costs by a factor of 4 overnight, and kept them from rising to god-know-what. ... and this happened without vorbis every gaining maybe more than a few percent of MP3's support.
593 2013-02-06 07:50:57 <MC1984> hmm a thought
594 2013-02-06 07:51:16 <petertodd> PayPal has their PR thing about how they're reforming their practices.
595 2013-02-06 07:51:17 <gmaxwell> I'm usually disappointed with the altcoin's lack of completeness of vision and yea, the fact that many do seem to be used by their creators or at least initial adopters as nothing more than a quick buck.
596 2013-02-06 07:51:27 <MC1984> disregarding moores law, is technology projected to scale faster than economic activity for the foreseeable future
597 2013-02-06 07:51:58 <petertodd> I think the biggest problem for altcoins right now is that there *is* a lot of interesting work to be done on Bitcoin, which attracts all the competent people instead.
598 2013-02-06 07:52:06 <gmaxwell> petertodd: yea... Did we contribute to that? hard to know for sure. It's certantly possible.
599 2013-02-06 07:52:20 <MC1984> if so hasnt bitcoin just got a rough few decade or whatever to get through before it could really handle everything at once
600 2013-02-06 07:52:52 <petertodd> (and for that matter s/altcoins/bitcoin-based timestamping/, the perenial bad idea)
601 2013-02-06 07:53:00 <gmaxwell> MC1984: no. fully decenteralized bitcoin has O(N^2)ish storage scaling. No amount of constant factor wait fixes that.
602 2013-02-06 07:53:39 <gmaxwell> If you centeralize bitcoin it becomes O(N) and then thats potentially viable given enough tech improvement over economic growth.
603 2013-02-06 07:54:19 <gmaxwell> centralize*
604 2013-02-06 07:54:52 <MC1984> i dont understand that algebra
605 2013-02-06 07:55:28 <MC1984> or the terms atleast
606 2013-02-06 07:55:54 <gmaxwell> MC1984: a node has to process all the transactions thats your O(N) e.g. one process per one transaction.  But we don't have just one node, we have as many nodes as users if its completely decenteralized
607 2013-02-06 07:55:59 <petertodd> MC1984: You have n people, they each make one transaction, so you have n transactions, they need to store everyone elses transaction, so every person has to store n transaction, and there are n people, thus you have n^2
608 2013-02-06 07:56:24 <gmaxwell> so if we're armwavy and pretend the number of transactions and users are the same you get N^2 operations for N activity.
609 2013-02-06 07:56:54 <gmaxwell> and if you graph that you see its a run away function that grows faster the more it grows. (constantly increasing growth)
610 2013-02-06 07:57:04 <petertodd> Comp-sci calles O(n) and similar "big-O notation", and it's just a short-hand way of saying how something scales as the size of your data increases.
611 2013-02-06 07:57:08 <MC1984> oh yeah thats exponential
612 2013-02-06 07:57:19 <gmaxwell> well it's quadratic, exponential is even worse.
613 2013-02-06 07:57:22 <petertodd> Thus bitcoin is O(n^2) in space and in bandwidth.
614 2013-02-06 07:57:46 <petertodd> MC1984: exponential would be say, 2^n
615 2013-02-06 07:57:59 <petertodd> MC1984: The only people who like exponential algorithms are cryptographers...
616 2013-02-06 07:58:23 <gmaxwell> But if you reduce bitcoin to just one or a small number of full nodes you get O(N) (or O(N*small_constant)) and thats much better but why not just have paypal?.
617 2013-02-06 07:59:19 <MC1984> fuck it im still running a full node as long as possible
618 2013-02-06 07:59:21 <petertodd> MC1984: FWIW, I had an interview at Google two years ago, and easily half the interview was about hand-waving analysis of programming ideas with big-O notation.
619 2013-02-06 07:59:44 <gmaxwell> N*M things aren't so bad??? so long as you keep one of N or M small and not growing (much or at all). People who say uncap the blocksize are implictly suggesting to solve the problem by limiting the number of validating nodes.
620 2013-02-06 08:00:05 <gmaxwell> People who say the size should remain tightly limited are instead proposing to solve the issue by leaving the number of transactions capped.
621 2013-02-06 08:00:53 <gmaxwell> in either case N*M doesn't run away because one or the other is small-ish and not growing.
622 2013-02-06 08:01:25 <MC1984> well im leaning towards the cap all things considered but seriously 1mb........
623 2013-02-06 08:01:27 <gmaxwell> I prefer to limit transactions because we can replace scale with off-chain, but nothing can replace decenteralization and zero trust.
624 2013-02-06 08:01:35 <SomeoneWeird> petertodd, i have no idea what half of those words mean, so I won't be working for google
625 2013-02-06 08:02:18 <gmaxwell> MC1984: does saying 144MB/day make you feel better? :P Or 52 gigabytes/yr?
626 2013-02-06 08:02:32 <gmaxwell> it adds up...
627 2013-02-06 08:03:02 <MC1984> nope, i pulled like 70gb of star trek in one night a while ago
628 2013-02-06 08:03:06 <petertodd> It's what clouds the discussion really; the number of people on the planet is unlikely to go above the 10billion mark, so your n is limited, but at the same time expecting 1GiB blocks requires what will be very expensive hardware for the forseeable future.
629 2013-02-06 08:03:08 <gmaxwell> but yea, I think my argument for this stuff is weakened because I'm not willing to say "1MB is the one true value and it must never be larger" ... the rules shouldn't be a total suicide pact.
630 2013-02-06 08:04:07 <petertodd> SomeoneWeird: heh, well, I didn't get an offer if it makes you any happier. :) Although when you are at a interview for a programming job, and tell them how much you like analog electronics...
631 2013-02-06 08:04:39 <SomeoneWeird> lol yeah
632 2013-02-06 08:05:06 <petertodd> If Satoshi had set the hard limit to, say, 25MiB, we probably wouldn't be having this discussion. On the other hand, people would be hating on satoshidice even more...
633 2013-02-06 08:05:21 <gmaxwell> My position is more subtle: this is a really serious tradeoff, with major indirect and long term costs to increasing it, some of which are hard to reason about. Extreme caution should be required, etc.
634 2013-02-06 08:05:32 <MC1984> if you could magically restart bitcoin without any drama, what would you change?
635 2013-02-06 08:05:53 <petertodd> SomeoneWeird: Google did a huge hiring campaign; they called me in for an interview on the basis of literally a single 25line patch I made to Cython... I think they were getting desperate.
636 2013-02-06 08:06:13 <gmaxwell> petertodd: I think we'd instead have had people howling that bitcoin was a scam because 1.2TB/tr is insane and impossible and it's all doomed to fail.
637 2013-02-06 08:06:26 <SomeoneWeird> wow
638 2013-02-06 08:06:27 <petertodd> https://en.bitcoin.it/wiki/Hardfork_Wishlist
639 2013-02-06 08:06:48 <gmaxwell> well hardfork wishlist doesn't list stuff that would change the 'contract' ...
640 2013-02-06 08:06:55 <SomeoneWeird> imo even 52gig/yr is insane
641 2013-02-06 08:07:01 <gmaxwell> I'd make utxo's expire. Everything else can be retrofitted.
642 2013-02-06 08:07:04 <MC1984> no drama, anything goes
643 2013-02-06 08:07:21 <petertodd> SomeoneWeird: 5,000 engineers are hard to find...
644 2013-02-06 08:07:44 <gmaxwell> SomeoneWeird: a $100 HDD stores like half a lifetime of that.. it's not really that big a deal.
645 2013-02-06 08:07:47 <petertodd> SomeoneWeird: You know, Amazon glacier charges a penny per GiB*month
646 2013-02-06 08:08:01 <gmaxwell> SomeoneWeird: it's currently annoying just because we have immature software that does the download in the 'foreground'.
647 2013-02-06 08:08:33 <SomeoneWeird> nah not storae
648 2013-02-06 08:08:35 <SomeoneWeird> storage
649 2013-02-06 08:08:40 <SomeoneWeird> bandwidth
650 2013-02-06 08:08:58 <SomeoneWeird> its still not that much I suppose, but when you have a 50 gig/month cap
651 2013-02-06 08:09:04 <petertodd> I registered blockchainbymail.com a few weeks ago...
652 2013-02-06 08:09:06 <gmaxwell> SomeoneWeird: it's like 14kbit/sec...
653 2013-02-06 08:09:12 <MC1984> yeah isp data caps put a dampner on it
654 2013-02-06 08:09:33 <MC1984> then again they put a dampner on the whole digital delivery setor anyway
655 2013-02-06 08:09:40 <SomeoneWeird> yeappp
656 2013-02-06 08:09:46 <gmaxwell> SomeoneWeird: even against a 50gig cap, it's like 8%.. meh.
657 2013-02-06 08:09:52 <petertodd> I figure just using a turn-key DVD-fufillment service would be low-maintenance enough to be worth it, although the blockchain isn't quite big enough yet to matter.
658 2013-02-06 08:10:26 <gmaxwell> besides lots of capped ISPs excempt local services from the caps??? presumably bitcoin would eventually be excempted... considering that it caches/multicasts infinitely well. :P
659 2013-02-06 08:10:48 <gmaxwell> petertodd: USB satellite reciever...
660 2013-02-06 08:10:56 <petertodd> gmaxwell: I wonder how many of those ISPs excempt their DNS servers...
661 2013-02-06 08:11:18 <MC1984> isnt tor an example of something that doesnt really scale but is doing its job just fine what what people need of it?
662 2013-02-06 08:11:33 <petertodd> Why do you say tor doesn't scale?
663 2013-02-06 08:11:47 <gmaxwell> MC1984: tor is basically all reasonable linear scaling.
664 2013-02-06 08:11:48 <thermoman> is there a reason the current 0.7.2 release only uses one cpu core?
665 2013-02-06 08:11:57 <MC1984> exit nodes, the directory stuff etc
666 2013-02-06 08:12:23 <petertodd> thermoman: the soon-to-be-released 0.8 uses more than one
667 2013-02-06 08:12:33 <MC1984> bitcoin completely assumes people would find no meta-utility in what it does for them to keep it running
668 2013-02-06 08:13:05 <MC1984> i remember the time deepbit got over 50% hashrate and people manned up and diversified
669 2013-02-06 08:13:19 <petertodd> MC1984: exit nodes and directories are all O(1) per tor user in principle, provided each tor user is willing to contribute back to the network in some way (on average)
670 2013-02-06 08:13:30 <gmaxwell> MC1984: if it did it would fail.... everyone except miners would stop running full nodes, and miners would give themselves an extra 100 btc per block..
671 2013-02-06 08:13:35 <gmaxwell> MC1984: your memory is funny.
672 2013-02-06 08:13:50 <thermoman> petertodd: will 0.8 use leveldb instead of berkeleydb?
673 2013-02-06 08:13:54 <SomeoneWeird> <gmaxwell> MC1984: if it did it would fail.... everyone except miners would stop running full nodes, and miners would give themselves an extra 100 btc per block.. < ha, never thought of that
674 2013-02-06 08:14:06 <petertodd> thermoman: for the block database yes, your wallet is still berkelydb
675 2013-02-06 08:14:39 <petertodd> SomeoneWeird: you might find this interesting: https://bitcointalk.org/index.php?topic=137933.0
676 2013-02-06 08:14:42 <gmaxwell> MC1984: I rememer people yelling and that not happening. And then I remember a series of DDOS attacks that basically left deepbit offline for days at a time... and many people moved to other pools.
677 2013-02-06 08:14:53 <petertodd> SomeoneWeird: (inflation-proofing via fraud notices)
678 2013-02-06 08:15:12 <MC1984> gmaxwell i dont mean have no rules and incentives, just how nice would it be if the problems of the block cap wernt that big after all beause people are better than bitcoin assumes
679 2013-02-06 08:15:19 <petertodd> gmaxwell: (inflation-proofing via DDoS attacks)
680 2013-02-06 08:15:23 <SomeoneWeird> hrmmm
681 2013-02-06 08:15:42 <thermoman> petertodd: are there any thoughts about using a RDBMS as backend? like postgres, mysql, etc? for blockchain *and* wallet?
682 2013-02-06 08:16:02 <MC1984> oh i thought people voluntarily moved pools
683 2013-02-06 08:16:10 <petertodd> SomeoneWeird: that said, I think avoiding the hard requirement for stuff like inflation-proofing fraud notices is best
684 2013-02-06 08:16:31 <gmaxwell> MC1984: I think it's best to have both kinds of protection: People really are smarter and more honest than we may pessimally assume... but cryptographic-proof is stronger still.
685 2013-02-06 08:16:45 <petertodd> thermoman: People have done it, but I don't think the dev team particularly thinks it needs to go in the satoshi reference client itself... and I'm not part of the dev team.
686 2013-02-06 08:17:04 <gmaxwell> petertodd: esp since making the software for fraud notices is another order of magnitude harder than what we seem to be having problems with now.
687 2013-02-06 08:17:28 <MC1984> of course in a idel world bitcoin could run on pure rationality of its participants.....
688 2013-02-06 08:17:40 <petertodd> gmaxwell: yeah... and it's dependent on changing the tx hashing algorithm too.
689 2013-02-06 08:17:46 <gmaxwell> thermoman: we don't even store the blockchain itself in a database, doing so wouldn't have any value to the software itself... only cost.
690 2013-02-06 08:18:18 <petertodd> MC1984: The way I described Bitcoin at the talk I gave a few weeks ago, started with "Imagine we had this village, and in this village everyone was honest and never made mistakes and carried around this little ledger book..."
691 2013-02-06 08:18:19 <gmaxwell> (it would make life easier for people trying to do varrious analysis things, but thats very specialized and would want a different schema than we would in any case)
692 2013-02-06 08:18:54 <petertodd> thermoman: In short, nothing is stopping you from writing a simple RPC-using program that makes your own database.
693 2013-02-06 08:20:51 <gmaxwell> MC1984: rationality is hard. Validation is subject to failure by people letting someone else handle the cost... it's even arguably more efficient for few people to do it instead of many. But people are silly with security: they only want to care _After_ the failure has happened.
694 2013-02-06 08:21:57 <MC1984> yah theres suprising almost no incentive for validation
695 2013-02-06 08:22:03 <petertodd> gmaxwel: That's why many of the "assume the UTXO hash buried n deep will never be orphaned" type proposals scare me... Being able to recover from a large attacker who gives up is a good thing.
696 2013-02-06 08:22:15 <MC1984> except fuzzy notions of colletive self interest
697 2013-02-06 08:22:29 <gmaxwell> petertodd: a lot of them create really awesome forever-fails.
698 2013-02-06 08:23:06 <gmaxwell> petertodd: e.g. manage a 101 block reorg _once_ and the currency is forever split in two and can never heal short of half the nodes whiping themselves manually.
699 2013-02-06 08:23:37 <MC1984> how would you even fix that? some sort of demurrage for validators?
700 2013-02-06 08:23:42 <petertodd> gmaxwell: yeah... I mean, hell, Bitcoin had a 50-odd block re-org with the tx overflow bug, there is precident.
701 2013-02-06 08:23:45 <gmaxwell> petertodd: and then people defend that failure mode saying that a 101 block reorg will never happen.... but if so, why the hell are they defending against it with their silly scheme? :P
702 2013-02-06 08:24:24 <petertodd> gmaxwell: It's bad enough how much software is out there that will fail badly on even a 6 block reorg, hell, I've written such software myself.
703 2013-02-06 08:24:35 <gmaxwell> MC1984: keeping validation so insanely cheap that you can just make validation a default in software and otherwise indifferent users become alturistic out of lazyness!
704 2013-02-06 08:24:50 <gmaxwell> petertodd: like blockexplorer. lol
705 2013-02-06 08:24:59 <MC1984> yes i like that
706 2013-02-06 08:25:01 <petertodd> gmaxwell: Actually, there's yet another argument against 1GiB blocks...
707 2013-02-06 08:25:12 <petertodd> gmaxwell: Ha, is that why it was broken on testnet for so long?
708 2013-02-06 08:25:15 <gmaxwell> yep
709 2013-02-06 08:25:58 <MC1984> GIGABYTE BLOCKS
710 2013-02-06 08:26:24 <petertodd> gmaxwell: what's the difficulty -> total mhash/second conversion again? because testnet is 30...
711 2013-02-06 08:26:26 <MC1984> it scares the othe side of the argument into submission
712 2013-02-06 08:26:45 <petertodd> TERABYTE BLOCKS <- beat you
713 2013-02-06 08:27:00 <MC1984> fffffffff
714 2013-02-06 08:27:01 <gmaxwell> MC1984: consensus system lit. talks about a BAR model??? where you classify participants into byzantine (evil??? just want to break everything), rational (self-interested, knowldgable), and alturistic (honest even if it costs them). Many systems are secure against byzantine users so long as there are enough alturistic ones. If have only the B and R the systems fail.
715 2013-02-06 08:27:07 <petertodd> PICOBYTE BLOCKS
716 2013-02-06 08:27:09 <petertodd> wait, no...
717 2013-02-06 08:27:29 <MC1984> DO YOU EVEN SI?
718 2013-02-06 08:27:39 <gmaxwell> So I like to think of how we can maximize the alturistic users in bitcoin (and how we can make the maximally effective)
719 2013-02-06 08:27:56 <gmaxwell> PEDOBYTE oh wait. no.
720 2013-02-06 08:28:17 <MC1984> wat
721 2013-02-06 08:28:42 <petertodd> Relay rules are a good example where alturistic users help things.
722 2013-02-06 08:28:53 <MC1984> so bitcoins alreay goes well against the literature of consensus systems
723 2013-02-06 08:28:57 <MC1984> ?
724 2013-02-06 08:30:00 <petertodd> Although, it reminds me: it'd be really nice to see P2Pool nodes vouch for their hash power as a way to better determine if your node is connecting to a statistical majority of actual bitcoin nodes out there; p2pool already has the tx forwarding backbone.
725 2013-02-06 08:30:10 <gmaxwell> MC1984: well, to some extent??? though you can analyize bitcoin under the BAR model, as petertodd points out.. if we only had B/R users then it would be relaly hard to get txn mined because no one would relay. Altrustic users make it rational for rational users to relay too.
726 2013-02-06 08:31:09 <MC1984> i wonder i building a strong bitcoin brand would help with this BAR thing
727 2013-02-06 08:31:10 <petertodd> gmaxwell: I dunno about that example... I suspect because BTC transactions are of value to miners, simple tit-for-tat accounting should mostly solve the "why relay" problem. The chance of getting a block is so low after all.
728 2013-02-06 08:31:18 <gmaxwell> petertodd: yea, in #p2pool we talked some about mining node identities for anti DOS attack on p2pool. That could be generalized to bitcoin as a whole.
729 2013-02-06 08:31:41 <petertodd> MC1984: the forum isn't exactly helping with branding...
730 2013-02-06 08:32:02 <MC1984> like ive been thinking how annoyed i am that many bitcoin business have BIT in the name playing of hte novelty, when the system should be transparent and just work
731 2013-02-06 08:32:14 <gmaxwell> petertodd: I dunno, I think you have two equlibrium the totally selfish and the tit for tat. The existance of alturistic relayers breaks the symmetry between the two.
732 2013-02-06 08:32:32 <petertodd> gmaxwell: ...and I re-invent yet another idea. :P Seriously though, the trick would be to keep the lowest hash discovered by a given p2pool identitiy, so the proofs could be short.
733 2013-02-06 08:32:39 <gmaxwell> ('an alturistic node may likely forward it anyways, I might as well tit for tat asap')
734 2013-02-06 08:32:52 <gmaxwell> petertodd: yea, I proposed that too.
735 2013-02-06 08:32:53 <MC1984> gmaxwell do you find a parallel with the way torrents need seeders?
736 2013-02-06 08:33:24 <petertodd> gmaxwell: lol, yeah, I thought of it only two days ago. :P
737 2013-02-06 08:33:26 <MC1984> youd think no one would seed, but so many people do they need to make laws stopping them
738 2013-02-06 08:33:27 <gmaxwell> MC1984: there are all kinds of weird motivations with torrents I don't pretend to understand.
739 2013-02-06 08:33:58 <petertodd> gmaxwell: That's a tough one, because it's basically a percolation problem, and it doesn't take very many alturistic nodes to achieve complete coverage in random graphs.
740 2013-02-06 08:34:18 <gmaxwell> MC1984: some of that is altrustic by default: torrent software that seeds by defalt until you shut it off.. some is trackers making seeding rational by requiring raios.
741 2013-02-06 08:34:21 <MC1984> or is that a function of seeding becoming so untaxing on modern tech that no one can be bothered to be an asshole
742 2013-02-06 08:34:36 <gmaxwell> MC1984: I think thats a big part of it.
743 2013-02-06 08:34:59 <petertodd> MC1984: Feeling like you're a rebel sticking it to the man can be a big motivation...
744 2013-02-06 08:35:02 <midnightmagic> That's how a lot of the early bitcoin functionality was designed. Knobs that were glued in-place by default.
745 2013-02-06 08:35:05 <MC1984> th last private tracker i was on had a ratio system, but they turned it off and never turned it on again
746 2013-02-06 08:35:24 <MC1984> petertodd LOL bitcoins got that in spades
747 2013-02-06 08:35:54 <gmaxwell> friendly by default, cheap enough to be friendly that most people won't bother ungluing the switch from the nice position.
748 2013-02-06 08:36:04 <MC1984> gmaxwell interesting too, its sort of why i feel post scarcity is the way forward for everyone long term, make it pointless to be an asshole
749 2013-02-06 08:36:10 <MC1984> theres a parallel there i think
750 2013-02-06 08:36:21 <midnightmagic> I'm not sure I'd call everything satoshi made it do, friendly. More like whorish..
751 2013-02-06 08:36:55 <petertodd> MC1984: post scarcity 'eh? so what have you done for the space program lately?
752 2013-02-06 08:36:58 <gmaxwell> "It takes advantage of the nature of information being easy to spread but hard to stifle"
753 2013-02-06 08:37:20 <petertodd> gmaxwell: ...yet another reason to keep the block sizes low.
754 2013-02-06 08:37:33 <midnightmagic> But there was weird stuff too; at one point, if you ever set a proxy, you could never go back to being proxy-less without creating a new wallet.
755 2013-02-06 08:37:48 <petertodd> midnightmagic: huh?
756 2013-02-06 08:38:05 <MC1984> petertodd i root for it at every opportunity lol
757 2013-02-06 08:38:06 <gmaxwell> Settings are stored in the wallet in a very automagic way.
758 2013-02-06 08:38:17 <gmaxwell> midnightmagic: pretty sure that wasn't intentional. :P
759 2013-02-06 08:38:32 <midnightmagic> It was set as a configurable knob inside the wallet. Once set, you could never delete it. You could, from then on, only ever change it. I'm not convinced it wasn't on purpose.
760 2013-02-06 08:38:49 <MC1984> wut
761 2013-02-06 08:38:55 <petertodd> midnightmagic: Wait, but what do you mean by "a proxy"?
762 2013-02-06 08:39:04 <petertodd> 
ACTION is totally lost

763 2013-02-06 08:39:07 <gmaxwell> midnightmagic: I am??? because thats what you'd get if you didn't think to make sure you could unset it.
764 2013-02-06 08:39:18 <gmaxwell> petertodd: e.g. configured it to use tor.
765 2013-02-06 08:39:49 <petertodd> Ah, so, set tor=on, and it'd always connect over tor in the future?
766 2013-02-06 08:39:50 <midnightmagic> petertodd: -proxy=
767 2013-02-06 08:39:56 <gmaxwell> -proxy=1.2.3.4:1234  if you set it via the gui it got saved into the wallet... and setting it to the empty string did nothing.
768 2013-02-06 08:40:06 <petertodd> Madness...
769 2013-02-06 08:40:35 <MC1984> its a feature
770 2013-02-06 08:40:38 <MC1984> not a bug
771 2013-02-06 08:40:43 <gmaxwell> more than proxy did that. I think the fees did that too.
772 2013-02-06 08:41:01 <midnightmagic> I think it would only *get* set in the wallet once it built a successful connection through it. If my memory of this condition is accurate, then this is the reason why I'm not convinced it wasn't deliberate.
773 2013-02-06 08:42:00 <gmaxwell> I don't see what motivation for that there would have been.
774 2013-02-06 08:42:28 <petertodd> being tor, that would be post-satoshi code right?
775 2013-02-06 08:42:40 <gmaxwell> it's not like bitcoin was full of safty-edges??? we've been adding them over time.
776 2013-02-06 08:42:54 <midnightmagic> Giving it a memory of positive connectivity in spite of a user shutting it back off. (Also why I think it was a whorish kind of behaviour..  very solicitous.)
777 2013-02-06 08:43:04 <gmaxwell> petertodd: no we had tor support before the tor support you're thinking of.
778 2013-02-06 08:43:08 <midnightmagic> That's true. I'm really happy with the new functionality coming online.
779 2013-02-06 08:43:25 <gmaxwell> petertodd: the thing we added more recently is hidden service support... plain outbound proxy has worked for ~forever.
780 2013-02-06 08:43:26 <petertodd> gmaxwell: Ah, like, pure connect, no hidden service?
781 2013-02-06 08:43:52 <gmaxwell> right.
782 2013-02-06 08:44:10 <midnightmagic> petertodd: Run "bitcoind --help|grep proxy"   It's just socks proxy'ing.
783 2013-02-06 08:44:28 <gmaxwell> yea, we still support general proxying in addition to the tor specific stuff.
784 2013-02-06 08:45:16 <midnightmagic> Meaningless in the grand scheme of things, but the attitude was there.. only people who could compile stuff were, basically, allowed to change it.
785 2013-02-06 08:45:30 <petertodd> gmaxwell: Incidentally, it's interesting how popular the hidden service support is - my EC2 node that offers it consistently has dozens of incoming connections.
786 2013-02-06 08:45:50 <midnightmagic> that's pretty cool
787 2013-02-06 08:46:27 <petertodd> There are probably a lot of services out there running nodes that use tor to connect with for security.
788 2013-02-06 08:46:29 <midnightmagic> petertodd: How much bandwidth does that instance normally eat up?
789 2013-02-06 08:47:01 <gmaxwell> we need more nodes running, we also need to solve DOS attack problems with them.. all our anti-dos stuff now is predicated on being able to ban nodes that waste our time...
790 2013-02-06 08:47:10 <gmaxwell> but we can't ban a hidden service inbound. :(
791 2013-02-06 08:47:30 <gmaxwell> so the hidden service bitcoin network is more vulnerable.
792 2013-02-06 08:47:50 <midnightmagic> do we not have access to the remote identifier? we could force them to rekey for every new connection.
793 2013-02-06 08:48:03 <gmaxwell> petertodd: more impressive when you realize a dual stack node will only make at most one hidden service connection out.
794 2013-02-06 08:48:16 <gmaxwell> midnightmagic: nope, hidden services give you no inbound identifier.
795 2013-02-06 08:48:41 <midnightmagic> huh. I guess I'm spoiled by i2p
796 2013-02-06 08:49:16 <gmaxwell> besides, what would it be? 'it's anonymous!' :P
797 2013-02-06 08:49:16 <petertodd> gmaxwell: It's relatively bad, looking to be a GiB or two a day, and EC2 is $0.12/GiB
798 2013-02-06 08:49:33 <gmaxwell> EC2 bandwidth is super overpriced.
799 2013-02-06 08:50:12 <petertodd> gmaxwell: It's also a non-micro node, although I have the 3 year pre-paid option.
800 2013-02-06 08:50:31 <petertodd> gmaxwell: Yes it is, but it's also super reliable and easy to use.
801 2013-02-06 08:51:09 <petertodd> gmaxwell: I just got 25Mb down, 10Mb up internet at home, so I just unrestricted all my nodes in my apartment...
802 2013-02-06 08:52:00 <gmaxwell> yep... ctrl-r un-in<enter>  I HAZ A COMPUTER
803 2013-02-06 08:52:17 <petertodd> (I was running a tor node on joyent, about 50Mb sustained, but I figure I should focus my donations to the most technically sophisticated thing I know how to run)
804 2013-02-06 08:52:23 <gmaxwell> petertodd: I'm going to miss my 25/25 fios.
805 2013-02-06 08:52:24 <petertodd> gmaxwell: Isn't moving FUN!
806 2013-02-06 08:53:08 <petertodd> I didn't even have internet for almost the whole time I was a student.
807 2013-02-06 08:53:16 <gmaxwell> I guess I should find some cheap colo to run some stable tor and bitcoin nodes.
808 2013-02-06 08:53:24 <petertodd> I'd sit in the stairwell of my apartment stealing wifi...
809 2013-02-06 08:54:03 <petertodd> ...and another testnet seed would keep the conspiracy theorists away.
810 2013-02-06 08:54:06 <gmaxwell> petertodd: I'm on google wifi now. :P actually contemplating going internet access free at home for opsec and cost-hypermiling reasons, esp since the only option here appears to be quite costly and crapcastic comcast service.
811 2013-02-06 08:54:25 <gmaxwell> (It's not as if I was in the middle of silicon valley .. oh wait. WTF universe)
812 2013-02-06 08:54:53 <petertodd> lol, that's where you are now? with crappy internet?
813 2013-02-06 08:54:55 <MC1984> google wifi?
814 2013-02-06 08:55:08 <gmaxwell> MC1984: google runs free wifi in some places.
815 2013-02-06 08:55:19 <MC1984> damn
816 2013-02-06 08:55:35 <gmaxwell> petertodd: yea.
817 2013-02-06 08:57:22 <petertodd> Be funny if google was mainly doing that because the local internet sucked and their employees were complaining...
818 2013-02-06 09:20:03 <MC1984> What this code allows you to do is take a 8MB chunk of data and cut it into any number of 1MB chunks such that any eight of them can reconstruct the original data.
819 2013-02-06 09:20:16 <MC1984> Vandermonde matrixes
820 2013-02-06 09:20:17 <MC1984> what
821 2013-02-06 09:33:23 <Diablo-D3> MC1984: ....
822 2013-02-06 09:33:28 <Diablo-D3> so wait
823 2013-02-06 09:33:37 <Diablo-D3> 8mb of data in 8 1mb chunks requires the original 8
824 2013-02-06 09:33:51 <Diablo-D3> thats called naming the fucking files in the right order
825 2013-02-06 09:36:34 <CodeShark> add an index byte to each chunk and you don't even need to know the right order to reconstruct it :)
826 2013-02-06 09:37:18 <Diablo-D3> that wasnt the original terms
827 2013-02-06 09:37:24 <Diablo-D3> if Im allowed a header, then yes, that
828 2013-02-06 09:37:33 <Eliel> gmaxwell: regarding the conversation abit earlier. Have you thought about what would be the optimal block size for maximizing decentralization? Too high and decentralization suffers due to the high costs. Too low and decentralization suffers due to lack of interest, since people can't use the system personally.
829 2013-02-06 09:37:58 <CodeShark> I think the more interesting problem is breaking up m bytes of data into n chunks of size s such that any k chunks suffice to reconstruct m :)
830 2013-02-06 09:39:37 <CodeShark> RAID 3 is an example where n = 3, m = 2s, and k = 2
831 2013-02-06 09:40:10 <Diablo-D3> no, the solution to THAT problem is par2
832 2013-02-06 10:26:40 <X-Scale> <CodeShark> I think the more interesting problem is breaking up m bytes of data into n chunks of size s such that any k chunks suffice to reconstruct m :) -> http://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction
833 2013-02-06 10:27:12 <CodeShark> yeah, that kind of stuff :)
834 2013-02-06 12:25:42 <moarrr> Anyone here?
835 2013-02-06 12:25:56 <daybyter> Nope...
836 2013-02-06 12:26:15 <moarrr> daybyter: wanna play my higher or lower game?
837 2013-02-06 12:26:22 <daybyter> Nope...
838 2013-02-06 12:26:47 <daybyter> cannot play...have to develop...
839 2013-02-06 12:27:17 <moarrr> :) It will releive stress and reduce fatigue ...
840 2013-02-06 12:27:24 <moarrr> What are you working on ?
841 2013-02-06 12:27:40 <daybyter> A game and a trading app....
842 2013-02-06 12:30:15 <ne0futur> "all work and no play makes jack a dull boy"
843 2013-02-06 12:30:41 <daybyter> ok....if I play...would you code for me?
844 2013-02-06 12:30:43 <ne0futur> http://en.wikipedia.org/wiki/All_work_and_no_play_makes_Jack_a_dull_boy