1 2012-01-01 01:20:02 <TeamColtra> mba|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?
  2 2012-01-01 01:20:29 <nanotube> TeamColtra|mba: yes
  3 2012-01-01 01:20:45 <TeamColtra> mba|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.
  4 2012-01-01 01:21:24 <nanotube> the only major problem with your system is that nobody will want to use it
  5 2012-01-01 01:21:36 <nanotube> i think bitcoin wins :)
  6 2012-01-01 01:21:37 <TeamColtra> mba|I guess the problem becomes what about the guy who is holding onto the coin at the end of the two months. >.>
  7 2012-01-01 01:23:37 <luke-jr> TeamColtra|mba: why do you assume that's a problem?
  8 2012-01-01 01:24:34 <TeamColtra> mba|Because it's not a currency at that point, it's an artificially inflated gold substitute
  9 2012-01-01 01:24:52 <TeamColtra> mba|artificially inflated by the people hording
 10 2012-01-01 01:25:19 <luke-jr> you're assuming gold cannot be used as currency
 11 2012-01-01 01:25:58 <TeamColtra> mba|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
 12 2012-01-01 01:26:38 <luke-jr> so?
 13 2012-01-01 01:26:53 <luke-jr> that's not exactly a problem.
 14 2012-01-01 01:27:22 <TeamColtra> mba|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
 15 2012-01-01 01:27:45 <luke-jr> not really, no.
 16 2012-01-01 01:28:04 <TeamColtra> mba|Explain?
 17 2012-01-01 01:28:19 <luke-jr> "the 10 richest people are the richest" is an oxymoron
 18 2012-01-01 01:29:04 <luke-jr> the problem you seem to be talking about is industrialization, and entirely unrelated
 19 2012-01-01 01:30:15 <TeamColtra> mba|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.
 20 2012-01-01 01:30:53 <luke-jr> if they have 90% of the money now, they have 90% of the money when we switch to Bitcoin
 21 2012-01-01 01:30:56 <luke-jr> nothing changes
 22 2012-01-01 01:30:58 <luke-jr> nor should it
 23 2012-01-01 01:31:14 <luke-jr> (at least, *Bitcoin* shouldn't be the game changer)
 24 2012-01-01 01:32:04 <luke-jr> what forces people to borrow is the central bank system, and usury.
 25 2012-01-01 01:32:12 <luke-jr> Bitcoin eliminates the central bank system.
 26 2012-01-01 01:32:23 <luke-jr> Bitcoin cannot eliminate usury.
 27 2012-01-01 01:32:40 <vsrinivas> such a system would be ... difficult.
 28 2012-01-01 01:32:50 <luke-jr> vsrinivas: ?
 29 2012-01-01 01:33:17 <vsrinivas> eliminating borrowing.
 30 2012-01-01 01:33:29 <TeamColtra> mba|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
 31 2012-01-01 01:33:38 <TeamColtra> mba|yes, you CAN trade them outside of the central system
 32 2012-01-01 01:34:24 <TeamColtra> mba|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
 33 2012-01-01 01:34:27 <luke-jr> vsrinivas: well, borrowing would also not be a problem without usury.
 34 2012-01-01 01:35:18 <vsrinivas> okay. are you defining usury as any interest? or very high interest? ; either way, very difficult to eliminiate via technical means...
 35 2012-01-01 01:35:21 <luke-jr> TeamColtra|mba: well, the State's duty comes in then
 36 2012-01-01 01:35:25 <luke-jr> vsrinivas: any interest.
 37 2012-01-01 01:35:41 <luke-jr> vsrinivas: sure, like I said, Bitcoin *cannot* eliminate it
 38 2012-01-01 01:35:48 <TeamColtra> mba|Again, i recognize an expiring bit coin isn't that feasible but think about this:
 39 2012-01-01 01:36:00 <vsrinivas> no argument there.
 40 2012-01-01 01:36:06 <TeamColtra> mba|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?
 41 2012-01-01 01:36:23 <luke-jr> TeamColtra|mba: people should not be encouraged to spend money
 42 2012-01-01 01:36:32 <luke-jr> hoarding is a good thing
 43 2012-01-01 01:36:41 <luke-jr> aka SAVING
 44 2012-01-01 01:36:43 <vsrinivas> i think we call that 'saving'
 45 2012-01-01 01:36:48 <luke-jr> :
 46 2012-01-01 01:37:48 <TeamColtra> mba|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
 47 2012-01-01 01:38:04 <TeamColtra> mba|of course, in the end, it was good because the last person who owns the grain could eat it
 48 2012-01-01 01:38:13 <luke-jr> &
 49 2012-01-01 01:38:26 <luke-jr> savings hasn't "become needed"
 50 2012-01-01 01:38:31 <luke-jr> it's always been needed
 51 2012-01-01 01:38:38 <TeamColtra> mba|For what?
 52 2012-01-01 01:38:45 <luke-jr> for buying a house, for instance.
 53 2012-01-01 01:38:55 <TeamColtra> mba|You keep paying for your house, and then it's paid off
 54 2012-01-01 01:38:59 <luke-jr> no
 55 2012-01-01 01:39:06 <luke-jr> that's the new system which is bad
 56 2012-01-01 01:39:11 <luke-jr> that's borrowing-based
 57 2012-01-01 01:39:41 <luke-jr> the right way: you save up money, and buy the house outright
 58 2012-01-01 01:40:46 <[Tycho]> I would never buy any cryptocurrency with artificially limited lifespan :)
 59 2012-01-01 01:41:06 <TeamColtra> mba|[Tycho]: yeah I have already stated that it wouldn't really work for a cryptocurrency
 60 2012-01-01 01:41:22 <luke-jr> [Tycho]: I would, provided you could 'refresh' it.
 61 2012-01-01 01:41:39 <TeamColtra> mba|because the difference between grain and crypto currency would be the last person in line can eat it
 62 2012-01-01 01:41:41 <[Tycho]> luke-jr: there is no point in that.
 63 2012-01-01 01:41:49 <luke-jr> [Tycho]: yes there is
 64 2012-01-01 01:41:59 <luke-jr> [Tycho]: it prevents permanent destruction
 65 2012-01-01 01:42:22 <[Tycho]> If you can refresh it then it won't stop hoarding, but adds chances to accidentally lose it.
 66 2012-01-01 01:42:34 <[Tycho]> Permanent destruction doesn't matters.
 67 2012-01-01 01:43:08 <vsrinivas> hmm if bitcoin were edible mining would be a whole different game.
 68 2012-01-01 01:43:13 <TeamColtra> mba|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
 69 2012-01-01 01:43:27 <TeamColtra> mba|I bet bit coins would be delicious
 70 2012-01-01 01:44:19 <TeamColtra> mba|like your bit coins could be refreshed through verifying blocks
 71 2012-01-01 01:45:31 <luke-jr> TeamColtra|mba: you sound jealous.
 72 2012-01-01 01:45:40 <luke-jr> TeamColtra|mba: like you want to steal from the rich
 73 2012-01-01 01:46:05 <TeamColtra> mba|Not at all& I just want money to be in flow.
 74 2012-01-01 01:46:14 <luke-jr> well that's stupid
 75 2012-01-01 01:46:19 <TeamColtra> mba|Because I feel that it would benefit the middle class more
 76 2012-01-01 01:46:32 <luke-jr> the middle class has no reason to be benefit more.
 77 2012-01-01 01:46:54 <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
 78 2012-01-01 01:48:05 <TeamColtra> mba|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)
 79 2012-01-01 01:48:33 <luke-jr> TeamColtra|mba: yeah, that's called SAVING
 80 2012-01-01 01:48:54 <luke-jr> TeamColtra|mba: you're basically saying to penalize people for being responsible.
 81 2012-01-01 01:48:57 <luke-jr> guess what that leads to
 82 2012-01-01 01:49:42 <TeamColtra> mba|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?
 83 2012-01-01 01:52:19 <luke-jr> TeamColtra|mba: why should it?
 84 2012-01-01 01:52:36 <luke-jr> the work you do hopefully helps the people paying you
 85 2012-01-01 01:55:21 <TeamColtra> mba|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
 86 2012-01-01 01:56:21 <luke-jr> nothing prevents you from contributing more
 87 2012-01-01 01:56:25 <TeamColtra> mba|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
 88 2012-01-01 01:56:45 <luke-jr> people need to spend money period.
 89 2012-01-01 01:56:57 <luke-jr> but spending for the sake of spending, is called waste.
 90 2012-01-01 01:57:02 <TeamColtra> mba|but it only works at its best when everyone is constantly spending and the economy encourages it
 91 2012-01-01 01:57:13 <luke-jr> I disagree.
 92 2012-01-01 01:57:22 <luke-jr> that's a waste-oriented economy
 93 2012-01-01 01:58:03 <TeamColtra> mba|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
 94 2012-01-01 01:58:31 <TeamColtra> mba|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
 95 2012-01-01 01:58:38 <TeamColtra> mba|or maybe even every other week
 96 2012-01-01 01:58:59 <Joric> i'm about to move to moscow an average 1 room appartment costs $0.5m salaries are $4k tops
 97 2012-01-01 01:59:04 <TeamColtra> mba|if I had encouragement to do that, like my money disappearing I would have the maid.
 98 2012-01-01 01:59:40 <TeamColtra> mba|That's not "waste" it's just giving more money into the economy
 99 2012-01-01 01:59:48 <TeamColtra> mba|more jobs, more people happy, more people getting services
