1 2012-01-01 00:03:23 wasabi1 has joined
2 2012-01-01 00:03:48 bitcoinbulletin has quit (Quit: bitcoinbulletin)
3 2012-01-01 00:04:10 wasabi2 has quit (Ping timeout: 240 seconds)
4 2012-01-01 00:06:32 theorbtwo has joined
5 2012-01-01 00:07:40 theorb has quit (Ping timeout: 255 seconds)
6 2012-01-01 00:11:17 b4epoche_ has joined
7 2012-01-01 00:12:08 b4epoche has quit (Ping timeout: 248 seconds)
8 2012-01-01 00:12:08 b4epoche_ is now known as b4epoche
9 2012-01-01 00:14:18 onelineproof has quit (Quit: Leaving.)
10 2012-01-01 00:15:22 Raziel_ has joined
11 2012-01-01 00:17:21 RazielZ has quit (Read error: Operation timed out)
12 2012-01-01 00:22:07 [\\\] is now known as imsaguy
13 2012-01-01 00:23:32 bitcoinbulletin has joined
14 2012-01-01 00:27:59 theymos has quit (Remote host closed the connection)
15 2012-01-01 00:43:52 dissipate has joined
16 2012-01-01 00:43:52 dissipate has quit (Changing host)
17 2012-01-01 00:43:52 dissipate has joined
18 2012-01-01 00:46:19 datagutt has quit (Quit: Computer has gone to sleep.)
19 2012-01-01 00:49:21 MimeNarrator has quit (Remote host closed the connection)
20 2012-01-01 00:53:33 vsrinivas has quit (Quit: leaving)
21 2012-01-01 00:54:59 theorb has joined
22 2012-01-01 00:55:11 theorbtwo has quit (Ping timeout: 244 seconds)
23 2012-01-01 01:13:24 Asthrou has joined
24 2012-01-01 01:19:19 h4ckm3 has joined
25 2012-01-01 01:24:52 abbe has quit (Read error: Connection reset by peer)
26 2012-01-01 01:25:37 vsrinivas has joined
27 2012-01-01 01:27:40 MobiusL has quit (Quit: Leaving)
28 2012-01-01 01:27:50 mizerydearia has quit (Ping timeout: 240 seconds)
29 2012-01-01 01:29:31 mizerydearia has joined
30 2012-01-01 01:30:35 abbe_ has joined
31 2012-01-01 01:34:14 eoss has quit (Quit: Leaving)
32 2012-01-01 01:34:25 abbe_ has quit (Changing host)
33 2012-01-01 01:34:25 abbe_ has joined
34 2012-01-01 01:34:28 abbe_ is now known as abbe
35 2012-01-01 01:34:53 JZavala has quit (Ping timeout: 240 seconds)
36 2012-01-01 01:40:14 Raziel_ has quit (Quit: Leaving)
37 2012-01-01 01:40:58 MobiusL has joined
38 2012-01-01 01:58:27 cryptoxchange has quit (Quit: Leaving)
39 2012-01-01 02:11:37 pickett_ has quit (Ping timeout: 276 seconds)
40 2012-01-01 02:15:33 Guest15474 is now known as MagicalTux
41 2012-01-01 02:15:38 MagicalTux has quit (Changing host)
42 2012-01-01 02:15:38 MagicalTux has joined
43 2012-01-01 02:16:02 copumpkin has joined
44 2012-01-01 02:21:58 TeamColtra has joined
45 2012-01-01 02:22:18 iocor has joined
46 2012-01-01 02:23:16 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|Just some out-loud thinking: Would it be possible to create a system from the bit coin system, but injects time into the coins, and give the coins a two month lifespan?
47 2012-01-01 02:23:44 <nanotube> TeamColtra|mba: yes
48 2012-01-01 02:23:59 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|The only major problem I find with bit coin, is that there is less encouragement to SPEND your bit coins as there is encouragement to horde them.
49 2012-01-01 02:24:39 <nanotube> the only major problem with your system is that nobody will want to use it
50 2012-01-01 02:24:51 <nanotube> i think bitcoin wins :)
51 2012-01-01 02:24:52 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|I guess the problem becomes what about the guy who is holding onto the coin at the end of the two months. >.>
52 2012-01-01 02:26:52 <luke-jr> TeamColtra|mba: why do you assume that's a problem?
53 2012-01-01 02:27:49 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|Because it's not a currency at that point, it's an artificially inflated gold substitute
54 2012-01-01 02:28:07 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|artificially inflated by the people hording
55 2012-01-01 02:28:33 <luke-jr> you're assuming gold cannot be used as currency
56 2012-01-01 02:29:13 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|it can be, and has been in the past⦠however⦠the same problem happened is that the top %s who could afford it, have bought a large majority of it
57 2012-01-01 02:29:53 <luke-jr> so?
58 2012-01-01 02:30:07 <luke-jr> that's not exactly a problem.
59 2012-01-01 02:30:37 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|It keeps power with the top %s of society, instead of shifting the power to the middle class which an abundance based economy would do
60 2012-01-01 02:31:00 <luke-jr> not really, no.
61 2012-01-01 02:31:18 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|Explain?
62 2012-01-01 02:31:33 <luke-jr> "the 10 richest people are the richest" is an oxymoron
63 2012-01-01 02:32:19 <luke-jr> the problem you seem to be talking about is industrialization, and entirely unrelated
64 2012-01-01 02:33:30 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|Eventually, if bit coin takes off in popularity -- the richest people / groups will start buying up bitcoins and acquiring them until the hold a substantial portion of them. Considering there is a limited number in existence we would be forced to eventually borrow from them, or create another currency again.
65 2012-01-01 02:34:07 <luke-jr> if they have 90% of the money now, they have 90% of the money when we switch to Bitcoin
66 2012-01-01 02:34:11 <luke-jr> nothing changes
67 2012-01-01 02:34:12 <luke-jr> nor should it
68 2012-01-01 02:34:29 <luke-jr> (at least, *Bitcoin* shouldn't be the game changer)
69 2012-01-01 02:35:18 <luke-jr> what forces people to borrow is the central bank system, and usury.
70 2012-01-01 02:35:26 <luke-jr> Bitcoin eliminates the central bank system.
71 2012-01-01 02:35:37 <luke-jr> Bitcoin cannot eliminate usury.
72 2012-01-01 02:35:54 <vsrinivas> such a system would be ... difficult.
73 2012-01-01 02:36:04 <luke-jr> vsrinivas: ?
74 2012-01-01 02:36:31 <vsrinivas> eliminating borrowing.
75 2012-01-01 02:36:43 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|It centralizes bitcoins elsewhere. Once the top %s own a vast majority of bit coins they will create systems which bring bit coins through them
76 2012-01-01 02:36:52 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|yes, you CAN trade them outside of the central system
77 2012-01-01 02:37:39 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|but you CAN go to other places than wal*mart, but they have been able to hurt everyone around them to keep making their prices below what anyone else can offer and brings people in against their moral judgement
78 2012-01-01 02:37:42 <luke-jr> vsrinivas: well, borrowing would also not be a problem without usury.
79 2012-01-01 02:38:32 <vsrinivas> okay. are you defining usury as any interest? or very high interest? ; either way, very difficult to eliminiate via technical means...
80 2012-01-01 02:38:35 <luke-jr> TeamColtra|mba: well, the State's duty comes in then
81 2012-01-01 02:38:40 <luke-jr> vsrinivas: any interest.
82 2012-01-01 02:38:55 <luke-jr> vsrinivas: sure, like I said, Bitcoin *cannot* eliminate it
83 2012-01-01 02:39:03 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|Again, i recognize an expiring bit coin isn't that feasible but think about this:
84 2012-01-01 02:39:15 <vsrinivas> no argument there.
85 2012-01-01 02:39:21 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|If I just generated a bit coin, and I know it's going to expire in a month⦠what am I going to do with it?
86 2012-01-01 02:39:38 <luke-jr> TeamColtra|mba: people should not be encouraged to spend money
87 2012-01-01 02:39:46 <luke-jr> hoarding is a good thing
88 2012-01-01 02:39:56 <luke-jr> aka SAVING
89 2012-01-01 02:39:58 <vsrinivas> i think we call that 'saving'
90 2012-01-01 02:40:02 <luke-jr> âº
91 2012-01-01 02:41:03 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|Yes, but savings has only become needed due to massive government/corporation hoarding. Look at the ye old grain based economies, they were highly successful for the villagers
92 2012-01-01 02:41:18 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|of course, in the end, it was good because the last person who owns the grain could eat it
93 2012-01-01 02:41:28 <luke-jr> â¦
94 2012-01-01 02:41:41 <luke-jr> savings hasn't "become needed"
95 2012-01-01 02:41:45 <luke-jr> it's always been needed
96 2012-01-01 02:41:52 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|For what?
97 2012-01-01 02:41:59 <luke-jr> for buying a house, for instance.
98 2012-01-01 02:42:09 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|You keep paying for your house, and then it's paid off
99 2012-01-01 02:42:13 <luke-jr> no
100 2012-01-01 02:42:21 <luke-jr> that's the new system which is bad
101 2012-01-01 02:42:25 <luke-jr> that's borrowing-based
102 2012-01-01 02:42:55 <luke-jr> the right way: you save up money, and buy the house outright
103 2012-01-01 02:43:58 mcorlett has joined
104 2012-01-01 02:44:01 <[Tycho]> I would never buy any cryptocurrency with artificially limited lifespan :)
105 2012-01-01 02:44:20 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|[Tycho]: yeah I have already stated that it wouldn't really work for a cryptocurrency
106 2012-01-01 02:44:36 <luke-jr> [Tycho]: I would, provided you could 'refresh' it.
107 2012-01-01 02:44:54 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|because the difference between grain and crypto currency would be the last person in line can eat it
108 2012-01-01 02:44:56 <[Tycho]> luke-jr: there is no point in that.
109 2012-01-01 02:45:03 <luke-jr> [Tycho]: yes there is
110 2012-01-01 02:45:13 <luke-jr> [Tycho]: it prevents permanent destruction
111 2012-01-01 02:45:37 <[Tycho]> If you can refresh it then it won't stop hoarding, but adds chances to accidentally lose it.
112 2012-01-01 02:45:49 <[Tycho]> Permanent destruction doesn't matters.
113 2012-01-01 02:46:22 <vsrinivas> hmm if bitcoin were edible mining would be a whole different game.
114 2012-01-01 02:46:28 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|unless it took some kind of cycle system where people with massive quantities would have to put much more work into preserving their wealth than someone with a little
115 2012-01-01 02:46:41 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|I bet bit coins would be delicious
116 2012-01-01 02:47:34 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|like your bit coins could be refreshed through verifying blocks
117 2012-01-01 02:48:45 <luke-jr> TeamColtra|mba: you sound jealous.
118 2012-01-01 02:48:55 <luke-jr> TeamColtra|mba: like you want to steal from the rich
119 2012-01-01 02:49:19 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|Not at all⦠I just want money to be in flow.
120 2012-01-01 02:49:29 <luke-jr> well that's stupid
121 2012-01-01 02:49:34 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|Because I feel that it would benefit the middle class more
122 2012-01-01 02:49:47 <luke-jr> the middle class has no reason to be benefit more.
123 2012-01-01 02:50:09 <luke-jr> if I live on $100/yr, and save up enough to buy a house, I shouldn't be penalized compared to the idiot who spends every paycheck on drugs the day he gets it
124 2012-01-01 02:50:49 Joric has joined
125 2012-01-01 02:51:19 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|Maybe the system needs to change to allow you to get a house without borrowing? :P But that just makes me sound communist (not that I am far from it)
126 2012-01-01 02:51:48 <luke-jr> TeamColtra|mba: yeah, that's called SAVING
127 2012-01-01 02:52:09 <luke-jr> TeamColtra|mba: you're basically saying to penalize people for being responsible.
128 2012-01-01 02:52:12 <luke-jr> guess what that leads to
129 2012-01-01 02:52:57 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|I have no problem with being rich, I personally make more than average for my area⦠and I do save money too, actually I save more each month than I spend. However, how does that help anyone else other than myself?
130 2012-01-01 02:54:20 Clipse has joined
131 2012-01-01 02:55:34 <luke-jr> TeamColtra|mba: why should it?
132 2012-01-01 02:55:50 <luke-jr> the work you do hopefully helps the people paying you
133 2012-01-01 02:58:35 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|Because happiness comes from contributing TO your society, not by taking from it. I am trying to find the ted talk on the matter, but by giving back to society you feel better yourself. Furthermore, if we are all constantly spending that just means more money that is going to come to you
134 2012-01-01 02:59:36 <luke-jr> nothing prevents you from contributing more
135 2012-01-01 02:59:40 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|I work at a communications company, if I spend a thousand dollars then that will flow through the economy and give people money to pay for more cable/faster internet etc and just comes back to me
136 2012-01-01 03:00:00 <luke-jr> people need to spend money period.
137 2012-01-01 03:00:12 <luke-jr> but spending for the sake of spending, is called waste.
138 2012-01-01 03:00:17 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|but it only works at its best when everyone is constantly spending and the economy encourages it
139 2012-01-01 03:00:28 <luke-jr> I disagree.
140 2012-01-01 03:00:31 Guest19057 has joined
141 2012-01-01 03:00:36 <luke-jr> that's a waste-oriented economy
142 2012-01-01 03:01:17 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|That's assuming that you are spending it on goods, but as goods become cheaper and cheaper to produce money is going to start going more and more into services
143 2012-01-01 03:01:46 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|I don't need a maid, I can clean my own apartment. However, I have been considering getting a maid to come in monthly and clean for me
144 2012-01-01 03:01:53 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|or maybe even every other week
145 2012-01-01 03:02:14 <Joric> i'm about to move to moscow an average 1 room appartment costs $0.5m salaries are $4k tops
146 2012-01-01 03:02:19 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|if I had encouragement to do that, like my money disappearing I would have the maid.
147 2012-01-01 03:02:54 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|That's not "waste" it's just giving more money into the economy
148 2012-01-01 03:03:03 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|more jobs, more people happy, more people getting services
149 2012-01-01 03:03:41 Guest19057 is now known as coingenuity
150 2012-01-01 03:03:47 coingenuity has quit (Changing host)
151 2012-01-01 03:03:47 coingenuity has joined
152 2012-01-01 03:04:04 <luke-jr> I don't need a maid, I can clean my own apartment. <-- that's paying yourself to be a maid. which is cheaper?
153 2012-01-01 03:04:22 <luke-jr> if your skillset is higher than a maid's, you should be paid more, and therefore hiring a maid is cheaper
154 2012-01-01 03:05:03 <TeamColtra> mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|Of course, but if I am sitting at home doing nothing while the maid is cleaning⦠then that means my current value per hour is 0
155 2012-01-01 03:06:01 dissipate has quit (Ping timeout: 240 seconds)
156 2012-01-01 03:09:44 <luke-jr> TeamColtra|mba: so stop wasting time
157 2012-01-01 03:11:35 iocor has quit (Quit: Computer has gone to sleep.)
158 2012-01-01 03:28:25 <CIA-100> bitcoin: Con Kolivas * r638c8c526f36 cgminer/util.c: Make curl use a fresh connection if the json rpc call fails for any reason in case curl is relying on dead persistent connections. http://tinyurl.com/7b2yh7b
159 2012-01-01 03:28:32 TheSeven has quit (Disconnected by services)
160 2012-01-01 03:28:44 roconnor has quit (Remote host closed the connection)
161 2012-01-01 03:28:44 [7] has joined
162 2012-01-01 03:30:51 rdponticelli has quit (Remote host closed the connection)
163 2012-01-01 03:39:38 TeamColtra has quit (mba!~TeamColtr@S0106602ad072965e.vc.shawcable.net|Quit: TeamColtra|mba)
164 2012-01-01 03:41:55 midnightmagic has quit (Quit: quit)
165 2012-01-01 03:42:25 midnightmagic has joined
166 2012-01-01 03:48:25 <CIA-100> bitcoin: Con Kolivas * rd56e5ae61b22 cgminer/main.c: Force fresh curl connections on any detected rpc failure in case of dead persistent connections.. http://tinyurl.com/7o6yvor
167 2012-01-01 03:50:13 Guest64855 has quit (Changing host)
168 2012-01-01 03:50:13 Guest64855 has joined
169 2012-01-01 03:50:20 Guest64855 is now known as SomeoneWeird
170 2012-01-01 04:00:05 tyn has joined
171 2012-01-01 04:05:35 RobinPKR has quit (Read error: Connection reset by peer)
172 2012-01-01 04:05:35 jgarzik has joined
173 2012-01-01 04:05:44 jgarzik has quit (Changing host)
174 2012-01-01 04:05:44 jgarzik has joined
175 2012-01-01 04:06:37 MimeNarrator has joined
176 2012-01-01 04:07:20 RobinPKR has joined
177 2012-01-01 04:20:11 tyn has quit (Ping timeout: 240 seconds)
178 2012-01-01 04:22:38 b4epoche_ has joined
179 2012-01-01 04:24:07 b4epoche has quit (Ping timeout: 268 seconds)
180 2012-01-01 04:24:08 b4epoche_ is now known as b4epoche
181 2012-01-01 04:25:32 copumpkin has quit (Ping timeout: 255 seconds)
182 2012-01-01 04:25:58 copumpkin has joined
183 2012-01-01 04:27:27 agath has quit (Ping timeout: 248 seconds)
184 2012-01-01 04:27:58 dissipate has joined
185 2012-01-01 04:52:03 [Tycho] has quit (Remote host closed the connection)
186 2012-01-01 05:04:38 wasabi2 has joined
187 2012-01-01 05:04:54 justmoon has quit (Quit: Leaving)
188 2012-01-01 05:05:31 RobinPKR has quit (Ping timeout: 240 seconds)
189 2012-01-01 05:06:24 wasabi1 has quit (Ping timeout: 240 seconds)
190 2012-01-01 05:08:02 sytse has quit (Ping timeout: 240 seconds)
191 2012-01-01 05:15:15 sytse has joined
192 2012-01-01 05:16:58 theymos has joined
193 2012-01-01 05:17:38 Zarutian has quit (Quit: Zarutian)
194 2012-01-01 05:18:27 <CIA-100> bitcoin: Con Kolivas * ra4f6d5c68586 cgminer/NEWS: Update NEWS. http://tinyurl.com/7dcqmmz
195 2012-01-01 05:18:29 <CIA-100> bitcoin: Kano * r9bf0ad18a49b cgminer/main.c: Display pool in summary if only 1 pool http://tinyurl.com/7ny3rcf
196 2012-01-01 05:18:30 <CIA-100> bitcoin: Con Kolivas * r4f6cf3c8e9f2 cgminer/main.c: Merge pull request #65 from kanoi/master http://tinyurl.com/8xoq38j
197 2012-01-01 05:18:31 <CIA-100> bitcoin: Con Kolivas * rafa72ffec0a9 cgminer/main.c: Merge branch 'master' of github.com:ckolivas/cgminer http://tinyurl.com/7auf9op
198 2012-01-01 05:26:20 yorick has quit (Remote host closed the connection)
199 2012-01-01 05:26:32 yorick has joined
200 2012-01-01 05:33:56 WakiMiko has joined
201 2012-01-01 05:36:51 WakiMiko_ has quit (Ping timeout: 240 seconds)
202 2012-01-01 05:44:04 BurtyB has quit (Ping timeout: 240 seconds)
203 2012-01-01 05:45:51 BurtyB has joined
204 2012-01-01 05:59:33 Joric has quit (Ping timeout: 252 seconds)
205 2012-01-01 06:04:05 BurtyB has quit (Ping timeout: 255 seconds)
206 2012-01-01 06:06:58 BurtyB has joined
207 2012-01-01 06:11:44 twobitcoins has quit (Quit: Leaving)
208 2012-01-01 06:18:32 Clipse has quit (Read error: Connection reset by peer)
209 2012-01-01 06:26:01 BurtyB has quit (Ping timeout: 252 seconds)
210 2012-01-01 06:28:49 BurtyB has joined
211 2012-01-01 06:46:04 EPiSKiNG- has quit (Ping timeout: 240 seconds)
212 2012-01-01 06:50:37 genjix has joined
213 2012-01-01 06:51:30 <genjix> hi
214 2012-01-01 07:00:45 <nanotube> hiya genjix :)
215 2012-01-01 07:04:25 <genjix> hey sup
216 2012-01-01 07:04:39 <nanotube> nm just hangin, thinking of going to sleep :)
217 2012-01-01 07:05:16 <genjix> i just fell asleep at my keyboard a few hours ago >_>
218 2012-01-01 07:05:21 <nanotube> heh
219 2012-01-01 07:05:22 <genjix> just got up
220 2012-01-01 07:08:47 BlueMatt has joined
221 2012-01-01 07:09:38 <genjix> i wonder why the std::regex impl is so broken in g++
222 2012-01-01 07:09:49 <genjix> i mean couldnt they just copy the boost one over?
223 2012-01-01 07:10:37 <BlueMatt> genjix: what are you doing online on new years?
224 2012-01-01 07:10:45 <BlueMatt> what are you doing programming on new years?
225 2012-01-01 07:11:23 <genjix> ah i have no time for new years
226 2012-01-01 07:11:29 <genjix> :(
227 2012-01-01 07:11:56 <BlueMatt> that busy with bitcoinj?
228 2012-01-01 07:12:01 <genjix> actually im not too worried since bitcoin is fun
229 2012-01-01 07:12:01 <BlueMatt> since when does bitcoinj have timelines?
230 2012-01-01 07:13:04 <genjix> :( = social pressure to imagine i have regrets lol
231 2012-01-01 07:15:01 Joric has joined
232 2012-01-01 07:41:32 toffoo has quit ()
233 2012-01-01 07:48:18 theymos has quit (Remote host closed the connection)
234 2012-01-01 08:06:58 wizkid057 has quit (Quit: Leaving)
235 2012-01-01 08:08:19 wizkid057 has joined
236 2012-01-01 08:10:53 BlueMatt has quit (Quit: Ex-Chat)
237 2012-01-01 08:11:30 h4ckm3 has quit (Ping timeout: 252 seconds)
238 2012-01-01 08:12:54 Diablo-D3 has quit (Ping timeout: 240 seconds)
239 2012-01-01 08:17:08 pickett has joined
240 2012-01-01 08:25:22 molecular has quit (Ping timeout: 240 seconds)
241 2012-01-01 08:26:00 molecular has joined
242 2012-01-01 08:28:47 gwillen is now known as tra4n
243 2012-01-01 08:29:06 tra4n is now known as gwillen
244 2012-01-01 08:34:20 twobitcoins has joined
245 2012-01-01 08:35:08 b4epoche_ has joined
246 2012-01-01 08:36:12 b4epoche has quit (Ping timeout: 255 seconds)
247 2012-01-01 08:36:12 b4epoche_ is now known as b4epoche
248 2012-01-01 08:41:53 pickett has quit (Remote host closed the connection)
249 2012-01-01 08:48:28 <CIA-100> libbitcoin: genjix * rb59738467c54 / (5 files in 4 dirs): Lookup external IP address using dyndns and whatismyip http://tinyurl.com/7nftxrj
250 2012-01-01 09:01:04 imsaguy is now known as [\\\]
251 2012-01-01 09:06:21 wasabi1 has joined
252 2012-01-01 09:08:05 wasabi2 has quit (Ping timeout: 240 seconds)
253 2012-01-01 09:10:15 RazielZ has joined
254 2012-01-01 09:19:02 erle- has joined
255 2012-01-01 09:21:59 Turingi has joined
256 2012-01-01 09:22:00 Turingi has quit (Changing host)
257 2012-01-01 09:22:00 Turingi has joined
258 2012-01-01 09:38:04 grondilu has joined
259 2012-01-01 09:38:26 <CIA-100> bitcoin: Con Kolivas * r743d81b36bfe cgminer/ (Makefile.am configure.ac main.c): Adjust column width of A/R/HW to be the maximum of any device and align them. http://tinyurl.com/8yufbrs
260 2012-01-01 09:38:27 <CIA-100> bitcoin: Con Kolivas * r30e6b34ef012 cgminer/NEWS: Update NEWS. http://tinyurl.com/88bm3w4
261 2012-01-01 09:38:28 <CIA-100> bitcoin: Con Kolivas * rd515d318547b cgminer/configure.ac: Bump version number to 2.1.1 http://tinyurl.com/6odzx6l
262 2012-01-01 09:38:33 <grondilu> anyone knows how to open the database with Perl? I tried with DB_File with no success.
263 2012-01-01 09:39:19 <grondilu> (I get only one entry with 'main' key and a four bytes value)
264 2012-01-01 09:41:51 EPiSKiNG- has joined
265 2012-01-01 09:48:44 dissipate has quit (Ping timeout: 252 seconds)
266 2012-01-01 09:51:28 <CIA-100> bitcoinjs/node-bitcoin-p2p: Stefan Thomas master * r34161ba / lib/db/leveldb/storage.js : Fix affects index not considering coinbases. ... https://github.com/bitcoinjs/node-bitcoin-p2p/commit/34161ba2882972fd3133c6177424233c64874922
267 2012-01-01 09:51:29 <CIA-100> bitcoinjs/node-bitcoin-p2p: Stefan Thomas master * r3def7d5 / (lib/rpc/jsonrpcserver.js package.json): Enable JSON-RPC server authentication. - http://git.io/m6zTrw https://github.com/bitcoinjs/node-bitcoin-p2p/commit/3def7d5fd5dcc14b4624c9778cd51cce2574a8cc
268 2012-01-01 10:12:21 grondilu has quit (Quit: leaving)
269 2012-01-01 10:24:00 rlinfati has joined
270 2012-01-01 10:26:27 rlinfati has left ("Ex-Chat")
271 2012-01-01 10:31:34 marf_away has joined
272 2012-01-01 10:31:39 dissipate has joined
273 2012-01-01 10:56:55 dissipate has quit (Read error: Operation timed out)
274 2012-01-01 11:00:51 abragin has joined
275 2012-01-01 11:00:51 abragin has quit (Changing host)
276 2012-01-01 11:00:51 abragin has joined
277 2012-01-01 11:05:38 iocor has joined
278 2012-01-01 11:07:56 Joric has quit (Ping timeout: 252 seconds)
279 2012-01-01 11:12:39 Joric has joined
280 2012-01-01 11:12:40 Joric has quit (Changing host)
281 2012-01-01 11:12:40 Joric has joined
282 2012-01-01 11:26:07 da2ce7 has joined
283 2012-01-01 12:18:19 theorbtwo has joined
284 2012-01-01 12:19:06 theorb has quit (Ping timeout: 260 seconds)
285 2012-01-01 12:40:37 [Tycho] has joined
286 2012-01-01 12:45:06 Clipse has joined
287 2012-01-01 12:46:08 b4epoche_ has joined
288 2012-01-01 12:47:21 b4epoche has quit (Ping timeout: 276 seconds)
289 2012-01-01 12:47:21 b4epoche_ is now known as b4epoche
290 2012-01-01 12:53:32 chrisb__ has joined
291 2012-01-01 12:57:10 K0lky has quit (Quit: Bye bye!)
292 2012-01-01 13:02:58 bakh has joined
293 2012-01-01 13:08:16 wasabi2 has joined
294 2012-01-01 13:09:40 abragin has quit (Ping timeout: 252 seconds)
295 2012-01-01 13:09:50 abragin has joined
296 2012-01-01 13:09:50 abragin has quit (Changing host)
297 2012-01-01 13:09:51 abragin has joined
298 2012-01-01 13:10:13 wasabi1 has quit (Ping timeout: 240 seconds)
299 2012-01-01 13:11:40 Kolky has joined
300 2012-01-01 13:18:33 da2ce7 has quit (Ping timeout: 276 seconds)
301 2012-01-01 13:19:12 abragin has quit (Read error: Connection reset by peer)
302 2012-01-01 13:20:49 abragin has joined
303 2012-01-01 13:23:44 RobinPKR has joined
304 2012-01-01 13:24:16 da2ce7 has joined
305 2012-01-01 13:27:12 datagutt has joined
306 2012-01-01 13:41:26 Clipse has quit (Ping timeout: 240 seconds)
307 2012-01-01 13:42:04 jarpiain has quit (Quit: leaving)
308 2012-01-01 13:46:16 da2ce7 has joined
309 2012-01-01 13:47:09 da2ce7 has quit (Ping timeout: 276 seconds)
310 2012-01-01 13:47:15 da2ce7 is now known as 2!~da2ce7@gateway/tor-sasl/da2ce7|da2ce7
311 2012-01-01 13:51:24 Fireball has joined
312 2012-01-01 13:51:25 abragin has quit (Ping timeout: 240 seconds)
313 2012-01-01 13:51:29 Fireball has quit (Changing host)
314 2012-01-01 13:51:29 Fireball has joined
315 2012-01-01 13:58:21 [Tycho] has quit (Remote host closed the connection)
316 2012-01-01 14:21:59 da2ce7 has joined
317 2012-01-01 14:22:54 da2ce7 has quit (Ping timeout: 276 seconds)
318 2012-01-01 14:26:33 jarpiain has joined
319 2012-01-01 14:37:32 da2ce7 is now known as 2!~da2ce7@gateway/tor-sasl/da2ce7|da2ce7
320 2012-01-01 14:59:35 dvide has joined
321 2012-01-01 15:07:26 jrmithdobbs has quit (Ping timeout: 252 seconds)
322 2012-01-01 15:09:30 jrmithdobbs has joined
323 2012-01-01 15:14:54 da2ce7 has quit (Ping timeout: 276 seconds)
324 2012-01-01 15:19:04 slush has quit (Ping timeout: 240 seconds)
325 2012-01-01 15:20:47 onelineproof has joined
326 2012-01-01 15:26:12 Diablo-D3 has joined
327 2012-01-01 15:26:17 bakh has quit (Ping timeout: 252 seconds)
328 2012-01-01 15:28:05 rdponticelli has joined
329 2012-01-01 15:35:09 slush has joined
330 2012-01-01 15:35:17 slush has quit (Changing host)
331 2012-01-01 15:35:17 slush has joined
332 2012-01-01 15:45:25 [Tycho] has joined
333 2012-01-01 15:56:47 Xunie has quit (Read error: Connection reset by peer)
334 2012-01-01 16:00:00 pickett has joined
335 2012-01-01 16:03:28 MC1984 has quit (Read error: Connection reset by peer)
336 2012-01-01 16:03:44 HaltingState has quit (Ping timeout: 240 seconds)
337 2012-01-01 16:03:45 MC1984 has joined
338 2012-01-01 16:19:47 <edcba> ;;bc,mtgox
339 2012-01-01 16:19:48 <gribble> {"ticker":{"high":5.17995,"low":4.536,"avg":4.802742198,"vwap":4.856152458,"vol":76323,"last_all":5.1739,"last_local":5.1739,"last":5.1739,"buy":5.14388,"sell":5.1739}}
340 2012-01-01 16:31:28 da2ce7 has joined
341 2012-01-01 16:34:33 Insti has quit (Ping timeout: 244 seconds)
342 2012-01-01 16:36:18 Insti has joined
343 2012-01-01 16:37:54 da2ce7 has joined
344 2012-01-01 16:38:07 da2ce7 has quit (Ping timeout: 276 seconds)
345 2012-01-01 16:39:29 Clipse has joined
346 2012-01-01 16:47:28 SomeoneWeird has quit (Ping timeout: 244 seconds)
347 2012-01-01 16:50:11 chrisb__ has quit (Quit: Ex-Chat)
348 2012-01-01 16:50:59 marf_away has quit (Ping timeout: 252 seconds)
349 2012-01-01 16:53:18 Guest30840 has joined
350 2012-01-01 16:56:24 p0s has joined
351 2012-01-01 16:57:04 b4epoche_ has joined
352 2012-01-01 16:57:48 b4epoche has quit (Ping timeout: 244 seconds)
353 2012-01-01 16:57:48 b4epoche_ is now known as b4epoche
354 2012-01-01 17:08:56 iocor has quit (Quit: Computer has gone to sleep.)
355 2012-01-01 17:09:54 wasabi1 has joined
356 2012-01-01 17:09:59 erle- has quit (Quit: erle-)
357 2012-01-01 17:11:45 wasabi2 has quit (Ping timeout: 252 seconds)
358 2012-01-01 17:28:44 danbri has quit (Read error: Connection reset by peer)
359 2012-01-01 17:29:33 danbri has joined
360 2012-01-01 17:35:06 Nicksasa has joined
361 2012-01-01 17:37:55 da2ce7 has quit (2!~da2ce7@gateway/tor-sasl/da2ce7|Ping timeout: 276 seconds)
362 2012-01-01 17:42:06 MC1984 has quit (Read error: Connection reset by peer)
363 2012-01-01 17:42:30 da2ce7 has joined
364 2012-01-01 17:42:58 MC1984 has joined
365 2012-01-01 17:52:53 d4de has joined
366 2012-01-01 17:52:53 d4de has quit (Changing host)
367 2012-01-01 17:52:53 d4de has joined
368 2012-01-01 17:56:38 hippich_ has joined
369 2012-01-01 18:10:31 wasabi2 has joined
370 2012-01-01 18:12:54 wasabi1 has quit (Ping timeout: 252 seconds)
371 2012-01-01 18:13:40 da2ce7 has quit (Ping timeout: 276 seconds)
372 2012-01-01 18:13:56 erle- has joined
373 2012-01-01 18:14:58 slush has quit (Ping timeout: 260 seconds)
374 2012-01-01 18:15:27 Guest30840 has quit (Ping timeout: 268 seconds)
375 2012-01-01 18:16:51 Cablesaurus has joined
376 2012-01-01 18:16:51 Cablesaurus has quit (Changing host)
377 2012-01-01 18:16:51 Cablesaurus has joined
378 2012-01-01 18:22:54 Zarutian has joined
379 2012-01-01 18:26:22 * Zarutian has been watching http://www.youtube.com/watch?v=hlWyTqL1hFA and has some ideas on how to reclaim "lost" coins
380 2012-01-01 18:26:23 justmoon has joined
381 2012-01-01 18:27:55 <Zarutian> basicly any unspent transaction older than (x * 52 * blocksPerWeek) relative to current block can be claimed by the miner of the next block
382 2012-01-01 18:28:31 Joric has quit ()
383 2012-01-01 18:28:31 <Zarutian> where x is 5, 10, 50 or any number between
384 2012-01-01 18:29:19 Guest34014 has joined
385 2012-01-01 18:29:54 chrisb__ has joined
386 2012-01-01 18:30:13 <Zarutian> that number has to be decided before this is implemented
387 2012-01-01 18:30:41 <Zarutian> any major holes in this proposed fix?
388 2012-01-01 18:31:04 da2ce7 has joined
389 2012-01-01 18:31:12 <sipa> Why do you consider it a fix>
390 2012-01-01 18:32:13 <sipa> Also, those coins should return to the to-be-mined pool, increasing all further mining income, instead of just allowing a single payout to the first lucky miner after that period
391 2012-01-01 18:32:43 <Zarutian> sipa: I consider it fix as it minimizes two things. Coins that cannot be spent because the owning address private key are lost and it cuts down what must be kept besides the merkel trees.
392 2012-01-01 18:33:02 <sipa> how do you know the keys are lost?
393 2012-01-01 18:33:52 <Zarutian> same way that a webserver knows that a session is lost. It times out only the time scale is much much bigger.
394 2012-01-01 18:34:13 <sipa> (i'm playing advocate of the devil here; the reason is that this may or not be considered an improvement by others, but there is no way it is going to be changed in the current bitcoin chain - that would be theft from all those who trusted their coins to be forever theirs)
395 2012-01-01 18:35:31 <Zarutian> I consider current bitcoin chain to be a hard-beta test so to speak and I apreaciate advocates of the devil
396 2012-01-01 18:36:22 <sipa> I believe it is something to be taken into account when a successor or alternative is designed.
397 2012-01-01 18:36:31 <da2ce7> how is the 0.6 bitcoin client comming along? there has been a few blog posts about it's features already
398 2012-01-01 18:36:51 <Zarutian> damn, I see I should upgrade from 0.3.15
399 2012-01-01 18:37:05 * Zarutian hasnt run bitcoin client for a while now.
400 2012-01-01 18:37:21 <sipa> da2ce7: I expect a release in a few weeks
401 2012-01-01 18:37:43 <da2ce7> :)
402 2012-01-01 18:38:17 <da2ce7> multibit is making large strides... it has been inproving at a remarkable rate.
403 2012-01-01 18:38:45 <Zarutian> sipa: hmm.. instead of a lucky miner getting all the "lost" coins how about it adds a claim that the miner now considers these unspent txnids to be invalid?
404 2012-01-01 18:39:17 <da2ce7> is these the mtgox miss-spent coins?
405 2012-01-01 18:39:42 <sipa> Zarutian: the only solution i know of requires a very large change in the mining income calculation
406 2012-01-01 18:39:44 <da2ce7> the coins that belong to addres 1 or somthing?
407 2012-01-01 18:40:11 <sipa> Zarutian: you're basically burning old coins, in what you suggest?
408 2012-01-01 18:40:41 <Zarutian> da2ce7: nope coins that havent been moved around for a long time as mesured in bitcoin chain blocks
409 2012-01-01 18:41:05 <sipa> That's a possibility as well - no need to have any special claim in the protocol if the rule is that coins that's havened moved for X blocks are simply invalid
410 2012-01-01 18:41:05 <Zarutian> sipa: yes, and aviable for remining
411 2012-01-01 18:41:33 <da2ce7> Zarutian: that sounds like a stupid idea... coins belong to the address they have been spent to.
412 2012-01-01 18:41:46 <sipa> Zarutian: the mining formula is just 50 BTC << 2int(height / 216000)
413 2012-01-01 18:41:49 <da2ce7> there is no concept of 'coin age' other than confimations.
414 2012-01-01 18:42:27 <sipa> Zarutian: if you want coins to become available for mining again, you need a very different formula that takes such reclaimed coins into account
415 2012-01-01 18:42:30 <Zarutian> I suspect that Satoshi Nakamoto might have intented btc to eventually vanish (hey it is a experimental protocol for frack's sake)
416 2012-01-01 18:42:58 <Zarutian> sipa: indeed
417 2012-01-01 18:43:01 <sipa> There are some implementation issues which make me believe not everything was intended to stay the way it currently is
418 2012-01-01 18:43:14 <da2ce7> Zarutian: well wouldn't he placed the commented out code in the client, like he did with other intented features.
419 2012-01-01 18:43:59 <Zarutian> da2ce7: noone is prescient enough to think of all posibilities before hand
420 2012-01-01 18:44:31 <Zarutian> da2ce7: for example the txn script language is inspired by Forth yet you can not have nesting IFs
421 2012-01-01 18:44:51 <Zarutian> (but that might be a mistake)
422 2012-01-01 18:45:18 <da2ce7> well I think that burning old coins has been decussed to death quite a few times; overall I personaly think that it is inmoral, and wouldn't respect any chain that impmneted it.
423 2012-01-01 18:45:48 <Zarutian> I am not discussing the morality of it, only how it might be implemented
424 2012-01-01 18:46:29 <sipa> I don't consider it a bad idea, but one that does need to be known in advance to anyone using the chain
425 2012-01-01 18:46:39 <da2ce7> ahh... well that is a totaly diffent questions... do you want to fork the current chain to make a new chain.
426 2012-01-01 18:46:51 <da2ce7> that would change how you would want to implment it.
427 2012-01-01 18:47:12 <Zarutian> da2ce7: that or do what namecoin did, start a new one.
428 2012-01-01 18:48:13 <da2ce7> I suspect the simpleist formular would be to dealay the 'reward half' point, but however long the burnt coins add up to.
429 2012-01-01 18:48:51 <da2ce7> so if you burn 100 coins... you will get 4 more blocks at 50 before you halve to 25.
430 2012-01-01 18:49:55 <Zarutian> and even there are a number of competeing cryptocurencies based on the ideas of bitcoin you can, often, put in transactions in each chain containing the hashes of the other chains. But that is another matter.
431 2012-01-01 18:51:03 <genjix> sipa: what do you think will be adopted for EVAL? i'm not in favour of lazy evaluation tbh
432 2012-01-01 18:51:09 <Zarutian> dac2ce7: what happens if someone burns 10 000 coins (lost his wallet or some such)? 400 more blocks before it halves?
433 2012-01-01 18:51:20 <sipa> genjix: what do you understand under lazy evaluation?
434 2012-01-01 18:51:37 <Zarutian> dac2ce7: or uneven number of coins? such as 97?
435 2012-01-01 18:51:48 <genjix> well justmoon said it has some problems
436 2012-01-01 18:52:00 <genjix> and i realised a whole bunch more
437 2012-01-01 18:52:22 <genjix> for instance it doesnt limit the number of sigops per block, just per transaction
438 2012-01-01 18:54:26 <sipa> I don't think it should be limited per block.
439 2012-01-01 18:54:43 <sipa> A miner may want to limit that, but that's not the responsibility of the network rules.
440 2012-01-01 18:55:16 <justmoon> hmm? are you guys saying MAX_BLOCK_SIGOPS is not enforced for incoming blocks?
441 2012-01-01 18:56:16 <sipa> justmoon: seems it is
442 2012-01-01 18:56:35 da2ce7 has quit (Ping timeout: 276 seconds)
443 2012-01-01 18:57:37 da2ce7 has joined
444 2012-01-01 18:58:11 <justmoon> sipa: yeah it is, line 1157
445 2012-01-01 18:58:18 <justmoon> https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L1157
446 2012-01-01 18:59:28 <[Tycho]> Oh, why people are trying to propose a method of reminting "lost" coins AGAIN ?
447 2012-01-01 18:59:42 <[Tycho]> Please forget about it.
448 2012-01-01 19:01:33 nus has joined
449 2012-01-01 19:02:01 <justmoon> sipa: do you understand gavin's idea? (the "ByteCoin's original intent" version)
450 2012-01-01 19:02:20 <copumpkin> http://www.youtube.com/watch?v=3kEfedtQVOY
451 2012-01-01 19:02:27 <justmoon> he says that it takes the "deserialized script from the stack" isn't that exactly what gavin's implementation does now?
452 2012-01-01 19:02:54 <sipa> justmoon: no
453 2012-01-01 19:03:04 da2ce7 has quit (Ping timeout: 276 seconds)
454 2012-01-01 19:03:07 <sipa> the current implementation takes it from the top of the stack at runtime
455 2012-01-01 19:03:27 <justmoon> yes? and this would take it from where?
456 2012-01-01 19:03:35 <sipa> the idea being proposed now, is that OP_EVAL codes are processed before execution of the script
457 2012-01-01 19:03:46 <copumpkin> that youtube talk is actually relevant
458 2012-01-01 19:03:51 <copumpkin> to the OP_EVAL stuff :)
459 2012-01-01 19:04:13 <sipa> namely, replacing them with the top elements of the scriptSig's stack, before executing scriptPubKey
460 2012-01-01 19:04:45 <sipa> I'd like to have roconnor's opinion about that
461 2012-01-01 19:04:56 <justmoon> how do you know scriptSig's stack without executing it?
462 2012-01-01 19:05:04 <sipa> you execute scriptSig
463 2012-01-01 19:05:13 <sipa> but you don't execute scriptPubKey yet
464 2012-01-01 19:05:28 <sipa> it's an extra processing step in between those exections
465 2012-01-01 19:06:17 <justmoon> how does that fix anything? we're still executing what could be the result of a complex calculation
466 2012-01-01 19:06:24 <justmoon> rather than a string literal
467 2012-01-01 19:06:48 <sipa> right - it implies execution of scriptSig before you can do analysis
468 2012-01-01 19:07:11 <sipa> but it would possibly still be combined with a rule that says that scripts can only result from PUSHDATA's in scriptSig e.g.
469 2012-01-01 19:07:18 <sipa> *could
470 2012-01-01 19:07:45 <genjix> sipa just explained to me in PM. from what i understood scripts are immutable because EVAL can only execute "push literals"
471 2012-01-01 19:07:53 <genjix> so you can count sig ops
472 2012-01-01 19:08:09 <justmoon> that rule alone would be enough - what's the benefit of the whole "only allow eval in scriptPubKey"?
473 2012-01-01 19:08:16 <sipa> genjix: we're now discussing a different idea
474 2012-01-01 19:08:24 <genjix> ah
475 2012-01-01 19:09:08 <sipa> justmoon: OP_EVAL is allowed in scriptPubKey, but it is processed before the actual execution of scriptPubKey
476 2012-01-01 19:09:48 <justmoon> sipa: what's the benefit of that over what we have now?
477 2012-01-01 19:09:51 Sedra- has quit (Remote host closed the connection)
478 2012-01-01 19:09:51 rm99 is now known as rohan
479 2012-01-01 19:10:16 <sipa> it does allow perfect static analysis, assuming you did already execute the scriptSig
480 2012-01-01 19:10:31 rohan has quit (Quit: Reconnecting)
481 2012-01-01 19:10:36 <justmoon> so what, you store the result of the scriptSig?!
482 2012-01-01 19:10:47 Sedra has joined
483 2012-01-01 19:10:48 <justmoon> disregard that
484 2012-01-01 19:10:51 <sipa> that's how execution is done already
485 2012-01-01 19:11:06 <justmoon> yeah, yeah sorry, I was thinking the wrong way around
486 2012-01-01 19:11:13 <sipa> scriptSig is executed, and its resulting stack is used as a start point for the execution of scriptPubKey
487 2012-01-01 19:11:24 <justmoon> how does it help us to do static analysis of scriptPubKey?
488 2012-01-01 19:11:30 <justmoon> if we can't do it on scriptSig?
489 2012-01-01 19:11:53 <justmoon> or better - if we can't do it without running scriptSig
490 2012-01-01 19:13:21 <sipa> actually, I'm not sure I understand ByteCoin's idea completely, i realize now
491 2012-01-01 19:13:30 <justmoon> put differently: it's not really "static analysis" if you have to execute stuff to do it ^^
492 2012-01-01 19:13:50 <sipa> agree
493 2012-01-01 19:14:09 <sipa> but most of the complexity is in scriptPubKey, not in scriptSIhg
494 2012-01-01 19:14:09 <justmoon> all that's needed is some form of the literal rule from what I can tell
495 2012-01-01 19:14:29 <justmoon> I can put the complexity whether it causes the most damage
496 2012-01-01 19:14:34 <justmoon> if I'm an attacker
497 2012-01-01 19:14:36 devrandom has quit (Remote host closed the connection)
498 2012-01-01 19:14:44 <sipa> the literal rule still requires you to process literal that looks like a serialized script
499 2012-01-01 19:14:56 <sipa> without knowing whether it will be executed (or even can be)
500 2012-01-01 19:15:18 <justmoon> same as with OP_IF
501 2012-01-01 19:15:24 <sipa> yes
502 2012-01-01 19:15:26 <justmoon> the way we do it is we assume the worst
503 2012-01-01 19:15:35 <justmoon> i.e. everything is a script and everything will be executed
504 2012-01-01 19:15:49 <justmoon> if there is a way to make it a bit cleverer, great
505 2012-01-01 19:15:56 <sipa> but how will knowing an upper bound help you?
506 2012-01-01 19:16:10 <justmoon> well, you enforce your limit on the upper bound
507 2012-01-01 19:16:16 <justmoon> as we do now
508 2012-01-01 19:17:04 <justmoon> for example right now GetSigOpCount counts OP_CHECKMULTISIG as 20 sigops
509 2012-01-01 19:17:14 <justmoon> it counts all branches of OP_IFs etc.
510 2012-01-01 19:17:37 <sipa> right - we do have the chance to extend GetSigOpCount now
511 2012-01-01 19:17:53 <sipa> it only needs to be compatible with the old behaviour
512 2012-01-01 19:18:00 <justmoon> the only things that we can't have are "invisible" op codes and loops
513 2012-01-01 19:18:13 <justmoon> i.e. OP_WHILE would screw up GetSigOpcount
514 2012-01-01 19:18:17 [\\\] is now known as imsaguy
515 2012-01-01 19:18:37 <justmoon> and OP_EVAL does too, because OP_EVAL is essentially a "something happens here, but what it is, you'll find out later" operation
516 2012-01-01 19:18:54 <sipa> i don't like putting a rule that says "count all sigops in things that look a bit like a script"
517 2012-01-01 19:19:02 <justmoon> true
518 2012-01-01 19:19:05 <sipa> into the network rules
519 2012-01-01 19:19:12 dissipate has joined
520 2012-01-01 19:19:28 <sipa> who knows you produce a signature or pubkey that accidentally happens to look like a very bad script
521 2012-01-01 19:20:06 <justmoon> so is there anything we can do to "mark" subscripts?
522 2012-01-01 19:21:06 agath has joined
523 2012-01-01 19:21:13 <justmoon> signatures and pubkeys start with certain bytes - so if our concern is mainly about those, that would be easy enough, we just make subscripts have to start with an OP_RESERVED byte or whatever, which is ignored - some byte that can never be at the start of a pubkey or sig
524 2012-01-01 19:21:27 <justmoon> it would add an extra byte though :(
525 2012-01-01 19:22:29 <sipa> another possibility would be to prefix every OP_EVAL with a constant push of a number that signifies the # of the push that needs to be executed
526 2012-01-01 19:23:07 <sipa> or how many pushes to go back
527 2012-01-01 19:23:30 Upoi has joined
528 2012-01-01 19:23:32 <justmoon> or just the position of the literal in the script?
529 2012-01-01 19:23:43 <sipa> for example
530 2012-01-01 19:23:57 <justmoon> would an extra constant screw up the backwards compatibility?
531 2012-01-01 19:24:04 <sipa> not necessarily
532 2012-01-01 19:24:24 <sipa> you can require the extra constant to be directly in front of OP_EVAL
533 2012-01-01 19:24:48 <sipa> and not use its value being pushed on the stack (just leave it there as well)
534 2012-01-01 19:25:28 <sipa> and I realize this doesn't work either
535 2012-01-01 19:25:44 <justmoon> why not?
536 2012-01-01 19:26:19 <sipa> any cod you write to validate the hash of the script being executed will work at run time on the stack
537 2012-01-01 19:26:42 <sipa> so you need to make sure that whatever is op_eval'ed corresponds to some known value on the stack that can be inspected
538 2012-01-01 19:27:07 <justmoon> you're right
539 2012-01-01 19:27:38 <sipa> you can add a rule that says that at runtime the top of the stack must be equal to that script being referred to by the prefix constant position in front of op_eval
540 2012-01-01 19:28:14 agath has quit (Ping timeout: 249 seconds)
541 2012-01-01 19:28:43 <nanotube> <Zarutian> dac2ce7: what happens if someone burns 10 000 coins (lost his wallet or some such)? <- same thing that happens if someone tosses 1kg of gold into a volcano. "tough shit (tm)".
542 2012-01-01 19:28:45 <justmoon> I keep coming back to the idea that the literal just needs to be marked in some way
543 2012-01-01 19:28:59 <justmoon> like the execute bit in processors
544 2012-01-01 19:29:09 <sipa> that would be an easy fix
545 2012-01-01 19:29:41 Poiu has joined
546 2012-01-01 19:29:48 <sipa> but you'd need to make sure that no signature, no pubkey, no hash, and none whatever is meaningfully being pushed ever accidentally matches that execute bit
547 2012-01-01 19:30:00 <sipa> in particular, hashes are hard to guarantee
548 2012-01-01 19:30:05 <justmoon> what if it's an operation rather than a bit in the data?
549 2012-01-01 19:30:21 <sipa> *bingo*
550 2012-01-01 19:30:26 <sipa> wait, no
551 2012-01-01 19:30:42 <genjix> wait, would it help if EVAL was always followed by a checksum for the script it executes?
552 2012-01-01 19:30:59 <sipa> genjix: like my original proposal
553 2012-01-01 19:30:59 <genjix> EVAL<checksum> as one piece
554 2012-01-01 19:31:15 <genjix> aha
555 2012-01-01 19:31:25 <sipa> it requires a push of the checksum before the OP_EVAL
556 2012-01-01 19:31:27 <justmoon> genjix: the checksum doesn't tell you what's in the script
557 2012-01-01 19:31:44 <genjix> ohh that's what you were talking about with gavin in the emails
558 2012-01-01 19:31:48 <genjix> ok gotcha.
559 2012-01-01 19:31:52 <sipa> but it's not very nice
560 2012-01-01 19:32:05 <genjix> yeah implementation wise it's a bit of a hassle
561 2012-01-01 19:32:34 Upoi has quit (Ping timeout: 258 seconds)
562 2012-01-01 19:32:36 agath has joined
563 2012-01-01 19:32:56 <genjix> roconnor does have a point about not being too hasty
564 2012-01-01 19:33:08 <genjix> 6 months is a good timeline, better than 3
565 2012-01-01 19:33:09 <copumpkin> "don't put turing into your protocols"
566 2012-01-01 19:33:16 <justmoon> sipa: if the checksum is after the OP_EVAL it would be pretty clean implementation wise, no?
567 2012-01-01 19:33:25 <genjix> but whatever i trust you all
568 2012-01-01 19:33:41 <justmoon> you just increment the script pointer
569 2012-01-01 19:33:56 <justmoon> or does it screw up backwards compatibility again?
570 2012-01-01 19:33:58 <justmoon> ...
571 2012-01-01 19:34:08 <genjix> yes
572 2012-01-01 19:34:19 <sipa> not necessarily
573 2012-01-01 19:34:20 <genjix> bitcoin expects OP's
574 2012-01-01 19:34:36 <sipa> it would be a push, of course
575 2012-01-01 19:34:38 <genjix> script would be unparsable otherwise unless you mandated a push
576 2012-01-01 19:34:41 <genjix> yeah
577 2012-01-01 19:35:07 Fireball is now known as abragin
578 2012-01-01 19:35:10 <sipa> but it would not be very different from my first proposal
579 2012-01-01 19:35:25 <genjix> ok that could work too. when reading an eval, then it would instantly read the next OP
580 2012-01-01 19:35:29 <sipa> i believe it still deals with all concerns, but i don't particularly like it myself
581 2012-01-01 19:36:24 Poiu has quit (Ping timeout: 258 seconds)
582 2012-01-01 19:36:42 <justmoon> how does it provide static analysis? you look for OP_EVAL <checksum> then parse any data that matches checksum?
583 2012-01-01 19:36:47 <justmoon> recursively?
584 2012-01-01 19:37:09 <sipa> no
585 2012-01-01 19:37:13 <genjix> well the idea is that OP_EVAL <checksum> are one op. they cannot be separated. OP_EVAL without the <checksum> fails
586 2012-01-01 19:37:26 <sipa> you go back to the last not-yet-used-by-op-eval push
587 2012-01-01 19:37:29 <sipa> and execute that
588 2012-01-01 19:37:33 <justmoon> genjix: I'm not talking about execution now, but about static analysis
589 2012-01-01 19:37:53 <sipa> and that isn't good either
590 2012-01-01 19:37:54 <justmoon> sipa: that's way more complicated than necessary
591 2012-01-01 19:37:59 <sipa> how so?
592 2012-01-01 19:38:16 <justmoon> if the only problem we're trying to solve is to distinguish script literals from other literals
593 2012-01-01 19:38:20 <genjix> counting the sig ops in the data recursively is totally fine
594 2012-01-01 19:38:23 <sipa> justmoon: no
595 2012-01-01 19:38:36 <sipa> we're trying to distinguish things that will be executed from things that won't
596 2012-01-01 19:38:41 <justmoon> if we have the checksum, we KNOW what the OP_EVAL is going to execute IF we have the literal that results in the checksum
597 2012-01-01 19:38:55 <justmoon> we just require that we find some literal that matches the checksum during static analysis
598 2012-01-01 19:39:06 <sipa> you really want a rule that says "try hashing *everything* and matching it with this hash?", in the network rules?
599 2012-01-01 19:39:42 <justmoon> well, it's a vast improvement over the current proposal with very little implementation complexity
600 2012-01-01 19:39:56 <genjix> hashing is the least of my worries
601 2012-01-01 19:39:57 <sipa> or do you just exectute the top of the stack?
602 2012-01-01 19:40:07 <genjix> especially with the database
603 2012-01-01 19:40:14 <sipa> that's a possbility, actually
604 2012-01-01 19:40:19 <sipa> aaargh no
605 2012-01-01 19:40:25 <justmoon> top of the stack?
606 2012-01-01 19:40:28 <justmoon> what was the idea?
607 2012-01-01 19:40:31 <sipa> we lose semi-verifiability by old nodes then
608 2012-01-01 19:40:46 <justmoon> with the checksum-after?
609 2012-01-01 19:40:49 <sipa> yes
610 2012-01-01 19:40:56 <sipa> because they won't verify the checksum
611 2012-01-01 19:41:00 <justmoon> do we care about semi-verifiability?
612 2012-01-01 19:41:12 <sipa> it is low-priority
613 2012-01-01 19:41:19 <sipa> but i'd prefer a solution that has it
614 2012-01-01 19:41:36 <justmoon> what was the top of the stack thought?
615 2012-01-01 19:41:43 <justmoon> did you solve that having to hash everything problem?
616 2012-01-01 19:41:49 <sipa> justmoon: explain your full idea now
617 2012-01-01 19:42:08 <sipa> because we're mixing things from all kinds of idea, i don't know what we're talking about anymore
618 2012-01-01 19:42:53 <justmoon> I have all kinds of ideas right now - but we went over the problems with most of them
619 2012-01-01 19:43:13 <sipa> ok, i'll list things that i consider viable
620 2012-01-01 19:43:16 <justmoon> oh you mean the execution bit thing?
621 2012-01-01 19:43:34 <justmoon> we could prefix executable literals with OP_NOP2
622 2012-01-01 19:43:56 <justmoon> call it OP_EVALPUSH or whatever
623 2012-01-01 19:44:08 <justmoon> in addition to the normal PUSHDATA of course
624 2012-01-01 19:44:23 <sipa> 1) follow each OP_EVAL with a checksum, let it execure its top of stack (which must match the hash), and require that it only executes literals
625 2012-01-01 19:44:44 marf_away has joined
626 2012-01-01 19:44:56 <sipa> that gives you static analysis, by recursing into each value whose hash is a checksum for an OP_EVAL
627 2012-01-01 19:45:28 <sipa> however, if you want a sigops limit, that would mean putting that recursion rule into the network rules - which i do not like
628 2012-01-01 19:45:36 <justmoon> agreed
629 2012-01-01 19:46:17 <justmoon> are there any downsides to OP_EVALPUSH other than +1 byte per OP_EVAL?
630 2012-01-01 19:46:18 <sipa> 2) prefix each OP_EVAL with a push of a position in the code that gives you the script, and require at runtime that that script is at the top of the stack
631 2012-01-01 19:46:29 <sipa> extra bytes, but waste another opcode
632 2012-01-01 19:46:48 <justmoon> extra byte - singular :P
633 2012-01-01 19:46:54 <sipa> right
634 2012-01-01 19:47:17 <justmoon> can we reuse OP_EVAL somehow?
635 2012-01-01 19:47:28 <justmoon> probably not :/
636 2012-01-01 19:47:37 <sipa> have OP_EVAL have a different meaning in scriptSig and scriptPubKey? yes, possible
637 2012-01-01 19:47:49 <justmoon> nah that doesn't allow recursion I don't think
638 2012-01-01 19:47:51 <justmoon> does it?
639 2012-01-01 19:47:55 erus` has joined
640 2012-01-01 19:48:00 <justmoon> no it doesn't
641 2012-01-01 19:48:11 <sipa> indeed
642 2012-01-01 19:48:16 <genjix> ohhh OP_EVALPUSH
643 2012-01-01 19:48:18 <genjix> that's nice
644 2012-01-01 19:48:37 <sipa> I think we need gavin in this discussion
645 2012-01-01 19:49:01 <sipa> my favorite right now is the prefix position push
646 2012-01-01 19:49:45 <sipa> actually, i'd throw the script language out and replace it with something clean ;)
647 2012-01-01 19:49:48 <genjix> hah OP_EVAL has a location inside the script for its data?
648 2012-01-01 19:49:54 <sipa> yes
649 2012-01-01 19:50:12 <sipa> but how do you let it refer to scriptSig, e.g. ?
650 2012-01-01 19:50:21 <sipa> that is not part of the same code body
651 2012-01-01 19:50:34 <genjix> how about tags
652 2012-01-01 19:50:48 <genjix> yes
653 2012-01-01 19:50:53 <genjix> ok instead of stack
654 2012-01-01 19:50:58 <genjix> there is a static data section
655 2012-01-01 19:51:00 <genjix> .rodata
656 2012-01-01 19:51:09 <genjix> and script can read that at any time but not modify it
657 2012-01-01 19:51:12 <justmoon> sipa: I don't follow scriptPubKey and scriptSig are always executed together
658 2012-01-01 19:51:46 <genjix> it is a read only stack. there can be a special script op to push to this stack but that is it
659 2012-01-01 19:51:50 <justmoon> the only problem is that OP_EVAL is in the sigPubKey, i.e. you'd have to tell the sender what position he needs to include
660 2012-01-01 19:52:15 <genjix> justmoon: what about my idea?
661 2012-01-01 19:52:36 BCBot has quit (Ping timeout: 255 seconds)
662 2012-01-01 19:52:38 <genjix> a secondary push-onlt stack where data cannot be removed
663 2012-01-01 19:52:43 <genjix> *push-only
664 2012-01-01 19:52:49 <luke-jr> justmoon: I suspect your OP_EVALPUSH would be likely to create blockchain forks
665 2012-01-01 19:52:57 <genjix> OP_EVAL refers to data inside that stack
666 2012-01-01 19:52:57 <sipa> genjix: how do you do that in a backward compatible way?
667 2012-01-01 19:52:59 <justmoon> luke-jr: how come?
668 2012-01-01 19:53:08 Sedra- has joined
669 2012-01-01 19:53:15 <sipa> luke-jr: OP_EVALPUSH would be OP_NOP23
670 2012-01-01 19:53:17 <genjix> sipa: append OP_DROP
671 2012-01-01 19:53:18 <sipa> OP_NOP2
672 2012-01-01 19:53:22 <luke-jr> justmoon: the scripts need to behave exactly the same as if it's a NOP
673 2012-01-01 19:53:32 <justmoon> of course it does
674 2012-01-01 19:53:33 <genjix> but have it ignored by the new push rodata stack OP
675 2012-01-01 19:53:39 <justmoon> you'd still have the normal PUSHDATA after it
676 2012-01-01 19:53:59 <luke-jr> justmoon: which means on NOP-based implementations, it'd end up in the default stack
677 2012-01-01 19:54:12 <justmoon> yes, in EVALPUSH based implementations too
678 2012-01-01 19:54:13 <sipa> and it should
679 2012-01-01 19:54:17 <genjix> OP_ROPUSH <data> OP_DROP OP_EVAL
680 2012-01-01 19:54:18 <luke-jr> why not just flag stack items that came from OP_PUSH?
681 2012-01-01 19:54:32 <genjix> OP_ROPUSH would skip OP_DROP
682 2012-01-01 19:54:33 <justmoon> because then any data might be executed
683 2012-01-01 19:54:43 <luke-jr> justmoon: that's already true
684 2012-01-01 19:54:45 <luke-jr> and SO WHAT?
685 2012-01-01 19:54:57 <justmoon> it's not true, OP_EVAL adds that
686 2012-01-01 19:55:08 <luke-jr> yes it is: I can put random data in a txn script
687 2012-01-01 19:55:23 <sipa> currently you can count a reasonable upper bound on the sigops count without executing a script
688 2012-01-01 19:55:26 <justmoon> yes, but I can see that random data and count the sigops for example
689 2012-01-01 19:55:35 <sipa> we want to find a way to not lose that property when adding OP_EVAL
690 2012-01-01 19:55:45 <genjix> why flag items that come from a push... why not just create a secondary stack for them?
691 2012-01-01 19:55:59 <genjix> one stack is push/drop and one is push only
692 2012-01-01 19:56:06 <genjix> seems much cleaner to separate tem
693 2012-01-01 19:56:09 BCBot has joined
694 2012-01-01 19:56:09 <sipa> genjix: read my initial proposal
695 2012-01-01 19:56:16 <luke-jr> sipa: sigop count is irrelevant
696 2012-01-01 19:56:22 <sipa> is it?
697 2012-01-01 19:56:35 <sipa> there is a network rule about it
698 2012-01-01 19:56:39 <justmoon> luke-jr: no it isn't, it is an enforced limit, i.e. it may invalidate the block
699 2012-01-01 19:56:41 <luke-jr> sipa: since they can vary in complexity, yes
700 2012-01-01 19:56:52 <luke-jr> justmoon: it's not like you can't test it anyway
701 2012-01-01 19:56:54 Sedra has quit (Ping timeout: 252 seconds)
702 2012-01-01 19:56:58 <luke-jr> in fact, anyone makign a block *needs* to test it
703 2012-01-01 19:57:09 <luke-jr> by execution
704 2012-01-01 19:57:15 <sipa> that is why you want to make it easy to test
705 2012-01-01 19:57:22 <luke-jr> sipa: it is easy to test
706 2012-01-01 19:57:24 <luke-jr> execute
707 2012-01-01 19:57:30 <luke-jr> you HAVE to execute no matter what
708 2012-01-01 19:57:30 <sipa> preferrably, in a way that doesn't require execution
709 2012-01-01 19:57:34 <sipa> no
710 2012-01-01 19:57:36 <luke-jr> â¦
711 2012-01-01 19:57:45 <justmoon> luke-jr: if you can only test it by execution, then parallelized implementations with high latencies are potentially vulnerable
712 2012-01-01 19:57:48 <sipa> if you know it is invalid in advance, you do not need to executre
713 2012-01-01 19:58:18 <genjix> i dont like having to execute scripts in a dry run
714 2012-01-01 19:58:23 <sipa> so you want an easy, fast, criterion to decide validity
715 2012-01-01 19:58:38 <sipa> and yes, dry-run is a possibility for that
716 2012-01-01 19:58:59 <luke-jr> even if it passes the "easy, fast" criterion, you still need to execute it
717 2012-01-01 19:59:04 <sipa> of course
718 2012-01-01 19:59:12 <sipa> but not if it isn't
719 2012-01-01 19:59:15 <sipa> that's the point
720 2012-01-01 19:59:19 <genjix> sipa: where is your original post?
721 2012-01-01 19:59:24 <luke-jr> so in the normal case, you're doing MORE work to static analyze it.
722 2012-01-01 19:59:26 <sipa> not requiring execution of things that are guaranteed to be invalid
723 2012-01-01 19:59:27 <justmoon> luke-jr: imagine a decentralized with 10000 participants validating a 1000000 tx block - everybody validates 100 transactions - but by the time they figure out that someone sent them a block with 300 times the maximum allowed number of sigops, they've already wasted tons of cpu time
724 2012-01-01 19:59:34 <justmoon> decentralized pool*
725 2012-01-01 19:59:53 <sipa> justmoon: you bail out as soon as you hit the sigops execution limit, of course
726 2012-01-01 20:00:15 <luke-jr> justmoon: and if you beat that with static analysis, they can waste your CPU time another way just as easily.
727 2012-01-01 20:00:29 <copumpkin> amusingly, that talk I linked to (that I claimed was vaguely relevant to OP_EVAL) also mentioned bitcoin :)
728 2012-01-01 20:00:31 <justmoon> sipa: which you only find out about after 1 1/2 round trips with the central hosts
729 2012-01-01 20:00:44 <sipa> that is why the static analysis needs to be easy
730 2012-01-01 20:01:25 <genjix> polymorphic bitcoin code using op_eval :)
731 2012-01-01 20:01:29 <luke-jr> it's extra work for no gain ;)
732 2012-01-01 20:01:39 <luke-jr> static analysis, I mean
733 2012-01-01 20:01:47 <justmoon> luke-jr: they can only waste it the same as for big centralized pools
734 2012-01-01 20:01:52 <sipa> luke-jr: don't understand too much under that word
735 2012-01-01 20:02:06 <sipa> luke-jr: the current (pre-op-eval) GetSigOpsCount is a static analyzer
736 2012-01-01 20:02:07 <luke-jr> there are much easier ways to perform the same DoS, without hiding sigops
737 2012-01-01 20:02:10 <copumpkin> people keep throwing it around without knowing what it would actually entail
738 2012-01-01 20:02:10 <sipa> and it works
739 2012-01-01 20:02:16 <justmoon> luke-jr: i.e. they can't make a block that a centralized pool will waste 100000 sigops on and a decentralized pool will waste 1000000
740 2012-01-01 20:02:35 <luke-jr> justmoon: relevance?
741 2012-01-01 20:03:03 <justmoon> luke-jr: we like decentralization and would like to avoid unnecessarily adding road blocks for decentralized alternatives?
742 2012-01-01 20:03:24 <luke-jr> justmoon: â¦
743 2012-01-01 20:03:33 <luke-jr> as you just said, decentralization is irrelevant to the topic
744 2012-01-01 20:03:49 <luke-jr> nobody is going to be stupid enough to make a block that will fail
745 2012-01-01 20:04:01 <luke-jr> the cost is so much higher than the time wasted to deal with it
746 2012-01-01 20:04:01 <sipa> an attacker may
747 2012-01-01 20:04:07 clapper has joined
748 2012-01-01 20:04:16 <luke-jr> and there are much easier ways to make an invalid block if they wanted to do that
749 2012-01-01 20:04:19 iocor has joined
750 2012-01-01 20:04:27 <justmoon> luke-jr: that depends whats more expensive, hashing or tx verification
751 2012-01-01 20:04:46 <luke-jr> ie, fill the block with the max valid transactions, then have the last one be invalid for some other reason
752 2012-01-01 20:06:07 roconnor has joined
753 2012-01-01 20:06:22 <justmoon> hmm
754 2012-01-01 20:06:45 <justmoon> it's true, there are other attacks you could come up with that hurt high-latency verifiers more I think
755 2012-01-01 20:07:03 clapper has quit (Client Quit)
756 2012-01-01 20:07:03 <sipa> justmoon: i'm beginning to think that it's so dirty to add nice static analysis abilities to OP_EVAL, that it's not worth it
757 2012-01-01 20:07:27 <sipa> and just require that OP_EVAL'ed scripts are literals
758 2012-01-01 20:08:13 <sipa> and just let GetSigOpsCount work based on dry-run
759 2012-01-01 20:08:32 <luke-jr> why require that OP_EVAL'd scripts are literals, even, btw?
760 2012-01-01 20:09:35 <luke-jr> !
761 2012-01-01 20:09:44 <justmoon> sipa: you can't dry run because it has exponential time complexity
762 2012-01-01 20:09:58 <luke-jr> slightly off topic: maybe the first octet of an OP_EVAL script can/should be a version number?
763 2012-01-01 20:10:13 <sipa> luke-jr: i like that idea
764 2012-01-01 20:10:21 <luke-jr> so for example, if 0.6 sees it "version 2", it treats it as OP_NOP again
765 2012-01-01 20:10:32 <justmoon> sipa: you can either make it statically analyzable, or you can do no checks other than execution
766 2012-01-01 20:10:34 <luke-jr> which lets us even easier upgrade the inside-OP_EVAL scripts
767 2012-01-01 20:10:56 * roconnor wonders if the client will ignore version numbers on OP_EVAL too
768 2012-01-01 20:11:13 <luke-jr> sipa: is there a sensible way to add it without breaking compatibility with the existing OP_EVAL txns in the chain?
769 2012-01-01 20:11:14 <sipa> justmoon: bah, true
770 2012-01-01 20:11:32 <sipa> luke-jr: there are only OP_EVAL's in the testnet chain, no?
771 2012-01-01 20:11:53 <luke-jr> sipa: not sure
772 2012-01-01 20:12:10 <sipa> roconnor: please
773 2012-01-01 20:12:19 <justmoon> luke-jr: why not just make it dependant on the tx version?
774 2012-01-01 20:12:26 <justmoon> rather than adding another byte...
775 2012-01-01 20:12:42 <luke-jr> justmoon: txn version AFAIK is about revising the individual txn, not txn format
776 2012-01-01 20:13:10 <justmoon> luke-jr: you're right, block version then?
777 2012-01-01 20:13:33 <justmoon> also the wiki page is wrong, it describes the version field as "Transaction data format version"
778 2012-01-01 20:13:38 <roconnor> luke-jr: I think you are wrong abu txn version
779 2012-01-01 20:13:40 <justmoon> -_-
780 2012-01-01 20:13:58 <roconnor> there is another field for revising txn I think
781 2012-01-01 20:14:00 * roconnor checks
782 2012-01-01 20:14:02 <justmoon> right...
783 2012-01-01 20:14:02 <luke-jr> justmoon: pretty sure current clients will not accept blocks with unknown versions
784 2012-01-01 20:14:16 <justmoon> they do, there are unusual block versions on testnet
785 2012-01-01 20:14:22 <luke-jr> oh?
786 2012-01-01 20:14:31 <luke-jr> so I can make a "version 2" block that everyone ignores?
787 2012-01-01 20:14:31 <justmoon> luke-jr: you confused tx version and sequence maybe?
788 2012-01-01 20:14:34 <luke-jr> maybe
789 2012-01-01 20:14:41 <roconnor> I think the txLock is for revising transactions
790 2012-01-01 20:14:47 <sipa> nSequence, in txins?
791 2012-01-01 20:14:56 <sipa> i think that is what luke-jr refers to
792 2012-01-01 20:15:01 <roconnor> oh right
793 2012-01-01 20:15:03 <roconnor> nSequence
794 2012-01-01 20:15:16 <luke-jr> in any case, would bumping the txn or block ver # allow backward compat?
795 2012-01-01 20:15:19 <justmoon> yeah, so you could use the tx version to make OP_EVAL nop again
796 2012-01-01 20:16:21 <luke-jr> â¦
797 2012-01-01 20:17:34 TD has joined
798 2012-01-01 20:18:24 <justmoon> sipa: the thing that I'm worried about - just because we can't come up with a use case for static analysis, doesn't mean there isn't an important one...
799 2012-01-01 20:18:47 <sipa> you just came up with a use case
800 2012-01-01 20:18:51 <justmoon> I did?
801 2012-01-01 20:19:00 <sipa> GetSigOpsCount
802 2012-01-01 20:19:25 <justmoon> well, but luke just destroyed my use case for *that* ^^
803 2012-01-01 20:19:34 <sipa> how so?
804 2012-01-01 20:19:58 <sipa> by giving another way that could also be used to cause latency in distributed verifiers?
805 2012-01-01 20:20:03 <justmoon> I thought it was a nice defense against asymmetric attacks against high latency verifiers yes
806 2012-01-01 20:20:12 <justmoon> and luke pointed out there are other attacks with the same properties anyway
807 2012-01-01 20:20:14 theorb has joined
808 2012-01-01 20:20:32 theorbtwo has quit (Ping timeout: 252 seconds)
809 2012-01-01 20:20:53 <sipa> right
810 2012-01-01 20:21:09 <justmoon> so yeah, right now all I have is an intuition that is probably going to be some reason we'll one curse ourselves for giving up static analysis entirely, but I couldn't tell you what it will be
811 2012-01-01 20:21:22 <justmoon> god I can't type for shit...
812 2012-01-01 20:21:33 * sipa still votes for referring-to-position-of-code-to-execute idea
813 2012-01-01 20:21:43 <justmoon> so yeah, right now all I have is an intuition that there is probably going to be some reason we'll one day curse ourselves for giving up static analysis entirely, but I couldn't tell you what it will be
814 2012-01-01 20:21:47 <justmoon> there, fixed
815 2012-01-01 20:22:00 nus has quit (Read error: Connection reset by peer)
816 2012-01-01 20:22:10 <TD> happy new year everyone!
817 2012-01-01 20:22:12 <justmoon> sipa: have we thought that through yet?
818 2012-01-01 20:22:15 <luke-jr> sipa: that's not extensible.
819 2012-01-01 20:22:16 <justmoon> TD: happy new year!
820 2012-01-01 20:22:21 <sipa> luke-jr: explain
821 2012-01-01 20:22:24 <sipa> TD: you too!
822 2012-01-01 20:22:28 <luke-jr> sipa: we can't add key extraction to it
823 2012-01-01 20:22:44 <sipa> that's entirely independent...
824 2012-01-01 20:22:50 nus has joined
825 2012-01-01 20:23:33 <sipa> justmoon: haven't found a reason why it'd be impossible (except a bit dirty semantics when referring to scriptSig code)
826 2012-01-01 20:24:07 <sipa> sec, brb
827 2012-01-01 20:25:18 GMP has quit (Read error: Connection reset by peer)
828 2012-01-01 20:27:05 devrandom has joined
829 2012-01-01 20:29:37 Cablesaurus has quit (Quit: Some folks are wise, and some otherwise.)
830 2012-01-01 20:31:44 <roconnor> Has this idea been tossed around: OP_PUSHCODE (literal) is defined to be OP_NOP2 OP_PUSHDATA (literal) assigns a code-type to the value pushed on the stack. Any arithmetic operations on code-typed data fails. And OP_EVAL fails on anything not marked as code-type ... essentially make stack values dynamically typed rather than untyped. (along with sipa's nop principle that OP_EVAL copies the stack and its only effect is to fail)
831 2012-01-01 20:32:15 <justmoon> yes, I suggested it earlier
832 2012-01-01 20:32:24 <roconnor> okay good.
833 2012-01-01 20:32:38 <justmoon> downsides are +1 byte per OP_EVAL and -1 NOP left to use in future
834 2012-01-01 20:32:39 <roconnor> Acutally I don't like it very much; still to hard to do static analysis.
835 2012-01-01 20:32:45 <roconnor> *too hard
836 2012-01-01 20:32:47 TD has quit (Read error: Connection reset by peer)
837 2012-01-01 20:33:01 <justmoon> you can require it to be a literal prefix
838 2012-01-01 20:33:18 <justmoon> then static analysis should be trivial with it, no?
839 2012-01-01 20:33:39 <roconnor> well, it may be hard to tell how many times the code will be OP_EVALd
840 2012-01-01 20:33:58 <roconnor> the way the script works right now is really convenient.
841 2012-01-01 20:34:10 <roconnor> nice and linear ... well linearish
842 2012-01-01 20:34:17 <justmoon> can it be eval'd more than once?
843 2012-01-01 20:34:25 <justmoon> if you disallow OP_DUP etc?
844 2012-01-01 20:34:32 <roconnor> Hmm
845 2012-01-01 20:34:37 <justmoon> or not disallow
846 2012-01-01 20:34:38 <roconnor> I didn't think about disallowing OP_DUP
847 2012-01-01 20:34:42 <roconnor> and OP_DROP
848 2012-01-01 20:34:52 <roconnor> that makes it a linear calculus
849 2012-01-01 20:34:54 <justmoon> not disallow, but have it drop the execute bit
850 2012-01-01 20:34:55 <roconnor> interesting
851 2012-01-01 20:35:04 <justmoon> i.e. turn it into normal data
852 2012-01-01 20:35:12 BlueMatt has joined
853 2012-01-01 20:38:42 <roconnor> I kinda think that my CODEHASH proposal is better than all this
854 2012-01-01 20:38:56 slush has joined
855 2012-01-01 20:39:07 <roconnor> It has the least amount of Unknowns IMHO
856 2012-01-01 20:39:44 <roconnor> though it doesn't satify sipa's NOP extension principle :(
857 2012-01-01 20:40:03 <justmoon> roconnor: my use case for why we need GetSigOpCount kinda fell apart, so right now we're back to "we have a vague sense that we may one day need static analysis, but we can't say exactly why"
858 2012-01-01 20:40:18 <roconnor> justmoon: why does the current client do static analysis?
859 2012-01-01 20:40:31 <justmoon> roconnor: because it can I suppose
860 2012-01-01 20:40:55 <BlueMatt> roconnor: I might be a bit behind what advantages does yours have over sipa's simple OP_EVAL runs in restricted environment one?
861 2012-01-01 20:41:31 <copumpkin> cleaner semantics, doesn't it?
862 2012-01-01 20:42:17 <roconnor> BlueMatt: I may not fully understand sipa's proposal.
863 2012-01-01 20:42:22 <justmoon> BlueMatt: restricted environment is the proposal I'm least familiar with, but I know that it's one of the hardest to implement
864 2012-01-01 20:42:54 <sipa> roconnor: which proposal exactly?
865 2012-01-01 20:43:03 <roconnor> sipa: I don't know.
866 2012-01-01 20:43:10 <sipa> I've done quite a few suggestions the past few days
867 2012-01-01 20:43:11 <justmoon> sipa: OP_CHECKEDEVAL
868 2012-01-01 20:43:18 <BlueMatt> justmoon: shouldnt be, essentially sipa's proposal (AFAIK) is just "take OP_EVAL and give it a new environment to work in, ie new alt_stack/etc"
869 2012-01-01 20:43:27 <BlueMatt> the simplest one
870 2012-01-01 20:43:41 <sipa> BlueMatt: yes, but that is not enough for static analysis
871 2012-01-01 20:43:49 <BlueMatt> meh...
872 2012-01-01 20:44:12 <BlueMatt> imho its the simplest one which gets rid of the most "there be dragons" complaints
873 2012-01-01 20:44:17 <justmoon> what *is* the benefit of a separate environment?
874 2012-01-01 20:44:20 <roconnor> BlueMatt: while that is a good idea, but it doesn't address pseudo-turing completeness nor execution of dynamically generated code, (nor non-linear use of subroutines).
875 2012-01-01 20:44:35 RazielZ has quit (Ping timeout: 240 seconds)
876 2012-01-01 20:44:38 <justmoon> BlueMatt: no the dragons come from being able to make code and then run it, not whether it runs sandboxed
877 2012-01-01 20:44:40 <roconnor> justmoon: you don't have to do that stupid second pass of treating OP_EVAL as a NOP
878 2012-01-01 20:44:41 <sipa> justmoon: understandable semantics
879 2012-01-01 20:44:44 <justmoon> BlueMatt: it's all sandboxed anyway
880 2012-01-01 20:45:39 <BlueMatt> justmoon: most of the "there be dragons" complaints Ive seen come from we dont know exactly what is possible with OP_EVAL, sandboxing it from main script execution gets rid of most of those concerns
881 2012-01-01 20:45:51 <sipa> roconnor: what i'm currently thinking about is prefixing each OP_EVAL with a push of a number x, which says "this OP_EVAL can only execute literal push #x in the code"
882 2012-01-01 20:46:00 <BlueMatt> well aside from the turing completeness stuff
883 2012-01-01 20:46:20 <justmoon> BlueMatt: the off-mailing-list discussion kinda went in a different direction...
884 2012-01-01 20:46:28 <justmoon> who's idea was it to go off the mailing list anyways...
885 2012-01-01 20:46:35 <sipa> gavin :)
886 2012-01-01 20:46:43 RazielZ has joined
887 2012-01-01 20:46:44 <sipa> we should head back there
888 2012-01-01 20:47:03 <BlueMatt> meh, whatever I guess Im just behind then...
889 2012-01-01 20:47:15 <justmoon> can we simplify it a bit for me - i.e. what the criticisms are exactly?
890 2012-01-01 20:47:21 <justmoon> I understand the static analysis one
891 2012-01-01 20:47:30 <justmoon> are there entirely distinct other criticisms?
892 2012-01-01 20:47:46 <roconnor> justmoon: I don't like the pseduo-turing completeness
893 2012-01-01 20:47:49 <sipa> it is hard to understand how e.g. OP_EVAL and IF_THEN_ELSE nesting work together
894 2012-01-01 20:47:52 <sipa> and hard to specify
895 2012-01-01 20:48:12 <sipa> by running the subscript in another environnement, you get understandable semantics
896 2012-01-01 20:48:14 <roconnor> the level 2 recursion maximum depth is totally arbitrary based on "gavin can think of a use of depth 2 but not of depth 3"
897 2012-01-01 20:48:19 <sipa> it's a different script altogether
898 2012-01-01 20:48:55 <justmoon> sipa: ok, that makes sense
899 2012-01-01 20:49:02 <justmoon> sipa: is that CHECKEDEVAL or something else?
900 2012-01-01 20:49:05 <copumpkin> roconnor: did you see the CCC talk about not putting TC-ness into your protocols just a couple of days ago?
901 2012-01-01 20:49:16 <sipa> justmoon: checkedeval does that, plus static analysis
902 2012-01-01 20:49:22 <justmoon> sipa: k
903 2012-01-01 20:49:30 <roconnor> justmoon: and no one has proved that looping is impossible even with depth 2 limitations AFAIK.
904 2012-01-01 20:50:00 <roconnor> copumpkin: nope, but having non-TC DSLs is pretty common nowadays AFAIU.
905 2012-01-01 20:50:03 <copumpkin> roconnor: http://www.youtube.com/watch?v=3kEfedtQVOY (also mentions bitcoin at the end, briefly)
906 2012-01-01 20:50:10 <copumpkin> roconnor: yeah, but tell the security guys that
907 2012-01-01 20:50:14 <copumpkin> that's what this talk does ;)
908 2012-01-01 20:50:27 <roconnor> really; I thought the security guys would be the first to know
909 2012-01-01 20:50:40 <copumpkin> not at all, most of them turn their noses up at PL/type theory
910 2012-01-01 20:51:18 <copumpkin> unfortunately the bitcoin mention is unrelated to the topic of the talk :)
911 2012-01-01 20:53:55 <justmoon> roconnor: do we care about looping? it'll exhaust the 200 ops counter anyway, no?
912 2012-01-01 20:54:07 <roconnor> I guess
913 2012-01-01 20:54:42 <roconnor> although that counter is pretty stupid to begin with
914 2012-01-01 20:54:48 <justmoon> looping makes static analysis impossible of course
915 2012-01-01 20:54:57 <justmoon> so if we care about that we care about looping by extension
916 2012-01-01 20:54:57 <roconnor> counting non-executed operations in IF branches
917 2012-01-01 20:59:08 booo has joined
918 2012-01-01 21:01:12 <sipa> roconnor: what do you think about having OP_EVAL refer to the push of the script that it executes?
919 2012-01-01 21:02:00 <roconnor> sipa: inelegant, but significantly better than the current proposal.
920 2012-01-01 21:02:13 <sipa> yes, inelegant indeed
921 2012-01-01 21:02:42 <sipa> yours is probably the most elegant now, but i really do not like the extra 20 bytes
922 2012-01-01 21:09:21 b4epoche_ has joined
923 2012-01-01 21:09:37 <justmoon> sipa: seems like there should be some way to remove the extra 20 bytes?
924 2012-01-01 21:10:15 b4epoche has quit (Ping timeout: 240 seconds)
925 2012-01-01 21:10:15 b4epoche_ is now known as b4epoche
926 2012-01-01 21:10:43 <sipa> if you know how, please say so :)
927 2012-01-01 21:10:55 <justmoon> sipa: CHALLENGE ACCEPTED
928 2012-01-01 21:11:49 <justmoon> it's there for what exactly? that weak verifiability we were talking about?
929 2012-01-01 21:12:38 <sipa> yes
930 2012-01-01 21:12:48 <justmoon> ...
931 2012-01-01 21:13:17 <justmoon> you guys realize that all that does is require you to know the pubkeys in order to generate transactions old clients will accept?
932 2012-01-01 21:13:40 <sipa> ?
933 2012-01-01 21:13:59 <justmoon> all the old clients verify is the hash of the code, right?
934 2012-01-01 21:14:06 <sipa> yes
935 2012-01-01 21:14:08 <justmoon> so if I know the code I can spend that transaction
936 2012-01-01 21:14:41 <sipa> at 0 confirmations, yes
937 2012-01-01 21:14:41 <justmoon> that's such weak security you may as well say you can spend any OP_EVAL transaction on old clients
938 2012-01-01 21:14:43 <sipa> *with
939 2012-01-01 21:15:38 <justmoon> if that is the only objection to OP_CODEHASH, then I'd just drop the code hash from the scriptSig and be done with it
940 2012-01-01 21:16:49 <justmoon> I guess it's not quite that easy
941 2012-01-01 21:17:00 <roconnor> justmoon: I largely agree
942 2012-01-01 21:17:19 <justmoon> but you agree that if you drop the ridiculous weak verifiability requirement it should be possible to get rid of the extra 20 bytes
943 2012-01-01 21:18:10 <roconnor> or at least drop the extra 20 bytes once the new scripting language is well accepted
944 2012-01-01 21:18:19 <roconnor> justmoon: there is another more complicated object
945 2012-01-01 21:18:21 <sipa> we meed gavin in this discussion :)
946 2012-01-01 21:18:33 <justmoon> it has to be well accepted before you start to do ANY OP_EVAL transactions
947 2012-01-01 21:19:13 <justmoon> weak verifiability may as well be no verifiability
948 2012-01-01 21:19:22 roconnor_ has joined
949 2012-01-01 21:19:27 <justmoon> I can connect to 15000 nodes and just replace transactions as they come in
950 2012-01-01 21:19:30 <roconnor_> nested OP_EVAL lets you do this thing where you can send to one-of-many scripts
951 2012-01-01 21:20:17 <roconnor_> but OP_CODEHASH would need to be modified in some (complicated?) way to allow this
952 2012-01-01 21:20:18 nus has quit (Ping timeout: 252 seconds)
953 2012-01-01 21:20:30 <justmoon> roconnor_: are you talking about gavin's this or that example?
954 2012-01-01 21:21:51 nus has joined
955 2012-01-01 21:21:52 <roconnor_> justmoon: yes
956 2012-01-01 21:22:02 JZavala has joined
957 2012-01-01 21:22:28 <justmoon> that example makes no sense at all to me - to generate a this or that sigPubKey you need to know both branches of the script to spend it, so why not just make a script with an OP_IF in it
958 2012-01-01 21:22:45 <roconnor_> just to save space
959 2012-01-01 21:22:51 ByteCoin2 has joined
960 2012-01-01 21:23:02 roconnor has quit (Ping timeout: 240 seconds)
961 2012-01-01 21:23:26 <roconnor_> (and since non-executed branches still count in the opcount, then saving space allows for "larger" transactions)
962 2012-01-01 21:23:31 <justmoon> save space in the txin at the expense of the txout o_O
963 2012-01-01 21:23:56 <roconnor_> justmoon: no no; the entire unused branch is never included other than its hash
964 2012-01-01 21:24:51 <justmoon> ok, gotcha
965 2012-01-01 21:25:00 <ByteCoin2> Hi guys. I'd just like to jump in here and mention that you're looking for alternative solutions for something you have not demonstrated is a problem.
966 2012-01-01 21:25:13 <justmoon> ByteCoin2: correct
967 2012-01-01 21:25:30 <justmoon> roconnor_: but it seems CODEHASH should support that too?
968 2012-01-01 21:26:18 <sipa> well, if you don't consider static analysis a requirement, i'd say the idea of no-op by construction makes the semantics so much easier to understand/sepcify/implement that it's worth it
969 2012-01-01 21:26:30 <roconnor_> justmoon: the way i specified CODEHASH is that OP_CODESEPARATOR pushes the hash of everything to the end of the script
970 2012-01-01 21:27:08 <justmoon> roconnor_: how about everything since the last CODESEPARATOR or something like that?
971 2012-01-01 21:27:36 <roconnor_> justmoon: but the naive implemenation of this-and-that with CODEHASH requires that hash to appear in the script that gets hashed
972 2012-01-01 21:27:46 <ByteCoin2> Perhaps it'd be worth spending some more time trying to show that the attack perimeter for your alternative solutions is smaller than the existing solution?
973 2012-01-01 21:28:01 <roconnor_> justmoon: knowing what the "last" CODESEPARATOR is tricky in the presence of OP_IF.
974 2012-01-01 21:28:09 <roconnor_> justmoon: it might be doable, but it gets very scary
975 2012-01-01 21:28:26 <justmoon> ByteCoin2: there is no attack perimeter - bitcoin scripts are sandboxed and operations counted
976 2012-01-01 21:28:49 <ByteCoin2> justmoon: Please!
977 2012-01-01 21:28:54 <justmoon> ByteCoin2: there is no reasons to put restrictions on anything, you can have loops, infinite recursion etc.
978 2012-01-01 21:29:11 <sipa> still, we have seen how easy implementation errors appear
979 2012-01-01 21:29:21 <sipa> and clear semanticsd are one way to reduce those
980 2012-01-01 21:31:02 <justmoon> sipa: that's an argument for CODEHASH in my opinion
981 2012-01-01 21:31:24 <justmoon> with code hash you don't change what is being executed, you just add a way to get a hash of what you've just run
982 2012-01-01 21:31:53 <justmoon> so you don't need any of those hacks that are in gavin's patch like passing in a counter of sigops etc.
983 2012-01-01 21:32:14 <roconnor_> codehash has the nice invarient that everything on the codehash stack is the hash of some script that was executed from that point in some context.
984 2012-01-01 21:32:43 <justmoon> roconnor_: I don't think you need a "codehash stack"
985 2012-01-01 21:33:09 <roconnor_> sure; I don't doubt that my proposal can be refined and improved.
986 2012-01-01 21:36:48 <justmoon> ByteCoin2: now that this line of thought is finished, let me properly address your comment, sorry for my flippant remarks before
987 2012-01-01 21:37:12 <ByteCoin2> roconnor: Could you please post on the forum an explanation of your proposal along with the evolution of the stack as the script is executed please?
988 2012-01-01 21:37:30 <justmoon> ByteCoin2: basically I pointed out a few days ago that without static analysis there is an asymmetric attack against decentralized verifiers that is possible with the current OP_EVAL implementation
989 2012-01-01 21:37:45 DontMindMe has joined
990 2012-01-01 21:37:49 <justmoon> ByteCoin2: so we talked about way on how to preserve static analysis
991 2012-01-01 21:37:51 roconnor_ is now known as roconnor
992 2012-01-01 21:38:01 <BlueMatt> ByteCoin2: why would anyone want to post on the forum?
993 2012-01-01 21:38:07 <ByteCoin2> justmoon: I'm not clear about what you mean by an asymmetric attack?
994 2012-01-01 21:38:15 <justmoon> ByteCoin2: then luke pointed out other asymmetric attacks with the same characteristics
995 2012-01-01 21:38:36 <ByteCoin2> justmoon: Where did luke do that?
996 2012-01-01 21:38:39 <justmoon> ByteCoin2: so now we're back to: some of us have a vague sense that static analysis might be useful for something, but we don't know what
997 2012-01-01 21:39:28 <roconnor> justmoon: you left out the part where you debunked gavin's dry-run idea
998 2012-01-01 21:39:28 <justmoon> ByteCoin2: in chat today, doesn't matter, it's neatly tied up anyway - for now, you are correct, I can't point out any concrete reason why we need static analysability
999 2012-01-01 21:39:33 <ByteCoin2> justmoon: People who don't share your feeling would have no reason to take your concerns seriously.
1000 2012-01-01 21:39:41 <justmoon> ByteCoin2: correct
1001 2012-01-01 21:39:50 <justmoon> ByteCoin2: that's why I've stopped arguing for it
1002 2012-01-01 21:39:56 <ByteCoin2> Ok
1003 2012-01-01 21:40:26 <justmoon> ByteCoin2: I just want to know what the best statically analyzable solution *would* look like
1004 2012-01-01 21:40:42 <ByteCoin2> An interesting, if academic question.
1005 2012-01-01 21:41:38 <ByteCoin2> roconnor: Point me to the bit where someone debunked gavin's idea
1006 2012-01-01 21:41:39 <sipa> justmoon: quite sure that the best staticaly analyzable solution is not a stack-based language ;)
1007 2012-01-01 21:41:47 nus- has joined
1008 2012-01-01 21:41:52 nus has quit (Read error: Connection reset by peer)
1009 2012-01-01 21:42:10 <justmoon> sipa: I'm quite sure that static analyzability is a primary design goal of the language as-is
1010 2012-01-01 21:42:18 <justmoon> sipa: note the absence of OP_LOOP OP_BREAK etc.
1011 2012-01-01 21:42:48 <roconnor> The problem is that the consequences of the OP_EVAL proposal has large unknown consequences. The way that you've framed the issuse is that the good guys, maybe 10 or 20, have at most 3 months to find all the problems with OP_EVAL and the bad guys, the rest of the world, get all the time they want.
1012 2012-01-01 21:42:49 <luke-jr> let's totally add OP_LOOP
1013 2012-01-01 21:42:59 <ByteCoin2> justmoon: I don't see evidence for that. I see a successful attempt to prevent looping
1014 2012-01-01 21:43:10 <roconnor> Why not prove the OP_EVAL proposal is good; starting with a proof of termination.
1015 2012-01-01 21:43:23 <ByteCoin2> roconnor: Beause we have finite engineering effort
1016 2012-01-01 21:43:38 <justmoon> ByteCoin2: why prevent looping, that is nothing magically evil about looping - the only downside is it remove static analyzability
1017 2012-01-01 21:43:41 <ByteCoin2> And even more finite(!) maths expertise!
1018 2012-01-01 21:43:49 <justmoon> there* is nothing
1019 2012-01-01 21:44:09 <roconnor> ByteCoin2: the more finite your resources, the longer you should take with protocol changes.
1020 2012-01-01 21:44:12 slush has quit (Ping timeout: 252 seconds)
1021 2012-01-01 21:44:19 <ByteCoin2> justmoon: You have preconceptions which I think are untrue and it's affecting your reasoning
1022 2012-01-01 21:44:30 <justmoon> what preconceptions?
1023 2012-01-01 21:44:41 <ByteCoin2> Looping constructs are perfectly analysable under certain circumstances
1024 2012-01-01 21:44:51 <ByteCoin2> Indeed many common circumstances
1025 2012-01-01 21:44:57 <justmoon> ok that's true
1026 2012-01-01 21:45:03 <justmoon> but that's not what I mean
1027 2012-01-01 21:45:25 <justmoon> right now the script is statically analyzable
1028 2012-01-01 21:45:39 <justmoon> in fact, we use that static analysis in the function GetSigOpCount
1029 2012-01-01 21:45:41 <ByteCoin2> I believe the reason to prevent looping was to remove the need for any "static analysis" or suchlike when reasoning about script execution
1030 2012-01-01 21:46:12 <justmoon> ah, so you and I understand the term static analysis differently
1031 2012-01-01 21:46:24 <justmoon> you call static analysis what gavin calls dry running
1032 2012-01-01 21:46:29 <ByteCoin2> Wrong
1033 2012-01-01 21:47:00 <justmoon> you said "remove the need for static analysis"
1034 2012-01-01 21:47:06 <justmoon> right now the client DOES do static analysis
1035 2012-01-01 21:47:25 <sipa> stronger: the network protovol relies on it
1036 2012-01-01 21:47:41 <sipa> s/v/c
1037 2012-01-01 21:47:44 <justmoon> gavin's patch REMOVES static analysis because it's no longer possible with OP_EVAL
1038 2012-01-01 21:47:45 <ByteCoin2> justmoon: Do I have to check whether you're correct before we continue the conversation?
1039 2012-01-01 21:48:12 <sipa> ByteCoin2: You're free to do, if you think that's necessary
1040 2012-01-01 21:48:16 <justmoon> GetSigOpCount goes over the script and counts the number of OP_CHECKSIGs and OP_CHECKMULTISIGs
1041 2012-01-01 21:48:21 <ByteCoin2> Put it this way - if I check and you are wrong will you concede the point?
1042 2012-01-01 21:48:31 <justmoon> it counts the OP_CHECKMULTISIGs as 20 as an upper bound
1043 2012-01-01 21:48:59 <justmoon> and then applies the sigops limits to that
1044 2012-01-01 21:49:19 <justmoon> gavin's OP_EVAL patch changes that behavior, rather than counting sigops before running
1045 2012-01-01 21:49:28 <justmoon> it just runs and if it runs into the limit it aborts
1046 2012-01-01 21:49:34 <midnightmagic> if people accept payment by bitcoin through IP address, does this mean that anyone who accepts it can be correlated if they are not careful with the "donation"?
1047 2012-01-01 21:49:50 <justmoon> I concede that there is no practical difference in any case that I can think of between applying the limit without execution and applying it with execution
1048 2012-01-01 21:50:21 <justmoon> but if you lose the *ability* to apply it without execution, I have an intuition that you lose something that *might* be useful
1049 2012-01-01 21:50:37 <justmoon> if i can't think of a concrete example and handling this case would incur significant overhead
1050 2012-01-01 21:50:40 <justmoon> I'll concede
1051 2012-01-01 21:50:59 <justmoon> if I can think of an example of if a statically analyzable version is just as good, I won't
1052 2012-01-01 21:51:36 <roconnor> if justmoon cannot think of an example that doesn't mean that someone won't be able to; and that person may not be as nice as justmoon.
1053 2012-01-01 21:52:15 <justmoon> roconnor: right, although static analysis is less of a potential attack vector as much as something that we might one day like to have as a feature
1054 2012-01-01 21:52:26 <justmoon> e.g. to sort transactions into categories or whatever
1055 2012-01-01 21:52:40 <roconnor> static analysis is a tool at our disposal to stop attack vectors
1056 2012-01-01 21:53:01 <justmoon> static analysis *may* be a tool at our disposal to stop attack vectors
1057 2012-01-01 21:53:42 <ByteCoin2> I'd like you guys to compile your thoughts into something a little bit more accessible than IRC logs
1058 2012-01-01 21:53:55 <ByteCoin2> And then make them available for review
1059 2012-01-01 21:54:02 MimeNarrator has quit (Ping timeout: 276 seconds)
1060 2012-01-01 21:54:16 <justmoon> ByteCoin2: gavin had the brilliant idea of starting an off-list email discussion, most of this is in there ... -_-
1061 2012-01-01 21:54:27 <justmoon> somebody should go, recompile and repost publicly
1062 2012-01-01 21:56:13 <justmoon> why is everybody looking at me?
1063 2012-01-01 21:56:20 <justmoon> :P
1064 2012-01-01 21:56:46 <justmoon> sipa, roconnor: unless one of you wants to do it I'll summarize and post to the mailing list?
1065 2012-01-01 21:57:01 <roconnor> justmoon: I wasn't part of the first part
1066 2012-01-01 21:57:14 slush has joined
1067 2012-01-01 21:57:16 <roconnor> I'm probably too opinionated :)
1068 2012-01-01 21:57:27 <justmoon> that's a good point, I wasn't part of the even earlier part
1069 2012-01-01 21:57:32 <ByteCoin2> I think you're a bit excitable
1070 2012-01-01 21:57:40 <sipa> justmoon: please do, if something's missing, i'll comment
1071 2012-01-01 21:57:53 <justmoon> k
1072 2012-01-01 21:58:01 <sipa> unless you prefer me to mail?
1073 2012-01-01 21:58:12 <justmoon> ByteCoin2: let him who is not excitable throw the first stone
1074 2012-01-01 21:58:26 <ByteCoin2> I thought I just did
1075 2012-01-01 21:58:46 <ByteCoin2> ;)
1076 2012-01-01 21:59:29 <ByteCoin2> afk for a bit
1077 2012-01-01 21:59:45 <justmoon> sipa: maybe I'll just put up a piratepad and just let everybody look over it before I post it to the list
1078 2012-01-01 21:59:46 <roconnor> "got 'im, dad!"
1079 2012-01-01 22:02:54 lfm has quit (Ping timeout: 252 seconds)
1080 2012-01-01 22:06:57 BurtyB has quit (Read error: Connection reset by peer)
1081 2012-01-01 22:10:37 Turingi has quit (Read error: Connection reset by peer)
1082 2012-01-01 22:11:13 TD has joined
1083 2012-01-01 22:12:10 <genjix> the problem with mailing list is all the white noise
1084 2012-01-01 22:12:31 <genjix> i dont get the chance to follow all the back and forth discussion
1085 2012-01-01 22:12:45 nus- is now known as nus
1086 2012-01-01 22:14:10 TD has quit (Client Quit)
1087 2012-01-01 22:20:14 <justmoon> roconnor: btw. it is better to use the OP_HASH160/OP_HASH256 pair for the dry runner attack than the OP_SHA256/OP_HASH256 pair because OP_HASH256(x) = OP_SHA256(OP_SHA256(x)) - which would allow the dry runner to theoretically do significant optimizations (it's no longer an exponential amount of possibilities, just a question of how many SHA256 hashes are applied) - also OP_HASH160 is slower than OP_SHA256
1088 2012-01-01 22:29:08 abragin has quit ()
1089 2012-01-01 22:30:12 nus has quit (Read error: Connection reset by peer)
1090 2012-01-01 22:30:14 nus- has joined
1091 2012-01-01 22:31:08 <roconnor> justmoon: fair point
1092 2012-01-01 22:31:51 adulau has quit (Ping timeout: 240 seconds)
1093 2012-01-01 22:33:28 <luke-jr> the problem with this OP_EVAL fight is that it's holding up everything else
1094 2012-01-01 22:38:31 <justmoon> luke-jr: what is it holding up?
1095 2012-01-01 22:39:08 <genjix> rate of blockchain prayers
1096 2012-01-01 22:39:21 <genjix> acceleration has slowed
1097 2012-01-01 22:39:31 <justmoon> I'm happy to postpone the OP_EVAL discussion into late 2012, personally, but from what I understand there are good reasons to have OP_EVAL deployed as soon as possible
1098 2012-01-01 22:40:35 <copumpkin> justmoon: what are they?
1099 2012-01-01 22:40:58 <copumpkin> it definitely gives a cool feature
1100 2012-01-01 22:41:18 <justmoon> copumpkin: OP_EVAL makes txouts smaller, so if we start using lots of multisig stuff the block chain would grow much faster without op-eval
1101 2012-01-01 22:41:39 <justmoon> or at least the harder-to-prune txouts would grow faster
1102 2012-01-01 22:41:48 <justmoon> or impossible-to-prune
1103 2012-01-01 22:41:58 <justmoon> whatever, ask someone else, my head is elsewhere, sorry ;)
1104 2012-01-01 22:43:31 <ByteCoin2> luke-jr: I'm not aware that the current "fight" is affecting development in any significant way. Is there any evidence to the contrary? I'm interested...
1105 2012-01-01 22:44:01 <sipa> ByteCoin2: i guess Gavin is currently concerned with rolling OP_EVAL out - this discussion is definitely making that take longer
1106 2012-01-01 22:44:24 <ByteCoin2> sipa: Has Gavin indicated the timescale has changed?
1107 2012-01-01 22:44:38 <sipa> i suppose he will delay it, yes
1108 2012-01-01 22:44:48 <ByteCoin2> sipa:He said so?
1109 2012-01-01 22:44:52 <luke-jr> ByteCoin2: coinbaser and signmessage_gui were approved for merging long before 0.5 merge window opened, but all merges have stopped now
1110 2012-01-01 22:45:13 <justmoon> sipa: gavin has pretty much said that he doesn't mind if it takes longer only that he doesn't want to just push x months back because then nobody would discuss it until we're again one month before deployment
1111 2012-01-01 22:45:34 datagutt has quit (Quit: Computer has gone to sleep.)
1112 2012-01-01 22:45:39 <justmoon> and he may have a point there
1113 2012-01-01 22:45:50 <luke-jr> justmoon: oh, so when discussion stops, whatever is decided is in? :P
1114 2012-01-01 22:46:01 <ByteCoin2> luke-jr: I imagine you meant for me to infer something from that... not sure what though
1115 2012-01-01 22:46:06 <justmoon> luke-jr: something like that yeah...
1116 2012-01-01 22:46:30 <luke-jr> ByteCoin2: I'm just annoyed at the delays for unrelated stuff :P
1117 2012-01-01 22:46:47 <luke-jr> on the bright side, I guess it means I don't have to rebase it either
1118 2012-01-01 22:47:15 <ByteCoin2> luke-jr: Is there any reason to believe that the two things are related - the delays and the current preoccupation?
1119 2012-01-01 22:47:35 <luke-jr> you're saying it's a coincidence?
1120 2012-01-01 22:48:11 <luke-jr> there's certainly a timing correlation
1121 2012-01-01 22:48:18 <ByteCoin2> You implied there was a link. It didn't seem obvious to me
1122 2012-01-01 22:48:37 <ByteCoin2> Lot's of things are temporally correlated
1123 2012-01-01 22:48:56 <ByteCoin2> Simply because lots of things can happen at the same time
1124 2012-01-01 22:50:03 dissipate has quit (Quit: Leaving)
1125 2012-01-01 22:50:53 nus- has quit (Ping timeout: 252 seconds)
1126 2012-01-01 22:51:12 <ByteCoin2> ;;seen gavinandresen
1127 2012-01-01 22:51:12 <gribble> gavinandresen was last seen in #bitcoin-dev 2 days, 22 hours, 40 minutes, and 59 seconds ago: <gavinandresen> (dinner was pretty good, kids and wife didn't like the veggies I cooked though)
1128 2012-01-01 22:53:25 <ByteCoin2> justmoon: You still here?
1129 2012-01-01 22:53:29 <genjix> developers are like gasoline
1130 2012-01-01 22:53:30 <justmoon> yea
1131 2012-01-01 22:53:33 <genjix> they can be used up
1132 2012-01-01 22:53:44 <justmoon> genjix: truth.
1133 2012-01-01 22:54:07 <luke-jr> maybe still Christmas too I guess
1134 2012-01-01 22:54:17 <luke-jr> I think I'm actually waiting on jgarzik and wumpus anyway
1135 2012-01-01 22:54:18 <ByteCoin2> My email address is bytecoin@gmx.com Could you email me the off list discussion so I can cut myself in?
1136 2012-01-01 22:54:29 <genjix> ByteCoin2: and roconnor
1137 2012-01-01 22:54:35 <genjix> roconnor: what is yours?
1138 2012-01-01 22:54:35 nus has joined
1139 2012-01-01 22:54:46 <luke-jr> what discussion?
1140 2012-01-01 22:54:52 <justmoon> genjix: I CC'd roconnor on the later emails, I only needs like two more or so
1141 2012-01-01 22:54:57 <justmoon> he* only needs
1142 2012-01-01 22:55:08 <genjix> luke-jr: about OP_EVAL
1143 2012-01-01 22:55:27 <justmoon> and those two were pretty retarded comments from me that are best left in the dustbin of history
1144 2012-01-01 22:55:39 <justmoon> I'm working on a summary of the discussion:
1145 2012-01-01 22:55:40 <genjix> it kind of grew by adding more people in
1146 2012-01-01 22:55:42 <justmoon> http://piratepad.net/E8AEAQJUw7
1147 2012-01-01 22:55:56 <luke-jr> genjix: feel free to CC me too
1148 2012-01-01 22:56:00 <luke-jr> no promises I'll read it tho
1149 2012-01-01 22:56:18 <genjix> ok whats your email?
1150 2012-01-01 22:56:26 <genjix> in fact i have a better idea
1151 2012-01-01 22:57:33 <sipa> being?
1152 2012-01-01 22:58:00 lianj has quit (Ping timeout: 255 seconds)
1153 2012-01-01 22:58:06 lianj has joined
1154 2012-01-01 22:58:07 lianj has quit (Changing host)
1155 2012-01-01 22:58:07 lianj has joined
1156 2012-01-01 22:58:32 * justmoon feels the summary he just spent 45 minutes writing is about to be obsoleted... -_-
1157 2012-01-01 22:59:03 <sipa> i think quite some people can use an update that is less than 15 e-mails being sent to and fro
1158 2012-01-01 22:59:59 <luke-jr> genjix: you know my email :p
1159 2012-01-01 23:00:01 <justmoon> especially given that my summary contains a few improvements like a stronger attack on the dry runner
1160 2012-01-01 23:02:00 BurtyB has joined
1161 2012-01-01 23:02:16 <genjix> luke-jr: i dont keep emails around, just tell me
1162 2012-01-01 23:02:33 <justmoon> genjix: luke@dashjr.org
1163 2012-01-01 23:02:38 <genjix> ok thanks
1164 2012-01-01 23:02:54 * justmoon pats his thunderbird on the head
1165 2012-01-01 23:02:57 bd_ has quit (Quit: back in a bit)
1166 2012-01-01 23:05:36 <luke-jr> genjix: luke-jr@bitcoinconsultancy.com
1167 2012-01-01 23:05:41 <luke-jr> * if you make the alias :p
1168 2012-01-01 23:06:09 <genjix> ok
1169 2012-01-01 23:06:16 <genjix> sent the email
1170 2012-01-01 23:08:08 <sipa> genjix: tuesday midnight is fine by me
1171 2012-01-01 23:09:14 <midnightmagic> is it possible to send bitcoin by IP using the command-line
1172 2012-01-01 23:09:30 <genjix> no
1173 2012-01-01 23:10:09 <genjix> sipa: would just be productive to make it a regular thing :) so the hand knows the foot
1174 2012-01-01 23:10:25 <midnightmagic> hrm.. and it requires -allowreceivebyip to be active.
1175 2012-01-01 23:11:02 <midnightmagic> there's a function of the GUI not represented in the client then?
1176 2012-01-01 23:12:03 <roconnor> justmoon: as far as I'm concerned it was you who pointed out that a dry runner cannot predict the outcome of an OP_CHECKSIG; but I'm not going to quibble over attribution too much. :P
1177 2012-01-01 23:12:20 <roconnor> at the very least it was a joint effort
1178 2012-01-01 23:14:13 <roconnor> justmoon: I thought luke-jr had some sort of DoS attack that is similar but not the same as excessive OP_CHECKSIG
1179 2012-01-01 23:15:31 <justmoon> roconnor: yes, his attack was simply to have a block that contains a single invalid transactions, a high latency verifies will likely verify a lot more transactions than a low latency one who can abort much more quickly once he sees the invalid tx
1180 2012-01-01 23:15:49 <justmoon> roconnor: and if there is already an attack like that, it doesn't really matter if there are more attacks like that
1181 2012-01-01 23:16:10 <justmoon> verifier*
1182 2012-01-01 23:16:30 <roconnor> I see
1183 2012-01-01 23:16:44 <justmoon> right now I'm on the fence myself
1184 2012-01-01 23:17:32 <justmoon> I agree with you that static analysis seems like a useful property, but I'm with gavin, luke and bytecoin that if we can't find a single example.... it's a very weak argument
1185 2012-01-01 23:19:33 <roconnor> The whole process of having us find some example is backwards from a security standpoint; The people proposing an extension should be the ones responsible for proving / providing evidence that there is no reason to keep static analysis or whatever. "I can't think of a problem with the proposal" shouldn't be sufficent.
1186 2012-01-01 23:20:29 <sipa> I'm still in the middle; on the one hand, it seems like such a nice property to waste, on the other hand, it seems every proposal that keeps it needs a compromise on features or other useful properties
1187 2012-01-01 23:25:10 <justmoon> sipa: agreed, but there is one thing I want to add:
1188 2012-01-01 23:25:43 nus has quit (Ping timeout: 252 seconds)
1189 2012-01-01 23:25:53 <justmoon> weak verifiability in my opinion should not be given any weight as a useful property. having it is better than not having it, but only very, very, very, slightly so. the "security" it provides is absolutely trivial to defeat - in fact I may do so just for fun, if anyone is insane enough to actually use OP_EVAL while there are still old clients in use
1190 2012-01-01 23:26:56 <sipa> i agree it should have very low priority
1191 2012-01-01 23:27:54 <justmoon> given that, I'm hopeful that codehash can be made as elegant or more elegant than the current implementation. but that still leaves arguments like the time already invested in the current impl that weigh in its favor
1192 2012-01-01 23:28:19 <justmoon> unless we can show static analysis to be useful in some scenario, i think the decision will fall on the existing impl
1193 2012-01-01 23:29:16 booo has quit (Ping timeout: 252 seconds)
1194 2012-01-01 23:29:22 adulau has joined
1195 2012-01-01 23:29:26 <sipa> roconnor: by the way, what do you think of ByteCoin's proposal, as mailed by Gavin?
1196 2012-01-01 23:29:53 <sipa> with OP_EVAL being replaced, rather than causing a sub-evaluation
1197 2012-01-01 23:30:21 <sipa> it sounds very easily well-specified, and it permits analysis after execution of scriptSig
1198 2012-01-01 23:30:27 <roconnor> on the surface it seems like a good idea
1199 2012-01-01 23:30:36 <roconnor> I haven't though much about it though
1200 2012-01-01 23:31:18 <justmoon> sipa: the way you explained it earlier it is completely pointless, but you said you don't understand it, so I'll withhold judgment until somebody explain what the proposal actually is
1201 2012-01-01 23:31:52 <sipa> yes, i don't understand how it allows observing the replacing script's hash
1202 2012-01-01 23:32:07 <sipa> ByteCoin2: maybe you can explain that?
1203 2012-01-01 23:33:13 imsaguy is now known as [\\\]
1204 2012-01-01 23:33:51 <ByteCoin2> Ok. I'm here for a few more mins... explain what exactly?
1205 2012-01-01 23:34:29 <sipa> ByteCoin2: gavin mailed about the original intent you had with OP_EVAL
1206 2012-01-01 23:34:30 adulau has quit (Read error: Operation timed out)
1207 2012-01-01 23:34:34 <sipa> with regard to semantics
1208 2012-01-01 23:34:46 nus has joined
1209 2012-01-01 23:35:12 <sipa> it would mean: execute scriptSig, replace OP_EVAL's in scriptPubKey with deserialized scripts from the stack resulting from scriptSig, run processed scriptPubKey
1210 2012-01-01 23:35:15 <ByteCoin2> sipa: For my original intent, I think it's best explained by my original post which gavin extracted into the OP_EVAL thread
1211 2012-01-01 23:35:27 <sipa> ok, link?
1212 2012-01-01 23:36:04 <sipa> i believe i read it, but found it rather complex
1213 2012-01-01 23:36:34 h4ckm3 has joined
1214 2012-01-01 23:36:37 <sipa> found it
1215 2012-01-01 23:38:49 <sipa> hmm, it's not what i believe Gavin described
1216 2012-01-01 23:40:05 <ByteCoin2> Interesting...
1217 2012-01-01 23:40:22 <ByteCoin2> sipa: Please point me to what Gavin described I meant
1218 2012-01-01 23:40:56 <sipa> ByteCoin2: i misread
1219 2012-01-01 23:42:13 <ByteCoin2> I'd probably find it helpful if you helped me understand how the scheme seems if you misread it
1220 2012-01-01 23:42:55 <sipa> ByteCoin2: gavin suggested (not on the mailinglist) the following semantics: a) execute scriptSig b) pre-process scriptPubKey by replacing any OP_EVAL's in it by values taken from the scriptSig resulting stack 3) execute the resulting scriptPubKey normally
1221 2012-01-01 23:43:17 <sipa> i misread it as that this was your original intent - it is not, it's just a proposal made by him
1222 2012-01-01 23:43:20 <justmoon> ByteCoin2: here's the exact text gavin used: http://piratepad.net/al7rhEBbeH
1223 2012-01-01 23:44:12 dissipate has joined
1224 2012-01-01 23:44:13 dissipate has quit (Changing host)
1225 2012-01-01 23:44:13 dissipate has joined
1226 2012-01-01 23:44:17 <justmoon> ByteCoin2: what I would find useful is if you stated whether OP_EVAL as implemented differs from your original idea and if so, how
1227 2012-01-01 23:44:51 <justmoon> or if anyone else can answer that question, that would help me too
1228 2012-01-01 23:45:04 <sipa> justmoon: ByteCoin2's original intent was to see the program as an instruction stack, and have OP_EVAL deserialize the normal stack onto the program stack
1229 2012-01-01 23:45:18 erle- has quit (Quit: erle-)
1230 2012-01-01 23:45:28 <sipa> instead of running a subevaluation
1231 2012-01-01 23:45:37 <ByteCoin2> I can't make statements about how it's implemented as I haven't familiarized myself with it. As Gavin said he was adopting my proposal, I assumed he had implemented what I proposed
1232 2012-01-01 23:45:40 <justmoon> ok, i see
1233 2012-01-01 23:45:56 <sipa> ByteCoin2: i believe it's very close
1234 2012-01-01 23:46:06 <sipa> but the way it is implemented makes it quite hard to judge whether it is
1235 2012-01-01 23:47:00 <ByteCoin2> I noticed he'd done it as some sort of recursive call to the script evaluation function. I assumed that it was equivalent and this was just a mechanism to check the nesting level of the OP_EVALs
1236 2012-01-01 23:47:03 <sipa> (the implementation spawns a new execution with a state that is shared by the original)
1237 2012-01-01 23:47:53 <justmoon> why restrict the nesting level?
1238 2012-01-01 23:48:06 kiba has joined
1239 2012-01-01 23:48:33 <sipa> I suppose because of an "no idea what could happen if we allow infinite recursion, but better be safe" thought
1240 2012-01-01 23:48:39 <kiba> hi
1241 2012-01-01 23:48:45 <kiba> sipa: you heard of my game?
1242 2012-01-01 23:48:54 <sipa> no
1243 2012-01-01 23:49:13 <justmoon> ... great so on that issue they want to err on the side of safety, but when it comes to static analysis we have to prove why we need it
1244 2012-01-01 23:49:18 <kiba> http://kibabase.com/articles/1-btc-later-the-city-game-development-report
1245 2012-01-01 23:49:39 <kiba> sipa: I am trying to get 2 BTC funding for the next version of my game
1246 2012-01-01 23:49:45 <ByteCoin2> I didn't really approve of implementing OP_EVAL using recursion but I assumed he had good reasons for doing so.
1247 2012-01-01 23:50:02 <kiba> so far I only got 0.25000001 BTC
1248 2012-01-01 23:50:16 <justmoon> ByteCoin2: he thought of a use case for depth, but not for depth three, so now the limit is two
1249 2012-01-01 23:50:17 nus has quit (Ping timeout: 252 seconds)
1250 2012-01-01 23:50:23 <justmoon> ByteCoin2: he thought of a use case for depth two, but not for depth three, so now the limit is two
1251 2012-01-01 23:50:48 <ByteCoin2> justmoon: I haven't seen Gavin's use case
1252 2012-01-01 23:51:05 <justmoon> isn't it page three in the OP_EVAL proposal thread?
1253 2012-01-01 23:51:19 <ByteCoin2> will look
1254 2012-01-01 23:51:24 <justmoon> i think it's this: https://bitcointalk.org/index.php?topic=46538.msg583802#msg583802
1255 2012-01-01 23:53:08 dissipate has quit (Ping timeout: 240 seconds)
1256 2012-01-01 23:55:19 <ByteCoin2> Depth=1 AFAICT. Just because it has 2 OP_EVALs != depth 2
1257 2012-01-01 23:56:30 <justmoon> depth 1 is the code inside OP_EVAL, depth 2 is the code inside an OP_EVAL inside an OP_EVAL
1258 2012-01-01 23:56:30 ByteCoin2 has left ()
1259 2012-01-01 23:56:46 <justmoon> so if you want to have an OP_EVAL in eval'd code that would be depth 2
1260 2012-01-01 23:56:52 <justmoon> sipa will correct me if I'm wrong
1261 2012-01-01 23:57:06 * kiba feels discouraged by the fact that nobody want to support his effort to produce a game
1262 2012-01-01 23:57:52 <justmoon> kiba: :( - sorry man, everyone is just really busy I think - there is a lot of important stuff not getting done at the moment - luke pointed that out earlier
1263 2012-01-01 23:58:09 bd_ has joined
1264 2012-01-01 23:58:10 <sipa> justmoon: you're correct
1265 2012-01-01 23:58:21 <sipa> (afaik)
1266 2012-01-01 23:59:26 <kiba> justmoon: been advertising to everyone that pass by, people got a whole lot of reasons not to donate a satoshi
1267 2012-01-01 23:59:36 nus has joined
1268 2012-01-01 23:59:39 <kiba> they think my demo sucks, they got no coins, they are too busy.
1269 2012-01-01 23:59:48 <kiba> that's fine with me