1 2012-01-04 00:06:50 <Uiuiuiui> exist any wiki page that list things will never change on bitcoin?
2 2012-01-04 00:06:59 theorbtwo has quit (Ping timeout: 240 seconds)
3 2012-01-04 00:07:03 booo has quit (Ping timeout: 255 seconds)
4 2012-01-04 00:07:05 theorbtwo has joined
5 2012-01-04 00:08:36 <luke-jr> Uiuiuiui: everything can be changed.
6 2012-01-04 00:09:21 copumpkin has quit (Quit: Computer has gone to sleep.)
7 2012-01-04 00:09:33 <sipa> there are rules which are enforced by each node and miner, called the network rules
8 2012-01-04 00:09:56 <sipa> they can be changed, but it requires everyone to upgrade (and reach a consensus about the change first)
9 2012-01-04 00:10:14 <luke-jr> http://scoweb.sco.ca.gov/UCP/PropertyDetails.aspx?propertyRecID=6279277
10 2012-01-04 00:11:04 <Uiuiuiui> hum, i was reading hardfork list
11 2012-01-04 00:11:43 <roconnor> sipa: do you understand the rational for send-to-script-hash rather than send-to-script?
12 2012-01-04 00:11:46 watson787 has joined
13 2012-01-04 00:11:53 <Uiuiuiui> it's safe to assume anything with significant economic impact will _never_ be changed in Bitcoin
14 2012-01-04 00:12:10 <roconnor> Uiuiuiui: I wouldn't assume that.
15 2012-01-04 00:12:12 <sipa> roconnor: short address, i suppose
16 2012-01-04 00:12:30 <sipa> roconnor: i've been wondering why no-one wants to encode txout scripts directly in urls or so
17 2012-01-04 00:12:51 <gmaxwell> Uiuiuiui: please don't shit all over that page with all the crack ass economic theories that are always overflowing on the forum.
18 2012-01-04 00:13:03 <gmaxwell> Uiuiuiui: if you do that the page will be locked to prevent editing.
19 2012-01-04 00:13:16 <Uiuiuiui> ok, sorry
20 2012-01-04 00:13:37 <sipa> Uiuiuiui: if you wonder whether something like the 21M limit will be changed; imho, no way that would ever be agreed upon
21 2012-01-04 00:13:49 <gmaxwell> Uiuiuiui: _technically_ you could just replace bitcoin with an interface to paypal if you wanted. Thats the power of upgrading software, but you'd actually have to convince people to run it.
22 2012-01-04 00:14:11 <Uiuiuiui> undestand
23 2012-01-04 00:14:34 <roconnor> sipa: I think I still oppose this magic-hash proposal; though at least it isn't disasterously bad.
24 2012-01-04 00:14:53 <Uiuiuiui> if more than 50 agree, everything is possible
25 2012-01-04 00:15:04 <gmaxwell> Uiuiuiui: 50?
26 2012-01-04 00:15:12 <gavinandresen> 50%
27 2012-01-04 00:15:14 <Uiuiuiui> 50%
28 2012-01-04 00:15:15 <gmaxwell> Uiuiuiui: no. you can't change most things with only a majority.
29 2012-01-04 00:15:50 <gmaxwell> (I mean, you can have a majority fork of course, but you can fork without 50%)
30 2012-01-04 00:16:04 dvide has quit ()
31 2012-01-04 00:16:23 <sipa> Uiuiuiui: there is exactly one thing that needs 50% support
32 2012-01-04 00:16:40 <sipa> namely, which valid transactions are accepted and in which order
33 2012-01-04 00:16:51 <gmaxwell> Uiuiuiui: 100% of the (remaining) participants in the system need to agree on any change that makes a previously disallowed-by-protocol-rules activity allowed.
34 2012-01-04 00:16:54 <sipa> miners vote about that, basically
35 2012-01-04 00:16:59 <phantomcircuit> luke-jr, lold
36 2012-01-04 00:17:12 <sipa> Uiuiuiui: but for everything else, you need 100% support
37 2012-01-04 00:17:12 <phantomcircuit> ITS A TRAP
38 2012-01-04 00:18:02 <Uiuiuiui> right, understand now, thanks. the decision is from miners, not users
39 2012-01-04 00:18:13 <gmaxwell> ...
40 2012-01-04 00:18:21 <roconnor> gmaxwell: not exactly; If every client except for me switches over, you hardly have a payment system.
41 2012-01-04 00:18:22 <gmaxwell> Uiuiuiui: if four people agree to change the limit to 42million bitcoin, then they can create a fork where thats true, and it works for the 100% of that fork (4 people). Everyone else's software would just completely ignore it.
42 2012-01-04 00:18:43 <gmaxwell> roconnor: I did qualify with '(remaining) participants' for that reason
43 2012-01-04 00:18:47 <gavinandresen> The state of California owes Satoshi 201 dollars and ELEVEN cents?
44 2012-01-04 00:18:48 <roconnor> ah
45 2012-01-04 00:19:11 <gmaxwell> Uiuiuiui: no, it's _not_ about miners. Miners only vote on the ordering and acceptablity of transactions.
46 2012-01-04 00:19:32 <gmaxwell> Uiuiuiui: But the users enforce all the rules unconditionally. No vote.
47 2012-01-04 00:19:50 <sipa> or rather, they ignore everything that doesn't fit the rules
48 2012-01-04 00:19:51 <phantomcircuit> gavinandresen, im guessing they got trolled by someone
49 2012-01-04 00:20:02 <phantomcircuit> the california state government is amazingly incompeteny
50 2012-01-04 00:20:03 <gavinandresen> ... and even if 75% of miners agreed, if most of the merchants and exchanges decided to stick with the other 25% then those 75% of miners wouldn't be able to spend their coins
51 2012-01-04 00:20:04 <sipa> satoshi and nakamoto are not uncommon names
52 2012-01-04 00:20:06 <phantomcircuit> incompetent *
53 2012-01-04 00:20:46 <gmaxwell> Uiuiuiui: if deepbit and eligius and btcguild started mining like there would be 42 million bitcoins, from the perspective of everyone else they would have just stopped mining.
54 2012-01-04 00:20:51 <Eliel> Uiuiuiui: even if majority of miners (say 60% or so) decided to start supporting a change, it would still mean nothing if the majority of bitcoin users kept using the old version.
55 2012-01-04 00:21:25 <Eliel> the old version would just work slower for a while and then drop difficulty (well, more likely the 60% miners would give up and return)
56 2012-01-04 00:21:37 hippich_ has joined
57 2012-01-04 00:22:17 <Uiuiuiui> hum, so is the client version that mantain a rule or no?
58 2012-01-04 00:23:35 roconnor has quit (Ping timeout: 240 seconds)
59 2012-01-04 00:23:40 <gmaxwell> Uiuiuiui: it's the bitcoin software that enforces the rules. All bitcoin software enforces the same rules or otherwise they would eventually stop talking.
60 2012-01-04 00:23:55 <gmaxwell> (man, the word 'client' for the software sure seems to foster confusion)
61 2012-01-04 00:24:37 <Eliel> the biggest problem with bitcoin that I can see, though, is that unless there is global connectivity, the network doesn't quite work. If one city would suddenly lose all connection to the rest of the world, bitcoin would be quite unusable for that time.
62 2012-01-04 00:24:53 <Eliel> in that city
63 2012-01-04 00:25:03 dvide has joined
64 2012-01-04 00:26:23 <sipa> more and more so... i think that city would be in problems, even without bitcoin
65 2012-01-04 00:27:29 <Eliel> yep, true. But they definitely don't need
66 2012-01-04 00:27:42 <Eliel> ... uh, typoing enter in the wrong place :)
67 2012-01-04 00:28:00 <Eliel> anyway, the definitely don't need their money system to stop working too if they've got that sort of trouble :)
68 2012-01-04 00:28:11 hippich_ has quit (Remote host closed the connection)
69 2012-01-04 00:28:37 <gmaxwell> Eliel: If you can raise about a grand a month I'd be glad to run a satellite blockchain feed that can be recieved by fairly inexpensive hardware.
70 2012-01-04 00:31:24 <Eliel> gmaxwell: getting the blockchain isn't enough, they'd also need a way to get the transactions out.
71 2012-01-04 00:32:08 <Eliel> although, this satellite thing reminds me of http://www.bbc.co.uk/news/technology-16367042
72 2012-01-04 00:32:25 <gmaxwell> Eliel: getting the chain prevents anyone from being victimized by double spends at least.
73 2012-01-04 00:32:44 <gmaxwell> Eliel: the DOS part.. well, yes, but e.g. if they're without power they can't use it eitherâ you don't expect me to fix that?
74 2012-01-04 00:33:25 <gmaxwell> You can get out via a two way satellite terminal if you have one, though they're not super cheap to just have laying around. :)
75 2012-01-04 00:33:28 <Eliel> I expect most bitcoin devices will be battery powered.
76 2012-01-04 00:34:20 oww has quit (Remote host closed the connection)
77 2012-01-04 00:34:33 <luke-jr> why?
78 2012-01-04 00:34:38 <luke-jr> Bitcoin requires a network connection
79 2012-01-04 00:34:42 oww has joined
80 2012-01-04 00:34:50 <luke-jr> might as well do power too
81 2012-01-04 00:35:19 RazielZ has quit (Quit: Leaving)
82 2012-01-04 00:35:26 <gmaxwell> Eliel: if you're battery powered then presumably you have access to a (battery backed up) wireless network.
83 2012-01-04 00:36:40 <Eliel> yes, I was thinking of a situation where a city gets isolated from the global network (for whatever reason) but local network remains operational.
84 2012-01-04 00:37:24 roconnor has joined
85 2012-01-04 00:39:01 Kolky has quit (Quit: Bye bye!)
86 2012-01-04 00:40:12 <gmaxwell> Eliel: actual connectivity doesn't usually work like that. Traceroute to something in your city and you'll often see it goes to another city, because networks don't interconnect everywhere.
87 2012-01-04 00:40:57 <Eliel> gmaxwell: ah, right :)
88 2012-01-04 00:53:05 rdponticelli_ has joined
89 2012-01-04 00:53:51 rdponticelli has quit (Ping timeout: 255 seconds)
90 2012-01-04 00:54:51 Uiuiuiui has quit (Quit: Leaving)
91 2012-01-04 01:00:59 Carmivore has quit (Read error: Connection reset by peer)
92 2012-01-04 01:04:56 spq` has joined
93 2012-01-04 01:05:13 rdponticelli_ has quit (Read error: Connection reset by peer)
94 2012-01-04 01:05:26 rdponticelli has joined
95 2012-01-04 01:07:06 spq has quit (Ping timeout: 252 seconds)
96 2012-01-04 01:07:20 spq` is now known as spq
97 2012-01-04 01:07:22 Carmivore has joined
98 2012-01-04 01:16:10 rdponticelli has quit (Read error: Connection reset by peer)
99 2012-01-04 01:16:50 btc_novice has quit (Quit: Leaving.)
100 2012-01-04 01:17:04 finway has joined
101 2012-01-04 01:17:12 finway has quit (Client Quit)
102 2012-01-04 01:27:12 BlueMatt has joined
103 2012-01-04 01:28:17 spq` has joined
104 2012-01-04 01:32:16 spq has quit (Ping timeout: 252 seconds)
105 2012-01-04 01:32:21 <BlueMatt> gmaxwell: ping
106 2012-01-04 01:32:24 Dagger3 has quit (Quit: Quitting)
107 2012-01-04 01:32:26 spq` is now known as spq
108 2012-01-04 01:35:51 b4epoche_ has joined
109 2012-01-04 01:36:51 b4epoche has quit (Ping timeout: 240 seconds)
110 2012-01-04 01:36:51 b4epoche_ is now known as b4epoche
111 2012-01-04 01:38:24 Dagger3 has joined
112 2012-01-04 01:40:36 copumpkin has joined
113 2012-01-04 01:44:32 <gmaxwell> BlueMatt: ploink
114 2012-01-04 01:44:33 <gavinandresen> Anybody still awake: email me if I missed something in the draft pay-to-script-hash BIP: https://gist.github.com/1557931
115 2012-01-04 01:45:21 <luke-jr> what if I just think it sucks?
116 2012-01-04 01:45:25 <luke-jr> (disclaimer: haven't read it yet)
117 2012-01-04 01:47:22 gavinandresen has quit (Quit: gavinandresen)
118 2012-01-04 01:48:40 pickett has quit (Ping timeout: 240 seconds)
119 2012-01-04 01:51:00 watson787 has quit (Ping timeout: 240 seconds)
120 2012-01-04 01:55:23 Dagger3 has quit (Ping timeout: 260 seconds)
121 2012-01-04 02:01:33 watson787 has joined
122 2012-01-04 02:03:52 BlueMatt has quit (Ping timeout: 248 seconds)
123 2012-01-04 02:03:59 BlueMatt_ has joined
124 2012-01-04 02:04:15 BlueMatt_ is now known as BlueMatt
125 2012-01-04 02:04:53 Carmivore has quit (Remote host closed the connection)
126 2012-01-04 02:06:09 iocor has quit (Quit: Computer has gone to sleep.)
127 2012-01-04 02:06:35 sytse has quit (Ping timeout: 260 seconds)
128 2012-01-04 02:06:45 <[Tycho]> What should {serialized script} look like ?
129 2012-01-04 02:07:12 <BlueMatt> the same way a script looks when its coming off the network
130 2012-01-04 02:07:16 <BlueMatt> /store on disk in a block
131 2012-01-04 02:07:53 <BlueMatt> ok, wtf is up with github, can anyone push to their repos?
132 2012-01-04 02:09:33 copumpkin is now known as HURR_DURR
133 2012-01-04 02:09:41 sytse has joined
134 2012-01-04 02:09:50 <[Tycho]> So it will be just normal script, just preceded by length byte/pushop ?
135 2012-01-04 02:10:42 * BlueMatt has to admit he has never examined the blockstore on disk, or examined the data CDataStream actually puts out
136 2012-01-04 02:10:49 <BlueMatt> but if thats the format of CDataStream
137 2012-01-04 02:11:21 Carmivore has joined
138 2012-01-04 02:11:33 <[Tycho]> Me too.
139 2012-01-04 02:11:49 <BlueMatt> iirc there are also length bytes on vectors, etc
140 2012-01-04 02:12:14 <BlueMatt> ok, how did github fuck up my bitcoin fork?
141 2012-01-04 02:15:10 <luke-jr> [Tycho]: no
142 2012-01-04 02:15:28 <luke-jr> [Tycho]: there should also be a leading octet for version
143 2012-01-04 02:16:06 xenland has joined
144 2012-01-04 02:16:08 <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
145 2012-01-04 02:16:09 <[Tycho]> Why will you continue to include OP_EVAL in your coinbase ?
146 2012-01-04 02:16:16 <luke-jr> [Tycho]: because OP_EVAL is better
147 2012-01-04 02:16:26 <gmaxwell> luke-jr: it's not the same as op_eval.
148 2012-01-04 02:16:34 <luke-jr> gmaxwell: it's less flexible.
149 2012-01-04 02:16:37 <[Tycho]> What was the point of this magic thing ?
150 2012-01-04 02:16:41 <luke-jr> it's not superior in any way
151 2012-01-04 02:16:55 <luke-jr> [Tycho]: presumably to save a byte
152 2012-01-04 02:16:56 <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.
153 2012-01-04 02:17:18 <luke-jr> gmaxwell: fine, so add the "input data must be from OP_PUSH" rule
154 2012-01-04 02:17:18 <[Tycho]> gmaxwell: what computation, for example ?
155 2012-01-04 02:18:00 <gmaxwell> [Tycho]: e.g. the OP_DUP looping scripts, or doing some crazy arithemetic to generate code on the fly.
156 2012-01-04 02:18:15 <luke-jr> also, I still think that isn't a problem.
157 2012-01-04 02:18:22 <[Tycho]> Arithmetics are crippled to 4 bytes.
158 2012-01-04 02:18:23 <gmaxwell> luke-jr: yes, that was one of the proposals. It's a lot more complicated to implement and validate however.
159 2012-01-04 02:18:29 <BlueMatt> there are several problems with OP_EVAL that are solved here
160 2012-01-04 02:18:33 <BlueMatt> and they have all been discussed at lenth...
161 2012-01-04 02:18:34 <gmaxwell> [Tycho]: not if we reenable concat.
162 2012-01-04 02:18:48 <[Tycho]> Concat is cool and harmless.
163 2012-01-04 02:18:56 <gmaxwell> sure, but it would remove that limit.
164 2012-01-04 02:18:59 <roconnor> [Tycho]: OP_SHA256
165 2012-01-04 02:18:59 <luke-jr> gmaxwell: I prefer complicated/impossible to static analyze over magic special casing
166 2012-01-04 02:19:18 <[Tycho]> roconnor: how is this harmful ?
167 2012-01-04 02:19:23 <gmaxwell> This isn't magic special casing.
168 2012-01-04 02:19:29 <luke-jr> yes it is
169 2012-01-04 02:19:50 * BlueMatt half-agrees with luke, an OP_NOP1 in the beginning to make it less magical would be nice...
170 2012-01-04 02:20:03 <luke-jr> or at the end
171 2012-01-04 02:20:09 <[Tycho]> Then we need to convince slush into implementing op_eval...
172 2012-01-04 02:20:10 <BlueMatt> either way
173 2012-01-04 02:20:11 <luke-jr> there's no reason the OP_EVAL needs to be made implicit
174 2012-01-04 02:20:22 <roconnor> [Tycho]: it means you have to run the script before you can count the number of OP_CHECKSIGs or other such analysis.
175 2012-01-04 02:20:22 <gmaxwell> BlueMatt: it has the hash160 at the front.
176 2012-01-04 02:20:32 <BlueMatt> please, for the love of god, do not implement OP_EVAL...
177 2012-01-04 02:20:48 <gmaxwell> Where where the two of your objections earlier today?
178 2012-01-04 02:20:52 <[Tycho]> roconnor: number of checksigs can be easily counted in runtime.
179 2012-01-04 02:21:01 <luke-jr> BlueMatt: you can take this proposal, slap an opcode on the end, and call that OP_EVAL.
180 2012-01-04 02:21:05 <gmaxwell> Luke was in the room but mostly quiet.
181 2012-01-04 02:21:06 <BlueMatt> gmaxwell: Ive always wanted an OP_NOP1
182 2012-01-04 02:21:16 <BlueMatt> oh, [Tycho]
183 2012-01-04 02:21:27 <roconnor> [Tycho]: only after running them.
184 2012-01-04 02:21:28 <BlueMatt> gmaxwell: well the script is an otherwise normal and valid script, at least if we add an OP_NOP1 its specially marked
185 2012-01-04 02:21:29 <luke-jr> gmaxwell: I had to leave. I started off with these objections.
186 2012-01-04 02:21:47 <[Tycho]> roconnor: hit the limit and stop executing. Problems ?
187 2012-01-04 02:22:12 <roconnor> [Tycho]: nothing beyond wasting your time.
188 2012-01-04 02:22:21 <luke-jr> AFAIK, nobody has expressed any reason static analysis is *useful*
189 2012-01-04 02:22:23 <gmaxwell> [Tycho]: you've just wasted $limit of computation, and I'm sending you limit wasting txn at line rate.
190 2012-01-04 02:22:37 <luke-jr> gmaxwell: I can do that with this new proposal too
191 2012-01-04 02:22:45 <[Tycho]> roconnor: exactly SAME time would be wasted with same number of checksigs if they are under the limit.
192 2012-01-04 02:22:50 <gmaxwell> luke-jr: because it allows you to drop many useless transactions without actually executing them.
193 2012-01-04 02:22:55 <BlueMatt> ok, seriously WTF???? Im getting "Timeout, server github.com not responding." AFTER "Total 50 (delta 42), reused 0 (delta 0)"
194 2012-01-04 02:22:58 <luke-jr> gmaxwell: nope
195 2012-01-04 02:23:08 <luke-jr> gmaxwell: it only allows you to drop an attack, and that attack can be done without it
196 2012-01-04 02:23:13 DontMindMe2 has quit (Quit: Nettalk6 - www.ntalk.de)
197 2012-01-04 02:23:16 <BlueMatt> and the internet is clearly 100% working...
198 2012-01-04 02:23:48 <roconnor> [Tycho]: That's true
199 2012-01-04 02:23:51 <[Tycho]> Well, at least in this part I'm correct.
200 2012-01-04 02:23:56 <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.
201 2012-01-04 02:23:59 <BlueMatt> and no freenode #github channel where the github people hang out...
202 2012-01-04 02:24:02 <luke-jr> gmaxwell: for example, a script that does exactly <LIMIT> OP_CHECKSIGs, then fails for some other unrelated reason
203 2012-01-04 02:24:15 <roconnor> gmaxwell: good test of the bitcoin system
204 2012-01-04 02:24:15 <gmaxwell> luke-jr: indeed, thats true.
205 2012-01-04 02:24:17 <luke-jr> gmaxwell: or a script that fails on its <LIMIT>th OP_CHECKSIG
206 2012-01-04 02:24:31 <[Tycho]> I'm not making anything by force. We still have to discuss this (with slush). And that will be democracy.
207 2012-01-04 02:24:47 <BlueMatt> [Tycho]: are you kidding me?
208 2012-01-04 02:24:53 <gmaxwell> No one wants a bitcoin system which is a democracy of luke-jr + [Tycho] + slush
209 2012-01-04 02:24:55 <[Tycho]> BlueMatt: yes.
210 2012-01-04 02:25:00 <BlueMatt> good
211 2012-01-04 02:25:12 <roconnor> gmaxwell: if people don't want it then they won't give their mining power to them.
212 2012-01-04 02:25:13 <luke-jr> gmaxwell: this change basically must be.
213 2012-01-04 02:25:24 <[Tycho]> BlueMatt: but I'm still against the change.
214 2012-01-04 02:25:38 <BlueMatt> luke-jr: do you have any possible use for OP_EVAL over the new version?
215 2012-01-04 02:25:40 * roconnor thinks the status quo is fine.
216 2012-01-04 02:25:44 <BlueMatt> other than "its more flexible"
217 2012-01-04 02:25:50 <BlueMatt> [Tycho]: why?
218 2012-01-04 02:26:13 <[Tycho]> BlueMatt: looks more ugly to me and adds "special case" logic.
219 2012-01-04 02:26:29 <[Tycho]> Also makes scripts more cryptic.
220 2012-01-04 02:26:36 <BlueMatt> [Tycho]: ok, on that count I totally agree
221 2012-01-04 02:26:57 <luke-jr> BlueMatt: for example, making a decision of which of 2 scripts to execute based on the result of a 1st script
222 2012-01-04 02:27:02 <BlueMatt> but then you can just add an OP_NOP1 to the beginning...
223 2012-01-04 02:27:02 <gmaxwell> I don't see how this is any more special case or cryptic than anything about their operations.
224 2012-01-04 02:27:22 <BlueMatt> luke-jr: I said a use, not what it allows
225 2012-01-04 02:27:25 <[Tycho]> May be we need to vote ?
226 2012-01-04 02:27:29 <roconnor> [Tycho]: why do we need send-to-script-hash as opposed to send-to-script?
227 2012-01-04 02:27:34 <BlueMatt> [Tycho]: no one is awake...
228 2012-01-04 02:27:39 <[Tycho]> Oh, stop, we will vote by our coinbases anyway.
229 2012-01-04 02:27:39 <luke-jr> BlueMatt: concealing your "alternative" script permanently.
230 2012-01-04 02:27:54 theymos has joined
231 2012-01-04 02:27:57 <BlueMatt> roconnor: send-to-script doesnt solve the original problem...
232 2012-01-04 02:28:06 <roconnor> BlueMatt: what is the original problem?
233 2012-01-04 02:28:28 <luke-jr> roconnor: long logic to redeem
234 2012-01-04 02:28:29 <[Tycho]> roconnor: send-to-script-hash is fine. I just want the script to be normal, not encrypted.
235 2012-01-04 02:28:33 <doublec> shouldn't it be the miners voting, not the pools?
236 2012-01-04 02:28:34 <BlueMatt> roconnor: the ability to send MULTISIG transactions that require 10/50 sigs to a reasonable length address
237 2012-01-04 02:28:50 <luke-jr> doublec: ideally, but that won't happen
238 2012-01-04 02:28:50 <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
239 2012-01-04 02:29:01 <luke-jr> doublec: even when DeepBit is down, it has a huge amount of power
240 2012-01-04 02:29:05 <[Tycho]> doublec: miners aren't developers. How they can know what is the right decision ?
241 2012-01-04 02:29:17 <luke-jr> [Tycho]: to be fair, you're not a developer either.
242 2012-01-04 02:29:29 <doublec> not all pool owners are developers
243 2012-01-04 02:29:32 <gmaxwell> [Tycho]: you haven't parcipated in any of the discussion how can you know what is the right recision.
244 2012-01-04 02:30:13 <roconnor> BlueMatt: Meh, I don't see why addresses need to be short.
245 2012-01-04 02:30:16 <[Tycho]> Well, if others will decide to implement that new thing instead of op_eval, I'll remove OP_EVAL from the pool.
246 2012-01-04 02:30:23 <luke-jr> 1) static analysis is useless; 2) special casing is always ugly; 3) special casing removes many possibilities
247 2012-01-04 02:30:58 <[Tycho]> So I'm not going to force my opinion by force.
248 2012-01-04 02:31:15 <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"
249 2012-01-04 02:31:16 <[Tycho]> So I recommend you all to agree with me.
250 2012-01-04 02:31:48 <[Tycho]> luke-jr: what about the timebomb in current code set to 01.02 ?
251 2012-01-04 02:31:50 <BlueMatt> doublec: the miners did vote (to give up their power to the pools)
252 2012-01-04 02:31:50 <BlueMatt> [Tycho]: I wouldnt call it encrypted
253 2012-01-04 02:31:50 <BlueMatt> [Tycho]: its just a special-meaning script
254 2012-01-04 02:31:54 <doublec> how about implementing it in an alt chain and seeing how it goes for a month or two
255 2012-01-04 02:31:56 <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
256 2012-01-04 02:32:03 <luke-jr> [Tycho]: ?
257 2012-01-04 02:32:08 <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
258 2012-01-04 02:32:09 <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.
259 2012-01-04 02:32:26 <luke-jr> doublec: they won't.
260 2012-01-04 02:32:27 <[Tycho]> luke-jr: if you won't remove OP_EVAL support, it will kick in at 01.01.2012
261 2012-01-04 02:32:36 <luke-jr> gmaxwell: it clearly is.
262 2012-01-04 02:32:36 Transisto has joined
263 2012-01-04 02:32:44 <luke-jr> [Tycho]: it's already past that date
264 2012-01-04 02:32:50 <BlueMatt> roconnor: it gets to the point where it wont even fit into a qr code
265 2012-01-04 02:32:53 <[Tycho]> luke-jr: 01.02.2012
266 2012-01-04 02:32:56 <gmaxwell> luke-jr: yes, in an absolute sense _every single operation executed_ is a "special case"
267 2012-01-04 02:33:00 <theymos> luke-jr: Would you feel better if there was a flag op in the script?
268 2012-01-04 02:33:09 <BlueMatt> roconnor: and you can reasonably type in a bitcoin address now (not that youd want to), you cant when you get into multisigs
269 2012-01-04 02:33:29 <luke-jr> [Tycho]: Oh, you mean 2012-02-01?
270 2012-01-04 02:33:33 * BlueMatt is now in the mountains, signal is going dowwwwnnnnnnn
271 2012-01-04 02:33:38 <doublec> BlueMatt: how many mining pool ops have you discussed it with?
272 2012-01-04 02:34:05 <doublec> I would imagine there aren't many following bitcoin development
273 2012-01-04 02:34:12 <luke-jr> theymos: I would "feel better" if the script ended with an opcode for the purpose
274 2012-01-04 02:34:35 <[Tycho]> int64 nEvalSwitchTime = GetArg("opevaltime", 1328054400); // Feb 1, 2012
275 2012-01-04 02:34:35 <gmaxwell> luke-jr: ended? I don't think end makes much sense?
276 2012-01-04 02:34:36 <luke-jr> theymos: and therefore, you could put that opcode in any script
277 2012-01-04 02:34:54 <luke-jr> gmaxwell: the code needs to evaluate AFTER the hash is checked
278 2012-01-04 02:35:13 HURR_DURR is now known as copumpkino
279 2012-01-04 02:35:15 copumpkino is now known as copumpkin
280 2012-01-04 02:36:01 <gmaxwell> doublec: gavin had one on oned the original op_eval stuff with a bunch of folks in addition to the public discussion
281 2012-01-04 02:36:03 <roconnor> it is fine to check the hash AFTER the code evaluates.
282 2012-01-04 02:36:16 <roconnor> that is how CODEHASH worked
283 2012-01-04 02:36:48 <luke-jr> roconnor: only if you can guarantee the code evaluated didn't mess with the hash ;)
284 2012-01-04 02:37:10 <luke-jr> CODEHASH worked like that because it pushed the hash onto the stack after the script ran
285 2012-01-04 02:37:31 <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..
286 2012-01-04 02:37:39 BlueMatt has quit (Ping timeout: 240 seconds)
287 2012-01-04 02:38:09 <gmaxwell> And the new thing is what exited the discussion with no active oppoisition (because apparently luke left)
288 2012-01-04 02:38:09 <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.
289 2012-01-04 02:38:14 <luke-jr> [Tycho]: I hope a consensus is reached by then
290 2012-01-04 02:38:34 <luke-jr> theymos: that was what was proposed earlier, and what I am OK with
291 2012-01-04 02:38:38 <doublec> gmaxwell: "annoyingly late" because there hasn't been enough publicity about it
292 2012-01-04 02:38:58 <luke-jr> theymos: specifically, the "execute flag" would only be set by OP_PUSH
293 2012-01-04 02:39:14 <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.
294 2012-01-04 02:39:22 <doublec> gmaxwell: but that aside, yeah, it's hard doing something that requires consensus
295 2012-01-04 02:39:30 <gmaxwell> doublec: No, the people who complained where all exposed to the prior discussion.
296 2012-01-04 02:39:32 dissipate_ has joined
297 2012-01-04 02:39:46 <gmaxwell> (I mean, perhaps you're also correct but thats not the cause here)
298 2012-01-04 02:40:05 <[Tycho]> gmaxwell: stack execution should contain it's own runtime counters and limits.
299 2012-01-04 02:40:10 <gmaxwell> roconnor seems to have ignored it until he used his holidy time to go implement it. ::shrugs::
300 2012-01-04 02:40:32 <gmaxwell> [Tycho]: it has no reason to prevent recursion with the execute bit proposal, so people would just not implement that.
301 2012-01-04 02:41:09 <[Tycho]> Not only to prevent recursion, but to prevent abuse. Even if recursion is impossible. Just IN CASE :)
302 2012-01-04 02:41:34 <gmaxwell> Should but since its a case thats actually impossible to hit the code will be completely untested
303 2012-01-04 02:41:39 <gmaxwell> and thus probably broken.
304 2012-01-04 02:41:56 <[Tycho]> It can be tested easily.
305 2012-01-04 02:42:08 <gmaxwell> (I mean we _might_ manage to get it right in the reference client but other software won't)
306 2012-01-04 02:42:14 <[Tycho]> Just feed with correctly wrong data.
307 2012-01-04 02:42:38 <[Tycho]> Ok, then reference client won't be affected, that's good too.
308 2012-01-04 02:43:01 <gmaxwell> [Tycho]: You're either underestimating how hard software testing is or over estimating the ongoing effort being applied to bitcoin implementations.
309 2012-01-04 02:43:09 EPiSKiNG has quit ()
310 2012-01-04 02:43:36 <luke-jr> gmaxwell: would you like to finish my MIPS quantum emulator?
311 2012-01-04 02:43:40 <[Tycho]> I think that there aren't that many ways to mess up a simple iterations counter.
312 2012-01-04 02:43:48 <gmaxwell> [Tycho]: ...
313 2012-01-04 02:44:37 <doublec> [Tycho]: didn't the op_eval patch have a messed up counter that roconnor caught :)
314 2012-01-04 02:44:42 <gmaxwell> Just like it's not too hard to mess up measuring the total spen between (-1..2016] ? :)
315 2012-01-04 02:44:49 <gmaxwell> doublec: yes.
316 2012-01-04 02:44:53 <luke-jr> doublec: I totally blame gavin for that.
317 2012-01-04 02:44:53 <doublec> [Tycho]: it might be easier to mess up than you think
318 2012-01-04 02:45:07 <luke-jr> it's really not hard to get that right. somehow gavin did :P
319 2012-01-04 02:45:17 <roconnor> gmaxwell: or to pop the right number of arguments for multisig
320 2012-01-04 02:45:19 <doublec> and no one caught it for how long...
321 2012-01-04 02:45:21 <gmaxwell> the recursive code did foo++ when it should have done foo+1 in the argument.
322 2012-01-04 02:45:24 Dagger3 has joined
323 2012-01-04 02:45:31 <doublec> some things are easy to miss
324 2012-01-04 02:45:34 <luke-jr> gmaxwell: var++ is almost always wrong
325 2012-01-04 02:45:40 <[Tycho]> I said "aren't that many ways", but gavin is a pro.
326 2012-01-04 02:45:40 <luke-jr> especially in C++
327 2012-01-04 02:45:51 <gmaxwell> Oh come on.
328 2012-01-04 02:45:52 <[Tycho]> So he managed to do it anyway :)
329 2012-01-04 02:46:08 <gmaxwell> Let he is with expirence but without sin cast the first stone.
330 2012-01-04 02:46:12 <luke-jr> if you want to increment, it's ++var
331 2012-01-04 02:46:52 <luke-jr> gmaxwell: I only use var++ when I really mean "increment this, only after finishing the statement with the old value"
332 2012-01-04 02:47:03 <gmaxwell> Yes, thats what it means.
333 2012-01-04 02:47:07 <roconnor> C++ takes C, makes it better, and hands you the mess that C originally was.
334 2012-01-04 02:47:14 <gmaxwell> But sometimes the figures autopilot and it looks bascially right.
335 2012-01-04 02:47:25 <gmaxwell> er s/figures/fingers/
336 2012-01-04 02:47:33 <luke-jr> bad habits are hard to break
337 2012-01-04 02:47:37 <luke-jr> my habit is ++var
338 2012-01-04 02:48:12 <gmaxwell> it certantly could have been foo++ ... if it were doing something else entirely. :)
339 2012-01-04 02:48:42 <gmaxwell> Gavin even had tests but they failed to catch it for other reasons.
340 2012-01-04 02:49:04 <[Tycho]> Sometimes I use ++var too.
341 2012-01-04 02:49:23 <[Tycho]> Also using "," op makes code funnier.
342 2012-01-04 02:49:37 <gmaxwell> the preincrement is fairly uncommon in most C code bases, and I've seen it confuse people.
343 2012-01-04 02:49:58 <luke-jr> gmaxwell: just because everyone else does it wrong, doesn't mean you should! :P
344 2012-01-04 02:50:07 <luke-jr> and Bitcoin is C++
345 2012-01-04 02:50:19 <luke-jr> postincrement actually has overhead in C++
346 2012-01-04 02:50:50 <gmaxwell> well, it doesn't for primitive types of course.
347 2012-01-04 02:51:03 <luke-jr> but you don't know the type is primitive :p
348 2012-01-04 02:51:21 Dagger3 has quit (Ping timeout: 248 seconds)
349 2012-01-04 02:51:26 * luke-jr sneaks in some C++11
350 2012-01-04 02:51:26 <gmaxwell> I had some code that did i=0;do{â¦}while(++i<flag); confuse the #@$@# out of people multiple times.
351 2012-01-04 02:51:57 <luke-jr> gmaxwell: the same people would be confused by the `do' statement
352 2012-01-04 02:53:26 <gmaxwell> oh, the flag case actually looks like i=0;do{â¦}while(++i<1+flag);
353 2012-01-04 02:53:48 <luke-jr> ok, that is just stupid :P
354 2012-01-04 02:53:56 <luke-jr> in that case, it should be (i++<flag)
355 2012-01-04 02:54:19 <luke-jr> or better yet
356 2012-01-04 02:54:23 <luke-jr> (++i<=flag)
357 2012-01-04 02:56:08 <roconnor> if (opcode > OP_16 && ++nOpCount > 201) // Honestly I'm not entirely sure how many operations are allowed 200? 201? 202?
358 2012-01-04 02:56:25 <roconnor> I think it is 201
359 2012-01-04 02:56:46 <gmaxwell> luke-jr: some fluke of the ti compiler made the former construction preferred, sadly.
360 2012-01-04 02:57:14 <luke-jr> roconnor: 201
361 2012-01-04 03:02:30 freewil has joined
362 2012-01-04 03:02:30 freewil has quit (Changing host)
363 2012-01-04 03:02:30 freewil has joined
364 2012-01-04 03:05:10 xenland has quit (Remote host closed the connection)
365 2012-01-04 03:06:36 BlueMatt-mobile has joined
366 2012-01-04 03:07:07 <roconnor> 201 ops should be enough for anyone.
367 2012-01-04 03:08:13 jacobwg has quit (Quit: Computer has gone to sleep.)
368 2012-01-04 03:13:25 <roconnor> yay, OP_IF works
369 2012-01-04 03:13:41 <luke-jr> lol
370 2012-01-04 03:17:03 Dagger3 has joined
371 2012-01-04 03:21:05 Dagger3 has quit (Client Quit)
372 2012-01-04 03:25:24 BlueMatt has joined
373 2012-01-04 03:25:48 pavel_ has joined
374 2012-01-04 03:27:43 BlueMatt-mobile has quit (Quit: BlueMatt)
375 2012-01-04 03:28:47 CaptainDDL has quit (Quit: I leave my first mate in charge!)
376 2012-01-04 03:28:49 dissipate_ has quit (Quit: Leaving)
377 2012-01-04 03:32:19 <BlueMatt> ;;seen theymos
378 2012-01-04 03:32:19 <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.
379 2012-01-04 03:32:40 dvide has quit ()
380 2012-01-04 03:33:45 Dagger3 has joined
381 2012-01-04 03:34:49 <phantomcircuit> ok so i see one problem with configuring hidden services
382 2012-01-04 03:34:54 [7] has quit (Disconnected by services)
383 2012-01-04 03:35:04 TheSeven has joined
384 2012-01-04 03:35:07 <phantomcircuit> specifically that you have to specify HiddenServiceDir
385 2012-01-04 03:35:16 Zarutian has joined
386 2012-01-04 03:35:19 <phantomcircuit> which isn't really something you can come up with safely ourselves
387 2012-01-04 03:35:23 <phantomcircuit> we*
388 2012-01-04 03:37:06 <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.
389 2012-01-04 03:37:37 <gmaxwell> phantomcircuit: but I thought there was a feature proposal to help.. I don't know where that currently stands.
390 2012-01-04 03:38:09 <gmaxwell> phantomcircuit: see also https://trac.torproject.org/projects/tor/ticket/1949
391 2012-01-04 03:38:10 Dagger3 has quit (Ping timeout: 260 seconds)
392 2012-01-04 03:38:51 <phantomcircuit> gmaxwell, well i could do something lazy like use temporary directory
393 2012-01-04 03:38:57 <phantomcircuit> but that seems like a bad plan
394 2012-01-04 03:43:03 Dagger3 has joined
395 2012-01-04 03:45:05 onelineproof has joined
396 2012-01-04 03:47:40 watson787 has quit (Ping timeout: 240 seconds)
397 2012-01-04 03:48:05 Dagger3 has quit (Ping timeout: 260 seconds)
398 2012-01-04 03:50:22 <phantomcircuit> gmaxwell, actually i think this will be relatively easy to do so long as the hidden service is preconfigured
399 2012-01-04 03:52:43 <roconnor> ramdisk?
400 2012-01-04 03:56:31 watson787 has joined
401 2012-01-04 03:56:41 <phantomcircuit> roconnor, cant set that up as a normal user
402 2012-01-04 03:56:51 <phantomcircuit> and definitely wouldnt work on windows
403 2012-01-04 03:57:51 <roconnor> testnet needs more OP_CODESEPARATOR
404 2012-01-04 04:00:22 <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?
405 2012-01-04 04:03:26 Dagger3 has joined
406 2012-01-04 04:04:17 <phantomcircuit> actually
407 2012-01-04 04:04:21 <phantomcircuit> that doesn't seem to be possible
408 2012-01-04 04:04:22 <phantomcircuit> boo
409 2012-01-04 04:07:00 <phantomcircuit> i can get the directory the hidden service name is in
410 2012-01-04 04:07:06 <phantomcircuit> but then wont have permissions to read
411 2012-01-04 04:07:27 Dagger3 has quit (Client Quit)
412 2012-01-04 04:10:44 darkee has quit (Ping timeout: 276 seconds)
413 2012-01-04 04:12:56 <phantomcircuit> bleh
414 2012-01-04 04:12:57 <phantomcircuit> so
415 2012-01-04 04:13:01 <phantomcircuit> onioncat is GPLv3
416 2012-01-04 04:13:22 <phantomcircuit> who wants to engage in a bit of white room reverse engineering?
417 2012-01-04 04:13:24 <phantomcircuit> anybody
418 2012-01-04 04:13:49 darkmethod has joined
419 2012-01-04 04:14:00 <luke-jr> lol nice
420 2012-01-04 04:14:55 <phantomcircuit> luke-jr, IS THAT A YES?
421 2012-01-04 04:15:12 <phantomcircuit> i just need a small write up of the encoding they use for ipv6 <-> onion
422 2012-01-04 04:15:34 <luke-jr> no, that's a "haha, no tor integration" ;)
423 2012-01-04 04:16:15 <phantomcircuit> boo
424 2012-01-04 04:16:34 <phantomcircuit> BlueMatt, roconnor gmaxwell any takers?
425 2012-01-04 04:16:48 <roconnor> sorry
426 2012-01-04 04:17:07 <roconnor> phantomcircuit: are wo doing tor instead of freenet now?
427 2012-01-04 04:18:57 <roconnor> Patterns not matched:
428 2012-01-04 04:18:59 <roconnor> OP_SHA1
429 2012-01-04 04:19:00 <roconnor> OP_CODESEPARATOR
430 2012-01-04 04:19:03 <roconnor> 2 more ops to go
431 2012-01-04 04:19:46 <phantomcircuit> roconnor, this is actually very low hanging fruit
432 2012-01-04 04:19:56 <phantomcircuit> i could probably get this working like today
433 2012-01-04 04:20:03 <roconnor> I'm going to bed
434 2012-01-04 04:21:56 <BlueMatt> phantomcircuit: I dont know the first thing about restrictions on what you are/arent allowed to know during whiteroom reverse engineering
435 2012-01-04 04:22:36 darkee has joined
436 2012-01-04 04:22:41 <phantomcircuit> BlueMatt, tell me the algorithm used basically
437 2012-01-04 04:22:44 <BlueMatt> though I have never searched/read anything on onioncat that I remember, so if you tell me what Im allowed to know...
438 2012-01-04 04:22:45 <phantomcircuit> without telling me their code
439 2012-01-04 04:22:49 <phantomcircuit> it's insanely stupid
440 2012-01-04 04:22:54 <phantomcircuit> but woo copyright law
441 2012-01-04 04:23:13 <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
442 2012-01-04 04:23:20 <BlueMatt> does that count?
443 2012-01-04 04:23:44 <theymos> I don't think copyright applies to simple facts like that algorithm.
444 2012-01-04 04:23:57 <BlueMatt> theymos: it does when lawyers are involved
445 2012-01-04 04:24:12 <BlueMatt> though theoretically mathematical algorithms are not copyrightable
446 2012-01-04 04:24:28 <BlueMatt> also, doesnt the person who has never read the onioncat source have to do the full implementing, not just tell you the algorithm?
447 2012-01-04 04:24:30 <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
448 2012-01-04 04:24:39 <phantomcircuit> if someone describes the algorithm too me however they cant
449 2012-01-04 04:24:45 <phantomcircuit> because i haven't even seen their code
450 2012-01-04 04:25:08 Joric has joined
451 2012-01-04 04:25:10 paraipan has quit (Remote host closed the connection)
452 2012-01-04 04:25:56 paraipan has joined
453 2012-01-04 04:26:03 <phantomcircuit> actually i could just write my own packing algorithm
454 2012-01-04 04:26:08 <phantomcircuit> it shouldn't really matter
455 2012-01-04 04:26:36 <BlueMatt> not sure if we could pull that...
456 2012-01-04 04:26:47 <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.
457 2012-01-04 04:26:48 <phantomcircuit> dur
458 2012-01-04 04:27:00 <phantomcircuit> i can just debase32
459 2012-01-04 04:32:27 pavel_ has quit (Ping timeout: 240 seconds)
460 2012-01-04 04:35:00 kiba has quit (Ping timeout: 240 seconds)
461 2012-01-04 04:36:29 roconnor has quit (Ping timeout: 268 seconds)
462 2012-01-04 04:36:54 wasabi2 has joined
463 2012-01-04 04:38:40 wasabi3 has quit (Ping timeout: 240 seconds)
464 2012-01-04 04:40:50 pavel_ has joined
465 2012-01-04 04:46:03 <BlueMatt> phantomcircuit: I SEE YOU
466 2012-01-04 04:46:22 <phantomcircuit> BlueMatt, xD
467 2012-01-04 04:46:51 * BlueMatt idles in #debian 24/7 to try to catch the maintainer of sshfs and tell him to update the damn package
468 2012-01-04 04:47:34 <nanotube> try sending him an email ? :)
469 2012-01-04 04:48:11 <BlueMatt> I filed a bug report, but Im too lazy to bug him by email
470 2012-01-04 04:48:20 <BlueMatt> maybe Ill get around to it someday...
471 2012-01-04 04:49:31 <phantomcircuit> so
472 2012-01-04 04:50:08 <luke-jr> BlueMatt: lol, I've done that before
473 2012-01-04 04:51:40 <phantomcircuit> is there a special variable for "whoami"
474 2012-01-04 04:51:50 <phantomcircuit> im sure there is but have no idea what it is
475 2012-01-04 04:54:19 <BlueMatt> variable where?
476 2012-01-04 04:54:53 <phantomcircuit> i mean a static
477 2012-01-04 04:54:58 <phantomcircuit> in bitcoin somewhere
478 2012-01-04 04:55:06 <phantomcircuit> that represents what we think our own address is
479 2012-01-04 04:55:07 <BlueMatt> whoami like uid?
480 2012-01-04 04:55:13 <phantomcircuit> no
481 2012-01-04 04:55:14 <BlueMatt> oh, ip yea I think there is...
482 2012-01-04 04:56:02 <theymos> addrMe, I think.
483 2012-01-04 04:56:02 <BlueMatt> addrLocalHost
484 2012-01-04 04:57:24 <phantomcircuit> this is actually going to be fairly easy
485 2012-01-04 04:57:33 <phantomcircuit> if you already have the hidden service setup
486 2012-01-04 04:57:45 * BlueMatt ponders offering a bounty for devs who ack https://github.com/bitcoin/bitcoin/pull/593 though I suppose thats too unethical...
487 2012-01-04 04:58:47 coblee has joined
488 2012-01-04 04:59:54 <phantomcircuit> BlueMatt, neat
489 2012-01-04 05:00:04 <phantomcircuit> id ack but i have no idea about qt
490 2012-01-04 05:00:09 <luke-jr> BlueMatt: I'd do it free if it fixed spec compliance ;)
491 2012-01-04 05:00:33 <BlueMatt> phantomcircuit: just compile it, beat on it a bit and comment that you beat on it a bit and it worked
492 2012-01-04 05:00:42 <BlueMatt> phantomcircuit: pretty please/
493 2012-01-04 05:00:43 <BlueMatt> ?
494 2012-01-04 05:01:09 <phantomcircuit> i'll put it in the middle of my todo list just below paying things and right above everything else
495 2012-01-04 05:01:11 <phantomcircuit> so
496 2012-01-04 05:01:18 <phantomcircuit> probably not this month? (yay money)
497 2012-01-04 05:01:31 RobinPKR_ has joined
498 2012-01-04 05:01:55 <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.
499 2012-01-04 05:02:23 <phantomcircuit> gmaxwell, yeah i thought they were doing something clever to pack it
500 2012-01-04 05:02:25 <phantomcircuit> but they're not
501 2012-01-04 05:02:54 <gmaxwell> ah. yea, nothing smart is required. Just base conversion and perhaps getting the same byteorder.
502 2012-01-04 05:03:00 RobinPKR has quit (Ping timeout: 240 seconds)
503 2012-01-04 05:03:01 RobinPKR_ is now known as RobinPKR
504 2012-01-04 05:04:50 Dagger3 has joined
505 2012-01-04 05:05:09 <gmaxwell> roconnor: there were people making a bunch of noise about freenet a while back, dunno if it resulted in code..
506 2012-01-04 05:05:30 <gmaxwell> but even if it did, it wouldn't really be anything to integrate with bitcoin, it would just be a gateway.
507 2012-01-04 05:05:49 ahihi2 has quit (Remote host closed the connection)
508 2012-01-04 05:06:02 <gmaxwell> tor support seems like a good candidate for direct support, since it fits with our normal p2p network protocol.
509 2012-01-04 05:06:04 <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.
510 2012-01-04 05:07:19 bushing has joined
511 2012-01-04 05:07:43 <gmaxwell> yea, I remembered not being impressed.
512 2012-01-04 05:08:03 <BlueMatt> Im pretty sure they never got anywhere
513 2012-01-04 05:08:24 <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)
514 2012-01-04 05:08:56 <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)
515 2012-01-04 05:09:25 Dagger3 has quit (Quit: Quitting)
516 2012-01-04 05:09:26 ahihi2 has joined
517 2012-01-04 05:10:26 <BlueMatt> gmaxwell: if you wait a couple years till I get some disposable income, I probably will...
518 2012-01-04 05:10:35 <theymos> Freenet or GNUnet might work OK. I just didn't like that specific proposal.
519 2012-01-04 05:11:34 <nanotube> gmaxwell: what would be the least costly and most useful relay to set up?
520 2012-01-04 05:12:33 dan__ has joined
521 2012-01-04 05:13:16 Dagger3 has joined
522 2012-01-04 05:14:00 <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.
523 2012-01-04 05:19:20 <phantomcircuit> you could broadcast bitcoin transactions/blocks over VHF or something
524 2012-01-04 05:20:35 <gmaxwell> phantomcircuit: sure, I could have that going in about 30 minutes.
525 2012-01-04 05:20:46 <gmaxwell> You don't go far that way though.
526 2012-01-04 05:21:52 underscor has quit (Read error: Connection reset by peer)
527 2012-01-04 05:21:54 <phantomcircuit> lol everytime i try and change something in bitcoin i have to remember c++
528 2012-01-04 05:22:05 <phantomcircuit> net.cpp:1734:9: error: ÂfTor was not declared in this scope
529 2012-01-04 05:22:09 <nanotube> bounce lasers off the moon :)
530 2012-01-04 05:22:17 Joric has quit ()
531 2012-01-04 05:22:24 <gmaxwell> I've talked to cydeweys who is in #bitcoin sometimes over vhf over a 30 mi path or so.
532 2012-01-04 05:23:33 <gmaxwell> The blockchain datarate is really quite low.
533 2012-01-04 05:23:34 pickett has joined
534 2012-01-04 05:24:42 <phantomcircuit> lol no wonder
535 2012-01-04 05:24:51 <phantomcircuit> fTor is refined in 2 places ie isn't global
536 2012-01-04 05:24:56 <phantomcircuit> but all definitions are identical
537 2012-01-04 05:25:02 <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.
538 2012-01-04 05:25:50 underscor has joined
539 2012-01-04 05:27:39 <BlueMatt> gmaxwell: chain download is disturbingly fast now...
540 2012-01-04 05:29:07 <gmaxwell> need to get the pointless db activity out of the way..
541 2012-01-04 05:29:21 * BlueMatt feels so bad about that...
542 2012-01-04 05:29:26 <gmaxwell> Pfft.
543 2012-01-04 05:29:35 <BlueMatt> gmaxwell: probably not too hard to do in CBlockStore
544 2012-01-04 05:29:49 <BlueMatt> (hopefully)
545 2012-01-04 05:30:02 <gmaxwell> if not a seperate dbenv, we could at least do batch updates or something.
546 2012-01-04 05:30:26 <nanotube> BlueMatt: i bet you feel kinda like the guy who invented captchas now eh? :D
547 2012-01-04 05:30:40 <BlueMatt> nanotube: haha, ok that was good
548 2012-01-04 05:30:45 <phantomcircuit> crap where is genjix
549 2012-01-04 05:30:46 <phantomcircuit> or
550 2012-01-04 05:30:53 <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.
551 2012-01-04 05:30:56 <phantomcircuit> someone tell me how the hell the extern settings work
552 2012-01-04 05:31:31 <BlueMatt> gmaxwell: good to hear
553 2012-01-04 05:31:53 <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.
554 2012-01-04 05:32:58 <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)
555 2012-01-04 05:33:05 <BlueMatt> gmaxwell: Ill put it on the todo
556 2012-01-04 05:33:30 <phantomcircuit> nvm i'll figure it out
557 2012-01-04 05:34:31 WakiMiko_ has joined
558 2012-01-04 05:35:00 <phantomcircuit> lol there is a completely useless line
559 2012-01-04 05:35:09 <phantomcircuit> net.cpp:1473
560 2012-01-04 05:35:56 kiba has joined
561 2012-01-04 05:36:02 <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)
562 2012-01-04 05:37:09 <gmaxwell> phantomcircuit: hm. clang scan-build should whine about that.
563 2012-01-04 05:37:20 <phantomcircuit> fTOR is never used
564 2012-01-04 05:37:22 <phantomcircuit> anywhere
565 2012-01-04 05:37:29 <phantomcircuit> fTor is
566 2012-01-04 05:37:46 WakiMiko has quit (Ping timeout: 260 seconds)
567 2012-01-04 05:37:55 <gmaxwell> I mean it should whine about the stuff being assigned and never used within its scope.
568 2012-01-04 05:37:57 <kiba> boom
569 2012-01-04 05:38:09 <phantomcircuit> yeah
570 2012-01-04 05:38:14 <phantomcircuit> guess it doesn't?
571 2012-01-04 05:38:28 <gmaxwell> phantomcircuit: gavin just committed some ftor related changes today that stupidity might have been a result of.
572 2012-01-04 05:38:28 <theymos> fTOR is used in 0.3.19. Maybe it changed.
573 2012-01-04 05:39:02 <gmaxwell> phantomcircuit: see https://github.com/bitcoin/bitcoin/issues/739
574 2012-01-04 05:40:42 <phantomcircuit> gmaxwell, yeah he added the fTor which is used
575 2012-01-04 05:40:49 <phantomcircuit> fTOR is from satoshi
576 2012-01-04 05:40:49 <theymos> Always annoyed me how Satoshi incorrectly said TOR instead of Tor.
577 2012-01-04 05:40:55 <phantomcircuit> and appears to have been obliterated
578 2012-01-04 05:41:00 <BlueMatt> there have been quite a few fTor changes recently
579 2012-01-04 05:41:08 <phantomcircuit> anyways
580 2012-01-04 05:41:18 <phantomcircuit> this is actually fairly easy to do
581 2012-01-04 05:41:29 <phantomcircuit> i should have a tor hidden services build available soonish
582 2012-01-04 05:41:34 Joric has joined
583 2012-01-04 05:41:45 <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! :)
584 2012-01-04 05:42:09 <phantomcircuit> this would actually be much easier with an ipv6 compatible build
585 2012-01-04 05:42:39 <phantomcircuit> as it stands i will probably have to create a COnionAddress object
586 2012-01-04 05:43:57 <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.
587 2012-01-04 05:44:13 <phantomcircuit> pretty much
588 2012-01-04 05:44:33 <gmaxwell> The rest of the code should just think it's just IPv6.
589 2012-01-04 05:44:37 <phantomcircuit> yeah
590 2012-01-04 05:44:56 theymos has quit (Remote host closed the connection)
591 2012-01-04 05:46:03 <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....
592 2012-01-04 05:46:22 <gmaxwell> so you could run mixed mode nodes without hurting the privacy of using tor.
593 2012-01-04 05:46:34 <kiba> status maximinzing versus moneymaking
594 2012-01-04 05:46:55 <gmaxwell> kiba: yibble plop?
595 2012-01-04 05:47:04 <kiba> just thinking about human motives
596 2012-01-04 05:47:20 <kiba> it would seems to me that humans are more motiviated by status rather than money
597 2012-01-04 05:47:32 <gmaxwell> kiba: whats money but a way of buying status?
598 2012-01-04 05:47:38 <gmaxwell> it's kinda boring by itself.
599 2012-01-04 05:48:02 <kiba> gmaxwell: well, charities don't need to be "non-profit" to achieve improtant changes
600 2012-01-04 05:48:37 b4epoche_ has joined
601 2012-01-04 05:48:38 <phantomcircuit> hmm
602 2012-01-04 05:48:53 <phantomcircuit> if the local address is 127.0.0.1:8333
603 2012-01-04 05:49:13 <phantomcircuit> then i cant accept connections from anybody who cant reach 127.0.0.0/8 which is everybody but me
604 2012-01-04 05:49:14 <phantomcircuit> ok safe
605 2012-01-04 05:49:19 <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
606 2012-01-04 05:49:29 b4epoche has quit (Ping timeout: 248 seconds)
607 2012-01-04 05:49:29 b4epoche_ is now known as b4epoche
608 2012-01-04 05:49:31 <kiba> say
609 2012-01-04 05:49:35 <kiba> you're a world class laywer
610 2012-01-04 05:50:10 <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
611 2012-01-04 05:50:36 groffer has quit (Quit: leaving)
612 2012-01-04 05:50:47 BurtyB has quit (Ping timeout: 252 seconds)
613 2012-01-04 05:50:51 <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
614 2012-01-04 05:52:26 <kiba> humans are overly complicated creatures for seemly no good reasons sometime
615 2012-01-04 05:52:44 BurtyB has joined
616 2012-01-04 05:56:25 <phantomcircuit> fUseProxy = 0
617 2012-01-04 05:56:34 <phantomcircuit> yeah i would say fUseProxy is broken
618 2012-01-04 05:57:37 <gmaxwell> init.cpp: fUseProxy = true;
619 2012-01-04 05:58:18 <phantomcircuit> yeah it's after that printf
620 2012-01-04 05:59:30 <phantomcircuit> ah i see
621 2012-01-04 05:59:39 <phantomcircuit> there are settings saved in the wallet.dat
622 2012-01-04 06:00:02 EPiSKiNG- has joined
623 2012-01-04 06:00:29 <gmaxwell> .. there .. are . huh????!
624 2012-01-04 06:00:41 <BlueMatt> gmaxwell: you didnt know that?
625 2012-01-04 06:00:53 <BlueMatt> settings have always been saved in wallet.dat...
626 2012-01-04 06:01:23 <BlueMatt> but...yea
627 2012-01-04 06:01:38 <Joric> ah that's why you fuck em up when you're replacing the wallet
628 2012-01-04 06:03:32 <phantomcircuit> ok what the fuck
629 2012-01-04 06:03:37 <phantomcircuit> i have this open in gdb
630 2012-01-04 06:03:50 <phantomcircuit> just went over if (fTor)
631 2012-01-04 06:03:52 <phantomcircuit> and yet
632 2012-01-04 06:03:55 <phantomcircuit> print fTor
633 2012-01-04 06:04:00 <phantomcircuit> $6 = 0
634 2012-01-04 06:04:03 <phantomcircuit> ???????????????????????????????
635 2012-01-04 06:05:46 <midnightmagic> shared variable between threads?
636 2012-01-04 06:06:19 <midnightmagic> aand.. overwritten by a bad syscall in another?
637 2012-01-04 06:06:21 <phantomcircuit> onlt 1 thread
638 2012-01-04 06:06:34 <phantomcircuit> this is in init.cpp InitApp
639 2012-01-04 06:07:20 <phantomcircuit> some insanity scope thing i guess
640 2012-01-04 06:07:39 drazak_ has quit (Ping timeout: 252 seconds)
641 2012-01-04 06:10:11 <wumpus> yes, all the ui-set settings are stored in wallet.dat ... that will give problems when multi-wallet support is added
642 2012-01-04 06:10:33 <wumpus> phantomcircuit: the handling of fTor/mUseProxy etc was recently refactored, maybe there's a bug
643 2012-01-04 06:10:50 <wumpus> well there was a bug already... but maybe there's a new one now the old one is fixed :-)
644 2012-01-04 06:11:02 <gmaxwell> BlueMatt: I haven't used the ui at any time in the modern era.
645 2012-01-04 06:11:20 <luke-jr> wumpus: hey
646 2012-01-04 06:11:37 <wumpus> well also if you change settings through rpc, all settings remembered by bitcoin itself in general are in the wallet
647 2012-01-04 06:11:45 <wumpus> luke-jr: hey
648 2012-01-04 06:11:49 <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?
649 2012-01-04 06:12:02 <wumpus> it has always been true
650 2012-01-04 06:12:07 <luke-jr> k
651 2012-01-04 06:12:09 <wumpus> with rpc you can set the to field
652 2012-01-04 06:12:25 <BlueMatt> gmaxwell: mmm
653 2012-01-04 06:12:27 <wumpus> in sendaddress
654 2012-01-04 06:12:32 <luke-jr> wumpus: could you get signmessage merged? ;p
655 2012-01-04 06:12:46 <luke-jr> plz
656 2012-01-04 06:12:56 <wumpus> yes it's on my todo
657 2012-01-04 06:13:52 <luke-jr> k, just would prefer to not have to keep rebasing it
658 2012-01-04 06:13:57 * luke-jr will try to be more patient âº
659 2012-01-04 06:14:13 <wumpus> yes, having to rebase it alll the time is bad...
660 2012-01-04 06:19:23 <phantomcircuit> ok partial victory
661 2012-01-04 06:19:26 <phantomcircuit> this
662 2012-01-04 06:19:29 <phantomcircuit> kind of works
663 2012-01-04 06:19:40 <phantomcircuit> if you setup all the tor stuff yourself
664 2012-01-04 06:19:47 <phantomcircuit> and know the hidden node you want to connect to
665 2012-01-04 06:19:48 <phantomcircuit> so
666 2012-01-04 06:19:49 <phantomcircuit> yeah
667 2012-01-04 06:21:14 <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.
668 2012-01-04 06:23:16 <phantomcircuit> phase 1 basically consists of listening on 127.0.0.1 instead of not listening at all
669 2012-01-04 06:23:18 <phantomcircuit> more or less
670 2012-01-04 06:23:41 watson787 has quit (Ping timeout: 240 seconds)
671 2012-01-04 06:26:05 <phantomcircuit> wtf
672 2012-01-04 06:26:08 <phantomcircuit> is it just me
673 2012-01-04 06:26:20 <phantomcircuit> or is master completely missing -connect
674 2012-01-04 06:28:13 <gmaxwell> phantomcircuit: it's you
675 2012-01-04 06:28:13 <gmaxwell> // Connect to specific addresses
676 2012-01-04 06:28:13 <gmaxwell> if (mapArgs.count("-connect"))
677 2012-01-04 06:29:31 <phantomcircuit> good
678 2012-01-04 06:33:34 Zarutian has quit (Quit: Zarutian)
679 2012-01-04 06:36:56 genjix has left ()
680 2012-01-04 06:37:23 dan__ has quit (Quit: dan__)
681 2012-01-04 06:45:26 paraipan has quit (Read error: Connection reset by peer)
682 2012-01-04 06:46:09 paraipan has joined
683 2012-01-04 06:46:46 mcorlett has quit (Remote host closed the connection)
684 2012-01-04 06:47:54 [Tycho] has quit (Remote host closed the connection)
685 2012-01-04 06:49:49 onelineproof has quit (Read error: Connection reset by peer)
686 2012-01-04 06:59:23 darkmethod has quit (Quit: Computer has gone to sleep.)
687 2012-01-04 07:08:21 davout has joined
688 2012-01-04 07:08:21 davout has quit (Changing host)
689 2012-01-04 07:08:21 davout has joined
690 2012-01-04 07:08:27 <phantomcircuit> gmaxwell, yeah im not going to add a special handler
691 2012-01-04 07:08:41 <phantomcircuit> what's the best ipv6 branch currently available
692 2012-01-04 07:13:13 larsivi_ has quit (Ping timeout: 248 seconds)
693 2012-01-04 07:18:09 <BlueMatt> sipa has one
694 2012-01-04 07:18:14 <BlueMatt> (not sure how up-to-date it is)
695 2012-01-04 07:25:53 dissipate_ has joined
696 2012-01-04 07:39:41 copumpkin has quit (Ping timeout: 252 seconds)
697 2012-01-04 07:42:54 darkee has quit (Remote host closed the connection)
698 2012-01-04 07:43:35 darkee has joined
699 2012-01-04 07:48:34 RazielZ has joined
700 2012-01-04 08:12:44 Clipse has joined
701 2012-01-04 08:15:14 erle- has joined
702 2012-01-04 08:16:27 molecular has quit (Ping timeout: 276 seconds)
703 2012-01-04 08:16:44 molecular has joined
704 2012-01-04 08:28:55 BlueMatt has quit (Quit: Ex-Chat)
705 2012-01-04 08:31:34 abragin has joined
706 2012-01-04 08:31:34 abragin has quit (Changing host)
707 2012-01-04 08:31:34 abragin has joined
708 2012-01-04 08:56:01 Diablo-D3 has joined
709 2012-01-04 09:04:02 marf_away has joined
710 2012-01-04 09:19:15 Turingi has joined
711 2012-01-04 09:20:15 tower has quit (Quit: | ReactOS - The FOSS alternative to MS Windows! | http://www.reactos.org/ | join #ReactOS |)
712 2012-01-04 09:25:08 pycke has joined
713 2012-01-04 09:26:37 Ken` has quit (Remote host closed the connection)
714 2012-01-04 09:29:08 darkskiez has joined
715 2012-01-04 09:30:04 davout has quit (Remote host closed the connection)
716 2012-01-04 09:31:20 davout has joined
717 2012-01-04 09:32:26 justmoon has quit (Quit: Leaving)
718 2012-01-04 09:35:58 tower has joined
719 2012-01-04 09:47:27 da2ce7 has joined
720 2012-01-04 09:56:56 osmosis has quit (Quit: Leaving)
721 2012-01-04 09:59:21 jim618 has joined
722 2012-01-04 09:59:59 b4epoche_ has joined
723 2012-01-04 10:01:04 jim618 has left ()
724 2012-01-04 10:01:29 b4epoche has quit (Ping timeout: 268 seconds)
725 2012-01-04 10:01:30 b4epoche_ is now known as b4epoche
726 2012-01-04 10:03:34 ovidiusoft has joined
727 2012-01-04 10:03:38 davout has quit (Remote host closed the connection)
728 2012-01-04 10:04:26 makomk has quit (Remote host closed the connection)
729 2012-01-04 10:10:38 <sipa> phantomcircuit: i have a 'ipv6' branch that is outdated but works
730 2012-01-04 10:11:21 Clipse has quit (Ping timeout: 240 seconds)
731 2012-01-04 10:11:34 <phantomcircuit> sipa, did you more recently create a branch to just handle the addresses?
732 2012-01-04 10:11:41 <sipa> i also have a 'netbase' branch that is up to date, and has almost ipv6 support
733 2012-01-04 10:18:26 <phantomcircuit> yeah
734 2012-01-04 10:18:38 <phantomcircuit> all i need is a way to pass around the onion in ipv6 addresses
735 2012-01-04 10:19:11 <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
736 2012-01-04 10:19:20 <phantomcircuit> sipa, how close is that to being merged?
737 2012-01-04 10:19:31 <phantomcircuit> i think i was reading it earlier and didn't see any issues
738 2012-01-04 10:21:03 Ken` has joined
739 2012-01-04 10:22:34 darkskiez has quit (Remote host closed the connection)
740 2012-01-04 10:22:59 darkskiez has joined
741 2012-01-04 10:24:12 booo has joined
742 2012-01-04 10:28:05 benne has quit (Ping timeout: 255 seconds)
743 2012-01-04 10:39:20 wasabi3 has joined
744 2012-01-04 10:39:28 da2ce7 has quit (Ping timeout: 276 seconds)
745 2012-01-04 10:40:05 Dagger3 is now known as Dagger2
746 2012-01-04 10:41:13 wasabi2 has quit (Ping timeout: 248 seconds)
747 2012-01-04 10:47:08 <sipa> phantomcircuit: i hope close
748 2012-01-04 10:55:42 devrandom has quit (Remote host closed the connection)
749 2012-01-04 10:58:12 erus` has joined
750 2012-01-04 11:00:00 BurtyB has quit (Read error: Connection reset by peer)
751 2012-01-04 11:00:17 BurtyB has joined
752 2012-01-04 11:08:35 Joric has quit (Ping timeout: 255 seconds)
753 2012-01-04 11:13:00 Joric has joined
754 2012-01-04 11:13:00 Joric has quit (Changing host)
755 2012-01-04 11:13:00 Joric has joined
756 2012-01-04 11:20:40 Turingi has quit (Quit: Leaving)
757 2012-01-04 11:22:28 b4epoche_ has joined
758 2012-01-04 11:22:38 b4epoche has quit (Ping timeout: 240 seconds)
759 2012-01-04 11:22:38 b4epoche_ is now known as b4epoche
760 2012-01-04 11:24:08 mcorlett has joined
761 2012-01-04 11:27:32 b4epoche has quit (Ping timeout: 252 seconds)
762 2012-01-04 11:28:17 b4epoche has joined
763 2012-01-04 11:28:38 Ken` has quit (Quit: leaving)
764 2012-01-04 11:33:24 Ken` has joined
765 2012-01-04 11:34:44 b4epoche has quit (Ping timeout: 252 seconds)
766 2012-01-04 11:35:19 b4epoche has joined
767 2012-01-04 11:40:00 wasabi2 has joined
768 2012-01-04 11:42:02 wasabi3 has quit (Ping timeout: 240 seconds)
769 2012-01-04 11:44:56 datagutt has joined
770 2012-01-04 11:51:54 b4epoche has quit (Ping timeout: 252 seconds)
771 2012-01-04 11:54:59 b4epoche has joined
772 2012-01-04 11:55:13 booo has quit (Ping timeout: 252 seconds)
773 2012-01-04 11:59:11 b4epoche has quit (Ping timeout: 240 seconds)
774 2012-01-04 11:59:27 b4epoche has joined
775 2012-01-04 12:01:55 devrandom has joined
776 2012-01-04 12:02:56 makomk has joined
777 2012-01-04 12:04:49 b4epoche has quit (Ping timeout: 240 seconds)
778 2012-01-04 12:06:07 b4epoche has joined
779 2012-01-04 12:12:21 davout has joined
780 2012-01-04 12:18:16 b4epoche has quit (Ping timeout: 276 seconds)
781 2012-01-04 12:19:25 toffoo has quit ()
782 2012-01-04 12:20:37 b4epoche has joined
783 2012-01-04 12:20:51 watson787 has joined
784 2012-01-04 12:25:02 watson787 has quit (Ping timeout: 240 seconds)
785 2012-01-04 12:32:40 b4epoche has quit (Read error: Connection reset by peer)
786 2012-01-04 12:33:03 b4epoche has joined
787 2012-01-04 12:38:49 <CIA-100> bitcoin: p2k * r6cf95a483b1d ecoinpool/ (4 files in 2 dirs): MySQL Replicator http://tinyurl.com/7wckkch
788 2012-01-04 12:39:04 davout has quit (Remote host closed the connection)
789 2012-01-04 13:00:56 copumpkin has joined
790 2012-01-04 13:01:08 ThomasV has quit (Quit: Leaving)
791 2012-01-04 13:03:18 diki has quit (Read error: Connection reset by peer)
792 2012-01-04 13:04:00 diki has joined
793 2012-01-04 13:04:11 b4epoche has quit (Ping timeout: 248 seconds)
794 2012-01-04 13:04:25 diki is now known as Guest33828
795 2012-01-04 13:07:30 b4epoche has joined
796 2012-01-04 13:10:42 JFK911_ has joined
797 2012-01-04 13:10:51 JFK911 has quit (Read error: Connection reset by peer)
798 2012-01-04 13:11:55 b4epoche has quit (Ping timeout: 252 seconds)
799 2012-01-04 13:14:29 b4epoche has joined
800 2012-01-04 13:17:37 rdponticelli has joined
801 2012-01-04 13:17:39 [Tycho] has joined
802 2012-01-04 13:19:31 b4epoche has quit (Read error: Connection reset by peer)
803 2012-01-04 13:19:32 abragin has quit (Read error: Connection reset by peer)
804 2012-01-04 13:19:56 b4epoche has joined
805 2012-01-04 13:20:46 abragin has joined
806 2012-01-04 13:20:46 abragin has quit (Changing host)
807 2012-01-04 13:20:46 abragin has joined
808 2012-01-04 13:23:24 b4epoche_ has joined
809 2012-01-04 13:24:23 b4epoche has quit (Ping timeout: 268 seconds)
810 2012-01-04 13:24:23 b4epoche_ is now known as b4epoche
811 2012-01-04 13:29:10 roconnor has joined
812 2012-01-04 13:29:28 davout has joined
813 2012-01-04 13:31:37 iocor has joined
814 2012-01-04 13:32:04 pavel_ has quit (Ping timeout: 252 seconds)
815 2012-01-04 13:41:39 JFK911_ is now known as JFK911
816 2012-01-04 13:43:02 rdponticelli has quit (Ping timeout: 240 seconds)
817 2012-01-04 13:43:09 roconnor has quit (Ping timeout: 260 seconds)
818 2012-01-04 13:43:27 rdponticelli has joined
819 2012-01-04 13:51:47 Iiuiuiu has joined
820 2012-01-04 13:52:42 davout has quit (Remote host closed the connection)
821 2012-01-04 13:52:43 minimoose has joined
822 2012-01-04 13:53:55 luke-jr_ has joined
823 2012-01-04 13:54:11 imsaguy2 has quit (Remote host closed the connection)
824 2012-01-04 13:54:36 luke-jr has quit (Ping timeout: 268 seconds)
825 2012-01-04 14:02:41 chrisb__ has joined
826 2012-01-04 14:04:30 imsaguy2 has joined
827 2012-01-04 14:04:31 imsaguy2 has quit (Changing host)
828 2012-01-04 14:04:31 imsaguy2 has joined
829 2012-01-04 14:12:08 copumpkin has quit (Quit: Computer has gone to sleep.)
830 2012-01-04 14:17:33 [Tycho] has quit (Remote host closed the connection)
831 2012-01-04 14:20:47 Iiuiuiu has quit (Quit: Leaving)
832 2012-01-04 14:23:11 erle- has quit (Quit: erle-)
833 2012-01-04 14:35:59 copumpkin has joined
834 2012-01-04 14:41:19 wasabi3 has joined
835 2012-01-04 14:43:18 wasabi2 has quit (Ping timeout: 240 seconds)
836 2012-01-04 14:47:11 abragin has quit (Ping timeout: 252 seconds)
837 2012-01-04 14:55:05 Turingi has joined
838 2012-01-04 15:03:47 roconnor has joined
839 2012-01-04 15:06:10 Xunie has joined
840 2012-01-04 15:06:33 abragin has joined
841 2012-01-04 15:06:33 abragin has quit (Changing host)
842 2012-01-04 15:06:33 abragin has joined
843 2012-01-04 15:07:15 user has joined
844 2012-01-04 15:10:06 cosurgi has joined
845 2012-01-04 15:10:48 RAWRwins254 has quit (Ping timeout: 245 seconds)
846 2012-01-04 15:13:06 larg78 has quit ()
847 2012-01-04 15:16:07 p0s has joined
848 2012-01-04 15:23:51 xtor_ has quit (Read error: Connection reset by peer)
849 2012-01-04 15:28:01 gavinandresen has joined
850 2012-01-04 15:29:14 rdponticelli_ has joined
851 2012-01-04 15:29:50 rdponticelli has quit (Ping timeout: 240 seconds)
852 2012-01-04 15:34:38 RAWRwins254 has joined
853 2012-01-04 15:35:21 <UukGoblin> no mtgox trades reported by bitcoincharts for 1h20m
854 2012-01-04 15:38:00 _Fireball has joined
855 2012-01-04 15:38:46 <erus`> :O
856 2012-01-04 15:39:31 [Tycho] has joined
857 2012-01-04 15:39:53 Guest33828 is now known as diki
858 2012-01-04 15:40:01 jacobwg has joined
859 2012-01-04 15:47:34 chrisb__ has quit (Quit: Ex-Chat)
860 2012-01-04 15:49:58 dvide has joined
861 2012-01-04 15:52:01 booo has joined
862 2012-01-04 15:52:11 user has quit (Quit: Leaving)
863 2012-01-04 15:53:26 gfinn has quit (Ping timeout: 276 seconds)
864 2012-01-04 15:53:45 phantomfake has joined
865 2012-01-04 15:56:50 rdponticelli_ has quit (Remote host closed the connection)
866 2012-01-04 16:01:18 <UukGoblin> still broken
867 2012-01-04 16:04:31 safra has joined
868 2012-01-04 16:07:40 <phantomfake> I have a stupid question, is there any way to use Bitcoin as password tokens?
869 2012-01-04 16:13:40 <gmaxwell> What is a password token? You mean like a two-factor auth keyfob?
870 2012-01-04 16:14:08 <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.
871 2012-01-04 16:15:01 <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)
872 2012-01-04 16:15:21 <gmaxwell> The problem there is that a savvy attacker could use a fast gpu miner to easily do that mining.
873 2012-01-04 16:15:45 <helo> hmmm... it would be cool if you could do something with the block hashes to make a synchronized time-changing password token
874 2012-01-04 16:16:34 <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.
875 2012-01-04 16:17:12 <helo> yeah...
876 2012-01-04 16:17:24 gfinn has joined
877 2012-01-04 16:17:37 <gmaxwell> once opencl becomes common, perhaps mining captchas will become viable.
878 2012-01-04 16:18:16 <helo> Click this button to demonstrate that you have a nice computer.
879 2012-01-04 16:18:25 <gmaxwell> (er, webcl not opencl)
880 2012-01-04 16:19:27 erus` has quit (Remote host closed the connection)
881 2012-01-04 16:22:24 merde has quit ()
882 2012-01-04 16:22:26 <phantomfake> gmaxwell, I don't understand the problem, how could the miner attack the system?
883 2012-01-04 16:23:47 <gmaxwell> phantomfake: In what kind of usage?
884 2012-01-04 16:24:06 <phantomfake> gmaxwell, I just didn't understand what you said before.
885 2012-01-04 16:24:39 <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?
886 2012-01-04 16:24:57 <phantomfake> gmaxwell, haha ok, I'll try.
887 2012-01-04 16:26:01 <Diablo-D3> http://www.regretsy.com/2012/01/03/from-the-mailbag-27/
888 2012-01-04 16:26:05 <phantomfake> gmaxwell, When I asked about using Bitcoin as a password token you said a miner would be able to compromise such a system.
889 2012-01-04 16:26:19 <gmaxwell> phantomfake: Explain what you mean by password token.
890 2012-01-04 16:27:22 <phantomfake> gmaxwell, If a password could be exchanged for spending Bitcoin.
891 2012-01-04 16:27:57 <phantomfake> gmaxwell, Or using the spending of Bitcoin as an authentication mechanism.
892 2012-01-04 16:28:32 <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.
893 2012-01-04 16:30:38 booo has quit (Ping timeout: 268 seconds)
894 2012-01-04 16:30:54 <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?
895 2012-01-04 16:31:10 <gmaxwell> phantomfake: There isn't a 'sending address', really.
896 2012-01-04 16:31:47 <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.
897 2012-01-04 16:33:26 <phantomfake> gmaxwell, Could you please send me a like to that?
898 2012-01-04 16:34:00 <phantomfake> gmaxwell, Has this question been asked before?
899 2012-01-04 16:34:58 <luke-jr_> http://www.regretsy.com/2012/01/03/from-the-mailbag-27/
900 2012-01-04 16:35:19 merde has joined
901 2012-01-04 16:36:37 <gmaxwell> $ ./bitcoind signmessage 1AGMAXWELLayCyS1vkLXEszESHEcB3LWqa "This address belongs to gmaxwell on freenode"
902 2012-01-04 16:36:45 <gmaxwell> HD4ct3e5j933O+6BmMeImVFd6FJayzH1ujafeCbkbBr9f+Acj+GcYishrJrYN/z7QyW5MdWaw3AaY+Y8Dxw5nX0=
903 2012-01-04 16:37:00 <gmaxwell> $ .//bitcoind verifymessage 1AGMAXWELLayCyS1vkLXEszESHEcB3LWqa "HD4ct3e5j933O+6BmMeImVFd6FJayzH1ujafeCbkbBr9f+Acj+GcYishrJrYN/z7QyW5MdWaw3AaY+Y8Dxw5nX0=" "This address belongs to gmaxwell on freenode"
904 2012-01-04 16:37:08 <gmaxwell> true
905 2012-01-04 16:37:42 <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.
906 2012-01-04 16:38:21 <gmaxwell> phantomfake: the gui interface for signmessage hasn't been merged yet, the feature is cli/rpc only at the moment.
907 2012-01-04 16:38:22 <roconnor> gmaxwell: that would require keyrecovery, no?
908 2012-01-04 16:38:30 <gmaxwell> roconnor: it already uses key recovery.
909 2012-01-04 16:38:44 <roconnor> gmaxwell: oh? I didn't think key recovery was part of openssl
910 2012-01-04 16:38:57 <gmaxwell> roconnor: the address wouldn't let it work without key recovery regardlessâ the address is a hash, remember? :)
911 2012-01-04 16:39:09 <gmaxwell> roconnor: there is key recovery in bitcoin now, for this. :)
912 2012-01-04 16:40:19 <roconnor> gmaxwell: who wrote that?
913 2012-01-04 16:40:24 <gmaxwell> roconnor: sipa
914 2012-01-04 16:40:32 * roconnor is impressed
915 2012-01-04 16:40:45 <gmaxwell> roconnor: the signature contains the extrabits required to disambiguate the recovery.
916 2012-01-04 16:41:05 <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.
917 2012-01-04 16:41:41 <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.
918 2012-01-04 16:42:02 <gmaxwell> If they don't they compromise their own privacy and that of their trading partners.
919 2012-01-04 16:42:52 booo has joined
920 2012-01-04 16:43:00 <phantomfake> gmaxwell, I was going along those lines, but what I was getting at was that owning an address could prove ownership.
921 2012-01-04 16:43:15 <gmaxwell> Yes, I just demonstrated that above.
922 2012-01-04 16:44:05 <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.
923 2012-01-04 16:45:04 <phantomfake> gmaxwell, They are generated randomly for each wallet using a hashing alg right?
924 2012-01-04 16:46:20 <sipa> gmaxwell: the reason for requiring the address is legacy, actually
925 2012-01-04 16:46:21 <phantomfake> gmaxwell, Could a collision of recipient addresses occur ?
926 2012-01-04 16:46:27 <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)
927 2012-01-04 16:46:50 <gmaxwell> sipa: it kinda sucks. :( also sucks that its first so its not easy to make optional without breaking compatiblity.
928 2012-01-04 16:47:13 <gmaxwell> phantomfake: Yes, though its astronomically unlikely, the addresses are 160 bits long.
929 2012-01-04 16:48:54 <phantomfake> gmaxwell, I haven't visited the wiki in a while, is this still the best place for me to dig into it?
930 2012-01-04 16:49:50 <gavinandresen> no
931 2012-01-04 16:50:06 gp5st has joined
932 2012-01-04 16:50:06 <gavinandresen> wait, yes.
933 2012-01-04 16:50:26 <gavinandresen> (wiki is a pretty good place to find out about bitcoin crypto)
934 2012-01-04 16:50:33 <phantomfake> Hey Gavin!
935 2012-01-04 16:50:46 gp5st has left ()
936 2012-01-04 16:50:52 <gavinandresen> ... although bitcoin.stackexchange.com might be better
937 2012-01-04 16:51:04 <phantomfake> gavinandresen, nice :)
938 2012-01-04 16:54:35 <phantomfake> Is there anyway to maintain a "receiving address" or will the client eventually cycle it out or delete it?
939 2012-01-04 16:54:35 <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.
940 2012-01-04 16:55:21 <phantomfake> The wiki says: ECDSA is a cryptographic algorithm used by Bitcoin to ensure that funds can only be spent by their rightful owners.
941 2012-01-04 16:55:24 <gmaxwell> roconnor: it's true, and I think it should be a recommended practice. Making it required is a little blah though.
942 2012-01-04 16:55:30 <sipa> phantomfake: the client never deletes keys
943 2012-01-04 16:55:44 <roconnor> gmaxwell: I agree, there should be a flag to return the signing address
944 2012-01-04 16:55:50 <gmaxwell> phantomfake: it's still a bad practice to recieve to a single address.
945 2012-01-04 16:55:59 <sipa> and yes, ECDSA and SHA256 are used (and AES-256-CBC for wallet encryption)
946 2012-01-04 16:56:06 <sipa> and RIPEMD160 as well
947 2012-01-04 16:56:14 <roconnor> sipa: and SHA1 in prinicple
948 2012-01-04 16:56:21 <sipa> roconnor: hmm, where?
949 2012-01-04 16:56:25 <roconnor> sipa: OP_SHA1
950 2012-01-04 16:56:25 <phantomfake> gmaxwell, What about creating a wallet for just one purpose?
951 2012-01-04 16:56:32 <sipa> ah, right
952 2012-01-04 16:56:56 <phantomfake> sipa, RIPEMD160 for address, right?
953 2012-01-04 16:57:00 chrisb__ has joined
954 2012-01-04 16:57:03 ahihi2 has quit (Read error: Connection reset by peer)
955 2012-01-04 16:57:09 <sipa> yes, addresses are RIPEMD160(SHA256(pubkey))
956 2012-01-04 16:57:12 <gmaxwell> I thought things like OP_SHA1 were there for zero-trust payments and the like.
957 2012-01-04 16:57:21 <phantomfake> sipa, I see.
958 2012-01-04 16:57:59 <gavinandresen> Anybody willing to proof-read the draft pay-to-script-hash BIP before I send it to genjix?
959 2012-01-04 16:58:00 <gavinandresen> https://gist.github.com/1557931
960 2012-01-04 17:00:56 <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?
961 2012-01-04 17:02:12 dissipate_ has quit (Remote host closed the connection)
962 2012-01-04 17:03:10 <luke-jr_> gavinandresen: better to just re-activate BIP 12
963 2012-01-04 17:04:16 <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.
964 2012-01-04 17:04:36 luke-jr_ is now known as luke-jr
965 2012-01-04 17:04:36 <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
966 2012-01-04 17:04:46 EPiSKiNG- has quit ()
967 2012-01-04 17:04:54 <sipa> (3 standard deviations)
968 2012-01-04 17:05:13 booo has quit (Ping timeout: 240 seconds)
969 2012-01-04 17:05:18 <[Tycho]> I didn't said that.
970 2012-01-04 17:05:48 marf_away has quit (Ping timeout: 252 seconds)
971 2012-01-04 17:06:05 <gavinandresen> They can continue supporting OP_EVAL if they like, it is compatible with the pay-to-script-hash proposal.
972 2012-01-04 17:06:23 <sipa> gavinandresen: so i would require at least 550 to be sure, preferrably more, as there is variation in hashing power too
973 2012-01-04 17:06:54 <gavinandresen> sipa: ok. 550 is a multiple of 11, so I like it.
974 2012-01-04 17:07:03 <sipa> good
975 2012-01-04 17:07:57 * luke-jr facepalms.
976 2012-01-04 17:08:05 <gavinandresen> roconnor: what do you think? The Satoshi client's script-matching algorithm doesn't care which pushdata is used....
977 2012-01-04 17:08:44 <safra> hello
978 2012-01-04 17:08:48 <phantomfake> What exactly does pay-to-script allow you to do?
979 2012-01-04 17:09:09 <sipa> phantomfake: it allows me to give you the hash of a validation script i have, and allow you to pay to it
980 2012-01-04 17:09:31 <safra> i am looking for a PHP programmer, to make a bitcoin gateway
981 2012-01-04 17:09:31 <sipa> phantomfake: requiring me to reveal the script, plus prove that it validates, to use the sent coins
982 2012-01-04 17:09:34 <phantomfake> sipa, I didn't understand the implications of any of that
983 2012-01-04 17:09:41 <luke-jr> phantomfake: it's OP_EVAL, with a magic script template instead of an opcod
984 2012-01-04 17:09:44 <sipa> phantomfake: in practice, it allows a 2-out-of-3 payment for example
985 2012-01-04 17:10:01 <sipa> phantomfake: where i have a script that allows spending if there are 2 signatures from a set of 3
986 2012-01-04 17:10:13 * phantomfake going to be busy hitting google with all this :)
987 2012-01-04 17:10:14 ahihi2 has joined
988 2012-01-04 17:10:16 <sipa> but i don't need to tell you this to allow you to pay
989 2012-01-04 17:10:55 <sipa> luke-jr: most people agree that the new proposal is ugly, but that it is better understood, specified and easier to implement
990 2012-01-04 17:11:16 <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
991 2012-01-04 17:11:36 <luke-jr> sipa: worse understood, and easier to implement *because* it's broken-by-design
992 2012-01-04 17:11:43 <phantomfake> gavinandresen, Thats interesting..
993 2012-01-04 17:12:06 <luke-jr> it replaces Scripts with essentially predefined transaction types
994 2012-01-04 17:12:18 <gmaxwell> luke-jr: please be reasonable.
995 2012-01-04 17:12:26 <luke-jr> gmaxwell: this new thing is NOT reasonable
996 2012-01-04 17:12:34 <gavinandresen> luke-jr: The design is: "How can we move scripts from the scriptPubKey to the scriptSig in a backwards-compatible way?"
997 2012-01-04 17:12:35 <phantomfake> luke-jr, why?
998 2012-01-04 17:12:41 <gmaxwell> Disliking it might be reasonable, but the claim of "predefined transaction types" is just rubbish.
999 2012-01-04 17:12:46 <gavinandresen> luke-jr: ... and I think pay-to-script-hash meets that design in a minimal way.
1000 2012-01-04 17:12:48 <luke-jr> gavinandresen: OP_EVAL did it fine
1001 2012-01-04 17:12:57 <sipa> and there were objections to that
1002 2012-01-04 17:13:04 <gmaxwell> It's specifying a pay-to-script. Thats it. There is still a script, it's provided by the other side.
1003 2012-01-04 17:13:05 <sipa> and people who had those, have less objections now
1004 2012-01-04 17:13:07 <luke-jr> well, there are bigger more valid objections to this
1005 2012-01-04 17:13:11 <gavinandresen> luke-jr: I further think that if I was designing bitcoin from scratch, scriptPubKey would be JUST scriptHash.
1006 2012-01-04 17:13:22 <sipa> gavinandresen: agree
1007 2012-01-04 17:13:25 <gmaxwell> I agree with gavinandresen.
1008 2012-01-04 17:13:47 <gmaxwell> (Or perhaps hashtype + scripthash, but whatever)
1009 2012-01-04 17:14:01 <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
1010 2012-01-04 17:14:22 <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"
1011 2012-01-04 17:14:27 user has joined
1012 2012-01-04 17:14:31 <gmaxwell> sipa: exactly.
1013 2012-01-04 17:15:28 <gavinandresen> luke-jr: And, again, if you like you can continue to support OP_EVAL, it'll play nicely with pay-to-script-hash
1014 2012-01-04 17:15:52 <sipa> and the nicest thing is: one does not lose anything (except a few bytes possibly) by just moving everything to scriptSig now
1015 2012-01-04 17:15:54 <luke-jr> I disagree that outputs should lose scripting
1016 2012-01-04 17:16:22 <gmaxwell> luke-jr: Well, they aren't losing itâ at least not yet. But why do you find that objectionable?
1017 2012-01-04 17:17:05 abragin has quit (Remote host closed the connection)
1018 2012-01-04 17:17:22 abragin has joined
1019 2012-01-04 17:17:22 abragin has quit (Changing host)
1020 2012-01-04 17:17:22 abragin has joined
1021 2012-01-04 17:17:46 <gmaxwell> The output really does still have a script in a pay to scripthash... it's just there in an semi-opaque compressed form.
1022 2012-01-04 17:18:16 btc_novice has joined
1023 2012-01-04 17:19:32 <luke-jr> a special magic script is being defined as "this output is not a script anymore"
1024 2012-01-04 17:19:35 <luke-jr> which is bs
1025 2012-01-04 17:20:04 <gmaxwell> "no! you're bs!"
1026 2012-01-04 17:20:12 <gmaxwell> Come on, please make a better argument than that.
1027 2012-01-04 17:21:15 <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.
1028 2012-01-04 17:22:28 <lianj> "space efficient" - i thought that train is long gone
1029 2012-01-04 17:23:52 <gmaxwell> ...?
1030 2012-01-04 17:24:37 <luke-jr> OP_EVAL extended the scripting capability
1031 2012-01-04 17:24:41 <luke-jr> this nonsense DESTROYS it
1032 2012-01-04 17:24:44 <luke-jr> (on one end)
1033 2012-01-04 17:24:46 baxter has joined
1034 2012-01-04 17:25:39 <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.
1035 2012-01-04 17:25:47 <gmaxwell> luke-jr: they both 'destroy' it equally.
1036 2012-01-04 17:26:14 <gmaxwell> The same people who would advocate accepting/creating only pay-to-scripthash would advocate it however pay-to-scripthash was accomplished.
1037 2012-01-04 17:26:32 <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.
1038 2012-01-04 17:26:51 <luke-jr> pay-to-script-hash describes OP_EVAL
1039 2012-01-04 17:27:25 * sipa kinda agrees that pay-to-script-hash is a too general name
1040 2012-01-04 17:28:02 <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?)
1041 2012-01-04 17:28:04 <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.
1042 2012-01-04 17:28:25 <gmaxwell> gavinandresen: mm is O(1)
1043 2012-01-04 17:28:26 <luke-jr> gavinandresen: where did you read that? merged-mining doesn't use more space for more chains
1044 2012-01-04 17:28:39 <luke-jr> and no, I oppose P2SH, so I won't put it in the coinbase.
1045 2012-01-04 17:28:50 <luke-jr> I will do what I can to prevent its adoption
1046 2012-01-04 17:28:52 <gavinandresen> luke-jr: ok, I don't know nuthin about merged mining....
1047 2012-01-04 17:29:09 <gavinandresen> luke-jr: sigh
1048 2012-01-04 17:29:19 <luke-jr> merged mining uses a merkle tree
1049 2012-01-04 17:29:42 booo has joined
1050 2012-01-04 17:31:07 <gavinandresen> roconnor: I modified the draft BIP to say that 20-byte-hash must be 0x14...
1051 2012-01-04 17:31:14 <luke-jr> I won't oppose an OP_EVAL with P2SH-like semantics.
1052 2012-01-04 17:31:28 <gmaxwell> What does that mean?
1053 2012-01-04 17:31:37 <luke-jr> ie, the script needs to be pushed by 0x14
1054 2012-01-04 17:32:05 <luke-jr> as much as I'd love to concatenate scripts in the future, I can live without it
1055 2012-01-04 17:32:09 <gmaxwell> all this argument over just burning an extra byte in the scriptâ½
1056 2012-01-04 17:32:17 Zarutian has joined
1057 2012-01-04 17:32:21 <gmaxwell> well crap, just add the byte then. jesus.
1058 2012-01-04 17:33:01 <[Tycho]> gavinandresen: why do you think that scripts should be statically analyzed ?
1059 2012-01-04 17:33:14 <luke-jr> gmaxwell: it's more than just burnign a byte
1060 2012-01-04 17:33:39 <gavinandresen> [Tycho]: I think it is better if it is POSSIBLE to statically analyze them.
1061 2012-01-04 17:33:40 <luke-jr> gmaxwell: by keeping it an opcode-based language, you can change the scriptPubKey without losing the OP_EVAL function
1062 2012-01-04 17:33:53 <luke-jr> P2SH basically *mandates* static analysis
1063 2012-01-04 17:34:00 <luke-jr> OP_EVAL *prevents* static analysis
1064 2012-01-04 17:34:12 <luke-jr> I prefer *optional* static analysis, or none at all
1065 2012-01-04 17:34:16 <sipa> [Tycho]: read this: http://sourceforge.net/mailarchive/message.php?msg_id=28616889
1066 2012-01-04 17:34:21 <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
1067 2012-01-04 17:34:25 <[Tycho]> gavinandresen: I think it's even more safe to support runtime limits.
1068 2012-01-04 17:34:43 b4epoche_ has joined
1069 2012-01-04 17:34:54 <gavinandresen> [Tycho]: I agree, runtime limits are important, and I wouldn't suggest getting rid of them. Security in depth is a good idea.
1070 2012-01-04 17:35:30 <luke-jr> gavinandresen: or they can just relay them regardless of sigops
1071 2012-01-04 17:35:39 b4epoche has quit (Ping timeout: 240 seconds)
1072 2012-01-04 17:35:39 b4epoche_ is now known as b4epoche
1073 2012-01-04 17:35:48 <gmaxwell> e.g. you might statically analyize scripts and then punt slow ones to a slow-txn handling cluster.
1074 2012-01-04 17:36:03 <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
1075 2012-01-04 17:36:16 <gmaxwell> luke-jr: "P2SH basically *mandates* static analysis" < this is gibberish
1076 2012-01-04 17:36:29 <sipa> it mandates analyzability
1077 2012-01-04 17:36:30 <gmaxwell> You're not required to analyize anything, you can just run the scripts like normal.
1078 2012-01-04 17:36:36 <gmaxwell> It mandates analyzability. Agreed.
1079 2012-01-04 17:36:48 <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
1080 2012-01-04 17:36:49 <[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 ?
1081 2012-01-04 17:36:58 <gmaxwell> Without mandating analyzability then people who want analyzability can't have it.
1082 2012-01-04 17:37:22 <luke-jr> gmaxwell: no, it mandates that implementors analyze the script
1083 2012-01-04 17:37:30 <sipa> [Tycho]: because that means the verifier can just see "oh, it has too many checksigs, i deny it immediately"
1084 2012-01-04 17:37:31 <luke-jr> it prevents straight "just evaluate it" implementations
1085 2012-01-04 17:37:33 <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?
1086 2012-01-04 17:37:35 <sipa> [Tycho]: which is cheaper
1087 2012-01-04 17:37:43 <gmaxwell> luke-jr: It does not!
1088 2012-01-04 17:37:46 <luke-jr> does
1089 2012-01-04 17:38:01 <gmaxwell> You simply evaluate it if you're not going to analyze it.
1090 2012-01-04 17:38:25 <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.
1091 2012-01-04 17:38:33 <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
1092 2012-01-04 17:39:02 <gavinandresen> [Tycho]: Fewer lines of code and NO changes to the inner EvalScript routine means less possibilty I made yet another stupid mistake
1093 2012-01-04 17:39:10 <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.
1094 2012-01-04 17:39:24 <gmaxwell> sipa: okay, so lets end this argument and add a freeking op_code for this for luke.
1095 2012-01-04 17:39:41 <luke-jr> gmaxwell: P2SH can't be "simply evaluated"
1096 2012-01-04 17:39:44 <sipa> i didn't mind an extra opcode, but some did :)
1097 2012-01-04 17:39:49 <gmaxwell> I did
1098 2012-01-04 17:40:01 <gavinandresen> I don't like adding an extra byte to make luke-jr feel better.
1099 2012-01-04 17:40:16 <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.
1100 2012-01-04 17:40:48 <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.
1101 2012-01-04 17:41:25 <devrandom> I would support adding an OP_NOP1 too
1102 2012-01-04 17:41:47 <gavinandresen> I'd rather go to justmoon's alternative proposal: OP_NOP1 <hash>
1103 2012-01-04 17:41:55 <luke-jr> OP_HASH160 OP_EQUALS OP_HASH160 OP_EQUALS OP_IF OP_POP OP_ENDIF OP_EVAL
1104 2012-01-04 17:42:06 abragin has left ()
1105 2012-01-04 17:42:23 <luke-jr> explain how to do that with your magic P2SH
1106 2012-01-04 17:42:30 <[Tycho]> gmaxwell: then I will assign non-analyzable scripts to that nodes.
1107 2012-01-04 17:43:14 <luke-jr> or better yet
1108 2012-01-04 17:43:24 <[Tycho]> Cleaner ? OP_EVAL looks more clean to me because script is inserted in plain view.
1109 2012-01-04 17:44:12 <luke-jr> OP_HASH160 OP_IF <hash A> OP_ELSE <hash B> OP_ENDIF OP_EQUALS OP_EVAL
1110 2012-01-04 17:44:14 <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
1111 2012-01-04 17:44:52 baxter has quit (Quit: baxter)
1112 2012-01-04 17:44:55 <gmaxwell> luke-jr: thats a point.
1113 2012-01-04 17:45:07 <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.
1114 2012-01-04 17:45:13 <gmaxwell> the p2sh as proposed doesn't allow pay to either or scripthash.
1115 2012-01-04 17:45:41 <gmaxwell> whereas as luke describes it, does.
1116 2012-01-04 17:45:51 pycke has quit ()
1117 2012-01-04 17:47:33 * luke-jr makes note to self that gmaxwell understands better from examples
1118 2012-01-04 17:48:19 <gavinandresen> You can still do "redeem with either this OR that" with P2SH, it just isn't as nice-looking without OP_EVAL.
1119 2012-01-04 17:48:23 <devrandom> couldn't you encode the either/or in the eval-script?
1120 2012-01-04 17:48:30 <gavinandresen> devrandom: exactly
1121 2012-01-04 17:48:40 <gmaxwell> luke-jr: I understand arguments from praticality better than arguments from principle/aesthetic, but I expect most people do too.
1122 2012-01-04 17:49:09 <gmaxwell> gavinandresen: but what if I don't know the eval script?
1123 2012-01-04 17:49:24 <gmaxwell> e.g. my OR is a script burried in a box in case my house burns down.
1124 2012-01-04 17:49:30 booo has quit (Ping timeout: 240 seconds)
1125 2012-01-04 17:49:45 <gmaxwell> I can't update my OR as a I add new eithers in new transactions.
1126 2012-01-04 17:49:46 <gavinandresen> gmaxwell: you managed to save the hash-of-the-or-script but not the script itself?
1127 2012-01-04 17:49:55 <luke-jr> gavinandresen: you can't conceal the other script
1128 2012-01-04 17:50:29 <gmaxwell> oh I see what gavinandresen is saying.
1129 2012-01-04 17:50:52 <gmaxwell> well, it might make the spending payments big.
1130 2012-01-04 17:51:06 <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.
1131 2012-01-04 17:51:10 <luke-jr> ^ from the spec, I don't see any way
1132 2012-01-04 17:51:11 Clipse has joined
1133 2012-01-04 17:51:22 <gmaxwell> Say the orscript is A||B||C||D||E .. having to disclose that every time kinda sucks.
1134 2012-01-04 17:51:23 Acciaio has joined
1135 2012-01-04 17:51:25 Kolky has joined
1136 2012-01-04 17:51:56 <gmaxwell> luke-jr: you pay to H(KEY A OR KEY B) rather than H(KEY A) OR H(KEY B).
1137 2012-01-04 17:52:02 ovidiusoft has quit (Ping timeout: 268 seconds)
1138 2012-01-04 17:52:08 <gavinandresen> luke-jr: Lets say the "this" is a 2-of-3 CHECKMULTISIG. and the "That" is a plain CHECKSIG.
1139 2012-01-04 17:52:14 <devrandom> a question I have - the only function of OP_EVAL / P2SH is for wallet security, right?
1140 2012-01-04 17:52:23 <gmaxwell> devrandom: ... oy, no, far from that.
1141 2012-01-04 17:52:24 <luke-jr> gmaxwell: what if the scripts aren't simple keys?
1142 2012-01-04 17:52:30 <gavinandresen> The <serialized script> for a P2SH would then be something like:
1143 2012-01-04 17:52:47 <luke-jr> devrandom: no
1144 2012-01-04 17:52:51 <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.
1145 2012-01-04 17:53:18 <gavinandresen> DUP <pubkey> CHECKSIG IF OP_1 ELSE 2 <pk1...2...3> 3 CHECKMULTISIG ENDIF
1146 2012-01-04 17:53:33 <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)
1147 2012-01-04 17:53:49 <gavinandresen> The only downside is you have to reveal all the public keys and script logic for both sides of the IF
1148 2012-01-04 17:54:26 <devrandom> so if you have to pass around the eval'ed script ahead of time, OP_EVAL/P2SH doesn't buy you anything
1149 2012-01-04 17:54:28 <gavinandresen> Which IS a shame. I agree OP_EVAL was spiffy, but I also agree with roconnor-- it was spiffy and a little dangerous.
1150 2012-01-04 17:54:39 <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.
1151 2012-01-04 17:54:58 <devrandom> gmaxwell: you are describing wallet security
1152 2012-01-04 17:55:07 <devrandom> (rather than escrow)
1153 2012-01-04 17:55:07 <gavinandresen> devrandom: Hmm? to fund that complicated this-or-that you just need the hash of the script....
1154 2012-01-04 17:55:15 <gmaxwell> devrandom: No. I'm describing pay to trust.
1155 2012-01-04 17:55:22 <luke-jr> devrandom: the point is, random 3rd parties can send to the escrow
1156 2012-01-04 17:56:00 <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.
1157 2012-01-04 17:56:05 <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
1158 2012-01-04 17:56:46 <gmaxwell> devrandom: I've used the word trust multiple times here for a reason. It's a subclass of escrows.
1159 2012-01-04 17:57:29 <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.
1160 2012-01-04 17:57:30 <devrandom> gmaxwell: what would you call something that protects the sender?
1161 2012-01-04 17:58:57 <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.
1162 2012-01-04 17:59:26 <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.
1163 2012-01-04 17:59:47 <devrandom> you'll need to pass around A and B
1164 2012-01-04 18:00:09 <gmaxwell> devrandom: each party tells the other their addresses. Sure.
1165 2012-01-04 18:00:49 <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.
1166 2012-01-04 18:01:07 <gmaxwell> And the bitcoin software is far more costly to maintain that build_escrow.py.
1167 2012-01-04 18:01:13 <gmaxwell> s/that/than/
1168 2012-01-04 18:02:07 <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.
1169 2012-01-04 18:02:51 <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
1170 2012-01-04 18:03:07 <devrandom> it's just a sequence of bytes either way
1171 2012-01-04 18:03:11 <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.
1172 2012-01-04 18:03:20 <gmaxwell> )
1173 2012-01-04 18:03:38 <devrandom> bitcoinj in fact is planning to support passing around of whole txs
1174 2012-01-04 18:03:41 nibor has quit (Ping timeout: 258 seconds)
1175 2012-01-04 18:03:53 <gmaxwell> I think thats super inadvisable.
1176 2012-01-04 18:04:12 <gmaxwell> At least unless its functionally constrainted to the txn that it could generate itself.
1177 2012-01-04 18:04:31 <gmaxwell> Determining all the possible ways of satisfying a script accurately is NP-HARD.
1178 2012-01-04 18:04:59 <gmaxwell> (well, s/a/any/)
1179 2012-01-04 18:05:00 <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
1180 2012-01-04 18:05:05 <luke-jr> gmaxwell: that's probably the same complexity as determining all possible execution paths of software
1181 2012-01-04 18:05:11 <gmaxwell> luke-jr: it is.
1182 2012-01-04 18:05:47 <devrandom> right, you want to make sure that the script is of a form you recognize
1183 2012-01-04 18:06:20 <gmaxwell> Then that has the same expressive power as generating it yourself, and it is less vulnerable to implementation mistakes.
1184 2012-01-04 18:06:34 <devrandom> (sorry if I derailed this discussion)
1185 2012-01-04 18:08:01 <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.
1186 2012-01-04 18:08:35 <luke-jr> it can also be a webapp
1187 2012-01-04 18:08:41 <luke-jr> maybe
1188 2012-01-04 18:08:42 <gmaxwell> (by safely parse, I mean determine all the necessary and sufficient satisfaction criteria accurately)
1189 2012-01-04 18:09:01 <gmaxwell> yes, if its run by a third party then you don't mind that you have to trust it not to lie.
1190 2012-01-04 18:09:03 <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
1191 2012-01-04 18:09:39 <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
1192 2012-01-04 18:09:47 <gmaxwell> devrandom: well, half (e.g. in the A&&B case). But whatever.
1193 2012-01-04 18:10:00 <gmaxwell> Okay, so we were talking past each other there.
1194 2012-01-04 18:10:17 <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.
1195 2012-01-04 18:10:52 <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.
1196 2012-01-04 18:11:12 <devrandom> I see, good point
1197 2012-01-04 18:12:01 <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)
1198 2012-01-04 18:12:30 <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
1199 2012-01-04 18:13:23 <devrandom> aren't spent outputs are also prunable?
1200 2012-01-04 18:14:08 <luke-jr> P2SH might be more acceptable if we decide that Bitcoin 2.0 won't support scriptPubKey anymore.
1201 2012-01-04 18:14:12 <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.
1202 2012-01-04 18:14:22 <luke-jr> but again, that seriously limits what scripts can do
1203 2012-01-04 18:14:40 * luke-jr notes txn spam tends to be unspendable outputs
1204 2012-01-04 18:14:53 <devrandom> I see
1205 2012-01-04 18:15:08 <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.
1206 2012-01-04 18:16:26 <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
1207 2012-01-04 18:17:31 <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.
1208 2012-01-04 18:17:50 <luke-jr> gmaxwell: I've been trying to explain that for days, and I thought you understood with my example today
1209 2012-01-04 18:18:06 <luke-jr> it's impossible to conceal an "alternative" script
1210 2012-01-04 18:18:16 <luke-jr> especially since scripts cannot recurse anymore
1211 2012-01-04 18:20:19 <devrandom> luke-jr: what is the info leakage you are concerned about? is it the form of the script or the key hashes?
1212 2012-01-04 18:20:33 <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.
1213 2012-01-04 18:20:49 <luke-jr> devrandom: if I'm not using <script X> to redeem it, I shouldn't need to publish <script X>
1214 2012-01-04 18:20:55 <gmaxwell> The reason I didn't consider it important is because we can't currently conceal scripts at all.
1215 2012-01-04 18:22:08 rdponticelli has joined
1216 2012-01-04 18:22:35 <luke-jr> gmaxwell: we can, with OP_EVAL :p
1217 2012-01-04 18:23:05 <gmaxwell> devrandom: say that if you die all your money will go to the church. so you make all your addresses have a ||churchscript
1218 2012-01-04 18:23:25 <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.
1219 2012-01-04 18:23:45 <gmaxwell> you write the content of the church script in an encrypted message to them that you add to your will.
1220 2012-01-04 18:24:13 <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.
1221 2012-01-04 18:24:38 <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.
1222 2012-01-04 18:24:57 <gmaxwell> yea.. meh, you're right, in my example you could just send a privkey.
1223 2012-01-04 18:25:00 <devrandom> s/since it's to/since it's easy to/
1224 2012-01-04 18:25:12 pycke has joined
1225 2012-01-04 18:25:18 <gmaxwell> I don't have an example where it's actually all that important to hide the script. But yes, the structure leaks info.
1226 2012-01-04 18:25:52 <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.
1227 2012-01-04 18:27:28 chrisb__ has quit (Quit: Ex-Chat)
1228 2012-01-04 18:28:11 <safra> I am looking for a programmer, for a project, anyone?
1229 2012-01-04 18:28:49 <luke-jr> safra: I suspect you'd better give more details to find the right person
1230 2012-01-04 18:30:21 <safra> PHP programmer :)
1231 2012-01-04 18:30:59 <safra> more details in private..
1232 2012-01-04 18:31:10 osmosis has joined
1233 2012-01-04 18:31:27 <safra> its related to bitcoin gateway
1234 2012-01-04 18:32:59 iocor has quit (Quit: Textual IRC Client: http://www.textualapp.com/)
1235 2012-01-04 18:33:55 darkskiez has quit (Read error: No route to host)
1236 2012-01-04 18:34:23 rdponticelli has quit (Read error: Connection reset by peer)
1237 2012-01-04 18:35:48 <UukGoblin> PHP programmer... sounds like an oxymoron...
1238 2012-01-04 18:36:45 iocor has joined
1239 2012-01-04 18:38:13 <slush> tcatm: bitcoinchart stream for mtgox is down, right?
1240 2012-01-04 18:38:39 ahbritto_ has quit (Quit: Ex-Chat)
1241 2012-01-04 18:38:50 <CIA-100> bitcoin: p2k * rf4a588db9b37 ecoinpool/ (13 files in 6 dirs): More Documentation http://tinyurl.com/6tnuqas
1242 2012-01-04 18:38:50 <UukGoblin> slush, yes
1243 2012-01-04 18:39:38 erle- has joined
1244 2012-01-04 18:40:00 <slush> UukGoblin: what happen on mtgox? Huge spike in volume? I don't see anything significant on clarkmoody
1245 2012-01-04 18:40:15 <UukGoblin> slush, not sure, I know the price went quite up
1246 2012-01-04 18:40:23 <UukGoblin> $5.7 high or sth
1247 2012-01-04 18:40:37 <slush> too bad I sold today at 5.07 :(
1248 2012-01-04 18:40:54 <UukGoblin> socket.io was having issues too, not sure if it still does
1249 2012-01-04 18:41:21 * roconnor often wonders what information people are using to determine their buy and sell orders.
1250 2012-01-04 18:41:38 <UukGoblin> roconnor, don't you get the 'gut feeling'?
1251 2012-01-04 18:42:43 <roconnor> UukGoblin: Normally I esitmate probablitly distributions on events based on research, estimate prices based on those events and run a portfolio optimiser.
1252 2012-01-04 18:42:53 <roconnor> ... that and buying index funds.
1253 2012-01-04 18:43:07 <UukGoblin> roconnor, I.. ugh... right ;-)
1254 2012-01-04 18:43:09 <UukGoblin> good for you!
1255 2012-01-04 18:43:14 <UukGoblin> I wouldn't trust guts either
1256 2012-01-04 18:43:23 <roconnor> I used to use my gut but I lost a lot of fake money that way.
1257 2012-01-04 18:43:51 <roconnor> granted I lost even more money buying index funds :P
1258 2012-01-04 18:44:04 <UukGoblin> what the hell are index funds?
1259 2012-01-04 18:44:34 <roconnor> er sorry, I mean ETFs
1260 2012-01-04 18:44:39 <roconnor> http://en.wikipedia.org/wiki/Exchange-traded_fund
1261 2012-01-04 18:44:46 justmoon has joined
1262 2012-01-04 18:44:59 <roconnor> specifically index ETFs
1263 2012-01-04 18:45:27 <UukGoblin> oh bloody hell
1264 2012-01-04 18:45:35 <UukGoblin> I'm too dumb to understand half the words
1265 2012-01-04 18:46:49 <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
1266 2012-01-04 18:46:54 <Diablo-D3> ;ticker
1267 2012-01-04 18:46:56 <Diablo-D3> ;;ticker
1268 2012-01-04 18:46:56 <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
1269 2012-01-04 18:47:06 <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
1270 2012-01-04 18:47:08 <Diablo-D3> not really
1271 2012-01-04 18:47:18 <Diablo-D3> why try to beat the market when you can OWN the market.
1272 2012-01-04 18:47:29 <roconnor> Diablo-D3: cjdelisle means recently
1273 2012-01-04 18:47:36 <UukGoblin> cjdelisle, I can see what "Most", "an" and "such as the" mean there
1274 2012-01-04 18:47:46 <cjdelisle> :)
1275 2012-01-04 18:47:48 <Diablo-D3> roconnor: who cares then
1276 2012-01-04 18:47:51 <Diablo-D3> thats short term thinking
1277 2012-01-04 18:48:00 <Diablo-D3> lrn2make money slowly, kthx
1278 2012-01-04 18:48:35 <cjdelisle> trouble is when the landlord doesn't accept long term payment of next month's rent ;)
1279 2012-01-04 18:48:54 <Diablo-D3> thats neither here nor there, cjdelisle
1280 2012-01-04 18:49:01 <Diablo-D3> you cant beat the market long term
1281 2012-01-04 18:49:21 <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
1282 2012-01-04 18:49:23 <cjdelisle> that is to say: long term thinking doesn't help if, in the short term, you go broke.
1283 2012-01-04 18:49:25 <Diablo-D3> usually 60/40 split
1284 2012-01-04 18:49:37 <Diablo-D3> cjdelisle: thats STILL neither here nor there
1285 2012-01-04 18:49:49 <Diablo-D3> why are you investing anything but what you've set aside for investing?
1286 2012-01-04 18:50:22 <cjdelisle> I don't invest anything I'm not willing to lose
1287 2012-01-04 18:50:28 <Diablo-D3> exactly.
1288 2012-01-04 18:50:42 <Diablo-D3> even investing in the 3000 some companies that make up the stock market, you can still lose money.
1289 2012-01-04 18:50:45 <roconnor> Diablo-D3: Yep. I buy vanguard ETFs. I'm in Canada so buying Vanguard mutual funds is not easy.
1290 2012-01-04 18:50:59 <Diablo-D3> roconnor: etfs just etf shares of the mutual fund
1291 2012-01-04 18:51:06 <Diablo-D3> its higher cost, but otherwise equivilent
1292 2012-01-04 18:51:14 <Diablo-D3> problem is, you cant use vanguard itself in canada
1293 2012-01-04 18:51:17 <Diablo-D3> which sucks
1294 2012-01-04 18:51:27 <roconnor> yep
1295 2012-01-04 18:51:33 <cjdelisle> too complex for me
1296 2012-01-04 18:51:39 <roconnor> but buying Vanguard ETFs is no so bad.
1297 2012-01-04 18:51:42 <Diablo-D3> vanguard's mission in life is to destroy all fees.
1298 2012-01-04 18:51:42 <cjdelisle> I'm happy losing money in more simple ways.
1299 2012-01-04 18:51:44 <roconnor> *not
1300 2012-01-04 18:51:47 <Diablo-D3> cjdelisle: well thats the thing
1301 2012-01-04 18:51:51 <Diablo-D3> its the most simplest thing ever
1302 2012-01-04 18:51:58 <Diablo-D3> its the true and only fire and forget investment
1303 2012-01-04 18:52:28 <Diablo-D3> you can setup auto-investment of dividends as well
1304 2012-01-04 18:52:42 <Diablo-D3> and vanguard can also painlessly auto-deduct from bank accounts and invest that
1305 2012-01-04 18:52:48 * roconnor can't auto-invest dividends with his broker :(
1306 2012-01-04 18:52:50 <Diablo-D3> if you do it right, you can pay basically nothing in fees to vanguard
1307 2012-01-04 18:53:15 <Diablo-D3> they're the closest you'll ever get to an investment bank acting like a credit union
1308 2012-01-04 18:53:35 <Diablo-D3> they serve their existing customers, all several trillion dollars worth of them.
1309 2012-01-04 18:54:27 <cjdelisle> anything w/ options or stocks in companies whose business model and cash flows I don't understand == spooky
1310 2012-01-04 18:54:44 <Diablo-D3> cjdelisle: except you dont have options, and you dont have singular stocks
1311 2012-01-04 18:54:51 <cjdelisle> yeap
1312 2012-01-04 18:55:02 <Diablo-D3> which is why I recommend what I do to begin with
1313 2012-01-04 18:55:14 <cjdelisle> but 3000 companies I don't understand, not much better IMO
1314 2012-01-04 18:55:17 <cjdelisle> *buy
1315 2012-01-04 18:55:18 <Diablo-D3> cjdelisle: er
1316 2012-01-04 18:55:20 <gmaxwell> roconnor: usually dividend auto-investment ends up making you pay a bunch in transaction fees.
1317 2012-01-04 18:55:26 chrisb__ has joined
1318 2012-01-04 18:55:32 <Diablo-D3> gmaxwell: not at vanguard, though
1319 2012-01-04 18:55:49 <gmaxwell> roconnor: I just sweep up dividends periodically... besides, most etfs are structured in a way that generally minimized dividends.
1320 2012-01-04 18:55:52 <Diablo-D3> cjdelisle: btw, you do realize how many companies are on the US stock market, right?
1321 2012-01-04 18:55:53 <luke-jr> â¦
1322 2012-01-04 18:55:57 <Diablo-D3> cjdelisle: slightly under 4000.
1323 2012-01-04 18:55:59 <luke-jr> vanguard is some kids' trading card game
1324 2012-01-04 18:56:34 <Diablo-D3> luke-jr: vanguard was founded in 1975, which is slightly before you were born.
1325 2012-01-04 18:56:51 <Diablo-D3> it was founded by the guy, jack bogle, who invented the original index fund
1326 2012-01-04 18:56:59 <roconnor> luke-jr: cardfight vanguard?
1327 2012-01-04 18:57:10 <gmaxwell> cjdelisle: when you invest in broad indexes you're just basically betting on the broad market vs the dollar, and upward ratio between the two is pretty stable.
1328 2012-01-04 18:57:17 <roconnor> luke-jr: all major investment banks are named after trading card games
1329 2012-01-04 18:57:26 <roconnor> luke-jr: vanguard, mtgox, etc.
1330 2012-01-04 18:57:27 * cjdelisle != complexity
1331 2012-01-04 18:57:29 <Diablo-D3> yeah what gmaxwell said
1332 2012-01-04 18:57:41 <Diablo-D3> cjdelisle: well thats the thing, this is why you use index funds
1333 2012-01-04 18:57:45 <Diablo-D3> and just invest in EVERYTHING
1334 2012-01-04 18:57:46 <copumpkin> people make a decent argument for cap-weighted index funds being effectively momentum investment
1335 2012-01-04 18:57:58 <Diablo-D3> copumpkin: yeah, and it doesnt work
1336 2012-01-04 18:58:00 <cjdelisle> infinite complexity
1337 2012-01-04 18:58:02 <copumpkin> which is often not what people who like index funds like
1338 2012-01-04 18:58:36 <gmaxwell> Anyone who claims to beat the market is probably just scamming you, even if they don't know that they're scamming you.
1339 2012-01-04 18:58:38 <Diablo-D3> copumpkin: index funds are ALREADY cap weighted
1340 2012-01-04 18:58:48 <Diablo-D3> over weighting them fucks it up
1341 2012-01-04 18:58:51 <copumpkin> Diablo-D3: I know?
1342 2012-01-04 18:58:56 <gmaxwell> Unfortunately the broad selection of funds means that there is lot of uncompensated multiple-comparisons.
1343 2012-01-04 18:59:01 <roconnor> Diablo-D3: I think that is copumpkin's point
1344 2012-01-04 18:59:01 <copumpkin> it depends on the index though, since not all indexes are cap-weighted
1345 2012-01-04 18:59:11 <Diablo-D3> roconnor: Im just agreeing with him
1346 2012-01-04 18:59:15 <roconnor> :)
1347 2012-01-04 18:59:21 <copumpkin> many people got screwed with "safe" index funds during the dot-com boom
1348 2012-01-04 18:59:29 <copumpkin> because the cap gave tech undue weigt
1349 2012-01-04 18:59:31 <copumpkin> weight
1350 2012-01-04 18:59:37 <Diablo-D3> copumpkin: yeah, but you have indexes like msci us broad market index which just lists basically everything
1351 2012-01-04 18:59:41 <copumpkin> yeah
1352 2012-01-04 18:59:52 <Diablo-D3> which is what vanguard's total market index fund follows
1353 2012-01-04 18:59:56 <copumpkin> most people go for S&P 500 anyway
1354 2012-01-04 19:00:04 <Diablo-D3> s&p 500 misses the small cap action
1355 2012-01-04 19:00:07 <copumpkin> yep
1356 2012-01-04 19:00:10 StevenCH2 has joined
1357 2012-01-04 19:00:16 * copumpkin pops a cap in the S&P 500's ass
1358 2012-01-04 19:00:20 <Diablo-D3> the difference between vanguard s&p 500 and vanguard total market is like 2%
1359 2012-01-04 19:00:21 <gmaxwell> copumpkin: interesting point that cap-weight gives over-emphasis to paper money valuation.
1360 2012-01-04 19:00:27 <Diablo-D3> the s&p 500 is the other 98% of total market cap
1361 2012-01-04 19:00:31 <roconnor> Diablo-D3: aren't vanguard's index ETFs cap-weighted?
1362 2012-01-04 19:00:38 <roconnor> e.g. VTI
1363 2012-01-04 19:00:44 <Diablo-D3> roconnor: all their index funds are naturally cap weighted
1364 2012-01-04 19:00:45 <gmaxwell> Yea, VTI is cap-weighed.
1365 2012-01-04 19:00:46 <copumpkin> how did #bitcoin-dev turn into #bitcoin-finance, btw? I wasn't paying attention to where I was talking :P
1366 2012-01-04 19:01:01 <gmaxwell> oops.
1367 2012-01-04 19:01:04 <Diablo-D3> roconnor: stock goes up, vanguard buys more, stock goes down, vanguard sells some
1368 2012-01-04 19:01:13 <roconnor> copumpkin: Er, my fault. I was wondering how people determing buy and sell prices for bitcoin.
1369 2012-01-04 19:01:16 <Diablo-D3> roconnor: they do it usually quarterly unless its shit pants day
1370 2012-01-04 19:01:24 <Diablo-D3> when its shit pants day, they skip the quarter
1371 2012-01-04 19:01:35 <copumpkin> roconnor: I read the tea leaves, and possibly check the ouija board
1372 2012-01-04 19:01:38 <Diablo-D3> (everyone else panic buys/sells, but hey, vanguard is in it for the long term)
1373 2012-01-04 19:02:02 ageis has quit (Quit: http://ageispolis.net)
1374 2012-01-04 19:02:09 <copumpkin> roconnor: that's also how I price my options, incidentally. Works a lot better than BOPM or Black-Scholes
1375 2012-01-04 19:02:23 <Diablo-D3> cjdelisle: but yeah, basically, I can setup an account at vanguard, use e-statements, and then eventually switch to admiral shares, and Im paying little or no fees
1376 2012-01-04 19:02:30 <roconnor> copumpkin: how's that working for you?
1377 2012-01-04 19:02:37 <copumpkin> roconnor: making craptons of money with zero risk
1378 2012-01-04 19:02:39 <copumpkin> you should try it
1379 2012-01-04 19:02:41 <gmaxwell> haha
1380 2012-01-04 19:02:43 <roconnor> lol
1381 2012-01-04 19:02:45 <Diablo-D3> I think iirc an account of at least $25k + e-statements + auto-invest on vanguard funds is zero fees
1382 2012-01-04 19:02:55 <Diablo-D3> and btw, for the record
1383 2012-01-04 19:02:58 <Diablo-D3> for the past, oh, 5+ years
1384 2012-01-04 19:03:03 <Diablo-D3> Ive been trying to beat the market consistently.
1385 2012-01-04 19:03:10 <copumpkin> trying?
1386 2012-01-04 19:03:24 <copumpkin> my ouija board approach actually works
1387 2012-01-04 19:03:30 <Diablo-D3> although I have beaten the market near consistently, I would still use a 60/40 split of v total market + v total bond
1388 2012-01-04 19:03:58 <Diablo-D3> so Im probably one of the few people in here who is qualified to speak on the subject, and even I wont play dice here.
1389 2012-01-04 19:04:04 <roconnor> Diablo-D3: my friend with cash under the bed has also been beating the market over the last 5 years.
1390 2012-01-04 19:04:05 <gmaxwell> Well, I 'beat' the market too, but only because I'm selling my upside by writing far out of the money options against my assets. This has worked super duper well due to market non-performance.
1391 2012-01-04 19:04:26 <roconnor> Diablo-D3: CAD cahs
1392 2012-01-04 19:04:28 <roconnor> *cash
1393 2012-01-04 19:04:29 <Diablo-D3> when someone says "beat the market", they can still lose money and still win
1394 2012-01-04 19:04:35 <Diablo-D3> you just have to lose less than the market.
1395 2012-01-04 19:04:41 <copumpkin> that's why hedge funds go for absolute return!
1396 2012-01-04 19:04:44 <copumpkin> (and often fail)
1397 2012-01-04 19:04:48 <Diablo-D3> copumpkin: bingo
1398 2012-01-04 19:04:58 <Diablo-D3> hedge funds are fucking retarded
1399 2012-01-04 19:05:05 <roconnor> copumpkin: and take down the global economy with them
1400 2012-01-04 19:05:07 <Diablo-D3> the only companies Im interested in are those who have functioning business models
1401 2012-01-04 19:05:09 <copumpkin> roconnor: pfft
1402 2012-01-04 19:05:12 <Diablo-D3> there arent many
1403 2012-01-04 19:05:15 <copumpkin> roconnor: the 2008 crash wasn't caused by hedge fund
1404 2012-01-04 19:05:21 <roconnor> true
1405 2012-01-04 19:05:25 <Diablo-D3> the 2008 was caused by hedge betting, however.
1406 2012-01-04 19:05:27 <copumpkin> it was predicted by a few of the hedge funds
1407 2012-01-04 19:05:36 <gmaxwell> (heck knows why people are willing to pay $2+ for six month options on SPY going up 25%)
1408 2012-01-04 19:05:38 <roconnor> I was thinking Long Term Captial
1409 2012-01-04 19:05:41 <copumpkin> 2008 was caused by the most ridiculous practices ever with mortgage
1410 2012-01-04 19:05:42 <copumpkin> roconnor: oh okay
1411 2012-01-04 19:05:48 <copumpkin> anyone not read the big short?
1412 2012-01-04 19:05:51 <copumpkin> that's a fun book
1413 2012-01-04 19:05:55 <Diablo-D3> banks were hedging bets against their own mortgage assets
1414 2012-01-04 19:05:57 <Diablo-D3> and they won
1415 2012-01-04 19:05:58 <gmaxwell> copumpkin: I read it, yes.
1416 2012-01-04 19:06:01 <Diablo-D3> which means they lost
1417 2012-01-04 19:06:05 <copumpkin> lol
1418 2012-01-04 19:06:07 <Diablo-D3> since they're _morons_
1419 2012-01-04 19:06:10 <copumpkin> mmm
1420 2012-01-04 19:06:18 <copumpkin> roconnor: you see standard chartered is hiring?
1421 2012-01-04 19:06:27 <roconnor> copumpkin: no I didn't
1422 2012-01-04 19:06:46 <safra> is there a PHP developer here ?
1423 2012-01-04 19:06:51 <cjdelisle> My thought is it's better to buy into a few companies which have a real product and non-goofie cash flow and are small enough that you can at least do a cursory check of their books...
1424 2012-01-04 19:06:55 <roconnor> safra: only Haskell developers
1425 2012-01-04 19:07:31 lyspooner has joined
1426 2012-01-04 19:07:54 darkmethod has joined
1427 2012-01-04 19:08:15 larsivi has joined
1428 2012-01-04 19:08:22 <cjdelisle> Then when <insert newest investing tool> turns out to be the same trickery as the last one, you still have your shirt.
1429 2012-01-04 19:09:28 user has quit (Quit: Leaving)
1430 2012-01-04 19:09:30 <copumpkin> roconnor: yeah, they want don to have more of a social life in NY
1431 2012-01-04 19:09:37 <copumpkin> since he's apparently the only haskeller there
1432 2012-01-04 19:09:51 <copumpkin> (all the others are in london or singapore)
1433 2012-01-04 19:10:19 <copumpkin> cjdelisle: some of them actually do work until too many people catch on
1434 2012-01-04 19:10:33 <cjdelisle> :)
1435 2012-01-04 19:13:34 <copumpkin> damn, all the finance went away :(
1436 2012-01-04 19:18:22 <cjdelisle> ^^ 2011 in one phrase
1437 2012-01-04 19:22:37 ageis_ has joined
1438 2012-01-04 19:23:34 <[Tycho]> So how do we find the final decision about OP_EVAL ?
1439 2012-01-04 19:25:26 <helo> dowsing
1440 2012-01-04 19:26:50 <gmaxwell> [Tycho]: I think luke withdraws his objections to the non-op-eval pay-to-script if it gets another, eval like opcode.
1441 2012-01-04 19:27:02 PK has joined
1442 2012-01-04 19:27:09 <gmaxwell> But gavinandresen said that he didn't like the idea of adding a byte to every transaction to satisify only luke.
1443 2012-01-04 19:27:21 <gmaxwell> So I think we need to figure out how other people feel about that extra byte.
1444 2012-01-04 19:27:33 <gmaxwell> Ideally we find something that everyone (or almost everyone) finds acceptable.
1445 2012-01-04 19:27:38 ageis_ is now known as ageis
1446 2012-01-04 19:27:44 <[Tycho]> Which byte ?
1447 2012-01-04 19:29:01 <roconnor> [Tycho]: the BIP 0012 says withdrawn if that helps you.
1448 2012-01-04 19:29:21 <gavinandresen> https://en.bitcoin.it/wiki/BIP_0016 just went up
1449 2012-01-04 19:29:31 phantomfake has quit (Read error: Connection reset by peer)
1450 2012-01-04 19:29:34 <[Tycho]> What was in 0012 ?
1451 2012-01-04 19:29:48 <gmaxwell> an OP_EVAL or whatever, if I don't misunderstand, it's basically a merger of the proposals (BIP_0012 and https://gist.github.com/1557931)
1452 2012-01-04 19:29:49 <gavinandresen> 12 is OP_EVAL
1453 2012-01-04 19:30:07 <gmaxwell> er, url changed: https://en.bitcoin.it/wiki/BIP_0016
1454 2012-01-04 19:30:21 <[Tycho]> Serialized script again :(
1455 2012-01-04 19:30:45 <gmaxwell> By having an additional NOP at the end of 0016 the execution looks like BIP_12 except the origin of the script is constrained.
1456 2012-01-04 19:31:10 <[Tycho]> This 0016 seems completely wrong to me.
1457 2012-01-04 19:31:54 <[Tycho]> Where is the opcode that will decode and run the script ?
1458 2012-01-04 19:32:18 <gmaxwell> Thats luke's objection (please, luke if you're around speak up if I'm incorrect)
1459 2012-01-04 19:33:03 <[Tycho]> The fact that luke thinks the same frightens me a bit.
1460 2012-01-04 19:33:33 <gmaxwell> So I think luke is opposing that unless its changed so that there is an opcode at the end (OP_EVAL) that says 'evaluate it' but unlike BIP_12 the op_eval would be constrained to only evaluate the script provided by the input script.
1461 2012-01-04 19:34:24 <justmoon> gmaxwell: and if we want to add real OP_EVAL? add another opcode? or is that idea upward compatible?
1462 2012-01-04 19:34:51 <gmaxwell> justmoon: it would need to be OP_EVAL2 because upwards compatible requires that you not permit anything that was rejected before.
1463 2012-01-04 19:35:05 <gmaxwell> And this would need to reject 'real' OP_EVAL usage.
1464 2012-01-04 19:35:06 <gavinandresen> [Tycho]: there is already ugliness in the system-- for example, where is the opcode in a normal transaction that clears the "alt stack" between the scriptSig and the scriptPubKey ?
1465 2012-01-04 19:35:37 <[Tycho]> I didn't tried to work with alt stack yet.
1466 2012-01-04 19:35:46 <[Tycho]> But this clearly is a violation.
1467 2012-01-04 19:35:52 <[Tycho]> "This" = 0016
1468 2012-01-04 19:36:07 <[Tycho]> So now I have even two objections.
1469 2012-01-04 19:36:22 <gmaxwell> [Tycho]: as I pointed out to luke beforeâ there are a lot of competing desires here and this needs to be governed by consensus. Settling the conflicting desires will require compromise... 'uglyness' is a cheap cost compared to the other things we could lose in a compromise.
1470 2012-01-04 19:36:31 <gmaxwell> [Tycho]: A violation?
1471 2012-01-04 19:36:36 <[Tycho]> Sorry for not supporting you now, but I hope that some new option may appear.
1472 2012-01-04 19:36:49 <gavinandresen> We had a conversation a while ago-- if I was designing bitcoin from scratch, there would be no scriptPubKey. Instead, you would just specify the script hash.
1473 2012-01-04 19:37:43 <gavinandresen> ... and the script would always be revealed in the scriptSig, when the coins were spent.
1474 2012-01-04 19:38:28 <justmoon> [Tycho]: please don't take this the wrong way, but it's a big difference as to what seems "clean" from a theoretical standpoint vs. what *is" clean if you know how the script interpreter works internally - this new idea saves us a byte on every transaction ever forever and does not require us to change the script interpreter at all
1475 2012-01-04 19:38:42 <justmoon> whereas OP_EVAL required us to split it into EvalScript and EvalScriptInner, etc.
1476 2012-01-04 19:38:43 <[Tycho]> Two things that I don't like now: 1) Lack of the script-decoding-and-execution opcode, 2) Serialized script format.
1477 2012-01-04 19:39:00 <gavinandresen> justmoon: were you the one who suggested OP_X <hash> as an alternative last night?
1478 2012-01-04 19:39:06 <justmoon> gavinandresen: no
1479 2012-01-04 19:39:26 <justmoon> somehow I think it was greg?
1480 2012-01-04 19:39:32 <justmoon> gmaxwell: ?
1481 2012-01-04 19:39:48 <gmaxwell> Wasn't me. And I don't think luke would like that anyways.
1482 2012-01-04 19:40:16 <gmaxwell> I like the current construction most. I don't like wasting the byte and I'm not at all offended by it being 'unclean'.
1483 2012-01-04 19:40:39 <gmaxwell> But my opinion isn't very relevant, and I don't think adding an extra opcode is terrible if it makes more people happy.
1484 2012-01-04 19:40:40 <justmoon> [Tycho]: don't think of the new proposal as a "script" - it's a special value you can put in the scriptPubKey to tell bitcoin "look for the script in the scriptSig"
1485 2012-01-04 19:41:03 <justmoon> that is *cleaner* than adding eval to a non-looping static stack language
1486 2012-01-04 19:41:29 <[Tycho]> justmoon: how can bitcoind "look for the script" if there is no script in scriptSig ?
1487 2012-01-04 19:41:31 <gavinandresen> I was thinking more about that alternative as I ate lunch today-- we could actually save two more bytes if just [20-byte-hash] was a standard scriptPubKey. Interpreted as "always true" by old clients, but interpreted as "the real script is on top of the scriptSig stack" by new clients. It makes me uncomfortable, though....
1488 2012-01-04 19:41:43 <gmaxwell> justmoon: luke pointed out a weakness of that, which is you can't create an either/or output that doesn't reveal the content of both branches when you spend. But I can't come up with a pratical example of why it matters, and those txn would be bad from a space efficiency perspective.
1489 2012-01-04 19:42:13 <justmoon> [Tycho]: the script is unwrapped from the scriptSig before the script interpreter even runs
1490 2012-01-04 19:42:27 <gmaxwell> gavinandresen: yea, then they don't even need to provide the thing that hashes to that value to trick clients.
1491 2012-01-04 19:42:46 <[Tycho]> justmoon: that's not a script, that's a data string that can be potentially deserialized.
1492 2012-01-04 19:42:54 phantomfake has joined
1493 2012-01-04 19:43:03 <justmoon> gmaxwell: I'm aware that this doesn't enable the recursive use case, that's why I'm open to add OP_EVAL later
1494 2012-01-04 19:43:18 <gavinandresen> That is all scripts are-- data strings that are sent across the network
1495 2012-01-04 19:43:21 <justmoon> [Tycho]: yes, for *backwards compatibility*
1496 2012-01-04 19:43:27 <gmaxwell> justmoon: what I'm describing doesn't even need the recursive case.
1497 2012-01-04 19:43:46 <[Tycho]> Open script would look much nicer to me.
1498 2012-01-04 19:44:15 <luke-jr> gmaxwell: it doesn't *have* to be an opcode, but I don't know any other way to make it sane
1499 2012-01-04 19:44:43 <justmoon> gmaxwell: I thought the recursive version was the most efficient
1500 2012-01-04 19:45:19 <gmaxwell> luke-jr: by sane you mean not having any implicit behavior, but the system is _full_ of implicit behavior, you're just drawing a line in some place where you call everything implicit on one side.. but there is no objective basis for the line to be there vs anywhere else.
1501 2012-01-04 19:45:33 <gmaxwell> justmoon: yes, recursive would be more efficient.
1502 2012-01-04 19:45:40 <gmaxwell> but you don't need recursion to make it possible
1503 2012-01-04 19:46:04 <luke-jr> gmaxwell: I mean not special-casing it
1504 2012-01-04 19:46:38 <luke-jr> I can live with BIP 16 iff we decide that scriptPubKey is going away entirely and this format exists only for backward compatibility
1505 2012-01-04 19:47:01 mologie has quit (Ping timeout: 255 seconds)
1506 2012-01-04 19:47:03 <luke-jr> as in, Bitcoin 2.0 will remove the scriptPubKey semantics entirely and only have a script hash
1507 2012-01-04 19:47:11 <gmaxwell> justmoon: e.g. OP_HASH160 OP_EQUALS OP_HASH160 OP_EQUALS OP_IF OP_POP OP_ENDIF OP_EVAL
1508 2012-01-04 19:47:17 <justmoon> luke-jr: I would support that
1509 2012-01-04 19:47:22 <justmoon> gmaxwell: gotcha
1510 2012-01-04 19:47:46 <gmaxwell> sipa, gavinandresen, and I have said that. But â I don't think we're in any position to talk about what bitcoin 2.0 would do with any confidence.
1511 2012-01-04 19:47:48 <justmoon> luke-jr: that's how I think of BIP 16
1512 2012-01-04 19:48:26 <luke-jr> gmaxwell: then there's no harm in doing it as a sane script either :P
1513 2012-01-04 19:49:06 <justmoon> roconnor: I was gonna ask you for a link to your client
1514 2012-01-04 19:49:32 imsaguy2 has quit (Read error: Connection reset by peer)
1515 2012-01-04 19:49:41 <roconnor> justmoon: you need to install darcs first
1516 2012-01-04 19:49:46 <gmaxwell> luke-jr: I added pay-to-scripthash-only to the list here: https://en.bitcoin.it/wiki/Hardfork_Wishlist#Transaction_behavior_changes
1517 2012-01-04 19:49:59 <justmoon> roconnor: is there a way to just look at the source online?
1518 2012-01-04 19:50:08 <roconnor> justmoon: not that I'm aware of
1519 2012-01-04 19:50:10 * roconnor checks
1520 2012-01-04 19:50:25 marf_away has joined
1521 2012-01-04 19:50:43 <roconnor> justmoon: nope
1522 2012-01-04 19:50:58 <justmoon> roconnor: ok, then i'll check it out when i have more time!
1523 2012-01-04 19:51:03 <roconnor> ok
1524 2012-01-04 19:51:43 imsaguy2 has joined
1525 2012-01-04 19:51:43 imsaguy2 has quit (Changing host)
1526 2012-01-04 19:51:44 imsaguy2 has joined
1527 2012-01-04 19:53:22 wutzebaer1 has joined
1528 2012-01-04 19:53:29 PK has quit ()
1529 2012-01-04 19:55:14 mologie has joined
1530 2012-01-04 19:56:16 <wutzebaer1> hi i wrote a bitcoin cpu miner in java, on my pc it can hash 300.000 per second, when i run it on my galaxy it reaches 2700 hashes... why is it 100 times slower? my pc has 2.3GHz the galaxy 1GHz
1531 2012-01-04 19:56:33 random_cat has quit (Ping timeout: 276 seconds)
1532 2012-01-04 19:57:28 <luke-jr> â¦
1533 2012-01-04 19:57:33 <luke-jr> because you're clueless?
1534 2012-01-04 19:57:43 <luke-jr> GHz is not a measure of speed.
1535 2012-01-04 20:06:19 <makomk> Side note: been privately working on Yet Another Bitcoin Clone(tm) that implements *everything* with OP_EVAL (except direct pay-to-pubkey).
1536 2012-01-04 20:07:41 <justmoon> makomk: code or it didn't happen :)
1537 2012-01-04 20:07:41 <gmaxwell> makomk: whats the advantage of pay to pubkey?
1538 2012-01-04 20:07:57 <gmaxwell> I mean, that sounds larger in total size.
1539 2012-01-04 20:08:14 <gmaxwell> Because you can recover the pubkey on the input script side.
1540 2012-01-04 20:08:44 RazielZ has quit (Ping timeout: 248 seconds)
1541 2012-01-04 20:09:32 RazielZ has joined
1542 2012-01-04 20:10:32 <makomk> gmaxwell: don't have key recovery support. Besides, I needed pay-to-pubkey in IsStandard anyway for the inner script.
1543 2012-01-04 20:11:07 <gmaxwell> makomk: oh by bitcoin clone you mean something that uses the bitcoin blockchain.
1544 2012-01-04 20:12:06 <makomk> Nope, it's an altcoin, but key recovery is a bit of a headache to implement at the same time as multi-key transactions.
1545 2012-01-04 20:13:35 datagutt is now known as TheMaynne
1546 2012-01-04 20:13:48 TheMaynne is now known as TheMayne
1547 2012-01-04 20:13:53 TheMayne is now known as Mayne
1548 2012-01-04 20:13:55 <luke-jr> fwiw, CapitalOne are scammers
1549 2012-01-04 20:14:07 <luke-jr> randomly decided to add an annual fee to our credit card with no warning
1550 2012-01-04 20:14:30 paraipan has quit (Remote host closed the connection)
1551 2012-01-04 20:14:32 <kiba> key recovery features
1552 2012-01-04 20:14:35 <kiba> are a security flaw
1553 2012-01-04 20:14:49 <gmaxwell> ...
1554 2012-01-04 20:14:53 <makomk> kiba: not that kind of key recovery.
1555 2012-01-04 20:15:00 <gmaxwell> kiba: You're speaking gibberish because you don't know what I'm talking about.
1556 2012-01-04 20:15:03 <makomk> This recovers the public key from the signature.
1557 2012-01-04 20:15:13 paraipan has joined
1558 2012-01-04 20:15:20 <kiba> um, I just skim, gmaxwell
1559 2012-01-04 20:15:33 <gmaxwell> kiba: your skimming is a conversational flaw. :)
1560 2012-01-04 20:15:34 <justmoon> kiba: bitcoin verifies the correctness of the public key from the hash anyway, this just saves us from writing it out in the scriptSig
1561 2012-01-04 20:15:37 <luke-jr> kiba: 'recovering' the PUBLIC key from the signature
1562 2012-01-04 20:16:06 <gmaxwell> kiba: it just reduces the size of transactions substantially. It doesn't have security implications.
1563 2012-01-04 20:16:16 <kiba> oh kool.
1564 2012-01-04 20:16:37 drazak has joined
1565 2012-01-04 20:16:42 safra has quit (Quit: Leaving)
1566 2012-01-04 20:17:02 <gmaxwell> luke-jr: https://en.bitcoin.it/wiki/Talk:Hardfork_Wishlist < I commented on something you added there
1567 2012-01-04 20:17:06 * kiba doesn't know much about security other than the concept of security theatre
1568 2012-01-04 20:18:18 <justmoon> kiba: we'll have some security theatre next month called "weak verifiability" - it'll only have a short run, but don't miss the performance!
1569 2012-01-04 20:19:06 <luke-jr> gmaxwell: I didn't say it was possible. :P
1570 2012-01-04 20:19:16 ovidiusoft has joined
1571 2012-01-04 20:19:24 <makomk> gmaxwell: ah, that was it actually. Because the address is a hash of a script with OP_EVAL, I couldn't figure out a way to actually save that much space through key recovery. You'd need a seperate hash of the key, and the compressed public key isn't much bigger itself.
1572 2012-01-04 20:19:25 <gmaxwell> luke-jr: yea, I'm not trying to argue with youâ more just wondering how we should handle arguments about these features?
1573 2012-01-04 20:19:51 Mayne has quit (Quit: kthxbai)
1574 2012-01-04 20:20:03 <gmaxwell> makomk: hash of the key is still smaller than the compressed public key itself. ::shrugs::
1575 2012-01-04 20:20:09 datagutt has joined
1576 2012-01-04 20:20:29 <gmaxwell> but okay, makes sense.
1577 2012-01-04 20:22:10 sytse has quit (Read error: Operation timed out)
1578 2012-01-04 20:22:28 luke-jr has quit (Read error: Connection reset by peer)
1579 2012-01-04 20:22:36 luke-jr has joined
1580 2012-01-04 20:24:42 <kiba> hmm, even the TSA use the term "security threatre
1581 2012-01-04 20:24:43 <kiba> "
1582 2012-01-04 20:24:54 <luke-jr> gmaxwell: I didn't say it was viable. :P
1583 2012-01-04 20:30:54 <sipa> gmaxwell: you hilighted me?
1584 2012-01-04 20:31:26 <gmaxwell> sipa: er, only mentioning you created our key recovery code?
1585 2012-01-04 20:31:48 <sipa> 20:44:11 < gmaxwell> sipa, gavinandresen, and I have said that. But â I don't think we're in any position to talk about what bitcoin 2.0 would do with any confidence.
1586 2012-01-04 20:32:16 <gmaxwell> sipa: this was WRT changing to exclusive pay-to-scripthash.
1587 2012-01-04 20:32:32 <sipa> ok
1588 2012-01-04 20:32:32 <luke-jr> sipa: he said you agreed with the concept of replacing scriptPubKey with script-hash alone
1589 2012-01-04 20:32:45 <sipa> yes, i did - if we'd redesign things
1590 2012-01-04 20:32:48 <gmaxwell> luke-jr was saying his objection to BIP_0016 would be reduced if the consensus was that 'future bitcoin' should be exclusively pay to scripthash.
1591 2012-01-04 20:33:13 <sipa> i'm not sure right now, given certain infrastructure that is built around bitcoin
1592 2012-01-04 20:33:20 <luke-jr> sipa: ie, "Bitcoin 2.0" after a block chain fork wouldn't *support* scriptPubKey at all
1593 2012-01-04 20:33:28 <gmaxwell> ::nods::
1594 2012-01-04 20:33:36 <sipa> that's one possibility, and i wouldn't object to it
1595 2012-01-04 20:34:00 <gmaxwell> I added that to the hardfork page. ::shrugs::
1596 2012-01-04 20:34:02 <jgarzik> IMO we should start bitcoin 2.0 right now, at block #0, including all wishlist changes, and announce a freeze 12 months from now
1597 2012-01-04 20:34:16 <jgarzik> parallel streams, for both code and data
1598 2012-01-04 20:34:20 <gavinandresen> I think the notion "payment address == public key == bitcoin user" was a mistake, but a mistake I know I wouldn't have seen before all experience of the last year or two
1599 2012-01-04 20:34:22 <luke-jr> jgarzik: I already made a branch actually
1600 2012-01-04 20:34:29 <luke-jr> jgarzik: it refuses to run except in testnet mode
1601 2012-01-04 20:34:31 <jgarzik> too much pressure for people to stuff crap into bitcoin 1.0
1602 2012-01-04 20:35:44 <luke-jr> well, Bitcoin 2 is (as I imagine it) a few years out still
1603 2012-01-04 20:36:04 <sipa> jgarzik: right now, it's a bit hard to start a bitcoin 2.0 chain, given that we don't have an implementaton yet
1604 2012-01-04 20:36:06 <luke-jr> Bitcoin 1 shouldn't suffer for it
1605 2012-01-04 20:36:17 <sipa> in fact, we hardly agree on what it should be, i think
1606 2012-01-04 20:37:00 <luke-jr> I think replacing scriptPubKey with scriptHash would be unfortunate, but necessary to prevent spam
1607 2012-01-04 20:37:46 sytse has joined
1608 2012-01-04 20:37:50 <jgarzik> sipa: sure we have an implementation, bitcoin/bitcoin.git + a policy that permits breaking changes for the next 12 months
1609 2012-01-04 20:38:09 <luke-jr> â¦
1610 2012-01-04 20:38:09 <sipa> huh?
1611 2012-01-04 20:38:11 <gmaxwell> luke-jr: right, it's .. such a size reducer... and the loss of flexiblity is nearly zero.
1612 2012-01-04 20:38:32 danbri has quit (Ping timeout: 252 seconds)
1613 2012-01-04 20:39:21 <[Tycho]> I don't like "Bitcoin 2.0"...
1614 2012-01-04 20:39:46 <luke-jr> [Tycho]: it's inevitable.
1615 2012-01-04 20:39:53 <sipa> jgarzik: i believe some wishlist features (such as merkle tree for open transactions), require such a change in the block structure, that i don't think it's meaningful to start with bitcoin 1.0 blocks in the same chain
1616 2012-01-04 20:40:02 <luke-jr> [Tycho]: Bitcoin 1 *cannot* scale.
1617 2012-01-04 20:40:20 <gmaxwell> luke-jr: or rather, at some point we'll need a cryptosystem upgrade that can't be done in a compatible way.
1618 2012-01-04 20:40:35 <gmaxwell> luke-jr: so regardless of the arguments about scability there will need to be a breaking change at some point.
1619 2012-01-04 20:40:38 <luke-jr> sipa: how else to retain balances?
1620 2012-01-04 20:40:51 danbri has joined
1621 2012-01-04 20:41:06 <sipa> luke-jr: don't
1622 2012-01-04 20:41:25 <luke-jr> sipa: â¦
1623 2012-01-04 20:41:32 <sipa> i definitely wouldn't retain balances - let the two systems coexist and let the market decide which wins
1624 2012-01-04 20:41:36 <luke-jr> then it's not Bitcoin 2, it's scamcoin :P
1625 2012-01-04 20:41:51 <sipa> bitcoin itself was scamcoin according to the same logic
1626 2012-01-04 20:42:02 <luke-jr> I'm not serious
1627 2012-01-04 20:42:02 <gmaxwell> meh, if there was a bitcoin 2.0 that was broadly supported, you could simply have a cutover point. E.g. where dual mode nodes switched from one to the other.
1628 2012-01-04 20:42:16 <luke-jr> gmaxwell: that's what I'm assuming
1629 2012-01-04 20:42:48 <gmaxwell> E.g. summarizing bitcoin 1.0 using the 2.0 logic, then cutting. New 2.0 only clients would have to trust that summary becaues they wouldn't know how to validate the 1.0 history.
1630 2012-01-04 20:43:02 <sipa> or you could run it first as an alt currency, to experiment with new technology
1631 2012-01-04 20:43:09 <gmaxwell> I agree with that however.
1632 2012-01-04 20:43:23 <gmaxwell> It should be run as an alt currency first, even if the goal is to make a switch.
1633 2012-01-04 20:43:27 <luke-jr> sipa: that's why my branch enforces -testnet
1634 2012-01-04 20:43:29 <sipa> indeed
1635 2012-01-04 20:43:37 <luke-jr> it just refuses to start without -testnet
1636 2012-01-04 20:43:42 <gmaxwell> You can mat the alt currency non-viable by uber-scamcoining it or using weak crypto.
1637 2012-01-04 20:43:56 <gmaxwell> e.g. premine 10 billion newcoins and give them to gavin.
1638 2012-01-04 20:44:00 <gmaxwell> s/mat/make/
1639 2012-01-04 20:44:16 <luke-jr> gmaxwell: or just restart it often? :P
1640 2012-01-04 20:44:17 <sipa> gmaxwell: but still, even intended not as a replacement, you want to use how it is used
1641 2012-01-04 20:44:29 <sipa> *see
1642 2012-01-04 20:44:37 <luke-jr> gmaxwell: I was thinking of having it "first 100 blocks are 1.0, after that follow 2.0 rules", and letting it break the chain whenever 2.0 rules change
1643 2012-01-04 20:44:39 <gmaxwell> That way there isn't risk of newcoin-test gumming up adoption of serious coins, if it does gavin drops his stack of coins on it and blows it up.
1644 2012-01-04 20:44:48 <sipa> making it unusable will make it much less interesting as an experiment
1645 2012-01-04 20:44:51 <luke-jr> gmaxwell: that way, it still has to verify 100 blocks the old way
1646 2012-01-04 20:45:03 <gmaxwell> luke-jr: restarting isn't a good solution because people can ignore the restart.
1647 2012-01-04 20:45:07 lyspooner has quit (Quit: ChatZilla 0.9.88 [Firefox 8.0.1/20111120135848])
1648 2012-01-04 20:45:25 <luke-jr> gmaxwell: not fabricated restarting
1649 2012-01-04 20:45:35 <luke-jr> gmaxwell: but "hey, block 101 isn't valid under our new 2.0 rules"
1650 2012-01-04 20:45:59 <sipa> haha, just a hard limit on the number of blocks
1651 2012-01-04 20:46:01 <kiba> I read the BIP #16
1652 2012-01-04 20:46:06 <gmaxwell> sipa: there is a fine line between being usable for development and being actually usable.
1653 2012-01-04 20:46:06 <kiba> it boggles my mind
1654 2012-01-04 20:46:07 <gavinandresen> I'd really rather not have the private keys to 10 billion coins. I don't want to have to live in a fortified bunker, even for a little while.
1655 2012-01-04 20:46:49 <gmaxwell> gavinandresen: fine, a n-of-m escrow. The point isn't to ever use the damn things, but to have a sword to discourage usage which is 'too serious'.
1656 2012-01-04 20:47:07 <gmaxwell> because if people use it seriously you can't @#$@# develop on top of it because people have skin in opposing changes.
1657 2012-01-04 20:47:20 <sipa> let's use a 3-out-of-2 escrow!
1658 2012-01-04 20:47:26 <gmaxwell> hah
1659 2012-01-04 20:47:50 <gmaxwell> meh, maybe I'm being silly.
1660 2012-01-04 20:47:54 <luke-jr> breaking the protocol as we make 2.0 changes, plus a hard block limit, should be fine
1661 2012-01-04 20:48:18 <gmaxwell> I suppose if this were done some _other_ altchain would crop up using the code but without the sword and people would use that. Can't prevent that.
1662 2012-01-04 20:48:54 <luke-jr> so blocks 0-255 follow Bitcoin 1.0 rules at all times; blocks 256-4095 follow Bitcoin 2.0 rules, which can be changed, and block 4096 triggers the system to reset to block 0 ;)
1663 2012-01-04 20:49:20 <sipa> we ever follow the old rules?
1664 2012-01-04 20:49:23 <sipa> *why
1665 2012-01-04 20:49:34 <sipa> ah, to test for switching over
1666 2012-01-04 20:49:36 <sipa> hmm
1667 2012-01-04 20:49:37 <gmaxwell> to test the transition, assuming this is intended to transition from bitcoin 1.0
1668 2012-01-04 20:49:38 <luke-jr> yes
1669 2012-01-04 20:50:13 <sipa> that would mean a ton of legacy code
1670 2012-01-04 20:50:20 <luke-jr> yep
1671 2012-01-04 20:50:31 Joric has quit ()
1672 2012-01-04 20:50:36 <gmaxwell> Which could be dropped after the switch in a real network for nodes that are willing to trust block 0 of newcoin.
1673 2012-01-04 20:50:39 c_k has quit (Read error: Operation timed out)
1674 2012-01-04 20:50:40 <luke-jr> might be possible to isolate it
1675 2012-01-04 20:50:48 random_cat has joined
1676 2012-01-04 20:51:02 <luke-jr> ie, have the code branch based on block early on in the validation
1677 2012-01-04 20:51:07 <luke-jr> block height*
1678 2012-01-04 20:51:41 <gmaxwell> bluematt has been working on a Cblockchain ... you could basically have Cblockchain and Cblockchain2 and a transition function.
1679 2012-01-04 20:51:45 <luke-jr> https://github.com/luke-jr/bitcoin/commit/ddc09d3d5423aec6104e4976ef1e17c4608cc6a2 <-- bitcoin2 branch as of right now, fwiw
1680 2012-01-04 20:52:09 <gmaxwell> the transition function makes a genesis block for blockchain2 based on the final state of blockchain1.
1681 2012-01-04 20:52:10 <luke-jr> the difficult part of this, IMO, will be constantly rebasing as Bitcoin 1 progresses
1682 2012-01-04 20:52:47 <kiba> I am curious: what will bitcoin2 have?
1683 2012-01-04 20:52:59 <luke-jr> https://en.bitcoin.it/wiki/Hardfork_Wishlist
1684 2012-01-04 20:53:00 <sipa> kiba: whatever the person(s) that implement it, put into it
1685 2012-01-04 20:53:06 <gmaxwell> then new nodes which are blockchain2 only would just trust the hash of the blockchain2 genesis coded into them.
1686 2012-01-04 20:53:34 <luke-jr> gmaxwell: right, it's just a checkpoint after all ;)
1687 2012-01-04 20:54:14 <gmaxwell> Personally I don't think it's worthwhile to even work on this unless there is someone willing to concurrently build a second implementation. The software QA problems in bitcoin1 won't be fixed by just doing it again. We need a process improvement, and I think a second implementation is essential to that.
1688 2012-01-04 20:54:39 <luke-jr> by isolating the Bitcoin1 vs Bitcoin2 code paths early, we make it easier to rebase as Bitcoin1 changes, and easy to strip out Bitcoin1 later
1689 2012-01-04 20:55:20 <luke-jr> gmaxwell: yeah, I wasn't planning on seriously starting on this idea for a few months
1690 2012-01-04 20:55:31 <luke-jr> since Bitcoin 1 still needs a lot of refactoring
1691 2012-01-04 20:55:39 <luke-jr> seems logical to wait until that's done
1692 2012-01-04 20:56:24 <gmaxwell> I'm generally concerned that such an effort is doomed to failure (opposition from users who don't want to upgrade) without a cryptographic motivator (your coins will be stolen!). And the latter isn't on the horizon and probably won't be in the near future.
1693 2012-01-04 20:56:35 <gmaxwell> On the other hand, this whole upgrade becomes harder the bigger bitcoin is. :(
1694 2012-01-04 20:57:39 <luke-jr> gmaxwell: if all the miners switch, everyone else will "have to"
1695 2012-01-04 20:57:51 <Backburn2> by going after the pools, like gavin is doing
1696 2012-01-04 20:57:54 <gmaxwell> no, they won't. They'll just mine and the new difficulty of 10. :)
1697 2012-01-04 20:58:02 <luke-jr> gmaxwell: they won't ever get to diff 10
1698 2012-01-04 20:58:09 <luke-jr> gmaxwell: and if they do, Bitcoin 1 becomes easy to attack
1699 2012-01-04 20:58:20 <gmaxwell> in any case, don't confuse miners and pool.s
1700 2012-01-04 20:58:32 <gmaxwell> We don't know how willing people would be to move pools.
1701 2012-01-04 20:58:52 <luke-jr> we do
1702 2012-01-04 20:58:55 <Backburn2> im a pool op, id be willing if it was a change that was good for the network
1703 2012-01-04 20:59:14 <luke-jr> we know relatively few change pools when they go down
1704 2012-01-04 20:59:30 <gmaxwell> Even though I would almost certantly support bitcoin2 â I suspect that if there were lots of miners that wanted to keep mining bitcoin1 I'd probably be willing to setup a pool for it for selfish reasons. :( (if bitcoin 1 wins, profit for whoever runs luddite pools)
1705 2012-01-04 20:59:55 <luke-jr> hmm
1706 2012-01-04 21:00:05 <Backburn2> gmaxwell: exactly
1707 2012-01-04 21:00:18 <luke-jr> we need to be careful to make it impossible to merged-mine Bitcoin2 on Bitcoin1 ;)
1708 2012-01-04 21:00:35 <Backburn2> lol that was my first thought
1709 2012-01-04 21:00:36 <gmaxwell> It would be, of course.
1710 2012-01-04 21:00:44 <luke-jr> gmaxwell: not if done right
1711 2012-01-04 21:00:54 <[Tycho]> "Increased efficiency for merged mining: restructure the primary header to make the bitcoin specific data non-mandatory. (e.g. the block chain specific stuff would go into second header connected by a header tree), making the primary headers pure timestamps and nonces" - bad perspective...
1712 2012-01-04 21:01:06 <luke-jr> require the proof-of-work based on the chain-merkle-root, and don't allow a parent chain
1713 2012-01-04 21:01:24 <gmaxwell> Well, I'd assume we'd design bitcoin2 so that it makes it easier to merge mine against it. But that wouldn't making it mergeminable against bitcoin1.
1714 2012-01-04 21:01:31 <luke-jr> [Tycho]: just think, we ALMOST got that into Bitcoin1 :P
1715 2012-01-04 21:01:43 <[Tycho]> luke-jr: when ?
1716 2012-01-04 21:01:44 <luke-jr> gmaxwell: right
1717 2012-01-04 21:01:53 <luke-jr> [Tycho]: when Satoshi suggested doing it a year ago
1718 2012-01-04 21:01:59 <gmaxwell> [Tycho]: merged mining is important for security. Because it makes the popularity of the system sufficient but not necessary for security.
1719 2012-01-04 21:02:02 <makomk> luke-jr: that'd break all the existing MM chains.
1720 2012-01-04 21:02:16 <luke-jr> makomk: then Namecoin should prepare for it.
1721 2012-01-04 21:02:17 <gmaxwell> makomk: yes, it would require anyone who wants to stay merged to upgrade.
1722 2012-01-04 21:02:18 <[Tycho]> gmaxwell: what security ? Altchains are not important at all.
1723 2012-01-04 21:02:38 <luke-jr> [Tycho]: parallel alt chains are
1724 2012-01-04 21:02:46 <makomk> How about requiring nBits to be set to something invalid in the parent header?
1725 2012-01-04 21:02:47 <[Tycho]> luke-jr: what for ?
1726 2012-01-04 21:02:58 <gmaxwell> [Tycho]: Today. But hypothetically, what if namecoin grew in popularity while bitcoin lost popularity. We'd still have good security in that case. Thus the sufficient but not necessary part.
1727 2012-01-04 21:02:59 <sipa> makomk: how about increasing the version number?
1728 2012-01-04 21:03:05 <luke-jr> [Tycho]: for non-financial data related directly to Bitcoin
1729 2012-01-04 21:03:20 <[Tycho]> The problem with headers is that it will broke hardware-based mining.
1730 2012-01-04 21:03:28 <makomk> [Tycho]: exactly.
1731 2012-01-04 21:03:29 <luke-jr> [Tycho]: no, it won't.
1732 2012-01-04 21:03:44 <gmaxwell> Yea, it can be made to not break hardware.
1733 2012-01-04 21:03:48 <luke-jr> so long as we do proofs with SHA256(SHA256(80 bytes)), we're fine
1734 2012-01-04 21:03:54 <gmaxwell> What luke-jr says.
1735 2012-01-04 21:04:00 <luke-jr> 80 bytes can be chain-merkle-root plus timestamp plus nonce
1736 2012-01-04 21:04:02 <gmaxwell> well 80 bytes where nonce is in the same position.
1737 2012-01-04 21:04:07 <[Tycho]> luke-jr: and nonce in exact position.
1738 2012-01-04 21:04:14 <makomk> If you're keeping compatibility with hardware, there's not a huge reason not to keep MM compat IMO.
1739 2012-01-04 21:04:22 <[Tycho]> Not sure about nTime, but that may be useful too.
1740 2012-01-04 21:04:22 <luke-jr> 64-bit time, 320-bit nonce
1741 2012-01-04 21:04:34 <gmaxwell> right. What I'd suggest doing is expanding the size of the timestamp and nonce fieldss.. but leaving at least the 32 bits in the same position.
1742 2012-01-04 21:04:36 <luke-jr> [Tycho]: true, time can be same place too
1743 2012-01-04 21:04:41 <gmaxwell> ha exactly what lue size too.
1744 2012-01-04 21:04:46 <gmaxwell> er luke
1745 2012-01-04 21:04:58 <luke-jr> makomk: the current MM design is broken btw
1746 2012-01-04 21:05:09 <gmaxwell> or nonce field is too small for quantum miners if they ever exist.
1747 2012-01-04 21:05:10 <makomk> luke-jr: oh?
1748 2012-01-04 21:05:21 <luke-jr> makomk: the entire parent coinbase needs to be in all the aux chains
1749 2012-01-04 21:05:27 <[Tycho]> Other part of 320 bit nonce should be incremented by software then ?
1750 2012-01-04 21:05:36 <luke-jr> [Tycho]: can be. or pools can use it
1751 2012-01-04 21:05:36 <gmaxwell> [Tycho]: or left zeros.
1752 2012-01-04 21:05:51 <luke-jr> [Tycho]: for example, you have 288 bits to distribute to miners
1753 2012-01-04 21:06:18 <[Tycho]> Hardware compatibility is very important because if bitcoin will continue to grow, difficulty will go up and hardware mining should be the way to go.
1754 2012-01-04 21:06:33 <luke-jr> [Tycho]: so instead of making a new work for every getwork, you just increment your pool-nonce
1755 2012-01-04 21:06:36 <gmaxwell> Yea, this can be done without breaking (sensible) hardware compatibility.
1756 2012-01-04 21:06:59 <gmaxwell> (e.g. assuming the hardware supports the header being any 80 bytes with the nonce in a particular position)
1757 2012-01-04 21:07:14 <[Tycho]> Yes.
1758 2012-01-04 21:07:29 <makomk> luke-jr: yeah. SolidCoin had a similar idea, except I think they forgot to define which nonce was for what >.<
1759 2012-01-04 21:07:45 <luke-jr> makomk: well, there's no need to define that.
1760 2012-01-04 21:07:51 <[Tycho]> How it will be linked to prev/next block data ?
1761 2012-01-04 21:07:54 <luke-jr> makomk: the protocols used should define what the miner is allowed to change
1762 2012-01-04 21:07:56 <gmaxwell> The real change would just be making the root be a merged mining root, instead of being a bitcoin root. Then hanging the bitcoin header off that.
1763 2012-01-04 21:08:03 <luke-jr> [Tycho]: that's in the block headers
1764 2012-01-04 21:08:19 <gmaxwell> yea, the POW header doesn't link in merged mining.
1765 2012-01-04 21:08:29 <[Tycho]> luke-jr: well, it should be interconnected with hashed data somehow.
1766 2012-01-04 21:08:38 <luke-jr> [Tycho]: it is.
1767 2012-01-04 21:08:38 <gmaxwell> [Tycho]: via the merged mining hashtree.
1768 2012-01-04 21:08:46 <makomk> luke-jr: SC forgot to include a way to do that too, unfortunately.
1769 2012-01-04 21:08:48 <gmaxwell> same way the coinbase connects today.
1770 2012-01-04 21:09:03 <gmaxwell> (or the way merged mining connects to the coinbase)
1771 2012-01-04 21:09:23 <gmaxwell> it's just moving the relationship around so that all the merged things are equal peers.
1772 2012-01-04 21:09:24 <[Tycho]> Hope it won't be too perverted to implement in MCUs
1773 2012-01-04 21:09:31 <luke-jr> [Tycho]: you know how you can have 100 transactions in a single block, connected via the merkle-root?
1774 2012-01-04 21:09:38 <[Tycho]> luke-jr: yes.
1775 2012-01-04 21:09:46 <gmaxwell> [Tycho]: I think it would be invisible, you should be sending the midstate to the hardware then just incrementing nonce there.
1776 2012-01-04 21:09:47 <luke-jr> [Tycho]: likewise, you could have 100 block chains in a single proof-of-work
1777 2012-01-04 21:10:11 <luke-jr> gmaxwell: good point: we need to keep the nonce in the post-midstate area probably
1778 2012-01-04 21:10:15 <luke-jr> maybe
1779 2012-01-04 21:10:22 <[Tycho]> gmaxwell: no, this time I wasn't talking about mining.
1780 2012-01-04 21:10:26 <gmaxwell> yes, it needs to be in the same location in the post-midstate.
1781 2012-01-04 21:10:30 <gmaxwell> oh oh.
1782 2012-01-04 21:10:34 <gmaxwell> gotcha.
1783 2012-01-04 21:11:00 marf_away has quit (Read error: Connection reset by peer)
1784 2012-01-04 21:11:04 <[Tycho]> Smart property and other funny objects.
1785 2012-01-04 21:11:21 marf_away has joined
1786 2012-01-04 21:11:45 <luke-jr> how many bytes are hashed into the midstate again?
1787 2012-01-04 21:12:17 <luke-jr> 64?
1788 2012-01-04 21:12:19 <gmaxwell> luke-jr: the new header would just be [four bytes=2][32bytes root hash][44 bytes nonce]
1789 2012-01-04 21:12:20 <[Tycho]> Do we still need to provide midstate ?
1790 2012-01-04 21:12:39 <luke-jr> gmaxwell: no time?
1791 2012-01-04 21:12:48 <luke-jr> [Tycho]: not for long
1792 2012-01-04 21:12:53 <gmaxwell> luke-jr: no, time should be chain specific.
1793 2012-01-04 21:12:56 <luke-jr> [Tycho]: but it's still an optimization miners should do
1794 2012-01-04 21:12:59 <luke-jr> gmaxwell: why?
1795 2012-01-04 21:13:07 <luke-jr> oh
1796 2012-01-04 21:13:09 <luke-jr> for Tonalcoin
1797 2012-01-04 21:13:10 <luke-jr> duh
1798 2012-01-04 21:13:17 <luke-jr> </sarcasm>
1799 2012-01-04 21:13:22 <gmaxwell> luke-jr: because they may have different time requirements.. e.g. some chain where timing was important might require you to be accurate within 30 minutes.
1800 2012-01-04 21:14:06 <gmaxwell> luke-jr: by _convention_ people might write other crap in those 44 bytes, because they don't need it all for nonce, but I don't see any reason to require anything of it.
1801 2012-01-04 21:14:08 <luke-jr> gmaxwell: all the more reason to put it up here
1802 2012-01-04 21:14:25 <luke-jr> gmaxwell: miners need to be able to update time, if it's important
1803 2012-01-04 21:14:59 <gmaxwell> luke-jr: hm? different applications may simply have different requirements. Bitcoin's requirements make sense for it, but e.g. a timestamping service would probably want something else.
1804 2012-01-04 21:15:08 <luke-jr> I'd love to define it in Timtons ;)
1805 2012-01-04 21:15:30 <luke-jr> gmaxwell: nothing can require more specific than "exactly"
1806 2012-01-04 21:18:29 <luke-jr> 4 bytes version (=2), 32 bytes chain-merkle-root, 4 bytes time (Timtons), 40 bytes nonce :D
1807 2012-01-04 21:19:01 <luke-jr> is there any reason to get more precise than Timtons?
1808 2012-01-04 21:19:04 <luke-jr> (about 5 minutes)
1809 2012-01-04 21:19:37 <luke-jr> (if so, the time would need to be moved to the post-midstate area anywayâ¦)
1810 2012-01-04 21:20:27 <luke-jr> 4 bytes version (=2), 32 bytes chain-merkle-root, 4 bytes time (Timtons), 24 bytes extranonce, 8 bytes time (seconds), 8 bytes nonce
1811 2012-01-04 21:20:49 <luke-jr> chains that don't need the accuracy of seconds can use the seconds as nonce too
1812 2012-01-04 21:21:03 <luke-jr> chains that don't care about time can use both time fields as nonce
1813 2012-01-04 21:21:04 <luke-jr> etc
1814 2012-01-04 21:21:20 <luke-jr> ;;monologue
1815 2012-01-04 21:21:20 <gribble> Your current monologue is at least 11 lines long.
1816 2012-01-04 21:23:31 <luke-jr> chains that only care about the day, could even use only 3 bytes for time ;)
1817 2012-01-04 21:28:30 StevenCH2 has quit ()
1818 2012-01-04 21:30:03 <gmaxwell> luke-jr: say, for example, one chain wants exact GPS time, another wants exact celestial time. They can't agree on a single value there.
1819 2012-01-04 21:31:03 bobke has quit (Read error: Operation timed out)
1820 2012-01-04 21:32:07 <gmaxwell> in any case, what I'm describing makes the POW pure and eliminates any field whos interpertation is bblockchain specific.. and as a result there can't be any mutual exclusion.
1821 2012-01-04 21:32:27 bobke has joined
1822 2012-01-04 21:32:46 <gmaxwell> If I were to spec anything I'd spec making a bunch of those nonce bytes zero so the headers can be 'compressed' (but without breaking the 80 byte length for hashing hardware)
1823 2012-01-04 21:33:19 <gmaxwell> we do need to increase the nonce size.. but 64-96 bits would be enough even assuming quantum miners. :)
1824 2012-01-04 21:33:40 <luke-jr> gmaxwell: even assuming collections of miners working off a single aux chain?
1825 2012-01-04 21:33:56 <luke-jr> gmaxwell: the time needs to be in the hashed data, so the miners can increment it on their own
1826 2012-01-04 21:34:00 the_batman has quit (Ping timeout: 248 seconds)
1827 2012-01-04 21:34:21 <gmaxwell> I think so, you have more expirence there. Thats why I said 96 on the upperend though.
1828 2012-01-04 21:34:35 the_batman has joined
1829 2012-01-04 21:34:38 * luke-jr does some math
1830 2012-01-04 21:35:15 <gmaxwell> luke-jr: to also allow for quantum miners you half the halve the number of bits in your calculations
1831 2012-01-04 21:35:27 <luke-jr> yeah, 64-bit is probably good enough
1832 2012-01-04 21:35:47 <luke-jr> gmaxwell: say what?
1833 2012-01-04 21:36:45 <gmaxwell> luke-jr: assuming you had a QC as 'fast' as your regular computer (in terms of operations per second) you get a sqrt() speedup for general nonlinear inversion.
1834 2012-01-04 21:37:10 <gmaxwell> E.g. a 128 bit brute force search takes 2^64 operations.
1835 2012-01-04 21:37:16 <luke-jr> 64-bits can sustain up to 18,446,744 TH/s
1836 2012-01-04 21:37:26 <gmaxwell> (see grover's algorithim)
1837 2012-01-04 21:37:40 <gmaxwell> thats why 256 bith hashes are being adopted. to give 128 bit security against QCs.
1838 2012-01-04 21:38:37 <luke-jr> 4 bytes version (=2), 32 bytes chain-merkle-root, 4 bytes time (Timtons), 24 bytes zero (not enforced), 8 bytes time (seconds), 8 bytes nonce ?
1839 2012-01-04 21:41:42 <[Tycho]> Seems we are going to have lots of versions :)
1840 2012-01-04 21:41:47 datagutt has quit (Quit: Computer has gone to sleep.)
1841 2012-01-04 21:42:09 <[Tycho]> What's "Timtons" ?
1842 2012-01-04 21:44:30 wasabi2 has joined
1843 2012-01-04 21:46:13 b4epoche_ has joined
1844 2012-01-04 21:46:24 wasabi3 has quit (Ping timeout: 276 seconds)
1845 2012-01-04 21:47:07 b4epoche has quit (Ping timeout: 252 seconds)
1846 2012-01-04 21:47:07 b4epoche_ is now known as b4epoche
1847 2012-01-04 21:52:38 <luke-jr> [Tycho]: approximately 5 minutes, exactly 1/256 of a day
1848 2012-01-04 21:52:58 <luke-jr> ie, first 3 bytes are day, last byte is sub-day precision if needed
1849 2012-01-04 21:53:09 <luke-jr> so if all you need is the day, you can ignore the last byte
1850 2012-01-04 21:53:13 <[Tycho]> luke-jr: why store it if it's calculable from seconds ?
1851 2012-01-04 21:54:10 <[Tycho]> I know that hex is funny, but data dedublication is even more cool.
1852 2012-01-04 21:54:19 <luke-jr> [Tycho]: ideally, seconds could be left out
1853 2012-01-04 21:54:34 <[Tycho]> No.
1854 2012-01-04 21:54:35 <luke-jr> [Tycho]: the seconds part is only reserved, in case a chain needs insanely accurate precision
1855 2012-01-04 21:54:38 <luke-jr> Bitcoin etc do not
1856 2012-01-04 21:55:05 <luke-jr> providing the 'seconds' field takes a lot more work for the miner
1857 2012-01-04 21:55:08 <luke-jr> because it changes so often
1858 2012-01-04 21:56:08 <luke-jr> so for Bitcoin, seconds could be ignored and treated like an extended nonce
1859 2012-01-04 21:56:34 <luke-jr> but for some kind of insanely-accurate chain I can't even imagine, it might be required
1860 2012-01-04 22:01:49 <[Tycho]> But miner doesn't have to increment it each second.
1861 2012-01-04 22:02:33 <luke-jr> they do, if seconds are needed.
1862 2012-01-04 22:04:22 p0s has quit (Remote host closed the connection)
1863 2012-01-04 22:04:55 <luke-jr> I suppose 8 bytes time could be 4 bytes for day, and 4 bytes for sub-day resolution
1864 2012-01-04 22:05:19 <luke-jr> so 0.000020116567611694 seconds max resolution
1865 2012-01-04 22:05:34 <luke-jr> and if a chain doesn't need that much, just leave the last bytes/bits null
1866 2012-01-04 22:07:13 <luke-jr> 4 bytes version (=2), 32 bytes chain-merkle-root, 28 bytes zero (not enforced), 8 bytes time (variable resolution), 8 bytes nonce
1867 2012-01-04 22:07:28 <luke-jr> or better still
1868 2012-01-04 22:07:43 <luke-jr> 4 bytes version (=2), 32 bytes chain-merkle-root, 24 bytes zero (not enforced), 8 bytes time (variable resolution), 12 bytes nonce
1869 2012-01-04 22:08:04 <luke-jr> then you have to redo the midstate daily
1870 2012-01-04 22:08:21 <luke-jr> but the merkle root will undoubtedly be invalid more often anyway
1871 2012-01-04 22:08:31 marf_away2 has joined
1872 2012-01-04 22:08:33 <luke-jr> but we only need 12 bytes (=96 bits) nonce anyway
1873 2012-01-04 22:09:43 <luke-jr> otoh, there might be an argument to be made for allowing miners to continue replaicng the old time field without corrupting it
1874 2012-01-04 22:10:07 <luke-jr> in any case, no need to go over this absurd detail level now - the point is, it's possible to do it in a backward-compatible way
1875 2012-01-04 22:10:12 <gmaxwell> luke-jr: thats perhaps an argument for having time in the header.
1876 2012-01-04 22:10:21 <luke-jr> gmaxwell: ?
1877 2012-01-04 22:10:45 marf_away has quit (Read error: Connection reset by peer)
1878 2012-01-04 22:10:47 <luke-jr> the argument for having time in the header, is because otherwise you need to remake the merkle tree every increment
1879 2012-01-04 22:10:57 <luke-jr> and restart the mining process
1880 2012-01-04 22:10:57 <gmaxwell> I've been arguing against having _any_ time in the header all afternoon, but it would need to be there for people to update it it without updating the tree.
1881 2012-01-04 22:11:08 <gmaxwell> luke-jr: the time field could be an _offset_ however.
1882 2012-01-04 22:11:17 <gmaxwell> e.g. how long I've been chewing on this work.
1883 2012-01-04 22:11:30 <luke-jr> could be
1884 2012-01-04 22:11:31 <luke-jr> but why?
1885 2012-01-04 22:11:53 <luke-jr> why not avoid the chains all having redundant times of their own?
1886 2012-01-04 22:12:04 <gmaxwell> to support different notions of time in the chain. which they _will_ have. e.g. bitcoin is bitcoin network time, no reason for namecoin to use bitcoin network time.
1887 2012-01-04 22:12:24 <gmaxwell> because there is no one single source of time.
1888 2012-01-04 22:12:27 <luke-jr> hmm
1889 2012-01-04 22:12:35 darkee has quit (Remote host closed the connection)
1890 2012-01-04 22:12:48 <luke-jr> I suppose you've got a point there
1891 2012-01-04 22:13:00 <luke-jr> in any case, the point is we can do it in a compatible way
1892 2012-01-04 22:13:01 <luke-jr> :p
1893 2012-01-04 22:13:12 <gmaxwell> even if you have an ensemble of cesium clocks, you still need someone to name time 0.
1894 2012-01-04 22:13:28 <gmaxwell> (and set a space time point as a reference)
1895 2012-01-04 22:13:40 darkee has joined
1896 2012-01-04 22:14:12 <luke-jr> hmm
1897 2012-01-04 22:15:05 _Fireball has quit (Quit: HydraIRC -> http://www.hydrairc.com <-)
1898 2012-01-04 22:22:23 marf_away2 is now known as marf_away_away
1899 2012-01-04 22:22:41 marf_away_away is now known as marf_away
1900 2012-01-04 22:25:19 roconnor has quit (Ping timeout: 240 seconds)
1901 2012-01-04 22:25:49 Cablesaurus has joined
1902 2012-01-04 22:25:50 Cablesaurus has quit (Changing host)
1903 2012-01-04 22:25:50 Cablesaurus has joined
1904 2012-01-04 22:27:29 <gmaxwell> ~.
1905 2012-01-04 22:29:32 BlueMatt has joined
1906 2012-01-04 22:29:45 booo has joined
1907 2012-01-04 22:31:48 jacobwg has quit (Quit: Textual IRC Client: http://www.textualapp.com/)
1908 2012-01-04 22:33:59 onelineproof has joined
1909 2012-01-04 22:34:54 rdponticelli has joined
1910 2012-01-04 22:37:19 ovidiusoft has quit (Ping timeout: 240 seconds)
1911 2012-01-04 22:39:54 ovidiusoft has joined
1912 2012-01-04 22:40:54 BlueMatt has quit (Quit: Ex-Chat)
1913 2012-01-04 22:42:25 minimoose has quit (Quit: minimoose)
1914 2012-01-04 22:43:36 kiba has quit (Ping timeout: 244 seconds)
1915 2012-01-04 22:46:17 safra has joined
1916 2012-01-04 22:48:47 <CIA-100> bitcoin: ckolivas * r59c29fc63f86 cgminer/main.c: Use an alternative pool should the donation getwork fail. http://tinyurl.com/7bmy6jm
1917 2012-01-04 22:52:08 theorbtwo has quit (Ping timeout: 240 seconds)
1918 2012-01-04 22:56:08 theorbtwo has joined
1919 2012-01-04 22:57:22 chrisb__ has quit (Quit: Ex-Chat)
1920 2012-01-04 23:06:42 <andrew12> hmm... what happened to TAABL?
1921 2012-01-04 23:08:19 larsivi has quit (Ping timeout: 276 seconds)
1922 2012-01-04 23:08:19 larsivi_ has joined
1923 2012-01-04 23:13:44 freewil has quit (Quit: Leaving)
1924 2012-01-04 23:15:52 rdponticelli has quit (Remote host closed the connection)
1925 2012-01-04 23:22:12 theorb has joined
1926 2012-01-04 23:23:13 <gribble> New news from bitcoinrss: soundrazor opened issue 744 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/744>
1927 2012-01-04 23:23:16 theorbtwo has quit (Ping timeout: 276 seconds)
1928 2012-01-04 23:23:25 theorb is now known as theorbtwo
1929 2012-01-04 23:27:08 oww has quit (Remote host closed the connection)
1930 2012-01-04 23:28:42 safra has quit (Quit: Leaving)
1931 2012-01-04 23:38:49 rdponticelli has joined
1932 2012-01-04 23:42:33 Acciaio has quit (Quit: Ex-Chat)
1933 2012-01-04 23:47:27 freeplay has quit (Quit: Textual IRC Client: http://www.textualapp.com/)
1934 2012-01-04 23:50:42 theorb has joined
1935 2012-01-04 23:51:12 theorbtwo has quit (Ping timeout: 240 seconds)
1936 2012-01-04 23:52:09 da2ce7 has joined
1937 2012-01-04 23:55:20 theorb has quit (Ping timeout: 248 seconds)
1938 2012-01-04 23:55:41 theorbtwo has joined