1 2011-12-29 00:10:22 <P3nt0> Right
  2 2011-12-29 00:10:42 <P3nt0> Any Avo members present?
  3 2011-12-29 00:10:46 <cjdelisle> Wrong
  4 2011-12-29 00:10:54 <sipa> What is Avo?
  5 2011-12-29 00:11:00 <P3nt0> somme faggot group of kids
  6 2011-12-29 00:11:25 <cjdelisle> how can I join?
  7 2011-12-29 00:11:40 <P3nt0> suck on your moms tits
  8 2011-12-29 00:11:45 <P3nt0> instant membership
  9 2011-12-29 00:11:54 <sipa> please
 10 2011-12-29 00:12:10 <P3nt0> Now
 11 2011-12-29 00:12:13 <P3nt0> Anyone with Avo?
 12 2011-12-29 00:13:19 <cjdelisle> so umm what did this group do to you?
 13 2011-12-29 00:13:45 <P3nt0> ah its ok
 14 2011-12-29 00:13:47 <P3nt0> im in the right place
 15 2011-12-29 00:13:54 <P3nt0> i recognise the names that i recieved on email
 16 2011-12-29 00:13:54 <sipa> and what does it have to do with the development of bitcoin?
 17 2011-12-29 00:14:06 <rjk2> doesn't sound liek the right place
 18 2011-12-29 00:14:13 <P3nt0> earlier today i recieved an email from a group of friends regarding this Team Avo
 19 2011-12-29 00:14:26 <P3nt0> nothing major, but still unwanted
 20 2011-12-29 00:14:32 <P3nt0> Anything further
 21 2011-12-29 00:14:39 <P3nt0> Will result in individual attacks
 22 2011-12-29 00:14:52 <rjk2> random threats directed at no one?
 23 2011-12-29 00:14:56 <rjk2> interesting
 24 2011-12-29 00:15:05 <sipa> does this have anything to do with bitcoin?
 25 2011-12-29 00:15:28 <cjdelisle> hmm according to gribble it's something todo with minecraft - some troll org or something
 26 2011-12-29 00:15:30 <TuxBlackEdo> i think this guy is just waisting people's time in here tbh....
 27 2011-12-29 00:15:36 <P3nt0> depends if Avo is associated, prrobably not
 28 2011-12-29 00:15:44 <P3nt0> it is to do with mc
 29 2011-12-29 00:15:47 <P3nt0> like i said its nothing major
 30 2011-12-29 00:15:48 <P3nt0> but
 31 2011-12-29 00:15:56 <P3nt0> a few friends show discomfort to these nubs
 32 2011-12-29 00:16:09 <P3nt0> which we do not see kindly
 33 2011-12-29 00:16:48 <cjdelisle> yeap, that's kind of the point of troll organizations..
 34 2011-12-29 00:17:09 <P3nt0> well if they were smart
 35 2011-12-29 00:17:12 <P3nt0> with what they already know
 36 2011-12-29 00:17:26 <P3nt0> very slight adjustments
 37 2011-12-29 00:17:31 <P3nt0> could cause a lot of problems
 38 2011-12-29 00:17:32 <P3nt0> as they are
 39 2011-12-29 00:17:38 <P3nt0> they are nothing more than flys that are removed
 40 2011-12-29 00:17:41 <rjk2> wtf is all this meta shit
 41 2011-12-29 00:17:44 <P3nt0> but with half a brain, causes issues
 42 2011-12-29 00:18:44 <gmaxwell> DNFTT
 43 2011-12-29 00:19:24 <P3nt0> anyway
 44 2011-12-29 00:19:39 <P3nt0> if Avo would like to be in contact please contact myself at P3nt0@cia.com
 45 2011-12-29 00:21:24 <sipa> ignored
 46 2011-12-29 00:22:04 <cjdelisle> I got a chuckle out of the outburst of randomness
 47 2011-12-29 00:22:51 <rjk2> veiled threats ftw
 48 2011-12-29 00:54:56 <wiel> whats the name of a channel where they talk about encryption?
 49 2011-12-29 00:55:25 <rjk2> try being more specific
 50 2011-12-29 00:56:24 <wiel> Im trying to identify the encryption being used on a string
 51 2011-12-29 00:59:25 <lianj> rot13
 52 2011-12-29 00:59:40 <wiel> rjk2
 53 2011-12-29 01:10:06 <finway> quote:  gmaxwell
 54 2011-12-29 01:10:13 <finway> Yes, i am the guy.
 55 2011-12-29 01:14:24 <gmaxwell> but you're in the room
 56 2011-12-29 01:29:33 <finway> I mean, i support OP_EVAL, roconor should talk two months ago, and OP_EVAL enables a lot good stuff, and the risks are managed well, i think.
 57 2011-12-29 01:29:40 <finway> I can't code
 58 2011-12-29 01:34:21 <roconnor> luke-jr gmaxwell sipa: new proposal: OP_CODESEPARATOR pushes the hash of the serialization of all the code after the OP_CODESEPARATOR onto a new "codehash" stack.  A new OP_CODEHASH function pops this codehash stack and pushes it onto the main stack.  Transactions are "OP_CODEHASH HASH160 {20-byte-hash-value} EQUALVERIFY"  and it is redeemed by "{hash of the_code} signatures OP_CODESEPARATOR the_code" The prefix of {
 59 2011-12-29 01:34:23 <roconnor> hash of the_code} in the redeeming script ensures that the hash of the code is on the top stack even if OP_CODEHASH is intepreted as a NOP.
 60 2011-12-29 01:34:59 <roconnor> (note this hash that OP_CODESEPARATOR pushes is exactly the hash that is used in signature verification)
 61 2011-12-29 01:40:17 <finway> I think the difference between OP_CHECKMULTISIG and OP_EVAL,  is sender do not care , right ?
 62 2011-12-29 01:47:48 <finway> Question: why nobody use OP_CHECKMULTISIG ?
 63 2011-12-29 01:49:13 <luke-jr> roconnor: might work, but significantly less safe than OP_EVAL for migration
 64 2011-12-29 01:50:48 <luke-jr> and wouldn't it need to be "signatures {hash of the_code} OP_CODESEPARATOR the_code" ?
 65 2011-12-29 01:51:16 <luke-jr> and have OP_CODEHASH verify the top stack item is identical to the actual code hash..
 66 2011-12-29 01:51:52 <luke-jr> also, this paradigm slows down evaluation since every code block needs hashing :/
 67 2011-12-29 01:55:12 <CIA-100> bitcoin: Con Kolivas * rd656c14ef84b cgminer/main.c: Don't give pool slow warning if it is the donation pool. http://tinyurl.com/cdqkr8u
 68 2011-12-29 01:57:01 <osmosis> for bitcoin-qt, could be nice on the  Overview - Recent Transactions to show the 'time ago' rather then just the date. Like "5 min ago."  " 6 hours ago."
 69 2011-12-29 02:07:33 <roconnor> luke-jr: only need hashing if there is a OP_CODESEPARATOR
 70 2011-12-29 02:07:52 <luke-jr> roconnor: which there often is
 71 2011-12-29 02:08:12 <roconnor> and it is "{hash of the_code} signature" since the_code will pop off all the signatures
 72 2011-12-29 02:08:21 <roconnor> I don't see why it is less safe than OP_EVAL
 73 2011-12-29 02:08:37 <roconnor> it is slightly slower with one additional hashing operator
 74 2011-12-29 02:08:45 <roconnor> *operation
 75 2011-12-29 02:09:23 <roconnor> the consequences of this is less severe than OP_EVAL
 76 2011-12-29 02:11:13 <finway> It still contains CODE in DATA
 77 2011-12-29 02:11:53 <roconnor> no, it cotains hash-of-code in data
 78 2011-12-29 02:11:57 <roconnor> *contains
 79 2011-12-29 02:14:02 <roconnor> luke-jr: the stuff in the codehash stack has the property that everything in the stack is the hash of some code that was definitely executed from that point.
 80 2011-12-29 02:15:51 <luke-jr> roconnor: it's less safe, since redeeming OP_EVAL even without OP_EVAL support requires the txn know the right script
 81 2011-12-29 02:16:03 <luke-jr> roconnor: with OP_CODEHASH, you just need to know the hash of the right script& which is right there
 82 2011-12-29 02:16:45 <roconnor> the proposed transaction is : OP_CODEHASH HASH160 {20-byte-hash-value} EQUALVERIFY
 83 2011-12-29 02:17:05 <roconnor> in order to process this on a standard transcation you need to know the inverse of that 20-byte-hash-value
 84 2011-12-29 02:17:13 <roconnor> just like the existing OP_EVAL proposal
 85 2011-12-29 02:17:47 <roconnor> due to the presence of the HASH160 command
 86 2011-12-29 02:17:50 <roconnor> er
 87 2011-12-29 02:17:56 <roconnor> the proposed transaction is : OP_CODEHASH OP_HASH160 {20-byte-hash-value} EQUALVERIFY
 88 2011-12-29 02:18:02 <roconnor> sorry I forgot the OP_
 89 2011-12-29 02:18:36 <luke-jr> ah
 90 2011-12-29 02:18:47 <luke-jr> so {20-byte-hash-value} is SHA256(SHA256(code)) ?
 91 2011-12-29 02:18:54 <luke-jr> err
 92 2011-12-29 02:18:59 <roconnor> more or less
 93 2011-12-29 02:19:00 <luke-jr> HMAC(SHA256(code))
 94 2011-12-29 02:19:08 <roconnor> HASH160 isn't quite SHA256
 95 2011-12-29 02:19:15 <luke-jr> HASH160, that's it :P
 96 2011-12-29 02:20:09 <luke-jr> hmm, why not wait until OP_CODEHASH to hash the script?
 97 2011-12-29 02:20:28 <roconnor> well, in Haskell that is what will happen :P
 98 2011-12-29 02:20:59 <luke-jr> ie, when OP_CODEHASH is called, hash everything leading up to it since the last OP_CODESEP
 99 2011-12-29 02:20:59 <roconnor> so the implementor is welcome to delay perfoming the hash
