1 2013-06-06 00:00:40 <phantomcircuit> ;;bc,blocks
2 2013-06-06 00:00:44 <gribble> 239989
3 2013-06-06 02:31:01 <BCB> kk
4 2013-06-06 02:31:02 <BCB> later
5 2013-06-06 02:49:38 <phantomcircuit> lol
6 2013-06-06 02:49:44 <phantomcircuit> you cant run bitcoind with mcheck
7 2013-06-06 02:50:06 <phantomcircuit> memory clobbered before allocated block
8 2013-06-06 02:51:59 <sipa> really? it works fine on valgrind here
9 2013-06-06 02:52:08 <TheUni> sipa: ping
10 2013-06-06 02:52:15 <sipa> TheUni: yes?
11 2013-06-06 02:52:35 <phantomcircuit> sipa, try building with -lmcheck
12 2013-06-06 02:52:41 <TheUni> sipa: are dependencies build deterministically as well?
13 2013-06-06 02:52:42 <phantomcircuit> it doesn't even get past AppInit2
14 2013-06-06 02:53:01 <gmaxwell> TheUni: the entire builds are determinstic.
15 2013-06-06 02:53:09 <TheUni> sipa: or does the final deterministic binary depend on a static set of pre-build non-deterministic libs?
16 2013-06-06 02:53:10 <TheUni> ok
17 2013-06-06 02:53:18 <sipa> well, iirc some dependencies are not exactly deterministic
18 2013-06-06 02:53:23 <sipa> without affecting the final build
19 2013-06-06 02:53:46 <gmaxwell> yea, asking that way??? the base system is a precondition... it's not like it builds gcc and glibc and such.
20 2013-06-06 02:53:52 <TheUni> but you and i could both start from qt/boost/etc. sources, and generate the same bitcoind?
21 2013-06-06 02:54:17 <TheUni> gmaxwell: sure, i realize there's an assumption of using a predetermined toolchain
22 2013-06-06 02:54:43 <sipa> at some point the qt build (i think) was not deterministic, and this affected the final build
23 2013-06-06 02:55:12 <sipa> so you had to start from a single built of qt, which sort-of defeated gitian's purpose
24 2013-06-06 02:55:13 <Luke-Jr> since we're not distributing the dependencies, it makes no difference
25 2013-06-06 02:55:19 <sipa> unsure whether that's still the case
26 2013-06-06 02:55:23 <maaku_> gmaxwell: well my vagrant-gitian scripts builds out the toolchain too :P
27 2013-06-06 02:55:39 <TheUni> Luke-Jr: what do you mean? the dependencies are static...
28 2013-06-06 02:56:26 <gmaxwell> the static ones are determinstically built, upto the OS level at least... otherwise the binaries we distribute wouldn't match, and they do.
29 2013-06-06 02:56:28 <Luke-Jr> TheUni: not the parts in question
30 2013-06-06 02:56:39 <TheUni> essentially i'm trying to understand what i have to do to provide (what i consider) to be a better way to handle the dependencies, without causing any regressions
31 2013-06-06 02:56:59 <Luke-Jr> TheUni: as long as the outputs of the gitian.yml and gitian-win32.yml match, you're fine
32 2013-06-06 02:57:33 <TheUni> gmaxwell: ok, thanks. that answers my question. i was trying to ascertain the base level. seems to be a toolchain and nothing more
33 2013-06-06 02:57:38 <sipa> TheUni: i would deal with the dependencies later
34 2013-06-06 02:58:08 <sipa> TheUni: assume you have the .zip files for the dependencies already in gitian/inputs, potentially organized/named differently if that simplifies things for you
35 2013-06-06 02:58:34 <TheUni> sipa: sure, that's done. i'm writing up a cheat-sheet for the PR. I'm just thinking of the next steps
36 2013-06-06 02:58:45 <sipa> TheUni: including bitcoin-qt?
37 2013-06-06 02:58:49 <TheUni> yea
38 2013-06-06 02:58:50 <phantomcircuit> sipa, VerifyDB "memory clobbered before allocated block"
39 2013-06-06 02:58:53 <phantomcircuit> weird
40 2013-06-06 02:59:07 <phantomcircuit> maybe something about how leveldb uses memory screws up mcheck
41 2013-06-06 02:59:14 <TheUni> sipa: i realize there's going to be endless bikeshedding about this, so i'm trying to make it as regression-free and easy one everyone as possible, to remove those arguments
42 2013-06-06 02:59:15 <sipa> phantomcircuit: mmap() ?
43 2013-06-06 02:59:22 <phantomcircuit> possibly
44 2013-06-06 02:59:27 <phantomcircuit> i'll follow the rabbit hole some more
45 2013-06-06 02:59:32 <TheUni> *easy on
46 2013-06-06 02:59:35 <sipa> TheUni: i'm eager to see it :)
47 2013-06-06 02:59:37 <phantomcircuit> huh
48 2013-06-06 02:59:53 <TheUni> sipa: will pr in a few
49 2013-06-06 02:59:57 <phantomcircuit> sipa, im getting the error before a breakpoint on VerifyDB is hit
50 2013-06-06 03:00:01 <phantomcircuit> confuse
51 2013-06-06 03:00:05 <TheUni> sipa: it gets rid of qmake, i expect that to raise a few eyebrows
52 2013-06-06 03:01:13 <phantomcircuit> disassemble AppInit2
53 2013-06-06 03:01:14 <phantomcircuit> :(
54 2013-06-06 03:01:32 <sipa> TheUni: as long as it works, not mine :)
55 2013-06-06 03:01:40 <sipa> TheUni: but wumpus may have a different opinion
56 2013-06-06 03:02:05 <TheUni> sipa: put a check in the box for the autotools plugin in qt-creator, and it's like nothing changed
57 2013-06-06 03:02:25 <sipa> ok
58 2013-06-06 03:02:30 <TheUni> it surprised me how elegant it is, actually
59 2013-06-06 03:03:10 <TheUni> all other autotools ide plugins i've seen have been trainwrecks, this one just works
60 2013-06-06 03:13:34 <TheUni> phantomcircuit: heh, there's not a silver bullet
61 2013-06-06 03:13:45 <TheUni> squash one and on to the next
62 2013-06-06 03:20:34 <phantomcircuit> stepping through the boost signaling stuff makes me want to cry
63 2013-06-06 03:23:32 <TheUni> phantomcircuit: you're on the overloaded operator, then?
64 2013-06-06 04:12:33 <wumpus> TheUni: please keep the qmake file (even if its in contrib/wumpus-crap or so :p)
65 2013-06-06 04:12:55 <TheUni> wumpus: everything i've done is back-compat, so they can live in harmony if necessary
66 2013-06-06 04:13:10 <wumpus> TheUni: I really like having a file tree in qt creator
67 2013-06-06 04:13:18 <TheUni> wumpus: you still do
68 2013-06-06 04:13:26 <wumpus> TheUni: even if it gets out of date for building anymore
69 2013-06-06 04:13:28 <TheUni> it looks just like a .pro layout
70 2013-06-06 04:13:42 <wumpus> ok...
71 2013-06-06 04:14:11 <TheUni> wumpus: got a min to try it out? i'm not done writing it up yet, but you can pull from my tree before i PR it if you don't mind taking a quick look?
72 2013-06-06 04:14:32 <wumpus> I don't have time right now, sorry, maybe in the afternoon
73 2013-06-06 04:14:43 <TheUni> np
74 2013-06-06 04:14:45 <sipa> TheUni: uri?
75 2013-06-06 04:15:11 <TheUni> sipa: sec. stupid phantomcircuit distracted me with his treasure hunt :)
76 2013-06-06 04:16:43 <TheUni> sipa: https://github.com/theuni/bitcoin/tree/autotools-rebase
77 2013-06-06 04:16:45 <sipa> ha
78 2013-06-06 04:17:38 <TheUni> or, to save you a click: git remote add -f theuni git://github.com/theuni/bitcoin.git
79 2013-06-06 04:18:17 <TheUni> sipa: in linux?
80 2013-06-06 04:18:38 <sipa> yes
81 2013-06-06 04:19:36 <TheUni> sipa: assuming there's nothing crazy about your setup, ./autogen.sh && ./configure && make
82 2013-06-06 04:19:55 <gmaxwell> akk/window 4
83 2013-06-06 04:20:19 <TheUni> eh?
84 2013-06-06 04:23:43 <SomeoneWeird> ACTION slaps gmaxwell
85 2013-06-06 04:25:23 <sipa> TheUni: seems to work!
86 2013-06-06 04:25:35 <TheUni> sipa: first try, i'll take it :)
87 2013-06-06 04:26:02 <sipa> yes
88 2013-06-06 04:26:44 <TheUni> sipa: if you don't mind: make check
89 2013-06-06 04:27:14 <sipa> also works :)
90 2013-06-06 04:27:44 <TheUni> great. recent-ish ubuntu, i guess?
91 2013-06-06 04:27:56 <sipa> yeah 13.04
92 2013-06-06 04:28:41 <TheUni> sipa: './configure --help' and see if there's anything glaring that i might've missed
93 2013-06-06 04:29:09 <sipa> there's --enable-upnp, but can you set whether it's enabled by default at runtime or not?
94 2013-06-06 04:29:40 <TheUni> i have lots of screaming about that to do, but atm i believe i emulate the current behavior
95 2013-06-06 04:29:57 <wumpus> TheUni: why put the autogen.sh in src/ ?
96 2013-06-06 04:30:16 <sipa> hmm, some m4 files are LGPL?
97 2013-06-06 04:30:20 <wumpus> any other project I know of simply has it in the root
98 2013-06-06 04:31:08 <wumpus> in any case, it works here too!
99 2013-06-06 04:31:22 <sipa> TheUni: it's probably the worst-understood config flag we have, and there's certainly better ways, but i don't see a way to enable/disable upnp at runtime?
100 2013-06-06 04:31:34 <wumpus> from the command line, at least, which file do I open in qt creator?
101 2013-06-06 04:31:48 <sipa> (not that i feel particularly hard about it, but if you say you're mimicking current behaviour, i don't see it)
102 2013-06-06 04:31:49 <TheUni> wumpus: cmdline, no clue. you have to install the plugin first
103 2013-06-06 04:31:59 <wumpus> oh crap :/
104 2013-06-06 04:32:09 <sipa> ?
105 2013-06-06 04:32:10 <TheUni> wumpus: heh, ssh'ing to home?
106 2013-06-06 04:32:30 <wumpus> TheUni: eh sorry those were two sentences merged in to one
107 2013-06-06 04:32:35 <wumpus> TheUni: it works from the command line
108 2013-06-06 04:32:48 <wumpus> TheUni: I'm now trying to open it in qt creator
109 2013-06-06 04:33:07 <TheUni> wumpus: understood. i saw the 'oh crap' and assumed it meant you don't have access to the gui atm
110 2013-06-06 04:33:08 <wumpus> but I need a plugin? ouch
111 2013-06-06 04:33:18 <TheUni> wumpus: it's literally just a click away
112 2013-06-06 04:33:38 <TheUni> about -> plugins -> automake -> done
113 2013-06-06 04:34:08 <TheUni> sorry, Autotools
114 2013-06-06 04:34:19 <TheUni> then, to answer your question, it's the Makefile.am that you'll be opening
115 2013-06-06 04:34:32 <wumpus> hm under about I see "Installed PLugins", but that doesn't help me
116 2013-06-06 04:34:46 <sipa> autotoolsprojectmanager?
117 2013-06-06 04:35:08 <TheUni> sipa: looks like you're right. i'll get that working.
118 2013-06-06 04:35:10 <TheUni> sipa: yep
119 2013-06-06 04:35:23 <wumpus> only four entries under build systems, and they're all enabled, none is called auto*
120 2013-06-06 04:35:45 <TheUni> wumpus: hmm. i'm on osx atm, and qt creator shipped with it ready to go
121 2013-06-06 04:36:13 <wumpus> could be, this the ubuntu stock install with 12.04 so it's probably pretty old...
122 2013-06-06 04:36:44 <sipa> wumpus: here on 13.04 it seems to work (but this is the first time i ever open qtcreator, so i have no idea what to check to see if it works)
123 2013-06-06 04:37:23 <wumpus> sipa: does it have a tree of files to the left, with sources, headers, forms, resources?
124 2013-06-06 04:37:26 <TheUni> sipa: open the .pro for comparison
125 2013-06-06 04:39:02 <wumpus> in any case, got to head of to the salt mines, speak to you later
126 2013-06-06 04:39:16 <TheUni> wumpus: only thing it doesn't do is let you deal with resources as resources
127 2013-06-06 04:39:24 <TheUni> meaning, you just see a flat list of files
128 2013-06-06 04:39:37 <TheUni> looking into whether that's fixable or not
129 2013-06-06 04:40:26 <sipa> it seems to work, but indeed, flat files
130 2013-06-06 04:40:34 <sipa> well, not flat, it's the directory hierarchy
131 2013-06-06 04:40:47 <sipa> not categorized into sources/headers/forms/resources
132 2013-06-06 04:41:11 <TheUni> yea, it doesn't know how to categorize anything
133 2013-06-06 04:41:33 <TheUni> i'm hoping it's possible to name/tag files such that it will pick them up. but i have a feeling the plugin just doesn't handle that
134 2013-06-06 04:41:55 <TheUni> (name/tag in the makefile, not changing filenames of course)
135 2013-06-06 04:43:49 <sipa> i don't see anything like forms or resources at all
136 2013-06-06 04:43:55 <sipa> just .cpp and .h files
137 2013-06-06 04:44:39 <sipa> can't see bitcoin.qrc either
138 2013-06-06 04:46:02 <TheUni> yea, i couldn't find any docs for how those things are supposed to be identified (if at all). i've cloned the plugin source, will grep around over the next few days
139 2013-06-06 04:46:08 <tgs3> the 4 hour wait on bitcoin forum is really fucking annoying
140 2013-06-06 04:48:40 <TheUni> sipa: but given that the plugin has some decent unit tests, and none include more than source/headers, i'm assuming it's just not implemented
141 2013-06-06 04:48:56 <sipa> i have a feeling wumpus will not like that :p
142 2013-06-06 04:49:12 <TheUni> heh
143 2013-06-06 04:49:23 <TheUni> my hope is that we can somehow save a .pro with the autotools build steps
144 2013-06-06 04:51:01 <TheUni> sipa: any other criticism? Any idea what the big counter-arguments might be?
145 2013-06-06 05:25:43 <CodeShark> if I accidentally close a pull request, how do I reopen it?
146 2013-06-06 05:26:39 <CodeShark> oh, nvm :)
147 2013-06-06 05:32:07 <TheUni> CodeShark: btw, i'm not worried about our work clashing, i just didn't want it so that we were conflicting on upstream and eachother at the same time
148 2013-06-06 05:32:41 <TheUni> but it's not a concern anymore
149 2013-06-06 05:36:40 <CodeShark> yeah, I don't think we're touching the same things very much
150 2013-06-06 05:37:05 <CodeShark> I've sort of abandoned the configure script pull request
151 2013-06-06 05:37:32 <CodeShark> seems like you're far more capable of pulling it off than I am :)
152 2013-06-06 05:38:54 <TheUni> ah, that was yours a while ago?
153 2013-06-06 05:41:02 <CodeShark> or were you talking about conflicting on more recent stuff?
154 2013-06-06 05:45:38 <TheUni> CodeShark: nevermind :)
155 2013-06-06 08:07:20 <FluffySheap> Hello all, I have a technical question about the algorithm.
156 2013-06-06 08:07:22 <FluffySheap> Mining is rated in mega hashes per second
157 2013-06-06 08:07:30 <FluffySheap> but each block attempt is actually two hashes
158 2013-06-06 08:07:40 <FluffySheap> one chained to the other
159 2013-06-06 08:07:50 <FluffySheap> does the megahash rating count both hashes, or just one of the two?
160 2013-06-06 08:07:59 <CodeShark> both
161 2013-06-06 08:08:25 <FluffySheap> ok, thanks
162 2013-06-06 08:08:38 <CodeShark> one block hash = sha256(sha256(block header))
163 2013-06-06 08:09:52 <FluffySheap> I think my hardware comparisons will make more sense now :)
164 2013-06-06 08:29:14 <CodeShark> but I believe it is possible to implement sha256(sha256(x)) more efficiently than computing sha256 two separate times
165 2013-06-06 08:35:57 <t7> well the second time the input is only 256bits and in memory already ...
166 2013-06-06 08:36:00 <t7> so maybe
167 2013-06-06 09:10:38 <FluffySheap> I think if you wanted to optimize that it would be based on the fact that the second block is mostly zeroes
168 2013-06-06 09:10:47 <FluffySheap> but even then I don't know how much you could do due to the mixing
169 2013-06-06 09:10:55 <FluffySheap> you might save like 10% of the first step
170 2013-06-06 09:12:05 <sipa> for repeated application, specifically with just the nonce varying, you only need something like 122 sha256 rounds
171 2013-06-06 09:12:11 <sipa> while naive application needs 192
172 2013-06-06 09:13:56 <FluffySheap> do current clients reduce the number of rounds by fancy math?
173 2013-06-06 09:14:15 <FluffySheap> if so... the answer is there
174 2013-06-06 09:14:16 <FluffySheap> heh
175 2013-06-06 09:15:23 <CodeShark> I would think exploiting massive parallelism in hardware is a more economic approach than trying to optimize sequential processing in software
176 2013-06-06 09:15:30 <CodeShark> *economical
177 2013-06-06 09:16:21 <CodeShark> although the two aren't necessarily mutually exclusive :)
178 2013-06-06 09:16:26 <FluffySheap> yeah I was going tos ay that
179 2013-06-06 09:16:32 <FluffySheap> anything you do by optimizing the algorithm is free
180 2013-06-06 09:16:52 <FluffySheap> if you're right that there is a 30% reduction available in math, that would be ... great
181 2013-06-06 09:16:59 <FluffySheap> especially if the ASICs aren't doing it
182 2013-06-06 09:17:00 <FluffySheap> heh
183 2013-06-06 09:17:52 <FluffySheap> however given how little of the existing algorithm is parallelizaable
184 2013-06-06 09:17:58 <FluffySheap> I'm not sure if 30% savings is possible
185 2013-06-06 09:18:39 <CodeShark> optimizations of the software could carry other costs, though - costs in synchronization requirements, memory, etc...although I haven't really studied this specific problem sufficiently to give anything other than speculations :p
186 2013-06-06 09:20:07 <FluffySheap> costs in memory are probably a good thing
187 2013-06-06 09:20:19 <CodeShark> not for someone trying to build cheap hardware
188 2013-06-06 09:20:32 <FluffySheap> which is why it's a good thing, memory is free for GPUs
189 2013-06-06 09:20:35 <CodeShark> moreover, memory I
190 2013-06-06 09:20:52 <CodeShark> moreover, memory I/O is a major bottleneck in modern computer design
191 2013-06-06 09:21:28 <FluffySheap> sure, but suppose you have an optimized algorithm that requires more memory but less computation
192 2013-06-06 09:21:36 <FluffySheap> that suits GPUs really well, which have the most memory bandwidth
193 2013-06-06 09:21:44 <FluffySheap> and is bad for ASICs which have the algorithm fixed
194 2013-06-06 09:21:52 <FluffySheap> and can't even add memory without a whole new PCB design
195 2013-06-06 09:21:58 <FluffySheap> it would send them back to the drawing board basically
196 2013-06-06 09:22:14 <FluffySheap> and while anyone that has an ASIC is glad to have it, wouldn't you say the community is better if GPUs are worthwhile
197 2013-06-06 09:23:15 <FluffySheap> sipa, do you have information on the reduced-round algorithm for iterated sha?
198 2013-06-06 09:25:14 <FluffySheap> it would be an obvious thing for password cracking so probably mathematicians have looked at it already
199 2013-06-06 09:26:15 <FluffySheap> http://ballastsec.blogspot.com/2012/07/transferable-state-attack-on-iterated.html
200 2013-06-06 09:26:18 <FluffySheap> I found this
201 2013-06-06 09:26:20 <FluffySheap> but I don't understand it yet
202 2013-06-06 09:31:12 <CodeShark> this optimization is for piping iterations of sha256, not for applying sha256 to multiple related inputs
203 2013-06-06 09:31:49 <FluffySheap> right
204 2013-06-06 09:32:07 <FluffySheap> that is true, but still he saved 10% on it
205 2013-06-06 09:33:10 <CodeShark> if you have two inputs that differ in, say, only one bit, you can reuse all the operations up to the point where that bit is used
206 2013-06-06 09:33:38 <CodeShark> in the transform function in particular
207 2013-06-06 09:34:05 <FluffySheap> I see you could probably improve the bit-expanding half of the algorithm
208 2013-06-06 09:34:08 <FluffySheap> but that is the cheap half
209 2013-06-06 09:36:27 <FluffySheap> best case, you'd save seven of the 48 rounds of the bit expander, before you would end up with different results
210 2013-06-06 09:36:55 <FluffySheap> well, no, you might do better in the bit expander
211 2013-06-06 09:37:01 <sipa> FluffySheap: look at any miner's source
212 2013-06-06 09:37:24 <FluffySheap> ah, so the existing miners use it already then
213 2013-06-06 09:37:40 <FluffySheap> so this is all a moot discussion then, except for my enlightenment :)
214 2013-06-06 09:38:20 <sipa> FluffySheap: you have no idea how many man-years have been spent on miner efficiency improvements :)
215 2013-06-06 09:38:54 <FluffySheap> I imagine quite a few
216 2013-06-06 09:38:56 <FluffySheap> :)
217 2013-06-06 09:39:32 <sipa> people have _sold_ optimized mining algorithms for hundreds of USD
218 2013-06-06 09:39:45 <FluffySheap> just for hundreds?
219 2013-06-06 09:39:54 <CodeShark> yeah, lol
220 2013-06-06 09:39:58 <sipa> this was two years ago :p
221 2013-06-06 09:39:59 <FluffySheap> that was a bad trade then :)
222 2013-06-06 09:40:11 <sipa> when the exchange rate was below <1 USD
223 2013-06-06 09:40:13 <FluffySheap> ah
224 2013-06-06 09:40:15 <FluffySheap> still
225 2013-06-06 09:40:19 <FluffySheap> better to keep it in your pocket
226 2013-06-06 09:40:49 <FluffySheap> which miner would have the easiest to understand source?
227 2013-06-06 09:40:59 <CodeShark> mining bitcoin naturally lends itself far more to horizontal scaling than vertical
228 2013-06-06 09:41:27 <epscy> which is a shame
229 2013-06-06 09:41:28 <CodeShark> the winner is massive low power parallelism
230 2013-06-06 09:42:02 <CodeShark> no matter how clever your algorithms, the gains will be minimal compared to just adding another unit
231 2013-06-06 09:42:14 <FluffySheap> I actually speculate that the eventual value of bitcoins will have more to do with hardware cost than energy cost
232 2013-06-06 09:42:42 <sipa> with neither
233 2013-06-06 09:42:58 <sipa> it has to do with how people think its usefulness/value will evolve in the future
234 2013-06-06 09:43:12 <sipa> hardhard and energy costs will be allowed to go up, when exchange rates go up
235 2013-06-06 09:43:15 <sipa> not the other way around
236 2013-06-06 09:43:18 <sipa> *hardware
237 2013-06-06 09:43:23 <FluffySheap> because of changing difficulty, your income is based on how much of the total share of computation you control, so as long as hardware continues to evolve and people are forced to buy new, the amortization of the HW always counts more than the energy
238 2013-06-06 09:44:07 <CodeShark> in the limit, mining is break even
239 2013-06-06 09:44:12 <FluffySheap> perhaps in the long term, the most money to be made is in selling the mining equipment rather than using it
240 2013-06-06 09:44:14 <CodeShark> in the short term, it can be profitable
241 2013-06-06 09:44:19 <FluffySheap> which is also similar to real world mining
242 2013-06-06 09:44:47 <FluffySheap> I have wondered about that too
243 2013-06-06 09:44:54 <CodeShark> it would be nice if general purpose computing equipment weren't becoming pretty much useless for mining
244 2013-06-06 09:45:02 <FluffySheap> theoretically, as the mining dries up, most mining income comes from transact fees
245 2013-06-06 09:45:06 <FluffySheap> but
246 2013-06-06 09:45:17 <CodeShark> I think the original intention was that mining would be done on general purpose hardware
247 2013-06-06 09:45:25 <CodeShark> but that's becoming less and less attractive
248 2013-06-06 09:45:30 <FluffySheap> if mining dries up and starts to lose money for everyone then who will bother doing it
249 2013-06-06 09:45:35 <FluffySheap> and then there is a 51% attack prospect
250 2013-06-06 09:45:38 <FluffySheap> unless I misunderstand something
251 2013-06-06 09:45:50 <CodeShark> if people stop doing it, the difficulty comes back down
252 2013-06-06 09:45:57 <CodeShark> and it becomes once again more attractive
253 2013-06-06 09:46:03 <FluffySheap> right, but the bounty keeps dropping forever
254 2013-06-06 09:46:10 <FluffySheap> eventually, all coins are gone
255 2013-06-06 09:46:25 <CodeShark> fees will go up
256 2013-06-06 09:46:44 <FluffySheap> but that depends on coins being spent, rather than hoarded
257 2013-06-06 09:46:47 <FluffySheap> right?
258 2013-06-06 09:48:42 <CodeShark> as long as the transaction fees for bitcoin are competitive with other methods of transmitting value, it will be attractive to people
259 2013-06-06 09:49:33 <CodeShark> and if people feel like bitcoin lacks liquidity, I wonder just how much they will want to hoard
260 2013-06-06 09:53:33 <FluffySheap> hm, cgminer source for sha2.c looks like the ordinary fips implementation
261 2013-06-06 09:53:45 <FluffySheap> oh, maybe they didn't bother with it for cpu implementation
262 2013-06-06 09:54:38 <FluffySheap> too bad as it would be easier to understand than the CL
263 2013-06-06 09:56:17 <UukGoblin> could err someone fix amphipod plz? :-]
264 2013-06-06 10:06:13 <FluffySheap> ah, I see, in cgminer opencl. 14 constant W's, 2 nonce optimized, an odd 17 reduced-complexity and then 31 full-complexity.
265 2013-06-06 10:09:57 <FluffySheap> but this would only apply to first iteration, right? second one would need the full version, since first part of it will be all random data, then a short block of zeroes, then what appears to be 48 more bytes of essentially random data.
266 2013-06-06 10:18:33 <warren> https://github.com/bitcoin/bitcoin/pull/2651 It appears this needs more work, but what is the likelihood of this approach being accepted?
267 2013-06-06 10:36:10 <CodeShark> translation table frameworks should support printf style specifiers and pluralization :)
268 2013-06-06 10:38:17 <CodeShark> that's to say, the translation tables should contain all the specifiers
269 2013-06-06 11:02:07 <MKCoin> o:
270 2013-06-06 11:02:07 <MKCoin> test successful
271 2013-06-06 11:02:29 <BlueMatt> those are weekly
272 2013-06-06 11:19:37 <jgarzik> mornin'
273 2013-06-06 11:19:47 <CodeShark> hi :)
274 2013-06-06 11:32:32 <Vinnie_win_q> dafuq
275 2013-06-06 11:32:38 <Vinnie_win_q> you two canoodling in here now?
276 2013-06-06 11:35:50 <helo> would sacrifice-to-miner motivate users of large mining pools to sabotage assurance contracts?
277 2013-06-06 11:36:10 <CodeShark> Vinnie_win: what part do you find odd? the fact that it is those particular two? that it's taking place here? or that it's happening now?
278 2013-06-06 11:36:11 <helo> and could that be a good thing? ;)
279 2013-06-06 11:36:41 <Vinnie_win> CodeShark: I was referring to you and Jeff.
280 2013-06-06 11:37:12 <CodeShark> if canoodling means saying "mornin'" and then disappearing, then yes - I guess Jeff was canoodling :p
281 2013-06-06 11:37:24 <Vinnie_win> Looks like your relationship has blossomed into a full-blown bromance
282 2013-06-06 11:38:06 <Vinnie_win> Anyway...good morning
283 2013-06-06 11:38:20 <CodeShark> morning, eh? no wonder it's getting bright outside
284 2013-06-06 11:38:27 <CodeShark> I was beginning to wonder
285 2013-06-06 11:38:57 <CodeShark> oh yeah, it's that whole earth rotation thing
286 2013-06-06 11:42:49 <jgarzik> um, ok
287 2013-06-06 11:43:28 <TD> helo: ?
288 2013-06-06 11:43:32 <TD> what do you mean ?
289 2013-06-06 11:44:57 <dugo> 15:35 < CodeShark> if canoodling means saying "mornin'" and then disappearing, then yes - I guess Jeff was canoodling :p
290 2013-06-06 11:45:03 <helo> TD: maybe i need to read more about assurance contracts via bitcoin... but basically, they pledge that A will occur, or the bitcoin they put in a particular place will be forefeit, right?
291 2013-06-06 11:45:15 <Vinnie_win> dugo: I think he was referring to the assurance contracts
292 2013-06-06 11:45:21 <CodeShark> lol
293 2013-06-06 11:45:30 <TD> no
294 2013-06-06 11:45:33 <TD> that's not what they do
295 2013-06-06 11:45:50 <Vinnie_win> Alright this place is dead I'm moving the party to #github
296 2013-06-06 11:46:13 <helo> i'm using the wrong term... what was "sacrifice-to-miner" being discussed for?
297 2013-06-06 11:46:22 <TD> anonymous passports?
298 2013-06-06 11:46:37 <TD> you create a provably valuable object that contains a public key, to which you have the private part
299 2013-06-06 11:46:51 <TD> now you can sign challenges with it. if you misbehave it can be blacklisted.
300 2013-06-06 11:46:59 <TD> sort of a self-minted certificate
301 2013-06-06 11:47:57 <helo> ahh, it was jeff re: fidelity bonds
302 2013-06-06 11:50:00 <helo> oh, the sacrifice happens at the beginning to create the identity
303 2013-06-06 11:50:13 <TD> yes
304 2013-06-06 11:50:27 <helo> sorry, got some concepts mixed up
305 2013-06-06 11:53:40 <jgarzik> helo, Yes, that was me
306 2013-06-06 11:53:55 <jgarzik> I've been looking at sacrifice-to-create-decentralized-identity
307 2013-06-06 11:54:11 <TD> jgarzik: cool. i'm in discussions with some guys from Tor and the EFF at the moment on that topic actually
308 2013-06-06 11:54:28 <jgarzik> Our ecosystem needs a decentralized identity system, cryptographically secured.
309 2013-06-06 11:54:33 <helo> i do like the idea where a company guarantees the security of some data (most directly a private key itself) by sending a bunch of bitcoin to the key. so if a dishonest person has access to the data (including or being the key), the issuer can see (in the blockchain when the bounty is transferred) that the key isn't held securely.
310 2013-06-06 11:54:34 <TD> jgarzik: the Tor guy doesn't think bitcoin is private enough, he isn't really sold on the idea. he wants some extra layer that uses chaumian tokens, maybe
311 2013-06-06 11:55:02 <TD> jgarzik: i prefer a pure bitcoin approach as there's no need for any additional middlemen, and i feel it's private enough for this and can be made more private later.
312 2013-06-06 11:55:12 <jgarzik> Start out with a proof of identity creation, possibly a sacrifice transaction. ECDSA may prove you created that.
313 2013-06-06 11:55:19 <helo> yeah, provably paying money to create an identity would cut down on scammers in -otc for sure (if such an identity was required for entry)
314 2013-06-06 11:55:27 <TD> helo: right
315 2013-06-06 11:55:28 <jgarzik> Attach key-value pairs, which are other data (PGP signatures) or remote attestations
316 2013-06-06 11:55:30 <TD> helo: there are lots of uses
317 2013-06-06 11:56:00 <TD> jgarzik: well the sacrifice transaction(s) have public keys in them anyway, in the inputs, assuming you sacrifice an address output
318 2013-06-06 11:56:07 <TD> so it doesn't need to be complicated
319 2013-06-06 11:56:09 <jgarzik> e.g. Identity Validation Corp, Inc. can check my identity, then digitally sign my identity as being verified to a certain level
320 2013-06-06 11:56:34 <jgarzik> then, if you trust Identity Validation Corp and their digital sig, you can trust (to that level) my decentralized id
321 2013-06-06 11:56:46 <TD> jgarzik: well, are you talking about the anonymous passports/fidelity bonds/proofs of sacrifices, etc? if so then there's no need for any middlemen
322 2013-06-06 11:56:54 <TD> jgarzik: or are you talking about a citizen PKI type thing?
323 2013-06-06 11:57:29 <jgarzik> TD, I suppose you could call this an anonymous passport. In my scheme, there is no need for middlemen to manage this identity data.
324 2013-06-06 11:57:52 <jgarzik> TD, However, a useful ecosystem of third parties may collaborate to provide digitally signed attestations and services associated with that identity
325 2013-06-06 11:57:59 <TD> i see
326 2013-06-06 11:58:24 <TD> i think a good v1 feature set would be - app that makes the sacrifices, server app that can check them and query a DNS server that vends blacklists, email RBL style.
327 2013-06-06 11:58:56 <TD> + an http/browser extension to make it all transparent, and then some patches to mediawiki, wordpress, etc so you can post comments via Tor with your self-made decentralised identity
328 2013-06-06 11:59:06 <TD> it's a fairly big project, but nothing complicated
329 2013-06-06 11:59:16 <jgarzik> You can KYC with org A, then use KYC-requiring orgs B and C, without giving out identity to everyone (assuming they trust A's digital signature and underlying identity services)
330 2013-06-06 11:59:30 <jgarzik> but yes, this is self-made decentralized identity
331 2013-06-06 11:59:39 <jgarzik> it _must_ be, otherwise there's no privacy or control
332 2013-06-06 11:59:41 <TD> if it's self made and decentralised, there's no KYC
333 2013-06-06 11:59:53 <TD> i have a feeling we're discussing two different system simultaneously :)
334 2013-06-06 12:00:08 <jgarzik> TD, No, KYC is an easy opt-in system, if this framework exists
335 2013-06-06 12:00:24 <jgarzik> TD, KYC can be opt-in and digitally provable.
336 2013-06-06 12:00:48 <jgarzik> TD, but as with any decentralized identity, you don't have to use that id for all websites
337 2013-06-06 12:02:55 <helo> it would take quite a bit of confidence that the destruction of bitcoin is absolutely benign... i think i'm convinced that it is, but it seems to be a common point of contention
338 2013-06-06 12:03:25 <TD> helo: you don't need to destroy bitcoins for the proof-of-sacrifice case. you can sacrifice the coins to miner fees
339 2013-06-06 12:03:31 <TD> then they recirculate into the economy
340 2013-06-06 12:03:40 <helo> how does one create such a transaction?
341 2013-06-06 12:03:47 <TD> the output value fields are all zeros
342 2013-06-06 12:03:55 <helo> oh of course
343 2013-06-06 12:04:06 <TD> you then provide the sacrifice transaction, along with the input transactions, and the merkle branches proving acceptance of all of them
344 2013-06-06 12:04:25 <TD> this can be statically checked with only a copy of the block headers (SPV security). so it's lightweight enough to run on almost any server.
345 2013-06-06 12:04:38 <helo> very nice
346 2013-06-06 12:05:30 <jgarzik> yep
347 2013-06-06 12:05:50 <TD> good morning gavinandresen
348 2013-06-06 12:05:56 <gavinandresen> good morning
349 2013-06-06 12:07:01 <jgarzik> Is anyone else having trouble getting HEAD to build and run Qt GUI?
350 2013-06-06 12:07:08 <jgarzik> Diapolo reported that
351 2013-06-06 12:09:40 <gavinandresen> I'm gitian-building the paymentrequest branch this morning, which I rebased onto HEAD yesterday, I'll let you know if I run into issues
352 2013-06-06 12:09:56 <kfreds> I just think it's so neat that so many people are literally working full time on making Bitcoin (the system, not the services around it) better.
353 2013-06-06 12:10:18 <kfreds> That's awesome. You guys, the developers are awesome. Thank you :)
354 2013-06-06 12:11:06 <kfreds> Just wanted to say that since I've been using it for a long time, and haven't thanked people yet :)
355 2013-06-06 12:14:15 <helo> built fine from git pull; make on ubuntu 13.04
356 2013-06-06 12:14:34 <helo> (and appeared to run fine)
357 2013-06-06 12:15:48 <jgarzik> gavinandresen, great
358 2013-06-06 12:16:17 <TD> kfreds: you're welcome
359 2013-06-06 12:20:40 <gavinandresen> jgarzik: No problem gitian-building for windows...
360 2013-06-06 12:20:49 <jgarzik> grau wrote, on trolltalk: Block 227930 enforces V2 check, agree?
361 2013-06-06 12:20:52 <jgarzik> ACTION forgets
362 2013-06-06 12:21:11 <jgarzik> ACTION would have to rescan the block chain
363 2013-06-06 12:23:25 <grau> jgarzik: I missed it earlier and do not know if that event was published. Not too important since it would have caused a fork long ago if was in mismatch, just curious.
364 2013-06-06 12:23:44 <jgarzik> grau, ISTR we added a checkpoint
365 2013-06-06 12:23:52 <grau> I mean a fork beetwen Satoshi and BOP certainly
366 2013-06-06 12:24:32 <msvb-lab> Hello folks, happy to see that Bitcoin is using gitian.
367 2013-06-06 13:04:15 <wallet43> if you had a half-node which prunes data would the relevant data be only chainstate + blockheader?
368 2013-06-06 13:36:45 <EvilPete> jgarzik: 227930 matches my recollection but its getting fuzzy now.
369 2013-06-06 13:37:02 <jgarzik> ack
370 2013-06-06 13:40:11 <EvilPete> I remember a checkpoint was added after the 8.x -> 7.x miner rollback trees reorganized
371 2013-06-06 13:40:43 <EvilPete> 0.8 -> 0.7 close enough
372 2013-06-06 13:48:07 <helo> i suppose the perceived value of an assurance contract could be clouded by deflation
373 2013-06-06 13:48:50 <helo> i.e. if someone sacrificed 10btc on an identity two years ago, today that identity would seem highly reliable
374 2013-06-06 13:50:38 <helo> but it would be equivalent to a 1btc identity today
375 2013-06-06 13:52:29 <helo> nanotube: bah, i keep using the wrong term... not "assurance contracts"... but "fidelity bonds"
376 2013-06-06 13:52:38 <helo> argh, wrong chan
377 2013-06-06 13:58:03 <cjsw3> if i create a wallet with a keypool of 1000. what would cause a new address to be generated?
378 2013-06-06 13:58:24 <lianj> cjsw3: if it runs out
379 2013-06-06 13:58:28 <cjsw3> is there some form of guarantee one won't be created until ~1000 transactions?
380 2013-06-06 13:59:34 <shesek> I think it also makes sure it always has some extra ones, doesn't it?
381 2013-06-06 14:00:00 <cjsw3> yeah i'm thinking about backup strategies
382 2013-06-06 14:00:56 <helo> cjsw3: a new address is generated every time an address is used in the pool, regardless of keypool size
383 2013-06-06 14:01:31 <cjsw3> helo: eek. that's what i was afraid of
384 2013-06-06 14:01:39 <gavinandresen> Somebody help me understand Linux packaging??? I need a statically compiled libprotobuf for the paymentrequest gitian linux build, and it looks like http://packages.debian.org/squeeze/libprotobuf-dev isn't giving it to me
385 2013-06-06 14:01:47 <rdponticelli_> cjsw3: You can use -keypool=0 to avoid it
386 2013-06-06 14:02:14 <helo> cjsw3: this makes backup strategies easy though... you just have to back up every 1000 transactions+addresses
387 2013-06-06 14:02:53 <helo> cjsw3: as after 999 transactions+addresses, the 1000 addresses sitting in your keypool haven't ever been used for anything, so don't need to be backed up
388 2013-06-06 14:03:01 <cjsw3> helo: well not if you mistakenly use one of the addresses created since the last backup? or they are always accessed FIFO?
389 2013-06-06 14:03:12 <helo> yes, FIFO
390 2013-06-06 14:06:54 <rdponticelli> gavinandresen: Are you sure it isn't there?
391 2013-06-06 14:07:15 <rdponticelli> It should be...
392 2013-06-06 14:07:20 <gavinandresen> rdponticelli: I've got a /usr/lib/libprotobuf.la /usr/lib/libprotobuf.so ??? but no .a
393 2013-06-06 14:07:29 <gavinandresen> (is .la symbols for the .so ?)
394 2013-06-06 14:08:07 <rdponticelli> Try dpkg-query -S libprotobuf.a
395 2013-06-06 14:08:18 <rdponticelli> But it should be there...
396 2013-06-06 14:08:25 <gavinandresen> dpkg: *libprotobuf.a* not found.
397 2013-06-06 14:08:33 <rdponticelli> :/
398 2013-06-06 14:09:24 <rdponticelli> I have it there in debian testing...
399 2013-06-06 14:10:21 <petertodd> helo: regarding fidelity bonds and the exchange rate, it would be really useful if exchanges, particularly mt. gox, digitally signed price information
400 2013-06-06 14:10:29 <gavinandresen> sounds like I'll have to add it as an explicit d
401 2013-06-06 14:11:40 <petertodd> helo: oh, and I should add, also timestamped those signatures and keys
402 2013-06-06 14:14:18 <rdponticelli> gavinandresen: According to the debian package system, it should be there: http://packages.debian.org/search?suite=squeeze&searchon=contents&keywords=libprotobuf.a
403 2013-06-06 14:15:29 <gavinandresen> rdponticelli: gitian doesn't use squeeze, it uses??? uh??? that older one. 10.04, I think
404 2013-06-06 14:16:36 <helo> petertodd: sounds reasonable... thanks
405 2013-06-06 14:25:19 <ryan-c> Anyone know of a web service that will give me the transactions where A given address was an input?
406 2013-06-06 14:25:43 <beethoven8201> blockchain ?
407 2013-06-06 14:25:49 <beethoven8201> .info
408 2013-06-06 14:25:52 <beethoven8201> you can use their api
409 2013-06-06 14:26:00 <ryan-c> which api?
410 2013-06-06 14:26:11 <ryan-c> i didn't see anything relevant at blockchain.info/q
411 2013-06-06 14:26:12 <nsh> ;;google blockchain.info API guide
412 2013-06-06 14:26:14 <beethoven8201> google blockchain api
413 2013-06-06 14:26:14 <gribble> Bitcoin Developer API's - Blockchain.info: <http://blockchain.info/api>; Bitcoin JSON RPC API - blockchain.info: <http://blockchain.info/api/json_rpc_api>; Block Explorer API - blockchain.info: <http://blockchain.info/api/blockchain_api>
414 2013-06-06 14:29:38 <ryan-c> http://blockchain.info/q/pubkeyaddr < this is actually what I wanted
415 2013-06-06 14:32:46 <Zoop_> a one?
416 2013-06-06 14:32:58 <ryan-c> hm?
417 2013-06-06 14:33:12 <Zoop_> that link only shows me '1'
418 2013-06-06 14:33:18 <Zoop_> on the top left corner
419 2013-06-06 14:33:53 <Zoop_> source code only shows '1' as well
420 2013-06-06 14:34:07 <ryan-c> Zoop_: http://blockchain.info/q/pubkeyaddr/1AddressGoesHere
421 2013-06-06 14:34:15 <Zoop_> oh
422 2013-06-06 14:34:19 <Zoop_> i get it now
423 2013-06-06 14:34:22 <Zoop_> -__-
424 2013-06-06 14:34:25 <ryan-c> Given an address that has spent, it returns the public key
425 2013-06-06 14:34:40 <Zoop_> thought it was some statistics about pubkey or wtv
426 2013-06-06 14:34:50 <ryan-c> on blockexplorere, you can do this http://blockexplorer.com/q/mytransactions/, but then you have to parse it
427 2013-06-06 14:53:20 <EvilPete> Wow, I hadn't realized just how much of a difference a SSD vs HDD made to the bitcoin-qt client on OSX. Subjectively it feels like between 1 and 2 orders of magnitude. eg: startup validation is seconds vs several minutes.