1 2011-12-26 01:02:01 <luke-jr> cjdelisle: Tor does not protect against DDoS
  2 2011-12-26 01:02:07 <luke-jr> cjdelisle: Tor enables DDoS
  3 2011-12-26 01:05:14 <CIA-100> bitcoin: Con Kolivas * rc786ac3b2a97 cgminer/main.c: Prevent crash from statline dereference if cgminer is quit before setting up fully. http://tinyurl.com/7ggw5fd
  4 2011-12-26 01:08:31 <luke-jr> cjdelisle: IMO, fragmentation has no business this low-level
  5 2011-12-26 01:08:49 <luke-jr> nor do switches need to know the type of a packet
  6 2011-12-26 01:16:25 <cjdelisle> luke-jr: I removed fragmentation but I have not had a chance to update the whitepaper
  7 2011-12-26 01:17:03 <cjdelisle> it would have been nice to have fragmentation without large (ip6) headers on each fragment but unfortunately it simply isn't possible for routers to pipeline packets through safely
  8 2011-12-26 01:18:10 <cjdelisle> also tor gives a measure of protection against DDoS to .onion servers since they are hard to find and they can move around easily, ofc tor->internet is more or less a loose cannon
  9 2011-12-26 01:19:28 <luke-jr> not really. lots of Tor nodes making lots of connections to the .onion is just as effective
 10 2011-12-26 01:19:30 <luke-jr> if not more
 11 2011-12-26 01:20:24 <luke-jr> cjdelisle: also, you left out the part where route discovery was
 12 2011-12-26 01:20:38 <luke-jr> I presume it's more sensible than a broadcast
 13 2011-12-26 01:22:12 <cjdelisle> yes, it's a DHT
 14 2011-12-26 01:22:36 <luke-jr> DHT how?
 15 2011-12-26 01:22:50 <cjdelisle> Each node does manual introduction to it's nearest neighbors and they hand the routes to their other neighbors over
 16 2011-12-26 01:22:50 <luke-jr> the route is different for every set of peers
 17 2011-12-26 01:23:02 <luke-jr> &
 18 2011-12-26 01:23:10 <cjdelisle> nodes splice the route from "me to alice" to alice's route to bob to get a route from me to bob
 19 2011-12-26 01:23:11 <luke-jr> so every node stores a route to every other node?
 20 2011-12-26 01:23:28 <cjdelisle> no, they only store routes to some nodes
 21 2011-12-26 01:23:40 <cjdelisle> you can drop a packet off at any router and it will forward it again
 22 2011-12-26 01:23:58 <luke-jr> &
 23 2011-12-26 01:24:16 <cjdelisle> so if you don't have the full route, you send the packet to a node which is close to you in physical space and close to the destination in address space
 24 2011-12-26 01:24:24 <cjdelisle> and you hope that they have the full route
 25 2011-12-26 01:24:30 <luke-jr> so there ARE addresses
 26 2011-12-26 01:25:03 <cjdelisle> and because it's based on DHT, nodes have an affinity for other nodes who have close addresses to their own so sending it to a close address is a good plan
 27 2011-12-26 01:26:01 <cjdelisle> There are ipv6 addresses in level3 and there are switch labels in level2
 28 2011-12-26 01:26:35 <gmaxwell> ::yawns::
 29 2011-12-26 01:26:36 <gmaxwell> http://grothoff.org/christian/pitchblack.pdf
 30 2011-12-26 01:26:42 <cjdelisle> you tell your node to send the packet to an ipv6 address, your node works out the rest
 31 2011-12-26 01:26:50 <Joric> are there any advantages of sqlite before berkeleydb? if i'll need to search/analyze the blockchain should i get rid of berkeley db?
 32 2011-12-26 01:27:12 <luke-jr> makes no sense
 33 2011-12-26 01:27:20 <luke-jr> Joric: totally different purposes
 34 2011-12-26 01:27:57 <Joric> i'll probably need a few other index tables for that
 35 2011-12-26 01:31:17 <Joric> bigtable on gae looks promising pity gae doesn't support sockets to download blockchain directly
 36 2011-12-26 01:41:22 <cjdelisle> gmaxwell: sybil/clustering attacks are not perticularly effective in this case, primarily because there is no data being stored in this "DHT"
 37 2011-12-26 01:42:34 <cjdelisle> also because routing information is highly duplicated, such that you can get a full route to anywhere in just a few hops -- likely not leaving your own isp
 38 2011-12-26 01:43:28 <cjdelisle> if there wasn't so much duplication it would be terribly slow because a packet would need to travel halfway around the world just to find a node which had the full route
 39 2011-12-26 06:29:55 <Joric> 3.9 O_o
 40 2011-12-26 06:33:45 <SomeoneWeird> ;;ticker --last
 41 2011-12-26 06:33:46 <gribble> 4.02836
 42 2011-12-26 06:33:47 <SomeoneWeird> BOOOOOOOO.
 43 2011-12-26 06:33:48 <SomeoneWeird> oh
 44 2011-12-26 06:33:49 <SomeoneWeird> yay
 45 2011-12-26 08:28:43 <finway-mobil> ;;ticker
 46 2011-12-26 08:28:45 <gribble> Best bid: 4.05, Best ask: 4.05155, Bid-ask spread: 0.00155, Last trade: 4.05, 24 hour volume: 116403, 24 hour low: 3.81, 24 hour high: 4.3897
 47 2011-12-26 09:18:02 <Joric> i don't quite get the transaction scheme, does client count nodes that were used in broadcasting? is there an upper limit of nodes where the broadcasting completely stops?
 48 2011-12-26 09:21:44 <SomeoneWeird> hm?
 49 2011-12-26 11:18:07 <[Tycho]> Did anyone saw TX 82cfebdbd7452214abbfafe440603f675a60ee05be3fde2893f5e6f98a8673e7 ?
 50 2011-12-26 11:21:02 <phantomcircuit> someone did see it
 51 2011-12-26 11:22:39 <lianj> bbe did not
 52 2011-12-26 11:24:10 <phantomcircuit> lianj, there are logs of people talking about them
 53 2011-12-26 11:43:22 <makomk> I wonder what's meant to be special about that TX...
 54 2011-12-26 11:46:13 <edcba> pt1 y a plus de r??seau ou quoi
 55 2011-12-26 11:47:15 <edcba> lag => wrong window :(
 56 2011-12-26 12:43:16 <phantomcircuit> makomk, it was a double spend
 57 2011-12-26 12:43:42 <SomeoneWeird> heh
 58 2011-12-26 12:49:05 <phantomcircuit> im not kidding
 59 2011-12-26 12:49:10 <phantomcircuit> it's not in the block chain though
 60 2011-12-26 13:11:29 <SomeoneWeird> yeah
 61 2011-12-26 13:20:13 <makomk> Interesting.
 62 2011-12-26 13:28:59 <finway> MagicalTux: What does this mean? Your account is currently pending review, please visit https://mtgox.com/forms/verification
 63 2011-12-26 13:30:25 <CIA-100> libbitcoin: Kamil Domanski abc * reb8bad54bbec / (9 files in 4 dirs): helper functions moved from types.hpp to data_helpers.hpp http://tinyurl.com/7rkgga8
 64 2011-12-26 13:36:06 <phantomcircuit> finway, it means b&
 65 2011-12-26 13:36:17 <phantomcircuit> finway, im guessing you made a dwolla transfer
 66 2011-12-26 13:36:46 <finway> phantomcircuit: no , i made some LR deposit through BitInstant
 67 2011-12-26 13:36:54 <copumpkin> finway: #mtgox seems more appropriate for that
 68 2011-12-26 13:37:01 <copumpkin> this is about actual bitcoin development
 69 2011-12-26 13:37:09 <phantomcircuit> speaking of which
 70 2011-12-26 13:37:16 <finway> sorry.
 71 2011-12-26 13:37:17 <phantomcircuit> given the recent bad patch merge
 72 2011-12-26 13:37:28 <phantomcircuit> i think there needs to be a radical shift in the way patches are accepted
 73 2011-12-26 13:37:47 <phantomcircuit> im thinking a formal multiparty sign off
 74 2011-12-26 14:05:12 <finway> I can't login #mtgox
 75 2011-12-26 14:05:14 <finway> :(
 76 2011-12-26 14:05:29 <copumpkin> you need a nickserv account
 77 2011-12-26 14:30:11 <finway> copumpkin: where to register a nickserv account?
 78 2011-12-26 14:38:47 <kinlo> just talk to nickserv
 79 2011-12-26 14:38:51 <kinlo> /query nickserv
 80 2011-12-26 14:38:57 <kinlo> that will open up a window to chat with it
 81 2011-12-26 15:05:30 <luke-jr> phantomcircuit: the merging of patches is already overly slow; stdint somehow bypassed that
 82 2011-12-26 15:05:44 <luke-jr> phantomcircuit: also, I'm pretty sure multiple people *did* sign off on it
 83 2011-12-26 15:05:54 <luke-jr> problem is, nobody who tested ran 64-bit
 84 2011-12-26 15:07:03 <Joric> luke-jr, would jun.dashjr.org accept 0.005 transaction without a fee? how about relay.eligius.st?
 85 2011-12-26 15:10:01 <luke-jr> Joric: jun.dashjr.org is the free relay node, and will relay anything
 86 2011-12-26 15:10:14 <luke-jr> relay.eligius.st is just a gateway to deliver txns to Eligius
 87 2011-12-26 15:17:28 <nanotube> what bad patch?
 88 2011-12-26 15:23:30 <nathan7> Hi nanotube
 89 2011-12-26 16:14:22 <nanotube> nathan7: howdy
 90 2011-12-26 16:27:04 <luke-jr> nanotube: stdint was merged within hours of my completing it, before anyone had tested on 64-bit
 91 2011-12-26 16:41:28 <sipa> 
 92 2011-12-26 18:06:19 <dikidera> ;;bc,stats
 93 2011-12-26 18:06:21 <gribble> Current Blocks: 159265 | Current Difficulty: 1159929.4972244 | Next Difficulty At Block: 161279 | Next Difficulty In: 2014 blocks | Next Difficulty In About: 2 weeks, 6 days, 8 hours, 57 minutes, and 16 seconds | Next Difficulty Estimate: 1592582.18321661 | Estimated Percent Change: 37.2999123678
 94 2011-12-26 18:34:28 <blue_> hi
 95 2011-12-26 18:38:21 <blue_> Iam trying to understand how the Transactions work - Here my Question: What is in the flag "scriptSig" ? wiki says a signature and a public key - public key from sender or recipient?
 96 2011-12-26 18:47:41 <blue_> hm
 97 2011-12-26 18:48:21 <dikidera> can you answer my counter question?
 98 2011-12-26 18:48:41 <dikidera> why do you want to know?
 99 2011-12-26 19:02:49 <luke-jr> blue_: sender
100 2011-12-26 19:03:00 <blue_> thanks
101 2011-12-26 19:03:24 <luke-jr> scriptSig is on the input side
102 2011-12-26 19:04:31 <blue_> one blank " " seperates key and signature ?
103 2011-12-26 19:04:54 <luke-jr> no
104 2011-12-26 19:05:07 <luke-jr> scriptSig is a script.
105 2011-12-26 19:05:25 <sipa> blue_: read about scripts on the bitcoin wiki
106 2011-12-26 19:05:36 <phantomcircuit> blue_, dont read the scriptSig from block explorer that is an interpretation of the actual script
107 2011-12-26 19:05:45 <luke-jr> blue_: Bitcoin is built upon a scripting lang
108 2011-12-26 19:06:08 <[Tycho]> Yes, that tricked me too before I learned about how scripts work :)
109 2011-12-26 19:06:36 <phantomcircuit> lol
110 2011-12-26 19:06:37 <phantomcircuit> so
111 2011-12-26 19:06:43 <phantomcircuit> i have a chart of bitcoinica quote prices
112 2011-12-26 19:06:59 <phantomcircuit> people getting liquidated is 100% not their fault
113 2011-12-26 19:07:11 <phantomcircuit> it's 100% his insane pricing algo
114 2011-12-26 19:07:15 <blue_> hmm
115 2011-12-26 19:07:40 <phantomcircuit> blue_, http://en.bitcoin.it/wiki/Script
116 2011-12-26 19:08:17 <sipa> blue_: the big picture: transactions consume inputs, and produce new outputs
117 2011-12-26 19:08:34 <sipa> each input refers to another transaction's output
118 2011-12-26 19:09:09 <blue_> its a tree or chain  of transactions right?
119 2011-12-26 19:09:16 <sipa> outputs have a scriptPubKey (which in most cases doesn't contain a pubkey these days) that contains a script that must evaluate to true when consuming it
120 2011-12-26 19:09:34 <sipa> you're talking about the block chain, that is something entirely separate
121 2011-12-26 19:09:45 <phantomcircuit> blue_, it's a chain of transactions which branch
122 2011-12-26 19:10:47 <blue_> well but the script is for checking if the transaction is vailid or not?
123 2011-12-26 19:10:49 <sipa> inputs refer to an output, and provide an input (called scriptSig) which ispassed to the previous output's scriptPubKey
124 2011-12-26 19:11:56 <sipa> when paying to an address (the most common transaction these days), you create an output with a script that says "give me a signature S and a pubkey K, such that S is a valid signature for P, and the hash of P is <address>"
125 2011-12-26 19:12:15 <sipa> when spending such an output, the corresponding scriptSig contains P and S
126 2011-12-26 19:16:46 <blue_> ok another stupid question^.^ : one transaction always contains input and output?
127 2011-12-26 19:17:04 <luke-jr> s/K/P
128 2011-12-26 19:17:24 <luke-jr> blue_: a transaction must have AT LEAST 1 input, and any number of outputs.
129 2011-12-26 19:17:44 <sipa> at least one output as well
130 2011-12-26 19:17:53 <blue_> ok thanks
131 2011-12-26 19:21:20 <luke-jr> sipa: really?
132 2011-12-26 19:21:32 <luke-jr> sipa: I think the wiki docs say 0 outputs is valid
133 2011-12-26 19:21:38 <sipa> yes, quite sure
134 2011-12-26 19:21:56 <luke-jr> would it be evil to find out by making a 0-output txn?
135 2011-12-26 19:22:10 <luke-jr> ie, and possibly risk a blockchain fork if someone screwed up
136 2011-12-26 19:22:22 <gmaxwell> Test on testnet, silly.
137 2011-12-26 19:22:31 <luke-jr> gmaxwell: too much effort
138 2011-12-26 19:24:15 <sipa> if (vout.empty())
139 2011-12-26 19:24:28 <blue_> without output u would not send a coin because the value is in output i guess
140 2011-12-26 19:24:51 <sipa> blue_: yes; but an output of value 0.00000000 is valid
141 2011-12-26 19:25:00 <blue_> oh^^
142 2011-12-26 19:25:02 <sipa> but no output at all isn't
143 2011-12-26 19:25:36 <blue_> so i can send nothing :D
144 2011-12-26 19:25:55 <gmaxwell> The system allows expressing that, though no one may mine it.
145 2011-12-26 19:26:25 <sipa> luke-jr: quite sure miners will accept it
146 2011-12-26 19:26:32 <blue_> i could send nothing with a fee :D
147 2011-12-26 19:26:33 <sipa> eh
148 2011-12-26 19:26:58 <gmaxwell> sipa: E.g. I think luke won't accept those.
149 2011-12-26 19:27:31 <gmaxwell> (as he's mentioned zero value outputs as a kind of spam that irritated him before)
150 2011-12-26 19:27:56 <sipa> oh sure specific miners can drop them
151 2011-12-26 19:31:10 <blue_> can i view my public key somewhere in the basic win version?
152 2011-12-26 19:32:43 <sipa> not in the gui
153 2011-12-26 19:34:26 <blue_> so i guess i have to open my wallet?
154 2011-12-26 19:34:26 <sipa> if you do a transaction using coins that were previously sent to address A, you can see the pubkey corresponding to A on BBE
155 2011-12-26 19:34:53 <luke-jr> sipa: confirmed vout>=1 requirement has been there from the initial import
156 2011-12-26 19:35:17 <sipa> blue_: do you need to+
157 2011-12-26 19:42:44 <blue_> still not getting the script well  - in normal transactions "scriptSig": contains  "<sig>" & "<pubKey>"  ?
158 2011-12-26 19:43:18 <blue_> normal means usual via client to another bitcoinadres
159 2011-12-26 19:43:28 <sipa> 21:11:56 < sipa> when paying to an address (the most common transaction these days), you create an output with a script that says "give me a signature S and a pubkey K, such that S is a valid signature for P, and the hash of P is <address>"
160 2011-12-26 19:43:32 <sipa> 21:12:14 < sipa> when spending such an output, the corresponding scriptSig contains P and S
161 2011-12-26 19:43:35 <sipa> 2
162 2011-12-26 19:46:03 <blue_> what u  describe is the flag "scriptPubKey" ?
163 2011-12-26 19:47:47 <sipa> scriptPubKey is the script that checks vality in outputs
164 2011-12-26 19:48:15 <sipa> scriptSig is the script in inputs which provides the data that will be checked in the corresponding output
165 2011-12-26 19:49:00 <sipa> for a normal transaction, the output says "give me P and S such that S is a valid signature for pubkey P, and the hash of P is <addressL"
166 2011-12-26 19:49:10 <sipa> the corresponding input says "P S"
167 2011-12-26 19:49:34 <blue_> is it always structured like this "OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG" ? Or is it usual to use other parameters?
168 2011-12-26 19:50:28 <sipa> that is the encoded form of "give me P and S such that S is a valid signature for pubkey P, and the hash of P is <address>"
169 2011-12-26 19:51:09 <sipa> you can use other scripts if you write a client that can create them, and a miner that will accept them
170 2011-12-26 19:51:31 <blue_> okay thanks a lot for ur help :)
171 2011-12-26 20:22:40 <blue_> how big is ur current blockchain mine is 812mb is that correct?
172 2011-12-26 20:23:51 <gmaxwell> I think its fantastic that even lolcats are getting into bitcoin technology.
173 2011-12-26 20:24:15 <lolcat> gmaxwell: I've been here since the price was $0.20
174 2011-12-26 20:24:22 <rjk2> pwned
175 2011-12-26 20:24:54 <gmaxwell> lolcat: I suspect that you're an imposter.
176 2011-12-26 20:25:49 <sipa> lolcat: about a year ago?
177 2011-12-26 20:26:10 <lolcat> gmaxwell: Why?
178 2011-12-26 20:26:21 <lolcat> Am I not identified?
179 2011-12-26 20:26:36 <lolcat> sipa: No idea, just remember buying like 200 @ $0.25
180 2011-12-26 20:26:41 <sipa> you speak english
181 2011-12-26 20:26:55 <lolcat> I do?
182 2011-12-26 20:27:29 <copumpkin> lolcat: ceiling cat watchz u typ english rite
183 2011-12-26 20:27:34 <copumpkin> lolcat: lrn 2 spel
184 2011-12-26 20:28:33 <lolcat> ...
185 2011-12-26 20:28:53 <gmaxwell> lolcat: English with mixed case, in fact.
186 2011-12-26 20:29:06 <copumpkin> wtf
187 2011-12-26 20:29:29 <copumpkin> u r a disgraec 2 ur speseiz
188 2011-12-26 20:29:31 <lolcat> Mixed case?
189 2011-12-26 20:29:39 <gmaxwell> Exactly.
190 2011-12-26 20:29:40 <rjk2> LOLCATS R SUPOZED 2 TYEP LIEK THIS
191 2011-12-26 20:29:42 <copumpkin> lolcat: lolcats are known for having terrible english
192 2011-12-26 20:29:54 <lolcat> I can't really understand, I don't see where I spelled wrong. I am not native so bear with me.
193 2011-12-26 20:29:57 <copumpkin> you're failing that
194 2011-12-26 20:30:09 <lolcat> Well, I won't spell like a 3 year old
195 2011-12-26 20:30:13 <lolcat> I just can't
196 2011-12-26 20:30:15 <gmaxwell> lolcat: You didn't spell anything wrong. Your use of english is fine. Thats the problem.
197 2011-12-26 20:30:20 <lolcat> oh
198 2011-12-26 20:30:22 <copumpkin> then you fail at being a lolcat
199 2011-12-26 20:30:31 <rjk2> lol you guys are confusing him
200 2011-12-26 20:30:34 <copumpkin> you can't sound like an adult, it's antithetical to the lolcat manifesto
201 2011-12-26 20:30:37 <lolcat> I've been a lolcat for ages.
202 2011-12-26 20:30:43 <copumpkin> lolcats never grow up
203 2011-12-26 20:30:49 <copumpkin> they're basically eternal lolkittens
204 2011-12-26 20:31:21 <gmaxwell> This should stop before we're all deafened by the wooshing sound.
205 2011-12-26 20:31:24 <rjk2> when they grow up they turn into monrail kittehs
206 2011-12-26 20:31:32 <rjk2> monorail*
207 2011-12-26 20:31:47 <lolcat> ...
208 2011-12-26 20:31:55 <lolcat> Does any of you know of a single usefull tor site?
209 2011-12-26 20:32:04 <lolcat> That isn't silk road
210 2011-12-26 20:32:08 <lolcat> I don't need drugs
211 2011-12-26 20:32:27 <rjk2> useful? ... not really
212 2011-12-26 20:32:38 <lolcat> Entertaining?
213 2011-12-26 20:32:41 <copumpkin> lolcat: you can buy musical instruments on there, too
214 2011-12-26 20:32:50 <copumpkin> and potting supplies
215 2011-12-26 20:32:58 <copumpkin> except I think the musical instruments are fake
216 2011-12-26 20:33:02 <lolcat> I don't want to buy anything
217 2011-12-26 20:33:40 <gmaxwell> lolcat: Tor hidden services are pretty obscure, it seems that most tor use is just to access the regular internet with improved anonymity.
218 2011-12-26 20:33:56 <lolcat> I feel it is sort of slow
219 2011-12-26 20:34:08 <lolcat> When I get home I will setup my other laptop with encryption + tor
220 2011-12-26 20:34:18 <rjk2> ...yeah its going to be slow
221 2011-12-26 20:35:00 <lolcat> I don't like that
222 2011-12-26 20:35:07 <lolcat> I have two 100mbit/s connections at home
223 2011-12-26 20:35:10 <gmaxwell> ... Then don't use it! :)
224 2011-12-26 20:35:54 <rjk2> the dismal throughput and latency is because of slow peers
225 2011-12-26 20:36:02 <rjk2> and overhead
226 2011-12-26 20:36:04 <lolcat> I want anonymity on one computer
227 2011-12-26 20:37:28 <lolcat> I think
228 2011-12-26 20:37:35 <lolcat> I SOO want servers
229 2011-12-26 21:30:21 <CIA-100> libbitcoin: genjix * rdcf6c592d9bb /src/blockchain/bdb/ (4 files): Added data_helpers include for bdb blockchain service http://tinyurl.com/7v73pzd
230 2011-12-26 21:30:22 <CIA-100> libbitcoin: genjix * r2650b1e7075b /doc/organize/ (begin.svg index.html pool.png tree.png): Merge branch 'master' of gitorious.org:libbitcoin/libbitcoin http://tinyurl.com/7mutnoy
231 2011-12-26 21:40:16 <CIA-100> bitcoin: Con Kolivas * rae78620292b9 cgminer/main.c: Show which pool is unresponsive on startup. http://tinyurl.com/d6jmgk8
232 2011-12-26 21:50:11 <CIA-100> bitcoin: Con Kolivas * r291f1749d0b7 cgminer/main.c: Ensure the correct pool information goes with the longpoll work item. http://tinyurl.com/7rhgkwh
233 2011-12-26 22:30:10 <CIA-100> bitcoin: Con Kolivas * reee665895d49 cgminer/main.c: Save config options for GPUs only if there are GPU devices. http://tinyurl.com/cdnmtcp
234 2011-12-26 22:40:09 <CIA-100> bitcoin: Con Kolivas * ra51514d9d13c cgminer/ (6 files): White space cleanup. http://tinyurl.com/7qmvyb6
235 2011-12-26 22:57:47 <roconnor> Oh god, you guys are going forward with that OP_EVAL craziness
236 2011-12-26 23:03:54 <luke-jr> roconnor: &
237 2011-12-26 23:04:32 <roconnor> last time I check it wasn't very well though through had unknown security implications and required a big hack to stop infinite loops.
238 2011-12-26 23:07:12 <luke-jr> then maybe you should bring it up on the ML
239 2011-12-26 23:08:31 <roconnor> I have nothing more to add than what is already on https://bitcointalk.org/index.php?topic=46538.0;all
240 2011-12-26 23:19:14 <roconnor> ugh, and it is so ill defined
241 2011-12-26 23:19:21 <roconnor> only defined by the reference implementation
242 2011-12-26 23:19:25 <roconnor> great
243 2011-12-26 23:28:37 <roconnor> if (!EvalScriptInner(stack, subscript, txTo, nIn, nHashType,
244 2011-12-26 23:28:38 <roconnor> pbegincodehash, pendcodehash, nOpCount, nSigOpCount, fStrictOpEval, nRecurseDepth++))
245 2011-12-26 23:28:52 <roconnor> this nRecursionDepth stays incremented after executing an OP_EVAL?
246 2011-12-26 23:29:58 <roconnor> so you cannot have 3 OP_EVAL even if they are not nested?
247 2011-12-26 23:30:43 <luke-jr> roconnor: report a bug, quick
248 2011-12-26 23:30:57 <roconnor> Without a spec nothing is a bug
249 2011-12-26 23:31:08 <roconnor> how can I say it is wrong?
250 2011-12-26 23:31:45 <luke-jr> you can write up a list of "issues" and post to the ML
251 2011-12-26 23:31:49 <luke-jr> and get a response at least
252 2011-12-26 23:32:04 <roconnor> Even if I am able to find an unknown security problem, all they will do is just fix it rather than pause and think, "hmm, maybe we shouldn't rush into this and actually think about what we are doing"
253 2011-12-26 23:32:11 <luke-jr> more relevant though, why would you ever need non-recursing OP_EVALs?
254 2011-12-26 23:32:32 <luke-jr> roconnor: I will support a delay.
255 2011-12-26 23:32:50 <luke-jr> roconnor: I want to see pubkey extraction added in OP_EVAL anyway
256 2011-12-26 23:33:13 <roconnor> luke-jr: heh, as a predominant miner, you have a lot of sway :)
257 2011-12-26 23:33:33 <luke-jr> I think a well-written email laying out many different possible issues, and concluding a delay is needed, would go far.
258 2011-12-26 23:33:48 <luke-jr> in the end, it will likely come down to Tycho's whim
259 2011-12-26 23:33:56 <roconnor> luke-jr: okay, I will look into it
260 2011-12-26 23:34:04 <roconnor> true what you say about Tycho
261 2011-12-26 23:34:10 <luke-jr> maybe CC Tycho and the other big pool owners
262 2011-12-26 23:35:07 <sipa> roconnor: looks like a bug to me
263 2011-12-26 23:35:22 <luke-jr> roconnor: the sooner the better; 0.6 is planned to be released around that OP_EVAL cutoff date
264 2011-12-26 23:35:36 <sipa> and nonrecursing opeval is useful
265 2011-12-26 23:35:38 <roconnor> maybe if I report the bug at the last minute, it will more likely result in a delay :P
266 2011-12-26 23:35:50 <luke-jr> sipa: any reason you can't just concat the code before a single OP_EVAL?
267 2011-12-26 23:35:56 <roconnor> oh right, I didn't understand what luke-jr meant by a non-recursing OP_EVAL
268 2011-12-26 23:35:57 <luke-jr> roconnor: I doubt it.
269 2011-12-26 23:36:56 <roconnor> sipa: what exception is thrown when a script fails to deserialize?  Is it caught by the evaluator?
270 2011-12-26 23:37:43 <sipa> roconnor: good question
271 2011-12-26 23:38:05 <sipa> the scripting system is a part of the code i rarely touched
272 2011-12-26 23:38:13 <roconnor> oh okay
273 2011-12-26 23:43:34 <gribble> The operation succeeded.
274 2011-12-26 23:43:34 <sipa> ;;later tell gavinandresen roconnor found that the op_eval implementation does't support more than two op_eval's, even non-recursing. is this intentional?
275 2011-12-26 23:45:09 <CIA-100> bitcoin: Con Kolivas * r5e2e2f282d1f cgminer/main.c: Only use GPU management menu item if GPU threads exist. http://tinyurl.com/d65uzgg
276 2011-12-26 23:45:11 <CIA-100> bitcoin: Con Kolivas * r2257b5023a96 cgminer/ (main.c miner.h util.c): Simplify longpoll changeover to just check which pool it should grab its next longpoll from. This should prevent locking hangs and thread cancellation crashes. http://tinyurl.com/ch3bokh
277 2011-12-26 23:45:53 <roconnor> sipa: oh wow, scripts are decoded on the fly
278 2011-12-26 23:46:17 <sipa> yes :(
279 2011-12-26 23:46:19 <roconnor> OP_INVALIDOPCODE is returned when it cannot deserialize
280 2011-12-26 23:46:26 <sipa> ok
281 2011-12-26 23:46:54 <luke-jr> sipa: do you pull anything? :P
282 2011-12-26 23:47:06 <roconnor> I think this is still compatible with what I do since any valid script must process every op code, even scripts using IF THEN ELSE
283 2011-12-26 23:48:07 <gmaxwell> oh boy. that could be pretty gnarly.
284 2011-12-26 23:48:15 <luke-jr> roconnor: you're a developer of another implementation?
285 2011-12-26 23:48:18 <gmaxwell> (I mean getting identical behavior wrt failing cases)
286 2011-12-26 23:48:25 <roconnor> luke-jr: more or less
287 2011-12-26 23:48:40 <luke-jr> roconnor: I suspect you have quite a bit of influence on Gavin regarding protocol changes, then
288 2011-12-26 23:48:47 <sipa> luke-jr: rarely
289 2011-12-26 23:48:51 <roconnor> luke-jr: I don't know about that
290 2011-12-26 23:49:20 <luke-jr> roconnor: I seem to recall him asking about other implementor's concerns on protocol changes
291 2011-12-26 23:49:29 <luke-jr> explicitly
292 2011-12-26 23:49:41 <sipa> i'm quite sure what you found is not intentional
293 2011-12-26 23:49:51 <roconnor> sipa: I might have a bug: if I find an unrecoginzed OP_CODE I fail, but I think maybe unrecognized opcodes may just be ignored in bitcoin
294 2011-12-26 23:50:13 <sipa> depends
295 2011-12-26 23:50:21 <roconnor> oh there is a default: return false
296 2011-12-26 23:50:25 <sipa> op_nopX are ignored
297 2011-12-26 23:50:38 <roconnor> okay, so unknown codes fail
298 2011-12-26 23:50:41 <roconnor> that is good
299 2011-12-26 23:50:44 <sipa> but unknown ones trigger and error, afaik
300 2011-12-26 23:50:51 <gmaxwell> luke-jr: roconnor's work should eventually result in a certifyable implementation but perhaps not code anyone (except perhaps miners and observation nodes) will run.
301 2011-12-26 23:51:21 <luke-jr> gmaxwell: I don't see a difference.
302 2011-12-26 23:51:28 <luke-jr> unless it's Ruby
303 2011-12-26 23:51:32 <luke-jr> Ruby should be boycotted
304 2011-12-26 23:51:33 <luke-jr> <.<
305 2011-12-26 23:52:40 <gmaxwell> IIRC his work is haskell now, though I hope it will give birth to a COQ version with formal statements about its correctness. :)
306 2011-12-26 23:52:42 <roconnor> I've been trying to think of a clever way of handling if_else_end, but I can't think of anything more clever than what bitcoin does :)
307 2011-12-26 23:53:10 <tower> squirrel: hey, this place
308 2011-12-26 23:53:36 <luke-jr> Haskell is fine
309 2011-12-26 23:54:10 <sipa> without haskell i wouldn't be here :)
310 2011-12-26 23:57:23 <gmaxwell> I'm hopeful in the future that there is some interface so that miners could test a candidate blocks/transactions against several implementations and throw out stuff that doesn't validate in all of them so that bugs couldn't cause forks.
311 2011-12-26 23:57:51 <luke-jr> gmaxwell: not the right solution :P
312 2011-12-26 23:58:03 <luke-jr> gmaxwell: test every possible block against them all.
313 2011-12-26 23:58:30 <gmaxwell> Okay, in the land of finite computation we do things a bit differently. ;)
314 2011-12-26 23:58:55 <cjdelisle> hah
315 2011-12-26 23:59:43 <TuxBlackEdo> reading you two talk makes me feel like a complete noob
316 2011-12-26 23:59:54 <luke-jr> gmaxwell: quantum computing :D
317 2011-12-26 23:59:58 <luke-jr> gmaxwell: LLVM has it