1 2013-07-14 00:26:47 <gribble> Error: "refesh" is not a valid command.
2 2013-07-14 00:26:47 <owowo> ;;refesh
3 2013-07-14 02:59:51 <saivann> Network analysis attack? https://bitcointalk.org/index.php?topic=254615.40
4 2013-07-14 03:05:46 <imton> sipa: you addrindex, did you change anything? should i recompile?
5 2013-07-14 03:06:00 <imton> *your
6 2013-07-14 03:16:49 <DiabloD3> fuck.
7 2013-07-14 03:16:55 <DiabloD3> gmaxwell: I NEED MORE HPMOR
8 2013-07-14 03:16:56 <pigeons> saivann: maybe that will encourage coin control merging
9 2013-07-14 03:17:01 <pigeons> no one sends me free money
10 2013-07-14 03:17:22 <DiabloD3> gmaxwell: also, I love how the characters are slowly learning from harry
11 2013-07-14 03:17:33 <DiabloD3> gmaxwell: you know what I dont get, btw?
12 2013-07-14 03:17:45 <DiabloD3> gmaxwell: the ONLY change to the world is harry potter was raised by sane parents
13 2013-07-14 03:17:59 <DiabloD3> gmaxwell: and he know understands math and science voodoo.
14 2013-07-14 03:18:03 <DiabloD3> er, now
15 2013-07-14 03:18:08 <DiabloD3> gmaxwell: everyone else is the same
16 2013-07-14 03:18:55 <DiabloD3> gmaxwell: yet, the dark lord is upping his game as fast as fucking possible
17 2013-07-14 03:19:15 <brendyn> Uh I'm pretty sure loads of characters are changed significantly, if only due to consequence of writing style
18 2013-07-14 03:20:33 <saivann> pigeons : maybe, I just hope that this does not become the next sensationalist subject about Bitcoin before it's actually improved.
19 2013-07-14 03:20:35 <DiabloD3> brendyn: well, yes and no
20 2013-07-14 03:20:54 <DiabloD3> brendyn: you can see the new improved harry potter's influence on them
21 2013-07-14 03:21:21 <DiabloD3> they enter into the story as the original characters, but they veer off course soon as harry potter fiddles with their character sheets
22 2013-07-14 03:21:41 <brendyn> DiabloD3: Quirell is also a bit of a rationalist. I don't remember much of the original quirell, was he like that?
23 2013-07-14 03:22:25 <DiabloD3> I havent read the books or seen the movies, but what Ive heard from harry potter fans that have started reading hpmor
24 2013-07-14 03:22:37 <DiabloD3> quirell has a role.
25 2013-07-14 03:22:51 <DiabloD3> a much expanded much bigger actually useful to the plot role
26 2013-07-14 03:23:15 <DiabloD3> I should actually sit down and read the original books, but I imagine I'll hate them
27 2013-07-14 03:23:30 <DiabloD3> fantasy novels that are full of plot holes and just make no fucking sense I cant deal with
28 2013-07-14 03:23:42 <brendyn> I can tell you then that the characters are changed in certain ways as a consequence of Eliezer being very different to Rowling
29 2013-07-14 03:23:50 <DiabloD3> brendyn: probably
30 2013-07-14 03:24:01 <DiabloD3> and I think eliezer is a better author, although, uh
31 2013-07-14 03:24:08 <brendyn> I'm speaking from from knowledge you dont have
32 2013-07-14 03:24:12 <DiabloD3> Im not sure how to quite put it but
33 2013-07-14 03:24:19 <DiabloD3> he has a writing quirk.
34 2013-07-14 03:24:45 <DiabloD3> Im not even sure how to explain it
35 2013-07-14 03:25:12 <brendyn> It stems from his massive corpus of rationalist knowledge
36 2013-07-14 03:25:20 <DiabloD3> I think so too
37 2013-07-14 03:25:23 <brendyn> It's made him a unique kind of person
38 2013-07-14 03:25:33 <DiabloD3> I mean, hes gone off the deep end
39 2013-07-14 03:25:37 <DiabloD3> how the hell does he even function irl?
40 2013-07-14 03:25:38 <brendyn> uh?
41 2013-07-14 03:25:52 <brendyn> what is wrong?
42 2013-07-14 03:26:01 <DiabloD3> well, nothing, in theory
43 2013-07-14 03:26:14 <DiabloD3> I mean, Ive read authors who were completely ... something irl.
44 2013-07-14 03:26:21 <DiabloD3> And I enjoyed their writings
45 2013-07-14 03:26:29 <DiabloD3> And I enjoy his writings
46 2013-07-14 03:26:33 <brendyn> I have no idea what your objection is
47 2013-07-14 03:26:40 <DiabloD3> I dont have an objection
48 2013-07-14 03:26:48 <DiabloD3> I just have no clue why the fuck he isnt massively rich by now
49 2013-07-14 03:26:55 <brendyn> what's that about the deep end then?
50 2013-07-14 03:27:05 <DiabloD3> brendyn: okay like
51 2013-07-14 03:27:18 <DiabloD3> ever talk to someone who is a lisp programmer?
52 2013-07-14 03:27:25 <DiabloD3> like, really one, that codes lisp every day
53 2013-07-14 03:27:30 <DiabloD3> (they are rare)
54 2013-07-14 03:27:31 <brendyn> I code lisp
55 2013-07-14 03:27:38 <DiabloD3> well you're no help.
56 2013-07-14 03:27:42 <brendyn> Atleast I'm learning
57 2013-07-14 03:27:57 <DiabloD3> well, you havent met a Real Programmer (???) until you have met a real lisp programmer
58 2013-07-14 03:28:07 <brendyn> yeah, ok
59 2013-07-14 03:28:07 <DiabloD3> it escapes from the part of the brain that they do programming in
60 2013-07-14 03:28:15 <DiabloD3> it intrudes into all parts of their lives
61 2013-07-14 03:28:25 <DiabloD3> in ways that cannot be easily explained
62 2013-07-14 03:29:09 <DiabloD3> lets try the opposite end of the spectrum
63 2013-07-14 03:29:19 <DiabloD3> ever meet someone thats read all of ayn rand's works and actually understands them?
64 2013-07-14 03:29:27 <brendyn> oh jesus
65 2013-07-14 03:29:32 <brendyn> no i haven't
66 2013-07-14 03:29:37 <DiabloD3> BE GLAD YOU HAVE NOT
67 2013-07-14 03:29:44 <DiabloD3> IT IS NOT A PLESANT EXPERIENCE
68 2013-07-14 03:30:02 <DiabloD3> but its like, every part of their lives just.... I dont know.
69 2013-07-14 03:30:11 <brendyn> But I think Lisp is legit.
70 2013-07-14 03:30:18 <DiabloD3> They are clearly not living in the same plane of reality the rest of us are
71 2013-07-14 03:30:35 <DiabloD3> they see the world in such a fundamentally different way
72 2013-07-14 03:31:05 <DiabloD3> and its not even wrong.
73 2013-07-14 03:31:14 <brendyn> Surely it is?
74 2013-07-14 03:31:26 <DiabloD3> well, the ayn rand people, sure, they're really wrong
75 2013-07-14 03:31:32 <DiabloD3> I just mean the whole... I dont know.
76 2013-07-14 03:31:43 <DiabloD3> I suspect its a form of religion almost.
77 2013-07-14 03:33:28 <DiabloD3> except instead of the colors "good" and "evil" you get shit like "charm" and "strange" or whatever
78 2013-07-14 03:33:41 <brendyn> you talking about a type of person i dont know about. someone that has read all of Ayn's stuff but sort of isnt proper objectivit?
79 2013-07-14 03:34:05 <DiabloD3> brendyn: no, Im saying a person who has read a subject to such extreme levels they... I dont know.
80 2013-07-14 03:34:10 <DiabloD3> they _become it_
81 2013-07-14 03:34:41 <brendyn> Sounds like you are judging people on very socially oriented criteria
82 2013-07-14 03:34:50 <DiabloD3> not quite
83 2013-07-14 03:34:54 <brendyn> Eliezer concerns himself with real problems
84 2013-07-14 03:35:03 <DiabloD3> social stuff is very built into the human existence
85 2013-07-14 03:35:07 <DiabloD3> we are shaped by other people
86 2013-07-14 03:35:18 <DiabloD3> I mean, literally, we are what other people think of us, both the good and the bad
87 2013-07-14 03:35:51 <DiabloD3> (and if we arent that, we eventually will become that unless we have a very strong will)
88 2013-07-14 03:36:50 <brendyn> You've gone way off track now.
89 2013-07-14 03:37:24 <brendyn> to the extent that I can't see your ideas in much fidelity. I'm just curious as to how you apply this to Eliezer
90 2013-07-14 03:37:54 <DiabloD3> well, Eliezer is one of these people I think who have been fundementally changed by something that isn't experienced through social contact
91 2013-07-14 03:38:07 <DiabloD3> he became a set of logical ideals at his core.
92 2013-07-14 03:38:32 <brendyn> Seems ok to me.
93 2013-07-14 03:38:51 <DiabloD3> I dunno, Ive never talked to him, but if he can write like that, I cant imagine what hes like irl
94 2013-07-14 03:39:01 <DiabloD3> theres no way in hell he can turn that off outside of writing
95 2013-07-14 03:39:02 <brendyn> Logical consistancy is something to strive for, and it turns out how have to change a lot to even get close
96 2013-07-14 03:39:20 <DiabloD3> Oh don't get me wrong, its not a bad thing
97 2013-07-14 03:39:24 <DiabloD3> Its just rare
98 2013-07-14 03:39:39 <brendyn> DiabloD3: Go type his name into Youtube and see him talk. It's bad to let yourself imagine what people are.
99 2013-07-14 03:39:55 <brendyn> I did the same, and then saw him and was like "Oh wow, I really didn't imagine him like that"
100 2013-07-14 03:43:33 <DiabloD3> http://www.youtube.com/watch?v=TwqYB1uzcU4
101 2013-07-14 03:43:41 <DiabloD3> hrm, he seeems normal
102 2013-07-14 03:44:02 <DiabloD3> btw, I have this paused at 2:44
103 2013-07-14 03:44:13 <DiabloD3> ACTION selects sequence 1
104 2013-07-14 03:44:30 <DiabloD3> AHAHA I KNEW IT
105 2013-07-14 03:44:49 <gwillen> DiabloD3: he talks the way he writes, but he does seem surprisingly normal to meet him
106 2013-07-14 03:45:00 <DiabloD3> ...
107 2013-07-14 03:45:07 <DiabloD3> so did gmaxwell just convert the entire channel or what?
108 2013-07-14 03:45:22 <gwillen> I would not describe myself as a 'convert'
109 2013-07-14 03:45:28 <warren> convert?
110 2013-07-14 03:45:29 <gwillen> and gmaxwell is not responsible
111 2013-07-14 03:45:47 <DiabloD3> warren: hes why a LOT of people in here know about hpmor
112 2013-07-14 03:46:16 <warren> I have no idea what HPMOR is.
113 2013-07-14 03:46:29 <DiabloD3> warren: REALLY?
114 2013-07-14 03:46:32 <brendyn> warren: fanfiction. go read it
115 2013-07-14 03:46:38 <gwillen> I read HPMoR long before I met gmaxwell
116 2013-07-14 03:46:45 <DiabloD3> http://hpmor.com/
117 2013-07-14 03:46:48 <gwillen> and I think I read lesswrong before I read hpmor
118 2013-07-14 03:46:52 <warren> won't that require having read the the non-fan-fiction first?
119 2013-07-14 03:46:53 <DiabloD3> warren: YOU MUST READ THIS NOW
120 2013-07-14 03:46:57 <DiabloD3> warren: nope
121 2013-07-14 03:46:57 <gwillen> although I no longer remember
122 2013-07-14 03:47:02 <DiabloD3> I have not read or seen harry potter
123 2013-07-14 03:47:05 <warren> oh
124 2013-07-14 03:47:06 <warren> o
125 2013-07-14 03:47:07 <warren> ok
126 2013-07-14 03:47:09 <gwillen> DiabloD3: huh, that's interesting
127 2013-07-14 03:47:10 <DiabloD3> yet I find this story engaging and worth reading
128 2013-07-14 03:47:18 <gwillen> I had wondered if someone who didn't know HP would enjoy HPMoR
129 2013-07-14 03:47:20 <DiabloD3> the conversation went like this
130 2013-07-14 03:47:27 <DiabloD3> <gmaxwell> read this harry potter fanfic
131 2013-07-14 03:47:31 <DiabloD3> <me> I hate harry potter
132 2013-07-14 03:47:36 <DiabloD3> <gmaxwell> good, you'll like this
133 2013-07-14 03:47:44 <DiabloD3> and thus, I read it.
134 2013-07-14 03:48:00 <DiabloD3> and now I hate gmaxwell because Im suffering from new episode itis.
135 2013-07-14 03:48:02 <warren> I was working on bitcoin-ruby, but apparently this is the most important thing I need to do according to gmaxwell, forrestv and DiabloD3, then I need to switch contexts.
136 2013-07-14 03:48:13 <DiabloD3> warren: yes, its more important than that
137 2013-07-14 03:48:18 <DiabloD3> code for a dead language can wait
138 2013-07-14 03:48:18 <warren> oh my
139 2013-07-14 03:49:16 <DiabloD3> btw
140 2013-07-14 03:49:23 <DiabloD3> the version I imagined of this guy
141 2013-07-14 03:49:37 <DiabloD3> had a longer greyer beard.
142 2013-07-14 03:49:37 <warren> this is surprising, "produced with the consent and at the request of the author."
143 2013-07-14 03:49:38 <warren> really?
144 2013-07-14 03:49:42 <pigeons> Confucious say: Rockstar programmer are just as you and me but they can also able write insecure Ruby code.
145 2013-07-14 03:49:42 <warren> I thought she sued people a lot.
146 2013-07-14 03:49:54 <DiabloD3> warren: nope, she liked it so goddamned much she greenlighted it
147 2013-07-14 03:50:04 <warren> DiabloD3: wow
148 2013-07-14 03:50:17 <DiabloD3> yeah, I still dont understand that
149 2013-07-14 03:50:44 <gwillen> DiabloD3: you can always start reading some other fics
150 2013-07-14 03:50:45 <warren> well, if it really is good, and it's a derivative work,she can collect royalties for anything built from it that makes income
151 2013-07-14 03:50:51 <gwillen> DiabloD3: if you like D&D, I recommend Harry Potter and the Natural 20
152 2013-07-14 03:51:03 <gwillen> DiabloD3: I think I saw it from EY's recommended list
153 2013-07-14 03:51:05 <DiabloD3> gwillen: Ive been told thats good, but... I dont really like harry potter
154 2013-07-14 03:51:18 <gmaxwell> gwillen: HP&N20 is fun ... though its also incomplete and now coming along slowly.
155 2013-07-14 03:51:26 <gwillen> DiabloD3: but you like HPMoR apparently, and the author of HPMoR recommended it, so!
156 2013-07-14 03:51:34 <gwillen> gmaxwell: it updated today, is the only reason I even thought of it
157 2013-07-14 03:52:27 <DiabloD3> you know what else is incomplete and slow?
158 2013-07-14 03:52:33 <warren> bitcoin?
159 2013-07-14 03:52:35 <DiabloD3> shinji and warhammer40k.
160 2013-07-14 03:52:39 <gwillen> gmaxwell: also, technically HPN20 is done
161 2013-07-14 03:52:46 <gwillen> gmaxwell: we're now on Harry Potter and the Confirmed Critical
162 2013-07-14 03:56:16 <DiabloD3> btw
163 2013-07-14 03:56:17 <DiabloD3> this video
164 2013-07-14 03:56:23 <DiabloD3> this vest is clearly too small for him
165 2013-07-14 03:58:10 <DiabloD3> gmaxwell: I just had a horrifying idea
166 2013-07-14 03:58:23 <DiabloD3> what if the world was as weird as fantasy authors make it out to be
167 2013-07-14 03:59:19 <warren> TradeFortress: how goes the deadlock issue?
168 2013-07-14 04:03:08 <TradeFortress> warren, seems to have resolved but only been a while
169 2013-07-14 04:03:40 <warren> TradeFortress: let me guess, you're stuck on master because you can't downgrade to 0.8.3 for safety because of the privkeys written by the refactor?
170 2013-07-14 04:04:11 <warren> TradeFortress: I mean, it's totally awesome that you discovered this issue before 0.9, you saved the world a lot of grief.
171 2013-07-14 04:04:13 <DiabloD3> I should upgrade to 0.8.3
172 2013-07-14 04:04:28 <TradeFortress> yep lol. bitcoin foundation should buy me a car :D
173 2013-07-14 04:04:33 <DiabloD3> TradeFortress: no no no no
174 2013-07-14 04:04:34 <DiabloD3> bad TradeFortress
175 2013-07-14 04:04:41 <DiabloD3> you must specify a tesla model s
176 2013-07-14 04:04:47 <TradeFortress> lol
177 2013-07-14 04:05:56 <warren> TradeFortress: if nobody suggested it yet, 0.8.3 + privkey refactor + refactor fix might be safer than bitcoin master.
178 2013-07-14 04:06:27 <TradeFortress> I don't think the refactor fix lets people go back
179 2013-07-14 04:06:54 <warren> TradeFortress: yeah, that's why I suggest 0.8.3 + only refactor fix
180 2013-07-14 04:07:58 <warren> TradeFortress: although if you're stable with master + shared lock fix then it's better for the world.
181 2013-07-14 04:08:05 <gmaxwell> warren: uh the refactor fix isn't relevant to 0.8.3.
182 2013-07-14 04:08:21 <warren> gmaxwell: it is if he's stuck with the "broken" wallet.dat
183 2013-07-14 04:08:37 <gmaxwell> then the refactor needs to be backported too.
184 2013-07-14 04:08:43 <warren> gmaxwell: he accidentally deployed bitcoin master into production without realizing it
185 2013-07-14 04:08:54 <gmaxwell> ::nods::
186 2013-07-14 04:08:55 <warren> gmaxwell: yeah, backport is trivial
187 2013-07-14 07:53:20 <sipa> imton: the disk format changed, so it's incompatible with older versions
188 2013-07-14 07:54:07 <imton> sipa: ok, but???. what do you mean by "disk" ?
189 2013-07-14 07:56:56 <sipa> imton: database
190 2013-07-14 07:57:19 <sipa> the address index on disk created by earlier versions of my patch won't worj with newer
191 2013-07-14 08:07:00 <warren> "Added locks on the setpwalletRegistered functions in main.cpp and added an UnregisterAllWallets function."
192 2013-07-14 08:07:06 <warren> I can't find the pull request that brought this in.
193 2013-07-14 08:07:44 <sipa> do a git log, search for the 7 characters of the commitid
194 2013-07-14 08:07:58 <sipa> you shoukd find the merge commit that made the change
195 2013-07-14 08:08:12 <sipa> which usually gets the pullreq described in it
196 2013-07-14 08:08:43 <sipa> warren: btw, i also read (mlst of) hpmor, but i never read hp (i did watch the movies though)
197 2013-07-14 08:08:48 <sipa> *most of
198 2013-07-14 08:08:52 <warren> sipa: hah
199 2013-07-14 08:09:01 <warren> sipa: I'm resisting for now.
200 2013-07-14 08:09:26 <warren> sipa: I see it in git log but I don't see a merge for it
201 2013-07-14 08:11:18 <sipa> indeed, me too
202 2013-07-14 08:11:30 <warren> Does that mean this person has direct commit access?
203 2013-07-14 08:11:57 <warren> sipa: and this is what introduced the deadlock, right?
204 2013-07-14 08:12:53 <sipa> #2209
205 2013-07-14 08:12:55 <sipa> no
206 2013-07-14 08:13:36 <sipa> if it's a fast-forward update, a merge commit is not required
207 2013-07-14 08:17:17 <warren> oh, if the last rebase was done literally right before the merge?
208 2013-07-14 08:28:49 <sipa> yes
209 2013-07-14 10:05:55 <warren> hmm, does a git tree require a "master" branch?
210 2013-07-14 10:06:54 <sipa> do you mean 'git repository' instead of 'git tree' ?
211 2013-07-14 10:07:05 <warren> yeah
212 2013-07-14 10:07:58 <warren> thinking how to reorg the git repository here, given that we need to constantly rebase our protocol to newer versions of bitcoin, a "master" branch doesn't exactly work.
213 2013-07-14 10:08:29 <warren> rebase to every major release at least
214 2013-07-14 10:08:39 <warren> 0.8.3 -> 0.9
215 2013-07-14 10:08:56 <warren> 0.6 -> 0.8.3 -> 0.9
216 2013-07-14 10:13:22 <swulf--> can anyone explain what the deal is with transaction 2a0597e665ac3d1cabeede95cedf907934db7f639e477b3c77b242140d8cf728? how is that 2nd output legit?
217 2013-07-14 10:13:34 <swulf--> ie, why did nodes accept this block/transaction?
218 2013-07-14 10:14:21 <swulf--> I'm guessing because an output script can quite literally be anything and you need an inputscript to make sense of it?
219 2013-07-14 10:16:41 <sipa> output scripts are only validated when they're being spent
220 2013-07-14 10:16:51 <swulf--> yeah, thought so
221 2013-07-14 10:16:56 <sipa> there is no earlier point at which you can evaluate them properly
222 2013-07-14 10:16:59 <swulf--> does EQUALVERIFY or CHECKSIG stop the program evaluation?
223 2013-07-14 10:17:48 <sipa> OP_VERIFY stops evaluation if its input is not true
224 2013-07-14 10:17:56 <sipa> OP_EQUALVERIFY is OP_EQUAL + OP_VERIFY
225 2013-07-14 10:18:15 <sipa> there is also OP_CHECKSIGVERIFY which is OP_CHECKSIG + OP_VERIFY
226 2013-07-14 10:18:29 <sipa> so to answer your question: OP_EQUALVERIFY does, OP_CHECKSIG doesn't
227 2013-07-14 10:18:42 <swulf--> does VERIFY stop if the evaluation is true?
228 2013-07-14 10:18:46 <sipa> no
229 2013-07-14 10:19:11 <swulf--> does CHECKSIG modify the stack?
230 2013-07-14 10:19:35 <swulf--> i'm being lazy - i suppose i could just check the code :)
231 2013-07-14 10:19:37 <sipa> yes, it consumes a pubkey and a signature, and produces a true of false
232 2013-07-14 10:19:40 <sipa> *or
233 2013-07-14 10:20:28 <coingenuity> sipa: has anyone ever donated anything for all the time you take answering these questions?
234 2013-07-14 10:20:29 <swulf--> so that 2nd output of that script is going to require a bunch of OP_DUPs (or any infinite number of other solutions) to produce a correct program?
235 2013-07-14 10:20:59 <swulf--> sipa has helped me out a ton, if sipa gives me a btc address i'll tip him
236 2013-07-14 10:21:28 <coingenuity> ;;gpg info sipa
237 2013-07-14 10:21:28 <gribble> User 'sipa', with keyid B9A408E71DAAC974, fingerprint D762373D24904A3E42F33B08B9A408E71DAAC974, and bitcoin address None, registered on Thu Mar 24 13:45:20 2011. http://bitcoin-otc.com/viewgpg.php?nick=sipa . Currently not authenticated.
238 2013-07-14 10:21:41 <coingenuity> bitcoin address None << old school lol
239 2013-07-14 10:21:59 <sipa> lol, no idea how long it's been since i used otc
240 2013-07-14 10:22:56 <sipa> coingenuity: i do get donations from time to time
241 2013-07-14 10:23:51 <warren> sipa: if you have a LTC address I'd like to send you a donation for secp256k1
242 2013-07-14 10:24:31 <coingenuity> sipa: post your address here, if you want :)
243 2013-07-14 10:24:36 <coingenuity> i'm sure you might see a few more ;)
244 2013-07-14 10:36:13 <sipa> warren: where is your litecoin repo?
245 2013-07-14 10:37:26 <warren> sipa: https://github.com/litecoin-project/litecoin-0.8
246 2013-07-14 10:37:36 <warren> sipa: I'm in the process of reorganizing it.
247 2013-07-14 10:37:49 <warren> sipa: https://github.com/litecoin-project/litecoin <--- 0.6.x
248 2013-07-14 10:40:06 <warren> sipa: that "master" is bitcoin and doesn't belong there. "awesomecoin" is a messy tree. "mark10b" contains the latest v0.8.3.5 release candidate, which is squashed and cleaned commits to be identical to awesomecoin. "mark10" are Litecoin-specific commits, "btc09backports" are bitcoin-0.9 cherry-picks, the two branches combined become mark10b.
249 2013-07-14 10:40:20 <sipa> outch :)
250 2013-07-14 10:40:25 <sipa> just tell me which to try :p
251 2013-07-14 10:40:46 <warren> sipa: mark10b is latest with GPG signed v0.8.3.5 tag
252 2013-07-14 10:42:23 <warren> When 0.8.x becomes an official release, markXXb will become "master" of some sort and pull requests for our 0.8.x series begin there. folks can refer to awesomecoin for the dev history prior to squashing.
253 2013-07-14 10:43:07 <warren> The goal of the squashed rebase is to make it easier to audit the code.
254 2013-07-14 10:43:17 <sipa> k
255 2013-07-14 10:44:16 <warren> sipa: mark10b-cc is the same thing with Coin Control, extremely well tested at this point but we aren't shipping it by default because it lacks translations. mark9b-ccsec is the last working version with secp256k1. didn't rebase your commit yet.
256 2013-07-14 10:45:21 <sipa> how large is the litecoin chain now?
257 2013-07-14 10:45:31 <warren> blocks + db?
258 2013-07-14 10:45:43 <sipa> just order of magnitude
259 2013-07-14 10:49:16 <warren> 2.2GB for blocks/ directory, "height" : 388522, "transactions" : 426913, "txouts" : 13678856. 12M of those UTXO are 1-satoshi spam from the very early days prior to the anti-spam rules.
260 2013-07-14 10:51:46 <warren> sipa: https://forum.litecoin.net/index.php/topic,4371.0.html GPG signed binaries, you can verify against your own gitian build.
261 2013-07-14 11:00:31 <warren> I'm considering putting these branches into https://github.com/litecoin-project/litecoin and renaming the branches
262 2013-07-14 11:00:34 <warren> master-0.6
263 2013-07-14 11:00:36 <warren> master-0.8
264 2013-07-14 11:00:52 <warren> master will be blank with just README.md explaining the branches
265 2013-07-14 11:02:00 <sipa> you can just drop master, i think?
266 2013-07-14 11:02:14 <warren> what becomes the default if you have no master?
267 2013-07-14 11:02:22 <sipa> unsure
268 2013-07-14 11:02:53 <warren> README.md explaining the current state of the branches might work well, given we have too many, and our dev process is confusing with the constant need to rebase.
269 2013-07-14 11:03:01 <sipa> remote: error: refusing to delete the current branch: refs/heads/master
270 2013-07-14 11:03:02 <sipa> To git@github.com:sipa/bitcoin.git ! [remote rejected] master (deletion of the current branch prohibited)
271 2013-07-14 11:03:18 <warren> huh?
272 2013-07-14 11:03:25 <warren> oh
273 2013-07-14 11:03:29 <sipa> i can't remove my 'master' branch (it's unused as well)
274 2013-07-14 11:03:41 <sipa> because it's the "current" branch according to github
275 2013-07-14 11:04:02 <warren> yeah, I think I'll just delete it locally, create a new one with just README.md, and push --force
276 2013-07-14 11:04:11 <warren> I *think* that'll work
277 2013-07-14 11:04:19 <sipa> yes that will work
278 2013-07-14 11:04:21 <sipa> ah
279 2013-07-14 11:04:42 <sipa> gitihub.com -> repo -> "settings" -> default branch: [select]
280 2013-07-14 11:04:59 <warren> coblee didn't give me access to those settings =P
281 2013-07-14 11:05:50 <warren> in any case I personally want the default branch to explain the mess of branches that we have.
282 2013-07-14 11:06:03 <sipa> ok
283 2013-07-14 11:09:43 <warren> Hmm, it seems better to put the GPG signed tags in master rather than side-branches, because you can't have duplicate tags, and the version displayed in splash and about comes from the most recent annotated/signed tag.
284 2013-07-14 11:09:57 <warren> I'm not sure why it comes from THAT.
285 2013-07-14 11:10:02 <warren> seems inconvenient
286 2013-07-14 11:12:20 <sipa> what would you use for the version?
287 2013-07-14 11:12:56 <warren> whatever is in src/clientversion.h ?
288 2013-07-14 11:13:09 <sipa> that's useless, as it doesn't have the commit in it
289 2013-07-14 11:13:39 <warren> the commit is appended after the version anyway if you aren't building directly from an annotated tag
290 2013-07-14 11:14:00 <sipa> hmm?
291 2013-07-14 11:14:17 <sipa> there are two mechanisms: one is using git-describe when available
292 2013-07-14 11:14:36 <sipa> another is putting the commit id statically in the source when exporting
293 2013-07-14 11:15:10 <sipa> git-describe is generally more informational, as it tells you what 'official' source a build is based on immediately
294 2013-07-14 11:15:24 <sipa> but it's somewhat more confusing when you have side branches
295 2013-07-14 11:15:51 <sipa> for example, as 0.8.1 was a side-branch, pre-releases to 0.8.2 where marked as 0.8.0-num-g<commit>
296 2013-07-14 11:16:42 <sipa> but yeah, maybe the benefit of seeing ancestory is less than being more consistent and just using the configured version
297 2013-07-14 11:20:57 <warren> I'll think more about this and have a proposal one day. Just higher priorities now, like interviewing for jobs.
298 2013-07-14 11:31:14 <warren> sipa: https://github.com/litecoin-project/litecoin-0.8/commit/3da6dc7302899e95a811377c0517836f735c56fe we want to submit this to upstream at some point. The pools, charting sites and others who do data recording seem to like it. Do you think Bitcoin would accept anything like this?
299 2013-07-14 11:31:26 <warren> sipa: we've had this for 2 years
300 2013-07-14 11:38:14 <warren> sipa: another issue with tags, if bitcoin has a v0.9 tag, we can't make a corresponding release named v0.9 because you can't have duplicate tags. I would need to add an artificial v0.9.1. It wouldn't work to have something like v0.9L because distros don't allow letters in version numbers.
301 2013-07-14 11:39:36 <warren> ACTION sleep
302 2013-07-14 11:47:50 <sipa> warren: you can probably just not copy bitcoin's tag in some way
303 2013-07-14 11:52:48 <sipa> warren: i wouodn't object to such an RPC, but it can be implemented more accurately :)
304 2013-07-14 11:53:08 <sipa> by using the difference in bnChainWork
305 2013-07-14 12:15:07 <Goonie> sipa: I've got a question about your dns seeder that Peter Todd is running for testnet. It does not answer to my DNS queries (e.g. dig testnet-seed.bitcoin.petertodd.org yields status SERVFAIL).
306 2013-07-14 12:15:26 <Goonie> sipa: Peter mentioned this might be due to unstandard usage of DNS.
307 2013-07-14 12:15:59 <sipa> eh, not that i know
308 2013-07-14 12:16:12 <sipa> afaik, it works fine for me
309 2013-07-14 12:16:33 <sipa> but i certainly don't know all details of dns, and it is possible i'm doing something non standard
310 2013-07-14 12:16:48 <Goonie> sipa: not for me. Testnet is basically unreachable from my lines here in Germany.
311 2013-07-14 12:18:13 <sipa> well if you have more details i'll look into it
312 2013-07-14 12:18:22 <sipa> maybe petertodd knows the problem better
313 2013-07-14 12:18:45 <Goonie> sipa: I talked to him but at some point he referred to you because you wrote the software.
314 2013-07-14 12:20:04 <Goonie> sipa: messaged you the output of my dig command. What info do you need?
315 2013-07-14 12:20:42 <sipa> does his non-testnet seed work?
316 2013-07-14 12:21:22 <Goonie> I'm not aware of one. What's the address?
317 2013-07-14 12:22:11 <sipa> hmm, maybe there is none
318 2013-07-14 12:23:30 <Goonie> ah, just noticed that your mainnet seed also fails: seed.bitcoin.sipa.be
319 2013-07-14 12:23:50 <sipa> aclloh
320 2013-07-14 12:23:52 <sipa> oh
321 2013-07-14 12:23:59 <sipa> that's interesting
322 2013-07-14 12:24:04 <Goonie> while dnsseed.bluematt.me works for example
323 2013-07-14 12:24:33 <sipa> what does dig -t NS seed.bitcoin.sipa.be give you?
324 2013-07-14 12:25:17 <Goonie> same SERVFAIL
325 2013-07-14 12:25:46 <sipa> and with '@vps.sipa.be' added to it?
326 2013-07-14 12:26:35 <Goonie> so the line is "dig -t NS seed.bitcoin.sipa.be @vps.sipa.be"?
327 2013-07-14 12:26:46 <Goonie> yields "seed.bitcoin.sipa.be.\t40000\tIN\tNS\tvps.sipa.be."
328 2013-07-14 12:27:08 <sipa> looks good
329 2013-07-14 12:27:59 <sipa> i wonder where the problem is
330 2013-07-14 12:28:24 <sipa> ;;later tell petertodd do you know what's nonstandard about my usage of DNS in bitcoin-seeder?
331 2013-07-14 12:28:25 <gribble> The operation succeeded.
332 2013-07-14 12:28:46 <Goonie> Peter mentioned you're using some non-standard/uncommon DNS stuff and maybe because of this my DNS server filters it
333 2013-07-14 12:29:34 <sipa> more details would be interesting :)
334 2013-07-14 12:32:21 <Goonie> Just found his mail:
335 2013-07-14 12:32:25 <Goonie> "Chances are there is some kind of DNS filtering or proxy between you and the outside world that is silently rewriting or blocking the DNS messages between you and the testnet seed servers. It could be a firewall for instance. The testnet seed DNS server is custom code so it's likely there is something unusual about it compared to standard DNS servers.""
336 2013-07-14 12:33:59 <Goonie> dnsseed.bitcoin.dashjr.org also has the problem.
337 2013-07-14 12:34:33 <Goonie> That means 3 out of 5 seeds preconfigured in bitcoinj have this problem. (I'm not sure about bitcoin-qt.)
338 2013-07-14 12:36:58 <sipa> that shouldn't matter
339 2013-07-14 12:37:12 <sipa> if you have it in bitcoinj, it will be elsewhere too
340 2013-07-14 12:37:27 <sipa> as you demonstrated it with dig as well
341 2013-07-14 12:38:20 <sipa> but i have no idea what is non-standard about my implementation
342 2013-07-14 12:38:45 <sipa> (not arguing that it is, just that i have no idea where to begin looking)
343 2013-07-14 12:39:18 <sipa> some verbose instance that logs received queries would be useful to debug that
344 2013-07-14 12:39:24 <sipa> but i have no time for that now
345 2013-07-14 12:47:36 <Goonie> Do you know if there is a way to trace how a DNS query runs?
346 2013-07-14 12:47:50 <Goonie> sipa: something like a tracert for dns
347 2013-07-14 12:51:04 <sipa> usually your isp's dns servers are recursive
348 2013-07-14 12:51:22 <sipa> so they do the query on your behalf, and return the result to you
349 2013-07-14 12:51:28 <sipa> instead of redirecting you
350 2013-07-14 12:51:41 <sipa> so you don't actually know what they are doing
351 2013-07-14 12:51:43 <Goonie> sipa: just tried to be recursive myself by adding +trace, and that works.
352 2013-07-14 12:51:58 <sipa> i'm pretty sure that will work
353 2013-07-14 12:52:05 <Goonie> sipa: guess that skips my ISPs server
354 2013-07-14 12:52:09 <sipa> yes
355 2013-07-14 12:52:13 <sipa> i assume so
356 2013-07-14 12:52:19 <sipa> one possibility perhaps
357 2013-07-14 12:52:32 <sipa> is that some server is trying to contact my dns server using tcp
358 2013-07-14 12:52:41 <sipa> which it doesn't implement
359 2013-07-14 12:53:00 <Goonie> sipa: How can I know? It appears to be a black box to me.
360 2013-07-14 12:53:34 <sipa> how do you know what your isp's dns server does?
361 2013-07-14 12:53:51 <sipa> run a test dns server yourself that logs queries, and let your isp resolve it
362 2013-07-14 12:54:49 <Goonie> sipa: That's an idea.
363 2013-07-14 12:56:18 <Goonie> sipa: Let's assume for a second that TCP is the problem - would you be willing to implement it?
364 2013-07-14 12:57:14 <Goonie> sipa: Is there source available somewhere?
365 2013-07-14 12:57:32 <sipa> https://github.com/sipa/bitcoin-seeder
366 2013-07-14 12:57:45 <sipa> and adding tcp support wouldn't be much work i think
367 2013-07-14 12:59:27 <gmaxwell> sipa: in idle interest, did a public network from scratch resync w/ git on an 3.2ghz ivybridge + ssd, took 9 hours 45 minutes; one interesting fact is that the network interface shows 12302873787 rx, 507501394 tx which I think is about 25% overhead over the blocks themselves.
368 2013-07-14 13:00:27 <sipa> gmaxwell: i think we need to increase the re-request timeout
369 2013-07-14 13:00:37 <sipa> what happens now is that you ask for 500 blocks at once
370 2013-07-14 13:00:38 <gmaxwell> The log shows 19085 'ProcessBlock() : already have block'
371 2013-07-14 13:00:57 <sipa> and if some of those don't arrive within a minute (iirc) after asking
372 2013-07-14 13:01:03 <sipa> they are candidates to be asked again
373 2013-07-14 13:01:38 <sipa> it'd be much saner to track per connection whether it's still active, and if not, remove the invs asked on it from the global alreadyasked table
374 2013-07-14 13:01:57 <sipa> but a stopgap solution is perhaps to just increase that timeout
375 2013-07-14 13:07:01 <gmaxwell> sipa: sum of sizes of the 'alread have' blocks is 1892925095 bytes, so yes, thats most of my apparent overhead.
376 2013-07-14 13:09:42 <gmaxwell> I imagine that its worse on a system with more limited bandwidth.
377 2013-07-14 13:09:53 <sipa> gmaxwell: could you test whether increasing the timeout (net.h, CNode::AskFor(const CInv&)) improves that?
378 2013-07-14 13:11:07 <gmaxwell> I did a benchmark syncing on tor last week too??? it finished in <24 hours, but my data collection was goofed up by the fact that I did it on my laptop and it was suspended on it a couple times (because I hadn't yet figured how how to disable suspend on lid close in my new OS install)
379 2013-07-14 13:11:31 <gmaxwell> sipa: sure, what kind of number are you thinking of there? 5 minutes?
380 2013-07-14 13:12:25 <sipa> currently it's 2, i'd try with something significantly higher
381 2013-07-14 13:12:49 <sipa> assume your peer has 30 KiB/s upload - how long would 500 blocks take?
382 2013-07-14 13:13:15 <sipa> 70 minutes...
383 2013-07-14 13:13:36 <sipa> i guess that explains why we see retransmits
384 2013-07-14 13:14:07 <gmaxwell> yea... eerk
385 2013-07-14 13:14:41 <gmaxwell> uh, perhaps we also need to change our request granularity... fetching more than 10mbytes at a time probably has diminishing returns.
386 2013-07-14 13:14:55 <sipa> except the request side doesn't know the size
387 2013-07-14 13:15:08 <sipa> the sending side however can truncate at will
388 2013-07-14 13:15:18 <gmaxwell> Sure, but you could feed-forward: just assume the next one will have the same average size as the last.
389 2013-07-14 13:15:31 <gmaxwell> ah. that. hm.
390 2013-07-14 13:15:34 <sipa> so it should perhaps refuse to answer using more than 2 minutes worth of upload time at once
391 2013-07-14 13:15:38 <sipa> if it knows its own upload
392 2013-07-14 13:16:02 <gmaxwell> Likewise, it too could feed forward. "my transmission rate is the same as my last apparent rate to this peer"
393 2013-07-14 13:16:11 <sipa> yeah
394 2013-07-14 13:17:06 <gmaxwell> okay, I'll try raising it to 70 minutes and see how it goes, just to make sure there aren't any other causes.
395 2013-07-14 13:18:41 <gmaxwell> Even if it reduces the time by 15% however, thats still taking rather long. :(
396 2013-07-14 13:19:32 <sipa> i'll think about rewriting the mapAlreadyAskedFor logic
397 2013-07-14 13:20:42 <sipa> one global inv -> (node*, time) map, with the entries forming a linked list in order of request time
398 2013-07-14 13:20:52 <sipa> and then per node just a set of waitingforinv's
399 2013-07-14 13:20:56 <gmaxwell> heh. 70 * 60 * 1000000 overflows int. :P
400 2013-07-14 13:21:13 <sipa> ha
401 2013-07-14 13:21:17 <sipa> thank god for 64 bits
402 2013-07-14 13:21:32 <sipa> or otherwise
403 2013-07-14 13:22:05 <sipa> let's use 1.0226 us as a base unit
404 2013-07-14 13:34:57 <sipa> warren: rebased my secp256k1 branch to bitcoin master and secp256k1 master
405 2013-07-14 14:56:30 <bmcgee> hey anyone here running cgminer on a mac mini
406 2013-07-14 14:57:33 <Luke-Jr> bmcgee: #bitcoin-mining
407 2013-07-14 14:58:04 <bmcgee> thx
408 2013-07-14 16:12:03 <Luke-Jr> ACTION wonders when this May15 hardfork is going to ever happen, sigh
409 2013-07-14 16:13:11 <gmaxwell> Bitcoin is so robust it won't even fail when we want it to.
410 2013-07-14 16:14:54 <Luke-Jr> XD
411 2013-07-14 16:15:23 <CheckDavid> If you want it to fail, and it fails, then it didn't fail.
412 2013-07-14 16:16:26 <sipa> Luke-Jr: simultaneously with a block size limit hardfork, i guess
413 2013-07-14 16:16:49 <Luke-Jr> sipa: meh, I doubt that's the next hardfork
414 2013-07-14 16:17:17 <Luke-Jr> we have to change the POW before 2014 to make Kaminsky happy, right?
415 2013-07-14 16:17:18 <Luke-Jr> :p
416 2013-07-14 16:17:31 <sipa> unless someone intentionally creates a block vlose to the limit in size, with an above-average of txins-per-txout
417 2013-07-14 16:17:52 <gmaxwell> I thought that had been done.
418 2013-07-14 16:18:30 <sipa> luke tried, durimg the horsestaplebattery flood, resulting in a very low txins-per-txout ratio
419 2013-07-14 16:18:54 <Luke-Jr> didn't try hard enough
420 2013-07-14 16:18:54 <sipa> afaik
421 2013-07-14 16:19:08 <DiabloD3> sipa: the _what_?
422 2013-07-14 16:19:09 <Luke-Jr> seems like I'd need to do some kind of txid-based filtering
423 2013-07-14 16:19:16 <Luke-Jr> maybe I should add that anyway
424 2013-07-14 16:19:42 <gmaxwell> Are there remaining correcthorse txouts?
425 2013-07-14 16:19:53 <DiabloD3> ACTION has no clue whats going on here
426 2013-07-14 16:19:56 <gmaxwell> presumably some mixture of redeeming existing junk could get the desired ratios.
427 2013-07-14 16:19:58 <DiabloD3> ACTION isnt sure if he wants to know
428 2013-07-14 16:20:51 <gmaxwell> Luke-Jr: might be fun to make a little dust sweeper python script that you run, and it finds all your dust and creates any anyone can pay signature and sends it off to some server
429 2013-07-14 16:21:08 <gmaxwell> which assembles a single gigantic sweep up transaction which you mine
430 2013-07-14 16:21:18 <nsh> hmm
431 2013-07-14 16:21:21 <nsh> nice
432 2013-07-14 16:21:36 <Luke-Jr> gmaxwell: dunno, bdb is scary :P
433 2013-07-14 16:21:42 <gmaxwell> (just give it a zero value OP_RETURN output, and pay the swept dust to the pool)
434 2013-07-14 16:22:04 <Luke-Jr> zero value = dust!
435 2013-07-14 16:22:06 <Luke-Jr> :P
436 2013-07-14 16:22:45 <Luke-Jr> besides, people would probably prefer Bitcoin-Qt sweep the dust on its own, in their own transactions
437 2013-07-14 16:23:23 <Luke-Jr> eg, after making any transaction, try to add the smallest coins <=DUST to it as long as the fee doesn't change
438 2013-07-14 16:25:55 <gmaxwell> Luke-Jr: fee always changes if there is a fee. :(
439 2013-07-14 16:26:05 <gmaxwell> also that makes deanonymization attacks more powerful. :(
440 2013-07-14 16:26:12 <Luke-Jr> gmaxwell: no..
441 2013-07-14 16:26:32 <Luke-Jr> gmaxwell: I can lots of dust to a high-priority no-fee txn, and still send with no-fee and get it confirmed in the next block
442 2013-07-14 16:26:33 <gmaxwell> Luke-Jr: I know the current coin select quantizes, but thats not actually how the mining code works.
443 2013-07-14 16:26:46 <gmaxwell> yes, if you're no fee then yea, you can do that.
444 2013-07-14 16:27:02 <gmaxwell> still leaves the incentivizes deanonymization attacks issue.
445 2013-07-14 16:27:44 <Luke-Jr> hm
446 2013-07-14 16:27:49 <gmaxwell> (where people send 0.0001 BTC to every previously used 'identifyable' address with no currently assigned outputs, in hope of linking more addresses)
447 2013-07-14 16:29:16 <gmaxwell> The obvious half improvement is to measure the taint-group of the coins you've already selected, and sweep as much dust from those as you can, if there is any dust.
448 2013-07-14 16:29:47 <gmaxwell> But that still doesn't leave any sweeping for users who don't make any high priority free transactions.
449 2013-07-14 16:29:51 <Luke-Jr> combined/collaborative transactions would help a lot for privacy
450 2013-07-14 16:30:28 <gmaxwell> indeed. What I was suggesting was basically just a collaborative transaction for dust sweeping. It would actually turn that kind of attack on its head by creating a bunch of false signals for it.
451 2013-07-14 16:31:01 <gmaxwell> (and the advantage for doing it for dust is that there isn't a security concern)
452 2013-07-14 16:31:39 <Luke-Jr> but the users would lose those funds
453 2013-07-14 16:31:46 <gmaxwell> doing it more generally is harder... you need an anonymous p2p network to meet each other at a minimum. If you want dos resistance is harder.
454 2013-07-14 16:32:44 <Luke-Jr> gmaxwell: couldn't just broadcast partially-signed transactions? :p
455 2013-07-14 16:33:00 <Luke-Jr> I mean, it's not anonymous, but should be just as well as the current setup?
456 2013-07-14 16:33:03 <gmaxwell> Luke-Jr: sure, but have a setting 0.0001 is $0.01 USD. ... If you wanted instead of a zero value output, you turn it into a lottery amass dust until you have at least 0.01 BTC worth, and pay it all to one of the dust contributors at random? :P
457 2013-07-14 16:33:33 <gmaxwell> Luke-Jr: maybe but that would incentivize people to run crappiles of monitoring nodes. :(
458 2013-07-14 18:50:52 <warren> Goonie: ping
459 2013-07-14 18:57:58 <sipa> warren: good morning :)
460 2013-07-14 18:58:23 <warren> sipa: hi
461 2013-07-14 18:58:34 <warren> sipa: looking at your rebased secp256k1 now
462 2013-07-14 18:58:48 <warren> hoping it didn't change too much so I can apply it to 0.8.3
463 2013-07-14 18:59:10 <sipa> no, one extra field implementation that isn't used by default
464 2013-07-14 18:59:24 <sipa> and added tweak functions to use in bip32
465 2013-07-14 19:02:04 <sipa> should work fine
466 2013-07-14 19:02:21 <sipa> if you have the key refactor + compatibility fix
467 2013-07-14 19:04:24 <sipa> ironically, the secp256k1-based key implementation didn't have the incompatibility problem
468 2013-07-14 19:04:29 <warren> heh
469 2013-07-14 19:04:49 <warren> I never got around to fixing the old makefile win32 gitian build
470 2013-07-14 19:05:05 <warren> TheUni told me how, need to fix the linker order
471 2013-07-14 19:05:12 <sipa> ah
472 2013-07-14 19:05:28 <warren> with secp256k1
473 2013-07-14 19:05:42 <sipa> the mingw/osx makefiles don't have secp256k1 support in the first place
474 2013-07-14 19:05:51 <warren> yeah, I have an incomplete patch that has it
475 2013-07-14 19:05:55 <sipa> ok
476 2013-07-14 19:06:00 <sipa> pullreqs welcome
477 2013-07-14 19:06:13 <warren> well, I couldn't figure out how to make one piece deterministic
478 2013-07-14 19:06:18 <sipa> ah
479 2013-07-14 19:07:01 <phantomcircuit> sipa, it seems like with BIP32 keys the last i value used to generate a key would be needed
480 2013-07-14 19:07:05 <phantomcircuit> or am i missing something
481 2013-07-14 19:07:08 <warren> https://github.com/wtogami/bitcoin/commit/35aa62c2686c8e8ba860577fe7b54846697ccf30 last attempt before I gave up, I think this is before TheUni told me how to fix the linker errors
482 2013-07-14 19:07:55 <sipa> phantomcircuit: yes, i guess
483 2013-07-14 19:08:06 <warren> sipa: oh, and more recently I had trouble building gitian linux secp256k1, it doesn't make a makefile anymore and just stops there
484 2013-07-14 19:08:13 <warren> been too busy to look into why
485 2013-07-14 19:08:22 <sipa> that may be fixed now
486 2013-07-14 19:08:53 <phantomcircuit> that would mean for an append only format you'd need to either have the same key dumped multiple times with new i values in metadata, or you'd need a record specificalyl for recording the new i value
487 2013-07-14 19:09:40 <gmaxwell> phantomcircuit: also similar to recording labels and such.
488 2013-07-14 19:09:45 <phantomcircuit> something like a normal record but with a pointer to the root?
489 2013-07-14 19:11:23 <sipa> phantomcircuit: just store every generated key
490 2013-07-14 20:24:57 <warren> sipa: gitian linux works again
491 2013-07-14 22:13:13 <jaekwon> is the transfer-to-ip type transaction (<sig> <pubKey> OP_CHECKSIG) used? why wouldn't all transactions just use transfer-to-bitcoin-address?
492 2013-07-14 22:13:39 <gmaxwell> sipa: looks like this fetch is going to come out a fair bit slower. The Already Haves are elimiated, but I'm ~9 hours in now and only at 17.4% (height 208560)... may just be luck of the peer.
493 2013-07-14 22:13:41 <gwillen> jaekwon: it is not generally used in modern practice, no.
494 2013-07-14 22:14:18 <gmaxwell> jaekwon: those are more commonly reconized as the pay to pubkey transactions produced by old style direct bitcoind mining.
495 2013-07-14 22:14:56 <jaekwon> mmm. danke!
496 2013-07-14 22:15:26 <gwillen> oh, interesting
497 2013-07-14 22:16:40 <gmaxwell> jaekwon: they do result in less total data added to the blockchain if you count both the output and the signature spending them.
498 2013-07-14 22:18:08 <Luke-Jr> jaekwon: there is no "transfer-to-bitcoin-address" O.o
499 2013-07-14 22:18:30 <sipa> he means transfer-to-pubkey-hash, obviously
500 2013-07-14 22:18:40 <Luke-Jr> I suppose, but addresses can represent 2 different kinds of scripts now
501 2013-07-14 22:18:54 <jaekwon> just what the wiki says: https://en.bitcoin.it/wiki/Transactions#general_format_.28inside_a_block.29_of_each_input_of_a_transaction_-_Txin
502 2013-07-14 22:19:18 <jaekwon> i mean https://en.bitcoin.it/wiki/Transactions#Transfer_to_Bitcoin_address
503 2013-07-14 22:19:26 <sipa> well transfer-to-address is sort of a tautology
504 2013-07-14 22:19:33 <sipa> as an address is something you transfer to
505 2013-07-14 22:21:22 <Luke-Jr> wow, that page is way outdated
506 2013-07-14 22:33:55 <sipa> gmaxwell: the variation from good/bad peers is very high, i think
507 2013-07-14 22:34:42 <sipa> but if this eliminates Already Haves, it may be worth it trying to avoid them in an equivalent way
508 2013-07-14 22:37:05 <gmaxwell> sipa: I think I was previously expecting that new block announcements would tend to move our fetching to faster peers.
509 2013-07-14 22:40:30 <jaekwon> this statement appears to be wrong: "The body of the block contains the transactions. These are hashed only indirectly through the Merkle root. Because transactions aren't hashed directly, hashing a block with 1 transaction takes exactly the same amount of effort as hashing a block with 10,000 transactions." from https://en.bitcoin.it/wiki/Block_hashing_algorithm
510 2013-07-14 22:40:58 <jaekwon> oh
511 2013-07-14 22:41:06 <jaekwon> it's talking about the block header.
512 2013-07-14 22:41:40 <jaekwon> nm
513 2013-07-14 22:42:18 <TradeFortress> hi. any devs online?
514 2013-07-14 22:42:34 <BTCOxygen> TradeFortress: Hi
515 2013-07-14 22:42:49 <sipa> TradeFortress: tons
516 2013-07-14 22:42:57 <BTCOxygen> ^
517 2013-07-14 22:43:04 <TradeFortress> OK, bitcoin addresses? :)
518 2013-07-14 22:43:14 <gribble> You are not identified.
519 2013-07-14 22:43:14 <sipa> ;;ident
520 2013-07-14 22:43:24 <BTCOxygen> ;;ident
521 2013-07-14 22:43:25 <gribble> You are identified as user BTCOxygen, with GPG key id None, key fingerprint None, and bitcoin address 1EMP3BY6WZeKfuiyv99ZxY3LPEiy8mVF5z
522 2013-07-14 22:43:46 <TradeFortress> ok, uhh, I was more of talking about the people that helped with the deadlock.
523 2013-07-14 22:44:15 <BTCOxygen> ah.
524 2013-07-14 22:44:26 <BTCOxygen> CodeShark and sipa.
525 2013-07-14 22:45:05 <BTCOxygen> ;;gpg info sipa1024
526 2013-07-14 22:45:05 <gribble> No such user registered.
527 2013-07-14 22:45:07 <BTCOxygen> ;;gpg info sipa
528 2013-07-14 22:45:08 <gribble> User 'sipa', with keyid B9A408E71DAAC974, fingerprint D762373D24904A3E42F33B08B9A408E71DAAC974, and bitcoin address 1x8NM1Bp9WJ9E5qYPp3RmwBiT7G6Lsipa, registered on Thu Mar 24 13:45:20 2011. http://bitcoin-otc.com/viewgpg.php?nick=sipa . Currently not authenticated.
529 2013-07-14 22:45:16 <BTCOxygen> ;;gpg info CodeShark
530 2013-07-14 22:45:16 <gribble> No such user registered.
531 2013-07-14 22:45:18 <TradeFortress> lastbits, lol
532 2013-07-14 22:45:31 <TradeFortress> sipa, thanks!
533 2013-07-14 22:46:04 <sipa> TradeFortress: yw :)
534 2013-07-14 22:46:15 <sipa> TradeFortress: and thanks for the help with debugging :)
535 2013-07-14 22:46:27 <BTCOxygen> TradeFortress: You transaction is the first transaction sent to sipa. ;p
536 2013-07-14 22:46:51 <sipa> i hope nobody here assumes that is my only address...
537 2013-07-14 22:47:13 <TradeFortress> haha
538 2013-07-14 22:47:16 <BTCOxygen> haha
539 2013-07-14 22:47:40 <BTCOxygen> At least he is the first to send to your gribble address.
540 2013-07-14 22:48:15 <sipa> TradeFortress == 1GLaDoS?
541 2013-07-14 22:48:21 <BTCOxygen> Yes.
542 2013-07-14 22:48:29 <gribble> User 'TradeFortress', with keyid None, fingerprint None, and bitcoin address 1xw6QFuj3jvQ1spfT9H5kqitaByeJjSRB, registered on Sun Sep 23 07:48:53 2012. http://bitcoin-otc.com/viewgpg.php?nick=TradeFortress . Currently not authenticated.
543 2013-07-14 22:48:29 <sipa> ;;gpg info TradeFortress
544 2013-07-14 22:48:38 <TradeFortress> sipa, Why?
545 2013-07-14 22:48:53 <TradeFortress> I have fb 1GLaD0S :P
546 2013-07-14 22:49:16 <sipa> 1GLados, you mean?
547 2013-07-14 22:49:23 <sipa> :p
548 2013-07-14 22:50:06 <TradeFortress> probably that :P
549 2013-07-14 22:51:53 <gribble> You are identified as user sipa, with GPG key id B9A408E71DAAC974, key fingerprint D762373D24904A3E42F33B08B9A408E71DAAC974, and bitcoin address 1x8NM1Bp9WJ9E5qYPp3RmwBiT7G6Lsipa
550 2013-07-14 22:51:53 <sipa> ;;ident
551 2013-07-14 22:55:54 <PRab> I just had a thought. I know bitcoin addresses have a checksum, but how many additional characters would it take to provide an ECC against any 1 letter being changed?
552 2013-07-14 22:57:39 <PRab> I believe standard ECC takes log(2)n additional bits to protect n data bits, but in base58 encoding each character represents more than just a bit.
553 2013-07-14 22:58:45 <PRab> It also seems like there could be an optimization because the "corruption" is known to be clustered (because you can't change half of 2 independent characters)
554 2013-07-14 23:10:00 <warren> sipa: hmm, would a secp256k1 node add any risk to the network for purely mining, where the target mining address is NOT the local wallet?
555 2013-07-14 23:10:33 <gmaxwell> PRab: the fact that 58 is 2*29 makes it hard to make an efficient erasure code for it.
556 2013-07-14 23:10:48 <gribble> User 'rethaw', with keyid B967E4E088147116, fingerprint EB135F1BD53A7186AEA3D4DCB967E4E088147116, and bitcoin address None, registered on Tue Jul 5 00:26:03 2011. http://bitcoin-otc.com/viewgpg.php?nick=rethaw . Currently not authenticated.
557 2013-07-14 23:10:48 <rethaw> ;;gpg info rethaw
558 2013-07-14 23:10:55 <gmaxwell> PRab: if it were base 32 or 64 it would be trivial.
559 2013-07-14 23:11:42 <warren> sipa: risk other than the node owner screwing up their own mining?
560 2013-07-14 23:11:55 <sipa> gmaxwell: split it in a base-2 sequence and a base-29 sequence
561 2013-07-14 23:12:01 <sipa> gmaxwell: and give them both a code
562 2013-07-14 23:12:41 <sipa> warren: the risk to the network is when a verification error would be present
563 2013-07-14 23:12:57 <sipa> warren: and the network'd fork between secp256k1 and openssl-based implementations
564 2013-07-14 23:13:14 <warren> sipa: wouldn't the vast majority of openssl nodes just reject invalid stuff coming from secp256k1 nodes?
565 2013-07-14 23:13:18 <warren> ok
566 2013-07-14 23:14:00 <warren> so secp256k1 nodes are at risk of forking, as long as they are a tiny minority for testing and those node operators accept the personal risk then it isn't a systemic risk.
567 2013-07-14 23:14:08 <sipa> well if it's a problem in signing, likely the transaction won't make it far through the network
568 2013-07-14 23:14:14 <warren> right
569 2013-07-14 23:14:37 <sipa> so the only really risky case is if a significant hashrate of full nodes is on secp256k1
570 2013-07-14 23:15:00 <sipa> and someone who has access to some (not much) mining power broadcasts a transaction that forks
571 2013-07-14 23:15:21 <sipa> so i'd say the risk is rather in having full nodes on it, not miners
572 2013-07-14 23:15:31 <warren> oh
573 2013-07-14 23:15:42 <sipa> it does require an exploitable attack though
574 2013-07-14 23:16:12 <warren> I was considering making our popular Coin Control variant "experimental" build also secp256k1 just to get it more exposure.
575 2013-07-14 23:16:45 <warren> nobody uses that for mining, only end-user clients
576 2013-07-14 23:17:16 <warren> the risk is real though, might be best to wait until after the audit
577 2013-07-14 23:31:53 <gmaxwell> ACTION gives up and syncs from a local node
578 2013-07-14 23:35:13 <warren> gmaxwell: does my apt-cacher-ng and python-vm-builder work for gitian on Fedora 19? I haven't tried it there yet.
579 2013-07-14 23:36:34 <gmaxwell> haven't tried yet??? but good though, I should.
580 2013-07-14 23:37:20 <warren> gmaxwell: http://wtogami.blogspot.com/2013/05/gitian-for-fedora.html