1 2012-01-04 00:28:50 <BlueMatt> gmaxwell: ping
2 2012-01-04 00:41:01 <gmaxwell> BlueMatt: ploink
3 2012-01-04 00:41:02 <gavinandresen> Anybody still awake: email me if I missed something in the draft pay-to-script-hash BIP: https://gist.github.com/1557931
4 2012-01-04 00:41:50 <luke-jr> what if I just think it sucks?
5 2012-01-04 00:41:54 <luke-jr> (disclaimer: haven't read it yet)
6 2012-01-04 01:03:15 <[Tycho]> What should {serialized script} look like ?
7 2012-01-04 01:03:41 <BlueMatt> the same way a script looks when its coming off the network
8 2012-01-04 01:03:45 <BlueMatt> /store on disk in a block
9 2012-01-04 01:04:21 <BlueMatt> ok, wtf is up with github, can anyone push to their repos?
10 2012-01-04 01:06:19 <[Tycho]> So it will be just normal script, just preceded by length byte/pushop ?
11 2012-01-04 01:07:18 <BlueMatt> but if thats the format of CDataStream
12 2012-01-04 01:08:02 <[Tycho]> Me too.
13 2012-01-04 01:08:18 <BlueMatt> iirc there are also length bytes on vectors, etc
14 2012-01-04 01:08:43 <BlueMatt> ok, how did github fuck up my bitcoin fork?
15 2012-01-04 01:11:39 <luke-jr> [Tycho]: no
16 2012-01-04 01:11:57 <luke-jr> [Tycho]: there should also be a leading octet for version
17 2012-01-04 01:12:37 <luke-jr> [Tycho]: but the important thing is that this is basically OP_EVAL except represented as a magic script template instead of an opcode
18 2012-01-04 01:12:38 <[Tycho]> Why will you continue to include OP_EVAL in your coinbase ?
19 2012-01-04 01:12:45 <luke-jr> [Tycho]: because OP_EVAL is better
20 2012-01-04 01:12:55 <gmaxwell> luke-jr: it's not the same as op_eval.
21 2012-01-04 01:13:03 <luke-jr> gmaxwell: it's less flexible.
22 2012-01-04 01:13:06 <[Tycho]> What was the point of this magic thing ?
23 2012-01-04 01:13:10 <luke-jr> it's not superior in any way
24 2012-01-04 01:13:24 <luke-jr> [Tycho]: presumably to save a byte
25 2012-01-04 01:13:25 <gmaxwell> OP_EVAL can have its content produced by computation which is less flexible because it means the only way to evaluate a script is by running it.
26 2012-01-04 01:13:47 <luke-jr> gmaxwell: fine, so add the "input data must be from OP_PUSH" rule
27 2012-01-04 01:13:47 <[Tycho]> gmaxwell: what computation, for example ?
28 2012-01-04 01:14:29 <gmaxwell> [Tycho]: e.g. the OP_DUP looping scripts, or doing some crazy arithemetic to generate code on the fly.
29 2012-01-04 01:14:44 <luke-jr> also, I still think that isn't a problem.
30 2012-01-04 01:14:51 <[Tycho]> Arithmetics are crippled to 4 bytes.
31 2012-01-04 01:14:52 <gmaxwell> luke-jr: yes, that was one of the proposals. It's a lot more complicated to implement and validate however.
32 2012-01-04 01:14:57 <BlueMatt> there are several problems with OP_EVAL that are solved here
33 2012-01-04 01:15:02 <BlueMatt> and they have all been discussed at lenth...
34 2012-01-04 01:15:03 <gmaxwell> [Tycho]: not if we reenable concat.
35 2012-01-04 01:15:17 <[Tycho]> Concat is cool and harmless.
36 2012-01-04 01:15:25 <gmaxwell> sure, but it would remove that limit.
37 2012-01-04 01:15:28 <roconnor> [Tycho]: OP_SHA256
38 2012-01-04 01:15:29 <luke-jr> gmaxwell: I prefer complicated/impossible to static analyze over magic special casing
39 2012-01-04 01:15:47 <[Tycho]> roconnor: how is this harmful ?
40 2012-01-04 01:15:52 <gmaxwell> This isn't magic special casing.
41 2012-01-04 01:15:58 <luke-jr> yes it is
42 2012-01-04 01:16:32 <luke-jr> or at the end
43 2012-01-04 01:16:38 <[Tycho]> Then we need to convince slush into implementing op_eval...
44 2012-01-04 01:16:39 <BlueMatt> either way
45 2012-01-04 01:16:40 <luke-jr> there's no reason the OP_EVAL needs to be made implicit
46 2012-01-04 01:16:51 <gmaxwell> BlueMatt: it has the hash160 at the front.
47 2012-01-04 01:16:51 <roconnor> [Tycho]: it means you have to run the script before you can count the number of OP_CHECKSIGs or other such analysis.
48 2012-01-04 01:17:01 <BlueMatt> please, for the love of god, do not implement OP_EVAL...
49 2012-01-04 01:17:17 <gmaxwell> Where where the two of your objections earlier today?
50 2012-01-04 01:17:21 <[Tycho]> roconnor: number of checksigs can be easily counted in runtime.
51 2012-01-04 01:17:30 <luke-jr> BlueMatt: you can take this proposal, slap an opcode on the end, and call that OP_EVAL.
52 2012-01-04 01:17:34 <gmaxwell> Luke was in the room but mostly quiet.
53 2012-01-04 01:17:35 <BlueMatt> gmaxwell: Ive always wanted an OP_NOP1
54 2012-01-04 01:17:45 <BlueMatt> oh, [Tycho]
55 2012-01-04 01:17:56 <roconnor> [Tycho]: only after running them.
56 2012-01-04 01:17:57 <BlueMatt> gmaxwell: well the script is an otherwise normal and valid script, at least if we add an OP_NOP1 its specially marked
57 2012-01-04 01:17:58 <luke-jr> gmaxwell: I had to leave. I started off with these objections.
58 2012-01-04 01:18:16 <[Tycho]> roconnor: hit the limit and stop executing. Problems ?
59 2012-01-04 01:18:41 <roconnor> [Tycho]: nothing beyond wasting your time.
60 2012-01-04 01:18:50 <luke-jr> AFAIK, nobody has expressed any reason static analysis is *useful*
61 2012-01-04 01:18:52 <gmaxwell> [Tycho]: you've just wasted $limit of computation, and I'm sending you limit wasting txn at line rate.
62 2012-01-04 01:19:06 <luke-jr> gmaxwell: I can do that with this new proposal too
63 2012-01-04 01:19:14 <[Tycho]> roconnor: exactly SAME time would be wasted with same number of checksigs if they are under the limit.
64 2012-01-04 01:19:19 <gmaxwell> luke-jr: because it allows you to drop many useless transactions without actually executing them.
65 2012-01-04 01:19:24 <BlueMatt> ok, seriously WTF???? Im getting "Timeout, server github.com not responding." AFTER "Total 50 (delta 42), reused 0 (delta 0)"
66 2012-01-04 01:19:27 <luke-jr> gmaxwell: nope
67 2012-01-04 01:19:37 <luke-jr> gmaxwell: it only allows you to drop an attack, and that attack can be done without it
68 2012-01-04 01:19:45 <BlueMatt> and the internet is clearly 100% working...
69 2012-01-04 01:20:17 <roconnor> [Tycho]: That's true
70 2012-01-04 01:20:21 <[Tycho]> Well, at least in this part I'm correct.
71 2012-01-04 01:20:25 <gmaxwell> I wish you guys could see how evil you're looking now you didn't participate in the open discussion so you're just proposing to go your own way by force.
72 2012-01-04 01:20:28 <BlueMatt> and no freenode #github channel where the github people hang out...
73 2012-01-04 01:20:31 <luke-jr> gmaxwell: for example, a script that does exactly <LIMIT> OP_CHECKSIGs, then fails for some other unrelated reason
74 2012-01-04 01:20:44 <roconnor> gmaxwell: good test of the bitcoin system
75 2012-01-04 01:20:46 <gmaxwell> luke-jr: indeed, thats true.
76 2012-01-04 01:20:48 <luke-jr> gmaxwell: or a script that fails on its <LIMIT>th OP_CHECKSIG
77 2012-01-04 01:21:00 <[Tycho]> I'm not making anything by force. We still have to discuss this (with slush). And that will be democracy.
78 2012-01-04 01:21:15 <BlueMatt> [Tycho]: are you kidding me?
79 2012-01-04 01:21:22 <gmaxwell> No one wants a bitcoin system which is a democracy of luke-jr + [Tycho] + slush
80 2012-01-04 01:21:24 <[Tycho]> BlueMatt: yes.
81 2012-01-04 01:21:29 <BlueMatt> good
82 2012-01-04 01:21:41 <roconnor> gmaxwell: if people don't want it then they won't give their mining power to them.
83 2012-01-04 01:21:42 <luke-jr> gmaxwell: this change basically must be.
84 2012-01-04 01:21:53 <[Tycho]> BlueMatt: but I'm still against the change.
85 2012-01-04 01:22:07 <BlueMatt> luke-jr: do you have any possible use for OP_EVAL over the new version?
86 2012-01-04 01:22:13 <BlueMatt> other than "its more flexible"
87 2012-01-04 01:22:19 <BlueMatt> [Tycho]: why?
88 2012-01-04 01:22:42 <[Tycho]> BlueMatt: looks more ugly to me and adds "special case" logic.
89 2012-01-04 01:22:58 <[Tycho]> Also makes scripts more cryptic.
90 2012-01-04 01:23:05 <BlueMatt> [Tycho]: ok, on that count I totally agree
91 2012-01-04 01:23:26 <luke-jr> BlueMatt: for example, making a decision of which of 2 scripts to execute based on the result of a 1st script
92 2012-01-04 01:23:30 <BlueMatt> but then you can just add an OP_NOP1 to the beginning...
93 2012-01-04 01:23:31 <gmaxwell> I don't see how this is any more special case or cryptic than anything about their operations.
94 2012-01-04 01:23:50 <BlueMatt> luke-jr: I said a use, not what it allows
95 2012-01-04 01:23:54 <[Tycho]> May be we need to vote ?
96 2012-01-04 01:23:58 <roconnor> [Tycho]: why do we need send-to-script-hash as opposed to send-to-script?
97 2012-01-04 01:24:03 <BlueMatt> [Tycho]: no one is awake...
98 2012-01-04 01:24:08 <luke-jr> BlueMatt: concealing your "alternative" script permanently.
99 2012-01-04 01:24:08 <[Tycho]> Oh, stop, we will vote by our coinbases anyway.
100 2012-01-04 01:24:25 <BlueMatt> roconnor: send-to-script doesnt solve the original problem...
101 2012-01-04 01:24:35 <roconnor> BlueMatt: what is the original problem?
102 2012-01-04 01:24:57 <luke-jr> roconnor: long logic to redeem
103 2012-01-04 01:24:58 <[Tycho]> roconnor: send-to-script-hash is fine. I just want the script to be normal, not encrypted.
104 2012-01-04 01:25:02 <BlueMatt> roconnor: the ability to send MULTISIG transactions that require 10/50 sigs to a reasonable length address
105 2012-01-04 01:25:02 <doublec> shouldn't it be the miners voting, not the pools?
106 2012-01-04 01:25:18 <doublec> if the miners don't know there is a vote on, how can they choose to mine on a pool that reflects their vote
107 2012-01-04 01:25:19 <luke-jr> doublec: ideally, but that won't happen
108 2012-01-04 01:25:30 <luke-jr> doublec: even when DeepBit is down, it has a huge amount of power
109 2012-01-04 01:25:34 <[Tycho]> doublec: miners aren't developers. How they can know what is the right decision ?
110 2012-01-04 01:25:45 <luke-jr> [Tycho]: to be fair, you're not a developer either.
111 2012-01-04 01:25:58 <doublec> not all pool owners are developers
112 2012-01-04 01:26:00 <gmaxwell> [Tycho]: you haven't parcipated in any of the discussion how can you know what is the right recision.
113 2012-01-04 01:26:42 <roconnor> BlueMatt: Meh, I don't see why addresses need to be short.
114 2012-01-04 01:26:45 <[Tycho]> Well, if others will decide to implement that new thing instead of op_eval, I'll remove OP_EVAL from the pool.
115 2012-01-04 01:26:52 <luke-jr> 1) static analysis is useless; 2) special casing is always ugly; 3) special casing removes many possibilities
116 2012-01-04 01:27:27 <[Tycho]> So I'm not going to force my opinion by force.
117 2012-01-04 01:27:44 <luke-jr> I will remove OP_EVAL if forced or a better version is created; I will not add this special-case even if it "wins"
118 2012-01-04 01:27:45 <[Tycho]> So I recommend you all to agree with me.
119 2012-01-04 01:28:17 <[Tycho]> luke-jr: what about the timebomb in current code set to 01.02 ?
120 2012-01-04 01:28:19 <BlueMatt> doublec: the miners did vote (to give up their power to the pools)
121 2012-01-04 01:28:23 <doublec> how about implementing it in an alt chain and seeing how it goes for a month or two
122 2012-01-04 01:28:25 <BlueMatt> doublec: how about we just discuss the options with mining pool ops and hope they come to the same decision the developers appear to be coming to
123 2012-01-04 01:28:32 <luke-jr> [Tycho]: ?
124 2012-01-04 01:28:37 <doublec> BlueMatt: but if they don't know a vote is on, they can't choose to change to a pool that reflects their vote
125 2012-01-04 01:28:38 <gmaxwell> luke-jr: I don't see why you're fixating on saying this is a special case. It's no more or less special than e.g. the sighash all bit.
126 2012-01-04 01:28:55 <luke-jr> doublec: they won't.
127 2012-01-04 01:28:56 <[Tycho]> luke-jr: if you won't remove OP_EVAL support, it will kick in at 01.01.2012
128 2012-01-04 01:29:05 <luke-jr> gmaxwell: it clearly is.
129 2012-01-04 01:29:13 <luke-jr> [Tycho]: it's already past that date
130 2012-01-04 01:29:18 <BlueMatt> roconnor: it gets to the point where it wont even fit into a qr code
131 2012-01-04 01:29:22 <[Tycho]> luke-jr: 01.02.2012
132 2012-01-04 01:29:25 <gmaxwell> luke-jr: yes, in an absolute sense _every single operation executed_ is a "special case"
133 2012-01-04 01:29:29 <theymos> luke-jr: Would you feel better if there was a flag op in the script?
134 2012-01-04 01:29:38 <BlueMatt> roconnor: and you can reasonably type in a bitcoin address now (not that youd want to), you cant when you get into multisigs
135 2012-01-04 01:29:58 <luke-jr> [Tycho]: Oh, you mean 2012-02-01?
136 2012-01-04 01:30:06 <doublec> BlueMatt: how many mining pool ops have you discussed it with?
137 2012-01-04 01:30:34 <doublec> I would imagine there aren't many following bitcoin development
138 2012-01-04 01:30:41 <luke-jr> theymos: I would "feel better" if the script ended with an opcode for the purpose
139 2012-01-04 01:31:04 <gmaxwell> luke-jr: ended? I don't think end makes much sense?
140 2012-01-04 01:31:04 <[Tycho]> int64 nEvalSwitchTime = GetArg("opevaltime", 1328054400); // Feb 1, 2012
141 2012-01-04 01:31:05 <luke-jr> theymos: and therefore, you could put that opcode in any script
142 2012-01-04 01:31:23 <luke-jr> gmaxwell: the code needs to evaluate AFTER the hash is checked
143 2012-01-04 01:32:30 <gmaxwell> doublec: gavin had one on oned the original op_eval stuff with a bunch of folks in addition to the public discussion
144 2012-01-04 01:32:32 <roconnor> it is fine to check the hash AFTER the code evaluates.
145 2012-01-04 01:32:45 <roconnor> that is how CODEHASH worked
146 2012-01-04 01:33:17 <luke-jr> roconnor: only if you can guarantee the code evaluated didn't mess with the hash ;)
147 2012-01-04 01:33:39 <luke-jr> CODEHASH worked like that because it pushed the hash onto the stack after the script ran
148 2012-01-04 01:34:00 <gmaxwell> doublec: this was all set and going along fine, and then we got the 12 hour objections. Which sounded well reasoned, if annoyingly late.. and more disucssion happened, and a meeting was held to reach a conclusion..
149 2012-01-04 01:34:38 <gmaxwell> And the new thing is what exited the discussion with no active oppoisition (because apparently luke left)
150 2012-01-04 01:34:38 <theymos> What do you guys think about OP_EVAL that only works on data with an "execute flag"? This seems a bit cleaner to me.
151 2012-01-04 01:34:43 <luke-jr> [Tycho]: I hope a consensus is reached by then
152 2012-01-04 01:35:03 <luke-jr> theymos: that was what was proposed earlier, and what I am OK with
153 2012-01-04 01:35:06 <doublec> gmaxwell: "annoyingly late" because there hasn't been enough publicity about it
154 2012-01-04 01:35:27 <luke-jr> theymos: specifically, the "execute flag" would only be set by OP_PUSH
155 2012-01-04 01:35:43 <gmaxwell> theymos: its easier to make buggy. e.g. if you don't properly track the execute bit, you may not know until someone smashes your stack with an infinite recursion script.
156 2012-01-04 01:35:51 <doublec> gmaxwell: but that aside, yeah, it's hard doing something that requires consensus
157 2012-01-04 01:35:59 <gmaxwell> doublec: No, the people who complained where all exposed to the prior discussion.
158 2012-01-04 01:36:15 <gmaxwell> (I mean, perhaps you're also correct but thats not the cause here)
159 2012-01-04 01:36:34 <[Tycho]> gmaxwell: stack execution should contain it's own runtime counters and limits.
160 2012-01-04 01:36:39 <gmaxwell> roconnor seems to have ignored it until he used his holidy time to go implement it. ::shrugs::
161 2012-01-04 01:37:01 <gmaxwell> [Tycho]: it has no reason to prevent recursion with the execute bit proposal, so people would just not implement that.
162 2012-01-04 01:37:39 <[Tycho]> Not only to prevent recursion, but to prevent abuse. Even if recursion is impossible. Just IN CASE :)
163 2012-01-04 01:38:03 <gmaxwell> Should but since its a case thats actually impossible to hit the code will be completely untested
164 2012-01-04 01:38:08 <gmaxwell> and thus probably broken.
165 2012-01-04 01:38:25 <[Tycho]> It can be tested easily.
166 2012-01-04 01:38:37 <gmaxwell> (I mean we _might_ manage to get it right in the reference client but other software won't)
167 2012-01-04 01:38:43 <[Tycho]> Just feed with correctly wrong data.
168 2012-01-04 01:39:07 <[Tycho]> Ok, then reference client won't be affected, that's good too.
169 2012-01-04 01:39:30 <gmaxwell> [Tycho]: You're either underestimating how hard software testing is or over estimating the ongoing effort being applied to bitcoin implementations.
170 2012-01-04 01:40:05 <luke-jr> gmaxwell: would you like to finish my MIPS quantum emulator?
171 2012-01-04 01:40:09 <[Tycho]> I think that there aren't that many ways to mess up a simple iterations counter.
172 2012-01-04 01:40:17 <gmaxwell> [Tycho]: ...
173 2012-01-04 01:41:06 <doublec> [Tycho]: didn't the op_eval patch have a messed up counter that roconnor caught :)
174 2012-01-04 01:41:11 <gmaxwell> Just like it's not too hard to mess up measuring the total spen between (-1..2016] ? :)
175 2012-01-04 01:41:18 <gmaxwell> doublec: yes.
176 2012-01-04 01:41:22 <doublec> [Tycho]: it might be easier to mess up than you think
177 2012-01-04 01:41:22 <luke-jr> doublec: I totally blame gavin for that.
178 2012-01-04 01:41:37 <luke-jr> it's really not hard to get that right. somehow gavin did :P
179 2012-01-04 01:41:46 <roconnor> gmaxwell: or to pop the right number of arguments for multisig
180 2012-01-04 01:41:48 <doublec> and no one caught it for how long...
181 2012-01-04 01:41:50 <gmaxwell> the recursive code did foo++ when it should have done foo+1 in the argument.
182 2012-01-04 01:42:00 <doublec> some things are easy to miss
183 2012-01-04 01:42:03 <luke-jr> gmaxwell: var++ is almost always wrong
184 2012-01-04 01:42:09 <luke-jr> especially in C++
185 2012-01-04 01:42:09 <[Tycho]> I said "aren't that many ways", but gavin is a pro.
186 2012-01-04 01:42:20 <gmaxwell> Oh come on.
187 2012-01-04 01:42:21 <[Tycho]> So he managed to do it anyway :)
188 2012-01-04 01:42:37 <gmaxwell> Let he is with expirence but without sin cast the first stone.
189 2012-01-04 01:42:41 <luke-jr> if you want to increment, it's ++var
190 2012-01-04 01:43:21 <luke-jr> gmaxwell: I only use var++ when I really mean "increment this, only after finishing the statement with the old value"
191 2012-01-04 01:43:32 <gmaxwell> Yes, thats what it means.
192 2012-01-04 01:43:36 <roconnor> C++ takes C, makes it better, and hands you the mess that C originally was.
193 2012-01-04 01:43:43 <gmaxwell> But sometimes the figures autopilot and it looks bascially right.
194 2012-01-04 01:43:54 <gmaxwell> er s/figures/fingers/
195 2012-01-04 01:44:02 <luke-jr> bad habits are hard to break
196 2012-01-04 01:44:06 <luke-jr> my habit is ++var
197 2012-01-04 01:44:41 <gmaxwell> it certantly could have been foo++ ... if it were doing something else entirely. :)
198 2012-01-04 01:45:11 <gmaxwell> Gavin even had tests but they failed to catch it for other reasons.
199 2012-01-04 01:45:33 <[Tycho]> Sometimes I use ++var too.
200 2012-01-04 01:45:52 <[Tycho]> Also using "," op makes code funnier.
201 2012-01-04 01:46:06 <gmaxwell> the preincrement is fairly uncommon in most C code bases, and I've seen it confuse people.
202 2012-01-04 01:46:27 <luke-jr> gmaxwell: just because everyone else does it wrong, doesn't mean you should! :P
203 2012-01-04 01:46:36 <luke-jr> and Bitcoin is C++
204 2012-01-04 01:46:48 <luke-jr> postincrement actually has overhead in C++
205 2012-01-04 01:47:19 <gmaxwell> well, it doesn't for primitive types of course.
206 2012-01-04 01:47:32 <luke-jr> but you don't know the type is primitive :p
207 2012-01-04 01:47:55 <gmaxwell> I had some code that did i=0;do{&}while(++i<flag); confuse the #@$@# out of people multiple times.
208 2012-01-04 01:48:26 <luke-jr> gmaxwell: the same people would be confused by the `do' statement
209 2012-01-04 01:49:55 <gmaxwell> oh, the flag case actually looks like i=0;do{&}while(++i<1+flag);
210 2012-01-04 01:50:17 <luke-jr> ok, that is just stupid :P
211 2012-01-04 01:50:25 <luke-jr> in that case, it should be (i++<flag)
212 2012-01-04 01:50:48 <luke-jr> or better yet
213 2012-01-04 01:50:52 <luke-jr> (++i<=flag)
214 2012-01-04 01:52:37 <roconnor> if (opcode > OP_16 && ++nOpCount > 201) // Honestly I'm not entirely sure how many operations are allowed 200? 201? 202?
215 2012-01-04 01:52:54 <roconnor> I think it is 201
216 2012-01-04 01:53:15 <gmaxwell> luke-jr: some fluke of the ti compiler made the former construction preferred, sadly.
217 2012-01-04 01:53:43 <luke-jr> roconnor: 201
218 2012-01-04 02:03:36 <roconnor> 201 ops should be enough for anyone.
219 2012-01-04 02:09:54 <roconnor> yay, OP_IF works
220 2012-01-04 02:10:10 <luke-jr> lol
221 2012-01-04 02:28:48 <BlueMatt> ;;seen theymos
222 2012-01-04 02:28:48 <gribble> theymos was last seen in #bitcoin-dev 54 minutes and 9 seconds ago: <theymos> What do you guys think about OP_EVAL that only works on data with an "execute flag"? This seems a bit cleaner to me.
223 2012-01-04 02:31:17 <phantomcircuit> ok so i see one problem with configuring hidden services
224 2012-01-04 02:31:35 <phantomcircuit> specifically that you have to specify HiddenServiceDir
225 2012-01-04 02:31:47 <phantomcircuit> which isn't really something you can come up with safely ourselves
226 2012-01-04 02:31:51 <phantomcircuit> we*
227 2012-01-04 02:33:34 <gmaxwell> phantomcircuit: yea, this is a bigger problem for some other things.. like the torchat that needs to know the hidden service private keys for mutual authentication.
228 2012-01-04 02:34:05 <gmaxwell> phantomcircuit: but I thought there was a feature proposal to help.. I don't know where that currently stands.
229 2012-01-04 02:34:38 <gmaxwell> phantomcircuit: see also https://trac.torproject.org/projects/tor/ticket/1949
230 2012-01-04 02:35:20 <phantomcircuit> gmaxwell, well i could do something lazy like use temporary directory
231 2012-01-04 02:35:26 <phantomcircuit> but that seems like a bad plan
232 2012-01-04 02:46:51 <phantomcircuit> gmaxwell, actually i think this will be relatively easy to do so long as the hidden service is preconfigured
233 2012-01-04 02:49:12 <roconnor> ramdisk?
234 2012-01-04 02:53:09 <phantomcircuit> roconnor, cant set that up as a normal user
235 2012-01-04 02:53:20 <phantomcircuit> and definitely wouldnt work on windows
236 2012-01-04 02:54:20 <roconnor> testnet needs more OP_CODESEPARATOR
237 2012-01-04 02:56:51 <phantomcircuit> so somone with a better understanding of the structure of the code want to tell me where i should add code to connect to the tor control channel and get the hidden services configuration?
238 2012-01-04 03:00:45 <phantomcircuit> actually
239 2012-01-04 03:00:49 <phantomcircuit> that doesn't seem to be possible
240 2012-01-04 03:00:51 <phantomcircuit> boo
241 2012-01-04 03:03:28 <phantomcircuit> i can get the directory the hidden service name is in
242 2012-01-04 03:03:34 <phantomcircuit> but then wont have permissions to read
243 2012-01-04 03:09:24 <phantomcircuit> bleh
244 2012-01-04 03:09:26 <phantomcircuit> so
245 2012-01-04 03:09:29 <phantomcircuit> onioncat is GPLv3
246 2012-01-04 03:09:50 <phantomcircuit> who wants to engage in a bit of white room reverse engineering?
247 2012-01-04 03:09:52 <phantomcircuit> anybody
248 2012-01-04 03:10:29 <luke-jr> lol nice
249 2012-01-04 03:11:24 <phantomcircuit> luke-jr, IS THAT A YES?
250 2012-01-04 03:11:40 <phantomcircuit> i just need a small write up of the encoding they use for ipv6 <-> onion
251 2012-01-04 03:12:02 <luke-jr> no, that's a "haha, no tor integration" ;)
252 2012-01-04 03:12:43 <phantomcircuit> boo
253 2012-01-04 03:13:03 <phantomcircuit> BlueMatt, roconnor gmaxwell any takers?
254 2012-01-04 03:13:17 <roconnor> sorry
255 2012-01-04 03:13:35 <roconnor> phantomcircuit: are wo doing tor instead of freenet now?
256 2012-01-04 03:15:26 <roconnor> Patterns not matched:
257 2012-01-04 03:15:27 <roconnor> OP_SHA1
258 2012-01-04 03:15:29 <roconnor> OP_CODESEPARATOR
259 2012-01-04 03:15:32 <roconnor> 2 more ops to go
260 2012-01-04 03:16:14 <phantomcircuit> roconnor, this is actually very low hanging fruit
261 2012-01-04 03:16:24 <phantomcircuit> i could probably get this working like today
262 2012-01-04 03:16:32 <roconnor> I'm going to bed
263 2012-01-04 03:18:25 <BlueMatt> phantomcircuit: I dont know the first thing about restrictions on what you are/arent allowed to know during whiteroom reverse engineering
264 2012-01-04 03:19:09 <phantomcircuit> BlueMatt, tell me the algorithm used basically
265 2012-01-04 03:19:13 <BlueMatt> though I have never searched/read anything on onioncat that I remember, so if you tell me what Im allowed to know...
266 2012-01-04 03:19:13 <phantomcircuit> without telling me their code
267 2012-01-04 03:19:18 <phantomcircuit> it's insanely stupid
268 2012-01-04 03:19:22 <phantomcircuit> but woo copyright law
269 2012-01-04 03:19:41 <BlueMatt> phantomcircuit: well I cant look it up because if I look it up on wikipedia then the person who wrote on wikipedia probably read the code
270 2012-01-04 03:19:48 <BlueMatt> does that count?
271 2012-01-04 03:20:13 <theymos> I don't think copyright applies to simple facts like that algorithm.
272 2012-01-04 03:20:25 <BlueMatt> theymos: it does when lawyers are involved
273 2012-01-04 03:20:40 <BlueMatt> though theoretically mathematical algorithms are not copyrightable
274 2012-01-04 03:20:56 <BlueMatt> also, doesnt the person who has never read the onioncat source have to do the full implementing, not just tell you the algorithm?
275 2012-01-04 03:20:58 <phantomcircuit> theymos, it doesn't however if i was to read their code then implement the algorithm myself a clever lawyer might be able to say i just made a copy and modified it
276 2012-01-04 03:21:08 <phantomcircuit> if someone describes the algorithm too me however they cant
277 2012-01-04 03:21:13 <phantomcircuit> because i haven't even seen their code
278 2012-01-04 03:22:32 <phantomcircuit> actually i could just write my own packing algorithm
279 2012-01-04 03:22:37 <phantomcircuit> it shouldn't really matter
280 2012-01-04 03:23:05 <BlueMatt> not sure if we could pull that...
281 2012-01-04 03:23:15 <phantomcircuit> These 16-character hashes can be made up of any letter of the alphabet, and decimal digits beginning with 2 and ending with 7, thus representing an 80-bit number in base32.
282 2012-01-04 03:23:16 <phantomcircuit> dur
283 2012-01-04 03:23:28 <phantomcircuit> i can just debase32
284 2012-01-04 03:42:31 <BlueMatt> phantomcircuit: I SEE YOU
285 2012-01-04 03:42:50 <phantomcircuit> BlueMatt, xD
286 2012-01-04 03:44:02 <nanotube> try sending him an email ? :)
287 2012-01-04 03:44:39 <BlueMatt> I filed a bug report, but Im too lazy to bug him by email
288 2012-01-04 03:44:48 <BlueMatt> maybe Ill get around to it someday...
289 2012-01-04 03:45:59 <phantomcircuit> so
290 2012-01-04 03:46:36 <luke-jr> BlueMatt: lol, I've done that before
291 2012-01-04 03:48:08 <phantomcircuit> is there a special variable for "whoami"
292 2012-01-04 03:48:18 <phantomcircuit> im sure there is but have no idea what it is
293 2012-01-04 03:50:47 <BlueMatt> variable where?
294 2012-01-04 03:51:21 <phantomcircuit> i mean a static
295 2012-01-04 03:51:26 <phantomcircuit> in bitcoin somewhere
296 2012-01-04 03:51:34 <phantomcircuit> that represents what we think our own address is
297 2012-01-04 03:51:35 <BlueMatt> whoami like uid?
298 2012-01-04 03:51:42 <BlueMatt> oh, ip yea I think there is...
299 2012-01-04 03:51:42 <phantomcircuit> no
300 2012-01-04 03:52:30 <theymos> addrMe, I think.
301 2012-01-04 03:52:31 <BlueMatt> addrLocalHost
302 2012-01-04 03:53:52 <phantomcircuit> this is actually going to be fairly easy
303 2012-01-04 03:54:01 <phantomcircuit> if you already have the hidden service setup
304 2012-01-04 03:56:22 <phantomcircuit> BlueMatt, neat
305 2012-01-04 03:56:32 <phantomcircuit> id ack but i have no idea about qt
306 2012-01-04 03:56:38 <luke-jr> BlueMatt: I'd do it free if it fixed spec compliance ;)
307 2012-01-04 03:57:02 <BlueMatt> phantomcircuit: just compile it, beat on it a bit and comment that you beat on it a bit and it worked
308 2012-01-04 03:57:10 <BlueMatt> phantomcircuit: pretty please/
309 2012-01-04 03:57:11 <BlueMatt> ?
310 2012-01-04 03:57:37 <phantomcircuit> i'll put it in the middle of my todo list just below paying things and right above everything else
311 2012-01-04 03:57:39 <phantomcircuit> so
312 2012-01-04 03:57:46 <phantomcircuit> probably not this month? (yay money)
313 2012-01-04 03:58:23 <gmaxwell> phantomcircuit: whats there to reverse engineer.. you take the onion address. decode it.. pack it into and ipv6 address.. the required prefix was linked above.
314 2012-01-04 03:58:51 <phantomcircuit> gmaxwell, yeah i thought they were doing something clever to pack it
315 2012-01-04 03:58:53 <phantomcircuit> but they're not
316 2012-01-04 03:59:22 <gmaxwell> ah. yea, nothing smart is required. Just base conversion and perhaps getting the same byteorder.
317 2012-01-04 04:01:38 <gmaxwell> roconnor: there were people making a bunch of noise about freenet a while back, dunno if it resulted in code..
318 2012-01-04 04:01:59 <gmaxwell> but even if it did, it wouldn't really be anything to integrate with bitcoin, it would just be a gateway.
319 2012-01-04 04:02:31 <gmaxwell> tor support seems like a good candidate for direct support, since it fits with our normal p2p network protocol.
320 2012-01-04 04:02:32 <theymos> I don't think they really did anything. I didn't much like their proposal, anyway, since it required you to get "introduced" to the network by someone.
321 2012-01-04 04:04:12 <gmaxwell> yea, I remembered not being impressed.
322 2012-01-04 04:04:31 <BlueMatt> Im pretty sure they never got anywhere
323 2012-01-04 04:04:52 <gmaxwell> I really would like to see something relaying bitcoin that wasn't our p2p protocol.. but I'm kinda short on useful ideas other than doing it over HF radio (and I haven't yet found a remote endpoint for that yet)
324 2012-01-04 04:05:24 <gmaxwell> (the reason I want to see bitcoin over something other than our p2p is to use an example of how none of the p2p stuff is actually essential to the bitcoin algorithim)
325 2012-01-04 04:06:54 <BlueMatt> gmaxwell: if you wait a couple years till I get some disposable income, I probably will...
326 2012-01-04 04:07:03 <theymos> Freenet or GNUnet might work OK. I just didn't like that specific proposal.
327 2012-01-04 04:08:03 <nanotube> gmaxwell: what would be the least costly and most useful relay to set up?
328 2012-01-04 04:10:28 <gmaxwell> well most useful would probably be transatlantic, e.g. as a demo of bitcoin being healed if the internet gets broken, but such links aren't reliable which sort of degrades the usefulness.
329 2012-01-04 04:15:48 <phantomcircuit> you could broadcast bitcoin transactions/blocks over VHF or something
330 2012-01-04 04:17:03 <gmaxwell> phantomcircuit: sure, I could have that going in about 30 minutes.
331 2012-01-04 04:17:14 <gmaxwell> You don't go far that way though.
332 2012-01-04 04:18:22 <phantomcircuit> lol everytime i try and change something in bitcoin i have to remember c++
333 2012-01-04 04:18:33 <phantomcircuit> net.cpp:1734:9: error: ???fTor??? was not declared in this scope
334 2012-01-04 04:18:37 <nanotube> bounce lasers off the moon :)
335 2012-01-04 04:18:52 <gmaxwell> I've talked to cydeweys who is in #bitcoin sometimes over vhf over a 30 mi path or so.
336 2012-01-04 04:20:01 <gmaxwell> The blockchain datarate is really quite low.
337 2012-01-04 04:21:10 <phantomcircuit> lol no wonder
338 2012-01-04 04:21:19 <phantomcircuit> fTor is refined in 2 places ie isn't global
339 2012-01-04 04:21:24 <phantomcircuit> but all definitions are identical
340 2012-01-04 04:21:30 <gmaxwell> The _maximum_ average block rate right now is something like 14kbit/sec, if you don't mind it taking 600 seconds to send a whole 1mb block.
341 2012-01-04 04:24:07 <BlueMatt> gmaxwell: chain download is disturbingly fast now...
342 2012-01-04 04:25:35 <gmaxwell> need to get the pointless db activity out of the way..
343 2012-01-04 04:25:55 <gmaxwell> Pfft.
344 2012-01-04 04:26:03 <BlueMatt> gmaxwell: probably not too hard to do in CBlockStore
345 2012-01-04 04:26:17 <BlueMatt> (hopefully)
346 2012-01-04 04:26:30 <gmaxwell> if not a seperate dbenv, we could at least do batch updates or something.
347 2012-01-04 04:26:54 <nanotube> BlueMatt: i bet you feel kinda like the guy who invented captchas now eh? :D
348 2012-01-04 04:27:08 <BlueMatt> nanotube: haha, ok that was good
349 2012-01-04 04:27:13 <phantomcircuit> crap where is genjix
350 2012-01-04 04:27:14 <phantomcircuit> or
351 2012-01-04 04:27:21 <gmaxwell> BlueMatt: I went over it very quickly, seems to be going in a useful direction. I will read it more carefully in the coming day or two and test it some.
352 2012-01-04 04:27:24 <phantomcircuit> someone tell me how the hell the extern settings work
353 2012-01-04 04:27:59 <BlueMatt> gmaxwell: good to hear
354 2012-01-04 04:28:21 <gmaxwell> BlueMatt: if you want to repent more you could look into using the boost pool allocator for the securealloc so that keypool filling won't take 17 seconds or whatever for me.
355 2012-01-04 04:29:26 <gmaxwell> (basically it's just a pluggable allocator where you can set the functions it uses to get memory.. e.g. you add the code to mlock there.. so we only end up with one or two mlocks during the whole bitcoin run, way better than the ten zillion that still happen with your patch)
356 2012-01-04 04:29:33 <BlueMatt> gmaxwell: Ill put it on the todo
357 2012-01-04 04:29:58 <phantomcircuit> nvm i'll figure it out
358 2012-01-04 04:31:27 <phantomcircuit> lol there is a completely useless line
359 2012-01-04 04:31:37 <phantomcircuit> net.cpp:1473
360 2012-01-04 04:32:30 <BlueMatt> gmaxwell: first let me benchmark cblockstore (it does AddToWalletIfInvolvingMe in callbacks and thus another thread which appears to do a small but measurable increase in chain download perf)
361 2012-01-04 04:33:38 <gmaxwell> phantomcircuit: hm. clang scan-build should whine about that.
362 2012-01-04 04:33:48 <phantomcircuit> fTOR is never used
363 2012-01-04 04:33:50 <phantomcircuit> anywhere
364 2012-01-04 04:33:57 <phantomcircuit> fTor is
365 2012-01-04 04:34:23 <gmaxwell> I mean it should whine about the stuff being assigned and never used within its scope.
366 2012-01-04 04:34:25 <kiba> boom
367 2012-01-04 04:34:37 <phantomcircuit> yeah
368 2012-01-04 04:34:42 <phantomcircuit> guess it doesn't?
369 2012-01-04 04:34:57 <gmaxwell> phantomcircuit: gavin just committed some ftor related changes today that stupidity might have been a result of.
370 2012-01-04 04:34:57 <theymos> fTOR is used in 0.3.19. Maybe it changed.
371 2012-01-04 04:35:31 <gmaxwell> phantomcircuit: see https://github.com/bitcoin/bitcoin/issues/739
372 2012-01-04 04:37:10 <phantomcircuit> gmaxwell, yeah he added the fTor which is used
373 2012-01-04 04:37:17 <phantomcircuit> fTOR is from satoshi
374 2012-01-04 04:37:18 <theymos> Always annoyed me how Satoshi incorrectly said TOR instead of Tor.
375 2012-01-04 04:37:23 <phantomcircuit> and appears to have been obliterated
376 2012-01-04 04:37:28 <BlueMatt> there have been quite a few fTor changes recently
377 2012-01-04 04:37:36 <phantomcircuit> anyways
378 2012-01-04 04:37:46 <phantomcircuit> this is actually fairly easy to do
379 2012-01-04 04:37:57 <phantomcircuit> i should have a tor hidden services build available soonish
380 2012-01-04 04:38:13 <gmaxwell> phantomcircuit: yea, seemed to so me, I brought it up today just because I didn't want sipa's new address code to make it harder! :)
381 2012-01-04 04:38:37 <phantomcircuit> this would actually be much easier with an ipv6 compatible build
382 2012-01-04 04:39:10 <phantomcircuit> as it stands i will probably have to create a COnionAddress object
383 2012-01-04 04:40:25 <gmaxwell> bleh. yea, this should leverage ipv6 as much as possible I think the only part should know about onion addresses are -connect and -addnode, and the actual connection logic.
384 2012-01-04 04:40:42 <phantomcircuit> pretty much
385 2012-01-04 04:41:01 <gmaxwell> The rest of the code should just think it's just IPv6.
386 2012-01-04 04:41:05 <phantomcircuit> yeah
387 2012-01-04 04:42:31 <gmaxwell> If you want to get really fansy pants: running different anti-collision IDs on tor and not tor connections, and having a mode to run normally but only announce your own txn via tor unless you've heard them from the network....
388 2012-01-04 04:42:50 <gmaxwell> so you could run mixed mode nodes without hurting the privacy of using tor.
389 2012-01-04 04:43:02 <kiba> status maximinzing versus moneymaking
390 2012-01-04 04:43:23 <gmaxwell> kiba: yibble plop?
391 2012-01-04 04:43:32 <kiba> just thinking about human motives
392 2012-01-04 04:43:48 <kiba> it would seems to me that humans are more motiviated by status rather than money
393 2012-01-04 04:44:01 <gmaxwell> kiba: whats money but a way of buying status?
394 2012-01-04 04:44:06 <gmaxwell> it's kinda boring by itself.
395 2012-01-04 04:44:30 <kiba> gmaxwell: well, charities don't need to be "non-profit" to achieve improtant changes
396 2012-01-04 04:45:06 <phantomcircuit> hmm
397 2012-01-04 04:45:21 <phantomcircuit> if the local address is 127.0.0.1:8333
398 2012-01-04 04:45:41 <phantomcircuit> then i cant accept connections from anybody who cant reach 127.0.0.0/8 which is everybody but me
399 2012-01-04 04:45:43 <phantomcircuit> ok safe
400 2012-01-04 04:45:47 <kiba> it might be better for charity to have one money maxinizing activities they're good at, and pass some of the profit to an organization that achieve actual change
401 2012-01-04 04:45:59 <kiba> say
402 2012-01-04 04:46:03 <kiba> you're a world class laywer
403 2012-01-04 04:46:38 <kiba> it's better to be a lawyer and make looooooooot of money and then donate most of the proceed to somebody who will use the money wisely, rather than work on legal cases for charities
404 2012-01-04 04:47:19 <kiba> it might make you feel a lot better to work on legal cases, but on balance, it's much better to just give money
405 2012-01-04 04:48:54 <kiba> humans are overly complicated creatures for seemly no good reasons sometime
406 2012-01-04 04:52:53 <phantomcircuit> fUseProxy = 0
407 2012-01-04 04:53:02 <phantomcircuit> yeah i would say fUseProxy is broken
408 2012-01-04 04:54:06 <gmaxwell> init.cpp: fUseProxy = true;
409 2012-01-04 04:54:46 <phantomcircuit> yeah it's after that printf
410 2012-01-04 04:55:58 <phantomcircuit> ah i see
411 2012-01-04 04:56:07 <phantomcircuit> there are settings saved in the wallet.dat
412 2012-01-04 04:56:58 <gmaxwell> .. there .. are . huh????!
413 2012-01-04 04:57:09 <BlueMatt> gmaxwell: you didnt know that?
414 2012-01-04 04:57:21 <BlueMatt> settings have always been saved in wallet.dat...
415 2012-01-04 04:57:51 <BlueMatt> but...yea
416 2012-01-04 04:58:06 <Joric> ah that's why you fuck em up when you're replacing the wallet
417 2012-01-04 05:00:00 <phantomcircuit> ok what the fuck
418 2012-01-04 05:00:04 <phantomcircuit> i have this open in gdb
419 2012-01-04 05:00:18 <phantomcircuit> just went over if (fTor)
420 2012-01-04 05:00:20 <phantomcircuit> and yet
421 2012-01-04 05:00:23 <phantomcircuit> print fTor
422 2012-01-04 05:00:28 <phantomcircuit> $6 = 0
423 2012-01-04 05:00:31 <phantomcircuit> ???????????????????????????????
424 2012-01-04 05:02:14 <midnightmagic> shared variable between threads?
425 2012-01-04 05:02:47 <midnightmagic> aand.. overwritten by a bad syscall in another?
426 2012-01-04 05:02:49 <phantomcircuit> onlt 1 thread
427 2012-01-04 05:03:01 <phantomcircuit> this is in init.cpp InitApp
428 2012-01-04 05:03:48 <phantomcircuit> some insanity scope thing i guess
429 2012-01-04 05:06:40 <wumpus> yes, all the ui-set settings are stored in wallet.dat ... that will give problems when multi-wallet support is added
430 2012-01-04 05:07:01 <wumpus> phantomcircuit: the handling of fTor/mUseProxy etc was recently refactored, maybe there's a bug
431 2012-01-04 05:07:19 <wumpus> well there was a bug already... but maybe there's a new one now the old one is fixed :-)
432 2012-01-04 05:07:30 <gmaxwell> BlueMatt: I haven't used the ui at any time in the modern era.
433 2012-01-04 05:07:48 <luke-jr> wumpus: hey
434 2012-01-04 05:08:05 <wumpus> well also if you change settings through rpc, all settings remembered by bitcoin itself in general are in the wallet
435 2012-01-04 05:08:13 <wumpus> luke-jr: hey
436 2012-01-04 05:08:17 <luke-jr> wumpus: "not all tx'es with "from"/"to" field are necessarily IP tx'es" - is that true before, or only after, OP_EVAL?
437 2012-01-04 05:08:30 <wumpus> it has always been true
438 2012-01-04 05:08:36 <luke-jr> k
439 2012-01-04 05:08:38 <wumpus> with rpc you can set the to field
440 2012-01-04 05:08:53 <BlueMatt> gmaxwell: mmm
441 2012-01-04 05:08:55 <wumpus> in sendaddress
442 2012-01-04 05:09:00 <luke-jr> wumpus: could you get signmessage merged? ;p
443 2012-01-04 05:09:14 <luke-jr> plz
444 2012-01-04 05:09:24 <wumpus> yes it's on my todo
445 2012-01-04 05:10:20 <luke-jr> k, just would prefer to not have to keep rebasing it
446 2012-01-04 05:10:41 <wumpus> yes, having to rebase it alll the time is bad...
447 2012-01-04 05:15:51 <phantomcircuit> ok partial victory
448 2012-01-04 05:15:54 <phantomcircuit> this
449 2012-01-04 05:15:57 <phantomcircuit> kind of works
450 2012-01-04 05:16:08 <phantomcircuit> if you setup all the tor stuff yourself
451 2012-01-04 05:16:15 <phantomcircuit> and know the hidden node you want to connect to
452 2012-01-04 05:16:16 <phantomcircuit> so
453 2012-01-04 05:16:17 <phantomcircuit> yeah
454 2012-01-04 05:17:42 <gmaxwell> Cool. Well phase 1 then.. Phase 2 you tell the node its own hidden service address, and it can announce it and you can connect to more.
455 2012-01-04 05:19:44 <phantomcircuit> phase 1 basically consists of listening on 127.0.0.1 instead of not listening at all
456 2012-01-04 05:19:46 <phantomcircuit> more or less
457 2012-01-04 05:22:33 <phantomcircuit> wtf
458 2012-01-04 05:22:36 <phantomcircuit> is it just me
459 2012-01-04 05:22:48 <phantomcircuit> or is master completely missing -connect
460 2012-01-04 05:24:41 <gmaxwell> phantomcircuit: it's you
461 2012-01-04 05:25:58 <phantomcircuit> good
462 2012-01-04 06:04:55 <phantomcircuit> gmaxwell, yeah im not going to add a special handler
463 2012-01-04 06:05:09 <phantomcircuit> what's the best ipv6 branch currently available
464 2012-01-04 06:14:37 <BlueMatt> sipa has one
465 2012-01-04 06:14:41 <BlueMatt> (not sure how up-to-date it is)
466 2012-01-04 09:07:05 <sipa> phantomcircuit: i have a 'ipv6' branch that is outdated but works
467 2012-01-04 09:08:01 <phantomcircuit> sipa, did you more recently create a branch to just handle the addresses?
468 2012-01-04 09:08:08 <sipa> i also have a 'netbase' branch that is up to date, and has almost ipv6 support
469 2012-01-04 09:14:53 <phantomcircuit> yeah
470 2012-01-04 09:15:05 <phantomcircuit> all i need is a way to pass around the onion in ipv6 addresses
471 2012-01-04 09:15:38 <phantomcircuit> i dont need actual ipv6 connection support since i have to change the actual connect() call to send the .onion domain name and not an ip address anyways
472 2012-01-04 09:15:47 <phantomcircuit> sipa, how close is that to being merged?
473 2012-01-04 09:15:58 <phantomcircuit> i think i was reading it earlier and didn't see any issues
474 2012-01-04 09:43:35 <sipa> phantomcircuit: i hope close
475 2012-01-04 11:35:15 <CIA-100> bitcoin: p2k * r6cf95a483b1d ecoinpool/ (4 files in 2 dirs): MySQL Replicator http://tinyurl.com/7wckkch
476 2012-01-04 14:31:47 <UukGoblin> no mtgox trades reported by bitcoincharts for 1h20m
477 2012-01-04 14:35:12 <erus`> :O
478 2012-01-04 14:57:44 <UukGoblin> still broken
479 2012-01-04 15:04:06 <phantomfake> I have a stupid question, is there any way to use Bitcoin as password tokens?
480 2012-01-04 15:10:06 <gmaxwell> What is a password token? You mean like a two-factor auth keyfob?
481 2012-01-04 15:10:34 <gmaxwell> I mean you could require someone to pay 0.01 btc every time they attempt to log in, that would certantly reduce bruteforcing.. but that would be an unusual approach.
482 2012-01-04 15:11:27 <gmaxwell> phantomfake: another approach would be to use a JS miner to force someone to do some bitcoin mining for you before they can log in (or in between incorrect attempts)
483 2012-01-04 15:11:47 <gmaxwell> The problem there is that a savvy attacker could use a fast gpu miner to easily do that mining.
484 2012-01-04 15:12:11 <helo> hmmm... it would be cool if you could do something with the block hashes to make a synchronized time-changing password token
485 2012-01-04 15:13:00 <gmaxwell> helo: nah, doesn't make much sense. I mean all those things just run a clock through an hmac, so you could do that with blocks.. but if you can feed data into the token, just use challenge response.
486 2012-01-04 15:13:38 <helo> yeah...
487 2012-01-04 15:14:03 <gmaxwell> once opencl becomes common, perhaps mining captchas will become viable.
488 2012-01-04 15:14:42 <helo> Click this button to demonstrate that you have a nice computer.
489 2012-01-04 15:14:51 <gmaxwell> (er, webcl not opencl)
490 2012-01-04 15:18:51 <phantomfake> gmaxwell, I don't understand the problem, how could the miner attack the system?
491 2012-01-04 15:20:13 <gmaxwell> phantomfake: In what kind of usage?
492 2012-01-04 15:20:32 <phantomfake> gmaxwell, I just didn't understand what you said before.
493 2012-01-04 15:21:05 <gmaxwell> phantomfake: well, I didn't know what you were asking, so I made some guesses. Perhaps if you clarify your question then I can clarify my answer?
494 2012-01-04 15:21:23 <phantomfake> gmaxwell, haha ok, I'll try.
495 2012-01-04 15:22:26 <Diablo-D3> http://www.regretsy.com/2012/01/03/from-the-mailbag-27/
496 2012-01-04 15:22:30 <phantomfake> gmaxwell, When I asked about using Bitcoin as a password token you said a miner would be able to compromise such a system.
497 2012-01-04 15:22:45 <gmaxwell> phantomfake: Explain what you mean by password token.
498 2012-01-04 15:23:48 <phantomfake> gmaxwell, If a password could be exchanged for spending Bitcoin.
499 2012-01-04 15:24:23 <phantomfake> gmaxwell, Or using the spending of Bitcoin as an authentication mechanism.
500 2012-01-04 15:24:58 <gmaxwell> phantomfake: You can do that but bitcoin is fungable, so you're only authenticating someone as someone who has bitcoin. :) And there are a lot of people who have bitcoin.
501 2012-01-04 15:27:19 <phantomfake> gmaxwell, The fungible nature of Bitcoin is a good thing in this case as most people have more than one password. If an account is established with a known Bitcoin address at signup couldn't that sending address be trusted?
502 2012-01-04 15:27:36 <gmaxwell> phantomfake: There isn't a 'sending address', really.
503 2012-01-04 15:28:13 <gmaxwell> Though if you wanted to use a bitcoin address as an authentication method, you could use the signmessage feature and you don't have to send any bitcoin at all.
504 2012-01-04 15:29:52 <phantomfake> gmaxwell, Could you please send me a like to that?
505 2012-01-04 15:30:25 <phantomfake> gmaxwell, Has this question been asked before?
506 2012-01-04 15:31:24 <luke-jr_> http://www.regretsy.com/2012/01/03/from-the-mailbag-27/
507 2012-01-04 15:33:03 <gmaxwell> $ ./bitcoind signmessage 1AGMAXWELLayCyS1vkLXEszESHEcB3LWqa "This address belongs to gmaxwell on freenode"
508 2012-01-04 15:33:11 <gmaxwell> HD4ct3e5j933O+6BmMeImVFd6FJayzH1ujafeCbkbBr9f+Acj+GcYishrJrYN/z7QyW5MdWaw3AaY+Y8Dxw5nX0=
509 2012-01-04 15:33:26 <gmaxwell> $ .//bitcoind verifymessage 1AGMAXWELLayCyS1vkLXEszESHEcB3LWqa "HD4ct3e5j933O+6BmMeImVFd6FJayzH1ujafeCbkbBr9f+Acj+GcYishrJrYN/z7QyW5MdWaw3AaY+Y8Dxw5nX0=" "This address belongs to gmaxwell on freenode"
510 2012-01-04 15:33:34 <gmaxwell> true
511 2012-01-04 15:34:08 <gmaxwell> and why the heck does the verify interface require you to provide the address? It could just print the address that signed, or 'false' if it's not valid.
512 2012-01-04 15:34:47 <gmaxwell> phantomfake: the gui interface for signmessage hasn't been merged yet, the feature is cli/rpc only at the moment.
513 2012-01-04 15:34:47 <roconnor> gmaxwell: that would require keyrecovery, no?
514 2012-01-04 15:34:56 <gmaxwell> roconnor: it already uses key recovery.
515 2012-01-04 15:35:10 <roconnor> gmaxwell: oh? I didn't think key recovery was part of openssl
516 2012-01-04 15:35:23 <gmaxwell> roconnor: the address wouldn't let it work without key recovery regardless the address is a hash, remember? :)
517 2012-01-04 15:35:34 <gmaxwell> roconnor: there is key recovery in bitcoin now, for this. :)
518 2012-01-04 15:36:45 <roconnor> gmaxwell: who wrote that?
519 2012-01-04 15:36:50 <gmaxwell> roconnor: sipa
520 2012-01-04 15:37:11 <gmaxwell> roconnor: the signature contains the extrabits required to disambiguate the recovery.
521 2012-01-04 15:37:31 <phantomfake> I'm in a little over my head with all this, just started learning about cryptography and the inner working of the Bitcoin protocol but its all really cool stuff.
522 2012-01-04 15:38:07 <gmaxwell> phantomfake: in any case, if you're mapping users to addresses in your mind you're probably making a mistake. Ideally a bitcoin user uses a new address with every transaction.
523 2012-01-04 15:38:28 <gmaxwell> If they don't they compromise their own privacy and that of their trading partners.
524 2012-01-04 15:39:26 <phantomfake> gmaxwell, I was going along those lines, but what I was getting at was that owning an address could prove ownership.
525 2012-01-04 15:39:41 <gmaxwell> Yes, I just demonstrated that above.
526 2012-01-04 15:40:31 <gmaxwell> Though when you send coins they don't 'come from' any particular address. So that complicates the kind of usage you're thinking about.
527 2012-01-04 15:41:29 <phantomfake> gmaxwell, They are generated randomly for each wallet using a hashing alg right?
528 2012-01-04 15:42:46 <sipa> gmaxwell: the reason for requiring the address is legacy, actually
529 2012-01-04 15:42:47 <phantomfake> gmaxwell, Could a collision of recipient addresses occur ?
530 2012-01-04 15:42:53 <gmaxwell> phantomfake: a new one is generated randomly any time you hit get new address or create a txn that needs change back using a cryptographically secure pseudo-random number generator. (the CSPRNG uses hashes, but thats incidental)
531 2012-01-04 15:43:16 <gmaxwell> sipa: it kinda sucks. :( also sucks that its first so its not easy to make optional without breaking compatiblity.
532 2012-01-04 15:43:39 <gmaxwell> phantomfake: Yes, though its astronomically unlikely, the addresses are 160 bits long.
533 2012-01-04 15:45:19 <phantomfake> gmaxwell, I haven't visited the wiki in a while, is this still the best place for me to dig into it?
534 2012-01-04 15:46:15 <gavinandresen> no
535 2012-01-04 15:46:32 <gavinandresen> wait, yes.
536 2012-01-04 15:46:52 <gavinandresen> (wiki is a pretty good place to find out about bitcoin crypto)
537 2012-01-04 15:46:59 <phantomfake> Hey Gavin!
538 2012-01-04 15:47:18 <gavinandresen> ... although bitcoin.stackexchange.com might be better
539 2012-01-04 15:47:30 <phantomfake> gavinandresen, nice :)
540 2012-01-04 15:51:00 <phantomfake> Is there anyway to maintain a "receiving address" or will the client eventually cycle it out or delete it?
541 2012-01-04 15:51:01 <roconnor> sipa: there is something to be said for entering the address and validating, because people are notoriously bad at comapring long strings of essentially random characters.
542 2012-01-04 15:51:47 <phantomfake> The wiki says: ECDSA is a cryptographic algorithm used by Bitcoin to ensure that funds can only be spent by their rightful owners.
543 2012-01-04 15:51:50 <gmaxwell> roconnor: it's true, and I think it should be a recommended practice. Making it required is a little blah though.
544 2012-01-04 15:51:55 <sipa> phantomfake: the client never deletes keys
545 2012-01-04 15:52:10 <roconnor> gmaxwell: I agree, there should be a flag to return the signing address
546 2012-01-04 15:52:16 <gmaxwell> phantomfake: it's still a bad practice to recieve to a single address.
547 2012-01-04 15:52:25 <sipa> and yes, ECDSA and SHA256 are used (and AES-256-CBC for wallet encryption)
548 2012-01-04 15:52:31 <sipa> and RIPEMD160 as well
549 2012-01-04 15:52:39 <roconnor> sipa: and SHA1 in prinicple
550 2012-01-04 15:52:47 <sipa> roconnor: hmm, where?
551 2012-01-04 15:52:51 <phantomfake> gmaxwell, What about creating a wallet for just one purpose?
552 2012-01-04 15:52:51 <roconnor> sipa: OP_SHA1
553 2012-01-04 15:52:57 <sipa> ah, right
554 2012-01-04 15:53:21 <phantomfake> sipa, RIPEMD160 for address, right?
555 2012-01-04 15:53:34 <sipa> yes, addresses are RIPEMD160(SHA256(pubkey))
556 2012-01-04 15:53:38 <gmaxwell> I thought things like OP_SHA1 were there for zero-trust payments and the like.
557 2012-01-04 15:53:46 <phantomfake> sipa, I see.
558 2012-01-04 15:54:24 <gavinandresen> Anybody willing to proof-read the draft pay-to-script-hash BIP before I send it to genjix?
559 2012-01-04 15:54:26 <gavinandresen> https://gist.github.com/1557931
560 2012-01-04 15:57:21 <roconnor> gavinandresen: I think you should be more clear about what {20-byte-hash-value} Can I use OP_PUSHDATA4 if I want or must it always be 0x14 followed by 20 bytes?
561 2012-01-04 15:59:36 <luke-jr_> gavinandresen: better to just re-activate BIP 12
562 2012-01-04 16:00:42 <gmaxwell> gavinandresen: I don't notice the logs from last night, but we have [Tycho] and luke-jr_ saying they will implement BIP_12 instead, fuckall the discussion.
563 2012-01-04 16:01:02 <sipa> gavinandresen: assuming that there is an actual support of 50% from miners, and one weeks counts 1000 blocks, it is reasonable to see between 455 and 545 /P2SH/ strings
564 2012-01-04 16:01:19 <sipa> (3 standard deviations)
565 2012-01-04 16:01:44 <[Tycho]> I didn't said that.
566 2012-01-04 16:02:30 <gavinandresen> They can continue supporting OP_EVAL if they like, it is compatible with the pay-to-script-hash proposal.
567 2012-01-04 16:02:49 <sipa> gavinandresen: so i would require at least 550 to be sure, preferrably more, as there is variation in hashing power too
568 2012-01-04 16:03:19 <gavinandresen> sipa: ok. 550 is a multiple of 11, so I like it.
569 2012-01-04 16:03:29 <sipa> good
570 2012-01-04 16:04:31 <gavinandresen> roconnor: what do you think? The Satoshi client's script-matching algorithm doesn't care which pushdata is used....
571 2012-01-04 16:05:10 <safra> hello
572 2012-01-04 16:05:14 <phantomfake> What exactly does pay-to-script allow you to do?
573 2012-01-04 16:05:35 <sipa> phantomfake: it allows me to give you the hash of a validation script i have, and allow you to pay to it
574 2012-01-04 16:05:56 <sipa> phantomfake: requiring me to reveal the script, plus prove that it validates, to use the sent coins
575 2012-01-04 16:05:57 <safra> i am looking for a PHP programmer, to make a bitcoin gateway
576 2012-01-04 16:06:00 <phantomfake> sipa, I didn't understand the implications of any of that
577 2012-01-04 16:06:06 <luke-jr> phantomfake: it's OP_EVAL, with a magic script template instead of an opcod
578 2012-01-04 16:06:10 <sipa> phantomfake: in practice, it allows a 2-out-of-3 payment for example
579 2012-01-04 16:06:27 <sipa> phantomfake: where i have a script that allows spending if there are 2 signatures from a set of 3
580 2012-01-04 16:06:41 <sipa> but i don't need to tell you this to allow you to pay
581 2012-01-04 16:07:20 <sipa> luke-jr: most people agree that the new proposal is ugly, but that it is better understood, specified and easier to implement
582 2012-01-04 16:07:41 <gavinandresen> I'm excited by it because I want people to start using bitcoin addresses that feed into wallets that need two signatures, created on two physically different devices, to spend from
583 2012-01-04 16:08:01 <luke-jr> sipa: worse understood, and easier to implement *because* it's broken-by-design
584 2012-01-04 16:08:08 <phantomfake> gavinandresen, Thats interesting..
585 2012-01-04 16:08:31 <luke-jr> it replaces Scripts with essentially predefined transaction types
586 2012-01-04 16:08:44 <gmaxwell> luke-jr: please be reasonable.
587 2012-01-04 16:08:52 <luke-jr> gmaxwell: this new thing is NOT reasonable
588 2012-01-04 16:08:59 <gavinandresen> luke-jr: The design is: "How can we move scripts from the scriptPubKey to the scriptSig in a backwards-compatible way?"
589 2012-01-04 16:09:01 <phantomfake> luke-jr, why?
590 2012-01-04 16:09:06 <gmaxwell> Disliking it might be reasonable, but the claim of "predefined transaction types" is just rubbish.
591 2012-01-04 16:09:11 <gavinandresen> luke-jr: ... and I think pay-to-script-hash meets that design in a minimal way.
592 2012-01-04 16:09:14 <luke-jr> gavinandresen: OP_EVAL did it fine
593 2012-01-04 16:09:22 <sipa> and there were objections to that
594 2012-01-04 16:09:30 <gmaxwell> It's specifying a pay-to-script. Thats it. There is still a script, it's provided by the other side.
595 2012-01-04 16:09:30 <sipa> and people who had those, have less objections now
596 2012-01-04 16:09:33 <luke-jr> well, there are bigger more valid objections to this
597 2012-01-04 16:09:36 <gavinandresen> luke-jr: I further think that if I was designing bitcoin from scratch, scriptPubKey would be JUST scriptHash.
598 2012-01-04 16:09:48 <sipa> gavinandresen: agree
599 2012-01-04 16:09:51 <gmaxwell> I agree with gavinandresen.
600 2012-01-04 16:10:13 <gmaxwell> (Or perhaps hashtype + scripthash, but whatever)
601 2012-01-04 16:10:26 <gavinandresen> So at some point in the future you can expect me to be arguing that all bitcoin implementations should produce nothing but the new pay-to-script-hash in the scriptPubKeys
602 2012-01-04 16:10:47 <sipa> i agree that the proposal is ugly if seen from the "special casing a script" standpoint, but quite elegant when considered from the "backward compatible way to move scripts to the input"
603 2012-01-04 16:10:57 <gmaxwell> sipa: exactly.
604 2012-01-04 16:11:53 <gavinandresen> luke-jr: And, again, if you like you can continue to support OP_EVAL, it'll play nicely with pay-to-script-hash
605 2012-01-04 16:12:17 <sipa> and the nicest thing is: one does not lose anything (except a few bytes possibly) by just moving everything to scriptSig now
606 2012-01-04 16:12:20 <luke-jr> I disagree that outputs should lose scripting
607 2012-01-04 16:12:47 <gmaxwell> luke-jr: Well, they aren't losing it at least not yet. But why do you find that objectionable?
608 2012-01-04 16:14:12 <gmaxwell> The output really does still have a script in a pay to scripthash... it's just there in an semi-opaque compressed form.
609 2012-01-04 16:15:58 <luke-jr> a special magic script is being defined as "this output is not a script anymore"
610 2012-01-04 16:16:00 <luke-jr> which is bs
611 2012-01-04 16:16:29 <gmaxwell> "no! you're bs!"
612 2012-01-04 16:16:38 <gmaxwell> Come on, please make a better argument than that.
613 2012-01-04 16:17:41 <gmaxwell> The fact that it upsets your inner austistic-geek shouldn't be a major consideration. It's a good approach, as far as I can tell. It results in the desired behavior, in a compatible way, with a simple implementation, and the resulting transactions are highly space efficient.
614 2012-01-04 16:18:53 <lianj> "space efficient" - i thought that train is long gone
615 2012-01-04 16:20:18 <gmaxwell> ...?
616 2012-01-04 16:21:02 <luke-jr> OP_EVAL extended the scripting capability
617 2012-01-04 16:21:07 <luke-jr> this nonsense DESTROYS it
618 2012-01-04 16:21:09 <luke-jr> (on one end)
619 2012-01-04 16:22:05 <gmaxwell> luke-jr: when building systems which must satisify many people, or really ones with interact with the real world at all, some compromise is needed and a little aesthetic quality is the first and the best thing to go.
620 2012-01-04 16:22:13 <gmaxwell> luke-jr: they both 'destroy' it equally.
621 2012-01-04 16:22:40 <gmaxwell> The same people who would advocate accepting/creating only pay-to-scripthash would advocate it however pay-to-scripthash was accomplished.
622 2012-01-04 16:22:58 <gavinandresen> luke-jr: the people implementing/re-implementing bitcoin (TD, justmoon, roconnor, me, genjix) all agree that pay-to-script-hash is a better approach FOR NOW.
623 2012-01-04 16:23:16 <luke-jr> pay-to-script-hash describes OP_EVAL
624 2012-01-04 16:24:28 <gavinandresen> luke-jr: any possibility you'll support both and put both OP_EVAL and /P2SH/ in your coinbases? Actually, your coinbases must be getting pretty crowded (did I read you are merge-mining three different chains now?)
625 2012-01-04 16:24:29 <gmaxwell> no, it describes writing payments where the rx side provides the script. Thats the goal that both op_eval and this can be used to implement. That goal removes scripting flexibility on one side of the txn if its all that is employed.
626 2012-01-04 16:24:51 <gmaxwell> gavinandresen: mm is O(1)
627 2012-01-04 16:24:51 <luke-jr> gavinandresen: where did you read that? merged-mining doesn't use more space for more chains
628 2012-01-04 16:25:04 <luke-jr> and no, I oppose P2SH, so I won't put it in the coinbase.
629 2012-01-04 16:25:16 <luke-jr> I will do what I can to prevent its adoption
630 2012-01-04 16:25:17 <gavinandresen> luke-jr: ok, I don't know nuthin about merged mining....
631 2012-01-04 16:25:34 <gavinandresen> luke-jr: sigh
632 2012-01-04 16:25:45 <luke-jr> merged mining uses a merkle tree
633 2012-01-04 16:27:32 <gavinandresen> roconnor: I modified the draft BIP to say that 20-byte-hash must be 0x14...
634 2012-01-04 16:27:40 <luke-jr> I won't oppose an OP_EVAL with P2SH-like semantics.
635 2012-01-04 16:27:54 <gmaxwell> What does that mean?
636 2012-01-04 16:28:02 <luke-jr> ie, the script needs to be pushed by 0x14
637 2012-01-04 16:28:30 <luke-jr> as much as I'd love to concatenate scripts in the future, I can live without it
638 2012-01-04 16:28:35 <gmaxwell> all this argument over just burning an extra byte in the script=
639 2012-01-04 16:28:47 <gmaxwell> well crap, just add the byte then. jesus.
640 2012-01-04 16:29:26 <[Tycho]> gavinandresen: why do you think that scripts should be statically analyzed ?
641 2012-01-04 16:29:40 <luke-jr> gmaxwell: it's more than just burnign a byte
642 2012-01-04 16:30:05 <gavinandresen> [Tycho]: I think it is better if it is POSSIBLE to statically analyze them.
643 2012-01-04 16:30:06 <luke-jr> gmaxwell: by keeping it an opcode-based language, you can change the scriptPubKey without losing the OP_EVAL function
644 2012-01-04 16:30:18 <luke-jr> P2SH basically *mandates* static analysis
645 2012-01-04 16:30:26 <luke-jr> OP_EVAL *prevents* static analysis
646 2012-01-04 16:30:37 <luke-jr> I prefer *optional* static analysis, or none at all
647 2012-01-04 16:30:41 <sipa> [Tycho]: read this: http://sourceforge.net/mailarchive/message.php?msg_id=28616889
648 2012-01-04 16:30:46 <gavinandresen> [Tycho]: I think when bitcoin becomes extremely popular and nodes relaying transactions have to quickly decide whether or not to relay them being able to determine very quickly how many sigops they require will be useful
649 2012-01-04 16:30:51 <[Tycho]> gavinandresen: I think it's even more safe to support runtime limits.
650 2012-01-04 16:31:19 <gavinandresen> [Tycho]: I agree, runtime limits are important, and I wouldn't suggest getting rid of them. Security in depth is a good idea.
651 2012-01-04 16:31:55 <luke-jr> gavinandresen: or they can just relay them regardless of sigops
652 2012-01-04 16:32:14 <gmaxwell> e.g. you might statically analyize scripts and then punt slow ones to a slow-txn handling cluster.
653 2012-01-04 16:32:28 <sipa> luke-jr: sorry, optional static analysis is as worthless as none at all - it is not in the interest of those creating transactions to allow it
654 2012-01-04 16:32:41 <gmaxwell> luke-jr: "P2SH basically *mandates* static analysis" < this is gibberish
655 2012-01-04 16:32:54 <sipa> it mandates analyzability
656 2012-01-04 16:32:55 <gmaxwell> You're not required to analyize anything, you can just run the scripts like normal.
657 2012-01-04 16:33:01 <gmaxwell> It mandates analyzability. Agreed.
658 2012-01-04 16:33:14 <luke-jr> P2SH can't be just evaluated; you need to look at the overall script template to decide if it behaves like a normal script, or gets special treatment
659 2012-01-04 16:33:15 <[Tycho]> gavinandresen: what I mean is in worst case node will perform <limit> sigops and stop then. If you think that this may be used as DoS attack, then what stops attacker from just submitting same number of checksigns as statically analyzable script if it's not over the limit anyway ?
660 2012-01-04 16:33:24 <gmaxwell> Without mandating analyzability then people who want analyzability can't have it.
661 2012-01-04 16:33:47 <luke-jr> gmaxwell: no, it mandates that implementors analyze the script
662 2012-01-04 16:33:55 <sipa> [Tycho]: because that means the verifier can just see "oh, it has too many checksigs, i deny it immediately"
663 2012-01-04 16:33:57 <luke-jr> it prevents straight "just evaluate it" implementations
664 2012-01-04 16:33:58 <gmaxwell> [Tycho]: forget the dos attack for a moment, what if you just want to cheaply load balance expensive txn to nodes assigned for that purpose?
665 2012-01-04 16:34:00 <sipa> [Tycho]: which is cheaper
666 2012-01-04 16:34:09 <gmaxwell> luke-jr: It does not!
667 2012-01-04 16:34:12 <luke-jr> does
668 2012-01-04 16:34:27 <gmaxwell> You simply evaluate it if you're not going to analyze it.
669 2012-01-04 16:34:50 <gavinandresen> [Tycho]: statically analyzing scripts isn't the reason I like the new proposal better. I like it better because it is cleaner to implement.
670 2012-01-04 16:34:58 <sipa> gmaxwell: i believe he means that you need to look at the entire script in advance to know that it is a magic script
671 2012-01-04 16:35:27 <gavinandresen> [Tycho]: Fewer lines of code and NO changes to the inner EvalScript routine means less possibilty I made yet another stupid mistake
672 2012-01-04 16:35:35 <gmaxwell> IF we kept op_eval BUT mandated analyzability, then yes, you'd have to analyize to know if the op_eval was a good or a bad one... but thats not whats happening.
673 2012-01-04 16:35:49 <gmaxwell> sipa: okay, so lets end this argument and add a freeking op_code for this for luke.
674 2012-01-04 16:36:07 <luke-jr> gmaxwell: P2SH can't be "simply evaluated"
675 2012-01-04 16:36:09 <sipa> i didn't mind an extra opcode, but some did :)
676 2012-01-04 16:36:15 <gmaxwell> I did
677 2012-01-04 16:36:26 <gavinandresen> I don't like adding an extra byte to make luke-jr feel better.
678 2012-01-04 16:36:42 <gmaxwell> I withdraw my objection in the fact of the stupid currently burnin my screen. Bloat the fking chain, it's better than this idiot argument.
679 2012-01-04 16:37:13 <gmaxwell> gavinandresen: I like adding the extra byte to avoid an all out war involving dozens of people who don't understand any of this all with strong opinions.. which is the direction that I fear this will go.
680 2012-01-04 16:37:51 <devrandom> I would support adding an OP_NOP1 too
681 2012-01-04 16:38:12 <gavinandresen> I'd rather go to justmoon's alternative proposal: OP_NOP1 <hash>
682 2012-01-04 16:38:21 <luke-jr> OP_HASH160 OP_EQUALS OP_HASH160 OP_EQUALS OP_IF OP_POP OP_ENDIF OP_EVAL
683 2012-01-04 16:38:48 <luke-jr> explain how to do that with your magic P2SH
684 2012-01-04 16:38:55 <[Tycho]> gmaxwell: then I will assign non-analyzable scripts to that nodes.
685 2012-01-04 16:39:40 <luke-jr> or better yet
686 2012-01-04 16:39:50 <[Tycho]> Cleaner ? OP_EVAL looks more clean to me because script is inserted in plain view.
687 2012-01-04 16:40:38 <luke-jr> OP_HASH160 OP_IF <hash A> OP_ELSE <hash B> OP_ENDIF OP_EQUALS OP_EVAL
688 2012-01-04 16:40:39 <gavinandresen> [Tycho]: the internal implementation is cleaner, and the semantics of exactly what happens are more clear. For example, there is no special case code to look for OP_CODESEPARATORS in the serialized script
689 2012-01-04 16:41:21 <gmaxwell> luke-jr: thats a point.
690 2012-01-04 16:41:32 <gavinandresen> And there is also no issue with transactions that fail if OP_EVAL is interpreted as a no-op (in old clients) but succeed when fully interpreted.
691 2012-01-04 16:41:39 <gmaxwell> the p2sh as proposed doesn't allow pay to either or scripthash.
692 2012-01-04 16:42:06 <gmaxwell> whereas as luke describes it, does.
693 2012-01-04 16:44:45 <gavinandresen> You can still do "redeem with either this OR that" with P2SH, it just isn't as nice-looking without OP_EVAL.
694 2012-01-04 16:44:49 <devrandom> couldn't you encode the either/or in the eval-script?
695 2012-01-04 16:44:56 <gavinandresen> devrandom: exactly
696 2012-01-04 16:45:06 <gmaxwell> luke-jr: I understand arguments from praticality better than arguments from principle/aesthetic, but I expect most people do too.
697 2012-01-04 16:45:35 <gmaxwell> gavinandresen: but what if I don't know the eval script?
698 2012-01-04 16:45:49 <gmaxwell> e.g. my OR is a script burried in a box in case my house burns down.
699 2012-01-04 16:46:10 <gmaxwell> I can't update my OR as a I add new eithers in new transactions.
700 2012-01-04 16:46:11 <gavinandresen> gmaxwell: you managed to save the hash-of-the-or-script but not the script itself?
701 2012-01-04 16:46:21 <luke-jr> gavinandresen: you can't conceal the other script
702 2012-01-04 16:46:55 <gmaxwell> oh I see what gavinandresen is saying.
703 2012-01-04 16:47:17 <gmaxwell> well, it might make the spending payments big.
704 2012-01-04 16:47:32 <luke-jr> [12:44:45] <gavinandresen> You can still do "redeem with either this OR that" with P2SH, it just isn't as nice-looking without OP_EVAL.
705 2012-01-04 16:47:36 <luke-jr> ^ from the spec, I don't see any way
706 2012-01-04 16:47:48 <gmaxwell> Say the orscript is A||B||C||D||E .. having to disclose that every time kinda sucks.
707 2012-01-04 16:48:22 <gmaxwell> luke-jr: you pay to H(KEY A OR KEY B) rather than H(KEY A) OR H(KEY B).
708 2012-01-04 16:48:33 <gavinandresen> luke-jr: Lets say the "this" is a 2-of-3 CHECKMULTISIG. and the "That" is a plain CHECKSIG.
709 2012-01-04 16:48:39 <devrandom> a question I have - the only function of OP_EVAL / P2SH is for wallet security, right?
710 2012-01-04 16:48:48 <gmaxwell> devrandom: ... oy, no, far from that.
711 2012-01-04 16:48:50 <luke-jr> gmaxwell: what if the scripts aren't simple keys?
712 2012-01-04 16:48:55 <gavinandresen> The <serialized script> for a P2SH would then be something like:
713 2012-01-04 16:49:13 <luke-jr> devrandom: no
714 2012-01-04 16:49:17 <gmaxwell> devrandom: it generally enables escrows. E.g. you could have a trust that requires 3 of 5 signatures, and you want people to be able to pay into that trust.
715 2012-01-04 16:49:43 <gavinandresen> DUP <pubkey> CHECKSIG IF OP_1 ELSE 2 <pk1...2...3> 3 CHECKMULTISIG ENDIF
716 2012-01-04 16:49:58 <devrandom> but with escrow you have to pass around the real script so that people know that they are putting the money in the escrow (and not in some random person's personal stash)
717 2012-01-04 16:50:14 <gavinandresen> The only downside is you have to reveal all the public keys and script logic for both sides of the IF
718 2012-01-04 16:50:52 <devrandom> so if you have to pass around the eval'ed script ahead of time, OP_EVAL/P2SH doesn't buy you anything
719 2012-01-04 16:50:53 <gavinandresen> Which IS a shame. I agree OP_EVAL was spiffy, but I also agree with roconnor-- it was spiffy and a little dangerous.
720 2012-01-04 16:51:05 <gmaxwell> devrandom: depends on what the purpose of the escrow is. Say my company uses an escrow to manage its funds. Our customers don't need to see the script. Yes, someone could trick them into paying someone else, but thats always the case escrow or no.
721 2012-01-04 16:51:24 <devrandom> gmaxwell: you are describing wallet security
722 2012-01-04 16:51:32 <devrandom> (rather than escrow)
723 2012-01-04 16:51:33 <gavinandresen> devrandom: Hmm? to fund that complicated this-or-that you just need the hash of the script....
724 2012-01-04 16:51:40 <gmaxwell> devrandom: No. I'm describing pay to trust.
725 2012-01-04 16:51:47 <luke-jr> devrandom: the point is, random 3rd parties can send to the escrow
726 2012-01-04 16:52:25 <gmaxwell> Without knowing or caring any of the details of the escrow operation. This is also the same thing for wallet security but the motivation on the part of the users isn't quite the same.
727 2012-01-04 16:52:31 <devrandom> an "escrow" is something that protects the sender and recipient. it sounds like you guys are talking about something that protects the recipient only
728 2012-01-04 16:53:12 <gmaxwell> devrandom: I've used the word trust multiple times here for a reason. It's a subclass of escrows.
729 2012-01-04 16:53:54 <gmaxwell> devrandom: if you're concerned about things that protect the recipent, then yes, the recipent will need to see the script, but there is no reason that functionality should be baked into every bitcoin client and web interface.
730 2012-01-04 16:53:56 <devrandom> gmaxwell: what would you call something that protects the sender?
731 2012-01-04 16:55:23 <gmaxwell> devrandom: for example, for sender protection there could exist a make_escrow.py that takes a pair of addresses and vomits out a A&&B send-to-script or a 2 of 3. Then you can use boring general software to send to that script.
732 2012-01-04 16:55:51 <gmaxwell> In that case you don't send around the script either, you just generate it all yourselves and see that you got the same thing.
733 2012-01-04 16:56:13 <devrandom> you'll need to pass around A and B
734 2012-01-04 16:56:34 <gmaxwell> devrandom: each party tells the other their addresses. Sure.
735 2012-01-04 16:57:15 <gmaxwell> devrandom: the key point here is that we can implement only a single address type in the software and then we get all these operations without having to add more and more special cases to the bitcoin software.
736 2012-01-04 16:57:32 <gmaxwell> And the bitcoin software is far more costly to maintain that build_escrow.py.
737 2012-01-04 16:57:38 <gmaxwell> s/that/than/
738 2012-01-04 16:58:33 <gmaxwell> basically it's an example of providing the minimum mechenism that enables all uses, rather than supporting the uses directly and getting stuck also baking in their policy.
739 2012-01-04 16:59:16 <devrandom> or you could pass around the script out of band and finally pass the script into the bitcoin software... still just one path enabling all uses
740 2012-01-04 16:59:32 <devrandom> it's just a sequence of bytes either way
741 2012-01-04 16:59:37 <gmaxwell> (also, you'd always want protect-sender style txn to generate the script independantly... if you expect people to parse scripts, you'll end op with cases like 2-of-3(A,B,C) <tricky stuf> OR D and software will fail to tell you that D can empty the excrow.
742 2012-01-04 16:59:45 <gmaxwell> )
743 2012-01-04 17:00:04 <devrandom> bitcoinj in fact is planning to support passing around of whole txs
744 2012-01-04 17:00:18 <gmaxwell> I think thats super inadvisable.
745 2012-01-04 17:00:37 <gmaxwell> At least unless its functionally constrainted to the txn that it could generate itself.
746 2012-01-04 17:00:57 <gmaxwell> Determining all the possible ways of satisfying a script accurately is NP-HARD.
747 2012-01-04 17:01:24 <gmaxwell> (well, s/a/any/)
748 2012-01-04 17:01:26 <devrandom> of course you have to figure out if a tx / script is really paying into where you wanted it to pay before accepting it
749 2012-01-04 17:01:30 <luke-jr> gmaxwell: that's probably the same complexity as determining all possible execution paths of software
750 2012-01-04 17:01:37 <gmaxwell> luke-jr: it is.
751 2012-01-04 17:02:13 <devrandom> right, you want to make sure that the script is of a form you recognize
752 2012-01-04 17:02:46 <gmaxwell> Then that has the same expressive power as generating it yourself, and it is less vulnerable to implementation mistakes.
753 2012-01-04 17:02:59 <devrandom> (sorry if I derailed this discussion)
754 2012-01-04 17:04:26 <gmaxwell> yea, in any case... no two implementations will safely know how to parse all the same scripts. So the pay-to-scripthash gives you an interop layer. You'll still need _someway_ of figuring out what the payment does for the subset of cases where that matters, but that can be external if required.
755 2012-01-04 17:05:01 <luke-jr> it can also be a webapp
756 2012-01-04 17:05:06 <luke-jr> maybe
757 2012-01-04 17:05:07 <gmaxwell> (by safely parse, I mean determine all the necessary and sufficient satisfaction criteria accurately)
758 2012-01-04 17:05:27 <gmaxwell> yes, if its run by a third party then you don't mind that you have to trust it not to lie.
759 2012-01-04 17:05:28 <devrandom> my point was that you can't generate it yourself without passing around all the components of it. so either way you are passing something around that has a size similar to the full script
760 2012-01-04 17:06:04 <devrandom> so in the case where the sender needs to be protected, OP_EVAL and such are not saving you any extra work or passing around of stuff
761 2012-01-04 17:06:12 <gmaxwell> devrandom: well, half (e.g. in the A&&B case). But whatever.
762 2012-01-04 17:06:25 <gmaxwell> Okay, so we were talking past each other there.
763 2012-01-04 17:06:42 <gmaxwell> No it doesn't in that case, but it saves you from having to use a wallet that knows about every possible txn type.
764 2012-01-04 17:07:18 <gmaxwell> E.g. you pass around a bunch of stuff, but you get out a boring regular wallet-security style address to pay into out of your excrow maker tool/webapp.
765 2012-01-04 17:07:37 <devrandom> I see, good point
766 2012-01-04 17:08:26 <gmaxwell> devrandom: and ignoring all other facts, as was mentioned before: if we redesigned the system today we'd probably be pay-to-scripthash only because it has better scaling properties. (space in output scripts is more expensive than inputs, because inputs are all (eventually) prunable)
767 2012-01-04 17:08:56 <gmaxwell> so regardless of what you're passing around, you'd still be best off actually constructing the real txn as a pay-to-scripthash
768 2012-01-04 17:09:49 <devrandom> aren't spent outputs are also prunable?
769 2012-01-04 17:10:34 <luke-jr> P2SH might be more acceptable if we decide that Bitcoin 2.0 won't support scriptPubKey anymore.
770 2012-01-04 17:10:38 <gmaxwell> yes, but the number of unspent outputs is always growing. And when an output is added to the network no one knows when (if) it will be spent.
771 2012-01-04 17:10:48 <luke-jr> but again, that seriously limits what scripts can do
772 2012-01-04 17:11:19 <devrandom> I see
773 2012-01-04 17:11:33 <gmaxwell> devrandom: so if I'm deciding what txn fee I'm going to require from you, given equal total sizes, I'll charge less for the one with the larger input script.
774 2012-01-04 17:12:51 <luke-jr> if we're going to go ahead and destroy scriptPubKey, I'll be sure to stop accepting *anything other than* P2SH in Eligius when there's client support for it ;p
775 2012-01-04 17:13:56 <gmaxwell> luke-jr: I'd like to better understand why you think its a (major) loss of functionality, but I don't have time for the discussion now.
776 2012-01-04 17:14:15 <luke-jr> gmaxwell: I've been trying to explain that for days, and I thought you understood with my example today
777 2012-01-04 17:14:31 <luke-jr> it's impossible to conceal an "alternative" script
778 2012-01-04 17:14:41 <luke-jr> especially since scripts cannot recurse anymore
779 2012-01-04 17:16:45 <devrandom> luke-jr: what is the info leakage you are concerned about? is it the form of the script or the key hashes?
780 2012-01-04 17:16:58 <gmaxwell> okay, only that. Sorry, I didn't forget that I just don't consider it that important. We could potentially preserve that while killing other types. E.g. by allowing a list of alternative scripts.
781 2012-01-04 17:17:14 <luke-jr> devrandom: if I'm not using <script X> to redeem it, I shouldn't need to publish <script X>
782 2012-01-04 17:17:21 <gmaxwell> The reason I didn't consider it important is because we can't currently conceal scripts at all.
783 2012-01-04 17:19:00 <luke-jr> gmaxwell: we can, with OP_EVAL :p
784 2012-01-04 17:19:31 <gmaxwell> devrandom: say that if you die all your money will go to the church. so you make all your addresses have a ||churchscript
785 2012-01-04 17:19:51 <gmaxwell> You don't want the church to know about this, because if they find out they'll send ninjas to help you find god prematurely.
786 2012-01-04 17:20:10 <gmaxwell> you write the content of the church script in an encrypted message to them that you add to your will.
787 2012-01-04 17:20:38 <devrandom> since it's to generate new keys, it doesn't seem that it leaks that much info. but maybe the structure of the script *is* giving away significant info.
788 2012-01-04 17:21:04 <gmaxwell> when you die, the executor of your will (perhaps an ensemble of secure hardware, an oracle) sends the message to the church and they form txn claiming all your funds.
789 2012-01-04 17:21:23 <gmaxwell> yea.. meh, you're right, in my example you could just send a privkey.
790 2012-01-04 17:21:25 <devrandom> s/since it's to/since it's easy to/
791 2012-01-04 17:21:44 <gmaxwell> I don't have an example where it's actually all that important to hide the script. But yes, the structure leaks info.
792 2012-01-04 17:22:17 <devrandom> e.g. if you have a complicated script you are likely to be in a corp environment with a certain number of officers, etc.
793 2012-01-04 17:24:36 <safra> I am looking for a programmer, for a project, anyone?
794 2012-01-04 17:25:14 <luke-jr> safra: I suspect you'd better give more details to find the right person
795 2012-01-04 17:26:47 <safra> PHP programmer :)
796 2012-01-04 17:27:25 <safra> more details in private..
797 2012-01-04 17:27:53 <safra> its related to bitcoin gateway
798 2012-01-04 17:32:14 <UukGoblin> PHP programmer... sounds like an oxymoron...
799 2012-01-04 17:34:38 <slush> tcatm: bitcoinchart stream for mtgox is down, right?
800 2012-01-04 17:35:15 <CIA-100> bitcoin: p2k * rf4a588db9b37 ecoinpool/ (13 files in 6 dirs): More Documentation http://tinyurl.com/6tnuqas
801 2012-01-04 17:35:15 <UukGoblin> slush, yes
802 2012-01-04 17:36:25 <slush> UukGoblin: what happen on mtgox? Huge spike in volume? I don't see anything significant on clarkmoody
803 2012-01-04 17:36:41 <UukGoblin> slush, not sure, I know the price went quite up
804 2012-01-04 17:36:49 <UukGoblin> $5.7 high or sth
805 2012-01-04 17:37:01 <slush> too bad I sold today at 5.07 :(
806 2012-01-04 17:37:19 <UukGoblin> socket.io was having issues too, not sure if it still does
807 2012-01-04 17:38:03 <UukGoblin> roconnor, don't you get the 'gut feeling'?
808 2012-01-04 17:39:08 <roconnor> UukGoblin: Normally I esitmate probablitly distributions on events based on research, estimate prices based on those events and run a portfolio optimiser.
809 2012-01-04 17:39:19 <roconnor> ... that and buying index funds.
810 2012-01-04 17:39:32 <UukGoblin> roconnor, I.. ugh... right ;-)
811 2012-01-04 17:39:35 <UukGoblin> good for you!
812 2012-01-04 17:39:39 <UukGoblin> I wouldn't trust guts either
813 2012-01-04 17:39:49 <roconnor> I used to use my gut but I lost a lot of fake money that way.
814 2012-01-04 17:40:17 <roconnor> granted I lost even more money buying index funds :P
815 2012-01-04 17:40:29 <UukGoblin> what the hell are index funds?
816 2012-01-04 17:40:59 <roconnor> er sorry, I mean ETFs
817 2012-01-04 17:41:05 <roconnor> http://en.wikipedia.org/wiki/Exchange-traded_fund
818 2012-01-04 17:41:24 <roconnor> specifically index ETFs
819 2012-01-04 17:41:52 <UukGoblin> oh bloody hell
820 2012-01-04 17:42:00 <UukGoblin> I'm too dumb to understand half the words
821 2012-01-04 17:43:14 <cjdelisle> Most ETFs track an index, such as the S&P 500 <-- I can see how that would be a way to lose a lot of money
822 2012-01-04 17:43:19 <Diablo-D3> ;ticker
823 2012-01-04 17:43:21 <Diablo-D3> ;;ticker
824 2012-01-04 17:43:22 <gribble> Best bid: 5.55, Best ask: 5.55089, Bid-ask spread: 0.00089, Last trade: 5.55, 24 hour volume: 136809, 24 hour low: 4.7241, 24 hour high: 5.7
825 2012-01-04 17:43:31 <Diablo-D3> [01:43:14] <cjdelisle> Most ETFs track an index, such as the S&P 500 <-- I can see how that would be a way to lose a lot of money
826 2012-01-04 17:43:33 <Diablo-D3> not really
827 2012-01-04 17:43:43 <Diablo-D3> why try to beat the market when you can OWN the market.
828 2012-01-04 17:43:54 <roconnor> Diablo-D3: cjdelisle means recently
829 2012-01-04 17:44:02 <UukGoblin> cjdelisle, I can see what "Most", "an" and "such as the" mean there
830 2012-01-04 17:44:11 <cjdelisle> :)
831 2012-01-04 17:44:13 <Diablo-D3> roconnor: who cares then
832 2012-01-04 17:44:16 <Diablo-D3> thats short term thinking
833 2012-01-04 17:44:25 <Diablo-D3> lrn2make money slowly, kthx
834 2012-01-04 17:45:00 <cjdelisle> trouble is when the landlord doesn't accept long term payment of next month's rent ;)
835 2012-01-04 17:45:19 <Diablo-D3> thats neither here nor there, cjdelisle
836 2012-01-04 17:45:26 <Diablo-D3> you cant beat the market long term
837 2012-01-04 17:45:46 <Diablo-D3> so the trick is to get an account at vanguard, and then use vanguard's mutual funds for total stock market and total bond market
838 2012-01-04 17:45:48 <cjdelisle> that is to say: long term thinking doesn't help if, in the short term, you go broke.
839 2012-01-04 17:45:50 <Diablo-D3> usually 60/40 split
840 2012-01-04 17:46:02 <Diablo-D3> cjdelisle: thats STILL neither here nor there