100 2011-12-29 02:21:16 <roconnor> luke-jr: that is also reasonable
101 2011-12-29 02:21:21 <luke-jr> I suppose it might mean two OP_CODEHASHes that way tho
102 2011-12-29 02:21:29 <luke-jr> since there's an implicit OP_CODESEP right before it
103 2011-12-29 02:22:04 <luke-jr> in any case, OP_CODEHASH needs to confirm that the same hash is already on the stack, and not change it
104 2011-12-29 02:22:12 <luke-jr> ie, it either aborts the script or not
105 2011-12-29 02:22:24 <roconnor> The important thing is to be clear that the code being hashed is from the Signature; which is why I want to assign the semantics to the OP_CODESEPARATOR
106 2011-12-29 02:22:42 <roconnor> you can replace the codehash stack with a codehash state variable
107 2011-12-29 02:22:55 <roconnor> (ie just keep the top of the stack and drop everything else
108 2011-12-29 02:23:12 <roconnor> and initialize the codehash state variable with the hash of the signature script
109 2011-12-29 02:23:36 <roconnor> (the implementation is welcome to delay performing this hash until OP_CODEHASH is called ... if ever  (ie using a future))
110 2011-12-29 02:23:59 <roconnor> luke-jr: I will subscribe to the development mailing list
111 2011-12-29 02:24:08 <roconnor> tonight or tomorrow
112 2011-12-29 02:24:33 <roconnor> luke-jr: should I CC major pool operators or are they all on the list already?
113 2011-12-29 02:24:44 <luke-jr> I'd CC DeepBit and BTCGuild at least
114 2011-12-29 02:26:34 <roconnor> what are their addresses?
115 2011-12-29 02:35:34 <roconnor> probably not though
116 2011-12-29 02:47:48 <pirateat40> I need a getwork request guru.
117 2011-12-29 04:53:35 <theymos> Interesting new attack on several programming languages, exploiting collisions in hash tables: http://tinyurl.com/bvjhtwt
118 2011-12-29 04:55:38 <SomeoneWeird> lol so php4 is partially vulnerable while php5 is
119 2011-12-29 04:55:40 <SomeoneWeird> -.-
120 2011-12-29 04:56:02 <SomeoneWeird> wow thats gotta hurt, easy ddos now.
121 2011-12-29 04:56:54 <the_batman> haha pretty cool
122 2011-12-29 04:57:19 <SomeoneWeird> yeah
123 2011-12-29 07:32:46 <midnightmagic> i never liked hash tables.
124 2011-12-29 07:33:30 <edcba> don't like worst cases ?
125 2011-12-29 07:33:46 <Graet> ;;seen shadders
126 2011-12-29 07:33:47 <gribble> shadders was last seen in #bitcoin-dev 4 weeks, 1 day, 18 hours, 55 minutes, and 47 seconds ago: <shadders> devrandom: is that you miron?
127 2011-12-29 07:36:09 <midnightmagic> never liked how they are abused by what appear to be lazy people.
128 2011-12-29 07:37:14 <copumpkin> there's also a bit of laziness in how people analyze their time complexity vs. balanced trees
129 2011-12-29 11:25:13 <CIA-100> libbitcoin: genjix * r48e0d39edc29 / (7 files in 4 dirs): bdb_blockchain: finished block validation + organisation. connect inputs working for orphan chain lookups. http://tinyurl.com/d59mx25
130 2011-12-29 16:02:14 <roconnor> copumpkin: feel like implementing the SK-calculus in bitcoin-script using OP_EVAL?
131 2011-12-29 16:02:38 <copumpkin> I don't know enough about OP_EVAL
132 2011-12-29 16:02:44 <copumpkin> I haven't been following any of this stuff, really
133 2011-12-29 16:03:07 <sipa> we already have an omega combinator :)
134 2011-12-29 16:03:14 <roconnor> yep
135 2011-12-29 16:03:38 <roconnor> copumpkin: It's pretty easy to learn the basic semantics of OP_EVAL
136 2011-12-29 16:04:09 <copumpkin> where can I read about it?
137 2011-12-29 16:04:38 <copumpkin> bip 12?
138 2011-12-29 16:04:41 <roconnor> In theory https://en.bitcoin.it/wiki/BIP_0012
139 2011-12-29 16:04:48 <copumpkin> except it's down :(
140 2011-12-29 16:04:50 <sipa> bitcoin.it down?
141 2011-12-29 16:07:55 <copumpkin> roconnor: do you actually own any bitcoins, by the way? :P
142 2011-12-29 16:08:12 <roconnor> copumpkin: do testnet coins count?
143 2011-12-29 16:08:17 <copumpkin> nope
144 2011-12-29 16:08:22 <roconnor> copumpkin: then no I don't
145 2011-12-29 16:08:24 <copumpkin> tsk tsk
146 2011-12-29 16:08:38 <copumpkin> how could you possibly be interested in bitcoin without a financial interest in them!
147 2011-12-29 16:08:43 <roconnor> copumpkin: have you seen the code behind bitcoin!!
148 2011-12-29 16:08:50 <roconnor> who would invest in that :D
149 2011-12-29 16:08:59 <copumpkin> :)
150 2011-12-29 16:11:22 <roconnor> once we have the SK calculus implement we can get the scripting language to play chess
151 2011-12-29 16:12:45 <sipa> with limits on code size, instructions executed, and disabled op codes, you won't get far
152 2011-12-29 16:12:52 <roconnor> http://www.engadget.com/2006/10/06/dutch-voting-machines-hacked-to-play-chess/
153 2011-12-29 16:13:51 <edcba> you need not to invest to own bitcoins
154 2011-12-29 16:14:19 <roconnor> edcba: true
155 2011-12-29 16:14:33 <roconnor> copumpkin: who would hold a position in that :D
156 2011-12-29 16:20:08 <roconnor> BIP 0016: OP_GOTO
157 2011-12-29 16:22:11 <copumpkin> roconnor: lol
158 2011-12-29 16:22:22 <copumpkin> OP_SUBLEQ
159 2011-12-29 16:22:46 <roconnor> :D
160 2011-12-29 16:23:32 <roconnor> copumpkin: with OP_SUBLEQ we can depricate all the other operations.
161 2011-12-29 16:23:48 <copumpkin> excellent :D
162 2011-12-29 16:23:55 <copumpkin> well, we might need a primop or two to talk to the outside world
163 2011-12-29 16:24:02 <roconnor> I suppose
164 2011-12-29 16:24:24 <copumpkin> the primop in our subleq language could be EXEC_PYTHON
165 2011-12-29 16:24:34 <roconnor> EXEC_PERL would be better
166 2011-12-29 16:24:42 <roconnor> since PERL isn't statically parsable
167 2011-12-29 16:24:46 <roconnor> it must be better
168 2011-12-29 16:24:48 <copumpkin> good point
169 2011-12-29 16:24:57 <edcba> perl isn't even readable
170 2011-12-29 16:25:06 <copumpkin> edcba: some say the same about haskell
171 2011-12-29 16:25:11 <copumpkin> and clearly they're wrong
172 2011-12-29 16:25:14 <roconnor> edcba: that's because you need to execute perl in order to read it
173 2011-12-29 16:28:23 <sipa> cut the crap
174 2011-12-29 16:28:29 <sipa> just use OP_X86ASM
175 2011-12-29 16:28:33 <copumpkin> lol
176 2011-12-29 16:28:58 <edcba> ?? la NaCl
177 2011-12-29 16:29:02 <roconnor> sipa: see now that is a very good idea
178 2011-12-29 16:29:11 <sipa> efficiency++
179 2011-12-29 16:29:12 <copumpkin> well, I insist on PCC x86asm
180 2011-12-29 16:29:18 <roconnor> sipa: because many users could just directly execute the bytecode
181 2011-12-29 16:29:25 <copumpkin> I demand my x86 with a side of proof
182 2011-12-29 16:29:26 <roconnor> what could go wrong?
183 2011-12-29 16:29:51 <roconnor> I can't think of any problems, so there must be none.
184 2011-12-29 16:30:15 <sipa> other systems just need a cpu emulator
185 2011-12-29 16:30:30 <sipa> those are well-researched and completely void of security problems
186 2011-12-29 16:30:35 <copumpkin> bundle QEMU in all bitcoin distros
187 2011-12-29 16:30:53 <copumpkin> b4epoche: how's it going?
188 2011-12-29 16:33:24 <lianj> BIP 0101: turing completeness
189 2011-12-29 16:33:39 <roconnor> lianj: that is what BIP 0012 is
190 2011-12-29 16:33:51 <lianj> ah m( lol
191 2011-12-29 16:33:58 <sipa> it is not
192 2011-12-29 16:34:16 <roconnor> well neither is my computer since it has limited RAM
193 2011-12-29 16:35:30 <roconnor> well to be fair I guess my computer can loop
194 2011-12-29 16:35:45 <roconnor> but even with BIP 0012 the scripting language cannot
195 2011-12-29 16:35:54 <roconnor> ... though I'd kinda like to see a proof of that
196 2011-12-29 16:36:32 <gmaxwell> and implement some kinds of infinite recursion too, (just not w/ languages that force every call to stake a stackframe)
197 2011-12-29 16:37:19 <gmaxwell> roconnor: even if it could 'loop' by having a program that wrote itself onto the stack and op_evaling it could only do so twice.
198 2011-12-29 16:37:59 <roconnor> gmaxwell: by the Gavin method, yes.
199 2011-12-29 16:38:02 <roconnor> gmaxwell: any other ways?
200 2011-12-29 16:38:44 <gmaxwell> Yea, I don't have a proof that it isn't possible but I don't see how.
201 2011-12-29 16:38:58 <roconnor> gmaxwell: well, if you guys don't see how, then it must be fine.
202 2011-12-29 16:39:15 <gmaxwell> :-/
203 2011-12-29 16:39:16 <sipa> clearly we're smarter than any potential attacker
204 2011-12-29 16:40:02 <roconnor> actually I have a vague idea how to prove loopin is impossible
205 2011-12-29 16:40:28 <roconnor> but I'm through helping this OP_EVAL proposal.
206 2011-12-29 16:40:36 <roconnor> I don't even want it
207 2011-12-29 16:40:57 <roconnor> now I have my own proposal
208 2011-12-29 16:41:23 <roconnor> not that I want it either, but it is better.
209 2011-12-29 16:42:00 <roconnor> sipa: are you on the bitcoin-development list?
210 2011-12-29 16:42:03 <copumpkin> BIP 0012.5?
211 2011-12-29 16:42:07 <sipa> roconnor: of course
212 2011-12-29 16:42:13 <roconnor> good
213 2011-12-29 16:42:27 <roconnor> copumpkin: you might not be
214 2011-12-29 16:42:34 <copumpkin> oh, I'm not
215 2011-12-29 16:42:41 <copumpkin> I am but a lowly bitcoin speculator
216 2011-12-29 16:42:43 <roconnor> I can give you an archive link
217 2011-12-29 16:42:50 <roconnor> oh but maybe you dont' care
218 2011-12-29 16:42:52 <copumpkin> oh I do
219 2011-12-29 16:43:15 <roconnor> http://sourceforge.net/mailarchive/forum.php?thread_name=CABsx9T06H29R4CpL9hXF_yyB4chko1YdkhbCZ8rdwo1gLmF1BQ%40mail.gmail.com&forum_name=bitcoin-development
220 2011-12-29 16:43:18 <sipa> roconnor: i like your proposal, but have the same remarks as gavin
221 2011-12-29 16:43:48 <roconnor> sipa: okay
222 2011-12-29 16:44:15 <sipa> though i'm definitely beginning to agree that it should be postponed, i must admit that OP_EVAL is still "nicer" in usage
223 2011-12-29 16:45:51 <lianj> is there a list of merged mainline BIPs?
224 2011-12-29 16:46:04 <sipa> BIPs aren't merged, they aren't code
225 2011-12-29 16:46:21 <sipa> they are accepted or not, by some or all
226 2011-12-29 16:46:23 <lianj> implementations of bips then
227 2011-12-29 16:47:25 <sipa> roconnor: if we ever want to chance to overhaul the script language completely, the only viable option is via an OP_EVALX trick, i'm afraid (though you rightfully point out that that is independent from the current proposal)
228 2011-12-29 16:47:28 <gmaxwell> roconnor: the increase in the input script size in your proposal is unfortunate. :(
229 2011-12-29 16:49:35 <gmaxwell> (Otherwise it sounds fine to me, but meh, big otherwise)
230 2011-12-29 16:50:42 <gmaxwell> (don't that the concern personally if you'll note I was whining about the lack of key recovery in op-eval weeks ago, because its a missed chance to further reduce input script size)
231 2011-12-29 16:51:52 <TD> there seem to have been 3 different talks at CCC about bitcoin
232 2011-12-29 16:51:53 <TD> not bad
233 2011-12-29 16:51:58 <sipa> wow
234 2011-12-29 16:52:38 <copumpkin> roconnor: I see, thanks
235 2011-12-29 16:54:01 <TD> i think we're going to see a lot of attacks on the privacy of bitcoin users from researchers over the next year or two. the practice of using static addresses is just bound to trip people up
236 2011-12-29 16:54:08 <jgarzik> TD: good.  _finally_ outsiders are beginning to look at the tech, think hard about it, try to break it.  That's healthy for bitcoin.
237 2011-12-29 16:54:14 <TD> agree
238 2011-12-29 16:54:25 <TD> unless bitcoin changes out from underneath them
239 2011-12-29 16:54:36 <gmaxwell> roconnor: so, what if there was a second stack that only picked up items that were pushed explicitly. (not the result of computations)
240 2011-12-29 16:54:51 <gmaxwell> roconnor: and then OP_EVAL only executed from that stack
241 2011-12-29 16:55:07 <sipa> roconnor: what about an OP_CHECKEDEVAL, which expects a) a script and b) its hash on the stack, verifies that the script's hash matches, and executes the script (having it inherit the current stack without the serialized script and its hash) without letting it touch the parent's stack
242 2011-12-29 16:55:30 <sipa> roconnor: with the explicit extra rule that OP_CHECKEDEVAL must follow a literal push of the scriot
243 2011-12-29 16:55:39 <TD> jgarzik: for example, if Script is changed .....
244 2011-12-29 16:56:24 <gmaxwell> TD: people do research all the time on systems which aren't set in stone, it's called dealing with reality. :-)
245 2011-12-29 16:56:43 <sipa> roconnor: which means you can statically analyze it, as the <code> + OP_CHECKEDEVAL pair can be seen and parsed as code
246 2011-12-29 16:57:10 <gmaxwell> TD: are any of them looking at that part of the system? That would be nice.
247 2011-12-29 16:57:24 <TD> which part? script?
248 2011-12-29 16:57:41 <gmaxwell> Yes.  Seems to me that people like to do deanonmization or boring p2p protocol stuff because it's cheap headlines.
249 2011-12-29 16:57:50 <TD> i'm not sure. i'm about half way through this video
250 2011-12-29 16:57:57 <TD> he seems to be talking about economics currently
251 2011-12-29 16:58:22 <TD> he thinks there has to be a way to recover lost bitcoins
252 2011-12-29 16:58:39 <sipa> who is 'he' ?
253 2011-12-29 16:58:39 <TD> i'm watching this one: http://www.youtube.com/28c3#p/u/5/rJN0Hm3srUc
254 2011-12-29 16:59:09 <TD> the speaker
255 2011-12-29 16:59:11 <sipa> ok
256 2011-12-29 16:59:20 <lianj> jgarzik: how are ccc crowd outsiders?
257 2011-12-29 16:59:32 <makomk> luke-jr: btw, it looks like -blocknotify leaks zombie child processes?
258 2011-12-29 17:00:00 <gmaxwell> downside of increasing popularity is the constant supply of new people who come up with the same IMPORTANT IDEAS everyone else does. Gets really tiring to hear the same things rehashed over and over again.
259 2011-12-29 17:00:47 <lianj> gmaxwell: well the talk TD is watch certainlly will not provide popularity/new-users
260 2011-12-29 17:01:29 <TD> i think it's fair enough
261 2011-12-29 17:01:36 <TD> there hasn't been enough research into tx graph analysis
262 2011-12-29 17:01:51 <lianj> TD: which is the third one? the blackops tcp one?
263 2011-12-29 17:01:54 <TD> in future i think we'll see wallets that actively attempt to improve your privacy
264 2011-12-29 17:02:00 <TD> lianj: yeah
265 2011-12-29 17:02:07 <TD> lianj: but it was just a repeat of the BH talk kaminsky gave
266 2011-12-29 17:02:28 <lianj> ah ok. iirc it was quite similar to the ccc-camps talk and defcon talk by him
267 2011-12-29 17:02:39 <lianj> yea
268 2011-12-29 17:03:00 <gmaxwell> TD: there are patches that help, but it's hard. I think these things are true: (1) you will always leak some information when you spend, (2) if any information is leaked there is always the possiblity of an attacker with better statistical tools (or better priors) identifying you.
269 2011-12-29 17:03:09 <TD> like, by breaking up transaction outputs into roughly equal size. i think in future we'll see groups of receiving pubkeys be sent by recipients to senders
270 2011-12-29 17:03:19 <gmaxwell> The research in that area is helpful, but it can't really lead to solutions to the above.
271 2011-12-29 17:04:15 <TD> i think the graph can be obfuscated pretty well. i think this will be a give/take thing .... attackers will show the current wallet softwares aren't doing a good enough job of obfuscation, the ecosystems tools/protocols will improve, wash/rinse/repeat
272 2011-12-29 17:04:27 <gmaxwell> TD: I was unsuccessful in talking pools into rounding their payments to avoid jagged coins that tag change. I don't think most of the community cares about privacy, much less anonymity.
273 2011-12-29 17:05:06 <lianj> TD: i was in the analysis talk, the room was full. not sure how many actual bitcoin users where there though
274 2011-12-29 17:05:16 <TD> privacy and anonymity are two sides of the same coin, the difference is "privacy" tends to mean "keeping my business away from my peers/companies" whereas anonymity tends to trigger associations of hiding from governments
275 2011-12-29 17:05:25 <TD> i agree, few people truly care about anonymity
276 2011-12-29 17:05:26 <copumpkin> are there plans to give the mainstream client the ability to control where the coins being spent are coming from?
277 2011-12-29 17:05:45 <TD> but most people do care about privacy. perversely, bitcoin is better at anonymity than privacy, when it should really be the other way around.
278 2011-12-29 17:05:47 <TD> but that can be fixed
279 2011-12-29 17:06:23 <gmaxwell> TD: I think it's more than that. I have privacy when figuring out what I'm doing is hard enough to block casual observation or large scale data mining, where anonymity needs to survive a targeted attack.
280 2011-12-29 17:06:23 <TD> copumpkin: some people have written patches that give you more control. i think automatic/implicit privacy protections are the way to go
281 2011-12-29 17:06:56 <gmaxwell> TD: e.g. you have privacy with a bank, but anyone with a legit need can petition a court to subpoena your records.
282 2011-12-29 17:06:58 <TD> gmaxwell: perhaps. technology is making "large scale data mining" and "targeted attack" not so different
283 2011-12-29 17:07:07 <gmaxwell> TD: fair enough.
284 2011-12-29 17:07:16 <TD> gmaxwell: yes, the banking model provides a good tradeoff, if you assume trusted governments. that's starting to break down though
285 2011-12-29 17:07:23 <TD> 1) governments are becoming less trustworthy
286 2011-12-29 17:07:37 <TD> 2) "banks" and payment processors are starting to wake up to the value of their data and selling it
287 2011-12-29 17:07:56 <roconnor> [12:55] <sipa> roconnor: with the explicit extra rule that OP_CHECKEDEVAL must follow a literal push of the scriot
288 2011-12-29 17:08:10 <TD> still
289 2011-12-29 17:08:22 <roconnor> sipa: I'd probably okay with that if you can make it work
290 2011-12-29 17:08:24 <gmaxwell> I don't know how useful it is to worry about government attack. It's really easy to underestimate how insanely powerful goverments are when they choose to be. But (2) resonates more for me.
291 2011-12-29 17:08:29 <roconnor> sipa: but My proposal is still better
292 2011-12-29 17:08:30 <TD> finding a way to balance these competing requirements would be good
293 2011-12-29 17:09:15 <TD> gmaxwell: i find it the other way around, actually. companies and banks are fairly restricted by privacy laws and those laws are just getting more restrictive with time. and ultimately in a working market i can go elsewhere. (maybe not with credit cards)
294 2011-12-29 17:09:17 <TD> http://consumerist.com/2011/10/credit-cards-to-sell-your-buying-history-so-online-advertisers-can-target-you-more-precisely.html
295 2011-12-29 17:09:23 <TD> "The company has since walked that back after they realized it would break rules about how financial-services companies can use their members' data. Now MasterCard and Visa have moved onto an idea where cardholders are anonymized and aggregated into various "buyer profiles" that can be sold to online advertisers."
296 2011-12-29 17:09:28 <TD> the latter doesn't really bother me
297 2011-12-29 17:10:02 <TD> gmaxwell: OTOH there are lots of examples of governments going on fishing expeditions, losing data, abusing power, etc. and that's the "good" ones! the perfect balance, for me, would be a system which makes court issued warrants effective
298 2011-12-29 17:10:16 <TD> but does not allow for TFTP-style unsupervised monitoring
299 2011-12-29 17:10:52 <gmaxwell> TD: governments can simply throw everyone who might know something into prisons until they agree to help. Makes a lot of cipherpunk solutions look like paper armor, especially considering how leaky even careful technology use it.
300 2011-12-29 17:10:52 <TD> this talk is mostly just giving stats about the tx graph. it's not really a security analysis, it seems.
301 2011-12-29 17:11:05 <TD> gmaxwell: yes, sure. i agree. and that's fine. that's the point of warrants.
302 2011-12-29 17:11:36 <TD> gmaxwell: the bigger problem from a civil liberties POV is cases where the entire, strongly authenticated, payments graph is imported into a single database
303 2011-12-29 17:11:42 <TD> and you can't escape from it. this happens already.
304 2011-12-29 17:12:01 <TD> there are effectively no controls or auditing on such systems and so it's basically guaranteed they will be abused
305 2011-12-29 17:12:07 <sipa> roconnor: it doesn't need extra 20 bytes storage, is even shorter than the current OP_EVAL script, allows analysis, does not introduce turing-completeness, ...
306 2011-12-29 17:12:14 <TD> and/or possibly compromised
307 2011-12-29 17:12:18 <gmaxwell> TD: I think the subject is all clouded by fairly unsophicated thinking in our community "I never put in my name! I'm anonymous!" or "I'll just use a MIXER! and they'll never catch me". Basically, a lot of people deny that there are very hard problems here.
308 2011-12-29 17:12:21 <sipa> roconnor: all advantages, except the subscript is serialized instead of a real script
309 2011-12-29 17:12:24 <TD> yes
310 2011-12-29 17:13:26 <TD> and that's before you even get into the regulatory aspects. theoretically everyone is supposed to know who they are trading with, and check against various blacklists (at least in the usa). which is itself a problem for democracy, of course, but the idea of being anonymous falls over when you encounter businesses who want ID verification
311 2011-12-29 17:14:12 <gmaxwell> I sent an international wire a couple weeks ago. Oy. I had to list all the nationalities of the recipient. wtf.
312 2011-12-29 17:14:12 <roconnor> sipa: well you still have to deal with the no OP_CODESEPARATORS in OP_EVAL, can IF statements span accrosss OP_EVAL boundaries (for the love of all that is holy I hope the answer is no), does the alt_stack get preserved through the OP_EVAL call or pushed and popped, plus anything else that I haven't thought of.
313 2011-12-29 17:14:24 <TD> i think a very interesting area of research would be to find a way of using cryptography to balance the needs of law enforcement vs privacy vs civil liberties, such that there is minimal potential for systematic abuse
314 2011-12-29 17:15:00 <TD> gmaxwell: well the current set of rules are well intentioned but absurd and in many ways harmful, imho
315 2011-12-29 17:15:23 <gmaxwell> TD: I think the answer is probably no there because the vast resources imbalaces make almost any attempt to balance anything fail. (though I'd be glad to see magical solutions!)
316 2011-12-29 17:15:23 <sipa> roconnor: the subscript is a completely independent execution environnement, that only inherits the stack
317 2011-12-29 17:15:45 <roconnor> sipa: that's how it is now, but gavin wants to "fix" this IIUC
318 2011-12-29 17:15:46 <sipa> roconnor: it does not return anything, the only output possible is that it can cause failure, in which case the entire script fails
319 2011-12-29 17:15:47 <TD> gmaxwell: doubt it. the internet is, after all, both invented by government and to a large extent private. not perfectly so, but "good enough"
320 2011-12-29 17:16:09 <sipa> roconnor: where do you read that?
321 2011-12-29 17:16:12 <TD> gmaxwell: i mean, if you want to, you can be pretty much entirely anonymous. everyday usage is private enough, but law enforcement can still act
322 2011-12-29 17:16:42 <TD> gmaxwell: there aren't many controls against centralized abuse though. nothing which _requires_ warrants
323 2011-12-29 17:16:46 <gmaxwell> TD: eh, well, we gain a lot of privacy due to the fact that if the privacy breaking things were made known they'd lose their effectiveness. :)
324 2011-12-29 17:16:49 <roconnor> sipa: https://github.com/bitcoin/bitcoin/issues/729#issuecomment-3294453
325 2011-12-29 17:17:05 <roconnor> sipa: this is my "second" bug found ... not that I knew it was a bug
326 2011-12-29 17:17:16 <roconnor> sipa: cause I have no idea what OP_EVAL is supposed to be exactly
327 2011-12-29 17:18:12 <roconnor> sipa: what gavin writes in that comment suggests he is going to enable spaning of IF statments accross OP_EVAL block
328 2011-12-29 17:18:23 <roconnor> sipa: which I think will literally make my head explode if he does that.
329 2011-12-29 17:19:38 <sipa> hmm, i don't read that there
330 2011-12-29 17:19:48 <roconnor> ``clearing the alt stack and the fExec state are bugs, because the BIP doesn't say they should be cleared.
331 2011-12-29 17:20:22 <roconnor> I admit it isn't entirely clear what he means
332 2011-12-29 17:20:29 <sipa> right, fExec is for if/then/else constructs?
333 2011-12-29 17:20:34 <roconnor> so there is hope for my head to remain intact
334 2011-12-29 17:20:37 <roconnor> yep
335 2011-12-29 17:21:43 <roconnor> if IF statements span OP_EVAL blocks I will have suceeded in making the OP_EVAL proposal even worse than when I started.
336 2011-12-29 17:23:08 <roconnor> sipa: thinking about the implications of this is what started me thinking about OP_GOTO
337 2011-12-29 17:23:38 <roconnor> OP_EVAL is sort of like a subroutine call
338 2011-12-29 17:23:55 <roconnor> and having if statement span subroutines is the antithesis of structured programming
339 2011-12-29 17:24:00 <TD> hmm
340 2011-12-29 17:24:02 <TD> en.bitcoin.it is gone ?
341 2011-12-29 17:24:09 <roconnor> of course you guys say the scripts are short code so who cares.
342 2011-12-29 17:24:14 <TD> looks like mtgox is getting DoSd again ?
343 2011-12-29 17:24:45 <jgarzik> TD: en.bitcoin.it DNS confirmed MIA
344 2011-12-29 17:24:45 <roconnor> TD: it's been down for at least a few hours
345 2011-12-29 17:24:53 <roconnor> oh
346 2011-12-29 17:24:57 <TD> oh dear
347 2011-12-29 17:24:59 <TD> he let it expire
348 2011-12-29 17:25:00 <jgarzik> nxdomain
349 2011-12-29 17:25:00 <roconnor> SOPA?
350 2011-12-29 17:25:05 <TD> Domain:             bitcoin.it
351 2011-12-29 17:25:19 <TD> Created:            2010-12-01 10:15:11
352 2011-12-29 17:25:23 <TD> so i guess it'll be back soon
353 2011-12-29 17:25:24 <gmaxwell> ...
354 2011-12-29 17:25:30 <gmaxwell> back soon, as a pornspam site?
355 2011-12-29 17:37:01 <[Tycho]> Hmm, looks like it's time to create a strange TX using altstack and IFs :)
356 2011-12-29 17:43:04 <roconnor> is OP_EVAL enabled on testnet?
357 2011-12-29 17:43:26 <roconnor> If not, why aren't we doing it on testnet first?
358 2011-12-29 17:47:05 <[Tycho]> May be because it's not as much fun as the main net ?
359 2011-12-29 17:47:14 <roconnor> lol
360 2011-12-29 17:47:45 <TD> hah
361 2011-12-29 17:47:52 <gmaxwell> roconnor: it's been tested on test net, yes. there isn't so much 'enabling' there because there isn't really a regular mining pool.
362 2011-12-29 17:48:15 <roconnor> gmaxwell: so there are OP_EVAL uses on testnet?
363 2011-12-29 17:48:18 <gmaxwell> (by pool I mean a base of miners, I don't mean a mining pool in the normal way, sorry)
364 2011-12-29 17:48:41 <roconnor> I guess without 50% of the testnet mining, it is pretty hard
365 2011-12-29 17:48:59 <sipa> gmaxwell: pretty nice idea, that push-only stack
366 2011-12-29 17:49:30 <roconnor> a stack isn't a stack without pop :D
367 2011-12-29 17:49:34 <gmaxwell> sipa: I thought it would solve it neatly. I don't have any strong preferences. I just want something that addresses all concerns with no compromises. :)
368 2011-12-29 17:49:47 <sipa> i'm typing a mail
369 2011-12-29 17:49:49 <roconnor> but ya, no arithmetic is good.
370 2011-12-29 17:50:27 <roconnor> and so is putting the code right next to the OP_EVAL
371 2011-12-29 17:50:40 <roconnor> but I don't think that happens in the proposed standard transactions
372 2011-12-29 17:50:55 <roconnor> and we would need another command to push to this new stack
373 2011-12-29 17:51:28 <gmaxwell> roconnor: just make the normal pushes all push to it.
374 2011-12-29 17:51:33 <sipa> exactly
375 2011-12-29 18:06:47 <copumpkin> lol
376 2011-12-29 18:06:58 <copumpkin> the bitcoin.it domain expired, or so someone on reddit says
377 2011-12-29 18:07:22 <pirateat40> good times
378 2011-12-29 18:09:09 <gmaxwell> copumpkin: welcome to several hours ago
379 2011-12-29 18:09:20 <copumpkin> thanks!
380 2011-12-29 18:09:44 <sipa> roconnor: proposal mailed :)
381 2011-12-29 18:11:22 <copumpkin> a proposal mailed is a proposal failed
382 2011-12-29 18:11:53 <sipa> possibly
383 2011-12-29 18:13:05 <TD> haha
384 2011-12-29 18:13:09 <TD> good slogan
385 2011-12-29 18:24:01 <luke-jr> copumpkin: easily verified :P
386 2011-12-29 18:39:02 <roconnor> sipa: darn.  My first attempt at implementing the SK calculus with unlimited OP_EVAL has failed :(
387 2011-12-29 18:39:15 <roconnor> sipa: I need OP_CONCAT or something like that :(
388 2011-12-29 18:39:38 <sipa> OP_CAT ?
389 2011-12-29 18:39:48 <roconnor> ya
390 2011-12-29 18:40:03 <roconnor> even then I'm not sure I could do it this way
391 2011-12-29 18:40:11 <sipa> OP_CAT exists (but is disabled)
392 2011-12-29 18:40:18 <roconnor> ya
393 2011-12-29 18:40:52 <sipa> so...?
394 2011-12-29 18:41:08 <roconnor> well I don't want to use disabled operations
395 2011-12-29 18:44:15 <roconnor> sipa: I need to pop x and y off the stack and push {OP_PUSHDATA x; y}
396 2011-12-29 18:44:19 <roconnor> :(
397 2011-12-29 18:44:29 <sipa> hmm?
398 2011-12-29 18:44:44 <roconnor> that said maybe there are other ways to proceed
399 2011-12-29 19:30:20 <gavinandresen> Howdy y'all.
400 2011-12-29 19:30:29 <[Tycho]> Hello, gavinandresen.
401 2011-12-29 19:31:53 <gavinandresen> roconnor: you're right, the 'if state' shouldn't percolate down into OP_EVAL (but the altstack should).
402 2011-12-29 19:32:20 <gavinandresen> sipa:  interesting proposal, the only downside is we lose the "old clients half-validate"
403 2011-12-29 19:32:54 <sipa> hmm, right; hadn't thought about that
404 2011-12-29 19:33:14 <sipa> i'm actually pondering about the alt stack
405 2011-12-29 19:33:40 <sipa> if that isn't inherited, a main script could control which data gets passed to subscripts
406 2011-12-29 19:33:48 <sipa> by hiding it in the altstack
407 2011-12-29 19:35:06 <gavinandresen> Interesting...
408 2011-12-29 19:35:26 <gavinandresen> Well, it is either a bug in the BIP or a bug in the code
409 2011-12-29 19:36:13 <sipa> I do feel much more confident with execution state of the inner script being independent, though
410 2011-12-29 19:38:11 <gavinandresen> I did a little refactoring of the OP_EVAL code yesterday to move the stack/altstack and all the pass-by-reference EvalScriptInner variables into a ScriptEvalContext structure.  Makes the code easier to understand, and would make rules like "this is/isn't shared state" easier to see.
411 2011-12-29 19:46:39 <sipa> i just realize the checking and evaluation can be done separately in my proposal as well; have OP_EVAL *not* touch the stack at all (and execute the subscript in an independent context), which you need for the clean semantics of overriding OP_NOP1
412 2011-12-29 19:46:45 <sipa> and do the checking as usual
413 2011-12-29 19:47:18 <sipa> <scriptHash> OP_EVAL OP_HASH160 OP_EQUALVERIFY, e.g.
414 2011-12-29 19:48:00 <sipa> so OP_EVAL uses the code-position wise last literal, and OP_HASH160 uses its value pushed on the normal stack
415 2011-12-29 19:48:04 <gavinandresen> ... EQUALVERIFY OP_1   (you have to leave a true value on the stack)
416 2011-12-29 19:48:26 <sipa> just OP_EQUAL then
417 2011-12-29 19:48:44 <gavinandresen> .... good idea
418 2011-12-29 19:49:00 <sipa> why didn't this discussion happen 3 months ago...
419 2011-12-29 19:49:03 <gavinandresen> I think I like that.
420 2011-12-29 19:49:18 <gavinandresen> Because deadlines make people pay attention
421 2011-12-29 19:49:34 <sipa> so it seems
422 2011-12-29 19:50:18 <sipa> luke-jr: the above idea also does
423 2011-12-29 19:50:24 <luke-jr> sipa: it does? cool
424 2011-12-29 19:50:29 <luke-jr> sipa: without new addresses, too?
425 2011-12-29 19:50:31 <sipa> it's really just a more restricted OP_EVAL
426 2011-12-29 19:52:45 <gavinandresen> I particularly like the "OP_EVAL is a no-op for by construction"
427 2011-12-29 19:53:01 <gavinandresen> ^for^^
428 2011-12-29 19:56:23 <gavinandresen> The only thing I'd quibble with is whether introducing Yet Another Stack is worth it; is anybody really going to try to do static analysis of arbitrary code, rather than just template-matching a set of standard transaction types?
429 2011-12-29 19:57:01 <gavinandresen> After all, we already have to deal with possibly-calculated CHECKMULTISIG arguments
430 2011-12-29 20:00:29 <gmaxwell> roconnor: ^ ? If anyone is going to say yes to 'static analysis of arbitrary code' it's you.
431 2011-12-29 20:01:01 <sipa> it's not actually a stack (though you can implement it using one)
432 2011-12-29 20:01:30 <sipa> it's really just looking back at the last not-yet-executed literal pushed
433 2011-12-29 20:02:24 <sipa> gavinandresen: and it does allow you to for example parse a script in advance and deserialize it, before execution
434 2011-12-29 20:04:06 <gavinandresen> sipa:  yes, but my point is if you're using nothing but 'standard' transactions then you'll be able to do that anyway.
435 2011-12-29 20:05:07 <sipa> if we only allow standard transaction, a simple transaction_type enum would suffice, instead of a script language :)
436 2011-12-29 20:05:20 <gavinandresen> sipa:  that would have been my preference :)
437 2011-12-29 20:05:29 <BlueMatt> then do that
438 2011-12-29 20:05:37 <gmaxwell> you guys are super unfun.
439 2011-12-29 20:05:39 <BlueMatt> (for OP_EVAL)
440 2011-12-29 20:05:49 <sipa> that would spoil the fun
441 2011-12-29 20:07:05 <gmaxwell> meh, the scripts are useful and allow good arguments about the security properties.
442 2011-12-29 20:07:14 <BlueMatt> heh
443 2011-12-29 20:08:23 <gmaxwell> E.g. someone once said to me 'oh but if _any_ weakness is found in ecdsa then bitcoin is instantly over', and I could retort no then we just use a new previously no-op opcode for a different signature type, and start writing txns that require both types of signature, and then we can gracefully upgrade without having to flag day it.
444 2011-12-29 20:08:39 <gmaxwell> Without scripts I wouldn't have been able to do that any such fix would require flagdaying the network.
445 2011-12-29 20:08:54 <gavinandresen> Yup, they are darn useful for backwards-compatible changes
446 2011-12-29 20:09:35 <gmaxwell> (and aruging that we _can_ easily flagday it is an argument that its not really decenteralized, so its not a good argument even if its might be somewhat true)
447 2011-12-29 20:11:36 <roconnor> sipa: it isn't "last code-position wise literal", it is "last code-execution wise literal" due to the presence of OP_IF
448 2011-12-29 20:12:00 <roconnor> sipa: I didn't have this conversation 2/3 months ago because it wasn't chirstmas break then.
449 2011-12-29 20:12:06 <roconnor> and I have a day job
450 2011-12-29 20:12:35 <sipa> roconnor: i explicitly mean the previous push in the code, even if it wasn't executed
451 2011-12-29 20:12:56 <sipa> wait
452 2011-12-29 20:13:07 <sipa> that would be very bad
453 2011-12-29 20:14:39 <sipa> that would allow someone to do a "<script satisfying required hash> 0 OP_IF <evil script> OP_ENDIF"
454 2011-12-29 20:14:47 <sipa> bah
455 2011-12-29 20:15:56 <roconnor> yes it would be very bad
456 2011-12-29 20:16:32 <roconnor> sipa: sorry, I had considered this sort of thing when thinking about my proposal
457 2011-12-29 20:17:00 <sipa> yes, so did i when i wrote the first one
458 2011-12-29 20:17:17 <sipa> but seem to have forgotten about when writing the update
459 2011-12-29 20:27:02 <helo> so this may be going live in ~1 month?
460 2011-12-29 20:29:19 <gavinandresen> The only thing possibly going live in 1-month is the un-modified original OP_EVAL proposal.
461 2011-12-29 20:29:39 <gavinandresen> ... if the general consensus is that the proposal should be modified, then the schedule will be pushed.
462 2011-12-29 20:34:43 <roconnor> gavinandresen: Just to warn you, if you don't delay the OP_EVAL proposal I will start a campagin (aka a blog post) to vote "no" on OP_EVAL. I don't mean this in a threatening way; I think it is fair for me to publicly argue against OP_EVAL.  I feel strongly that it is a bad propsal and it is up to the miners to decide.  I can pass my post along to you first if you like before posting it publically.
463 2011-12-29 20:37:02 <gavinandresen> roconnor: ok
464 2011-12-29 20:37:15 <helo> sounds like a viable way to establish general consensus
465 2011-12-29 20:37:44 <gmaxwell> helo: not really.
466 2011-12-29 20:37:59 <gavinandresen> what sounds like a viable way?  99.999% of bitcoin using people will have no idea what we're talking about
467 2011-12-29 20:38:53 <gavinandresen> ... and there's a good chance some writer will pick it up and there will be a slashdot headline "Major Schism in the BItcoin Community Threatens Fledgling Currency"
468 2011-12-29 20:38:59 <gmaxwell> ^ because that, also because miners have delegated their authority to pools. (and evidence suggests that in large miners aren't too thoughtful about their mining e.g. they'll happily mine on higher fee pools when lower fee ones are available with compariable options)
469 2011-12-29 20:39:03 <Diablo-D3> wait
470 2011-12-29 20:39:06 <Diablo-D3> first of all
471 2011-12-29 20:39:08 <Diablo-D3> any journalist
472 2011-12-29 20:39:09 <Diablo-D3> that prints
473 2011-12-29 20:39:10 <Diablo-D3> the words
474 2011-12-29 20:39:15 <Diablo-D3> "bitcoin community" is a bold faced liar
475 2011-12-29 20:39:18 <Diablo-D3> theres no such thing
476 2011-12-29 20:39:20 <roconnor> gavinandresen: ya, I know :(
477 2011-12-29 20:39:28 <Diablo-D3> its a group of ten people, ten people does not form a community
478 2011-12-29 20:40:16 <gmaxwell> and to the extent that the 99.999% care it will either be on the basis of the good stuff op_eval enables, or the bad stuff the journalist makes up (and not the actual issues raised).
479 2011-12-29 20:40:37 <roconnor> gmaxwell: I know :(
480 2011-12-29 20:40:53 <Diablo-D3> gmaxwell: man
481 2011-12-29 20:40:59 <Diablo-D3> a journalist should pick up that thread
482 2011-12-29 20:41:08 <Diablo-D3> "bitcoin community turns on founding member"
483 2011-12-29 20:41:09 <sipa> gavinandresen: anyway, my last proposal isn't good (though you can use the idea of no-op by construction in the current eval idea, without getting static analyzability)
484 2011-12-29 20:41:21 <copumpkin> gavinandresen: the other option is to just delay it and figure out the issues?
485 2011-12-29 20:41:28 <copumpkin> so no journalist schism bullshit
486 2011-12-29 20:41:35 <copumpkin> no bad op_eval unexpected problems
487 2011-12-29 20:41:44 <copumpkin> and unicorns and rainbows
488 2011-12-29 20:42:15 <[eval]> "major schism in bitcoin commuinty" = good for those of us trying to buy more coins on the cheap :D
489 2011-12-29 20:42:20 <copumpkin> lol
490 2011-12-29 20:42:40 <gmaxwell> [eval]: you can't predict that.
491 2011-12-29 20:42:54 <[eval]> gmaxwell: i know... i was mostly kidding.
492 2011-12-29 20:43:00 <gmaxwell> [eval]: "major schism in bitcoin commuinty" may equal, "omg bitcoin undervalued because of bad press, buy buy buy"
493 2011-12-29 20:43:14 <copumpkin> gmaxwell: you can't explain that
494 2011-12-29 20:43:18 <copumpkin> just like tides
495 2011-12-29 20:43:37 <gavinandresen> sipa:  what if the rule was "EVAL evaluates the item on the top of the stack, which must immediately precede the EVAL with no other opcodes in between"
496 2011-12-29 20:44:16 <gavinandresen> sipa:  scriptSig would be   <sigs> <script>   scriptPubKey would be:  EVAL HASH160 <> EQUAL
497 2011-12-29 20:44:24 <gavinandresen> (EVAL would just execute, not consume)
498 2011-12-29 20:44:33 <sipa> gavinandresen: that[ possible, but precludes multiple OP_EVAL's
499 2011-12-29 20:45:23 <sipa> although you could weaken it a bit to: element popped of the literal stack must equal (at runtime) element at top of main stack
500 2011-12-29 20:45:43 <sipa> but that feels dirty
501 2011-12-29 20:46:40 <copumpkin> damn stack languages, always complicating things
502 2011-12-29 20:47:19 <luke-jr> can we switch to MIPS yet?
503 2011-12-29 20:47:42 <roconnor> MIPS?
504 2011-12-29 20:47:54 <sipa> i vote INTERCAL
505 2011-12-29 20:48:15 <gmaxwell> COME FROM FTW.
506 2011-12-29 20:50:59 <ByteCoin2> ping Gavin
507 2011-12-29 20:51:07 <sipa> hello ByteCoin2
508 2011-12-29 20:51:18 <gavinandresen> howdy ByteCoin2
509 2011-12-29 20:51:27 <ByteCoin2> Ok so there's some push back against OP_EVAL
510 2011-12-29 20:51:59 <ByteCoin2> Just out of interest.. what's so bad about evaluating as scripts the result of calculations?
511 2011-12-29 20:52:00 <roconnor> ByteCoin2: it might be just me.
512 2011-12-29 20:52:01 <gavinandresen> roconnor hates it.  TD doesn't like spend-to-script addresses in general....
513 2011-12-29 20:52:16 <ByteCoin2> And what's so good about static analysis?
514 2011-12-29 20:52:26 <TD> specifically, it's changing Script that i'm uneasy about
515 2011-12-29 20:52:37 <TD> spend-to-script would be fine if the address contained the actual script
516 2011-12-29 20:53:01 <gavinandresen> (I sit corrected, thanks TD)
517 2011-12-29 20:53:24 <ByteCoin2> Aren't we a little far down the line?
518 2011-12-29 20:53:39 <ByteCoin2> There's nothing in the proposal that's broken
519 2011-12-29 20:53:43 <roconnor> static analysis lets you do all sorts of great things potentially: gathering statics, byte-code compilation, who knows.
520 2011-12-29 20:54:01 <ByteCoin2> Precisely... who knows?
521 2011-12-29 20:54:14 <gavinandresen> I think so, yes.  Although roconnor brings up excellent points-- at the very least the BIP should specify what happens to the altstack and if-state across an OP_EVAL
522 2011-12-29 20:54:18 <roconnor> ByteCoin2: well the code was broken and there is the alt-stack issue which is either a bug in the BIP or in the code depending on what we decide.
523 2011-12-29 20:54:29 <sipa> the fact that it is possible is kind of a proof of a clean language semantics
524 2011-12-29 20:54:52 <roconnor> ByteCoin2: AFAIU we are not too far down the line until Jan 15th
525 2011-12-29 20:55:02 <copumpkin> I mean, you guys all set the timelines anyway
526 2011-12-29 20:55:04 <gmaxwell> More concretely it allows you to make fairly tight statements about the computational complexity of a script without actually executing it.
527 2011-12-29 20:55:06 <ByteCoin2> sipa: What? So the fact that static analysis is possible is proof of clean language semantics?
528 2011-12-29 20:55:12 <copumpkin> it seems weird to present them as some unstoppable train
529 2011-12-29 20:55:19 <sipa> proof is the wrong word
530 2011-12-29 20:55:42 <ByteCoin2> gmaxwell: That might be a concern if your talking about thousands of lines of source code..
531 2011-12-29 20:56:02 <ByteCoin2> I believe it will take longer to statically analyse a script than to execute it
532 2011-12-29 20:56:05 <sipa> we are... spread over millions of small programs
533 2011-12-29 20:56:32 <ByteCoin2> Identical programs adhering to specific IsStandard rules
534 2011-12-29 20:56:45 <gmaxwell> ByteCoin2: FWIW, I don't really share rconnor's concerns (beyond the basic software QA ones),  but I think I at least understand them. And I think they're worth accommodating if we can do so at minimal cost.
535 2011-12-29 20:56:59 <sipa> agree with gmaxwell here
536 2011-12-29 20:57:01 <gmaxwell> ByteCoin2: the scripts in the chain can't be subject to IsStandard, of course.
537 2011-12-29 20:58:21 <gmaxwell> A key point here is that this is all fundimental to the trustworthness of the system. Rconnor's views might be an overreaction, but there are millions of other people who are looking for excuses to not trust the bitcoin system, and there will be other very smart people (like rconnor) who share his concerns. This makes them worth addressing, independant of their direct pratical merits.
538 2011-12-29 20:58:59 <Diablo-D3> gmaxwell: wait wait wait
539 2011-12-29 20:59:00 <Diablo-D3> hold up
540 2011-12-29 20:59:00 <roconnor> gavinandresen: when the wiki is back you, you should describe how OP_EVAL interact with OP_IF on the BIP page.
541 2011-12-29 20:59:27 <roconnor> ie, all OP_IFs must be closed off before ending the OP_EVAL'd script
542 2011-12-29 20:59:35 <ByteCoin2> I've read the new proposal and I couldn't follow how it all works on the stack
543 2011-12-29 21:00:03 <gmaxwell> (and I think the combination of IsStandard and the strict limits on op_eval make the concerns not very pratical then again, I'm not writing or planning to write a script engine and rconnor has been)
544 2011-12-29 21:00:24 <sipa> I hope we won't need IsStandard anymore some time in the future.
545 2011-12-29 21:00:28 <Diablo-D3> A key point here is that this is all fundimental to the trustworthyness of the government. Ron Paul's views might be an overreaction, but there are millions of other people who are looking for excuses to not trust the government, and there will be other very smart people (like Ron Paul) who share his concerns. This makes them worth addressing, independant of their direct practical merits.
546 2011-12-29 21:00:52 <copumpkin> o.O
547 2011-12-29 21:01:11 <ByteCoin2> Basically, I'm hearing that OP_EVAL is "too expressive". Isn't that a good thing?
548 2011-12-29 21:01:14 <gmaxwell> Diablo-D3: and when ron paul raises and issue that can be costlessly corrected, it happens. ::shrugs::
549 2011-12-29 21:01:15 <copumpkin> no
550 2011-12-29 21:01:27 <copumpkin> ByteCoin2: in PL circles, we try to avoid "too expressive" with barge poles ;)
551 2011-12-29 21:01:42 <ByteCoin2> Rubbish
552 2011-12-29 21:01:44 <copumpkin> being turing complete is way easier than designing something that is tastefully not
553 2011-12-29 21:01:49 <copumpkin> no it isn't
554 2011-12-29 21:01:52 <gmaxwell> ByteCoin2: it's an expressive in a way that make it enormously harder to reason about the scripts formally, relative to the increase in expressiveness.
555 2011-12-29 21:01:53 <sipa> ByteCoin2: to exaggerate... if OP_EVAL were OP_ASMX86, it would be even more expressive and more efficient - that wouldn't make it a good proposal, right?
556 2011-12-29 21:02:04 <Diablo-D3> what if it was OP_JPG?
557 2011-12-29 21:02:09 <Diablo-D3> LOLCHILDPORNS
558 2011-12-29 21:02:15 <copumpkin> OP_EXPLOITABLETIFF
559 2011-12-29 21:02:16 <ByteCoin2> Language design is always moving towards more expressive constructions
560 2011-12-29 21:02:24 <roconnor> sipa: espeically since bitcoin only runs on x86 right now ;)
561 2011-12-29 21:02:25 <Diablo-D3> "breaking news: this just in, running bitcoin can get you raped by the FBI"
562 2011-12-29 21:02:37 <gmaxwell> ByteCoin2: e.g. with our size limits, the ability to execute code you computed is almost certantly pratically useless. But it makes it impossible, e.g. always be able to count up the maximum signature evaluations a particular script might run.
563 2011-12-29 21:02:40 <copumpkin> ByteCoin2: we already hit the peak in computing power back when we figured out what turing machines did
564 2011-12-29 21:02:46 <copumpkin> ByteCoin2: should we give up on language design?
565 2011-12-29 21:02:53 <ByteCoin2> Ok gmaxwell puts your point better
566 2011-12-29 21:02:58 <Diablo-D3> after lisp? yes.
567 2011-12-29 21:03:03 <copumpkin> lol
568 2011-12-29 21:03:20 <roconnor> we are talking about expressiveness in a different sense than languages that are already turing complete.
569 2011-12-29 21:03:56 <ByteCoin2> But it will take longer to reason about the execution of the script than  actually executing it!
570 2011-12-29 21:03:59 <copumpkin> ByteCoin2: I interpreted your original point about being too expressive as having a lot of computational power, which is what I said PL people tried to avoid, tastefully
571 2011-12-29 21:04:06 <roconnor> but, ya, where copumpkin and I come from, turing completeness is bad.
572 2011-12-29 21:04:13 <gmaxwell> Likewise, e.g. a script to x86 compiler probably becomes an order of magnitude harder (well, ignoring the fact that one could detect these cases and abort to a fallback)... again, for no real benefit because we can't actually use the expressiveness.
573 2011-12-29 21:04:50 <ByteCoin2> Why on earth would you want to compile bitcoin script to x86?
574 2011-12-29 21:04:55 <gavinandresen> I thought we all agreed that our limited-recursion, limited-opcount expression evaluation language is not turing complete.
575 2011-12-29 21:05:00 <copumpkin> ByteCoin2: it was a joke point :P
576 2011-12-29 21:05:10 <gmaxwell> gavinandresen: yes, though by the same argument your computer isn't either.
577 2011-12-29 21:05:15 <roconnor> gavinandresen: well, my laptop isn't turing complete either
578 2011-12-29 21:05:24 <copumpkin> gavinandresen: some would argue limited-recursion isn't a feature of the language as much as one of the interpreter
579 2011-12-29 21:05:25 <ByteCoin2> I'm all for jokes but could we perhaps talk about this seriously for a bit?
580 2011-12-29 21:05:35 <copumpkin> and that thus, abstractly, the language is still too powerful
581 2011-12-29 21:06:02 <ByteCoin2> So what's so bad about the "extra" power?
582 2011-12-29 21:06:03 <gavinandresen> all righty, y'all are getting at why these arguments get so frustrating:  IN PRACTICE, is there a problem with OP_EVAL as proposed?
583 2011-12-29 21:06:06 <gmaxwell> (thats the argument, personally I agree that the limitations are adequate the stand against turing complete here is principled not pratical)
584 2011-12-29 21:06:10 <copumpkin> ByteCoin2: rice's theorem, etc.
585 2011-12-29 21:06:18 <gavinandresen> We could argue angels-on-the-head-of-a-pin all year and get nowhere
586 2011-12-29 21:06:33 <copumpkin> I think all he's arguing is to delay it
587 2011-12-29 21:06:46 <copumpkin> so people who care about this kind of stuff can take a closer look
588 2011-12-29 21:06:55 <roconnor> gavinandresen: I don't know if there is a problem in practice or not; nobody knows.
589 2011-12-29 21:07:03 <ByteCoin2> IN PRACTICE, there seems no reason not to believe that OP_EVAL is ok
590 2011-12-29 21:07:07 <gmaxwell> ByteCoin2: as to why you'd compile to x86 you'd do so in order to evaluate frequently seen scripts faster. (though, why this matters I dunno, because even moron-slow evaluation will be fast compared to signature checking)
591 2011-12-29 21:07:27 <gmaxwell> ByteCoin2: the in practice objection is that the software is not sufficiently mature.
592 2011-12-29 21:07:35 <ByteCoin2> This would have been much more interesting had it all happened 4 months ago!
593 2011-12-29 21:07:35 <gavinandresen> roconnor: nobody has proven that the existing Script has no problems, either, and yet we use it.
594 2011-12-29 21:07:41 <gmaxwell> ByteCoin2: and rconner proved that by just finding a _severe_ bug in gavin's code a few days ago.
595 2011-12-29 21:08:01 <ByteCoin2> There have been other more severe bugs like int64 wrapping
596 2011-12-29 21:08:16 <gavinandresen> ... or the OP_RETURN bug...
597 2011-12-29 21:08:20 <ByteCoin2> I don't think the project should get too ossified at this stage
598 2011-12-29 21:08:20 <sipa> at a time when the bitcoin economy wasn't worth millions
599 2011-12-29 21:08:33 <ByteCoin2> Paper millions
600 2011-12-29 21:08:33 <copumpkin> well, let's put this differently
601 2011-12-29 21:08:37 <copumpkin> what are the downsides to delaying it?
602 2011-12-29 21:08:48 <gmaxwell> For all those millions you'd think that someone might actually fund some more of this validation work&
603 2011-12-29 21:08:53 <ByteCoin2> Precisely
604 2011-12-29 21:08:55 <copumpkin> gmaxwell: pfft
605 2011-12-29 21:08:57 <sipa> gmaxwell: yeah...
606 2011-12-29 21:09:08 <roconnor> gavinandresen: well that's why I was arguing we should understand the existing scripting system first.
607 2011-12-29 21:09:23 <ByteCoin2> We can delay the client implementation until the bugs are ironed out completely
608 2011-12-29 21:09:32 <copumpkin> ByteCoin2: nobody's even arguing that
609 2011-12-29 21:09:41 <ByteCoin2> Let's get it into the rest of the network
610 2011-12-29 21:09:43 <copumpkin> that's just misrepresenting your opponent's position :P
611 2011-12-29 21:09:52 <ByteCoin2> It'll take ages for non-supporting clients to die out
612 2011-12-29 21:10:05 <copumpkin> I just don't see what the rush is
613 2011-12-29 21:10:26 <ByteCoin2> By that reasoning there's no problem slipping any deadline forever
614 2011-12-29 21:10:44 <ByteCoin2> The thing is. There was a deadline. It was well known. We should meet it.
615 2011-12-29 21:10:47 <gmaxwell> copumpkin: presuming that the installed base of bitcoin grows, every day delay translates into more than a day of real delay on average.
616 2011-12-29 21:11:03 <copumpkin> ByteCoin2: a deadline people in this room set
617 2011-12-29 21:11:07 <copumpkin> who's it benefitting?
618 2011-12-29 21:11:13 <gmaxwell> copumpkin: there aren't any other people to set one!
619 2011-12-29 21:11:18 <ByteCoin2> We have a process.
620 2011-12-29 21:11:20 <copumpkin> and there's nobody else who cares
621 2011-12-29 21:11:24 <ByteCoin2> We should stick to it
622 2011-12-29 21:11:26 <copumpkin> why?
623 2011-12-29 21:11:43 <gavinandresen> Consistency builds trust
624 2011-12-29 21:11:45 <gmaxwell> Gah, there are already frequent delays about the development process being ossified. Where are you arguing against this when they come up?
625 2011-12-29 21:11:59 <ByteCoin2> I believe that having a process and sticking to it will be better in the long run for the project than chopping and changing
626 2011-12-29 21:12:01 <copumpkin> gavinandresen: trust that you'll rush to honor deadlines despite significant objections?
627 2011-12-29 21:12:39 <gmaxwell> copumpkin: be fair, 12th hour objections without concretely articulated pratical implications.
628 2011-12-29 21:12:49 <gavinandresen> copumpkin: I'll ask again:  Are there any PRACTICAL, not theoretical "if we don't have any limits" problems with the OP_EVAL proposal?
629 2011-12-29 21:13:08 <ByteCoin2> gmaxwell. You express my thoughts much better than I do - again!
630 2011-12-29 21:13:16 <roconnor> gmaxwell: what I said would happen is happening:  I find a bug, they fix the bug, and they presume there are no more bugs.
631 2011-12-29 21:13:22 <ByteCoin2> Not at all
632 2011-12-29 21:13:28 <ByteCoin2> This is why we need testing
633 2011-12-29 21:13:34 <gmaxwell> Well, I'm kinda arguing both sides here, because I'm completely sympathetic to both perspecties.
634 2011-12-29 21:13:39 <copumpkin> ByteCoin2: testing finds bugs in implementation, not in design
635 2011-12-29 21:13:39 <gmaxwell> er perspecitives.
636 2011-12-29 21:13:57 <ByteCoin2> copumpkin; Can't it find both?
637 2011-12-29 21:13:58 <slush> I have stupid question. How can I validate ecdsa-signed data when I have only bitcoin address (which is hash of pubkey)...?
638 2011-12-29 21:14:11 <sipa> slush: you can't
639 2011-12-29 21:14:12 <roconnor> slush: you cannot
640 2011-12-29 21:14:16 <copumpkin> gavinandresen: it's hard to say :) you give people a programming language, they can do fancy things with it. We haven't thought of exploits, but neither to writers of other exploitable software
641 2011-12-29 21:14:19 <gmaxwell> roconnor: I said before when you weren't in the room, I think, that you're discounting the fact that the process works because you're failing to recognize that you're part of the process.
642 2011-12-29 21:14:29 <gmaxwell> (I've seen many wikipedians flame out for that very reason)
643 2011-12-29 21:14:57 <gavinandresen> roconnor: bugs are a fact of life.  And I take offense to your prior suggestions that I'm not proactive about security concerns, I've made several changes that are proactive (DoS detection/prevention, etc)
644 2011-12-29 21:15:00 <roconnor> gmaxwell: ya I understand that;  Everytime I see an error I get mad at wikipedia, fix it, and realize that it does work!
645 2011-12-29 21:15:10 <roconnor> but this is a bit different IMHO
646 2011-12-29 21:15:29 <roconnor> any bugs in the Protocol more or less become perminent
647 2011-12-29 21:15:43 <copumpkin> anyway, it seems that roconnor is arguing that _we don't fully understand_ what we're creating with OP_EVAL, and wants to understand it better. And the response is "what can you break with OP_EVAL?", which he obviously won't be able to asnwer
648 2011-12-29 21:15:43 <roconnor> like timejacking and that extra pop in CHECKMULTISIG
649 2011-12-29 21:15:51 <copumpkin> but it isn't an actual counter-argument to roconnor's point
650 2011-12-29 21:16:03 <ByteCoin2> Look. These objections have been happening very quickly on IRC and the mailing list. There's no real substance behind the Fear Uncertainty and Doubt
651 2011-12-29 21:16:18 <ByteCoin2> How about we stick to the plan until something more concrete comes up
652 2011-12-29 21:16:20 <gmaxwell> gavinandresen: so say we find a bug in OP_EVAL. Like the limit not being right. How do we fix it without creating a severe forking risk?
653 2011-12-29 21:16:21 <ByteCoin2> ?
654 2011-12-29 21:16:37 <copumpkin> "you give people a programming language, they can do fancy things with it. We haven't thought of exploits, but neither to writers of other exploitable software"
655 2011-12-29 21:16:45 <copumpkin> "oconnor is arguing that _we don't fully understand_ what we're creating with OP_EVAL, and wants to understand it better"
656 2011-12-29 21:16:56 <copumpkin> "how about we stick to the plan until something more concrete comes up"
657 2011-12-29 21:16:59 <copumpkin> cross-purposes
658 2011-12-29 21:17:20 <ByteCoin2> copumpkin: I'm very sympathetic to that point of view. But let's not throw OP_EVAL out for no concrete reason
659 2011-12-29 21:17:28 <copumpkin> he's not suggesting throwing it out
660 2011-12-29 21:17:29 <gmaxwell> copumpkin: I think you're overstating that. We _do_ understant a lot, e.g. we _know_ (minus implementation bugs) that OP_EVAL doesn't allow e.g. bitcoin to convert the earth into grey goo.
661 2011-12-29 21:17:38 <copumpkin> he just wants to think about it more :P
662 2011-12-29 21:17:43 <copumpkin> gmaxwell: hah, okay, yep :)
663 2011-12-29 21:17:47 <gavinandresen> gmaxwell: limit too high or limit too low?   Actually, it doesn't matter:  to fix it without a forking risk, you convince 50+% of miners it is a problem and get them to 'discourage' blocks that break your desired new rules.
664 2011-12-29 21:18:29 <gmaxwell> copumpkin: I think you're arguing for a delay more than roconnor is?
665 2011-12-29 21:18:32 <gavinandresen> gmaxwell: .... or you hijack another NOP opcode to extend again....
666 2011-12-29 21:18:40 <copumpkin> gmaxwell: could be :)
667 2011-12-29 21:18:47 <copumpkin> anyway, I'm bowing out of this discussion. Poke me if you want PL nerd trivia
668 2011-12-29 21:18:50 <gmaxwell> (I mean rconner wants a delay too, but OP_EVAL is dead to him as is)
669 2011-12-29 21:18:50 <roconnor> ByteCoin2: gmaxwell thinks that the OP_EVAL propsoal has no infinite loops.  But he has no proof; no one does.
670 2011-12-29 21:18:59 <helo> is there any limit to the delay required to prove there are no possible problems with OP_EVAL?
671 2011-12-29 21:19:07 <roconnor> ByteCoin2: I also think OP_EVAL has no loops, but I'm not 100% sure.
672 2011-12-29 21:19:36 <lianj> roconnor: maybe writing some creative tests?
673 2011-12-29 21:19:46 <gmaxwell> gavinandresen: 'hijack another NOP opcode' doesn't remove the fork risk. But your first response is okay. I guess.
674 2011-12-29 21:19:52 <roconnor> But I do know the current scripting code has no loops because 1 instruction is consumed every instruction until none are left
675 2011-12-29 21:19:55 <ByteCoin2> It obviously doesnt have infinite loops because of the recursion limit
676 2011-12-29 21:20:11 <roconnor> lianj: tests cannot prove the absance of bugs
677 2011-12-29 21:20:27 <lianj> so better write none?
678 2011-12-29 21:20:35 <roconnor> lianj: better is to write a proof
679 2011-12-29 21:20:50 <lianj> in form of tests
680 2011-12-29 21:20:51 <roconnor> I write formal computer checked proofs, but paper proofs are quite effective.
681 2011-12-29 21:21:01 <sipa> roconnor: how would you feel about using the current OP_EVAL idea, but limit it to a) not touch the outer script's evaluation state at all b) failure inside means failure outside c) inner scripts are executed completely indepently, only inheriting the outer's main stack d) we trust recursion, cpu and memory limits to prevent turing completeness
682 2011-12-29 21:21:45 <sipa> if your concern is OP_EVAL being not well understood and specified enough, i believe this is a step in the right direction
683 2011-12-29 21:21:52 <roconnor> sipa: There are two major things I don't like about OP_EVAL: running dynamically generated code, and pseduo-turing completeness.
684 2011-12-29 21:22:10 <gmaxwell> ByteCoin2: thats why roconnor is saying I believe that. But it isn't a proof. E.g. if the inner script could modify the stack (in some way we're missing because we're forgetting about some crazy opcode) then this might not be true. I really doubt it, but thats what roconnor means by it's not proven.
685 2011-12-29 21:22:17 <roconnor> sipa: moreover, OP_EVAL isn't well tested and not well specified at the momement IMHO
686 2011-12-29 21:22:43 <roconnor> sipa: even if I liked the propsoal
687 2011-12-29 21:23:40 <roconnor> and, possibly like TD, I don't see the big deal about send-to-script.  Just send the script and be done with it.  I don't think "all the investment in short addresses" is that big of a deal.
688 2011-12-29 21:25:08 <gavinandresen> roconnor: small scriptPubKeys have other advantages (redeemer pays the transaction-size cost, and scriptSigs can easily be pruned if storage is a problem)
689 2011-12-29 21:25:35 <gmaxwell> In any case, I think the attitude of treating this as a really serious matter that must be _carefully_ handled is a good one. We're a long way from writing software meeting e.g. FAA guidelines for life-critical software, but thats the direction bitcoin development should generally be moving in, at least for the blockchain validation parts of the code.
690 2011-12-29 21:25:54 <sipa> I do like send-to-script, and though i'm very much in favor of moving towards URI's, QR codes, NFC, payment negociation protocols, and payment description files, i believe short addresses will be here for a while now
691 2011-12-29 21:26:05 <gmaxwell> roconnor: if gavinandresen wasn't clear enough that: space in input scripts in, at least in theory, much cheaper than space in output scripts.
692 2011-12-29 21:26:23 <gmaxwell> s/scripts in/scripts is/
693 2011-12-29 21:26:54 <roconnor> gavinandresen: ya, I still don't think it is a big deal, but I'm not opposed to the idea either.  I did write a proposal after all ;)
694 2011-12-29 21:27:15 <gmaxwell> (because an input script can always be pruned once you have one, where as output scripts may never be prunable)
695 2011-12-29 21:27:34 <roconnor> gmaxwell: someone has to keep the input script around
696 2011-12-29 21:27:42 <sipa> gmaxwell: not immediately either, but relatively soon afterwards
697 2011-12-29 21:27:48 <sipa> and not everyone either, indeed
698 2011-12-29 21:28:00 <roconnor> true
699 2011-12-29 21:28:08 <sipa> but it is true that marginally speaking for the network, inputs are cheaper than outputs
700 2011-12-29 21:32:14 <gmaxwell> roconnor: well, if in the future nodes don't do start from stratch validation then no one needs them. E.g. the bitcoin community could publish a hash of open txn as of block 100k in every publication medium available. And then 5 years later people could just start new nodes pruned up to that height trusting that if the published values were wrong someone would have noticed in 5 years, or whatever.
701 2011-12-29 21:32:25 <gmaxwell> Then it could be everyone, eventually.
702 2011-12-29 21:32:37 <gmaxwell> though I don't think it matters because archival space is cheap enough.
703 2011-12-29 21:32:48 <ByteCoin2> Sorry I was AFK. sipa: Isn't that overkill^4?
704 2011-12-29 21:33:07 <sipa> ByteCoin2: what, precisely?
705 2011-12-29 21:33:12 <ByteCoin2> Ooops. Responding with lag
706 2011-12-29 21:33:27 <gmaxwell> Though I do think we want to make it as easy as possible to run full nodes for as long as possible. Otherwise we'll end up where the chain is 1 PB and only a dozen big banks hae copied of it.
707 2011-12-29 21:34:15 <gmaxwell> (wow, I fail to type with great justice)
708 2011-12-29 21:34:40 <ByteCoin2> Ok. How about this: There are some concerns to address but we don't need to run around with our heads on fire thinking that the sky is falling. Eh roconnor?
709 2011-12-29 21:34:44 <sipa> roconnor: now, when it only comes to the protocol, and not its implementation; is the ability to run dynamically generated code or pseudo-turingcompleteness (combined with a recursion, operation count and stack size limits) an actual problem to the network, according to you?
710 2011-12-29 21:35:34 <roconnor> ByteCoin2: well after Jan 15th it will basically be too late.
711 2011-12-29 21:36:08 <ByteCoin2> Why's that?
712 2011-12-29 21:36:14 <Diablo-D3> gmaxwell: have you said anything in that thread yet?
713 2011-12-29 21:36:37 <roconnor> ByteCoin2: because OP_EVAL will be deployed in whatever state it is in and changing any design errors will be difficult.
714 2011-12-29 21:36:39 <ByteCoin2> The client can't generate OP_EVAL trannsactions
715 2011-12-29 21:36:56 <roconnor> ByteCoin2: but the clients will accept OP_EVAL transactions on Feb 1
716 2011-12-29 21:37:01 <roconnor> maybe Feb 1 is the last last day
717 2011-12-29 21:37:24 <ByteCoin2> So if someone generates OP_EVAL transactions and there's a bug then what's the worst plausible case?
718 2011-12-29 21:37:52 <roconnor> ByteCoin2: all miners get stuck in an infinite loop bringing down the entire network
719 2011-12-29 21:37:59 <roconnor> scrabling to fix things fork the block chain
720 2011-12-29 21:38:13 <roconnor> something like that I guess
721 2011-12-29 21:38:20 <ByteCoin2> Mechanism for infinite loop using OP_EVAL is what?
722 2011-12-29 21:38:22 <roconnor> maybe there are worse cases
723 2011-12-29 21:38:31 <roconnor> ByteCoin2: I don't know for goddness sake!
724 2011-12-29 21:38:36 <roconnor> ByteCoin2: neither do you
725 2011-12-29 21:38:53 <ByteCoin2> Well whenever the miners roll out a new version it's possible that what you say can happen
726 2011-12-29 21:39:03 <ByteCoin2> You can't rule that out either
727 2011-12-29 21:39:26 <ByteCoin2> We have to MANAGE the risk not avoid it
728 2011-12-29 21:40:22 <roconnor> well, we can say this is a lot riskier than anything else that has been rolled out recently and the stakes are higher than ever before.
729 2011-12-29 21:40:44 <ByteCoin2> all  the more reason to examine the code closely and to test it thoroughly
730 2011-12-29 21:40:51 <ByteCoin2> Before the set deadline!
731 2011-12-29 21:41:01 <sipa> Still, roconnor's opinions have convinced me that there are several possible (some minor, some major) improvements that could have been made to OP_EVAL
732 2011-12-29 21:41:04 <ByteCoin2> Why is it you haven't looked at this months ago?
733 2011-12-29 21:41:04 <roconnor> I'm done looking myself.
734 2011-12-29 21:41:16 <roconnor> ByteCoin2: it wasn't christmas vacation 2 months ago
735 2011-12-29 21:41:30 <roconnor> ByteCoin2: I didn't think anyone was taking OP_EVAL seriously
736 2011-12-29 21:41:40 <roconnor> since it is such a terrible idea :P
737 2011-12-29 21:41:45 <roconnor> (cognative bias)
738 2011-12-29 21:41:47 <ByteCoin2> We can't plan development around when people might be most inclined to spend some time looking at things
739 2011-12-29 21:42:02 <roconnor> ByteCoin2: why didn't you look at it 2 months ago and find my bugs?
740 2011-12-29 21:42:07 <ByteCoin2> roconnor: Wow you really ddn't pay attention!
741 2011-12-29 21:42:15 <roconnor> no I didn't
742 2011-12-29 21:42:49 <ByteCoin2> I don't appreciate you threatening Gavin with going "to the blogosphere" to force his hand
743 2011-12-29 21:43:16 <roconnor> what is the point of a voting without a public debate?
744 2011-12-29 21:43:29 <ByteCoin2> There was a public debate on the forum
745 2011-12-29 21:43:46 <roconnor> great
746 2011-12-29 21:43:49 <ByteCoin2> I am kicking myself about that bug. I did see it and go "that's wierd"
747 2011-12-29 21:44:03 <ByteCoin2> What's so bad about the forum?
748 2011-12-29 21:44:05 <gavinandresen> The ++ bug?
749 2011-12-29 21:44:09 <ByteCoin2> yes
750 2011-12-29 21:44:29 <gavinandresen> I'm kicking myself about that one, too.......
751 2011-12-29 21:44:41 <roconnor> ByteCoin2: would it make you feel better if I campaigned on the form instead of my blog?
752 2011-12-29 21:44:43 <roconnor> *forum
753 2011-12-29 21:45:09 <ByteCoin2> If there was a surfeit of programming effort than I would feel comfortable criticising people's efforts
754 2011-12-29 21:45:33 <roconnor> ByteCoin2: have you seen my reimpelemenation of the bitcoin core protocol?
755 2011-12-29 21:45:36 <ByteCoin2> As it is, if people get discouraged the project tanks more surely than if we have a major network hiccough
756 2011-12-29 21:46:24 <ByteCoin2> roconnor: I'll read your stuff but I didn't find what I read very clear. If you spell out how the stack evolves and what each entry is it'll be clearer
757 2011-12-29 21:46:48 <ByteCoin2> roconnor: On the forum is MUCH better imo
758 2011-12-29 21:46:56 <sipa> Really?
759 2011-12-29 21:47:00 <ByteCoin2> Let's not be snobbish about it
760 2011-12-29 21:47:12 <ByteCoin2> Is it really that difficult to read?
761 2011-12-29 21:47:32 <ByteCoin2> I know that there's lots of rubbish you need to skip over
762 2011-12-29 21:47:48 <ByteCoin2> But I believe we can pick up the tone by leading by example
763 2011-12-29 21:48:02 <ByteCoin2> Did you ever get involved with adult conversations as a child?
764 2011-12-29 21:48:07 <gavinandresen> I'm liking sipa's latest proposal; if the EVAL'd script cannot affect the enclosing script's state (beyond making validation fail), then it seems clear to me we understand it at least as well as we understand current Script, and the dangers are equivalent.
765 2011-12-29 21:48:43 <gavinandresen> That is, conceptually, a minor change to the current OP_EVAL proposal.
766 2011-12-29 21:49:16 <gmaxwell> ::shrugs:: I think the forum has improved from where it was a few months ago. My only real complain now is that there are a lot of time wasting WOULND'T IT BE GREAT IF SCRIPTS HAD PACMAN BUILT IN kinda posts, where the poster hasn't even put in 10 minutes of contemplation before hitting send.
767 2011-12-29 21:49:33 <gmaxwell> Diablo-D3: which thread? yours or the op-eval stuff?
768 2011-12-29 21:49:51 <gmaxwell> I haven't commented on the OP_EVAL stuff because I have nothing 'adult' to offer.
769 2011-12-29 21:50:20 <ByteCoin2> gavinandresen: I don't know what dangers that proposal would implicitly be addressing
770 2011-12-29 21:50:44 <sipa> ByteCoin2: I've sort of given up on the forum - I still read the dev section there to see what those not on the mailinglist think
771 2011-12-29 21:50:46 <gmaxwell> It's a serious matter, and I'm only commenting about it here because (I hope) that adding a bit more text is enhancing communication. The messages on the list have been pretty clear.
772 2011-12-29 21:51:17 <ByteCoin2> sipa: The dev section is the only thing I read for a few years
773 2011-12-29 21:51:25 <sipa> and indeed, it has improved over the past few months
774 2011-12-29 21:51:27 <gavinandresen> ByteCoin2: I'm trying to address roconnor / gmaxwell's  "what if OP_EVAL interacts in some subtle way we can't see..."
775 2011-12-29 21:51:43 <ByteCoin2> But I occasionally look at what gavin, theymos and a few others have been doing
776 2011-12-29 21:52:17 <sipa> I'm pretty confident that memory, instruction and recursion limits are enough to prevent the worst case scenario (I'm talking about the protocol now, not the implementation)
777 2011-12-29 21:52:33 <ByteCoin2> gavinandresen: When OP_EVAL is executed I think it should just spew a load of script on to the top of the stack
778 2011-12-29 21:52:42 <ByteCoin2> I don't see what's so complex about it
779 2011-12-29 21:53:03 <ByteCoin2> Just like is shown in the explanation I wrote
780 2011-12-29 21:54:04 <gmaxwell> Frankly, wrt implementation.. I don't think it should go live unless there is another implementation that it can be tested against. ... except that this position is undermined by the fact that its so much taller than the testing requirement we have for the system as a whole. :(  nor am I about to write one for this purpose.
781 2011-12-29 21:54:55 <ByteCoin2> Testing against another implementation: Sounds good but exactly how would that be done?
782 2011-12-29 21:55:08 <ByteCoin2> What things are tested for equality?
783 2011-12-29 21:55:20 <ByteCoin2> Testing is HARD
784 2011-12-29 21:55:36 <ByteCoin2> Sorry... EFFECTIVE testing is hard.
785 2011-12-29 21:55:53 <ByteCoin2> "Gives me a fuzzy warm feeling" testing is easy
786 2011-12-29 21:56:23 <gmaxwell> ByteCoin2: a mixture of prefab pass and fail scripts which get fuzzed with some instrumention (e.g. to bypass checksig). Both implementations should always produce the same result. This is not a certification, but it will find a great many bugs in practice.
787 2011-12-29 21:56:42 <sipa> gavinandresen: you're purely referring to the no-op-except-for-failure idea now, not either of the larger ones around it i've mailed about
788 2011-12-29 21:56:47 <gmaxwell> (bugs... and more importantly, ambiguities)
789 2011-12-29 21:57:37 <ByteCoin2> gmaxwell: Ok that'd work but it's quite a lot of work - especially as your testing harness would probably be complex enough to require testing!
790 2011-12-29 21:58:13 <ByteCoin2> To test the test harness you'd have to have an alternative implementation with some bugs built in!
791 2011-12-29 21:58:39 <ByteCoin2> The test harness passes if it detects the known buggy bitcoin implementation
792 2011-12-29 21:58:41 <gmaxwell> ByteCoin2: its true, though if the test harness finds false bugs you will find them.. and if it fails to find bugs you can get substantial testing just by manually introducing some. This isn't at all unprecedented.
793 2011-12-29 21:59:36 <gmaxwell> (this is the same techniques I use for codec development, with substantially greater complexity than the scripts). The tests could also compare logs of the stacks, which should be absolutely identical in all implementations.
794 2011-12-29 22:00:11 <ByteCoin2> gmaxwell: I'm glad its not unprecendented and indeed if this was a commercial project than it's quite practical. The problem is that we have a "multimillion dollar" system operating with very little engineering resources
795 2011-12-29 22:01:06 <ByteCoin2> You clearly "get" it but can it really be made to happen?
796 2011-12-29 22:01:10 <gmaxwell> If I didn't have too many other commitments right now, and if I had a second implementation to test against, I'd do it.
797 2011-12-29 22:01:46 <sipa> there is roconnor's script implementation...
798 2011-12-29 22:02:06 <ByteCoin2> This is why I'm trying to get roconnor to "play nicely" with the devs
799 2011-12-29 22:02:07 <helo> if only there were some people with massive bitcoin stockpiles that could put some bounties up...
800 2011-12-29 22:02:08 <gmaxwell> I've never actually seen roconnor's work. Is it up someplace?
801 2011-12-29 22:02:17 <gmaxwell> helo: money wouldn't help.
802 2011-12-29 22:03:09 <ByteCoin2> gmaxwell: I think it WOULD help but it's not going to happen so it's not worth talking about
803 2011-12-29 22:03:41 <gmaxwell> I mean, the only way you're going to buy my time with money is if you can put up enough to pay my income now for several years (because I'm sure as hell not going to disrupt my current activities for something short term). Which isn't a reasonable or realistic thing to do. And I expect the same is true for other people.
804 2011-12-29 22:04:03 <ByteCoin2> Ok. Precisely, it would have to be a large sum distributed appropriately
805 2011-12-29 22:04:27 <ByteCoin2> Why do you think my involvement is limited to kibbitzing from the side
806 2011-12-29 22:04:56 <copumpkin> for what it's worth, my experience with development teams splitting money was pretty bad, and in the end we decided to just refuse donations outright
807 2011-12-29 22:04:59 <ByteCoin2> I think we already waste too much time on something that won't pay our bills!
808 2011-12-29 22:05:31 <ByteCoin2> copumpkin: That makes sense. It's a shame really
809 2011-12-29 22:05:42 <gavinandresen> ByteCoin2: my wife thinks that, too....
810 2011-12-29 22:05:42 <gmaxwell> In my case, I _do_ have free time, but I'm getting near the end of the finalization of a _5 year_ development project, with all sorts of end game political and technical complications. So basically bitcoin just gets my attention when I'm fed up with productive work. ::shrugs::
811 2011-12-29 22:05:56 <helo> presumably some people have time to do software development for free. so for even a small amount of money i would expect there would be some takers