1 2012-09-19 00:23:22 <jgarzik> is anybody else having problems reaching bitcointalk.org?
2 2012-09-19 00:24:37 <diki> Works on my end.
3 2012-09-19 00:37:30 <kreal> works
4 2012-09-19 00:58:10 <jgarzik> seems like there is a problem with 0.7 on Mac OSX, that does not seem present on other platforms
5 2012-09-19 01:12:26 <denisx> jgarzik: what problem, I have osx
6 2012-09-19 01:12:38 <jgarzik> denisx: see the 0.7 announce thread
7 2012-09-19 01:13:20 <gmaxwell> bitcointalk seems broken for me.
8 2012-09-19 01:13:24 <gmaxwell> Is it high cpu usage?
9 2012-09-19 01:13:24 <jgarzik> denisx: Gavin has macosx, and he would not release if macosx is 100% broken
10 2012-09-19 01:13:58 <jgarzik> gmaxwell: it was dead for me, for two days, until I turned off my Red Hat VPN and restarted Firefox. Now, right this minute, it is working fine.
11 2012-09-19 01:14:19 <jgarzik> previous behavior: Firefox just spun on "connecting..." until timeout
12 2012-09-19 01:14:26 <jgarzik> Fedora 17
13 2012-09-19 01:41:13 <Ryan45> Curious if anyone knows of projects that use the bitcoin mining process, but apply it to a gaming system. to generate role playing cards.
14 2012-09-19 01:41:22 <Ryan45> well, not the bitcoin process
15 2012-09-19 01:41:25 <Ryan45> but the same concept
16 2012-09-19 01:41:28 <kjj_> huh?
17 2012-09-19 01:41:35 <maaku> why?
18 2012-09-19 01:42:18 <gmaxwell> Ryan45: http://en.wikipedia.org/wiki/Hashcash
19 2012-09-19 01:43:46 <Ryan45> Why? Because it sounds like a facinating way to generate game cards.
20 2012-09-19 01:44:05 <Ryan45> thanks gmax, looking
21 2012-09-19 01:44:25 <kjj_> I think you are going to need to clarify what part of bitcoin you are talking about
22 2012-09-19 01:44:40 <Ryan45> bitcoin mining process
23 2012-09-19 01:45:18 <kjj_> hashing? like all of the participants agree on a base number, and then try to find a nonce that gives them the least likely output in a set amount of time?
24 2012-09-19 01:45:21 <Ryan45> Gmax: thanks for the link but that is not exactly what I was talking about
25 2012-09-19 01:45:57 <Ryan45> kjj: sort of just like assigning cards to unique bit coins
26 2012-09-19 01:46:10 <Ryan45> not the mining process
27 2012-09-19 01:47:36 <Ryan45> I'll do some more learning so I can come back and clarify :)
28 2012-09-19 01:57:33 <bitfoo> am I a bad person if I cap my bitcoind outbound bandwidth to around 150 kbps?
29 2012-09-19 01:57:52 <bitfoo> I have around 70 connections usually
30 2012-09-19 01:57:58 <kjj_> that probably isn't why you are a bad person, no
31 2012-09-19 01:57:59 <bitfoo> and sometimes my connection gets choked
32 2012-09-19 01:58:02 <bitfoo> lol
33 2012-09-19 01:58:34 <kjj_> if you are actually throttling, I'd scale back your connections
34 2012-09-19 01:58:41 <bitfoo> ok, maybe I should do that
35 2012-09-19 02:00:30 <bitfoo> I suppose blocks these days have gotten a lot bigger than they used to be
36 2012-09-19 02:01:13 <kjj_> I think that you (and the network) would be better off with a smaller number of connections that can run at full speed than
37 2012-09-19 02:01:29 <bitfoo> yeah, trying to figure the option to do that
38 2012-09-19 02:01:33 <bitfoo> if you know it off hand let me know :)
39 2012-09-19 02:01:35 <kjj_> maxconnections
40 2012-09-19 02:01:41 <bitfoo> thanks
41 2012-09-19 02:01:45 <kjj_> in the bitcoin.conf
42 2012-09-19 02:05:16 <kjj_> I'd just watch your cap and if you see it getting hit, keep cranking down maxconnections. if maxconnections gets lower than you are comfortable with, think about cranking the cap up
43 2012-09-19 02:05:56 <gmaxwell> bitfoo: if you're going to cap, just set listen=0 it'll avoid causing problems and also remove most of the bandwidth usage.
44 2012-09-19 02:06:14 <bitfoo> ah, maybe I should just do that
45 2012-09-19 02:06:25 <bitfoo> I suppose I'm not really helping by accepting connections and then sending out blocks slowly
46 2012-09-19 02:08:00 <gmaxwell> Right.
47 2012-09-19 02:08:38 <bitfoo> I'll still be sending blocks out to my 8 outbound connections though right?
48 2012-09-19 02:09:04 <gmaxwell> bitfoo: yes, but since you'll only be connecting out, the nodes you connect to should have the complete chain already, so it will only be new blocks.
49 2012-09-19 02:09:34 <bitfoo> ok, so you're saying that most of the bandwidth is due to ancient nodes catching up and not new blocks
50 2012-09-19 02:09:45 <gmaxwell> 1MB / 600 seconds is only about 13kbit/sec.. and you don't send a block to someone who already got it elsewhere.... so on average the usage isn't enormous.
51 2012-09-19 02:09:54 <gmaxwell> bitfoo: correct
52 2012-09-19 02:10:07 <bitfoo> cool, thanks
53 2012-09-19 02:10:53 <gmaxwell> catching up peers just pull all they can from the first peer they connect to, so you get great big sustained loads when one picks you
54 2012-09-19 02:11:51 <bitfoo> ok, that's probably what I just saw a while ago then.
55 2012-09-19 02:12:12 <kjj_> that was you?
56 2012-09-19 02:12:28 <bitfoo> what? me?
57 2012-09-19 02:14:11 <kjj_> hmm. I wonder if the github people will nuke a user account that's been idle for a year
58 2012-09-19 02:23:01 <copumpkin> does it have any code? then I'd guess not
59 2012-09-19 02:23:11 <copumpkin> if it's completely unused, perhaps they'll be more open to it
60 2012-09-19 03:01:27 <gmaxwell> ;;bc,tblb 1h
61 2012-09-19 03:01:30 <gribble> 6 days, 1 hour, 15 minutes, and 22 seconds
62 2012-09-19 06:10:49 <_dr> i have what i presume to be a stupid question, but why are spent txn kept by the client?
63 2012-09-19 06:11:30 <Joric> _dr, more to say, all txn kept =)
64 2012-09-19 06:14:29 <_dr> well, all = spent + unspent, right? unspent are required for several reasons; can't think of a reason for keeping spent txns (but i'm sure there are reasons)
65 2012-09-19 06:14:32 <Joric> _dr, sipa's working on ultraprune branch it makes blockchain 15x smaller but your node loses all historical data
66 2012-09-19 06:15:25 <_dr> any reason to keep historical data? apart from 'i want to trace money'; might actually be a 'feature' not to have historical data
67 2012-09-19 06:15:57 <_dr> only a snapshot of current coin distribution represented by the unspent txns
68 2012-09-19 06:15:59 <Joric> idk an ability to trace all transactions back to origin is quite fun
69 2012-09-19 06:16:39 <_dr> Joric: agreed, but you know what i mean...
70 2012-09-19 08:24:06 <epscy> i think getting rid of spent txes has security implications
71 2012-09-19 08:44:00 <thermoman> hi there. i have problems with bitcoins sent from a mining pool to my daemon ... i don't get the account/label from the daemon with gettransactions and category is generate instead of receive: http://pastebin.com/uRY2UCme
72 2012-09-19 08:44:05 <thermoman> any ideas how a piece of software, using the RPC interface, could determine to which address/label/account these coins were originally sent?
73 2012-09-19 08:44:08 <thermoman> is this a bug in the old 0.3.24 client? does upgrading help?
74 2012-09-19 09:06:26 <doublec> thermoman: pools that use "generate" transactions weren't compatible with accounts and "getreceived" rpc calls iirc
75 2012-09-19 09:06:34 <doublec> thermoman: it may have changed recently but I'm not sure
76 2012-09-19 09:06:53 <doublec> thermoman: I think Luke-Jr was working on some patches
77 2012-09-19 09:07:12 <_dr> epscy: care to elaborate?
78 2012-09-19 09:08:08 <epscy> _dr: you are best off asking sipa or gmaxwell
79 2012-09-19 09:08:16 <_dr> ok, i'll just wait
80 2012-09-19 09:11:32 <thermoman> doublec: ok, so this is expected behaviour? so the user in question should send his mined btc to his own wallet and then transfer them to us, right?
81 2012-09-19 09:12:58 <Luke-Jr> thermoman: don't use unmaintained clients. 0.3.24 is vulnerable to a number of known and possibly unknown exploits
82 2012-09-19 09:13:17 <Luke-Jr> thermoman: 0.7.0 is the first version with the generated-to-account issue fixed
83 2012-09-19 09:23:03 <thermoman> Luke-Jr: thanks. yes, will update to the newest version as soon as possible. is the RPC api from 0.7.0 backwards compatible to 0.3.24?
84 2012-09-19 09:29:22 <doublec> thermoman: as long as you don't use getmemorypool you should be fine
85 2012-09-19 09:29:33 <thermoman> doublec: ok, thanks
86 2012-09-19 09:37:51 <thermoman> doublec: 0.3.24 doesn't have -detachdb option ... so should i upgrade to 0.6.3, run 0.6.3 with -detachdb and then upgrade to 0.7.0 or is it safe to upgrade straight to 0.7.0 from 0.3.24?
87 2012-09-19 09:52:20 <Luke-Jr> thermoman: I think the only backward incompatible change is the address/account w/ generation fix
88 2012-09-19 09:52:28 <Luke-Jr> doublec: 0.3 and 0.4 didn't have GMP at all ;)
89 2012-09-19 09:52:43 <Luke-Jr> thermoman: before 0.6, -detachdb was always used
90 2012-09-19 09:53:04 <Luke-Jr> thermoman: but be sure to do a clean shutdown
91 2012-09-19 09:53:06 <Luke-Jr> and wait for it to finish
92 2012-09-19 09:55:22 <[7]> can someone tell me if these assumptions are correct?
93 2012-09-19 09:55:57 <[7]> 1. to extend mining keyspace beyond the normal nonce + nTime field, you increment a field in the coinbase txn
94 2012-09-19 09:56:21 <thermoman> Luke-Jr: ok, thanks
95 2012-09-19 09:56:46 <[7]> 2. to build a new block header from the modified coinbase txn you need, at the minimum, the hashes of all other merkle branches on the way to the root
96 2012-09-19 10:00:43 <[7]> do you think it makes sense to push this kind of stuff down into the mining hardware in the future? or rather let the hardware work on 120 second ntime ranges on its own and step the extranonce on the host
97 2012-09-19 10:01:06 <[7]> i.e. basically abuse the ntime field as a hardware-level extra nonce
98 2012-09-19 10:02:27 <_dr> [7]: isn't that what rollntime does?
99 2012-09-19 10:03:42 <[7]> well, the original intention of rollntime seems to be allowing the miner software to step that field every second for autonomous host-side job generation for hardware up to 4.3GH/s
100 2012-09-19 10:04:23 <[7]> I'm talking about stepping it inside the mining hardware itself at a faster than realtime speed, for mining hardware up to about 1TH/s
101 2012-09-19 10:05:18 <[7]> and basically using extranonce for what rollntime was originally used for (to autonomously generate new work for that ntime-aware hardware on the host a couple of times per second)
102 2012-09-19 10:07:59 <[7]> ACTION wonders how such a thing would line up with BIP22
103 2012-09-19 10:18:17 <Luke-Jr> [7]: well, I told BFL if they can, they should design their ASICs so the nonce size can be made larger (backward)
104 2012-09-19 10:18:41 <Luke-Jr> I don't see how GBT would necessarily be involved in that, just an implementation detail for the miner
105 2012-09-19 10:19:20 <[7]> well I'm sure GBT pooled mining would introduce some more constraints on the coinbase etc. than solo mining
106 2012-09-19 10:20:36 <[7]> "nonce size made larger" as in allow to specify additional parts of the 96bit "taildata" to be incremented when running out of nonce space?
107 2012-09-19 10:21:32 <[7]> the only things one can really roll are the nonce and ntime... nbits doesn't make much sense and the last bits of the merkle root neither
108 2012-09-19 11:09:47 <electronplusplus> Hi, I want to buy a FPGA but I'm not sure how to pick the right one. I saw the butterflylabs prices and when compared to other, it seems like a scam. How technical details should I look for when choosing an FPGA?
109 2012-09-19 11:12:13 <kjj_> cost and hash rate. divide the second one by the first one to find out how many hashes per second per dollar you are spending.
110 2012-09-19 11:12:16 <otimm> i'd start with non technical details like actual delivery or support
111 2012-09-19 11:12:39 <kjj_> also, if you like p2pool, make sure the one you buy can handle short cycles (I don't think BFL can be used on p2pool)
112 2012-09-19 11:13:13 <kjj_> heh, and as otimm says, whether they are actually shipping or not is a big factor
113 2012-09-19 11:13:57 <[7]> does someone happen to know what the network limits on ntime are?
114 2012-09-19 11:14:08 <[7]> and what would be a reasonable "acceptable range"?
115 2012-09-19 11:14:10 <electronplusplus> how about butterfly labs? it's a scam, right?
116 2012-09-19 11:14:12 <kjj_> yeah
117 2012-09-19 11:14:30 <kjj_> BFL has been shipping FPGAs for quite a while now, with plenty of happy customers
118 2012-09-19 11:14:44 <[7]> for most pools it's 0 to +120 secs, which seems a bit tight to me
119 2012-09-19 11:15:03 <otimm> electronplusplus: they have shipped in the past, but their asic offerings look questionable
120 2012-09-19 11:15:38 <electronplusplus> the images on their web site are rendered, I think
121 2012-09-19 11:15:46 <kjj_> the new stratum protocol should take care of high speed mining. check slush and btcguild
122 2012-09-19 11:15:47 <[7]> electronplusplus: if you want something that actually delivers almost immediately (1-2 working days usually), buy X6500 boards
123 2012-09-19 11:15:52 <kjj_> more pools should support it in the future
124 2012-09-19 11:16:01 <[7]> cablesaurus has around 10 of them in stock right now
125 2012-09-19 11:16:26 <[7]> but for 5+ boards you might get a bulk price directly from us
126 2012-09-19 11:17:25 <otimm> i am pretty happy with an 4x Spartan 6 XC6SLX150 board from a german supplier
127 2012-09-19 11:18:00 <sipa> ztex?
128 2012-09-19 11:18:04 <otimm> yes
129 2012-09-19 11:18:05 <[7]> well, that's about the most expensive one you can find
130 2012-09-19 11:18:27 <[7]> and also doesn't ship immediately, at least for bigger quantities
131 2012-09-19 11:18:35 <kjj_> I'm just not buying anything right now. if ASICs show up, an investment in FPGAs at this point will never pay off
132 2012-09-19 11:19:33 <otimm> just wanted this one board, did not plan to invest big at the moment, looked like the most trustworthy
133 2012-09-19 11:20:13 <sipa> the ztex one certainly works
134 2012-09-19 11:20:33 <kjj_> it doesn't help that actual FPGA chips are ungodly expensive
135 2012-09-19 11:21:12 <[7]> electronplusplus: which country are you located in?
136 2012-09-19 11:27:56 <kjj_> I'm pretty sure that in a few months the FPGA era will be seen as nothing more than a way to bootstrap ASIC production. FPGAs don't deliver any more hashes per second per dollar than GPUs
137 2012-09-19 11:28:21 <sipa> they do produce more hashes per joule than GPUs though
138 2012-09-19 11:28:23 <sipa> significantly
139 2012-09-19 11:28:48 <kjj_> yes, by a lot. but for various reasons, I don't think that factor is the important one
140 2012-09-19 11:29:51 <sipa> it depends on the % of mining revenue being spent on electricity costs
141 2012-09-19 11:30:02 <otimm> but it is all speculation, nobody has seen a working asic yet
142 2012-09-19 11:30:11 <sipa> indeed
143 2012-09-19 11:30:26 <sipa> though i found the fact that someone from BFL was present at the london conference reassuring
144 2012-09-19 11:30:47 <sipa> in the sense that they're not some anonymous entity
145 2012-09-19 11:31:07 <kjj_> but there are chip fabs that will take your FPGA firmware and build THAT chip, so it isn't like they aren't coming soon
146 2012-09-19 11:31:42 <[7]> kjj_: that's not really a viable strategy
147 2012-09-19 11:31:53 <kjj_> how so?
148 2012-09-19 11:32:14 <[7]> you lose the reprogrammability of fpgas but still can't compete against "real" asics
149 2012-09-19 11:32:32 <sipa> if you're going to do the effort of making an ASIC, better spend some money on getting the best performance you can get out of it
150 2012-09-19 11:32:42 <kjj_> I'd be totally amazed if there are "real" ASICs coming soon
151 2012-09-19 11:33:00 <[7]> well standard cell designs are still much better than hardcopys or even easypath
152 2012-09-19 11:33:35 <otimm> bitcoin is growing steadily so i'd say we see asic in the next 12 months, but next 3 i am not so sure
153 2012-09-19 11:33:53 <kjj_> these designs are not like Intel CPU designs with teams of nerds hand carving gates and busses
154 2012-09-19 11:34:55 <kjj_> or maybe I'm wrong about that. I just don't see bitcoin on that scale yet
155 2012-09-19 11:35:46 <otimm> it is a huge step from fpga to asic indeed
156 2012-09-19 11:36:51 <[7]> so... does anybody here think that one will ever need to roll ntime by more than 255 seconds?
157 2012-09-19 11:39:35 <kjj_> 255 seconds is halfway to the next block already
158 2012-09-19 11:40:12 <sipa> no, 600 seconds would be halfway to the next block
159 2012-09-19 11:40:37 <kjj_> 600 seconds would BE the next block. 10*60=600
160 2012-09-19 11:41:09 <sipa> 600 is the average time between blocks, not the maximum or exact time
161 2012-09-19 11:41:30 <kjj_> agreed, and nothing stops blocks from moving backwards in time
162 2012-09-19 11:41:47 <kjj_> still, messing with the timestamp was a hack that needs to die a quick death as soon as possible
163 2012-09-19 11:42:46 <[7]> IMO it would have been much more reasonable to bury the nBits field somewhere in the merkle tree and put 4 bytes of extranonce into the header
164 2012-09-19 11:42:55 <[7]> that would have avoided all of this mess
165 2012-09-19 11:43:19 <sipa> the only mess is the current mining protocol; there is nothing technically hard about local work generation
166 2012-09-19 11:43:36 <[7]> my point is that I'm currently designing a hardware communication protocol which needs to be capable supporting of very high hashrates
167 2012-09-19 11:43:50 <[7]> and doing block generation on the hardware itself isn't really feasible
168 2012-09-19 11:44:17 <sipa> well, getwork + rollntime is enough for 4GH/s
169 2012-09-19 11:44:28 <[7]> transferring a new block header for every 4.3GH calculated isn't really feasible either
170 2012-09-19 11:44:41 <epscy> 4GH/s is more than anybody will ever need
171 2012-09-19 11:44:47 <[7]> lol
172 2012-09-19 11:44:47 <kjj_> heh
173 2012-09-19 11:44:52 <[7]> yeah, 640KB...
174 2012-09-19 11:45:26 <kjj_> what's wrong with sending half a kilobyte per second per core?
175 2012-09-19 11:46:19 <kjj_> actually, half a kilobit, not kilobyte. that's 8 times easier
176 2012-09-19 11:46:43 <[7]> there are several constraints that make this impractical (it would require large packets of variable size, and it would cause avoidable latencies after new blocks are found)
177 2012-09-19 11:47:11 <[7]> ah, I thought you meant transferring the data required for on-hardware block generation
178 2012-09-19 11:47:35 <[7]> and I'm not talking 4GH/s per core here
179 2012-09-19 11:47:59 <[7]> as this protocol is intended to be somewhat future proof I'd like to push the limit to at least ~1TH/s per core
180 2012-09-19 11:48:04 <kjj_> by core, I mean ASIC core.
181 2012-09-19 11:48:12 <[7]> yes
182 2012-09-19 11:49:08 <[7]> if people are already working on low-cost ~15GH/s asic chips these days, that'll probably grow to the 3 figure GH/s per chip fairly quickly
183 2012-09-19 11:49:34 <andyrossy> the cost of the hardware for these ASICs doesnt add up
184 2012-09-19 11:49:39 <andyrossy> i call pirate mark 2.
185 2012-09-19 11:49:41 <kjj_> that seems unlikely to me
186 2012-09-19 11:49:49 <sipa> andyrossy: explain
187 2012-09-19 11:50:04 <sipa> (not questioning, just interested in what numbers you have)
188 2012-09-19 11:50:19 <shamoon> super noob question. i'm trying to work on the source code for bitcoin. after i make a change, how do i run it to see the effect? I shouldn't have to make the whole thing for a small change, should i?
189 2012-09-19 11:50:21 <kjj_> the clock rate is bound, and you can only unroll so far. more hashes per second is going to mean more cores
190 2012-09-19 11:50:32 <[7]> shamoon: you do
191 2012-09-19 11:50:34 <kjj_> shamoon: yes
192 2012-09-19 11:50:50 <kjj_> the good news is that make is super duper smart and will only rebuild what it must
193 2012-09-19 11:50:51 <[7]> kjj_: well what is a "core" in your terms?
194 2012-09-19 11:50:55 <sipa> shamoon: the build system will make sure you don't rebuild parts which aren't changed
195 2012-09-19 11:51:05 <shamoon> so i need to make it, run the binary and see the impact of my change(s)?
196 2012-09-19 11:51:09 <gmaxwell> shamoon: make will 'only' recompile the required things, but thats often everything (e.g. if you edit any of several of the headers).
197 2012-09-19 11:51:21 <kjj_> [7]: like a core in your CPU.
198 2012-09-19 11:51:23 <gmaxwell> shamoon: right.
199 2012-09-19 11:51:33 <shamoon> okay then, wish me luck as i delve into contributing to this awesome project (hopefully)
200 2012-09-19 11:51:34 <[7]> well, there are probably hundreds of those inside those asics
201 2012-09-19 11:51:34 <kjj_> [7]: we can't make those any faster either, so we pile on more of them
202 2012-09-19 11:51:42 <[7]> but those are abstracted away by the hardware
203 2012-09-19 11:51:43 <sipa> shamoon: what are you trying to accomplish?
204 2012-09-19 11:51:46 <shamoon> and thank you all for being so helpful
205 2012-09-19 11:51:57 <shamoon> nothing yet... going through issues and seeing what i can tackle
206 2012-09-19 11:52:02 <sipa> ok
207 2012-09-19 11:52:06 <kjj_> I don't mean a fundamental logic unit or even a group of those. I mean one unit of sha256
208 2012-09-19 11:52:10 <shamoon> but step 1 is do SOMETHING to see the impact
209 2012-09-19 11:52:19 <[7]> so what I usually refer to is a "logical" core, which is usually one (emulated) high-performance mining core per chip
210 2012-09-19 11:52:42 <[7]> or whatever is presented to the outside
211 2012-09-19 11:53:19 <[7]> technically you can view these asics as one huge superscalar core, just like modern CPU cores are
212 2012-09-19 11:53:49 <[7]> (each CPU core also has multiple execution units that work in parallel if possible, but that parallelism can be exploited to a much higher degree on that kind of chips)
213 2012-09-19 11:53:54 <sipa> gmaxwell: i'm seeing a very weird big here... valgrind only shows one error, in a stack trace 4 deep, sha256 being called on a null pointer; gdb shows a stack trace 1000s deep, all garbage
214 2012-09-19 11:54:05 <kjj_> still, say the BFL minirig is a single chip. 1 TH/sec requires ~250 midstates per second, or 16000 bytes
215 2012-09-19 11:54:13 <sipa> stack corruption for sure, but why didn't catch valgrind the corruption earlier
216 2012-09-19 11:54:40 <gmaxwell> [7]: I'm still not following what your issue is here. At 100 getworks/sec with 8 bits of time rolling, you get 109TH/s of capacity.
217 2012-09-19 11:55:02 <[7]> the point is that I want to offload as much of this as practically possible to the hardware
218 2012-09-19 11:55:19 <sipa> well it's not *impossible* to do work generation on the hardware
219 2012-09-19 11:55:20 <[7]> so I don't have to send 100 requests to each device per second, but more like one per second with a +100 ntime range
220 2012-09-19 11:55:26 <sipa> it's just somewhat more sha256
221 2012-09-19 11:55:40 <[7]> sipa: pushing the required data to the hardware is the bigger problem here
222 2012-09-19 11:55:49 <gmaxwell> sipa: use exp-ptr-check too in valgrind. (er, that got renamed one minute while I remember the new name is) memcheck is kinda lossy for the stack, but I dunno why stackguard isn't catching it either.
223 2012-09-19 11:56:05 <gmaxwell> [7]: thats not a goal; it's a mechenism. You might as well be telling us that it has to be a miner made of meat.
224 2012-09-19 11:57:04 <[7]> well, I'm not asking you to design the protocol, I'm just asking if you consider it feasible to go past +255 ntime one day, and providing some reasoning why I think this might be wanted at some point
225 2012-09-19 11:58:03 <kjj_> I still say that messing with the timestamp was a hack that needs to die a quick death as soon as possible
226 2012-09-19 11:58:12 <gmaxwell> [7]: whats the reasoning? ntime +255 gets you 100TH/s on 100getworks/s.
227 2012-09-19 11:58:32 <sipa> [7]: pushing the data to the device... if you can get 464 bytes (header + 12 merkle path entries) to the device every time the block (or some transactions) changes, you can support +infinity hashrate
228 2012-09-19 11:59:19 <[7]> where does that 12 limit come from?
229 2012-09-19 11:59:38 <[7]> why can't there be more than 4K txns per block?
230 2012-09-19 11:59:47 <gmaxwell> Because there is a maximum blocksize of 1MB.
231 2012-09-19 11:59:58 <[7]> that's all stuff that's likely to change at some point though
232 2012-09-19 12:00:15 <[7]> 4k txns per block probably won't be sufficient in a couple of years
233 2012-09-19 12:00:28 <gmaxwell> I'm skeptical about that, but it seems very clear to me that you're just adding constraints to preserve your goal.
234 2012-09-19 12:01:05 <[7]> well I can think of two ways to get this done:
235 2012-09-19 12:01:14 <gmaxwell> [7]: If there isn't block space scarcity bitcoin makes no economic sense. It might make sense to increase it somewhat in the far future, but it must remain scarce or security can't be funded.
236 2012-09-19 12:01:27 <kjj_> but so what? say 24 entries in the merkle table. still under a kilobyte
237 2012-09-19 12:01:30 <sipa> [7]: changing that requires a hardfork, and I don't expect that will happen without a 1- or 2-year advance planning
238 2012-09-19 12:01:31 <gmaxwell> And going from 12 to 16 doesn't change the data size numbers much.
239 2012-09-19 12:01:39 <[7]> I still wouldn't dare to hardwire that 12 number in my code though
240 2012-09-19 12:02:08 <sipa> but indeed, make it 64 merkle entries if you want, and do it under 4K data per update, and support more transactions per block than there have been hashes performed to date
241 2012-09-19 12:02:33 <sipa> [7]: how long do you figure your protocol will be useful?
242 2012-09-19 12:02:38 <gmaxwell> or indeed, that.
243 2012-09-19 12:03:19 <sipa> 2128 bytes per update, to be precise
244 2012-09-19 12:03:20 <[7]> my experience tells me that protocols generally will be useful for much shorter than anticipated, so one should better add some safety margin
245 2012-09-19 12:03:22 <gavinandresen> yeah, do what sipa and gmaxwell said, have the hardware compute the merkle root and you're good forever.
246 2012-09-19 12:04:03 <[7]> well, that's one possibility, letting the hardware work fully autonomously, just pushing merkle tree updates everytime you decide you want to include new TXNs
247 2012-09-19 12:04:28 <[7]> and thus allow broadcasting of *one* set of data to all devices after a new block is found, eliminating that traffic storm
248 2012-09-19 12:05:17 <[7]> (with the different cores working on different starting extranonces that get set up during boot)
249 2012-09-19 12:05:48 <kjj_> USB even does broadcasting, so you get transaction updates nearly for free, regardless of your cluster size
250 2012-09-19 12:06:00 <gavinandresen> seems like the simplest solution to me. A 256-bit extranonce space is plenty big enough to start with a globally unique, random nonce
251 2012-09-19 12:06:04 <[7]> kjj_: er, what?
252 2012-09-19 12:06:13 <[7]> I never heard of USB broadcasts...
253 2012-09-19 12:06:32 <[7]> but I don't need them either, so that's fine
254 2012-09-19 12:06:35 <[7]> so while that might be the ideal long term solution, it just won't work with most of today's mining pools
255 2012-09-19 12:07:04 <[7]> many of those work with rollntime at the best
256 2012-09-19 12:07:30 <kjj_> all devices on a USB branch see everything the host says. they just ignore things that don't have their own address in the header
257 2012-09-19 12:07:34 <sipa> [7]: i think betting on the existance of the current-style centralized mining pool is a far less safe bet, than betting on there not being more than 4000 tx/block any time soon
258 2012-09-19 12:07:44 <[7]> kjj_: that's not true at all
259 2012-09-19 12:08:14 <[7]> sipa: sure, I'm just wondering if I need to implement two separate models or if I can merge this somehow
260 2012-09-19 12:08:43 <kjj_> [7]: you sure? the docs I'm looking at right now make that pretty clear
261 2012-09-19 12:09:11 <[7]> kjj_: at least as soon as hubs are involved, which they usually are (and the host's root ports form a hub for that matter as well)
262 2012-09-19 12:09:50 <kjj_> upstream traffic only goes towards the host, but downstream traffic is replicated to all downstream ports
263 2012-09-19 12:10:41 <[7]> traffic to address 0 might possibly be broadcast, but I'm fairly sure that at least USB2 hubs need to learn their device's addresses
264 2012-09-19 12:11:25 <[7]> if a high speed hub has a full speed device on it, the highspeed bus will be released while the fullspeed transfer is in progress, with split transactions and that kind of stuff
265 2012-09-19 12:11:25 <kjj_> that sounds like a pointless complication. it isn't like an ethernet switched fabric where slaves can talk to each other
266 2012-09-19 12:12:31 <[7]> anyway, relying on any kind of USB broadcast would be massively standards-incompliant
267 2012-09-19 12:12:38 <[7]> and probably not work at all with most usb chipsets
268 2012-09-19 12:14:13 <kjj_> actually, a google search for "microcontroller usb bus snooping" is surprisingly encouraging
269 2012-09-19 12:14:53 <sipa> gmaxwell: any idea what that exp-ptr-check is called now?
270 2012-09-19 12:16:09 <gmaxwell> sipa: sgcheck
271 2012-09-19 12:16:51 <gmaxwell> sipa: http://valgrind.org/docs/manual/sg-manual.html
272 2012-09-19 12:18:05 <sipa> meh, not installed
273 2012-09-19 12:18:32 <gmaxwell> might be called exp-ptrcheck on the version you have.
274 2012-09-19 12:19:15 <sipa> ah, exp-sgcheck
275 2012-09-19 12:19:16 <sipa> !
276 2012-09-19 12:20:56 <sipa> gmaxwell: looks excessively slow, but i'll let it run :)
277 2012-09-19 12:21:40 <gmaxwell> It's slower, indeed.
278 2012-09-19 12:21:51 <sipa> in memcheck it already takes hours to reproduce
279 2012-09-19 12:33:22 <sipa> gmaxwell: after 15 minutes: wallet is loaded :)
280 2012-09-19 12:41:51 <gmaxwell> I wonder if there is money to be made running an online program to help people with gambling addiction. https://bitcointalk.org/index.php?topic=80312.msg1201785#msg1201785 0_o
281 2012-09-19 12:48:48 <[7]> btw, does the stratum protocol allow for a client to specify its desired difficulty?
282 2012-09-19 12:49:36 <slush> [7]: no, difficulty is driven by server
283 2012-09-19 12:49:59 <slush> [7]: but server can provide a tool (on user profile?) to specify requested difficulty, of course. Then it's not a matter of protocol
284 2012-09-19 12:50:43 <[7]> is there a particular reason for not letting the client hint the server at an adequate difficulty?
285 2012-09-19 12:51:16 <slush> [7]: well, as a hint - maybe yes. But still the server will do the final decision
286 2012-09-19 12:51:29 <[7]> sure, makes sense for the servers to bound it
287 2012-09-19 12:52:10 <slush> but the retargeting of newly connected miner is quite fast, so I think leaving it to "autopilot" is good enough
288 2012-09-19 12:52:54 <slush> there are two implementations at the time. afaik btcguild is retargeting every 10 seconds, I'm retargeting every 100 submits and on new block
289 2012-09-19 12:55:09 <slush> [7]: every 100 submits to push difficulty higher and on new bitcoin block to push difficulty higher for workers who slower down for some reason
290 2012-09-19 12:55:59 <slush> on new block to push it lower, of course :)
291 2012-09-19 12:56:21 <[7]> do you do it per connection, per worker account, or per user account?
292 2012-09-19 12:56:27 <slush> per connection
293 2012-09-19 12:56:33 <[7]> and what's your target?
294 2012-09-19 12:56:59 <slush> I'm not decided yet. Ideally 5-10 seconds per share
295 2012-09-19 12:57:14 <[7]> people might prefer variance over bandwidth or the other way round
296 2012-09-19 12:57:38 <slush> but I'll probably have also per-backend limit to be sure everything will balance automatically when some huge join it.
297 2012-09-19 12:57:59 <slush> it's better for everybody to push everyone's difficulty a bit high than have unresponsible server
298 2012-09-19 12:58:49 <[7]> also at which difficulty do you start? 1?
299 2012-09-19 12:59:11 <[7]> this means that an asic could cause a burst of 100 requests after connecting
300 2012-09-19 12:59:35 <[7]> whereas a higher initial difficulty would be suboptimal for slow miners which might effectively be solo'ing that way until the next block
301 2012-09-19 13:00:03 <[7]> so I think at least a way for the miner to tell the server about its expected hashrate while connecting might be helpful
302 2012-09-19 13:02:07 <slush> [7]: I'll add "minimal difficulty" for the worker on profile page
303 2012-09-19 13:02:12 <slush> actually it's here already, just hidden
304 2012-09-19 13:03:42 <slush> so if somebody connect 1THash/s asic without setting higher difficulty on the profile, there'll be a burst for one second or so, then it retarget him very quickly.
305 2012-09-19 13:06:12 <gavinandresen> ACTION is glad he doesn't have OCD or he'd waste the entire day on http://xkcd.com/1110/
306 2012-09-19 13:06:31 <kjj_> I had to stop after a few minutes and go looking in the forums for the cheat
307 2012-09-19 13:06:48 <gavinandresen> I do have enough OCD that I found the bitcoin reference by clicking and dragging....
308 2012-09-19 13:08:32 <gavinandresen> I heard he hid a private key address with 10 BTC somewhere in there....
309 2012-09-19 13:09:21 <gavinandresen> ACTION now feels a little guilty about starting rumors
310 2012-09-19 13:09:42 <kjj_> xkcd's bitcoin reference was the big announcement?
311 2012-09-19 13:10:20 <gavinandresen> <sarcasm>Yes, that is the Big Announcment(tm)</sarcasm>
312 2012-09-19 13:12:53 <otimm> i think the private key is hidden in a mine deep underground
313 2012-09-19 13:13:03 <kjj_> you should tell people it is so that they can let it go
314 2012-09-19 13:15:13 <gavinandresen> i heard the private key is in the middle of the sky
315 2012-09-19 13:15:33 <gavinandresen> wait... or maybe it was split into two parts....
316 2012-09-19 13:16:10 <gavinandresen> ooh, I know, it is a brain wallet, you have to find all the words beginning with the letter 'w' in the strip....
317 2012-09-19 13:17:21 <gavinandresen> Seriously, I would like to see more "hide some bitcoins" games. I bet somebody creative and smart could run a couple of free ones, then maybe charge people to enter later ones (or pay for clues....)
318 2012-09-19 13:26:54 <sipa> gavinandresen: there's a zoomable version somewhere on the web
319 2012-09-19 13:27:07 <gavinandresen> sipa: that's cheating
320 2012-09-19 13:27:45 <sipa> good. ok. carry on.
321 2012-09-19 13:32:13 <otimm> http://forums.xkcd.com/viewtopic.php?t=91362&p=3133922
322 2012-09-19 13:49:38 <t7> oo that might be the last comic :O
323 2012-09-19 13:51:59 <sipa> ?
324 2012-09-19 14:45:56 <copumpkin> why do later blocks take longer to download? I've seen the explanation before that fewer nodes on the network have them to serve to you, but isn't the network mostly at roughly the same spot? It seems odd that a significant portion of the network would be missing even 100 of the most recent blocks, and the slowdown starts way before that
325 2012-09-19 14:47:29 <gmaxwell> 0_o
326 2012-09-19 14:47:42 <gmaxwell> copumpkin: who the @#$@# told you that?
327 2012-09-19 14:47:53 <copumpkin> I've seen it repeated in a few places, can't remember :)
328 2012-09-19 14:48:05 <gmaxwell> Pure jibberish. They're slower because they're much much bigger because they're full of transactions; lots of signatures to validate, more data to transfer.
329 2012-09-19 14:48:11 <copumpkin> ah, fair enough
330 2012-09-19 14:48:45 <gmaxwell> Also slower because lookups in the txn index slow down the more total transactions there have been. (ultraprune largely fixes this)
331 2012-09-19 14:51:35 <phantomcircuit> gmaxwell, should eventually be more or less flat time to lookup
332 2012-09-19 14:52:03 <gmaxwell> phantomcircuit: assuming that the database scales well. :P
333 2012-09-19 14:52:08 <phantomcircuit> true
334 2012-09-19 14:52:29 <gmaxwell> big performance difference between the lookup time being in ram and on disk.
335 2012-09-19 14:52:49 <phantomcircuit> well assuming that the top part of the binary tree are in ram
336 2012-09-19 14:52:59 <phantomcircuit> hitting the last bit that's on disk shouldn't be *that* bad
337 2012-09-19 14:53:05 <phantomcircuit> but of course it will be :)
338 2012-09-19 14:58:35 <Ukto> not sure if this has been a discussion yet in here or not. probably.. but lately we have been having many 30+ min blocks, just had a 60+min block.. and diffs stil going up by 7%.. to me.. it seems the higher the diff, the larger a variance... have there been any thoughts on this?
339 2012-09-19 15:01:01 <gmaxwell> Ukto: higher difficulties don't result in larger variance. (assuming they're matched to the hashrate.
340 2012-09-19 15:01:21 <Ukto> hmm
341 2012-09-19 15:01:28 <gmaxwell> ;;bc,tblb 30m
342 2012-09-19 15:01:33 <gribble> 4 hours, 30 minutes, and 24 seconds
343 2012-09-19 15:01:56 <Ukto> I just think its strange that were getting 30~60min blocks pretty common, and having to go up in diff :/
344 2012-09-19 15:01:59 <gmaxwell> ^ see, many 30+ minute blocks are expecected... one every 4.5 hours or so on average.
345 2012-09-19 15:02:21 <Ukto> oh, ill see them 3~5 in a row :/
346 2012-09-19 15:02:51 <gmaxwell> Ukto: yes, that happens too.
347 2012-09-19 15:02:53 <Ukto> ;;bc,tblb 60m
348 2012-09-19 15:02:54 <gribble> 5 days, 19 hours, 24 minutes, and 58 seconds
349 2012-09-19 15:03:11 <gmaxwell> Ukto: also, are you looking at block timestamps? because they're lies and fantasies. ;P
350 2012-09-19 15:03:24 <Ukto> no, I am watching LP's
351 2012-09-19 15:03:44 <Ukto> the project I am working on, reqires me to wait for each LP to triggr to debug
352 2012-09-19 15:03:59 <gmaxwell> Ukto: well pools dork around with LPs to screw with hoppers.
353 2012-09-19 15:04:02 <Ukto> so i get stuck watching a lot of logs fly by for that percise moment :P
354 2012-09-19 15:04:14 <Ukto> well, i am watching for actual block changes
355 2012-09-19 15:04:16 <Ukto> not just from lp
356 2012-09-19 15:04:25 <Ukto> i am waiting for block changes
357 2012-09-19 15:04:28 <Ukto> so test my LP software
358 2012-09-19 15:05:10 <gmaxwell> In any case, block times are random. They have an expected value. What you're telling me so far isn't inconsistent with the expected behavior.
359 2012-09-19 15:05:24 <Ukto> k, just asking :)
360 2012-09-19 15:05:32 <Ukto> you guys know alot more about that side of things than I do by zillions. :)
361 2012-09-19 15:09:44 <gmaxwell> It's always fine to ask.
362 2012-09-19 16:00:25 <BlueMatt> ahh xkcd..."If you're having fencepost errors I feel bad for you, son - I got 99 problems but somehow solved 101"
363 2012-09-19 16:02:59 <gmaxwell> jgarzik: I'm not familar with a current failure mode where we get stuck when peers offer us a new block.
364 2012-09-19 16:04:10 <jgarzik> gmaxwell: outside of my own experience recently, IRC and forums still pop up "I am well connected, but not advancing" reports
365 2012-09-19 16:04:34 <jgarzik> if they are well connected, they are getting block offers
366 2012-09-19 16:04:49 <gmaxwell> jgarzik: yes, I've seen those reports, but thus far as far as I can tell (big hunk of salt) all were resolved by simply waiting for the next block.
367 2012-09-19 16:04:55 <gmaxwell> hmph.
368 2012-09-19 16:05:10 <jgarzik> gmaxwell: no the public node running git HEAD was stuck 1000 blocks behind
369 2012-09-19 16:05:11 <gmaxwell> (well, all where it wasn't due to having already rejected the real chain; seen a bunch of those)
370 2012-09-19 16:05:29 <jgarzik> "stuck" is at least a day behind, in my book
371 2012-09-19 16:05:43 <helo> i can't get over how nice raw transactions and the debug console is
372 2012-09-19 16:05:56 <gmaxwell> jgarzik: well crap. Thats bad.
373 2012-09-19 16:06:58 <helo> its a great way to learn too
374 2012-09-19 16:07:02 <gmaxwell> jgarzik: might be interesting to loadblocks initilize 1000 blocks behind, and then disable getblocks.
375 2012-09-19 16:08:17 <jgarzik> gmaxwell: note, I do not claim #1834 fixes this problem... only closes one window. #1834 should eliminate a possible multi-hour pause, before things straighten out.
376 2012-09-19 16:09:36 <gmaxwell> jgarzik: Sure, I understand what you're doing that. I'm not sure that the workaround is wise. If this happens to a miner its an extreme fork creation risk, with or without that change... but it may be harder to track down with it in.
377 2012-09-19 16:09:51 <gmaxwell> er why youre doing that* (now)
378 2012-09-19 16:11:51 <gmaxwell> e.g. whatever is happening there happens to a major pool and we get a third of the hashpower mining some fork for an hour.
379 2012-09-19 16:13:16 <jgarzik> gmaxwell: that is not really applicable to #1834
380 2012-09-19 16:14:17 <gmaxwell> It's applicable to the root issue behind whatever is motivating 1835.
381 2012-09-19 16:14:59 <gmaxwell> My concern on 1834 is gone, so long as it's only about initial selection. Though it may exacerbate the risk from whatever the heck that won't-reorg bug you hit was.
382 2012-09-19 16:15:08 <gmaxwell> but better to just worry about that root problem.
383 2012-09-19 16:15:25 <gmaxwell> I'm trying to reproduce your stuckness.
384 2012-09-19 16:16:51 <jgarzik> gmaxwell: the public node was getting tons of incoming connections, plus the normal 8 outgoing, and was just over 1000 blocks behind. was git HEAD circa 1000+144 blocks ago. _very_ well connected. restarted and it successfully verified and caught up.
385 2012-09-19 16:17:13 <jgarzik> gmaxwell: #1835 adds a guarantee that is harmless if wrong: we send extra getblocks that turn out to be unneeded
386 2012-09-19 16:17:19 <jgarzik> but useful if correct
387 2012-09-19 16:18:26 <gmaxwell> jgarzik: how many incoming connections?
388 2012-09-19 16:18:34 <gmaxwell> (just curious)
389 2012-09-19 16:18:40 <jgarzik> gmaxwell: 80-100
390 2012-09-19 16:19:41 <gmaxwell> All bitcoinj? :P heh but yea, I believe what you saw. Just need to figure out how to reproduce. I've never seen that, and I have a half dozen nodes running, some public some not.
391 2012-09-19 16:21:19 <gmaxwell> jgarzik: I just have some concern that 1835 doesn't really reduce the risk of the underlying issue it works around, but it may make the cause harder to find because it 'fixes' it (well, if it indeed does??? not sure why a getblocks would unstick it) before its far enough behind to be obviously broken beyond the regular expected lag.
392 2012-09-19 16:25:26 <jgarzik> gmaxwell: #1834 is separate from #1835 for reasons like this. #1834 is a bug fix, while #1835 is a fix attempt.
393 2012-09-19 16:27:00 <gmaxwell> Yes, I'm fine with 1834 now. (which I also said on it last night; I was a dipshit and didn't read the patch, only the title, and thought it was a change to never attempt to fetch a block from a node claiming a count lower than ours)
394 2012-09-19 16:31:35 <jgarzik> or heck, just send getblocks to everybody and let God sort it out
395 2012-09-19 16:31:41 <jgarzik> ;p
396 2012-09-19 16:32:59 <gmaxwell> if getblocks unsticks it!
397 2012-09-19 16:34:03 <jgarzik> More generally, the P2P code needs to spread out its getblock and getdata requests across peers
398 2012-09-19 16:35:32 <jgarzik> that also solves the common problem of pausing for hours, expecting the remote peer to send more data
399 2012-09-19 16:35:44 <jgarzik> but it never does (or does so very slowly)
400 2012-09-19 16:40:52 <gmaxwell> jgarzik: that problem??? of _hours_??? shouldn't??? exist.
401 2012-09-19 16:41:16 <gmaxwell> it should pause but only until the next network block comes in then it'll begin fetching from the peer that gave it the network block.
402 2012-09-19 16:42:04 <gmaxwell> And this does work, at least sometimes. If it doesn't work always then thats interest.. of course that doesn't replace smarter fetching generally.
403 2012-09-19 16:42:15 <jgarzik> gmaxwell: note that PushGetBlocks filters out duplicate requests
404 2012-09-19 16:42:33 <jgarzik> gmaxwell: so what seems like a request, from reading main.cpp, may not reach the remote
405 2012-09-19 16:44:35 <jgarzik> gmaxwell: also, "strange getblocks behavior" continues to occur each time a new network block is seen
406 2012-09-19 16:44:43 <jgarzik> gmaxwell: e.g. my public nodes see
407 2012-09-19 16:44:45 <jgarzik> getblocks -1 to 00000000000000000000 limit 500
408 2012-09-19 16:44:58 <jgarzik> gmaxwell: immediately after SetBestChain() success
409 2012-09-19 16:45:03 <jgarzik> gmaxwell: over and over again.
410 2012-09-19 16:45:21 <jgarzik> you also see the same heights requested, over and over again
411 2012-09-19 16:45:24 <jgarzik> getblocks 153057 to 00000000000006276718 limit 500
412 2012-09-19 16:45:37 <jgarzik> repeats at each SetBestChain()
413 2012-09-19 16:46:32 <jgarzik> one expects such getblocks triggered as you say... but the same height requested repeatedly with each SetBestChain() implies an odd condition
414 2012-09-19 16:47:16 <jgarzik> "with each SetBestChain()" is shorthand for "following each new network block event", if that is not clear... SetBestChain is simply a readily visible marker in the log for this behavior
415 2012-09-19 16:59:45 <jgarzik> ASIC update: BFL does burn-in testing on a live pool, EMC, for ~24 hours before packing and shipping
416 2012-09-19 17:00:50 <gmaxwell> jgarzik: hm, are they shipping product already?
417 2012-09-19 17:01:57 <jgarzik> gmaxwell: no. BFL_Josh was describing their current product procedure, with the implication that that will continue for future products.
418 2012-09-19 17:15:04 <_dr> i'll be happy to see the 'experts', formerly assuring that notime sooner than 12 months before we'll see asics, proclaiming 'yeah, i knew bfl would deliver'
419 2012-09-19 17:15:30 <gmaxwell> _dr: who are you talking about?
420 2012-09-19 17:16:05 <_dr> i'm just quoting form the backlog
421 2012-09-19 17:19:42 <gmaxwell> _dr: your message above is the only 'time sooner than 12 months' in the bitcoin-dev log, I'm confused about what you're quoting.
422 2012-09-19 17:21:43 <_dr> someone was saying it would probably take 12 months before asics will arrive. however, it was not meant as a critique against that particular person. just wanted to point out that the numbers people are coming up with are somewhat interesting
423 2012-09-19 17:22:22 <_dr> why would it take 12 months to create a stupid chip which has almost no control logic and and array of (probably improved freely available) sha256 soft-ips
424 2012-09-19 17:23:02 <kjj_> heh. there are no bitcoin hashing engines that are freely available to be just dropped in
425 2012-09-19 17:23:18 <_dr> yes, but they are trivial
426 2012-09-19 17:24:15 <jgarzik> silicon and PCB engineering and fabbing is the most trivial thing on the planet. even my Aunt Tillie can do it, these days.
427 2012-09-19 17:24:58 <_dr> it's an automated process, isn't it? i know that it takes a lot of expertise, but it won't take someone to design a chip that long
428 2012-09-19 17:25:04 <sipa> i think the actual gate logic is the smallest problem
429 2012-09-19 17:25:12 <sipa> and the largest problem is the economics
430 2012-09-19 17:25:42 <_dr> in fact, some colleague at the chair i work teaches an asic class and they let students help design a cpu and already did their tape out (they started several months ago)
431 2012-09-19 17:26:49 <gmaxwell> _dr: it's harder when you're not targeting mundane process and when you're actually pushing the performance envelope.
432 2012-09-19 17:28:26 <_dr> gmaxwell: i totally agree. all i was trying to say was to take all these 'no way they're for real!', 'no way will asics hit in the next 12 months' with a grain of salt
433 2012-09-19 17:29:25 <gmaxwell> _dr: oh yea. Okay. I asked for the clarification just because I didn't know if you were also picking on the moderate positions. "Thats a risky thing to drop funds on" ::nods:: sounds like we agree.
434 2012-09-19 17:30:24 <_dr> of course i'm psychologically inclined to side with BFLs claims, since i pre-ordered
435 2012-09-19 17:30:26 <sipa> gmaxwell: reproduced in sgcheck... no errors at all
436 2012-09-19 17:30:28 <_dr> but i agree :)
437 2012-09-19 17:32:07 <gmaxwell> _dr: The point I've made to people is just that so far they've missed every deadline, and underperformed every spec.. but delivered. Though an asic run has high NRE, and if they flub it they may not be able to afford a respin. And their (initial at least, they took them down) sounded very agressive??? unachievable on 130nm. But other than that... sure.
438 2012-09-19 17:33:15 <_dr> i also expect them to lower their specs, but i'm still optimistic they'll deliver 'something' :)
439 2012-09-19 17:36:26 <gmaxwell> _dr: well, if the lack of funds recovery in the pirate40 case is a useful data point; it might not be rational to do anything than take the funds and vanish. :(
440 2012-09-19 17:40:03 <_dr> sorry, couldn't hear you over all my humming. but seriously, sure... could happen. otoh, they delivered their fpgas. seems like an awful lot of trouble to set up a scam like this.
441 2012-09-19 17:40:29 <gmaxwell> Agreed.
442 2012-09-19 17:41:19 <_dr> of course, there's also the fact that computer scientists have moral and are nice, they wouldn't do such a thing :)
443 2012-09-19 17:41:21 <sipa> also, they're not some anonymous entity like mybitcoin or pirateat40
444 2012-09-19 17:42:02 <sipa> ... or satoshi
445 2012-09-19 17:42:04 <gmaxwell> sipa: pirateat40 isn't an anonymous entity however. His name and other info has been well known since long before it, many people met him at the vegas event.
446 2012-09-19 17:42:05 <_dr> when i read the pirate thread, form the language my brain rapidly extracted 'bankster - do not trust':)
447 2012-09-19 17:42:21 <sipa> gmaxwell: really? :s
448 2012-09-19 17:42:54 <gmaxwell> Really.
449 2012-09-19 17:43:03 <sipa> why aren't people suing him?
450 2012-09-19 17:43:22 <_dr> or shooting him
451 2012-09-19 17:43:59 <maaku> i think there's a thread on the forums about just that
452 2012-09-19 17:44:04 <maaku> suing, not shooting
453 2012-09-19 17:44:07 <kjj_> more than one
454 2012-09-19 17:44:21 <gmaxwell> who the heck knows? Because he said if you do you'll be inelegable to be paid back? (he did, dunno if anyone cares) Because they feel stupid for falling for it? Because they only put stolen funds with him? Because they think that they can't take a bitcoin contract dispute to a regular court?
455 2012-09-19 17:44:42 <gmaxwell> Because they're lazy and resigned to the loss?
456 2012-09-19 17:45:03 <kjj_> I think they need to first convince a lawyer that they gave the bitcoins to him for something
457 2012-09-19 17:45:36 <_dr> well, if anything i know that laws pertaining to financial fraud in the us can't be very good :D
458 2012-09-19 17:45:39 <gmaxwell> kjj_: this shouldn't be a problem. The paper trail is a mile long.
459 2012-09-19 17:46:43 <kjj_> I suspect that some of the documentation is kinda sketchy
460 2012-09-19 17:46:54 <gmaxwell> In any case, it's expected that fraud has low report rates, whatever the reasons are. It's not a bitcoin unique thing, its one of the reasons fraud is as attractive as it is.
461 2012-09-19 17:47:22 <kjj_> say GLBSE disappeared tomorrow. I'm not sure that I have anything that really shows that I sent the bitcoins to the exchange for investing (rather than a donation)
462 2012-09-19 17:47:23 <gmaxwell> kjj_: In civil litigation the bar is not terribly high. And pirate has not appeared too careful.
463 2012-09-19 17:48:10 <kjj_> I've never dealt with pirate, so I don't know what people that dealt with him have for paperwork
464 2012-09-19 17:48:31 <gmaxwell> kjj_: it's perfectly possible to prevail in court over purely verbal agreements. Preponderance of the evidence, you know.
465 2012-09-19 17:49:08 <kjj_> still, I'd be nervous about going first
466 2012-09-19 19:09:15 <zooko> jgarzik: did you make some decisions about dforum design and Tahoe-LAFS?
467 2012-09-19 19:10:08 <jgarzik> zooko: trying to let things percolate in my brain
468 2012-09-19 19:10:25 <zooko> Cool.
469 2012-09-19 19:17:04 <DBordello> Does the wallet need to be unlocked to generate a new address? (CLI)
470 2012-09-19 19:18:57 <jgarzik> DBordello: strictly speaking yes, because an address requires a private key
471 2012-09-19 19:19:27 <jgarzik> DBordello: but it is possible to pregenerate addresses, and "request a new address" from the pre-generated pool
472 2012-09-19 19:19:45 <DBordello> jgarzik, ah, I was thinking it might be possible to encrypt the private key without the passprhase
473 2012-09-19 19:19:50 <DBordello> Thanks
474 2012-09-19 19:20:00 <DBordello> I'll stick with the pregenerated addresses then
475 2012-09-19 19:20:31 <sipa> the wallet encryption is symmetric, so no
476 2012-09-19 19:23:07 <etotheipi_> Any reason why Armory would not longer be able to complete the handshake with Bitcoin-Qt after upgrading to 0.7.0?
477 2012-09-19 19:23:13 <etotheipi_> or disconnect/blacklist logic?
478 2012-09-19 19:23:43 <sipa> nothing obvious i can think of
479 2012-09-19 19:24:36 <etotheipi_> what can I look for in the debug log?
480 2012-09-19 19:25:09 <sipa> try git-bisecting between 0.6.0 and 0.7.0, to see which commit broke it?
481 2012-09-19 19:25:36 <etotheipi_> well, it may not be broken... well on testnet it APPEARS to be
482 2012-09-19 19:25:53 <etotheipi_> if nothing comes to mind (like no protocol tweaks), I'll keep digging, myself
483 2012-09-19 19:25:53 <kjj_> were you working around the port increment issue?
484 2012-09-19 19:26:24 <Luke-Jr> 0.6.1..0.7.0 might be slightly easier
485 2012-09-19 19:27:09 <etotheipi_> not a port issue, because it definitely detects the Satoshi client properly
486 2012-09-19 19:27:13 <etotheipi_> and it tries to to connect
487 2012-09-19 19:27:35 <gmaxwell> etotheipi_: well testnet is totally rebooted.
488 2012-09-19 19:27:43 <sipa> oh, testnet3 is new in 0.7.0
489 2012-09-19 19:27:44 <gmaxwell> it's a different protocol version on testnet now.
490 2012-09-19 19:28:00 <gmaxwell> see /topic :)
491 2012-09-19 19:28:57 <etotheipi_> oh
492 2012-09-19 19:29:05 <etotheipi_> is there a two sentence summary?
493 2012-09-19 19:29:15 <etotheipi_> and what do you mean by "see /topic"?
494 2012-09-19 19:29:40 <sipa> the topic here mentions "testnet restarted in 0.7.0"
495 2012-09-19 19:30:13 <sipa> and testnet3 has different magic bytes
496 2012-09-19 19:30:23 <etotheipi_> what is: "PROCESSMESSAGE MESSAGESTART NOT FOUND"
497 2012-09-19 19:31:00 <sipa> every bitcoin message is prefixed by 4 magic bytes
498 2012-09-19 19:31:01 <etotheipi_> oh, different magic bytes will do it
499 2012-09-19 19:31:25 <sipa> see commit a9d811a9760
500 2012-09-19 19:33:50 <etotheipi_> new genesis block, too
501 2012-09-19 19:33:54 <etotheipi_> different home dir
502 2012-09-19 19:33:59 <etotheipi_> okay, great to know!
503 2012-09-19 19:36:25 <etotheipi_> so from now on, testnet dir will actually be ~/.bitcoin/testnet3 ?
504 2012-09-19 19:36:32 <gmaxwell> Correct.
505 2012-09-19 19:37:38 <sipa> until we get a next testnet... testnet3.1, testnet3.14, testnet3.141, ...
506 2012-09-19 19:39:13 <etotheipi_> blockexplorer.com/testnet is testnet3, now?
507 2012-09-19 19:39:35 <gmaxwell> yes, and the faucet.
508 2012-09-19 19:40:11 <etotheipi_> is the "addrByte" still the same?
509 2012-09-19 19:40:16 <etotheipi_> 0x6f
510 2012-09-19 19:41:25 <gmaxwell> yes.
511 2012-09-19 19:42:13 <diki> Couldn't find any info on the wiki, but what is shortest possible Bitcoin address? In this article https://en.bitcoin.it/wiki/List_of_address_prefixes it is mentioned that an address can be up to 34 characters(possible more?) but not the minimum.
512 2012-09-19 19:44:18 <kjj_> if I had to guess, I'd say likely to be this one:
513 2012-09-19 19:44:19 <kjj_> http://blockexplorer.com/address/1QLbz7JHiBTspS962RLKV8GndWFwi5j6Qr
514 2012-09-19 19:44:38 <kjj_> no, wait, that's the longest.
515 2012-09-19 19:44:45 <kjj_> http://blockexplorer.com/address/1111111111111111111114oLvT2
516 2012-09-19 19:44:52 <kjj_> that's the shortest
517 2012-09-19 19:45:12 <diki> Thanks.
518 2012-09-19 19:45:18 <etotheipi_> fantastic, "Handshake finished, connection open!"
519 2012-09-19 19:45:21 <etotheipi_> thanks guys
520 2012-09-19 19:45:42 <etotheipi_> lol, wait... can someone send me some testnet coins? :)
521 2012-09-19 19:45:59 <etotheipi_> mrnPvwkqSHuL5c9CGfUGcuYVzhT4rfFNPq
522 2012-09-19 19:46:25 <kjj_> diki: on the network however, they are all the same 160 bits long. the length is only variable in the base58 encoding
523 2012-09-19 19:47:43 <gmaxwell> etotheipi_: sent you some.
524 2012-09-19 19:47:45 <diki> Yes, I know the ripemd160 hash is exactly 20 bytes.
525 2012-09-19 19:48:38 <etotheipi_> thanks gmaxwell
526 2012-09-19 19:59:14 <gavinandresen> etotheipi_: http://testnet.freebitcoins.appspot.com/ was working last I checked
527 2012-09-19 20:00:54 <etotheipi_> gavinandresen: good call, I forgot about that site
528 2012-09-19 20:14:51 <diki> Flo Rida has some nice tunes this year.
529 2012-09-19 21:13:47 <jgarzik> <BFL_Josh> Regardless, we aren't testing any ASIC equipment on the live network either now or in the past, so it's pretty immaterial. We already have a plan, which I explained to several people at the Bitcoin conference on how we are going to handle the live testing when that time comes.
530 2012-09-19 21:14:52 <Luke-Jr> that doesn't seem logical
531 2012-09-19 22:18:46 <Eliel> Luke-Jr: It's good for their long-term reputation if they don't test them on the live network.
532 2012-09-19 22:19:02 <gmaxwell> testing on testnet would make a lot of sense if they want a public test.
533 2012-09-19 22:19:18 <gmaxwell> esp because testnet has the anti-islanding rule.
534 2012-09-19 22:20:58 <Eliel> Even better if they verifiably test them on testnet :P
535 2012-09-19 22:21:49 <gmaxwell> well, go convince them to do that.
536 2012-09-19 22:23:05 <Eliel> nah, too sleepy. I'll head to bed now :)
537 2012-09-19 22:37:44 <sipa> jgarzik: current code doesn't sync after every block; only after IBD, or at multiples of 500 block
538 2012-09-19 22:38:41 <crazyMF> Hello. How to run bitcoind only on IPv4 ? I've tried -onlynet=IPv4 but still get "address family not supported"
539 2012-09-19 22:39:17 <sipa> crazyMF: that message is from the RPC subsystem; -onlynet only applies to the P2P system
540 2012-09-19 22:40:23 <sipa> jgarzik: anyway, there is no safe way to keep using something like that
541 2012-09-19 22:40:29 <crazyMF> uhhm, how to get more verbose stuff ?
542 2012-09-19 22:40:35 <sipa> crazyMF: -debug
543 2012-09-19 22:40:44 <crazyMF> tried
544 2012-09-19 22:40:46 <crazyMF> same one liner
545 2012-09-19 22:41:08 <crazyMF> do I need some RPC support in kernel ?
546 2012-09-19 22:41:11 <crazyMF> I mean linux kernel
547 2012-09-19 22:41:58 <sipa> heh?
548 2012-09-19 22:42:07 <sipa> what is the problem you're trying to solve?
549 2012-09-19 22:42:10 <gmaxwell> crazyMF: the address family message you're seeing is harmless. It's just the rpc subsystem trying to get a v6 port and failing then continuing on with ipv4 only.
550 2012-09-19 22:42:51 <Luke-Jr> Eliel: I don't see why it would be
551 2012-09-19 22:43:37 <crazyMF> gmax, I believe that's an error, not a warning, because the process terminates right after that message
552 2012-09-19 22:43:53 <sipa> which version are you running?
553 2012-09-19 22:43:54 <BlueMatt> gmaxwell: btw, got those arm boards in yesterday, just started playing around with them; will probably have time to do some bitcoin benchmarks on them this weekend, if you're interested
554 2012-09-19 22:44:06 <sipa> crazyMF: there was a bug that caused that in 0.7.0rc2
555 2012-09-19 22:44:14 <sipa> but it's fixed in rc3 and final
556 2012-09-19 22:44:20 <crazyMF> bitcoind-0.7.0-rc2
557 2012-09-19 22:44:26 <crazyMF> brb :D
558 2012-09-19 22:44:26 <sipa> there you go :)
559 2012-09-19 22:44:55 <crazyMF> daaamn, manual ebuild writing =(
560 2012-09-19 22:45:03 <Luke-Jr> ACTION peers
561 2012-09-19 22:45:38 <Luke-Jr> crazyMF: layman -a bitcoin
562 2012-09-19 22:46:19 <crazyMF> emerge layman, I'm on really minimal setup
563 2012-09-19 22:47:44 <etotheipi_> Is it normal for testnet3 to not propagate transactions well?
564 2012-09-19 22:49:12 <etotheipi_> I'm not receiving any zero-conf, but I'm also testing a new version of Armory that may have broken it (though, when I broadcast a Tx, then request the same tx, Armory does do receive it properly, so it can't be completely broken)
565 2012-09-19 22:52:04 <gmaxwell> etotheipi_: it should propagate transactions exactly like bitcoin.
566 2012-09-19 22:52:58 <etotheipi_> I know it *should*, I'm asking if the test network is dense enough to do it reliably
567 2012-09-19 22:53:06 <Luke-Jr> gmaxwell: possible testnet1/2 nodes interfering?
568 2012-09-19 22:53:18 <gmaxwell> Luke-Jr: no, they don't anymore. Won't connect to them.
569 2012-09-19 22:53:50 <gmaxwell> etotheipi_: yes, actually because it's so small partitioning shouldn't be an issue. If you have any connections at all, you've probably got a connection to me, and I'm doing most of the mining right now it seems.
570 2012-09-19 22:54:10 <etotheipi_> okay, probably an Armory problem then...
571 2012-09-19 22:55:52 <etotheipi_> actually, I should be able to verify by logging every message received
572 2012-09-19 23:06:45 <etotheipi_> interesting... it looks like the tx doesn't even make it to my Bitcoin-Qt (or isn't forwarded)
573 2012-09-19 23:09:36 <etotheipi_> oh, I did, like 4 minutes later
574 2012-09-19 23:09:48 <etotheipi_> how is it possible for it to propagate that slowly?
575 2012-09-19 23:14:02 <jgarzik> ACTION wonder how well UDP hole punching works
576 2012-09-19 23:14:15 <jgarzik> mainly, what might be a typical timeout (and thus required keep-alive interval)
577 2012-09-19 23:18:48 <BlueMatt> jgarzik: I wonder more about how well TCP hole punching works, if you are looking at it in a bitcoin context
578 2012-09-19 23:19:05 <jgarzik> BlueMatt: pybond / UDP / DHT context
579 2012-09-19 23:20:17 <crazyMF> YAY! 0.7.0 works. One more question. How do I disable writing to debug.log ?
580 2012-09-19 23:20:44 <sipa> no way to do that; why would you want that?
581 2012-09-19 23:20:59 <sipa> if you really hate debug.log, symlink it to /dev/null or so
582 2012-09-19 23:21:48 <crazyMF> SSD, that's why
583 2012-09-19 23:23:09 <crazyMF> btw, how big blkindex/0001/etc .dat should get these days?
584 2012-09-19 23:23:21 <kjj_> 1/2/1 GB
585 2012-09-19 23:26:26 <crazyMF> guess it will take some time then
586 2012-09-19 23:27:47 <Luke-Jr> jgarzik: T-Mobile has like 60 second timeout on UDP :/
587 2012-09-19 23:28:26 <Luke-Jr> except port 500 or something like that which some VPN uses