100 2012-01-01 02:00:50 <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?
101 2012-01-01 02:01:08 <luke-jr> if your skillset is higher than a maid's, you should be paid more, and therefore hiring a maid is cheaper
102 2012-01-01 02:01:48 <TeamColtra> mba|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
103 2012-01-01 02:06:30 <luke-jr> TeamColtra|mba: so stop wasting time
104 2012-01-01 02:25:10 <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
105 2012-01-01 02:45:10 <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
106 2012-01-01 04:15:12 <CIA-100> bitcoin: Con Kolivas * ra4f6d5c68586 cgminer/NEWS: Update NEWS. http://tinyurl.com/7dcqmmz
107 2012-01-01 04:15:13 <CIA-100> bitcoin: Kano * r9bf0ad18a49b cgminer/main.c: Display pool in summary if only 1 pool http://tinyurl.com/7ny3rcf
108 2012-01-01 04:15:14 <CIA-100> bitcoin: Con Kolivas * r4f6cf3c8e9f2 cgminer/main.c: Merge pull request #65 from kanoi/master http://tinyurl.com/8xoq38j
109 2012-01-01 04:15:16 <CIA-100> bitcoin: Con Kolivas * rafa72ffec0a9 cgminer/main.c: Merge branch 'master' of github.com:ckolivas/cgminer http://tinyurl.com/7auf9op
110 2012-01-01 05:48:15 <genjix> hi
111 2012-01-01 05:57:29 <nanotube> hiya genjix :)
112 2012-01-01 06:01:10 <genjix> hey sup
113 2012-01-01 06:01:23 <nanotube> nm just hangin, thinking of going to sleep :)
114 2012-01-01 06:02:00 <genjix> i just fell asleep at my keyboard a few hours ago >_>
115 2012-01-01 06:02:05 <nanotube> heh
116 2012-01-01 06:02:06 <genjix> just got up
117 2012-01-01 06:06:22 <genjix> i wonder why the std::regex impl is so broken in g++
118 2012-01-01 06:06:33 <genjix> i mean couldnt they just copy the boost one over?
119 2012-01-01 06:07:21 <BlueMatt> genjix: what are you doing online on new years?
120 2012-01-01 06:07:29 <BlueMatt> what are you doing programming on new years?
121 2012-01-01 06:08:08 <genjix> ah i have no time for new years
122 2012-01-01 06:08:14 <genjix> :(
123 2012-01-01 06:08:40 <BlueMatt> that busy with bitcoinj?
124 2012-01-01 06:08:45 <BlueMatt> since when does bitcoinj have timelines?
125 2012-01-01 06:08:46 <genjix> actually im not too worried since bitcoin is fun
126 2012-01-01 06:09:48 <genjix> :( = social pressure to imagine i have regrets lol
127 2012-01-01 07:45:12 <CIA-100> libbitcoin: genjix * rb59738467c54 / (5 files in 4 dirs): Lookup external IP address using dyndns and whatismyip http://tinyurl.com/7nftxrj
128 2012-01-01 08:35:09 <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
129 2012-01-01 08:35:10 <CIA-100> bitcoin: Con Kolivas * r30e6b34ef012 cgminer/NEWS: Update NEWS. http://tinyurl.com/88bm3w4
130 2012-01-01 08:35:12 <CIA-100> bitcoin: Con Kolivas * rd515d318547b cgminer/configure.ac: Bump version number to 2.1.1 http://tinyurl.com/6odzx6l
131 2012-01-01 08:35:16 <grondilu> anyone knows how to open the database with Perl?  I tried with DB_File with no success.
132 2012-01-01 08:36:03 <grondilu> (I get only one entry with 'main' key and a four bytes value)
133 2012-01-01 08:48:12 <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
134 2012-01-01 15:16:30 <edcba> ;;bc,mtgox
135 2012-01-01 15:16:30 <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}}
136 2012-01-01 17:24:37 <Zarutian> basicly any unspent transaction older than (x * 52 * blocksPerWeek) relative to current block can be claimed by the miner of the next block
137 2012-01-01 17:25:13 <Zarutian> where x is 5, 10, 50 or any number between
138 2012-01-01 17:26:55 <Zarutian> that number has to be decided before this is implemented
139 2012-01-01 17:27:23 <Zarutian> any major holes in this proposed fix?
140 2012-01-01 17:27:54 <sipa> Why do you consider it a fix>
141 2012-01-01 17:28:54 <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
142 2012-01-01 17:29:25 <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.
143 2012-01-01 17:29:44 <sipa> how do you know the keys are lost?
144 2012-01-01 17:30:34 <Zarutian> same way that a webserver knows that a session is lost. It times out only the time scale is much much bigger.
145 2012-01-01 17:30:55 <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)
146 2012-01-01 17:32:12 <Zarutian> I consider current bitcoin chain to be a hard-beta test so to speak and I apreaciate advocates of the devil
147 2012-01-01 17:33:03 <sipa> I believe it is something to be taken into account when a successor or alternative is designed.
148 2012-01-01 17:33:13 <da2ce7> how is the 0.6 bitcoin client comming along? there has been a few blog posts about it's features already
149 2012-01-01 17:33:33 <Zarutian> damn, I see I should upgrade from 0.3.15
150 2012-01-01 17:34:03 <sipa> da2ce7: I expect a release in a few weeks
151 2012-01-01 17:34:25 <da2ce7> :)
152 2012-01-01 17:34:59 <da2ce7> multibit is making large strides... it has been inproving at a remarkable rate.
153 2012-01-01 17:35:26 <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?
154 2012-01-01 17:35:59 <da2ce7> is these the mtgox miss-spent coins?
155 2012-01-01 17:36:24 <sipa> Zarutian: the only solution i know of requires a very large change in the mining income calculation
156 2012-01-01 17:36:25 <da2ce7> the coins that belong to addres 1 or somthing?
157 2012-01-01 17:36:52 <sipa> Zarutian: you're basically burning old coins, in what you suggest?
158 2012-01-01 17:37:23 <Zarutian> da2ce7: nope coins that havent been moved around for a long time as mesured in bitcoin chain blocks
159 2012-01-01 17:37:46 <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
160 2012-01-01 17:37:47 <Zarutian> sipa: yes, and aviable for remining
161 2012-01-01 17:38:15 <da2ce7> Zarutian: that sounds like a stupid idea... coins belong to the address they have been spent to.
162 2012-01-01 17:38:27 <sipa> Zarutian: the mining formula is just 50 BTC << 2int(height / 216000)
163 2012-01-01 17:38:30 <da2ce7> there is no concept of 'coin age' other than confimations.
164 2012-01-01 17:39:08 <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
165 2012-01-01 17:39:12 <Zarutian> I suspect that Satoshi Nakamoto might have intented btc to eventually vanish (hey it is a experimental protocol for frack's sake)
166 2012-01-01 17:39:40 <Zarutian> sipa: indeed
167 2012-01-01 17:39:43 <sipa> There are some implementation issues which make me believe not everything was intended to stay the way it currently is
168 2012-01-01 17:39:55 <da2ce7> Zarutian: well wouldn't he placed the commented out code in the client, like he did with other intented features.
169 2012-01-01 17:40:41 <Zarutian> da2ce7: noone is prescient enough to think of all posibilities before hand
170 2012-01-01 17:41:13 <Zarutian> da2ce7: for example the txn script language is inspired by Forth yet you can not have nesting IFs
171 2012-01-01 17:41:32 <Zarutian> (but that might be a mistake)
172 2012-01-01 17:42:00 <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.
173 2012-01-01 17:42:30 <Zarutian> I am not discussing the morality of it, only how it might be implemented
174 2012-01-01 17:43:10 <sipa> I don't consider it a bad idea, but one that does need to be known in advance to anyone using the chain
175 2012-01-01 17:43:21 <da2ce7> ahh... well that is a totaly diffent questions... do you want to fork the current chain to make a new chain.
176 2012-01-01 17:43:33 <da2ce7> that would change how you would want to implment it.
177 2012-01-01 17:43:53 <Zarutian> da2ce7: that or do what namecoin did, start a new one.
178 2012-01-01 17:44:55 <da2ce7> I suspect the simpleist formular would be to dealay the 'reward half' point, but however long the burnt coins add up to.
179 2012-01-01 17:45:33 <da2ce7> so if you burn 100 coins... you will get 4 more blocks at 50 before you halve to 25.
180 2012-01-01 17:46:37 <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.
181 2012-01-01 17:47:45 <genjix> sipa: what do you think will be adopted for EVAL? i'm not in favour of lazy evaluation tbh
182 2012-01-01 17:47:51 <Zarutian> dac2ce7: what happens if someone burns 10 000 coins (lost his wallet or some such)? 400 more blocks before it halves?
183 2012-01-01 17:48:01 <sipa> genjix: what do you understand under lazy evaluation?
184 2012-01-01 17:48:19 <Zarutian> dac2ce7: or uneven number of coins? such as 97?
185 2012-01-01 17:48:30 <genjix> well justmoon said it has some problems
186 2012-01-01 17:48:42 <genjix> and i realised a whole bunch more
187 2012-01-01 17:49:04 <genjix> for instance it doesnt limit the number of sigops per block, just per transaction
188 2012-01-01 17:51:07 <sipa> I don't think it should be limited per block.
189 2012-01-01 17:51:24 <sipa> A miner may want to limit that, but that's not the responsibility of the network rules.
190 2012-01-01 17:51:57 <justmoon> hmm? are you guys saying MAX_BLOCK_SIGOPS is not enforced for incoming blocks?
191 2012-01-01 17:52:57 <sipa> justmoon: seems it is
192 2012-01-01 17:54:53 <justmoon> sipa: yeah it is, line 1157
193 2012-01-01 17:55:00 <justmoon> https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L1157
194 2012-01-01 17:56:10 <[Tycho]> Oh, why people are trying to propose a method of reminting "lost" coins AGAIN ?
195 2012-01-01 17:56:24 <[Tycho]> Please forget about it.
196 2012-01-01 17:58:43 <justmoon> sipa: do you understand gavin's idea? (the "ByteCoin's original intent" version)
197 2012-01-01 17:59:02 <copumpkin> http://www.youtube.com/watch?v=3kEfedtQVOY
198 2012-01-01 17:59:09 <justmoon> he says that it takes the "deserialized script from the stack" isn't that exactly what gavin's implementation does now?
199 2012-01-01 17:59:35 <sipa> justmoon: no
200 2012-01-01 17:59:49 <sipa> the current implementation takes it from the top of the stack at runtime
201 2012-01-01 18:00:09 <justmoon> yes? and this would take it from where?
202 2012-01-01 18:00:16 <sipa> the idea being proposed now, is that OP_EVAL codes are processed before execution of the script
203 2012-01-01 18:00:28 <copumpkin> that youtube talk is actually relevant
204 2012-01-01 18:00:33 <copumpkin> to the OP_EVAL stuff :)
205 2012-01-01 18:00:54 <sipa> namely, replacing them with the top elements of the scriptSig's stack, before executing scriptPubKey
206 2012-01-01 18:01:26 <sipa> I'd like to have roconnor's opinion about that
207 2012-01-01 18:01:38 <justmoon> how do you know scriptSig's stack without executing it?
208 2012-01-01 18:01:45 <sipa> you execute scriptSig
209 2012-01-01 18:01:54 <sipa> but you don't execute scriptPubKey yet
210 2012-01-01 18:02:09 <sipa> it's an extra processing step in between those exections
211 2012-01-01 18:02:59 <justmoon> how does that fix anything? we're still executing what could be the result of a complex calculation
212 2012-01-01 18:03:06 <justmoon> rather than a string literal
213 2012-01-01 18:03:30 <sipa> right - it implies execution of scriptSig before you can do analysis
214 2012-01-01 18:03:52 <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.
215 2012-01-01 18:04:00 <sipa> *could
216 2012-01-01 18:04:27 <genjix> sipa just explained to me in PM. from what i understood scripts are immutable because EVAL can only execute "push literals"
217 2012-01-01 18:04:35 <genjix> so you can count sig ops
218 2012-01-01 18:04:51 <justmoon> that rule alone would be enough - what's the benefit of the whole "only allow eval in scriptPubKey"?
219 2012-01-01 18:04:57 <sipa> genjix: we're now discussing a different idea
220 2012-01-01 18:05:06 <genjix> ah
221 2012-01-01 18:05:49 <sipa> justmoon: OP_EVAL is allowed in scriptPubKey, but it is processed before the actual execution of scriptPubKey
222 2012-01-01 18:06:30 <justmoon> sipa: what's the benefit of that over what we have now?
223 2012-01-01 18:06:57 <sipa> it does allow perfect static analysis, assuming you did already execute the scriptSig
224 2012-01-01 18:07:17 <justmoon> so what, you store the result of the scriptSig?!
225 2012-01-01 18:07:30 <justmoon> disregard that
226 2012-01-01 18:07:32 <sipa> that's how execution is done already
227 2012-01-01 18:07:48 <justmoon> yeah, yeah sorry, I was thinking the wrong way around
228 2012-01-01 18:07:54 <sipa> scriptSig is executed, and its resulting stack is used as a start point for the execution of scriptPubKey
229 2012-01-01 18:08:06 <justmoon> how does it help us to do static analysis of scriptPubKey?
230 2012-01-01 18:08:12 <justmoon> if we can't do it on scriptSig?
231 2012-01-01 18:08:35 <justmoon> or better - if we can't do it without running scriptSig
232 2012-01-01 18:10:02 <sipa> actually, I'm not sure I understand ByteCoin's idea completely, i realize now
233 2012-01-01 18:10:12 <justmoon> put differently: it's not really "static analysis" if you have to execute stuff to do it ^^
234 2012-01-01 18:10:31 <sipa> agree
235 2012-01-01 18:10:50 <sipa> but most of the complexity is in scriptPubKey, not in scriptSIhg
236 2012-01-01 18:10:51 <justmoon> all that's needed is some form of the literal rule from what I can tell
237 2012-01-01 18:11:11 <justmoon> I can put the complexity whether it causes the most damage
238 2012-01-01 18:11:15 <justmoon> if I'm an attacker
239 2012-01-01 18:11:25 <sipa> the literal rule still requires you to process literal that looks like a serialized script
240 2012-01-01 18:11:38 <sipa> without knowing whether it will be executed (or even can be)
241 2012-01-01 18:12:00 <justmoon> same as with OP_IF
242 2012-01-01 18:12:05 <sipa> yes
243 2012-01-01 18:12:07 <justmoon> the way we do it is we assume the worst
244 2012-01-01 18:12:16 <justmoon> i.e. everything is a script and everything will be executed
245 2012-01-01 18:12:31 <justmoon> if there is a way to make it a bit cleverer, great
246 2012-01-01 18:12:37 <sipa> but how will knowing an upper bound help you?
247 2012-01-01 18:12:52 <justmoon> well, you enforce your limit on the upper bound
248 2012-01-01 18:12:58 <justmoon> as we do now
249 2012-01-01 18:13:46 <justmoon> for example right now GetSigOpCount counts OP_CHECKMULTISIG as 20 sigops
250 2012-01-01 18:13:56 <justmoon> it counts all branches of OP_IFs etc.
251 2012-01-01 18:14:18 <sipa> right - we do have the chance to extend GetSigOpCount now
252 2012-01-01 18:14:34 <sipa> it only needs to be compatible with the old behaviour
253 2012-01-01 18:14:42 <justmoon> the only things that we can't have are "invisible" op codes and loops
254 2012-01-01 18:14:54 <justmoon> i.e. OP_WHILE would screw up GetSigOpcount
255 2012-01-01 18:15:19 <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
256 2012-01-01 18:15:35 <sipa> i don't like putting a rule that says "count all sigops in things that look a bit like a script"
257 2012-01-01 18:15:44 <justmoon> true
258 2012-01-01 18:15:46 <sipa> into the network rules
259 2012-01-01 18:16:09 <sipa> who knows you produce a signature or pubkey that accidentally happens to look like a very bad script
260 2012-01-01 18:16:48 <justmoon> so is there anything we can do to "mark" subscripts?
261 2012-01-01 18:17:55 <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
262 2012-01-01 18:18:08 <justmoon> it would add an extra byte though :(
263 2012-01-01 18:19:10 <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
264 2012-01-01 18:19:49 <sipa> or how many pushes to go back
265 2012-01-01 18:20:14 <justmoon> or just the position of the literal in the script?
266 2012-01-01 18:20:24 <sipa> for example
267 2012-01-01 18:20:39 <justmoon> would an extra constant screw up the backwards compatibility?
268 2012-01-01 18:20:45 <sipa> not necessarily
269 2012-01-01 18:21:05 <sipa> you can require the extra constant to be directly in front of OP_EVAL
270 2012-01-01 18:21:29 <sipa> and not use its value being pushed on the stack (just leave it there as well)
271 2012-01-01 18:22:09 <sipa> and I realize this doesn't work either
272 2012-01-01 18:22:26 <justmoon> why not?
273 2012-01-01 18:23:00 <sipa> any cod you write to validate the hash of the script being executed will work at run time on the stack
274 2012-01-01 18:23:23 <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
275 2012-01-01 18:23:49 <justmoon> you're right
276 2012-01-01 18:24:19 <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
277 2012-01-01 18:25:25 <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)".
278 2012-01-01 18:25:27 <justmoon> I keep coming back to the idea that the literal just needs to be marked in some way
279 2012-01-01 18:25:40 <justmoon> like the execute bit in processors
280 2012-01-01 18:25:50 <sipa> that would be an easy fix
281 2012-01-01 18:26:29 <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
282 2012-01-01 18:26:41 <sipa> in particular, hashes are hard to guarantee
283 2012-01-01 18:26:47 <justmoon> what if it's an operation rather than a bit in the data?
284 2012-01-01 18:27:02 <sipa> *bingo*
285 2012-01-01 18:27:07 <sipa> wait, no
286 2012-01-01 18:27:24 <genjix> wait, would it help if EVAL was always followed by a checksum for the script it executes?
287 2012-01-01 18:27:40 <sipa> genjix: like my original proposal
288 2012-01-01 18:27:41 <genjix> EVAL<checksum> as one piece
289 2012-01-01 18:27:57 <genjix> aha
290 2012-01-01 18:28:07 <sipa> it requires a push of the checksum before the OP_EVAL
291 2012-01-01 18:28:08 <justmoon> genjix: the checksum doesn't tell you what's in the script
292 2012-01-01 18:28:26 <genjix> ohh that's what you were talking about with gavin in the emails
293 2012-01-01 18:28:30 <genjix> ok gotcha.
294 2012-01-01 18:28:33 <sipa> but it's not very nice
295 2012-01-01 18:28:46 <genjix> yeah implementation wise it's a bit of a hassle
296 2012-01-01 18:29:38 <genjix> roconnor does have a point about not being too hasty
297 2012-01-01 18:29:50 <genjix> 6 months is a good timeline, better than 3
298 2012-01-01 18:29:51 <copumpkin> "don't put turing into your protocols"
299 2012-01-01 18:29:58 <justmoon> sipa: if the checksum is after the OP_EVAL it would be pretty clean implementation wise, no?
300 2012-01-01 18:30:07 <genjix> but whatever i trust you all
301 2012-01-01 18:30:23 <justmoon> you just increment the script pointer
302 2012-01-01 18:30:38 <justmoon> or does it screw up backwards compatibility again?
303 2012-01-01 18:30:40 <justmoon> ...
304 2012-01-01 18:30:49 <genjix> yes
305 2012-01-01 18:31:00 <sipa> not necessarily
306 2012-01-01 18:31:02 <genjix> bitcoin expects OP's
307 2012-01-01 18:31:17 <sipa> it would be a push, of course
308 2012-01-01 18:31:20 <genjix> script would be unparsable otherwise unless you mandated a push
309 2012-01-01 18:31:23 <genjix> yeah
310 2012-01-01 18:31:51 <sipa> but it would not be very different from my first proposal
311 2012-01-01 18:32:06 <genjix> ok that could work too. when reading an eval, then it would instantly read the next OP
312 2012-01-01 18:32:10 <sipa> i believe it still deals with all concerns, but i don't particularly like it myself
313 2012-01-01 18:33:24 <justmoon> how does it provide static analysis? you look for OP_EVAL <checksum> then parse any data that matches checksum?
314 2012-01-01 18:33:29 <justmoon> recursively?
315 2012-01-01 18:33:50 <sipa> no
316 2012-01-01 18:33:54 <genjix> well the idea is that OP_EVAL <checksum> are one op. they cannot be separated. OP_EVAL without the <checksum> fails
317 2012-01-01 18:34:07 <sipa> you go back to the last not-yet-used-by-op-eval push
318 2012-01-01 18:34:10 <sipa> and execute that
319 2012-01-01 18:34:15 <justmoon> genjix: I'm not talking about execution now, but about static analysis
320 2012-01-01 18:34:34 <sipa> and that isn't good either
321 2012-01-01 18:34:36 <justmoon> sipa: that's way more complicated than necessary
322 2012-01-01 18:34:41 <sipa> how so?
323 2012-01-01 18:34:58 <justmoon> if the only problem we're trying to solve is to distinguish script literals from other literals
324 2012-01-01 18:35:02 <genjix> counting the sig ops in the data recursively is totally fine
325 2012-01-01 18:35:04 <sipa> justmoon: no
326 2012-01-01 18:35:18 <sipa> we're trying to distinguish things that will be executed from things that won't
327 2012-01-01 18:35:22 <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
328 2012-01-01 18:35:37 <justmoon> we just require that we find some literal that matches the checksum during static analysis
329 2012-01-01 18:35:47 <sipa> you really want a rule that says "try hashing *everything* and matching it with this hash?", in the network rules?
330 2012-01-01 18:36:24 <justmoon> well, it's a vast improvement over the current proposal with very little implementation complexity
331 2012-01-01 18:36:38 <genjix> hashing is the least of my worries
332 2012-01-01 18:36:39 <sipa> or do you just exectute the top of the stack?
333 2012-01-01 18:36:49 <genjix> especially with the database
334 2012-01-01 18:36:55 <sipa> that's a possbility, actually
335 2012-01-01 18:37:00 <sipa> aaargh no
336 2012-01-01 18:37:06 <justmoon> top of the stack?
337 2012-01-01 18:37:10 <justmoon> what was the idea?
338 2012-01-01 18:37:13 <sipa> we lose semi-verifiability by old nodes then
339 2012-01-01 18:37:27 <justmoon> with the checksum-after?
340 2012-01-01 18:37:30 <sipa> yes
341 2012-01-01 18:37:37 <sipa> because they won't verify the checksum
342 2012-01-01 18:37:42 <justmoon> do we care about semi-verifiability?
343 2012-01-01 18:37:53 <sipa> it is low-priority
344 2012-01-01 18:38:00 <sipa> but i'd prefer a solution that has it
345 2012-01-01 18:38:18 <justmoon> what was the top of the stack thought?
346 2012-01-01 18:38:25 <justmoon> did you solve that having to hash everything problem?
347 2012-01-01 18:38:30 <sipa> justmoon: explain your full idea now
348 2012-01-01 18:38:50 <sipa> because we're mixing things from all kinds of idea, i don't know what we're talking about anymore
349 2012-01-01 18:39:35 <justmoon> I have all kinds of ideas right now - but we went over the problems with most of them
350 2012-01-01 18:39:54 <sipa> ok, i'll list things that i consider viable
351 2012-01-01 18:39:58 <justmoon> oh you mean the execution bit thing?
352 2012-01-01 18:40:16 <justmoon> we could prefix executable literals with OP_NOP2
353 2012-01-01 18:40:37 <justmoon> call it OP_EVALPUSH or whatever
354 2012-01-01 18:40:49 <justmoon> in addition to the normal PUSHDATA of course
355 2012-01-01 18:41:04 <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
356 2012-01-01 18:41:37 <sipa> that gives you static analysis, by recursing into each value whose hash is a checksum for an OP_EVAL
357 2012-01-01 18:42:10 <sipa> however, if you want a sigops limit, that would mean putting that recursion rule into the network rules - which i do not like
358 2012-01-01 18:42:18 <justmoon> agreed
359 2012-01-01 18:42:59 <justmoon> are there any downsides to OP_EVALPUSH other than +1 byte per OP_EVAL?
360 2012-01-01 18:43:00 <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
361 2012-01-01 18:43:10 <sipa> extra bytes, but waste another opcode
362 2012-01-01 18:43:30 <justmoon> extra byte - singular :P
363 2012-01-01 18:43:35 <sipa> right
364 2012-01-01 18:43:58 <justmoon> can we reuse OP_EVAL somehow?
365 2012-01-01 18:44:10 <justmoon> probably not :/
366 2012-01-01 18:44:18 <sipa> have OP_EVAL have a different meaning in scriptSig and scriptPubKey? yes, possible
367 2012-01-01 18:44:31 <justmoon> nah that doesn't allow recursion I don't think
368 2012-01-01 18:44:33 <justmoon> does it?
369 2012-01-01 18:44:41 <justmoon> no it doesn't
370 2012-01-01 18:44:52 <sipa> indeed
371 2012-01-01 18:44:57 <genjix> ohhh OP_EVALPUSH
372 2012-01-01 18:45:00 <genjix> that's nice
373 2012-01-01 18:45:18 <sipa> I think we need gavin in this discussion
374 2012-01-01 18:45:42 <sipa> my favorite right now is the prefix position push
375 2012-01-01 18:46:26 <sipa> actually, i'd throw the script language out and replace it with something clean ;)
376 2012-01-01 18:46:30 <genjix> hah OP_EVAL has a location inside the script for its data?
377 2012-01-01 18:46:35 <sipa> yes
378 2012-01-01 18:52:50 <sipa> genjix: read my initial proposal
379 2012-01-01 18:52:57 <luke-jr> sipa: sigop count is irrelevant
380 2012-01-01 18:53:03 <sipa> is it?
381 2012-01-01 18:53:16 <sipa> there is a network rule about it
382 2012-01-01 18:53:20 <justmoon> luke-jr: no it isn't, it is an enforced limit, i.e. it may invalidate the block
383 2012-01-01 18:53:22 <luke-jr> sipa: since they can vary in complexity, yes
384 2012-01-01 18:53:33 <luke-jr> justmoon: it's not like you can't test it anyway
385 2012-01-01 18:53:40 <luke-jr> in fact, anyone makign a block *needs* to test it
386 2012-01-01 18:53:51 <luke-jr> by execution
387 2012-01-01 18:53:56 <sipa> that is why you want to make it easy to test
388 2012-01-01 18:54:04 <luke-jr> sipa: it is easy to test
389 2012-01-01 18:54:05 <luke-jr> execute
390 2012-01-01 18:54:11 <luke-jr> you HAVE to execute no matter what
391 2012-01-01 18:54:11 <sipa> preferrably, in a way that doesn't require execution
392 2012-01-01 18:54:15 <sipa> no
393 2012-01-01 18:54:18 <luke-jr> &
394 2012-01-01 18:54:26 <justmoon> luke-jr: if you can only test it by execution, then parallelized implementations with high latencies are potentially vulnerable
395 2012-01-01 18:54:29 <sipa> if you know it is invalid in advance, you do not need to executre
396 2012-01-01 18:55:00 <genjix> i dont like having to execute scripts in a dry run
397 2012-01-01 18:55:04 <sipa> so you want an easy, fast, criterion to decide validity
398 2012-01-01 18:55:19 <sipa> and yes, dry-run is a possibility for that
399 2012-01-01 18:55:40 <luke-jr> even if it passes the "easy, fast" criterion, you still need to execute it
400 2012-01-01 18:55:45 <sipa> of course
401 2012-01-01 18:55:53 <sipa> but not if it isn't
402 2012-01-01 18:55:56 <sipa> that's the point
403 2012-01-01 18:56:01 <genjix> sipa: where is your original post?
404 2012-01-01 18:56:06 <luke-jr> so in the normal case, you're doing MORE work to static analyze it.
405 2012-01-01 18:56:08 <sipa> not requiring execution of things that are guaranteed to be invalid
406 2012-01-01 18:56:09 <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
407 2012-01-01 18:56:16 <justmoon> decentralized pool*
408 2012-01-01 18:56:34 <sipa> justmoon: you bail out as soon as you hit the sigops execution limit, of course
409 2012-01-01 18:56:56 <luke-jr> justmoon: and if you beat that with static analysis, they can waste your CPU time another way just as easily.
410 2012-01-01 18:57:10 <copumpkin> amusingly, that talk I linked to (that I claimed was vaguely relevant to OP_EVAL) also mentioned bitcoin :)
411 2012-01-01 18:57:12 <justmoon> sipa: which you only find out about after 1 1/2 round trips with the central hosts
412 2012-01-01 18:57:25 <sipa> that is why the static analysis needs to be easy
413 2012-01-01 18:58:07 <genjix> polymorphic bitcoin code using op_eval :)
414 2012-01-01 18:58:11 <luke-jr> it's extra work for no gain ;)
415 2012-01-01 18:58:21 <luke-jr> static analysis, I mean
416 2012-01-01 18:58:28 <justmoon> luke-jr: they can only waste it the same as for big centralized pools
417 2012-01-01 18:58:33 <sipa> luke-jr: don't understand too much under that word
418 2012-01-01 18:58:47 <sipa> luke-jr: the current (pre-op-eval) GetSigOpsCount is a static analyzer
419 2012-01-01 18:58:48 <luke-jr> there are much easier ways to perform the same DoS, without hiding sigops
420 2012-01-01 18:58:51 <copumpkin> people keep throwing it around without knowing what it would actually entail
421 2012-01-01 18:58:51 <sipa> and it works
422 2012-01-01 18:58:58 <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
423 2012-01-01 18:59:17 <luke-jr> justmoon: relevance?
424 2012-01-01 18:59:45 <justmoon> luke-jr: we like decentralization and would like to avoid unnecessarily adding road blocks for decentralized alternatives?
425 2012-01-01 19:00:05 <luke-jr> justmoon: &
426 2012-01-01 19:00:15 <luke-jr> as you just said, decentralization is irrelevant to the topic
427 2012-01-01 19:00:31 <luke-jr> nobody is going to be stupid enough to make a block that will fail
428 2012-01-01 19:00:42 <sipa> an attacker may
429 2012-01-01 19:00:43 <luke-jr> the cost is so much higher than the time wasted to deal with it
430 2012-01-01 19:00:58 <luke-jr> and there are much easier ways to make an invalid block if they wanted to do that
431 2012-01-01 19:01:08 <justmoon> luke-jr: that depends whats more expensive, hashing or tx verification
432 2012-01-01 19:01:27 <luke-jr> ie, fill the block with the max valid transactions, then have the last one be invalid for some other reason
433 2012-01-01 19:03:03 <justmoon> hmm
434 2012-01-01 19:03:27 <justmoon> it's true, there are other attacks you could come up with that hurt high-latency verifiers more I think
435 2012-01-01 19:03:44 <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
436 2012-01-01 19:04:08 <sipa> and just require that OP_EVAL'ed scripts are literals
437 2012-01-01 19:04:55 <sipa> and just let GetSigOpsCount work based on dry-run
438 2012-01-01 19:05:13 <luke-jr> why require that OP_EVAL'd scripts are literals, even, btw?
439 2012-01-01 19:06:16 <luke-jr> !
440 2012-01-01 19:06:26 <justmoon> sipa: you can't dry run because it has exponential time complexity
441 2012-01-01 19:06:39 <luke-jr> slightly off topic: maybe the first octet of an OP_EVAL script can/should be a version number?
442 2012-01-01 19:06:54 <sipa> luke-jr: i like that idea
443 2012-01-01 19:07:03 <luke-jr> so for example, if 0.6 sees it "version 2", it treats it as OP_NOP again
444 2012-01-01 19:07:13 <justmoon> sipa: you can either make it statically analyzable, or you can do no checks other than execution
445 2012-01-01 19:07:15 <luke-jr> which lets us even easier upgrade the inside-OP_EVAL scripts
446 2012-01-01 19:07:54 <luke-jr> sipa: is there a sensible way to add it without breaking compatibility with the existing OP_EVAL txns in the chain?
447 2012-01-01 19:07:55 <sipa> justmoon: bah, true
448 2012-01-01 19:08:14 <sipa> luke-jr: there are only OP_EVAL's in the testnet chain, no?
449 2012-01-01 19:08:35 <luke-jr> sipa: not sure
450 2012-01-01 19:08:51 <sipa> roconnor: please
451 2012-01-01 19:09:00 <justmoon> luke-jr: why not just make it dependant on the tx version?
452 2012-01-01 19:09:07 <justmoon> rather than adding another byte...
453 2012-01-01 19:09:23 <luke-jr> justmoon: txn version AFAIK is about revising the individual txn, not txn format
454 2012-01-01 19:09:52 <justmoon> luke-jr: you're right, block version then?
455 2012-01-01 19:10:15 <justmoon> also the wiki page is wrong, it describes the version field as "Transaction data format version"
456 2012-01-01 19:10:19 <roconnor> luke-jr: I think you are wrong abu txn version
457 2012-01-01 19:10:22 <justmoon> -_-
458 2012-01-01 19:10:40 <roconnor> there is another field for revising txn I think
459 2012-01-01 19:10:43 <justmoon> right...
460 2012-01-01 19:10:44 <luke-jr> justmoon: pretty sure current clients will  not accept blocks with unknown versions
461 2012-01-01 19:10:57 <justmoon> they do, there are unusual block versions on testnet
462 2012-01-01 19:11:03 <luke-jr> oh?
463 2012-01-01 19:11:12 <justmoon> luke-jr: you confused tx version and sequence maybe?
464 2012-01-01 19:11:12 <luke-jr> so I can make a "version 2" block that everyone ignores?
465 2012-01-01 19:11:16 <luke-jr> maybe
466 2012-01-01 19:11:22 <roconnor> I think the txLock is for revising transactions
467 2012-01-01 19:11:28 <sipa> nSequence, in txins?
468 2012-01-01 19:11:38 <sipa> i think that is what luke-jr refers to
469 2012-01-01 19:11:43 <roconnor> oh right
470 2012-01-01 19:11:44 <roconnor> nSequence
471 2012-01-01 19:11:57 <luke-jr> in any case, would bumping the txn or block ver # allow backward compat?
472 2012-01-01 19:12:01 <justmoon> yeah, so you could use the tx version to make OP_EVAL nop again
473 2012-01-01 19:13:02 <luke-jr> &
474 2012-01-01 19:15:05 <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...
475 2012-01-01 19:15:28 <sipa> you just came up with a use case
476 2012-01-01 19:15:33 <justmoon> I did?
477 2012-01-01 19:15:41 <sipa> GetSigOpsCount
478 2012-01-01 19:16:06 <justmoon> well, but luke just destroyed my use case for *that* ^^
479 2012-01-01 19:16:15 <sipa> how so?
480 2012-01-01 19:16:39 <sipa> by giving another way that could also be used to cause latency in distributed verifiers?
481 2012-01-01 19:16:44 <justmoon> I thought it was a nice defense against asymmetric attacks against high latency verifiers yes
482 2012-01-01 19:16:53 <justmoon> and luke pointed out there are other attacks with the same properties anyway
483 2012-01-01 19:17:34 <sipa> right
484 2012-01-01 19:17:50 <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
485 2012-01-01 19:18:03 <justmoon> god I can't type for shit...
486 2012-01-01 19:18:25 <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
487 2012-01-01 19:18:28 <justmoon> there, fixed
488 2012-01-01 19:18:51 <TD> happy new year everyone!
489 2012-01-01 19:18:53 <justmoon> sipa: have we thought that through yet?
490 2012-01-01 19:18:57 <luke-jr> sipa: that's not extensible.
491 2012-01-01 19:18:58 <justmoon> TD: happy new year!
492 2012-01-01 19:19:01 <sipa> luke-jr: explain
493 2012-01-01 19:19:05 <sipa> TD: you too!
494 2012-01-01 19:19:10 <luke-jr> sipa: we can't add key extraction to it
495 2012-01-01 19:19:25 <sipa> that's entirely independent...
496 2012-01-01 19:20:14 <sipa> justmoon: haven't found a reason why it'd be impossible (except a bit dirty semantics when referring to scriptSig code)
497 2012-01-01 19:20:48 <sipa> sec, brb
498 2012-01-01 19:28:25 <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)
499 2012-01-01 19:28:56 <justmoon> yes, I suggested it earlier
500 2012-01-01 19:29:06 <roconnor> okay good.
501 2012-01-01 19:29:19 <justmoon> downsides are +1 byte per OP_EVAL and -1 NOP left to use in future
502 2012-01-01 19:29:21 <roconnor> Acutally I don't like it very much; still to hard to do static analysis.
503 2012-01-01 19:29:26 <roconnor> *too hard
504 2012-01-01 19:29:43 <justmoon> you can require it to be a literal prefix
505 2012-01-01 19:30:00 <justmoon> then static analysis should be trivial with it, no?
506 2012-01-01 19:30:20 <roconnor> well, it may be hard to tell how many times the code will be OP_EVALd
507 2012-01-01 19:30:40 <roconnor> the way the script works right now is really convenient.
508 2012-01-01 19:30:52 <roconnor> nice and linear ... well linearish
509 2012-01-01 19:30:58 <justmoon> can it be eval'd more than once?
510 2012-01-01 19:31:06 <justmoon> if you disallow OP_DUP etc?
511 2012-01-01 19:31:13 <roconnor> Hmm
512 2012-01-01 19:31:18 <justmoon> or not disallow
513 2012-01-01 19:31:20 <roconnor> I didn't think about disallowing OP_DUP
514 2012-01-01 19:31:23 <roconnor> and OP_DROP
515 2012-01-01 19:31:33 <roconnor> that makes it a linear calculus
516 2012-01-01 19:31:36 <justmoon> not disallow, but have it drop the execute bit
517 2012-01-01 19:31:36 <roconnor> interesting
518 2012-01-01 19:31:46 <justmoon> i.e. turn it into normal data
519 2012-01-01 19:35:24 <roconnor> I kinda think that my CODEHASH proposal is better than all this
520 2012-01-01 19:35:48 <roconnor> It has the least amount of Unknowns IMHO
521 2012-01-01 19:36:26 <roconnor> though it doesn't satify sipa's NOP extension principle :(
522 2012-01-01 19:36:44 <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"
523 2012-01-01 19:36:59 <roconnor> justmoon: why does the current client do static analysis?
524 2012-01-01 19:37:13 <justmoon> roconnor: because it can I suppose
525 2012-01-01 19:37:36 <BlueMatt> roconnor: I might be a bit behind what advantages does yours have over sipa's simple OP_EVAL runs in restricted environment one?
526 2012-01-01 19:38:12 <copumpkin> cleaner semantics, doesn't it?
527 2012-01-01 19:38:58 <roconnor> BlueMatt: I may not fully understand sipa's proposal.
528 2012-01-01 19:39:04 <justmoon> BlueMatt: restricted environment is the proposal I'm least familiar with, but I know that it's one of the hardest to implement
529 2012-01-01 19:39:35 <sipa> roconnor: which proposal exactly?
530 2012-01-01 19:39:45 <roconnor> sipa: I don't know.
531 2012-01-01 19:39:51 <sipa> I've done quite a few suggestions the past few days
532 2012-01-01 19:39:52 <justmoon> sipa: OP_CHECKEDEVAL
533 2012-01-01 19:40:00 <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"
534 2012-01-01 19:40:08 <BlueMatt> the simplest one
535 2012-01-01 19:40:22 <sipa> BlueMatt: yes, but that is not enough for static analysis
536 2012-01-01 19:40:30 <BlueMatt> meh...
537 2012-01-01 19:40:53 <BlueMatt> imho its the simplest one which gets rid of the most "there be dragons" complaints
538 2012-01-01 19:40:58 <justmoon> what *is* the benefit of a separate environment?
539 2012-01-01 19:41:01 <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).
540 2012-01-01 19:41:19 <justmoon> BlueMatt: no the dragons come from being able to make code and then run it, not whether it runs sandboxed
541 2012-01-01 19:41:21 <roconnor> justmoon: you don't have to do that stupid second pass of treating OP_EVAL as a NOP
542 2012-01-01 19:41:22 <sipa> justmoon: understandable semantics
543 2012-01-01 19:41:25 <justmoon> BlueMatt: it's all sandboxed anyway
544 2012-01-01 19:42:20 <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
545 2012-01-01 19:42:32 <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"
546 2012-01-01 19:42:41 <BlueMatt> well aside from the turing completeness stuff
547 2012-01-01 19:43:01 <justmoon> BlueMatt: the off-mailing-list discussion kinda went in a different direction...
548 2012-01-01 19:43:09 <justmoon> who's idea was it to go off the mailing list anyways...
549 2012-01-01 19:43:16 <sipa> gavin :)
550 2012-01-01 19:43:25 <sipa> we should head back there
551 2012-01-01 19:43:45 <BlueMatt> meh, whatever I guess Im just behind then...
552 2012-01-01 19:43:57 <justmoon> can we simplify it a bit for me - i.e. what the criticisms are exactly?
553 2012-01-01 19:44:02 <justmoon> I understand the static analysis one
554 2012-01-01 19:44:11 <justmoon> are there entirely distinct other criticisms?
555 2012-01-01 19:44:27 <roconnor> justmoon: I don't like the pseduo-turing completeness
556 2012-01-01 19:44:30 <sipa> it is hard to understand how e.g. OP_EVAL and IF_THEN_ELSE nesting work together
557 2012-01-01 19:44:33 <sipa> and hard to specify
558 2012-01-01 19:44:53 <sipa> by running the subscript in another environnement, you get understandable semantics
559 2012-01-01 19:44:55 <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"
560 2012-01-01 19:45:00 <sipa> it's a different script altogether
561 2012-01-01 19:45:37 <justmoon> sipa: ok, that makes sense
562 2012-01-01 19:45:44 <justmoon> sipa: is that CHECKEDEVAL or something else?
563 2012-01-01 19:45:46 <copumpkin> roconnor: did you see the CCC talk about not putting TC-ness into your protocols just a couple of days ago?
564 2012-01-01 19:45:57 <sipa> justmoon: checkedeval does that, plus static analysis
565 2012-01-01 19:46:04 <justmoon> sipa: k
566 2012-01-01 19:46:11 <roconnor> justmoon: and no one has proved that looping is impossible even with depth 2 limitations AFAIK.
567 2012-01-01 19:46:41 <roconnor> copumpkin: nope, but having non-TC DSLs is pretty common nowadays AFAIU.
568 2012-01-01 19:46:44 <copumpkin> roconnor: http://www.youtube.com/watch?v=3kEfedtQVOY (also mentions bitcoin at the end, briefly)
569 2012-01-01 19:46:51 <copumpkin> roconnor: yeah, but tell the security guys that
570 2012-01-01 19:46:55 <copumpkin> that's what this talk does ;)
571 2012-01-01 19:47:08 <roconnor> really; I thought the security guys would be the first to know
572 2012-01-01 19:47:22 <copumpkin> not at all, most of them turn their noses up at PL/type theory
573 2012-01-01 19:47:59 <copumpkin> unfortunately the bitcoin mention is unrelated to the topic of the talk :)
574 2012-01-01 19:50:36 <justmoon> roconnor: do we care about looping? it'll exhaust the 200 ops counter anyway, no?
575 2012-01-01 19:50:48 <roconnor> I guess
576 2012-01-01 19:51:23 <roconnor> although that counter is pretty stupid to begin with
577 2012-01-01 19:51:29 <justmoon> looping makes static analysis impossible of course
578 2012-01-01 19:51:38 <justmoon> so if we care about that we care about looping by extension
579 2012-01-01 19:51:38 <roconnor> counting non-executed operations in IF branches
580 2012-01-01 19:57:53 <sipa> roconnor: what do you think about having OP_EVAL refer to the push of the script that it executes?
581 2012-01-01 19:58:41 <roconnor> sipa: inelegant, but significantly better than the current proposal.
582 2012-01-01 19:58:54 <sipa> yes, inelegant indeed
583 2012-01-01 19:59:23 <sipa> yours is probably the most elegant now, but i really do not like the extra 20 bytes
584 2012-01-01 20:06:18 <justmoon> sipa: seems like there should be some way to remove the extra 20 bytes?
585 2012-01-01 20:07:24 <sipa> if you know how, please say so :)
586 2012-01-01 20:07:36 <justmoon> sipa: CHALLENGE ACCEPTED
587 2012-01-01 20:08:30 <justmoon> it's there for what exactly? that weak verifiability we were talking about?
588 2012-01-01 20:09:19 <sipa> yes
589 2012-01-01 20:09:29 <justmoon> ...
590 2012-01-01 20:09:58 <justmoon> you guys realize that all that does is require you to know the pubkeys in order to generate transactions old clients will accept?
591 2012-01-01 20:10:21 <sipa> ?
592 2012-01-01 20:10:41 <justmoon> all the old clients verify is the hash of the code, right?
593 2012-01-01 20:10:47 <sipa> yes
594 2012-01-01 20:10:49 <justmoon> so if I know the code I can spend that transaction
595 2012-01-01 20:11:22 <justmoon> that's such weak security you may as well say you can spend any OP_EVAL transaction on old clients
596 2012-01-01 20:11:22 <sipa> at 0 confirmations, yes
597 2012-01-01 20:11:24 <sipa> *with
598 2012-01-01 20:12:19 <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
599 2012-01-01 20:13:31 <justmoon> I guess it's not quite that easy
600 2012-01-01 20:13:42 <roconnor> justmoon: I largely agree
601 2012-01-01 20:14:00 <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
602 2012-01-01 20:14:52 <roconnor> or at least drop the extra 20 bytes once the new scripting language is well accepted
603 2012-01-01 20:15:01 <roconnor> justmoon: there is another more complicated object
604 2012-01-01 20:15:02 <sipa> we meed gavin in this discussion :)
605 2012-01-01 20:15:14 <justmoon> it has to be well accepted before you start to do ANY OP_EVAL transactions
606 2012-01-01 20:15:55 <justmoon> weak verifiability may as well be no verifiability
607 2012-01-01 20:16:08 <justmoon> I can connect to 15000 nodes and just replace transactions as they come in
608 2012-01-01 20:16:11 <roconnor_> nested OP_EVAL lets you do this thing where you can send to one-of-many scripts
609 2012-01-01 20:16:58 <roconnor_> but OP_CODEHASH would need to be modified in some (complicated?) way to allow this
610 2012-01-01 20:17:12 <justmoon> roconnor_: are you talking about gavin's this or that example?
611 2012-01-01 20:18:33 <roconnor_> justmoon: yes
612 2012-01-01 20:19:09 <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
613 2012-01-01 20:19:25 <roconnor_> just to save space
614 2012-01-01 20:20:07 <roconnor_> (and since non-executed branches still count in the opcount, then saving space allows for "larger" transactions)
615 2012-01-01 20:20:12 <justmoon> save space in the txin at the expense of the txout o_O
616 2012-01-01 20:20:37 <roconnor_> justmoon: no no; the entire unused branch is never included other than its hash
617 2012-01-01 20:21:32 <justmoon> ok, gotcha
618 2012-01-01 20:21:41 <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.
619 2012-01-01 20:21:54 <justmoon> ByteCoin2: correct
620 2012-01-01 20:22:12 <justmoon> roconnor_: but it seems CODEHASH should support that too?
621 2012-01-01 20:22:59 <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
622 2012-01-01 20:23:11 <roconnor_> justmoon: the way i specified CODEHASH is that OP_CODESEPARATOR pushes the hash of everything to the end of the script
623 2012-01-01 20:23:49 <justmoon> roconnor_: how about everything since the last CODESEPARATOR or something like that?
624 2012-01-01 20:24:17 <roconnor_> justmoon: but the naive implemenation of this-and-that with CODEHASH requires that hash to appear in the script that gets hashed
625 2012-01-01 20:24:27 <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?
626 2012-01-01 20:24:42 <roconnor_> justmoon: knowing what the "last" CODESEPARATOR is tricky in the presence of OP_IF.
627 2012-01-01 20:24:50 <roconnor_> justmoon: it might be doable, but it gets very scary
628 2012-01-01 20:25:08 <justmoon> ByteCoin2: there is no attack perimeter - bitcoin scripts are sandboxed and operations counted
629 2012-01-01 20:25:30 <ByteCoin2> justmoon: Please!
630 2012-01-01 20:25:35 <justmoon> ByteCoin2: there is no reasons to put restrictions on anything, you can have loops, infinite recursion etc.
631 2012-01-01 20:25:51 <sipa> still, we have seen how easy implementation errors appear
632 2012-01-01 20:26:02 <sipa> and clear semanticsd are one way to reduce those
633 2012-01-01 20:27:43 <justmoon> sipa: that's an argument for CODEHASH in my opinion
634 2012-01-01 20:28:05 <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
635 2012-01-01 20:28:35 <justmoon> so you don't need any of those hacks that are in gavin's patch like passing in a counter of sigops etc.
636 2012-01-01 20:28:55 <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.
637 2012-01-01 20:29:24 <justmoon> roconnor_: I don't think you need a "codehash stack"
638 2012-01-01 20:29:50 <roconnor_> sure; I don't doubt that my proposal can be refined and improved.
639 2012-01-01 20:33:29 <justmoon> ByteCoin2: now that this line of thought is finished, let me properly address your comment, sorry for my flippant remarks before
640 2012-01-01 20:33:54 <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?
641 2012-01-01 20:34:11 <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
642 2012-01-01 20:34:30 <justmoon> ByteCoin2: so we talked about way on how to preserve static analysis
643 2012-01-01 20:34:42 <BlueMatt> ByteCoin2: why would anyone want to post on the forum?
644 2012-01-01 20:34:48 <ByteCoin2> justmoon: I'm not clear about what you mean by an asymmetric attack?
645 2012-01-01 20:34:56 <justmoon> ByteCoin2: then luke pointed out other asymmetric attacks with the same characteristics
646 2012-01-01 20:35:17 <ByteCoin2> justmoon: Where did luke do that?
647 2012-01-01 20:35:21 <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
648 2012-01-01 20:36:09 <roconnor> justmoon: you left out the part where you debunked gavin's dry-run idea
649 2012-01-01 20:36:10 <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
650 2012-01-01 20:36:14 <ByteCoin2> justmoon: People who don't share your feeling would have no reason to take your concerns seriously.
651 2012-01-01 20:36:22 <justmoon> ByteCoin2: correct
652 2012-01-01 20:36:31 <justmoon> ByteCoin2: that's why I've stopped arguing for it
653 2012-01-01 20:36:37 <ByteCoin2> Ok
654 2012-01-01 20:37:07 <justmoon> ByteCoin2: I just want to know what the best statically analyzable solution *would* look like
655 2012-01-01 20:37:23 <ByteCoin2> An interesting, if academic question.
656 2012-01-01 20:38:19 <ByteCoin2> roconnor: Point me to the bit where someone debunked gavin's idea
657 2012-01-01 20:38:20 <sipa> justmoon: quite sure that the best staticaly analyzable solution is not a stack-based language ;)
658 2012-01-01 20:38:51 <justmoon> sipa: I'm quite sure that static analyzability is a primary design goal of the language as-is
659 2012-01-01 20:38:59 <justmoon> sipa: note the absence of OP_LOOP OP_BREAK etc.
660 2012-01-01 20:39:29 <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.
661 2012-01-01 20:39:30 <luke-jr> let's totally add OP_LOOP
662 2012-01-01 20:39:40 <ByteCoin2> justmoon: I don't see evidence for that. I see a successful attempt to prevent looping
663 2012-01-01 20:39:52 <roconnor> Why not prove the OP_EVAL proposal is good; starting with a proof of termination.
664 2012-01-01 20:40:04 <ByteCoin2> roconnor: Beause we have finite engineering effort
665 2012-01-01 20:40:19 <justmoon> ByteCoin2: why prevent looping, that is nothing magically evil about looping - the only downside is it remove static analyzability
666 2012-01-01 20:40:22 <ByteCoin2> And even more finite(!) maths expertise!
667 2012-01-01 20:40:30 <justmoon> there* is nothing
668 2012-01-01 20:40:50 <roconnor> ByteCoin2: the more finite your resources, the longer you should take with protocol changes.
669 2012-01-01 20:41:00 <ByteCoin2> justmoon: You have preconceptions which I think are untrue and it's affecting your reasoning
670 2012-01-01 20:41:12 <justmoon> what preconceptions?
671 2012-01-01 20:41:22 <ByteCoin2> Looping constructs are perfectly analysable under certain circumstances
672 2012-01-01 20:41:32 <ByteCoin2> Indeed many common circumstances
673 2012-01-01 20:41:38 <justmoon> ok that's true
674 2012-01-01 20:41:44 <justmoon> but that's not what I mean
675 2012-01-01 20:42:06 <justmoon> right now the script is statically analyzable
676 2012-01-01 20:42:20 <justmoon> in fact, we use that static analysis in the function GetSigOpCount
677 2012-01-01 20:42:22 <ByteCoin2> I believe the reason to prevent looping was to remove the need for any "static analysis" or suchlike when reasoning about script execution
678 2012-01-01 20:42:53 <justmoon> ah, so you and I understand the term static analysis differently
679 2012-01-01 20:43:06 <justmoon> you call static analysis what gavin calls dry running
680 2012-01-01 20:43:10 <ByteCoin2> Wrong
681 2012-01-01 20:43:41 <justmoon> you said "remove the need for static analysis"
682 2012-01-01 20:43:47 <justmoon> right now the client DOES do static analysis
683 2012-01-01 20:44:05 <sipa> stronger: the network protovol relies on it
684 2012-01-01 20:44:22 <sipa> s/v/c
685 2012-01-01 20:44:25 <justmoon> gavin's patch REMOVES static analysis because it's no longer possible with OP_EVAL
686 2012-01-01 20:44:26 <ByteCoin2> justmoon: Do I have to check whether you're correct before we continue the conversation?
687 2012-01-01 20:44:53 <sipa> ByteCoin2: You're free to do, if you think that's necessary
688 2012-01-01 20:44:57 <justmoon> GetSigOpCount goes over the script and counts the number of OP_CHECKSIGs and OP_CHECKMULTISIGs
689 2012-01-01 20:45:02 <ByteCoin2> Put it this way - if I check and you are wrong will you concede the point?
690 2012-01-01 20:45:12 <justmoon> it counts the OP_CHECKMULTISIGs as 20 as an upper bound
691 2012-01-01 20:45:40 <justmoon> and then applies the sigops limits to that
692 2012-01-01 20:46:00 <justmoon> gavin's OP_EVAL patch changes that behavior, rather than counting sigops before running
693 2012-01-01 20:46:09 <justmoon> it just runs and if it runs into the limit it aborts
694 2012-01-01 20:46:15 <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"?
695 2012-01-01 20:46:31 <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
696 2012-01-01 20:47:02 <justmoon> but if you lose the *ability* to apply it without execution, I have an intuition that you lose something that *might* be useful
697 2012-01-01 20:47:18 <justmoon> if i can't think of a concrete example and handling this case would incur significant overhead
698 2012-01-01 20:47:21 <justmoon> I'll concede
699 2012-01-01 20:47:40 <justmoon> if I can think of an example of if a statically analyzable version is just as good, I won't
700 2012-01-01 20:48:18 <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.
701 2012-01-01 20:48:56 <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
702 2012-01-01 20:49:07 <justmoon> e.g. to sort transactions into categories or whatever
703 2012-01-01 20:49:21 <roconnor> static analysis is a tool at our disposal to stop attack vectors
704 2012-01-01 20:49:42 <justmoon> static analysis *may* be a tool at our disposal to stop attack vectors
705 2012-01-01 20:50:23 <ByteCoin2> I'd like you guys to compile your thoughts into something a little bit more accessible than IRC logs
706 2012-01-01 20:50:36 <ByteCoin2> And then make them available for review
707 2012-01-01 20:50:57 <justmoon> ByteCoin2: gavin had the brilliant idea of starting an off-list email discussion, most of this is in there ... -_-
708 2012-01-01 20:51:08 <justmoon> somebody should go, recompile and repost publicly
709 2012-01-01 20:52:54 <justmoon> why is everybody looking at me?
710 2012-01-01 20:53:01 <justmoon> :P
711 2012-01-01 20:53:27 <justmoon> sipa, roconnor: unless one of you wants to do it I'll summarize and post to the mailing list?
712 2012-01-01 20:53:42 <roconnor> justmoon: I wasn't part of the first part
713 2012-01-01 20:53:57 <roconnor> I'm probably too opinionated :)
714 2012-01-01 20:54:08 <justmoon> that's a good point, I wasn't part of the even earlier part
715 2012-01-01 20:54:13 <ByteCoin2> I think you're a bit excitable
716 2012-01-01 20:54:21 <sipa> justmoon: please do, if something's missing, i'll comment
717 2012-01-01 20:54:34 <justmoon> k
718 2012-01-01 20:54:41 <sipa> unless you prefer me to mail?
719 2012-01-01 20:54:53 <justmoon> ByteCoin2: let him who is not excitable throw the first stone
720 2012-01-01 20:55:07 <ByteCoin2> I thought I just did
721 2012-01-01 20:55:27 <ByteCoin2> ;)
722 2012-01-01 20:56:10 <ByteCoin2> afk for a bit
723 2012-01-01 20:56:26 <justmoon> sipa: maybe I'll just put up a piratepad and just let everybody look over it before I post it to the list
724 2012-01-01 20:56:27 <roconnor> "got 'im, dad!"
725 2012-01-01 21:08:51 <genjix> the problem with mailing list is all the white noise
726 2012-01-01 21:09:12 <genjix> i dont get the chance to follow all the back and forth discussion
727 2012-01-01 21:16:56 <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
728 2012-01-01 21:27:49 <roconnor> justmoon: fair point
729 2012-01-01 21:30:09 <luke-jr> the problem with this OP_EVAL fight is that it's holding up everything else
730 2012-01-01 21:35:12 <justmoon> luke-jr: what is it holding up?
731 2012-01-01 21:35:49 <genjix> rate of blockchain prayers
732 2012-01-01 21:36:01 <genjix> acceleration has slowed
733 2012-01-01 21:36:12 <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
734 2012-01-01 21:37:16 <copumpkin> justmoon: what are they?
735 2012-01-01 21:37:39 <copumpkin> it definitely gives a cool feature
736 2012-01-01 21:37:59 <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
737 2012-01-01 21:38:20 <justmoon> or at least the harder-to-prune txouts would grow faster
738 2012-01-01 21:38:29 <justmoon> or impossible-to-prune
739 2012-01-01 21:38:39 <justmoon> whatever, ask someone else, my head is elsewhere, sorry ;)
740 2012-01-01 21:40:12 <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...
741 2012-01-01 21:40:42 <sipa> ByteCoin2: i guess Gavin is currently concerned with rolling OP_EVAL out - this discussion is definitely making that take longer
742 2012-01-01 21:41:05 <ByteCoin2> sipa: Has Gavin indicated the timescale has changed?
743 2012-01-01 21:41:19 <sipa> i suppose he will delay it, yes
744 2012-01-01 21:41:29 <ByteCoin2> sipa:He said so?
745 2012-01-01 21:41:33 <luke-jr> ByteCoin2: coinbaser and signmessage_gui were approved for merging long before 0.5 merge window opened, but all merges have stopped now
746 2012-01-01 21:41:54 <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
747 2012-01-01 21:42:20 <justmoon> and he may have a point there
748 2012-01-01 21:42:31 <luke-jr> justmoon: oh, so when discussion stops, whatever is decided is in? :P
749 2012-01-01 21:42:42 <ByteCoin2> luke-jr: I imagine you meant for me to infer something from that... not sure what though
750 2012-01-01 21:42:47 <justmoon> luke-jr: something like that yeah...
751 2012-01-01 21:43:11 <luke-jr> ByteCoin2: I'm just annoyed at the delays for unrelated stuff :P
752 2012-01-01 21:43:28 <luke-jr> on the bright side, I guess it means I don't have to rebase it either
753 2012-01-01 21:43:55 <ByteCoin2> luke-jr: Is there any reason to believe that the two things are related - the delays and the current preoccupation?
754 2012-01-01 21:44:15 <luke-jr> you're saying it's a coincidence?
755 2012-01-01 21:44:52 <luke-jr> there's certainly a timing correlation
756 2012-01-01 21:44:59 <ByteCoin2> You implied there was a link. It didn't seem obvious to me
757 2012-01-01 21:45:18 <ByteCoin2> Lot's of things are temporally correlated
758 2012-01-01 21:45:37 <ByteCoin2> Simply because lots of things can happen at the same time
759 2012-01-01 21:47:52 <ByteCoin2> ;;seen gavinandresen
760 2012-01-01 21:47:53 <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)
761 2012-01-01 21:50:06 <ByteCoin2> justmoon: You still here?
762 2012-01-01 21:50:10 <genjix> developers are like gasoline
763 2012-01-01 21:50:10 <justmoon> yea
764 2012-01-01 21:50:14 <genjix> they can be used up
765 2012-01-01 21:50:25 <justmoon> genjix: truth.
766 2012-01-01 21:50:49 <luke-jr> maybe still Christmas too I guess
767 2012-01-01 21:50:58 <luke-jr> I think I'm actually waiting on jgarzik and wumpus anyway
768 2012-01-01 21:50:59 <ByteCoin2> My email address is bytecoin@gmx.com Could you email me the off list discussion so I can cut myself in?
769 2012-01-01 21:51:10 <genjix> ByteCoin2: and roconnor
770 2012-01-01 21:51:16 <genjix> roconnor: what is yours?
771 2012-01-01 21:51:27 <luke-jr> what discussion?
772 2012-01-01 21:51:33 <justmoon> genjix: I CC'd roconnor on the later emails, I only needs like two more or so
773 2012-01-01 21:51:38 <justmoon> he* only needs
774 2012-01-01 21:51:48 <genjix> luke-jr: about OP_EVAL
775 2012-01-01 21:52:07 <justmoon> and those two were pretty retarded comments from me that are best left in the dustbin of history
776 2012-01-01 21:52:20 <justmoon> I'm working on a summary of the discussion:
777 2012-01-01 21:52:21 <genjix> it kind of grew by adding more people in
778 2012-01-01 21:52:23 <justmoon> http://piratepad.net/E8AEAQJUw7
779 2012-01-01 21:52:37 <luke-jr> genjix: feel free to CC me too
780 2012-01-01 21:52:41 <luke-jr> no promises I'll read it tho
781 2012-01-01 21:52:59 <genjix> ok whats your email?
782 2012-01-01 21:53:06 <genjix> in fact i have a better idea
783 2012-01-01 21:54:14 <sipa> being?
784 2012-01-01 21:55:43 <sipa> i think quite some people can use an update that is less than 15 e-mails being sent to and fro
785 2012-01-01 21:56:40 <luke-jr> genjix: you know my email :p
786 2012-01-01 21:56:42 <justmoon> especially given that my summary contains a few improvements like a stronger attack on the dry runner
787 2012-01-01 21:58:57 <genjix> luke-jr: i dont keep emails around, just tell me
788 2012-01-01 21:59:14 <justmoon> genjix: luke@dashjr.org
789 2012-01-01 21:59:19 <genjix> ok thanks
790 2012-01-01 22:02:16 <luke-jr> genjix: luke-jr@bitcoinconsultancy.com
791 2012-01-01 22:02:22 <luke-jr> * if you make the alias :p
792 2012-01-01 22:02:50 <genjix> ok
793 2012-01-01 22:02:57 <genjix> sent the email
794 2012-01-01 22:04:48 <sipa> genjix: tuesday midnight is fine by me
795 2012-01-01 22:05:54 <midnightmagic> is it possible to send bitcoin by IP using the command-line
796 2012-01-01 22:06:10 <genjix> no
797 2012-01-01 22:06:50 <genjix> sipa: would just be productive to make it a regular thing :) so the hand knows the foot
798 2012-01-01 22:07:06 <midnightmagic> hrm..  and it requires -allowreceivebyip to be active.
799 2012-01-01 22:07:43 <midnightmagic> there's a function of the GUI not represented in the client then?
800 2012-01-01 22:08:44 <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
801 2012-01-01 22:09:01 <roconnor> at the very least it was a joint effort
802 2012-01-01 22:10:54 <roconnor> justmoon: I thought luke-jr had some sort of DoS attack that is similar but not the same as excessive OP_CHECKSIG
803 2012-01-01 22:12:12 <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
804 2012-01-01 22:12:30 <justmoon> roconnor: and if there is already an attack like that, it doesn't really matter if there are more attacks like that
805 2012-01-01 22:12:51 <justmoon> verifier*
806 2012-01-01 22:13:10 <roconnor> I see
807 2012-01-01 22:13:24 <justmoon> right now I'm on the fence myself
808 2012-01-01 22:14:12 <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
809 2012-01-01 22:16:13 <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.
810 2012-01-01 22:17:09 <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
811 2012-01-01 22:21:51 <justmoon> sipa: agreed, but there is one thing I want to add:
812 2012-01-01 22:22:34 <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
813 2012-01-01 22:23:37 <sipa> i agree it should have very low priority
814 2012-01-01 22:24:35 <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
815 2012-01-01 22:24:59 <justmoon> unless we can show static analysis to be useful in some scenario, i think the decision will fall on the existing impl
816 2012-01-01 22:26:07 <sipa> roconnor: by the way, what do you think of ByteCoin's proposal, as mailed by Gavin?
817 2012-01-01 22:26:34 <sipa> with OP_EVAL being replaced, rather than causing a sub-evaluation
818 2012-01-01 22:27:01 <sipa> it sounds very easily well-specified, and it permits analysis after execution of scriptSig
819 2012-01-01 22:27:08 <roconnor> on the surface it seems like a good idea
820 2012-01-01 22:27:17 <roconnor> I haven't though much about it though
821 2012-01-01 22:27:59 <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
822 2012-01-01 22:28:32 <sipa> yes, i don't understand how it allows observing the replacing script's hash
823 2012-01-01 22:28:47 <sipa> ByteCoin2: maybe you can explain that?
824 2012-01-01 22:30:31 <ByteCoin2> Ok. I'm here for a few more mins... explain what exactly?
825 2012-01-01 22:31:10 <sipa> ByteCoin2: gavin mailed about the original intent you had with OP_EVAL
826 2012-01-01 22:31:14 <sipa> with regard to semantics
827 2012-01-01 22:31:53 <sipa> it would mean: execute scriptSig, replace OP_EVAL's in scriptPubKey with deserialized scripts from the stack resulting from scriptSig, run processed scriptPubKey
828 2012-01-01 22:31:55 <ByteCoin2> sipa: For my original intent, I think it's best explained by my original post which gavin extracted into the OP_EVAL thread
829 2012-01-01 22:32:07 <sipa> ok, link?
830 2012-01-01 22:32:44 <sipa> i believe i read it, but found it rather complex
831 2012-01-01 22:33:18 <sipa> found it
832 2012-01-01 22:35:29 <sipa> hmm, it's not what i believe Gavin described
833 2012-01-01 22:36:46 <ByteCoin2> Interesting...
834 2012-01-01 22:37:03 <ByteCoin2> sipa: Please point me to what Gavin described I meant
835 2012-01-01 22:37:36 <sipa> ByteCoin2: i misread
836 2012-01-01 22:38:54 <ByteCoin2> I'd probably find it helpful if you helped me understand how the scheme seems if you misread it
837 2012-01-01 22:39:35 <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
838 2012-01-01 22:39:57 <sipa> i misread it as that this was your original intent - it is not, it's just a proposal made by him
839 2012-01-01 22:40:00 <justmoon> ByteCoin2: here's the exact text gavin used: http://piratepad.net/al7rhEBbeH
840 2012-01-01 22:40:58 <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
841 2012-01-01 22:41:32 <justmoon> or if anyone else can answer that question, that would help me too
842 2012-01-01 22:41:45 <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
843 2012-01-01 22:42:08 <sipa> instead of running a subevaluation
844 2012-01-01 22:42:18 <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
845 2012-01-01 22:42:20 <justmoon> ok, i see
846 2012-01-01 22:42:36 <sipa> ByteCoin2: i believe it's very close
847 2012-01-01 22:42:46 <sipa> but the way it is implemented makes it quite hard to judge whether it is
848 2012-01-01 22:43:41 <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
849 2012-01-01 22:43:43 <sipa> (the implementation spawns a new execution with a state that is shared by the original)
850 2012-01-01 22:44:34 <justmoon> why restrict the nesting level?
851 2012-01-01 22:45:13 <sipa> I suppose because of an "no idea what could happen if we allow infinite recursion, but better be safe" thought
852 2012-01-01 22:45:20 <kiba> hi
853 2012-01-01 22:45:26 <kiba> sipa: you heard of my game?