1 2011-12-27 00:00:34 <roconnor> Oh god, you guys are going forward with that OP_EVAL craziness
2 2011-12-27 00:04:09 Guest92284 has joined
3 2011-12-27 00:04:25 Guest92284 is now known as phantomcircuit
4 2011-12-27 00:04:39 theorb has joined
5 2011-12-27 00:05:55 theorbtwo has quit (Ping timeout: 240 seconds)
6 2011-12-27 00:06:41 <luke-jr> roconnor: â¦
7 2011-12-27 00:07:18 <roconnor> last time I check it wasn't very well though through had unknown security implications and required a big hack to stop infinite loops.
8 2011-12-27 00:09:58 theorb has quit (Ping timeout: 252 seconds)
9 2011-12-27 00:09:59 <luke-jr> then maybe you should bring it up on the ML
10 2011-12-27 00:10:52 Joric has joined
11 2011-12-27 00:11:18 <roconnor> I have nothing more to add than what is already on https://bitcointalk.org/index.php?topic=46538.0;all
12 2011-12-27 00:19:42 theorbtwo has joined
13 2011-12-27 00:21:27 paraipan has quit (Quit: Saliendo)
14 2011-12-27 00:22:00 <roconnor> ugh, and it is so ill defined
15 2011-12-27 00:22:07 <roconnor> only defined by the reference implementation
16 2011-12-27 00:22:12 <roconnor> great
17 2011-12-27 00:23:10 iocor has quit (Quit: Computer has gone to sleep.)
18 2011-12-27 00:23:58 paraipan has joined
19 2011-12-27 00:31:23 <roconnor> if (!EvalScriptInner(stack, subscript, txTo, nIn, nHashType,
20 2011-12-27 00:31:25 <roconnor> pbegincodehash, pendcodehash, nOpCount, nSigOpCount, fStrictOpEval, nRecurseDepth++))
21 2011-12-27 00:31:39 <roconnor> this nRecursionDepth stays incremented after executing an OP_EVAL?
22 2011-12-27 00:31:45 [Tycho] has quit (Remote host closed the connection)
23 2011-12-27 00:32:45 <roconnor> so you cannot have 3 OP_EVAL even if they are not nested?
24 2011-12-27 00:33:30 <luke-jr> roconnor: report a bug, quick
25 2011-12-27 00:33:44 <roconnor> Without a spec nothing is a bug
26 2011-12-27 00:33:55 <roconnor> how can I say it is wrong?
27 2011-12-27 00:34:32 <luke-jr> you can write up a list of "issues" and post to the ML
28 2011-12-27 00:34:36 <luke-jr> and get a response at least
29 2011-12-27 00:34:51 <roconnor> Even if I am able to find an unknown security problem, all they will do is just fix it rather than pause and think, "hmm, maybe we shouldn't rush into this and actually think about what we are doing"
30 2011-12-27 00:34:58 <luke-jr> more relevant though, why would you ever need non-recursing OP_EVALs?
31 2011-12-27 00:35:19 <luke-jr> roconnor: I will support a delay.
32 2011-12-27 00:35:37 <luke-jr> roconnor: I want to see pubkey extraction added in OP_EVAL anyway
33 2011-12-27 00:36:00 <roconnor> luke-jr: heh, as a predominant miner, you have a lot of sway :)
34 2011-12-27 00:36:20 <luke-jr> I think a well-written email laying out many different possible issues, and concluding a delay is needed, would go far.
35 2011-12-27 00:36:35 <luke-jr> in the end, it will likely come down to Tycho's whim
36 2011-12-27 00:36:43 <roconnor> luke-jr: okay, I will look into it
37 2011-12-27 00:36:51 <roconnor> true what you say about Tycho
38 2011-12-27 00:36:57 <luke-jr> maybe CC Tycho and the other big pool owners
39 2011-12-27 00:37:38 sneak has quit (Ping timeout: 252 seconds)
40 2011-12-27 00:37:54 <sipa> roconnor: looks like a bug to me
41 2011-12-27 00:38:08 <luke-jr> roconnor: the sooner the better; 0.6 is planned to be released around that OP_EVAL cutoff date
42 2011-12-27 00:38:23 <sipa> and nonrecursing opeval is useful
43 2011-12-27 00:38:24 <roconnor> maybe if I report the bug at the last minute, it will more likely result in a delay :P
44 2011-12-27 00:38:37 <luke-jr> sipa: any reason you can't just concat the code before a single OP_EVAL?
45 2011-12-27 00:38:42 <roconnor> oh right, I didn't understand what luke-jr meant by a non-recursing OP_EVAL
46 2011-12-27 00:38:44 <luke-jr> roconnor: I doubt it.
47 2011-12-27 00:39:43 <roconnor> sipa: what exception is thrown when a script fails to deserialize? Is it caught by the evaluator?
48 2011-12-27 00:40:00 sneak has joined
49 2011-12-27 00:40:00 sneak has quit (Changing host)
50 2011-12-27 00:40:00 sneak has joined
51 2011-12-27 00:40:21 jacobwg has quit (Quit: Computer has gone to sleep.)
52 2011-12-27 00:40:30 <sipa> roconnor: good question
53 2011-12-27 00:40:52 <sipa> the scripting system is a part of the code i rarely touched
54 2011-12-27 00:41:00 <roconnor> oh okay
55 2011-12-27 00:41:10 * roconnor looks
56 2011-12-27 00:41:23 osmosis has quit (Read error: Operation timed out)
57 2011-12-27 00:44:42 SomeoneWeirdzzz is now known as SomeoneWeird
58 2011-12-27 00:46:21 <sipa> ;;later tell gavinandresen roconnor found that the op_eval implementation does't support more than two op_eval's, even non-recursing. is this intentional?
59 2011-12-27 00:46:21 <gribble> The operation succeeded.
60 2011-12-27 00:46:36 RazielZ has quit (Quit: Leaving)
61 2011-12-27 00:47:31 davout has quit (Remote host closed the connection)
62 2011-12-27 00:47:57 <CIA-100> bitcoin: Con Kolivas * r5e2e2f282d1f cgminer/main.c: Only use GPU management menu item if GPU threads exist. http://tinyurl.com/d65uzgg
63 2011-12-27 00:47:58 <CIA-100> bitcoin: Con Kolivas * r2257b5023a96 cgminer/ (main.c miner.h util.c): Simplify longpoll changeover to just check which pool it should grab its next longpoll from. This should prevent locking hangs and thread cancellation crashes. http://tinyurl.com/ch3bokh
64 2011-12-27 00:48:39 <roconnor> sipa: oh wow, scripts are decoded on the fly
65 2011-12-27 00:49:04 <sipa> yes :(
66 2011-12-27 00:49:05 <roconnor> OP_INVALIDOPCODE is returned when it cannot deserialize
67 2011-12-27 00:49:13 <sipa> ok
68 2011-12-27 00:49:41 <luke-jr> sipa: do you pull anything? :P
69 2011-12-27 00:49:53 <roconnor> I think this is still compatible with what I do since any valid script must process every op code, even scripts using IF THEN ELSE
70 2011-12-27 00:50:53 <gmaxwell> oh boy. that could be pretty gnarly.
71 2011-12-27 00:51:02 <luke-jr> roconnor: you're a developer of another implementation?
72 2011-12-27 00:51:05 <gmaxwell> (I mean getting identical behavior wrt failing cases)
73 2011-12-27 00:51:11 <roconnor> luke-jr: more or less
74 2011-12-27 00:51:12 chrisb__ has quit (Quit: Ex-Chat)
75 2011-12-27 00:51:27 <luke-jr> roconnor: I suspect you have quite a bit of influence on Gavin regarding protocol changes, then
76 2011-12-27 00:51:34 <sipa> luke-jr: rarely
77 2011-12-27 00:51:38 <roconnor> luke-jr: I don't know about that
78 2011-12-27 00:52:08 <luke-jr> roconnor: I seem to recall him asking about other implementor's concerns on protocol changes
79 2011-12-27 00:52:16 <luke-jr> explicitly
80 2011-12-27 00:52:28 <sipa> i'm quite sure what you found is not intentional
81 2011-12-27 00:52:38 <roconnor> sipa: I might have a bug: if I find an unrecoginzed OP_CODE I fail, but I think maybe unrecognized opcodes may just be ignored in bitcoin
82 2011-12-27 00:53:00 <sipa> depends
83 2011-12-27 00:53:08 <roconnor> oh there is a default: return false
84 2011-12-27 00:53:11 cryptoxchange has quit (Read error: Connection reset by peer)
85 2011-12-27 00:53:12 <sipa> op_nopX are ignored
86 2011-12-27 00:53:25 <roconnor> okay, so unknown codes fail
87 2011-12-27 00:53:27 <roconnor> that is good
88 2011-12-27 00:53:31 <sipa> but unknown ones trigger and error, afaik
89 2011-12-27 00:53:38 <gmaxwell> luke-jr: roconnor's work should eventually result in a certifyable implementationâ but perhaps not code anyone (except perhaps miners and observation nodes) will run.
90 2011-12-27 00:54:08 <luke-jr> gmaxwell: I don't see a difference.
91 2011-12-27 00:54:15 <luke-jr> unless it's Ruby
92 2011-12-27 00:54:19 <luke-jr> Ruby should be boycotted
93 2011-12-27 00:54:20 <luke-jr> <.<
94 2011-12-27 00:55:24 squirrel has joined
95 2011-12-27 00:55:27 <gmaxwell> IIRC his work is haskell now, though I hope it will give birth to a COQ version with formal statements about its correctness. :)
96 2011-12-27 00:55:29 <roconnor> I've been trying to think of a clever way of handling if_else_end, but I can't think of anything more clever than what bitcoin does :)
97 2011-12-27 00:55:57 <tower> squirrel: hey, this place
98 2011-12-27 00:56:23 <luke-jr> Haskell is fine
99 2011-12-27 00:56:58 <sipa> without haskell i wouldn't be here :)
100 2011-12-27 00:57:18 osmosis has joined
101 2011-12-27 00:58:19 squirrel has left ()
102 2011-12-27 00:59:57 dan__ has quit (Quit: dan__)
103 2011-12-27 01:00:10 <gmaxwell> I'm hopeful in the future that there is some interface so that miners could test a candidate blocks/transactions against several implementations and throw out stuff that doesn't validate in all of them so that bugs couldn't cause forks.
104 2011-12-27 01:00:38 <luke-jr> gmaxwell: not the right solution :P
105 2011-12-27 01:00:50 <luke-jr> gmaxwell: test every possible block against them all.
106 2011-12-27 01:00:57 dr_win has quit (Remote host closed the connection)
107 2011-12-27 01:01:17 <gmaxwell> Okay, in the land of finite computation we do things a bit differently. ;)
108 2011-12-27 01:01:42 <cjdelisle> hah
109 2011-12-27 01:02:25 dr_win has joined
110 2011-12-27 01:02:30 <TuxBlackEdo> reading you two talk makes me feel like a complete noob
111 2011-12-27 01:02:41 <luke-jr> gmaxwell: quantum computing :D
112 2011-12-27 01:02:45 <luke-jr> gmaxwell: LLVM has it
113 2011-12-27 01:04:14 MimeNarrator_ has joined
114 2011-12-27 01:04:16 MimeNarrator has quit (Ping timeout: 268 seconds)
115 2011-12-27 01:09:20 <roconnor> um, can someone double check with me that post-fix ++ returns the unincremented value
116 2011-12-27 01:09:40 dan__ has joined
117 2011-12-27 01:09:50 <roconnor> and thus the current code doesn't stop arbitrarly deep nestings of OP_EVAL?
118 2011-12-27 01:10:22 <roconnor> though maybe it still stops infinite loops
119 2011-12-27 01:10:39 <roconnor> BBL
120 2011-12-27 01:10:41 <luke-jr> roconnor: yep
121 2011-12-27 01:11:03 <luke-jr> I didn't even think of that one >_<
122 2011-12-27 01:12:15 EPiSKiNG- has quit ()
123 2011-12-27 01:13:43 <cjdelisle> in most things, security issues aren't "real" until they are proven -- by crashing a significant number of nodes
124 2011-12-27 01:14:30 <cjdelisle> sometimes a whole network is brought to the ground and the serucity issue still isn't acknoleged
125 2011-12-27 01:14:38 <cjdelisle> *cough* solidcoin
126 2011-12-27 01:14:54 <gmaxwell> "it's a feature, not a bug"
127 2011-12-27 01:15:26 <cjdelisle> hehe the solidcoin network suicide feature
128 2011-12-27 01:20:56 HaltingState has quit (Ping timeout: 240 seconds)
129 2011-12-27 01:26:51 eoss has joined
130 2011-12-27 01:26:51 eoss has quit (Changing host)
131 2011-12-27 01:26:51 eoss has joined
132 2011-12-27 01:37:47 dissipate has quit (Quit: Leaving)
133 2011-12-27 01:42:17 underscor has quit (Quit: Leaving)
134 2011-12-27 01:59:49 <roconnor> luke-jr: I'm pretty sure it doesn't even stop infinite loops
135 2011-12-27 02:00:05 <roconnor> OP_PUSHDATA {OP_DUP OP_EVAL} OP_DUP OP_EVAL
136 2011-12-27 02:00:21 <roconnor> I conjecture that runs in an infinite loop with the current code
137 2011-12-27 02:00:31 <roconnor> or at least until the call stack explodes
138 2011-12-27 02:02:10 <roconnor> OP_EVAL needs a proper spec and the whole scripting systems needs a spec that bounds the memory and time use before any changes are made
139 2011-12-27 02:02:12 <roconnor> IMHO
140 2011-12-27 02:05:36 <roconnor> luke-jr: it only took me 70 minutes to find a bug....
141 2011-12-27 02:05:39 Diablo-D3 has joined
142 2011-12-27 02:05:45 <roconnor> well, I guess I should prove it is a bug
143 2011-12-27 02:08:33 Rabbit67890 has quit (Quit: Rabbit67890)
144 2011-12-27 02:09:05 wasabi has joined
145 2011-12-27 02:10:57 wasabi1 has quit (Ping timeout: 255 seconds)
146 2011-12-27 02:12:13 underscor has joined
147 2011-12-27 02:19:33 dr_win has quit (Remote host closed the connection)
148 2011-12-27 02:21:16 mcorlett has quit (Ping timeout: 244 seconds)
149 2011-12-27 02:25:08 mcorlett has joined
150 2011-12-27 02:27:33 mcorlett_ has joined
151 2011-12-27 02:28:53 DaQatz has joined
152 2011-12-27 02:29:36 <roconnor> pfft, the OP_EVAL code is already in the HEAD
153 2011-12-27 02:30:18 mcorlett has quit (Ping timeout: 255 seconds)
154 2011-12-27 02:30:28 mcorlett_ is now known as mcorlett
155 2011-12-27 02:30:38 <gmaxwell> roconnor: yes, but there hasn't been a release with it yet.
156 2011-12-27 02:30:40 dan__ has quit (Quit: dan__)
157 2011-12-27 02:30:49 <roconnor> I'll post an issue
158 2011-12-27 02:30:52 <cjdelisle> wait till there's couple hundred nodes running it -- crash them -- then make your case for a slower dev cycle
159 2011-12-27 02:30:55 mcorlett has quit (Changing host)
160 2011-12-27 02:30:55 mcorlett has joined
161 2011-12-27 02:31:03 <roconnor> cjdelisle: I'm tempted by this
162 2011-12-27 02:31:24 <gmaxwell> No need for the adversarial approach.
163 2011-12-27 02:31:41 <roconnor> I'll try the nice approach first
164 2011-12-27 02:31:54 <cjdelisle> it's not like you'll be crashing people who use it for really important stuff or people who don't understand the code, most will be devs and beta testers if you do it early
165 2011-12-27 02:32:05 * cjdelisle is an asshole though
166 2011-12-27 02:33:29 <cjdelisle> and I'm sure I will be greeted with the very same wakeup call in my own project..
167 2011-12-27 02:34:47 b4epoche_ has joined
168 2011-12-27 02:34:52 <rjk2> hehe
169 2011-12-27 02:35:43 b4epoche has quit (Ping timeout: 252 seconds)
170 2011-12-27 02:35:43 b4epoche_ is now known as b4epoche
171 2011-12-27 02:35:55 <luke-jr> roconnor: IMO, the entire scripting system should be revamped, and only the new form allowed inside OP_EVAL
172 2011-12-27 02:36:11 <roconnor> luke-jr: I wouldn't disagree with that
173 2011-12-27 02:36:16 <luke-jr> cjdelisle: no, the dev cycle isn't the problem
174 2011-12-27 02:36:23 <luke-jr> cjdelisle: the review cycle for *protocol* changes is
175 2011-12-27 02:36:37 <luke-jr> the dev cycle is already far too slow
176 2011-12-27 02:37:23 <rjk2> same problem as most projects - lack of many dedicated testers :(
177 2011-12-27 02:37:30 <cjdelisle> indeed, I retract my hastily chosen words
178 2011-12-27 02:37:59 <luke-jr> Bitcoin.org needs to be revamped to present multiple versions of multiple clients
179 2011-12-27 02:38:20 <roconnor> rjk2: testing only shows the presence of bugs, not their absance.
180 2011-12-27 02:38:23 <gmaxwell> presenting _more_ clients doesn't help this at all.
181 2011-12-27 02:38:28 <gmaxwell> In fact, it makes it worse.
182 2011-12-27 02:38:47 <luke-jr> and categorized under "stable for long-term production use", "testing for regular users", and "bleeding edge with new features"
183 2011-12-27 02:38:58 <gmaxwell> Because if _any_ widely used client has a difference in the validation logic you can use it to make nasty forks which can be worse than the mere misbehavior.
184 2011-12-27 02:39:57 <cjdelisle> more clients exposes bugs
185 2011-12-27 02:40:14 <cjdelisle> but if you really don't like bugs, perhaps you rather they not be exposed ;)
186 2011-12-27 02:41:48 <luke-jr> long-term production should be rolling out 0.4.x now IMO
187 2011-12-27 02:42:20 <gmaxwell> cjdelisle: There are multiple kinds of bugs.
188 2011-12-27 02:42:50 <gmaxwell> cjdelisle: In particular, there are places in bitcoin (block validation) where any _difference_ in behavior can be fatal, even if any of the different ways would be perfectly fine on their own.
189 2011-12-27 02:42:51 rasengan[busy] is now known as rasengan
190 2011-12-27 02:44:04 <cjdelisle> /nod
191 2011-12-27 02:46:36 <roconnor> https://github.com/bitcoin/bitcoin/issues/729
192 2011-12-27 02:46:38 <roconnor> complete with rant
193 2011-12-27 02:49:58 <luke-jr> roconnor: that's not the mailing list
194 2011-12-27 02:50:17 <roconnor> I'm not getting involved in any mailing list
195 2011-12-27 02:50:23 <sipa> still it will be seen
196 2011-12-27 02:50:48 <roconnor> I don't really want to be involved in the development of the bitcoin client
197 2011-12-27 02:51:00 <luke-jr> roconnor: the mailing list is not for any specific client.
198 2011-12-27 02:51:48 amiller has quit (Excess Flood)
199 2011-12-27 02:52:38 amiller has joined
200 2011-12-27 02:54:09 <roconnor> luke-jr: I'll think about it
201 2011-12-27 03:13:26 m00p has quit (Ping timeout: 240 seconds)
202 2011-12-27 03:16:46 eoss has quit (Remote host closed the connection)
203 2011-12-27 03:18:28 TheSeven has quit (Read error: Operation timed out)
204 2011-12-27 03:19:08 TheSeven has joined
205 2011-12-27 03:23:52 <roconnor> Ideally you'd be able to determine (a resonable bound on) the runtime of a script before evaluating it; OP_EVAL pretty much destroys this property.
206 2011-12-27 03:25:08 <gmaxwell> roconnor: it doesn't if its invocation is limited.
207 2011-12-27 03:25:28 <gmaxwell> it's the same thing as bounding a runtime on a language with finite recursion. (er because thats what it is)
208 2011-12-27 03:26:21 <roconnor> yes, but you won't get a resonable estimate of, say, the number of CHECKSIGS because the values passed to OP_EVAL can be computed by arithmetic operations.
209 2011-12-27 03:26:34 <roconnor> as it stands you can simply count them right now
210 2011-12-27 03:27:03 <roconnor> and even with OP_IF you can get a resonable count of the maximum number of CHECKSIGS by enumerating paths.
211 2011-12-27 03:27:07 <roconnor> (If you wanted)
212 2011-12-27 03:27:15 <gmaxwell> oh. bleh. well you can still terminate if it gets too big.
213 2011-12-27 03:28:09 nhodges has quit (Remote host closed the connection)
214 2011-12-27 03:28:16 m00p has joined
215 2011-12-27 03:28:16 kobier has quit (Read error: Connection reset by peer)
216 2011-12-27 03:28:16 terrytibbs has quit (Remote host closed the connection)
217 2011-12-27 03:28:17 <roconnor> I'm sure miners would appreciate knowing before execution
218 2011-12-27 03:28:23 <roconnor> we'll I guess I'm not sure
219 2011-12-27 03:30:51 nhodges has joined
220 2011-12-27 03:30:54 <gmaxwell> I agree that its a good goal, but .. I'm not sure it matters. It does matter that complexity is roughly proportional to size.. but I think you can ignore checksig for that purpose.
221 2011-12-27 03:33:32 terrytibbs has joined
222 2011-12-27 03:40:56 HaltingState has joined
223 2011-12-27 03:40:56 HaltingState has quit (Changing host)
224 2011-12-27 03:40:56 HaltingState has joined
225 2011-12-27 03:42:13 dissipate has joined
226 2011-12-27 03:42:14 dissipate has quit (Changing host)
227 2011-12-27 03:42:14 dissipate has joined
228 2011-12-27 03:50:56 dissipate has quit (Ping timeout: 240 seconds)
229 2011-12-27 03:54:00 datagutt has joined
230 2011-12-27 03:54:06 luke-jr has quit (Read error: Connection reset by peer)
231 2011-12-27 03:55:58 sacredchao has quit (Remote host closed the connection)
232 2011-12-27 03:56:44 sacredchao has joined
233 2011-12-27 03:57:13 luke-jr has joined
234 2011-12-27 03:57:29 luke-jr has joined
235 2011-12-27 04:04:54 rasengan has quit (Quit: leaving)
236 2011-12-27 04:08:04 <CIA-100> bitcoin: Con Kolivas * r9f41f2f34184 cgminer/main.c: Try to align device outputs in curses output. http://luke.dashjr.org/programs/bitcoin/w/cpuminer/cgminer.git/commitdiff/9f41f2f34184afce1ba8c9616a9d6aeb45da41fa
237 2011-12-27 04:11:07 RobinPKR_ has joined
238 2011-12-27 04:12:36 RobinPKR has quit (Ping timeout: 240 seconds)
239 2011-12-27 04:12:37 RobinPKR_ is now known as RobinPKR
240 2011-12-27 04:30:52 kobier has joined
241 2011-12-27 04:35:37 DontMindMe2 has joined
242 2011-12-27 04:35:58 DontMindMe has quit (Ping timeout: 252 seconds)
243 2011-12-27 04:37:58 <CIA-100> bitcoin: Con Kolivas * r17ea91aef598 cgminer/README: Update README. http://tinyurl.com/csr8zay
244 2011-12-27 04:49:33 parus has quit (Ping timeout: 248 seconds)
245 2011-12-27 04:50:19 parus has joined
246 2011-12-27 04:51:09 amiller has quit (Excess Flood)
247 2011-12-27 04:52:17 amiller has joined
248 2011-12-27 04:56:37 luke-jr has quit (Read error: Connection reset by peer)
249 2011-12-27 04:56:37 luke-jr has quit (otg!~luke-jr@2001:470:5:265:222:4dff:fe50:4c49|Read error: Connection reset by peer)
250 2011-12-27 05:16:32 mcorlett has quit (Remote host closed the connection)
251 2011-12-27 05:18:21 cloudbank has quit (Ping timeout: 268 seconds)
252 2011-12-27 05:18:53 luke-jr has joined
253 2011-12-27 05:23:56 recurrence has joined
254 2011-12-27 05:26:44 mcorlett has joined
255 2011-12-27 05:29:19 Joric has quit ()
256 2011-12-27 05:33:28 WakiMiko_ has joined
257 2011-12-27 05:37:10 WakiMiko has quit (Ping timeout: 276 seconds)
258 2011-12-27 05:37:59 <CIA-100> bitcoin: Con Kolivas * r1d0730a85963 cgminer/NEWS: Update NEWS. http://tinyurl.com/bvwc6ok
259 2011-12-27 05:38:00 <CIA-100> bitcoin: Con Kolivas * r4f879b42864c cgminer/configure.ac: Bump version to 2.1.0. http://tinyurl.com/bpp7slj
260 2011-12-27 05:40:01 dissipate has joined
261 2011-12-27 05:42:00 mcorlett has quit (Quit: ChatZilla 0.9.88 [Firefox 8.0/20111115183813])
262 2011-12-27 05:42:14 mcorlett has joined
263 2011-12-27 05:42:32 recurrence has left ("Textual IRC Client: http://www.textualapp.com/")
264 2011-12-27 05:49:10 TheSeven has quit (Disconnected by services)
265 2011-12-27 05:49:22 [7] has joined
266 2011-12-27 05:56:17 Sedra- has joined
267 2011-12-27 05:57:43 Sedra has quit (Remote host closed the connection)
268 2011-12-27 06:10:53 wasabi1 has joined
269 2011-12-27 06:12:26 wasabi has quit (Ping timeout: 240 seconds)
270 2011-12-27 06:21:20 BlueMatt has joined
271 2011-12-27 06:37:03 <roconnor> Ugh, even if OP_VERIF or OP_VERNOTIF occurs in an unexecuted IF_ELSE_END branch the transaction is invalid.
272 2011-12-27 06:37:37 <roconnor> but if other reserved words are occur in an unexecuted IF_ELSE_END branch then the transaction is not invalidated
273 2011-12-27 06:46:27 b4epoche has quit (Read error: Operation timed out)
274 2011-12-27 06:46:33 b4epoche has joined
275 2011-12-27 06:47:18 <nanotube> it appears that bitcoin-qt client shows the datetime of the transaction as the time it was first seen by the client, rather than the timestamp in the actual transaction
276 2011-12-27 06:48:15 <roconnor> OP_IFDUP is bizarre
277 2011-12-27 06:48:16 <nanotube> (i just updated my blockchain from the past three days or so... and have a couple transactions with 400-some and 500-some confirmations, dating as of an hour ago (apparently when client first saw them)
278 2011-12-27 06:48:23 <nanotube> can anyone confirm or deny this behavior?
279 2011-12-27 06:48:55 <gmaxwell> nanotube: thats the behavior as I understand it, yes.
280 2011-12-27 06:49:16 <nanotube> gmaxwell: iirc, the old wx client used to show actual tx datetime?
281 2011-12-27 06:49:28 <nanotube> at any rate, this seems to me undesirable behavior...
282 2011-12-27 06:50:06 <gmaxwell> nanotube: it's the only time you can really trust. ... I don't know what the old wx behavior was. You're not the first to comment on this, but I think you're the first who I've seen say it changed.
283 2011-12-27 06:50:16 <nanotube> client should, imo, either show timestamp on the tx, or show timestamp when it first saw it AND timestamp of the tx.
284 2011-12-27 06:50:32 <BlueMatt> nanotube: tell wumpus to fix it :)
285 2011-12-27 06:50:52 <nanotube> gmaxwell: well, i can't be sure what it was in the wx client at this moment, just 'iirc' :)
286 2011-12-27 06:51:06 <nanotube> wumpus: ^ fix it :)
287 2011-12-27 06:51:12 <nanotube> BlueMatt: done :D
288 2011-12-27 06:51:50 <nanotube> gmaxwell: it's fine for unconfirmed tx flying about... but when catching up on the blockchain... it is a little useless to show 'time first seen' on transactions.
289 2011-12-27 06:51:55 <BlueMatt> (its nice that wumpus is an official developer, that way we can tell him to fix things instead of doing it ourselves :)
290 2011-12-27 06:52:15 <nanotube> (consider, if deleting a blockchain and refetching it, all your tx will show the timestamp of "today" which is useless)
291 2011-12-27 06:52:23 <BlueMatt> random poll: (word :) or (word :) ) or (word :))
292 2011-12-27 06:52:35 <nanotube> BlueMatt: (word :) )
293 2011-12-27 06:52:48 <nanotube> sometimes the latter. but never the first. :)
294 2011-12-27 06:53:13 <gmaxwell> it's too bad that some many blocks are horribly mistimed now.
295 2011-12-27 06:53:43 <BlueMatt> is that a mainline client or a miners with bad clocks thing?
296 2011-12-27 06:53:44 <BlueMatt> or timing attack thing?
297 2011-12-27 06:53:55 <nanotube> BlueMatt: probably rolling ntime thing for miners
298 2011-12-27 06:54:02 <gmaxwell> what nanotube said.
299 2011-12-27 06:54:04 <BlueMatt> mmm
300 2011-12-27 06:54:11 <BlueMatt> ah, that makes sense
301 2011-12-27 06:54:12 <gmaxwell> Probably a little bit of miners with bad clocks too. Not an attack.
302 2011-12-27 06:54:36 <BlueMatt> yea, thought so but I cant say Im farmiliar with the bitcoin timing code that well...
303 2011-12-27 06:54:44 <gmaxwell> It's kinda dumb.
304 2011-12-27 06:54:57 <BlueMatt> (well I guess Im not that familiar with many specific bitcoin workings, but whatever...)
305 2011-12-27 06:55:03 <gmaxwell> You learn offsets from your neighbors which you never forget, and apply the median of those as a correction.
306 2011-12-27 06:55:14 <BlueMatt> oh, fun
307 2011-12-27 06:55:49 <gmaxwell> if your clock starts of stupid but slews correct (e.g. bitcoind and ntp starting at the same time), the correction will be screwing up your time.
308 2011-12-27 06:57:03 <BlueMatt> oh, even more fun
309 2011-12-27 06:57:31 <nanotube> gmaxwell: file a github issue :)
310 2011-12-27 06:58:05 sacarlson has quit (Ping timeout: 240 seconds)
311 2011-12-27 06:58:22 <BlueMatt> nanotube: heh, like anyone is gonna spend the time to write a fix...
312 2011-12-27 06:58:51 <gmaxwell> well, my fix is to just use NTP locally when you know its correct and ignore network time.
313 2011-12-27 06:59:05 <gmaxwell> Some other p2p software calls NTP directly to ask it if it thinks its in sync.
314 2011-12-27 06:59:36 <BlueMatt> agreed...
315 2011-12-27 06:59:37 <gmaxwell> (e.g. gtk-gnutella does this)
316 2011-12-27 07:00:42 <gmaxwell> and high value sites should really have good ntp setups (e.g. a local gps clockâ $100-$200 on ebay. :) ) but ::shrugs::
317 2011-12-27 07:01:02 <gmaxwell> I think it's pretty typical that my home network is more securely configured than bit bitcoin ecommerce sites. :)
318 2011-12-27 07:01:04 <nanotube> gmaxwell: why not just make peer-offsets forgettable? (i.e., refresh at regular intervals?)
319 2011-12-27 07:01:43 <nanotube> that may be a less draconian change
320 2011-12-27 07:01:45 * luke-jr chuckles at BlueMatt's reply/comment
321 2011-12-27 07:02:15 <luke-jr> nanotube: transactions don't have timestamps
322 2011-12-27 07:02:19 <BlueMatt> luke-jr: hey, you know its true...
323 2011-12-27 07:02:29 bobke has quit (Ping timeout: 240 seconds)
324 2011-12-27 07:02:30 <gmaxwell> luke-jr: but blocks do
325 2011-12-27 07:02:40 <gmaxwell> sadly they are often pretty wrong
326 2011-12-27 07:02:53 <luke-jr> BlueMatt: actually, I don't see any follow option
327 2011-12-27 07:03:01 <luke-jr> BlueMatt: nor know of any decent RSS reader :P
328 2011-12-27 07:03:08 <gmaxwell> nanotube: that would help, but might somehwhat increase the vulnerability to e.g. the time splitting attack so it should be considered carefully.
329 2011-12-27 07:03:08 <nanotube> luke-jr: well yea i mean the block that it's in. i'd rather see the timestamp of the block, than the timestamp of when i saw it, because when i saw it can be dramatically wrong, while block timestamp can be only somewhat wrong.
330 2011-12-27 07:03:16 * BlueMatt uses google reader, not that its great, but it works
331 2011-12-27 07:03:31 <luke-jr> nanotube: I'd rather see the timestamp I first saw it. :P
332 2011-12-27 07:03:39 <gmaxwell> fight fight
333 2011-12-27 07:03:40 <BlueMatt> luke-jr: you get a "personal feed" which has all of your subscriptions on github
334 2011-12-27 07:03:53 <luke-jr> nanotube: actually, there's a thread on the dev forum where I posted ideal behaviour IMO
335 2011-12-27 07:04:00 <BlueMatt> its https://github.com/user.private.atom?token=unique token to make it private(ish)
336 2011-12-27 07:04:08 <nanotube> luke-jr: and when you dump the blockchain and refetch it... you'd rather see all your tx show up as being from today?
337 2011-12-27 07:04:19 <luke-jr> nanotube: no
338 2011-12-27 07:04:26 <BlueMatt> luke-jr: there has been discussion of timing upgrades over and over, but it hasnt happened (as always seems to happen in bitcoin...)
339 2011-12-27 07:04:34 <luke-jr> nanotube: AIUI, transactions involving you are saved in wallet.dat too ;p
340 2011-12-27 07:04:48 <luke-jr> BlueMatt: ?
341 2011-12-27 07:04:53 bobke has joined
342 2011-12-27 07:05:02 <BlueMatt> luke-jr: plenty of talk, not enough code
343 2011-12-27 07:05:34 <nanotube> luke-jr: well, wasn't sure if the timestamp is 'refreshed' when you reget the blockchain. heh.
344 2011-12-27 07:05:49 <luke-jr> nanotube: anyhow, I think my proposed solution works for everyone
345 2011-12-27 07:05:57 <BlueMatt> linky?
346 2011-12-27 07:05:59 <nanotube> luke-jr: linky?
347 2011-12-27 07:05:59 <BlueMatt> code?
348 2011-12-27 07:06:01 <nanotube> heh
349 2011-12-27 07:06:56 <luke-jr> https://bitcointalk.org/index.php?topic=54527.0
350 2011-12-27 07:13:00 <CIA-100> bitcoin: Con Kolivas * r4c1c825084c6 cgminer/README: Fix typos courtesy of Steve Brecher. http://tinyurl.com/buf3j3n
351 2011-12-27 07:13:13 <nanotube> ic, interesting. not sure i'm happy with "i send a tx, while not being up to date on the blockchain, then download some old blocks... and any tx to me in those get a timestamp that must be >= the tx i just sent" bit
352 2011-12-27 07:13:26 <nanotube> but i understand the desirability of avoiding listtransactions reshuffling....
353 2011-12-27 07:18:37 DontMindMe2 has quit (Ping timeout: 240 seconds)
354 2011-12-27 07:33:09 dissipate has quit (Read error: Operation timed out)
355 2011-12-27 07:46:37 dr_win has joined
356 2011-12-27 07:47:02 bobke has quit (Ping timeout: 252 seconds)
357 2011-12-27 08:01:05 ShadowE989 has quit (Quit: Leaving)
358 2011-12-27 08:03:08 <CIA-100> bitcoin: Kano * r5033dcd355e6 cgminer/ (README main.c miner.h util.c): fix test/set of thr->pth to also work in windows http://tinyurl.com/7hoggny
359 2011-12-27 08:03:09 <CIA-100> bitcoin: Con Kolivas * rd1f896a64ae3 cgminer/ (README main.c miner.h util.c): Merge pull request #63 from kanoi/master http://tinyurl.com/7ew6sc5
360 2011-12-27 08:04:46 ShadowE989 has joined
361 2011-12-27 08:06:33 bobke has joined
362 2011-12-27 08:11:31 wasabi has joined
363 2011-12-27 08:13:40 wasabi1 has quit (Ping timeout: 255 seconds)
364 2011-12-27 08:22:06 molecular has quit (Ping timeout: 240 seconds)
365 2011-12-27 08:23:15 molecular has joined
366 2011-12-27 08:26:15 HaltingState has quit (Read error: Connection reset by peer)
367 2011-12-27 08:26:47 HaltingState has joined
368 2011-12-27 08:26:47 HaltingState has quit (Changing host)
369 2011-12-27 08:26:47 HaltingState has joined
370 2011-12-27 08:32:37 <wumpus> nanotube: the old wx behaviour was the same, I took that over
371 2011-12-27 08:40:24 <wumpus> could add the actual block time/date to the "transaction details" if it's not yet in there
372 2011-12-27 08:40:42 gfinn has quit (Remote host closed the connection)
373 2011-12-27 08:43:25 * BlueMatt thinks we need to put together a ton of cash and hire a professional to review OP_EVAL
374 2011-12-27 08:43:37 <BlueMatt> if ever there was a time to get a review of bitcoin, 0.6 would be it
375 2011-12-27 08:45:11 marf_away has joined
376 2011-12-27 08:45:29 abragin has joined
377 2011-12-27 08:46:05 bobke has quit (Ping timeout: 255 seconds)
378 2011-12-27 08:49:51 <osmosis> cool
379 2011-12-27 08:50:16 bobke has joined
380 2011-12-27 08:50:53 TuxBlackEdo has quit (Ping timeout: 276 seconds)
381 2011-12-27 08:51:03 kobier has quit (Max SendQ exceeded)
382 2011-12-27 08:51:14 terrytibbs has quit (Excess Flood)
383 2011-12-27 08:51:55 gfinn has joined
384 2011-12-27 08:52:15 <wumpus> yeah...
385 2011-12-27 08:52:22 terrytibbs has joined
386 2011-12-27 08:53:11 RazielZ has joined
387 2011-12-27 08:53:35 <BlueMatt> we could probably get the cash together if gavin tried
388 2011-12-27 08:53:58 <osmosis> who is the 'professional' that would be hired?
389 2011-12-27 08:54:01 <BlueMatt> or if ie luke-jr plus [Tycho] required it before implementing it on their pools
390 2011-12-27 08:54:46 <BlueMatt> osmosis: one would buy a professional who does security analysis for a living (there are a ton of those out there)
391 2011-12-27 08:54:49 <wumpus> good question osmosis, I'm don't think randomly throwing money at it is going to solve it
392 2011-12-27 08:55:09 <osmosis> I thought BlueMatt was the professional.
393 2011-12-27 08:55:14 <BlueMatt> no, someone would need to find which firms have good reputations
394 2011-12-27 08:55:18 <BlueMatt> osmosis: hahahaha
395 2011-12-27 08:55:26 * BlueMatt a professional? no way in hell
396 2011-12-27 08:55:55 <wumpus> but we should recommend heavy code review, at the least
397 2011-12-27 08:55:57 <wumpus> and not rush it in
398 2011-12-27 08:56:19 <BlueMatt> well its already in...
399 2011-12-27 08:56:25 <BlueMatt> so we better review before release
400 2011-12-27 08:56:34 <wumpus> maybe disable it for now, it's too dangerous for our own good
401 2011-12-27 08:56:58 <BlueMatt> OP_EVAL is essentially gavin's highest priority ever
402 2011-12-27 08:57:08 <osmosis> just release it as 'beta'
403 2011-12-27 08:57:12 <wumpus> okay
404 2011-12-27 08:57:23 <osmosis> no one will complain if it says beta right on it.
405 2011-12-27 08:57:30 <wumpus> but how did something like ScriptInner(recursionDepth++) come through code review?
406 2011-12-27 08:57:37 <BlueMatt> no bitcoin is stable
407 2011-12-27 08:57:51 <BlueMatt> wumpus: you realize we have no code review
408 2011-12-27 08:58:59 <wumpus> well we do vet pull requests
409 2011-12-27 08:59:20 <BlueMatt> not really
410 2011-12-27 08:59:37 <edcba> ;;bc,mtgox
411 2011-12-27 08:59:37 <gribble> {"ticker":{"high":4.07425,"low":3.9002,"avg":3.99902409,"vwap":3.999648042,"vol":38759,"last_all":4.03613,"last_local":4.03613,"last":4.03613,"buy":4.03613,"sell":4.0371}}
412 2011-12-27 08:59:49 dissipate has joined
413 2011-12-27 08:59:53 <wumpus> sigh, okay whatever... it's all good, nothing to see here
414 2011-12-27 09:00:16 TuxBlackEdo has joined
415 2011-12-27 09:05:30 kobier has joined
416 2011-12-27 09:11:45 wasabi has quit (Read error: Connection reset by peer)
417 2011-12-27 09:12:13 wasabi has joined
418 2011-12-27 09:13:42 HaltingState has quit (Ping timeout: 240 seconds)
419 2011-12-27 09:19:25 abragin has left ()
420 2011-12-27 09:22:53 davout has joined
421 2011-12-27 09:24:27 vsrinivas has quit (Ping timeout: 240 seconds)
422 2011-12-27 09:32:22 red__ has joined
423 2011-12-27 09:35:26 <red__> hi, what is the minimum BTC Transaktion with the standart Client?
424 2011-12-27 09:36:25 HaltingState has joined
425 2011-12-27 09:37:02 <edcba> there is no minimum afaik but you will have to pay a fee
426 2011-12-27 09:37:23 <edcba> minimum being 1e-8 BTC iirc
427 2011-12-27 09:38:13 <edcba> now the fee thingie may depend on "standard client" :)
428 2011-12-27 09:38:59 <red__> standart= download from bitcoin.org
429 2011-12-27 09:39:09 <edcba> ie a miner can accept a transaction without fee even if transaction is small
430 2011-12-27 09:39:14 <red__> 1e-8 means?
431 2011-12-27 09:39:30 <edcba> 0.00000001
432 2011-12-27 09:39:39 <extor> Can someone tell me what cart system this guy is using and whether it's free or paid? http://library-list.com/
433 2011-12-27 09:42:11 <red__> well i got a problem my Client wants a minimum fee from 0.0005 BTC even if the settings say fee is 0 - any idea why?
434 2011-12-27 09:43:34 <edcba> maybe your client sux or maybe there is a bug
435 2011-12-27 09:44:45 marf_away has quit (Read error: Connection reset by peer)
436 2011-12-27 09:45:07 <red__> okay but this should not be usual right?
437 2011-12-27 09:46:29 marf_away has joined
438 2011-12-27 09:50:21 <BlueMatt> red__: that is normal, see the fee page on the wiki
439 2011-12-27 09:50:41 [Tycho] has joined
440 2011-12-27 09:51:57 dissipate has quit (Ping timeout: 240 seconds)
441 2011-12-27 09:52:59 <red__> okay thanks
442 2011-12-27 09:54:20 [Tycho]_ has joined
443 2011-12-27 09:54:56 [Tycho] has quit (Ping timeout: 244 seconds)
444 2011-12-27 10:05:46 BlueMatt has quit (Quit: Ex-Chat)
445 2011-12-27 10:12:31 wasabi1 has joined
446 2011-12-27 10:12:58 vsrinivas has joined
447 2011-12-27 10:14:30 wasabi has quit (Ping timeout: 240 seconds)
448 2011-12-27 10:23:11 dissipate has joined
449 2011-12-27 10:27:46 dvide has quit ()
450 2011-12-27 10:36:25 m00p has quit (Ping timeout: 240 seconds)
451 2011-12-27 10:51:34 devrandom has quit (Remote host closed the connection)
452 2011-12-27 10:52:46 devrandom has joined
453 2011-12-27 10:53:15 TD has joined
454 2011-12-27 10:58:25 b4epoche_ has joined
455 2011-12-27 10:59:27 b4epoche has quit (Ping timeout: 240 seconds)
456 2011-12-27 10:59:28 b4epoche_ is now known as b4epoche
457 2011-12-27 11:08:33 SomeoneWeird_ has joined
458 2011-12-27 11:08:48 SomeoneWeird_ has quit (Changing host)
459 2011-12-27 11:08:49 SomeoneWeird_ has joined
460 2011-12-27 11:13:12 wasabi has joined
461 2011-12-27 11:14:58 wasabi1 has quit (Ping timeout: 240 seconds)
462 2011-12-27 11:16:12 MimeNarrator_ has quit (Remote host closed the connection)
463 2011-12-27 11:16:20 MimeNarrator has joined
464 2011-12-27 11:19:36 SomeoneWeird_ has quit (Quit: Leaving)
465 2011-12-27 11:29:29 dissipate has quit (Ping timeout: 244 seconds)
466 2011-12-27 11:36:28 chrisb__ has joined
467 2011-12-27 11:37:11 davout has quit (Read error: Connection reset by peer)
468 2011-12-27 11:37:40 davout has joined
469 2011-12-27 11:49:45 peck has quit (Ping timeout: 240 seconds)
470 2011-12-27 12:01:49 WakiMiko_ is now known as WakiMiko
471 2011-12-27 12:20:18 merde has quit ()
472 2011-12-27 12:37:45 Turingi has quit (Read error: Connection reset by peer)
473 2011-12-27 12:40:16 Sedra has joined
474 2011-12-27 12:42:02 <CIA-100> bitcoinjs/node-bitcoin-p2p: Danny Navarro master * r12527b1 / lib/node.js : Not every block has version 1. Fixes #50. ... https://github.com/bitcoinjs/node-bitcoin-p2p/commit/12527b1b069be70265150b714cfaa76b3d9f2d07
475 2011-12-27 12:42:03 <CIA-100> bitcoinjs/node-bitcoin-p2p: Danny Navarro master * rdf28101 / lib/script.js : Missing assignment to `len` for `OP_PUSHDATA4`. - http://git.io/ZfRVXw https://github.com/bitcoinjs/node-bitcoin-p2p/commit/df2810162c6ff961c7457a700cfe7f87385b3535
476 2011-12-27 12:42:03 <CIA-100> bitcoinjs/node-bitcoin-p2p: Danny Navarro master * rb336737 / (lib/schema/transaction.js test/blockchain.js): Remove whitespace. - http://git.io/RnFYaA https://github.com/bitcoinjs/node-bitcoin-p2p/commit/b336737063effa74105da4acb578ddb12bfbfa90
477 2011-12-27 12:42:03 <CIA-100> bitcoinjs/node-bitcoin-p2p: Stefan Thomas master * r2929d61 / (4 files in 3 dirs): Merge pull request #52 from jdnavarro/master ... https://github.com/bitcoinjs/node-bitcoin-p2p/commit/2929d6198202f4561999dd0d2b265d10bd2d99c7
478 2011-12-27 12:43:43 Sedra- has quit (Ping timeout: 240 seconds)
479 2011-12-27 12:44:50 iocor has joined
480 2011-12-27 12:52:00 TuxBlackEdo has quit (Quit: Leaving)
481 2011-12-27 12:53:40 TuxBlackEdo has joined
482 2011-12-27 13:04:03 peck has joined
483 2011-12-27 13:05:09 Cablesaurus has quit (Quit: Some folks are wise, and some otherwise.)
484 2011-12-27 13:09:28 chrisb__ has quit (Quit: Ex-Chat)
485 2011-12-27 13:10:34 PK has joined
486 2011-12-27 13:12:28 DontMindMe2 has joined
487 2011-12-27 13:14:18 imsaguy2 has quit (Ping timeout: 240 seconds)
488 2011-12-27 13:16:29 red__ has left ()
489 2011-12-27 13:34:08 MobiusL has quit (Remote host closed the connection)
490 2011-12-27 13:34:17 sacredchao has quit (Remote host closed the connection)
491 2011-12-27 13:34:34 sacredchao has joined
492 2011-12-27 13:35:13 MobiusL has joined
493 2011-12-27 13:41:14 Turingi has joined
494 2011-12-27 13:43:56 <Diablo-D3> http://falkvinge.net/2011/09/27/never-trust-a-vpn-provider-that-doesnt-accept-bitcoin/
495 2011-12-27 13:53:09 gfinn has quit (Ping timeout: 276 seconds)
496 2011-12-27 14:16:37 bobke has quit (Read error: No route to host)
497 2011-12-27 14:19:34 [Tycho]_ has quit (Remote host closed the connection)
498 2011-12-27 14:26:16 wladston has joined
499 2011-12-27 14:26:48 bobke has joined
500 2011-12-27 14:26:56 <wladston> guys, is there any way to set the transaction fee I'm willing to pay with bitcoind sendtoaddress ?
501 2011-12-27 14:27:28 <wladston> right now, when I try to send some amount using json-rpc, I get no warning about the fee being applied
502 2011-12-27 14:38:55 <wladston> I can't find a way to avoid sending compulsory transaction fee using bitcoind. :(
503 2011-12-27 14:39:42 <gmaxwell> wladston: There isn't a way with the GUI either. If it's _compulsory_ it's because its confident that the transaction will get stuck without it.
504 2011-12-27 14:40:01 <gmaxwell> (though the GUI does give you the option to abort in that case)
505 2011-12-27 14:40:10 <wladston> gmaxwell: the GUI gives me a warning saying the amount of the fee
506 2011-12-27 14:40:11 <edcba> confident ?
507 2011-12-27 14:40:15 <edcba> how ?
508 2011-12-27 14:40:21 <TD> because the rules say it will be stuck
509 2011-12-27 14:40:28 <wladston> gmaxwell: bitcoind gives no warning at all
510 2011-12-27 14:40:34 <gmaxwell> edcba: by applying the same fee rule that it would use for relaying.
511 2011-12-27 14:40:50 <edcba> wait there is a relaying fee now ?
512 2011-12-27 14:40:53 <gmaxwell> wladston: I know. But thats not what it appeared you were asking about.
513 2011-12-27 14:41:23 <wladston> gmaxwell: sorry :) my question is how can I know the transaction fee of a senttoaddress before it gets sent
514 2011-12-27 14:41:56 <gmaxwell> edcba: ... No. There is an automatic rule which stops DDOS attacks by preventing rapid back to back transactions of the same coin, unless a fee is provided.
515 2011-12-27 14:42:50 <gmaxwell> edcba: without it I could simply type while true; do bitcoind sendtoaddress `bitcoind getnewaddress`;done and pretty much take out bitcoin
516 2011-12-27 14:43:56 <edcba> so you can stop a legitimate transaction if you have same coin ?
517 2011-12-27 14:44:14 <gmaxwell> wladston: You can't currently, and thats because getting a new txn in or getting a new block may drastically change the coin selection... so even if you could ask it, the answer would potentially be invalid by the time you got your answer.
518 2011-12-27 14:44:17 <edcba> or at least stop spreading
519 2011-12-27 14:45:25 <wladston> gmaxwell: that could be a major problem, no ? What is the blocksize is getting closer to 500Kb and I loose 2BTC for trying to send 0.5BTC ?
520 2011-12-27 14:45:48 <gmaxwell> edcba: bitcoin nodes will not relay transactions which look like a DOS attack.
521 2011-12-27 14:46:18 <gmaxwell> wladston: er. The compulsory fees needed for anti-ddos are 0.0005 btc.
522 2011-12-27 14:46:27 <edcba> why not just use some bayesian thingie ?
523 2011-12-27 14:46:53 <edcba> maybe too easy to circumvent
524 2011-12-27 14:46:53 <wladston> gmaxwell: I know, but I've seen on the wiki some cases of very high fee being applied
525 2011-12-27 14:47:22 <wladston> gmaxwell: how can I assure that my fee won't be greater than 0.0005 BTC ?
526 2011-12-27 14:47:26 * edcba should look at recent code...
527 2011-12-27 14:47:35 <gmaxwell> edcba: none of this is recent.
528 2011-12-27 14:47:50 <edcba> yes i know
529 2011-12-27 14:47:58 <edcba> it's been a while i looked at it
530 2011-12-27 14:50:11 <gmaxwell> wladston: how? go read the fee logic in main.h
531 2011-12-27 14:50:14 <gmaxwell> ::shrugs::
532 2011-12-27 14:50:40 <wladston> gmaxwell: so I have to implement fee calculations outside of bitcoind ?
533 2011-12-27 14:50:46 <gmaxwell> wladston: In any case, all of the reported "high fees" I've seen have been people confused by change in block explorer.
534 2011-12-27 14:50:59 <gmaxwell> wladston: No, you can't implement fee calculations outside of bitcoind.
535 2011-12-27 14:51:31 <gmaxwell> 06:41 < gmaxwell> wladston: You can't currently, and thats because getting a new txn in or getting a new block may drastically change the coin selection... so even if you could ask it, the answer would potentially be invalid by the time you got your answer.
536 2011-12-27 14:52:31 <sipa> the right solution is to be able to create a transaction in "preview" mode, which allows you to inspect the transacton before it is sent out
537 2011-12-27 14:52:43 <sipa> and then give the option to either cancel or proceed
538 2011-12-27 14:53:16 <wladston> sipa: thanks :) what's the command for creating a preview sendtoaddress ?
539 2011-12-27 14:53:26 <sipa> it doesn't exist yet...
540 2011-12-27 14:53:44 <sipa> i'm just saying what would need to be implemented to solve the issue you're having
541 2011-12-27 14:53:47 <lianj> someone at 28c3?
542 2011-12-27 14:54:11 gfinn has joined
543 2011-12-27 14:54:19 <wladston> sipa: do you have any services based on bitcoins ? how do you handle this issue ?
544 2011-12-27 14:54:29 <gmaxwell> sipa: right, I suppose it could be made tolerable if the preview only locked the inputs until the next send.
545 2011-12-27 14:54:39 <sipa> wladston: i only run bitcoin.sipa.be
546 2011-12-27 14:54:44 <sipa> no payment handling stuff
547 2011-12-27 14:55:03 <sipa> but it's a nice idea that's been around fro a while
548 2011-12-27 14:55:04 <gmaxwell> wladston: people running services just take the fees as a cost of doing business (and sometimes pass them on to customers e.g. 0.01 for withdraws, at a profit).
549 2011-12-27 14:55:08 <helo> if random bits were written to a wallet where the encrypted keys are stored, the wallet would be indistinguishable from a wallet with encrypted keys intact, right?
550 2011-12-27 14:55:08 <sipa> i guess i could implement it
551 2011-12-27 14:55:32 <sipa> helo: indeed, unless you knoz the key
552 2011-12-27 14:56:13 <helo> if such wallets were common, it might provide some plausible deniability and waste the resources of attackers
553 2011-12-27 14:56:23 <wladston> gmaxwell: it still sounds very dangerous. if my clients mange to create outgoing transactions with generate a big fee ( since it's compulsory), it's possible that I would end up owing money
554 2011-12-27 14:56:46 <sipa> it won't ever let you go negative
555 2011-12-27 14:56:57 <wladston> sipa: how ?
556 2011-12-27 14:57:09 <sipa> that's sinmply impossible
557 2011-12-27 14:57:18 <sipa> the protocol does not allow you to send coins you don't have
558 2011-12-27 14:57:23 <gmaxwell> wladston: I think you're over reacting because you don't understand how it works, go walk through the code and see the fee that it would apply.
559 2011-12-27 14:57:56 <wladston> I have a cliend with one of those bitcoind accounts. If I try to transfer everything in it to an address, it will do so, getting the fee from the main wallet.dat
560 2011-12-27 14:58:15 <sipa> oh yes
561 2011-12-27 14:58:23 <gmaxwell> wladston: You can also insert a one line change to make it fail if the fee would be higher than 0.01 if you like... though it takes a 20kbyte transaction to make the fee that large.
562 2011-12-27 14:58:25 <sipa> the guarantee is only for the entire wallet
563 2011-12-27 14:59:00 <gmaxwell> (and if something about your service is reliably allowing customers to produce 20kbyte transactions, then you ought to fix it)
564 2011-12-27 14:59:36 <wladston> gmaxwell: right. And how could I do that ?
565 2011-12-27 14:59:49 <gmaxwell> wladston: and how could you do what?
566 2011-12-27 15:00:06 <wladston> gmaxwell: insert a one line change to make it fail if the fee would be higher than 0.01
567 2011-12-27 15:02:40 JZavala has quit (Ping timeout: 252 seconds)
568 2011-12-27 15:02:49 <wladston> I just have no idea how the transaction size would grow
569 2011-12-27 15:03:01 <wladston> and I wanted to launch my service free of charge at the start
570 2011-12-27 15:03:28 <wladston> without the risk of getting backrupt :D
571 2011-12-27 15:04:30 <gmaxwell> wladston: e.g. untested, http://pastebin.com/EkD45McZ
572 2011-12-27 15:04:43 <gmaxwell> wladston: but I think you're being irrational.
573 2011-12-27 15:05:37 <wladston> gmaxwell: maybe ... I would like if you could help me understand better
574 2011-12-27 15:06:00 <wladston> gmaxwell: because from what I've read so far, there is no upper limit for the transaction fee
575 2011-12-27 15:06:18 <wladston> gmaxwell: and it gets taken from the wallet.dat compulsively
576 2011-12-27 15:06:41 <wladston> gmaxwell: so I can't see how that isn't a problem for automated bitcoind applications
577 2011-12-27 15:06:46 <gmaxwell> wladston: Sure, there is. But the upper limit isn't relevant.
578 2011-12-27 15:07:12 <gmaxwell> wladston: because in practice the required fee is almost always zero, and when its not it's almost always 0.0005.
579 2011-12-27 15:07:46 <gmaxwell> It can be larger, when the transaction data is very large. But the software makes an effort to minimize the data size.
580 2011-12-27 15:08:45 <nanotube> <wumpus> [00:37:35] could add the actual block time/date to the "transaction details" if it's not yet in there <- yes please.! :)
581 2011-12-27 15:09:03 <wladston> gmaxwell: so if I charge my clients a withdraw fee of 0.0005 I can be safe ?
582 2011-12-27 15:09:45 b4epoche_ has joined
583 2011-12-27 15:10:07 <wladston> gmaxwell: also I can't see if my service could be attacked by a malicious user trying to create large transactions
584 2011-12-27 15:10:20 <gmaxwell> so the only way that I'm aware of to end up with a 'large' fee is e.g. to have a wallet with nothing other than tiny dust (e.g. 1e-8) inputs confirmed.
585 2011-12-27 15:10:21 weather has quit (Ping timeout: 252 seconds)
586 2011-12-27 15:10:36 <gmaxwell> one sec and I'll figure out the current maximum fee it could come up with.
587 2011-12-27 15:10:44 b4epoche has quit (Ping timeout: 252 seconds)
588 2011-12-27 15:10:44 b4epoche_ is now known as b4epoche
589 2011-12-27 15:11:41 <wladston> the way I'm coding it now, the service could be used like an online wallet, with the client being able to deposit and withdraw at any times from his account.
590 2011-12-27 15:13:12 davout has quit (Remote host closed the connection)
591 2011-12-27 15:13:58 <gmaxwell> wladston: okay, the _highest_ it can come up with right now appears to be 0.05 BTC.
592 2011-12-27 15:14:16 <wladston> gmaxwell: ! not as much as I thought
593 2011-12-27 15:14:57 <gmaxwell> wladston: sure, but to force you to use tiny inputs he'd have to prevent your wallet from containing anything else.
594 2011-12-27 15:15:16 <gmaxwell> That limit arises from,
595 2011-12-27 15:15:16 <gmaxwell> if (nBytes >= MAX_BLOCK_SIZE_GEN/5)
596 2011-12-27 15:15:16 <gmaxwell> return false;
597 2011-12-27 15:15:51 <wladston> gmaxwell: I think I'll settle with charging a 0.005 withdraw fee
598 2011-12-27 15:16:54 <gmaxwell> where MAX_BLOCK_SIZE_GEN = MAX_BLOCK_SIZE/2; MAX_BLOCK_SIZE = 1000000; and nMinFee = (1 + (int64)nBytes / 1000) * nBaseFee; where nBaseFee=MIN_TX_FEE and MIN_TX_FEE=50000
599 2011-12-27 15:17:59 <gmaxwell> I suppose it would be useful to document that, just to help calm people's nerves.
600 2011-12-27 15:18:23 <wladston> gmaxwell: I wonder how instawallet handles this, since their service is apparently "free"
601 2011-12-27 15:18:51 <gmaxwell> wladston: if your wallet has a good amount of older inputs in it, you'll simple never run into this.
602 2011-12-27 15:18:55 Internet13 has quit (Read error: Connection reset by peer)
603 2011-12-27 15:19:20 <wladston> interesting
604 2011-12-27 15:20:53 Internet13 has joined
605 2011-12-27 15:21:53 <gmaxwell> The fees are only required when you fail the anti-ddos rules (e.g. respending inputs that arrived too recently). You need, on average, about one bitcoin day (one bitcoin for one day, two bitcoin for a half day, a half bitcoin for two days, etc) of sit-still-time to get a typical transaction past the anti-ddos rule.
606 2011-12-27 15:22:18 btc_novice has joined
607 2011-12-27 15:22:57 <wladston> gmaxwell: got it. Thinking here on how to best handle this in the webapp
608 2011-12-27 15:24:52 hippich has quit (Changing host)
609 2011-12-27 15:24:53 hippich has joined
610 2011-12-27 15:33:30 <helo> is the age of the inputs available used to determine which inputs to spend?
611 2011-12-27 15:34:34 <gmaxwell> Yes, though only in a limited way.
612 2011-12-27 15:34:47 <wladston> gmaxwell: thanks for the help :) going to class now. hopefully I'll manage to launch the service with a very low fee.
613 2011-12-27 15:35:09 <helo> i think unless your webapp is being used to generate spam, the issue won't arise
614 2011-12-27 15:35:16 <gmaxwell> It runs the selection algorithim multiple times, trying to use older inputs first.
615 2011-12-27 15:35:23 <wladston> gmaxwell: the thing is I didn't want to change the incoming deposits ... nor the outgoing withdraws ... just the use of the service
616 2011-12-27 15:35:43 conman has quit (Remote host closed the connection)
617 2011-12-27 15:36:07 <wladston> helo: yeah, maybe I would have to thing of a way to block spam-users
618 2011-12-27 15:36:30 <wladston> halo: because the way it is now a user could deposit and withdraw multiple times generating spam
619 2011-12-27 15:37:12 <wladston> off I go :)
620 2011-12-27 15:37:19 wladston has left ()
621 2011-12-27 15:38:35 dub has quit (Ping timeout: 252 seconds)
622 2011-12-27 15:38:42 dub has joined
623 2011-12-27 15:39:05 chrisb__ has joined
624 2011-12-27 15:40:22 genjix has joined
625 2011-12-27 15:41:22 <genjix> wumpus: you have a bash script scripts/qt/make_windows_icon.py
626 2011-12-27 15:41:26 <genjix> should end in .sh
627 2011-12-27 15:41:31 <genjix> fyi
628 2011-12-27 15:41:38 <wumpus> lol
629 2011-12-27 15:41:44 <wumpus> yes
630 2011-12-27 15:41:49 <sipa> just calculated some statistics from my dnsseeder's crawler
631 2011-12-27 15:41:53 <wumpus> I generally write python scripts, so I'm used to .py
632 2011-12-27 15:42:06 <sipa> most nodes run 0.3.23 :(
633 2011-12-27 15:42:13 <wumpus> ouch :s
634 2011-12-27 15:42:17 <sipa> 2787 reachable ones
635 2011-12-27 15:42:33 <sipa> 1645 at 0.3.24
636 2011-12-27 15:42:46 <sipa> 1425 at 0.4.0
637 2011-12-27 15:42:58 <sipa> 810 at 0.5.1
638 2011-12-27 15:43:10 <sipa> 432 at 0.5.0.1
639 2011-12-27 15:43:30 <sipa> 389 at 0.3.21
640 2011-12-27 15:43:35 [Tycho] has joined
641 2011-12-27 15:43:55 <wumpus> seems people are reluctant to upgrade
642 2011-12-27 15:44:11 <genjix> or what they have already works
643 2011-12-27 15:44:13 <gmaxwell> wumpus: they may have no idea a new version is available.
644 2011-12-27 15:44:25 <TD> sipa: there's a site that tracks those stats
645 2011-12-27 15:44:37 <sipa> TD: i know, i should compare the numbers
646 2011-12-27 15:44:41 <TD> http://bitcoinstatus.rowit.co.uk/
647 2011-12-27 15:44:55 <TD> it's been showing a steady decline in the number of reachable nodes
648 2011-12-27 15:45:22 <TD> it may be an issue with the stat collector
649 2011-12-27 15:45:25 <wumpus> genjix: yes, so they are reluctant to upgrade
650 2011-12-27 15:45:39 <TD> is there an issue with UPnP?
651 2011-12-27 15:45:42 <wumpus> it makes sense, in a twisted way
652 2011-12-27 15:46:18 <gmaxwell> TD: Yes. I'd fix it but don't have any way to test it.
653 2011-12-27 15:46:28 <TD> you don't have a upnp capable router?
654 2011-12-27 15:46:35 <gmaxwell> TD: the UPNP just fires off once. So once the router expires it, its gone.
655 2011-12-27 15:46:40 <TD> ah
656 2011-12-27 15:46:46 <TD> how quickly do the entries expire?
657 2011-12-27 15:46:54 <wumpus> so it has to re-send the request once in a while?
658 2011-12-27 15:47:01 <sipa> i think that UPnP issue should be fixed before 0.6.0
659 2011-12-27 15:47:15 <sipa> wumpus: i believe so
660 2011-12-27 15:47:20 <gmaxwell> We don't ask for a limit. But evidence suggests that (some, many, most, all??) router clamp at an hour or so.
661 2011-12-27 15:47:22 <sipa> sounds trivial to implement
662 2011-12-27 15:47:35 <TD> i guess that makes sense
663 2011-12-27 15:47:45 <TD> otherwise a buggy implementation could keep a port forwarded indefinitely
664 2011-12-27 15:48:01 <genjix> why not measure nodes accept/connect ratio
665 2011-12-27 15:48:08 <wumpus> yep, killing a program owuld leave the port open forever
666 2011-12-27 15:48:15 <gmaxwell> We should probably ask the router for an hour and refresh ever half hour or something like that. But I don't know whats considered best practices.
667 2011-12-27 15:48:21 <gmaxwell> s/ever/every/
668 2011-12-27 15:48:55 <TD> http://bitcoinstatus.rowit.co.uk/hostsservers.html
669 2011-12-27 15:49:00 <TD> genjix: you mean like that ?
670 2011-12-27 15:49:21 <sipa> genjix: bitcoin-seeder tracks that
671 2011-12-27 15:49:36 <sipa> over several windozs
672 2011-12-27 15:49:50 <sipa> to determine whether it's worth reporting that IP over DNS
673 2011-12-27 15:51:12 <genjix> TD: yeah like that
674 2011-12-27 15:51:28 <gmaxwell> it .. would be nice if we had some information about alternative clients.
675 2011-12-27 15:51:29 <sipa> genjix: oh, i meant something else :)
676 2011-12-27 15:51:39 <TD> it's interesting to speculate on the cause of the falling number of nodes
677 2011-12-27 15:51:42 <TD> at a time when the tx rate is rising
678 2011-12-27 15:51:42 <genjix> not that much of a climb to blame it on upnp
679 2011-12-27 15:51:47 <TD> a shift in the demographics of bitcoin uses?
680 2011-12-27 15:52:00 <sipa> the decrease is remarkably consistent
681 2011-12-27 15:52:00 <gmaxwell> I expect some portion of that address rumoring decline is the introduction of multibit and
682 2011-12-27 15:52:04 <gmaxwell> Electrum
683 2011-12-27 15:52:12 <TD> perhaps
684 2011-12-27 15:52:12 <genjix> weird that is a mystery
685 2011-12-27 15:52:20 <TD> i'd be surprised if they had significant usage
686 2011-12-27 15:52:24 <genjix> i doubt they have enough share
687 2011-12-27 15:52:25 <TD> given they aren't linked to from bitcoin.org
688 2011-12-27 15:52:30 <gmaxwell> sipa: some of that may be due to do a half-lifing effect of addr.dat?
689 2011-12-27 15:53:47 eueueue has joined
690 2011-12-27 15:53:50 <gmaxwell> I'm not quite clear on why an address would ever fall out of address circulation.
691 2011-12-27 15:54:00 <sipa> gmaxwell: http://bitcoinstatus.rowit.co.uk/versions.html
692 2011-12-27 15:54:16 <sipa> those are real listening servers
693 2011-12-27 15:54:22 <sipa> and that number drops as well
694 2011-12-27 15:54:28 <helo> bash scripts shouldn't end in '.sh'
695 2011-12-27 15:54:59 <genjix> i would expect .3 to be most common for servers
696 2011-12-27 15:55:02 <helo> sh scripts should end in '.sh'
697 2011-12-27 15:55:12 <gmaxwell> sipa: I wish they had a sum line there.
698 2011-12-27 15:55:20 * TD continues to think there should be/have been an alert for <= 0.3.23
699 2011-12-27 15:55:23 <TD> or heck
700 2011-12-27 15:55:23 <TD> al
701 2011-12-27 15:55:26 <TD> all old versions
702 2011-12-27 15:55:33 <genjix> alerts have version numbers in them?
703 2011-12-27 15:55:36 <gmaxwell> Yes.
704 2011-12-27 15:55:41 <sipa> strange that 0.3.23 is so popular
705 2011-12-27 15:55:41 <TD> yes. you can restrict to arbitrary version ranges
706 2011-12-27 15:55:47 <sipa> it was our least stable release ever imho
707 2011-12-27 15:55:50 <TD> sipa: it was the version that existed during the press cycle
708 2011-12-27 15:55:56 <genjix> so they do
709 2011-12-27 15:56:00 <TD> sipa: lots of users probably installed during that time, forgot about it
710 2011-12-27 15:56:14 <TD> or don't even realize there IS an upgrade. software that doesn't auto upgrade itself is a nonsense these days
711 2011-12-27 15:56:21 <TD> it's quite reasonable to assume it's automatic
712 2011-12-27 15:56:27 <edcba> or prefer to keep that version
713 2011-12-27 15:56:29 <genjix> what auto-upgrading frameworks are there?
714 2011-12-27 15:56:34 <gmaxwell> edcba: doubt it.
715 2011-12-27 15:56:40 <gmaxwell> genjix: none that we should use.
716 2011-12-27 15:56:43 <genjix> i was looking before and there aren't any good opensource ones
717 2011-12-27 15:56:46 <edcba> but we don't know gmaxwell :)
718 2011-12-27 15:56:49 <TD> google updater is open source.
719 2011-12-27 15:56:54 <TD> however, it does silent upgrades
720 2011-12-27 15:57:02 <TD> that makes total sense for lightweight clients
721 2011-12-27 15:57:15 <gmaxwell> edcba: You're suggesting a more complicated explination, less likely to be true. :)
722 2011-12-27 15:57:15 <TD> for voting/miner clients ...... probably still makes sense, imho, but more controverial for sure
723 2011-12-27 15:57:18 <sipa> there is the gitian updater script
724 2011-12-27 15:57:53 <edcba> they may just let it run without caring for an upgraded version
725 2011-12-27 15:58:01 <edcba> since it still works
726 2011-12-27 15:58:17 <gmaxwell> TD: it does not make sense. An autoupdater on a majority of the network would make a complete lie of "decenteralized". I wouldn't bother protesting, because bitcoin users should be smart enough to not use such a thing, but soldcoin proves otherwise. :)
727 2011-12-27 15:58:31 <genjix> TD: their website says it is discontinued :/
728 2011-12-27 15:58:52 <TD> http://code.google.com/p/omaha/
729 2011-12-27 15:59:00 <TD> i don't see anything saying it's discontinued there
730 2011-12-27 15:59:14 <genjix> http://pack.google.com/intl/en/pack_installer.html
731 2011-12-27 15:59:15 <TD> gmaxwell: well, it's about the fundamental balance of experts vs users rather than auto update technologies
732 2011-12-27 15:59:42 <genjix> ah ok so this works too
733 2011-12-27 15:59:46 <TD> gmaxwell: you're right if you assume "bitcoin users" bother to review changelogs, understand the system at great depth, and may choose to research and switch to forks if gavin et al do things they disagree with
734 2011-12-27 15:59:52 <TD> genjix: pack is something different
735 2011-12-27 16:00:08 <TD> gmaxwell: in practice that isn't true. for users where it isn't true, they're best served by a silent, automatic upgrade
736 2011-12-27 16:00:22 <TD> which (on windows/macos) is best done by omaha, because google did it the longest and this engine has a proven track record
737 2011-12-27 16:00:23 <edcba> i won't change client before reviewing changes
738 2011-12-27 16:00:31 <sipa> it would surprise me that a bunch of users that downloaded the software months ago and don't care any further still account for the majority of *reachable* nodes on the network
739 2011-12-27 16:00:40 <gmaxwell> TD: No, just the slowness of non-auto-updates means that if only a few people review the changes then there is plenty of oppturnity to sound loud public alarms if something bad happens.
740 2011-12-27 16:00:55 <TD> who would see those alarms? where do they go?
741 2011-12-27 16:01:01 <TD> on the forums?
742 2011-12-27 16:01:09 TheZimm has joined
743 2011-12-27 16:01:13 <edcba> that or slashdot :)
744 2011-12-27 16:01:19 <genjix> omaha is windows only
745 2011-12-27 16:01:23 <TD> right. ie, places that regular users and merchants won't see
746 2011-12-27 16:01:33 <TD> genjix: yes. there's a mac version with a different name (and codebase)
747 2011-12-27 16:01:38 <TD> i forgot what
748 2011-12-27 16:01:46 <TD> http://code.google.com/p/update-engine/
749 2011-12-27 16:01:47 <TD> there we go
750 2011-12-27 16:01:52 <gmaxwell> TD: e.g. if gavin was taken over by aliens, and put out a 0.6 with a feature to send him all the coins. .. then within an hour or two we'd have it off the site, news of it would be on several tech news sites, an alert to not upgrade would go out, etc.
751 2011-12-27 16:02:06 <gmaxwell> TD: but with an auto-upgrade ... bitcoin would simply be over.
752 2011-12-27 16:02:11 <wumpus> gmaxwell: exactly
753 2011-12-27 16:02:16 <genjix> so for an update engine you need to maintain: windows, mac and several linux packages
754 2011-12-27 16:02:20 <wumpus> one hack could compromise everything
755 2011-12-27 16:02:22 <TD> gmaxwell: so that's why you don't allow the auto-update binaries to be signed with a single key
756 2011-12-27 16:02:24 <genjix> instead of rolling your own.
757 2011-12-27 16:02:30 <wumpus> or an exploit in the auto updater...
758 2011-12-27 16:02:38 weather has joined
759 2011-12-27 16:02:50 <TD> gmaxwell: far MORE likely is that there's a repeat of what already happened - gavin releases a binary with a serious bug
760 2011-12-27 16:02:56 <TD> and then people don't realize there's a bug and don't upgrade
761 2011-12-27 16:03:02 <gmaxwell> TD: There was a paper written for the tor project for an autoupdater which made sense, but I don't think it's been implemented yet.
762 2011-12-27 16:03:07 <sipa> gmaxwell: gitian-updater requires signatures from multiple gpg keys
763 2011-12-27 16:04:14 <gmaxwell> The system that I think make more sense requires multiple keys, and then it holds the update in quarentine (unless the user seeks it out and manually triggers it) and only applys after a delay and only if no vetos are recieved.
764 2011-12-27 16:04:55 <gmaxwell> And you give out the veto keys a bit more broadly, the holders only need to be trusted not to disrupt an important upgrade.
765 2011-12-27 16:05:06 <wumpus> tor does not have an auto upgrader afaik
766 2011-12-27 16:05:18 <wumpus> well maybe for windows
767 2011-12-27 16:05:24 <TD> sure, that would work
768 2011-12-27 16:05:35 <wumpus> for linux they simply rely on debian packages etc
769 2011-12-27 16:05:38 <wumpus> as they should
770 2011-12-27 16:05:42 <gmaxwell> wumpus: no, it doesn't have one... because of these issues, but they've been trying to find something that would be acceptable.
771 2011-12-27 16:05:43 <TD> well, that doesn't work, but i can't be bothered with this argument again
772 2011-12-27 16:05:44 <TD> d
773 2011-12-27 16:05:48 <TD> debian is bitcoins worst enemy
774 2011-12-27 16:05:57 <sipa> i agree with TD here
775 2011-12-27 16:06:01 <gmaxwell> wumpus: "wumpus> as they should" ugh!
776 2011-12-27 16:06:33 <genjix> why is everyone anti-debian? is there something i'm missing?
777 2011-12-27 16:06:35 <wumpus> I really hate that in windows every program has its own upgrader service, at least in linux it's handled in a central place
778 2011-12-27 16:06:48 <gmaxwell> Tor goes out of packaging periodically because the tor project has to say to distros "look, if you keep shipping remotely exploitable copies of our software from two years ago, you're going to get people killed"
779 2011-12-27 16:06:49 <genjix> apt is great
780 2011-12-27 16:06:52 <wumpus> you simply add the tor repository and you get automatic updates, I don't see the problem
781 2011-12-27 16:06:56 <sipa> genjix: i love debian, but its package syste, is not what should be used to keep bitcoin up to date
782 2011-12-27 16:07:13 <wumpus> they have their own repos with up-to-date clients
783 2011-12-27 16:07:26 <wumpus> the central debian one sucks, that's true...
784 2011-12-27 16:07:31 <genjix> also you can swim downstream and get them to update
785 2011-12-27 16:07:41 <genjix> we did it a few times on old projects
786 2011-12-27 16:08:41 <genjix> they will do it if you help out or even provide to update the packages yourself. mostly it happens because developers build against unstable packages or the maintainer goes missing/is busy.
787 2011-12-27 16:08:47 <wumpus> at least it integrates all upgrades in one place, so people don't have to worry about each program individually
788 2011-12-27 16:09:05 <TD> yeah, exactly\
789 2011-12-27 16:09:07 <TD> so they shouldn't ship
790 2011-12-27 16:09:22 <TD> if it were up to me there'd be a big, fat build system check that aborts the build if it detects the debian build servers
791 2011-12-27 16:09:38 weather has quit (Read error: Connection reset by peer)
792 2011-12-27 16:09:43 <wumpus> right, let's sabotage each other, long live open source... :/
793 2011-12-27 16:11:31 <genjix> i support your movement. sabotage windows and macs
794 2011-12-27 16:11:36 Nicksasa has joined
795 2011-12-27 16:17:59 <wumpus> but on windows an auto upgrader indeed makes sense as there is no central infrastructure for updates
796 2011-12-27 16:18:37 eueueue has quit (Quit: Saindo)
797 2011-12-27 16:18:40 a_meteorite has quit (Ping timeout: 248 seconds)
798 2011-12-27 16:19:17 SomeoneWeird is now known as SomeoneWeirdzzzz
799 2011-12-27 16:19:27 TD has quit (Quit: TD)
800 2011-12-27 16:23:06 TD has joined
801 2011-12-27 16:23:42 btc_novice1 has joined
802 2011-12-27 16:24:11 btc_novice1 has quit (Client Quit)
803 2011-12-27 16:24:53 btc_novice1 has joined
804 2011-12-27 16:25:43 btc_novice has quit (Ping timeout: 252 seconds)
805 2011-12-27 16:27:22 btc_novice1 has quit (Client Quit)
806 2011-12-27 16:28:08 wasabi1 has joined
807 2011-12-27 16:28:50 genjix has left ()
808 2011-12-27 16:40:59 red__ has joined
809 2011-12-27 16:42:10 da2ce7 has quit (2!~da2ce7@gateway/tor-sasl/da2ce7|Ping timeout: 276 seconds)
810 2011-12-27 16:46:37 dan__ has joined
811 2011-12-27 16:46:52 btc_novice has joined
812 2011-12-27 16:49:45 red__ has left ()
813 2011-12-27 16:57:50 <sipa> wumpus: i heard they'll get something in win8
814 2011-12-27 16:59:02 <wumpus> yes, but windows users update much slower (also because the new versions have to be purchased), so by far most people will still be running xp/7 for the forseeable future :/
815 2011-12-27 16:59:14 <devrandom> gmaxwell: the gitian downloader should be a pretty secure way to auto-update
816 2011-12-27 16:59:41 <gmaxwell> devrandom: Did you read the discussion?
817 2011-12-27 17:00:12 <gmaxwell> devrandom: There wasn't a concern about the download security itself, there is a concern about the introduction of central control invalidating the decenteralized promise that makes bitcoin worth having.
818 2011-12-27 17:00:12 <devrandom> I absorbed maybe 50% of it
819 2011-12-27 17:00:27 <gmaxwell> There are lots of ways to do an update so that it can't be forged by random people.
820 2011-12-27 17:01:12 <devrandom> gmaxwell: the gitian downloader requires a minimum number of votes (actually weighted votes)... that's relatively decentralized
821 2011-12-27 17:01:29 <sipa> So what is the point? That auto-updating even with such protection measures is still centralized?
822 2011-12-27 17:01:44 <TD> hey devrandom
823 2011-12-27 17:01:45 phungus is now known as Marquis_de_Bitco
824 2011-12-27 17:01:49 <devrandom> hey TD
825 2011-12-27 17:01:54 Marquis_de_Bitco is now known as MarquisdeBitcoin
826 2011-12-27 17:02:28 dan__ has quit (Quit: dan__)
827 2011-12-27 17:02:49 <devrandom> you could have multiple thresholds, a lower one would quarantine for awhile
828 2011-12-27 17:03:10 <sipa> gmaxwell: The software distribution process is inherently centralized... you trusted that binary on bitcoin.org (a single place) you downloaded
829 2011-12-27 17:03:26 <sipa> given enough precautions, there is no reason you should trust the auto-update process less
830 2011-12-27 17:03:46 <devrandom> right, you can't expect each end-user to read the code, so they have to delegate some trust
831 2011-12-27 17:03:53 <sipa> (except when you built from source and inspected it yourself, but you wouldn't run an auto-update in the first place then)
832 2011-12-27 17:04:07 <gmaxwell> sipa: Think the incentives through some more. If I put a compromised version up on bitcoin.org I might hit a few folks before its noticed, mostly low value nodes.
833 2011-12-27 17:04:29 <gmaxwell> If I can push an auto update, I could hit a significant majority all at once.
834 2011-12-27 17:04:59 <gmaxwell> In the former case, it's not worth sending ninjas to hold guns to the heads of the core developers to make it happen. In the latter case it is.
835 2011-12-27 17:05:27 <sipa> What's the difference?
836 2011-12-27 17:05:36 <devrandom> a compromised version on bitcoin.org could be undetected for a long time
837 2011-12-27 17:05:37 <gmaxwell> devrandom: right, today they delegate trust to the developers AND the anyone else will catch baddness before they upgrade.
838 2011-12-27 17:05:43 <sipa> You can do massive damage by putting a compromised version in bitcoin.org as well
839 2011-12-27 17:06:33 <gmaxwell> sipa: the version upgrade charges suggest otherwise. :)
840 2011-12-27 17:06:59 <sipa> hmm?
841 2011-12-27 17:07:49 <gmaxwell> I mean, the initial deployments of new versions are fairly slow. Yes you could cause massive damage.. hundreds of nodes screwed up. But thats still another world from an autoupdate.
842 2011-12-27 17:08:55 <sipa> true, the impact is undenyably larger
843 2011-12-27 17:09:00 <devrandom> the autoupdate algorithm could stagger the update over days/weeks if ninjas are a concern
844 2011-12-27 17:10:02 <sipa> then the compromised version will only start behaving dangerously after a few weeks
845 2011-12-27 17:10:25 <gmaxwell> devrandom: absolutely, and I think if you put in enough of those kinds of factors (I was personally enamored with the veto stuff) then it gets better.
846 2011-12-27 17:10:47 <devrandom> sipa: well, with deterministic source-to-binary, anybody could check if there's a compromise by examining the code
847 2011-12-27 17:11:03 <gmaxwell> sipa: using something like gitian you (~)prove that the binaries match the source. Then you trust that someone reads the diff... and hope that the compromise wasn't subtle.
848 2011-12-27 17:11:25 <devrandom> vetoes sound good, I'll look into adding them into the downloader
849 2011-12-27 17:11:28 <gmaxwell> devrandom: they can't really, but we can at least make the attack risky enough and unlikely to be successful enough that people don't try.
850 2011-12-27 17:12:00 <sipa> oh sure, you could even have automated services that verify gitian-updater actions
851 2011-12-27 17:13:10 <sipa> devrandom: idea: alloz each key to have an allowed range for scores [-BAD..GOOD]
852 2011-12-27 17:13:18 <gmaxwell> devrandom: e.g. look at the OP_EVAL bug that gavin introduced.. foo++ where it should have been foo+1 that bug potentially introduced a stack smash. In some alternative universe, evil ninjas made gavin insert that flaw and they were waiting with an exploit for it.
853 2011-12-27 17:13:52 <sipa> it's not tahat bad, by the way, there is still a limit of 100 instructions executed
854 2011-12-27 17:14:04 <devrandom> as to gitian - right now the problem is that everybody trusts gavinandresen and therefore nobody checks other signatures :-P
855 2011-12-27 17:14:29 <gmaxwell> sipa: yea, sorry, I didn't mean to exagerate it. I'm just using it to point out the limitations of code review.
856 2011-12-27 17:14:30 slush has joined
857 2011-12-27 17:14:44 <sipa> gmaxwell: sure, it was potentially disasterous
858 2011-12-27 17:14:44 <devrandom> gmaxwell: but hopefully that will change... after all, gavin's machine could be compromised
859 2011-12-27 17:14:49 <gmaxwell> I skimmed over that diff, didn't see anything wrong with it. But obviously wasn't reading it very carefully.
860 2011-12-27 17:14:58 <sipa> same
861 2011-12-27 17:15:19 <devrandom> sipa: sounds good re -BAD
862 2011-12-27 17:15:43 <sipa> then sumall available scores, clamp them to their allowed range and see if a treshhold is reached or notµ
863 2011-12-27 17:15:56 <devrandom> sipa: need to think about an alternative way to get votes, because the main distribution method might silence negatives
864 2011-12-27 17:16:11 <devrandom> (if compromised)
865 2011-12-27 17:16:47 <sipa> separate URL's for each keys that are downloaded and checked for updated sigs?
866 2011-12-27 17:17:27 <sipa> like i could distribute my sigs via https://bicoinsipa.be/gitian.sig or so
867 2011-12-27 17:17:49 <sipa> (sorry for bad typography, i'm ssh'in over tethered EDGE in a train)
868 2011-12-27 17:18:07 <devrandom> sipa: sounds good, especially as .be is a separate jurisdiction
869 2011-12-27 17:19:14 <devrandom> should probably also warn the user if URL is unreachable, SSL fingerprint changed, etc.
870 2011-12-27 17:19:38 <devrandom> I guess should just warn the user if vote is not available
871 2011-12-27 17:20:26 <sipa> maybe have a configurable score for "not reachable or otherwise suspicious connection", also counting as a negative score
872 2011-12-27 17:22:24 <luke-jr> gmaxwell: if you want to review it, I have a pending pull request that enables better control over txn fees in bitcoind
873 2011-12-27 17:22:37 <gmaxwell> luke-jr: Sure.
874 2011-12-27 17:22:56 <gmaxwell> Is there any way I can get some kind of feed of pull requests on bitcon?
875 2011-12-27 17:23:11 <luke-jr> I wish
876 2011-12-27 17:23:20 <devrandom> sipa: ok
877 2011-12-27 17:25:24 <roconnor> if (opcode > OP_16 && ++nOpCount > 201)
878 2011-12-27 17:25:37 <roconnor> seriously ... can you make this code any more obtuse?
879 2011-12-27 17:25:46 <edcba> it's not obtuse imo
880 2011-12-27 17:25:55 eueueue has joined
881 2011-12-27 17:25:57 <roconnor> using short circut && to decide if nOpCount is incremented?!
882 2011-12-27 17:26:00 <gmaxwell> edcba: some people don't like early out operations.
883 2011-12-27 17:26:16 <edcba> ok the problem is &&
884 2011-12-27 17:26:22 <gmaxwell> roconnor: sure, because the lower opcodes are just the pushes no?
885 2011-12-27 17:26:34 <edcba> so 5000 push is ok ?
886 2011-12-27 17:26:36 <gmaxwell> edcba: funny that you said it was obtuse when you were misreading it yourself. :)
887 2011-12-27 17:26:54 <edcba> i was reading it correctly but i didn't see it was a problem
888 2011-12-27 17:27:22 <edcba> also magic constant
889 2011-12-27 17:27:24 <edcba> again :)
890 2011-12-27 17:27:25 <gmaxwell> roconnor: just think of it as keeping you on your toes. :)
891 2011-12-27 17:27:45 <roconnor> gmaxwell: I'm okay with the semantics of the code; I just think it is written in a very confusing way that is hard to interpret.
892 2011-12-27 17:28:09 <sipa> roconnor: there should be a specification that detrmines all conditions
893 2011-12-27 17:28:22 MarquisdeBitcoin is now known as phungus
894 2011-12-27 17:28:36 <sipa> so you don't need to dig in the code to find these things
895 2011-12-27 17:28:44 <edcba> haha
896 2011-12-27 17:28:55 * edcba writing a documentation at work
897 2011-12-27 17:29:10 <edcba> usually it's better to write it before coding :(
898 2011-12-27 17:31:53 Sedra- has joined
899 2011-12-27 17:32:10 Sedra has quit (Read error: Connection reset by peer)
900 2011-12-27 17:34:09 <devrandom> TD: did you see the go client?
901 2011-12-27 17:34:22 <sipa> how finished is gobtc?
902 2011-12-27 17:34:35 <TD> i did
903 2011-12-27 17:35:38 <devrandom> TD: any early impressions?
904 2011-12-27 17:36:06 <gmaxwell> sipa: "features: basic parsing of version cmd"
905 2011-12-27 17:36:17 <sipa> haha
906 2011-12-27 17:36:34 <sipa> even bitcoin-seeder already supports "version", "verack" and "addr" !
907 2011-12-27 17:36:35 <TD> just a sec
908 2011-12-27 17:36:44 <roconnor> gmaxwell: that's where I started!
909 2011-12-27 17:37:08 <gmaxwell> yea, heh. I'm not insulting it, just answering SIPA's question. :)
910 2011-12-27 17:37:10 <devrandom> just looked at it, it seems like very early boilerplate
911 2011-12-27 17:37:17 <sipa> (~)disclaimer: i copied some code from the satoshi codebase...
912 2011-12-27 17:37:22 <gmaxwell> boooo
913 2011-12-27 17:38:00 <roconnor> sipa: you can do that?
914 2011-12-27 17:38:08 <sipa> why not?
915 2011-12-27 17:38:30 <roconnor> because go is a different langauge from C++
916 2011-12-27 17:38:39 eueueue has quit (Ping timeout: 240 seconds)
917 2011-12-27 17:39:18 <roconnor> heh, OP_CODESEPARATOR is really beginning to piss me off :P
918 2011-12-27 17:39:21 <sipa> roconnor: i was talking about my own project, bitcoin-seeder, zhich is in C++, sorry
919 2011-12-27 17:39:27 <roconnor> ah
920 2011-12-27 17:39:32 <roconnor> makes more sense
921 2011-12-27 17:40:53 <TD> roconnor: yeah, if you figure out what it's useful for, let me know :)
922 2011-12-27 17:41:10 <sipa> afaik nobody found a use for it
923 2011-12-27 17:41:38 <sipa> TD: what's your opinion about the usefulness of different txhash types?
924 2011-12-27 17:42:18 <roconnor> I have a plan to staticly enforce well-balaned IF statements, but the OPCODESEPARATOR means that unbalanced scripts may be used in the hashing.
925 2011-12-27 17:42:30 <roconnor> so I have to find some way to support that
926 2011-12-27 17:42:41 <roconnor> or drop my idea of statically enforcing well-balanced IF statements.
927 2011-12-27 17:43:09 <roconnor> or something else
928 2011-12-27 17:45:17 chrisb__ has quit (Quit: Ex-Chat)
929 2011-12-27 17:45:26 <sipa> roconnor: wouldn't enforcing that potentially cause a block chain split, if others don't enforce it?
930 2011-12-27 17:45:57 <roconnor> sipa: the protocol does enforce it at the moment
931 2011-12-27 17:47:02 <roconnor> At the end of evalScript we have
932 2011-12-27 17:47:14 <TD> sipa: there are use cases for them on the contracts page
933 2011-12-27 17:47:17 <roconnor> if (!vfExec.empty())
934 2011-12-27 17:47:18 <roconnor> return false;
935 2011-12-27 17:47:40 <roconnor> which means that if all the if statements haven't been endif'd then we return false
936 2011-12-27 17:48:12 <roconnor> sipa: In my proposed implementation we would fail at parse time rather than failing at the end of execution time.
937 2011-12-27 17:48:59 <luke-jr> what if the code inside the block, that never gets executed, fails to parse?
938 2011-12-27 17:49:09 <roconnor> sipa: and moreover would mean that one couldn't use my library to build scripts that are unbalanced. The code wouldn't compile.
939 2011-12-27 17:49:48 <sipa> roconnor: i was already thinking about building up an expression tree from a script (dynamically), and then lazyly evaluate it, taking costs for evaluation into accountµ
940 2011-12-27 17:49:48 <roconnor> luke-jr: all code is eventually parsed in the standard client even when inside an unexcuted branch.
941 2011-12-27 17:49:52 <devrandom> right... there could be a stray IF inside an IF that has a false input
942 2011-12-27 17:50:00 <roconnor> luke-jr: in fact it has to be parsed in order to find the OP_ENDIF
943 2011-12-27 17:50:26 <devrandom> ah, yes
944 2011-12-27 17:51:50 <sipa> TD: i must admit taht contracts is something i haven't thought about enough yet, but would things become impossible if everything was SIGHASH_NONE?
945 2011-12-27 17:53:00 <TD> you mean sighash_all ?
946 2011-12-27 17:53:04 <TD> that's the default
947 2011-12-27 17:53:20 <TD> yeah some contracts wouldn't work. i mean, you'd need trusted intermediaries instead of using the protocol features
948 2011-12-27 17:53:25 <TD> i'd actually like to see more sighash modes.
949 2011-12-27 17:53:39 erus` has joined
950 2011-12-27 17:53:45 <TD> but too late now.
951 2011-12-27 17:53:48 <TD> given that people don't upgrade :-)
952 2011-12-27 17:53:55 <roconnor> I use random sighash values in my client
953 2011-12-27 17:54:01 <sipa> what would you add?
954 2011-12-27 17:54:08 <gmaxwell> well, we've hardly tried to make people upgrade yet.
955 2011-12-27 17:54:30 <TD> one that doesn't cover the outpoints, so you could connect a transaction to a different transaction without needing to resign
956 2011-12-27 17:55:00 <devrandom> could hang up on really old versions to motivate people
957 2011-12-27 17:55:18 <gmaxwell> devrandom: just sending an alert is likely enough.
958 2011-12-27 17:55:18 <sipa> they may end up connecting to themselves
959 2011-12-27 17:55:25 <sipa> in their own little world
960 2011-12-27 17:55:31 <gmaxwell> yea, don't partition the network please. :)
961 2011-12-27 17:55:33 <roconnor> nHashType = rand() & 0xff;
962 2011-12-27 17:55:35 <roconnor> nHashType ^= nHashType & SIGHASH_ANYONECANPAY;
963 2011-12-27 17:55:38 <roconnor> is the code I use
964 2011-12-27 17:55:53 <sipa> roconnor: huh, why?
965 2011-12-27 17:56:08 <TD> that's kind of stupid
966 2011-12-27 17:56:10 <roconnor> to mess with the protocol
967 2011-12-27 17:56:25 <roconnor> because you guys aren't checking for invalid hashTypes
968 2011-12-27 17:56:33 <TD> well, it's treated as a bitmask
969 2011-12-27 17:56:42 <gmaxwell> "This is why we can't have nice things"
970 2011-12-27 17:56:52 <TD> but it does make it a bit more annoying to add extra flags in future. though i doubt it will happen
971 2011-12-27 17:56:57 <roconnor> gmaxwell: yep
972 2011-12-27 17:57:00 <TD> the use cases are obscure enough it's not worth a chain split
973 2011-12-27 17:57:18 <roconnor> gmaxwell: I've only infected testnet
974 2011-12-27 17:58:12 <roconnor> I personally want the bitcoin developers to stop messing around with extensions to the protocol and fix the current one.
975 2011-12-27 17:58:41 <sipa> what would fix mean? formal specification? major revision?
976 2011-12-27 17:58:49 <roconnor> and since the developers (and people in general) are reactive instead of proactive, I figure this is the best way to get attention to the problems.
977 2011-12-27 17:59:30 <roconnor> sipa: formal specification; thinking about what can go wrong, and fixing things like: checking for valid version numbers or valid hashTypes
978 2011-12-27 17:59:48 <roconnor> actually an informal spec would probably work too
979 2011-12-27 17:59:59 <roconnor> anything to get people to think through the corner cases of the protocol.
980 2011-12-27 18:00:16 <nathan7> We informally have a bunch of ninjas staged all over the world who kill anyone who fucks with the network.
981 2011-12-27 18:01:02 <roconnor> But, I have no stake in bitcoin, so I don't know how much influence I should have.
982 2011-12-27 18:02:17 * roconnor also uses nVersion = rand();
983 2011-12-27 18:03:26 <sipa> roconnor: you could have posted an issue about the lack of checks on that part
984 2011-12-27 18:03:53 <roconnor> sipa: all that will do is fix the particular problems I know about.
985 2011-12-27 18:03:57 <sipa> that clearly deserves attention, but if people have to wait until they see a strange transaction from you, we can wait for a long time
986 2011-12-27 18:04:13 <roconnor> sipa: I've put these transactions in testnet months ago
987 2011-12-27 18:04:20 <sipa> and nobody notices
988 2011-12-27 18:04:22 <roconnor> well maybe 1 month ago
989 2011-12-27 18:04:57 <sipa> i think you're in a particularly interesting position as you're reverse engineering the protocol
990 2011-12-27 18:04:58 <roconnor> all me posting these problems will do is get them to fix them. I'm more concered about the problems I don't know about.
991 2011-12-27 18:05:02 <sipa> but please, share what you learn
992 2011-12-27 18:05:40 <roconnor> that timewarp attack is pretty devistating
993 2011-12-27 18:05:50 <sipa> and so easily fixed
994 2011-12-27 18:06:09 <roconnor> Gavin is wrong when he says that a 50%+1 attacker would be motived to help the network rather than attack
995 2011-12-27 18:06:28 <gmaxwell> sipa: Except for that whole not forking it.
996 2011-12-27 18:06:35 <roconnor> with the timewarp bug, an 50%+1 attack can quickly acquire essentialy all bitcoins
997 2011-12-27 18:06:54 <roconnor> If I understand well
998 2011-12-27 18:06:54 <gmaxwell> roconnor: yes, which is not all that valuable to the attacker.
999 2011-12-27 18:06:57 <sipa> gmaxwell: that's as much a problem as getting OP-eval accepted zithout forkingµ
1000 2011-12-27 18:07:09 <roconnor> gmaxwell: it would destroy bitcoin
1001 2011-12-27 18:07:35 <gmaxwell> sipa: you think? old nodes will happily ignore op-eval forever.
1002 2011-12-27 18:08:03 <gmaxwell> but if you fix the offby one they'll fall off onto their own fork.
1003 2011-12-27 18:08:11 <sipa> http://sourceforge.net/mailarchive/message.php?msg_id=28365241
1004 2011-12-27 18:08:27 <roconnor> gmaxwell: I recall sipa had some ideas for backwards compatiable fixes
1005 2011-12-27 18:08:32 <sipa> i've posted a solution that's backward compatible and would imho fix the problem
1006 2011-12-27 18:09:14 <gmaxwell> sipa: I saw that before, and forgot about it.
1007 2011-12-27 18:09:25 <sipa> but nobody reacts
1008 2011-12-27 18:09:45 <roconnor> sipa: people only will react after an 50%+1 attack
1009 2011-12-27 18:10:05 <roconnor> where is only [Tycho] can help
1010 2011-12-27 18:10:06 <sipa> there was a lot of talk about the timejacking issue
1011 2011-12-27 18:10:07 <roconnor> er
1012 2011-12-27 18:10:10 <roconnor> only [Tycho] can help
1013 2011-12-27 18:10:22 <gmaxwell> I was mostly distracted by luke whining about tighter time clamping in general.
1014 2011-12-27 18:10:26 <sipa> but by the time i proposed a solution, it seems almost everybody forgot about it
1015 2011-12-27 18:11:42 <roconnor> everytime someone claims a 50%+1 attacker would rather cooperate with the network, you guys need to call out on this issue.
1016 2011-12-27 18:12:20 <sipa> i guess i should just implement it
1017 2011-12-27 18:13:45 <[Tycho]> Hello.
1018 2011-12-27 18:14:05 <roconnor> [Tycho]: I'd like you to implement a 50% + 1 timewarp attack so we can get this bug fixed.
1019 2011-12-27 18:14:24 <roconnor> though I don't seriously expect to you to agree to do this.
1020 2011-12-27 18:14:31 <[Tycho]> Which bug ?
1021 2011-12-27 18:15:08 <roconnor> that bug that destroyed that gestgeld(?) alt-chain.
1022 2011-12-27 18:15:28 <gmaxwell> roconnor: I agree that it needs to be fixed, I think you're overstating the consequences. Someone with a super majority can also just refuse to process transactions. At least in the timewarp cases the good nodes could just fix the bug and cut off the trixster's fork.
1023 2011-12-27 18:15:34 <[Tycho]> ArtForz's attack ?
1024 2011-12-27 18:15:43 <gmaxwell> [Tycho]: yes, thats what he's talking about.
1025 2011-12-27 18:16:15 <[Tycho]> Does it works with 2-week difficulty adjustment window ?
1026 2011-12-27 18:16:29 wasabi2 has joined
1027 2011-12-27 18:16:52 <gmaxwell> roconnor: my reason for saying it should be fixed is because it adds to the very short list of things a 50% attacker can do, and that it makes it harder to reason about the security as a result.
1028 2011-12-27 18:16:56 <gmaxwell> [Tycho]: sure.
1029 2011-12-27 18:17:44 wasabi has quit (Ping timeout: 252 seconds)
1030 2011-12-27 18:17:54 <gmaxwell> [Tycho]: it lets someone with >50% hashpower drive down the difficulty while maintaining the longest chain.
1031 2011-12-27 18:18:11 <gmaxwell> so they cause inflation as they capture more and more coins.
1032 2011-12-27 18:18:14 da2ce7 has joined
1033 2011-12-27 18:18:24 <[Tycho]> Scary.
1034 2011-12-27 18:18:42 <roconnor> gmaxwell: worse, the can rewrite the entire blockchain taking all the coins ever created
1035 2011-12-27 18:18:51 <roconnor> and ever will be created
1036 2011-12-27 18:19:01 <roconnor> If I understand well
1037 2011-12-27 18:19:22 <gmaxwell> roconnor: no, not any more than normally.
1038 2011-12-27 18:19:30 Detritus has joined
1039 2011-12-27 18:19:32 <gmaxwell> roconnor: the criteria for longest chain is highest sum difficulty.
1040 2011-12-27 18:19:50 <gmaxwell> roconnor: they can't rewrite the past chain without doing work greater than it in sum difficulty.
1041 2011-12-27 18:19:51 <sipa> they can always rewrite the entire chain
1042 2011-12-27 18:20:12 <sipa> but what the timejacking issue allows is having them generate all further minable funds more quickly
1043 2011-12-27 18:20:29 <roconnor> right
1044 2011-12-27 18:20:44 <[Tycho]> Well, may be I'll be able to sell you special boxes for this, next year :)
1045 2011-12-27 18:20:52 <roconnor> heh
1046 2011-12-27 18:21:35 <gmaxwell> sipa: unfortunately the altcoins just fixed it directly so we can't use them as test victims^wsubjects for your fix.
1047 2011-12-27 18:21:38 <[Tycho]> Also there are some hardcoded checkpoints, AFAIR.
1048 2011-12-27 18:21:41 <roconnor> how about we write timejacking mode software for your boxes. You can add a switch to the box: destroy bitcoin <----> don't destroy bitcoin
1049 2011-12-27 18:22:01 <gmaxwell> [Tycho]: yea, but the checkpoints aren't relevant here.
1050 2011-12-27 18:22:22 <roconnor> that's true, you couldn't easily go past the checkpoints, but you'd still get all future coins
1051 2011-12-27 18:22:28 <gmaxwell> roconnor was mistaken about there being increased rewrite risk here.
1052 2011-12-27 18:23:34 da2ce7 has quit (2!~da2ce7@gateway/tor-sasl/da2ce7|Ping timeout: 276 seconds)
1053 2011-12-27 18:23:35 davout has joined
1054 2011-12-27 18:23:42 <[Tycho]> Who would need those coins anyway ?
1055 2011-12-27 18:24:32 <gmaxwell> The checkpoints aren't there to prevent rewrites, though they do as a side effect, they're mostly useful to prevent disk space exaustion attacks. (e.g. I feed you a 100000 block long chain of 1mb blocks starting at block 1, all with difficulty 1)
1056 2011-12-27 18:25:05 <gmaxwell> (such a chain wouldn't be the longest, but you'd maintain it on disk just in case it became the longest)
1057 2011-12-27 18:25:15 <roconnor> oh?
1058 2011-12-27 18:25:39 <roconnor> shit
1059 2011-12-27 18:27:27 <gmaxwell> (even the most recent checkpoints are far enough back that catching up to them even with hash power twice the network would take a long timeâ and for that purpose you only need the most recent one)
1060 2011-12-27 18:27:53 <gmaxwell> [Tycho]: thats basically gavin's argument. That someone wouldn't perform the attack because it would make the resulting coins worthless.
1061 2011-12-27 18:28:26 <roconnor> if checkpointing is needed to make the protocol workable, then I'll give up on bitcoin
1062 2011-12-27 18:28:36 <roconnor> it is no longer decentralized
1063 2011-12-27 18:28:50 <gmaxwell> ...
1064 2011-12-27 18:29:12 <gmaxwell> roconnor: I think you need to take a break. Your every response is coming off as needlessly emotional.
1065 2011-12-27 18:29:40 <roconnor> it is not decentralized if the client requires checkpoints
1066 2011-12-27 18:29:43 davout has quit (Remote host closed the connection)
1067 2011-12-27 18:29:43 <gmaxwell> roconnor: for anti-DOS the checkpoints don't have to come from any particular source.
1068 2011-12-27 18:29:44 <roconnor> this is a fact.
1069 2011-12-27 18:29:59 <luke-jr> sipa: what solution?
1070 2011-12-27 18:30:31 <roconnor> gmaxwell: maybe you are right about taking a break.
1071 2011-12-27 18:30:43 <luke-jr> [13:21:41] <gmaxwell> The checkpoints aren't there to prevent rewrites, though they do as a side effect, they're mostly useful to prevent disk space exaustion attacks. (e.g. I feed you a 100000 block long chain of 1mb blocks starting at block 1, all with difficulty 1)
1072 2011-12-27 18:30:49 <luke-jr> gmaxwell: that's not what it was originally for, no
1073 2011-12-27 18:30:53 <luke-jr> that was only recently added
1074 2011-12-27 18:31:17 <gmaxwell> There is another attack they also close which I should have mentioned.
1075 2011-12-27 18:31:23 <gmaxwell> Which is the new node boostraping issue.
1076 2011-12-27 18:32:08 <gmaxwell> e.g. you isolate the network of a mind wiped node, then feed it a fake diff 1 chain.
1077 2011-12-27 18:33:01 <gmaxwell> luke-jr: checkpoints do prevent that, gavin recently added additional protection against that.
1078 2011-12-27 18:34:54 storrgie has quit (Quit: Leaving)
1079 2011-12-27 18:35:14 <gmaxwell> luke-jr: here is an email I sent to ben laurie months ago, responding to his assertions that bitcoin wasn't decenteralized because of checkpoints. http://people.xiph.org/~greg/bc_checkpoints.txt
1080 2011-12-27 18:35:55 <luke-jr> gmaxwell: that is to roconnor
1081 2011-12-27 18:37:43 <gmaxwell> In it, I raise both the exaustion attack and the new nodes attacks as reasons for checkpoints that have nothing to do with rewriting. And I point out that the cheapest rewriting attack a checkpoint would protect you from at that time would require astronomical energy use.
1082 2011-12-27 18:41:27 <gmaxwell> roconnor: you may find the paper linked from that link interesting (even if it makes you more unhappy :( ), and perhaps my rather long winded response to it.
1083 2011-12-27 18:41:55 <roconnor> I think I've read that PDF
1084 2011-12-27 18:42:46 <roconnor> I'm not convinced from your response that checkpointing doesn't make bitcoin not decentralzied.
1085 2011-12-27 18:42:50 <roconnor> um
1086 2011-12-27 18:42:59 <roconnor> there were a lot of nots in that sentence :)
1087 2011-12-27 18:43:26 <roconnor> Before I thought checkpointing was just harmless paranoia
1088 2011-12-27 18:43:58 <roconnor> but if clients must checkpoint ... that is a whole new ball game for me.
1089 2011-12-27 18:44:58 <gmaxwell> I think gavin's recent anti-ddos stuff closes the space exaustion attack without checkpoints.
1090 2011-12-27 18:45:17 <gmaxwell> But I haven't had time to give it serious thought.
1091 2011-12-27 18:45:17 <roconnor> oh?
1092 2011-12-27 18:45:21 <roconnor> thats good
1093 2011-12-27 18:45:34 <roconnor> how does it work?
1094 2011-12-27 18:48:35 <gmaxwell> It adds plausablity checks to the pow values on orphan blocks that are disconnected from the current longest chain. I don't recall the details.
1095 2011-12-27 18:48:51 <roconnor> sounds reasonable
1096 2011-12-27 18:50:55 <roconnor> hey, I just realized that I don't ever have to implement OP_EVAL if I don't want to
1097 2011-12-27 18:50:58 <roconnor> that's nice
1098 2011-12-27 18:51:25 copumpkin is now known as scamubtc4pp
1099 2011-12-27 18:51:38 <gmaxwell> right, you can keep treating it as a noop. Though nodes with your code wouldn't provide security for those transactions.
1100 2011-12-27 18:52:12 <roconnor> as long as no miners use my code it is fine.
1101 2011-12-27 18:53:36 <gmaxwell> I think miners should use multi-node decision making.. don't mine a txn unless all N of N implementations like it. :)
1102 2011-12-27 18:53:59 <gmaxwell> but for that there needs to exist multiple implementations. :)
1103 2011-12-27 18:54:10 <TD> i'm making bitcoinj broadcast relevant (to the wallet) transactions. pro: improved robustness and tx propagation. con: a malicious peer that you connect to and which knows one of your keys could flood you off the network/get you banned
1104 2011-12-27 18:54:46 devrandom has quit (Ping timeout: 276 seconds)
1105 2011-12-27 18:54:51 <gmaxwell> TD: rate limit the flooding.
1106 2011-12-27 18:56:18 devrandom has joined
1107 2011-12-27 18:56:24 <gmaxwell> TD: wrt 'knows', without countermeasures it wouldn't be too terribly hard to take all the addresses seen in the blockchain and cycle them through such a node to see what they forward. Then use them as spam multipliers.
1108 2011-12-27 18:57:09 <sipa> luke-jr: limiting time of multiple-of-2016 blocks to be strivtly more that that of the previous 11 blocks
1109 2011-12-27 18:57:41 <TD> that's a lot of addresses
1110 2011-12-27 18:58:04 <TD> you might as well just connect to all the nodes you want to annoy directly
1111 2011-12-27 18:58:11 <TD> (with a botnet)
1112 2011-12-27 18:58:22 <TD> but rate limiting is a good idea regardless
1113 2011-12-27 18:59:37 <gmaxwell> sipa: I think it should be min(max(median(last)+1,current_time),current_time+7200),max(last)+1)
1114 2011-12-27 19:00:11 <gmaxwell> sipa: e.g. it should be allowed to violate the +7200 in order to meet the max(last)+1 constraint.
1115 2011-12-27 19:00:59 <gmaxwell> sipa: so that someone mining a current_time+7200 block doesn't stop you from processing for a second, no? (your block will eventually become valid)
1116 2011-12-27 19:01:09 <gmaxwell> (probably before you actually solve it)
1117 2011-12-27 19:02:18 <gmaxwell> alternatively the current_time+7200 check at input should be reduced to current_time+7200-1.
1118 2011-12-27 19:05:37 <luke-jr> sipa: that sounds like asking for trouble
1119 2011-12-27 19:06:52 <gmaxwell> luke-jr: why? Not fixing the attack is asking for troubleâ¦
1120 2011-12-27 19:08:12 AlexWaters has quit (Disconnected by services)
1121 2011-12-27 19:08:18 TD has quit (Quit: TD)
1122 2011-12-27 19:08:50 AlexWaters1 has joined
1123 2011-12-27 19:10:19 DivineOmega has joined
1124 2011-12-27 19:12:40 slush has quit (Ping timeout: 240 seconds)
1125 2011-12-27 19:14:04 <luke-jr> gmaxwell: I'm not sure how that would fix it
1126 2011-12-27 19:16:59 <gmaxwell> luke-jr: because the actual attack requires the 2016 block to timewarp with respect to the prior ones. Or at least, it stops the pattern of timestamps that _I'd_ use for the attack. I haven't given it enough though yet to figure out if there is some other pattern which would work.
1127 2011-12-27 19:17:25 <luke-jr> gmaxwell: couldn't the attacker just adjust 12 blocks instead of 1, to get around it?
1128 2011-12-27 19:17:53 slush has joined
1129 2011-12-27 19:20:03 <gmaxwell> the attack works by making the end of one window not overlap with the next. By tying multiple blocks togeather you make the windows overlap
1130 2011-12-27 19:21:02 <gmaxwell> without the bug lying about timestamps wins you nothing because the cheating you do now you pay for later (well, you can steal the maximum forward shift for free but only once)
1131 2011-12-27 19:21:17 b4epoche_ has joined
1132 2011-12-27 19:21:26 <gmaxwell> E.g. staying this 2016-cycle took longer than it did would make you say the next took less than it did by the same amount.
1133 2011-12-27 19:21:32 <gmaxwell> s/staying/saying/
1134 2011-12-27 19:22:16 b4epoche has quit (Ping timeout: 252 seconds)
1135 2011-12-27 19:22:16 <gmaxwell> But the bug means that they don't really overlap, you can hop a block into the future and not have it count in the next cycle.
1136 2011-12-27 19:22:17 b4epoche_ is now known as b4epoche
1137 2011-12-27 19:22:45 * gmaxwell bbl
1138 2011-12-27 19:25:12 marf_away has quit (Ping timeout: 248 seconds)
1139 2011-12-27 19:26:57 DivineOmega has quit (Quit: Bye)
1140 2011-12-27 19:27:49 imsaguy is now known as IamDeadSexC
1141 2011-12-27 19:27:57 antix has joined
1142 2011-12-27 19:31:00 <midnightmagic> i thought the 2016th block still has to be within the (2016-1),(2016+1) timestamp window
1143 2011-12-27 19:31:43 <midnightmagic> just within that you can put it anywhere and therefore make it slightly easier on yourself to overtake the network.
1144 2011-12-27 19:32:10 gjs278 has quit (Remote host closed the connection)
1145 2011-12-27 19:32:16 antix is now known as malfy
1146 2011-12-27 19:35:21 TD has joined
1147 2011-12-27 19:35:51 <luke-jr> gmaxwell: oh, I see. wouldn't just the last 1 block be sufficient then?
1148 2011-12-27 19:36:42 TheZimm has quit (Quit: Computer has gone to sleep.)
1149 2011-12-27 19:39:21 davout has joined
1150 2011-12-27 19:43:48 scamubtc4pp is now known as copumpkin
1151 2011-12-27 19:46:14 chrisb__ has joined
1152 2011-12-27 19:49:21 <roconnor> [12:53] <gmaxwell> "This is why we can't have nice things"
1153 2011-12-27 19:49:43 <roconnor> on occasion my messing aroung produces nice things too: like compressed public keys =)
1154 2011-12-27 19:52:24 <Diablo-D3> [02:07:52] <Diablo-D3> this is strange
1155 2011-12-27 19:52:24 <Diablo-D3> [02:07:57] <Diablo-D3> I cant change my fan speed
1156 2011-12-27 19:52:24 <Diablo-D3> [02:08:05] <Diablo-D3> cant do it in windows either
1157 2011-12-27 19:52:59 dissipate has joined
1158 2011-12-27 19:53:05 RazielZ has quit (Ping timeout: 252 seconds)
1159 2011-12-27 19:54:14 RazielZ has joined
1160 2011-12-27 20:05:29 TheZimm has joined
1161 2011-12-27 20:11:09 <gmaxwell> midnightmagic: overtake the network is irrelevant.
1162 2011-12-27 20:11:32 <gmaxwell> midnightmagic: if you don't have enough hash power to produce a chain with higher sum difficulty you won't over take it.
1163 2011-12-27 20:11:47 <gmaxwell> midnightmagic: doesn't matter if you've made a chain with a zillion diff 1 blocks.
1164 2011-12-27 20:12:35 <gmaxwell> luke-jr: yes. In my mind using max(last,median(last_11))+1 there would be okay.
1165 2011-12-27 20:12:54 <gmaxwell> oh no. It wouldn't.
1166 2011-12-27 20:13:53 <gmaxwell> the reason to use a big group is so that you end up bounding the median used on the next block.
1167 2011-12-27 20:14:03 TheZimm has quit (Quit: Computer has gone to sleep.)
1168 2011-12-27 20:14:13 <gmaxwell> meh. I need to sit down and actually write it up to be sure. I'm having a tough time reasoning about it.
1169 2011-12-27 20:14:36 malfy is now known as predator
1170 2011-12-27 20:15:47 DontMindMe2 has quit (Quit: Nettalk6 - www.ntalk.de)
1171 2011-12-27 20:16:52 <midnightmagic> gmaxwell: That's the point. The fact that the 2016th block is mobile means it's slightly easier, but not by much. It would've made the attack on namecoin easier, but whoever that was behind that threat, they chickened out.
1172 2011-12-27 20:17:33 <midnightmagic> gmaxwell: So I'm curious now what you're talking about re: overlap. Is my understanding still accurate? the 2016th block is mobile re: timstamp, but not outside of the (2016-1),(2016+1) range, correct?
1173 2011-12-27 20:18:54 <gmaxwell> midnightmagic: overtaking has nothing to do with timestamps. The timestamps aren't involved in the longest chain calculations.
1174 2011-12-27 20:19:48 <midnightmagic> ... then how does it know how many blocks at diff X happened within the timespan of the retarget?
1175 2011-12-27 20:20:13 <midnightmagic> you are talking about the 2016th block missing from the retarget calc, right?
1176 2011-12-27 20:20:31 <gmaxwell> Yes. And I'm saying this has _nothing_ to do with overtaking the good chain.
1177 2011-12-27 20:21:41 <gmaxwell> The attack permitted by the missing gap in the retarget calc is that someone with a super majority of the hashpower can inflate the currency.
1178 2011-12-27 20:22:06 da2ce7 has joined
1179 2011-12-27 20:24:04 <gmaxwell> speaking of that, wtf purpose does this serve except enabling attacks: https://bitcointalk.org/index.php?topic=55819.msg664029#msg664029
1180 2011-12-27 20:24:22 <roconnor> sipa: Oh I did post about checking version number and hashtypes in: https://github.com/bitcoin/bitcoin/issues/317
1181 2011-12-27 20:24:30 <midnightmagic> isn't.. that.. overtaking the chain? and.. wouldn't that mean that someone could rewrite past history *more easily* than they could otherwise?
1182 2011-12-27 20:24:39 <roconnor> sipa: and now I've posted such transactions and block in the testnet
1183 2011-12-27 20:25:03 <roconnor> sipa: Maybe I could make a patch; but I expect it would be ignored too
1184 2011-12-27 20:25:15 <gmaxwell> midnightmagic: No. Sigh. I'm sorry, bad day. I'm not communicating effectively at all.
1185 2011-12-27 20:25:17 <roconnor> gmaxwell: oh maybe this should be directed at you
1186 2011-12-27 20:25:20 <sipa> roconnor: if it's up to me, it won't
1187 2011-12-27 20:25:51 <roconnor> sipa: do I have to use git to make a patch?
1188 2011-12-27 20:25:53 <midnightmagic> gmaxwell: hey join the club, I started a huge 5-ft grease fire last night and burned the fuck out of my wrist
1189 2011-12-27 20:26:12 <midnightmagic> "must.. save.. the bacon.."
1190 2011-12-27 20:26:26 <sipa> roconnor: you can send a patch by mail as well, but once you're used to it, git is vastly easier :)
1191 2011-12-27 20:26:34 <roconnor> midnightmagic: is the bacon safe?
1192 2011-12-27 20:27:05 <midnightmagic> no, bacon was crisped. total, epic fail, there was like 20 lbs of it and it'd been curing for days
1193 2011-12-27 20:27:11 dissipate has quit (Ping timeout: 252 seconds)
1194 2011-12-27 20:27:13 <gmaxwell> midnightmagic: Soâ first, when picking the longest chain nodes use sum-difficulty. So you can't overtake the chain without actually doing more computation in your fork vs what you're trying to beat(well plus luck).
1195 2011-12-27 20:27:19 <sipa> midnightmagic: to overtakr the network, you need to do as much *work* as was done to create the chain
1196 2011-12-27 20:27:25 <midnightmagic> special rub, mustard seed, peppercorn, rosemary, molasses. :(
1197 2011-12-27 20:27:27 <sipa> midnightmagic: sorry, to rewrite the chain
1198 2011-12-27 20:27:32 <gmaxwell> midnightmagic: e.g. if I handed you a chain with a million diff 1 blocks it wouldn't be longer than the current chain.
1199 2011-12-27 20:27:41 <sipa> midnightmagic: irrelevant whether those are many low-diff blocks or a few high-diff blocks
1200 2011-12-27 20:27:57 <sipa> midnightmagic: timewarp allows you to have more low-diff blocks, thus more mining income
1201 2011-12-27 20:28:06 <sipa> but not change the amount of work in the chain
1202 2011-12-27 20:28:21 <gmaxwell> midnightmagic: what this attack allows someone to do is to write a chain with the same sum work as you would have if you were not cheating, but have that work in the form of low diff blocks.. more blocks means more coins.
1203 2011-12-27 20:28:28 <midnightmagic> hrm..
1204 2011-12-27 20:28:48 <gmaxwell> But you can only do this attack if you have a majority of the hash power, since blocks from other miners in your chain will goof up your fun and games.
1205 2011-12-27 20:29:22 <copumpkin> nobody tell [Tycho]
1206 2011-12-27 20:29:23 <midnightmagic> okay, i grok. thanks.
1207 2011-12-27 20:29:24 <copumpkin> oh shit
1208 2011-12-27 20:29:30 <[Tycho]> Hello.
1209 2011-12-27 20:29:32 <gmaxwell> the protocol continues to work as normal, but we go off the inflation schedule.
1210 2011-12-27 20:29:32 <roconnor> copumpkin: I already asked [Tycho]
1211 2011-12-27 20:29:38 <Diablo-D3> so no one is having fan speed control problems on 11.12?
1212 2011-12-27 20:29:54 <roconnor> [13:11] <roconnor> [Tycho]: I'd like you to implement a 50% + 1 timewarp attack so we can get this bug fixed.
1213 2011-12-27 20:30:14 <copumpkin> aha
1214 2011-12-27 20:30:27 <gmaxwell> Gavin's argument that this was irrelevant was basically that if you did this you'd destroy confidence in bitcoin, making your excess coins worthless. I think this is correct. (and if you just wanted to take out bitcoin you could do so by processing no txn at all)
1215 2011-12-27 20:30:45 <Diablo-D3> gmaxwell: I agree with that... but...
1216 2011-12-27 20:30:48 <gmaxwell> Howeverâ I think having to make this argument everytime you explain the security properties of bitcoin sucks.
1217 2011-12-27 20:30:50 <Diablo-D3> some people want to destroy bitcoin anyhow
1218 2011-12-27 20:30:57 <Diablo-D3> no matter the cost
1219 2011-12-27 20:31:03 <Diablo-D3> some people just want to watch the world burn
1220 2011-12-27 20:31:27 <roconnor> bitcoin is hardly the world
1221 2011-12-27 20:31:29 <gmaxwell> Diablo-D3: they do, and if they have and can maintain >>50% of the hashpower we probably can't stop them.
1222 2011-12-27 20:31:36 <roconnor> better to destroy bitcoin earlier than later
1223 2011-12-27 20:32:53 <Diablo-D3> roconnor: I was quoting the line spoken about the Joker
1224 2011-12-27 20:33:00 <Diablo-D3> pay attention
1225 2011-12-27 20:33:10 <roconnor> right
1226 2011-12-27 20:33:15 <gmaxwell> (I mean, there are things you could do with a >>50% attacker that wasn't processing transactions at all... likewise things you could do reactively to a timerwarper)
1227 2011-12-27 20:34:33 <midnightmagic> huh. well then, in that case I don't care about the timewarp bug suddenly.
1228 2011-12-27 20:36:38 <roconnor> gmaxwell: what if [Tycho] decided to move off inflation schedule and just started lowering the difficulty? That could be done right?
1229 2011-12-27 20:36:40 slush has quit (Ping timeout: 248 seconds)
1230 2011-12-27 20:37:03 * [Tycho] is not evil
1231 2011-12-27 20:37:24 <luke-jr> s/not//
1232 2011-12-27 20:37:43 <copumpkin> oh shit
1233 2011-12-27 20:37:47 <copumpkin> luke-jr just made [Tycho] evil
1234 2011-12-27 20:37:49 <copumpkin> now we're done for
1235 2011-12-27 20:37:52 <[Tycho]> luke-jr is evil, he even inserted prayers in his blocks.
1236 2011-12-27 20:38:29 shogun has joined
1237 2011-12-27 20:38:36 * roconnor decides to fiddle with [Tycho]'s NTP connection.
1238 2011-12-27 20:39:00 <gmaxwell> roconnor: well, assuming he had >>50% and so he could choose to split off blocks with timestamps not agreeing with the new inflation schedule.
1239 2011-12-27 20:39:22 <gmaxwell> I don't think you can meaningfully change it unless you can be sure you get that first/last block.
1240 2011-12-27 20:39:40 shogun has left ("Leaving")
1241 2011-12-27 20:47:42 <luke-jr> [Tycho]: prayers are good
1242 2011-12-27 20:47:52 slush has joined
1243 2011-12-27 20:48:00 <copumpkin> only if you pray to a true god
1244 2011-12-27 20:48:09 <copumpkin> luke-jr: I said hi to the false pope the other day
1245 2011-12-27 20:48:20 <[Tycho]> Prayers are related to religion, so it's very evil.
1246 2011-12-27 20:48:35 <luke-jr> [Tycho]: such comments just prove you are evil :P
1247 2011-12-27 20:50:44 wasabi1 has quit (Read error: Connection reset by peer)
1248 2011-12-27 20:51:05 heinz` has joined
1249 2011-12-27 20:53:27 <CIA-100> bitcoin: Gavin Andresen bitcoin2 * rfe358165e3ed bitcoind-personal/src/main.cpp: Be more conservative: check all transactions in blocks after last checkpoint. http://tinyurl.com/7otyswf
1250 2011-12-27 20:53:29 <CIA-100> bitcoin: Gavin Andresen bitcoin2 * r6996a9d7131c bitcoind-personal/src/main.cpp: Check for valid prevout.n in FetchInputs. IsStandardInputs could crash if given invalid input index. http://tinyurl.com/83ajvkd
1251 2011-12-27 20:53:29 <CIA-100> bitcoin: Gavin Andresen bitcoin2 * r60835d962765 bitcoind-personal/src/main.cpp: assert condition in previous commit was backwards http://tinyurl.com/6utmf3v
1252 2011-12-27 20:53:31 <CIA-100> bitcoin: Gavin Andresen bitcoin2 * r61977f956c6b bitcoind-personal/src/main.cpp: Check all prevout.n if one transaction provides multiple inputs http://tinyurl.com/6teg85q
1253 2011-12-27 20:54:14 * luke-jr peers
1254 2011-12-27 20:57:43 dissipate has joined
1255 2011-12-27 20:58:05 * luke-jr wonders where the *actual* commit is
1256 2011-12-27 20:58:53 Sedra has joined
1257 2011-12-27 21:00:11 gavinandresen has joined
1258 2011-12-27 21:00:58 davout has quit (Remote host closed the connection)
1259 2011-12-27 21:01:38 Sedra- has quit (Ping timeout: 252 seconds)
1260 2011-12-27 21:03:08 <CIA-100> bitcoin: Luke Dashjr bitcoin2 * rddc09d3d5423 bitcoind-personal/src/ (init.cpp irc.cpp main.cpp util.cpp): Basic blockchain-forking Bitcoin2 testnet adjustments http://tinyurl.com/7qvq8br
1261 2011-12-27 21:03:40 dissipate has quit (Quit: Leaving)
1262 2011-12-27 21:06:15 hippich has quit (Remote host closed the connection)
1263 2011-12-27 21:07:22 heinz` has left ()
1264 2011-12-27 21:09:39 _Fireball has joined
1265 2011-12-27 21:10:54 wasabi has joined
1266 2011-12-27 21:11:34 theorb has joined
1267 2011-12-27 21:12:09 theorbtwo has quit (Ping timeout: 240 seconds)
1268 2011-12-27 21:15:11 da2ce7 has quit (2!~da2ce7@gateway/tor-sasl/da2ce7|Ping timeout: 276 seconds)
1269 2011-12-27 21:18:00 * gmaxwell cries
1270 2011-12-27 21:18:08 <gmaxwell> roconnor: okay, I give up. You're right bitcoin is doomed.
1271 2011-12-27 21:18:18 <sipa> ?
1272 2011-12-27 21:18:39 <Diablo-D3> doooooooOOOOOOOOOoooOoooooooooomed
1273 2011-12-27 21:19:17 <TD> slush: for your overlay network
1274 2011-12-27 21:19:26 <TD> slush: i don't get what's wrong with just extending the core bitcoin software+protocol?
1275 2011-12-27 21:19:31 <gmaxwell> sipa: someone on the forms has started what is effective a meta pool site that gives rpc miners some fancy stats and pool fail over ability, plus they'll resell your hash power to the highest bidder for you.
1276 2011-12-27 21:19:56 <TD> lol
1277 2011-12-27 21:20:03 <TD> well this is the problem with pools
1278 2011-12-27 21:20:10 <TD> p2pool!
1279 2011-12-27 21:20:14 <Diablo-D3> quickly, to the solo mining cave!
1280 2011-12-27 21:20:14 * sipa wonders whether itĺl be used to crack passwords :D
1281 2011-12-27 21:20:41 <gmaxwell> sipa: and the person running it (pirateat40) can't articulate any legit purpose as to why people would buy hash power at a premium. I suggested it would only be interesting in order to buy power for attacks (e.g. finny/isolated node attacks)
1282 2011-12-27 21:20:51 <gmaxwell> sipa: I'd be fine with that, but it can't do that. It's only for mining.
1283 2011-12-27 21:21:26 <gmaxwell> (well, he's saying now that people will use it to gamble... 0_o)
1284 2011-12-27 21:21:34 <rjk2> so, buy ALL THE HASHPOWERS and rest easy
1285 2011-12-27 21:21:45 <gmaxwell> it would be pretty cool to see a workload agile gpu miner, I don't expect them to exist until fpgas/asics have made gpus otherwise less interesting for mining.
1286 2011-12-27 21:22:11 <slush> TD: did you read the google document? I don't see a point in extending p2p protocol, because it have another purpose
1287 2011-12-27 21:22:18 <TD> yes, i did
1288 2011-12-27 21:22:49 <slush> TD: bitcoin binary protocol from javascript - really?
1289 2011-12-27 21:22:54 <Diablo-D3> rjk2: >all the hashpowers
1290 2011-12-27 21:22:57 <Diablo-D3> rjk2: goddamnit
1291 2011-12-27 21:23:05 <TD> you can do binary in javascript just fine
1292 2011-12-27 21:23:09 <slush> TD I simply think that overlay network is generally a good idea
1293 2011-12-27 21:23:46 <rjk2> Diablo-D3: :-)
1294 2011-12-27 21:25:01 <TD> lightweight+superlightweight clients could just use the regular system with a few extensions. that way, you don't need extra servers - people can just "run bitcoin" and be providing everything the system needs
1295 2011-12-27 21:25:14 <TD> i'm planning on extending bitcoind to support what lightweight clients need at some point (for additional scalability/performance).
1296 2011-12-27 21:25:22 <TD> for superlightweight, it'd need some additional database work
1297 2011-12-27 21:27:05 <[Tycho]> Light clients are cool.
1298 2011-12-27 21:27:23 <[Tycho]> If they don't need special centralized servers to work.
1299 2011-12-27 21:27:44 <gmaxwell> [Tycho]: what if the users can run the "special centralized servers" themselves?
1300 2011-12-27 21:28:07 <gmaxwell> I really wish I could have a single full node at home then run a half dozen superlight clients off it.
1301 2011-12-27 21:28:21 <gmaxwell> having to run a full node for each isolated wallet stinks.
1302 2011-12-27 21:28:31 <[Tycho]> I think that if they need some additional service then usual full nodes should provide it.
1303 2011-12-27 21:29:26 <gmaxwell> [Tycho]: you can make lite clients that don't have to have significant trust in their peersâ or superlight clients that have to trust that the nodes they are talking to trustworthy.
1304 2011-12-27 21:29:46 <gmaxwell> I think both are useful, but they aren't the same.
1305 2011-12-27 21:30:13 <[Tycho]> The most important thing about light client is the ability to send funds in autonomous mode.
1306 2011-12-27 21:31:41 <gavinandresen> Howdy y'all. What'd I miss in the last couple days?
1307 2011-12-27 21:31:50 <[Tycho]> Hello, gavinandresen.
1308 2011-12-27 21:32:09 <luke-jr> gmaxwell: Spesmilo
1309 2011-12-27 21:32:44 <luke-jr> gavinandresen: OP_EVAL being killed off, more or less
1310 2011-12-27 21:32:51 <luke-jr> :P
1311 2011-12-27 21:33:14 <gavinandresen> Mmm. The ++ bug is a very interesting comedy of errors....
1312 2011-12-27 21:33:22 <gmaxwell> gavinandresen: roconnor had decided bitcoin is a bucket of rotten fish guts. :(
1313 2011-12-27 21:33:22 wasabi1 has joined
1314 2011-12-27 21:33:27 <[Tycho]> Which bug ?
1315 2011-12-27 21:33:49 <luke-jr> [Tycho]: DoS exploit basically
1316 2011-12-27 21:33:54 <gavinandresen> My op_eval code wasn't limiting recursion properly.
1317 2011-12-27 21:33:58 <luke-jr> might even affect our pools, actually :/
1318 2011-12-27 21:33:59 <gavinandresen> luke-jr: no, it wouldn't DoS....
1319 2011-12-27 21:34:02 <luke-jr> gavinandresen: no?
1320 2011-12-27 21:34:06 <luke-jr> gavinandresen: what would happen then?
1321 2011-12-27 21:34:15 <luke-jr> unlimited recursion = DoS, afaik
1322 2011-12-27 21:34:26 <[Tycho]> What ++ and where is the fix ?
1323 2011-12-27 21:34:46 <gmaxwell> luke-jr: as sipa pointed out to me before, it's limited by the number of opcodes.
1324 2011-12-27 21:34:55 <luke-jr> hmm
1325 2011-12-27 21:34:57 <gmaxwell> so its not unlimited.
1326 2011-12-27 21:35:06 <luke-jr> gavinandresen: what do you think of my "compromise" btw?
1327 2011-12-27 21:35:15 <gavinandresen> [Tycho]: In script.cpp, case OP_EVAL: change the EvalScriptInner(.... nRecurseDepth++...) to nRecurseDepth+1
1328 2011-12-27 21:35:26 <luke-jr> that is, implementing OP_EVAL on miners only
1329 2011-12-27 21:35:46 <gavinandresen> It wasn't caught by the unit test for a couple of amusing-in-retrospect reasons....
1330 2011-12-27 21:36:04 <TD> not realistic enough?
1331 2011-12-27 21:37:01 <[Tycho]> nRecurseDepth++ used instead of ++nRecurseDepth ?
1332 2011-12-27 21:37:15 <[Tycho]> unit tests are cool...
1333 2011-12-27 21:37:20 <gavinandresen> TD: no, but in the unit test made it behave exactly right (evaluated two OP_EVALs deep then returned 'false')
1334 2011-12-27 21:37:22 wasabi has quit (Ping timeout: 252 seconds)
1335 2011-12-27 21:37:25 <TD> gmaxwell: i'm using "superlightweight" to mean electrum style clients that just send the pubkeys to the server and say "give me something to sign". and lightweight clients ask for blocks (possibly filtered) and process the chain, so they find the transactions themselves.
1336 2011-12-27 21:37:26 <gavinandresen> ^but^bug
1337 2011-12-27 21:37:41 <TD> gavinandresen: ah
1338 2011-12-27 21:37:49 theymos has joined
1339 2011-12-27 21:38:25 <TD> hey theymos
1340 2011-12-27 21:38:26 <gavinandresen> Fixing the unit test so it is correct and it STILL won't fail, because the check for "executed too many operations" kicks in before the stack overflows.
1341 2011-12-27 21:38:27 <theymos> Hi.
1342 2011-12-27 21:38:55 <gavinandresen> ... which is why it isn't a DoS, luke-jr
1343 2011-12-27 21:39:18 <luke-jr> i c
1344 2011-12-27 21:40:05 <gavinandresen> Either our process is working perfectly (all these bugs are shaking out before a rc1 release) or we're doomed. I'm not sure which.
1345 2011-12-27 21:40:33 <sipa> I'd say we were lucky :)
1346 2011-12-27 21:40:36 <TD> i guess it depends how the bugs were found :)
1347 2011-12-27 21:40:37 <gmaxwell> roconnor thinks we're doomed, but I think his perspective is distortedâ he's not realizing that he's part of the machine. :)
1348 2011-12-27 21:40:44 <TD> heh
1349 2011-12-27 21:41:00 <gmaxwell> "oh no! the process failed!" "no dude, you're the process."
1350 2011-12-27 21:41:05 <gavinandresen> exactly
1351 2011-12-27 21:41:14 <sipa> don't tell it
1352 2011-12-27 21:41:23 <gavinandresen> Suggestions for improving the process always welcome, of course....
1353 2011-12-27 21:41:29 <gmaxwell> although I think he's a bit burned out on it, so if we're depending on that....
1354 2011-12-27 21:41:29 <[Tycho]> gavinandresen: should it work as ++nRecurseDepth or I get it wrong ?
1355 2011-12-27 21:41:39 <sipa> [Tycho]: it should ne nRecurseDepth+1
1356 2011-12-27 21:41:40 AAA_awright has quit (Ping timeout: 240 seconds)
1357 2011-12-27 21:41:41 <gavinandresen> [Tycho]: aught to be +1
1358 2011-12-27 21:41:42 <sipa> be
1359 2011-12-27 21:42:11 <gavinandresen> Actually declaring nRecurseDepth const in the call would be good belt-and-suspenders....
1360 2011-12-27 21:42:22 <[Tycho]> So the variable should be not changed ? Ok.
1361 2011-12-27 21:42:51 <gavinandresen> I'm about to commit a unit test that DOES fail on the broken code, then I'll pull the fix...
1362 2011-12-27 21:43:24 <sipa> gavinandresen: first pull the fix then?
1363 2011-12-27 21:43:35 <gavinandresen> unit tests are supposed to break before working...
1364 2011-12-27 21:43:57 AAA_awright has joined
1365 2011-12-27 21:44:35 <sipa> ok
1366 2011-12-27 21:45:15 <luke-jr> there's a fix to pull?
1367 2011-12-27 21:45:23 <theymos> I found an interesting comment in the code: "Version 0.2 obsoletes 20 Feb 2012". 0.2 was released December 2009, so it looks like Satoshi intended releases to be backward-compatible for 2 years.
1368 2011-12-27 21:45:50 <luke-jr> theymos: I'm pretty sure 0.2 is already obsoleted
1369 2011-12-27 21:45:59 <[Tycho]> Did anyone tried to perform static code analysis on bitcoind ?
1370 2011-12-27 21:46:08 <gmaxwell> [Tycho]: yes.
1371 2011-12-27 21:46:13 <TD> i don't think there are any static analyses that would catch that type of bug
1372 2011-12-27 21:46:22 <theymos> luke-jr: The compatability code is still in current releases, I believe, so it should still work as a client.
1373 2011-12-27 21:46:22 <gmaxwell> [Tycho]: I've run clang on it.
1374 2011-12-27 21:46:24 <sipa> theymos: i'm very curious what will happen on february 20
1375 2011-12-27 21:46:41 <rjk2> >world implodes
1376 2011-12-27 21:46:46 <sipa> theymos: the network protocol effectively changes that day
1377 2011-12-27 21:46:48 Clipse has joined
1378 2011-12-27 21:47:07 <luke-jr> theymos: even 0.3.23 doesn't quite work as a client really
1379 2011-12-27 21:47:11 <sipa> if i understood the code correctly, version and verack will get a checksum that day
1380 2011-12-27 21:47:13 <gavinandresen> I think I'll plan to be on an airplane to Australia that day...
1381 2011-12-27 21:47:22 <[Tycho]> TD: not sure about that.
1382 2011-12-27 21:47:32 <gmaxwell> perhaps someone ought to advance the clock on a testnet in a box install...
1383 2011-12-27 21:47:38 <sipa> gmaxwell: indeed
1384 2011-12-27 21:47:46 <gavinandresen> there you go with "someone" again....
1385 2011-12-27 21:47:50 <[Tycho]> Ensure that the plane is not running on bitcoind :)
1386 2011-12-27 21:47:50 <sipa> i'm quite sure satoshi nodes will keep working
1387 2011-12-27 21:47:58 <gavinandresen> ... when we just talked about everybody being part of the machine
1388 2011-12-27 21:47:59 <sipa> but i'm not sure all alternative clients will
1389 2011-12-27 21:48:16 <TD> what's the change on feb 20th again?
1390 2011-12-27 21:48:19 * TD saw that once but forgot
1391 2011-12-27 21:48:34 <sipa> TD: right now, connections initialize as version 0, and upgrade after verack
1392 2011-12-27 21:48:36 <theymos> Yeah. Working off the "protocol specification" wiki page would certainly give you an incorrect result.
1393 2011-12-27 21:48:49 <sipa> after februari 20th, they initialize as version 209 iirc
1394 2011-12-27 21:48:49 <CIA-100> bitcoin: Wladimir J. van der Laan master * r89772f9 / src/script.cpp : Fix OP_EVAL recursion depth counting - http://git.io/YVTDHA https://github.com/bitcoin/bitcoin/commit/89772f932ac9477ff4745dc62a01cf57dbc0f70d
1395 2011-12-27 21:48:49 <CIA-100> bitcoin: Gavin Andresen master * r6d6d392 / src/test/script_op_eval_tests.cpp : Fixed OP_EVAL recursion unit test, checks for both infinite and exactly-3-deep recursion - http://git.io/iRLxXg https://github.com/bitcoin/bitcoin/commit/6d6d392b2238a4c6469f7e4d70071f17841197eb
1396 2011-12-27 21:48:50 <CIA-100> bitcoin: Gavin Andresen master * r625b56d / src/script.cpp : Merge branch 'opevalcountfix' of https://github.com/laanwj/bitcoin - http://git.io/B-xYhw https://github.com/bitcoin/bitcoin/commit/625b56de6491170ad6a2e45c57d974fca6160750
1397 2011-12-27 21:48:53 <TD> oh, right
1398 2011-12-27 21:49:05 <sipa> and version 209 has checksums on messages
1399 2011-12-27 21:50:18 <theymos> luke-jr: I still run unmodified 0.3.15 on my wallet machine and it works fine, more or less.
1400 2011-12-27 21:50:19 <gmaxwell> well, here is something you can't blame me for not doing:
1401 2011-12-27 21:50:27 <gmaxwell> _someone_ should send out an alert prior to feb 20
1402 2011-12-27 21:50:33 <gmaxwell> to old nodes
1403 2011-12-27 21:50:47 <gavinandresen> That's actually on my TODO list already
1404 2011-12-27 21:50:48 <gmaxwell> (or is .2 old enough to not have alerts with version scoping?)
1405 2011-12-27 21:50:59 <theymos> 0.2 doesn't have alerts at all.
1406 2011-12-27 21:51:06 <theymos> Alerts were introduced around 0.3.10.
1407 2011-12-27 21:51:07 <sipa> i don't think there are pre-0.2 nodes left
1408 2011-12-27 21:51:11 <gmaxwell> bleh yea, okay ..
1409 2011-12-27 21:51:13 <gavinandresen> ... good, one less thing for my TODO list
1410 2011-12-27 21:51:14 <[Tycho]> "luke-jr: theymos: even 0.3.23 doesn't quite work as a client really" - why do you think so ?
1411 2011-12-27 21:51:21 gjs278 has joined
1412 2011-12-27 21:51:27 <gmaxwell> When was freenode removed from the software?
1413 2011-12-27 21:51:29 <vsrinivas> will former (0.3) clients continue to interop after feb 20?
1414 2011-12-27 21:51:36 <sipa> vsrinivas: yes
1415 2011-12-27 21:51:37 <gmaxwell> vsrinivas: yes.
1416 2011-12-27 21:51:45 <vsrinivas> ok.
1417 2011-12-27 21:51:58 <gmaxwell> Because there _are_ nodes sill joining #bitcoin from time to time.
1418 2011-12-27 21:53:39 <theymos> gmaxwell: 0.3.0
1419 2011-12-27 21:54:27 _Fireball has quit (Quit: HydraIRC -> http://www.hydrairc.com <- Go on, try it!)
1420 2011-12-27 21:57:46 MimeNarrator has quit (Read error: Connection reset by peer)
1421 2011-12-27 21:59:21 MimeNarrator has joined
1422 2011-12-27 22:05:38 <makomk> sipa: ah yeah, I saw there was some ugly code in blkmond to handle the fact packets aren't checksummed in older protocol versions.
1423 2011-12-27 22:07:39 PK has quit ()
1424 2011-12-27 22:18:51 <slush> TD: ad "Extending bitcoin software+protocol". Yes, it can do the job, too. But I see that more as a grid of semi-trusted servers providing additional services for lightweight clients. I feel that distributing USD/BTC quotes isn't the job for p2p network itself.
1425 2011-12-27 22:19:07 <TD> is it a job for any network?
1426 2011-12-27 22:19:21 <slush> what do you mean?
1427 2011-12-27 22:19:37 <slush> I'm not sure if I'll trust usd/btc quote from some unknown p2p node
1428 2011-12-27 22:19:38 <TD> perhaps that's a job for client code. a server that provides a bogus quote could cause quite a bit of loss
1429 2011-12-27 22:19:57 <slush> but I can choose some "electrum node provider" and trust him enough that he won't lie me with btc/usd price
1430 2011-12-27 22:20:18 <TD> why not just use a client library that knows how to poll various exchanges itself?
1431 2011-12-27 22:20:18 <sipa> why not just contact the trade site itself?
1432 2011-12-27 22:20:44 <slush> sipa: because every site has proprietary API now
1433 2011-12-27 22:20:56 <sipa> then you should push for a common API
1434 2011-12-27 22:21:07 <slush> sipa: which I'm doing
1435 2011-12-27 22:21:18 <sipa> but it can be HTTP alright
1436 2011-12-27 22:21:26 <sipa> no need to do it via a p2p protocol
1437 2011-12-27 22:21:27 <slush> sipa: yes, it can be
1438 2011-12-27 22:21:37 <slush> so you agree with me :-)
1439 2011-12-27 22:22:16 <slush> TD: because such library must be implemented in all languages for all platform
1440 2011-12-27 22:22:30 <[Tycho]> I don't think that bitcoin needs USD/BTC info :)
1441 2011-12-27 22:22:41 <slush> TD: Imagine that you want to build bitcoin client on 3$ AVR processor...
1442 2011-12-27 22:22:53 <slush> [Tycho]: it was just an example :)
1443 2011-12-27 22:23:19 <slush> TD: then implementing all stack in C for AVR is probably much more complex than call simple RPC to some grid of servers
1444 2011-12-27 22:24:35 <slush> I understand that you all probably don't like anything what isn't absolutely p2p and what needs some kind of trust. But it is how internet services usually works. I just want to propose some standard API and reference implementation for providing such services.
1445 2011-12-27 22:26:04 <rjk2> Bitcoin as per Dan Kaminsky! http://saal1.h264.28c3.fem-net.de/
1446 2011-12-27 22:28:40 <vsrinivas> boo needs flash.
1447 2011-12-27 22:30:40 <TD> rjk2: when was this video made?
1448 2011-12-27 22:30:55 <rjk2> i think its streaming live right now
1449 2011-12-27 22:31:18 <TD> i think i've seen it before
1450 2011-12-27 22:32:34 <TD> indeed i have
1451 2011-12-27 22:32:35 <TD> http://www.slideshare.net/dakami/black-ops-of-tcpip-2011-black-hat-usa-2011
1452 2011-12-27 22:33:56 <rjk2> http://28c3.fem-net.de/ <-- other streams from CCC #28
1453 2011-12-27 22:37:57 <luke-jr> anyone tested bitcoind on MIPS or SPARC?
1454 2011-12-27 22:38:54 <vsrinivas> won't work.
1455 2011-12-27 22:39:00 <vsrinivas> bitcoind is LE only, no?
1456 2011-12-27 22:39:09 <sipa> yes
1457 2011-12-27 22:39:12 <vsrinivas> (sparc isn't, mips isn't iirc?)
1458 2011-12-27 22:39:23 <sipa> mips is biendian, according to wikipedia
1459 2011-12-27 22:39:40 <vsrinivas> oh hm.
1460 2011-12-27 22:39:47 MobiusL_ has joined
1461 2011-12-27 22:42:11 datagutt has quit (Quit: Computer has gone to sleep.)
1462 2011-12-27 22:42:56 MobiusL has quit (Ping timeout: 276 seconds)
1463 2011-12-27 22:44:24 <luke-jr> mipsel then? :P
1464 2011-12-27 22:44:55 <luke-jr> "Since almost all MIPS microprocessors have the capability of operating with either little endian or big endian byte order, the term is used only for processors where little endian byte order has been pre-determined."
1465 2011-12-27 22:45:01 ShadowE989 has quit (Ping timeout: 240 seconds)
1466 2011-12-27 22:47:56 <gmaxwell> luke-jr: yea, it's funny to try it on sparc... fails because the hash is wrong on the genesis block. :)
1467 2011-12-27 22:48:35 <gmaxwell> If someone wants to try porting it to sparc, I'll gladly give you an account on a ultrasparc box with solaris.
1468 2011-12-27 22:48:51 <luke-jr> I'd personally prefer AVR32, but I don't know how to build a cross compiler for it
1469 2011-12-27 22:49:06 <vsrinivas> tons of byte swaps cheers.
1470 2011-12-27 22:49:13 <luke-jr> my goal is to quantum-emulate every possible input, since KLEE only does argv -.-
1471 2011-12-27 22:49:21 <makomk> AVR32 requires a forked version of gcc, right?
1472 2011-12-27 22:49:27 <gmaxwell> luke-jr: KLEE doesn't only do argv.
1473 2011-12-27 22:49:29 <vsrinivas> does bitcoind use any 64-bit integers?
1474 2011-12-27 22:49:35 <sipa> yes
1475 2011-12-27 22:49:36 <luke-jr> gmaxwell: well, their instructions suggest that
1476 2011-12-27 22:49:38 <gmaxwell> luke-jr: you use the GET_SYMBOLIC or whatever it's called.
1477 2011-12-27 22:49:41 <luke-jr> gmaxwell: and their binaries don't work
1478 2011-12-27 22:49:47 <luke-jr> gmaxwell: and their source requires obsolete LLVM
1479 2011-12-27 22:50:02 <vsrinivas> okay. sparc does something odd, i think 64-bit integers are two BE 32-bit words in LE order.
1480 2011-12-27 22:50:04 <luke-jr> vsrinivas: bitcoind is full of int256 ;)
1481 2011-12-27 22:50:05 <gmaxwell> luke-jr: KLEE is a bit of a pain to build. I have it running.....
1482 2011-12-27 22:50:20 <luke-jr> gmaxwell: want to run it on bitcoind?
1483 2011-12-27 22:50:55 <gmaxwell> running it on whole programs the size of bitcoin is an excercize in frustration. It works best on small parts in isolation.
1484 2011-12-27 22:50:55 <sipa> luke-jr: uint256 is implemented using uint32's
1485 2011-12-27 22:51:01 <luke-jr> sipa: I know âº
1486 2011-12-27 22:52:05 theymos has quit (Remote host closed the connection)
1487 2011-12-27 22:52:49 <gmaxwell> All the $%^$% hashes and checksums in bitcoin make it resistant to fuzz testing.
1488 2011-12-27 22:53:30 <gmaxwell> KLEE is pretty powerful, but it won't solve checksums in an acceptable amount of time.
1489 2011-12-27 22:53:45 <gavinandresen> gmaxwell: I did some design notes and research on fuzz testing yesterday....
1490 2011-12-27 22:54:42 <gavinandresen> gmaxwell: bitcoin-specific rules for http://peachfuzzer.com/ are probably the way to go
1491 2011-12-27 22:55:35 <gmaxwell> gavinandresen: perhaps. But, for example, no fuzzer is going to solve valid blocks with random junk in them. :) (or at least, even if you do it, you won't get good coverage that way)
1492 2011-12-27 22:56:07 <gavinandresen> Right, that's the bitcoin-specific part: you want to extend the smart fuzzer to talk the getwork protocol to generate fuzzed blocks with valid POW, for example
1493 2011-12-27 22:56:51 <gavinandresen> (here's where TD tells us that's dumb and we should just have a command-line arg to bitcoind to allow any-POW....)
1494 2011-12-27 22:56:53 <gmaxwell> yea, I'm skeptical. Beyond the first 10 minutes of itâ which might yeild something.. The value in fuzz testing is that you can let it attempt 100 million times while you sleep. Won't work so well if you have to generate valid blocks.
1495 2011-12-27 22:57:03 <gmaxwell> I guess I'm taking TD's role there.
1496 2011-12-27 22:57:06 <gmaxwell> ;)
1497 2011-12-27 22:57:26 <TD> yes, unit test difficulty is the way to go :)
1498 2011-12-27 22:57:29 <gavinandresen> Yeah, fuzzing blocks you probably want the "difficulty 0" switch
1499 2011-12-27 22:57:55 <gavinandresen> Fuzzing transactions is easier, you just have to calculate the right txid hash
1500 2011-12-27 22:58:12 <gmaxwell> gavinandresen: unrelated to fuzz testing, another technique you should consider is mutation testing. I think it would be unusually valuable in helping you build test cases. But I'm not aware of any C++ tools to recommend.
1501 2011-12-27 22:58:36 <gmaxwell> yea, transactions I think you can cover with a specialized fuzzer (likewise for the network protocol in general)
1502 2011-12-27 22:59:17 <gmaxwell> (mutation testing is where you corrupt the source code in syntatically valid ways, and make sure your unit tests fail)
1503 2011-12-27 22:59:58 <gmaxwell> (it's basically fuzz testing for your testsâ treating the source of bitcoin as the input to the tests and corrupting it and making sure it doesn't pass any broken versions of bitcoin)
1504 2011-12-27 23:00:10 ShadowE989 has joined
1505 2011-12-27 23:01:15 <gavinandresen> Mmm... yeah, sounds like something that is easy to do in ML and impossible in C++.....
1506 2011-12-27 23:02:35 <gavinandresen> Part of my research yesterday was thinking about how to intelligently fuzz transactions; one could spend a very long time creating the Perfect Bitcoin Transaction Fuzzer
1507 2011-12-27 23:04:19 <gmaxwell> My recommendation is to do a little of everything. Any technique you apply will quickly hit the low hanging fruit reachable from that technique, then give diminishing returns.
1508 2011-12-27 23:05:20 <gavinandresen> Anyway, I think it wouldn't be terribly hard to do a pretty good job. I plan on making some phone calls to see if I can find somebody or several somebodies who might donate towards hiring somebody who already knows how to use the Peach fuzzing tool to work with me (or somebody) to develop a cross-implementation transaction fuzzer
1509 2011-12-27 23:05:27 <gavinandresen> (transaction and network protocol)
1510 2011-12-27 23:07:06 <gmaxwell> Slides I made for IETF 82, wrt software testing for the opus codec effort: http://www.ietf.org/proceedings/82/slides/codec-4.pdf may be of idle interest to anyone doing software QA. They were presented by another guy on the opus team, as I didn't want to fly to Taipei, unfortunately I can't find the audio.
1511 2011-12-27 23:11:11 <TD> it might be better to just write a custom fuzzer from scratch
1512 2011-12-27 23:11:13 <gavinandresen> gmaxwell: cool. So the danger, it seems to me, is that you spend a few years navel-gazing and writing every-more-sophisticated tests... and you end up with as-bugfree-as-humany-possible code that nobody actually uses for anything....
1513 2011-12-27 23:11:16 <TD> or use bitcoinj to help or whatever.
1514 2011-12-27 23:11:26 <TD> the bitcoin rules are complex enough a generic fuzzer tool may have issues
1515 2011-12-27 23:11:33 <TD> with getting sufficient coverage
1516 2011-12-27 23:12:01 <gavinandresen> TD: that's always the hard decision, isn't it, spend a bunch of time learning some does-almost-exactly-what-you-want tool or just write it yourself.........
1517 2011-12-27 23:12:21 <TD> yeah
1518 2011-12-27 23:13:20 <gmaxwell> TD: you can take a real implementation and instrument it into a fuzzer.
1519 2011-12-27 23:14:59 <gmaxwell> E.g. make FUZZ(x,0,5) which is a macro which resolves to x normally, and rand()&5+0 or something if built with fuzzing enabled. (well, thats what I'd do in C land, in C++ land you can do even more fun things)
1520 2011-12-27 23:15:17 <gmaxwell> sometimes when there are a lot of rules it can be easier to do that.
1521 2011-12-27 23:15:45 eoss has joined
1522 2011-12-27 23:15:45 eoss has quit (Changing host)
1523 2011-12-27 23:15:46 eoss has joined
1524 2011-12-27 23:19:28 <gavinandresen> gmaxwell: here were my thoughts: https://gist.github.com/1525448
1525 2011-12-27 23:24:09 <roconnor> gmaxwell: I decided bitcoin is a bucket of rotten fish guts because of checkpointing rather than OP_EVAL. :)
1526 2011-12-27 23:24:37 <vsrinivas> the statically baked in list of checkpoints?
1527 2011-12-27 23:25:16 <gavinandresen> roconnor: it took you this long to figure out the guts of bitcoin are .... ummm.... smelly ?
1528 2011-12-27 23:25:45 <roconnor> vsrinivas: yes; I originally though checkpoints were harmless paranoia, but gmaxwell told me they are needed to stop DOS attacks
1529 2011-12-27 23:25:52 <roconnor> now I'm worried about my client
1530 2011-12-27 23:26:20 <vsrinivas> wait, they are? ; my understanding was that they only prevented disk-flooding DoSes.
1531 2011-12-27 23:26:37 <roconnor> vsrinivas: yes that is the attack that gmaxwell told me about
1532 2011-12-27 23:26:42 <vsrinivas> oh okay.
1533 2011-12-27 23:27:22 <roconnor> vsrinivas: Checkpoint is commonly presented as a block forking prevension thing.
1534 2011-12-27 23:27:27 <gavinandresen> If you've got a better way to prevent the "tell a new client about a bogus difficulty-1 blockchain" .... send me email (I'm afk for a while)
1535 2011-12-27 23:27:28 <vsrinivas> well, that that's fixed via checkpoints is i suppose an artifact of not having a Cleaner for the log.
1536 2011-12-27 23:27:44 <gmaxwell> roconnor: so deal with it another way.. you could, for example save only block headers for anything except the longest chain.
1537 2011-12-27 23:28:14 <TD> i think checkpointing is a fine thing
1538 2011-12-27 23:28:28 <gmaxwell> roconnor: that plus a rate limit on accepting non-longest chain blocks would also adequately close that.
1539 2011-12-27 23:28:30 <roconnor> TD: I think it makes bitcoin not decentralized, though gmaxwell disagrees
1540 2011-12-27 23:28:42 <TD> why?
1541 2011-12-27 23:28:54 <gmaxwell> roconnor: I think it makes bitcoin decenteralized if its ever needed to arbritrate between to possibly longest chains.
1542 2011-12-27 23:29:02 <gmaxwell> roconnor: but its never actually called on to do that.
1543 2011-12-27 23:29:42 <vsrinivas> you wouldn't even need to use the same set of checkpoints as anyone else.
1544 2011-12-27 23:29:55 Fnar has quit (Ping timeout: 268 seconds)
1545 2011-12-27 23:31:08 Synix has quit (Ping timeout: 240 seconds)
1546 2011-12-27 23:31:11 <roconnor> gmaxwell: I'm contemplating an autocheckpointing mode: (a) ship with a blockchain, and dont accept blocks unless they attach (indirectly) to somewhere along the last 10000 blocks of the most difficult chain.
1547 2011-12-27 23:31:44 <roconnor> but it doesn't really make me happy
1548 2011-12-27 23:31:55 <roconnor> I'll need to think about things more
1549 2011-12-27 23:32:14 <gmaxwell> roconnor: I think the DOS could be closed if the node feteched fetching headers most recent to oldest, then validating oldest to most recent.
1550 2011-12-27 23:32:29 <gmaxwell> And then it prioritized so that it feteched headers for the chain with the highest instant difficulty.
1551 2011-12-27 23:32:51 b4epoche_ has joined
1552 2011-12-27 23:32:59 <gmaxwell> The cost of building blocks _now_ is enough enough to make the attack unrealistic. So thats not the problem. The problem is the old blocks which can be low difficulty.
1553 2011-12-27 23:33:03 graingert has joined
1554 2011-12-27 23:33:36 <roconnor> gmaxwell: so with the headers you could know if the chain has the potential to be the longest
1555 2011-12-27 23:33:45 <roconnor> I mean the most difficult
1556 2011-12-27 23:33:50 b4epoche has quit (Ping timeout: 252 seconds)
1557 2011-12-27 23:33:50 b4epoche_ is now known as b4epoche
1558 2011-12-27 23:34:00 <gmaxwell> If the current diff is 1e8 and the curren block is 1e6 you now know a lower bound on the sum even if you don't know the chain, because of the 4x maximum shift rule.
1559 2011-12-27 23:34:26 <gmaxwell> roconnor: yes. It might be full of invalid gibberish still but â you can't make gibberish blocks with valid headers cheaper than valid blocks.
1560 2011-12-27 23:34:34 <Diablo-D3> gmaxwell: welp, I seem to be winning
1561 2011-12-27 23:34:44 <Diablo-D3> gmaxwell: I have now been accused of being a gay nigger from outerspace.
1562 2011-12-27 23:34:55 <roconnor> gmaxwell: blocks would be sent along with their alledged position in the chain?
1563 2011-12-27 23:35:00 <gmaxwell> Diablo-D3: oh, thats a new one. I've never been accused of that one.
1564 2011-12-27 23:35:18 <Diablo-D3> yeah, Im like, Ive doxed GNAA members, get real.
1565 2011-12-27 23:35:28 <Diablo-D3> gmaxwell: seriously, ask dub
1566 2011-12-27 23:35:30 <Diablo-D3> hes right in here
1567 2011-12-27 23:35:42 <Diablo-D3> dub: tell gmaxwell about how you think Im a gay nigger from outerspace.
1568 2011-12-27 23:36:01 <roconnor> Diablo-D3: forum?
1569 2011-12-27 23:36:15 <Diablo-D3> roconnor: irc
1570 2011-12-27 23:36:23 <dub> GNAA !GNFOS
1571 2011-12-27 23:36:31 <Diablo-D3> seriously dub
1572 2011-12-27 23:36:35 <Diablo-D3> everytime someone attacks me
1573 2011-12-27 23:36:39 <dub> they just bandwaggon on that shit
1574 2011-12-27 23:36:41 <Diablo-D3> someone donates to improve diablominer.
1575 2011-12-27 23:36:51 <Diablo-D3> so, please, continue.
1576 2011-12-27 23:37:01 <gmaxwell> roconnor: Soâ yes. You'd ask each peer to tell you the identity of their best block. You'd then fetch all the distinct best blocks (if there is more than one). Ideally you fetch only the header (though .. do we currently have a network call for that?) in any case you keep only the header.
1577 2011-12-27 23:37:52 dr_win has quit (Remote host closed the connection)
1578 2011-12-27 23:37:56 <roconnor> gmaxwell: this sounds really good
1579 2011-12-27 23:38:35 <gmaxwell> roconnor: then for each you walk back to the genesis, staring with the highest current diff, getting the headers. You give up on one if it has no chance of being the best.
1580 2011-12-27 23:38:37 <roconnor> We'd have to adjust the p2p protocol right? but that is fine. We don't need to touch the core bitcoin protocol?
1581 2011-12-27 23:38:42 <gmaxwell> roconnor: right.
1582 2011-12-27 23:38:49 <roconnor> I like this
1583 2011-12-27 23:38:51 <gmaxwell> p2p needs these changes anyways, for the most part.
1584 2011-12-27 23:38:57 <roconnor> I'd have to think about it some more
1585 2011-12-27 23:39:02 <roconnor> but it sounds really good
1586 2011-12-27 23:39:15 <gmaxwell> Once you've found the best from the headers, you refill with blocks and make sure it follows the rules.
1587 2011-12-27 23:39:21 <roconnor> right
1588 2011-12-27 23:39:30 <gmaxwell> If it does great.. if it doesn't .. you stop and go to the next best etc..
1589 2011-12-27 23:39:49 <gmaxwell> yea, I'll think about it some more, but I think it addresses this family of weaknesses without needing checkpoints.
1590 2011-12-27 23:40:25 <roconnor> so what if someone claims to have the 100 000 000 th block or whatever and is pepared to produce a bunch of fake headers?
1591 2011-12-27 23:41:12 <gmaxwell> you start with fetching the highest current difficulty. So this resistance depends on blocks currently being expensive to make.
1592 2011-12-27 23:41:13 <roconnor> all with low difficulty
1593 2011-12-27 23:41:42 <gmaxwell> it might actually be the longest chain, but you'll go to find that out after you know the sum of the current one.
1594 2011-12-27 23:42:06 <gmaxwell> And at worseâ they make you fetch a bunch of stupid headers.
1595 2011-12-27 23:42:09 <gmaxwell> Which isn't a big deal.
1596 2011-12-27 23:42:37 <gmaxwell> I gues 100,000,000 headers is 7629 gbytes.
1597 2011-12-27 23:42:48 <gmaxwell> megabytes!
1598 2011-12-27 23:42:54 <gmaxwell> MiB
1599 2011-12-27 23:43:59 <gmaxwell> You can clamp the max chain length vs the current time, but I'd have to think for a bit how tight a clamp that would be.
1600 2011-12-27 23:43:59 <graingert> Mio
1601 2011-12-27 23:44:21 eoss has quit (Ping timeout: 240 seconds)
1602 2011-12-27 23:46:22 <gmaxwell> in any case, the simple process of fetching the headers first and only fetching blocks for the longest chain _seriously_ shifts the cost balance for these attacks in favor of the defender.
1603 2011-12-27 23:47:41 larsa has joined
1604 2011-12-27 23:48:47 <gmaxwell> Assuming the attacker was willing to generate lots of diff1 headers ... the cost (lost income) to them is 0.000069 BTC per byte of disk space taken given the current network difficulty.
1605 2011-12-27 23:49:51 <gmaxwell> Or around $300k in order to eat up a GiB of disk space on any nodes they want to attack.
1606 2011-12-27 23:50:29 <gmaxwell> If you assume that it probably takes at least 10 gigs to start breaking serious numbers of nodesâ this is not the least expensive attack you could do to bitcoin, by far.
1607 2011-12-27 23:50:49 <gmaxwell> (again, this is all assuming it does a header fetch (in either direction) and only pulls full blocks for the longest chain)
1608 2011-12-27 23:51:56 <gmaxwell> oh my math is off. :(
1609 2011-12-27 23:52:18 <gmaxwell> Reciprocals I hate you.
1610 2011-12-27 23:52:57 <gmaxwell> 578.5 BTC per spam GiB. :-/
1611 2011-12-27 23:53:18 <gmaxwell> Well, still expensive.. but not completely implusable.
1612 2011-12-27 23:55:12 theorb is now known as theorbtwo
1613 2011-12-27 23:55:25 <gmaxwell> though frankly, You could have some simple rule like "no diff <100 after block X" and instantly increase the cost of the attack by 100x at the risk of making your nodes fail if the real network drops that low ever again.
1614 2011-12-27 23:55:33 theorbtwo has quit (Remote host closed the connection)
1615 2011-12-27 23:55:35 <gmaxwell> But if the real network does drop that lowâ bitcoin has already failed.
1616 2011-12-27 23:55:42 theorbtwo has joined
1617 2011-12-27 23:55:45 chrisb__ has quit (Quit: Ex-Chat)
1618 2011-12-27 23:56:09 erus` has quit (Quit: ChatZilla 0.9.88 [Firefox 8.0/20111104165243])