1 2011-09-17 00:00:50 <gmaxwell> Though I worry that it would be adding an unwelcome element of centeralization to bitcoin. I'm doubtful that most ntp users are all that independant. (well, obviously, just about everything is ultimately clocked off GPS these days)
  2 2011-09-17 00:02:48 <gmaxwell> I'd almost kinda prefer to see a proper time protocol bolted onto the side of bitcoin the chrony implementation of NTP is small and excellent. ... but I'm certantly not going to be seriously proposing anything like that anytime soon.
  3 2011-09-17 00:05:03 <vsrinivas> there is an ad-hoc one now afterall. (averaging version time data)
  4 2011-09-17 00:12:48 <gmaxwell> vsrinivas: taking the median in fact.
  5 2011-09-17 00:12:53 <gmaxwell> (which is way better than averaging)
  6 2011-09-17 00:12:59 <gmaxwell> Though it does a number of things wrong too.
  7 2011-09-17 00:13:14 <vsrinivas> sorry, my mistake; i only looked very briefly; what is it doing wrongly?
  8 2011-09-17 00:14:10 <gmaxwell> It only remembers the first correction it gets from a particular IP. It's never influenced by future ones. It's influenced equally by IPs that connect to it as it connects to. It doesn't forget a correction after a peer disconnects.
  9 2011-09-17 00:14:40 <gmaxwell> So the net effect is that if I have a bunch of distinct IPs I can just connect to your node once from each and set your network time to any value I like in the allowed window.
 10 2011-09-17 00:15:46 <gmaxwell> This permits a kind of far out attack where I do this to both a miner and a bank-like target, drive their clocks ???70 minutes (the maximum) which is  greater than the 2hours of mutual shift that the blockchain validation permits.
 11 2011-09-17 00:16:22 <gmaxwell> This would allow me to cause a short lasting fork on demand, for as long as I can keep the clocks seperated.
 12 2011-09-17 00:17:37 <bittwist> the fabled time warp
 13 2011-09-17 00:17:43 <gmaxwell> It's not an especially pratical attack, more realistic is just driving people's network time to crazy values in order to DOS them.
 14 2011-09-17 00:18:25 <gmaxwell> In any case, some minor fixes to the current network time would close the attack. (treat inbound differently, forget times when neighbors disconnect, etc)
 15 2011-09-17 00:20:21 <vsrinivas> treating inbound differently would help; but if you control _a lot_ of IPs then there's still a chance an node falls into your trap.
 16 2011-09-17 00:21:39 <gmaxwell> Sure, but it's an order of magnitude different. The maximum adjustment should also be reduced to the point where you can't create enough mutual skew to produce a fork.
 17 2011-09-17 00:23:02 <gmaxwell> Alternatively, the bitcoin RPC could return unconfirmed/0 on transactions while the skeq is unreasonably large or something like that.
 18 2011-09-17 00:23:16 <gmaxwell> though it would make the attack a more powerful DOS vector.
 19 2011-09-17 00:24:40 <vsrinivas> if i understand ntp, its algorithm requires time sources to report intervals, not points? ;
 20 2011-09-17 00:25:15 <gmaxwell> Right. There is an effort made to compensate for transmission delay.
 21 2011-09-17 00:29:59 <Joric> damn flash won't connect to 8333 at all - SecurityErrorEvent, java applets atleast ask for permission (
 22 2011-09-17 00:30:48 <gmaxwell> Joric: IIRC flash wants to be able to read a xml 'permissions' file on the same IP as its connecting to.
 23 2011-09-17 00:31:42 <Joric> well, nobody would host those
 24 2011-09-17 00:32:32 <vsrinivas> gmaxwell: how could the time code get more than one correction from a source? the unix time is only sent in the version message iirc?
 25 2011-09-17 00:32:42 <gmaxwell> of course not, no one wants flash based web zombie hordes connecting to them.
 26 2011-09-17 00:34:06 <gmaxwell> vsrinivas: Well, what I was referring to was that right now if you connect, give a connection, disconnect, and then later reconnect the peer will not take another / replace your original correction.
 27 2011-09-17 00:34:30 <vsrinivas> it won't? that seems odd. [that's by ip?]
 28 2011-09-17 00:34:36 <gmaxwell> vsrinivas: but even on one connection it could do a version message ping pong every few hours per peer.
 29 2011-09-17 00:34:46 <gmaxwell> It's by IP, yes.
 30 2011-09-17 00:35:20 <gmaxwell> the code is intended to prevent a single IP from connecting over and over again to stuff the list of corrections.
 31 2011-09-17 00:35:46 <gmaxwell> but it goes a bit beyond that. :)
 32 2011-09-17 00:36:19 <gmaxwell> IIRC it doesn't bother tracking which peer gave it which correction. It just maintains a set of IPs its has corrections from.
 33 2011-09-17 00:36:40 <Joric> looks like java applets allow both networking and filesystem, no wonder the dialog is so scary
 34 2011-09-17 00:37:58 <gmaxwell> in any case, one consequence of this is that if your time is wrong at startup you'll get a bunch of big corrections (Good), and then if you/ntp fixes your time you'll keep using all those old big corrections (bad) and you'll pass out wrong time to everyone and you'll take a very long time to recover.
 35 2011-09-17 00:51:00 <gp5st1> hello! could bitcoins ever be used for POS since it takes time to validate a tx?
 36 2011-09-17 00:51:19 <gmaxwell> gp5st1: sure.
 37 2011-09-17 00:51:20 <gp5st1> significant amount of time relative to the length of a POS tx*
 38 2011-09-17 00:51:25 <gp5st1> gmaxwell: how?
 39 2011-09-17 00:51:45 <gmaxwell> gp5st1: there are a half different proposed methods.
 40 2011-09-17 00:51:54 <gp5st1> in the forums?
 41 2011-09-17 00:52:36 <gp5st1> just seems very easy to fake
 42 2011-09-17 00:52:38 <gmaxwell> gp5st1: I bullet pointed a bunch of them here: https://bitcointalk.org/index.php?topic=28565.5;wap2
 43 2011-09-17 00:52:57 <gmaxwell> (see that whole thread, or any of a bunch of other threads on the subject)
 44 2011-09-17 00:53:11 <gp5st1> will do
 45 2011-09-17 00:53:28 <gp5st1> i had been reading some others, but i can still evinsion attacks
 46 2011-09-17 00:53:32 <gp5st1> invision*
 47 2011-09-17 00:54:09 <gp5st1> thanks for the link
 48 2011-09-17 00:59:19 <gmaxwell> gp5st1: it's important to keep in mind that nothing exists in isolation. Bitcoin by itself doesn't do anything fantastic for POS, but think about that credit cards looked like at POS 15 years ago: a mechnical impression device. Any furhter validation required the vendors pick up a phone (and so it was only ever done on big spends).
 49 2011-09-17 01:00:06 <gp5st1> this is true
 50 2011-09-17 01:00:10 <gmaxwell> All the electronic validation we have for credit cards is an additional layer on top of what used to be a plastic card and carbon paper.
 51 2011-09-17 01:00:13 <gmaxwell> :)
 52 2011-09-17 01:00:29 <gp5st1> that's true
 53 2011-09-17 01:00:41 <gmaxwell> So, I see nothing wrong with saying that optimal bitcoin POS will require any one or two of several possible add ons.
 54 2011-09-17 01:01:03 <gp5st1> thanks
 55 2011-09-17 01:01:04 <vsrinivas> hmm what would current bitcoin nodes do if they received a version message later in communications?
 56 2011-09-17 01:01:12 <gp5st1> i have a bit more to read now
 57 2011-09-17 01:01:43 <gmaxwell> vsrinivas: nothing. They write it into their logs and go on with life.
 58 2011-09-17 01:01:59 <gmaxwell> There have been some bright bulbs out there sending psycho version messages in the past.
 59 2011-09-17 01:02:36 <vsrinivas> ok.
 60 2011-09-17 01:07:45 <Joric> lol lol nobody loves flash http://blogs.msdn.com/b/b8/archive/2011/09/14/metro-style-browsing-and-plug-in-free-html5.aspx
 61 2011-09-17 01:08:21 <Joric> ie10/win8 drop flash support
 62 2011-09-17 01:08:45 <gmaxwell> Joric: of course microsoft doesn't want you to use adobe's propritary bugfest platform, & they would prefer you use _their_ propritary bugfest platform.
 63 2011-09-17 01:19:55 <Disposition> Joric: flash is terrible.
 64 2011-09-17 01:24:36 <BTCTrader> can multiple bitcoind run on one host?
 65 2011-09-17 01:24:46 <luke-jr> BTCTrader: if you tweak it right
 66 2011-09-17 01:25:01 <luke-jr> and have a single trusted instance
 67 2011-09-17 01:25:02 <BTCTrader> it has to run a different port obviously, anything else?
 68 2011-09-17 01:25:57 <Diablo-D3> AnniAFK: dont spawn extra threads for your pool.
 69 2011-09-17 01:26:01 <BTCTrader> i dont understand, a single trusted instance?
 70 2011-09-17 01:29:24 <BTCTrader> i should explain, i want to run two separate bitcoin services on one host, do i need 2 different bitcoind's to do that or would it messup the bitcoind accounts to use one for each service
 71 2011-09-17 01:29:38 <BTCTrader> to use one bitcoind*
 72 2011-09-17 01:30:49 <CIA-101> bitcoin: Con Kolivas * rb8ea0dd194b3 cgminer/ (adl.c main.c miner.h util.c): Update curses logging to allow LOG_WARNING and LOG_ERR messages to still go through while within the menu, and drop share message to LOG_NOTICE.
 73 2011-09-17 01:34:20 <luke-jr> BTCTrader: it'd only mess it up if you wrote it poorly
 74 2011-09-17 01:40:52 <CIA-101> bitcoin: Con Kolivas * rd0901858f5e6 cgminer/NEWS: Update NEWS.
 75 2011-09-17 01:42:14 <CIA-101> poolserverj: shadders * 75ecf990c82a r76 /poolserverj-main/src/main/java/com/shadworld/poolserver/conf/Conf.java: - trace logging with target groups for granular tracing.
 76 2011-09-17 01:42:37 <Diablo-D3> lol
 77 2011-09-17 01:43:07 <Diablo-D3> a .29% reject rate on btcguild so far
 78 2011-09-17 01:43:17 <Diablo-D3> best pool ever
 79 2011-09-17 01:43:34 <CIA-101> poolserverj: shadders * b3f753e16639 r79 /bitcoin-jsonrpc/src/main/java/com/shadworld/poolserver/conf/Res.java: - trace framework updates
 80 2011-09-17 01:44:15 <conman> Diablo-D3, yah pretty darn good
 81 2011-09-17 01:45:57 <Diablo-D3> thats 2702 shares vs 8.
 82 2011-09-17 01:47:23 <Diablo-D3> conman: so I think Ive proved conclusively that luke is on drugs
 83 2011-09-17 01:47:28 <luke-jr> Diablo-D3: no u
 84 2011-09-17 01:47:49 <Diablo-D3> luke-jr: go be gay for jesus somewhere else
 85 2011-09-17 01:47:53 <luke-jr> Diablo-D3: no u
 86 2011-09-17 01:49:11 <conman> alright, let's build a windows fail build and see if I can tag and release this
 87 2011-09-17 01:49:46 <Diablo-D3> >windows
 88 2011-09-17 01:49:47 <Diablo-D3> >fail
 89 2011-09-17 01:49:49 <Diablo-D3> redundant much?
 90 2011-09-17 01:50:44 <conman> tautology here we come
 91 2011-09-17 01:50:56 <Diablo-D3> http://hazuki.prolikewoah.com/img/#id53141
 92 2011-09-17 01:51:21 <conman> hah
 93 2011-09-17 01:51:27 <conman> never knew they had so much sun up there
 94 2011-09-17 01:56:11 <sacarlson> BTCTrader: can you just run another virtualbox system on this single host to have another bitcoind running?
 95 2011-09-17 01:56:34 <Diablo-D3> http://hazuki.prolikewoah.com/img/#45384
 96 2011-09-17 01:56:51 <BTCTrader> it is already a xen
 97 2011-09-17 01:57:03 <Diablo-D3> a big game sniper rifle? goddamnit
 98 2011-09-17 01:57:10 <sacarlson> BTCTrader: I would also think you could have multiple services just use a single bitcoind as just keep track of accounts with mysql
 99 2011-09-17 02:00:48 <Diablo-D3> accurate representation of con: http://hazuki.prolikewoah.com/img/#22964
