--- Log opened Sun Jan 26 00:00:59 2014
04:20 < jtimon> yo
04:21 < jtimon> yolandi
04:21 < jtimon> ninja
08:35 < azariah4> stumbled over the ethereum white-paper, interesting stuff
08:35 < c0rw1n> it was elusive about some technical details last time i checked
08:36 < azariah4> what do you think about its turing-complete "scripts" ?
08:36 < c0rw1n> that's the thing. there's a very good reason bitcoin script isn't turing-complete
08:36 < qwertyoruiop> c0rw1n++
08:37 < c0rw1n> and the ethereum paper didn't say how they solved it
08:37 < c0rw1n> (last time i checked)
08:38 < brisque> there's something about the transaction fee being charged for the number of operations a script takes.
08:39 < Ursium> my understanding (and I'm going to walk on eggshells here) is that they solved it by limiting the opscode to the strick miminum, meaning it won't be possible to build anything that could lead to disaster
08:39 < c0rw1n> i think if you could get fees on the computing of turing-complete scripts, you could mine on that
08:39 < Ursium> operations are expensive, and the instruction set very limited
08:39 < brisque> logically every single node has to execute the scripts, so they can't be particularly complicated.
08:40 < c0rw1n> um not necessarily
08:40 < c0rw1n> you could zkp the running of scripts
08:40 < azariah4> talk about a new type of incentive for optimization, hehe, not for cycles or mem but for fees on a blockchain
08:41 < brisque> bitcoin already restricts it's scripts just by virtue of their size. bigger transaction leads to more fees.
08:42 < brisque> c0rw1n: maybe I've missed something, but wouldn't nodes need to know the output of a transaction to conclude if a block is valid or invalid?
08:44 < c0rw1n> the output yes
08:46 < brisque> how would you get there without executing it?
08:48 < sipa> give a zkp of the evaluation
08:48 < azariah4> seems ethereum scripts will require a fee for every 16 instructions
08:48 < c0rw1n> which is a way to go about that
08:48 < Ursium> azariah4: a fee per step AFTER 16 more like ;)
08:49 < azariah4> Ursium: oh right!
08:50 < adam3us1> there is a thread about turing complete on bct https://bitcointalk.org/index.php?topic=431513.0
08:50 < azariah4> ah, seems the fee structure is more complicated
08:51 < azariah4> 1x fee for each instruction after the first 16, but crypto operations cost 20x fee each
08:51 < adam3us1> anyone have gmaxwell grey goo bct url?  (bad implications of covenants)
08:51 < azariah4> and different logic for storage
08:51 < sipa> how do they enforce fees? at the consensus level, or local policy?
08:51 < azariah4> adam3us1: thanks for the link
08:52 < adam3us1> ah got it https://bitcointalk.org/index.php?topic=278122.0 gmaxwell on how you get grey goo from even the simplest one opcode mistake on current bitcoin (never mind TC byte code stateful, looping, full generic)
08:53 < adam3us1> sipa: i think fees are enforced by all validators executing them, but only financially benefit successful miners
08:54 < sipa> adam3us1: how is the exchange rate set?
08:54 < adam3us1> note its balance based and a script "owns" and defends value, and can originate transactions from its logic and balance with no input transaction
08:54 < adam3us1> sipa: its an alt with it own mining race :) vitaliks own personal one.  i asked him in person if he's gone to the dark side, and he smiled and chuckled as an answer :)
08:55 < sipa> i know that
08:55 < azariah4> sipa: "The coefficients will be revised as more hard data on the relative computational cost of each operation becomes available."
08:55 < azariah4> they mention two ideas in the current version of the paper
08:55 < sipa> but i'm asking at what level the fee structure is enforced
08:55 < adam3us1> sipa: exchange u mean ^^ variable cost of exec
08:56 < sipa> bitcoin only does it as a policy, as you cannot fix the cost of fees in the consensus rules
08:56 < adam3us1> sipa: i thnk the enforcement stems from miners.  the miners define thecorrect interpretation and execution of the script.  and their execution is defined in part by the interpreter cycles from the fees
08:56 < sipa> miners have the same validation as other nodes
08:56 < adam3us1> sipa: oooh.  now i get yu.
08:57 < adam3us1> sipa: i was thinking that they just set an arbitrary baked per cycle fee, but that doesnt work in a floating value coin
08:57 < sipa> and the only way paying for validation can work economically, is when validation work is limited per block as a consensus rule
08:57 < sipa> as miners have in incentive to fill up whatever is allowed in a block (they are paid, the rest isn't)
08:58 < azariah4> adam3us1: they mention setting it partly based on difficulty, which is one measure of the value of the coin
08:58 < adam3us1> sipa: gmaxwell was pointing out that if there is even one instruction diff in interpretation it could lead to a hard fork so haing that fee be dynamic / loose could be undesirable
09:02 < adam3us1> sipa: i was also wondering like what if the cycles (for all contracts in block) go above the CPU resources of some nodes, so they cant keep up with validation.
09:02 < adam3us1> sipa: maybe thats what you were saying "only way paying for validation can work economically, is when validation work is limited per block as a consensus rule"
09:02 < sipa> adam3us1: that is why full nodes need to demand a network rule that limits it
09:03 < sipa> otherwise they are voting themself out of the electorate
09:10 < adam3us1> sipa: so if the maximum cycles are voted on via some rolling avg by consensus, that cant be an integer or someone will put maxint in there? so then what a proof cpu resources in the interval?  then maybe someone uses a compute farm to jack up the max cycles.  so then a non-parallelizable Pow?  then someone uses dozens of liquid cooled 5ghz boxes (or nitrogen 6ghz).  there is a financial motive to exclude
09:11 < sipa> adam3us1: define 'voted'; who votes?
09:11 < adam3us1> sipa: maybe they put a human chosen cap at some comfortable level for avg desktop/ultrabook hw
09:11 < adam3us1> sipa: miners, by putting their pref for max cycles as a field in coinbase?  (i am trying to understand how this policy and rate could be set)
09:12 < sipa> no, not miners!
09:12 < sipa> miners are the ones who have the incentive to raise the limits
09:12 < sipa> it's the rest of the nodes that need the limit exactly to keep miners in check
09:13 < adam3us1> sipa: to exclude other miner yes.  but there is no non sybil voting without pow itself, and miners concentrate and buil asic for any and all pow  long term
09:13 < sipa> to exclude other miners, or just to maximize their own fee income
09:14 < sipa> it's non-mining nodes that need to demand rules which prevent that
09:14 < adam3us1> sipa: by being the only cloud miner with fast cpu to even execute and collect fees
09:15 < adam3us1> sipa: so eg then non-miners have a default sanity limit somthing simple for a 1ghz machine to keep up with
09:15 < sipa> well, that is what bitcoin has: a 1 MB limit on blocks, and a 20k sigop limit in it
09:15 < sipa> which means you have a guaranteed way of being able to keep up
09:15 < adam3us1> sipa: yes i was think its analogous to limit.  but n this case if its over
09:16 < adam3us1> sipa: then some nodes woud reject it as too many cycles by policy?
09:16 < sipa> not policy, this needs to be a consensus rule
09:16 < adam3us1> sipa: but how do u reach consensus without hash power...
09:16 < sipa> by fixing it
09:16 < sipa> in the rules, at the start of the system
09:17 < adam3us1> sipa: ok yes then so like some max ins / block target interval that a 1ghz machine can easily keep up with
09:17 < sipa> and do a hard fork if there is wide consensus (among humans using the system) that it can be changed
09:17 < sipa> i don't believe it is a problem you can solve technically inside the consensus system
09:17 < azariah4> one issue is that how efficient hardware can compute the ethereum "script" language may not relate to how efficient it can hash the blocks
09:18 < azariah4> so it might not be possible to have a consensus rule which is based on making the fee multiple inversely proportional to square root of hashing difficulty, as they mention
09:18 < adam3us1> sipa: yes.  another issue fairness between competing scripts. these contracts are like programs that run whenever an instrument of a given type are transacted.
09:19 < adam3us1> the contract program has persistent state and can react to user transactions invoking it and originate transactions fro the script code
09:20 < adam3us1> drawing on script managed funds, or user supplied inputs.
09:25 < azariah4> the potential for grey goo is very interesting
09:27 < adam3us1> azariah4: i am (pure speculation) assuming its why there is no extrospection (ie ability for the script to lexically examine the script of the output address to enforce terms on it)  i think gmaxwell called that a covenant in the link above
09:28 < adam3us1> azariah4: (in existing bitcoin script)
09:30 < adam3us1> azariah4: i think extrospection or covenants are potentially dangerous because they could spread virally through the coins.
09:31 < azariah4> adam3us1: hmm, did you see the op (59) EXTRO in the current version of the paper?
09:32 < adam3us1> azariah4: ethereum paper? no.  i did describe the extrospection viral goo risk to vitalik tho :)
09:33 < azariah4> ah yes, now I reached your post in the thread talking about it :)
09:33 < adam3us1> azariah4: maaku_ was discussing it for freimarket too and he figured he could somewhat contain it by disabling extrospect on basic coins (non contract)
09:35 < azariah4> well, even if one could prove the language itself has no extrospection, the fact that it has a form of persistent storage could be a issue in practice
09:36 < azariah4> e.g. one specific impl of a ethereum node has overflow/bounds bug in its impl, enabling a script to read outside its defined persistent storage
09:36 < adam3us1> azariah4: it seems interesting to me however to look at contracts you can build by composing dependent and hash-locked non-extrospection bitcoin scripts or other composing methods.  while it seems at first laborious to not be able to express these in a single contract, so long as its functionally equivalent an all the intereting useful things can be built, without adding extrospection i think that can be enuf, and suspect it might be a des
09:37 < adam3us1> azariah4: yes.  i think they have sparse storage tho.  maybe the address space was like 2^128 or something vast if i recall
09:39 < azariah4> yepp [0 ... 2^256-1] for both temp and persistent storage
09:40 < azariah4> hopefully they can post some updates about these risks before their fundraiser starts in a week
10:11 < Ursium> azariah4: i'm not sure there's anyone from the core dev team on this channel (i could be wrong) - is that something you could raise on forum.ethereum.org?
10:14 < azariah4> I could, but I need to read more about it first to properly understand it :>
10:57 < adam3us1> azariah4: didnt they already write about security risk soewhere?  vitalik wrote an article on bitcoinmagazine recently also (didnt read it all yet)
13:26 < maaku_> azariah4: the scripting language would have to be perfectly sandboxed, yes
13:27 < maaku_> but we are talking about a language that could be as small as a dozen or so opcodes, 2-3 types, and an implementation measured in the hundreds of lines of C++ code
13:28 < maaku_> these can be made safe. it could even be proven safe, if you have the resources to do so
13:29 < maaku_> well, i'm talking about my language here, not etherium's
13:29 < TD> maaku_: there were exploits in bitcoin script even though that's tiny. so ..... this stuff is hard :)
13:30 < maaku_> TD: bitcoin's scripting language is more complex than a minimal turning complete language
13:30 < maaku_> and was not given appropriate care and attention
13:37 < maaku_> what i'm saying is there's nothing magical about writing a scripting interpreter that makes it dangerous in itself
13:38 < maaku_> compared to say, the network stack, which is quite a bit larger and also has to be free of remote exploits
14:23 < gmaxwell> maaku_: sure there is, the script interperter is procol normative in a way the net code isn't. It doesn't just have to be free of "remote exploits" it has to be free of consistency failures. So that adds a number of additional constraints and makes it fixing it hard.
14:24 < gmaxwell> maaku_: and of course all that "just a couple hundred lines of code" stuff fails if you then need to make it fast and implementers find that they're pratically required to employ a JIT compiler for it.
14:27 < TD> the world has a poor track record when it comes to sandboxing malicious code
--- Log closed Mon Jan 27 00:00:02 2014