01:33:27Ketamine_:Just getting into the game, anything greatly appreciated. Pweeese.
01:33:27Ketamine_:Cryptsy: 912e35c2dc1316cd9eea19e31768ff27f20fddef
01:33:28Ketamine_:BTC: 1MHPQCbkJ6uyD2kpZveNpXdjG396duaYVw
01:33:28Ketamine_:LTC: LNtbFxtr1gEpPnvubT314HNSX2zAFpa37X
01:33:28Ketamine_:DOGE: DJ1NXr9WLv2Wqda4mCTW5K71NRaUrNVdDX
01:33:28Ketamine_:PP: o24@usa.com
01:33:30Ketamine_:Ketamine_ has left #bitcoin-wizards
01:38:52justanotheruser2:justanotheruser2 is now known as justanotheruser
02:18:53jps_:jps_ is now known as jps
09:20:35jtimon:yo
09:21:02jtimon:yolandi
09:21:13jtimon:ninja
13:35:12azariah4:stumbled over the ethereum white-paper, interesting stuff
13:35:54c0rw1n:it was elusive about some technical details last time i checked
13:36:22azariah4:what do you think about its turing-complete "scripts" ?
13:36:50c0rw1n:that's the thing. there's a very good reason bitcoin script isn't turing-complete
13:36:58qwertyoruiop:c0rw1n++
13:37:06c0rw1n:and the ethereum paper didn't say how they solved it
13:37:26c0rw1n:(last time i checked)
13:38:58brisque:there's something about the transaction fee being charged for the number of operations a script takes.
13:39:06Ursium: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
13:39:09man31:man31 has left #bitcoin-wizards
13:39:25c0rw1n:i think if you could get fees on the computing of turing-complete scripts, you could mine on that
13:39:39Ursium:operations are expensive, and the instruction set very limited
13:39:57brisque:logically every single node has to execute the scripts, so they can't be particularly complicated.
13:40:08c0rw1n:um not necessarily
13:40:12c0rw1n:you could zkp the running of scripts
13:40:37azariah4:talk about a new type of incentive for optimization, hehe, not for cycles or mem but for fees on a blockchain
13:41:32brisque:bitcoin already restricts it's scripts just by virtue of their size. bigger transaction leads to more fees.
13:42:03brisque: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?
13:44:29c0rw1n:the output yes
13:46:35brisque:how would you get there without executing it?
13:48:16sipa:give a zkp of the evaluation
13:48:17azariah4:seems ethereum scripts will require a fee for every 16 instructions
13:48:28c0rw1n:which is a way to go about that
13:48:36Ursium:azariah4: a fee per step AFTER 16 more like ;)
13:49:17azariah4:Ursium: oh right!
13:50:20adam3us1:there is a thread about turing complete on bct https://bitcointalk.org/index.php?topic=431513.0
13:50:41azariah4:ah, seems the fee structure is more complicated
13:51:11azariah4:1x fee for each instruction after the first 16, but crypto operations cost 20x fee each
13:51:17adam3us1:anyone have gmaxwell grey goo bct url? (bad implications of covenants)
13:51:23azariah4:and different logic for storage
13:51:47sipa:how do they enforce fees? at the consensus level, or local policy?
13:51:55azariah4:adam3us1: thanks for the link
13:52:33adam3us1: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)
13:53:17adam3us1:sipa: i think fees are enforced by all validators executing them, but only financially benefit successful miners
13:54:06sipa:adam3us1: how is the exchange rate set?
13:54:07adam3us1:note its balance based and a script "owns" and defends value, and can originate transactions from its logic and balance with no input transaction
13:54:59adam3us1: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 :)
13:55:11sipa:i know that
13:55:13azariah4:sipa: "The coefficients will be revised as more hard data on the relative computational cost of each operation becomes available."
13:55:32azariah4:they mention two ideas in the current version of the paper
13:55:38sipa:but i'm asking at what level the fee structure is enforced
13:55:42adam3us1:sipa: exchange u mean ^^ variable cost of exec
13:56:00sipa:bitcoin only does it as a policy, as you cannot fix the cost of fees in the consensus rules
13:56:28adam3us1: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
13:56:44sipa:miners have the same validation as other nodes
13:56:45adam3us1:sipa: oooh. now i get yu.
13:57:22adam3us1:sipa: i was thinking that they just set an arbitrary baked per cycle fee, but that doesnt work in a floating value coin
13:57:23sipa:and the only way paying for validation can work economically, is when validation work is limited per block as a consensus rule
13:57:54sipa:as miners have in incentive to fill up whatever is allowed in a block (they are paid, the rest isn't)
13:58:09azariah4:adam3us1: they mention setting it partly based on difficulty, which is one measure of the value of the coin
13:58:12adam3us1: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
14:02:05adam3us1: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.
14:02:30adam3us1: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"
14:02:50sipa:adam3us1: that is why full nodes need to demand a network rule that limits it
14:03:13sipa:otherwise they are voting themself out of the electorate
14:10:20adam3us1: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
14:11:22sipa:adam3us1: define 'voted'; who votes?
14:11:26adam3us1:sipa: maybe they put a human chosen cap at some comfortable level for avg desktop/ultrabook hw
14:11:54adam3us1: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)
14:12:17sipa:no, not miners!
14:12:28sipa:miners are the ones who have the incentive to raise the limits
14:12:45sipa:it's the rest of the nodes that need the limit exactly to keep miners in check
14:13:21adam3us1: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
14:13:49sipa:to exclude other miners, or just to maximize their own fee income
14:14:30sipa:it's non-mining nodes that need to demand rules which prevent that
14:14:31adam3us1:sipa: by being the only cloud miner with fast cpu to even execute and collect fees
14:15:02adam3us1:sipa: so eg then non-miners have a default sanity limit somthing simple for a 1ghz machine to keep up with
14:15:25sipa:well, that is what bitcoin has: a 1 MB limit on blocks, and a 20k sigop limit in it
14:15:49sipa:which means you have a guaranteed way of being able to keep up
14:15:52adam3us1:sipa: yes i was think its analogous to limit. but n this case if its over
14:16:07adam3us1:sipa: then some nodes woud reject it as too many cycles by policy?
14:16:22sipa:not policy, this needs to be a consensus rule
14:16:43adam3us1:sipa: but how do u reach consensus without hash power...
14:16:48sipa:by fixing it
14:16:56sipa:in the rules, at the start of the system
14:17:33adam3us1:sipa: ok yes then so like some max ins / block target interval that a 1ghz machine can easily keep up with
14:17:36sipa:and do a hard fork if there is wide consensus (among humans using the system) that it can be changed
14:17:56sipa:i don't believe it is a problem you can solve technically inside the consensus system
14:17:59azariah4:one issue is that how efficient hardware can compute the ethereum "script" language may not relate to how efficient it can hash the blocks
14:18:47azariah4: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
14:18:52adam3us1:sipa: yes. another issue fairness between competing scripts. these contracts are like programs that run whenever an instrument of a given type are transacted.
14:19:53adam3us1:the contract program has persistent state and can react to user transactions invoking it and originate transactions fro the script code
14:20:47adam3us1:drawing on script managed funds, or user supplied inputs.
14:25:57azariah4:the potential for grey goo is very interesting
14:27:57adam3us1: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
14:28:17adam3us1:azariah4: (in existing bitcoin script)
14:30:23adam3us1:azariah4: i think extrospection or covenants are potentially dangerous because they could spread virally through the coins.
14:31:45azariah4:adam3us1: hmm, did you see the op (59) EXTRO in the current version of the paper?
14:32:36adam3us1:azariah4: ethereum paper? no. i did describe the extrospection viral goo risk to vitalik tho :)
14:33:51azariah4:ah yes, now I reached your post in the thread talking about it :)
14:33:54adam3us1:azariah4: maaku_ was discussing it for freimarket too and he figured he could somewhat contain it by disabling extrospect on basic coins (non contract)
14:35:37azariah4: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
14:36:08azariah4: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
14:36:56adam3us1: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
14:37:42adam3us1:azariah4: yes. i think they have sparse storage tho. maybe the address space was like 2^128 or something vast if i recall
14:39:30azariah4:yepp [0 ... 2^256-1] for both temp and persistent storage
14:40:13azariah4:hopefully they can post some updates about these risks before their fundraiser starts in a week
15:11:43Ursium: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?
15:14:32azariah4:I could, but I need to read more about it first to properly understand it :>
15:35:21tt_away_:tt_away_ is now known as tacotime_
15:57:44adam3us1:azariah4: didnt they already write about security risk soewhere? vitalik wrote an article on bitcoinmagazine recently also (didnt read it all yet)
18:21:55TD2:TD2 has left #bitcoin-wizards
18:26:35maaku_:azariah4: the scripting language would have to be perfectly sandboxed, yes
18:26:57TD2:TD2 is now known as TD
18:27:31maaku_: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
18:28:01maaku_:these can be made safe. it could even be proven safe, if you have the resources to do so
18:29:14maaku_:well, i'm talking about my language here, not etherium's
18:29:57TD:maaku_: there were exploits in bitcoin script even though that's tiny. so ..... this stuff is hard :)
18:30:28maaku_:TD: bitcoin's scripting language is more complex than a minimal turning complete language
18:30:38maaku_:and was not given appropriate care and attention
18:37:55maaku_:what i'm saying is there's nothing magical about writing a scripting interpreter that makes it dangerous in itself
18:38:29maaku_:compared to say, the network stack, which is quite a bit larger and also has to be free of remote exploits
19:23:26gmaxwell: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.
19:24:31gmaxwell: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.
19:27:37TD:the world has a poor track record when it comes to sandboxing malicious code