100 2011-09-17 02:11:06 <conman> lulz
101 2011-09-17 02:39:43 <flying> btw, vaginas.
102 2011-09-17 02:44:02 <gmaxwell> flying: According to my logs you prior messages in here have consisted only of of "afk/beer", "hooray for tor", "stupid irc client.", "kittens!", "guise...", "puscifer, vaginas, etc.". This channel is for bitcoin development. Perhaps you want #random
103 2011-09-17 02:47:54 <Blitzboom> gmaxwell: u jelly?
104 2011-09-17 02:49:20 <CIA-101> poolserverj: shadders * ffe9a54cc4bc r80 /poolserverj-main/src/main/java/com/shadworld/poolserver/ (7 files in 4 dirs): native longpolling listener alpha implementation
105 2011-09-17 02:49:21 <CIA-101> poolserverj: shadders * 5d937584802d r81 /poolserverj-main/src/main/java/com/shadworld/poolserver/NativeLongpollListener.java: add listener class
106 2011-09-17 02:49:22 <CIA-101> poolserverj: - add new config options
107 2011-09-17 02:49:23 <CIA-101> poolserverj: shadders * cebd73b6b0b3 r85 /bitcoin-jsonrpc/ (.classpath src/test/java/PingTest.java): get rid of useless empty file causing build errors
108 2011-09-17 02:56:27 <Diablo-D3> http://hazuki.prolikewoah.com/img/#46821
109 2011-09-17 05:28:43 <flying> mmmngh, aenima
110 2011-09-17 08:14:43 <flying> wtf?
111 2011-09-17 09:47:09 <tcatm> neofutur: it looks like the API bandwidth is limited to about 100..200kb/s. can this be fixed?
112 2011-09-17 09:50:06 <phantomcircuit> tcatm, hey
113 2011-09-17 09:50:41 <phantomcircuit> tcatm, can you add intrsngGBP and intrsngPLN
114 2011-09-17 09:50:47 <phantomcircuit> intrsngPLN hasn't had a trade yet
115 2011-09-17 09:52:16 <tcatm> phantomcircuit: I need website URL, currency, and urls for trades and orderbook
116 2011-09-17 09:52:55 <phantomcircuit> https://intersango.com/ GBP https://intersango.com/api/trades.php?currency_id=1
117 2011-09-17 09:53:03 <tcatm> phantomcircuit: also is intrsngGBP == britcoinGBP?
118 2011-09-17 09:53:12 <phantomcircuit> https://intersango.com/ PLN https://intersango.com/api/trades.php?currency_id=4
119 2011-09-17 09:53:22 <phantomcircuit> tcatm, they're trading in parallel so no
120 2011-09-17 09:54:00 <phantomcircuit> rather than trying to seamlessly migrate users we're operating in parallel
121 2011-09-17 09:54:11 <tcatm> phantomcircuit: does your API ensure that tids are alway increasing and newer trades will always have higher tids than the previous trades?
122 2011-09-17 09:54:16 <phantomcircuit> the structure of trade info is so different on britcoin it didn't seem like a good idea
123 2011-09-17 09:54:22 <phantomcircuit> yes it does
124 2011-09-17 09:55:36 <tcatm> if you like to save some bandwidth you could accept a since=$tid GET argument. That will be part of the new API revision (the old one will still be supported)
125 2011-09-17 09:56:31 <phantomcircuit> sure
126 2011-09-17 09:58:24 <tcatm> https://intersango.com/api/trades.php?currency_id=1 has a strange format. looks like it's all wrapped in a dict?
127 2011-09-17 09:58:48 <Gekz> it's called JSON.
128 2011-09-17 09:59:18 <tcatm> it's supposed to be json, but with a toplevel array of dicts
129 2011-09-17 10:04:01 <phantomcircuit> tcatm, oh my bad
130 2011-09-17 10:04:09 <phantomcircuit> tcatm, https://intersango.com/api/trades.php?currency_pair_id=1
131 2011-09-17 10:04:15 <phantomcircuit> https://intersango.com/api/trades.php?currency_pair_id=4
132 2011-09-17 10:04:34 <phantomcircuit> without currency_pair_id it just gives you the last 1000 trades for all of them
133 2011-09-17 10:05:03 <phantomcircuit> https://intersango.com/api/depth.php?currency_pair_id=4
134 2011-09-17 10:05:05 <phantomcircuit> https://intersango.com/api/depth.php?currency_pair_id=1
135 2011-09-17 10:11:40 <tcatm> added
136 2011-09-17 10:28:44 <flying> -.-
137 2011-09-17 10:51:31 <phantomcircuit> flying, ^_^
138 2011-09-17 11:18:04 <bstation_> Hi there! My pool just went "officially online" and awaits your testrun! Returning users as well as test users are both very welcome! Visit https://bitcoin-station.com
139 2011-09-17 11:44:53 <bstation_> Hi, can you please tell me the procedure to list a pool on bitcointalk.org? Thx!
140 2011-09-17 12:05:50 <sipa> list?
141 2011-09-17 12:05:58 <sipa> it's a forum
142 2011-09-17 12:08:03 <Joric> pools are listed here btw https://en.bitcoin.it/wiki/Comparison_of_mining_pools
143 2011-09-17 12:10:31 <bstation_> Thanks for the replies. I found out it's made that way that the post-count has to be high enough to start threads on the "mining" subforum.
144 2011-09-17 12:15:30 <soap> forums which reward post-count tend to get what they deserve.  ;)
145 2011-09-17 13:09:41 <CIA-101> poolserverj: shadders * d3651fc58d78 r87 /poolserverj-main/ (2 files in 2 dirs): bad properties file
146 2011-09-17 13:09:42 <CIA-101> poolserverj: shadders * f7cf48ade656 r88 /poolserverj-main/src/main/java/com/shadworld/poolserver/logging/ShareLogger.java: - fix: nullpointer if share output file not specified.
147 2011-09-17 13:09:43 <CIA-101> poolserverj: shadders * 5294dffa6f2c r91 /poolserverj-main/src/main/java/com/shadworld/poolserver/servlet/auth/WorkerAuthenticator.java: - addresses issue #7. When setting worker IP first check X-Forwarded-For header then falls back to remoteAddr. This covers situations where the server is behind a load balancing proxy.
148 2011-09-17 13:10:35 <CIA-101> poolserverj: can result in multiple db lookups where one hasn't been put into the cache
149 2011-09-17 13:10:36 <CIA-101> poolserverj: shadders * d052bea0f491 r96 /poolserverj-main/src/main/java/com/shadworld/poolserver/BlockChainTracker.java:
150 2011-09-17 13:11:35 <CIA-101> poolserverj: native longpoll handling improvements
151 2011-09-17 13:11:35 <CIA-101> poolserverj: tidy longpoll limit enforement.
152 2011-09-17 13:11:36 <CIA-101> poolserverj: shadders * f22a0168c240 r101 /poolserverj-main/doc/config-samples/local-daemon.properties: yet more sample config fixes... this time a 30000 second timeout on work cache.
153 2011-09-17 13:45:39 <Lolcust> Sorry for disturbance guys, while playing with various "coins" behind a router (a shitty one, D-Link DIR-615 Wireless N) and I get much more incoming connections on any coin client (tested with bitcoind namecoin and yeah, my fork too) if the router is configured to allow ICMP. Meanwhile, uTorrent does not care and gives a lot  of incoming in both cases.
154 2011-09-17 13:46:07 <Lolcust> relevant ports are forwarded in both cases. Is that "normal" ?
155 2011-09-17 13:46:17 <sipa> that's strange
156 2011-09-17 13:46:25 <Diablo-D3> ICMP isnt really useful here
157 2011-09-17 13:46:35 <Lolcust> Yeah, that's why I ask
158 2011-09-17 13:46:35 <sipa> are you sure it is related to ICMP?
159 2011-09-17 13:46:36 <Diablo-D3> although blocking ICMP is a good way of not being able to connect to the internet.
160 2011-09-17 13:46:44 <SomeoneWeird> ^
161 2011-09-17 13:47:08 <sipa> as in, not to some random element such as where you connect first?
162 2011-09-17 13:47:10 <Lolcust> Well, it connects to the ISP irregardless of this setting
163 2011-09-17 13:47:51 <Lolcust> generally, it's one hell of a weird router, so probably shenanigans.
164 2011-09-17 13:48:22 <Lolcust> I was just wondering if bitcoin wants to ping listener guys for some reason, or something.
165 2011-09-17 13:48:34 <sipa> afaik it only uses TCP
166 2011-09-17 13:49:02 <Lolcust> well, I sort of know that / think that, that;s why this behavior is so surprising
167 2011-09-17 13:49:33 <Lolcust> Anyways, DIR615 sucks and is stupidly hot, so I'll get her change it for something less sucky anyways
168 2011-09-17 14:15:32 <luke-jr> considering ping requires root (until very recently), I don't think Bitcoin could ping if it wanted to
169 2011-09-17 14:19:16 <lfm> ping still requires root (suid root)
170 2011-09-17 14:20:19 <cjdelisle> the kernel will send an arp packet if it can't find the location on the ethernet but nothing with icmp
171 2011-09-17 14:20:38 <luke-jr> lfm: no, Linux supports ping without root now
172 2011-09-17 14:20:56 <lfm> newer than 2.6.32?
173 2011-09-17 14:20:59 <cjdelisle> the ping utility is setuid IIRC
174 2011-09-17 14:20:59 <luke-jr> yes
175 2011-09-17 14:21:20 <lfm> k thats what I have
176 2011-09-17 14:21:54 <lfm> ping can be kinda dangerous is why I think it needs root in the past
177 2011-09-17 14:24:02 <phantomcircuit> luke-jr, bitcoin could call ping heh
178 2011-09-17 14:24:43 <luke-jr> Summary: Besides a new version numbering scheme, Linux 3.0 also has several new features: &, unprivileged ICMP_ECHO, &
179 2011-09-17 14:24:44 <lfm> oh, you use capabilities instead of suid root! It is still privledged
180 2011-09-17 14:24:56 <CIA-101> bitcoin: Dean Lee master * r67c6994 / locale/zh_cn/LC_MESSAGES/bitcoin.po : Update to the Chinese Simp translation - http://git.io/zFhUNQ
181 2011-09-17 14:24:57 <CIA-101> bitcoin: Jeff Garzik master * r7337b34 / locale/zh_cn/LC_MESSAGES/bitcoin.po :
182 2011-09-17 14:25:20 <luke-jr> http://kernelnewbies.org/LinuxChanges
183 2011-09-17 14:25:26 <lfm> ok well I dunno about 3.0 you could be right then
184 2011-09-17 14:29:38 <lfm> its still optional and disabled by default , for compatibility I spzoe.
185 2011-09-17 14:31:57 <luke-jr> &
186 2011-09-17 14:32:06 <luke-jr> *everything* is optional, and Linux doesn't really have defaults
187 2011-09-17 14:32:35 <luke-jr> I presume <your-distro>'s default is based on whether they support it or not
188 2011-09-17 14:32:43 <luke-jr> ie, with a ping tool that uses it
189 2011-09-17 14:38:21 <lfm> I was just reading the desc of 3.0 , I dont have it. it sez linux will boot with the traditional handling of ICMP stuff and you can enable the rootless ping feature "at bootup".
190 2011-09-17 14:40:15 <luke-jr> "traditional handling" = raw sockets
191 2011-09-17 15:02:44 <flying> kittens.
192 2011-09-17 15:34:19 <BGL> heh that url is a 404
193 2011-09-17 15:34:38 <BGL> the redirect anyways
194 2011-09-17 15:55:44 <b4epoche_> damn it, did someone run up the testnet difficulty and leave?
195 2011-09-17 15:57:35 <phantomcircuit> yes
196 2011-09-17 16:07:02 <b4epoche_> are they testing miners?
197 2011-09-17 16:07:14 <b4epoche_> maybe we should have a separate 'mining' testnet
198 2011-09-17 16:07:35 <b4epoche_> at this point I'm trying to debug stuff and the testnet is useless
199 2011-09-17 16:08:27 <kinlo> ?
200 2011-09-17 16:08:36 <kinlo> what's not usefull about the testnet?
201 2011-09-17 16:11:26 <phantomcircuit> b4epoche, i believe they just thought it was funny
202 2011-09-17 16:12:03 <b4epoche_> kinlo:  the fact that a block hasn't been found in 2 hours
203 2011-09-17 16:12:22 <b4epoche_> maybe the testnet should have a fixed difficulty
204 2011-09-17 16:12:32 <kinlo> create testnet in a box and mine yourself
205 2011-09-17 16:12:57 <kinlo> a low-end gpu can create blocks every minute then
206 2011-09-17 16:14:06 <b4epoche_> kinlo:  testnet in a box can't be used in all situations
207 2011-09-17 16:15:02 <kinlo> you can if you're a bit creative :)
208 2011-09-17 16:16:44 <b4epoche_> and have a network of computers sitting around
209 2011-09-17 16:18:49 <kinlo> sure :P
210 2011-09-17 16:18:56 <kinlo> ok, I've enabled my miner on the testnet
211 2011-09-17 16:18:59 <kinlo> it's only a cpu miner
212 2011-09-17 16:19:20 <kinlo> but now I can feel good, thinking that I've helped you, knowing that I will generate a block within one week from now :p
213 2011-09-17 16:21:33 <vsrinivas> testnet is reset periodically, no?
214 2011-09-17 16:21:52 <kinlo> sometimes when there is a new release
215 2011-09-17 16:21:58 <kinlo> so periodically is a big word
216 2011-09-17 16:22:15 <luke-jr> vsrinivas: not really, no
217 2011-09-17 16:22:23 <luke-jr> vsrinivas: but you can reset it yourself
218 2011-09-17 16:25:17 <CIA-101> bitcoin: Luke Dashjr * r1e34b503c83c gentoo/net-p2p/wxbitcoin/ (4 files): net-p2p/wxbitcoin: 0.4+ require wxGTK >=2.9.1
219 2011-09-17 16:31:52 <lfm> b4epoche "testnet-in-a-box" is designed to run on a single computer!
220 2011-09-17 16:32:19 <lfm> thats what "in a box" means, just one box
221 2011-09-17 16:32:23 <b4epoche_> sure
222 2011-09-17 16:32:41 <b4epoche_> but if you need a network it's not particularly useful
223 2011-09-17 16:33:04 <kinlo> b4epoche_: what are you trying to do?
224 2011-09-17 16:33:30 <lfm> well it is anetwork in one box
225 2011-09-17 16:33:35 <kinlo> in any case, the difficulty on the testnet is usually too high
226 2011-09-17 16:33:40 <b4epoche_> kinlo:  at the moment something that I can use 'box' for
227 2011-09-17 16:33:51 <kinlo> but not much one can do about it
228 2011-09-17 16:34:12 <b4epoche_> well, it could be set to a fixed difficulty
229 2011-09-17 16:34:24 <lfm> if you really need blocks on testnet I can put a gpu on there
230 2011-09-17 16:34:26 <b4epoche_> it's not like it matters
231 2011-09-17 16:34:36 <kinlo> b4epoche_: dunno, set up several boxes all in a fixed testnet setup
232 2011-09-17 16:34:37 <b4epoche_> lfm:  no need atm
233 2011-09-17 16:35:07 <kinlo> would be nicer if nobody set a gpu on it so the difficulty keeps dropping :)
234 2011-09-17 16:35:19 <kinlo> that cpu miners would still make a difference on the testnet
235 2011-09-17 16:36:01 <lfm> kinlo, I dont think there is any reasonable way to do that, gpu's need testing too
236 2011-09-17 16:36:02 <b4epoche_> yea, I see this as a bit of a bitcoin flaw...
237 2011-09-17 16:36:12 <kinlo> lfm: true...
238 2011-09-17 16:36:18 <b4epoche_> lfm:  thus, my suggestion of two testnets
239 2011-09-17 16:36:20 <kinlo> b4epoche_: it's not a bitcoin flaw :)
240 2011-09-17 16:36:32 <b4epoche_> kinlo:  yes, it is
241 2011-09-17 16:36:43 <kinlo> but perhaps the bitcoin client should be adjusted to accept any difficulty blocks on the testnet
242 2011-09-17 16:36:54 <kinlo> and a special override switch so you can override the difficulty
243 2011-09-17 16:37:08 <lfm> b4epoche ya but you see it wrong! (grin)
244 2011-09-17 16:37:24 <b4epoche_> see what wrong?
245 2011-09-17 16:37:30 <lfm> as a flaw
246 2011-09-17 16:37:59 <b4epoche_> it a feature that if enough miners drop out the entire thing goes down?
247 2011-09-17 16:38:32 <lfm> it doesnt go down, it just slows down
248 2011-09-17 16:38:56 <b4epoche_> and winds up in a death spiral as more miners drop out
249 2011-09-17 16:39:22 <kinlo> b4epoche_: I don't think you understand the concept of the difficulty
250 2011-09-17 16:39:26 <lfm> it doesnt  happen on the real bitnet cuz people come back when it goes down
251 2011-09-17 16:39:52 <b4epoche_> kinlo:  I don't think you're understanding actually
252 2011-09-17 16:40:05 <b4epoche_> lfm:  depends on the times
253 2011-09-17 16:40:09 <b4epoche_> s/times/timing
254 2011-09-17 16:40:32 <lfm> we know it slows down when the mining partisipation drops till the diff adjust catches up
255 2011-09-17 16:41:36 <b4epoche_> so half the mining power drops&  now it's 20 minutes per block&  and four weeks to a difficulty update
256 2011-09-17 16:42:23 <lfm> on the real bitnet not everyone drops out at the same time because electricity prices are different and stuff like that
257 2011-09-17 16:42:52 <b4epoche_> lfm:  yea, but what happens when reward drops to 25?
258 2011-09-17 16:43:26 <lfm> it is totally predictable so people prepare for it
259 2011-09-17 16:43:45 <b4epoche_> by modifying how the difficulty gets adjusted
260 2011-09-17 16:44:02 <lfm> no, by adjusting their mining behaviour
261 2011-09-17 16:44:15 <lfm> no need to change the system
262 2011-09-17 16:44:17 <b4epoche_> and how will they adjust?
263 2011-09-17 16:44:35 <lfm> some will drop out, some wont
264 2011-09-17 16:44:39 <b4epoche_> by deciding it isn't worth it any more and dropping out
265 2011-09-17 16:44:45 <MacRohard> by spending less money on mining i guess - until the value catches up
266 2011-09-17 16:44:51 <b4epoche_> I'm not saying all have to drop out...
267 2011-09-17 16:45:03 <b4epoche_> but if a significant fraction do, it could be an issue
268 2011-09-17 16:45:10 <lfm> so what if it is 20 min per block for a while?!
269 2011-09-17 16:45:34 <b4epoche_> the problem is what the feedback mechanism is...
270 2011-09-17 16:45:51 <MacRohard> it's sortof a shame that it doesn't adjust more gradually but it will work itself out
271 2011-09-17 16:46:02 <lfm> sometimes NOW it takes an hour for the next block and bitcoin doesnt crash!
272 2011-09-17 16:46:22 <b4epoche_> will people see 20 minutes per reward and think, this is even worse?
273 2011-09-17 16:46:30 <b4epoche_> worse for mining that is
274 2011-09-17 16:46:41 <b4epoche_> now it's 25 btc ever 20 minutes
275 2011-09-17 16:46:49 <lfm> b4epoche thats only temporary, for 1 month at most
276 2011-09-17 16:47:17 <b4epoche_> lfm:  depends on whether the feedback is positive or negative
277 2011-09-17 16:47:25 <lfm> prolly less cuz of the people who have free power
278 2011-09-17 16:47:26 <b4epoche_> and it's not clear to me which it is
279 2011-09-17 16:47:51 <lfm> with free power they will keep on no matter what
280 2011-09-17 16:48:10 <b4epoche_> sure, but what percent has free power?
281 2011-09-17 16:48:32 <lfm> look at the pools, how many cpus are still mining?
282 2011-09-17 16:48:49 <b4epoche_> there's a very long tail...
283 2011-09-17 16:48:58 <b4epoche_> that accounts for a very small percentage
284 2011-09-17 16:49:44 <lfm> how many nvidia are mining? I doubt they are cost effective unless they have free power
285 2011-09-17 16:51:06 <b4epoche_> free power or parents power
286 2011-09-17 16:51:30 <lfm> how many use the waste heat to offset heating bills in the winter? their power is nearly free too.
287 2011-09-17 16:52:00 <b4epoche_> heating with electricity is ridiculously costly
288 2011-09-17 16:52:03 <b4epoche_> but sure&
289 2011-09-17 16:52:44 <b4epoche_> all I'm saying is that if like, 20% of miners drop out it could cause a negative feedback loop causing more to drop
290 2011-09-17 16:53:02 <luke-jr> nonsense
291 2011-09-17 16:53:11 <luke-jr> 20% of miners drop out, it just makes it more profitable for everyone else
292 2011-09-17 16:53:23 <b4epoche_> how?
293 2011-09-17 16:53:46 <b4epoche_> and before you say 'difficulty changes' read above
294 2011-09-17 16:53:55 <lfm> yup, and its possible some of the early bird miners could dump a ton of bitcoins into the market and drive the price down to 5 cents too. but I dont think it will
295 2011-09-17 16:54:47 <b4epoche_> a ton of things could happen&  I'm just saying that having difficulty changes tied to the number of blocks found could be an issue/flaw
296 2011-09-17 16:55:08 <mtrlt> the problem is that the diff periods are too long
297 2011-09-17 16:55:26 <b4epoche_> and tied to blocks found, not time
298 2011-09-17 16:55:45 <mtrlt> it's tied to blocks found for a reason
299 2011-09-17 16:56:08 <b4epoche_> not really
300 2011-09-17 16:56:35 <b4epoche_> other than that blocks found substitutes for time
301 2011-09-17 16:56:45 <lfm> b4epoche You think Satoshi didnt think about it before he implemented it?
302 2011-09-17 16:57:01 <b4epoche_> lfm:  I think he thought about it a ton
303 2011-09-17 16:57:28 <mtrlt> but for example solidcoin has a 12h average diff period instead of bitcoin's 2 weeks. it's a lot better.
304 2011-09-17 16:58:07 <lfm> mtrlt: well, we'll see how solidcoin does compared to bitcoin in the long run.
305 2011-09-17 16:59:21 <mtrlt> well it's not the only change :P
306 2011-09-17 16:59:36 <mtrlt> but i think the diff period change is a positive one
307 2011-09-17 17:00:25 <b4epoche_> I think that Satoshi realized that what's best at the beginning is not necessarily what's best at steady state&  and parameters will have to evolve
308 2011-09-17 17:01:01 <lfm> I think the 2 week period is working really very well.
309 2011-09-17 17:01:12 <mtrlt> lfm: so far
310 2011-09-17 17:01:19 <lfm> yup
311 2011-09-17 17:01:23 <mtrlt> lfm: it has been disastrous for other networks when people jumped out
312 2011-09-17 17:01:42 <b4epoche_> yea, so far&  but I foresee that it could be a problem
313 2011-09-17 17:01:46 <lfm> yup, thats good too. we dont want other nets
314 2011-09-17 17:02:28 <b4epoche_> brilliant&  flaws in the system that take down other networks are good?
315 2011-09-17 17:03:01 <lfm> a unified bitcoin is stronger than a ton of "me too"s
316 2011-09-17 17:03:31 <b4epoche_> well, the "me toos" can provide some information
317 2011-09-17 17:03:56 <lfm> so long as you dont interpret the info the wrong way
318 2011-09-17 17:04:48 <phantomcircuit> b4epoche_, other networks are economically infeasible
319 2011-09-17 17:05:24 <phantomcircuit> it's in the best interest of large bitcoin miners to difficulty spike the other networks regardless of the re-target threshold
320 2011-09-17 17:05:30 <phantomcircuit> so it will always happen
321 2011-09-17 17:06:20 <gjs278> ;;bc,stats
322 2011-09-17 17:06:23 <gribble> Current Blocks: 145753 | Current Difficulty: 1755425.3203287 | Next Difficulty At Block: 147167 | Next Difficulty In: 1414 blocks | Next Difficulty In About: 1 week, 3 days, 8 hours, 14 minutes, and 8 seconds | Next Difficulty Estimate: 1669004.11911234
323 2011-09-17 17:06:55 <b4epoche_> phantomcircuit:  sure
324 2011-09-17 17:08:07 <phantomcircuit> b4epoche, realistically the only solution is merged mining
325 2011-09-17 17:08:25 <b4epoche_> for other networks?
326 2011-09-17 17:08:40 <pigeons> b4epoche_: absolutely
327 2011-09-17 17:08:42 <phantomcircuit> yes
328 2011-09-17 17:08:47 <b4epoche_> I'm not advocating other networks&  but I hope they keep popping up and keep dying
329 2011-09-17 17:08:59 <b4epoche_> because they 'test' things
330 2011-09-17 17:09:45 <b4epoche_> where are the rc binaries?
331 2011-09-17 17:09:48 <b4epoche_> where are the rc binaries?
332 2011-09-17 17:10:24 <lfm> ok, bitcoin maybe isn't perfect but it is good enuf that with its head start, it seem nothing can replace it.
333 2011-09-17 17:10:53 <b4epoche_> lfm:  agreed, but I think it'll need tweaked along the way
334 2011-09-17 17:11:17 <mtrlt> lfm: nothing can replace it? there's no-one that has even tried
335 2011-09-17 17:11:51 <b4epoche_> well, depends on the time-scales we're talking about
336 2011-09-17 17:11:51 <lfm> mtrlt: well Id say you havnt been paying attention, theres been many who tried
337 2011-09-17 17:12:11 <b4epoche_> something /will/ replace it at some point
338 2011-09-17 17:14:47 <mtrlt> lfm: namecoin? ixcoin?
339 2011-09-17 17:14:59 <mtrlt> solidcoin is the first that seems to be trying
340 2011-09-17 17:17:46 <mtrlt> but we'll see once 2.0 is released
341 2011-09-17 17:18:13 <lfm> what solidcoin 2.0? vs bitcoin 0.4?
342 2011-09-17 17:19:39 <mtrlt> we'll see if there are actually any changes that matter in it :p
343 2011-09-17 17:19:41 <mtrlt> in sc 2.0
344 2011-09-17 17:20:40 <phantomcircuit> mtrlt, solidcoin is a failure
345 2011-09-17 17:20:45 <lfm> seems kind amusing sc thinks they are on v 2.0 based on code from btc 0.3.x
346 2011-09-17 17:20:46 <phantomcircuit> that's pretty clear
347 2011-09-17 17:20:53 <phantomcircuit> realsolid is in a word incompetent
348 2011-09-17 17:21:13 <copumpkin> incompetent is fine if you aren't also a douchebag
349 2011-09-17 17:21:31 <copumpkin> I'd prefer not douchebag + not incompetent
350 2011-09-17 17:21:40 <sipa> i don't mind people trying alternatives
351 2011-09-17 17:22:16 <mtrlt> lfm: it's just a number
352 2011-09-17 17:22:17 <sipa> as long as they are aware they're experimenting
353 2011-09-17 17:22:21 <lfm> trying alts is fine but try not to get delusional about taking over the world
354 2011-09-17 17:22:27 <sipa> inded
355 2011-09-17 17:22:34 <mtrlt> lfm: the same applies to bitcoin ;-)
356 2011-09-17 17:22:39 <lfm> true
357 2011-09-17 17:22:50 <sipa> i consider bitcoin an experiment like everything else
358 2011-09-17 17:23:08 <sipa> but at least one which already survives for two years
359 2011-09-17 17:23:19 <mtrlt> yeah
360 2011-09-17 17:23:27 <mtrlt> but people don't have to invent it all over again
361 2011-09-17 17:23:39 <mtrlt> so bitcoin really does not have a 2 year advantage over others :p
362 2011-09-17 17:23:52 <lfm> no, its 2.5+
363 2011-09-17 17:24:06 <sipa> they have network effect of two years to fight against
364 2011-09-17 17:24:13 <sipa> that's harder than reinventing, imho
365 2011-09-17 17:24:20 <mtrlt> more like network effect of slightly over a year
366 2011-09-17 17:24:25 <sipa> agree
367 2011-09-17 17:24:44 <mtrlt> but the community is still small
368 2011-09-17 17:24:50 <sipa> sure
369 2011-09-17 17:25:03 <lfm> over a year since the first big slashdot infusion
370 2011-09-17 17:25:35 <mtrlt> and there are hardly any places that i've seen that accept bitcoin
371 2011-09-17 17:25:35 <sipa> i've been here for 10 months now
372 2011-09-17 17:35:11 <luke-jr> mtrlt: SC 2.0 requires new miner software
373 2011-09-17 17:36:43 <sipa> how so?
374 2011-09-17 17:40:01 <k9quaint> has anything specific about SC 2 has been published? or is it still just claims instead of source code?
375 2011-09-17 17:41:17 <sipa> obviously it will solve the 51% attack problem
376 2011-09-17 17:41:42 <k9quaint> by building in a successful 51% attack by one individual :)
377 2011-09-17 17:45:04 <luke-jr> sipa: dunno, I just heard conman ranting how cgminer won't add support for it :P
378 2011-09-17 17:45:48 <k9quaint> is CH even going to post the source? or just release binaries?
379 2011-09-17 17:45:59 <luke-jr> probably not
380 2011-09-17 17:48:35 <phantomcircuit> ch?
381 2011-09-17 17:48:50 <k9quaint> CoinHunter/RealSolid
382 2011-09-17 18:03:00 <lfm> tcatm: addr.dat seems like a good idea for binaries that havnt been updated in a long time, builtin lists would be too old after a while. I spoze the dns lists are still good but addr.dat doesnt hurt to have extra insurance
383 2011-09-17 18:04:45 <phantomcircuit> lfm, addr.txt not .dat
384 2011-09-17 18:05:20 <lfm> doh, ok, I didnt know that either then
385 2011-09-17 18:07:04 <lfm> cant help but wonder if it has ever been used!
386 2011-09-17 18:07:10 <tcatm> probably not
387 2011-09-17 18:07:35 <tcatm> maybe it doesn't even work?
388 2011-09-17 18:09:19 <lfm> looks like it just adds the ip addresses to the database with a timestamp of zero
389 2011-09-17 18:10:08 <tcatm> works
390 2011-09-17 18:15:44 <flying> bbiab
391 2011-09-17 18:22:09 <pointbiz> satoshi said it was more redundant to have IRC and a built in list for bootstrapping
392 2011-09-17 18:23:00 <phantomcircuit> lol the irc points to a single irc server
393 2011-09-17 18:23:01 <pointbiz> https://bitcointalk.org/index.php?topic=84.msg1579#msg1579
394 2011-09-17 18:23:27 <pointbiz> he mentions having a list of long standing nodes shipped with the client
395 2011-09-17 18:24:16 <phantomcircuit> choosing the right peers is actually a fairly complex problem
396 2011-09-17 18:24:19 <lfm> pointbiz: yes, that list is in the source
397 2011-09-17 18:25:29 <phantomcircuit> you want to have beens on the extremes of latency and location, you dont want to connect to the same individual or group more than once, and you need to be able to drop peers that are simply spamming you
398 2011-09-17 18:25:41 <phantomcircuit> doing all of that is more complex than it would seem
399 2011-09-17 18:27:21 <pointbiz> satoshi mentioned just getting a list of addresses from the seed nodes and not to connect to them. but i agree it's not a simple problem.
400 2011-09-17 18:27:54 <phantomcircuit> pointbiz, getting a list of peers is actually fairly easy assuming that you have made at least 1 connection to a legitimate peer
401 2011-09-17 18:28:08 <phantomcircuit> the current client doesn't do this but it should
402 2011-09-17 18:28:19 <phantomcircuit> some connections should be stable and some should be rotating
403 2011-09-17 18:30:17 <Lolcust> With all due respect and pardons for possible ignorance on my part, isn't complex, sybil-resistant peer selections kinda moot when several pools amounting to ( -I am still trying to get indication approximately how many, but likely couple hundred or so- ) nodes define the operation of the network ?
404 2011-09-17 18:31:37 <tcatm> Big pools are a problem. I'd love to see a distributed pool but that's not easy to do.
405 2011-09-17 18:32:20 <sipa> it's not that hard
406 2011-09-17 18:32:34 <Lolcust> Well, I agree that big pools disagree ^__^ with bitcoin philosophy
407 2011-09-17 18:32:35 <sipa> not sure how much of it is implemented though
408 2011-09-17 18:33:00 <Lolcust> Still, their current existence makes "robust peer selection" a foregone conclusion it seems to me
409 2011-09-17 18:33:26 <sipa> satoshi envisioned a newtwork where +- all full nodes were miners
410 2011-09-17 18:33:46 <Lolcust> Well, yeah, I sort of got that feel from the paper )
411 2011-09-17 18:33:46 <sipa> we're indeed far from that today
412 2011-09-17 18:34:11 <tcatm> I don't think satoshi ever envisioned difficulty at 1755888 :)
413 2011-09-17 18:34:22 <sipa> ;;bc,diff
414 2011-09-17 18:34:23 <gribble> 1755425.3203287
415 2011-09-17 18:34:54 <tcatm> Hrm, why is my calculation different?
416 2011-09-17 18:35:07 <sipa> how do you calculate it?
417 2011-09-17 18:35:29 <tcatm> float(0x00000000FFFF0000000000000000000000000000000000000000000000000000>>193) / float(target)
418 2011-09-17 18:35:54 <tcatm> with target =  ((c & 0xFFFFFFL) << (8 * ((c >> 24) - 3))) >> 193
419 2011-09-17 18:36:14 <sipa> that should be correct
420 2011-09-17 18:36:22 <luke-jr> tcatm: gribble is wrong IIRC
421 2011-09-17 18:36:50 <sipa> gribble's result is bitcoin'd getinfo
422 2011-09-17 18:36:58 <sipa> bitcoind's
423 2011-09-17 18:36:59 <luke-jr> old bitcoind was wrong
424 2011-09-17 18:37:10 <sipa> yes, but way more off than this
425 2011-09-17 18:39:28 <lfm> sipa, what do you get?
426 2011-09-17 18:40:26 <lfm> 1a098ea5 =   1755425.32 by my calcs
427 2011-09-17 18:40:38 <gribble> Error: "bc,target" is not a valid command.
428 2011-09-17 18:40:38 <sipa> ;;bc,target
429 2011-09-17 18:40:43 <sipa> ;;bc,hextarget
430 2011-09-17 18:40:44 <gribble> 000000000000098EA50000000000000000000000000000000000000000000000
431 2011-09-17 18:41:13 <gribble> 000000000000098EA50000000000000000000000000000000000000000000000
432 2011-09-17 18:41:13 <lfm> ;;bc,hextarget
433 2011-09-17 18:42:32 <sipa> bitcoind's getinfo result is exactly right
434 2011-09-17 18:42:38 <sipa> all decimals of it
435 2011-09-17 18:43:08 <lfm> huh? would only be accurate to 5 or so decimals really
436 2011-09-17 18:44:01 <sipa> i get 1755425.320328702735410902367879477792
437 2011-09-17 18:44:22 <sipa> with arbitrary-precision calculation
438 2011-09-17 18:45:00 <lfm> ya well the 98ea5 is only 16 to 23 bits of significance
439 2011-09-17 18:45:58 <tcatm> fixed. the >> 193 was truncating the 0xA5
440 2011-09-17 18:47:01 <luke-jr> 1755425.320328702735410902367879478
441 2011-09-17 18:47:28 <luke-jr> actually
442 2011-09-17 18:47:34 <luke-jr> it goes on for a long way
443 2011-09-17 18:47:59 <luke-jr> possibly infinite
444 2011-09-17 18:48:14 <lfm> naw, it is rational
445 2011-09-17 18:48:32 <lfm> might repeat eventually
446 2011-09-17 18:49:07 <gmaxwell> It's a sum of ratio of integers, of course it's rational. :)
447 2011-09-17 18:49:23 <gmaxwell> could have a really long period though
448 2011-09-17 18:49:36 <lfm> ya so it repeats eventially one way or another
449 2011-09-17 18:49:49 <luke-jr> 1??????21.52010????637????6????326????528??6306??????64??35444??0416????????148????47??????8??435??2??????71??????6??05??0014????????40??61225????3??2??
450 2011-09-17 18:49:55 <lfm> eventually
451 2011-09-17 18:50:27 <lfm> what the heck are those chicken scratches?
452 2011-09-17 18:50:57 <luke-jr> Tonal shows more precision in less characters :P
453 2011-09-17 18:51:09 <lfm> oh right, of course
454 2011-09-17 18:51:25 <luke-jr> 1755425.320328702735410902367879477792448522450230784828072886814051770521169778124057023250912841407476119
455 2011-09-17 18:51:39 <luke-jr> or by pool accounting
456 2011-09-17 18:51:41 <luke-jr> 1755452.106402103646416249295511550417424374262582203623904550396668842079389781299997458350422241473219503
457 2011-09-17 18:52:08 <lfm> its not real precicision tho when its only significant to 16 to 23 bits
458 2011-09-17 18:52:46 <luke-jr> ?
459 2011-09-17 18:53:15 <luke-jr> that's 399 bits of precision there
460 2011-09-17 18:53:20 <luke-jr> for the tonal one, at least
461 2011-09-17 18:54:28 <lfm> ok you're starting with the 0x098ea5 part of the compressed diff. you can tell how many significant digits if you assume the next bit is either a zero or a one, you dont really know. calculate it both ways and youll see it makes everything but the first 7 digits or so change
462 2011-09-17 18:55:05 <luke-jr> &
463 2011-09-17 18:55:17 <luke-jr> there are no next bits
464 2011-09-17 18:55:24 <luke-jr> the "compressed diff" is all that matters
465 2011-09-17 18:55:37 <lfm> ok then just add one and see how much of a change it is
466 2011-09-17 18:55:51 <luke-jr> why
467 2011-09-17 18:55:54 <luke-jr> it doesn't prove anything
468 2011-09-17 18:56:12 <lfm> because after that the rest of the digits are a waste of time
469 2011-09-17 18:58:43 <lfm> see we have 1a098ea5 -> 1755425.32 and 1a098ea6 would give you 1755422.518 so the fractional part is totally insignificant
470 2011-09-17 19:01:10 <lfm> if you were to start with 1755425 and convert back with any fraction you want you would still get 1a098ea5
471 2011-09-17 19:01:29 <sipa> you're comparing two real difficulties
472 2011-09-17 19:01:53 <sipa> so you get indeed that a few decimals suffices to distinguish difficulties
473 2011-09-17 19:02:08 <sipa> but the actual probabilities behind them do have much higher precision
474 2011-09-17 19:02:13 <sipa> infinite precision even
475 2011-09-17 19:02:24 <lfm> Im just saying the faction is pointless to report
476 2011-09-17 19:02:30 <lfm> fraction
477 2011-09-17 19:03:34 <tcatm> should we add a enhanced download page to bitcoin.org with unstable versions like 0.4rc2?
478 2011-09-17 19:03:58 <lfm> well its not really infinite precision either. you acually compare the 256 bit values, so there is 256 significant bits there, not infinite
479 2011-09-17 19:09:49 <luke-jr> &..
480 2011-09-17 19:10:36 <lfm> Eliel: by insignificant I mean you can calculate a number but you dont really know what the trailing digits should be after a point because the number you started with did not supply that much accuracy to you for the input value.
481 2011-09-17 19:12:14 <Eliel> lfm: that's fine for physical and analog stuff but... I don't think it's exactly applicable in this case.
482 2011-09-17 19:12:42 <luke-jr> lfm: the bits are perfectly accurate
483 2011-09-17 19:13:31 <lfm> well it is cuz the compressed difficulty is a tracation of a calculation of the time it took for the last 2016 blocks. It could have had more accuracy that was thrown away to stor it in the 32 bit word special format
484 2011-09-17 19:13:51 <lfm> tracation -> truncation
485 2011-09-17 19:14:08 <luke-jr> it doesn't have more accuracy
486 2011-09-17 19:14:17 <luke-jr> if you try to use more accuracy, your blocks will be rejected
487 2011-09-17 19:14:35 <luke-jr> the truncation is part of the calculation
488 2011-09-17 19:14:36 <lfm> ya well the time is only accurate to one second out of two weeks so ...
489 2011-09-17 19:15:53 <lfm> and of course those times depend on the clock settings of various computers which could be much less than one second accuracy
490 2011-09-17 19:16:48 <lfm> luke-jr I'm just trying to formalize how many digits of the difficulty it makes sense to report.
491 2011-09-17 19:17:02 <luke-jr> lfm: depends what it's being used for
492 2011-09-17 19:17:08 <luke-jr> for PPS calculations, quite a bit
493 2011-09-17 19:17:23 <lfm> after a certain point it doesnt matter what its used for tho
494 2011-09-17 19:17:41 <lfm> pps?
495 2011-09-17 19:17:44 <Eliel> yes, for PPS calculation, you'd want as much accuracy as you can.
496 2011-09-17 19:17:51 <Eliel> PPS = Pay Per Share
497 2011-09-17 19:18:17 <lfm> but just calculating extra digits blindly doe not give you any extra accuracy really
498 2011-09-17 19:18:50 <lfm> it becomes arbitrary, not accurate
499 2011-09-17 19:19:21 <Eliel> it does, because you're interested in the network's characteristics, not the semantics of the difficulty calculation.
500 2011-09-17 19:19:40 <luke-jr> it's not blind
501 2011-09-17 19:20:00 <Eliel> the network does the comparison with quite some bits of accuracy.
502 2011-09-17 19:20:47 <lfm> eliel when you have the "compressed" diff of 1a098ea5 you cant reall tell what the real fraction is because it was thrown away. doing extra calculations is arbitrary, not informative
503 2011-09-17 19:21:15 <Eliel> like I was just saying, the "real fraction" doesn't matter.
504 2011-09-17 19:21:29 <Eliel> what matters is the fraction used by the nodes on the network
505 2011-09-17 19:21:42 <luke-jr> lfm: wrong.
506 2011-09-17 19:21:50 <Eliel> for that, you need equal accuracy to the nodes
507 2011-09-17 19:22:11 <luke-jr> lfm: 1a098ea5 is the compressed form of 98ea500000000000000000&
508 2011-09-17 19:22:21 <luke-jr> exactly
509 2011-09-17 19:22:26 <lfm> all you know is it somewhere between 1a098ea4 and 1a098ea6 really. any extra significance is totally arbitrary
510 2011-09-17 19:22:30 <luke-jr> lfm: wrong
511 2011-09-17 19:22:36 <luke-jr> 1a098ea5 is exact
512 2011-09-17 19:23:45 <Eliel> lfm: 1a098ea5 stores the actual difficulty used by the network and it does so exactly.
513 2011-09-17 19:24:30 <lfm> but if you convert it to decimal. it doesnt grow all those fraction digits outa thin air. they are an articat of the base conversion
514 2011-09-17 19:24:42 <lfm> artifcat
515 2011-09-17 19:24:46 <luke-jr> lfm: no, they aren't
516 2011-09-17 19:24:49 <lfm> artifact
517 2011-09-17 19:24:52 <luke-jr> because difficulty is not just a conversion to decimal
518 2011-09-17 19:24:59 <luke-jr> difficulty is a division
519 2011-09-17 19:25:11 <lfm> and division is inacurate
520 2011-09-17 19:25:15 <luke-jr> no
521 2011-09-17 19:25:19 <luke-jr> division does not need to be inaccurate
522 2011-09-17 19:25:25 <lfm> you round off or truncate the result
523 2011-09-17 19:25:25 <luke-jr> lrn2math
524 2011-09-17 19:25:43 <luke-jr> you don't need to
525 2011-09-17 19:25:56 <lfm> well you did to get the 098ea5
526 2011-09-17 19:26:02 <luke-jr> nope
527 2011-09-17 19:26:21 <luke-jr> 98ea5& is EXACT
528 2011-09-17 19:26:33 <luke-jr> how you got at that target is irrelevant
529 2011-09-17 19:26:38 <lfm> and   you try divideing those seconds by 2016 or whatever it is and you will need to truncate somewhere
530 2011-09-17 19:26:42 <luke-jr> the network doesn't care about that
531 2011-09-17 19:26:48 <luke-jr> the network only cares that it's 98ea5&
532 2011-09-17 19:28:03 <lfm> and how did it get the 098ea5? a divide and truncate operation, ie throw away all those fractional digits that you think you are reinventing
533 2011-09-17 19:28:06 <luke-jr> irrelevant
534 2011-09-17 19:28:14 <luke-jr> no, we're not reinventing those
535 2011-09-17 19:28:17 <luke-jr> they were discarded
536 2011-09-17 19:28:19 <luke-jr> they are not relevant
537 2011-09-17 19:29:47 <lfm> yes they were discarded, but when you report a 100 digits of difficulty you seem to be pretending that you have recovered them
538 2011-09-17 19:30:20 <luke-jr> nope
539 2011-09-17 19:30:28 <luke-jr> those 100 digits are part of the truncated target
540 2011-09-17 19:31:28 <lfm> so you would say that if I use a 32 bit float I can print out 100 bigits of fraction and it is usefull?
541 2011-09-17 19:33:14 <luke-jr> no
542 2011-09-17 19:33:18 <lfm> I am saying if you report a difficulty of 1755425.3 or 1755425.4 you are actually reporting the same exact difficulty and you shouldnt really even put any fraction there
543 2011-09-17 19:33:18 <luke-jr> I would say you have no clue
544 2011-09-17 19:35:22 <gmaxwell> lfm: Eh, from the perspective of calculating e.g. payoff odds one is more accurate than the other.
545 2011-09-17 19:35:46 <gmaxwell> lfm: most people don't give a !@#!@ about "difficulty as the measurement of an interval"
546 2011-09-17 19:35:49 <lfm> when you calculate you pps how many digits (or bits) do you use?
547 2011-09-17 19:36:31 <sipa> the point is that you can calculate the expected income from mining at a given hash rate up to infinite precision
548 2011-09-17 19:36:38 <gmaxwell> "enough to hit the bitcoin precision with conservative rounding"
549 2011-09-17 19:36:45 <sipa> ignoring stale blocks
550 2011-09-17 19:37:19 <sipa> it wouldn't be meaningful
551 2011-09-17 19:37:25 <sipa> but it would be correct
552 2011-09-17 19:38:32 <lfm> "with conservative rounding" means you are rounding off somewhere. just another way of assuming a certain level of accuracy in a calculation
553 2011-09-17 19:39:02 <gmaxwell> Sure, but thats output limited.
554 2011-09-17 19:39:03 <sipa> we're talking about different things
555 2011-09-17 19:40:02 <gmaxwell> e.g. if I'm going to pay you something and the smallest I can pay you is 1e-8 the I just need enough precision to calculate to that with the required rounding.
556 2011-09-17 19:41:01 <lfm> sure so long as you calculate some value out to a satoshi you figure it must be the right number?
557 2011-09-17 19:41:06 <sipa> your claim is this: there are only a limited number of possible targets, and they are quite far apart, thus it is not meaningful to calculate difficulties up to more precision
558 2011-09-17 19:41:07 <gmaxwell> so if I were figuring out pps for a pool I was running, I'd calculate it out to coin unit integer and round down.
559 2011-09-17 19:41:30 <gmaxwell> If I used more than that I'd expect to lose money on average, and greater than that I'd be cheating the users.
560 2011-09-17 19:42:17 <gmaxwell> (and I'm still taking more than I should most of the time, but thats not my fault)
561 2011-09-17 19:42:57 <lfm> gmaxwell: actually you could keep track of fractions of a satoshi and save them up till you get whole ones to credit to your users.
562 2011-09-17 19:43:21 <gmaxwell> I could, sure, but I was assuming there was a constant PPS amount.
563 2011-09-17 19:43:58 <gmaxwell> I could also add uniform zero mean random numbers with a scale equal to the payment quantization step for each payment.
564 2011-09-17 19:45:35 <gmaxwell> (a memoryless way of adding up to exactly the right amount)
565 2011-09-17 19:45:40 <lfm> or you could use the gmp (gnu multi-precision) ration numbers option and calculate the 256 bit target ratio to the 0x00000000ffff000... number and do all the calculations exact in rational arithmetic.
566 2011-09-17 19:45:43 <gmaxwell> (in infinite time :) )
567 2011-09-17 19:45:58 <gmaxwell> lfm: I'm still forced to quantize eventually.
568 2011-09-17 19:46:06 <gmaxwell> (in order to make a payment)
569 2011-09-17 19:46:09 <lfm> naw gmp does that stuff quite quick
570 2011-09-17 19:47:04 <lfm> it still silly to report 100 digits for the difficulty
571 2011-09-17 19:47:19 <sipa> silly: definitely
572 2011-09-17 19:47:26 <gmaxwell> Agreed.
573 2011-09-17 19:47:30 <sipa> but not wrong
574 2011-09-17 19:47:41 <sipa> and it does have more information than using less digits
575 2011-09-17 19:47:56 <gmaxwell> Better to report the target instead.
576 2011-09-17 19:48:02 <gmaxwell> Infinite precision.
577 2011-09-17 19:48:03 <sipa> indeed
578 2011-09-17 19:48:34 <gmaxwell> And anyone that really wants 100 digits probably wants to do the calculation with exact rational math.
579 2011-09-17 19:48:51 <lfm> I wouldnt call it infinite prescision. I would perhaps call the hex value the exact value. it is still only 16-23 digits precision
580 2011-09-17 19:49:14 <gmaxwell> lfm: it's infinite for the purpose of calculating what bitcoin mining returns are.
581 2011-09-17 19:49:27 <gmaxwell> The mean of that distibution is exactly thus.
582 2011-09-17 19:50:02 <lfm> well with the terminology I am used to it is exact but not infinitly precise
583 2011-09-17 19:50:24 <da2ce7> well it is exzact percisicon
584 2011-09-17 19:50:39 <da2ce7> lol
585 2011-09-17 19:51:04 <gmaxwell> lfm: I don't see why you say that. The decision to accept a block is compared exactly to a figure produced from that determinstically.
586 2011-09-17 19:51:09 <lfm> da2ce7: exact but not precice according to the definitions of the terms that I use
587 2011-09-17 19:51:36 <gmaxwell> If you were to diminish it by any fraction you would be less correct.
588 2011-09-17 19:52:17 <da2ce7> anyway. just pass the target. we should be doing all our calculations based upon that.
589 2011-09-17 19:53:11 <lfm> there is no fraction in the 1a098ea5 value. it is a fixed binary value like : ;;bc,hextarget
590 2011-09-17 19:53:25 <lfm> ;;bc,hextarget
591 2011-09-17 19:53:26 <gribble> 000000000000098EA50000000000000000000000000000000000000000000000
592 2011-09-17 19:54:30 <gmaxwell> lfm: I know. But if you were to add one it could only make the value calculated for the mean of the distribution of the time between hashes less accurate.
593 2011-09-17 19:54:35 <lfm> see, no fraction and all those zeros are just placeholders, not "precision".
594 2011-09-17 19:56:13 <da2ce7> why don't we just use big-int?
595 2011-09-17 19:56:19 <da2ce7> and use floor?
596 2011-09-17 19:56:38 <lfm> da2ce7: we do for some cases
597 2011-09-17 19:58:45 <lfm> the zeros in the hextarget are not precision because we cannot have a hextarget of 000000000000098EA50000000000000000000000000000000000000000000001  <- see htere, thats not allowed. the spec does not carry that "precision".
598 2011-09-17 20:00:01 <lfm> and same for all the other trailing zeros, they are required to be zeros, not other digits
599 2011-09-17 20:00:27 <da2ce7> they are just padding.
600 2011-09-17 20:00:49 <lfm> padding or filler or placeholders, call them what you want.
601 2011-09-17 20:01:59 <gmaxwell> It doesn't really matter whats allowed.
602 2011-09-17 20:02:21 <gmaxwell> The target is what it is.
603 2011-09-17 20:02:55 <gmaxwell> If you convert it to a format that allows more precision and you fill any of that precision with anything but zero you've made the figure less accurate.
604 2011-09-17 20:03:14 <lfm> huh?
605 2011-09-17 20:03:51 <da2ce7> well: (hex)target > (bigInt)target > do calculations > (floor) to format you want.
606 2011-09-17 20:04:06 <da2ce7> or something like that.
607 2011-09-17 20:04:41 <lfm> the spec might specify those filler digits should be Fs or 5 or anything, it happens to specifiy 0s
608 2011-09-17 20:05:17 <gmaxwell> You're not at all following what I'm saying.
609 2011-09-17 20:06:46 <lfm> gmaxwell: true, I am not following what your definition of the term "accurate" is. yo you mean exact or do you mean precise? (as I use those terms) I suspect you dont knwo which you mean.
610 2011-09-17 20:07:07 <gmaxwell> If difficulty values could only be e.g. 1.234450 -> 1.234900 (e.g. I'm giving too much precision here)  you would get incorrect answers if you computed the expected operations between solutions using 1.2344 instead of 1.234450.
611 2011-09-17 20:08:04 <gmaxwell> No, I mean accurate. You would get results which are incorrect up to available precision, which is infinite for the mean of the distribution of operations between solutions.
612 2011-09-17 20:08:56 <gmaxwell> Just because the spec can't expres intermedate target values doesn't mean that bitcoin clients might use them rather than the actual target.
613 2011-09-17 20:09:17 <lfm> gmaxwell: well computers cannot really do infinatly accurate calculations you know. they are always limited usually by avalable memory.
614 2011-09-17 20:10:01 <gmaxwell> It's all rational, finite in finite out.
615 2011-09-17 20:10:52 <gmaxwell> And I do infinite precision calculations all the time. Using exact rational arithemetic, which is something that every computer algebra system is perfectly comfortable with.
616 2011-09-17 20:11:06 <lfm> and rounding off all the time and with maximums and minimums beyond which any givven format will overflow or underflow.
617 2011-09-17 20:11:46 <sipa> lfm let me make an analogy
618 2011-09-17 20:11:57 <lfm> you only handle a small subset of possible values tho, nothing like infinite.
619 2011-09-17 20:12:36 <sipa> the only speed limits that exist here (belgium) are 10, 20, 30, 50, 70, 90 and 120 km/h
620 2011-09-17 20:13:01 <sipa> does that mean it is impossible to drive 40km in hour?
621 2011-09-17 20:13:10 <lfm> if you have a single number that fills up your memory you cant do much more. thats not do ing infinite numbers. that is still finite.
622 2011-09-17 20:13:58 <sipa> it's entirely irrelevant
623 2011-09-17 20:14:32 <lfm> sipa pretty much impossible ya. Id say you almost certainly are either going faster than 40 km/h or slower. It may in fact be impossible to go exactly 40 km/h
624 2011-09-17 20:14:43 <sipa> no
625 2011-09-17 20:14:45 <sipa> i mean
626 2011-09-17 20:15:01 <sipa> if i am describing a speed limit
627 2011-09-17 20:15:14 <sipa> it suffices that i give you the multiple of 10km/h
628 2011-09-17 20:15:42 <lfm> and if you dont know exactly how fast you are going then how can you know if you are speeding?
629 2011-09-17 20:15:44 <sipa> as there is no 15km/h limit, it suffices to say "oh it's 1-something per hour"
630 2011-09-17 20:15:51 <sipa> agree?
631 2011-09-17 20:15:53 <sipa> just bear with me
632 2011-09-17 20:17:33 <sipa> lfm: agree?
633 2011-09-17 20:17:40 <lfm> so whats the question?
634 2011-09-17 20:17:48 <sipa> there is no 15km/h limit
635 2011-09-17 20:17:55 <lfm> ok
636 2011-09-17 20:18:15 <sipa> so if i'm describing a speed limit, and say "it is 1-something km per hour", you know i can only mean 10km/h
637 2011-09-17 20:18:18 <sipa> right?
638 2011-09-17 20:18:50 <lfm> unless you mean 19.9999 ... (with the 9s repeating) then it is equal to 20
639 2011-09-17 20:19:11 <sipa> technically, you're right
640 2011-09-17 20:19:24 <lfm> sorry, I know what you wanted me to say
641 2011-09-17 20:19:35 <sipa> rephrase: "it is 3-something km per hour", then you know i can only mean 30km/h
642 2011-09-17 20:20:01 <sipa> however, that doesn't mean 32km/h is an impossible or meaningless number
643 2011-09-17 20:20:17 <sipa> speeds are also relevant for other things than describing speed limits
644 2011-09-17 20:20:37 <da2ce7> lfm. take two rational numbers and proform the inverse product fuction (division).
645 2011-09-17 20:20:47 <da2ce7> what is the most complicated result you can obtain?
646 2011-09-17 20:20:49 <lfm> in the sense that 32 is like in a range of 31.5 to 32.5 or something
647 2011-09-17 20:21:09 <sipa> no, just 32 on itself is a useful metric that can occur in calculations
648 2011-09-17 20:21:14 <da2ce7> this will show the ABS_maths memory limits.
649 2011-09-17 20:21:22 <sipa> even if there are no roads where exactly that speed is enforced
650 2011-09-17 20:21:26 <lfm> da2ce7: what you mean complicated?
651 2011-09-17 20:21:48 <da2ce7> for two 256bit numbers the limit is 512bit complexity.
652 2011-09-17 20:22:23 <lfm> da2ce7: ya, I guess, assuming your using rational numbers or something
653 2011-09-17 20:22:37 <da2ce7> yes... the target is a rational number...
654 2011-09-17 20:22:42 <sipa> lfm: for the difficulty it is exactly the same: yes, there exists no difficulty between 14423.5 and 14423.51, but that doesn't mean the first one isn't less accurate
655 2011-09-17 20:23:51 <lfm> sipa your confusing accurate with exact or precise. it may be less exact but no more precise.
656 2011-09-17 20:24:14 <pointbiz> tcatm: bitcoin.org should promote stability. people who should try a release candidate probably know how to get it.
657 2011-09-17 20:25:40 <sipa> i agree
658 2011-09-17 20:26:07 <tcatm> what's the correct way to get it with the forums being "unofficial"? -dev mailinglist?
659 2011-09-17 20:27:36 <lfm> you mean like announcing "official" release candidates?
660 2011-09-17 20:27:53 <sipa> tcatm: i suppose
661 2011-09-17 20:28:24 <tcatm> lfm: yes. basically copying gavin's forum post to bitcoin.org
662 2011-09-17 20:46:03 <gribble> Best bid: 4.7508, Best ask: 4.788, Bid-ask spread: 0.0372, Last trade: 4.7507, 24 hour volume: 21174, 24 hour low: 4.7, 24 hour high: 4.93
663 2011-09-17 20:46:03 <ymirhotfoot> ;;ticker
664 2011-09-17 21:28:06 <pointbiz> should there be official release candidate? that would be more software for gavin to support
665 2011-09-17 21:28:19 <pointbiz> be an*
666 2011-09-17 21:30:30 <pointbiz> average user doesn't know that "RC" means Release Candidate
667 2011-09-17 21:32:15 <pointbiz> i guess you could add a developer tab on bitcoin.org
668 2011-09-17 21:32:43 <pointbiz> some of the comments about the website not being very appealing for the mainstream might be true
669 2011-09-17 21:32:54 <pointbiz> i like the new design, but i'm a coder
670 2011-09-17 21:33:54 <pointbiz> why is the word "experimental" used on the home page? isn't that just an opinion?
671 2011-09-17 21:35:51 <jgarzik> pointbiz: there are multiple release candidates, leading up to the release itself
672 2011-09-17 21:37:30 <tcatm> pointbiz: most developers (all?) consider bitcoin still experimental
673 2011-09-17 22:04:24 <jjjrmy> Selling BitPizza.net
674 2011-09-17 22:14:44 <flying> stupid irc client.
675 2011-09-17 23:40:42 <Disposition> it has come to my attention Satoshi is the main character from Pokemon.
676 2011-09-17 23:50:47 <luke-jr> Disposition: no crap
677 2011-09-17 23:51:01 <luke-jr> Disposition: it's also a rather common name
678 2011-09-17 23:51:23 <luke-jr> http://en.wikipedia.org/wiki/Satoshi has like 30 notables
679 2011-09-17 23:51:31 <luke-jr> most of which are real people
680 2011-09-17 23:56:42 <hololeap> does anyone know how to set up the client to use JSON-RPC
681 2011-09-17 23:57:31 <luke-jr> hololeap: only Spesmilo supports that
682 2011-09-17 23:58:05 <hololeap> i was really just looking for a way to start mining
683 2011-09-17 23:58:15 <hololeap> so the standard client doesnt allow that?
684 2011-09-17 23:59:28 <luke-jr> oh, you mean *provides* JSON-RPC
685 2011-09-17 23:59:44 <luke-jr> the Satoshi client does, via the -server option
686 2011-09-17 23:59:49 <luke-jr> but that's solo mining, and not very efficient