1 2011-12-29 00:03:24 BlueMatt has quit (Quit: Ex-Chat)
   2 2011-12-29 00:03:51 sacredchao has joined
   3 2011-12-29 00:03:54 marf_away has quit (Ping timeout: 252 seconds)
   4 2011-12-29 00:06:07 theorb has joined
   5 2011-12-29 00:06:26 theorbtwo has quit (Ping timeout: 240 seconds)
   6 2011-12-29 00:13:09 <roconnor> luke-jr: okay, building on your idea, (or exactly your idea) add a new operator OP_CODEVERIFY that verifies that the hash of the signature script from the last (executed?) OP_CODESEPARATOR to the end of the signature script is equal to the hash on the top of the stack.
   7 2011-12-29 00:13:31 <roconnor> so the standard tranaction becomes:
   8 2011-12-29 00:13:56 <roconnor> {20-byte-hash-value} OP_CODEVERIFY
   9 2011-12-29 00:14:04 <roconnor> and it is redeemed by
  10 2011-12-29 00:14:24 <roconnor> ...signatures... OP_CODESEPARATOR script
  11 2011-12-29 00:15:04 <sipa> that's... nice actually
  12 2011-12-29 00:15:18 <luke-jr> roconnor: yeah, I was trying to avoid that, but it might be the only thing to work :/
  13 2011-12-29 00:16:01 <roconnor> sipa: there is a little issue about how OP_IF interacts with OP_CODESEPARATOR, but I think it workable
  14 2011-12-29 00:16:32 TD has quit (Quit: TD)
  15 2011-12-29 00:16:38 <roconnor> I'm not entirely happy with this yet, but it is way better than OP_EVAL IMHO
  16 2011-12-29 00:16:44 <roconnor> even as it stands
  17 2011-12-29 00:17:20 <gavinandresen> How does OP_CODEVERIFY work?  what is it hashing exactly?
  18 2011-12-29 00:17:48 <roconnor> well there are somepossible variations
  19 2011-12-29 00:18:01 <sipa> roconnor: i don't like the fact that it needs to ignore itself + the previous push
  20 2011-12-29 00:18:11 [Tycho] has quit (Remote host closed the connection)
  21 2011-12-29 00:18:56 <gavinandresen> It also loses some security for old clients that interepret CODEVERIFY as a NO-OP
  22 2011-12-29 00:19:02 <roconnor> but the simplest would be to serialize the signature script from the last OP_CODESEPARATOR in the signature script to the end of the signature script (or the whole signature script if there is not OP_CODESEPARATOR)
  23 2011-12-29 00:19:07 <roconnor> then hash160 that
  24 2011-12-29 00:19:38 <roconnor> gavinandresen: I don't think it loses more security than the current OP_EVAL proposal
  25 2011-12-29 00:20:32 <gavinandresen> roconnor: sure it does, if you use a new public key for your op-eval transaction then even old clients can't create a valid hash, and the hash IS checked by old clients/miners using DUP .. HASH160 EQUALVERIFY.....
  26 2011-12-29 00:20:42 <gavinandresen> roconnor: CODEVERIFY could be modified to have the same property
  27 2011-12-29 00:20:58 <gavinandresen> ... wait, no it couldn't....
  28 2011-12-29 00:21:26 <roconnor> I'm not following
  29 2011-12-29 00:21:56 <gavinandresen> roconnor: You send bitcoins to me, with scriptPubKey   DUP HASH160 <hash> EQUALVERIFY EVAL
  30 2011-12-29 00:22:18 <gavinandresen> I am the only person who knows the script that hashes to <hash>, so only I can generate the scriptSig.
  31 2011-12-29 00:22:38 <roconnor> oh I see
  32 2011-12-29 00:22:45 <gavinandresen> That is true even if you interepret EVAL as a no-op....
  33 2011-12-29 00:23:22 <sipa> i'm not following
  34 2011-12-29 00:23:26 <sipa> what is the problem?
  35 2011-12-29 00:23:54 <gavinandresen> <hash> OP_CODEVERIFY will be interepreted as  <hash> NO-OP to old clients....
  36 2011-12-29 00:23:56 <roconnor> sipa: with my propsoal anyone can redeem my transaction with an old client
  37 2011-12-29 00:24:01 <sipa> right
  38 2011-12-29 00:24:03 <sipa> of course
  39 2011-12-29 00:24:29 <roconnor> with the current OP_EVAL prosoal only someone who knows there inverse of the pushed hash can redeem with the old client
  40 2011-12-29 00:24:58 <roconnor> I mean we can retrofit this onto my proposal by making the scripts a bit longer
  41 2011-12-29 00:25:23 <sipa> make it OP_CODEHASH
  42 2011-12-29 00:25:37 <roconnor> actually it it would make addresses twice as long
  43 2011-12-29 00:25:39 <roconnor> hmm
  44 2011-12-29 00:26:03 <roconnor> sipa: naive OP_CODEHASH isn't backwards compatiable with NOP
  45 2011-12-29 00:26:16 <sipa> right
  46 2011-12-29 00:26:17 <sipa> bah
  47 2011-12-29 00:26:20 <roconnor> still, I think there is something to my idea
  48 2011-12-29 00:26:23 <roconnor> needs more work
  49 2011-12-29 00:26:31 <sipa> OP_EVAL is a pretty nice find
  50 2011-12-29 00:26:33 <roconnor> it is close
  51 2011-12-29 00:27:10 <gavinandresen> roconnor: thank you very much for looking closely at all this, by the way.
  52 2011-12-29 00:27:10 <roconnor> at least I satified Gavin's first criteria: send-to-script
  53 2011-12-29 00:27:34 <roconnor> gavinandresen: you and I both just want what is best for bitcoin
  54 2011-12-29 00:27:54 MimeNarrator has quit (Remote host closed the connection)
  55 2011-12-29 00:27:56 <gavinandresen> roconnor: yup.  We may disagree on the most ideal way to get there.....
  56 2011-12-29 00:28:35 <roconnor> sipa: other than backwards compatibility I like the OP_CODEHASH
  57 2011-12-29 00:28:51 <gavinandresen> Losing the "eval scripts still safe for old clients" might be worth sacrificing if another solution is really much simpler/safer/better
  58 2011-12-29 00:29:20 <roconnor> gavinandresen: there is probably a way to get your second criteria too
  59 2011-12-29 00:29:23 <gavinandresen> ... but a change that would require a hard blockchain split won't fly
  60 2011-12-29 00:29:46 <roconnor> I'll think about it more
  61 2011-12-29 00:30:00 wasabi has joined
  62 2011-12-29 00:30:31 <gavinandresen> roconnor: Have you seen sipa's proposal for a revamped Script?  Long term, I still think something like that is the right answer, wrapped in an OP_EVAL2 so it is compatible with old clients.
  63 2011-12-29 00:31:03 <roconnor> gavinandresen: Probably, but you should link to it anyways
  64 2011-12-29 00:31:15 <gavinandresen> ... but we probably don't want to do that until we have another good reason to upgrade scripts, like a quantum-resistant signature algorithm or SHA3
  65 2011-12-29 00:31:55 <sipa> https://gist.github.com/1262449
  66 2011-12-29 00:33:03 wasabi2 has quit (Ping timeout: 240 seconds)
  67 2011-12-29 00:34:36 <gavinandresen> roconnor: That's another reason I like OP_EVAL:  it gives us a way of designing a completely new and different (and better) system in a completely backwards compatible way.
  68 2011-12-29 00:35:45 <gavinandresen> I suppose I should say "it shows a way of ...."
  69 2011-12-29 00:36:12 <gavinandresen> We could come up with a different solution now and still do an op-eval-type solution later....
  70 2011-12-29 00:37:28 <roconnor> I pretty adamantly opposed to anything that allows arithmetic to determine the code to execute
  71 2011-12-29 00:40:15 <sipa> technically, no such arithmetic is possible now
  72 2011-12-29 00:40:22 <gavinandresen> roconnor: agreed.  We could add more band-aids to the OP_EVAL rules to prevent it...  (require the EVAL'd item to be more than 4 bytes big should do it, since arithmetic for larger values is illegal right now)
  73 2011-12-29 00:40:43 <roconnor> I disagree when BIP_12 claims that "That same argument can be applied to the existing Bitcoin 'scripting' system"
  74 2011-12-29 00:41:58 sacredchao has quit (Remote host closed the connection)
  75 2011-12-29 00:42:04 <gavinandresen> I've argued in the past that general Scripts are a bad idea, so the same argument can definitely be applied.
  76 2011-12-29 00:42:29 dissipate has quit (Ping timeout: 255 seconds)
  77 2011-12-29 00:42:32 <roconnor> sure that argument can be applied
  78 2011-12-29 00:42:49 sacredchao has joined
  79 2011-12-29 00:42:53 <roconnor> but OP_EVAL is evaluating data as code in a much different way
  80 2011-12-29 00:44:32 <gavinandresen> How is it any different from an implementation getting data off the wire and then evaluating it?
  81 2011-12-29 00:44:40 <roconnor> which is essentially the crux of my static-analysis argument
  82 2011-12-29 00:45:24 b4epoche_ has joined
  83 2011-12-29 00:46:32 b4epoche has quit (Ping timeout: 255 seconds)
  84 2011-12-29 00:46:32 b4epoche_ is now known as b4epoche
  85 2011-12-29 00:47:30 <gavinandresen> W
  86 2011-12-29 00:47:30 <gavinandresen> '
  87 2011-12-29 00:48:23 <gavinandresen> We'll start going around in circles... the limits on recursion and opcode execution count keeps bad things from happening, with or without OP_EVAL
  88 2011-12-29 00:48:40 <sipa> gavinandresen: the difference, according to roconnor, is that scripts can modify the code being executed themselves, essentially making it impossible to analyse the code being executed in advance
  89 2011-12-29 00:49:06 <gavinandresen> sipa:  ... and I'd be more sympathetic to that concern if scripts had long execution times.
  90 2011-12-29 00:49:29 graingert has left ()
  91 2011-12-29 00:50:07 <gavinandresen> sipa:  but it is pretty trivial to either do a 'dry-run' of a script, counting up all the signature checks, or just pass in a "don't do more than THIS number of ECDSA signature checks"
  92 2011-12-29 00:50:45 <gavinandresen> And ECDSA signature checking is what you'll spend all your time doing in Scripts, by about a factor of a million
  93 2011-12-29 00:51:29 <sipa> agree - i like the idea of static checking very much, but in practice i'm not sure how much it helps
  94 2011-12-29 00:53:55 iocor has quit (Quit: Computer has gone to sleep.)
  95 2011-12-29 00:55:12 dissipate has joined
  96 2011-12-29 01:03:15 erus` has quit (Remote host closed the connection)
  97 2011-12-29 01:06:41 MimeNarrator has joined
  98 2011-12-29 01:12:24 Lisk has joined
  99 2011-12-29 01:12:44 Lisk has quit (Client Quit)
 100 2011-12-29 01:13:13 P3nt0 has joined
 101 2011-12-29 01:13:20 <P3nt0> Right
 102 2011-12-29 01:13:40 <P3nt0> Any Avo members present?
 103 2011-12-29 01:13:44 <cjdelisle> Wrong
 104 2011-12-29 01:13:52 <sipa> What is Avo?
 105 2011-12-29 01:13:58 <P3nt0> somme faggot group of kids
 106 2011-12-29 01:14:23 <cjdelisle> how can I join?
 107 2011-12-29 01:14:38 <P3nt0> suck on your moms tits
 108 2011-12-29 01:14:43 <P3nt0> instant membership
 109 2011-12-29 01:14:53 <sipa> please
 110 2011-12-29 01:15:07 <P3nt0> Now
 111 2011-12-29 01:15:10 <P3nt0> Anyone with Avo?
 112 2011-12-29 01:16:17 <cjdelisle> so umm what did this group do to you?
 113 2011-12-29 01:16:43 <P3nt0> ah its ok
 114 2011-12-29 01:16:45 <P3nt0> im in the right place
 115 2011-12-29 01:16:51 <P3nt0> i recognise the names that i recieved on email
 116 2011-12-29 01:16:52 <sipa> and what does it have to do with the development of bitcoin?
 117 2011-12-29 01:17:04 <rjk2> doesn't sound liek the right place
 118 2011-12-29 01:17:11 <P3nt0> earlier today i recieved an email from a group of friends regarding this Team Avo
 119 2011-12-29 01:17:24 <P3nt0> nothing major, but still unwanted
 120 2011-12-29 01:17:29 da2ce7 has quit (Ping timeout: 276 seconds)
 121 2011-12-29 01:17:29 <P3nt0> Anything further
 122 2011-12-29 01:17:36 <P3nt0> Will result in individual attacks
 123 2011-12-29 01:17:51 <rjk2> random threats directed at no one?
 124 2011-12-29 01:17:54 <rjk2> interesting
 125 2011-12-29 01:18:03 <sipa> does this have anything to do with bitcoin?
 126 2011-12-29 01:18:26 <cjdelisle> hmm according to gribble it's something todo with minecraft - some troll org or something
 127 2011-12-29 01:18:28 <TuxBlackEdo> i think this guy is just waisting people's time in here tbh....
 128 2011-12-29 01:18:34 <P3nt0> depends if Avo is associated, prrobably not
 129 2011-12-29 01:18:42 <P3nt0> it is to do with mc
 130 2011-12-29 01:18:45 <P3nt0> like i said its nothing major
 131 2011-12-29 01:18:46 <P3nt0> but
 132 2011-12-29 01:18:53 <P3nt0> a few friends show discomfort to these nubs
 133 2011-12-29 01:19:07 <P3nt0> which we do not see kindly
 134 2011-12-29 01:19:47 <cjdelisle> yeap, that's kind of the point of troll organizations..
 135 2011-12-29 01:20:07 <P3nt0> well if they were smart
 136 2011-12-29 01:20:09 <P3nt0> with what they already know
 137 2011-12-29 01:20:24 <P3nt0> very slight adjustments
 138 2011-12-29 01:20:28 <P3nt0> could cause a lot of problems
 139 2011-12-29 01:20:30 <P3nt0> as they are
 140 2011-12-29 01:20:36 <P3nt0> they are nothing more than flys that are removed
 141 2011-12-29 01:20:40 <rjk2> wtf is all this meta shit
 142 2011-12-29 01:20:42 <P3nt0> but with half a brain, causes issues
 143 2011-12-29 01:21:42 <gmaxwell> DNFTT
 144 2011-12-29 01:22:22 gavinandresen has quit (Quit: gavinandresen)
 145 2011-12-29 01:22:22 <P3nt0> anyway
 146 2011-12-29 01:22:37 <P3nt0> if Avo would like to be in contact please contact myself at P3nt0@cia.com
 147 2011-12-29 01:23:08 P3nt0 has quit ()
 148 2011-12-29 01:24:22 <sipa> ignored
 149 2011-12-29 01:25:03 <cjdelisle> I got a chuckle out of the outburst of randomness
 150 2011-12-29 01:25:49 <rjk2> veiled threats ftw
 151 2011-12-29 01:26:58 chrisb__ has quit (Remote host closed the connection)
 152 2011-12-29 01:33:10 btc_novice has quit (Ping timeout: 248 seconds)
 153 2011-12-29 01:35:23 dissipate has quit (Remote host closed the connection)
 154 2011-12-29 01:36:32 Turingi has quit (Read error: Connection reset by peer)
 155 2011-12-29 01:37:27 Clipse has quit (Ping timeout: 240 seconds)
 156 2011-12-29 01:52:02 TuxBlackEdo is now known as TuxBlackEdo_away
 157 2011-12-29 01:55:09 ageis has quit (Quit: http://ageispolis.net)
 158 2011-12-29 01:55:55 lfm has quit (Quit: bye)
 159 2011-12-29 01:57:30 ageis has joined
 160 2011-12-29 01:57:46 wiel has joined
 161 2011-12-29 01:57:54 <wiel> whats the name of a channel where they talk about encryption?
 162 2011-12-29 01:58:24 <rjk2> try being more specific
 163 2011-12-29 01:59:22 <wiel> Im trying to identify the encryption being used on a string
 164 2011-12-29 02:02:23 <lianj> rot13
 165 2011-12-29 02:02:38 <wiel> rjk2
 166 2011-12-29 02:02:58 eoss has quit (Remote host closed the connection)
 167 2011-12-29 02:04:43 Joric has joined
 168 2011-12-29 02:13:00 finway has joined
 169 2011-12-29 02:13:05 <finway> quote:  gmaxwell	sipa: (I don't share his concern because I believe there is ï¾µ people outside of this room who are interested in understanding these issues
 170 2011-12-29 02:13:12 <finway> Yes, i am the guy.
 171 2011-12-29 02:14:24 devrandom has quit (Remote host closed the connection)
 172 2011-12-29 02:17:20 storrgie has quit (Quit: Leaving)
 173 2011-12-29 02:17:22 <gmaxwell> but you're in the room
 174 2011-12-29 02:19:40 rasengan has joined
 175 2011-12-29 02:21:52 mcorlett has quit (Ping timeout: 244 seconds)
 176 2011-12-29 02:32:31 <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.
 177 2011-12-29 02:32:38 <finway> I can't code
 178 2011-12-29 02:33:32 h4ckm3 has joined
 179 2011-12-29 02:33:43 dr_win has joined
 180 2011-12-29 02:37:20 <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 {
 181 2011-12-29 02:37:21 <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.
 182 2011-12-29 02:37:33 mcorlett has joined
 183 2011-12-29 02:37:58 <roconnor> (note this hash that OP_CODESEPARATOR pushes is exactly the hash that is used in signature verification)
 184 2011-12-29 02:41:35 finway has quit (Ping timeout: 258 seconds)
 185 2011-12-29 02:42:22 wiel has quit (Quit: Page closed)
 186 2011-12-29 02:43:11 finway has joined
 187 2011-12-29 02:43:15 <finway> I think the difference between OP_CHECKMULTISIG and OP_EVAL,  is sender do not care , right ?
 188 2011-12-29 02:44:35 dr_win has quit (Remote host closed the connection)
 189 2011-12-29 02:48:35 conman has joined
 190 2011-12-29 02:50:47 <finway> Question: why nobody use OP_CHECKMULTISIG ?
 191 2011-12-29 02:50:58 Aexoden has quit (Remote host closed the connection)
 192 2011-12-29 02:52:03 Aexoden has joined
 193 2011-12-29 02:52:11 <luke-jr> roconnor: might work, but significantly less safe than OP_EVAL for migration
 194 2011-12-29 02:53:46 <luke-jr> and wouldn't it need to be "signatures {hash of the_code} OP_CODESEPARATOR the_code" ?
 195 2011-12-29 02:54:14 <luke-jr> and have OP_CODEHASH verify the top stack item is identical to the actual code hash..
 196 2011-12-29 02:54:50 <luke-jr> also, this paradigm slows down evaluation since every code block needs hashing :/
 197 2011-12-29 02:55:39 Fnar has quit (Ping timeout: 276 seconds)
 198 2011-12-29 02:55:52 Fnar has joined
 199 2011-12-29 02:57:00 minimoose has joined
 200 2011-12-29 02:58:10 <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
 201 2011-12-29 02:59:59 <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."
 202 2011-12-29 03:10:32 <roconnor> luke-jr: only need hashing if there is a OP_CODESEPARATOR
 203 2011-12-29 03:10:50 <luke-jr> roconnor: which there often is
 204 2011-12-29 03:11:11 <roconnor> and it is "{hash of the_code} signature" since the_code will pop off all the signatures
 205 2011-12-29 03:11:19 <roconnor> I don't see why it is less safe than OP_EVAL
 206 2011-12-29 03:11:35 <roconnor> it is slightly slower with one additional hashing operator
 207 2011-12-29 03:11:43 <roconnor> *operation
 208 2011-12-29 03:12:21 <roconnor> the consequences of this is less severe than OP_EVAL
 209 2011-12-29 03:14:11 <finway> It still contains CODE in DATA
 210 2011-12-29 03:14:51 <roconnor> no, it cotains hash-of-code in data
 211 2011-12-29 03:14:55 <roconnor> *contains
 212 2011-12-29 03:17:00 <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.
 213 2011-12-29 03:17:53 h4ckm3 has quit (Quit: Leaving)
 214 2011-12-29 03:18:47 finway has quit (Ping timeout: 258 seconds)
 215 2011-12-29 03:18:49 <luke-jr> roconnor: it's less safe, since redeeming OP_EVAL even without OP_EVAL support requires the txn know the right script
 216 2011-12-29 03:19:02 <luke-jr> roconnor: with OP_CODEHASH, you just need to know the hash of the right script… which is right there
 217 2011-12-29 03:19:44 <roconnor> the proposed transaction is : OP_CODEHASH HASH160 {20-byte-hash-value} EQUALVERIFY
 218 2011-12-29 03:20:03 <roconnor> in order to process this on a standard transcation you need to know the inverse of that 20-byte-hash-value
 219 2011-12-29 03:20:11 <roconnor> just like the existing OP_EVAL proposal
 220 2011-12-29 03:20:37 devrandom has joined
 221 2011-12-29 03:20:45 <roconnor> due to the presence of the HASH160 command
 222 2011-12-29 03:20:48 <roconnor> er
 223 2011-12-29 03:20:55 <roconnor> the proposed transaction is : OP_CODEHASH OP_HASH160 {20-byte-hash-value} EQUALVERIFY
 224 2011-12-29 03:21:00 <roconnor> sorry I forgot the OP_
 225 2011-12-29 03:21:34 <luke-jr> ah
 226 2011-12-29 03:21:46 <luke-jr> so {20-byte-hash-value} is SHA256(SHA256(code)) ?
 227 2011-12-29 03:21:53 <luke-jr> err
 228 2011-12-29 03:21:57 <roconnor> more or less
 229 2011-12-29 03:21:58 <luke-jr> HMAC(SHA256(code))
 230 2011-12-29 03:22:06 <roconnor> HASH160 isn't quite SHA256
 231 2011-12-29 03:22:14 <luke-jr> HASH160, that's it :P
 232 2011-12-29 03:23:07 <luke-jr> hmm, why not wait until OP_CODEHASH to hash the script?
 233 2011-12-29 03:23:27 <roconnor> well, in Haskell that is what will happen :P
 234 2011-12-29 03:23:57 <roconnor> so the implementor is welcome to delay perfoming the hash
 235 2011-12-29 03:23:57 <luke-jr> ie, when OP_CODEHASH is called, hash everything leading up to it since the last OP_CODESEP
 236 2011-12-29 03:24:12 conman has left ("Leaving")
 237 2011-12-29 03:24:14 <roconnor> luke-jr: that is also reasonable
 238 2011-12-29 03:24:19 <luke-jr> I suppose it might mean two OP_CODEHASHes that way tho
 239 2011-12-29 03:24:28 <luke-jr> since there's an implicit OP_CODESEP right before it
 240 2011-12-29 03:25:03 <luke-jr> in any case, OP_CODEHASH needs to confirm that the same hash is already on the stack, and not change it
 241 2011-12-29 03:25:11 <luke-jr> ie, it either aborts the script or not
 242 2011-12-29 03:25:22 <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
 243 2011-12-29 03:25:41 <roconnor> you can replace the codehash stack with a codehash state variable
 244 2011-12-29 03:25:54 <roconnor> (ie just keep the top of the stack and drop everything else
 245 2011-12-29 03:26:10 <roconnor> and initialize the codehash state variable with the hash of the signature script
 246 2011-12-29 03:26:34 <roconnor> (the implementation is welcome to delay performing this hash until OP_CODEHASH is called ... if ever  (ie using a future))
 247 2011-12-29 03:26:57 <roconnor> luke-jr: I will subscribe to the development mailing list
 248 2011-12-29 03:27:06 <roconnor> tonight or tomorrow
 249 2011-12-29 03:27:31 <roconnor> luke-jr: should I CC major pool operators or are they all on the list already?
 250 2011-12-29 03:27:43 <luke-jr> I'd CC DeepBit and BTCGuild at least
 251 2011-12-29 03:29:32 <roconnor> what are their addresses?
 252 2011-12-29 03:31:12 devrandom has quit (Remote host closed the connection)
 253 2011-12-29 03:31:19 TheSeven has quit (Disconnected by services)
 254 2011-12-29 03:31:31 [7] has joined
 255 2011-12-29 03:32:05 devrandom has joined
 256 2011-12-29 03:37:52 * roconnor is starting to get an inkling that this might doable with just OP_CODESEPARATOR with the current client code.
 257 2011-12-29 03:38:32 <roconnor> probably not though
 258 2011-12-29 03:46:32 TuxBlackEdo_away is now known as TuxBlackEdo
 259 2011-12-29 03:49:48 nmat has joined
 260 2011-12-29 03:49:52 nmat has left ()
 261 2011-12-29 03:49:57 Greed has joined
 262 2011-12-29 03:50:46 <pirateat40> I need a getwork request guru.
 263 2011-12-29 04:01:18 devrandom has quit (Ping timeout: 276 seconds)
 264 2011-12-29 04:07:31 Nesetalis has quit (Quit: <+shponka> how does one scissor with four people <+shponka> hypercube tribadism)
 265 2011-12-29 04:08:16 Nesetalis has joined
 266 2011-12-29 04:08:16 RobinPKR has quit (Read error: Connection reset by peer)
 267 2011-12-29 04:09:27 RobinPKR has joined
 268 2011-12-29 04:10:25 theymos has joined
 269 2011-12-29 04:11:55 Nesetalis has quit (Client Quit)
 270 2011-12-29 04:13:02 Nesetalis has joined
 271 2011-12-29 04:16:13 vrs has left ()
 272 2011-12-29 04:19:38 Joric has quit ()
 273 2011-12-29 04:21:42 jacobwg has joined
 274 2011-12-29 04:25:46 DontMindMe has joined
 275 2011-12-29 04:32:12 devrandom has joined
 276 2011-12-29 04:35:07 DontMindMe has quit (Ping timeout: 240 seconds)
 277 2011-12-29 04:35:47 DontMindMe has joined
 278 2011-12-29 04:44:00 mcorlett has quit (Quit: ChatZilla 0.9.88 [Firefox 8.0/20111115183813])
 279 2011-12-29 04:44:54 dr_win has joined
 280 2011-12-29 04:49:07 dr_win has quit (Ping timeout: 240 seconds)
 281 2011-12-29 04:56:47 OneFixt has quit (Ping timeout: 240 seconds)
 282 2011-12-29 04:56:57 b4epoche has quit (Read error: Operation timed out)
 283 2011-12-29 04:58:08 b4epoche has joined
 284 2011-12-29 04:59:10 m86 has joined
 285 2011-12-29 04:59:18 SomeoneWeird has joined
 286 2011-12-29 05:00:24 mcorlett has joined
 287 2011-12-29 05:02:00 m87 has quit (Ping timeout: 252 seconds)
 288 2011-12-29 05:02:15 OneFixt has joined
 289 2011-12-29 05:02:42 OneFixt is now known as Guest22354
 290 2011-12-29 05:04:28 Guest22354 has quit (Changing host)
 291 2011-12-29 05:04:28 Guest22354 has joined
 292 2011-12-29 05:07:09 dissipate has joined
 293 2011-12-29 05:07:15 Guest22354 is now known as OneFixt
 294 2011-12-29 05:13:49 the_batman has joined
 295 2011-12-29 05:15:17 jacobwg has quit (Quit: Computer has gone to sleep.)
 296 2011-12-29 05:32:14 wasabi2 has joined
 297 2011-12-29 05:34:16 wasabi has quit (Ping timeout: 240 seconds)
 298 2011-12-29 05:36:07 WakiMiko_ has quit (Ping timeout: 240 seconds)
 299 2011-12-29 05:36:38 slobo has joined
 300 2011-12-29 05:38:20 WakiMiko has joined
 301 2011-12-29 05:39:17 minimoose has quit (Quit: minimoose)
 302 2011-12-29 05:50:26 JZavala has joined
 303 2011-12-29 05:56:34 <theymos> Interesting new attack on several programming languages, exploiting collisions in hash tables: http://tinyurl.com/bvjhtwt
 304 2011-12-29 05:58:37 <SomeoneWeird> lol so php4 is partially vulnerable while php5 is
 305 2011-12-29 05:58:39 <SomeoneWeird> -.-
 306 2011-12-29 05:59:01 <SomeoneWeird> wow thats gotta hurt, easy ddos now.
 307 2011-12-29 05:59:53 <the_batman> haha pretty cool
 308 2011-12-29 06:00:18 <SomeoneWeird> yeah
 309 2011-12-29 06:05:06 Joric has joined
 310 2011-12-29 06:05:06 Joric has quit (Changing host)
 311 2011-12-29 06:05:06 Joric has joined
 312 2011-12-29 06:13:15 BurtyB has quit (Ping timeout: 276 seconds)
 313 2011-12-29 06:15:14 BurtyB has joined
 314 2011-12-29 06:24:47 dissipate has quit (Ping timeout: 240 seconds)
 315 2011-12-29 06:33:58 BurtyBB has joined
 316 2011-12-29 06:34:16 BurtyB has quit (Ping timeout: 248 seconds)
 317 2011-12-29 06:45:17 theymos has quit (Remote host closed the connection)
 318 2011-12-29 06:57:41 BlueMatt has joined
 319 2011-12-29 07:07:36 Diablo-D3 has quit (Ping timeout: 244 seconds)
 320 2011-12-29 07:09:04 copumpkin has quit (Ping timeout: 252 seconds)
 321 2011-12-29 07:09:11 copumpkin has joined
 322 2011-12-29 07:14:02 pirateat40 has quit (Read error: Connection reset by peer)
 323 2011-12-29 07:15:40 JZavala has quit (Ping timeout: 276 seconds)
 324 2011-12-29 07:48:45 abragin has joined
 325 2011-12-29 07:48:45 abragin has quit (Changing host)
 326 2011-12-29 07:48:45 abragin has joined
 327 2011-12-29 07:49:00 dissipate has joined
 328 2011-12-29 07:51:59 Greed has left ("A plus tard, le meunier!")
 329 2011-12-29 07:52:33 stalled has quit (Ping timeout: 244 seconds)
 330 2011-12-29 08:23:29 molecular has quit (Ping timeout: 240 seconds)
 331 2011-12-29 08:24:29 molecular has joined
 332 2011-12-29 08:28:42 Zarutian has quit (Quit: Zarutian)
 333 2011-12-29 08:28:53 nanotube has quit (Read error: Operation timed out)
 334 2011-12-29 08:31:01 nanotube has joined
 335 2011-12-29 08:31:39 stalled has joined
 336 2011-12-29 08:35:45 <midnightmagic> i never liked hash tables.
 337 2011-12-29 08:36:29 <edcba> don't like worst cases ?
 338 2011-12-29 08:36:37 ageis has quit (Ping timeout: 248 seconds)
 339 2011-12-29 08:36:46 <Graet> ;;seen shadders
 340 2011-12-29 08:36:46 <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?
 341 2011-12-29 08:38:13 JZavala has joined
 342 2011-12-29 08:38:50 ahbritto_ has joined
 343 2011-12-29 08:38:51 ahbritto_ has quit (Changing host)
 344 2011-12-29 08:38:51 ahbritto_ has joined
 345 2011-12-29 08:39:08 <midnightmagic> never liked how they are abused by what appear to be lazy people.
 346 2011-12-29 08:39:34 stalled has quit (Ping timeout: 244 seconds)
 347 2011-12-29 08:40:13 <copumpkin> there's also a bit of laziness in how people analyze their time complexity vs. balanced trees
 348 2011-12-29 08:44:19 imsaguy2 has joined
 349 2011-12-29 08:46:49 mtve has quit (Ping timeout: 244 seconds)
 350 2011-12-29 08:48:17 mtve has joined
 351 2011-12-29 08:52:14 ageis has joined
 352 2011-12-29 08:56:34 nr9 has joined
 353 2011-12-29 08:58:28 nr9 has quit (Client Quit)
 354 2011-12-29 09:00:16 stalled has joined
 355 2011-12-29 09:01:20 nr9 has joined
 356 2011-12-29 09:02:08 RazielZ has joined
 357 2011-12-29 09:02:39 nr9 has quit (Client Quit)
 358 2011-12-29 09:09:51 b4epoche_ has joined
 359 2011-12-29 09:10:05 BlueMatt has quit (Quit: Ex-Chat)
 360 2011-12-29 09:10:36 b4epoche has quit (Ping timeout: 252 seconds)
 361 2011-12-29 09:10:37 b4epoche_ is now known as b4epoche
 362 2011-12-29 09:14:32 marf_away has joined
 363 2011-12-29 09:15:11 ovidiusoft has joined
 364 2011-12-29 09:18:44 BlueMatt has joined
 365 2011-12-29 09:34:04 wasabi has joined
 366 2011-12-29 09:36:08 wasabi2 has quit (Ping timeout: 252 seconds)
 367 2011-12-29 09:44:06 da2ce7 has joined
 368 2011-12-29 09:52:39 iocor has joined
 369 2011-12-29 10:11:20 BlueMatt has quit (Ping timeout: 252 seconds)
 370 2011-12-29 10:28:04 da2ce7 has quit (Ping timeout: 276 seconds)
 371 2011-12-29 10:36:58 da2ce7 has joined
 372 2011-12-29 10:38:06 [Tycho] has joined
 373 2011-12-29 10:39:21 sytse has quit (Ping timeout: 252 seconds)
 374 2011-12-29 10:40:10 sytse has joined
 375 2011-12-29 10:43:23 iocor has quit (Quit: Computer has gone to sleep.)
 376 2011-12-29 10:45:40 dr_win_ has joined
 377 2011-12-29 10:50:33 graingert has joined
 378 2011-12-29 10:55:13 datagutt has joined
 379 2011-12-29 11:03:10 da2ce7 has quit (Ping timeout: 276 seconds)
 380 2011-12-29 11:11:54 xtor_ has joined
 381 2011-12-29 11:12:33 iocor has joined
 382 2011-12-29 11:14:04 extor has quit (Ping timeout: 244 seconds)
 383 2011-12-29 11:19:29 xtor_ has quit (Quit: Leaving)
 384 2011-12-29 11:19:53 Clipse has joined
 385 2011-12-29 11:20:04 extor has joined
 386 2011-12-29 11:20:23 graingert has quit (Remote host closed the connection)
 387 2011-12-29 11:28:07 PK has joined
 388 2011-12-29 11:28:36 genjix has joined
 389 2011-12-29 11:28:52 larsivi has quit (Ping timeout: 252 seconds)
 390 2011-12-29 11:29:07 MobiusL_ has quit (Remote host closed the connection)
 391 2011-12-29 11:31:49 MobiusL_ has joined
 392 2011-12-29 11:40:42 larsivi has joined
 393 2011-12-29 11:40:43 larsivi has quit (Read error: Connection reset by peer)
 394 2011-12-29 11:50:42 SomeoneWeird has quit (Ping timeout: 240 seconds)
 395 2011-12-29 11:55:30 SomeoneWeird has joined
 396 2011-12-29 12:07:40 TD has joined
 397 2011-12-29 12:18:06 lfm has joined
 398 2011-12-29 12:27:35 MobiusL_ has quit (Remote host closed the connection)
 399 2011-12-29 12:27:35 darkee has quit (Remote host closed the connection)
 400 2011-12-29 12:28:14 <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
 401 2011-12-29 12:28:38 darkee has joined
 402 2011-12-29 12:28:50 MobiusL_ has joined
 403 2011-12-29 12:29:11 tower has quit (Ping timeout: 252 seconds)
 404 2011-12-29 12:29:50 larsivi has joined
 405 2011-12-29 12:31:43 copumpkin is now known as Jim
 406 2011-12-29 12:31:46 imsaguy is now known as A
 407 2011-12-29 12:31:48 Jim is now known as Bo
 408 2011-12-29 12:31:52 A is now known as imsaguy
 409 2011-12-29 12:32:22 Bo is now known as copumpkin
 410 2011-12-29 12:32:29 imsaguy is now known as _
 411 2011-12-29 12:32:47 _ is now known as __
 412 2011-12-29 12:32:51 __ is now known as ___
 413 2011-12-29 12:33:01 ___ is now known as ____
 414 2011-12-29 12:33:04 ____ is now known as _____
 415 2011-12-29 12:33:34 _____ is now known as Guest92641
 416 2011-12-29 12:33:40 Guest92641 is now known as imsaguy
 417 2011-12-29 12:36:43 imsaguy is now known as \_\_\
 418 2011-12-29 12:37:09 tower has joined
 419 2011-12-29 12:38:10 \_\_\ is now known as \\
 420 2011-12-29 12:38:15 \\ is now known as \\\
 421 2011-12-29 12:38:21 \\\ is now known as \\\\
 422 2011-12-29 12:38:30 \\\\ is now known as \_\_\
 423 2011-12-29 12:38:48 Pasha has joined
 424 2011-12-29 12:39:01 Pasha has quit (Excess Flood)
 425 2011-12-29 12:40:19 \_\_\ is now known as [\]
 426 2011-12-29 12:40:28 [\] is now known as [\\]
 427 2011-12-29 12:40:37 [\\] is now known as [\\\]
 428 2011-12-29 12:45:22 Joric has quit (Ping timeout: 256 seconds)
 429 2011-12-29 12:49:45 Joric has joined
 430 2011-12-29 12:49:57 Joric has quit (Changing host)
 431 2011-12-29 12:49:57 Joric has joined
 432 2011-12-29 12:55:19 * SomeoneWeird hits [\\] 
 433 2011-12-29 13:00:10 Clipse has quit (Quit: Clipse)
 434 2011-12-29 13:01:14 Turingi has joined
 435 2011-12-29 13:13:16 genjix has left ()
 436 2011-12-29 13:14:45 Joric has quit ()
 437 2011-12-29 13:21:14 b4epoche_ has joined
 438 2011-12-29 13:22:10 b4epoche has quit (Ping timeout: 252 seconds)
 439 2011-12-29 13:22:10 b4epoche_ is now known as b4epoche
 440 2011-12-29 13:24:40 [Tycho] has quit (Remote host closed the connection)
 441 2011-12-29 13:33:54 abragin has quit (Ping timeout: 240 seconds)
 442 2011-12-29 13:34:10 abragin has joined
 443 2011-12-29 13:34:10 abragin has quit (Changing host)
 444 2011-12-29 13:34:10 abragin has joined
 445 2011-12-29 13:34:38 random_cat has quit (Ping timeout: 276 seconds)
 446 2011-12-29 13:35:44 dr_win_ has quit (Remote host closed the connection)
 447 2011-12-29 13:36:35 MobiusL_ has quit (Ping timeout: 276 seconds)
 448 2011-12-29 13:38:42 erle- has joined
 449 2011-12-29 13:38:47 abragin has quit (Ping timeout: 255 seconds)
 450 2011-12-29 13:38:47 imsaguy2 has quit (Ping timeout: 255 seconds)
 451 2011-12-29 13:41:09 abragin has joined
 452 2011-12-29 13:41:09 abragin has quit (Changing host)
 453 2011-12-29 13:41:09 abragin has joined
 454 2011-12-29 13:43:42 TD_ has joined
 455 2011-12-29 13:43:54 larsivi has quit (Read error: Connection reset by peer)
 456 2011-12-29 13:45:33 coingenuity has joined
 457 2011-12-29 13:47:49 TD has quit (Ping timeout: 240 seconds)
 458 2011-12-29 13:47:50 TD_ is now known as TD
 459 2011-12-29 13:51:13 random_cat has joined
 460 2011-12-29 13:53:46 MobiusL_ has joined
 461 2011-12-29 13:53:54 marf_away has quit (Ping timeout: 252 seconds)
 462 2011-12-29 13:58:14 Daniel0108 has quit (Quit: ZNC - http://znc.in)
 463 2011-12-29 14:02:01 Daniel0108 has joined
 464 2011-12-29 14:07:08 TD_ has joined
 465 2011-12-29 14:10:50 TD has quit (Ping timeout: 240 seconds)
 466 2011-12-29 14:10:50 TD_ is now known as TD
 467 2011-12-29 14:13:22 PK has quit ()
 468 2011-12-29 14:13:53 da2ce7 has joined
 469 2011-12-29 14:19:42 Xunie has quit (Quit: Can God microwave a taco so hot that not even *HE* can eat it without burns?)
 470 2011-12-29 14:27:45 larsivi has joined
 471 2011-12-29 14:46:38 erle- has quit (Quit: erle-)
 472 2011-12-29 14:48:24 _Fireball has joined
 473 2011-12-29 14:53:30 Xunie has joined
 474 2011-12-29 15:00:20 dr_win has joined
 475 2011-12-29 15:01:24 Maroni_ has joined
 476 2011-12-29 15:13:36 knotwork has quit (Remote host closed the connection)
 477 2011-12-29 15:14:45 knotwork has joined
 478 2011-12-29 15:14:57 knotwork has quit (Changing host)
 479 2011-12-29 15:14:57 knotwork has joined
 480 2011-12-29 15:18:10 Xunie has quit (Remote host closed the connection)
 481 2011-12-29 15:20:33 Xunie has joined
 482 2011-12-29 15:25:20 [Tycho] has joined
 483 2011-12-29 15:36:48 wasabi2 has joined
 484 2011-12-29 15:38:47 wasabi has quit (Ping timeout: 276 seconds)
 485 2011-12-29 15:39:43 danbri has joined
 486 2011-12-29 15:54:38 rdponticelli has quit (Remote host closed the connection)
 487 2011-12-29 16:02:49 imsaguy has joined
 488 2011-12-29 16:02:49 imsaguy has quit (Changing host)
 489 2011-12-29 16:02:50 imsaguy has joined
 490 2011-12-29 16:13:20 pumpkin has joined
 491 2011-12-29 16:14:13 copumpkin has quit (Ping timeout: 248 seconds)
 492 2011-12-29 16:18:35 pumpkin is now known as copumpkin
 493 2011-12-29 16:23:21 imsaguy is now known as imsaguy2
 494 2011-12-29 16:24:33 TD has quit (Quit: TD)
 495 2011-12-29 16:24:34 booo has joined
 496 2011-12-29 16:30:35 Daniel0108 has quit (Ping timeout: 268 seconds)
 497 2011-12-29 16:34:03 devrandom has quit (Ping timeout: 276 seconds)
 498 2011-12-29 16:34:03 gfinn has quit (Ping timeout: 276 seconds)
 499 2011-12-29 16:34:41 MobiusL_ has quit (Ping timeout: 276 seconds)
 500 2011-12-29 16:44:51 SomeoneWeird has quit (Quit: Leaving)
 501 2011-12-29 16:48:42 devrandom has joined
 502 2011-12-29 16:57:56 gfinn has joined
 503 2011-12-29 17:05:15 <roconnor> copumpkin: feel like implementing the SK-calculus in bitcoin-script using OP_EVAL?
 504 2011-12-29 17:05:40 <copumpkin> I don't know enough about OP_EVAL
 505 2011-12-29 17:05:45 <copumpkin> I haven't been following any of this stuff, really
 506 2011-12-29 17:06:09 <sipa> we already have an omega combinator :)
 507 2011-12-29 17:06:15 <roconnor> yep
 508 2011-12-29 17:06:40 <roconnor> copumpkin: It's pretty easy to learn the basic semantics of OP_EVAL
 509 2011-12-29 17:07:10 <copumpkin> where can I read about it?
 510 2011-12-29 17:07:39 <copumpkin> bip 12?
 511 2011-12-29 17:07:42 <roconnor> In theory https://en.bitcoin.it/wiki/BIP_0012
 512 2011-12-29 17:07:50 <copumpkin> except it's down :(
 513 2011-12-29 17:07:52 <sipa> bitcoin.it down?
 514 2011-12-29 17:09:11 wasabi1 has quit (Read error: Connection reset by peer)
 515 2011-12-29 17:10:56 <copumpkin> roconnor: do you actually own any bitcoins, by the way? :P
 516 2011-12-29 17:10:58 Maroni_ has quit (Ping timeout: 255 seconds)
 517 2011-12-29 17:11:13 <roconnor> copumpkin: do testnet coins count?
 518 2011-12-29 17:11:19 <copumpkin> nope
 519 2011-12-29 17:11:23 <roconnor> copumpkin: then no I don't
 520 2011-12-29 17:11:25 <copumpkin> tsk tsk
 521 2011-12-29 17:11:39 <copumpkin> how could you possibly be interested in bitcoin without a financial interest in them!
 522 2011-12-29 17:11:44 <roconnor> copumpkin: have you seen the code behind bitcoin!!
 523 2011-12-29 17:11:52 <roconnor> who would invest in that :D
 524 2011-12-29 17:11:52 * sipa has
 525 2011-12-29 17:12:00 <copumpkin> :)
 526 2011-12-29 17:12:46 marf_away has joined
 527 2011-12-29 17:12:51 Maroni has joined
 528 2011-12-29 17:14:23 <roconnor> once we have the SK calculus implement we can get the scripting language to play chess
 529 2011-12-29 17:15:47 <sipa> with limits on code size, instructions executed, and disabled op codes, you won't get far
 530 2011-12-29 17:15:54 <roconnor> http://www.engadget.com/2006/10/06/dutch-voting-machines-hacked-to-play-chess/
 531 2011-12-29 17:16:53 <edcba> you need not to invest to own bitcoins
 532 2011-12-29 17:17:20 <roconnor> edcba: true
 533 2011-12-29 17:17:34 <roconnor> copumpkin: who would hold a position in that :D
 534 2011-12-29 17:18:43 hippich has joined
 535 2011-12-29 17:22:07 Daniel0108 has joined
 536 2011-12-29 17:22:19 schilly has joined
 537 2011-12-29 17:23:10 <roconnor> BIP 0016: OP_GOTO
 538 2011-12-29 17:24:22 wasabi has joined
 539 2011-12-29 17:25:13 <copumpkin> roconnor: lol
 540 2011-12-29 17:25:23 <copumpkin> OP_SUBLEQ
 541 2011-12-29 17:25:47 <roconnor> :D
 542 2011-12-29 17:26:34 <roconnor> copumpkin: with OP_SUBLEQ we can depricate all the other operations.
 543 2011-12-29 17:26:49 <copumpkin> excellent :D
 544 2011-12-29 17:26:56 <copumpkin> well, we might need a primop or two to talk to the outside world
 545 2011-12-29 17:27:04 <roconnor> I suppose
 546 2011-12-29 17:27:25 <copumpkin> the primop in our subleq language could be EXEC_PYTHON
 547 2011-12-29 17:27:36 <roconnor> EXEC_PERL would be better
 548 2011-12-29 17:27:43 <roconnor> since PERL isn't statically parsable
 549 2011-12-29 17:27:47 <roconnor> it must be better
 550 2011-12-29 17:27:49 * roconnor nods
 551 2011-12-29 17:27:50 <copumpkin> good point
 552 2011-12-29 17:27:58 <edcba> perl isn't even readable
 553 2011-12-29 17:28:08 <copumpkin> edcba: some say the same about haskell
 554 2011-12-29 17:28:13 <copumpkin> and clearly they're wrong
 555 2011-12-29 17:28:16 <roconnor> edcba: that's because you need to execute perl in order to read it
 556 2011-12-29 17:31:25 <sipa> cut the crap
 557 2011-12-29 17:31:31 <sipa> just use OP_X86ASM
 558 2011-12-29 17:31:34 <copumpkin> lol
 559 2011-12-29 17:32:00 <edcba> à la NaCl
 560 2011-12-29 17:32:04 <roconnor> sipa: see now that is a very good idea
 561 2011-12-29 17:32:13 <sipa> efficiency++
 562 2011-12-29 17:32:13 <copumpkin> well, I insist on PCC x86asm
 563 2011-12-29 17:32:20 <roconnor> sipa: because many users could just directly execute the bytecode
 564 2011-12-29 17:32:21 slobo has quit (Quit: slobo)
 565 2011-12-29 17:32:26 <copumpkin> I demand my x86 with a side of proof
 566 2011-12-29 17:32:27 <roconnor> what could go wrong?
 567 2011-12-29 17:32:52 <roconnor> I can't think of any problems, so there must be none.
 568 2011-12-29 17:33:17 <sipa> other systems just need a cpu emulator
 569 2011-12-29 17:33:32 <sipa> those are well-researched and completely void of security problems
 570 2011-12-29 17:33:36 <copumpkin> bundle QEMU in all bitcoin distros
 571 2011-12-29 17:33:47 b4epoche_ has joined
 572 2011-12-29 17:33:55 <copumpkin> b4epoche: how's it going?
 573 2011-12-29 17:34:35 b4epoche has quit (Ping timeout: 248 seconds)
 574 2011-12-29 17:34:35 b4epoche_ is now known as b4epoche
 575 2011-12-29 17:36:26 <lianj> BIP 0101: turing completeness
 576 2011-12-29 17:36:34 TD has joined
 577 2011-12-29 17:36:41 <roconnor> lianj: that is what BIP 0012 is
 578 2011-12-29 17:36:52 <lianj> ah m( lol
 579 2011-12-29 17:37:00 <sipa> it is not
 580 2011-12-29 17:37:18 <roconnor> well neither is my computer since it has limited RAM
 581 2011-12-29 17:38:19 booo has quit (Ping timeout: 252 seconds)
 582 2011-12-29 17:38:31 <roconnor> well to be fair I guess my computer can loop
 583 2011-12-29 17:38:46 <roconnor> but even with BIP 0012 the scripting language cannot
 584 2011-12-29 17:38:55 <roconnor> ... though I'd kinda like to see a proof of that
 585 2011-12-29 17:39:33 <gmaxwell> and implement some kinds of infinite recursion too, (just not w/ languages that force every call to stake a stackframe)
 586 2011-12-29 17:40:21 <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.
 587 2011-12-29 17:41:00 <roconnor> gmaxwell: by the Gavin method, yes.
 588 2011-12-29 17:41:04 <roconnor> gmaxwell: any other ways?
 589 2011-12-29 17:41:39 da2ce7 has quit (Ping timeout: 276 seconds)
 590 2011-12-29 17:41:46 <gmaxwell> Yea, I don't have a proof that it isn't possible but I don't see how.
 591 2011-12-29 17:42:00 <roconnor> gmaxwell: well, if you guys don't see how, then it must be fine.
 592 2011-12-29 17:42:17 <gmaxwell> :-/
 593 2011-12-29 17:42:19 <sipa> clearly we're smarter than any potential attacker
 594 2011-12-29 17:43:04 <roconnor> actually I have a vague idea how to prove loopin is impossible
 595 2011-12-29 17:43:30 <roconnor> but I'm through helping this OP_EVAL proposal.
 596 2011-12-29 17:43:37 <roconnor> I don't even want it
 597 2011-12-29 17:43:59 <roconnor> now I have my own proposal
 598 2011-12-29 17:44:24 <roconnor> not that I want it either, but it is better.
 599 2011-12-29 17:45:02 <roconnor> sipa: are you on the bitcoin-development list?
 600 2011-12-29 17:45:05 <copumpkin> BIP 0012.5?
 601 2011-12-29 17:45:09 <sipa> roconnor: of course
 602 2011-12-29 17:45:15 <roconnor> good
 603 2011-12-29 17:45:29 <roconnor> copumpkin: you might not be
 604 2011-12-29 17:45:36 <copumpkin> oh, I'm not
 605 2011-12-29 17:45:43 <copumpkin> I am but a lowly bitcoin speculator
 606 2011-12-29 17:45:44 <roconnor> I can give you an archive link
 607 2011-12-29 17:45:51 <roconnor> oh but maybe you dont' care
 608 2011-12-29 17:45:53 <copumpkin> oh I do
 609 2011-12-29 17:46:16 <roconnor> http://sourceforge.net/mailarchive/forum.php?thread_name=CABsx9T06H29R4CpL9hXF_yyB4chko1YdkhbCZ8rdwo1gLmF1BQ%40mail.gmail.com&forum_name=bitcoin-development
 610 2011-12-29 17:46:20 <sipa> roconnor: i like your proposal, but have the same remarks as gavin
 611 2011-12-29 17:46:50 <roconnor> sipa: okay
 612 2011-12-29 17:47:17 <sipa> though i'm definitely beginning to agree that it should be postponed, i must admit that OP_EVAL is still "nicer" in usage
 613 2011-12-29 17:47:17 Daniel0108 has quit (Quit: ZNC - http://znc.in)
 614 2011-12-29 17:48:21 wasabi1 has joined
 615 2011-12-29 17:48:43 HaltingState has quit (Quit: Leaving)
 616 2011-12-29 17:48:53 <lianj> is there a list of merged mainline BIPs?
 617 2011-12-29 17:49:06 <sipa> BIPs aren't merged, they aren't code
 618 2011-12-29 17:49:23 <sipa> they are accepted or not, by some or all
 619 2011-12-29 17:49:25 <lianj> implementations of bips then
 620 2011-12-29 17:50:27 <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)
 621 2011-12-29 17:50:30 <gmaxwell> roconnor: the increase in the input script size in your proposal is unfortunate. :(
 622 2011-12-29 17:51:56 Daniel0108 has joined
 623 2011-12-29 17:52:10 wasabi has quit (Ping timeout: 240 seconds)
 624 2011-12-29 17:52:36 <gmaxwell> (Otherwise it sounds fine to me, but meh, big otherwise)
 625 2011-12-29 17:53:43 <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)
 626 2011-12-29 17:54:54 <TD> there seem to have been 3 different talks at CCC about bitcoin
 627 2011-12-29 17:54:55 <TD> not bad
 628 2011-12-29 17:55:00 <sipa> wow
 629 2011-12-29 17:55:39 <copumpkin> roconnor: I see, thanks
 630 2011-12-29 17:57:03 <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
 631 2011-12-29 17:57:10 <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.
 632 2011-12-29 17:57:15 <TD> agree
 633 2011-12-29 17:57:27 <TD> unless bitcoin changes out from underneath them
 634 2011-12-29 17:57:38 <gmaxwell> roconnor: so, what if there was a second stack that only picked up items that were pushed explicitly. (not the result of computations)
 635 2011-12-29 17:57:52 <gmaxwell> roconnor: and then OP_EVAL only executed from that stack
 636 2011-12-29 17:58:09 <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
 637 2011-12-29 17:58:32 <sipa> roconnor: with the explicit extra rule that OP_CHECKEDEVAL must follow a literal push of the scriot
 638 2011-12-29 17:58:40 <TD> jgarzik: for example, if Script is changed .....
 639 2011-12-29 17:59:25 <gmaxwell> TD: people do research all the time on systems which aren't set in stone, it's called dealing with reality. :-)
 640 2011-12-29 17:59:45 <sipa> roconnor: which means you can statically analyze it, as the <code> + OP_CHECKEDEVAL pair can be seen and parsed as code
 641 2011-12-29 17:59:47 copumpkin has quit (Read error: Operation timed out)
 642 2011-12-29 18:00:12 <gmaxwell> TD: are any of them looking at that part of the system? That would be nice.
 643 2011-12-29 18:00:26 <TD> which part? script?
 644 2011-12-29 18:00:43 <gmaxwell> Yes.  Seems to me that people like to do deanonmization or boring p2p protocol stuff because it's cheap headlines.
 645 2011-12-29 18:00:52 <TD> i'm not sure. i'm about half way through this video
 646 2011-12-29 18:00:58 <TD> he seems to be talking about economics currently
 647 2011-12-29 18:01:23 <TD> he thinks there has to be a way to recover lost bitcoins
 648 2011-12-29 18:01:32 * gmaxwell rolls eyes
 649 2011-12-29 18:01:41 <TD> i'm watching this one: http://www.youtube.com/28c3#p/u/5/rJN0Hm3srUc
 650 2011-12-29 18:01:42 <sipa> who is 'he' ?
 651 2011-12-29 18:02:11 <TD> the speaker
 652 2011-12-29 18:02:13 <sipa> ok
 653 2011-12-29 18:02:22 <lianj> jgarzik: how are ccc crowd outsiders?
 654 2011-12-29 18:02:34 <makomk> luke-jr: btw, it looks like -blocknotify leaks zombie child processes?
 655 2011-12-29 18:03:01 <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.
 656 2011-12-29 18:03:49 <lianj> gmaxwell: well the talk TD is watch certainlly will not provide popularity/new-users
 657 2011-12-29 18:04:31 <TD> i think it's fair enough
 658 2011-12-29 18:04:38 <TD> there hasn't been enough research into tx graph analysis
 659 2011-12-29 18:04:44 copumpkin has joined
 660 2011-12-29 18:04:52 <lianj> TD: which is the third one? the blackops tcp one?
 661 2011-12-29 18:04:55 <TD> in future i think we'll see wallets that actively attempt to improve your privacy
 662 2011-12-29 18:05:02 <TD> lianj: yeah
 663 2011-12-29 18:05:09 <TD> lianj: but it was just a repeat of the BH talk kaminsky gave
 664 2011-12-29 18:05:30 <lianj> ah ok. iirc it was quite similar to the ccc-camps talk and defcon talk by him
 665 2011-12-29 18:05:41 <lianj> yea
 666 2011-12-29 18:06:01 <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.
 667 2011-12-29 18:06:10 <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
 668 2011-12-29 18:06:20 <gmaxwell> The research in that area is helpful, but it can't really lead to solutions to the above.
 669 2011-12-29 18:07:17 <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
 670 2011-12-29 18:07:28 <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.
 671 2011-12-29 18:08:08 <lianj> TD: i was in the analysis talk, the room was full. not sure how many actual bitcoin users where there though
 672 2011-12-29 18:08:17 <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
 673 2011-12-29 18:08:27 <TD> i agree, few people truly care about anonymity
 674 2011-12-29 18:08:27 <copumpkin> are there plans to give the mainstream client the ability to control where the coins being spent are coming from?
 675 2011-12-29 18:08:47 <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.
 676 2011-12-29 18:08:49 <TD> but that can be fixed
 677 2011-12-29 18:09:24 <TD> copumpkin: some people have written patches that give you more control. i think automatic/implicit privacy protections are the way to go
 678 2011-12-29 18:09:25 <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.
 679 2011-12-29 18:09:57 <gmaxwell> TD: e.g. you have privacy with a bank, but anyone with a legit need can petition a court to subpoena your records.
 680 2011-12-29 18:09:59 <TD> gmaxwell: perhaps. technology is making "large scale data mining" and "targeted attack" not so different
 681 2011-12-29 18:10:08 <gmaxwell> TD: fair enough.
 682 2011-12-29 18:10:18 <TD> gmaxwell: yes, the banking model provides a good tradeoff, if you assume trusted governments. that's starting to break down though
 683 2011-12-29 18:10:24 <TD> 1) governments are becoming less trustworthy
 684 2011-12-29 18:10:24 <TD> 2
 685 2011-12-29 18:10:38 <TD> 2) "banks" and payment processors are starting to wake up to the value of their data and selling it
 686 2011-12-29 18:10:58 <roconnor> [12:55] <sipa> roconnor: with the explicit extra rule that OP_CHECKEDEVAL must follow a literal push of the scriot
 687 2011-12-29 18:11:12 <TD> still
 688 2011-12-29 18:11:23 <roconnor> sipa: I'd probably okay with that if you can make it work
 689 2011-12-29 18:11:25 <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.
 690 2011-12-29 18:11:30 <roconnor> sipa: but My proposal is still better
 691 2011-12-29 18:11:31 <TD> finding a way to balance these competing requirements would be good
 692 2011-12-29 18:12:16 <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)
 693 2011-12-29 18:12:19 <TD> http://consumerist.com/2011/10/credit-cards-to-sell-your-buying-history-so-online-advertisers-can-target-you-more-precisely.html
 694 2011-12-29 18:12:25 <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."
 695 2011-12-29 18:12:29 <TD> the latter doesn't really bother me
 696 2011-12-29 18:13:03 <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
 697 2011-12-29 18:13:18 <TD> but does not allow for TFTP-style unsupervised monitoring
 698 2011-12-29 18:13:53 <TD> this talk is mostly just giving stats about the tx graph. it's not really a security analysis, it seems.
 699 2011-12-29 18:13:54 <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.
 700 2011-12-29 18:14:07 <TD> gmaxwell: yes, sure. i agree. and that's fine. that's the point of warrants.
 701 2011-12-29 18:14:37 <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
 702 2011-12-29 18:14:43 <TD> and you can't escape from it. this happens already.
 703 2011-12-29 18:15:03 <TD> there are effectively no controls or auditing on such systems and so it's basically guaranteed they will be abused
 704 2011-12-29 18:15:09 <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, ...
 705 2011-12-29 18:15:16 <TD> and/or possibly compromised
 706 2011-12-29 18:15:19 <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.
 707 2011-12-29 18:15:24 <sipa> roconnor: all advantages, except the subscript is serialized instead of a real script
 708 2011-12-29 18:15:26 <TD> yes
 709 2011-12-29 18:16:28 <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
 710 2011-12-29 18:17:14 <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.
 711 2011-12-29 18:17:14 <gmaxwell> I sent an international wire a couple weeks ago. Oy. I had to list all the nationalities of the recipient. wtf.
 712 2011-12-29 18:17:25 <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
 713 2011-12-29 18:18:02 <TD> gmaxwell: well the current set of rules are well intentioned but absurd and in many ways harmful, imho
 714 2011-12-29 18:18:24 <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!)
 715 2011-12-29 18:18:25 <sipa> roconnor: the subscript is a completely independent execution environnement, that only inherits the stack
 716 2011-12-29 18:18:47 <roconnor> sipa: that's how it is now, but gavin wants to "fix" this IIUC
 717 2011-12-29 18:18:48 <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"
 718 2011-12-29 18:18:48 <sipa> roconnor: it does not return anything, the only output possible is that it can cause failure, in which case the entire script fails
 719 2011-12-29 18:19:11 <sipa> roconnor: where do you read that?
 720 2011-12-29 18:19:13 <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
 721 2011-12-29 18:19:43 <TD> gmaxwell: there aren't many controls against centralized abuse though. nothing which _requires_ warrants
 722 2011-12-29 18:19:47 <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. :)
 723 2011-12-29 18:19:51 <roconnor> sipa: https://github.com/bitcoin/bitcoin/issues/729#issuecomment-3294453
 724 2011-12-29 18:20:06 <roconnor> sipa: this is my "second" bug found ... not that I knew it was a bug
 725 2011-12-29 18:20:12 copumpkin has quit (Read error: Operation timed out)
 726 2011-12-29 18:20:18 <roconnor> sipa: cause I have no idea what OP_EVAL is supposed to be exactly
 727 2011-12-29 18:21:13 <roconnor> sipa: what gavin writes in that comment suggests he is going to enable spaning of IF statments accross OP_EVAL block
 728 2011-12-29 18:21:25 <roconnor> sipa: which I think will literally make my head explode if he does that.
 729 2011-12-29 18:22:40 <sipa> hmm, i don't read that there
 730 2011-12-29 18:22:50 <roconnor> ``clearing the alt stack and the fExec state are bugs, because the BIP doesn't say they should be cleared.
 731 2011-12-29 18:23:24 <roconnor> I admit it isn't entirely clear what he means
 732 2011-12-29 18:23:31 <sipa> right, fExec is for if/then/else constructs?
 733 2011-12-29 18:23:35 <roconnor> so there is hope for my head to remain intact
 734 2011-12-29 18:23:39 <roconnor> yep
 735 2011-12-29 18:24:37 copumpkin has joined
 736 2011-12-29 18:24:44 <roconnor> if IF statements span OP_EVAL blocks I will have suceeded in making the OP_EVAL proposal even worse than when I started.
 737 2011-12-29 18:26:10 <roconnor> sipa: thinking about the implications of this is what started me thinking about OP_GOTO
 738 2011-12-29 18:26:39 <roconnor> OP_EVAL is sort of like a subroutine call
 739 2011-12-29 18:26:57 <roconnor> and having if statement span subroutines is the antithesis of structured programming
 740 2011-12-29 18:27:01 <TD> hmm
 741 2011-12-29 18:27:04 <TD> en.bitcoin.it is gone ?
 742 2011-12-29 18:27:10 <roconnor> of course you guys say the scripts are short code so who cares.
 743 2011-12-29 18:27:16 <TD> looks like mtgox is getting DoSd again ?
 744 2011-12-29 18:27:41 copumpkin is now known as [\|-\{}]
 745 2011-12-29 18:27:46 <roconnor> TD: it's been down for at least a few hours
 746 2011-12-29 18:27:48 <jgarzik> TD: en.bitcoin.it DNS confirmed MIA
 747 2011-12-29 18:27:54 <roconnor> oh
 748 2011-12-29 18:27:59 <TD> oh dear
 749 2011-12-29 18:28:01 <TD> he let it expire
 750 2011-12-29 18:28:02 <roconnor> SOPA?
 751 2011-12-29 18:28:02 <jgarzik> nxdomain
 752 2011-12-29 18:28:07 <TD> Domain:             bitcoin.it
 753 2011-12-29 18:28:07 <TD> Status:             pendingDelete / redemptionPeriod
 754 2011-12-29 18:28:21 <TD> Created:            2010-12-01 10:15:11
 755 2011-12-29 18:28:21 <TD> Last Update:        2011-12-29 14:13:56
 756 2011-12-29 18:28:21 <TD> Expire Date:        2012-12-01
 757 2011-12-29 18:28:25 <TD> so i guess it'll be back soon
 758 2011-12-29 18:28:26 <gmaxwell> ...
 759 2011-12-29 18:28:32 <gmaxwell> back soon, as a pornspam site?
 760 2011-12-29 18:35:37 [\\\] is now known as [----]
 761 2011-12-29 18:36:50 [\ is now known as -\{}]!~pumpkin@unaffiliated/pumpkingod|copumpkin
 762 2011-12-29 18:37:36 [----] is now known as [|]
 763 2011-12-29 18:37:49 [ is now known as ]!~nick@unaffiliated/imsaguy|[\\\]
 764 2011-12-29 18:39:02 jgarzik has quit (Quit: Client exiting)
 765 2011-12-29 18:39:57 pumpkin has joined
 766 2011-12-29 18:39:59 pumpkin has quit (Changing host)
 767 2011-12-29 18:39:59 pumpkin has joined
 768 2011-12-29 18:40:03 <[Tycho]> Hmm, looks like it's time to create a strange TX using altstack and IFs :)
 769 2011-12-29 18:42:07 copumpkin has quit (Ping timeout: 252 seconds)
 770 2011-12-29 18:43:44 Aexoden has quit (Read error: Operation timed out)
 771 2011-12-29 18:43:44 dub has quit (Read error: Operation timed out)
 772 2011-12-29 18:44:09 Aexoden has joined
 773 2011-12-29 18:46:06 <roconnor> is OP_EVAL enabled on testnet?
 774 2011-12-29 18:46:10 HaltingState has joined
 775 2011-12-29 18:46:10 HaltingState has quit (Changing host)
 776 2011-12-29 18:46:11 HaltingState has joined
 777 2011-12-29 18:46:28 <roconnor> If not, why aren't we doing it on testnet first?
 778 2011-12-29 18:47:06 [\\\] is now known as imsaguy
 779 2011-12-29 18:48:49 dub has joined
 780 2011-12-29 18:49:55 Diablo-D3 has joined
 781 2011-12-29 18:50:07 <[Tycho]> May be because it's not as much fun as the main net ?
 782 2011-12-29 18:50:16 <roconnor> lol
 783 2011-12-29 18:50:46 <TD> hah
 784 2011-12-29 18:50:54 <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.
 785 2011-12-29 18:51:16 <roconnor> gmaxwell: so there are OP_EVAL uses on testnet?
 786 2011-12-29 18:51:20 <gmaxwell> (by pool I mean a base of miners, I don't mean a mining pool in the normal way, sorry)
 787 2011-12-29 18:51:31 luke-jr has quit (Excess Flood)
 788 2011-12-29 18:51:43 <roconnor> I guess without 50% of the testnet mining, it is pretty hard
 789 2011-12-29 18:51:54 luke-jr has joined
 790 2011-12-29 18:52:01 <sipa> gmaxwell: pretty nice idea, that push-only stack
 791 2011-12-29 18:52:31 <roconnor> a stack isn't a stack without pop :D
 792 2011-12-29 18:52:36 <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. :)
 793 2011-12-29 18:52:49 <sipa> i'm typing a mail
 794 2011-12-29 18:52:51 <roconnor> but ya, no arithmetic is good.
 795 2011-12-29 18:53:29 <roconnor> and so is putting the code right next to the OP_EVAL
 796 2011-12-29 18:53:42 <roconnor> but I don't think that happens in the proposed standard transactions
 797 2011-12-29 18:53:57 <roconnor> and we would need another command to push to this new stack
 798 2011-12-29 18:54:27 iocor has quit (Ping timeout: 244 seconds)
 799 2011-12-29 18:54:30 <gmaxwell> roconnor: just make the normal pushes all push to it.
 800 2011-12-29 18:54:36 <sipa> exactly
 801 2011-12-29 18:54:59 xtor_ has joined
 802 2011-12-29 18:55:13 rdponticelli has joined
 803 2011-12-29 18:55:33 iocor has joined
 804 2011-12-29 18:56:13 extor has quit (Ping timeout: 252 seconds)
 805 2011-12-29 18:56:20 DontMindMe has quit (Read error: Connection reset by peer)
 806 2011-12-29 18:56:43 DontMindMe has joined
 807 2011-12-29 19:01:24 rdponticelli_ has joined
 808 2011-12-29 19:02:17 rdponticelli has quit (Ping timeout: 268 seconds)
 809 2011-12-29 19:04:39 pirateat40 has joined
 810 2011-12-29 19:06:16 pumpkin is now known as copumpkin
 811 2011-12-29 19:08:06 theorbtwo has joined
 812 2011-12-29 19:08:19 theorb has quit (Ping timeout: 252 seconds)
 813 2011-12-29 19:09:49 <copumpkin> lol
 814 2011-12-29 19:10:00 <copumpkin> the bitcoin.it domain expired, or so someone on reddit says
 815 2011-12-29 19:10:24 <pirateat40> good times
 816 2011-12-29 19:12:11 <gmaxwell> copumpkin: welcome to several hours ago
 817 2011-12-29 19:12:22 <copumpkin> thanks!
 818 2011-12-29 19:12:46 <sipa> roconnor: proposal mailed :)
 819 2011-12-29 19:14:24 <copumpkin> a proposal mailed is a proposal failed
 820 2011-12-29 19:14:55 <sipa> possibly
 821 2011-12-29 19:16:07 <TD> haha
 822 2011-12-29 19:16:11 <TD> good slogan
 823 2011-12-29 19:20:48 xtor_ has quit (Ping timeout: 255 seconds)
 824 2011-12-29 19:21:15 extor has joined
 825 2011-12-29 19:26:20 predator has quit (Ping timeout: 268 seconds)
 826 2011-12-29 19:27:03 <luke-jr> copumpkin: easily verified :P
 827 2011-12-29 19:29:36 danbri has quit (Read error: Connection reset by peer)
 828 2011-12-29 19:33:15 danbri has joined
 829 2011-12-29 19:37:33 danbri has quit (Read error: Connection reset by peer)
 830 2011-12-29 19:39:12 theorb has joined
 831 2011-12-29 19:40:40 theorbtwo has quit (Ping timeout: 240 seconds)
 832 2011-12-29 19:42:04 <roconnor> sipa: darn.  My first attempt at implementing the SK calculus with unlimited OP_EVAL has failed :(
 833 2011-12-29 19:42:17 <roconnor> sipa: I need OP_CONCAT or something like that :(
 834 2011-12-29 19:42:29 Wizzleby has quit (Remote host closed the connection)
 835 2011-12-29 19:42:40 <sipa> OP_CAT ?
 836 2011-12-29 19:42:48 jacobwg has joined
 837 2011-12-29 19:42:50 <roconnor> ya
 838 2011-12-29 19:43:05 <roconnor> even then I'm not sure I could do it this way
 839 2011-12-29 19:43:14 <sipa> OP_CAT exists (but is disabled)
 840 2011-12-29 19:43:20 <roconnor> ya
 841 2011-12-29 19:43:55 <sipa> so...?
 842 2011-12-29 19:44:10 <roconnor> well I don't want to use disabled operations
 843 2011-12-29 19:44:50 cosurgi has quit (Read error: Operation timed out)
 844 2011-12-29 19:46:49 danbri has joined
 845 2011-12-29 19:47:18 <roconnor> sipa: I need to pop x and y off the stack and push {OP_PUSHDATA x; y}
 846 2011-12-29 19:47:21 <roconnor> :(
 847 2011-12-29 19:47:31 <sipa> hmm?
 848 2011-12-29 19:47:46 <roconnor> that said maybe there are other ways to proceed
 849 2011-12-29 19:48:01 predator has joined
 850 2011-12-29 19:50:27 jacobwg has quit (Quit: Textual IRC Client: http://www.textualapp.com/)
 851 2011-12-29 19:52:44 predator is now known as antix
 852 2011-12-29 20:02:05 minimoose has joined
 853 2011-12-29 20:08:09 Turingi has quit (Read error: Connection reset by peer)
 854 2011-12-29 20:23:22 RazielZ has quit (Read error: Operation timed out)
 855 2011-12-29 20:30:10 gavinandresen has joined
 856 2011-12-29 20:33:23 <gavinandresen> Howdy y'all.
 857 2011-12-29 20:33:31 <[Tycho]> Hello, gavinandresen.
 858 2011-12-29 20:33:53 TD has quit (Quit: TD)
 859 2011-12-29 20:34:36 iocor has quit (Quit: Computer has gone to sleep.)
 860 2011-12-29 20:34:55 <gavinandresen> roconnor: you're right, the 'if state' shouldn't percolate down into OP_EVAL (but the altstack should).
 861 2011-12-29 20:35:23 <gavinandresen> sipa:  interesting proposal, the only downside is we lose the "old clients half-validate"
 862 2011-12-29 20:35:57 <sipa> hmm, right; hadn't thought about that
 863 2011-12-29 20:36:16 <sipa> i'm actually pondering about the alt stack
 864 2011-12-29 20:36:43 <sipa> if that isn't inherited, a main script could control which data gets passed to subscripts
 865 2011-12-29 20:36:51 <sipa> by hiding it in the altstack
 866 2011-12-29 20:38:09 <gavinandresen> Interesting...
 867 2011-12-29 20:38:29 <gavinandresen> Well, it is either a bug in the BIP or a bug in the code
 868 2011-12-29 20:39:09 wasabi has joined
 869 2011-12-29 20:39:16 <sipa> I do feel much more confident with execution state of the inner script being independent, though
 870 2011-12-29 20:41:14 <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.
 871 2011-12-29 20:41:31 wasabi2 has quit (Ping timeout: 240 seconds)
 872 2011-12-29 20:48:47 Maroni has quit (Ping timeout: 255 seconds)
 873 2011-12-29 20:49:32 slush has joined
 874 2011-12-29 20:49:42 <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
 875 2011-12-29 20:49:47 <sipa> and do the checking as usual
 876 2011-12-29 20:50:21 <sipa> <scriptHash> OP_EVAL OP_HASH160 OP_EQUALVERIFY, e.g.
 877 2011-12-29 20:51:03 <sipa> so OP_EVAL uses the code-position wise last literal, and OP_HASH160 uses its value pushed on the normal stack
 878 2011-12-29 20:51:06 <gavinandresen> ... EQUALVERIFY OP_1   (you have to leave a true value on the stack)
 879 2011-12-29 20:51:29 <sipa> just OP_EQUAL then
 880 2011-12-29 20:51:47 <gavinandresen> .... good idea
 881 2011-12-29 20:52:03 <sipa> why didn't this discussion happen 3 months ago...
 882 2011-12-29 20:52:06 <gavinandresen> I think I like that.
 883 2011-12-29 20:52:20 <gavinandresen> Because deadlines make people pay attention
 884 2011-12-29 20:52:36 <sipa> so it seems
 885 2011-12-29 20:53:03 * luke-jr notes that only OP_EVAL allows future extension without blockchain forking…
 886 2011-12-29 20:53:21 <sipa> luke-jr: the above idea also does
 887 2011-12-29 20:53:26 <luke-jr> sipa: it does? cool
 888 2011-12-29 20:53:32 <luke-jr> sipa: without new addresses, too?
 889 2011-12-29 20:53:34 <sipa> it's really just a more restricted OP_EVAL
 890 2011-12-29 20:55:47 <gavinandresen> I particularly like the "OP_EVAL is a no-op for by construction"
 891 2011-12-29 20:56:04 <gavinandresen> ^for^^
 892 2011-12-29 20:58:37 danbri has quit (Read error: Connection reset by peer)
 893 2011-12-29 20:59:25 <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?
 894 2011-12-29 20:59:37 Fnar has quit (Ping timeout: 252 seconds)
 895 2011-12-29 21:00:04 <gavinandresen> After all, we already have to deal with possibly-calculated CHECKMULTISIG arguments
 896 2011-12-29 21:01:07 RazielZ has joined
 897 2011-12-29 21:01:47 BlueMatt has joined
 898 2011-12-29 21:03:32 <gmaxwell> roconnor: ^ ? If anyone is going to say yes to 'static analysis of arbitrary code' it's you.
 899 2011-12-29 21:04:04 <sipa> it's not actually a stack (though you can implement it using one)
 900 2011-12-29 21:04:33 <sipa> it's really just looking back at the last not-yet-executed literal pushed
 901 2011-12-29 21:04:48 erle- has joined
 902 2011-12-29 21:05:06 Fnar has joined
 903 2011-12-29 21:05:27 <sipa> gavinandresen: and it does allow you to for example parse a script in advance and deserialize it, before execution
 904 2011-12-29 21:05:40 danbri has joined
 905 2011-12-29 21:05:57 iocor has joined
 906 2011-12-29 21:07:08 <gavinandresen> sipa:  yes, but my point is if you're using nothing but 'standard' transactions then you'll be able to do that anyway.
 907 2011-12-29 21:07:11 JZavala has quit (Ping timeout: 240 seconds)
 908 2011-12-29 21:08:10 <sipa> if we only allow standard transaction, a simple transaction_type enum would suffice, instead of a script language :)
 909 2011-12-29 21:08:22 <gavinandresen> sipa:  that would have been my preference :)
 910 2011-12-29 21:08:32 <BlueMatt> then do that
 911 2011-12-29 21:08:39 <gmaxwell> you guys are super unfun.
 912 2011-12-29 21:08:41 <BlueMatt> (for OP_EVAL)
 913 2011-12-29 21:08:51 <sipa> that would spoil the fun
 914 2011-12-29 21:10:06 <gmaxwell> meh, the scripts are useful and allow good arguments about the security properties.
 915 2011-12-29 21:10:17 <BlueMatt> heh
 916 2011-12-29 21:11:25 <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.
 917 2011-12-29 21:11:39 Joric has joined
 918 2011-12-29 21:11:41 <gmaxwell> Without scripts I wouldn't have been able to do that— any such fix would require flagdaying the network.
 919 2011-12-29 21:11:57 <gavinandresen> Yup, they are darn useful for backwards-compatible changes
 920 2011-12-29 21:11:57 Fnar has quit (Ping timeout: 255 seconds)
 921 2011-12-29 21:12:37 <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)
 922 2011-12-29 21:14:39 <roconnor> sipa: it isn't "last code-position wise literal", it is "last code-execution wise literal" due to the presence of OP_IF
 923 2011-12-29 21:15:02 <roconnor> sipa: I didn't have this conversation 2/3 months ago because it wasn't chirstmas break then.
 924 2011-12-29 21:15:09 <roconnor> and I have a day job
 925 2011-12-29 21:15:38 <sipa> roconnor: i explicitly mean the previous push in the code, even if it wasn't executed
 926 2011-12-29 21:15:59 <sipa> wait
 927 2011-12-29 21:16:10 <sipa> that would be very bad
 928 2011-12-29 21:17:42 <sipa> that would allow someone to do a "<script satisfying required hash> 0 OP_IF <evil script> OP_ENDIF"
 929 2011-12-29 21:17:50 <sipa> bah
 930 2011-12-29 21:18:13 TD has joined
 931 2011-12-29 21:18:25 Fnar has joined
 932 2011-12-29 21:18:58 <roconnor> yes it would be very bad
 933 2011-12-29 21:19:34 <roconnor> sipa: sorry, I had considered this sort of thing when thinking about my proposal
 934 2011-12-29 21:20:03 <sipa> yes, so did i when i wrote the first one
 935 2011-12-29 21:20:19 <sipa> but seem to have forgotten about when writing the update
 936 2011-12-29 21:20:41 Joric has quit (Ping timeout: 240 seconds)
 937 2011-12-29 21:26:34 booo has joined
 938 2011-12-29 21:27:07 Joric has joined
 939 2011-12-29 21:27:07 Joric has quit (Changing host)
 940 2011-12-29 21:27:07 Joric has joined
 941 2011-12-29 21:30:04 <helo> so this may be going live in ~1 month?
 942 2011-12-29 21:31:42 Cory has joined
 943 2011-12-29 21:32:22 <gavinandresen> The only thing possibly going live in 1-month is the un-modified original OP_EVAL proposal.
 944 2011-12-29 21:32:42 <gavinandresen> ... if the general consensus is that the proposal should be modified, then the schedule will be pushed.
 945 2011-12-29 21:37:45 <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.
 946 2011-12-29 21:40:04 <gavinandresen> roconnor: ok
 947 2011-12-29 21:40:17 <helo> sounds like a viable way to establish general consensus
 948 2011-12-29 21:40:46 <gmaxwell> helo: not really.
 949 2011-12-29 21:41:02 <gavinandresen> what sounds like a viable way?  99.999% of bitcoin using people will have no idea what we're talking about
 950 2011-12-29 21:41:56 <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"
 951 2011-12-29 21:42:01 <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)
 952 2011-12-29 21:42:06 <Diablo-D3> wait
 953 2011-12-29 21:42:06 <Diablo-D3> what?
 954 2011-12-29 21:42:08 <Diablo-D3> first of all
 955 2011-12-29 21:42:10 <Diablo-D3> any journalist
 956 2011-12-29 21:42:12 <Diablo-D3> that prints
 957 2011-12-29 21:42:13 <Diablo-D3> the words
 958 2011-12-29 21:42:18 <Diablo-D3> "bitcoin community" is a bold faced liar
 959 2011-12-29 21:42:21 <Diablo-D3> theres no such thing
 960 2011-12-29 21:42:22 <roconnor> gavinandresen: ya, I know :(
 961 2011-12-29 21:42:31 <Diablo-D3> its a group of ten people, ten people does not form a community
 962 2011-12-29 21:43:18 <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).
 963 2011-12-29 21:43:39 <roconnor> gmaxwell: I know :(
 964 2011-12-29 21:43:56 <Diablo-D3> gmaxwell: man
 965 2011-12-29 21:44:02 <Diablo-D3> a journalist should pick up that thread
 966 2011-12-29 21:44:11 <Diablo-D3> "bitcoin community turns on founding member"
 967 2011-12-29 21:44:12 <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)
 968 2011-12-29 21:44:24 <copumpkin> gavinandresen: the other option is to just delay it and figure out the issues?
 969 2011-12-29 21:44:31 <copumpkin> so no journalist schism bullshit
 970 2011-12-29 21:44:38 devrandom has quit (Remote host closed the connection)
 971 2011-12-29 21:44:38 <copumpkin> no bad op_eval unexpected problems
 972 2011-12-29 21:44:47 <copumpkin> and unicorns and rainbows
 973 2011-12-29 21:45:17 <[eval]> "major schism in bitcoin commuinty" = good for those of us trying to buy more coins on the cheap :D
 974 2011-12-29 21:45:23 <copumpkin> lol
 975 2011-12-29 21:45:42 <gmaxwell> [eval]: you can't predict that.
 976 2011-12-29 21:45:57 <[eval]> gmaxwell: i know... i was mostly kidding.
 977 2011-12-29 21:46:02 <gmaxwell> [eval]: "major schism in bitcoin commuinty" may equal, "omg bitcoin undervalued because of bad press, buy buy buy"
 978 2011-12-29 21:46:07 b4epoche_ has joined
 979 2011-12-29 21:46:17 <copumpkin> gmaxwell: you can't explain that
 980 2011-12-29 21:46:21 <copumpkin> just like tides
 981 2011-12-29 21:46:40 <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"
 982 2011-12-29 21:46:41 devrandom has joined
 983 2011-12-29 21:46:58 b4epoche has quit (Ping timeout: 240 seconds)
 984 2011-12-29 21:46:59 b4epoche_ is now known as b4epoche
 985 2011-12-29 21:47:19 <gavinandresen> sipa:  scriptSig would be   <sigs> <script>   scriptPubKey would be:  EVAL HASH160 <> EQUAL
 986 2011-12-29 21:47:27 <gavinandresen> (EVAL would just execute, not consume)
 987 2011-12-29 21:47:36 <sipa> gavinandresen: thatś possible, but precludes multiple OP_EVAL's
 988 2011-12-29 21:48:26 <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
 989 2011-12-29 21:48:46 <sipa> but that feels dirty
 990 2011-12-29 21:49:43 <copumpkin> damn stack languages, always complicating things
 991 2011-12-29 21:50:21 <luke-jr> can we switch to MIPS yet?
 992 2011-12-29 21:50:45 <roconnor> MIPS?
 993 2011-12-29 21:50:57 <sipa> i vote INTERCAL
 994 2011-12-29 21:51:17 <gmaxwell> COME FROM FTW.
 995 2011-12-29 21:53:35 ByteCoin2 has joined
 996 2011-12-29 21:54:01 <ByteCoin2> ping Gavin
 997 2011-12-29 21:54:10 <sipa> hello ByteCoin2
 998 2011-12-29 21:54:21 <gavinandresen> howdy ByteCoin2
 999 2011-12-29 21:54:30 <ByteCoin2> Ok so there's some push back against OP_EVAL
1000 2011-12-29 21:55:01 <ByteCoin2> Just out of interest.. what's so bad about evaluating as scripts the result of calculations?
1001 2011-12-29 21:55:02 <roconnor> ByteCoin2: it might be just me.
1002 2011-12-29 21:55:03 <gavinandresen> roconnor hates it.  TD doesn't like spend-to-script addresses in general....
1003 2011-12-29 21:55:19 <ByteCoin2> And what's so good about static analysis?
1004 2011-12-29 21:55:29 <TD> specifically, it's changing Script that i'm uneasy about
1005 2011-12-29 21:55:39 <TD> spend-to-script would be fine if the address contained the actual script
1006 2011-12-29 21:56:03 <gavinandresen> (I sit corrected, thanks TD)
1007 2011-12-29 21:56:27 <ByteCoin2> Aren't we a little far down the line?
1008 2011-12-29 21:56:41 <ByteCoin2> There's nothing in the proposal that's broken
1009 2011-12-29 21:56:45 <roconnor> static analysis lets you do all sorts of great things potentially: gathering statics, byte-code compilation, who knows.
1010 2011-12-29 21:57:04 <ByteCoin2> Precisely... who knows?
1011 2011-12-29 21:57:17 <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
1012 2011-12-29 21:57:20 <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.
1013 2011-12-29 21:57:32 <sipa> the fact that it is possible is kind of a proof of a clean language semantics
1014 2011-12-29 21:57:55 <roconnor> ByteCoin2: AFAIU we are not too far down the line until Jan 15th
1015 2011-12-29 21:58:05 <copumpkin> I mean, you guys all set the timelines anyway
1016 2011-12-29 21:58:07 <gmaxwell> More concretely it allows you to make fairly tight statements about the computational complexity of a script without actually executing it.
1017 2011-12-29 21:58:09 <ByteCoin2> sipa: What? So the fact that static analysis is possible is proof of clean language semantics?
1018 2011-12-29 21:58:15 <copumpkin> it seems weird to present them as some unstoppable train
1019 2011-12-29 21:58:22 <sipa> proof is the wrong word
1020 2011-12-29 21:58:44 <ByteCoin2> gmaxwell: That might be a concern if your talking about thousands of lines of source code..
1021 2011-12-29 21:59:04 <ByteCoin2> I believe it will take longer to statically analyse a script than to execute it
1022 2011-12-29 21:59:08 <sipa> we are... spread over millions of small programs
1023 2011-12-29 21:59:35 <ByteCoin2> Identical programs adhering to specific IsStandard rules
1024 2011-12-29 21:59:47 <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.
1025 2011-12-29 22:00:02 <sipa> agree with gmaxwell here
1026 2011-12-29 22:00:04 <gmaxwell> ByteCoin2: the scripts in the chain can't be subject to IsStandard, of course.
1027 2011-12-29 22:01:23 larsa has quit (Ping timeout: 252 seconds)
1028 2011-12-29 22:01:24 <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.
1029 2011-12-29 22:02:02 <Diablo-D3> gmaxwell: wait wait wait
1030 2011-12-29 22:02:03 <roconnor> gavinandresen: when the wiki is back you, you should describe how OP_EVAL interact with OP_IF on the BIP page.
1031 2011-12-29 22:02:03 <Diablo-D3> hold up
1032 2011-12-29 22:02:30 <roconnor> ie, all OP_IFs must be closed off before ending the OP_EVAL'd script
1033 2011-12-29 22:02:37 <ByteCoin2> I've read the new proposal and I couldn't follow how it all works on the stack
1034 2011-12-29 22:02:37 <ByteCoin2> It'd  be nice if it was spelled out a bit more explicitly
1035 2011-12-29 22:02:37 <ByteCoin2> Also. Didn't we agree that OP_CODESEPARATOR is something none of us understand?
1036 2011-12-29 22:02:43 larsa has joined
1037 2011-12-29 22:03:05 <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)
1038 2011-12-29 22:03:27 <sipa> I hope we won't need IsStandard anymore some time in the future.
1039 2011-12-29 22:03:31 <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.
1040 2011-12-29 22:03:55 <copumpkin> o.O
1041 2011-12-29 22:04:13 <ByteCoin2> Basically, I'm hearing that OP_EVAL is "too expressive". Isn't that a good thing?
1042 2011-12-29 22:04:17 <gmaxwell> Diablo-D3: and when ron paul raises and issue that can be costlessly corrected, it happens. ::shrugs::
1043 2011-12-29 22:04:18 <copumpkin> no
1044 2011-12-29 22:04:30 <copumpkin> ByteCoin2: in PL circles, we try to avoid "too expressive" with barge poles ;)
1045 2011-12-29 22:04:45 <ByteCoin2> Rubbish
1046 2011-12-29 22:04:47 <copumpkin> being turing complete is way easier than designing something that is tastefully not
1047 2011-12-29 22:04:52 <copumpkin> no it isn't
1048 2011-12-29 22:04:54 <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.
1049 2011-12-29 22:04:55 devrandom has quit (Ping timeout: 276 seconds)
1050 2011-12-29 22:04:56 <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?
1051 2011-12-29 22:05:07 <Diablo-D3> what if it was OP_JPG?
1052 2011-12-29 22:05:12 <Diablo-D3> LOLCHILDPORNS
1053 2011-12-29 22:05:18 <copumpkin> OP_EXPLOITABLETIFF
1054 2011-12-29 22:05:18 <ByteCoin2> Language design is always moving towards more expressive constructions
1055 2011-12-29 22:05:26 <roconnor> sipa: espeically since bitcoin only runs on x86 right now ;)
1056 2011-12-29 22:05:28 <Diablo-D3> "breaking news: this just in, running bitcoin can get you raped by the FBI"
1057 2011-12-29 22:05:39 <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.
1058 2011-12-29 22:05:43 <copumpkin> ByteCoin2: we already hit the peak in computing power back when we figured out what turing machines did
1059 2011-12-29 22:05:49 <copumpkin> ByteCoin2: should we give up on language design?
1060 2011-12-29 22:05:55 <ByteCoin2> Ok gmaxwell puts your point better
1061 2011-12-29 22:06:01 <Diablo-D3> after lisp? yes.
1062 2011-12-29 22:06:06 <copumpkin> lol
1063 2011-12-29 22:06:22 <roconnor> we are talking about expressiveness in a different sense than languages that are already turing complete.
1064 2011-12-29 22:06:59 <ByteCoin2> But it will take longer to reason about the execution of the script than  actually executing it!
1065 2011-12-29 22:07:02 <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
1066 2011-12-29 22:07:08 <roconnor> but, ya, where copumpkin and I come from, turing completeness is bad.
1067 2011-12-29 22:07:16 <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.
1068 2011-12-29 22:07:53 <ByteCoin2> Why on earth would you want to compile bitcoin script to x86?
1069 2011-12-29 22:07:58 <gavinandresen> I thought we all agreed that our limited-recursion, limited-opcount expression evaluation language is not turing complete.
1070 2011-12-29 22:08:03 <copumpkin> ByteCoin2: it was a joke point :P
1071 2011-12-29 22:08:12 <gmaxwell> gavinandresen: yes, though by the same argument your computer isn't either.
1072 2011-12-29 22:08:18 <roconnor> gavinandresen: well, my laptop isn't turing complete either
1073 2011-12-29 22:08:27 <copumpkin> gavinandresen: some would argue limited-recursion isn't a feature of the language as much as one of the interpreter
1074 2011-12-29 22:08:28 <ByteCoin2> I'm all for jokes but could we perhaps talk about this seriously for a bit?
1075 2011-12-29 22:08:38 <copumpkin> and that thus, abstractly, the language is still too powerful
1076 2011-12-29 22:09:05 <ByteCoin2> So what's so bad about the "extra" power?
1077 2011-12-29 22:09:06 <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?
1078 2011-12-29 22:09:09 <gmaxwell> (thats the argument, personally I agree that the limitations are adequate— the stand against turing complete here is principled not pratical)
1079 2011-12-29 22:09:13 <copumpkin> ByteCoin2: rice's theorem, etc.
1080 2011-12-29 22:09:21 <gavinandresen> We could argue angels-on-the-head-of-a-pin all year and get nowhere
1081 2011-12-29 22:09:36 <copumpkin> I think all he's arguing is to delay it
1082 2011-12-29 22:09:49 <copumpkin> so people who care about this kind of stuff can take a closer look
1083 2011-12-29 22:09:58 <roconnor> gavinandresen: I don't know if there is a problem in practice or not; nobody knows.
1084 2011-12-29 22:10:06 <ByteCoin2> IN PRACTICE, there seems no reason not to believe that OP_EVAL is ok
1085 2011-12-29 22:10:09 <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)
1086 2011-12-29 22:10:29 <gmaxwell> ByteCoin2: the in practice objection is that the software is not sufficiently mature.
1087 2011-12-29 22:10:37 <gavinandresen> roconnor: nobody has proven that the existing Script has no problems, either, and yet we use it.
1088 2011-12-29 22:10:38 <ByteCoin2> This would have been much more interesting had it all happened 4 months ago!
1089 2011-12-29 22:10:43 <gmaxwell> ByteCoin2: and rconner proved that by just finding a _severe_ bug in gavin's code a few days ago.
1090 2011-12-29 22:11:04 <ByteCoin2> There have been other more severe bugs like int64 wrapping
1091 2011-12-29 22:11:19 <gavinandresen> ... or the OP_RETURN bug...
1092 2011-12-29 22:11:23 <ByteCoin2> I don't think the project should get too ossified at this stage
1093 2011-12-29 22:11:23 <sipa> at a time when the bitcoin economy wasn't worth millions
1094 2011-12-29 22:11:31 devrandom has joined
1095 2011-12-29 22:11:35 <ByteCoin2> Paper millions
1096 2011-12-29 22:11:36 <copumpkin> well, let's put this differently
1097 2011-12-29 22:11:40 <copumpkin> what are the downsides to delaying it?
1098 2011-12-29 22:11:50 <gmaxwell> For all those millions you'd think that someone might actually fund some more of this validation work…
1099 2011-12-29 22:11:56 <ByteCoin2> Precisely
1100 2011-12-29 22:11:58 <copumpkin> gmaxwell: pfft
1101 2011-12-29 22:12:00 <sipa> gmaxwell: yeah...
1102 2011-12-29 22:12:10 <roconnor> gavinandresen: well that's why I was arguing we should understand the existing scripting system first.
1103 2011-12-29 22:12:26 <ByteCoin2> We can delay the client implementation until the bugs are ironed out completely
1104 2011-12-29 22:12:35 <copumpkin> ByteCoin2: nobody's even arguing that
1105 2011-12-29 22:12:44 <ByteCoin2> Let's get it into the rest of the network
1106 2011-12-29 22:12:46 <copumpkin> that's just misrepresenting your opponent's position :P
1107 2011-12-29 22:12:55 <ByteCoin2> It'll take ages for non-supporting clients to die out
1108 2011-12-29 22:13:08 <copumpkin> I just don't see what the rush is
1109 2011-12-29 22:13:13 imsaguy is now known as [\\\]
1110 2011-12-29 22:13:29 <ByteCoin2> By that reasoning there's no problem slipping any deadline forever
1111 2011-12-29 22:13:46 <ByteCoin2> The thing is. There was a deadline. It was well known. We should meet it.
1112 2011-12-29 22:13:49 <gmaxwell> copumpkin: presuming that the installed base of bitcoin grows, every day delay translates into more than a day of real delay on average.
1113 2011-12-29 22:13:51 molecular has quit (Quit: Leaving)
1114 2011-12-29 22:14:06 <copumpkin> ByteCoin2: a deadline people in this room set
1115 2011-12-29 22:14:11 <copumpkin> who's it benefitting?
1116 2011-12-29 22:14:15 <gmaxwell> copumpkin: there aren't any other people to set one!
1117 2011-12-29 22:14:21 <ByteCoin2> We have a process.
1118 2011-12-29 22:14:23 <copumpkin> and there's nobody else who cares
1119 2011-12-29 22:14:26 <ByteCoin2> We should stick to it
1120 2011-12-29 22:14:29 <copumpkin> why?
1121 2011-12-29 22:14:46 <gavinandresen> Consistency builds trust
1122 2011-12-29 22:14:47 <gmaxwell> Gah, there are already frequent delays about the development process being ossified. Where are you arguing against this when they come up?
1123 2011-12-29 22:15:02 <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
1124 2011-12-29 22:15:04 <copumpkin> gavinandresen: trust that you'll rush to honor deadlines despite significant objections?
1125 2011-12-29 22:15:25 * copumpkin shrugs
1126 2011-12-29 22:15:41 <gmaxwell> copumpkin: be fair, 12th hour objections without concretely articulated pratical implications.
1127 2011-12-29 22:15:52 <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?
1128 2011-12-29 22:16:11 <ByteCoin2> gmaxwell. You express my thoughts much better than I do - again!
1129 2011-12-29 22:16:18 <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.
1130 2011-12-29 22:16:25 <ByteCoin2> Not at all
1131 2011-12-29 22:16:31 <ByteCoin2> This is why we need testing
1132 2011-12-29 22:16:36 <gmaxwell> Well, I'm kinda arguing both sides here, because I'm completely sympathetic to both perspecties.
1133 2011-12-29 22:16:42 <gmaxwell> er perspecitives.
1134 2011-12-29 22:16:42 <copumpkin> ByteCoin2: testing finds bugs in implementation, not in design
1135 2011-12-29 22:17:00 <ByteCoin2> copumpkin; Can't it find both?
1136 2011-12-29 22:17:01 <slush> I have stupid question. How can I validate ecdsa-signed data when I have only bitcoin address (which is hash of pubkey)...?
1137 2011-12-29 22:17:04 bitcoin_ro has joined
1138 2011-12-29 22:17:14 <sipa> slush: you can't
1139 2011-12-29 22:17:15 <roconnor> slush: you cannot
1140 2011-12-29 22:17:20 <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
1141 2011-12-29 22:17:22 <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.
1142 2011-12-29 22:17:32 <gmaxwell> (I've seen many wikipedians flame out for that very reason)
1143 2011-12-29 22:17:53 _W_ has quit (Ping timeout: 252 seconds)
1144 2011-12-29 22:18:00 <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)
1145 2011-12-29 22:18:02 <roconnor> gmaxwell: ya I understand that;  Everytime I see an error I get mad at wikipedia, fix it, and realize that it does work!
1146 2011-12-29 22:18:12 <roconnor> but this is a bit different IMHO
1147 2011-12-29 22:18:31 <roconnor> any bugs in the Protocol more or less become perminent
1148 2011-12-29 22:18:46 <roconnor> like timejacking and that extra pop in CHECKMULTISIG
1149 2011-12-29 22:18:46 <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
1150 2011-12-29 22:18:54 <copumpkin> but it isn't an actual counter-argument to roconnor's point
1151 2011-12-29 22:19:06 <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
1152 2011-12-29 22:19:21 <ByteCoin2> How about we stick to the plan until something more concrete comes up
1153 2011-12-29 22:19:23 <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?
1154 2011-12-29 22:19:24 <ByteCoin2> ?
1155 2011-12-29 22:19:28 * copumpkin throws up hands
1156 2011-12-29 22:19:40 <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"
1157 2011-12-29 22:19:48 <copumpkin> "oconnor is arguing that _we don't fully understand_ what we're creating with OP_EVAL, and wants to understand it better"
1158 2011-12-29 22:19:59 <copumpkin> "how about we stick to the plan until something more concrete comes up"
1159 2011-12-29 22:20:02 <copumpkin> cross-purposes
1160 2011-12-29 22:20:24 <ByteCoin2> copumpkin: I'm very sympathetic to that point of view. But let's not throw OP_EVAL out for no concrete reason
1161 2011-12-29 22:20:31 <copumpkin> he's not suggesting throwing it out
1162 2011-12-29 22:20:31 <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.
1163 2011-12-29 22:20:41 <copumpkin> he just wants to think about it more :P
1164 2011-12-29 22:20:46 <copumpkin> gmaxwell: hah, okay, yep :)
1165 2011-12-29 22:20:50 <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.
1166 2011-12-29 22:20:53 dub has quit (Changing host)
1167 2011-12-29 22:20:53 dub has joined
1168 2011-12-29 22:21:11 * BlueMatt likes roconnor's alternative, but Im not so sure about switching to it as it has no huge advantage over tweaking OP_EVAL imo
1169 2011-12-29 22:21:32 <gmaxwell> copumpkin: I think you're arguing for a delay more than roconnor is?
1170 2011-12-29 22:21:35 <gavinandresen> gmaxwell: .... or you hijack another NOP opcode to extend again....
1171 2011-12-29 22:21:43 <copumpkin> gmaxwell: could be :)
1172 2011-12-29 22:21:50 <copumpkin> anyway, I'm bowing out of this discussion. Poke me if you want PL nerd trivia
1173 2011-12-29 22:21:52 <roconnor> ByteCoin2: gmaxwell thinks that the OP_EVAL propsoal has no infinite loops.  But he has no proof; no one does.
1174 2011-12-29 22:21:53 <gmaxwell> (I mean rconner wants a delay too, but OP_EVAL is dead to him as is)
1175 2011-12-29 22:22:02 <helo> is there any limit to the delay required to prove there are no possible problems with OP_EVAL?
1176 2011-12-29 22:22:09 <roconnor> ByteCoin2: I also think OP_EVAL has no loops, but I'm not 100% sure.
1177 2011-12-29 22:22:38 <lianj> roconnor: maybe writing some creative tests?
1178 2011-12-29 22:22:48 <gmaxwell> gavinandresen: 'hijack another NOP opcode' doesn't remove the fork risk. But your first response is okay. I guess.
1179 2011-12-29 22:22:55 <roconnor> But I do know the current scripting code has no loops because 1 instruction is consumed every instruction until none are left
1180 2011-12-29 22:22:58 <ByteCoin2> It obviously doesnt have infinite loops because of the recursion limit
1181 2011-12-29 22:23:14 <roconnor> lianj: tests cannot prove the absance of bugs
1182 2011-12-29 22:23:30 <lianj> so better write none?
1183 2011-12-29 22:23:31 _Fireball has quit (Quit:  HydraIRC -> http://www.hydrairc.com <- Go on, try it!)
1184 2011-12-29 22:23:38 <roconnor> lianj: better is to write a proof
1185 2011-12-29 22:23:53 <lianj> in form of tests
1186 2011-12-29 22:23:53 <roconnor> I write formal computer checked proofs, but paper proofs are quite effective.
1187 2011-12-29 22:24:04 <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
1188 2011-12-29 22:24:43 m86 has quit (Changing host)
1189 2011-12-29 22:24:43 m86 has joined
1190 2011-12-29 22:24:49 <sipa> if your concern is OP_EVAL being not well understood and specified enough, i believe this is a step in the right direction
1191 2011-12-29 22:24:55 <roconnor> sipa: There are two major things I don't like about OP_EVAL: running dynamically generated code, and pseduo-turing completeness.
1192 2011-12-29 22:25:13 <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.
1193 2011-12-29 22:25:19 <roconnor> sipa: moreover, OP_EVAL isn't well tested and not well specified at the momement IMHO
1194 2011-12-29 22:25:45 <roconnor> sipa: even if I liked the propsoal
1195 2011-12-29 22:26:43 <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.
1196 2011-12-29 22:28:11 <gavinandresen> roconnor: small scriptPubKeys have other advantages (redeemer pays the transaction-size cost, and scriptSigs can easily be pruned if storage is a problem)
1197 2011-12-29 22:28:37 <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.
1198 2011-12-29 22:28:57 <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
1199 2011-12-29 22:29:03 [\\\] is now known as [\\\\\\\\\\\\\\\
1200 2011-12-29 22:29:07 <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.
1201 2011-12-29 22:29:26 <gmaxwell> s/scripts in/scripts is/
1202 2011-12-29 22:29:26 [\\\\\\\\\\\\\\\ is now known as [\\\\\\\\\\\\\\]
1203 2011-12-29 22:29:51 booo has quit (Ping timeout: 240 seconds)
1204 2011-12-29 22:29:57 <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 ;)
1205 2011-12-29 22:30:18 <gmaxwell> (because an input script can always be pruned once you have one, where as output scripts may never be prunable)
1206 2011-12-29 22:30:29 [\\\\\\\\\\\\\\] is now known as [\\\]
1207 2011-12-29 22:30:37 <roconnor> gmaxwell: someone has to keep the input script around
1208 2011-12-29 22:30:45 <sipa> gmaxwell: not immediately either, but relatively soon afterwards
1209 2011-12-29 22:30:51 <sipa> and not everyone either, indeed
1210 2011-12-29 22:31:03 <roconnor> true
1211 2011-12-29 22:31:11 <sipa> but it is true that marginally speaking for the network, inputs are cheaper than outputs
1212 2011-12-29 22:32:13 eoss has joined
1213 2011-12-29 22:32:14 eoss has quit (Changing host)
1214 2011-12-29 22:32:14 eoss has joined
1215 2011-12-29 22:35:17 <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.
1216 2011-12-29 22:35:28 <gmaxwell> Then it could be everyone, eventually.
1217 2011-12-29 22:35:40 <gmaxwell> though I don't think it matters because archival space is cheap enough.
1218 2011-12-29 22:35:51 <ByteCoin2> Sorry I was AFK. sipa: Isn't that overkill^4?
1219 2011-12-29 22:36:10 <sipa> ByteCoin2: what, precisely?
1220 2011-12-29 22:36:15 <ByteCoin2> Ooops. Responding with lag
1221 2011-12-29 22:36:29 <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.
1222 2011-12-29 22:37:00 erle- has quit (Quit: erle-)
1223 2011-12-29 22:37:18 <gmaxwell> (wow, I fail to type with great justice)
1224 2011-12-29 22:37:43 <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?
1225 2011-12-29 22:37:47 <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?
1226 2011-12-29 22:38:37 <roconnor> ByteCoin2: well after Jan 15th it will basically be too late.
1227 2011-12-29 22:39:11 <ByteCoin2> Why's that?
1228 2011-12-29 22:39:18 <Diablo-D3> gmaxwell: have you said anything in that thread yet?
1229 2011-12-29 22:39:40 <roconnor> ByteCoin2: because OP_EVAL will be deployed in whatever state it is in and changing any design errors will be difficult.
1230 2011-12-29 22:39:42 <ByteCoin2> The client can't generate OP_EVAL trannsactions
1231 2011-12-29 22:39:54 Maroni has joined
1232 2011-12-29 22:39:59 <roconnor> ByteCoin2: but the clients will accept OP_EVAL transactions on Feb 1
1233 2011-12-29 22:40:04 <roconnor> maybe Feb 1 is the last last day
1234 2011-12-29 22:40:27 <ByteCoin2> So if someone generates OP_EVAL transactions and there's a bug then what's the worst plausible case?
1235 2011-12-29 22:40:55 <roconnor> ByteCoin2: all miners get stuck in an infinite loop bringing down the entire network
1236 2011-12-29 22:41:02 <roconnor> scrabling to fix things fork the block chain
1237 2011-12-29 22:41:15 <roconnor> something like that I guess
1238 2011-12-29 22:41:23 <ByteCoin2> Mechanism for infinite loop using OP_EVAL is what?
1239 2011-12-29 22:41:25 <roconnor> maybe there are worse cases
1240 2011-12-29 22:41:33 <roconnor> ByteCoin2: I don't know for goddness sake!
1241 2011-12-29 22:41:39 <roconnor> ByteCoin2: neither do you
1242 2011-12-29 22:41:56 <ByteCoin2> Well whenever the miners roll out a new version it's possible that what you say can happen
1243 2011-12-29 22:42:06 <ByteCoin2> You can't rule that out either
1244 2011-12-29 22:42:29 <ByteCoin2> We have to MANAGE the risk not avoid it
1245 2011-12-29 22:43:24 <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.
1246 2011-12-29 22:43:47 <ByteCoin2> all  the more reason to examine the code closely and to test it thoroughly
1247 2011-12-29 22:43:54 <ByteCoin2> Before the set deadline!
1248 2011-12-29 22:44:04 <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
1249 2011-12-29 22:44:07 <roconnor> I'm done looking myself.
1250 2011-12-29 22:44:07 <ByteCoin2> Why is it you haven't looked at this months ago?
1251 2011-12-29 22:44:19 <roconnor> ByteCoin2: it wasn't christmas vacation 2 months ago
1252 2011-12-29 22:44:32 <roconnor> ByteCoin2: I didn't think anyone was taking OP_EVAL seriously
1253 2011-12-29 22:44:43 <roconnor> since it is such a terrible idea :P
1254 2011-12-29 22:44:48 <roconnor> (cognative bias)
1255 2011-12-29 22:44:50 <ByteCoin2> We can't plan development around when people might be most inclined to spend some time looking at things
1256 2011-12-29 22:45:04 <roconnor> ByteCoin2: why didn't you look at it 2 months ago and find my bugs?
1257 2011-12-29 22:45:10 <ByteCoin2> roconnor: Wow you really ddn't pay attention!
1258 2011-12-29 22:45:18 <roconnor> no I didn't
1259 2011-12-29 22:45:52 <ByteCoin2> I don't appreciate you threatening Gavin with going "to the blogosphere" to force his hand
1260 2011-12-29 22:46:19 <roconnor> what is the point of a voting without a public debate?
1261 2011-12-29 22:46:32 <ByteCoin2> There was a public debate on the forum
1262 2011-12-29 22:46:49 <roconnor> great
1263 2011-12-29 22:46:52 <ByteCoin2> I am kicking myself about that bug. I did see it and go "that's wierd"
1264 2011-12-29 22:47:06 <ByteCoin2> What's so bad about the forum?
1265 2011-12-29 22:47:08 <gavinandresen> The ++ bug?
1266 2011-12-29 22:47:13 <ByteCoin2> yes
1267 2011-12-29 22:47:32 <gavinandresen> I'm kicking myself about that one, too.......
1268 2011-12-29 22:47:44 <roconnor> ByteCoin2: would it make you feel better if I campaigned on the form instead of my blog?
1269 2011-12-29 22:47:46 <roconnor> *forum
1270 2011-12-29 22:48:12 <ByteCoin2> If there was a surfeit of programming effort than I would feel comfortable criticising people's efforts
1271 2011-12-29 22:48:37 <roconnor> ByteCoin2: have you seen my reimpelemenation of the bitcoin core protocol?
1272 2011-12-29 22:48:39 <ByteCoin2> As it is, if people get discouraged the project tanks more surely than if we have a major network hiccough
1273 2011-12-29 22:49:27 <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
1274 2011-12-29 22:49:51 <ByteCoin2> roconnor: On the forum is MUCH better imo
1275 2011-12-29 22:49:59 <sipa> Really?
1276 2011-12-29 22:50:03 <ByteCoin2> Let's not be snobbish about it
1277 2011-12-29 22:50:16 <ByteCoin2> Is it really that difficult to read?
1278 2011-12-29 22:50:35 <ByteCoin2> I know that there's lots of rubbish you need to skip over
1279 2011-12-29 22:50:51 <ByteCoin2> But I believe we can pick up the tone by leading by example
1280 2011-12-29 22:51:05 <ByteCoin2> Did you ever get involved with adult conversations as a child?
1281 2011-12-29 22:51:10 <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.
1282 2011-12-29 22:51:46 <gavinandresen> That is, conceptually, a minor change to the current OP_EVAL proposal.
1283 2011-12-29 22:51:58 abragin has quit ()
1284 2011-12-29 22:52:19 <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.
1285 2011-12-29 22:52:36 <gmaxwell> Diablo-D3: which thread? yours or the op-eval stuff?
1286 2011-12-29 22:52:54 <gmaxwell> I haven't commented on the OP_EVAL stuff because I have nothing 'adult' to offer.
1287 2011-12-29 22:53:23 <ByteCoin2> gavinandresen: I don't know what dangers that proposal would implicitly be addressing
1288 2011-12-29 22:53:47 <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
1289 2011-12-29 22:53:49 <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.
1290 2011-12-29 22:54:20 <ByteCoin2> sipa: The dev section is the only thing I read for a few years
1291 2011-12-29 22:54:28 <sipa> and indeed, it has improved over the past few months
1292 2011-12-29 22:54:30 <gavinandresen> ByteCoin2: I'm trying to address roconnor / gmaxwell's  "what if OP_EVAL interacts in some subtle way we can't see..."
1293 2011-12-29 22:54:46 <ByteCoin2> But I occasionally look at what gavin, theymos and a few others have been doing
1294 2011-12-29 22:54:47 [\\\] is now known as imsaguy
1295 2011-12-29 22:55:20 <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)
1296 2011-12-29 22:55:36 <ByteCoin2> gavinandresen: When OP_EVAL is executed I think it should just spew a load of script on to the top of the stack
1297 2011-12-29 22:55:45 <ByteCoin2> I don't see what's so complex about it
1298 2011-12-29 22:56:06 <ByteCoin2> Just like is shown in the explanation I wrote
1299 2011-12-29 22:56:59 <ByteCoin2> I'm willing to concede that it might not actually be able to work that way if there's something funny about how the scripts execute
1300 2011-12-29 22:57:06 <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.
1301 2011-12-29 22:57:58 <ByteCoin2> Testing against another implementation: Sounds good but exactly how would that be done?
1302 2011-12-29 22:58:11 <ByteCoin2> What things are tested for equality?
1303 2011-12-29 22:58:23 <ByteCoin2> Testing is HARD
1304 2011-12-29 22:58:39 <ByteCoin2> Sorry... EFFECTIVE testing is hard.
1305 2011-12-29 22:58:56 <ByteCoin2> "Gives me a fuzzy warm feeling" testing is easy
1306 2011-12-29 22:59:03 molecular has joined
1307 2011-12-29 22:59:26 <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.
1308 2011-12-29 22:59:46 <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
1309 2011-12-29 22:59:50 <gmaxwell> (bugs... and more importantly, ambiguities)
1310 2011-12-29 23:00:40 <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!
1311 2011-12-29 23:01:16 <ByteCoin2> To test the test harness you'd have to have an alternative implementation with some bugs built in!
1312 2011-12-29 23:01:42 <ByteCoin2> The test harness passes if it detects the known buggy bitcoin implementation
1313 2011-12-29 23:01:44 <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.
1314 2011-12-29 23:01:52 eoss has quit (Ping timeout: 240 seconds)
1315 2011-12-29 23:02:38 <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.
1316 2011-12-29 23:03:01 HaltingState has quit (Read error: Operation timed out)
1317 2011-12-29 23:03:14 <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
1318 2011-12-29 23:04:10 <ByteCoin2> You clearly "get" it but can it really be made to happen?
1319 2011-12-29 23:04:12 <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.
1320 2011-12-29 23:04:49 <sipa> there is roconnor's script implementation...
1321 2011-12-29 23:05:09 <ByteCoin2> This is why I'm trying to get roconnor to "play nicely" with the devs
1322 2011-12-29 23:05:10 <helo> if only there were some people with massive bitcoin stockpiles that could put some bounties up...
1323 2011-12-29 23:05:10 <gmaxwell> I've never actually seen roconnor's work. Is it up someplace?
1324 2011-12-29 23:05:15 HaltingState has joined
1325 2011-12-29 23:05:20 <gmaxwell> helo: money wouldn't help.
1326 2011-12-29 23:06:12 <ByteCoin2> gmaxwell: I think it WOULD help but it's not going to happen so it's not worth talking about
1327 2011-12-29 23:06:29 MobiusL has joined
1328 2011-12-29 23:06:44 <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.
1329 2011-12-29 23:07:06 <ByteCoin2> Ok. Precisely, it would have to be a large sum distributed appropriately
1330 2011-12-29 23:07:30 <ByteCoin2> Why do you think my involvement is limited to kibbitzing from the side
1331 2011-12-29 23:07:56 Cablesaurus has joined
1332 2011-12-29 23:07:56 Cablesaurus has quit (Changing host)
1333 2011-12-29 23:07:56 Cablesaurus has joined
1334 2011-12-29 23:07:59 <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
1335 2011-12-29 23:08:02 <ByteCoin2> I think we already waste too much time on something that won't pay our bills!
1336 2011-12-29 23:08:34 <ByteCoin2> copumpkin: That makes sense. It's a shame really
1337 2011-12-29 23:08:42 <gavinandresen> ByteCoin2: my wife thinks that, too....
1338 2011-12-29 23:08:44 <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::
1339 2011-12-29 23:08:45 Maroni has quit (Ping timeout: 255 seconds)
1340 2011-12-29 23:08:56 JZavala has joined
1341 2011-12-29 23:08:58 <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
1342 2011-12-29 23:09:06 <gmaxwell> copumpkin: it's different when its small amounts of money vs enough to pay people full time.
1343 2011-12-29 23:09:16 <ByteCoin2> I also imagine that the people with lots of time who have the engineering experise have rather hot heads!
1344 2011-12-29 23:09:33 <ByteCoin2> gavinandresen: It's not worth getting divorced over!
1345 2011-12-29 23:09:41 <copumpkin> gmaxwell: even smallish amounts of money can cause large amounts of drama, at least in my case :) the issue is with splitting it
1346 2011-12-29 23:09:43 <gmaxwell> helo: changes up the incentives. $50 to fix some bugs means nothing to me, but I'm less likely to contribute if someone else can get $50 for it.
1347 2011-12-29 23:10:43 minimoose has quit (Quit: minimoose)
1348 2011-12-29 23:10:57 <TD> there are exactly two levels of useful donations to open source software projects
1349 2011-12-29 23:10:59 <TD> 1) zero
1350 2011-12-29 23:11:03 <TD> 2) a decent salary
1351 2011-12-29 23:11:23 <ByteCoin2> So can I just establish what people think about the desirability of static analysis of scripts given the current system with IsStandard, opcode limits etc
1352 2011-12-29 23:11:29 <TD> because anyone with the skills to work on bitcoind could easily get a well paid job elsewhere, (2) is quite a large sum of money
1353 2011-12-29 23:12:09 <gmaxwell> TD: pretty much.  ... well, a trickle income that lets the project as a whole buy a server here and there without money coming out of anyone's pocket is nice. But that doesn't take much.
1354 2011-12-29 23:12:18 <copumpkin> ByteCoin2: I think the divide is pretty cleanly down the line of people who are PL/proof nerds and everyone else :)
1355 2011-12-29 23:12:25 <copumpkin> which isn't unexpected
1356 2011-12-29 23:12:54 <gmaxwell> copumpkin: where's your implementation? ;)
1357 2011-12-29 23:13:15 <ByteCoin2> Static analysis seems overkill for such short executables in such a constrained language
1358 2011-12-29 23:13:40 BlueMatt has quit (Quit: Ex-Chat)
1359 2011-12-29 23:14:01 <copumpkin> gmaxwell: hah, everything I say in here is almost always qualified with something along the lines of "but I'm not too involved in the bitcoin development process, so I'm only making fairly general comments based on my PL tastes"
1360 2011-12-29 23:14:05 <sipa> ByteCoin2: I'm somewhere in between I guess - it think those are nice properties to have, but I wouldn't kill OP_EVAL over lack of it. That said, the discussion made it clear to me that there are several useful improvements possible that are easy enough to still do before it makes it into an implemented specification
1361 2011-12-29 23:14:09 BlueMatt has joined
1362 2011-12-29 23:14:14 <copumpkin> gmaxwell: but there is none, to reiterate :)
1363 2011-12-29 23:14:25 <copumpkin> I have been thinking about good ways to express crypto proofs, though
1364 2011-12-29 23:14:27 <gmaxwell> ByteCoin2: even without using them in practice the same properties let you make concrete statements about the language more easily. What use that has in practice, I dunno. People use solidcoin, so ... technical trustworthness may just not be much of an issue so long as the PR is good. :(
1365 2011-12-29 23:15:00 <copumpkin> hah
1366 2011-12-29 23:15:15 <copumpkin> gmaxwell: the PL community has been feeling that about haskell and other "clean" languages for a while now
1367 2011-12-29 23:15:37 <copumpkin> people continue to use unclean things and all the researchers wonder "wtf", and everyone else just ignores them :)
1368 2011-12-29 23:15:45 eoss has joined
1369 2011-12-29 23:15:49 <ByteCoin2> sipa, gmaxwell: Ok now we're talking. This is what we need to discuss with less of the "let's replace OP_EVAL"
1370 2011-12-29 23:16:00 eoss has quit (Remote host closed the connection)
1371 2011-12-29 23:16:39 <sipa> Still, I think bitcoin got its initial group of supporters because of its design
1372 2011-12-29 23:17:03 <sipa> not the design of details such as the script language, where oversights and problems still exist
1373 2011-12-29 23:17:09 <ByteCoin2> Ok and why is doing some maths, then arriving at some number and then turning that into some script and executing it so horrendous. Gavin you have said you don't like that idea....
1374 2011-12-29 23:18:21 datagutt has quit (Quit: Computer has gone to sleep.)
1375 2011-12-29 23:18:34 <gmaxwell> without it, there is a direct static correspondence between the number of opcodes and the number of operations performed. A txn size limit is also directly and linearly an operations limit.
1376 2011-12-29 23:19:15 <gavinandresen> ByteCoin2: afk for dinner, can't respond now...
1377 2011-12-29 23:19:34 <gmaxwell> The value of this is reduced somewhat by the fact that not all operations are equal in cost, but even so there is a clear upper bound on the computational complexity of a block in the chain.
1378 2011-12-29 23:19:41 <ByteCoin2> gavin: Cool. Thx
1379 2011-12-29 23:20:07 <ByteCoin2> gmaxwell: But the numbers are so tiny!
1380 2011-12-29 23:20:16 <ByteCoin2> Why do we care?
1381 2011-12-29 23:20:32 <gmaxwell> E.g. if someone asks "what if someone makes a super expensive block to knock out 40% of the miners" and I could actually prove this to be impossible.
1382 2011-12-29 23:21:15 <ByteCoin2> gmaxwell: The cost of signature verification is large compared with anything else. We're doing multiplications of 256 bit numbers! Lots of them!
1383 2011-12-29 23:21:28 <gmaxwell> (I don't have such a proof now, but I'm confident one could be created— and I don't mean just an armwave, I mean a strict formal statement)
1384 2011-12-29 23:22:08 <ByteCoin2> gmaxwell: Is the absence of a proof going to change anything?
1385 2011-12-29 23:22:15 <gmaxwell> ByteCoin2: yes, I know. And the recusion limits _probably_ (assuming no oversights) still result in an upperbound that is no big deal.
1386 2011-12-29 23:22:49 <gmaxwell> ByteCoin2: well, it reduces our ability to counteract fud. I don't know if it actually matters, because the public will trust anything it seems. :-/
1387 2011-12-29 23:23:11 <ByteCoin2> Well this is an important trade-off
1388 2011-12-29 23:23:49 <ByteCoin2> On the one hand we don't want to be TOO liberal but on the other hand we want to be able to implement multisignature transactions
1389 2011-12-29 23:24:04 <gmaxwell> It does mean things like, "You can't actually tell that you'll eventually reject this block due to too many checksigs" until you run checksig max checks. Though.. an attacker could just make valid txn with the checksig max checks.
1390 2011-12-29 23:24:13 <gmaxwell> ByteCoin2: well, thats why I found the discussion promising.
1391 2011-12-29 23:24:26 <gmaxwell> It sounds like we could potentially get send-to-script without being able to run computed values.
1392 2011-12-29 23:24:43 <gmaxwell> And that puts us back in the land of static analysis and linear-with-size software.
1393 2011-12-29 23:24:55 <ByteCoin2> Can you explain it to me briefly?
1394 2011-12-29 23:26:09 <ByteCoin2> If someone could post an explanation of how a standard transaction would be implemented with how the stack evolves....
1395 2011-12-29 23:26:21 <sipa> ByteCoin2: which proposal are you talking about?
1396 2011-12-29 23:26:21 <gmaxwell> Er there have been a couple. But basically one group comes down to making the operation that pushes the script onto the stack somewhat special, and then making op_eval only able to run those scripts. E.g. not ones resulting from computation.
1397 2011-12-29 23:26:36 _W_ has joined
1398 2011-12-29 23:27:17 <ByteCoin2> Ok so calculated values are marked "tainted"
1399 2011-12-29 23:27:30 <ByteCoin2> That's not roconnor's proposal as I understand it
1400 2011-12-29 23:27:34 <sipa> That's not enough to get static analysis, though.
1401 2011-12-29 23:27:39 <gmaxwell> Right thats not rconnor's.
1402 2011-12-29 23:27:52 <ByteCoin2> sipa: It's not?
1403 2011-12-29 23:27:54 <gmaxwell> My understanding is that roconnor's was basically sticking the script after a separator, and having a 'look over there and run the script if its hash matches X'
1404 2011-12-29 23:28:09 <gmaxwell> yea, it's not? hm. I thought that was.
1405 2011-12-29 23:28:45 <sipa> ByteCoin2: if can write an If/then/else that depends on a complex expression (potentially a signature validation), and based on that pushes either X or Y on the stack
1406 2011-12-29 23:28:54 <sipa> and then executes X or Y using OP_EVAL
1407 2011-12-29 23:29:13 <ByteCoin2> This static analysis sounds like a relatively complex piece of software prone to subtle bugs and difficult to understand. Do we want it>
1408 2011-12-29 23:29:17 <ByteCoin2> ?
1409 2011-12-29 23:29:35 <ByteCoin2> sipa: Then look at X and Y and take the worst case?
1410 2011-12-29 23:29:52 <sipa> right, that's a possible analysis
1411 2011-12-29 23:30:02 <gmaxwell> oh, yea, if the script isn't at the tail, then it breaks static analysis.
1412 2011-12-29 23:30:20 <ByteCoin2> Static analysis is complex. More complex than anything else in bitcoin
1413 2011-12-29 23:30:22 <gmaxwell> if the eval is at the tail, then static analysis is still trivial.
1414 2011-12-29 23:31:01 <ByteCoin2> Do you guys think static analysis is easy to implement and simple to understand?
1415 2011-12-29 23:31:02 <gmaxwell> ByteCoin2: it's my hope that someday miners will run multiple independant validation engines and only permit transactions if all find them acceptable.
1416 2011-12-29 23:31:28 <gmaxwell> ByteCoin2: It doesn't have to be, because it doesn't have to be a mandatory part of the software. Some high security implementations might have it. Some might not.
1417 2011-12-29 23:31:41 <ByteCoin2> gmaxwell: Isn't that a problem if not all miners run the same suite of validation engines?
1418 2011-12-29 23:31:45 <copumpkin> static analysis isn't a single procedure
1419 2011-12-29 23:31:49 <copumpkin> it could take the form of something ad-hoc
1420 2011-12-29 23:31:51 <copumpkin> or a type system
1421 2011-12-29 23:31:55 <gmaxwell> I wouldn't want to write any rule that depends on having it. (except perhaps the most simple kind, like count up the opcodes and you know your maximum)
1422 2011-12-29 23:31:56 Joric has quit (Ping timeout: 248 seconds)
1423 2011-12-29 23:32:04 <copumpkin> some of them are easier to trust than others
1424 2011-12-29 23:32:39 <ByteCoin2> Do you guys admit that this is all completely academic at the moment because everything has to be IsStandard?
1425 2011-12-29 23:32:39 <sipa> ByteCoin2: it could just be inferring that a certain signature check isn't necessary, as the result of the script doesn't depend on it
1426 2011-12-29 23:32:46 <gmaxwell> ByteCoin2: if they are using it for _transactions_ going into their memory pool its no issue at all.
1427 2011-12-29 23:32:47 <copumpkin> yes
1428 2011-12-29 23:32:59 <sipa> ByteCoin2: miners need to validate non-IsStandard things in the blockchain as well
1429 2011-12-29 23:33:12 <gmaxwell> and I damn well hope all validators would agree on txn in the chain.
1430 2011-12-29 23:33:45 <sipa> ByteCoin2: and yes, most applications of analysis are not yet here, but I do believe it is a very nice property to have
1431 2011-12-29 23:34:00 <gmaxwell> (and, as a point about whats possible in the realm of formal software validation: http://compcert.inria.fr/ )
1432 2011-12-29 23:34:07 <ByteCoin2> sipa: The IsStandard check with OP_EVAL happens on redemption so it's not a problem with incuding transactions into blocks
1433 2011-12-29 23:34:24 <sipa> It is when including the spending transaction...
1434 2011-12-29 23:34:48 * sipa -> bed
1435 2011-12-29 23:35:02 <schilly> this discussion somehow reminds me of a talk, yesterday at the 28c3 convention about non-turing complete languages for protocols. this commands need to be incomplete and
1436 2011-12-29 23:35:03 <gmaxwell> There was a point I raised at the very start of spend-to-script: Yes, you can spend to addresses you can't redeem, thus making coins get stuck. So sad for you.
1437 2011-12-29 23:35:07 <ByteCoin2> I'm very keen on static analysis but we simply haven't got the engineering effort to do it
1438 2011-12-29 23:35:15 <schilly> be a context free pushdown -something- language
1439 2011-12-29 23:35:18 <gmaxwell> ByteCoin2: we don't hae it _today_.
1440 2011-12-29 23:35:34 <schilly> otherwise it's doomed to be impossible to check if two different implementation actually do the same validation
1441 2011-12-29 23:35:34 <gmaxwell> ByteCoin2: but if we adopt a protocol feature that precludes it, we can't ever have it.
1442 2011-12-29 23:35:55 <copumpkin> schilly: well!
1443 2011-12-29 23:35:58 <ByteCoin2> It's like not letting a plane take off because there are no lemon scented paper napkins.
1444 2011-12-29 23:36:03 <copumpkin> schilly: that's oversimplifying the question a bit more
1445 2011-12-29 23:36:08 <copumpkin> ByteCoin2: you're trivializing it :)
1446 2011-12-29 23:36:10 <ByteCoin2> HHGTG reference
1447 2011-12-29 23:36:31 <ByteCoin2> copumpkin: Yes
1448 2011-12-29 23:36:45 <gmaxwell> ByteCoin2: meh. Protocol features are more or less forever.
1449 2011-12-29 23:37:04 <copumpkin> protocol features are forever, but deadlines are in 2 weeks!
1450 2011-12-29 23:37:09 <copumpkin> mmm
1451 2011-12-29 23:37:09 <ByteCoin2> gmaxwell: Ok. I take your point
1452 2011-12-29 23:37:11 <copumpkin> :)
1453 2011-12-29 23:37:21 <ByteCoin2> We should have had this discussion a LONG time ago
1454 2011-12-29 23:37:29 <copumpkin> schilly: you can use more powerful things than that if you're willing to write a manual proof
1455 2011-12-29 23:37:50 Joric has joined
1456 2011-12-29 23:37:51 Joric has quit (Changing host)
1457 2011-12-29 23:37:51 Joric has joined
1458 2011-12-29 23:37:52 <copumpkin> ByteCoin2: I don't think roconnor had implemented anything back then, and I was too busy buying high and selling low to even know what was going on
1459 2011-12-29 23:37:58 <gmaxwell> Well, I was happy with the strict recursion limit. I didn't even _think_ of OP_EVAL _code_ arising as the result of arithemetic. :(
1460 2011-12-29 23:38:01 <copumpkin> but yeah
1461 2011-12-29 23:38:07 <copumpkin> I agree that it's late
1462 2011-12-29 23:38:34 <ByteCoin2> Perhaps gavinandresen should have set shorter deadlines and then we would have been here earlier! Then he should have extended to the realistic timescale he always was aiming for!
1463 2011-12-29 23:38:49 <gmaxwell> maybe he did? dum dum dum
1464 2011-12-29 23:39:00 <copumpkin> lol
1465 2011-12-29 23:39:38 <luke-jr> roconnor is certainly right that OP_EVAL should have been in 0.5 testnet
1466 2011-12-29 23:39:41 <gmaxwell> (in particular, I didn't think of code arising from arithemetic because its @#$@# stupid and useless. ——— not thinking like an attacker there. :( )
1467 2011-12-29 23:39:53 <gmaxwell> luke-jr: gavin used it in testnet some time ago.
1468 2011-12-29 23:40:03 <luke-jr> gmaxwell: arithmetic code is not an attack
1469 2011-12-29 23:40:15 <gmaxwell> The way the testnet code is structure in bitcoin its not easy to hae core features which are there for one and not for another, at least not without risk.
1470 2011-12-29 23:40:17 <luke-jr> gmaxwell: I mean for mass testing
1471 2011-12-29 23:40:33 <luke-jr> gmaxwell: sure it is, so long as we have the code to do a "enabled only after X point in time"
1472 2011-12-29 23:40:41 <gmaxwell> also, testnet gets very little observation or usage.
1473 2011-12-29 23:41:00 <gmaxwell> roconnor was apparently shoving all kinds of garbage transactions into it months ago and no one noticed.
1474 2011-12-29 23:41:13 <luke-jr> lol
1475 2011-12-29 23:41:37 <ByteCoin2> There's a risk of feature bleed whereby you think the changes you implement only affect testnet but some side effect blows up bitcoin
1476 2011-12-29 23:41:46 <gmaxwell> luke-jr: we still take most of the implementation hazard there from whatever refactoring was required to add the code.
1477 2011-12-29 23:42:00 <gmaxwell> and what ByteCoin2 said.
1478 2011-12-29 23:42:11 <ByteCoin2> gmaxwell: There's all sorts of garbage in various unchecked bits of transactions in the main network
1479 2011-12-29 23:43:13 <ByteCoin2> A long time ago I advocated that testnet be run by a completely separate executable
1480 2011-12-29 23:44:17 <ByteCoin2> Perhaps there should be test networks for each new client version
1481 2011-12-29 23:44:51 <ByteCoin2> The test network clients play with each other with toy bitcoins at toy difficulties at random for a few months
1482 2011-12-29 23:46:30 <gmaxwell> testnet is pretty hard to use for people without a lot of mining power.. it'll go hours without a block ... but still maintains a fairly high difficulty because of bursts of activity.
1483 2011-12-29 23:46:43 <luke-jr> ByteCoin2: I recently made a 'bitcoin2' branch, intending to turn it into a playground for blockchain-forking changes
1484 2011-12-29 23:47:02 <gmaxwell> (I think its at 35 now, ... long enough that it takes joe blow 16 hours to mine a block)
1485 2011-12-29 23:47:33 <TD> phew
1486 2011-12-29 23:47:37 <ByteCoin2> I'm much more unhappy about this sort of stuff than the risks of OP_EVAL
1487 2011-12-29 23:47:42 <TD> getheaders catchup nearly implemented in bitcoinj
1488 2011-12-29 23:47:50 <TD> this should help close the UX gap with the superlightweight clients
1489 2011-12-29 23:50:45 <gmaxwell> TD: I'm pretty happy seeing the competition between SPV and thinclients. :)
1490 2011-12-29 23:51:25 <TD> yeah the bitcoin wallet app is getting the same problem as the satoshi client - takes too long for new users to catch up with the chain
1491 2011-12-29 23:51:36 <TD> this is something of a short term fix, but it'll suffice for now
1492 2011-12-29 23:52:38 <TD> the real fix is for andreas to frequently refresh his block chain copy
1493 2011-12-29 23:54:01 Warlord has joined
1494 2011-12-29 23:57:21 <gmaxwell> initial syncup is really becoming an issue for casual use of full nodes.
1495 2011-12-29 23:57:41 <gmaxwell> I'd really rather not have to encourage people to run SPV nodes purely because of impatience with the initial syncup.
1496 2011-12-29 23:58:25 <gmaxwell> (SPV nodes because you're on a mobile or limited device is great— but on a system which could otherwise be a full node listening on the p2p network, that kinda sucks)
1497 2011-12-29 23:58:34 <TD> well i think gavin plans to do a super-cool "start in SPV mode, transition to full mode in the background"
1498 2011-12-29 23:58:44 <luke-jr> someone should kill the stupid fsync