1 2012-07-30 03:57:30 <jgarzik> good grief
  2 2012-07-30 03:57:34 <jgarzik> testnet3 chain grew overnight
  3 2012-07-30 03:58:49 <jgarzik> ERROR: mempool transaction missing input
  4 2012-07-30 03:58:50 <jgarzik> ERROR: mempool transaction missing input
  5 2012-07-30 03:58:57 <jgarzik> first line repeated at least 50 times
  6 2012-07-30 04:10:08 <jgarzik> in fact, testnet3 doubled since last I looked
  7 2012-07-30 04:10:23 <jgarzik> somebody over-mining testnet3 coins?
  8 2012-07-30 04:12:30 <jgarzik> looks like super-big reorg tests...  I have a bunch of generated orphans in my wallet
  9 2012-07-30 04:14:59 <luke-jr> jgarzik: gmaxwell IIRC
 10 2012-07-30 05:11:08 <zevus> hmm, i just had to firewall someone that was requesting a portion of the block chain over and over
 11 2012-07-30 05:11:32 <zevus> 07/29/12 21:25:26 receive version message: version 60001, blocks=191411, us=5.9.24.81:14493, them=99.67.160.106:8333, peer=99.67.160.106:8333
 12 2012-07-30 05:11:35 <zevus> 0
 13 2012-07-30 05:11:40 <zevus> 07/30/12 01:53:21 receive version message: version 60001, blocks=177777, us=5.9.24.81:8333, them=0.0.0.0:0, peer=99.67.160.106:32996
 14 2012-07-30 05:11:43 <zevus> same peer
 15 2012-07-30 05:12:26 <zevus> i think it had been going on for a few hrs, i'd think that it would autoban some person like that?
 16 2012-07-30 05:13:50 <zevus> or did it just detect wrong?  shrug... either way it kept requesting the same block piece over and over, it's in my log a thousand times
 17 2012-07-30 05:16:19 <zevus> 114.79.55.107      that IP as well
 18 2012-07-30 05:17:07 <gmaxwell> can you pastebin the actual log lines in question?
 19 2012-07-30 05:18:44 <zevus> well, i can't identify which was doing which... i ended up putting 5 IPs on hosts.deny  as they were the 5 that were transferring continuously, the 114.79.55.107 was constant mbit or so for 15minutes
 20 2012-07-30 05:20:33 <zevus> log is 200 megs, i'll look for it
 21 2012-07-30 05:21:02 <midnightmagic> i have a connection to that user also
 22 2012-07-30 05:21:31 <zevus> is there a way to get it to tell me who is requesting blocks?
 23 2012-07-30 05:21:36 <zevus> the 114.79.55.107 person?
 24 2012-07-30 05:22:06 <zevus> i mean i don't know if it was intentional or not...  the only one that really looked strange was the 99.67.160.106 one
 25 2012-07-30 05:23:46 <zevus> conn at 21:25, he has 191411 blocks, i have 191411 blocks.... discon at 1:25... conn at 1:53, he has 1777777, i have 191445
 26 2012-07-30 05:24:59 <midnightmagic> no, user 99.67.160.106
 27 2012-07-30 05:25:14 <midnightmagic> he might be having a blk* corruption issue of some sort.
 28 2012-07-30 05:25:44 <gmaxwell> zevus: is your complaint based entirely on the version message entries?
 29 2012-07-30 05:25:49 <zevus> no
 30 2012-07-30 05:25:57 <gmaxwell> midnightmagic: there might also be multiple computers behind a nat.
 31 2012-07-30 05:26:02 <zevus> it's from 3 hours or so of requesting blocks
 32 2012-07-30 05:26:24 <gmaxwell> Or someone is switching out and syncing up multiple chains (for some daft reason, e.g. thinking they have to swap the whole directory when they swap wallets).. or it could be a tor exit.
 33 2012-07-30 05:27:42 <zevus> well, i couldnt say if it was malicious, probably not
 34 2012-07-30 05:28:00 <zevus> but i guess it shouldn't let the same thing get requested over and over, one sec
 35 2012-07-30 05:28:38 <zevus> hmm
 36 2012-07-30 05:28:46 <zevus> i can just put the whole log up i guess, it's a bit unwieldy
 37 2012-07-30 05:29:55 <gmaxwell> some of the log messages are a bit misleading, I was asking for them just to see if it really was the same thing. :)
 38 2012-07-30 05:30:10 <MC-Eeepc> is there any way to make bitcoin use wherever it is running from as the datadir
 39 2012-07-30 05:30:26 <gmaxwell> We do ban nodes that misbehave but we must be very careful in what we allow to trigger banning, otherwise if you could trigger a node to misbehave you could do that to partition in from the network and then attack it.
 40 2012-07-30 05:30:44 <gmaxwell> MC-Eeepc: -datadir=`pwd`
 41 2012-07-30 05:31:00 <gmaxwell> (well thats where, you're running it from at least)
 42 2012-07-30 05:31:09 <MC-Eeepc> what does pwd mean
 43 2012-07-30 05:31:50 <gmaxwell> on real computers it prints the working directory.
 44 2012-07-30 05:32:12 <gmaxwell> On playschool computers you're on your own. :)  Though I expect there is a way to do that in windows too.
 45 2012-07-30 05:32:36 <zevus> ok, i cut out a portion of it.. but it was going on before and after also... like a 2hr snippet
 46 2012-07-30 05:32:40 <MC-Eeepc> atleast i dont use a mac
 47 2012-07-30 05:33:11 <gmaxwell> MC-Eeepc: these days macs are more like real computers than windows is. ;)
 48 2012-07-30 05:33:45 <MC-Eeepc> not the way most mac owners use them
 49 2012-07-30 05:34:21 <MC-Eeepc> i wuld try ubuntu but youd just make me feel bad about that too :(
 50 2012-07-30 05:35:43 <zevus> it probably was a corrupted DB or something, on that 99.67 guy anyway..  dunno what the point would be really since his transfer speed was slow
 51 2012-07-30 05:38:22 <zevus> http://nogleg.com/debug.log
 52 2012-07-30 05:39:37 <zevus> i believe it was 3 diff ppl
 53 2012-07-30 06:09:27 <gribble> New news from bitcoinrss: Diapolo opened pull request 1639 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1639>
 54 2012-07-30 06:21:56 <MC-Eeepc> why wont datadir work from a bitcoin.conf
 55 2012-07-30 06:22:50 <weex> MC-Eeepc: because the program would need to look in the default place and kind of restart with a datadir flag
 56 2012-07-30 06:23:26 <weex> might as well just force people to use the datadir flag when they run it
 57 2012-07-30 06:23:31 <weex> less confusing that way
 58 2012-07-30 06:23:46 <MC-Eeepc> i cant attatch flags to an .exe
 59 2012-07-30 06:24:09 <MC-Eeepc> only shortcuts
 60 2012-07-30 06:24:36 <weex> you aren't using cmd?
 61 2012-07-30 06:24:53 <weex> you can make a shortcut and put it all in quotes
 62 2012-07-30 06:25:53 <MC-Eeepc> ill look at the daemon now
 63 2012-07-30 06:26:00 <MC-Eeepc> some batch file fuckery might be in order
 64 2012-07-30 06:26:43 <MC-Eeepc> fffffffffffff i bought this usb stick so i could have some fast random access memory to server the blockchain from for as long as possible
 65 2012-07-30 06:26:58 <MC-Eeepc> and there isnt even a proper portable mode in bitcoin yet :(
 66 2012-07-30 06:33:22 <weex> you want fast, portable, presumably secure and you're planning on accessing this from multiple windows computers?
 67 2012-07-30 06:33:44 <weex> i barely want to let one windows computer ever see my wallet or any important passwords
 68 2012-07-30 06:33:57 <luke-jr> MC-Eeepc: um, USB flash is generally slow
 69 2012-07-30 06:35:29 <weex> never thought to put an ssd in an enclosure but that might be ok
 70 2012-07-30 06:36:05 <MC-Eeepc> faster than hard disks
 71 2012-07-30 06:36:17 <MC-Eeepc> for random access
 72 2012-07-30 06:36:31 <MC-Eeepc> its just a usb thumb drive
 73 2012-07-30 06:36:39 <weex> most thumb drives aren't
 74 2012-07-30 06:36:50 <weex> there's a lot of reading and writing going on with the blk*.dat files
 75 2012-07-30 06:37:05 <weex> and the 5-10mb/s for most usb thumb drives will surely make it slower
 76 2012-07-30 06:37:34 <weex> internal ssd can be 200mb/s, most spinning disk hds are 25-40mb/s
 77 2012-07-30 06:38:01 <weex> capitalize all those B's by the way
 78 2012-07-30 06:38:07 <weex> bytes not bits
 79 2012-07-30 06:38:34 <MC-Eeepc> sequential bandwidth is not a bottleneck as i understand
 80 2012-07-30 06:42:17 <MC-Eeepc> wow o bitcoind is just a blank cmd box with no output whatsoever
 81 2012-07-30 06:42:40 <MC-Eeepc> no verbose option or something
 82 2012-07-30 06:42:56 <MC-Eeepc> just go hunting around for debug.log if you want to know whats going on lel
 83 2012-07-30 06:43:00 <MC-Eeepc> really........
 84 2012-07-30 06:43:05 <weex> no you start it again with commands
 85 2012-07-30 06:43:10 <weex> so like "bitcoind getinfo
 86 2012-07-30 06:43:12 <weex> "
 87 2012-07-30 06:43:47 <MC-Eeepc> bitcoind is running and downloading blocks
 88 2012-07-30 06:44:11 <MC-Eeepc> but i can only tell that from watching the blk001 filesize
 89 2012-07-30 06:44:38 <weex> start another cmd and run bitcoind with the datadir switch and the command like getinfo
 90 2012-07-30 06:44:55 <MC-Eeepc> what does getinfo do
 91 2012-07-30 06:45:09 <weex> if you have a debian or ubuntu linux box, your bitcoin life will become richer and more secure i believe
 92 2012-07-30 06:45:12 <freewil> you probably want to do bitcoind -daemon so it runs in the background and returns to the shell prompt
 93 2012-07-30 06:45:22 <weex> shows latest block, balance
 94 2012-07-30 06:45:32 <weex> # of connections
 95 2012-07-30 06:45:37 <MC-Eeepc> cool thanks peeps
 96 2012-07-30 06:50:51 <MC-Eeepc> neither of those seems to do anything
 97 2012-07-30 06:50:57 <MC-Eeepc> still an empty black box
 98 2012-07-30 06:58:55 <MC-Eeepc> does bitcoin nactually have some sort of cmd line interface or am i missing something
 99 2012-07-30 07:03:52 <luke-jr> MC-Eeepc: bitcoind is a JSON-RPC server, for automation and stuff
100 2012-07-30 07:04:21 <luke-jr> there's also a testing tool builtin, but you need to run it separately
101 2012-07-30 07:23:31 <MC-Eeepc> luke-jr what is the testing tool?
102 2012-07-30 07:23:41 <MC-Eeepc> will it give me cmd line interface or something similar?
103 2012-07-30 07:24:27 <MC-Eeepc> alternatively, how do i access the json data in a manner similar to that
104 2012-07-30 07:45:10 <weex> MC-Eeepc: what language you want to access that data from? php and python scripts are easy to find
105 2012-07-30 07:45:57 <MC-Eeepc> whatever works on windows
106 2012-07-30 07:47:47 <MC-Eeepc> maybe il just stick with qt
107 2012-07-30 07:48:15 <MC-Eeepc> i thought bitcoind was a cmd line version, but its something else
108 2012-07-30 07:49:30 <weex> it's a daemon but it's also a program to talk to that daemon
109 2012-07-30 07:49:37 <jouke> What did you expect exactly?
110 2012-07-30 07:49:38 <weex> have you not gotten getinfo output yet?
111 2012-07-30 07:49:51 <jouke> Because everything can be done trough command line
112 2012-07-30 07:53:19 <MC-Eeepc> launching bitcoind.exe just gives me a cmd box with a single blinking cursor in it, and wont let me type anything in
113 2012-07-30 07:54:20 <jouke> Open an other cmd box
114 2012-07-30 07:54:38 <jouke> type "bitcoind.exe getinfo"
115 2012-07-30 08:01:04 <MC-Eeepc> haha, i cant navigate a cmd box into a truecrypt container
116 2012-07-30 08:03:45 <[\\]> you can if you assign it a drive
117 2012-07-30 08:04:08 <[\\]> or just just an ntfs junction point
118 2012-07-30 08:04:19 <[\\]> bitcoin-qt fresh sync ups suck
119 2012-07-30 08:04:28 <[\\]> running it via bitcoind is much faster
120 2012-07-30 08:04:56 <MC-Eeepc> it has a drive letter
121 2012-07-30 08:05:00 <sipa> it's exactly the same
122 2012-07-30 08:05:08 <MC-Eeepc> its mounted as a drive
123 2012-07-30 08:05:20 <[\\]> it took almost 4 hours with qt
124 2012-07-30 08:05:26 <[\\]> ust to get the first 40k
125 2012-07-30 08:05:33 <[\\]> having 12 connections
126 2012-07-30 08:05:36 <sipa> bitcoind or qt dordnt matter, the only difference is the UI code is not compiled in
127 2012-07-30 08:05:49 <[\\]> now I'm doing 1k in a few seconds
128 2012-07-30 08:05:56 <[\\]> my set of peers are static
129 2012-07-30 08:06:02 <[\\]> so its not the restart that fixed it
130 2012-07-30 08:06:08 <sipa> you may have accidentally selected a slow peer to download from
131 2012-07-30 08:06:55 <[\\]> well, I run 2/12 of the nodes I connect to
132 2012-07-30 08:07:03 <[\\]> so its not those
133 2012-07-30 08:07:06 <[\\]> perhaps one of the others
134 2012-07-30 08:07:33 <[\\]> or perhaps bitcoin qt is just slower than bitcoind, even if you say they are the same
135 2012-07-30 08:10:12 <sipa> that would surprise me :)
136 2012-07-30 08:10:24 <[\\]> sipa, will a client continue to download from the same peer for the entire process?
137 2012-07-30 08:10:26 <MC-Eeepc> does maxconnections only count if you have an open port
138 2012-07-30 08:10:39 <[\\]> or does it roundrobin?
139 2012-07-30 08:11:10 <sipa> it just uses the first one that works
140 2012-07-30 08:12:14 <MC-Eeepc> ha thats probably ripe for improvement in future
141 2012-07-30 08:19:04 <MC-Eeepc> so bitcoin pulls a couple hundred blocks, then pauses then continues
142 2012-07-30 08:19:06 <MC-Eeepc> is that normal
143 2012-07-30 08:19:20 <MC-Eeepc> seems to be going pretty fast but dont know why it pauses
144 2012-07-30 08:21:42 <[\\]> MC-Eeepc, yeah, the pauses are usually very short
145 2012-07-30 08:25:17 <MC-Eeepc> not just me then
146 2012-07-30 08:25:22 <MC-Eeepc> they add up
147 2012-07-30 08:36:54 <OneEyed> Noone from bitcoin-central.net around here? I think I've found some kind of a flaw in the site.
148 2012-07-30 09:16:35 <andyrossy> hey, to make a backup/restore a backup of blockchain, which files do I need?
149 2012-07-30 09:16:38 <andyrossy> just blk000?.dat ?
150 2012-07-30 09:16:44 <andyrossy> or blkindex.dat too?
151 2012-07-30 09:25:59 <Joric> we just hit a record breaking difficulty of all time
152 2012-07-30 09:26:05 <Joric> champagne anyone?
153 2012-07-30 09:38:45 <andyrossy> 2mirrion?
154 2012-07-30 09:38:46 <andyrossy> xD
155 2012-07-30 09:40:20 <Joric> 2.0366710886933 jigahashes!!
156 2012-07-30 09:40:35 <andyrossy> 1 point two one JIJAWATTS?!
157 2012-07-30 09:43:45 <RazielZ> Hey guys
158 2012-07-30 09:43:50 <RazielZ> I wanna get back into mining
159 2012-07-30 09:44:01 <RazielZ> What miner should I use on a gtx660 and i7 ivy core?
160 2012-07-30 09:44:08 <RazielZ> ivy bridge even
161 2012-07-30 09:44:11 <RazielZ> 4 cores 8 threads
162 2012-07-30 09:45:20 <andyrossy> ask in #bitcoin might be better ~~
163 2012-07-30 09:45:26 <RazielZ> mmmk thanks
164 2012-07-30 10:00:23 <TD> justmoon: i figured it out
165 2012-07-30 10:00:48 <TD> justmoon: stupid bugs in the loading code which i somehow managed to never test :(
166 2012-07-30 10:01:46 <TD> although i'm still seeing shitty performance on my laptop for some reason
167 2012-07-30 10:03:12 <epscy> ;;bc,stats
168 2012-07-30 10:03:13 <gribble> Current Blocks: 191527 | Current Difficulty: 2036671.0886933 | Next Difficulty At Block: 193535 | Next Difficulty In: 2008 blocks | Next Difficulty In About: 1 week, 0 days, 1 hour, 33 minutes, and 52 seconds | Next Difficulty Estimate: 6175653.65940787 | Estimated Percent Change: 203.222925572
169 2012-07-30 10:03:58 <epscy> ;;bc,diffchange
170 2012-07-30 10:03:59 <gribble> Estimated percent change in difficulty this period | 203.222925572 % based on data since last change | 10.4019152406 % based on data for last three days
171 2012-07-30 11:03:48 <MC-Eeepc> welp ground to a halt at 62000 blocks
172 2012-07-30 11:04:18 <MC-Eeepc> still seems to clog up then go through 10 blocks quickly then clog up again
173 2012-07-30 11:04:42 <MC-Eeepc> or maybe the counter is just now wholly accurate
174 2012-07-30 11:04:54 <MC-Eeepc> but i would have though each block would take roughly the same time to validate
175 2012-07-30 11:05:18 <MC-Eeepc> i mean each block near to each other, not over the whole chain
176 2012-07-30 11:26:23 <ersi> MC-Eeepc: Let it run, it'll complete
177 2012-07-30 11:27:16 <ersi> MC-Eeepc: If you're on Linux/Mac, you could tail -f .bitcoin/debug.log and see how it's doing for sure in real time (which is, before the actual GUI)
178 2012-07-30 11:27:49 <MC-Eeepc> windows
179 2012-07-30 11:28:08 <ersi> You could open up the debug.log in a editor and re-open occationally to see it progress then
180 2012-07-30 11:28:08 <MC-Eeepc> this intel atom is starting to struggle maybe
181 2012-07-30 11:28:18 <MC-Eeepc> though its not even 100% usage
182 2012-07-30 11:28:26 <ersi> Well, it's pretty well known that EEEPc + Bitcoin = slow
183 2012-07-30 11:28:30 <ersi> :D
184 2012-07-30 11:28:41 <ersi> But yeah, initial sync *can* be quite slow
185 2012-07-30 11:28:41 <MC-Eeepc> and the chain is going into a flash drive so ultra fast random access
186 2012-07-30 11:29:00 <ersi> It *can* also be quite fast.. It depends.
187 2012-07-30 11:29:02 <MC-Eeepc> and the blocks are still small enough
188 2012-07-30 11:29:09 <MC-Eeepc> where is the damn bottleneck#
189 2012-07-30 11:29:27 <jgarzik> at the top of the bottle
190 2012-07-30 11:29:37 <MC-Eeepc> huehue
191 2012-07-30 11:29:58 <MC-Eeepc> totally stalled on 61467 blocks
192 2012-07-30 11:30:40 <jgarzik> mainnet orphan last night led pynode astray
193 2012-07-30 11:30:43 <MC-Eeepc> the workhouse?
194 2012-07-30 11:33:51 <MC-Eeepc> i regret trying to open debug.log at this point
195 2012-07-30 11:56:55 <Ferroh> Is it possible to have a "brain wallet" type mechanism, where you have two passwords: A public one that generates only public keys for the wallet. A private one that generates both public and private keys for the wallet?
196 2012-07-30 11:57:17 <Ferroh> it doesnt seem possible, but I thought i'd ask
197 2012-07-30 11:57:48 <quintopia> yeah no
198 2012-07-30 11:58:29 <Ferroh> what?
199 2012-07-30 11:59:13 <Eliel> Ferroh: in a way, yes, if you consider the public key itself the password :P But that kind of defeats what you were going for I think :)
200 2012-07-30 11:59:32 <epscy> brain wallets are silly
201 2012-07-30 12:00:08 <Ferroh> Eliel, heh, ok thanks
202 2012-07-30 12:00:12 <Eliel> Ferroh: besides, why would you need a password to generate just the public key? Would it not be easier to just save the public key?
203 2012-07-30 12:00:31 <epscy> but then you wouldn't be using your brain!
204 2012-07-30 12:00:45 <Ferroh> epscy, this has nothing to do with using your brain, as per my original comment.
205 2012-07-30 12:01:22 <Ferroh> Eliel, There are a few reasons, but mainly because you might want to be able to generate a new public address for a user, without having access to the private keys (so you cant be compromised)
206 2012-07-30 12:02:13 <Eliel> Ferroh: you could always use the deterministic wallet model. secret passphrase for generating the seed.
207 2012-07-30 12:02:13 <Ferroh> For example, business sites that want to accept coins without having a client running could use this to generate public keys for the users
208 2012-07-30 12:02:18 <Ferroh> it would be extremely useful imo
209 2012-07-30 12:02:36 <Ferroh> Eliel, ... but then you are storing the secret passphrase, which can be compromised.
210 2012-07-30 12:02:42 <Ferroh> that defeats the point, unfortunately :(
211 2012-07-30 12:02:46 <quintopia> you could have the generator wipe the private key number from memory as soon as it generates it. then you would only be compromisable for less than a second
212 2012-07-30 12:03:13 <Eliel> Ferroh: the deterministic wallet model can generate new addresses from just the public key of the seed
213 2012-07-30 12:03:14 <Ferroh> quintopia, less than a second is the same as 1 million seconds for an attacker that has compromised your machine
214 2012-07-30 12:03:45 <quintopia> Ferroh: it would be much less than a second, and it would pobably never hit RAM. ~1ms probably
215 2012-07-30 12:03:52 <Ferroh> Eliel, oh... then that is the public password I was asking about. So the answer to my question is yes
216 2012-07-30 12:04:15 <quintopia> Eliel: ?
217 2012-07-30 12:04:18 <Ferroh> quintopia, You have to give the private seed to the server, so it of course would hit a lot more than just RAM
218 2012-07-30 12:04:46 <quintopia> Ferroh: oh yeah, the seed. right.
219 2012-07-30 12:05:35 <Eliel> Ferroh: take a look at http://acceptbit.com/
220 2012-07-30 12:06:32 <Ferroh> Eliel, that solves nothing
221 2012-07-30 12:07:11 <Eliel> Ferroh: so, what is the problem you're trying to solve?
222 2012-07-30 12:07:14 <quintopia> what is master public key?
223 2012-07-30 12:07:17 <Ferroh> Eliel, the goal is to have a server that can generate public keys that does not have private keys. If the deterministic wallet model can do that, then the problem is solved. I'm not sure that it can though
224 2012-07-30 12:07:52 <jgarzik> Ferroh: HD wallets can do that: https://en.bitcoin.it/wiki/BIP_0032
225 2012-07-30 12:07:56 <quintopia> Ferroh: i dont think it is cryptographically possible, what you really want
226 2012-07-30 12:07:59 <Eliel> Ferroh: that's exactly what it does. You do have to generate the private master key (or seed) on some system to get the public one though.
227 2012-07-30 12:08:30 <quintopia> Eliel: i dont understand
228 2012-07-30 12:08:31 <Eliel> after you have the master public key, though, you only need the master private key to spend the coins.
229 2012-07-30 12:08:34 <Ferroh> jgarzik, ah, yeah I heard about that BIP. It's not implemented though.
230 2012-07-30 12:09:00 <Ferroh> quintopia, That's what I thought too. Two people just told us that it is though :)
231 2012-07-30 12:09:36 <Eliel> quintopia: it is cryptographically possible.
232 2012-07-30 12:09:39 <quintopia> Ferroh: i'm waiting on an explanation
233 2012-07-30 12:11:02 <quintopia> okay thats how it does it "elliptic curve mathematics"
234 2012-07-30 12:12:07 <jrmithdobbs> quintopia: ya, gmaxwell has it written up somewhere very detailed, but it's a bunch of fancy math that does basically what he's looking for, ha
235 2012-07-30 12:12:13 <Joric> Bitcoin Wallet HD!
236 2012-07-30 12:12:16 <Joric> sounds cool
237 2012-07-30 12:12:34 <Ferroh> Apart from HD wallets which are not implemented anywhere AFAIK, can we do this using electrum right now? is acceptbit the only place that has done this?
238 2012-07-30 12:12:41 <jrmithdobbs> (in short highly offensive summary/high level words, anyways ;p)
239 2012-07-30 12:12:43 <Eliel> quintopia: say, for example, that you have private key A and corresponding public key a. Now, let's assume we have some modifier, for example a hash of a serial number. You can now combine the hash and a to make a new public key b. You can also combine the hash and A to make B, the corresponding private key.
240 2012-07-30 12:12:44 <Ferroh> I guess I can go look at the electrum source
241 2012-07-30 12:13:22 <jrmithdobbs> Eliel: yes i think electrum has a version of it implemented. But it's pretty straight forward and not too hard to implement
242 2012-07-30 12:14:32 <Eliel> I remember seeing the mathematical explanation of how this works on bitcointalk.org forum thread somewhere.
243 2012-07-30 12:15:09 <jrmithdobbs> err I meant ferroh, but w/e, I really have to take bitcoin and bitcoin-dev out of the same window, hard to follow with all the lolbertarian spam ;p
244 2012-07-30 12:15:34 <Eliel> lolbertarian :D
245 2012-07-30 12:15:36 <Joric> Ferroh, http://brainwallet.org/#chains <- both electrum and armory
246 2012-07-30 12:15:46 <quintopia> Eliel: i read the above BIP. i will study it further later.
247 2012-07-30 12:21:33 <Ferroh> Joric, the tool you just linked doesn't have the feature I want.
248 2012-07-30 12:22:13 <Ferroh> (the ability to generate public keys without the private seed)
249 2012-07-30 12:23:01 <gribble> New news from bitcoinrss: MatthewLM opened issue 1640 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1640>
250 2012-07-30 12:26:16 <jgarzik> gavinandresen: got Mountain Lion yet? :)
251 2012-07-30 12:35:17 <Joric> Ferroh, extend_chain has fromPrivKey=true/false
252 2012-07-30 12:38:50 <Ferroh> Joric, oh beautiful, thanks
253 2012-07-30 12:40:20 <Ferroh> what feature do HD wallets hypothetically bring to the table that this cannot do?
254 2012-07-30 12:40:56 <Ferroh> I guess I can just go read the BIP
255 2012-07-30 12:41:19 <Eliel> Ferroh: standardised implementation perhaps?
256 2012-07-30 12:42:03 <Ferroh> Eliel, the ability to share portions of the public keys and not all using a heirarchy of master public keys I think
257 2012-07-30 12:42:40 <Eliel> well, even that uses the same algo from what I can see.
258 2012-07-30 12:42:56 <Ferroh> except it adds the heirarchy part
259 2012-07-30 12:43:02 <Ferroh> not that it is necessarily hard to do that
260 2012-07-30 12:43:14 <Ferroh> but yes maybe you're right, maybe the main benefit is the standardization
261 2012-07-30 12:44:17 <Ferroh> Eliel, https://en.bitcoin.it/w/images/en/3/36/BIP32-derivation.png is a tree, but electrum/armory deterministic wallets are just one branch of that tree really
262 2012-07-30 12:45:14 <Eliel> yes, it's like several wallets in one.
263 2012-07-30 14:03:57 <justmoon> TD: just saw your message from ealier - cool!
264 2012-07-30 14:06:09 <TD> justmoon: the code was just bugged
265 2012-07-30 14:06:49 <justmoon> glad it was an easy fix and not something env_boost related
266 2012-07-30 14:06:53 <TD> right :)
267 2012-07-30 14:07:08 <TD> i guess somehow i never ran it twice. wish i had enough time to do a good job of all this
268 2012-07-30 14:07:54 <justmoon> it happened reliably on the second run every time?
269 2012-07-30 14:08:38 <justmoon> wow can't believe I didn't notice that either - I guess I usually used a restart as an opportunity to test the migration again ^^
270 2012-07-30 14:23:59 <Ferroh> gavinandresen, https://bitcointalk.org/index.php?topic=1026.0 why do you return the integer version of an address when the address is valid? Why not just return "valid" or whatever? is it just for fun or what?
271 2012-07-30 14:24:09 <Ferroh> i.e. what is the point of knowing the integer version of an address
272 2012-07-30 14:24:20 <Ferroh> also, sorry if it's bad form to highlight you :)
273 2012-07-30 14:27:08 <Joric> i'd use js version http://pastebin.com/B5r3P5Ny
274 2012-07-30 14:27:26 <Ferroh> why?
275 2012-07-30 14:27:50 <Ferroh> well, i guess the answer to that is kind of obvious
276 2012-07-30 14:27:54 <Ferroh> ok I'll use both.
277 2012-07-30 14:28:08 <Joric> less server load
278 2012-07-30 14:28:20 <Ferroh> yeah, thanks Joric :)
279 2012-07-30 14:30:03 <justmoon> Joric: I'd recommend using the latest version: https://github.com/bitcoinjs/bitcoinjs-lib/tree/master/src
280 2012-07-30 14:30:19 <justmoon> I've made a few improvements since bitaddress copied my code :)
281 2012-07-30 14:30:27 <Joric> justmoon, there's no jslib used, sorry pal
282 2012-07-30 14:30:39 <Joric> maybe partially )
283 2012-07-30 14:31:03 <justmoon> the code you posted is mine almost verbatim
284 2012-07-30 14:31:46 <Joric> yeah thanks for base58
285 2012-07-30 14:33:47 <Joric> justmoon, what's with minified version it's still 8 months old
286 2012-07-30 14:34:56 <justmoon> Joric: good point
287 2012-07-30 14:36:00 <Joric> justmoon, oh about the point conversion
288 2012-07-30 14:36:29 <Joric> justmoon, libssl originally just sets an internal flag if it's compressed or not
289 2012-07-30 14:37:01 <Joric> maybe bitcoinjs should the same just for consistency
290 2012-07-30 14:37:17 <gavinandresen> Ferroh: it returns the integer version so you can warn your users that they're trying to use a testnet address on main net (or vice-versa)
291 2012-07-30 14:37:32 <Joric> it's literally just EC_KEY_set_conv_form(POINT_CONVERSION_COMPRESSED / POINT_CONVERSION_UNCOMPRESSED)
292 2012-07-30 14:37:33 <Ferroh> gavinandresen, how does one determine that from the int?
293 2012-07-30 14:37:49 <gavinandresen> 111 is a testnet address
294 2012-07-30 14:37:56 <Ferroh> gavinandresen, thankyou :)
295 2012-07-30 14:38:31 <gavinandresen> Ferroh: also see https://en.bitcoin.it/wiki/BIP_0013
296 2012-07-30 14:38:40 <justmoon> Joric: I could let people set a default, that the lib will use if compressed === undefined
297 2012-07-30 14:43:46 <Joric> oh, it's not global it's per key EC_KEY_set_conv_form(key, form)
298 2012-07-30 14:44:41 <justmoon> ahh I see, hmm
299 2012-07-30 14:45:14 <justmoon> I don't think that's a good idea to be honest, in C/C++ I can see why you'd do it, but in JavaScript you can pass a parameter during encoding just fine
300 2012-07-30 14:45:45 <justmoon> otherwise you have the possibility that one part of your application sets the key type to compressed and another still expects uncompressed
301 2012-07-30 14:46:25 <justmoon> can you apply this patch to the paste? https://github.com/bitcoinjs/bitcoinjs-lib/commit/c952aaeb3ee472e3776655b8ea07299ebed702c7
302 2012-07-30 14:46:40 <justmoon> it fixes some issues where the base58 accepted invalid addresses as valid
303 2012-07-30 14:47:34 <justmoon> also a notice that the Bitcoin Base56 and the Bitcoin.Address are from bitcoinjs wouldn't kill you
304 2012-07-30 14:47:44 <justmoon> Base58*
305 2012-07-30 14:49:01 <jgarzik> luke-jr: random FWIW...  I think your CheckBlock split into CheckBlockHeader / CheckBlockBody (or whatever you called it) was good enough to be in a separate logical commit
306 2012-07-30 14:49:04 <jgarzik> and pushed upstream
307 2012-07-30 14:49:39 <gmaxwell> 07:14 < Eliel> I remember seeing the mathematical explanation of how this works on bitcointalk.org forum thread somewhere.
308 2012-07-30 14:49:42 <gmaxwell> https://bitcointalk.org/index.php?topic=19137.0
309 2012-07-30 14:51:56 <jgarzik> sigh
310 2012-07-30 14:52:07 <jgarzik> Satoshi just punted on weak-chain checking :(
311 2012-07-30 14:52:19 <jgarzik> see InvalidChainFound() and the reasons for calling InvalidChainFound()...
312 2012-07-30 14:53:28 <CodesInChaos> btw. how do nodes know how large a block is/how deep the hash tree is?
313 2012-07-30 14:53:47 <jgarzik> Example case:  main chain grows to height 100.  weak chain begins growing at height 90... but the weak chain includes some invalid transactions
314 2012-07-30 14:54:05 <CodesInChaos> I didn't see any header field for that, and from what I read there is no separate leaf hash either
315 2012-07-30 14:54:14 <jgarzik> if the weak chain grows strong enough to overtake the main chain...  we see weak chain become strong, try to switch to it, then shit ourselves when that fails
316 2012-07-30 14:54:32 <jgarzik> seems like a viable remote attack
317 2012-07-30 14:55:22 <jgarzik> This is why I was thinking about analogues to filesystem snapshots.  That's really what each fork wants, its own, valid txindex.
318 2012-07-30 14:55:59 <jgarzik> then you can be certain each fork is a valid chain, be certain you're not dumping weak garbage into the block db/index
319 2012-07-30 14:56:01 <justmoon> jgarzik: leveldb has a snapshot feature: http://leveldb.googlecode.com/svn/trunk/doc/index.html
320 2012-07-30 14:56:11 <justmoon> would be interesting to see if the leveldb branch can support something like that
321 2012-07-30 14:56:13 <jgarzik> justmoon: really??  hmmmm ;)
322 2012-07-30 14:56:17 <justmoon> and what the performance is like
323 2012-07-30 14:57:13 <gmaxwell> jgarzik: thats tricky because you'd need to be COW for that... otherwise N stubs would use N storage.  A simpler alternative is reorging, catching the violation then making a note that the block is bad and that you should ignore any blocks past it. Then trigger a reorg again an you'll end up on the right chain.
324 2012-07-30 14:57:19 <justmoon> I don't think it can do branching snapshots though - at least not without modifying the library
325 2012-07-30 14:57:48 <Joric> justmoon, i don't see why, it doesn't use validRegex and throws just fine as as
326 2012-07-30 14:58:48 <Joric> also those two lines comeon you're not oracle
327 2012-07-30 14:58:51 <justmoon> ignore the regex, the important line is the if (alphaIndex < 0)
328 2012-07-30 14:59:05 <justmoon> if you feed it a character that isn't in alphabet indexOf will return -1
329 2012-07-30 14:59:19 <justmoon> which BigInteger.valueOf will accept and continue
330 2012-07-30 14:59:40 <justmoon> if the checksum is made to match that invalid result, the function will accept it as a valid address
331 2012-07-30 14:59:58 <Joric> good point (i guess)
332 2012-07-30 15:00:09 <justmoon> [Tycho] pointed out somebody submitted such an address to his pool
333 2012-07-30 15:00:20 <justmoon> (bitcoin-php had the same bug)
334 2012-07-30 15:00:59 <jgarzik> gmaxwell: yep
335 2012-07-30 15:01:19 <jgarzik> gmaxwell: kernel filesystems already do such COW fun
336 2012-07-30 15:01:29 <jgarzik> I wonder if there is a userspace lib-btrfs...
337 2012-07-30 15:01:45 <Joric> justmoon, updated http://pastebin.com/B5r3P5Ny
338 2012-07-30 15:02:06 <gmaxwell> jgarzik: I'm pretty sure that BTRFS's cow is not rugged enough for a hostile party being able to trigger snapshots. :)
339 2012-07-30 15:02:14 <justmoon> Joric: thanks :)
340 2012-07-30 15:02:25 <justmoon> I updated the compiled version too
341 2012-07-30 15:02:28 <jgarzik> gmaxwell: snapshot-every-change is one of their stress tests :)
342 2012-07-30 15:02:43 <Joric> god i hate this attribution thing it's so annoying
343 2012-07-30 15:02:49 <Joric> better be pirate
344 2012-07-30 15:02:58 <gmaxwell> jgarzik: The simple block blacklist is still simpler.
345 2012-07-30 15:03:03 <jgarzik> gmaxwell: agreed :)
346 2012-07-30 15:03:24 <jgarzik> gmaxwell: I'm certainly not proposing swapping out bdb for libtrfs in the satoshi client :)
347 2012-07-30 15:04:05 <jgarzik> gmaxwell: it does explain why some nodes might get stuck on a weak chain
348 2012-07-30 15:04:17 <jgarzik> satoshi did not do the reorg-back part
349 2012-07-30 15:04:28 <gmaxwell> jgarzik: I _really_ thought the code would recover once the real chain got another block. :(
350 2012-07-30 15:05:23 <gmaxwell> (e.g. it would go up the fork.. get stuck. New block comes in "oh this other chain is longer" and switch. though it would also switch back if the longer bad chain got another block)
351 2012-07-30 15:12:30 <jgarzik> gmaxwell: looks like you're right.  it should get unstuck if another chain regains the lead.
352 2012-07-30 15:12:55 <jgarzik> so the node is merely stuck temporarily
353 2012-07-30 15:14:18 <luke-jr> 2012-07-30 17:05:05,701     JSONRPCServer   INFO    Longpoll woke up 23929 clients in 9.274 seconds
354 2012-07-30 15:14:22 <luke-jr> %*(#% botnets -.-
355 2012-07-30 15:14:53 <luke-jr> any ideas on how one might optimize this? :|
356 2012-07-30 15:14:55 <jgarzik> luke-jr: what kernel interface does that use under the hood?  epoll? select? poll?
357 2012-07-30 15:15:41 <luke-jr> jgarzik: the main loop is epoll, but the longpoll sending is just non-blocking send()
358 2012-07-30 15:16:01 <luke-jr> (if it would block, it waits for the main loop to say it's writable)
359 2012-07-30 15:16:03 <jgarzik> luke-jr: and, do you send the same memory buffer to each client (containing the HTTP response)?
360 2012-07-30 15:16:20 <luke-jr> jgarzik: unlikely, it's Python :p
361 2012-07-30 15:16:43 <jgarzik> luke-jr: python assignment copies a reference, so it's feasible
362 2012-07-30 15:16:57 <luke-jr> I think it's serializing the JSON every time too
363 2012-07-30 15:17:01 <luke-jr> to JSON*
364 2012-07-30 15:20:40 <Ferroh> how the hell does python do this???
365 2012-07-30 15:21:07 <Ferroh> you can see that the "address" variable is "1B3WhwWtRLZrpwSRabTqu9MMPTB9Fz8o8" from the first print statement
366 2012-07-30 15:21:18 <Ferroh> yet the re.match outputs "None" the first time
367 2012-07-30 15:21:33 <Ferroh> but if I do the same re.match again but give it the string literal, then it works?
368 2012-07-30 15:21:37 <luke-jr> the literal is not the same
369 2012-07-30 15:21:44 <Ferroh> apparently not
370 2012-07-30 15:21:45 <Ferroh> why though?
371 2012-07-30 15:21:55 <luke-jr> it even looks different
372 2012-07-30 15:22:04 <luke-jr> though, I don't know why the match fails
373 2012-07-30 15:22:06 <Ferroh> oh, im missing a char.. i dont think that matters though
374 2012-07-30 15:22:07 <Ferroh> let me check
375 2012-07-30 15:22:21 <Ferroh> yeah that makes no difference
376 2012-07-30 15:23:21 <luke-jr> print a2b_hex(address)
377 2012-07-30 15:24:21 <jgarzik> luke-jr: pre-build one HTTP response, then foreach(client) { send }
378 2012-07-30 15:24:39 <jgarzik> luke-jr: it will be under 1 second
379 2012-07-30 15:24:39 <luke-jr> jgarzik: they all need different data tho :/
380 2012-07-30 15:24:59 <jgarzik> luke-jr: sucks to be you then ;-)
381 2012-07-30 15:27:19 <Ferroh> luke-jr> print a2b_hex(address)" was that directed at me? "TypeError: Non-hexadecimal digit found"
382 2012-07-30 15:30:30 <jgarzik> it will be interesting replicating Reorganize() and SetBestChain() in gdbm with no transactions... ;)
383 2012-07-30 15:31:37 <luke-jr> Ferroh: sorry, b2a_hex
384 2012-07-30 15:32:08 <Ferroh> luke-jr, c2963142335768775774524c5a72707753526162547175394d4d50544239467a386f3876
385 2012-07-30 15:32:39 <Ferroh> oh...
386 2012-07-30 15:32:42 <Ferroh> they are not the same
387 2012-07-30 15:32:57 <luke-jr> 00000000  c2 96 31 42 33 57 68 77  57 74 52 4c 5a 72 70 77  |..1B3WhwWtRLZrpw|
388 2012-07-30 15:32:58 <luke-jr> 00000010  53 52 61 62 54 71 75 39  4d 4d 50 54 42 39 46 7a  |SRabTqu9MMPTB9Fz|
389 2012-07-30 15:33:00 <luke-jr> 00000020  38 6f 38 76 0a                                    |8o8v.|
390 2012-07-30 15:39:02 <Ferroh> sigh it doesnt even matter, even if I fix that argv encoding issue, gavin's python script is returning "0" as the integer address of a valid bitcoin address
391 2012-07-30 15:39:11 <Ferroh> so this is taking up too much time, i'll stick with the bash script crap that i have
392 2012-07-30 15:39:41 <luke-jr> Isn't 0 right?
393 2012-07-30 15:39:43 <gavinandresen> 0 is the version, and that is a main-network ordinary address...
394 2012-07-30 15:39:54 <Ferroh> oh, so that is correct output?
395 2012-07-30 15:39:55 <gavinandresen> (so it is probably working perfectly)
396 2012-07-30 15:40:00 <Ferroh> oh ok, sorry :)
397 2012-07-30 15:40:55 <Ferroh> sigh ok i'll try to fix this encoding issue then
398 2012-07-30 16:47:29 <jgarzik> oh, very nice!  I can have super-long conditionals in python, if I enclosed the entire expression in parens.
399 2012-07-30 16:47:51 <jgarzik> (super-long == multi-line, not byte count)
400 2012-07-30 16:55:31 <CCCP> what effect do dup. blocks have in invs?
401 2012-07-30 16:56:07 <jgarzik> kicking getblocks on remote to continue
402 2012-07-30 17:12:16 <imsaguy> <jgarzik> (super-long == multi-line, not byte count)  << that is a long password ;)
403 2012-07-30 17:14:32 <Ferroh> jgarzik, why would you want a super-long conditional?
404 2012-07-30 17:15:25 <Ferroh> also if you need multiline conditionals, cant you just put a  at the end of each part of the condition and continue the condition on the next line?
405 2012-07-30 17:26:43 <jgarzik> hurrah.  IBD is finally full speed in pynode.
406 2012-07-30 17:27:20 <jgarzik> employing satoshi's crafty "let the node get stuck" method of handling chain reorg failure should work, too
407 2012-07-30 17:42:36 <gmaxwell> luke-jr: please don't write a BIP to expand the nonce space and screw up our block versioning in the process. :(  We need that versioning for future upgrades, and the existing nonce already gives you a 4 billion to 1 speedup on coinbase generation operations.
408 2012-07-30 17:42:55 <gmaxwell> Reducing it further will only disincentivize frequently updating the coinbase to update transactions.
409 2012-07-30 17:43:55 <gmaxwell> 1MH/s of coinbase generation (which should be trivial since a desktop CPU can mine about about 3MH/s core) is good for 4294 TH/s of work generation.
410 2012-07-30 17:44:22 <gmaxwell> Having to give up one boring desktop core per 4000 TH/s of mining seems pretty good to me.
411 2012-07-30 17:44:36 <gmaxwell> (and thats ignoring ntime rolling, which multiplies it further)
412 2012-07-30 17:46:23 <luke-jr> gmaxwell: Gavin apparently disagrees; and it's not 1 MH/s, it's 1,000,000 getworks/s - that's a lot of bandwidth
413 2012-07-30 17:47:31 <gmaxwell> The concern about this is driven by a mixture of paranoia and lazyness by people operating bad centeralized systems that don't want to change any of the mining protocols for new hardware. It's a bad motivation. Changing from getwork to getmemorypool fixes it trivially, and doesn't even greatly increase bandwidth if all you do is allow the client to advance the extranonce. (because it wouldn't have to return the whole block)
414 2012-07-30 17:48:18 <gmaxwell> luke-jr: I wasn't aware that someone was planning on supporting 4 petahash anytime soon...
415 2012-07-30 17:48:45 <luke-jr> gmaxwell: apparently a lot of miners don't like the load entailed in running work-making proxies :/
416 2012-07-30 17:48:52 <luke-jr> gmaxwell: with 1 TH/s per SC MiniRig&
417 2012-07-30 17:49:15 <gmaxwell> "Load" which could be done on a little tiny arm computer.
418 2012-07-30 17:50:05 <gmaxwell> (at least with an efficient workmaker)
419 2012-07-30 17:50:22 <luke-jr> gmaxwell: I suppose if they're not required to run bitcoind&
420 2012-07-30 17:50:30 <gmaxwell> Right. They wouldn't have to be.
421 2012-07-30 17:50:54 <luke-jr> but without a local bitcoind, GMP isn't much more secure than getwork really
422 2012-07-30 17:51:10 <luke-jr> since there's no way to verify the transactions
423 2012-07-30 17:51:19 <gmaxwell> And seriously. You're telling me to worry about someone who has a $30,000 piece of specialized hardware... who doesn't want to run a $50 arm cpu worth of processing to make it go. Please wait while a pay a sad song for you on my virtual violin. :)
424 2012-07-30 17:51:21 <luke-jr> unless maybe jgarzik's pynode fills that void&
425 2012-07-30 17:51:31 <luke-jr> lol
426 2012-07-30 17:51:49 <gmaxwell> luke-jr: it's still a move in the right direction though if the data is sent you could optionally run a node to validate it.
427 2012-07-30 17:51:59 <gmaxwell> e.g. like bitpenny.
428 2012-07-30 17:52:01 <luke-jr> I suppose
429 2012-07-30 17:52:22 <luke-jr> gmaxwell: speaking of which, get a chance to look at the refactored BIP?
430 2012-07-30 17:52:27 <gmaxwell> s/while a pay/while I play/
431 2012-07-30 17:53:55 <gmaxwell> Yes, big improvement. I do think that _all_ of the optional parts should be moved to another document. (and stubbed in with a section which says "there are optional things for X/Y/Z look over here")
432 2012-07-30 17:55:17 <luke-jr> gmaxwell: what would you call 2.4-2.6?
433 2012-07-30 17:57:42 <gmaxwell> luke-jr: right, "Mining extensions to getmemorypool [BIPxx]"?
434 2012-07-30 17:57:54 <gmaxwell> bbl
435 2012-07-30 17:58:16 <luke-jr> gmaxwell: but& the whole thing is mining XD
436 2012-07-30 17:58:26 <luke-jr> sipa: wb
437 2012-07-30 17:58:27 <gmaxwell> sipa: WELCOME BACK
438 2012-07-30 17:58:31 <luke-jr> sipa: I missed you :P
439 2012-07-30 17:58:44 <gmaxwell> luke-jr: er. "pooling extensions", you've got me.
440 2012-07-30 17:58:53 <sipa> luke-jr: eh...
441 2012-07-30 17:59:15 <luke-jr> gmaxwell: those extensions have nothing to do with pooling ;)
442 2012-07-30 18:01:15 <luke-jr> I suppose maybe Core, Fundamentals, Pooled Mining
443 2012-07-30 18:22:21 <luke-jr> gmaxwell: how shall I split it if genjix refuses to cooperate with it?
444 2012-07-30 18:22:51 <gmaxwell> :(
445 2012-07-30 18:23:27 <gmaxwell> I'd say "I can't see why he would" but he didn't want to BIP GMP in the first place, I think.
446 2012-07-30 18:23:48 <Diablo-D3> gmaxwell: hey
447 2012-07-30 18:23:50 <Diablo-D3> if I wrote a video codec
448 2012-07-30 18:23:59 <Diablo-D3> how many companies would immediately sue me?
449 2012-07-30 18:24:04 <Diablo-D3> a dozen? two?
450 2012-07-30 18:24:39 <gmaxwell> Companies don't sue, for the most part. They theraten to sue and quitely collect hush money. And because you have no money they'd likely leave _you_ alone.
451 2012-07-30 18:25:05 <Diablo-D3> really?! sweet!
452 2012-07-30 18:25:12 <Diablo-D3> finally, being poor works!
453 2012-07-30 18:25:40 <Diablo-D3> I dunno, I'm just tired of how video codecs work
454 2012-07-30 18:25:43 <gmaxwell> Diablo-D3: if you want to work on video, then please join us on Daala.  http://xiph.org/daala/
455 2012-07-30 18:26:08 <Diablo-D3> daala sucks for one reason
456 2012-07-30 18:26:26 <Diablo-D3> its still thinking the mpeg way
457 2012-07-30 18:26:31 <luke-jr> gmaxwell: he's trolling about process, wants the discussion on the ML -.-
458 2012-07-30 18:26:43 <luke-jr> gmaxwell: you really think Backward Compatibility belongs in a separate BIP?
459 2012-07-30 18:26:53 <luke-jr> and if no, you really think Long Polling needs its own BIP? :P
460 2012-07-30 18:26:56 <Diablo-D3> gmaxwell: what I want is something that scales "resolution" with detail
461 2012-07-30 18:26:57 <gmaxwell> luke-jr: the last place the list left off was sipa saying that there was too much optional stuff in it.
462 2012-07-30 18:27:07 <Diablo-D3> I mean wrt: bandwidth
463 2012-07-30 18:27:20 <Diablo-D3> no more of this fucking 320x240 internet video feed shit
464 2012-07-30 18:28:21 <gmaxwell> Diablo-D3: ... the work we've doing is utterly unlike mpeg, it's based on a generalization of wavelets (a kind of wavelet packet) though we call it "overlapped DCT". Though scalability is not a target (because it costs coding gain and is patented all to hell and back; and almost no one uses it where it does exist).
465 2012-07-30 18:28:49 <gmaxwell> luke-jr: so you can rightfully point him at that message and say that the discussion was there.
466 2012-07-30 18:28:58 <Diablo-D3> gmaxwell: huh, so its like brutha?
467 2012-07-30 18:29:47 <gmaxwell> luke-jr: I'll reply.
468 2012-07-30 18:30:06 <Diablo-D3> gmaxwell: brutha was that audio codec I was working on
469 2012-07-30 18:30:20 <Diablo-D3> it worked well but I couldnt figure out how to write entropy coding
470 2012-07-30 18:35:42 <gmaxwell> Diablo-D3: our filterbanks are based on the DCT because it's nearly optimal for autoregressive (smooth) fields and because we have fast decompositions.. any case, go flip through the slides and join #theora if you want to help. [and then we can stop offtopicing the bitcoin channels].
471 2012-07-30 18:42:31 <luke-jr> gmaxwell: so& LP+BackwardCompat in a separate BIP? or just LP? O.o
472 2012-07-30 18:42:58 <gmaxwell> luke-jr: Does backward compat even need to be specified?
473 2012-07-30 18:43:06 <luke-jr> gmaxwell: yes?
474 2012-07-30 18:43:42 <gmaxwell> It needs to be implimented... but if the spec allows non-standard extensions then backwards compat could just be one, no?
475 2012-07-30 18:44:09 <luke-jr> I suppose; I'd rather have it well-documented
476 2012-07-30 18:45:23 <gmaxwell> I think that BIPs aren't the place for that, simply because the BIP should be immortal but backwards compat won't matter a year from now.
477 2012-07-30 18:46:58 <Diablo-D3> gmaxwell: I thought I was banned from #theora
478 2012-07-30 18:47:02 <Diablo-D3> or was it #xiph
479 2012-07-30 18:47:10 <gmaxwell> Diablo-D3: I unbanned you about a year ago.
480 2012-07-30 18:47:18 <Diablo-D3> ahh
481 2012-07-30 18:47:29 <Diablo-D3> gmaxwell: I dunno, Im probably just better off writing my own
482 2012-07-30 18:48:01 <Diablo-D3> gmaxwell: teams have a bad habit of stabbing me in the back after I do all the work
483 2012-07-30 18:48:14 <luke-jr> gmaxwell: BIP 0001 specifies backward compatibility as an explicit requirement for BIPs ;P
484 2012-07-30 18:49:31 <gmaxwell> luke-jr: meh. It's not actually much of an issue for this. backwards compat matters for blockchain / p2p things, but less for this but whatever it's not worth all the talk we've had about it so far.
485 2012-07-30 18:50:06 <luke-jr> heh
486 2012-07-30 18:50:15 <luke-jr> I'm just wondering if we really need a 3rd part
487 2012-07-30 18:50:26 <luke-jr> seems silly to have it just for LP when LP is so essential anyway
488 2012-07-30 18:52:29 <gmaxwell> Diablo-D3: in any case, if nothing else we've written two entropy coders you can use. The opus one which is withing a fraction of a percent of optimal efficiency; and the daala one which is about 1% inefficient but possible to make very fast (and implement without multiplies).
489 2012-07-30 18:53:05 <Diablo-D3> gmaxwell: well, I'd like to know how entropy coders work
490 2012-07-30 18:53:19 <Diablo-D3> gmaxwell: remember how hard it was for me to learn how wavelets work because wikipedia lies?
491 2012-07-30 18:53:33 <gmaxwell> Diablo-D3: then go write a SIMD version of the daala one.
492 2012-07-30 18:53:53 <Diablo-D3> the reason I write things is so I understand how they work
493 2012-07-30 18:54:06 <Diablo-D3> if I dont understand how they work, it doesnt matter how good the code is, if it breaks I cant fix it
494 2012-07-30 19:03:26 <jgarzik> quoting private email,
495 2012-07-30 19:03:32 <jgarzik> I am a Computer Science student studying Bitcoin at the University of Maryland, as part of a research project. Having one of the University's Bitcoin server's IP addresses resolved to by a dnsseed lookup would greatly aid in our research.
496 2012-07-30 19:03:33 <jgarzik> 
497 2012-07-30 19:04:06 <jgarzik> likely answers fall within the range "no" ... "hell no"
498 2012-07-30 19:04:07 <Diablo-D3> jgarzik: wat
499 2012-07-30 19:04:59 <andyrossy> surely they can just addnode to their own if they wanted?
500 2012-07-30 19:06:01 <gmaxwell> jgarzik: ask for the addresses so we can add filters to the dns seeds. :)
501 2012-07-30 19:06:27 <Diablo-D3> YES
502 2012-07-30 19:06:30 <Diablo-D3> DO IT
503 2012-07-30 19:06:41 <jgarzik> gmaxwell: UoMD tripped my paranoid gov't connection alarm too :)
504 2012-07-30 19:08:38 <gmaxwell> It wouldn't really help them in any case..
505 2012-07-30 19:08:52 <gmaxwell> And generally we should be supportive of research... but not by giving them special privledges.
506 2012-07-30 19:09:48 <jgarzik> gmaxwell: well, given BitcoinJ's limitations, it does give them ready access to a greater-than-average pool of bitcoin users
507 2012-07-30 19:10:36 <TD> jgarzik: but not the type they are probably interested in
508 2012-07-30 19:10:45 <TD> jgarzik: specifically, those nodes won't relay anything
509 2012-07-30 19:11:37 <weex> research/writing a book are common social engineering pretexts
510 2012-07-30 19:11:48 <weex> i'm writing a book about passwords...
511 2012-07-30 19:11:55 <TD> jgarzik: did they say why they wanted that?
512 2012-07-30 19:12:03 <jgarzik> TD: I pasted the entire email
513 2012-07-30 19:12:07 <Ferroh> protip: if they are doing something malicious and bitcoin-dev related, then they are in #bitcoin-dev
514 2012-07-30 19:12:23 <TD> did they have a uomd email address?
515 2012-07-30 19:12:27 <jgarzik> TD: those nodes won't relay, but you sure can compromise privacy more easily
516 2012-07-30 19:12:28 <jgarzik> TD: yes
517 2012-07-30 19:12:43 <TD> yeah. well the privacy protections aren't good enough today, that's for sure
518 2012-07-30 19:13:24 <jgarzik> TD: it is far easier to observe BitcoinJ nodes creating transactions.  You know they are not relaying, and they only connect to DNS seeds.  Thus tying bitcoin transaction to an IP address is very easy, if BitcoinJ users are targeted.
519 2012-07-30 19:13:30 <TD> indeed
520 2012-07-30 19:13:43 <weex> if all bitcoin network traffic ran over TOR what % of TOR traffic would that be?
521 2012-07-30 19:14:06 <weex> i know total TOR traffic is necessarily hard to estimate
522 2012-07-30 19:14:16 <TD> tor traffic can be measured very accurately
523 2012-07-30 19:14:22 <TD> it's bitcoin traffic that can't be easily estimated
524 2012-07-30 19:15:16 <gmaxwell> weex: it should be a very tiny percentage.
525 2012-07-30 19:15:58 <gmaxwell> weex: the blockchain currently has a maximum long term rate of 14kbit/sec. Nodes have multiple connections but exchange very small amounts of information in order to avoid sending data wastefully.
526 2012-07-30 19:17:04 <weex> good to know gmaxwell
527 2012-07-30 19:17:10 <jgarzik> even with GDBM_SYNC, databases may get corrupted
528 2012-07-30 19:17:18 <gmaxwell> jgarzik: We shoud advise them to use testnet, and also ask if the university IRB has approved expirementation on non-consenting bitcoin users.
529 2012-07-30 19:17:37 <jgarzik> gmaxwell: oh... the latter is a good question
530 2012-07-30 19:18:07 <gmaxwell> A lot of CS people are basically unaware of the requirements for testing on human subjects, but esp with privacy technology they shoudn't be.
531 2012-07-30 19:19:20 <gmaxwell> I mean, if they want to do research that might ultimately improve bitcoin and it won't hurt people we should be as helpful as we have time for... but certantly distorting the peer selection is not something that falls within clearly non-harmful. :)
532 2012-07-30 19:48:59 <yellowhat> TD, or others, what is the proper way to import a base58 encoded private key to BitcoinJ ? new ECKey(new BigInteger(1,Base58.decode("5Jij5G.....")))) does not seem to work
533 2012-07-30 19:49:03 <Matt_von_Mises> Why is it that bitcoin-qt broadcasts the nodes network address with it's assumed external IP, every 24 hours? Why don't nodes just relay addresses of nodes that connect to them?
534 2012-07-30 19:49:31 <Matt_von_Mises> If the reason is simply to get other nodes to relay you to a couple other nodes, it's a bit awkward.
535 2012-07-30 19:50:53 <TD> yellowhat: there's a Base58.decodeToBigInteger method btw
536 2012-07-30 19:51:04 <TD> yellowhat: how do you mean it doesn't work? you don't get the public address you expect?