1 2013-01-28 00:00:44 RainbowDashh has quit (Ping timeout: 245 seconds)
2 2013-01-28 00:01:26 <HM> roll on C++17
3 2013-01-28 00:01:35 <HM> or 14, or whatever it is
4 2013-01-28 00:04:53 k0rx has quit (Quit: Leaving.)
5 2013-01-28 00:07:34 <D34TH> HM: more like C++666
6 2013-01-28 00:09:14 RainbowDashh has joined
7 2013-01-28 00:10:55 <HM> just give us modules
8 2013-01-28 00:30:49 Gladamas has quit (Read error: Connection reset by peer)
9 2013-01-28 00:31:03 tcatm has quit (Quit: No Ping reply in 180 seconds.)
10 2013-01-28 00:31:20 tcatm has joined
11 2013-01-28 00:31:21 tcatm has quit (Changing host)
12 2013-01-28 00:31:21 tcatm has joined
13 2013-01-28 00:32:31 HM has quit (Ping timeout: 252 seconds)
14 2013-01-28 00:35:56 HM has joined
15 2013-01-28 00:40:18 toffoo has quit ()
16 2013-01-28 00:51:38 djoot has quit (Quit: leaving)
17 2013-01-28 00:52:17 HM has quit (Read error: Connection reset by peer)
18 2013-01-28 00:52:32 HM2 has joined
19 2013-01-28 00:57:38 paybitcoin1 has quit (Read error: Connection reset by peer)
20 2013-01-28 00:57:51 t7 has quit (Quit: Konversation terminated!)
21 2013-01-28 00:59:14 porquilho has quit ()
22 2013-01-28 00:59:47 paybitcoin has joined
23 2013-01-28 01:01:59 RainbowDashh has quit (Quit: Computer has gone to sleep.)
24 2013-01-28 01:02:39 HM has joined
25 2013-01-28 01:02:50 HM2 has quit (Read error: Connection reset by peer)
26 2013-01-28 01:04:17 paybitcoin has quit (Ping timeout: 252 seconds)
27 2013-01-28 01:04:17 RainbowDashh has joined
28 2013-01-28 01:04:18 RainbowDashh has quit (Changing host)
29 2013-01-28 01:04:18 RainbowDashh has joined
30 2013-01-28 01:04:47 paybitcoin has joined
31 2013-01-28 01:06:42 <D34TH> sipa: why only check 288 blocks?
32 2013-01-28 01:08:23 <sipa> D34TH: https://github.com/bitcoin/bitcoin/issues/2205
33 2013-01-28 01:08:24 HM has quit (Read error: Connection reset by peer)
34 2013-01-28 01:08:44 rdymac has quit (Quit: This computer has gone to sleep)
35 2013-01-28 01:08:50 HM has joined
36 2013-01-28 01:09:04 <HM> that varint encoding used by satoshi isn't bad
37 2013-01-28 01:09:08 <D34TH> thanks! all i saw was 2222 which had no comments
38 2013-01-28 01:09:28 djoot has joined
39 2013-01-28 01:09:29 <sipa> it linked to #2205, though
40 2013-01-28 01:09:43 <D34TH> not in my command line news reader
41 2013-01-28 01:09:44 <D34TH> D:
42 2013-01-28 01:09:51 <sipa> HM: i like base128 encoding better
43 2013-01-28 01:10:07 <D34TH> oh wow
44 2013-01-28 01:10:12 <D34TH> that is quite a bit faster
45 2013-01-28 01:10:19 darkskiez has quit (Ping timeout: 245 seconds)
46 2013-01-28 01:10:35 <gmaxwell> HM: its redundant, which is lame and potentially problematic.
47 2013-01-28 01:11:57 <HM> why problematic
48 2013-01-28 01:12:35 <gmaxwell> because we hash lots of things, it means that if you deserialze and reseralize something you may get something different back which has a different hash but the same content.
49 2013-01-28 01:12:48 <sipa> gmaxwell: ... i just realized
50 2013-01-28 01:12:55 darkskiez has joined
51 2013-01-28 01:13:12 <sipa> if you use a non-standard encoded varint for the vin/vout count in a transaction
52 2013-01-28 01:13:18 <HM> oh because someone might encoded a short int as a long one?
53 2013-01-28 01:13:27 <sipa> its signature won't change
54 2013-01-28 01:13:50 <sipa> then again, its txid also won't
55 2013-01-28 01:14:08 <sipa> so it's not really a problem, unless there are nodes out there that calculate the txid based on the raw data
56 2013-01-28 01:14:21 <HM> yeah i can see some people being lazy and just outputing 0xff uint64_t for all values
57 2013-01-28 01:15:22 <gmaxwell> unimportantly it also makes them bigger than they could be otherwise.
58 2013-01-28 01:16:16 <HM> yeah i guess normalisation has to be part of your specification if you're hashing
59 2013-01-28 01:16:28 <sipa> well, not necessarily true - compared to base128 encoding, if there is a large(r) probability of values 128-252, satoshi varints are smaller
60 2013-01-28 01:16:34 <HM> but hey, networking standards like IP have "pseudo headers" for hashing
61 2013-01-28 01:19:52 one_zero has joined
62 2013-01-28 01:21:26 <sipa> ha
63 2013-01-28 01:21:38 <gmaxwell> sipa: 'satoshi' varints could simply have specified that each size up subtracts the maximum of the prior size.
64 2013-01-28 01:22:17 <gmaxwell> Doing so doesn't make the code to read it really any more complex, and it makes it non-redundant and more compact.
65 2013-01-28 01:22:45 <sipa> yes, agree
66 2013-01-28 01:23:08 <sipa> so there is a variation possible that is guaranteed to be never less efficient
67 2013-01-28 01:24:04 FredEE has quit (Quit: FredEE)
68 2013-01-28 01:24:43 <HM> it's kind of strange to try and save a few bits anyway when you're transmitting lengthy pseudorandom hashes and scripts
69 2013-01-28 01:25:05 <sipa> sure - it's more about guaranteeing a normalization
70 2013-01-28 01:25:38 <sipa> you could guarantee that otherwise too by saying "implementations must always use the shortest possible form", but that is very easy to forget to check
71 2013-01-28 01:27:59 <HM> many of my projects that have needed mini protocols have utilised protocol buffers. i can't be arsed twiddling with bits and hand writing such code.
72 2013-01-28 01:28:23 <sipa> protocol buffers' integer encoding is also redundant, actually
73 2013-01-28 01:28:31 <HM> it's base 128
74 2013-01-28 01:28:35 <sipa> yes
75 2013-01-28 01:28:39 <gmaxwell> HM: well, it's important that transactions be maximally small.. I agree that the space savings isn't paramount, though as sipa saysâ the point wouldn't be to save space... thats just a bonus.
76 2013-01-28 01:28:52 <HM> indeed
77 2013-01-28 01:29:23 <sipa> HM: but you can manually construct a protocol buffer serialization that is not the smallest possible, and is accepted
78 2013-01-28 01:29:36 <gmaxwell> ugh.
79 2013-01-28 01:30:23 <sipa> non-redundant versions are much more cpu intensive, though
80 2013-01-28 01:31:10 <HM> yeah but pb is designed to be a flexible format, so you'd never be hashing it in that form anyway because normalising it isn't simple
81 2013-01-28 01:31:20 <gmaxwell> HM: haha
82 2013-01-28 01:31:49 <sipa> indeed, they lack normalisation in other ways too
83 2013-01-28 01:31:55 <HM> you can just send someone redundant fields with field id's that they don't recognise, fields can also be in any order
84 2013-01-28 01:32:12 <gmaxwell> sipa: not for anything we're doing at leastâ I mean, you end up with a branch for difference sizes, just insert the subtraction in there. It should be free on any modern cpu.
85 2013-01-28 01:32:41 <HM> pfft
86 2013-01-28 01:32:47 <HM> future is gzipped json, didn't you hear?
87 2013-01-28 01:32:56 <sipa> in base64
88 2013-01-28 01:33:03 <HM> no no, base 58 :)
89 2013-01-28 01:33:21 * sipa kills himself
90 2013-01-28 01:33:27 <gmaxwell> 58 isn't prime. Base59!
91 2013-01-28 01:34:01 <HM> but then you can't rot29 it
92 2013-01-28 01:34:16 <sipa> you mean triple-rot29, i hope
93 2013-01-28 01:34:26 <sipa> single rot29 is considered broken these days
94 2013-01-28 01:35:01 <HM> well there goes my wallet
95 2013-01-28 01:36:45 <sipa> HM: actually, i'd prefer base58-encoded zip files containing png's with QR codes that encode the data, itself encoded as JSON
96 2013-01-28 01:37:11 <gmaxwell> s/zip/rar/
97 2013-01-28 01:37:20 <HM> compressing a png isn't going to gain you much space
98 2013-01-28 01:37:25 <sipa> wait wait wait
99 2013-01-28 01:37:27 <kjj> delivered by avian carrier, I hope
100 2013-01-28 01:37:29 <HM> maybe an animated gif
101 2013-01-28 01:37:33 <sipa> are we trying to gain space? :o
102 2013-01-28 01:37:59 <gmaxwell> HM: thats why you mandate the png itself be uncompressedâ avoids mucking up the rar compression.
103 2013-01-28 01:38:01 <HM> the point wouldn't be to save space... thats just a bonus.
104 2013-01-28 01:38:18 <sipa> HM: you do know there's a parent on repeatedly compressing a file, to reach arbitrarily small sizes, right?
105 2013-01-28 01:38:23 <sipa> *patent
106 2013-01-28 01:38:30 <HM> yes, it's called rename
107 2013-01-28 01:38:38 <gmaxwell> they keep it right next to the perpetual motion machine patent.
108 2013-01-28 01:39:00 <HM> read byte from file, truncate file, append to filename :P
109 2013-01-28 01:39:06 <HM> zomg 0 byte file
110 2013-01-28 01:39:45 <sipa> http://gailly.net/05533051.html
111 2013-01-28 01:40:47 rdponticelli has quit (Ping timeout: 276 seconds)
112 2013-01-28 01:43:43 <gmaxwell> sipa: if it makes you feel better that patent was abandoned (applicant failed to pay maintance fees) and is no longer valid.
113 2013-01-28 01:44:23 <sipa> gmaxwell: thanks for saving my trust in the human kind
114 2013-01-28 01:44:36 <sipa> s/saving/restoring/
115 2013-01-28 01:46:53 <gmaxwell> Also, the patent was initially rejected by the examiner and the applicant fought the rejection.
116 2013-01-28 01:47:13 <sipa> wow!
117 2013-01-28 01:47:59 <gmaxwell> Because it was before 2002 I can't get the filewrapper online, so I dunno what the examiner says. (It would cost $200 to get the fileâ too much for idle curiosity)
118 2013-01-28 01:48:31 <gmaxwell> I expect the examiner pointed out it was impossible and the applicant pointed to his weasel words and they allowed it.
119 2013-01-28 01:48:51 <gmaxwell> (they amended their claims tooâ so they may have added the weasel words in response)
120 2013-01-28 01:50:00 <gmaxwell> Another interesting tidbitâ they failed to pay their maintenance fees back in 2004 and filed a petition for permission to pay them late. It was granted ... but then they never paid them and the patent lapsed in 2008.
121 2013-01-28 01:51:18 graham1 has joined
122 2013-01-28 01:57:19 <andytoshi> but why pay for such a patent? nobody could ever infringe
123 2013-01-28 01:58:30 <gmaxwell> There are a number of reasons. In this case the inventor probably didn't know that and thought he had something, he may have been being exploited by an attorney he was paying to do the application.
124 2013-01-28 01:58:59 <gmaxwell> But a patent is fine resume padding, so it could be rational to get one which could never be enforced just to put it on your resume.
125 2013-01-28 01:59:08 <andytoshi> bizarre
126 2013-01-28 01:59:24 <CodeShark> lol
127 2013-01-28 01:59:51 <gmaxwell> Plenty of large companies get unenforcable patents just to pad their warchest... making sure you don't infringe it is still a cost. (rather: they don't care if its enforcable or not, and its generally easier to get non-enforcable patents)
128 2013-01-28 02:00:48 <CodeShark> getting a patent is cheap - it's the litigation that's expensive
129 2013-01-28 02:01:06 <gmaxwell> E.g. any patent claim longer than half a page is almost certantly non-enforcable. (~all of the text is limiting, so with enough of it nothing can infringe)
130 2013-01-28 02:01:23 <gmaxwell> But a long claim is almost certantly novel and distinct from the prior art!
131 2013-01-28 02:06:41 FredEE has joined
132 2013-01-28 02:20:19 reizuki__ has quit (Ping timeout: 252 seconds)
133 2013-01-28 02:20:46 gavinandresen has quit (Quit: gavinandresen)
134 2013-01-28 02:26:43 reizuki__ has joined
135 2013-01-28 02:26:43 reizuki__ has quit (Changing host)
136 2013-01-28 02:26:43 reizuki__ has joined
137 2013-01-28 02:32:07 rdponticelli has joined
138 2013-01-28 02:35:14 <HM> scary
139 2013-01-28 02:35:26 <HM> python doesn't care if you declare 2 classes of the same name in one file
140 2013-01-28 02:35:32 <HM> must merge them
141 2013-01-28 02:38:38 rdponticelli has quit (Ping timeout: 276 seconds)
142 2013-01-28 02:40:04 mappum has quit (Read error: Connection reset by peer)
143 2013-01-28 02:43:25 <Mad7Scientist> ;;getrating carryon
144 2013-01-28 02:43:25 <gribble> WARNING: Currently not authenticated. User carryon, rated since Fri Jan 25 21:29:00 2013. Cumulative rating 1, from 1 total ratings. Received ratings: 1 positive, 0 negative. Sent ratings: 1 positive, 0 negative. Details: http://bitcoin-otc.com/viewratingdetail.php?nick=carryon
145 2013-01-28 02:43:52 BGL has quit (Ping timeout: 255 seconds)
146 2013-01-28 02:45:43 RainbowDashh has quit (Quit: Computer has gone to sleep.)
147 2013-01-28 02:46:35 <jgarzik> Mad7Scientist: try /msg gribble please
148 2013-01-28 02:50:48 pi___ has joined
149 2013-01-28 02:54:44 MrTiggr has quit (Ping timeout: 256 seconds)
150 2013-01-28 02:55:47 pi___ has quit (Quit: Page closed)
151 2013-01-28 03:02:22 rdponticelli has joined
152 2013-01-28 03:06:09 copumpkin has quit (Ping timeout: 245 seconds)
153 2013-01-28 03:06:45 copumpkin has joined
154 2013-01-28 03:13:14 RainbowDashh has joined
155 2013-01-28 03:14:24 dust-otc has quit (Remote host closed the connection)
156 2013-01-28 03:15:02 rdponticelli has quit (Ping timeout: 276 seconds)
157 2013-01-28 03:17:24 CodeInChaos has quit (Ping timeout: 256 seconds)
158 2013-01-28 03:18:10 BGL has joined
159 2013-01-28 03:21:08 D34TH has quit (Quit: Leaving)
160 2013-01-28 03:29:01 paraipan has quit (Quit: Saliendo)
161 2013-01-28 03:30:49 impulse is now known as impulse-
162 2013-01-28 03:33:59 freewil has quit (Read error: Connection reset by peer)
163 2013-01-28 03:37:00 RBecker is now known as rbecker
164 2013-01-28 03:49:24 Gladamas has joined
165 2013-01-28 03:50:01 b4epoche has quit (Ping timeout: 255 seconds)
166 2013-01-28 03:50:31 fiesh has quit (Ping timeout: 252 seconds)
167 2013-01-28 03:52:39 MrTiggr has joined
168 2013-01-28 03:53:20 fiesh has joined
169 2013-01-28 03:53:32 b4epoche has joined
170 2013-01-28 03:56:55 freewil has joined
171 2013-01-28 04:01:31 HM has quit (Ping timeout: 252 seconds)
172 2013-01-28 04:07:52 HM has joined
173 2013-01-28 04:09:41 <CodeShark> are there any other distros of linux besides ubuntu, debian, and gentoo that should be supported by the bitcoind configure file?
174 2013-01-28 04:09:53 <kjj> slackware
175 2013-01-28 04:10:27 <CodeShark> any estimates on the bitcoind userbase using slackware? :)
176 2013-01-28 04:10:38 <kjj> >=1
177 2013-01-28 04:10:43 <CodeShark> lol
178 2013-01-28 04:10:48 <andytoshi> arch
179 2013-01-28 04:11:04 rdponticelli has joined
180 2013-01-28 04:11:53 <andytoshi> CodeShark: by 'configure', do you mean you are setting up autotools?
181 2013-01-28 04:12:03 <gmaxwell> CodeShark: uh. if you're asking about supporting distros in the configure, you're failing at autotools.
182 2013-01-28 04:12:09 <CodeShark> no, I'm handwriting the script
183 2013-01-28 04:12:09 <Luke-Jr> CodeShark: HP-UX, SunOS
184 2013-01-28 04:12:16 <Luke-Jr> gmaxwell: he's not using autotools :P
185 2013-01-28 04:12:32 <CodeShark> autotools is a huge bloated monster :)
186 2013-01-28 04:12:48 <Luke-Jr> CodeShark: but it works well
187 2013-01-28 04:12:50 <gmaxwell> ugh.
188 2013-01-28 04:12:59 <Luke-Jr> CodeShark: also, don't forget to make sure cross-compiling works! :P
189 2013-01-28 04:12:59 <andytoshi> it does work well, unfortunately
190 2013-01-28 04:13:39 <gmaxwell> Luke-Jr: as soon as you stipulate cross-compiling people end up reinventing autotools poorly in order to comply.
191 2013-01-28 04:14:20 JZavala has joined
192 2013-01-28 04:15:52 owowo has quit (Quit: sayonara)
193 2013-01-28 04:16:47 B0g4r7 has quit (Ping timeout: 276 seconds)
194 2013-01-28 04:16:53 <CodeShark> no cross-compiling for now...this is not intended for production builds - it's intended for users who want to compile it themselves...and very few windows users will
195 2013-01-28 04:17:03 <Luke-Jr> gmaxwell: yeah, when I first saw his work, I decided I'd better just keep my mouth shut as long as I wasn't planning to do a proper autotools myself <.<
196 2013-01-28 04:18:36 Gladamas has quit (Read error: Connection reset by peer)
197 2013-01-28 04:19:29 <Luke-Jr> CodeShark: btw, did you get my point about MACHINE? uname -m is NEVER useful for configure scripts. ever.
198 2013-01-28 04:19:59 Guest62759 has quit (Read error: No route to host)
199 2013-01-28 04:20:04 <CodeShark> i386 vs x86_64?
200 2013-01-28 04:20:21 Guest62759 has joined
201 2013-01-28 04:20:32 <CodeShark> I could imagine that being useful in some instances
202 2013-01-28 04:20:42 <Luke-Jr> CodeShark: but it doesn't tell you which one the OS is
203 2013-01-28 04:20:44 <Luke-Jr> just the kernel
204 2013-01-28 04:20:55 <Luke-Jr> for example, I run 32-bit, but my kernel is 64-bit, so uname -m will tell you x86_64
205 2013-01-28 04:21:02 <Luke-Jr> if you compile for x86_64 somehow, it won't run
206 2013-01-28 04:21:31 <Luke-Jr> and x32 systems always have x86_64 kernels
207 2013-01-28 04:21:31 B0g4r7 has joined
208 2013-01-28 04:21:41 <CodeShark> wait...huh?
209 2013-01-28 04:22:24 <Luke-Jr> CodeShark: x86_64 kernels can run more than just x86_64 OS ;)
210 2013-01-28 04:22:42 <Luke-Jr> they can also run regular i386 OS, or x32 OS
211 2013-01-28 04:23:16 <CodeShark> isn't the kernel like the main part of the OS?
212 2013-01-28 04:23:30 <etotheipi_> does bitcoin-qt finally register itself for URI-handling on all OS, now?
213 2013-01-28 04:23:32 <Luke-Jr> no, it's just the hardware go-between more or less
214 2013-01-28 04:23:33 * jgarzik ditto's luke-jr
215 2013-01-28 04:23:45 <jgarzik> I prefer autotools, and used it in picocoin, cpuminer, ...
216 2013-01-28 04:24:07 * jgarzik noticed the pull requests's "configure" was hand-rolled... but not prepared to do the work myself to get autotools working for bitcoin
217 2013-01-28 04:24:17 <jgarzik> so I kept my mouth shut
218 2013-01-28 04:24:20 <Luke-Jr> CodeShark: gcc -dumpmachine <-- useful
219 2013-01-28 04:24:21 <CodeShark> lol
220 2013-01-28 04:24:27 <Diablo-D3> jgarzik: lol
221 2013-01-28 04:25:01 SomeoneWeird has quit (Ping timeout: 245 seconds)
222 2013-01-28 04:25:45 <CodeShark> so everyone knows how to do it with autotools but nobody wants to...
223 2013-01-28 04:26:20 <Luke-Jr> CodeShark: don't let us discourage you though, your hand-script is certainly better than nothing at all
224 2013-01-28 04:26:44 <andytoshi> CodeShark: i don't know how :)
225 2013-01-28 04:27:14 <CodeShark> I still don't follow the 32 bit OS on 64-bit kernel thing. I understand 32-bit applications on a 64-bit OS...but 32-bit OS on a 64-bit kernel?
226 2013-01-28 04:27:18 Guest23476 has joined
227 2013-01-28 04:27:32 <andytoshi> CodeShark: you can have all your libraries be 32-bit
228 2013-01-28 04:27:39 <andytoshi> including libc, which is pretty-much your OS
229 2013-01-28 04:27:57 <Luke-Jr> CodeShark: 32-bit applications don't *actually* run on a 64-bit OS - what you're thinking is really a hybrid 32/64 OS :p
230 2013-01-28 04:27:59 <CodeShark> libraries yes - but the kernel is still 64-bits
231 2013-01-28 04:28:13 <Luke-Jr> CodeShark: the kernel doesn't matter to applications
232 2013-01-28 04:29:28 <CodeShark> I agree that it is more important what the libraries are than the kernel as far as building software...but if the kernel is only 32-bits, you will not get anything from trying to install and link to a 64-bit library
233 2013-01-28 04:29:48 <CodeShark> as far as performance, etc..
234 2013-01-28 04:29:53 <Luke-Jr> CodeShark: of course, an i386 kernel can only run an i386 OS
235 2013-01-28 04:30:14 <Luke-Jr> it's the x86_64 kernel that can run 3 flavours of OS architectures
236 2013-01-28 04:31:14 TheSeven has quit (Disconnected by services)
237 2013-01-28 04:31:23 [7] has joined
238 2013-01-28 04:34:08 <CodeShark> an i386 could still run 64-bit libraries using emulation
239 2013-01-28 04:36:01 <CodeShark> anyhow, I'm not sure I've heard of OS architecture and kernel architecture being treated as two separate things - I've always thought of the kernel as the most important part of the OS...and libraries are libraries.
240 2013-01-28 04:36:05 <Luke-Jr> or MIPS, PPC, or ARM even, but that's not really as relevant I think :P
241 2013-01-28 04:36:20 <CodeShark> so to me, the kernel and the OS are inseparable
242 2013-01-28 04:36:43 <CodeShark> the libraries, the shell, etc...they can also be considered part of the OS - but without the kernel you cannot have an OS at all
243 2013-01-28 04:36:49 <Luke-Jr> CodeShark: well, thankfully that mistake plagues only very few programs anymore âº
244 2013-01-28 04:36:59 <Luke-Jr> CodeShark: the kernel is the easiest part of the OS to replace
245 2013-01-28 04:37:47 <Luke-Jr> you could replace Linux with FreeBSD's kernel and (assuming it supports all your hardware) never know the difference
246 2013-01-28 04:38:08 <Luke-Jr> (Debian in fact supports this)
247 2013-01-28 04:39:29 <andytoshi> to be fair, systemd would stop working and /proc and /sys would look different
248 2013-01-28 04:40:03 <Luke-Jr> andytoshi: please, keep systemd away from my systems regardless of kernel
249 2013-01-28 04:40:06 <Luke-Jr> init works fine
250 2013-01-28 04:40:25 <Luke-Jr> anyhow, I meant from the perspective of an end user, not a low-level hacker ;)
251 2013-01-28 04:40:56 <gmaxwell> Systemd seems pretty nice actually. I liked it more than I expected, and I didn't even expect to dislike it.
252 2013-01-28 04:41:18 * andytoshi goes back to LWN, where there's none of this awful systemd arguing..
253 2013-01-28 04:41:53 <Luke-Jr> gmaxwell: besides init working great and I'd miss it and have to relearn everything⦠systemd's assimilation of udev recently screwed me out of a whole day
254 2013-01-28 04:42:45 <gmaxwell> andytoshi: systemd's non-portablity is arguably a bug, though its own its developers defend... in either case that doesn't really invalidate Luke's point. From 20 layers down the stack the kernel is mostly only relevent when its buggy or broken. :P
255 2013-01-28 04:43:13 <andytoshi> i really wish systemd was portable, because it's actually a killer app for linux for me
256 2013-01-28 04:43:29 <andytoshi> but it's not BSD-licensed, so i can't see how any of the BSD's could use it, even if they were able to
257 2013-01-28 04:43:50 <Luke-Jr> andytoshi: how is it a killer app when it doesn't do anything new?
258 2013-01-28 04:44:20 * Luke-Jr wonders what he did to get on stamit's PM list
259 2013-01-28 04:44:24 <andytoshi> it does things much more simply, and does all the awful PID juggling for me
260 2013-01-28 04:44:46 <andytoshi> so i can write .service files without any trouble, and not worry that i'll be rewriting them every time i switch distro
261 2013-01-28 04:44:57 RainbowDashh is now known as RainbowD_
262 2013-01-28 04:45:09 <Luke-Jr> ⦠assuming every distro uses systemd <.<
263 2013-01-28 04:45:21 <andytoshi> well, sure
264 2013-01-28 04:45:39 <CodeShark> what about upstart?
265 2013-01-28 04:45:47 <andytoshi> i've never used upstart tbh
266 2013-01-28 04:46:00 <Luke-Jr> CodeShark: same thing as systemd more or less
267 2013-01-28 04:46:13 <Luke-Jr> unnecessary reinventing the wheel
268 2013-01-28 04:46:19 <andytoshi> there are some pretty big technical differences
269 2013-01-28 04:46:41 <andytoshi> systemd uses cgroups, so it can track processes and see when they die, consistently
270 2013-01-28 04:46:43 <jgarzik> systemd breaks everything, but the end result seems quite fast
271 2013-01-28 04:46:50 <gmaxwell> I think upstart takes most of the compatiblity costs (though it pretends to be a bit more backwards compatible) without most of the benefits, I was not a big fan of it.
272 2013-01-28 04:47:20 <Luke-Jr> a well-configured init is pretty fast
273 2013-01-28 04:47:25 <Luke-Jr> especially if you enable parallel boot
274 2013-01-28 04:47:29 <andytoshi> jgarzik, Luke-Jr, lennart just posted a "30 myths about systemd" post which talks about a bit of this
275 2013-01-28 04:47:44 <Luke-Jr> andytoshi: I find the myths are about init.
276 2013-01-28 04:48:01 <Luke-Jr> andytoshi: upstart and systemd seem to pretend init doesn't do 90% of what it can
277 2013-01-28 04:48:25 <andytoshi> http://0pointer.de/blog/projects/the-biggest-myths
278 2013-01-28 04:48:56 <gmaxwell> Another more subtle argument is that change is a fact of lifeâ and some parts of the linux ecosystem are changing in ugly ways (e.g. I've been generally unimpressed by everything within 10 meters of gconf). Systemd at least clearly understands the positive values of the things it is replacing, and so competent change ought to be rewarded by embracing it so that people who try to push incompent change can't argue that I'm rejecting all ...
279 2013-01-28 04:49:02 <gmaxwell> ... change.
280 2013-01-28 04:50:05 <Luke-Jr> A package involving 69 individual binaries can hardly be called monolithic. <-- this person is arguing semantics; if those 69 binaries only work with each other, it's still monolithic
281 2013-01-28 04:50:48 <CodeShark> no, if they can work independently I disagree
282 2013-01-28 04:51:00 <CodeShark> they are monolithic if they cease to function if you remove any of them
283 2013-01-28 04:51:04 Guest62759 has quit (Read error: Connection reset by peer)
284 2013-01-28 04:51:25 <andytoshi> gmaxwell, i bet i can remove gconf from my system with no ill effect
285 2013-01-28 04:51:50 <andytoshi> whn yum is done stalling i'll let you know
286 2013-01-28 04:52:31 <andytoshi> wth, emacs depends on it
287 2013-01-28 04:52:57 <gmaxwell> HAHAH
288 2013-01-28 04:53:02 <gmaxwell> Exactly
289 2013-01-28 04:53:33 <gmaxwell> Seriously, forget I mentioned it. The rage gconf will induce as you peel back the layers will shorten your life. It's not worth it.
290 2013-01-28 04:54:15 <Luke-Jr> I don't have gconf installed.
291 2013-01-28 04:54:17 <gmaxwell> (also generally, anything touching d-bus, â which I suppose includes systemd, oh well..)
292 2013-01-28 04:54:29 <Luke-Jr> haven't made any particular effort to avoid it (specifically) either
293 2013-01-28 04:54:36 <Diablo-D3> FUCKING SYSTEMD
294 2013-01-28 04:54:39 <Diablo-D3> WHY WONT IT DIE
295 2013-01-28 04:54:46 <gmaxwell> Luke-Jr: Yea, you're not on a distro so afflicted by the particular desktop stupidity that fedora is...
296 2013-01-28 04:54:49 <Diablo-D3> ITS SO GODDAMNED HORRIBLE
297 2013-01-28 04:54:52 <Diablo-D3> JUST KILL IT ALREADY
298 2013-01-28 04:55:09 <Diablo-D3> SYSVINIT IS PARALLEL AND BOOTS FASTER AND HAS LESS DEPENDENCIES
299 2013-01-28 04:55:11 <CodeShark> lol - well, one thing's for certain - everyone seems to have a very strong opinion on this subject
300 2013-01-28 04:55:14 <andytoshi> ah, phonon depends on gconf, and everything depends on phonon
301 2013-01-28 04:55:25 <Diablo-D3> andytoshi: if you're on kde, yes
302 2013-01-28 04:55:29 <Diablo-D3> but who the fuck uses that pile of shit
303 2013-01-28 04:55:37 <CodeShark> lol
304 2013-01-28 04:55:41 <gmaxwell> Diablo-D3: do you yell like this in person?
305 2013-01-28 04:55:53 <andytoshi> Diablo-D3: i don't even have a DE
306 2013-01-28 04:55:54 <Diablo-D3> gmaxwell: its not yelling as much as channeling lewis black
307 2013-01-28 04:55:56 <andytoshi> this is ludicrous
308 2013-01-28 04:56:23 <gmaxwell> andytoshi: I apologize for pointing out the rot behind the walls. :P
309 2013-01-28 04:56:37 <Luke-Jr> andytoshi: I have phonon, but not gconf..
310 2013-01-28 04:56:38 <Diablo-D3> I should make my own fucking linux distro
311 2013-01-28 04:56:48 <gmaxwell> RantOS
312 2013-01-28 04:56:51 <Luke-Jr> lol
313 2013-01-28 04:56:57 <Diablo-D3> it'll boot instantly
314 2013-01-28 04:57:11 <andytoshi> gmaxwell: my gf constantly badgers me about using fedora
315 2013-01-28 04:57:15 <andytoshi> because she uses arch
316 2013-01-28 04:57:20 <Diablo-D3> andytoshi: use debian
317 2013-01-28 04:57:33 <CodeShark> lol - the religious hour has started
318 2013-01-28 04:57:47 <Diablo-D3> I think even an arch hipster would agree debian > fedora
319 2013-01-28 04:58:07 <andytoshi> haha, hipster
320 2013-01-28 04:58:34 <andytoshi> yeah, i should really switch to debian
321 2013-01-28 04:58:38 <andytoshi> as long as i can run systemd ;)
322 2013-01-28 04:58:40 <Diablo-D3> I COMPILE MY OWN DISTRO BECAUSE ITS IRONIC
323 2013-01-28 04:58:41 * Luke-Jr wonders if *anyone* would disagree about Debian > Fedoraâ¦
324 2013-01-28 04:58:51 <weex> nah...nobody.
325 2013-01-28 04:59:02 <Diablo-D3> Luke-Jr: there are people who work for redhat who use debian as their primary distro of choice
326 2013-01-28 04:59:04 <andytoshi> Diablo-D3: well, given how much effort it takes to tear down a big distro to a usable level
327 2013-01-28 04:59:06 <Luke-Jr> andytoshi: Debian doesn't support systemd because of its lack of portability.
328 2013-01-28 04:59:33 <CodeShark> that's pretty ironic :)
329 2013-01-28 05:02:34 HM has quit (Ping timeout: 252 seconds)
330 2013-01-28 05:03:11 <gmaxwell> andytoshi: Everyone I know that has switched to arch eventually stoped using free software and switched to OSX. I suggest you run now, lawyer up, hit the gym, etc.
331 2013-01-28 05:03:29 <Diablo-D3> >hit the gym
332 2013-01-28 05:03:32 <andytoshi> haha
333 2013-01-28 05:03:38 <Diablo-D3> PSSSH, DO YOU EVEN LIFT?!
334 2013-01-28 05:03:53 <Luke-Jr> LOL
335 2013-01-28 05:04:12 <gmaxwell> Luke-Jr: I am not a fan of debian at all. Debian perpetually ships out of date software in stable and makes my life sad. In testing they are frequently broken. The overall system is very very slow to pull in major infrastructure changes (e.g. multiarch)
336 2013-01-28 05:04:20 <Diablo-D3> gmaxwell: no no no no
337 2013-01-28 05:04:21 <Diablo-D3> you fail
338 2013-01-28 05:04:26 <Diablo-D3> stable means unmoving
339 2013-01-28 05:04:28 <Diablo-D3> use sid.
340 2013-01-28 05:04:31 <Diablo-D3> not testing. sid.
341 2013-01-28 05:04:37 <Diablo-D3> dont argue with this wisdom
342 2013-01-28 05:05:06 <Diablo-D3> testing is not meant for end users, its meant for those following internal debian development
343 2013-01-28 05:05:08 <Luke-Jr> gmaxwell: I strongly dislike multiarch. I also often find Debian stable has newer stuff than Gentoo stable.
344 2013-01-28 05:05:10 <gmaxwell> Diablo-D3: Other people use stable on servers. Then they report bugs I fixed twenty years ago. I would do something about this, but apparently it is unlawful to kill all the users.
345 2013-01-28 05:05:20 <Diablo-D3> gmaxwell: because they're retarded
346 2013-01-28 05:05:23 <Diablo-D3> use sid
347 2013-01-28 05:05:31 <Diablo-D3> even on production servers, use sid
348 2013-01-28 05:05:42 <gmaxwell> Luke-Jr: multiarch in fedora is a pleasureâ and in a default system there is no i386 binaries ... but when you want to cross compile its a cinch.
349 2013-01-28 05:05:45 <Luke-Jr> I am happy with Debian stable (soon to be oldstable) on my remote servers.
350 2013-01-28 05:05:48 <Diablo-D3> if they cant read the fucking debian users guide on the fucking debian.org website
351 2013-01-28 05:05:53 <Diablo-D3> theyc an go fuck themselves
352 2013-01-28 05:06:10 <Diablo-D3> stable is for people who work for companies that have criminally broken internal policies
353 2013-01-28 05:06:17 <Diablo-D3> sid is for anyone who actually wants to get work done
354 2013-01-28 05:06:18 <Luke-Jr> gmaxwell: I don't see a point to having more than one arch.
355 2013-01-28 05:06:32 <gmaxwell> Diablo-D3: And yet its very very widely used...
356 2013-01-28 05:06:34 <Diablo-D3> Ive used sid since before it was sid and was potato unstable
357 2013-01-28 05:06:47 <Diablo-D3> gmaxwell: quite a few companies have broken policies
358 2013-01-28 05:07:01 <Diablo-D3> this is why "websites" keep getting "hacked" or whatever the buzzwords this week are
359 2013-01-28 05:07:31 <Diablo-D3> Luke-Jr: multiarch is typically used for ia32 binaries on x86-64
360 2013-01-28 05:07:43 Guest62759 has joined
361 2013-01-28 05:07:47 <Luke-Jr> gmaxwell: I used x86_64 exclusively from almost the day it was available until 2011, and never saw a need for any i386 binaries. Now that I'm back on i386 because I value memory more than CPU time, I don't see a need for x86_64 binaries.
362 2013-01-28 05:07:50 <gmaxwell> In any case, I don't care to argue it. Luke asked if anyone disagreed, I do.
363 2013-01-28 05:07:52 HM has joined
364 2013-01-28 05:07:55 <Diablo-D3> LOL
365 2013-01-28 05:07:59 <Diablo-D3> luke thinks ia32 uses less memory
366 2013-01-28 05:08:17 <gmaxwell> Diablo-D3: it does for some things, esp if you happen to have a major service written in python.
367 2013-01-28 05:08:22 <Diablo-D3> too bad in the average program, pointers take up about 1-2% of the memory used
368 2013-01-28 05:08:59 <gmaxwell> Diablo-D3: And when has anyone said that Luke was average?
369 2013-01-28 05:09:01 <gmaxwell> :P
370 2013-01-28 05:09:03 <Diablo-D3> and you're losing about 35% performance on your average program by running it wrong
371 2013-01-28 05:09:06 <CodeShark> why would you write a major service in python?!
372 2013-01-28 05:09:11 <Diablo-D3> gmaxwell: well, who knows what his bible app does
373 2013-01-28 05:09:16 <Diablo-D3> CodeShark: drugs.
374 2013-01-28 05:09:17 <Luke-Jr> Diablo-D3 must not use C++ or any higher-level languagesâ¦
375 2013-01-28 05:09:18 <gmaxwell> CodeShark: you missed that argument by 24 hours.
376 2013-01-28 05:09:34 <Diablo-D3> Luke-Jr: this is why no one will ever take you seriously as a programmer
377 2013-01-28 05:09:39 <Diablo-D3> you dont know this shit already
378 2013-01-28 05:09:42 mappum has joined
379 2013-01-28 05:09:47 <andytoshi> i got gconf down to 26 dependent packages, so i'm happy
380 2013-01-28 05:09:49 <gmaxwell> Diablo-D3: Please cut the hostility.
381 2013-01-28 05:09:55 <andytoshi> and most of it is kde stuff drawn in by kmplot
382 2013-01-28 05:10:06 <Luke-Jr> Diablo-D3: if I run x86_64, I'm constantly swapping even with 16 GB RAM
383 2013-01-28 05:10:09 <gmaxwell> What is kmplot?
384 2013-01-28 05:10:17 <Luke-Jr> at least i386 keeps me off the swap
385 2013-01-28 05:10:26 <Diablo-D3> Luke-Jr: _lol_
386 2013-01-28 05:10:31 <andytoshi> gmaxwell: it's a simple point-and-click graphing calculator
387 2013-01-28 05:10:34 <Diablo-D3> you think linux doesnt preemptively swap, how cute
388 2013-01-28 05:10:41 <gmaxwell> andytoshi: ah.
389 2013-01-28 05:10:43 <Luke-Jr> that's not the point
390 2013-01-28 05:10:44 <andytoshi> Diablo-D3: i don't even have swap
391 2013-01-28 05:10:54 <Luke-Jr> andytoshi: that's kinda silly
392 2013-01-28 05:10:55 <gmaxwell> Diablo-D3: _constantly_ swapping != preemptive swapping.
393 2013-01-28 05:11:08 <Diablo-D3> gmaxwell: and I doubt hes constantly swapping
394 2013-01-28 05:11:14 <Diablo-D3> either that, or hes running one hell of a leaky program
395 2013-01-28 05:11:16 <andytoshi> it's a bit silly, yeah, but i've only got a 64-gig hdd
396 2013-01-28 05:11:17 <gmaxwell> andytoshi: yea, swap is good. The kernel is competent.
397 2013-01-28 05:11:26 <Diablo-D3> the kernel isnt competent
398 2013-01-28 05:11:28 <Diablo-D3> it really isnt
399 2013-01-28 05:11:39 <gmaxwell> hm.
400 2013-01-28 05:11:44 * gmaxwell tests a hypothesis.
401 2013-01-28 05:11:51 <gmaxwell> Diablo-D3: Diablo-D3 is really smart.
402 2013-01-28 05:11:54 <Luke-Jr> Diablo-D3: KDE's Plasma is pretty leaky.
403 2013-01-28 05:12:07 <Diablo-D3> using low values for swappiness is recommended (but not 0, that breaks shit)
404 2013-01-28 05:12:22 <Luke-Jr> but I also keep about 100 browser windows open with like 5 tabs each on average
405 2013-01-28 05:12:25 <Diablo-D3> gmaxwell: that isnt it, you're saying shit thats already been generally proven wrong
406 2013-01-28 05:12:28 <Luke-Jr> and numerous Kate instances, etc
407 2013-01-28 05:12:40 <Diablo-D3> Luke-Jr: I usually have about 200 tabs open across a dozen windows in firefox
408 2013-01-28 05:12:46 <Diablo-D3> never goes above 2gb usage
409 2013-01-28 05:12:47 <Luke-Jr> [04:54:28] <gmaxwell> Diablo-D3: Diablo-D3 is really smart. <-- already been generally proven wrong
410 2013-01-28 05:12:51 <gmaxwell> Hm. Theory validated. Diablo-D3 actually does disagree with everything.
411 2013-01-28 05:13:04 <Diablo-D3> gmaxwell: I didnt disagree with everything
412 2013-01-28 05:13:08 <gmaxwell> lol
413 2013-01-28 05:13:10 <Diablo-D3> there are things that I do agree with
414 2013-01-28 05:13:11 <Luke-Jr> lol
415 2013-01-28 05:13:29 <Diablo-D3> its just that, atm, you and luke both are saying some pretty stupid shit
416 2013-01-28 05:14:15 brwyatt is now known as brwyatt|Away
417 2013-01-28 05:14:26 <Luke-Jr> Diablo-D3: I suppose everyone behind x32 and merging it (like Linus, the GCC/glibc folks, etc) are idiots too?
418 2013-01-28 05:15:34 <gmaxwell> x32 makes me sad.
419 2013-01-28 05:15:53 <gmaxwell> I'd prefer to just encourage things to fix their insane pointer bloat. :-/
420 2013-01-28 05:16:18 <andytoshi> i like to think all the pointers are making the code cleaner
421 2013-01-28 05:16:19 <Luke-Jr> gmaxwell: I'd rewrite my entire OS given the spare time, but there's only so much people can do :P
422 2013-01-28 05:16:21 <gmaxwell> 4gb address space limits stink, and the resulting scalablity limits stink. ... and having systems with two sets of all libraries stinks.
423 2013-01-28 05:16:22 <andytoshi> maybe it's all in lisp or something
424 2013-01-28 05:16:46 <Luke-Jr> gmaxwell: one set of x32 libraries should be fine; maybe some new PAE-like hacks for VM-type software
425 2013-01-28 05:17:18 RainbowD_ is now known as RainbowDashh
426 2013-01-28 05:17:21 <gmaxwell> As soon as you need even one x86_64 binary for scalablity reasons the duplicate libraries in ram eat most of the memory savings of x32... I'd say it makes sense on phones, except phones are going to start bumping into 4gb address space limits in a few more years (even arm is going 64 bit now).
427 2013-01-28 05:18:13 <gmaxwell> Luke-Jr: I frequently run single tasks that actually need more than 4gb ram. I know my workloads are not common desktop ones, but they're not that crazy.
428 2013-01-28 05:18:21 EasyAt_ has joined
429 2013-01-28 05:18:29 knotwork has joined
430 2013-01-28 05:18:29 knotwork has quit (Changing host)
431 2013-01-28 05:18:29 knotwork has joined
432 2013-01-28 05:18:32 <Luke-Jr> gmaxwell: O.o
433 2013-01-28 05:31:54 <etotheipi_> maybe we should've been more proactive and skipped 64-bit CPU.... jumped right to 256-bit CPU or something
434 2013-01-28 05:32:26 <etotheipi_> we're just delaying another annoying architecture mess
435 2013-01-28 05:32:36 <Luke-Jr> etotheipi_: meh, the CPUs are really like 48-bit anyway
436 2013-01-28 05:32:42 <etotheipi_> and at least then we could do some crypto in "int" types in C++
437 2013-01-28 05:32:53 <mappum> meanwhile, my gpu is 192-bit
438 2013-01-28 05:32:57 JyZyXEL has quit (Ping timeout: 256 seconds)
439 2013-01-28 05:33:25 <Luke-Jr> etotheipi_: I agree wider registers and ops might be nice, but no reason to increase pointers.
440 2013-01-28 05:34:51 <andytoshi> indeed, 48 bits can refer to 28Tb
441 2013-01-28 05:35:04 <andytoshi> but having 256 bits in general-purpose registers would be wonderful
442 2013-01-28 05:36:37 <CodeShark> no increasing pointers? how else will I address my zettabyte RAM?
443 2013-01-28 05:38:46 <gmaxwell> I'd much rather have things like hardware tagging. (e.g. having zero perfomance hit valgrind on everything, did someone mention lisp machines?)
444 2013-01-28 05:39:28 <Luke-Jr> CodeShark: take MMUs to the next step
445 2013-01-28 05:40:19 * Luke-Jr wonders how much performance hit all the PIC stuff has, and why we can't just have compilers output code using non-overlapping memory regions <.<
446 2013-01-28 05:40:52 <gmaxwell> etotheipi_: you don't need 256 bit registers to have a 256 bit int type in C like languages.
447 2013-01-28 05:41:14 <CodeShark> primitive types?
448 2013-01-28 05:41:23 <Luke-Jr> GCC probably has a SSE 256-bit int type hidden somewhere
449 2013-01-28 05:41:27 <gmaxwell> (an, in fact, GCC has a reasonable 128 bit int type)
450 2013-01-28 05:41:34 <gmaxwell> s/an/and/
451 2013-01-28 05:41:48 <gmaxwell> CodeShark: primitive types doesn't mean it has to fit in a single register.
452 2013-01-28 05:42:52 <gmaxwell> And on x86_64 doing arithemetic on 128 bit values is pretty much no different than 64 bit ones (you use the carry flags and do half-word math)... same way nominally 16 bit arches do 32 bit 'long'.
453 2013-01-28 05:43:20 <CodeShark> takes a few more CPU cycles
454 2013-01-28 05:43:59 <gmaxwell> it takes more instructions and has higher latency, doesn't usually harm throughput much.
455 2013-01-28 05:44:01 DamascusVG has quit (Quit: I Quit - http://www.youtube.com/watch?v=9p97zsQ51Rw)
456 2013-01-28 05:44:19 <gmaxwell> (and certantly if it were common the implementation could make it free)
457 2013-01-28 05:45:42 <Luke-Jr> looks like native int256 would need AVX
458 2013-01-28 05:45:59 * Luke-Jr ponders how well an AVX miner would perform
459 2013-01-28 05:47:27 <Luke-Jr> looks like Ufasoft found it infeasable for some reason, oh well
460 2013-01-28 05:49:30 <gmaxwell> Luke-Jr: the first generation of AVX is basically float only.
461 2013-01-28 05:49:46 <gmaxwell> The integer stuff gets added in the next rev which isn't shipping in anything yet, I think.
462 2013-01-28 05:50:15 <gmaxwell> Yea, AVX2 is Haswell.
463 2013-01-28 05:50:21 <Luke-Jr> and float probably lacks bitshift ops I guess
464 2013-01-28 05:52:44 FredEE has quit (Quit: FredEE)
465 2013-01-28 05:53:39 <kjj> does it really have enough width internally?
466 2013-01-28 05:56:15 <gmaxwell> kjj: does what really have enough width?
467 2013-01-28 06:01:08 EasyAt_ is now known as EasyAt
468 2013-01-28 06:01:20 <kjj> does the CPU have enough capacity to do 4096 bits at once, or is the instruction set just a handy wrapper around a multi-cycle series of 64 bit operations?
469 2013-01-28 06:01:33 EasyAt has quit (Changing host)
470 2013-01-28 06:01:33 EasyAt has joined
471 2013-01-28 06:02:31 HM has quit (Ping timeout: 252 seconds)
472 2013-01-28 06:02:59 <gmaxwell> AVX is not 16*256.
473 2013-01-28 06:03:16 <gmaxwell> It's 256 bits wide, with instructions that partition it up in different ways.
474 2013-01-28 06:03:40 <gmaxwell> (well the whole avx register file is 16*256 â actually because of shadowing it's probably substantially larger than that in reality)
475 2013-01-28 06:05:00 Hashdog has joined
476 2013-01-28 06:05:40 <kjj> it isn't so much the storage that I was wondering about, as the ALU
477 2013-01-28 06:07:19 JyZyXEL has joined
478 2013-01-28 06:07:56 HM has joined
479 2013-01-28 06:08:15 <gmaxwell> sandy bridge can actually execute a 256bit (e.g. 8 x single precision) multiply in a single cycle (and IIRC, can also do an non-dependant 8xsingle precision add, and an unrelated load/store at the same time)
480 2013-01-28 06:13:43 dust-otc has joined
481 2013-01-28 06:15:10 HM has quit (Ping timeout: 252 seconds)
482 2013-01-28 06:17:50 HM has joined
483 2013-01-28 06:21:33 <CodeShark> I'm still using penryn microarchitecture CPUs
484 2013-01-28 06:21:46 JZavala has quit (Ping timeout: 252 seconds)
485 2013-01-28 06:23:09 <CodeShark> I'll probably wait for Haswell before upgrading everything
486 2013-01-28 06:28:31 nus- has joined
487 2013-01-28 06:29:22 FredEE has joined
488 2013-01-28 06:29:59 Guest23476 has quit (Changing host)
489 2013-01-28 06:29:59 Guest23476 has joined
490 2013-01-28 06:30:05 Guest23476 is now known as SomeoneWeird
491 2013-01-28 06:30:47 MrTiggr has quit (Ping timeout: 244 seconds)
492 2013-01-28 06:33:00 nus has quit (Ping timeout: 276 seconds)
493 2013-01-28 06:33:32 paybitcoin has quit (Read error: Connection reset by peer)
494 2013-01-28 06:36:42 hahuang65 has quit (Quit: Textual IRC Client: http://www.textualapp.com/)
495 2013-01-28 06:46:05 paybitcoin has joined
496 2013-01-28 07:00:18 <wumpus> <gmaxwell> (an, in fact, GCC has a reasonable 128 bit int type) <- it does (__int128_t), but it only works on 64-bit platforms
497 2013-01-28 07:04:05 <gmaxwell> wumpus: yea, it continues the C tradition of having some kind of long / long long that is one step larger than the largest native type, implemented using the carry flags (so its still fast).
498 2013-01-28 07:04:44 <CodeShark> I really wish C would have made the width explicit in their types from the beginning and would have made unsigned ints the default :)
499 2013-01-28 07:04:57 <CodeShark> you should have to use a signed keyword for signed
500 2013-01-28 07:05:13 HM has quit (Ping timeout: 252 seconds)
501 2013-01-28 07:05:21 <gmaxwell> CodeShark: unsigned is not magically superior. In particular you often get worse performing loops when you use unsigned as an iterator.
502 2013-01-28 07:05:32 <CodeShark> worse performing loops?
503 2013-01-28 07:05:37 <gmaxwell> (though the promotion rules in C kinda suck)
504 2013-01-28 07:05:52 <CodeShark> why would they perform worse as iterators?
505 2013-01-28 07:06:30 <gmaxwell> CodeShark: yea, it's really really common for the compiler to be able to prove that a loop runsâ sayâ 4 times _exactly_ or infinity. Overflow of a signed integer is undefined in C, so the compiler can exclude the infinity case and vectorize or unroll the loop.
506 2013-01-28 07:07:03 <gmaxwell> but if the loop counter is unsigned, no joy. The loop might run until it overflows.
507 2013-01-28 07:07:53 HM has joined
508 2013-01-28 07:08:06 <andytoshi> i wish char had been unsigned by default
509 2013-01-28 07:08:12 <andytoshi> instead of implementation-defined..
510 2013-01-28 07:08:32 <andytoshi> there's no need for a 1-byte counter unless you're deliberately doing overflow tricks
511 2013-01-28 07:09:45 <CodeShark> gmaxwell: give me an example where the compiler could prove that a loop runs either 4 times exactly or infinity
512 2013-01-28 07:10:55 <andytoshi> CodeShark: anytime the iterator might start above 4
513 2013-01-28 07:11:03 <andytoshi> for (i; i < 4; ++i)
514 2013-01-28 07:11:07 <andytoshi> ;)
515 2013-01-28 07:11:15 <CodeShark> oh... :)
516 2013-01-28 07:11:36 <CodeShark> well, if the i is not modified inside the loop, the compiler could prove it always runs 4 times exactly
517 2013-01-28 07:11:41 <CodeShark> never infinity
518 2013-01-28 07:11:57 <andytoshi> if i is not modified, it will definitely run infinity times:P
519 2013-01-28 07:12:10 <CodeShark> it gets modified by the ++i only
520 2013-01-28 07:12:27 <CodeShark> oh, you're saying if it's not even initialized
521 2013-01-28 07:12:46 <andytoshi> for (i = 15; i < 4; ++i) printf ("Running for the %dth time\n", i);
522 2013-01-28 07:13:05 <kjj> C looks like portable assembly, but it isn't. modern CPUs would be worthless without compilers being aggressive with "undefined" behavior
523 2013-01-28 07:13:34 <andytoshi> yeah, that's why C still acts the way it does in 2013
524 2013-01-28 07:13:56 <andytoshi> it's certainly -possible- to do bounds checking and trap on overflow and watch for NULLs
525 2013-01-28 07:14:24 <gmaxwell> CodeShark: or initilized elsewhere, or based off a nonstatic values.. for(i=x;i<x+4;i++)
526 2013-01-28 07:14:54 <CodeShark> who the hell writes for loops that loop around the maximum unsigned value anyhow? lol
527 2013-01-28 07:15:34 <andytoshi> well, suppose you wanted to run 256 times, but you wanted the starting value of something to be variable..
528 2013-01-28 07:15:35 <gmaxwell> CodeShark: I've actually seen code that needed that, don't askâ but regardless, it _must_ not break in that case. unsigned overflow is well defined.
529 2013-01-28 07:15:39 <andytoshi> say, for some sorta duff's device..
530 2013-01-28 07:19:42 <andytoshi> and say, your starting value came from setjmp, and represented a recursion depth
531 2013-01-28 07:19:43 Mad7Scientist has quit (Ping timeout: 255 seconds)
532 2013-01-28 07:19:55 <andytoshi> so that you could do different things depending how fine you'd split a problem up
533 2013-01-28 07:20:02 <andytoshi> i believe that is called "dynamic programming"
534 2013-01-28 07:21:26 <gmaxwell> andytoshi: I ... wouldn't normally describe that as dynamic programmingâ though I suppose some DP algorithims coule be implemented that way.
535 2013-01-28 07:21:36 <andytoshi> hahaha
536 2013-01-28 07:22:14 Guest91877 has quit (Read error: Operation timed out)
537 2013-01-28 07:22:46 <CodeShark> well, compiler optimization aside, it seems unsigned ints are used far more in typical programs than signed ints
538 2013-01-28 07:23:15 <CodeShark> at least ints that are never set to negative values (even if it's a signed type)
539 2013-01-28 07:23:17 <andytoshi> CodeShark: i don't think so
540 2013-01-28 07:23:25 <andytoshi> yeah, that's probably true
541 2013-01-28 07:23:30 <CodeShark> array indices? counters?
542 2013-01-28 07:24:01 <gmaxwell> what, you don't use negative indexes? pshaw.
543 2013-01-28 07:24:02 <andytoshi> but most ints also don't use more than the signed range
544 2013-01-28 07:24:03 <andytoshi> so it's a wash
545 2013-01-28 07:24:26 <CodeShark> but it's an issue when comparing ints
546 2013-01-28 07:24:33 <andytoshi> sometimes i use negative indexes to implement a fixed-size stack, when i'm writing throwaway code
547 2013-01-28 07:24:47 <gmaxwell> and the underflow behavior makes signed values produce more tractable errors too.
548 2013-01-28 07:24:48 <andytoshi> CodeShark: yeah, that's frustrating
549 2013-01-28 07:25:15 <gmaxwell> CodeShark: yea, the promotion rules are annoyingâ but you can solve them by _never_ using unsigned, as a rule.. and lots of people use that rule.
550 2013-01-28 07:25:21 <andytoshi> i kinda wish you could set ranges like in ada
551 2013-01-28 07:25:30 <andytoshi> even if the compiler wouldn't enforce it for you
552 2013-01-28 07:25:54 <gmaxwell> andytoshi: ACSL (http://frama-c.com/acsl.html)
553 2013-01-28 07:26:24 <andytoshi> ooh, exciting!
554 2013-01-28 07:29:15 <CodeShark> as for simple counting loops, it would have been nice for there to be a foreach in range type deal from the beginning :)
555 2013-01-28 07:29:46 <CodeShark> but I guess C took a fairly minimalist approach to language constructs
556 2013-01-28 07:29:51 WolfAlex_ has joined
557 2013-01-28 07:30:35 <andytoshi> gmaxwell, this is so cool
558 2013-01-28 07:30:50 <CodeShark> yeah, it is pretty neat
559 2013-01-28 07:30:52 <andytoshi> i generally use dozens of asserts() everywhere
560 2013-01-28 07:31:57 Mad7Scientist has joined
561 2013-01-28 07:32:21 Mad7Scientist is now known as Guest74768
562 2013-01-28 07:32:43 WolfAlex has quit (Ping timeout: 252 seconds)
563 2013-01-28 07:33:37 <gmaxwell> andytoshi: the prover stuff in frama .. well. it's not as smart as I'd hope. hopefully it gets better... but when I've used it I'd quickly run into cases where no matter how many hard assertions I added I couldn't get it to prove an operation didn't overflow.
564 2013-01-28 07:34:30 Guest74768 is now known as Mad7Scientist_
565 2013-01-28 07:34:59 <andytoshi> well, the next time i've got some academic C code to write, i'll try it out
566 2013-01-28 07:35:20 RazielZ has joined
567 2013-01-28 07:36:16 Guest91877 has joined
568 2013-01-28 07:36:34 FredEE has quit (Quit: FredEE)
569 2013-01-28 07:39:43 CodesInChaos has joined
570 2013-01-28 07:40:07 <gmaxwell> petertodd: you should join #bitcoin
571 2013-01-28 07:51:28 Hashdog has quit (Remote host closed the connection)
572 2013-01-28 07:58:26 Mad7Scientist_ has quit (Ping timeout: 255 seconds)
573 2013-01-28 07:59:26 jdnavarro has joined
574 2013-01-28 08:00:43 osmosis has joined
575 2013-01-28 08:02:59 ovidiusoft has joined
576 2013-01-28 08:05:37 b4epoche has quit (Ping timeout: 240 seconds)
577 2013-01-28 08:05:56 leotreasure has joined
578 2013-01-28 08:08:54 b4epoche has joined
579 2013-01-28 08:11:22 <gmaxwell> petertodd: so I think it's possible (given blockchain rule modifications) to make it so that your blinded bank can't block withdraws back into bitcoin.
580 2013-01-28 08:11:30 Mad7Scientist_ has joined
581 2013-01-28 08:11:37 <SomeoneWeird> can you get the version of bitcoind running with tcp ?
582 2013-01-28 08:11:53 <SomeoneWeird> like echo "version" | nc host port o something ?
583 2013-01-28 08:12:09 <gmaxwell> SomeoneWeird: not that simply.
584 2013-01-28 08:12:33 <SomeoneWeird> handshake or something ?
585 2013-01-28 08:12:45 <gmaxwell> SomeoneWeird: yes.
586 2013-01-28 08:12:54 MrTiggr has joined
587 2013-01-28 08:12:55 <SomeoneWeird> mm
588 2013-01-28 08:13:08 <gmaxwell> petertodd: I have a 1BTC token from your bank. I want to withdraw it. You have issued 1000 1BTC tokens, their bitcoin is all assigned at txout AAAA with some special flags and scriptpubkey.
589 2013-01-28 08:13:19 <SomeoneWeird> and i suppose that isn't simple enough todo via cli ?
590 2013-01-28 08:14:09 <gmaxwell> petertodd: I ask you to exchange my 1 BTC token for a new blinded one. But unknown to you, the new blinded one says inside "can be redeemd from the blockchain". If I later try to get you to swap that after unblinding it, you'll tell me to buzz off.
591 2013-01-28 08:14:31 HM has quit (Ping timeout: 252 seconds)
592 2013-01-28 08:14:35 <gmaxwell> petertodd: Instead I present that unblinded token to the blockchain and it lets me spend 1btc out of the 1000 to an address of my choosing.
593 2013-01-28 08:15:57 <gmaxwell> petertodd: what I'd really like is a secure way to redeem the tokens if the bank goes out of business, but I haven't come up with one of those yet... but at least I got "bank can't block you from getting your coins out of it", which I think sounds like a useful property.
594 2013-01-28 08:16:44 <CodeShark> SomeoneWeird, you can do it via curl -d '{"method":"getinfo","params":[],"id":0}' http://user:pwd@host:port :)
595 2013-01-28 08:16:57 <SomeoneWeird> ah, neat thanks
596 2013-01-28 08:17:07 <gmaxwell> I'd assumed that SomeoneWeird wanted the p2p port.
597 2013-01-28 08:17:24 <SomeoneWeird> well in this case both are open, so it doesn't matter
598 2013-01-28 08:17:36 <gmaxwell> SomeoneWeird: someone has an open RPC port on the internets?
599 2013-01-28 08:17:42 <SomeoneWeird> mhm
600 2013-01-28 08:17:53 HM has joined
601 2013-01-28 08:17:56 * gmaxwell facepalm
602 2013-01-28 08:19:14 <Cryo> this sync is taking forever.. 7000 more blocks to go zzzzzzzzz
603 2013-01-28 08:20:24 <CodeShark> via p2p port, I have a utility that can do that but haven't published it
604 2013-01-28 08:20:48 <gmaxwell> just addnode it and use getpeerinfo. :P
605 2013-01-28 08:21:39 <CodeShark> no, I mean a utility that can do that even if the local host doesn't have bitcoind
606 2013-01-28 08:23:49 <SomeoneWeird> nice
607 2013-01-28 08:26:37 HM has quit (Ping timeout: 252 seconds)
608 2013-01-28 08:26:52 <andytoshi> gmaxwell: will the addnode stuff be pulled?
609 2013-01-28 08:27:27 <andytoshi> i'm suprised that nobody looked at it today..i guess its sunday
610 2013-01-28 08:27:52 HM has joined
611 2013-01-28 08:28:03 <CodeShark> dynamic addnode would be nice to have
612 2013-01-28 08:28:40 <gmaxwell> CodeShark: we have a now tested pull request for it.
613 2013-01-28 08:30:22 <CodeShark> 1549?
614 2013-01-28 08:30:43 <andytoshi> yeah
615 2013-01-28 08:32:02 <gmaxwell> CodeShark: feel free to do your own testing and provide feedback.
616 2013-01-28 08:33:19 mappum has quit (Ping timeout: 246 seconds)
617 2013-01-28 08:34:01 <leotreasure> hello, does anyone know how to connect to mt gox api using the python script?
618 2013-01-28 08:35:00 reizuki__ has quit (Remote host closed the connection)
619 2013-01-28 08:35:22 reizuki__ has joined
620 2013-01-28 08:35:22 reizuki__ has quit (Changing host)
621 2013-01-28 08:35:22 reizuki__ has joined
622 2013-01-28 08:36:31 HM has quit (Ping timeout: 252 seconds)
623 2013-01-28 08:37:52 HM has joined
624 2013-01-28 08:48:46 ThomasV has joined
625 2013-01-28 08:49:21 DamascusVG has joined
626 2013-01-28 08:49:21 DamascusVG has quit (Changing host)
627 2013-01-28 08:49:21 DamascusVG has joined
628 2013-01-28 08:52:59 Dyaheon has quit (Read error: Connection reset by peer)
629 2013-01-28 08:53:10 Dyaheon has joined
630 2013-01-28 08:58:02 fpgaminer has quit ()
631 2013-01-28 08:58:02 HM has quit (Read error: Connection reset by peer)
632 2013-01-28 08:58:16 HM has joined
633 2013-01-28 08:58:41 CodeInChaos has joined
634 2013-01-28 09:00:26 Arch_Coldfire has joined
635 2013-01-28 09:02:56 <gmaxwell> petertodd: so the best I've got for the shutdown case is orderly-but-effortless-shutdown. As the bank operates it maintainsâ potentially in publicâ a merkelized STXO (spent transaction) tree for each issuance containing all the redeemed tokens. (you'd want to do that anyways if the bank is in secure hardware, as it would let you have the expensive storage outside of the stored hardware.
636 2013-01-28 09:03:05 CodesInChaos has quit (Ping timeout: 256 seconds)
637 2013-01-28 09:03:43 <gmaxwell> petertodd: if the bank needs to shut down fast, it makes sure the final STXO state is published, and it makes a final bitcoin transaction to transfer all the funds to a recievership script.
638 2013-01-28 09:04:13 <gmaxwell> petertodd: then any token can be redeemed by putting it in a transaction along with the tree fragments that prove the token is not in the final STXO set.
639 2013-01-28 09:04:23 <gmaxwell> the problem is that the transactions would be really big. :(
640 2013-01-28 09:05:34 yareyare has quit (Quit: brb)
641 2013-01-28 09:07:55 fpgaminer has joined
642 2013-01-28 09:08:20 techlife has quit (Ping timeout: 272 seconds)
643 2013-01-28 09:08:52 t7 has joined
644 2013-01-28 09:13:55 PK has joined
645 2013-01-28 09:13:59 yareyare has joined
646 2013-01-28 09:14:43 techlife has joined
647 2013-01-28 09:14:45 techlife has quit (Max SendQ exceeded)
648 2013-01-28 09:14:46 t7` has joined
649 2013-01-28 09:15:10 techlife has joined
650 2013-01-28 09:15:11 techlife has quit (Max SendQ exceeded)
651 2013-01-28 09:15:43 t7 has quit (Ping timeout: 260 seconds)
652 2013-01-28 09:15:59 techlife has joined
653 2013-01-28 09:16:00 techlife has quit (Max SendQ exceeded)
654 2013-01-28 09:16:48 techlife has joined
655 2013-01-28 09:19:48 dvide has joined
656 2013-01-28 09:29:48 <sipa> jgarzik: what would be needed to convince you to write an autotools based config for bitcoin...?
657 2013-01-28 09:31:43 <CodeShark> I'll do it if that's what everyone wants
658 2013-01-28 09:32:29 <sipa> actually, what i want is anything that is maintained
659 2013-01-28 09:32:54 <sipa> so pushing someone to write a config which is then neglected seems like a vad idea
660 2013-01-28 09:33:30 <sipa> and i have no problem personally with a hand-rolled script, if it allows more platforms than we do now
661 2013-01-28 09:34:17 <sipa> though it should also be used for production builds, otherwise it will too easily lag behind
662 2013-01-28 09:37:43 Ferroh has joined
663 2013-01-28 09:42:00 osmosis has quit (Quit: Leaving)
664 2013-01-28 09:53:18 njbartlett has joined
665 2013-01-28 09:53:43 <njbartlett> Hi, I'm having trouble with the Bitcoin-Qt client synchronizing the blockchain. It's been stuck at block no 210348 for over 24 hours now. Previously it was downloading okay (though slow!). Any ideas what might be wrong?
666 2013-01-28 09:54:42 <sipa> njbartlett: likely database corruption
667 2013-01-28 09:54:48 copumpkin has quit (Ping timeout: 260 seconds)
668 2013-01-28 09:55:19 <njbartlett> sipa: Damn. What does that mean, I have to start downloading the chain all over again?
669 2013-01-28 09:55:33 <sipa> basically, yes
670 2013-01-28 09:55:57 <sipa> if it's any help: 0.8 should be a lot faster and less prone to corruption
671 2013-01-28 09:56:18 copumpkin has joined
672 2013-01-28 09:57:52 <njbartlett> sipa: Thanks. I don't see 0.8 available for download yet... would I need to build from source?
673 2013-01-28 09:58:56 <kinlo> njbartlett: it's not released yet
674 2013-01-28 10:13:19 HM has quit (Ping timeout: 252 seconds)
675 2013-01-28 10:17:55 HM has joined
676 2013-01-28 10:21:27 B0g4r7 has quit (Ping timeout: 276 seconds)
677 2013-01-28 10:21:35 njbartlett_ has joined
678 2013-01-28 10:23:58 njbartlett has quit (Ping timeout: 260 seconds)
679 2013-01-28 10:23:58 njbartlett_ is now known as njbartlett
680 2013-01-28 10:24:29 variousnefarious has quit (Ping timeout: 245 seconds)
681 2013-01-28 10:24:37 variousnefarious has joined
682 2013-01-28 10:26:09 B0g4r7 has joined
683 2013-01-28 10:28:42 one_zero has quit ()
684 2013-01-28 10:32:10 t7` is now known as t7
685 2013-01-28 10:33:05 Acciaio has joined
686 2013-01-28 10:45:30 MrTiggr has quit (Ping timeout: 244 seconds)
687 2013-01-28 10:51:39 testnode9_ has quit (Read error: Connection reset by peer)
688 2013-01-28 10:56:46 reizuki__ has quit (Ping timeout: 252 seconds)
689 2013-01-28 11:05:13 MrTiggr has joined
690 2013-01-28 11:05:14 darkee has quit (!~darkee@gateway/tor-sasl/darkee|Remote host closed the connection)
691 2013-01-28 11:06:56 darkee has joined
692 2013-01-28 11:12:57 njbartlett has quit (Quit: njbartlett)
693 2013-01-28 11:15:18 Joric has joined
694 2013-01-28 11:15:55 testnode9 has joined
695 2013-01-28 11:20:27 altamic has joined
696 2013-01-28 11:26:27 MobiusL has quit (Ping timeout: 276 seconds)
697 2013-01-28 11:38:35 rbecker is now known as RBecker
698 2013-01-28 11:41:18 copumpkin has quit (Ping timeout: 244 seconds)
699 2013-01-28 11:41:44 pooler has joined
700 2013-01-28 11:41:52 copumpkin has joined
701 2013-01-28 11:44:02 drizztbsd has joined
702 2013-01-28 11:45:46 rdymac has joined
703 2013-01-28 11:55:41 RBecker is now known as rbecker
704 2013-01-28 11:56:30 MobiusL has joined
705 2013-01-28 12:04:46 njbartlett has joined
706 2013-01-28 12:12:55 njbartlett has quit (Read error: Connection reset by peer)
707 2013-01-28 12:13:35 njbartlett has joined
708 2013-01-28 12:13:45 njbartlett has quit (Client Quit)
709 2013-01-28 12:21:10 b4epoche has quit (Ping timeout: 246 seconds)
710 2013-01-28 12:23:44 b4epoche has joined
711 2013-01-28 12:28:57 Goonie has joined
712 2013-01-28 12:39:50 <Luke-Jr> TD[gone]`: it's quite trivial in theory to monopolize on miner policy differences to double-spend
713 2013-01-28 12:41:47 porquilho has joined
714 2013-01-28 12:42:03 <porquilho> hello
715 2013-01-28 12:45:07 BTCOxygen has quit (Ping timeout: 252 seconds)
716 2013-01-28 12:45:13 <Mikej0h> hi
717 2013-01-28 12:56:36 Acciaio has quit (Quit: BYE ALL)
718 2013-01-28 13:02:41 agricocb has quit (Quit: Leaving.)
719 2013-01-28 13:04:33 BTCOxygen has joined
720 2013-01-28 13:06:43 yareyare has quit (Quit: .)
721 2013-01-28 13:08:57 paraipan has joined
722 2013-01-28 13:09:17 HM has quit ()
723 2013-01-28 13:15:14 HM has joined
724 2013-01-28 13:43:43 debiantoruser has joined
725 2013-01-28 13:43:50 <debiantoruser> Greetings!
726 2013-01-28 13:44:38 <debiantoruser> Is there easy way to discuss with bitcoind developers bitcoind options ?
727 2013-01-28 13:45:22 xHire has left ("Bye bye!")
728 2013-01-28 13:46:14 <sipa> debiantoruser: just ask your question, people may or may not answer
729 2013-01-28 13:48:20 <debiantoruser> bitcoind getaccountaddress "myaccount"
730 2013-01-28 13:48:30 <debiantoruser> this way, i get New address
731 2013-01-28 13:48:48 andytoshi has quit (Ping timeout: 276 seconds)
732 2013-01-28 13:49:11 <debiantoruser> Like bitcoind getnewaddress "named"
733 2013-01-28 13:49:33 <debiantoruser> But i looking for this options # bitcoind getaddressesbyaccount "named"
734 2013-01-28 13:49:48 <debiantoruser> for listing all of addresses in account
735 2013-01-28 13:50:28 <debiantoruser> There is one option # bitcoind listaccounts
736 2013-01-28 13:50:49 <debiantoruser> It show me all of my accounts, but it doesn't show addresses
737 2013-01-28 13:51:20 <debiantoruser> It would be cool to have one easy, pretty json printed options to see all of accounts with addresses in each
738 2013-01-28 13:52:00 <debiantoruser> And another one cool option - to delete (remove) address from wallet
739 2013-01-28 13:52:15 <debiantoruser> Do you copy?
740 2013-01-28 13:52:16 DutchBrat has quit (Quit: No Ping reply in 180 seconds.)
741 2013-01-28 13:52:33 <sipa> deleting addresses is intentionally not possible - it's way too easy to burn yourself that way
742 2013-01-28 13:52:56 <sipa> as it means losing any transactions that were sent to that address before, which may screw up your balance
743 2013-01-28 13:53:01 DutchBrat has joined
744 2013-01-28 13:53:17 <sipa> hiding an address is something else, which may be useful but isn't implemented
745 2013-01-28 13:53:32 <debiantoruser> rm -fr / - to one of such ways, but it is accessible by user (:
746 2013-01-28 13:54:14 t7 has quit (Read error: Connection reset by peer)
747 2013-01-28 13:54:38 t7 has joined
748 2013-01-28 13:55:26 <debiantoruser> I set new account and import address by private key, when i use option: bitcoind getaccountaddress "this my new account"
749 2013-01-28 13:55:32 <debiantoruser> I get another one address
750 2013-01-28 13:55:43 <debiantoruser> so my wallet with 10 accounts looks like junkyard
751 2013-01-28 13:56:15 <debiantoruser> and i am no so addictive
752 2013-01-28 13:56:26 <sipa> when importing an address, and giving it a label, i don't think it is made the default address of that account
753 2013-01-28 13:56:38 <sipa> so you don't get that address when requesting getaccountaddress
754 2013-01-28 13:57:05 <debiantoruser> why?
755 2013-01-28 13:57:26 <debiantoruser> Am i need to submit ticket?
756 2013-01-28 13:57:41 <sipa> in general, the accounts feature is not very useful
757 2013-01-28 13:57:55 <sipa> and it badly interacts with a lot of other things
758 2013-01-28 13:58:14 <sipa> imho, multi-wallet support (probably coming in 0.9) is much closer to what people exptect accounts to be
759 2013-01-28 13:59:20 <debiantoruser> how far it from nowadayz?
760 2013-01-28 13:59:22 agricocb has joined
761 2013-01-28 13:59:46 <sipa> we don't even have a 0.8 release candidate, so not very soon
762 2013-01-28 14:00:45 <debiantoruser> what a main task for dev command today?
763 2013-01-28 14:00:55 <sipa> ?
764 2013-01-28 14:01:21 <debiantoruser> what do you do?
765 2013-01-28 14:01:34 copumpkin has quit (Ping timeout: 252 seconds)
766 2013-01-28 14:02:10 copumpkin has joined
767 2013-01-28 14:03:47 <sipa> eh, several things :)
768 2013-01-28 14:03:59 <sipa> i'm a core developer, but i haven't worked on wallet-related things for a while
769 2013-01-28 14:04:42 <debiantoruser> Could you please divide fee by ten?
770 2013-01-28 14:04:53 <HM> lol
771 2013-01-28 14:05:30 <sipa> haha
772 2013-01-28 14:05:57 MobiusL has quit (Remote host closed the connection)
773 2013-01-28 14:06:23 <SomeoneWeird> lols
774 2013-01-28 14:08:54 Joric has quit ()
775 2013-01-28 14:09:12 <sipa> debiantoruser: you choose the fee yourself; there is a safety minimal fee if you try large(bytes)/young/spammy transactions, as the network won't relay those without a fee
776 2013-01-28 14:09:44 <sipa> the fee policy is certainly going to change, but it first needs changes in the network
777 2013-01-28 14:14:40 xtest has joined
778 2013-01-28 14:15:13 spenvo has joined
779 2013-01-28 14:19:31 gavinandresen has joined
780 2013-01-28 14:24:05 cdecker_ has quit (Ping timeout: 255 seconds)
781 2013-01-28 14:30:25 DutchBrat_ has joined
782 2013-01-28 14:30:35 <HM> sipa: going to change?
783 2013-01-28 14:30:41 <HM> you mean go up? ;)
784 2013-01-28 14:33:00 DutchBrat has quit (Ping timeout: 276 seconds)
785 2013-01-28 14:42:28 andytoshi has joined
786 2013-01-28 14:44:03 B0g4r7 has quit (Ping timeout: 276 seconds)
787 2013-01-28 14:45:01 Hashdog has joined
788 2013-01-28 14:47:07 daybyter has joined
789 2013-01-28 14:48:16 spenvo has quit (Quit: This computer has gone to sleep)
790 2013-01-28 14:51:55 TD has joined
791 2013-01-28 14:54:11 spenvo has joined
792 2013-01-28 14:54:12 <TD> BlueMatt: poke
793 2013-01-28 14:54:15 <TD> are you there?
794 2013-01-28 14:55:32 <jgarzik> sipa: it would be easy to maintain, once written
795 2013-01-28 14:55:33 Guest62759 is now known as topace
796 2013-01-28 14:55:37 topace has quit (Changing host)
797 2013-01-28 14:55:37 topace has joined
798 2013-01-28 14:55:49 <jgarzik> sipa: autotools configure just annoying to get going the first time
799 2013-01-28 14:55:51 <jgarzik> *is just
800 2013-01-28 14:56:43 <CodeShark> I could use the experience so I volunteer
801 2013-01-28 14:59:07 xtest has quit (Quit: Page closed)
802 2013-01-28 15:00:27 topace has quit (Read error: Connection reset by peer)
803 2013-01-28 15:05:10 topace has joined
804 2013-01-28 15:05:19 topace has quit (Changing host)
805 2013-01-28 15:05:19 topace has joined
806 2013-01-28 15:13:07 <epscy> what is the motivation for changing the fee structure
807 2013-01-28 15:16:04 <BlueMatt> TD: pong
808 2013-01-28 15:19:29 <TD> in FilteredBlockAndMerkelTreeTests the filtered block is still being sent after the transactions, not before
809 2013-01-28 15:19:33 <TD> is that intentional?
810 2013-01-28 15:21:57 <BlueMatt> shouldnt be
811 2013-01-28 15:22:08 <BlueMatt> I know I changed that test like yesterday
812 2013-01-28 15:22:09 <BlueMatt> did I not push?
813 2013-01-28 15:23:10 <TD> http://code.google.com/r/bluemattme-bitcoinj/source/list?name=bloomfilter
814 2013-01-28 15:23:42 <TD> not sure â¦. i guess not
815 2013-01-28 15:23:58 zooko has joined
816 2013-01-28 15:24:01 <TD> i'm merging it in, perhaps i've merged a 2/3 day old version?
817 2013-01-28 15:24:08 <TD> but i think i started yesterday
818 2013-01-28 15:24:30 <BlueMatt> the version on git bloomfilter is right, though the change may have ended up in the wrong commit?
819 2013-01-28 15:25:11 <BlueMatt> seems to be right in 3906aa62d902, where it was added
820 2013-01-28 15:25:25 <BlueMatt> first filteredBlock, then tx0-3 then Pong
821 2013-01-28 15:25:26 <TD> hmm
822 2013-01-28 15:25:31 <TD> ok
823 2013-01-28 15:25:39 <TD> i wish i could see the history of pushes
824 2013-01-28 15:26:04 <BlueMatt> yea...push -f gets kinda messy
825 2013-01-28 15:26:28 <BlueMatt> Im pretty sure the last change I made was just before the bitcoinj ml post asking for reviews
826 2013-01-28 15:26:48 B0g4r7 has joined
827 2013-01-28 15:27:20 <TD> i probably messed up git
828 2013-01-28 15:27:32 <TD> this tool is still one of the sharpest and most dangerous knives i've seen for a while
829 2013-01-28 15:27:40 <BlueMatt> yes
830 2013-01-28 15:27:41 <TD> how do I force my local branch to be identical to your remote branch?
831 2013-01-28 15:27:50 <TD> "git reset --hard bluematt/bloomfilter" didn't do the trick
832 2013-01-28 15:28:08 <BlueMatt> git fetch and git checkout should do it
833 2013-01-28 15:28:16 <BlueMatt> (unless you have local changes, then checkout should complain)
834 2013-01-28 15:28:31 <BlueMatt> hmm...reset should too
835 2013-01-28 15:28:33 <TD> i have an existing branch that i want to make a duplicate of yours
836 2013-01-28 15:28:41 <BlueMatt> yea, that should do it
837 2013-01-28 15:28:59 <BlueMatt> Im not sure, does git log bluematt/bloomfilter show cea95b809d9935406c057905f415731b3e81cdb3 as head?
838 2013-01-28 15:29:24 <TD> $ git log bluematt/bloomfilter|head
839 2013-01-28 15:29:24 <TD> commit 6440237d0037a9e27ac65bdb3fc85ad4ba60fbab
840 2013-01-28 15:29:24 <TD> Author: Matt Corallo <git@bluematt.me>
841 2013-01-28 15:29:24 <TD> Date: Mon Dec 24 17:28:12 2012 -0500
842 2013-01-28 15:29:25 <TD> Add test cases for PMT/FilteredBlock including network download.
843 2013-01-28 15:29:27 <TD> nope
844 2013-01-28 15:29:31 <TD> guess that's the issue
845 2013-01-28 15:29:38 <BlueMatt> umm...yea, so fetch didnt get it right
846 2013-01-28 15:30:04 <BlueMatt> wow, that is really old, that is before the refresh bloom filter every 25k blocks stuff
847 2013-01-28 15:30:09 <BlueMatt> or nFlags
848 2013-01-28 15:31:13 <TD> it must be when i first fetched the branch
849 2013-01-28 15:31:17 <TD> grr.
850 2013-01-28 15:31:20 <BlueMatt> bluematt is the right remote, right?
851 2013-01-28 15:31:56 <BlueMatt> cat .git/config
852 2013-01-28 15:32:11 <TD> hearn-macbookpro:bitcoinj hearn$ git remote show bluematt
853 2013-01-28 15:32:12 <TD> * remote bluematt
854 2013-01-28 15:32:12 <TD> Fetch URL: https://code.google.com/r/bluemattme-bitcoinj/
855 2013-01-28 15:32:12 <TD> Push URL: https://code.google.com/r/bluemattme-bitcoinj/
856 2013-01-28 15:32:33 <TD> [remote "bluematt"]
857 2013-01-28 15:32:33 <TD> url = https://code.google.com/r/bluemattme-bitcoinj/
858 2013-01-28 15:32:33 <TD> fetch = +refs/heads/*:refs/remotes/bluematt/*
859 2013-01-28 15:32:37 <TD> i guess so
860 2013-01-28 15:32:37 <BlueMatt> yea, thats right...
861 2013-01-28 15:32:44 <BlueMatt> wtf google code?
862 2013-01-28 15:32:59 <BlueMatt> wait can you even git show cea95b809d9935406c057905f415731b3e81cdb3?
863 2013-01-28 15:33:55 <TD> yes. i get "refresh filter every 25k blocks"
864 2013-01-28 15:34:04 <BlueMatt> ok, so just reset your branch to that and go from there
865 2013-01-28 15:35:06 <TD> ok
866 2013-01-28 15:35:58 <BlueMatt> you can probably skip the "fix #292" commit until I throw in the second part (the inputIndex+1 fix)
867 2013-01-28 15:36:07 <BlueMatt> unless you want to get murexcon... to sign the cla
868 2013-01-28 15:36:41 <TD> if you could do it, that'd be convenient for me
869 2013-01-28 15:36:43 <TD> or i'll do it
870 2013-01-28 15:36:45 <TD> it seemed easy
871 2013-01-28 15:36:55 andytoshi has quit (Quit: WeeChat 0.3.9.2)
872 2013-01-28 15:36:56 <TD> actually i can just do it
873 2013-01-28 15:36:58 <TD> that seems fastest
874 2013-01-28 15:36:58 <BlueMatt> yea, I just wanted to read through the code and make sure its all wrong before I add the +1
875 2013-01-28 15:37:10 <TD> ok if you want to do extra stuff, no problem
876 2013-01-28 15:37:16 <BlueMatt> but feel free, Im sure Ill read through it before 0.7 gets released
877 2013-01-28 15:37:35 <BlueMatt> I just want to read through bitcoind side-by-side to make sure its +1 in all cases
878 2013-01-28 15:39:54 <TD> ok. it might be easier to understand the if the SigType mangling is done a bit differently, like with an accessor that maps the byte value to the right enum value
879 2013-01-28 15:40:42 <BlueMatt> well I figured it would work fine the way it was done, as you have to use the original byte value when doing the checkSig whether you map it to an enum or not
880 2013-01-28 15:40:58 spenvo has quit (Quit: This computer has gone to sleep)
881 2013-01-28 15:41:15 <TD> why? because of round-trip serialization?
882 2013-01-28 15:41:53 <jgarzik> CodeShark: I'd be happy to supply any and all info you need for an autotools task
883 2013-01-28 15:42:07 <jgarzik> CodeShark: I'm an expert at this point (note: that's not something to brag about :))
884 2013-01-28 15:42:13 <CodeShark> thank you, much appreciated.
885 2013-01-28 15:42:46 <CodeShark> I'm doing a little research - if I have any questions, I'll bug you :)
886 2013-01-28 15:44:13 tonikt has joined
887 2013-01-28 15:45:09 EPiSKiNG- has quit ()
888 2013-01-28 15:45:33 <BlueMatt> when doing the checkSig, you sign the (hash of the txn+sigType byte) not just the hash
889 2013-01-28 15:45:33 <BlueMatt> and you have to use the original byte value not the "real" value
890 2013-01-28 15:45:33 <BlueMatt> TD: yea, the +1 is obviously right...somehow I missed that subList is inclusive on the first parameter, exclusive on the second
891 2013-01-28 15:45:34 <BlueMatt> TD: feel free to just add it
892 2013-01-28 15:45:45 <TD> ok
893 2013-01-28 15:46:18 <BlueMatt> TD: anyway, re: test-cases, I know the script tests include at least one of each opcode except for sig checking, I was just apparently not paying attention and the the sig checking stuff went largely untested for non-SIGHASH_ALL
894 2013-01-28 15:46:28 <TD> maybe it's simpler to just scrap the enum then.
895 2013-01-28 15:46:38 <TD> or maybe it's still better API. i need to look at that code again.
896 2013-01-28 15:46:41 <TD> ok
897 2013-01-28 15:46:42 <BlueMatt> may be, but it makes it way better for API
898 2013-01-28 15:46:56 <BlueMatt> and the way it is thats all its used for
899 2013-01-28 15:47:44 <TD> i guess so
900 2013-01-28 15:48:26 <jgarzik> CodeShark: This is a useful template to start with: https://github.com/jgarzik/picocoin/blob/master/configure.ac
901 2013-01-28 15:48:51 <jgarzik> CodeShark: see also autogen.sh, and *.am from https://github.com/jgarzik/picocoin/
902 2013-01-28 15:48:57 <CodeShark> ok, thanks
903 2013-01-28 15:54:00 <CodeShark> jgarzik: I added that AM_INIT_AUTOMAKE line to my configure.ac and automake keeps giving me "configure.ac: no proper invocation of AM_INIT_AUTOMAKE was found."
904 2013-01-28 15:54:39 <jgarzik> CodeShark: take picocoin's configure.ac and modify it to suit. order is important, for each macro line.
905 2013-01-28 15:54:55 <jgarzik> CodeShark: don't start from scratch. take a working one, and delete the unneeded bits near the bottom.
906 2013-01-28 15:55:22 <jgarzik> CodeShark: I have never run into that error :) Also, make sure you are using autogen.sh, not running it manually.
907 2013-01-28 15:55:23 daybyter has quit (Quit: Konversation terminated!)
908 2013-01-28 15:55:41 <CodeShark> hmmm, but I want to understand what everything is
909 2013-01-28 15:55:57 <jgarzik> CodeShark: the order is -very- important for the first several lines
910 2013-01-28 15:56:26 <jgarzik> CodeShark: that will take forever ;-)
911 2013-01-28 15:56:41 <CodeShark> nah...
912 2013-01-28 15:56:51 <CodeShark> it's not conceptually difficult - just tedious
913 2013-01-28 15:58:49 sgornick has joined
914 2013-01-28 15:59:05 <jgarzik> nod -- tedious for hysterical raisins, as you'll find out :)
915 2013-01-28 16:00:06 <jgarzik> some macros just break, if in the wrong order. and some macros had to be placed, and executed, early in configure.ac for automake-implementation-related reasons, not anything related to your own code.
916 2013-01-28 16:00:15 <CodeShark> I just had to run autoreconf, apparently
917 2013-01-28 16:00:18 <CodeShark> now that error is gone
918 2013-01-28 16:01:07 <CodeShark> ok, excellent - automake gave no errors now :)
919 2013-01-28 16:05:44 <Cryo> is it really supposed to take over 2 days for the block sync when bitcoin-qt hasn't been run in a couple months?
920 2013-01-28 16:05:58 <Cryo> or is my connection to the irc server going via pluto
921 2013-01-28 16:07:09 <jgarzik> Cryo: version 0.7.x I presume? it is possible, yes :( you can try closing the program and restarting, to find a new network peer.
922 2013-01-28 16:07:16 <jgarzik> Cryo: is your hard drive running 100%?
923 2013-01-28 16:07:56 <Cryo> hmm, yes it is. I thought that was supposed to be fixed a while back
924 2013-01-28 16:08:18 <Cryo> not 100% bandwidth of it, just doing constant read/write
925 2013-01-28 16:11:41 <jgarzik> Cryo: if the hard drive is running 100% of the time, it is probably not sitting around waiting for the network :/
926 2013-01-28 16:12:05 <jgarzik> Cryo: You can try a pre-0.8 release, which is much much faster: https://bitcointalk.org/index.php?topic=129861.0
927 2013-01-28 16:19:37 <Cryo> nope, sipa only has winux builds
928 2013-01-28 16:20:23 <Cryo> I'll create a ramdisk and try that
929 2013-01-28 16:20:30 <sipa> Cryo: using truecrypt, perhaps?
930 2013-01-28 16:20:52 <Cryo> nope, just regular HFS+ journaled
931 2013-01-28 16:21:46 <Cryo> it's just been a while since I fired up to test :)
932 2013-01-28 16:22:40 <Cryo> ok, maybe no ramdisk on THIS machine
933 2013-01-28 16:22:42 <Cryo> 10.0M ./database
934 2013-01-28 16:22:42 <Cryo> 5.8G .
935 2013-01-28 16:22:59 <Cryo> these dat files are hugemongous
936 2013-01-28 16:23:08 <SomeoneWeird> that they are
937 2013-01-28 16:29:09 <muhoo> 5G is normal now, it seems
938 2013-01-28 16:30:19 <muhoo> what's the status of pruning? coming in 0.8?
939 2013-01-28 16:30:41 <Luke-Jr> muhoo: not a real priority, afaik
940 2013-01-28 16:30:44 <Luke-Jr> probably not in 0.8
941 2013-01-28 16:31:08 <Luke-Jr> but probably not hard to add yourself, if you're looking for something to code :p
942 2013-01-28 16:33:26 drizztbsd has quit (Quit: Konversation terminated!)
943 2013-01-28 16:34:21 <sipa> not in 0.8, indeed
944 2013-01-28 16:34:37 <sipa> we first need a mechanism for clients to distinguish between pruned servers and non-pruned ones
945 2013-01-28 16:34:52 <sipa> as they'd try to do IBD from pruned ones otherwise
946 2013-01-28 16:35:27 <sipa> this requires adding a network bit, and rolling out clients that know about it
947 2013-01-28 16:35:35 <sipa> when that is done, we can start having pruned servers :)
948 2013-01-28 16:35:46 <sturles> How about half-pruned servers? I'l like to keep the last 2 GiB of blockchain, and prune the first on a very fast server due to disk qouta (university alumni account).
949 2013-01-28 16:35:51 B0g4r7 has quit (Ping timeout: 276 seconds)
950 2013-01-28 16:36:03 zooko has quit (Remote host closed the connection)
951 2013-01-28 16:36:10 b4epoche has quit (Ping timeout: 245 seconds)
952 2013-01-28 16:36:16 <sipa> sturles: same problem
953 2013-01-28 16:36:22 <gmaxwell> sturles: thats even harder stillâ but if we don't do that there is significant risk that lots of people will turn on pruning and make it impossible to initilize a full node.
954 2013-01-28 16:36:36 DutchBrat has joined
955 2013-01-28 16:36:56 <sturles> I will keep full nodes, but my full nodes will have slower connections.
956 2013-01-28 16:37:54 agricocb has quit (Ping timeout: 260 seconds)
957 2013-01-28 16:38:28 grau has joined
958 2013-01-28 16:38:35 b4epoche has joined
959 2013-01-28 16:38:38 <gmaxwell> sturles: the 'last' 2GiB is not what you'd wantâ for safty and security the system will force keeping some of the very latest in any case.. otherwise a reorg kills you.
960 2013-01-28 16:39:02 drizztbsd has joined
961 2013-01-28 16:39:06 DutchBrat_ has quit (Ping timeout: 276 seconds)
962 2013-01-28 16:39:14 <gmaxwell> sturles: what you'd want to do is also keep some random segment before the last so that even if many nodes are pruned the full chain would still be highly available.
963 2013-01-28 16:39:27 <gavinandresen> sipa: I'm working on issue 2201 (Catch LevelDB I/O errors), and thinking that throwing an exception, at least in the Read()/Exists() routines, is not the right thing to do. Read and Write already return bools for success/failure...
964 2013-01-28 16:39:52 <gmaxwell> (I misunderstood you at first)... but then that requires communicating which segmnts nodes have.
965 2013-01-28 16:40:02 <sipa> gavinandresen: seen #2224 ?
966 2013-01-28 16:40:14 <sipa> gavinandresen: that already catches write errors
967 2013-01-28 16:41:57 DutchBrat_ has joined
968 2013-01-28 16:42:08 <muhoo> gmaxwell: interesting. almost bittorrent-like?
969 2013-01-28 16:42:45 <gmaxwell> muhoo: uh. very superficially.
970 2013-01-28 16:43:01 <sipa> gavinandresen: only problem is how to convey a failed read
971 2013-01-28 16:43:08 <sipa> api-wise
972 2013-01-28 16:43:18 <gavinandresen> sipa: I think just return false from Read() is sufficient
973 2013-01-28 16:43:29 <sipa> no, that means NotFound
974 2013-01-28 16:43:43 <sturles> gmaxwell: True. Some bittorrent-like system where the entire file is collcted from bits from random nodes.
975 2013-01-28 16:43:44 <sipa> well, it can be changed to mean something else
976 2013-01-28 16:43:56 <gavinandresen> false from Exists means not found....
977 2013-01-28 16:44:18 <gavinandresen> (unless i'm misunderstanding, which is always possible)
978 2013-01-28 16:44:18 DutchBrat has quit (Ping timeout: 276 seconds)
979 2013-01-28 16:44:29 <sipa> gavinandresen: from Read as well, and in most cases, you don't do Exists + Read if you're going to read the data anyway
980 2013-01-28 16:44:34 <gavinandresen> I'm working from the outside in-- randomly corrupting leveldb files and seeing what happens
981 2013-01-28 16:44:53 <sipa> plus, that's just moving the problem to Exists, as that also has no way to distinguish between failed read an not found
982 2013-01-28 16:45:13 <gmaxwell> Then you end up rejecting blocks when they don't validate, and get that problem I ran into on out of space.
983 2013-01-28 16:45:25 <gmaxwell> (where the node never recovers)
984 2013-01-28 16:45:34 <sipa> please, see #2224
985 2013-01-28 16:46:15 <gavinandresen> sipa: ok, I'll test 2224. Is that intended to be pulled before the 0.8rc1 ?
986 2013-01-28 16:46:24 <sipa> gavinandresen: i'd like that, yes
987 2013-01-28 16:46:38 <sipa> i feel the current code is too fragile
988 2013-01-28 16:46:54 RainbowDashh has quit (Remote host closed the connection)
989 2013-01-28 16:48:02 <sipa> gavinandresen: imho the easiest solution is defining an exception in leveldb.h or txdb.h, and throwing that on read or write error
990 2013-01-28 16:48:19 <sipa> but that would certainly need testing
991 2013-01-28 16:48:44 <sipa> without an exception, you need a way to pass "failed read" through the CCoins interface
992 2013-01-28 16:48:49 <CodeShark> I totally concur, sipa :)
993 2013-01-28 16:49:10 <CodeShark> no point in having to deal with these errors at every single level of the stack
994 2013-01-28 16:49:19 <gavinandresen> sipa: simply throwing a runtime_error gives bad behavior (core dump with uncaught exception in Init)
995 2013-01-28 16:49:26 <CodeShark> it needs to be caught
996 2013-01-28 16:49:32 <gavinandresen> okey dokey
997 2013-01-28 16:49:33 <sipa> it needs to be caught in main
998 2013-01-28 16:51:21 <gavinandresen> Well, current behavior seems to be correct; I get "Error: Corrupted block database detected. Please restart the client with -reindex." A throw/catch at the very top level would give a less useful message
999 2013-01-28 16:51:40 <sipa> gavinandresen: not the same thing
1000 2013-01-28 16:51:55 <sipa> what you're seeing is an application-level consistency check failing
1001 2013-01-28 16:51:55 <gavinandresen> not the same thing asâ¦. what?
1002 2013-01-28 16:52:12 <sipa> of course you hope that those cause any problems with the chain data if they exist at startup
1003 2013-01-28 16:52:47 <sipa> but that has nothing to do with correctly dealing with leveldb i/o errors
1004 2013-01-28 16:52:55 <sipa> it's another layer of defense
1005 2013-01-28 16:53:48 <sipa> it's just stupid to throw away information that exists at the leveldb level
1006 2013-01-28 16:53:49 <sipa> it'
1007 2013-01-28 16:54:11 <sipa> it can perfectly detect "hey dude, i can't give you any useful data, as what i'm seeing on disk is bullshit"
1008 2013-01-28 16:54:23 <sipa> and we're like "nevermind, just give us something and we'll see what happens"
1009 2013-01-28 16:54:47 <gavinandresen> ok, let me pop a level and ask directly: what needs to change to get 0.8rc1 out the door
1010 2013-01-28 16:54:47 <gavinandresen> ?
1011 2013-01-28 16:55:14 <gavinandresen> ⦠and how can I help?
1012 2013-01-28 16:55:27 <sipa> i'd like to have #2224 + some interface that reports failed read/writes upwards
1013 2013-01-28 16:55:47 bitnumus has joined
1014 2013-01-28 16:55:52 <sipa> i'll code something this evening, ok?
1015 2013-01-28 16:56:06 <gavinandresen> ok, so Read()/Exists()/Write() either throw exceptions, and everyplace that calls them catches, or they return something other than a bool?
1016 2013-01-28 16:56:12 <sipa> exactly
1017 2013-01-28 16:56:12 <gmaxwell> I'm currently casually testing 2061.patch 2221.patch 2224.patch 2229.patch on a node here, fwiw.
1018 2013-01-28 16:56:58 <CodeShark> well, you only need to catch them at some point on the stack
1019 2013-01-28 16:57:01 bitafterbit has joined
1020 2013-01-28 16:57:08 <gavinandresen> sipa: let me know how I can help, we need to get a 0.8rc out soon
1021 2013-01-28 16:57:10 <CodeShark> not necessarily at the point where Read/Exists/Write are called
1022 2013-01-28 16:57:15 <sipa> CodeShark: sure
1023 2013-01-28 16:57:58 <CodeShark> catching them at the top level might be good enough if you intend to immediately shutdown
1024 2013-01-28 16:58:39 <sipa> well, #2224 adds a mechanism to report "runtime error during validation, try to shutdown cleanly"
1025 2013-01-28 16:59:15 <CodeShark> right - cleanup must be performed where appropriate
1026 2013-01-28 16:59:24 <Luke-Jr> #1583 seems trivial enough for 0.8, but also no big deal if it's missed
1027 2013-01-28 16:59:47 <gmaxwell> Hm. Why would I get three add addresses from in my log from the same node right next to each other?
1028 2013-01-28 16:59:51 da2ce7 has joined
1029 2013-01-28 17:00:01 <HM> oO
1030 2013-01-28 17:00:17 <sipa> gmaxwell: maybe it sent 3 addr messages?
1031 2013-01-28 17:00:27 <sipa> getaddr may result in several addr's
1032 2013-01-28 17:00:31 agricocb has joined
1033 2013-01-28 17:00:44 <Luke-Jr> sipa: did #2042 end up fixed by something else?
1034 2013-01-28 17:00:58 <sipa> no
1035 2013-01-28 17:01:53 Hasimir is now known as Hasimir`
1036 2013-01-28 17:01:56 <sipa> Luke-Jr: i'm ok with the first commit in that pullreq, by the way
1037 2013-01-28 17:02:11 <Luke-Jr> yeah, that's probably the more important part
1038 2013-01-28 17:02:12 Hasimir` is now known as Hasimir
1039 2013-01-28 17:02:30 da2ce7_d has quit (Ping timeout: 276 seconds)
1040 2013-01-28 17:02:32 <Luke-Jr> the next commit almost certainly needs a rebase on top of the other problmes
1041 2013-01-28 17:03:33 <gmaxwell> sipa: duh, yea. thats it. Just looked a bit odd.
1042 2013-01-28 17:05:48 <Luke-Jr> sipa: actually⦠looking at this commit again, it looks like it always truncates files not opened read-only? :/
1043 2013-01-28 17:05:58 <Luke-Jr> either I wasn't thinking when I made it, or I'm not now..
1044 2013-01-28 17:06:55 <sipa> Luke-Jr: i can't remember precisely, but i do remember that you convinced me the current code is very wrong
1045 2013-01-28 17:07:15 <Luke-Jr> doesn't help if the new code is more wrong >_<
1046 2013-01-28 17:14:24 t7 has quit (Quit: Leaving)
1047 2013-01-28 17:15:00 <MC1984> 52 connections 224mb ram uptime about a week
1048 2013-01-28 17:15:04 <MC1984> thats good right?
1049 2013-01-28 17:15:37 <HM> my bitcoind has 60 and is using about a gig
1050 2013-01-28 17:15:54 <HM> so yeah
1051 2013-01-28 17:16:02 <MC1984> what build you got
1052 2013-01-28 17:16:19 <HM> 0.7.2 debian
1053 2013-01-28 17:17:20 <MC1984> im using pre 0.8 builds
1054 2013-01-28 17:18:19 <HM> well debian stable isn't a great system to develop on if you want bleeding edge things
1055 2013-01-28 17:18:40 <HM> and i don't want to run unstable on a VPS
1056 2013-01-28 17:19:15 <gmaxwell> What reduced the memory usage recently?
1057 2013-01-28 17:19:15 <MC1984> wit didnt they just manage to get the debian guys to update the package from 0.4 or something lol
1058 2013-01-28 17:19:53 <HM> it was 0.7.2 hit a week or so ago
1059 2013-01-28 17:20:07 <HM> well for amd64, i noticed it was available for other platforms first :|, even Itanium
1060 2013-01-28 17:20:31 pooler has quit (Remote host closed the connection)
1061 2013-01-28 17:21:00 altamic has quit (Quit: altamic)
1062 2013-01-28 17:21:06 <MC1984> who the hell is doing builds for itanium?
1063 2013-01-28 17:21:20 <epscy> is there a sparc build too?
1064 2013-01-28 17:22:03 <MC1984> someone roll a dec alpha
1065 2013-01-28 17:22:31 <MC1984> actually an arm build might be a good idea
1066 2013-01-28 17:23:22 <HM> well a lot of intel64 abis are taken from itanium
1067 2013-01-28 17:23:34 <HM> compiling code for itanium that works on amd64 doesn't seem difficult
1068 2013-01-28 17:23:37 <Cryo> heh, <derp> running on ramdisk doesn't kill my machine</derp>
1069 2013-01-28 17:23:43 agricocb has quit (Remote host closed the connection)
1070 2013-01-28 17:23:59 <Cryo> I have an alpha and multiple ARMs
1071 2013-01-28 17:24:36 zooko has joined
1072 2013-01-28 17:25:25 <gmaxwell> HM: wtf. the itanium machine code looks nothing like amd64!
1073 2013-01-28 17:25:38 <gmaxwell> (I have an itanium system, fwiw)
1074 2013-01-28 17:25:54 <MC1984> um i thught itanium was a completely different chip
1075 2013-01-28 17:25:56 andytoshi has joined
1076 2013-01-28 17:27:28 <Cryo> umm "yes"?
1077 2013-01-28 17:27:37 copumpkin has quit (Ping timeout: 240 seconds)
1078 2013-01-28 17:27:45 <HM> i never said the machine code or memory model was remotely the same
1079 2013-01-28 17:27:49 <Cryo> from the depth of hell the itanic comes to steal your opcodes
1080 2013-01-28 17:28:12 copumpkin has joined
1081 2013-01-28 17:32:38 kicek has quit (Ping timeout: 256 seconds)
1082 2013-01-28 17:33:26 zooko has left ("#tahoe-lafs")
1083 2013-01-28 17:40:38 andytoshi is now known as andytoshi-away
1084 2013-01-28 17:43:20 rdymac has quit (Quit: This computer has gone to sleep)
1085 2013-01-28 17:43:43 agricocb has joined
1086 2013-01-28 17:43:48 rdymac has joined
1087 2013-01-28 17:45:18 kicek has joined
1088 2013-01-28 17:46:21 <Mikej0h> guys, is there a way to get some statistics out of the bitcoind (under Linux) daemon (while running)?
1089 2013-01-28 17:47:46 <kjj> other than what you get with getinfo, getpeerinfo and getmininginfo?
1090 2013-01-28 17:48:26 <Mikej0h> perhaps some SNMP integration or whatsoever?
1091 2013-01-28 17:48:35 <CodeShark> what kind of statistics are you looking for?
1092 2013-01-28 17:48:38 <kjj> JSON RPC API
1093 2013-01-28 17:48:52 <Mikej0h> cuz I love graphs :)
1094 2013-01-28 17:48:59 devrandom has joined
1095 2013-01-28 17:49:05 <kjj> there is no SNMP support, but you could write a wrapper easily enough
1096 2013-01-28 17:49:17 porquilho has quit (Read error: Connection reset by peer)
1097 2013-01-28 17:49:32 <Mikej0h> around the JSON API?
1098 2013-01-28 17:49:36 porquilho has joined
1099 2013-01-28 17:50:26 voodster has joined
1100 2013-01-28 17:50:26 <kjj> yes, that would let you integrate all of the exposed info into your SNMP system
1101 2013-01-28 17:50:52 <kjj> if you want more, you'll have to write (or hire) a SNMP patch, and I doubt it would ever get pulled into the main line
1102 2013-01-28 17:51:06 <CodeShark> bitcoind only has two interfaces - RPC and CLI
1103 2013-01-28 17:51:19 <CodeShark> and the third interface is qt
1104 2013-01-28 17:51:25 <kjj> and the CLI is just a wrapper for RPC
1105 2013-01-28 17:51:28 <CodeShark> right
1106 2013-01-28 17:53:31 <Mikej0h> is there some documentation around for the CLI?
1107 2013-01-28 17:53:50 <CodeShark> bitcoind --help :p
1108 2013-01-28 17:53:57 <CodeShark> and bitcoind help
1109 2013-01-28 17:54:34 <Mikej0h> I understand that; but with some background information, SDK-alike
1110 2013-01-28 17:54:34 <CodeShark> https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list
1111 2013-01-28 17:55:06 <kjj> --help will get you the startup options, which are not what you want
1112 2013-01-28 17:55:30 <Mikej0h> CodeShark; that looks like what I'm looking for, thanks
1113 2013-01-28 17:55:36 <CodeShark> yw
1114 2013-01-28 17:57:53 agricocb has quit (Remote host closed the connection)
1115 2013-01-28 17:58:36 BTCOxygen has quit (Ping timeout: 256 seconds)
1116 2013-01-28 17:58:56 rdymac has quit (Quit: Saliendo)
1117 2013-01-28 17:59:58 BTCOxygen has joined
1118 2013-01-28 18:00:38 rdymac has joined
1119 2013-01-28 18:03:03 <ThomasV> if a transaction in memorypool becomes a double spend, because a conflicting tx made it in a block, does bitcoind removes it?
1120 2013-01-28 18:03:20 <sipa> ThomasV: git head does, previous versions wouldn' ty
1121 2013-01-28 18:03:29 <ThomasV> since when?
1122 2013-01-28 18:03:49 <ThomasV> slush: ^
1123 2013-01-28 18:03:52 <sipa> one or two months
1124 2013-01-28 18:04:11 <ThomasV> I see. do you happen to remember which commit?
1125 2013-01-28 18:04:28 <slush> ThomasV: so update will solve it?
1126 2013-01-28 18:04:52 <ThomasV> slush: probably.. would be good to know if you are running a version older than that
1127 2013-01-28 18:04:53 <sipa> https://github.com/bitcoin/bitcoin/pull/2033
1128 2013-01-28 18:05:28 <sipa> merge november 30
1129 2013-01-28 18:05:44 <slush> ThomasV: yes, I have older version
1130 2013-01-28 18:05:51 <ThomasV> https://github.com/bitcoin/bitcoin/commit/cd7fb7d1deece9da15d7750b3e05f729555a2cbe
1131 2013-01-28 18:05:58 <ThomasV> cool
1132 2013-01-28 18:06:09 <slush> ThomasV: Should I update? Or you still want to test on this older version?
1133 2013-01-28 18:06:09 <ThomasV> well, I reasonably assume that was the reason
1134 2013-01-28 18:06:21 <ThomasV> no, let's update
1135 2013-01-28 18:06:43 <CodeShark> now if only wallet transactions were removed as well :p
1136 2013-01-28 18:07:26 <sipa> s/removed/deactivated/
1137 2013-01-28 18:07:42 <sipa> CodeShark: i actually had a patch over a year ago that did that :)
1138 2013-01-28 18:07:50 <CodeShark> and what happened?
1139 2013-01-28 18:07:53 <sipa> but it never got integrated with GUI/RPC
1140 2013-01-28 18:08:04 <CodeShark> could it keep track of all dependencies?
1141 2013-01-28 18:08:14 <sipa> no, only inside a wallet
1142 2013-01-28 18:08:24 <sipa> anyway, i know of better solutions now
1143 2013-01-28 18:08:38 <CodeShark> so if A -> B -> C, C is in the wallet, A gets double-spent...
1144 2013-01-28 18:08:48 <sipa> yes, bad luck
1145 2013-01-28 18:09:33 <sipa> although you can do things like assuming a transaction is rejected by the network if it doesn't confirm within X time
1146 2013-01-28 18:10:03 <CodeShark> I like gmaxwell's idea of negative confirmation counts
1147 2013-01-28 18:10:30 <sipa> i can't remember who came up with it, but indeed :)
1148 2013-01-28 18:10:44 <CodeShark> well, gmaxwell was the one who brought it up to me
1149 2013-01-28 18:10:57 <CodeShark> dunno who actually came up with it and I suppose it doesn't really matter :)
1150 2013-01-28 18:10:57 <gmaxwell> I think that wasnt from me.
1151 2013-01-28 18:11:00 <ThomasV> when does it get negative? when the tx has been there for too long?
1152 2013-01-28 18:11:26 <gmaxwell> ThomasV: no, the negative ness is the height of the first conflict.. "How big of an attack do I need to recover this txn" :P
1153 2013-01-28 18:11:29 <sipa> ThomasV: when a transaction depends on an output that is conflicted by a transaction N deep in the chain, it has -N confirmations
1154 2013-01-28 18:11:30 <CodeShark> the negative confirmations would represent the number of blocks that would have to be pulled off the chain before the conflicting transaction is removed
1155 2013-01-28 18:11:41 <ThomasV> ok
1156 2013-01-28 18:11:44 <gmaxwell> So positive confirms tell you how sure you are that a txn is good, negative tell you how sure you are that its bad. :P
1157 2013-01-28 18:12:09 <gmaxwell> But actually computing it is a pain because of dependencies.
1158 2013-01-28 18:13:30 <ThomasV> actually, I had always been assuming sipa/kickconflicts to be the default behaviour
1159 2013-01-28 18:13:46 <sipa> me too :D
1160 2013-01-28 18:13:50 <gmaxwell> Likewise.
1161 2013-01-28 18:13:56 <ThomasV> are there security implications when doing this, versus not?
1162 2013-01-28 18:14:04 <sipa> none that i know of
1163 2013-01-28 18:14:11 <slush> ThomasV: ok, bitcoind updated
1164 2013-01-28 18:14:15 <kuzetsa> sipa / gmaxwell: the negative confirmations thing is an excellent idea. a few different "software as a service / web wallets" have problems with how they shuffle things around before sending of funds.
1165 2013-01-28 18:14:17 <gmaxwell> It's opens up dos attacks to not do it.
1166 2013-01-28 18:14:30 <ThomasV> slush: nice. actually, my server too is old and need an update
1167 2013-01-28 18:14:46 <sipa> ThomasV: we saw mempools grow steadily because of chains of conflicts
1168 2013-01-28 18:14:57 <CodeShark> satoshi dice attacks? :)
1169 2013-01-28 18:15:12 <gmaxwell> ThomasV: all versions of bitcoin have had that bogus behavior. But I guess your old software didn't care about the mempool?
1170 2013-01-28 18:15:32 <kuzetsa> CodeShark: some of the online wallets offer a "zero taint / mixing service" which shuffles bitcoin around before ultimately sending.
1171 2013-01-28 18:15:43 <gmaxwell> Personally I really liked the bug that would let invalid transactions get into the memory pool. That one was great.
1172 2013-01-28 18:16:01 <ThomasV> gmaxwell: yes it did. but I was blaming my code not bitcoind
1173 2013-01-28 18:16:31 <kuzetsa> I was helping someone troubleshoot lack of confirmations the other day, and noticed that their "send" from a web-wallet was attempting a transaction which was spending a zero-confirmation input
1174 2013-01-28 18:16:40 FredEE has joined
1175 2013-01-28 18:16:46 <ThomasV> gmaxwell: also, abe-based servers worked differently
1176 2013-01-28 18:16:46 <sipa> kuzetsa: coinbase?
1177 2013-01-28 18:16:57 <kuzetsa> sipa: might've been blockchain.info
1178 2013-01-28 18:17:06 <CodeShark> "taint" sounds more like ben's language :)
1179 2013-01-28 18:17:11 <sipa> ThomasV: did you see the -txindex merged in git head?
1180 2013-01-28 18:17:12 <kuzetsa> ... I could pull it up in IRC logs if you really want to know
1181 2013-01-28 18:17:20 <kuzetsa> actually, I'm curious, so I will look it up
1182 2013-01-28 18:17:28 bitcoinbulletin has quit (Remote host closed the connection)
1183 2013-01-28 18:17:30 <CodeShark> sounds very blockchain.info-ish
1184 2013-01-28 18:17:30 <gmaxwell> sipa: where is the address index pull?
1185 2013-01-28 18:17:38 bitcoinbulletin has joined
1186 2013-01-28 18:17:43 <sipa> gmaxwell: never made it into a pull - i didn't like it enough yet
1187 2013-01-28 18:18:02 <sipa> afk
1188 2013-01-28 18:25:02 rdymac has quit (Ping timeout: 252 seconds)
1189 2013-01-28 18:25:26 <kuzetsa> hmm
1190 2013-01-28 18:25:34 <kuzetsa> grepping logs is hard sometimes :(
1191 2013-01-28 18:26:13 rdymac has joined
1192 2013-01-28 18:26:25 daybyter has joined
1193 2013-01-28 18:27:17 <CodeShark> I wouldn't think that blockchain.info would have problems with discovering negative confirmations though, given that it's got that entire database that's nicely indexed
1194 2013-01-28 18:27:35 <HM> how are they indexing it?
1195 2013-01-28 18:27:35 drizztbsd has quit (Read error: Connection reset by peer)
1196 2013-01-28 18:27:44 <CodeShark> it's just a MySQL database :p
1197 2013-01-28 18:28:00 <HM> PAH
1198 2013-01-28 18:28:02 <CodeShark> lol
1199 2013-01-28 18:28:07 <HM> Filth
1200 2013-01-28 18:28:12 <kjj> you got something against MySQL?
1201 2013-01-28 18:28:52 <kjj> if so, just remember that like 95% of all websites are totally reliant on it
1202 2013-01-28 18:31:31 sgornick has quit (Quit: Ex-Chat)
1203 2013-01-28 18:31:46 spenvo has joined
1204 2013-01-28 18:32:08 BTCOxygen has quit (Ping timeout: 255 seconds)
1205 2013-01-28 18:32:42 <lianj> where does bfgminer write its config?
1206 2013-01-28 18:32:53 <kjj> ~/.bfgminer/bfgminer.conf
1207 2013-01-28 18:33:22 <lianj> hm, nope. at least not here
1208 2013-01-28 18:33:35 <kjj> did you write it already? it doesn't autocreate
1209 2013-01-28 18:34:00 <lianj> no, didnt write it, but i remembered the pools
1210 2013-01-28 18:34:28 <lianj> just wanted to switch to another pool but if i press 'p' i still see the old pool in there too
1211 2013-01-28 18:34:29 <kjj> after you start it and configure it to your liking, go into settings, and then write.
1212 2013-01-28 18:35:00 <kjj> it has several schedulers, and you can enable/disable individual pools
1213 2013-01-28 18:35:20 <lianj> but how does it remember the last pool? thats kinda strange
1214 2013-01-28 18:36:34 <kjj> so, you closed it, looked for the file, didn't find it, started it again, and the pool is still there?
1215 2013-01-28 18:36:42 <lianj> ha, looks like it load .cgminder/cgminder.conf too
1216 2013-01-28 18:37:03 <kjj> ahh, ok
1217 2013-01-28 18:44:35 andytoshi-away is now known as andytoshi
1218 2013-01-28 18:49:27 <gmaxwell> ;;bc,blocks
1219 2013-01-28 18:49:29 <gribble> 212178
1220 2013-01-28 18:49:36 <gmaxwell> :-/
1221 2013-01-28 18:49:50 <gmaxwell> nanotube: where is it getting that from?
1222 2013-01-28 18:50:28 BTCOxygen has joined
1223 2013-01-28 18:50:41 <CodeShark> lol
1224 2013-01-28 18:51:26 <CodeShark> gribble thinks we're still in december
1225 2013-01-28 18:51:52 <kuzetsa> CodeShark / sipa / gmaxwell: Sorry it took so long. The conversation took place in a very active channel over the course of like 4 hours ---> http://pastebin.com/Zi8PRNWr (re: negative confirmations might help / someone's web-wallet acted up)
1226 2013-01-28 18:52:21 <kuzetsa> I grep'd the hell out of it and added multiple ((...snip...)) where there was random chatter and whatnot.
1227 2013-01-28 18:53:33 WolfAlex has joined
1228 2013-01-28 18:54:24 WolfAlex_ has quit (Ping timeout: 260 seconds)
1229 2013-01-28 18:55:28 TD has quit (Quit: TD)
1230 2013-01-28 18:56:33 asa1024 has quit (Quit: asa1024)
1231 2013-01-28 18:57:47 <gmaxwell> kuzetsa: Negative counts wouldn't help that caseâ as they'd be counting the height since it became impossible to confirm the transaction.. What you want is a time until confirmation... which is really hard to reason about.
1232 2013-01-28 18:57:49 <CodeShark> both of the transactions mentioned there are apparently confirmed - so how is that relevant to our earlier discussion?
1233 2013-01-28 18:59:22 <CodeShark> I suppose you could track back to the dependency that's holding up the chain
1234 2013-01-28 18:59:32 <CodeShark> like what happened with that coinbase transaction a couple days ago
1235 2013-01-28 18:59:44 <CodeShark> but that's not negative confs
1236 2013-01-28 19:00:09 <CodeShark> if miners had more rational logic in their prioritizing algorithms, it might be easier to estimate confirmation time
1237 2013-01-28 19:01:10 <CodeShark> using similar algorithms to what is required for the negative conf thing
1238 2013-01-28 19:02:21 <CodeShark> the big difference is that with negative confs, you're talking about a conflicting transaction already in the chain - whereas with long confirmation times, you're talking about dependencies that are not conflicted but are low priority
1239 2013-01-28 19:02:39 <gmaxwell> CodeShark: kuzetsa isn't talking aboue dependencies.
1240 2013-01-28 19:02:55 <gmaxwell> kuzetsa: is talking about a feeless transation below min priority.
1241 2013-01-28 19:03:11 BurtyBB has quit (Read error: Connection reset by peer)
1242 2013-01-28 19:03:20 BurtyB has joined
1243 2013-01-28 19:03:29 <CodeShark> then yeah, that's a separate issue
1244 2013-01-28 19:04:47 dust-otc has quit (Remote host closed the connection)
1245 2013-01-28 19:06:14 agricocb has joined
1246 2013-01-28 19:06:21 Internet13 has quit (Quit: Leaving)
1247 2013-01-28 19:07:49 bitnumus has quit (Quit: Leaving)
1248 2013-01-28 19:09:32 bitnumus has joined
1249 2013-01-28 19:10:58 Grishnakh has quit (Read error: Operation timed out)
1250 2013-01-28 19:13:17 mappum has joined
1251 2013-01-28 19:15:22 Internet13 has joined
1252 2013-01-28 19:16:04 <jgarzik> CodeShark: how goes the hacking/
1253 2013-01-28 19:16:04 <jgarzik> ?
1254 2013-01-28 19:16:25 <SomeoneWeird> i can hear the black helicopters, they're coming for you
1255 2013-01-28 19:16:54 <CodeShark> jgarzik: I got all the way to a makefile...but still having issues with libraries
1256 2013-01-28 19:17:21 <jgarzik> CodeShark: you mean finding/linking/including dependent libs?
1257 2013-01-28 19:17:29 <CodeShark> linking
1258 2013-01-28 19:17:40 ThomasV has quit (Quit: Leaving)
1259 2013-01-28 19:18:21 <jgarzik> CodeShark: for boost and bdb, I would copy recipes from the following url into $topsrc/m4: http://www.gnu.org/software/autoconf-archive/The-Macros.html#The-Macros
1260 2013-01-28 19:19:00 emryss has quit (Ping timeout: 252 seconds)
1261 2013-01-28 19:19:06 <jgarzik> CodeShark: then add to your bitcoind_LDADD $(BOOST_FILESYSTEM_LIB)
1262 2013-01-28 19:19:18 <jgarzik> etc. as needed
1263 2013-01-28 19:19:36 moore has joined
1264 2013-01-28 19:19:44 <jgarzik> CodeShark: bitcoind_LDADD += $(DB_CXX_LIBS)
1265 2013-01-28 19:19:56 <CodeShark> in Makefile.am?
1266 2013-01-28 19:19:56 <jgarzik> when using the AX_BERKELEY_DB_CXX macro
1267 2013-01-28 19:20:01 <jgarzik> CodeShark: correct
1268 2013-01-28 19:20:19 <jgarzik> CodeShark: Makefile.am contains a line like: bin_PROGRAMS = bitcoind
1269 2013-01-28 19:20:26 <CodeShark> yes it does
1270 2013-01-28 19:20:28 <jgarzik> CodeShark: then following lines look like "bitcoind_BLAHBLAH"
1271 2013-01-28 19:20:38 <CodeShark> bitcoind_SOURCES
1272 2013-01-28 19:20:52 rng29a has joined
1273 2013-01-28 19:20:53 rng29a has quit (Changing host)
1274 2013-01-28 19:20:53 rng29a has joined
1275 2013-01-28 19:20:53 <moore> gmaxwell: you around to talk about dup r values? In the block chain seems that more than one one of us is doing work on it...
1276 2013-01-28 19:20:54 <jgarzik> CodeShark: in this case: bitcoind_LDADD = $(each) $(separate) $(lib) $(from) $(AC_SUBST...)
1277 2013-01-28 19:21:37 <kuzetsa> CodeInChaos: the time between the actual transaction(s) being submitted, and then both getting confirmed was several hours. I'm really not sure if the serializer / history trace whatever fancy pant swords in the reference bitcoin's source can show it...
1278 2013-01-28 19:21:55 Arch_Coldfire has quit (Quit: Arch Linux)
1279 2013-01-28 19:21:59 <kuzetsa> but blockchain.info's logs show how long it took from submitting the transaction(s) to actually being confirmed
1280 2013-01-28 19:22:01 <jgarzik> CodeShark: for CFLAGS, I put those in a top-level INCLUDES rule at the top. But I'm told there is a better way now, something like: bitcoind_CFLAGS = blahblah
1281 2013-01-28 19:22:14 <kuzetsa> any case, my thought about negative transactions, like...
1282 2013-01-28 19:22:18 <CodeShark> I was trying stuff like this: bitcoind_CPPFLAGS=-I./leveldb/include -I./leveldb/helpers
1283 2013-01-28 19:22:21 <kuzetsa> err negative confirmation count rather
1284 2013-01-28 19:22:26 <CodeShark> but there should be a cleaner way
1285 2013-01-28 19:22:36 <jgarzik> CodeShark: not necessarily
1286 2013-01-28 19:22:52 <jgarzik> CodeShark: but at least you would want -I$(top_srcdir)/foo/bar
1287 2013-01-28 19:22:57 <kuzetsa> wouldn't spending an input which wasn't yet in the blockchain show up as negative confirmation count? in that case, it was a zero conf respend by the web-wallet service in question
1288 2013-01-28 19:23:12 <jgarzik> CodeShark: $top_srcdir use enables builddir != srcdir and some cross compilation stuff later
1289 2013-01-28 19:23:13 <CodeShark> right, what's the top_srcdir symbol?
1290 2013-01-28 19:23:27 <CodeShark> is there a special constant defined for it somewhere?
1291 2013-01-28 19:23:42 <jgarzik> CodeShark: configure automatically defines it for you
1292 2013-01-28 19:23:55 <CodeShark> so I can just use $(top_srcdir) literally?
1293 2013-01-28 19:24:16 <jgarzik> CodeShark: it is the top-level source directory as set in AC_CONFIG_SRCDIR
1294 2013-01-28 19:24:19 <jgarzik> CodeShark: yes, literally
1295 2013-01-28 19:24:37 <CodeShark> I was also trying stuff like bitcoind_LDFLAGS=-lboost_system -lboost_filesystem -lboost_program_options -lboost_thread -ldb -lssl -lcrypto
1296 2013-01-28 19:24:40 <CodeShark> but that was a dismal failure
1297 2013-01-28 19:24:45 <CodeShark> apparently didn't help at all
1298 2013-01-28 19:24:53 occulta has joined
1299 2013-01-28 19:24:55 <kuzetsa> the reason I linked that log / my idea was that simply showing a confirmation count as "negative" wouldn't actively make things faster, but it would help people who use and/or develop web-wallets realize what is happening and why
1300 2013-01-28 19:25:08 <jgarzik> picocoin_LDADD = libnode.a ../lib/libccoin.a \
1301 2013-01-28 19:25:08 <jgarzik> @GLIB_LIBS@ @CRYPTO_LIBS@ @EVENT_LIBS@ @JANSSON_LIBS@
1302 2013-01-28 19:25:33 <jgarzik> CodeShark: that example illustrates a single binary, with some local libs and some libs pulled in from 'configure'
1303 2013-01-28 19:26:10 <jgarzik> CodeShark: ../lib/libccoin.a is a built object (obviously), so no $top_srcdir
1304 2013-01-28 19:26:36 <jgarzik> CodeShark: and make sure to include your headers in your myprogram_SOURCES list
1305 2013-01-28 19:27:49 jdnavarro has quit (Remote host closed the connection)
1306 2013-01-28 19:28:05 <sipa> moore: i have a branch that finds all reused k values in the block chain during sync
1307 2013-01-28 19:28:51 <CodeShark> jgarzik: so I also need to put macros into configure.ac so it tests the libraries, right?
1308 2013-01-28 19:29:13 <CodeShark> I see you have AC_CHECK_LIB
1309 2013-01-28 19:29:46 <CodeShark> then you have AC_SUBST
1310 2013-01-28 19:30:21 icebattle has joined
1311 2013-01-28 19:31:26 Mad7Scientist_ has quit (Ping timeout: 255 seconds)
1312 2013-01-28 19:32:34 D34TH has joined
1313 2013-01-28 19:33:25 <jgarzik> CodeShark: yep. you test for them in configure.ac, and set a variable via AC_SUBST
1314 2013-01-28 19:33:33 <jgarzik> CodeShark: then that var appears in Makefile.am for @VAR@
1315 2013-01-28 19:34:55 <jgarzik> CodeShark: But really, don't reinvent the wheel when it comes to boost, BDB etc. macros. You'll wind up running into and fixing the same problems others already have. It is easier just to add "AX_BOOST_FILESYSTEM" to configure.ac and use BOOST_FILESYSTEM_LIB in Makefile.am
1316 2013-01-28 19:35:15 <jgarzik> AC_CHECK_LIB is reserved for the easiest cases. I guess openssl qualifies.
1317 2013-01-28 19:35:26 emryss has joined
1318 2013-01-28 19:36:11 debiantoruser has quit (Ping timeout: 245 seconds)
1319 2013-01-28 19:36:12 <moore> sipa: ya I have that code to and analysis/graph viz of the addresses
1320 2013-01-28 19:37:15 <moore> but it looks like the only week keys being used had all the outputs spent after gmaxwell posted the link to a page of reused r's
1321 2013-01-28 19:37:34 swappermall_ has joined
1322 2013-01-28 19:37:47 Grishnakh has joined
1323 2013-01-28 19:38:15 <moore> did you find the owner of the keys or did some one just see that work and seal the bitcoin?
1324 2013-01-28 19:38:29 andytoshi has quit (Quit: WeeChat 0.3.9.2)
1325 2013-01-28 19:38:37 <sipa> moore: most were caused by bitcoincard people with a non-complete test setup
1326 2013-01-28 19:38:50 <moore> ah
1327 2013-01-28 19:39:03 <sipa> they all used k=0
1328 2013-01-28 19:39:04 <jgarzik> tcatm: bitcoinwatch.com has some glitchy numbers (zero)
1329 2013-01-28 19:39:09 <moore> how did you work out where they came from...
1330 2013-01-28 19:39:12 <moore> ah
1331 2013-01-28 19:39:34 MobiusL has joined
1332 2013-01-28 19:40:34 Silverion has joined
1333 2013-01-28 19:40:49 <sipa> about the the naming of the data directories: anyone have a suggestion? i'm currently proposing $DATADIR/blocks (for blk* and rev*), $DATADIR/blocks/index/ (for blktree database) and $DATADIR/chaindata/ (for coins database)
1334 2013-01-28 19:42:06 <CodeShark> coins database is only utxo?
1335 2013-01-28 19:42:10 <sipa> reason to put blktree underneath blocks: to make it intuitively clear they are tied together
1336 2013-01-28 19:42:49 <sipa> reason to not put coins underneath it: it is in practice unrelated (except it the top block hash it refers to must be present in the block index)
1337 2013-01-28 19:43:06 <sipa> yes, UTXOs + current best block hash
1338 2013-01-28 19:43:09 <sipa> that's it
1339 2013-01-28 19:43:15 <CodeShark> then I'm not sure I'd call it chaindata
1340 2013-01-28 19:43:29 <CodeShark> I might just call it utxo :)
1341 2013-01-28 19:43:33 Mad7Scientist_ has joined
1342 2013-01-28 19:43:44 <sipa> reason to not call it coins: makes people thing it's related to their wallet
1343 2013-01-28 19:44:11 <sipa> utxo is obscure (which is not a problem), but if they find out it means unspent outputs, they may still think it's about wallets
1344 2013-01-28 19:44:14 emryss has quit (Ping timeout: 252 seconds)
1345 2013-01-28 19:44:18 <gavinandresen> I vote for utxo
1346 2013-01-28 19:44:29 <gavinandresen> (but I don't really care)
1347 2013-01-28 19:44:48 <sipa> i like gmaxwell's suggestion to put 'chain' in the name, even though it does not literally contains any chain
1348 2013-01-28 19:44:57 <CodeShark> if they go through the effort of researching what utxo stands for, they probably know it doesn't mean their wallet
1349 2013-01-28 19:45:09 <sipa> but it is data derived from the current chain
1350 2013-01-28 19:45:12 <gavinandresen> ok, chainutxo
1351 2013-01-28 19:45:19 <CodeShark> chainutxo is ok
1352 2013-01-28 19:45:26 <CodeShark> but chaindata...data is too generic
1353 2013-01-28 19:45:43 bitnumus has quit (Read error: No route to host)
1354 2013-01-28 19:45:54 <gavinandresen> we should just call it "Bruce"
1355 2013-01-28 19:45:54 <CodeShark> it could get people to think it's the same kind of data as you'd find on blockchain.info
1356 2013-01-28 19:45:59 bitnumus has joined
1357 2013-01-28 19:46:01 <CodeShark> lol @ gavinandresen
1358 2013-01-28 19:46:05 <sipa> haha
1359 2013-01-28 19:46:28 <CodeShark> blockbruce :p
1360 2013-01-28 19:46:50 <CodeShark> let's call it kfiodmwd02lf2mskda
1361 2013-01-28 19:47:03 <sipa> gavinandresen: yesterday we ended up suggestion to create a poll for it, and let people send coins to related addresses to vote
1362 2013-01-28 19:47:24 <gavinandresen> sipa: way too much bike-shed-paintingâ¦.. just pick something and go for it
1363 2013-01-28 19:47:24 <sipa> problem is we may end up calling it Bruce indeed, in that case :p
1364 2013-01-28 19:47:31 <sipa> gavinandresen: that was a joke of course
1365 2013-01-28 19:47:37 <CodeShark> blockutxo has my vote
1366 2013-01-28 19:47:40 <sipa> i don't like utxo :(
1367 2013-01-28 19:48:00 <gavinandresen> ok, I change my vote to "chaindata" then
1368 2013-01-28 19:48:14 <sipa> it requires reading into how the system works internally to know what the data is about
1369 2013-01-28 19:48:33 <CodeShark> I stick with block{something not generic} - if not utxo, something else but not data
1370 2013-01-28 19:48:43 <sipa> suggestions welcome :p
1371 2013-01-28 19:48:58 <gavinandresen> chainspent
1372 2013-01-28 19:49:06 <CodeShark> chainunspent?
1373 2013-01-28 19:49:10 <sipa> 21:24:56 < gmaxwell> chaintip chainbest chainhead chainsum chaincheck chainagg chainvalid all sound okay to me (note the theme?)
1374 2013-01-28 19:49:17 debiantoruser has joined
1375 2013-01-28 19:49:17 <CodeShark> chainsaw :p
1376 2013-01-28 19:49:39 <CodeShark> chainsmoke
1377 2013-01-28 19:50:51 <gavinandresen> chainactive "transaction outputs that are still active"
1378 2013-01-28 19:51:10 <sipa> i already decided which data is stored in it, i shouldn't be punished by also deciding how it's called :'( (though i'll still complain loudly if i don't like someone else's decision of course)
1379 2013-01-28 19:51:44 CodeInChaos is now known as CodesInChaos
1380 2013-01-28 19:51:50 <sipa> chainstate?
1381 2013-01-28 19:51:55 <weex> if there's no chain in it, adding chain to it would seem to be misleading
1382 2013-01-28 19:52:09 <gavinandresen> chain state is pretty good
1383 2013-01-28 19:52:14 <sipa> chainstate doesn't imply it contains a chain
1384 2013-01-28 19:52:47 <CodeShark> hmmm...state is a little too generic for my taste :)
1385 2013-01-28 19:53:27 <CodeShark> activecoins
1386 2013-01-28 19:53:46 <gavinandresen> active coins sounds like a wallet thing again
1387 2013-01-28 19:53:58 <CodeShark> livecoins
1388 2013-01-28 19:54:11 <sipa> i want to avoid coins, it almost directly links to wallet
1389 2013-01-28 19:54:12 <gavinandresen> ⦠anything coins will sound like a wallet thing
1390 2013-01-28 19:54:18 <CodeShark> doesn't just refer to the user's wallet - it refers to the entire network
1391 2013-01-28 19:54:25 <CodeShark> as in all the network's coins
1392 2013-01-28 19:54:28 <sipa> i _know_ what it refers to :p
1393 2013-01-28 19:54:33 <sipa> but users don't
1394 2013-01-28 19:54:40 <CodeShark> existingcoins
1395 2013-01-28 19:55:02 <CodeShark> extantcoins
1396 2013-01-28 19:55:03 <gavinandresen> I like chainstate
1397 2013-01-28 19:55:05 <weex> it's kind of like a front, or stock, or a surface
1398 2013-01-28 19:55:22 <HM> Nihilistcoins
1399 2013-01-28 19:55:29 <CodeShark> chainstate could mean anything, really - as chaindata
1400 2013-01-28 19:55:36 <sipa> but that's it
1401 2013-01-28 19:55:39 <gavinandresen> I like chaindata, too
1402 2013-01-28 19:55:47 <sipa> it literally contains all information relating to the current state of the chain
1403 2013-01-28 19:55:49 <CodeShark> I might easily come to think that it stores the same kind of stuff I see on blockchain.info
1404 2013-01-28 19:55:49 <HM> what're you naming?
1405 2013-01-28 19:55:58 <CodeShark> if I didn't know better
1406 2013-01-28 19:56:05 <sipa> HM: a directory name :)
1407 2013-01-28 19:56:27 <HM> crap/beta/old/crap/junk/crap/version8
1408 2013-01-28 19:56:34 <sipa> haha
1409 2013-01-28 19:56:41 <sipa> $DATADIR/junk
1410 2013-01-28 19:56:48 <CodeShark> something that suggests all existing coins on the entire network and not just the user's wallet's coins...but compacted into 8-10 characters
1411 2013-01-28 19:57:01 <HM> globalcoin
1412 2013-01-28 19:57:09 <weex> coinsupply
1413 2013-01-28 19:57:24 <jgarzik> chaindata
1414 2013-01-28 19:57:26 <sipa> CodeShark: no, that is not what i want, because it implies people understand how it works
1415 2013-01-28 19:57:29 <jgarzik> or just chain
1416 2013-01-28 19:57:38 <jgarzik> KISS
1417 2013-01-28 19:57:53 <CodeShark> sipa, if you're concerned about people who shouldn't be tampering with it tampering with it, give it some really obscure name
1418 2013-01-28 19:58:00 <HM> "That's why I need a name that's cutting-edge, like CutCo, EdgeCom, Interslice."
1419 2013-01-28 19:58:14 <CodeShark> what about dontmesswithem
1420 2013-01-28 19:58:14 <sipa> i don't want people to need to know that bitcoin works by maintaining a set of unspent transaction outputs, to understand that that data is a) not related to the wallet b) related to the blockchain c) valuable
1421 2013-01-28 19:58:37 <CodeShark> the data dir shouldn't even be accessible to the user, then
1422 2013-01-28 19:58:42 <jgarzik> top level dirs: public (the chain), private
1423 2013-01-28 19:58:48 * jgarzik is only 1/2 joking there
1424 2013-01-28 19:58:59 <gavinandresen> CodeShark: the data dir isn't meant to be accessible to the user
1425 2013-01-28 19:59:09 <sipa> but people access it anyway
1426 2013-01-28 19:59:09 <CodeShark> I definitely am in favor of keeping the wallet completely separate from the rest of the datadir
1427 2013-01-28 19:59:15 <jgarzik> "data", "wallet"
1428 2013-01-28 19:59:17 <sipa> CodeShark: yes, different discussion
1429 2013-01-28 19:59:22 <HM> call it "dragons"
1430 2013-01-28 19:59:28 <sipa> not helping
1431 2013-01-28 19:59:40 <CodeShark> and if the two are kept separate, there's less of a chance that users will come to think that the datadir stores their coins
1432 2013-01-28 19:59:54 <HM> "cache"
1433 2013-01-28 20:00:12 <sipa> cache is actually not too inaccurate, as it can be rebuilt easily
1434 2013-01-28 20:00:19 <sipa> but "easily" may still mean hours :)
1435 2013-01-28 20:00:32 <gavinandresen> $DATADIR/blocks, $DATADIR/blocks/index, â¦. how about $DATADIR/blocks/chain
1436 2013-01-28 20:00:42 <HM> just stick a readme in the data dir, with a brief explaination of each directory
1437 2013-01-28 20:00:44 <weex> temp
1438 2013-01-28 20:00:49 <CodeShark> yes to the first two, gavin - nay on the third :)
1439 2013-01-28 20:00:51 <sipa> gavinandresen: inside blocks...?
1440 2013-01-28 20:01:13 <gavinandresen> sure, inside blocks/, why not? the utxo depends on the blocksâ¦.
1441 2013-01-28 20:01:18 <sipa> no, it doesn't
1442 2013-01-28 20:01:27 <sipa> that's the entire reason why it's a separate directory
1443 2013-01-28 20:01:36 <sipa> s/directory/database/
1444 2013-01-28 20:01:53 <sipa> blockchain/blocks, blockchain/blocks/index, blockchain/chaindata, ... ok
1445 2013-01-28 20:02:16 <sipa> but the blocktree is directly linked to the blocks - you should always copy/move them together
1446 2013-01-28 20:02:22 <CodeShark> I vote no on chaindata...but I don't want to spend all day arguing this :p
1447 2013-01-28 20:02:22 <sipa> that's not true for the chain data
1448 2013-01-28 20:03:12 * sipa makes it: blocks/, blocks/index/, chainstate/
1449 2013-01-28 20:03:12 <sipa> nah
1450 2013-01-28 20:03:16 <CodeShark> blockchain/active, perhaps
1451 2013-01-28 20:03:20 <CodeShark> or blockchain/live
1452 2013-01-28 20:03:53 <gavinandresen> Can I change my mind and we just keep it the way it is? We're spending WAY too much time thinking about this, it really doesn't matter
1453 2013-01-28 20:04:07 <sipa> no
1454 2013-01-28 20:04:13 lumberjak has quit (Read error: Connection reset by peer)
1455 2013-01-28 20:04:19 <sipa> we've already spent WAY too much time on it for that :p
1456 2013-01-28 20:04:20 lumberjak has joined
1457 2013-01-28 20:05:05 <gavinandresen> "sunk costs"
1458 2013-01-28 20:05:35 <sipa> well, i have now something that i consider better that what we already have
1459 2013-01-28 20:05:45 <CodeShark> wespentwaytoomuchtimearguingthisname/fileN.dat
1460 2013-01-28 20:05:47 <gavinandresen> good, do that.
1461 2013-01-28 20:07:09 sgornick has joined
1462 2013-01-28 20:07:20 rdymac has quit (Quit: This computer has gone to sleep)
1463 2013-01-28 20:09:35 <nanotube> gmaxwell: bbe and if not available, b.i
1464 2013-01-28 20:09:45 <nanotube> (or the other way around .... don't recall :) )
1465 2013-01-28 20:10:20 debiantoruser has quit (Ping timeout: 245 seconds)
1466 2013-01-28 20:11:43 daybyter has quit (Quit: Konversation terminated!)
1467 2013-01-28 20:15:27 techlife has quit (Ping timeout: 252 seconds)
1468 2013-01-28 20:16:26 <CodeShark> anyhow, I'll just make one last comment with regards to naming - I believe datadir names should be helpful primarily to developers, not to typical endusers. if an enduser doesn't understand what the files actually are, he/she has no business being in there in the first place
1469 2013-01-28 20:17:09 <sipa> CodeShark: but end users _will_ be messing with it
1470 2013-01-28 20:17:17 <sipa> even if they have no business in doing so :)
1471 2013-01-28 20:17:22 <CodeShark> that's their problem :p
1472 2013-01-28 20:17:50 <CodeShark> if you tinker around with enough system files, pretty soon your computer won't boot
1473 2013-01-28 20:17:56 <sipa> it's a problem they'll blame us for, so we can at least make everyone a tiny bit happier on average by making things not confusion :)
1474 2013-01-28 20:18:27 debiantoruser has joined
1475 2013-01-28 20:19:07 <HM> user is going to care about the size of the files more than anything
1476 2013-01-28 20:22:16 techlife has joined
1477 2013-01-28 20:22:17 techlife has quit (Max SendQ exceeded)
1478 2013-01-28 20:22:21 rdymac has joined
1479 2013-01-28 20:22:28 Diapolo has joined
1480 2013-01-28 20:22:43 techlife has joined
1481 2013-01-28 20:22:44 techlife has quit (Max SendQ exceeded)
1482 2013-01-28 20:23:19 techlife has joined
1483 2013-01-28 20:23:20 techlife has quit (Max SendQ exceeded)
1484 2013-01-28 20:23:46 techlife has joined
1485 2013-01-28 20:23:46 techlife has quit (Max SendQ exceeded)
1486 2013-01-28 20:24:31 techlife has joined
1487 2013-01-28 20:24:32 techlife has quit (Max SendQ exceeded)
1488 2013-01-28 20:24:58 techlife has joined
1489 2013-01-28 20:30:09 voodster has quit (Quit: leaving)
1490 2013-01-28 20:33:39 rbecker is now known as RBecker
1491 2013-01-28 20:34:07 rdymac has quit (Quit: This computer has gone to sleep)
1492 2013-01-28 20:34:46 techlife has quit (Read error: Connection reset by peer)
1493 2013-01-28 20:35:22 techlife has joined
1494 2013-01-28 20:35:23 techlife has quit (Max SendQ exceeded)
1495 2013-01-28 20:36:41 techlife has joined
1496 2013-01-28 20:36:42 techlife has quit (Max SendQ exceeded)
1497 2013-01-28 20:37:09 techlife has joined
1498 2013-01-28 20:39:41 rng29a has quit (Quit: Ex-Chat)
1499 2013-01-28 20:40:00 Diapolo has left ()
1500 2013-01-28 20:40:08 rng29a has joined
1501 2013-01-28 20:40:08 rng29a has quit (Changing host)
1502 2013-01-28 20:40:08 rng29a has joined
1503 2013-01-28 20:46:11 bitnumus has quit (Remote host closed the connection)
1504 2013-01-28 20:46:29 bitnumus has joined
1505 2013-01-28 20:46:41 debiantoruser has quit (Ping timeout: 256 seconds)
1506 2013-01-28 20:47:04 <muhoo> just name it "beatles". seems to work pretty well.
1507 2013-01-28 20:48:13 debiantoruser has joined
1508 2013-01-28 20:48:32 variousnefarious has quit ()
1509 2013-01-28 20:49:50 variousnefarious has joined
1510 2013-01-28 20:50:44 b4epoche has quit (Ping timeout: 255 seconds)
1511 2013-01-28 20:51:32 <CodeShark> just to think had I bought some bitcoins at the beginning of this conversation and sold them now I could have made a few bucks :p
1512 2013-01-28 20:52:01 <gmaxwell> ;;ticker
1513 2013-01-28 20:52:01 <gribble> BTCUSD ticker | Best bid: 18.60006, Best ask: 18.65000, Bid-ask spread: 0.04994, Last trade: 18.65000, 24 hour volume: 51237.56979931, 24 hour low: 17.67720, 24 hour high: 18.75000, 24 hour vwap: 18.22110
1514 2013-01-28 20:53:53 b4epoche has joined
1515 2013-01-28 20:55:37 andytoshi has joined
1516 2013-01-28 21:01:29 owowo has joined
1517 2013-01-28 21:01:51 occulta has quit (Quit: KVIrc 4.1.3 Equilibrium http://www.kvirc.net/)
1518 2013-01-28 21:02:30 bitnumus_ has joined
1519 2013-01-28 21:08:41 ThomasV has joined
1520 2013-01-28 21:09:41 bitnumus_ has quit (Quit: Leaving)
1521 2013-01-28 21:10:24 <gmaxwell> Uh another jonmatonis forbes article. :(
1522 2013-01-28 21:10:37 <ThomasV> heh
1523 2013-01-28 21:11:56 debiantoruser has quit (Ping timeout: 256 seconds)
1524 2013-01-28 21:13:24 <helo> "bring it on, you can't hurt us!"
1525 2013-01-28 21:13:59 debiantoruser has joined
1526 2013-01-28 21:14:55 <jgarzik> gmaxwell: uh indeed :/
1527 2013-01-28 21:17:30 spenvo has quit (Quit: This computer has gone to sleep)
1528 2013-01-28 21:18:09 occulta has joined
1529 2013-01-28 21:23:34 <MC1984> is darren styles the scammer?
1530 2013-01-28 21:26:25 <Goonie> In case anyone cares, I uploaded previews for Bitcoin Wallet with bloom filtering enabled (using bitcoinj 0.7-SNAPSHOT) to http://code.google.com/p/bitcoin-wallet/downloads/list
1531 2013-01-28 21:27:28 <jgarzik> gmaxwell: I wish there was a counter-Matonis blogger out there
1532 2013-01-28 21:28:11 <jgarzik> gmaxwell: Matonis' high profile "evade taxes!" blogging worries
1533 2013-01-28 21:28:43 <jgarzik> BitSynCom posts an ASIC update: https://bitcointalk.org/index.php?topic=137534.msg1486047#msg1486047
1534 2013-01-28 21:28:51 <jgarzik> or non-update
1535 2013-01-28 21:29:20 packc has joined
1536 2013-01-28 21:32:01 packc has quit (Client Quit)
1537 2013-01-28 21:32:07 <Luke-Jr> jgarzik: LOL, the picture looks intentionally designed to look like an old PC
1538 2013-01-28 21:32:29 tonikt has quit (Read error: Connection reset by peer)
1539 2013-01-28 21:33:54 reizuki__ has joined
1540 2013-01-28 21:33:54 reizuki__ has quit (Changing host)
1541 2013-01-28 21:33:54 reizuki__ has joined
1542 2013-01-28 21:34:08 <jaakkos> wow, the thing is quite big
1543 2013-01-28 21:34:37 <Luke-Jr> just a heads up, slush's stratum-server can make invalid blocks in some cases
1544 2013-01-28 21:34:46 <Luke-Jr> for Bitcoin mainnet, it shouldn't be a problem for 155 more years tho
1545 2013-01-28 21:37:06 <MC1984> why 155
1546 2013-01-28 21:38:20 <grau> Am I correct that we are already at about 1/2 of permissible block size ?
1547 2013-01-28 21:38:23 <Luke-Jr> MC1984: it starts at block 8,388,608 (80,0000 tonal)
1548 2013-01-28 21:39:07 <MC1984> >tonal
1549 2013-01-28 21:39:26 <Luke-Jr> I only included it because it demonstrates a case where tonal is clearly easier to work with :P
1550 2013-01-28 21:39:52 <gavinandresen> grau : peeking at blockexplorer.com for the size of the last dozen or so blocks⦠no, looks like the average is maybe 200K, which is 1/5 max size
1551 2013-01-28 21:40:35 <grau> I did not do serious stat but just saw 218472 with 447 K
1552 2013-01-28 21:41:14 <grau> with 818 tx. That lets me think that we hit the barrier soon.
1553 2013-01-28 21:41:42 <Luke-Jr> grau: bitcoind won't even make blocks over 500k right now
1554 2013-01-28 21:43:09 <grau> I am worried that this will be tight. We only have one high volume service and marginal adoption and we are about to hit a barrier soon.
1555 2013-01-28 21:43:34 <ThomasV> you mean SD?
1556 2013-01-28 21:43:38 <grau> yes
1557 2013-01-28 21:43:45 <Luke-Jr> grau: that's a DDoS attack ;)
1558 2013-01-28 21:44:08 <grau> does not matter. There will be similar since it makes money
1559 2013-01-28 21:44:25 <Luke-Jr> you could run an equivalent gambling site without the DDoS easily
1560 2013-01-28 21:44:56 <gavinandresen> they'll have to start competing for block space using transaction fees. Or decide to adapt and implement their service a different way.
1561 2013-01-28 21:45:33 <Luke-Jr> I'd write one just to put SD out of business, but the USA likes to prosecute people who write gambling software â¦
1562 2013-01-28 21:46:02 <grau> competition is good, but price discovery will be painful and until settles confirmation times could be discouraging
1563 2013-01-28 21:46:38 <Luke-Jr> yeah, SD is only a real threat because Bitcoin is so young and lacks adoption :/
1564 2013-01-28 21:47:03 <gavinandresen> the payment protocol proposal was designed for instant notification from merchant back to buyer with an eye towards the "settle confirmation times" issue
1565 2013-01-28 21:47:04 <grau> SD is a driver of adoption actually
1566 2013-01-28 21:47:44 <sipa> grau: adoption of "buy bitcoins at exchange, gamble, sell bitcoins at exchange", or adoption leading to an actual economy in bitcoins?
1567 2013-01-28 21:47:58 <gavinandresen> sipa: that is "an actual economy"
1568 2013-01-28 21:48:20 <sipa> i disagree - the first will certainly lead to the second
1569 2013-01-28 21:48:27 <grau> I am not valuing it, but believe that some are actually buying bitcoin to gamble.
1570 2013-01-28 21:48:29 <sipa> but in the case of SD i think only in a very small amount
1571 2013-01-28 21:49:28 <Luke-Jr> the gambling economy doesn't depend on SD's DDoS
1572 2013-01-28 21:49:40 <sipa> can you stop using that word?
1573 2013-01-28 21:49:42 <Luke-Jr> people can gamble at other sites easily
1574 2013-01-28 21:49:47 <sipa> then again, i don't understand people who play it at all
1575 2013-01-28 21:49:55 <sipa> so i can't really guess
1576 2013-01-28 21:50:06 <gavinandresen> me neither. But I don't understand a lot of what people decide to spend money on.
1577 2013-01-28 21:50:25 <grau> that is why we still work :)
1578 2013-01-28 21:50:32 <sipa> haha
1579 2013-01-28 21:50:47 dvide has quit ()
1580 2013-01-28 21:52:56 Acciaio has joined
1581 2013-01-28 21:56:34 rng29a has quit (Quit: Ex-Chat)
1582 2013-01-28 21:56:51 bitnumus has quit (Read error: No route to host)
1583 2013-01-28 21:57:07 bitnumus has joined
1584 2013-01-28 21:58:07 <grau> The good thing on hitting that barrier is that it caps our optimization effort. There will be no more than about 2K transactions per block.
1585 2013-01-28 21:58:30 <grau> And it will spark innovation. People will start side chains or whatever...
1586 2013-01-28 21:58:58 ThomasV has quit (Ping timeout: 256 seconds)
1587 2013-01-28 21:59:11 * gmaxwell points at petertodd
1588 2013-01-28 21:59:50 <MC1984> are you really set on keeping that limit?
1589 2013-01-28 22:00:16 occulta has quit (Quit: KVIrc 4.1.3 Equilibrium http://www.kvirc.net/)
1590 2013-01-28 22:01:08 <gmaxwell> MC1984: removing it entirely appears to be clear long term suicide. I'm not sure how to agree on a _differnet limit_. And reasons entirely unrelated to the limit necessitate secondary systems that should make the limit no big deal.
1591 2013-01-28 22:01:21 <gmaxwell> different*
1592 2013-01-28 22:02:06 <moore> sipa, gmaxwell, etc: I along with some other am going to write a blog post about reuse of r values in the block chain in the next few days. Given that you have looked in to it do I suspect we will mention the url gmaxwell posed, unless you don't want us to. Just a heads up.
1593 2013-01-28 22:02:06 <gmaxwell> Things like petertodd's fidelity banks should be able to give people highly private, reasonably trustworthy, very instant transactions at enormous volume.
1594 2013-01-28 22:02:37 <CodeShark> is this fidelity bank idea documented anywhere? or is it just fragments of chats?
1595 2013-01-28 22:02:38 <MC1984> 2000 seems low though for any sort of adoption
1596 2013-01-28 22:02:47 <gmaxwell> moore: some of those addresses have funds connect to them, not muchâ I think I counted up about 1btc worth or so?
1597 2013-01-28 22:02:59 <moore> I don't think they do any more
1598 2013-01-28 22:03:10 <gmaxwell> CodeShark: he wrote about it on the forums, but I don't think his explination is powerful enough, â as I didn't really get it at first.
1599 2013-01-28 22:03:41 <MC1984> seems clear everyone has given up on bitcoin as anything other that a settlement network
1600 2013-01-28 22:04:01 <moore> gmaxwell, it seems you published that link in IRC late December and early January all the funs got transfered out.
1601 2013-01-28 22:04:02 <MC1984> endpoint supremacy takes a knock :(
1602 2013-01-28 22:04:36 <moore> I only found your link by googeling for addresses I independently found
1603 2013-01-28 22:04:45 t7 has joined
1604 2013-01-28 22:04:54 <moore> I have been looking in to it for the last week or so
1605 2013-01-28 22:05:04 <gmaxwell> moore: I think tcatm actually bothered writing the code to recover the private keys. If the funds are moved then perhaps he might release it.
1606 2013-01-28 22:05:06 <HM> gambling is a service
1607 2013-01-28 22:05:25 <HM> it creates value to gamblers who find it enjoyable
1608 2013-01-28 22:06:23 <HM> not that i understand why people find SD enjoyable
1609 2013-01-28 22:06:24 <CodeShark> I guess some people do find it enjoyable to get totally ripped off in a game of no skill where you have no chance of getting any edge...ever
1610 2013-01-28 22:06:41 <HM> same reason people play lotteries
1611 2013-01-28 22:06:52 <HM> they hope variance swings in their favour and they hit the jackpot
1612 2013-01-28 22:06:52 <kjj> seems to work for the lottery
1613 2013-01-28 22:06:58 <moore> hear is one of the addresses that transfered out the bitcoin in January: http://blockchain.info/address/16mWzkk6iznyJQ3sKQRYxQ1Zr8xWpGMFWi
1614 2013-01-28 22:07:12 <grau> MC1984: yes, it seems it evolves to a final settlement system as its transactions will become expensive
1615 2013-01-28 22:07:46 <MC1984> why are you still even working on a client then
1616 2013-01-28 22:07:48 <moore> I am going to do the post about it with these people: https://freedom-to-tinker.com/blog/nadiah/new-research-theres-no-need-panic-over-factorable-keys-just-mind-your-ps-and-qs/
1617 2013-01-28 22:07:55 <moore> so it might get a little press
1618 2013-01-28 22:08:03 <MC1984> end user client
1619 2013-01-28 22:08:08 <grau> MC1984: I am not working on a client but on a node
1620 2013-01-28 22:08:18 <MC1984> you guys*
1621 2013-01-28 22:08:42 <moore> I and Eric Wustrow have both been working on this
1622 2013-01-28 22:09:25 <gavinandresen> MC1984: I disagree with gmaxwell RE: removing the block size limit. But I think that's a long discussion for another day, and I doubt we'll be able to tell who is right or wrong without actually doing (or not doing) something.
1623 2013-01-28 22:09:54 <MC1984> youre right, this stuff is way in the future
1624 2013-01-28 22:10:17 <grau> like 3 months :)
1625 2013-01-28 22:10:25 <MC1984> i doubt it will even be you guys decision if and when
1626 2013-01-28 22:11:02 <grau> I belive the decision is made. We will not be able to upgrade the network before the limit is hit.
1627 2013-01-28 22:11:49 <MC1984> what limit
1628 2013-01-28 22:11:57 <grau> blocksize
1629 2013-01-28 22:12:10 debiantoruser has quit (Ping timeout: 244 seconds)
1630 2013-01-28 22:12:11 <HM> so if the block size limit is hit, we'll simply see greater delays on tx's getting in to the bc?
1631 2013-01-28 22:12:27 <MC1984> free noes yes
1632 2013-01-28 22:13:02 <gavinandresen> yes. And we'll have to write some code to tell users "Your transaction is taking a long time to confirm; add a bigger fee and re-transmit?"
1633 2013-01-28 22:13:49 <gavinandresen> Before then, we'll have to write some code to estimate what a reasonable transaction fee is, instead of hard-coding arbitrary rules
1634 2013-01-28 22:13:58 debiantoruser has joined
1635 2013-01-28 22:14:27 <CodeShark> will the lock_time and sequence fields be enabled by then? :)
1636 2013-01-28 22:14:29 <grau> I doubt you can program price discovery into the client.
1637 2013-01-28 22:14:43 <gavinandresen> lock_time and sequence work now...
1638 2013-01-28 22:14:52 <CodeShark> then the documentation is out-of-date
1639 2013-01-28 22:15:04 <CodeShark> https://en.bitcoin.it/wiki/Protocol_specification#tx
1640 2013-01-28 22:15:12 <gavinandresen> grau : why do you doubt that? Observing transactions broadcast and then included or not included in blocks should be sufficient to estimate miners' behavior
1641 2013-01-28 22:15:43 <HM> it's possible some miners will set their own min fees and simply ignore low payers
1642 2013-01-28 22:15:44 <kjj> no, the doc is right. replacement is disabled
1643 2013-01-28 22:15:50 <grau> If there is an algorithm that increases the fee then miner will optimize blocks to trigger it
1644 2013-01-28 22:16:39 <gavinandresen> CodeShark: oh, I see, it says without replacement lock_time is useless. That's just wrong.
1645 2013-01-28 22:16:53 FredEE has quit (Quit: FredEE)
1646 2013-01-28 22:17:24 FredEE has joined
1647 2013-01-28 22:19:18 <grau> I rather think that miner will take initiative and quote price for blockspace.
1648 2013-01-28 22:19:44 <gavinandresen> grau: miners have a strong incentive to quote a higher price than they will really accept.
1649 2013-01-28 22:20:49 <HM> well if miners stop mining the difficulty falls doesn't it?
1650 2013-01-28 22:20:49 <grau> gavinandresen: true, but they compete. Clients might route to miner quotes lower.
1651 2013-01-28 22:20:49 <gavinandresen> ⦠that is why I think having the client look at what they actually DO, rather than what they say they will do, is a better approach.
1652 2013-01-28 22:21:28 <sipa> that assumes all transactions ending up in blocks get to miners via the p2p network
1653 2013-01-28 22:21:46 <sipa> i really doubt that will be good assumption in the reasonably long future
1654 2013-01-28 22:22:09 <gavinandresen> sure, that's another possible future.
1655 2013-01-28 22:22:22 <grau> sipa: I learned that big pools already set up direct lines between each other.
1656 2013-01-28 22:22:42 <grau> it is the same to be expected for clients to get tx to cheaper miner.
1657 2013-01-28 22:23:06 <sipa> i expect clearing houses that have deals with groups of miners
1658 2013-01-28 22:24:01 <gavinandresen> what is the advantage over just "broadcast to everybody, including enough fee to get confirmed in the timeframe you care about" ?
1659 2013-01-28 22:24:16 <HM> All this unbridled capitalism sounds scary
1660 2013-01-28 22:24:44 <gavinandresen> I can see clearing houses that guarantee 0-confirmation transactions from their subscribers....
1661 2013-01-28 22:24:53 <sipa> exactly that
1662 2013-01-28 22:25:02 <Diablo-D3> aka bitcoin banks
1663 2013-01-28 22:25:17 pooler has joined
1664 2013-01-28 22:25:17 pooler has quit (Changing host)
1665 2013-01-28 22:25:17 pooler has joined
1666 2013-01-28 22:25:36 <gavinandresen> sipa: ok, I can see that. And they contract with big miners to ensure that their transactions settle at least once a day or something
1667 2013-01-28 22:25:37 <grau> gavinandresen: if you quote to hight your a "reseller" of a miner will forward it and do not tell others. If you quote too low your transaction will strive.
1668 2013-01-28 22:25:50 RBecker is now known as rbecker
1669 2013-01-28 22:26:24 <sipa> gavinandresen: and get instant confirmation from the miners that the tx is included in their mempools, and they will not drop it, for example
1670 2013-01-28 22:27:09 <sipa> to increase the viability of risk analysis for 0-conf accepts
1671 2013-01-28 22:27:36 <gmaxwell> The P2pool method can provide persusave evidence of hashpower being applied to an unconfirmed txn.
1672 2013-01-28 22:27:41 <sipa> true
1673 2013-01-28 22:28:36 <grau> gmaxwell: what is p2pool?
1674 2013-01-28 22:28:53 <gmaxwell> grau: https://en.bitcoin.it/wiki/P2Pool
1675 2013-01-28 22:31:00 MrTiggr has quit (Ping timeout: 255 seconds)
1676 2013-01-28 22:31:22 Zarutian has joined
1677 2013-01-28 22:33:48 <gmaxwell> gavinandresen: WRT the limitâ I'd encourage focusing on the non-necessity: Secondary payment networks (like petertodds' bonded chaum tokens) are a arguably a necessity for many reasons andâ even if they aren't a necessity they will be provided by the free market purely because they'll be more efficient. Once those are mature, then I suspect there is little cause to worry about the maximum block size, and so the risk-friction won't ...
1678 2013-01-28 22:33:54 <gmaxwell> ... be overcome.
1679 2013-01-28 22:34:53 <porquilho> i am watching a song from a real artist
1680 2013-01-28 22:34:57 <porquilho> a honest artist
1681 2013-01-28 22:35:05 <porquilho> with not any comercial sense
1682 2013-01-28 22:35:12 <porquilho> and schizophrenic
1683 2013-01-28 22:35:17 <porquilho> like all great artists are
1684 2013-01-28 22:35:17 <gavinandresen> gmaxwell: maybe. I want to see what happens between block size 250K and 1M before I make up my mind (250K being the default 'soft' limit right now)
1685 2013-01-28 22:35:44 <gmaxwell> gavinandresen: yea, I was happy that we cranked on the soft limit, allows us to see the effect of pressure there.
1686 2013-01-28 22:36:05 <sipa> when did we change the soft limit?
1687 2013-01-28 22:36:26 <gavinandresen> we didn't, reallyâ¦. well, we kind of did
1688 2013-01-28 22:36:41 <gmaxwell> part of the fee/priority reworking. It got set to 'typical behavior' and made a tunable.
1689 2013-01-28 22:36:57 <gavinandresen> satoshi's original code was: fill block by priority up to 250Kbytes. Then exponentially increase tx fees to 500Kbytes.
1690 2013-01-28 22:37:08 TD_ has joined
1691 2013-01-28 22:37:33 <Diablo-D3> how does it work now?
1692 2013-01-28 22:37:38 <gavinandresen> I rewrote as part of the sort-transactions-by-fee change, so it is now fill block sorted by fee up to 250Kbytes by default
1693 2013-01-28 22:37:42 <Diablo-D3> because I'd like to see it based on block size of n past blocks
1694 2013-01-28 22:37:49 Hashdog has quit (Remote host closed the connection)
1695 2013-01-28 22:39:25 <Diablo-D3> if a lot of giant blocks have happened recently (where giant > 100k) then start ramping up tx for all tx (instead of just tx after the first 250k)
1696 2013-01-28 22:39:55 <CodeShark> the logic should be to maximize the fee-to-size ratio given the mempool
1697 2013-01-28 22:40:05 <Zarutian> Diablo-D3: tx being tx fees in that last post of yours?
1698 2013-01-28 22:40:37 <Diablo-D3> er, yes
1699 2013-01-28 22:40:40 <Zarutian> (that is the first tx being replaced by tx fees)
1700 2013-01-28 22:40:41 <gmaxwell> sipa: so... when I should have been thinking last night I was thinking about what a system would look like where preference = (fee/kb*α) + log(priority/avg_priority*β) and setting α/β such that a 0.01 (tunable) fee transaction of average size and zero priority will tie a typical priority txn with zero fee.
1701 2013-01-28 22:41:09 <Zarutian> Diablo-D3: just wanted to stomp out a potentially confusing typo
1702 2013-01-28 22:41:12 <gmaxwell> sipa: the effect of that kind of function is that priority always matters slightly, but it becomes dominated by fees as you move away from some tunable fee-indifference amount.
1703 2013-01-28 22:41:14 <grau> the last 4 out of 7 where giant by that definition
1704 2013-01-28 22:41:33 <gmaxwell> (priority in that case being a new priority metric that also involves the txout set impact)
1705 2013-01-28 22:41:36 <Diablo-D3> so, lets say, past 10 blocks are no more than 2500k in size, then dont increase fees
1706 2013-01-28 22:41:40 <Diablo-D3> if they are, then increase fees
1707 2013-01-28 22:41:45 <Diablo-D3> if they are much smaller, then decrease fees
1708 2013-01-28 22:42:05 <Diablo-D3> and instead of 2500k, move it down to 1000k
1709 2013-01-28 22:42:28 <grau> why not make it more complicated ...?
1710 2013-01-28 22:42:43 PK has quit ()
1711 2013-01-28 22:42:50 <Diablo-D3> grau: its not really complicated
1712 2013-01-28 22:43:04 <Diablo-D3> and it punishes idiot pools that dont follow the rules
1713 2013-01-28 22:43:24 <Diablo-D3> a pool that, say, just scavenges ANY tx no matter the size just punishes itself by shitting out 1mb blocks
1714 2013-01-28 22:43:33 <Diablo-D3> er, no matter the tx fees
1715 2013-01-28 22:43:39 <HM> why is charging by the kilobyte even desirable
1716 2013-01-28 22:43:53 <sipa> HM: because kilobytes are the limited resource
1717 2013-01-28 22:43:55 <Diablo-D3> and large blocks propagate slower, thus its possible to outrun the pool
1718 2013-01-28 22:44:04 <grau> I think it is foolhardy to define algorithms for prices.
1719 2013-01-28 22:44:07 <Diablo-D3> and THEN because the fee schedule is based on past n blocks, the 1mb block then increases fees
1720 2013-01-28 22:44:08 <Luke-Jr> HM: it's not JUST by the kb
1721 2013-01-28 22:44:14 ForceMajeure_ has quit (Ping timeout: 260 seconds)
1722 2013-01-28 22:44:22 <Diablo-D3> thus punishes stupid pools with even MORE tx that it'll happily punish itself with
1723 2013-01-28 22:44:27 <gavinandresen> yes, and kilobytes are also a good proxy for CPU time needed to verify a transaction
1724 2013-01-28 22:44:49 drizztbsd has joined
1725 2013-01-28 22:44:51 <grau> please keep it simple.
1726 2013-01-28 22:44:51 <sipa> they are however a very bad proxy for estimating the effect on the UTXO set size
1727 2013-01-28 22:45:04 <grau> you wont get it right either.
1728 2013-01-28 22:45:10 <grau> then at least simple
1729 2013-01-28 22:45:16 <Diablo-D3> I think my plan is the best option
1730 2013-01-28 22:45:24 <Diablo-D3> it punishes anyone who tries to get greedy
1731 2013-01-28 22:45:28 <HM> yes, but block limits encourage higher value batch transactions instead of frequent small transactions, so why not do that by lowering fees for high value transactions. or transactions with fewer inputs or outputs (which means smaller bytesize)?
1732 2013-01-28 22:45:43 <Zarutian> also kilobytes are good proxy for transmission time over a communication channel. (Big blocks propagate slower)
1733 2013-01-28 22:45:50 <Diablo-D3> hm: but higher value batch transactions require less disk storage
1734 2013-01-28 22:45:53 <gmaxwell> HM: if you make things non-linear you general encourage gaming... so it has to be done with great care.
1735 2013-01-28 22:45:53 <gavinandresen> the current algorithm is designed to be simple. We give miners the knobs to tweak so they can collectively set policy; that's what I want to watch as transaction volume increases.
1736 2013-01-28 22:45:56 <Diablo-D3> its not CPU time we need to worry about
1737 2013-01-28 22:46:01 <Diablo-D3> its storage space
1738 2013-01-28 22:46:15 <Diablo-D3> by weight, isnt the chain now like half satoshisdice?
1739 2013-01-28 22:46:17 <HM> but you only need to store unspent transactions as well
1740 2013-01-28 22:46:26 <sipa> imho the two most important limiting factors are block size and accumulated UTXO set size
1741 2013-01-28 22:46:27 <HM> right?
1742 2013-01-28 22:46:39 <sipa> block size because it is artifically limited
1743 2013-01-28 22:46:45 <Diablo-D3> so, the easy way is to just nuke SD with block size fees
1744 2013-01-28 22:46:57 <Luke-Jr> is there docs on what exactly is signed and not signed, in a txn?
1745 2013-01-28 22:46:58 <sipa> UTXO size because every full node (and at least every miner) must have it rapidly-accessible
1746 2013-01-28 22:47:01 <Diablo-D3> the more they try to gamble, the more money goes into the hands of miners
1747 2013-01-28 22:47:09 <Zarutian> Diablo-D3: havent checked but I suspect that you might be right about that (Satoshisdice being half the current weight of the block chain)
1748 2013-01-28 22:47:10 <sipa> Luke-Jr: etotheipi_ has a nice diagram
1749 2013-01-28 22:47:22 <sipa> some 53% iirc
1750 2013-01-28 22:47:23 <HM> doesn't a massive transaction with 3 million inputs, which spends all those inputs fully, and only has one output, actually free up disk space?
1751 2013-01-28 22:47:35 <sipa> HM: in the UTXO set, yes
1752 2013-01-28 22:47:47 <sipa> but in the block chain it obviously adds more than it removes
1753 2013-01-28 22:47:57 <HM> i see
1754 2013-01-28 22:47:58 <CodeShark> inputs must always be spent fully
1755 2013-01-28 22:48:03 <CodeShark> :)
1756 2013-01-28 22:48:06 <sipa> (txins are significantly largers than the txouts they spend)
1757 2013-01-28 22:48:07 <Diablo-D3> and SD wont be the only abuser
1758 2013-01-28 22:48:09 <HM> i knew that
1759 2013-01-28 22:48:12 <HM> <_<
1760 2013-01-28 22:48:16 <Diablo-D3> so the network should aim for 100k blocks
1761 2013-01-28 22:48:26 <Diablo-D3> and then start moving the fee up if blocks start exceeding that
1762 2013-01-28 22:48:49 <Diablo-D3> it'd drain the resources of the SD DDOS and end that shit
1763 2013-01-28 22:48:52 <gavinandresen> Diablo-D3: so lobby for miners to set their target to 100k blocks.
1764 2013-01-28 22:49:06 <Diablo-D3> gavinandresen: theres not enough controls for that
1765 2013-01-28 22:49:10 <CodeShark> there should be a fee associated with keeping bitcoins too deep in the block chain...some reward for spending old txouts
1766 2013-01-28 22:49:15 <Diablo-D3> like, I can set block max, but thats not what I want
1767 2013-01-28 22:49:26 <HM> CodeShark: like negative bank interest :P
1768 2013-01-28 22:49:29 <gavinandresen> Diablo-D3: sure there are
1769 2013-01-28 22:49:30 <Luke-Jr> CodeShark: that's freicoin
1770 2013-01-28 22:49:30 <Diablo-D3> I dont mind producing 1mb blocks if the fuckers pay for it
1771 2013-01-28 22:49:43 <Diablo-D3> gavinandresen: maybe I missed it, but Ive only seen four controls on the size
1772 2013-01-28 22:49:45 <Zarutian> HM: demurrage? (however it is spelled I never can recall)
1773 2013-01-28 22:49:48 <grau> CodeShark: what you whant there is negative interest als called the D word.
1774 2013-01-28 22:49:53 <Luke-Jr> Diablo-D3: gavinandresen rewrote the block creation logic to add more controls
1775 2013-01-28 22:49:59 <Diablo-D3> ahh
1776 2013-01-28 22:50:03 <gavinandresen> Diablo-D3: see https://en.bitcoin.it/wiki/Transaction_fee -- in particular -mintxfee
1777 2013-01-28 22:50:04 <Diablo-D3> its not in stable yet, then?
1778 2013-01-28 22:50:08 <HM> I have no idea what demurrage is, or how you even say it
1779 2013-01-28 22:50:25 <Diablo-D3> I only know about blockmaxsize, blockminsize, blockprioritysize, and mintxfee
1780 2013-01-28 22:50:29 <grau> HM: its simple negative interest rate.
1781 2013-01-28 22:50:32 * Luke-Jr wonders if we should make a table showing which versions introduced which features <.<
1782 2013-01-28 22:50:32 <gavinandresen> Did I rewrite it for 0.6 or 0.7 ? I can't remember....
1783 2013-01-28 22:50:42 <Luke-Jr> gavinandresen: definitely not 0.6 I think
1784 2013-01-28 22:50:47 <Luke-Jr> I'd have guessed 0.7 or 0.8
1785 2013-01-28 22:50:51 <Diablo-D3> what Im suggesting is something like blockmaxsize == absolute max, blockminsize = 0, blockprioritysize = 0, mintxfee == my algo
1786 2013-01-28 22:50:57 rdymac has joined
1787 2013-01-28 22:51:34 <grau> You really do not know?
1788 2013-01-28 22:52:05 <grau> release notes ?
1789 2013-01-28 22:52:34 <Diablo-D3> so if blocks are very tiny over the past, say, 10 blocks, it rapidly decreases tx size
1790 2013-01-28 22:52:43 <Diablo-D3> if they're very large, rapidly increase it
1791 2013-01-28 22:52:55 <Diablo-D3> er, tx fee
1792 2013-01-28 22:53:31 <gavinandresen> Diablo-D3: a RPC call to change settings on the fly would be pretty easy. Then you could write a -blocknotify script that did what you wanted with the fees.
1793 2013-01-28 22:53:52 <Diablo-D3> yeah, but then no one else would run it
1794 2013-01-28 22:53:55 <grau> gavinandresen: Are there release notes ?
1795 2013-01-28 22:54:01 <Diablo-D3> thus meaning SD gets away scott free
1796 2013-01-28 22:54:12 * HM will have to inspect the bitcoind database code and learn more about the blockchain itself
1797 2013-01-28 22:54:27 <gavinandresen> I would like to move away from a centralized "We Know The Right Answer" ⦠because that is happening anyway, as we get multiple implementations.
1798 2013-01-28 22:54:42 <Diablo-D3> yeah, but the default impl should prevent leeches like SD
1799 2013-01-28 22:54:47 Silverion has quit (Ping timeout: 256 seconds)
1800 2013-01-28 22:55:05 <gavinandresen> grau: sure. Knock yourself out going back and reading them, it would be either 0.6 or 0.7 I think.
1801 2013-01-28 22:55:29 <HM> volume based pricing tends to be fair
1802 2013-01-28 22:55:56 <gavinandresen> grau: release notes are the README files with the released binaries on sourceforge
1803 2013-01-28 22:57:36 <grau> I thought github would be the place.
1804 2013-01-28 22:58:39 <CodeShark> yeah...released binaries? what are those?
1805 2013-01-28 22:58:50 <sipa> ...?
1806 2013-01-28 22:59:14 * CodeShark puts on the facetious face
1807 2013-01-28 23:00:31 <HM> Binaries are for mortals
1808 2013-01-28 23:01:56 <grau> So release notes are kept were developers are not. I should have thought.
1809 2013-01-28 23:02:24 <sipa> historic artefact, i guess
1810 2013-01-28 23:04:11 <gavinandresen> release notes are for users⦠'git blame' and 'git log' are for developers.
1811 2013-01-28 23:04:27 <grau> Tell me more about software development.
1812 2013-01-28 23:04:41 <gavinandresen> ok, what do you want to know?
1813 2013-01-28 23:04:58 * gavinandresen is good at playing along
1814 2013-01-28 23:05:14 <CodeShark> 10 GOTO 10
1815 2013-01-28 23:10:52 <grau> The issues list on github is also irrelevant ?
1816 2013-01-28 23:11:10 <lianj> nope
1817 2013-01-28 23:11:18 debiantoruser has quit (Read error: Operation timed out)
1818 2013-01-28 23:11:24 <lianj> but pull request list is preferred
1819 2013-01-28 23:11:52 owowo has quit (Quit: sayonara)
1820 2013-01-28 23:11:53 <gavinandresen> if github had binary downloads, we'd use it. But it doesn't (any more-- and when it did it was flaky)
1821 2013-01-28 23:13:09 <grau> There are 50 outstanding pull requests and 293 open issues. I guess thats more than you can ever catch up with. I would close or reject most if i knew how to develop software.
1822 2013-01-28 23:13:18 <gavinandresen> lianj: the issues list is a superset of the github pull requests
1823 2013-01-28 23:13:24 <lianj> true
1824 2013-01-28 23:14:35 debiantoruser has joined
1825 2013-01-28 23:14:57 gavinandresen has quit (Quit: gavinandresen)
1826 2013-01-28 23:16:24 smiddi_ has quit (Ping timeout: 264 seconds)
1827 2013-01-28 23:16:55 smiddi has joined
1828 2013-01-28 23:20:41 <grau> I apologize 49 are open.
1829 2013-01-28 23:20:54 icebattle has quit (Read error: Connection reset by peer)
1830 2013-01-28 23:21:08 icebattle has joined
1831 2013-01-28 23:25:25 grau has quit (Remote host closed the connection)
1832 2013-01-28 23:26:10 zooko` has joined
1833 2013-01-28 23:26:38 zooko` is now known as zooko
1834 2013-01-28 23:27:51 sgstair has quit (Ping timeout: 245 seconds)
1835 2013-01-28 23:27:56 RazielZ has quit (Ping timeout: 246 seconds)
1836 2013-01-28 23:28:30 johnsmith has joined
1837 2013-01-28 23:30:09 porquilho has quit ()
1838 2013-01-28 23:34:23 agricocb has quit (Quit: Leaving.)
1839 2013-01-28 23:34:37 t7 has quit (Quit: Konversation terminated!)
1840 2013-01-28 23:38:57 debiantoruser has quit (Ping timeout: 252 seconds)
1841 2013-01-28 23:40:41 debiantoruser has joined
1842 2013-01-28 23:43:32 <sipa> bah, so far for testing whether leveldb error catching works
1843 2013-01-28 23:43:53 <sipa> it doesn't even notice that i delete a database file during execution...
1844 2013-01-28 23:44:36 <sipa> not completely weird though... i guess it has enough in cache to not ever need reading from disk at this point
1845 2013-01-28 23:45:24 <Diablo-D3> erm
1846 2013-01-28 23:45:28 <Diablo-D3> if you never close the file
1847 2013-01-28 23:45:31 <Diablo-D3> its not actually deleted
1848 2013-01-28 23:45:57 <sipa> it may indeed not be closed
1849 2013-01-28 23:46:44 <sipa> indeed, it keeps most files open it seems
1850 2013-01-28 23:47:17 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
1851 2013-01-28 23:49:20 MrTiggr has joined
1852 2013-01-28 23:49:55 <phantomcircuit> sipa, the more important question is what happens when it restarts
1853 2013-01-28 23:50:08 Garr255_ has joined
1854 2013-01-28 23:50:09 Garr255_ has quit (Changing host)
1855 2013-01-28 23:50:09 Garr255_ has joined
1856 2013-01-28 23:50:39 Silverion has joined
1857 2013-01-28 23:50:50 one_zero has joined
1858 2013-01-28 23:52:10 <gmaxwell> https://bitcointalk.org/index.php?topic=139581.msg1486430#msg1486430
1859 2013-01-28 23:53:15 Garr255 has quit (Ping timeout: 252 seconds)
1860 2013-01-28 23:53:38 panzerfaust has joined
1861 2013-01-28 23:54:21 <doublec> hmm, I see a whole new field of posts with "just paste these raw transation commands in your bitcoin console...."
1862 2013-01-28 23:54:39 <doublec> the bitcoin equivalent of "paste the javascript in your browser url for fun"
1863 2013-01-28 23:55:53 <Zarutian> or "paste this in your bash root shell to install"
1864 2013-01-28 23:55:54 <Zarutian> ?
1865 2013-01-28 23:56:08 <gmaxwell> Zarutian: or type 'make' ... really :)
1866 2013-01-28 23:56:11 panzer has quit (Ping timeout: 245 seconds)
1867 2013-01-28 23:56:15 <gmaxwell> doublec: but perhaps a good oppturnity to point that out.
1868 2013-01-28 23:56:38 <Zarutian> gmaxwell: yebb hence my fascination with KeyKOS/EROS/Capros and such oses
1869 2013-01-28 23:56:57 <Zarutian> gmaxwell: 0install is also nifty in that regard.
1870 2013-01-28 23:58:03 MC1984 has quit (Ping timeout: 252 seconds)