1 2011-12-12 00:00:20 <CIA-100> libbitcoin: genjix * r55580145f5f9 /include/bitcoin/types.hpp: hash_digest / short_hash std::hash implementations for std::*map variants. http://tinyurl.com/88n8dqq
  2 2011-12-12 01:07:23 <amiller> hey copumpkin was it you who mentioned ATS earlier?
  3 2011-12-12 01:07:33 <copumpkin> hmm, it might have been doublec
  4 2011-12-12 01:07:36 <amiller> i'm finding this pretty fascinating http://www.ats-lang.org/EXAMPLE/
  5 2011-12-12 01:07:51 <copumpkin> doublec wrote his namecoin mining pool in ATS iirc
  6 2011-12-12 01:08:42 <amiller> this is the least crufty introduction to verified programming i've seen yet
  7 2011-12-12 01:08:48 <amiller> better than the guru book
  8 2011-12-12 01:08:58 <doublec> copumpkin: parts of it are in ATS, other parts in Ur/Web
  9 2011-12-12 01:09:13 <doublec> copumpkin: I slowly hack on a complete implementatoin in ATS
 10 2011-12-12 01:09:20 <copumpkin> cool :)
 11 2011-12-12 01:09:41 <amiller> doublec, do you prefer ATS to coq or agda? have you used the others?
 12 2011-12-12 01:10:06 <doublec> the downside of an expressive language is I spend a lot of time in changing things to try out cool features of the language
 13 2011-12-12 01:10:21 <doublec> amiller: I've only used ATS - I haven't used coq or agda
 14 2011-12-12 01:11:55 <doublec> amiller: you might like some of the papers in here http://cs-people.bu.edu/aren/workspace/paper/
 15 2011-12-12 01:12:04 <doublec> amiller: for other examples of using ATS' proof system
 16 2011-12-12 01:12:12 <doublec> they're quite approachable
 17 2011-12-12 01:16:57 <amiller> yeah this in particular resonates with me quite well, and it completes the fibonacci example i enjoyed so much http://cs-people.bu.edu/aren/workspace/paper/programmer_centric/main.pdf
 18 2011-12-12 01:17:03 <amiller> thanks
 19 2011-12-12 01:17:07 <doublec> np
 20 2011-12-12 03:35:08 <CIA-100> bitcoin: Luke Dashjr maintree * rcc6fc28fdef4 gentoo/licenses/md2k7-asyouwish: Merge branch 'master' into maintree http://tinyurl.com/d63ok95
 21 2011-12-12 03:38:55 <rjk2> hey luke-jr what's the latest on the BFL unicorn
 22 2011-12-12 03:39:07 <rjk2> did you get it to go any faster
 23 2011-12-12 03:43:07 <luke-jr> rjk2: I lost my connection, so no.
 24 2011-12-12 03:43:19 <luke-jr> maybe on Monday
 25 2011-12-12 03:44:04 <luke-jr> I did refactor the code mess I made, and pushed it to Gitorious
 26 2011-12-12 03:44:22 <luke-jr> it's still not sane for merging upstream, but decently usable ;P
 27 2011-12-12 03:44:59 <rjk2> mmm refactoring
 28 2011-12-12 03:45:02 <rjk2> fun
 29 2011-12-12 05:14:04 <BlueMatt> oh shit...my dnsseed is down
 30 2011-12-12 05:14:33 <gmaxwell> hmph. I came like .. inches from discovering that on my own a little bit ago.
 31 2011-12-12 05:14:55 <BlueMatt> heh, I was responding to your email when I found out
 32 2011-12-12 05:15:23 <BlueMatt> ...and gavin has the vm on his amazon account, so only he can reboot...
 33 2011-12-12 05:15:42 <BlueMatt> no ping, ssh, etc
 34 2011-12-12 05:19:24 <BlueMatt> well...
 35 2011-12-12 05:20:25 <CIA-100> libbitcoin: genjix * r46b243181ddf / (6 files in 4 dirs): messages::block.prev_block -> messages::block.previous_block_hash http://tinyurl.com/7aj857o
 36 2011-12-12 05:20:33 <BlueMatt> well I could try to set it up on another vm tonight, or I could let it be...
 37 2011-12-12 05:20:45 <BlueMatt> and my roomate is sleeping behind me...
 38 2011-12-12 05:20:56 <gmaxwell> I wonder if thats why a few people have complained about bitcoin hanging up on start for them.
 39 2011-12-12 05:21:10 <BlueMatt> I just cname'd the record to jgarzik's dnsseed for now
 40 2011-12-12 05:21:17 <BlueMatt> to keep that from being too big a problem
 41 2011-12-12 05:26:09 <Guest13976> BlueMatt: does your stuff directly serve DNS records, or does it generate BIND zonefiles and run stock named?
 42 2011-12-12 05:26:16 <BlueMatt> bind
 43 2011-12-12 05:26:34 <BlueMatt> its that old php crap I wrote a while back
 44 2011-12-12 05:27:25 <BlueMatt> Ill go throw one up on another server Ive got for the night
 45 2011-12-12 05:27:49 <BlueMatt> brb
 46 2011-12-12 05:50:06 <CIA-100> bitcoin: Luke Dashjr maintree * r4cd49c784d09 gentoo/net-p2p/ (bitcoind/Manifest wxbitcoin/Manifest): Merge branch 'master' into maintree http://tinyurl.com/cxtzhs8
 47 2011-12-12 06:27:21 <BlueMatt> aaaand...new dnsseed up
 48 2011-12-12 06:29:35 <BlueMatt> (Ill deal with wildcarding and other crap in the morning when I get the old server back up)
 49 2011-12-12 06:29:37 <BlueMatt> goodnight all
 50 2011-12-12 06:44:05 <[Tycho]> Hello, luke-jr ?
 51 2011-12-12 06:44:14 <luke-jr> [Tycho]: what?
 52 2011-12-12 06:44:58 <[Tycho]> luke-jr: why were your blocks' timestamps offsetted ?
 53 2011-12-12 06:45:44 <luke-jr> none of your business? :P
 54 2011-12-12 06:47:12 <[Tycho]> Looks like you are suspiciously unfriendly.
 55 2011-12-12 06:48:08 <luke-jr> do you usually ask people random questions? :P
 56 2011-12-12 06:49:07 <[Tycho]> It's not a random question.
 57 2011-12-12 06:49:56 <jgarzik> timestamps may definitely have a bearing on network and block security.
 58 2011-12-12 06:52:03 <luke-jr> my block timestamps are within normal limits.
 59 2011-12-12 06:52:22 <luke-jr> (if they weren't, they'd be orphans)
 60 2011-12-12 06:54:19 <[Tycho]> Hmm, checked last ones and they seem to be normal.
 61 2011-12-12 07:07:11 <[Tycho]> What is the "Toasty" miner in blockchain.info stats ?
 62 2011-12-12 07:30:24 <c_k> [Tycho]: where do you see that? I don't see it in the "pools" stats
 63 2011-12-12 07:30:51 <[Tycho]> I see it at least in the "orphaned blocks" list.
 64 2011-12-12 07:31:07 <[Tycho]> There is also some "Virtulex" miner.
 65 2011-12-12 07:31:17 <c_k> http://blockchain.info/blocks ahh I see it there
 66 2011-12-12 07:31:31 <c_k> Vircurex? isn't that a virtual currency exchange?
 67 2011-12-12 07:33:13 <c_k> [Tycho]: https://bitcointalk.org/index.php?topic=40264.msg556425#msg556425
 68 2011-12-12 07:33:44 <c_k> [Tycho]: an explanation of why Eligius time is intentionally not "normal"
 69 2011-12-12 07:34:26 <[Tycho]> Yes, that link points to an exchange. But their mining share looks big enough.
 70 2011-12-12 07:34:37 <[Tycho]> More than most of small pools (each).
 71 2011-12-12 07:40:12 <c_k> I was wondering the same thing
 72 2011-12-12 09:00:13 <ThomasV> what is 1VayNert3x1KzbpzMGt2qdqrAThiRovi8 ?
 73 2011-12-12 09:00:22 <ThomasV> a spammer?
 74 2011-12-12 10:18:53 <[Tycho]> Someone found my VayNert again :)
 75 2011-12-12 10:21:43 <ThomasV> [Tycho]: are you doing this?
 76 2011-12-12 11:06:08 <[Tycho]> ThomasV: Yes, why ?
 77 2011-12-12 11:54:51 <ThomasV> [Tycho]: what is your goal?
 78 2011-12-12 11:57:03 <[Tycho]> My goal is to promote Bitcoin, mostly.
 79 2011-12-12 11:57:14 <[Tycho]> If you are asking globally.
 80 2011-12-12 11:59:01 <ThomasV> [Tycho]: I am asking what is the point of all these 1VayNert3x1KzbpzMGt2qdqrAThiRovi8 transactions?
 81 2011-12-12 11:59:16 <ThomasV> are you stress-testing the memory pool?
 82 2011-12-12 12:04:24 <[Tycho]> ThomasV: Hmm. Do you know how many users I need to pay daily ?
 83 2011-12-12 12:04:25 <ThomasV> oh I see, I found the relevant forum thread
 84 2011-12-12 12:04:47 <ThomasV> [Tycho]: thank you for your relevant explanations, that was very helpful
 85 2011-12-12 12:05:14 <[Tycho]> Looks like sarcasm.
 86 2011-12-12 12:05:24 <[Tycho]> No one likes my work :(
 87 2011-12-12 12:05:41 <ThomasV> it is always very nice to have a constructive communication with someone who answers your questions
 88 2011-12-12 12:06:09 <Eliel_> [Tycho]: I'd beg to differ. Look at the number of miners mining through your pool.
 89 2011-12-12 12:07:54 <[Tycho]> ThomasV: these transactions are clearly not spam, they are big enough, not relay-restricted, with matured coins and to different people.
 90 2011-12-12 12:08:13 <[Tycho]> Eliel_: everything is fine with number of people.
 91 2011-12-12 12:08:18 <[Tycho]> Slightly more today.
 92 2011-12-12 12:09:58 <ThomasV> [Tycho]: I know, I found the forum thread. perhaps one day you will understand that not everybody knows you are deepbit, and that the kind of answers you gave above are not really helpful
 93 2011-12-12 12:10:22 <[Tycho]> ThomasV: sorry.
 94 2011-12-12 12:10:24 <slush> [Tycho]: Hi, I joined in the middle of the discussion, so sorry if it was answered already, but why not sendmany?
 95 2011-12-12 12:10:44 <ThomasV> slush: it's explained in the thread
 96 2011-12-12 12:10:57 <slush> ok
 97 2011-12-12 12:10:57 <ThomasV> https://bitcointalk.org/index.php?topic=53892.0
 98 2011-12-12 12:11:09 <[Tycho]> slush: actually I can't remember. I had some really important reason to do this, something related to network's future.
 99 2011-12-12 12:11:37 <[Tycho]> slush: but now I'm already preparing to use it.
100 2011-12-12 12:12:34 <[Tycho]> slush: why the blockchain.info says that they can't detect your pool's network share ?
101 2011-12-12 12:12:50 <slush> [Tycho]: don't know
102 2011-12-12 12:13:08 <slush> they're not using website stats, but p2p analysis
103 2011-12-12 12:13:19 <slush> and they probably cannot identify my IPs or whatever
104 2011-12-12 12:13:42 <slush> and those stats are extremely inaccurate. I don't see a point in such wrong stats anyway :)
105 2011-12-12 12:13:46 <[Tycho]> Also I wonder where that Vircurex got such share.
106 2011-12-12 12:14:36 <[Tycho]> At least they are (possibly) based on number of blocks instead of pool's returned hashrate.
107 2011-12-12 12:14:50 <doublec> I thought vircurex was an exchange, not a pool
108 2011-12-12 12:15:29 <slush> [Tycho]: yes, but it is far less accurate than fetching website stats. And pool operator cannot lie *so much* with his hashrate
109 2011-12-12 12:16:12 <[Tycho]> slush: fetching website stats is bad because they compare hashrate with block numbers. Like apples to oranges.
110 2011-12-12 12:17:49 <slush> well, pool report hashrate AND block numbers. Even if you pick only block numbers, you'll make much better graph than by analyzing just a p2p traffic
111 2011-12-12 12:19:05 <[Tycho]> slush: I mean that they are calculating network's total from total number of blocks generated.
112 2011-12-12 12:19:21 <[Tycho]> doublec: me too. Actually I discovered them only today.
113 2011-12-12 12:19:50 <doublec> odd
114 2011-12-12 12:20:23 <[Tycho]> May be they are relaying.
115 2011-12-12 12:20:28 <[Tycho]> Or he knows something.
116 2011-12-12 12:21:13 <[Tycho]> If my payments are stressing the network, then what stress it will be after widespread adoption :)
117 2011-12-12 12:31:01 <Eliel_> wasn't there some performance issues with handling transactions with huge numbers of inputs and/or outputs?
118 2011-12-12 12:35:58 <[Tycho]> May be. I'm limiting the maximum numbers.
119 2011-12-12 15:46:01 <luke-jr> oh, [Tycho] is a spammer? :P
120 2011-12-12 15:46:16 <[Tycho]> No, you ! :)
121 2011-12-12 15:47:29 <copumpkin> you might be interested in http://fgiesen.wordpress.com/2011/11/21/buffer-centric-io/
122 2011-12-12 15:47:47 <copumpkin> it's a neat pattern, and closely reflects a similar pattern I use quite a bit in certain other languages
123 2011-12-12 15:52:19 <sipa> copumpkin: right channel?
124 2011-12-12 15:52:33 <copumpkin> yeah
125 2011-12-12 15:52:37 <copumpkin> :P
126 2011-12-12 15:52:42 <copumpkin> cause you guys use C++ and do stream processing
127 2011-12-12 16:00:44 <BlueMatt> gavinandresen: ok...so we need more dnsseeds...
128 2011-12-12 16:01:23 <gavinandresen> yup
129 2011-12-12 16:01:58 <gavinandresen> Easy-to-follow instructions for how to set up a dnsseed would help (are there somewhere?)
130 2011-12-12 16:02:23 <BlueMatt> Im gonna write an email to the dev list with some later
131 2011-12-12 16:03:10 <gavinandresen> I was thinking in the shower this morning that people might be willing to run paid EC2 instances to support bitcoin
132 2011-12-12 16:03:38 <BlueMatt> maybe it would be a good idea to build a minimalist dnsseed instance that people could clone...
133 2011-12-12 16:03:55 <gavinandresen> Yes, that would be great.
134 2011-12-12 16:04:22 <jgarzik> BlueMatt: good idea
135 2011-12-12 16:04:54 <BlueMatt> well I might be able to delete some stuff from the one I whipped together last night and tweak it and just release that...
136 2011-12-12 16:06:51 <gavinandresen> Make sure it restarts itself on reboot...
137 2011-12-12 16:07:01 <jgarzik> BlueMatt: whatever OS is used, make sure it automatically installs nightly software updates
138 2011-12-12 16:07:03 <BlueMatt> yea...
139 2011-12-12 16:07:10 <BlueMatt> jgarzik: good point
140 2011-12-12 16:12:43 <sipa> BlueMatt: i upgraded my VPS recently; how hard is it to set up a dns seed?
141 2011-12-12 16:13:04 <BlueMatt> its not too bad, but it does require php-cli and bind
142 2011-12-12 16:13:09 <sipa> if it doesn't consume too much ram, i can run one
143 2011-12-12 16:13:31 <sipa> how hard would it be to write a custom dns server extension to bitcoind?
144 2011-12-12 16:13:45 <sipa> i've never looked at the details, but the dns protocol can't be hard
145 2011-12-12 16:14:12 <BlueMatt> I mean the dnsseed software I run is crap, so running it in an environment with <256m is not much of an option...
146 2011-12-12 16:14:18 <BlueMatt> but it works
147 2011-12-12 16:14:35 <gmaxwell> You'd only need a fairly limited subset of dns for that... but right now bitcoind doesn't e.g. have code to track nodes which are actually good.
148 2011-12-12 16:14:58 <gmaxwell> We don't want dnsseed just repeating the addr rumoring, because the vast majority of rumored nodes are unreachable.
149 2011-12-12 16:15:14 <sipa> agree
150 2011-12-12 16:15:26 <sipa> maybe the priority should be to fix the addr handling :)
151 2011-12-12 16:17:26 <sipa> what about: track addresses per /16 (and per configured "ip range group" for ipv6), in each set maintain a fixed maximum number of addresses (like 256), normally only forward incoming addresses to one or two random peers, but if a succeefull connection is made, forward its ip to all peers
152 2011-12-12 16:17:46 <sipa> and just keep the 256 most recent ones in each set
153 2011-12-12 16:18:34 <BlueMatt> heh ""North Korea warned South Korea on Sunday of 'unexpected consequences' if Seoul displays Christmas lights near the tense border"
154 2011-12-12 16:18:36 <BlueMatt> wtf?
155 2011-12-12 16:18:45 <gmaxwell> sipa: yea, I proposed something in that family before. E.g. hash buckets by prefix and having buckets by confidence.
156 2011-12-12 16:19:03 <sipa> gmaxwell: i remember the conversion vaguely, yes
157 2011-12-12 16:19:17 <sipa> (it's definitely not entirely my own idea)
158 2011-12-12 16:19:25 <gmaxwell> sipa: there are more than two confidence sets though, e.g. I've never connected / I've connected but not recently / I've recently connected.
159 2011-12-12 16:20:06 <gmaxwell> but, whatever, almost anything would be better than what we have now.
160 2011-12-12 16:20:58 <sipa> would you give preference to addresse you've tried yourself already?
161 2011-12-12 16:21:48 <sipa> maybe we also need separate confidence levels for addresses you hear about from nodes you've connected to yourself, vs. from nodes that connected to you
162 2011-12-12 16:21:50 <gmaxwell> I don't know so much about connection preference but I think you'd want to retain them for longer. (e.g. never allow a flood of addresses you haven't connected to to cause ones you know work to expire)
163 2011-12-12 16:22:09 <sipa> very good point
164 2011-12-12 16:22:40 <sipa> just keeping separate sets for recently-connected-to-ourselves vs the rest would be a good idea, then
165 2011-12-12 16:23:08 <BlueMatt> sipa: for the record, a dnsseed running my crap will probably need ~200m
166 2011-12-12 16:23:20 <gmaxwell> I was thinking that you could have nodes tell you their own confidences, and you subtract one level for peers you connected to, two levels for peers that connected to you.  Perhaps zero levels for keepnoded peers.
167 2011-12-12 16:24:25 <gmaxwell> And promote/demote things based on how recently you've connected to them / failed to connect to them.. but all that orthorgonal to who you select to connect to.
168 2011-12-12 16:24:43 <sipa> let's keep things simple for now :)
169 2011-12-12 16:25:29 <gmaxwell> I think who you select to connect to should be based on how many peers you have up. E.g. preference for most-likely-to-connect for the first two or so, then random, and perhaps least recently tested for the last position. or something vaguely in that class.
170 2011-12-12 16:26:26 <gmaxwell> (In general, the peer selection should avoid having exploitable structure)
171 2011-12-12 16:27:13 <sipa> well, what about just having a probability set for the choice known good / unknown peer, and have that probility change based on the number of current connections
172 2011-12-12 16:28:36 <gmaxwell> Right, it's really important to get a working peer up when you have none/few. But after that we should prefer to not introduce structure in the decisions, so that an attacker can't exploit that structure to gather more of your connections cheaply.
173 2011-12-12 16:44:17 <ohzer0> has anyone been experiencing timeouts during API calls? I'm getting spikes of high disk IO that cause my API calls to timeout
174 2011-12-12 18:01:55 <BlueMatt> gavinandresen: is there any indication on aws as to how long jenkins/dnsseed was down?
175 2011-12-12 18:02:29 <gavinandresen> BlueMatt: the problem was triggered by a scheduled reboot... I'll forward you the email
176 2011-12-12 18:02:51 <imsaguy2> they're still doing those forced reboots?
177 2011-12-12 18:03:01 <BlueMatt> yea, kinda poor if you ask me...
178 2011-12-12 18:03:09 <imsaguy2> that was like a week ago when they start that
179 2011-12-12 18:03:13 <imsaguy2> started*
180 2011-12-12 18:03:25 <BlueMatt> the question is when the dnsseed actually went down...
181 2011-12-12 18:03:27 <imsaguy2> at least fail people over to other machines
182 2011-12-12 18:03:34 <BlueMatt> mostly I ask
183 2011-12-12 18:03:40 <BlueMatt> ...
184 2011-12-12 18:03:47 <gavinandresen> I don't know why the jenkins instance didn't come back up, didn't bother to ask Amazon
185 2011-12-12 18:04:12 <BlueMatt> mostly I ask because when I scraped together another dnsseed last night, I now notice that it and the old one have almost entirely different databases
186 2011-12-12 18:04:22 <BlueMatt> which is an interesting result to say the least...
187 2011-12-12 18:05:34 <BlueMatt> and since it appears the dnsseed was only down very briefly, ie its data isnt just stale, well...
188 2011-12-12 18:06:15 <BlueMatt> or maybe turnover is just that ridiculously fast...
189 2011-12-12 18:06:35 <sipa> or you have a bug? ;)
190 2011-12-12 18:06:48 <BlueMatt> a bug in my software, impossible
191 2011-12-12 18:07:10 <BlueMatt> :)
192 2011-12-12 18:07:51 <gmaxwell> or the network is partitioned and you ended up in another partition? :)
193 2011-12-12 18:07:59 <BlueMatt> since the total accepting nodes is converging together on the two seeds (Im merging the dbs) Im assuming its turnover
194 2011-12-12 18:08:13 <BlueMatt> but its either that or partitioning is worse than I suspected
195 2011-12-12 18:08:37 <BlueMatt> (which I kind of doubt because afaik there arent that many complaints about block download lag?)
196 2011-12-12 18:08:39 <gmaxwell> the irc behavior is very pro-partition formation.
197 2011-12-12 18:09:19 <BlueMatt> true...
198 2011-12-12 18:09:34 <gmaxwell> BlueMatt: unless the partitions are bridged for blocks but not bridged for addr rumoring, somehow. (perhaps some side effect of how the rumoring works, I dunno)
199 2011-12-12 18:09:57 <BlueMatt> that is also entirely possible
200 2011-12-12 18:10:21 <BlueMatt> in any case an interesting data point in case someone wants to do network research (would be really nice if someone had the free time to do that...)
201 2011-12-12 18:10:57 <jgarzik> BlueMatt: I forget...  from where does your php stuff get bitcoin address data?  direct from bitcoind db?  via special RPC query?  remotely over network?
202 2011-12-12 18:13:04 <sipa> BlueMatt: btw, how many nodes does the db contain?
203 2011-12-12 18:13:25 <BlueMatt> jgarzik: traverses the network
204 2011-12-12 18:13:49 <sipa> so it speaks bitcoin p2p?
205 2011-12-12 18:13:50 <BlueMatt> sipa: it drops non-connectable nodes so that number is fairly unreliable, but connectable nodes tends to hover around 1500
206 2011-12-12 18:13:53 <BlueMatt> yea
207 2011-12-12 18:14:04 <gmaxwell> BlueMatt: yea, it would be interesting to startup a couple instances of your traverser with different start points and make sure they converge.
208 2011-12-12 18:14:16 <gmaxwell> If they don't.. thats bad.
209 2011-12-12 18:15:02 <gmaxwell> If .. I wanted to sit down and calculate I could figure out how fast they should converge if nothing is broken/being exploited.
210 2011-12-12 18:15:24 <BlueMatt> I have a feeling they would, but the question is how quickly, ie is the net partitioned slightly with bridges in between, or is it fairly unpartitioned
211 2011-12-12 18:16:48 <gmaxwell> right, but you can answer that question by doing a bunch of polls and measuring how fast it converges.
212 2011-12-12 18:16:56 <BlueMatt> yep
213 2011-12-12 18:17:10 <sipa> BlueMatt: what priviliges would you need to run it on my vps?
214 2011-12-12 18:17:23 <sipa> just bind listening, i suppose?
215 2011-12-12 18:18:09 <BlueMatt> sipa: yea pretty much...I think the only thing that needs half-root is the ability to SIGHUP bind when the zonefile changes
216 2011-12-12 18:18:36 <BlueMatt> which means root or some variation thereon
217 2011-12-12 18:18:46 <BlueMatt> ie visudo rule, etc
218 2011-12-12 18:18:51 <BlueMatt> s/visudo/sudoers/
219 2011-12-12 18:18:55 <sipa> right
220 2011-12-12 18:21:09 <BlueMatt> would be cool
221 2011-12-12 18:21:31 <BlueMatt> especially if it could actually download a few blocks to check the other node is good
222 2011-12-12 18:21:38 <BlueMatt> (mine only checks version number)
223 2011-12-12 18:22:33 <gmaxwell> BlueMatt: perhaps validate the highest current checkpoint or something.
224 2011-12-12 18:24:23 <BlueMatt> sadly MagicalTux's php node implementation doesnt support that and I dont have the time this week to write that support in
225 2011-12-12 18:24:28 <BlueMatt> (exams and such...)
226 2011-12-12 18:24:30 <luke-jr> constantly add peers, and when it gets a DNS request, disconnect from 2-4 and return those ;)
227 2011-12-12 18:25:16 <gmaxwell> ha, thats interesting, then you know they have open sockets.
228 2011-12-12 18:25:38 <gmaxwell> a bit wasteful though, alas.
229 2011-12-12 18:32:52 <CIA-100> bitcoin: Gavin Andresen master * rca287d6 / src/net.cpp : Merge pull request #694 from luke-jr/restore_old_miniupnp_compat ... https://github.com/bitcoin/bitcoin/commit/ca287d66f2f12ae3006daef831fbf00a4723e46d
230 2011-12-12 18:32:53 <CIA-100> bitcoin: Luke Dashjr master * r94b9704 / src/net.cpp : Restore compatibility with miniupnpc 1.5 (without breaking miniupnp 1.6) - http://git.io/Uti8Ag https://github.com/bitcoin/bitcoin/commit/94b97046fdd7466564f77f1f6631d50a8521cf10
231 2011-12-12 18:33:23 <CIA-100> bitcoin: Gavin Andresen master * r93e92d3 / (2 files): Merge pull request #687 from TheBlueMatt/gitianssl ... https://github.com/bitcoin/bitcoin/commit/93e92d3f44cbb4ac96c394871090e8f2b32c0f8e
232 2011-12-12 18:34:05 <gmaxwell> BlueMatt: in any case, the same distrust about the network is why I think keepnode is important. A lot of spookyness goes away with a few manually configured trusted nodes.
233 2011-12-12 18:34:20 <BlueMatt> agreed
234 2011-12-12 18:34:31 <sipa> BlueMatt: where does your dns seed live?
235 2011-12-12 18:34:41 <BlueMatt> the jenkins server...
236 2011-12-12 18:34:48 <BlueMatt> (AWS)
237 2011-12-12 18:35:13 <sipa> what host name i mean
238 2011-12-12 18:35:20 <BlueMatt> dnsseedns.bluematt.me
239 2011-12-12 18:35:21 <sipa> (not on my own computer right now)
240 2011-12-12 18:38:26 <luke-jr> * a225351 Re-enable RPCSSL in gitian builds.
241 2011-12-12 18:38:30 <luke-jr> ^ is this a bugfix?
242 2011-12-12 18:38:48 <BlueMatt> yea
243 2011-12-12 18:38:50 <gmaxwell> luke-jr: I think so it wasn't intentionally turned off, and people using it have complained.
244 2011-12-12 18:39:08 <BlueMatt> (might not be applicable to 0.4 though)
245 2011-12-12 18:40:02 <luke-jr> BlueMatt: no, but it is for 0.5.x
246 2011-12-12 18:40:08 <BlueMatt> true
247 2011-12-12 18:40:22 <CIA-100> bitcoin: Luke Dashjr 0.5.x * r12c69167e367 bitcoind-stable/src/net.cpp: Merge branch '0.4.x' into 0.5.x http://tinyurl.com/cy3x57k
248 2011-12-12 18:40:24 <CIA-100> bitcoin: Matt Corallo 0.5.x * r9a7f4948c6e6 bitcoind-stable/contrib/gitian-descriptors/ (gitian-win32.yml gitian.yml): Re-enable RPCSSL in gitian builds. http://tinyurl.com/brlqd3b
249 2011-12-12 18:43:21 <luke-jr> fwiw, there are currently about 11,000 lines of code different between 0.5.x and master right now
250 2011-12-12 18:43:43 <luke-jr> (8,000 of which are locale)
251 2011-12-12 18:44:19 <luke-jr> (1,700 are Doxyfile)
252 2011-12-12 18:44:48 <helo> 1.3k line changes is a ton...
253 2011-12-12 18:45:05 <CIA-100> bitcoin: Luke Dashjr * r75e50ce91669 gentoo/net-p2p/ (4 files in 2 dirs): net-p2p/bitcoin{-qt,d}: 9999 works with any miniupnpc version again http://tinyurl.com/cedct8o
254 2011-12-12 18:45:14 <luke-jr> hence why I think master should just go ahead with 0.6 and leave 0.5.1 for a stable release :P
255 2011-12-12 18:45:27 <BlueMatt> no way we have that many changes?
256 2011-12-12 18:46:27 <luke-jr> 1,545 line diff after stripping out locales and Doxyfile
257 2011-12-12 18:46:41 <luke-jr> http://paste.pocoo.org/show/519884/
258 2011-12-12 18:46:53 <sipa> ok, DNS protocol seems easy enough to implement
259 2011-12-12 18:47:07 <sipa> surprises me that i never looked up how it worked
260 2011-12-12 18:47:24 <jgarzik> sipa: it is, but there are a lot of gotchas
261 2011-12-12 18:47:42 <CIA-100> DiabloMiner: Forrest Voight master * r8bf49df / src/main/java/com/diablominer/DiabloMiner/DiabloMiner.java : Gracefully handle H != 0 targets - http://git.io/aOKsKQ https://github.com/Diablo-D3/DiabloMiner/commit/8bf49df4d963212d957270ff83f02fe43a9153fe
262 2011-12-12 18:47:42 <sipa> i hope that for a dns seed, many of them can be ignored
263 2011-12-12 18:47:44 <CIA-100> DiabloMiner: Patrick McFarland master * r675498c / src/main/java/com/diablominer/DiabloMiner/DiabloMiner.java : Merge pull request #34 from forrestv/all_targets ... https://github.com/Diablo-D3/DiabloMiner/commit/675498c72cda9c5f89320ec7e0a0df43a0aeda88
264 2011-12-12 18:47:46 <luke-jr> otoh, SecureString changes *might* qualify as a bugfix for Bitcoin-Qt& it didn't make any practical security improvement for bitcoind, but might for the GUI
265 2011-12-12 18:48:30 <sipa> jgarzik: like just looking at the first question record (or even not at all), ignoring things like authorativity, ...
266 2011-12-12 18:48:31 <gavinandresen> tcatm: ping
267 2011-12-12 18:48:35 <jgarzik> sipa: resolvers and servers expect certain things.  it is -very- easy to have overflow/corruption bugs.  djb's "tinydns" is a great example to read.  you should not return more than 512 bytes without special considerations
268 2011-12-12 18:48:37 <tcatm> gavinandresen: pong
269 2011-12-12 18:49:00 <gavinandresen> tcatm:  Are there more translations ready to go into a 0.5.0.1 release?
270 2011-12-12 18:49:00 <luke-jr> SecureString is only 285 lines though
271 2011-12-12 18:49:04 <jgarzik> sipa: yep, standard is one (1) question
272 2011-12-12 18:49:15 <jgarzik> anymore, and some software pukes
273 2011-12-12 18:49:24 <tcatm> gavinandresen: I think so. just a moment
274 2011-12-12 18:49:32 <luke-jr> gavinandresen: it makes no sense at all to make a 0.5.0.1 from master&
275 2011-12-12 18:49:42 <luke-jr> 0.5.1 maybe, but not 0.5.0.1
276 2011-12-12 18:50:13 <BlueMatt> we really have no new features though, so 0.6 doesnt make much sense to me...
277 2011-12-12 18:50:23 <sipa> it's only bugfixes, so 0.5.1
278 2011-12-12 18:50:25 <luke-jr> if you guys do 0.5.1 from the current master, I will rename 0.5.x to 0.5.0.x, and probably not support it for long
279 2011-12-12 18:50:28 <BlueMatt> 0.5.0.1 is a bit much...
280 2011-12-12 18:50:40 <luke-jr> BlueMatt: there are a bunch of features already ACK'd for 0.6 that could be merged in a day
281 2011-12-12 18:50:51 <sipa> luke-jr: i would suggest that you "take over" old branches as soon as the next major release is out
282 2011-12-12 18:51:10 <luke-jr> sipa: sure, 0.5.x is a draft branch right now
283 2011-12-12 18:51:24 <sipa> as in, maybe do a backported 0.5.2 based on 0.5.1 + 0.6 bugfixes, after 0.6 is out
284 2011-12-12 18:51:25 <luke-jr> sipa: if the next release from master turns out to be 0.5.1, it gets renamed :P
285 2011-12-12 18:51:48 <luke-jr> ok
286 2011-12-12 18:51:57 <sipa> if that's fine by you, of course
287 2011-12-12 18:52:11 <gavinandresen> Ok, so 0.5.1...   as soon as all the translations are pulled, I'll start creating a rc1 from master.
288 2011-12-12 18:52:13 <luke-jr> easier to apply the fixes to a branch as they're applied to master IMO, but for practical (ie, release) purposes, sounds fine
289 2011-12-12 18:53:15 <gavinandresen> BlueMatt: ... and what is the status of reproducible builds?  Windows still not reproducible?
290 2011-12-12 18:53:53 <BlueMatt> gavinandresen: should be afaik, I know me and wumpus got the same builds pre-0.5, but the 0.5-release ones I could not reproduce iirc
291 2011-12-12 18:54:09 <BlueMatt> gavinandresen: though i kinda forgot about that and never followed up...
292 2011-12-12 18:54:42 <gavinandresen> More dns seeds would be higher priority
293 2011-12-12 18:54:56 <sipa> jgarzik: 512 bytes response only? that would limit it to like 10 IP addresses
294 2011-12-12 18:55:03 <BlueMatt> I think 2-3 dynamic ones should be in the next release...
295 2011-12-12 18:55:05 <luke-jr> gavinandresen: speaking of which, did the DNS seed fix get merged?
296 2011-12-12 18:55:10 <BlueMatt> luke-jr: yes
297 2011-12-12 18:55:15 <sipa> that should be enough, actually
298 2011-12-12 18:55:17 <luke-jr> oh good
299 2011-12-12 18:55:28 <BlueMatt> (currently we have 2, and one is a static list)
300 2011-12-12 18:56:06 <jgarzik> sipa: 512 bytes is what is widely supported.  Look into "EDNS" for details on longer packets.
301 2011-12-12 18:56:15 <sipa> nah, no need for now
302 2011-12-12 18:56:23 <jgarzik> sipa: you cannot unconditionally send back anything more than 512 bytes total
303 2011-12-12 18:56:32 <sipa> ok, good to know
304 2011-12-12 18:56:48 <luke-jr> sipa: are you working on a replacement for base58 btw?
305 2011-12-12 18:57:04 <sipa> luke-jr: no, i've given up, actually
306 2011-12-12 18:57:10 <jgarzik> sipa: also there is dispute as to whether or not omitting a copy of the question, in the answer, causes problems
307 2011-12-12 18:57:25 <jgarzik> ...which is another factor possibly limiting your response
308 2011-12-12 18:57:25 <sipa> i'll just stick to keeping it
309 2011-12-12 18:57:26 <luke-jr> gavinandresen: pull 585 might be considered a bugfix
310 2011-12-12 18:57:54 <jgarzik> DNS is the most complex "simple" protocol known to man ;-)
311 2011-12-12 18:57:57 <CIA-100> bitcoin: Nils Schneider master * r7ad4ca9 / (4 files): updated translations: es es_CL nb ru - http://git.io/Z8HWtg https://github.com/bitcoin/bitcoin/commit/7ad4ca9c17696ad3cc573093f45faf39bae890c0
312 2011-12-12 18:58:01 <tcatm> gavinandresen: done
313 2011-12-12 18:58:13 <luke-jr> sipa: so do we just give up on trying to make a spec for version numbers, and choose them arbitrarily?
314 2011-12-12 18:58:16 <gavinandresen> tcatm: thanks
315 2011-12-12 18:58:43 <luke-jr> maybe pull 673 too
316 2011-12-12 18:59:16 <gavinandresen> luke-jr: I'll cherry-pick just the caps-lock check/warning from 585
317 2011-12-12 18:59:23 <sipa> luke-jr: the OP_EVAL proposal is the first to need a new version number byte, since any discussion about them started
318 2011-12-12 18:59:38 <luke-jr> gavinandresen: I think you can git merge just the relevant commit, too
319 2011-12-12 18:59:40 <tcatm> it might be a good idea to ask for help with translations in the next release notes again. there are a few translations that are almost complete
320 2011-12-12 19:00:01 <helo> are many miners indicating support for OP_EVAL yet?
321 2011-12-12 19:00:09 <sipa> luke-jr: currently gavin uses 2/109, according to "my" proposal, with new 'version' field
322 2011-12-12 19:00:17 <gavinandresen> tcatm: ok, if you want specific wording (or help with particular translations) send me email with suggested text
323 2011-12-12 19:00:23 <luke-jr> sipa: yes, which falls short of end user requirements
324 2011-12-12 19:00:23 <sipa> luke-jr: however, i agree that is actually requires a new data class instead of a new version
325 2011-12-12 19:00:32 <CIA-100> bitcoin: various 0.5.0.x * r9a7f49..aaa1c3 bitcoind-stable/ (554 files in 73 dirs): (559 commits) http://tinyurl.com/7anqaem
326 2011-12-12 19:01:04 <sipa> luke-jr: agree, byte 2 is really the worst choice there is
327 2011-12-12 19:01:27 <gavinandresen> luke-jr: I think we should wait until 0.6 to pull 673
328 2011-12-12 19:01:28 <luke-jr> 1 is worse :P
329 2011-12-12 19:02:02 <luke-jr> gavinandresen: k, I have no preference, just throwing out ideas
330 2011-12-12 19:02:42 <luke-jr> and yes, 'git merge 7298ebb' should work for JUST the CapsLock bit
331 2011-12-12 19:03:10 <luke-jr> might edit the commit message to make it look pretty if you want ;P
332 2011-12-12 19:03:35 <sipa> luke-jr: i'm afraid that any standard we try to make up will only be followed by us ourselves
333 2011-12-12 19:04:06 <gavinandresen> tcatm: RCC: Error in 'src/qt/bitcoin.qrc': Cannot find file 'locale/bitcoin_pt_BR.qm'
334 2011-12-12 19:04:08 <luke-jr> sipa: I don't think it's possible to make a standard that suits the end-user requirement of aesthetics, and still using base58
335 2011-12-12 19:04:37 <gavinandresen> tcatm: the .ts file is there....
336 2011-12-12 19:04:43 <tcatm> gavinandresen: run qmake
337 2011-12-12 19:04:55 <sipa> luke-jr: agree, plus hopefully end users will hopefully not see much base58 anyway in the future, so it's "only for now"
338 2011-12-12 19:05:00 <gavinandresen> tcatm: ah, thanks
339 2011-12-12 19:05:20 <[Tycho]> Make good version numbers :)
340 2011-12-12 19:06:13 <luke-jr> sipa: in that case, I propose OP_EVAL use versions 3 and 115 ;)
341 2011-12-12 19:06:32 <CIA-100> bitcoin: Gavin Andresen master * r5491c31 / (3 files in 2 dirs): Merge commit '7298ebb' - http://git.io/qB65Vg https://github.com/bitcoin/bitcoin/commit/5491c310a6c70220e32c123ba7b8ce3da3e26126
342 2011-12-12 19:06:32 <luke-jr> which means they begin with '2' and 'o'
343 2011-12-12 19:08:21 <sipa> luke-jr: under your last proposal, it would become 4/5 and 196/197
344 2011-12-12 19:08:24 <sipa> right?
345 2011-12-12 19:09:22 <[Tycho]> Why 'o' ?
346 2011-12-12 19:11:28 <luke-jr> sipa: 5 and 196, yes
347 2011-12-12 19:11:41 <luke-jr> sipa: '3' and '2'
348 2011-12-12 19:12:07 <luke-jr> sipa: think we should just use that proposal so long as we're dealing with 20-byte content?
349 2011-12-12 19:12:24 <sipa> except it breaks testnet
350 2011-12-12 19:12:35 <luke-jr> sipa: ?
351 2011-12-12 19:12:53 <sipa> your proposal breaks testnet version bytes, right?
352 2011-12-12 19:12:57 <luke-jr> it changes it
353 2011-12-12 19:13:07 <luke-jr> and it's going to be restarted Jan 1 anyway
354 2011-12-12 19:13:47 <sipa> gavinandresen: would you consider changing the op_eval version codes to 5 and 196, and testnet to 192 after reset?
355 2011-12-12 19:14:11 <gavinandresen> sure
356 2011-12-12 19:15:07 <sipa> ok, that'll at least give recognizable addresses
357 2011-12-12 19:15:09 <[Tycho]> What initial characters will it produce ?
358 2011-12-12 19:16:24 <sipa> ah, it also changes private keys
359 2011-12-12 19:16:52 <sipa> hmm, wonder if that means we'd need a compatibility mode (e.g. for tools like vanitygen that generate private keys in the old format)
360 2011-12-12 19:19:17 <luke-jr> [Tycho]: '3' for mainnet, '2' for testnet
361 2011-12-12 19:19:53 <luke-jr> [Tycho]: testnet addresses, whether pubkey or OP_EVAL, will always be '2' this way
362 2011-12-12 19:19:54 <BlueMatt> wait you are changing the bits for mainnet addresses?
363 2011-12-12 19:20:06 <luke-jr> [Tycho]: mainnet will be '1' for pubkey, and '3' for OP_EVAL
364 2011-12-12 19:20:18 <BlueMatt> mmm
365 2011-12-12 19:20:43 <sipa> luke-jr: so privkeys will use 13 "6..."
366 2011-12-12 19:20:48 <BlueMatt> still, why are we so drastically overhauling these numbers...
367 2011-12-12 19:21:03 <[Tycho]> luke-jr: cool.
368 2011-12-12 19:21:06 <luke-jr> sipa: right
369 2011-12-12 19:21:08 <BlueMatt> human readability/identifyability is nice, but not worth it...
370 2011-12-12 19:21:09 <sipa> and 204 "2..."
371 2011-12-12 19:21:19 <[Tycho]> BlueMatt: worth it.
372 2011-12-12 19:21:20 <luke-jr> BlueMatt: it's arguably the most important factor
373 2011-12-12 19:21:34 <sipa> the only thing i don't like is that we need to break testnet and privkeys, but that's the only downside
374 2011-12-12 19:21:35 <luke-jr> sipa: wait, no
375 2011-12-12 19:21:38 <BlueMatt> except that now you have to change testnet addresses, privkey prefixes
376 2011-12-12 19:21:41 <luke-jr> sipa: because private keys aren't length 20
377 2011-12-12 19:21:42 <BlueMatt> and namecoin, right?
378 2011-12-12 19:21:47 <sipa> luke-jr: oh, right
379 2011-12-12 19:21:59 <luke-jr> BlueMatt: latest proposal is namecoin-compatible
380 2011-12-12 19:22:07 <BlueMatt> mmm, well I guess thats a plus
381 2011-12-12 19:22:14 <sipa> and privkeys were never merged
382 2011-12-12 19:22:29 <luke-jr> sipa: non-length-20 has no reason to follow any of my proposals.
383 2011-12-12 19:22:47 <luke-jr> sipa: if possible, it would make sense to use one of the length-20-unusable version numbers
384 2011-12-12 19:22:48 <sipa> luke-jr: sure, could you check what characters result for length 32?
385 2011-12-12 19:22:49 <luke-jr> what is it now?
386 2011-12-12 19:22:53 <luke-jr> yes
387 2011-12-12 19:23:06 <sipa> 128 and 239
388 2011-12-12 19:23:59 <BlueMatt> gavinandresen: so you are doing an 0.5.1 in the next couple days?
389 2011-12-12 19:24:00 <luke-jr> mmm, 128 is at least redundant for 20-byte&
390 2011-12-12 19:24:06 <luke-jr> BlueMatt: sounds like right now
391 2011-12-12 19:24:20 <luke-jr> sipa: 32-byte is looking worse than 20-byte
392 2011-12-12 19:24:39 <luke-jr> are priv keys really 32-byte?
393 2011-12-12 19:24:52 <sipa> yes
394 2011-12-12 19:25:04 <luke-jr> every version starting with 30 is yielding '2' so far
395 2011-12-12 19:25:24 <luke-jr> I assume there's a checksum still?
396 2011-12-12 19:25:27 <sipa> yes
397 2011-12-12 19:25:29 <BlueMatt> in that case, sipa can you commit a dns name for a dnsseed, and worry about getting the seed running later?
398 2011-12-12 19:25:34 <luke-jr> ah, it moved on to '3'
399 2011-12-12 19:25:42 <BlueMatt> (CNAME it to your fallback node for now, or something)
400 2011-12-12 19:26:08 <gavinandresen> BlueMatt: yes, 0.5.1 as soon as I figure out why my gitian machine's ethernet connection isn't working....
401 2011-12-12 19:26:29 <luke-jr> BlueMatt: if you want to add dnsseed.bitcoin.dashjr.org., I can CNAME that to one of your dnsseeds until I have something going
402 2011-12-12 19:26:49 <BlueMatt> either way, just someone add another dnsseed
403 2011-12-12 19:27:01 <sipa> BlueMatt: adding CNAME
404 2011-12-12 19:27:06 <luke-jr> just tell me where to CNAME it for now
405 2011-12-12 19:27:12 <BlueMatt> 2 more is better than 1 too
406 2011-12-12 19:27:29 <BlueMatt> mine is at dnsseed.bluematt.me though Im not sure its better to have the addresses added twice...
407 2011-12-12 19:27:55 <BlueMatt> maybe just cname it to a fallback node, or maybe just make it not have an A record
408 2011-12-12 19:28:57 <luke-jr> dnsseed.bitcoin.dashjr.org. 60  IN  CNAME   bitseed.xf2.org.
409 2011-12-12 19:29:14 <BlueMatt> works for me
410 2011-12-12 19:29:23 <luke-jr> I'll setup something better later
411 2011-12-12 19:29:41 <[Tycho]> Do someone knows why bitcoind generates data in getwork longer than 80 bytes ? I mean, why the other part is concatenated with block header ?
412 2011-12-12 19:29:42 <diki> very centralized...this dns seed
413 2011-12-12 19:29:56 <BlueMatt> diki: less than irc
414 2011-12-12 19:30:07 <luke-jr> diki: that's why we're adding more
415 2011-12-12 19:30:23 <diki> you'd need to add a few thousand more
416 2011-12-12 19:30:50 <BlueMatt> if someone can come up with a decentralized bootstrap mechanism you will be regarded as the most brilliant computer scientist ever
417 2011-12-12 19:31:00 <sipa> seed.bitcoin.sipa.be.
418 2011-12-12 19:31:10 <luke-jr> BlueMatt: I did that a while ago. It's just not practical yet. ;P
419 2011-12-12 19:31:17 <luke-jr> anycast or multicast
420 2011-12-12 19:31:22 <BlueMatt> heh
421 2011-12-12 19:31:46 <diki> luke-jr:you will give me a bit credit, right :D
422 2011-12-12 19:32:17 <luke-jr> diki: no
423 2011-12-12 19:32:53 <luke-jr> sipa: http://pastebin.com/4cUWhiN8
424 2011-12-12 19:32:58 <BlueMatt> sipa: want to commit them to the repo?
425 2011-12-12 19:33:36 <jgarzik> sipa: that's the host, or the DNS server?
426 2011-12-12 19:33:36 <luke-jr> sipa: fine by me to leave the privkey version at 128 :P
427 2011-12-12 19:33:46 <BlueMatt> (as long as luke doesnt start statically adding eligius relays to his dnsseed)
428 2011-12-12 19:34:09 <sipa> jgarzik: for now it's a CNAME, i'll change it to an NS later as soon as an nameserver is running there
429 2011-12-12 19:34:26 <jgarzik> FWIW my DNS seed is a static list of fallback nodes
430 2011-12-12 19:34:28 <jgarzik> i.e. lame
431 2011-12-12 19:34:39 <luke-jr> LOL
432 2011-12-12 19:34:43 <sipa> mine is a static list of one node
433 2011-12-12 19:34:46 <sipa> i.e. pathetic
434 2011-12-12 19:34:51 <jgarzik> :)
435 2011-12-12 19:34:55 <BlueMatt> jgarzik: last I heard those were usually all overloaded ;)
436 2011-12-12 19:34:55 <diki> jgarzik:static is so..90s
437 2011-12-12 19:35:02 <luke-jr> jgarzik: I think you're the only DNS seed left&
438 2011-12-12 19:35:09 <BlueMatt> luke-jr: mine is back up
439 2011-12-12 19:35:18 <luke-jr> ah
440 2011-12-12 19:35:23 <BlueMatt> (has been since last night, I think it was only down a couple hours)
441 2011-12-12 19:36:00 <jgarzik> does anyone offer AWS access w/ bitcoin payments?
442 2011-12-12 19:36:26 <gavinandresen> jgarzik: that's a good idea...  I think AWS allows resellers.
443 2011-12-12 19:37:31 <luke-jr> sipa: after all, in the current proposal, 128 is reserved
444 2011-12-12 19:37:32 <BlueMatt> (someone who runs a bitcoin vps service asked me a while back on instructions on how to set up a dnsseed...)
445 2011-12-12 19:38:39 <diki> BlueMatt:tbh, you are the fastest learner i've ever seen
446 2011-12-12 19:38:46 <BlueMatt> ???
447 2011-12-12 19:38:58 <diki> you seem to grasp things from the first try
448 2011-12-12 19:39:03 <BlueMatt> heh, I wish
449 2011-12-12 19:39:07 <BlueMatt> Ive met much faster...
450 2011-12-12 19:44:20 <BlueMatt> yay free food in compsci building for undergrads paid for by google :)
451 2011-12-12 19:44:36 <BlueMatt> thanks google and your ridiculous quantities of cash
452 2011-12-12 19:47:50 <sipa> luke-jr: i really hate how every testnet thing will end up having first character '2'
453 2011-12-12 19:48:50 <luke-jr> sipa: saves more characters for real networks :D
454 2011-12-12 19:48:51 <[Tycho]> Testnet addresses will start with the same char as mainnet ?
455 2011-12-12 19:49:01 <luke-jr> [Tycho]: no, ONLY testnet will start with '2'
456 2011-12-12 19:49:17 <luke-jr> [Tycho]: but BOTH testnet pubkey and testnet OP_EVAL
457 2011-12-12 19:49:30 <luke-jr> sipa: also, recall that this proposal is only valid for 20 byte data
458 2011-12-12 20:14:54 <diki> Hmm
459 2011-12-12 20:15:11 <diki> I think that monitors should have USB ports
460 2011-12-12 20:15:23 <diki> and via HDMI or other cable communicate with the motherboard
461 2011-12-12 20:18:40 <BlueMatt> usb hubs on monitors was popular for a while
462 2011-12-12 20:20:23 <diki> I could've also used an HDMI cable if they werent so expensive
463 2011-12-12 20:20:27 <diki> ...and short
464 2011-12-12 20:47:57 <[Tycho]> diki: some HDMI cables aren't short.
465 2011-12-12 20:48:51 <cjdelisle> hdmi needs to die
466 2011-12-12 20:49:14 <[Tycho]> But there is nothing to replace it.
467 2011-12-12 20:51:04 <luke-jr> [Tycho]: yes there is.
468 2011-12-12 20:51:47 <luke-jr> DisplayPort and/or HDBaseT
469 2011-12-12 20:53:06 <BlueMatt> DP also needs to die
470 2011-12-12 20:53:20 <BlueMatt> the licensing costs make even DP cables expensive compared to hdmi/dvi
471 2011-12-12 20:57:34 <luke-jr> :o
472 2011-12-12 20:57:40 <luke-jr> wtf are you licensing?
473 2011-12-12 20:59:32 <BlueMatt> ok, so I assumed that was true, but dp cabes always tend to be more expensive and can sometimes be waay more expensive...
474 2011-12-12 20:59:50 <BlueMatt> no way they dont have ridiculous licensing costs
475 2011-12-12 20:59:57 <luke-jr> to license what?
476 2011-12-12 21:00:05 <luke-jr> mere cables are pure interface.
477 2011-12-12 21:00:10 <luke-jr> interfaces cannot be copyrighted.
478 2011-12-12 21:00:19 <BlueMatt> heh
479 2011-12-12 21:00:22 <BlueMatt> and yet they are...
480 2011-12-12 21:00:29 <luke-jr> says who?
481 2011-12-12 21:00:38 <gmaxwell> Rambus. ;)
482 2011-12-12 21:00:45 <BlueMatt> apple
483 2011-12-12 21:00:50 <BlueMatt> go try to make one of their power cables
484 2011-12-12 21:01:15 <cjdelisle> gotta love how there's no law and yet someone says there's a law and people act like there's a law and everything behaves asif there was :/
485 2011-12-12 21:01:40 <BlueMatt> when it comes to copyright it often works out that way...
486 2011-12-12 21:01:49 <BlueMatt> fair use, bullshit no such thing
487 2011-12-12 21:02:02 <cjdelisle> /nod
488 2011-12-12 21:02:37 <cjdelisle> mixing copyright, patent, license agreement, and legal fiction together to make the legal environment they want
489 2011-12-12 21:03:50 <BlueMatt> yep
490 2011-12-12 21:26:43 <CIA-100> DiabloMiner: Patrick McFarland master * r13d436e / src/main/java/com/diablominer/DiabloMiner/DiabloMiner.java : Moving 3 threads per device to 2, AMD fixed CPU use bug - http://git.io/f_-rFA https://github.com/Diablo-D3/DiabloMiner/commit/13d436e6f33689f68fa2f0038d5ef3f3230df36b
491 2011-12-12 21:26:44 <CIA-100> DiabloMiner: Patrick McFarland master * r8d8e4f2 / src/main/java/com/diablominer/DiabloMiner/DiabloMiner.java : Merge branch 'master' of github.com:Diablo-D3/DiabloMiner - http://git.io/Ac1Mbw https://github.com/Diablo-D3/DiabloMiner/commit/8d8e4f23a7dd44b83df4f7a60d3a0197e2c30258
492 2011-12-12 21:26:45 <CIA-100> DiabloMiner: Patrick McFarland master * r6138aeb / src/main/java/com/diablominer/DiabloMiner/DiabloMiner.java : Reduce FPS management aggression - http://git.io/I8MgEw https://github.com/Diablo-D3/DiabloMiner/commit/6138aeb7e183f5dbdf1f967d2f84b292f0af8ec1
493 2011-12-12 21:58:51 <the_batman> alright, I figured out the first real world application of bitcoin
494 2011-12-12 21:58:52 <the_batman> :D
495 2011-12-12 21:59:10 <the_batman> I wanna go non-profit on this one. Is there a team I could or should hook up with?
496 2011-12-12 22:00:07 <helo> write it and release it, or you won't be able to build much of a team
497 2011-12-12 22:03:01 <BlueMatt> care to share?
498 2011-12-12 22:05:22 <Eliel> the_batman: if you want to go non-profit with it, I think it's best to share the idea with as many people as possible to see what people think.
499 2011-12-12 22:39:01 <jgarzik> when I hear "non-profit", my brain usually translates it into "unsustainable without continued donations"
500 2011-12-12 22:39:44 <BlueMatt> heh
501 2011-12-12 22:40:36 <cjdelisle> when I hear not-for-profit, I think of not-for-paying-taxes
502 2011-12-12 22:40:58 <cjdelisle> *cough* NPR
503 2011-12-12 22:42:38 <luke-jr> when I hear "non-profit", I think "employees take home all the profit"
504 2011-12-12 22:45:54 <copumpkin> you should get your ears checked
505 2011-12-12 22:46:03 <copumpkin> those don't sound alike at all
506 2011-12-12 22:46:43 <Eliel> :D
507 2011-12-12 22:49:03 <luke-jr> copumpkin: that's the reality of it in the USA :P
508 2011-12-12 22:49:53 <copumpkin> man, I should work for a non-profit
509 2011-12-12 22:50:29 <luke-jr> lol
510 2011-12-12 22:53:29 <copumpkin> that way I can sound like less of a sellout, and still make good money
511 2011-12-12 22:53:45 <copumpkin> BlueMatt: sounds like that puts incentives in all the right places
512 2011-12-12 22:55:38 <cjdelisle> a charity to help poor developers... sounds like a plan!
513 2011-12-12 22:56:04 <BlueMatt> copumpkin: fine we can do it by git commits, but that means I actually have to work...
514 2011-12-12 22:56:12 <BlueMatt> (or split my commits up into 1-char diffs)
515 2011-12-12 22:57:14 <copumpkin> yeah, incentives are good there too
516 2011-12-12 22:57:42 <BlueMatt> commit, revert, commit, revert, commit, revert...PROFIT
517 2011-12-12 22:58:05 <cjdelisle> heh
518 2011-12-12 22:59:26 <cjdelisle> actually if someone wanted to donate money to bitcoin development, the thing to do would be pay someone to make a set of functional tests and then give awards to whoever makes those tests execute faster.
519 2011-12-12 22:59:49 <gmaxwell> cjdelisle: Does it matter how fast they run?
520 2011-12-12 22:59:55 <BlueMatt> or just set goals..ie SPV->500$ bounty
521 2011-12-12 22:59:56 <gmaxwell> I mean - computing time is cheap.
522 2011-12-12 23:00:13 <BlueMatt> there used to be bounties for bitcoin code, what ever happened to that model?
523 2011-12-12 23:00:16 <cjdelisle> faster tests -> faster bitcoin -> happier users
524 2011-12-12 23:00:35 <gmaxwell> oh oh, I follow. Not speeding up the tests themselves but the underlying code.
525 2011-12-12 23:00:55 <cjdelisle> ahh right, I remember the bounties discussion re it preventing collaboration and such
526 2011-12-12 23:01:39 <BlueMatt> like there is that much collaboration on large features anyway
527 2011-12-12 23:02:30 <cjdelisle> /nod yea in my experience most major development is done by one dev.
528 2011-12-12 23:03:14 <BlueMatt> well if you want to get a big feature done, making a git tree and having more than 2-3 people work on it is just gonna result in more headache than its worth
529 2011-12-12 23:03:28 <BlueMatt> you are better off having each work on one feature and then merging it at the end
530 2011-12-12 23:03:45 <cjdelisle> lots of "write in cave, release to world finishedish" is the standard
531 2011-12-12 23:05:49 <BlueMatt> yea and for better or for worse, bounties dont change that (too much)
532 2011-12-12 23:05:56 <BlueMatt> in some cases they do, but only if its a really huge project
533 2011-12-12 23:06:04 <sipa> BlueMatt: wallet encryption was somewhat collaboration :)
534 2011-12-12 23:07:02 <BlueMatt> sipa: that is the way it normally is, one person write it, other people comment and fix what is broken (which in the case of wallet encryption just happened to be more broken than working...)
535 2011-12-12 23:07:30 <BlueMatt> (or I guess in the case of wallet encryption jgarzik wrote it and I made it better until I released it in a still mostly-broken state)
536 2011-12-12 23:08:22 <BlueMatt> that and you provided the framework with CWallet...
537 2011-12-12 23:08:32 <BlueMatt> anyway, you still get the point...
538 2011-12-12 23:08:37 <sipa> yeah
539 2011-12-12 23:09:32 <BlueMatt> and it wouldnt have happened differently if there were a bounty on wallet encryption
540 2011-12-12 23:09:44 <BlueMatt> (which Im still confused as to why there never was, I mean there was one on UPnP...)
541 2011-12-12 23:11:07 <cjdelisle> I think the reason why there isn't a lot of collaboration here or anywhere is because when you have a vision of how something should work, you can't really communicate it, or even validate that it isn't a flawed design, without putting it in code
542 2011-12-12 23:11:21 <BlueMatt> very true
543 2011-12-12 23:11:22 <gmaxwell> ding ding.
544 2011-12-12 23:12:05 <gmaxwell> 99% of the work is actually making it work. The 1% of blabbing about things in general we have in spades in any case.
545 2011-12-12 23:12:41 <BlueMatt> there always has been an oddly high talk to code ratio in bitcoin...
546 2011-12-12 23:12:58 <sipa> haha, yes
547 2011-12-12 23:13:18 <BlueMatt> implementation details have been discussed over and over again months ago for stuff that probably wont get implemented for months...
548 2011-12-12 23:13:45 <jgarzik> BlueMatt: heh
549 2011-12-12 23:13:48 <jgarzik> BlueMatt: indeed