Turing complete language vs non-Turing complete (Ethereum vs Bitcoin)

[lebing]

The concept of a Turning complete scripting language has come up as essentially the defining feature of this new coin, ethereum. If we assume Satoshi purposefully left out this feature set (as the developers of ethereum maintain), was that intentional because having this functionality is in itself to risky to the infrastructure? What does the community think regarding this distinction & what does the risk/ benefit look like?

[1715435861]

1715435861

[theymos]

Satoshi probably left it out because making a Turing-complete transaction scripting language safe is more difficult. You have to prevent scripts from running endlessly while also allowing them to run long enough to be useful, and you can't let them access too much external data or they might become invalid after being valid for a while and really screw things up. A Turing-complete transaction scripting language would be really cool, though. If done well, it could be used to add all sorts of new features (even new crypto) in a backward-compatible way.

I don't know much at all about Ethereum, but it looks like their scripts can access info about blocks, which seems dangerous. If this was possible in Bitcoin, then a reorg could cause many fully-confirmed transactions to all of a sudden become invalid by accident, without even any attacker. This is very undesirable. Maybe Ethereum does something to fix this -- I don't know.

[bitfreak!]

Satoshi only included support for a limited range of transaction types for security reasons but I'm sure he had many ideas about how the scripting system could be used to create a wide range of interesting scripts to serve different purposes. A full turing-complete scripting system seems like a pretty dangerous idea to me but the people working on Ethereum seem to be fairly bright fellows so I'll be interested to see how they tackle this problem. On a some what related note, my mini-blockchain system aims to achieve almost the opposite of what Ethereum is aiming for:

Script is not used within the mini-blockchain scheme. Since the account tree holds the final balance of all non-empty addresses and is not a continuous ledger of transactions like Bitcoin it's not possible to use scripts which must be solved at a later time because transactions in the mini-blockchain are discarded after a relatively small period of time (the length of the mini-blockchain cycle time). However, this is not really as much of a disadvantage as it may seem.

It is still possible to allow more complex types of transactions by defining special account types which support things such as a multi-signature transactions. By not utilizing script we get the advantage of making many aspects of the system exceptionally simpler and at the same we get an increased level of security because every type of possible transaction will be very well defined, eliminating the risk of an unforeseen script causing havoc on the network.

http://bitfreak.info/mbc-wiki/index.php?title=Transaction_Signing

[coinrevo]

yes, there are many reasons this does not exist in bitcoin.

say you want to run arbitrary source code on a p2p node to make possible "smart contracts". how do you know the source is not going to root your operating system? to understand that you have to know how easy and quick introducing backdoors is, in terms of computational complexity. in most cases you have program flow, create some kind of jump, and emulate further normal program flow. usually you have to be quite clever, as Operating System/application developers battle hackers all the time and there is a long list of vulnerabilities. it takes only one bug to introduce a hole. vulnerabilities can be a combination of software and configurations.

writing source code which can predict if source code does what is supposed to do is largely impossible (virus scanners are basically just a list of known vulnerabilities). for smart contracts you need inputs from the outside world, otherwise they are useless. you want inputs like prices, or even a verified date (bitcoin is a timestamp server). if you get data from the outside world that means you can inject any data into nodes you want, and the runner of node has no means to verify whether he is currently executing code which steal his money. remember, in John-Von-Neumann programmable machines code and data exist in the same address space.

as for ethereum. there are some good ideas, but raising millions of dollars very heavily skews the conflict of interest. and I say this in the most friendly way I can. so take all of their claims with a very heavy grain of salt. if you go through the paper you will not find an example of what smart contracts or DAO in this context should even mean. its sad as there is some quite interesting elements. most of it is just nonsense though, if you really think about this should work. most contracts only make sense in terms of possible legal recourse. which is why bitcoin is perfect for uni-directional payments, but useless for everything else.

[MatthewLM]

These contracts from what I tell are verified like the bitcoin scripting language, only with a new language with commands that provide block-chain data, commands that stores information that can be referenced in later contracts and jump commands. They didn't explain how they would limit the execution of contracts. I suppose they will have a limit on the number of steps each contract execution can make.

More interesting than this would be the use of the SNARK programs to replace the scripting system, as previously mentioned elsewhere. That way completely arbitrary programs can be used in transactions.

[maaku]

Replacing the scripting system with SNARK proofs has non-serious problems that remain unsolved. Verifying keys for SNARKs are huge, so it is completely impracticable to compute arbitrary new proof circuits for each output. The most likely alternative is that you compute shared proving and verifying keys for a Turing-complete virtual machine, like tinyram. The problem now is the nature of how the key is generated: a security parameter is chosen which is a sort of master skeleton key - if kept, it could be used to spend anyone's output undetectably. That's no laughing matter. Every known SNARK system with practical requirements has this limitation. In theory you could do some sort of large multi-party compute to create the key in a way where only one participant needs to be honest to ensure destruction of the trapdoor. However besides the practical difficulties of doing this (orders of magnitude greater size problem than anything that's been handled so far), there's the the fact that it only shifts the problem. Practical MPC systems work on the same principle - whoever created the MPC parameters could backdoor that calculation and derive the SNARK security parameter. Try to solve that and its turtles all the way down...

If that weren't bad enough, there's also the issue that while validating a SNARK proof is cheap, creating it is *very* expensive. These sorts of things are typically done on small HPC clusters. It's pretty ludicrous to think of doing it on a smartphone.

Now making a more expressive scripting language is very much possible, but requires being very careful. I'm working on some proposed bitcoin extensions for this.. if anyone is interested in helping out, feel free to PM me.

[behindtext]

Satoshi probably left it out because making a Turing-complete transaction scripting language safe is more difficult. You have to prevent scripts from running endlessly while also allowing them to run long enough to be useful, and you can't let them access too much external data or they might become invalid after being valid for a while and really screw things up. A Turing-complete transaction scripting language would be really cool, though. If done well, it could be used to add all sorts of new features (even new crypto) in a backward-compatible way.

I don't know much at all about Ethereum, but it looks like their scripts can access info about blocks, which seems dangerous. If this was possible in Bitcoin, then a reorg could cause many fully-confirmed transactions to all of a sudden become invalid by accident, without even any attacker. This is very undesirable. Maybe Ethereum does something to fix this -- I don't know.

i definitely agree that the reason this kind of functionality was not added to bitcoin was that it makes shooting oneself in the foot far easier. a related question that could be asked is "why are many of the script opcodes disabled in bitcoind?" and it has the same answer - the functionality that comes with more scripts and more opcodes is risky and creates many more corner cases to code around.

it's obviously possible to do amazing things with more powerful scripting options but i suspect it would not be sufficiently stable and secure as currently proposed in ethereum. bitcoin's success is strongly related to the fact that it is a digital currency system with a few key innovations that added a ton of value, the main innovation being the distributed public ledger. ethereum proposes sweeping changes that are not minor variations and have unknown dynamics in a real-world use case. i do quite like the ideas proposed in the ethereum proposal.

[oakpacific]

I could say I have seen altcoiners trying to change nearly every aspect of Bitcoin, just for the heck of it.

It would have been easy for Satoshi to implement a Turing-complete scripting, he refrains from doing it because Bitcoin is an infrastructure, a security max system, if someone succeeds with remote-exploiting a miner then there is theoretically no limit to the amount of money they can double-spend. Otoh, miners would probably have zero interest in handling complex transactions for you so they will reject most of the opcodes, but it only took one successful exploitation to do irreparrable damage to the network.

[adam3us]

From another thread:

Thanks d'aniel.  My initial feeling is that Turing-completeness is not necessary for bitcoin and would very likely lead to unforeseen problems and instability (mostly related to the halting problem).  Money isn't a computer.

They address halting by fee paying for interpreter cycles.  When the fee runs out the contract is stopped.

But there are obviously interpreter escape dangers, which are harder to contain for a stateful, looping, low level (byte code like) language.  Look at the history of java sandbox escapes.  People say that was mostly due to call outs to complex native library have to look through the (large!) CVE database on JVM to figure out the stats.  Also the pressure may have been lower.  If you get real money under it all kinds of resources and unrevealed 0-days can leak out of the woodwork and create the new target for grey and black hats some of whom are world class at this stuff.  Or even from national security network intrusion insiders with Snowden-level access or the people developing and selling grey market 0-day to the intelligence community etc.  Those people are fallible humans too - they may succum to the financial motive, or the people who developed and sold them the 0-days may find a new monetization model, or second use for them (they cant "forget" them after sale).

There have also been VM escapes from full hw abstraction vms (i mean not just API sandbox light linux-in-linux virtuozzo but actual whole OS in the container).

And finally bitcoin scripting is functional, stateless and non-looping (non TC in fact also) for a reason.  Bitcoin doesnt (and I think its intentional) have even extrospection.  There are grey-goo outcomes if you are not careful with even something as constrained as an extrospection op code to existing language.   There will be whole classes of not yet imagined grey goo opportunities lurking in a full TC language.  You cant easily systematically defend against whole classes of such issues without intentional constrained language.

Here's a thread started by Greg to explore grey-goo outcomes from extended scripting:

https://bitcointalk.org/index.php?topic=278122.0

Greg Maxwell also noted the elevated risk of forks developing.  If there is any deviation in script outcome and being more complex there is more risk there also.  eg tracking how many cycles through a JIT executed/CSE optimized etc version as super-majority of nodes MUST interpret the script to the same byte code instruction, or one version can return true, another false etc.

I discussed these risks with Vitalik and he is a very smart guy, so obviously they'll try to do what they can to contain them, but you know bitcoin is the highest assurance sw dev and QA risk on the planet by orders of magnitude.  So it maybe a time for risk containment rather than risk LoC and API size expansion, I am already worried on bitcoin about base band-processors hacks, 0-day OS and CPU hacks, and thinking a more zero-trust more air-gap model needs to be the objective.

If hypothetically ethereum grew to large adoption (litecoin level say) and then there was enough motivation and something failed hard, there are potential whole system value loss, hard fork and other failure modes.  It seems to have by design, ongoing higher surface area security & value safety risk

Also btw Dan Kaminsky said he spent 4 months trying to hack bitcoin (network stack, overflow on messages, the usual host-security 0-day discovery process) and he failed.  He's one of the best host security guys and the experience impressed him.  Its not a simple thing to make a network stack that bullet proof, most even hard core programmers cant do it.  You probably have to practice 0-day development to some depth to even understand fully the risks and defense landscape.  Bitcoin got there with a really solid start from Satoshi and a bootstrap period where other bugs were fixed before the pressure built up to $10b.

I am not going to comment for now on the funding model  They are somewhere between the others and I am sure Vitalik has his eye on actual innovation as well, because knowing him he lives for tech challenge.

I think anything that needs to be done, can be done in a bitcoin centric backwards compatible evolutionary way using eg 1-way peg and other related features while maintaining value firewalls between long term holders and people using newer features.

But clearly other than the security containment, zero-defect in flight once live, and grey-goo risks, Ethereum can create some fun self-extensibility with a loose analog of like introspection, late binding, eval and dynamically loadable code languages.  We do have to be clear that the cost is the towards opposite end of the spectrum, though lower than activeX and executing native code delivered over the network.  Fun possibilities but a big security job.

Adam

[lebing]

Interesting. It seems that it certainly does not make sense to incorporate it into a protocol when that protocol is designed to be money. However, it seems that it could (alot of answered questions in that could!) make sense if it was designed to compete with the app store.

[coinrevo]

Thanks for the technical comments. Fundraising up to a claimed goal of 36 million USD is not exactly trivial. Conflating money supply issues and in the proof of stake ("IPO") is not helpful in my opinion. so any claims about money supply function is tied to the initial fundraising process. obviously bitcoin completely bootstrapped, so its hard to see for me how this should be an improvement. although I do like the idea that developers get paid for their work. it raises many questions in terms of interaction with the law. private IPO's are not legal.

[Peter Todd]

Also btw Dan Kaminsky said he spent 4 months trying to hack bitcoin (network stack, overflow on messages, the usual host-security 0-day discovery process) and he failed.  He's one of the best host security guys and the experience impressed him.  Its not a simple thing to make a network stack that bullet proof, most even hard core programmers cant do it.

There's nothing impressive about that at all. Those security problems are characteristic of non-bounds-checked languages, and Bitcoin is effectively written in a safe, bounds checked, subset of the C++ language. Meanwhile Dan Kaminsky did miss a whole bunch of dumb and not so dumb DoS attacks, including ones that crash the Bitcoin Core daemon with out-of-memory errors. (e.g. the extra tx data issue where Bitcoin would accept transactions with up to 32MiB of junk data appended to them and keep that all in memory) Quite frankly for him to give such a glowing report of Bitcoin makes me question his competence more than anything else.

[gmaxwell]

Replacing the scripting system with SNARK proofs has non-serious problems that remain unsolved. Verifying keys for SNARKs are huge,

Huh. No, in the (refined) GGPR'12 construction that you're referring to with the other criticisms (e.g. the CRS assumptions) the verifying keys are 2.8KB. This probably compares pretty favorably to program size for any program complicated enough to actually need a turing complete expression. The proving keys are huge, which might be what you were thinking of— but they don't have a major impact on the network.

The verification keys may end up being larger for something without the CRS security assumptions— though as you note its possible to just reuse a single universal circuit for all computations with some efficiency loss.

I think that the more important point in all this is that in a publicly verifiable system like Bitcoin what you want is _not_ execution. What you want is a witness that proves that execution was performed faithfully and what its result was.  There is no need to have an identical computation performed over and over again, it's just waste. In many cases this witness must be at least partially zero knoweldge, in order to prevent miners/other nodes from replaying it and stealing coins.

The simplest way to get a witness for execution is to disclose the code and have everyone perform it again... but it's not the best: It can't be zero knoweldge, it exposes a lot of code that never gets executed, it requires all verifiers to completely reproduce the work— which creates a disincentive against verification which is opposed to the decentralization goals of the system (and if you don't care about trustless decentralization why not just run open transactions?).

SNARKs are a way (well a family of ways) to improve this and in theory they tick a lot of those boxes— e.g. they can achieve zero knoweldge, they can be very small, etc. But SNARKs (esp one particular kind of SNARK) are not the only thing that can be done.  E.g. without invoking moon math we can use the merkelized abstract syntax trees to at least get succinctness and privacy for untaken branches in execution.

In any case, part of the problem with trying to do powerful things in script directly is not that turing completeness itself is hard to make safe— it can be made safe with careful design— but when script evaluation time is non-trivial it will be necessary to build things like JITs to eliminate the 100 fold slowdown from dumbly interpreted evaluation and that will come with a whole host of consistency and safety risks. JITs which are internally indistinguishable from interpreted execution seem to be a pretty much unstudied area.

Keep in mind that execution inside a consensus system multiplies the security considerations of normal sandboxed execution tremendously since absolute consistency becomes a security requirement too, not just memory and control flow integrity.

[coinrevo]

For smart contracts to work one really wants external inputs from the world. For example weather derivatives are an interesting example, say:

sunshine = get_weather('weather.com')
if sunshine:
 pay 1 BTC to xyz
else:
 pay 0.5 BTC to abc

One solution would be to have a trusted source list (weather.com or several sources). The question then is not about node security, but the relationship between a node and some server. One solution might be to sandbox on some external virtual machine image which is specifically used for a transaction.

I'm not sure how much work has been done in terms of virtualization for specific transactions, if at all. one idea is the possible connection of btc to some ("cloud") server. the server takes money for execution and if the balance is zero it destroy itself. on top of a server one can run a pre-build machine image with application software. In the above example you want weather.com to provide a highly stable API, and if it goes down the contract is canceled and you get an insurance payoff. If enough people have economic interest in weather.com to provide a certain interface they can maintain that function with a small amount of btc. This then is not so much a corporation running a service at weather.com but a self maintaining public server. it seems ethereum tries to address this kind of problem, but is missing some primitives. for instance how to run a server without one admin with total control, but rather group control.

[maaku]

There's no way you'd want transaction validation to depend on responses from a specific server. That would destroy distributed consensus. I think that's a terrible example of what to do on the block chain, but if you were to do it you'd have to depend on data committed to the block chain in some way. Otherwise you are destroying the security guarantees of everybody else who uses it.

[pera]

Really short and synthetic text but yet a bit relevant:
http://www.haskell.org/haskellwiki/Safely_running_untrusted_Haskell_code

Anyways, in my opinion the choose of a Forth like language for Bitcoin is one of the wisest decisions made by Satoshi

[coinrevo]

There's no way you'd want transaction validation to depend on responses from a specific server. That would destroy distributed consensus. I think that's a terrible example of what to do on the block chain, but if you were to do it you'd have to depend on data committed to the block chain in some way. Otherwise you are destroying the security guarantees of everybody else who uses it.

What would I want to do with contracts if I can't use inputs? For this reason talk about smart contracts is theory at best, and gibberish at worst. I agree that such a solution is not possible when you talk about traditional servers. for instance just consider the fact that contracts are usually confidential, i.e. not every node should process the information, only the parties involved.

[Mike Hearn]

I think my biggest concern/question mark with Ethereum is that nobody has shown that the limitation on implementing cool stuff inside Bitcoin is script. Script is limited, but even so, most of our ideas never even get close to pushing the boundaries.

The limits on what we can do right now are far more mundane things, like people writing nice GUIs and slick workflows. The underlying cryptography is often very simple. Ethereum isn't focused on solving that.

BTW the latest results on SNARKs have generalised the keys so that you only need one proving key and one verification key (I think) for all programs you might want to ever execute up to a running-time bound. If only proving weren't so expensive, and the math so hard to understand, they'd really be an ideal fit for a next-gen cryptocurrency.

[k99]

I think my biggest concern/question mark with Ethereum is that nobody has shown that the limitation on implementing cool stuff inside Bitcoin is script. Script is limited, but even so, most of our ideas never even get close to pushing the boundaries.

The limits on what we can do right now are far more mundane things, like people writing nice GUIs and slick workflows. The underlying cryptography is often very simple. Ethereum isn't focused on solving that.

BTW the latest results on SNARKs have generalised the keys so that you only need one proving key and one verification key (I think) for all programs you might want to ever execute up to a running-time bound. If only proving weren't so expensive, and the math so hard to understand, they'd really be an ideal fit for a next-gen cryptocurrency.

Vitalik described here (http://bitcoinmagazine.com/9671/ethereum-next-generation-cryptocurrency-decentralized-application-platform) his problems when working in Colored Coins or other Metacoin projects (Mastercoin,...) . It is not only the limitation of scripts but also scalability problems (need full blockchain to operate).

He also introduced other new exciting ideas and concepts (mining algorithms, way how to store the balance, inflation model...) which really drives crypto currencies to a new level.
I really think he deserves a more intense attention and discussion from BTC core devs.
For me it seems by FAR the most interesting project since BTC itself. And Vitalik Buterin has gained his high reputation not by chance. He seems to be one of the brightest minds in the community.

SNARK sounds really promising but due the complexity and open problems not a solution we could expect in the next 2 years I fear.

[coinrevo]

And Vitalik Buterin has gained his high reputation not by chance. He seems to be one of the brightest minds in the community.

what has he actually implemented? the only thing this shows is that is that cryptocurrencies are currently going nowhere, when such drivel can get so much attention. so I ask: where is the source code that does all these magical things? smarts contracts, DAC, ... all of this is simply nonsense the way it is described. and this has little to do with Turing complete languages.

[Mike Hearn]

Yeah, SNARKs will be fun to play with when the kit is open sourced but I am very skeptical it'd be useful for anything production for a while. For one, it's unexplainable black magic. We'd need to write good tutorials and explanations of how it all works, basic stuff like that ...

[Vitalik Buterin]

And Vitalik Buterin has gained his high reputation not by chance. He seems to be one of the brightest minds in the community.

what has he actually implemented?

You're asking for a dev resume? Here you go then:

http://github.com/vbuterin/pybitcointools
http://github.com/vbuterin/node-sx
http://github.com/vbuterin/bitcoinjs-lib
http://multisig.info
http://github.com/ethereum/pyethereum

where is the source code that does all these magical things? smarts contracts, DAC, ... all of this is simply nonsense the way it is described.

http://ethereum.org/ethereum.html , the section on "applications"

[Gavin Andresen]

How do transaction fees work in Ethereum?

One of the non-obvious reasons Bitcoin works is transaction fees are based on the size (in bytes) of the transaction. And since there are no loops executing a transaction, CPU usage is bound by transaction size.

If CPU usage to verify a transaction is NOT related to the transaction size, then you open yourself up to denial-of-service attacks. Like:

Create an Ethereum transaction with a (huge!) fee that will pay for 60 seconds of CPU execution time.
... but craft it so execution takes 61 seconds (or, heck, make it an infinite loop, maybe you'll tickle a bug in the execution termination code).

Now broadcast it.  It will be rejected for insufficient fee, but only after peers have wasted 60 seconds of CPU time. And if the transaction is rejected, the attacker won't pay the fee.

Then tweak it slightly and broadcast it again, maybe from a different IP address if you got banned for bad behavior.

I haven't thought deeply about whether or not there is a way to punish the attacker; my first thought would be to publish the attacker's transaction and take the fee but ignore any other effects of the transaction, but you'd have to be careful to design THAT mechanism so it couldn't be abused.

[coinrevo]

You're asking for a dev resume? Here you go then:

That was a bit mean from me. I appreciated the work more, before someone put in the idea of corporate control. that is not opensource/anarchism. anyway, if everyone plays fair, its a free market.

cryptocurrencies have as much to do with economics as it has to do with cryptography/computer security/etc. One problem is one can't pick up sound economic thinking from a textbook, as modern economics is mostly nonsensical drivel. And it does not help to understand how in the future human societies will be organized based on principles of cryptocurrencies.

this thread is a good example. it discusses various technical questions, but does not touch at all on the questions of contracts, and why we even would want smart contracts/DAC's and what they are good for. say for example all contracts with the government, which can be changed more or less arbitrarily by those in power, starting with control of money supply. so the question is how this new arising form of social organization fits in with the existing civilization, which is build on nation states + a rather strangely constructed institution named United Nations + other institutions like Worldbank, IMF, SWIFT, G8, etc.

[behindtext]

One of the non-obvious reasons Bitcoin works is transaction fees are based on the size (in bytes) of the transaction. And since there are no loops executing a transaction, CPU usage is bound by transaction size.

If CPU usage to verify a transaction is NOT related to the transaction size, then you open yourself up to denial-of-service attacks. Like:
...

this is precisely why a turing complete scripting language is a bad idea in the context of cryptocurrencies: it is highly non-trivial to put bounds in place to prevent or mitigate exploits.

[coinrevo]

this is precisely why a turing complete scripting language is a bad idea in the context of cryptocurrencies: it is highly non-trivial to put bounds in place to prevent or mitigate exploits.

satoshi designed the stack engine for a very good reason. it doesn't look like this will ever be done in bitcoin itself. the risk is too high for that kind of experimentation to occur now. overall the system/network has probably much more inertia than initially thought. from which I infer that there will be several serious candidates in the long term.

[Vitalik Buterin]

How do transaction fees work in Ethereum?

One of the non-obvious reasons Bitcoin works is transaction fees are based on the size (in bytes) of the transaction. And since there are no loops executing a transaction, CPU usage is bound by transaction size.

If CPU usage to verify a transaction is NOT related to the transaction size, then you open yourself up to denial-of-service attacks. Like:

Create an Ethereum transaction with a (huge!) fee that will pay for 60 seconds of CPU execution time.
... but craft it so execution takes 61 seconds (or, heck, make it an infinite loop, maybe you'll tickle a bug in the execution termination code).

Now broadcast it.  It will be rejected for insufficient fee, but only after peers have wasted 60 seconds of CPU time. And if the transaction is rejected, the attacker won't pay the fee.

Then tweak it slightly and broadcast it again, maybe from a different IP address if you got banned for bad behavior.

I haven't thought deeply about whether or not there is a way to punish the attacker; my first thought would be to publish the attacker's transaction and take the fee but ignore any other effects of the transaction, but you'd have to be careful to design THAT mechanism so it couldn't be abused.

You're (very understandably ) coming at this from too much of a Bitcoin perspective, where scripts are attached to transactions and transaction outputs and transactions can either pass or fail. That's not how Ethereum works. In Ethereum, you have entities called contracts, where contracts have their own balances, and are activated every time you send a transaction (think: money with an optional message attached) to them. The contract has 16 computational steps for free to give it wiggle room to determine whether a transaction is even worth processing; after this, every computational step that the contract takes costs it 1x BASEFEE (or more for specialized data access or crypto ops). If the contract goes bankrupt halfway through the computational process, it just stops halfway through. Here is the critical part: unlike is the case with Bitcoin, here the transaction does not "fail". The transaction still succeeds; the contract just ends up sitting there out of gas halfway through some long calculation instead of doing anything interesting. If you send a second transaction to the same contract immediately after, it will halt right after the 16 step grace period (or maybe more if the second transaction is sending some non-negligible amount of ether to refill it).

That was a bit mean from me. I appreciated the work more, before someone put in the idea of corporate control. that is not opensource/anarchism. anyway, if everyone plays fair, its a free market.

cryptocurrencies have as much to do with economics as it has to do with cryptography/computer security/etc. One problem is one can't pick up sound economic thinking from a textbook, as modern economics is mostly nonsensical drivel. And it does not help to understand how in the future human societies will be organized based on principles of cryptocurrencies.

this thread is a good example. it discusses various technical questions, but does not touch at all on the questions of contracts, and why we even would want smart contracts/DAC's and what they are good for. say for example all contracts with the government, which can be changed more or less arbitrarily by those in power, starting with control of money supply. so the question is how this new arising form of social organization fits in with the existing civilization, which is build on nation states + a rather strangely constructed institution named United Nations + other institutions like Worldbank, IMF, SWIFT, G8, etc.

Okay, time for me to put my armchair econo-socio-politico-philosopher hat on.

We're not trying to be a corporate controller. You may notice that unlike Freicoin, Devcoin and the like, the Ethereum organization is NOT collecting any kind of tax or issuance share forever; there is only a small one-time fundraise/premine at the start. This essentially sets in stone what I have come to realize is an important principle in business and social organization: small organizations, like startups, usually have to be dictatorial and have one or a few dominant players pushing a coherent vision with appropriate incentivization to help the process along. In the long term, however, structures that aim to be basic institutions of society (currency being one of the most important) should be controlled by no one. I feel like this compromise approach well represents the feelings of the Bitcoin community. The problem we have today is that organizations either try to either start decentralized, and often unfortunately fail, or start centralized, and then get drunk with power (or get co-opted by entities that are already drunk with power) and never bother actually implementing the decentralization step.

We do spend a lot of time thinking about exactly how these new decentralized structures can help either augment or replace existing systems, and how they fit into the categories of standard economics. At this point, we are still very much in the speculative fiction stage, but perhaps you might find these interesting:

http://bitcoinmagazine.com/9435/markets-institutions-currencies-new-method-social-incentivization/
http://blog.ethereum.org/2013/12/31/bootstrapping-a-decentralized-autonomous-corporation-part-i/
http://blog.ethereum.org/2013/12/31/bootstrapping-an-autonomous-decentralized-corporation-part-2-interacting-with-the-world/
http://blog.ethereum.org/2013/12/31/bootstrapping-a-decentralized-autonomous-corporation-part-3-identity-corp/
http://bitcoinmagazine.com/6528/what-proof-of-stake-is-and-why-it-matters/
http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/
http://blog.ethereum.org/2014/02/01/on-transaction-fees-market-based-solutions/

What I like about the Ethereum community so far is precisely the level of interest in economic issues and willingness to look for solutions with a fresh eye that I'm seeing. We are all committed Bitcoiners, and believe in the principle of decentralization; however, at the same time we understand well why centralized systems have come to exist and the positive role they have often served in pushing humanity forward even while committing those evils of which we are all very aware. Thus, the emphasis is precisely on figuring out what the benefits are that centralization brings, and seeing if we can come up with incentive structures that provide most of the benefits without most of the drawbacks. A good analogy here is data structures in computer science. We have arrays, where a 1000-item array takes 1 step to modify or access a value but 500 steps to insert or delete, and we have linked lists, where a 1000-item list takes 500 steps to access a value but only 1 step to insert or delete. However, more recently we invented the concept of trees, where you can have a 1000-item tree where inserting, modifying, accessing and deleting all take no more than 10 steps -  a compromise that gives us nearly the best of both worlds. Those are the kinds of cleverly rigged and elegant solutions to problems that we are trying to seek.

[Gavin Andresen]

Okey dokey... so how do fees work in Ethereum?

Or do you have some other clever distributed way of preventing flood-the-system-with-bogus-contracts DoS attacks?

[k99]

Okey dokey... so how do fees work in Ethereum?

Or do you have some other clever distributed way of preventing flood-the-system-with-bogus-contracts DoS attacks?

Here is my understanding how it works, hope Vitalik can give a more precise answer.

A contract is associated with a balance. If the balance is 0 the contract will not be executed. A contract gets executed by sending a transaction to a contract. The tx needs to be funded, so I assume you cannot send a 0 Ether tx to a contract. That way you prevent to flood execution of unfunded contracts. So you have 2 times a fee in place to prevent attacks. The tx needs to be funded with a fee to activate a contract and the contract need to have some balance to get executed.

If you have an endless loop, the loop consumes with every step some fee and after a limited time the contract run out of balance and stop.

About fees: http://blog.ethereum.org/2014/02/01/on-transaction-fees-market-based-solutions/

[Vitalik Buterin]

Okey dokey... so how do fees work in Ethereum?

Or do you have some other clever distributed way of preventing flood-the-system-with-bogus-contracts DoS attacks?

Here's the relevant part of my post above highlighted for clarity:

In Ethereum, you have entities called contracts, where contracts have their own balances, and are activated every time you send a transaction (think: money with an optional message attached) to them. The contract has 16 computational steps for free to give it wiggle room to determine whether a transaction is even worth processing; after this, every computational step that the contract takes costs it 1x BASEFEE (or more for specialized data access or crypto ops). If the contract goes bankrupt halfway through the computational process, it just stops halfway through.

A contract is associated with a balance. If the balance is 0 the contract will not be executed. A contract gets executed by sending a transaction to a contract. The tx needs to be funded, so I assume you cannot send a 0 Ether tx to a contract.

Actually, you can send a 0 ether tx to a contract, although that tx will still cost the sender a TXFEE.

The tx needs to be funded with a fee to activate a contract and the contract need to have some balance get executed.

Precisely; although with the proviso that the first 16 computational steps in contract execution are free, so if a contract is decently written you can't involuntarily send transactions to it to bankrupt it.


Here's an example also (assume BASEFEE = 1 ether for convenience)

CONTRACT: [ PUSH 0 JMP ], balance: 1000

The contract is pretty much the simplest possible infinite loop script; it's the equivalent of "10: DO_NOTHING; 20: GOTO 10"

Now, suppose that someone sends it a transaction with value 10 ether (this tx will cost the sender 110 ether due to the TXFEE):

TX: [ ADDRESS, 10, [], v, r, s]

Step 1: { Counter: 0, Index pointer: 0, Stack: [], balance: 1010 }
Step 2: { Counter: 1, Index pointer: 2, Stack: [ 0 ], balance: 1010 }
Step 3: { Counter: 2, Index pointer: 0, Stack: [], balance: 1010 }
...
Step 16: { Counter: 15, Index pointer: 2, Stack: [ 0 ], balance: 1010 }
Step 17: { Counter: 16, Index pointer: 0, Stack: [], balance: 1009 }
Step 18: { Counter: 16, Index pointer: 2, Stack: [ 0 ], balance: 1008 }
...
Step 1025:  { Counter: 16, Index pointer: 0, Stack: [], balance: 1 }
Step 1026:  { Counter: 16, Index pointer: 2, Stack: [ 0 ], balance: 0 }
Step 1027: ERROR NOT ENOUGH FUNDS HALT

The contract now has a balance of 0 ether, so if someone tries to send that transaction again, the second time around execution will stop at step 17 rather than 1027.

[Peter Todd]

Vitalik: Is that a true fee that goes to miners, or a sacrifice?

[maaku]

Okey dokey... so how do fees work in Ethereum?

Or do you have some other clever distributed way of preventing flood-the-system-with-bogus-contracts DoS attacks?

Gavin, as far as I can tell there is no such thing as a bogus contract in Etherium. You pay a one-time fee to register a contract - setup an execution context for a script in the validation state of every node - but script representing that contract is not validated in any way. There's no way for a contract to be rejected, so there's no way to "DoS with bogus contracts".

[coinrevo]

We're not trying to be a corporate controller.
We are all committed Bitcoiners, and believe in the principle of decentralization;

What we need is a structured marketplace, where people who buy and sell cryptocurrencies meet, based on same principles. that's what I'm working on. as long as some market principles are met, demand and supply can establish a fair price of any currency. price is then the estimate of future value.

there is only a small one-time fundraise/premine at the start.

We don't have a process for tracking fundraisers. There is no way to know what happened with past funds. It would be much better to build a plattform which can be re-used and to actually build out the intermediation process. the alt-coin market is pretty fragile at the moment.

[Gavin Andresen]

Thanks, k99 and Vitalik, that helps clear it up.  I've put "On Transaction Fees, And The Fallacy of Market-Based Solutions" on my to-think-about-deeply list.

I'm curious about this, though:

Precisely; although with the proviso that the first 16 computational steps in contract execution are free, so if a contract is decently written you can't involuntarily send transactions to it to bankrupt it.

If my contract needs more than 16 computational steps to execute, then other people CAN send transactions to it to intentionally bankrupt it? That is what I was worrying about when I said "publish the attacker's transaction and take the fee but ignore any other effects of the transaction, but you'd have to be careful to design THAT mechanism so it couldn't be abused."

[coinrevo]

I've put "On Transaction Fees, And The Fallacy of Market-Based Solutions" on my to-think-about-deeply list.

..which is this article
http://blog.ethereum.org/2014/02/01/on-transaction-fees-market-based-solutions/

[Mike Hearn]

Re: the article. Saying mining is not a market because if it becomes dominated by a tiny number of players fees might go up seems backwards - surely higher prices due to lack of competition is exactly how you'd expect a market to behave? At any rate, I question whether the additional few minutes would make any real difference to most users. For all the miles of forum posts the block chain algorithm generates, there are really only two speeds that matter for the majority of cases: instant and not instant.

The fact that fees would trend towards the cost of accepting a transaction into a block is a well known issue that has been studied for a long time. The block chain is indeed a commons (as is a lot of other important aspects of the Bitcoin infrastructure). There are ways to fund public goods, fortunately.

I've expected for a long time that fees will end up being used in several different ways simultaneously:

• A tiny fee of either bitcoins (assigned to miners) or priority (burned) on every transaction, as a simple load management mechanism. I hope to see these fees largely collapse or disappear in future in favour of priority, as Bitcoin gets more sophisticated and scales better. These fees would not be large enough to support proof of work based security.
• Occasional large fees for proofs of sacrifice. These would be too rare to support proof of work based security.
• Occasional large fees for mining assurance contracts, at whatever level proves to be the best balance as determined by the market (perhaps intermediated by insurance companies).

[k99]

Thanks, k99 and Vitalik, that helps clear it up.  I've put "On Transaction Fees, And The Fallacy of Market-Based Solutions" on my to-think-about-deeply list.

I'm curious about this, though:

Precisely; although with the proviso that the first 16 computational steps in contract execution are free, so if a contract is decently written you can't involuntarily send transactions to it to bankrupt it.

If my contract needs more than 16 computational steps to execute, then other people CAN send transactions to it to intentionally bankrupt it? That is what I was worrying about when I said "publish the attacker's transaction and take the fee but ignore any other effects of the transaction, but you'd have to be careful to design THAT mechanism so it couldn't be abused."

As Vitalik mentioned a 0 Ether tx could be sent to a contract to activate it and cause some cost for the contract if it runs more then 16 steps. If the contract balance is 0 it will stop there.
A flooding with 0 Ether tx is protected due the tx fee.
As far as I understand a contract gets feeded by the tx activating it. So if a contract has been run out of its own contract funds, only tx with sufficient tx value will cause the contract to run (> 16 steps).
For me it is not clear why a contract holds balance on its own and why the tx value is not enough to control the contract execution. If a contract is funded (contract balance >0) there is no incentive to send a tx with a value there (paying for the execution).

[coinrevo]

Saying mining is not a market because if it becomes dominated by a tiny number of players fees might go up seems backwards - surely higher prices due to lack of competition is exactly how you'd expect a market to behave?

Surely mining does not suffer from lack of competition. Its rather how pools shift power from consumer to producer. much economic research is spent on studying monopols, oligopols, polypols (1, few, many). oligopols often exist in resource markets like oil and electricity, because of scaling effects. its not that surprising we see the same in bitcoin. a miners tax is probably not a bad idea to redirect excess profits.

[Come-from-Beyond]

In Ethereum, you have entities called contracts, where contracts have their own balances, and are activated every time you send a transaction (think: money with an optional message attached) to them. The contract has 16 computational steps for free to give it wiggle room to determine whether a transaction is even worth processing; after this, every computational step that the contract takes costs it 1x BASEFEE (or more for specialized data access or crypto ops). If the contract goes bankrupt halfway through the computational process, it just stops halfway through.

How r blockchain reorgs handled? Computational steps can't be rolled back nor blockchain can be re-rolled from block 0, so u r supposed to store blockchain snapshots each N-th block, which is quite expensive.
Can't a Finney attack be combined with a very long-running transactions to DoS all nodes? If a miner earns all block fees then even without a Finney attack a malicious miner could include a lot of long-running transactions into their block to slow down processing of the next block / transactions.

[crabel]

I've put "On Transaction Fees, And The Fallacy of Market-Based Solutions" on my to-think-about-deeply list.

..which is this article
http://blog.ethereum.org/2014/02/01/on-transaction-fees-market-based-solutions/

Be very careful about non market pricing mechanisms. The problem with price determination is about discovering the price. While you can set the price, ala a Pigovian tax, you are doing so without knowing the actual value of the item being assessed.

There is much more going on here than the simplistic models being proposed. I'm reminded of Bastiat's "Seen and unseen". The market possess many methods that enforce discipline. Such things are the emergence of practices of what is proper. Things like common law (written and unwritten) emerge from propriety. The complexity contained within these relationships greatly affects the price and value of action within that market.

Satoshi was very wise to leave as much up to the market and the individuals that comprise each market. Here he accessed one of the greatest information aggregators humanity ever devised. For the Etherum developers I suggest you read an article by Hayek, "The Use of Knowledge in Society". You can get a copy here: http://www.econlib.org/library/Essays/hykKnw1.html

Here is an amusing and informative video by Mike Munger explaining the information problem in externalities: http://www.learnliberty.org/videos/externalities-when-is-a-potato-chip-not-just-a-potato-chip

I am from the energy field and have dealt a great deal with understanding the impact of externalities on the production and consumption of energy. I found that invariably any policy that is founded on presuming to know the social value ALWAYS creates a net social harm. I now appreciate the Coasian approach to resolving these externalities through the creation of proerty rights (markets) even this approach is not fail proof. Please look at the work of Coase and Hazzlet. There are two parts to Coase's theorem about externalites. Both need to be understood before effective policy is developed.

[Dusty]

Is there a hard limit to the execution time of a transaction or is it capped only by his attached fee?

[k99]

Is there a hard limit to the execution time of a transaction or is it capped only by his attached fee?

A contract can run a infinite loop until it runs out of ether. There is no hard cap.

[rethaw]

There are grey-goo outcomes if you are not careful with even something as constrained as an extrospection op code to existing language.   There will be whole classes of not yet imagined grey goo opportunities lurking in a full TC language.  You cant easily systematically defend against whole classes of such issues without intentional constrained language.

I figure the grey goo nightmare is an unspoken goal of Ethereum. Has Vitalik written on this elsewhere?

[Dusty]

Is there a hard limit to the execution time of a transaction or is it capped only by his attached fee?

A contract can run a infinite loop until it runs out of ether. There is no hard cap.

So someone having a good chunk of ether can freeze the network by broadcasting one hundred transactions that runs out of ether after some days of computation time?

[k99]

Is there a hard limit to the execution time of a transaction or is it capped only by his attached fee?

A contract can run a infinite loop until it runs out of ether. There is no hard cap.

So someone having a good chunk of ether can freeze the network by broadcasting one hundred transactions that runs out of ether after some days of computation time?

Depends on the fees. Assume they will adjust the fees in a reasonable way. And if so, it would not be the end of the world, one whealty will loose his wealth and depending on the fee strategy they will implement, the spended fee will make all others (or the minders) wealthier.

Additionally if it turns out that this could become a real problem, to introduce a max. amount of steps for a contract should be also an option.

[gmaxwell]

Assume they

That doesn't doesn't sound like the kind of assumption permitted in a trustless decenteralized system. If you're willing to trust specific parties to do specific things— the design of paypal is far more efficient.

[maaku]

Consensus is tied to fee calculation in etherium, so there is no mechanism for adjusting fees later without a hard fork...

[k99]

Assume they

That doesn't doesn't sound like the kind of assumption permitted in a trustless decenteralized system. If you're willing to trust specific parties to do specific things— the design of paypal is far more efficient.

Sorry, I was not clear with my previous post. I meant the Ethereum team is still discussing the details and the model of the fee and I assume they will set it to a reasonable value so attacks cannot hurt the overall network. There is a voting model in discussion allowing to adjust slowly the fees.

Maybe Vitalik can give more details here, I just repeat stuff I have read in other places.

See also:
Whitepaper: http://www.ethereum.org/ethereum.html
Wiki: http://wiki.ethereum.org/index.php/Main_Page
Blog: http://blog.ethereum.org/

[k99]

Consensus is tied to fee calculation in etherium, so there is no mechanism for adjusting fees later without a hard fork...

There is the idea to use a voting mechanism where the fee can be adjusted (slowly). No hard forks are needed.

[k99]

Consensus is tied to fee calculation in etherium, so there is no mechanism for adjusting fees later without a hard fork...

There is the idea to use a voting mechanism where the fee can be adjusted (slowly). No hard forks are needed.

[maaku]

But what if the voting mechanism is flawed/insufficient/exploitable? Changing it requires a hard-fork.

[k99]

But what if the voting mechanism is flawed/insufficient/exploitable? Changing it requires a hard-fork.

There will never be a 100% safety that serious flaws not will provoke a hard fork. BTC has that experienced as well.

[maaku]

I think you're missing the point. Consensus in bitcoin does not depend on fee policy - miners can include whatever transactions they want. In Etherium, the fee policy is tightly integrated with contract balances and the ledger, so changing the fee policy is not an option. It doesn't have to be this way however - Etherium could have used a bitcoin-like input/output transaction system with optional fees. Fees would then determine transaction priority, but not be part of the consensus mechanism.

[k99]

I think you're missing the point. Consensus in bitcoin does not depend on fee policy - miners can include whatever transactions they want. In Etherium, the fee policy is tightly integrated with contract balances and the ledger, so changing the fee policy is not an option. It doesn't have to be this way however - Etherium could have used a bitcoin-like input/output transaction system with optional fees. Fees would then determine transaction priority, but not be part of the consensus mechanism.

The main task for fees in Ethereum are the protection against resource overuse (endless loop of a contract as worst case, but also storage costs,...). Why should the change of the fee be not an option or why would it need a hard fork?
The voting for a change of the basefee form say 100 Ether to 101 Ether (small change to not cause to much disruption) after a certain block index should not cause a problem in the concensus. After the voting the new fee is set up and all nodes require that fee for including a tx.
The voting is just one idea, it is not defined yet how they will implement the fee model, but they are aware that finding the right fee will be difficult.
In BTC we are confronted with a similar problem, the current fee is way too high and there is no flexible mechanism yet to solve that. I am not up to date what are the current plans to fix that in BTC... (maybe someone has a link to the current discussion about that topic in BTC?)

See here a discussion from Vitalik:
http://blog.ethereum.org/2014/02/01/on-transaction-fees-market-based-solutions/

[gmaxwell]

In BTC we are confronted with a similar problem

No, in fact, we are not. Please pay attention to what maaku is saying, he is drawing distinctions which you are missing and which— if you continue to miss— will be fatal to your project.

[maaku]

The vote would have to be on the chain, in a format that all clients understand. In other words the mechanism of voting will have to be set in stone, forever (any change to that mechanism would be a hard fork). And I would be very wary of anyone claiming to have a distributed voting protocol that is secure and with correct, safe incentives and which itself can't be subject to DoS or withholding attacks. This is complicated frontier stuff people are still working out.

But again, there's no reason Etherium has to be structured that way. Include execution counts in the transactions, and base fees off that explicit amount. During validation check that the execution counts are correct (and invalidate the transaction & block otherwise). Delay script execution until transaction is included in a block, and black list outputs of transactions that fail this validation check so as to provide an economic cost to DoS attempts. Problem solved.

[k99]

The vote would have to be on the chain, in a format that all clients understand. In other words the mechanism of voting will have to be set in stone, forever (any change to that mechanism would be a hard fork). And I would be very wary of anyone claiming to have a distributed voting protocol that is secure and with correct, safe incentives and which itself can't be subject to DoS or withholding attacks. This is complicated frontier stuff people are still working out.

See http://blog.ethereum.org/2014/02/01/on-transaction-fees-market-based-solutions:
"Fortunately, cryptocurrency is all about democratic consensus, and every cryptocurrency already has at least two forms of consensus baked in: proof of work and proof of stake. I will show two very simple protocols for doing this right now:
Proof of work Protocol

    If you mine a block, you have the right to set a value in the “extra data field”, which can be anywhere from 0-32 bytes (this is already in the protocol)
    If the first byte of this data is 0, nothing happens
    If the first byte of this data is 1, we set block.basefee = block.basefee + floor(block.basefee / 65536)
    If the first byte of this data is 255, we set block.basefee = block.basefee - floor(block.basefee / 65536)

Proof of stake Protocol

    After each block, calculate h = sha256(block.parenthash + address) * block.address_balance(address) for each address
    If h > 2^256 / difficulty, where difficulty is a set constant, that address can sign either 1, 0 or 255 and create a signed object of the form [ val, v, r, s ]
    The miner can then include that object in the block header, giving the miner and the stakeholder some miniscule reward.
    If the data is 1, we set block.basefee = block.basefee + floor(block.basefee / 65536)
    If the data is 255, we set block.basefee = block.basefee - floor(block.basefee / 65536)"

But again, there's no reason Etherium has to be structured that way. Include execution counts in the transactions, and base fees off that explicit amount. During validation check that the execution counts are correct (and invalidate the transaction & block otherwise). Delay script execution until transaction is included in a block, and black list outputs of transactions that fail this validation check so as to provide an economic cost to DoS attempts. Problem solved.

Thats all in the design (execution count, fees above). The open question is how to set the base fee and is there a way to structure them flexible?

I am not a Ethereum dev and also dont know the current state of the internal discussion. As far as I see they are still researching for the best solution.

[gmaxwell]

Ugh. Cryptocurrency. or at least Bitcoin at a minimum—  is _NOT_ about "democratic consensus" cue the trope about democracy is wolves voting to have the sheep for supper. Democratic consensus is a terrible way to handle things, but sometimes its the best available of all possible terrible ways to handle things, but that doesn't make it good. Ideally people could operate on a purely consensual basis and never be coerced just because someone amassed superior numbers.  "Democracy" is particularly intolerable, however, when voting power isn't tied to people-with-shared-interests but is instead tied to spending (as it must be in a POW blockchain consensus).

In Bitcoin the rules of the system are fixed in the software and autonomously enforced by everyone, without reference to any consensus. No simple majority of users or miners can change them, they are as immune to a majority tyranny as anything we know how to make. Sadly the whole system can't work on this alone, since there is no known decenteralized way to autonomously decide transaction order, but it is only in narrow-as-we-can make it way that we compromise on that.

You do not make your proposals look good when you justify them with such vulgar misunderstandings of the structure and motivations that enable Bitcoin to be (possibly!) viable.

[k99]

Ugh. Cryptocurrency. or at least Bitcoin at a minimum—  is _NOT_ about "democratic consensus" cue the trope about democracy is wolves voting to have the sheep for supper. Democratic consensus is a terrible way to handle things, but sometimes its the best available of all possible terrible ways to handle things, but that doesn't make it good. Ideally people could operate on a purely consensual basis and never be coerced just because someone amassed superior numbers.  "Democracy" is particularly intolerable, however, when voting power isn't tied to people-with-shared-interests but is instead tied to spending (as it must be in a POW blockchain consensus).

In Bitcoin the rules of the system are fixed in the software and autonomously enforced by everyone, without reference to any consensus. No simple majority of users or miners can change them, they are as immune to a majority tyranny as anything we know how to make. Sadly the whole system can't work on this alone, since there is no known decenteralized way to autonomously decide transaction order, but it is only in narrow-as-we-can make it way that we compromise on that.

You do not make your proposals look good when you justify them with such vulgar misunderstandings of the structure and motivations that enable Bitcoin to be (possibly!) viable.

As I noted in the response to maaku, I am not a Ethereum dev, only enthusiastic about the project.
Not sure if you really read the Whitepaper and the blog entry, if not maybe its worth to read it. I cannot add more then whats there written.

[Mike Hearn]

Theoretically Bitcoin is controlled by the "economic majority", i.e. if you're BitStamp or BitPay or some other very important player in the economy then what ruleset you choose to run matters more than if you're just a guy with some bitcoins on a phone. In practice we've never had a doomsday scenario where there's a deep disagreement over how Bitcoin should operate, so nobody knows if the "economic majority" concept actually matters or how it would work in practice.

Re: Bitcoin fees, yes the plan is to make them float. I'm hoping that fees will eventually fall if we do that, but it's going to be hard work because lots of major transaction emitters today heavily overbid for no real reason (like Mt Gox) and getting them to use more rational fee policies will take time.

[Apprehension]

The idea behind it is great but practical it will be very difficult.
The language must be 100% secure without too much restrictions.
One small exploit in the language and the whole coin will be useless.

[k99]

Theoretically Bitcoin is controlled by the "economic majority", i.e. if you're BitStamp or BitPay or some other very important player in the economy then what ruleset you choose to run matters more than if you're just a guy with some bitcoins on a phone. In practice we've never had a doomsday scenario where there's a deep disagreement over how Bitcoin should operate, so nobody knows if the "economic majority" concept actually matters or how it would work in practice.

Re: Bitcoin fees, yes the plan is to make them float. I'm hoping that fees will eventually fall if we do that, but it's going to be hard work because lots of major transaction emitters today heavily overbid for no real reason (like Mt Gox) and getting them to use more rational fee policies will take time.

Thats why I like that Ethereum is looking for new ideas to not use the miners conscensus (if they does not support a software update they vote against a change) but the stakeholders conscensus (PoS voting). I think it is important to the network that many full nodes are running, but with the growth of the network and tx volume the costs get higher to run a full node, so there must be an incentive for it.
I will be difficult to solve the fee issue in BTC as we are dependent to the miners acceptance. To change for instance the mining algorithm to an asic resistant one, would be already impossible (they just invested too much money to asics), showing much more the strong dependency to miners. I think in BTC the power balance between the users/full nodes/miners are not in a healthy balance anymore.

What are the plans to make the fees float in BTC. Can you post a link or some information?

[mmeijeri]

For smart contracts to work one really wants external inputs from the world. For example weather derivatives are an interesting example, say:

This can be done with something like Reality Keys without needing script extensions.

[mmeijeri]

I think my biggest concern/question mark with Ethereum is that nobody has shown that the limitation on implementing cool stuff inside Bitcoin is script. Script is limited, but even so, most of our ideas never even get close to pushing the boundaries.

I don't think the lack of Turing completeness is the biggest limitation. It's unfortunate that scripts do not have direct access to the transaction data itself and some notion of time. If they did, you could implement things like daily withdrawal limits and limit withdrawals to certain classes of scriptPubKeys. Of course, we should probably first experiment with things like that by using something like Reality Keys and additional signatures.

[JoeyD]

I'm having a real hard time in trying to understand the point of Ethereum.

The only one I could think of was, that currently it's risky to have a program/contract manage it's own bitcoin(or any other coin) wallet, because of the exposed private keys. But I recently read an article by Vitalik where he explains how that might be possible in the near future, through obfuscation. If that is true, don't we already have all the turing-complete languages you'd ever need to make distributed block-chain-inspired programs/contracts/organisations etc. on top of any coin you'd want, if it can manage and interact with it's own wallet(s)?

I imagine this would also enable really distributed and more efficient (purpose built) blockchain reward systems/applications that could grow on their own on top of bitcoin or any other, even multiple "coins" as their "fuel".

I don't really understand why you'd need a turing-complete centralized solution, if you could create a much more flexible system in a modular and even more decentralized way, not even dependent on a single type of potentially hazardous "fuel" (i.e. bitcoin and others).

[charleshoskinson]

Greg and Mike glad to see you guys here having a lovely chat about Ethereum. Greg I took your advice and got a real cryptographer since last time .

[bluemeanie1]

And Vitalik Buterin has gained his high reputation not by chance. He seems to be one of the brightest minds in the community.

what has he actually implemented? the only thing this shows is that is that cryptocurrencies are currently going nowhere, when such drivel can get so much attention. so I ask: where is the source code that does all these magical things? smarts contracts, DAC, ... all of this is simply nonsense the way it is described. and this has little to do with Turing complete languages.

Im with you on this.  'Turing Complete' seems to be some sort of totem to attract investors.

What I'm not hearing is the obvious problem here- to compute a balance or verify a chain I need to compute several million little C programs with potentially infinite loops?  perhaps several billion?  

It's a huge problem and the various rantings I'm hearing lately about magical 'turing complete' tx scripts don't even begin to address this basic problem.  The current scripting language has limits on execution time and processing requirements.  If you put limits on infinite loops, then its not turing complete.

see: The Halting Problem, http://en.wikipedia.org/wiki/Halting_problem

there's no 'grey goo' nightmare scenarios here, the scare is that I can put a TX in the block chain(perhaps several thousand) that potentially use all the processor resources of a node.  This seems to be yet another episode of the centralization story.

-bm

[benjyz]

well besides that, in an ethereum contract you simply broadcast the data of your private agreements to the whole world.

[bluemeanie1]

well, in an ethereum contract you simply broadcast the data of your private agreements to the whole world. neat.

where is this explained?

[benjyz]

Here is the paper: https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-White-Paper
This goes back to this wiki-pages. https://en.bitcoin.it/wiki/Contracts

anyway, the idea here is that you have "contracts", i.e. agreements between 2 parties. those are special transactions, although it's not at all clear what this should mean. contracts are mental objects of legal systems. "contracts" here have to be verified by P2P nodes. in Bitcoin all nodes know the global transactions. that is the public blockchain. this works because there is no sensitive data (ignoring anonymity and mixing). but these special contract arrangements would not be public. it doesn't really make sense for arbitrary transactions. it makes only sense for global financial contracts (forwards on commodities primarily).

and so the nomenclature is going wild here. I don't think any of it makes sense. so you can either have formal definitions and then explain what you precisely mean, or you're using natural language, which has a long history. contracts are traditionally tied to legal systems.

[Ursium]

Here is the paper: https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-White-Paper

And here's the "yellow" paper, more technical in nature for those who are inclined: http://gavwood.com/Paper.pdf

[jmw74]

And Vitalik Buterin has gained his high reputation not by chance. He seems to be one of the brightest minds in the community.

what has he actually implemented? the only thing this shows is that is that cryptocurrencies are currently going nowhere, when such drivel can get so much attention. so I ask: where is the source code that does all these magical things? smarts contracts, DAC, ... all of this is simply nonsense the way it is described. and this has little to do with Turing complete languages.

Im with you on this.  'Turing Complete' seems to be some sort of totem to attract investors.

What I'm not hearing is the obvious problem here- to compute a balance or verify a chain I need to compute several million little C programs with potentially infinite loops?  perhaps several billion?  

It's a huge problem and the various rantings I'm hearing lately about magical 'turing complete' tx scripts don't even begin to address this basic problem.  The current scripting language has limits on execution time and processing requirements.  If you put limits on infinite loops, then its not turing complete.

see: The Halting Problem, http://en.wikipedia.org/wiki/Halting_problem

there's no 'grey goo' nightmare scenarios here, the scare is that I can put a TX in the block chain(perhaps several thousand) that potentially use all the processor resources of a node.  This seems to be yet another episode of the centralization story.

-bm

Your computing environment is not Turing complete either!  Here's proof:  while (true) { print("hi") }

Run that, I guarantee it will be interrupted because it used too many resources.  How long will it be before it's interrupted?  Well, that can be arbitrarily long.  But it's the same with ethereum.  There won't be any infinite loops that don't get interrupted after some reasonable time.

Whether new nodes having to catch up by executing a billion scripts is a problem, depends on whether the history grows faster than Moore's law.  Hopefully there's some kind of feedback mechanism that prices ether according to computing power needed to operate a full node.

[bluemeanie1]

we're seeing a trend here.

apparently some groups involved in Bitcoin development don't see an issue with centralizing bitcoin.  This may give us some outward features, but it destroys the basic value proposition of the Bitcoin technology.

If we're talking about block chain scripts that are Turing Complete then certainly we are talking about block chains that potentially require infinite execution time, and likely very long expensive computation times.  If we abandon the constraints that currently exist in the block chain scripts then, in order to manage this problem, you must introduce a very complex dispatching environment that is capable of detecting runaway processes and the like.  At the LEAST, it will be a total redesign of Bitcoin and processing the chain will be incredibly cumbersome.

thus, in order to achieve this idea, you need to have more centralization.  Fact is we already have complex financial contract engines.  This isn't a new idea.  It would be a new idea if you could do it in a p2p way.

Non-turing complete was a FEATURE it wasn't a limitation that was heroically solved by some uber-genius.

-bm

[benjyz]

Turing completeness is the least of problems with these kinds of proposals.

quoting from http://gavwood.com/Paper.pdf

Early work on smart contracts has been done by Szabo [1997] and Miller [1997]. Around the 1990s it became clear that algorithmic enforcement of agreements could become a signicant force in human cooperation. Though no specific system was proposed to implement such a system, it was proposed that the future of law would be heavily affected by such systems. In this light, Ethereum may be seen as a general implementation of such a crypto-law system

This is deeply confused and misreads the original authors. why do laws exist in the first place? people don't enact their own laws at will. say Alice contracts with Bob to ship 1 kilogram of cocaine from Peru to New York City. how would ethereum enforce that contract? it's nice to speculate about a crypto-law system in 2100, but this hardly solves problems in the real world. in the world that exists, we have laws and nation states, global trade agreements, transportation systems, stock exchanges, insurance companies and many other social artifacts. What is needed is a thorough understanding why these exist and how that could potentially change based on new networks and cryptography.

[bluemeanie1]

notice that the author doesn't even mention the Halting Problem which is the basic reason why this constraint was introduced to the original Bitcoin scripting.

It's like removing seat belts from cars and declaring yourself a genius for making us slightly more comfortable. 

-bm

[jmw74]

Turing completeness is the least of problems with these kinds of proposals.

quoting from http://gavwood.com/Paper.pdf

Early work on smart contracts has been done by Szabo [1997] and Miller [1997]. Around the 1990s it became clear that algorithmic enforcement of agreements could become a signicant force in human cooperation. Though no specific system was proposed to implement such a system, it was proposed that the future of law would be heavily affected by such systems. In this light, Ethereum may be seen as a general implementation of such a crypto-law system

This is deeply confused and misreads the original authors. why do laws exist in the first place? people don't enact their own laws at will. say Alice contracts with Bob to ship 1 kilogram of cocaine from Peru to New York City. how would ethereum enforce that contract? it's nice to speculate about a crypto-law system in 2100, but this hardly solves problems in the real world. in the world that exists, we have laws and nation states, global trade agreements, transportation systems, stock exchanges, insurance companies and many other social artifacts.

Obviously crypto can't really prove anything about the real world.  That doesn't make "crypto-law" systems useless though.  It just means you have to have some kind of trusted authority to at least certify what happened in the real world, and then the "crypto-law" system can do the rest.

So using your example, if you have a trusted delivery guy Dave who certifies that he received 1 kg cocaine from Alice and delivered it to Bob, then his signature would unlock terms of the contract as-written (payment or whatever).  He could sign that the shipment was damaged in transit and that would unlock some kind of insurance payment.

[benjyz]

Obviously crypto can't really prove anything about the real world.  That doesn't make "crypto-law" systems useless though.  It just means you have to have some kind of trusted authority to at least certify what happened in the real world, and then the "crypto-law" system can do the rest.

So using your example, if you have a trusted delivery guy Dave who certifies that he received 1 kg cocaine from Alice and delivered it to Bob, then his signature would unlock terms of the contract as-written (payment or whatever).  He could sign that the shipment was damaged in transit and that would unlock some kind of insurance payment.

In scenario B, Alice would ship 1 kg of gold to Bob. She would have to acquire various licenses. Those authorities already exist and are tied to fabric of the global economy. Obviously, in scenario A - shipment of cocaine from Peru to the USA - this is illegal. What gets shipped in the world is determined by nation states and multi-national cooperations. Which natural resources gets shipped where on what conditions is what geopolitics is mostly about. The recent TPP efforts want to establish a kind of cooperate regime, where cooperations can sue governments. This kind of stuff is infinitely complex, and declaring the world your own jurisdiction is not leading to solutions.

[bluemeanie1]

"Ethereum Virtual Machine (EVM). It is a quasi-Turing-complete machine; the quasi qualification comes from the fact that the computation is intrinsically bounded through a parameter, gas, which limits the total amount of computation done."

it's kind of Turing Complete, except it isn't.

so apparently they have a new kind of resource monitoring that they call 'Gas', and I guess you have to purchase this "gas" in order to run your script?

I've worked for E-commerce companies that had specialized definition languages for financial processing like this.  One of them had some neat 'pipelines' that were supposed to be incredibly easy to use.  In at least one case they abandoned them because it was too much overhead to support them over just traditional scripting.  

This idea seems incredibly monolithic.  Not sure how the project is organized, but it will resemble Ripple in a lot of ways, but even more complex- and it'll require huge amounts of money to develop successfully.  If they put together this computation management system together, the language they are proposing, think about all the support and such they need to build out in order for it to work?  are people going to actually use this?  And there's a lot of remaining questions about how centralized or 'p2p' this is, I can't see everyone running one of these contract engines on their own computer.  Bitcoin is relatively lightweight, this thing sounds like a monster.



-bm

[bluemeanie1]

Your computing environment is not Turing complete either!  Here's proof:  while (true) { print("hi") }

Run that, I guarantee it will be interrupted because it used too many resources.  How long will it be before it's interrupted?  Well, that can be arbitrarily long.  But it's the same with ethereum.  There won't be any infinite loops that don't get interrupted after some reasonable time.

Whether new nodes having to catch up by executing a billion scripts is a problem, depends on whether the history grows faster than Moore's law.  Hopefully there's some kind of feedback mechanism that prices ether according to computing power needed to operate a full node.

a 'computing environment' is not Turing Complete, but computer languages are.

this poses the first problem of FALSE ADVERTISING.  These aren't Turing Complete scripts, it's just a bloated up dispatching environment for financial transactions.  I think they're overestimating how 'cool' this is going to be.  It's not going to be fun to make or to use.  Why dont they just use the JVM?  you can control thread execution from another process.  Java caught onto CLLs long before these guys declared they discovered  the idea.

there is an entire field of research called 'workflow engines' that attempt to deal with these problems.  If you've ever worked with one, you would probably come running back to all your Bitcoin friends after a few hours of mind numbing process definition languages and the like.

if they can make this as advertised and it's open source... great!  have fun storming the castle!

-bm

[jmw74]

a 'computing environment' is not Turing Complete, but computer languages are.

So?  Ethereum is turing complete then.  Running out of ether is part of the environment, not the language.

this poses the first problem of FALSE ADVERTISING.  These aren't turning complete scripts, it's just a bloated up dispatching environment for financial transactions.  I think they're overestimating how 'cool' this is going to be.  It's not going to be fun to make or to use. 

Yes, this is what I think is the real problem, programs are hard to understand and debug.

In law, sure judges are nondeterministic, but they don't do totally insane stuff, like in a parental custody hearing, they don't set their program counter to the wrong number and accidentally sentence some innocent bystander to death.  Something that bizarre could maybe happen in ethereum.

Still, I am not sure if this is a fatal flaw, if anything it might limit scripts to what is easily comprehendable by one programmer.  That's still a lot more flexible than bitcoin's scripting system.

I don't really care how they sandbox their environment, in theory it should be a lot simpler than the JVM.  But maybe it is easier to just use the JVM and lock down everything except the few resources ethereum needs access to.  Either way, the sandbox is not going to be what holds them back, I think those already exist and are a proven concept.

[jmw74]

Obviously crypto can't really prove anything about the real world.  That doesn't make "crypto-law" systems useless though.  It just means you have to have some kind of trusted authority to at least certify what happened in the real world, and then the "crypto-law" system can do the rest.

So using your example, if you have a trusted delivery guy Dave who certifies that he received 1 kg cocaine from Alice and delivered it to Bob, then his signature would unlock terms of the contract as-written (payment or whatever).  He could sign that the shipment was damaged in transit and that would unlock some kind of insurance payment.

In scenario B, Alice would ship 1 kg of gold to Bob. She would have to acquire various licenses. Those authorities already exist and are tied to fabric of the global economy. Obviously, in scenario A - shipment of cocaine from Peru to the USA - this is illegal. What gets shipped in the world is determined by nation states and multi-national cooperations. Which natural resources gets shipped where on what conditions is what geopolitics is mostly about. The recent TPP efforts want to establish a kind of cooperate regime, where cooperations can sue governments. This kind of stuff is infinitely complex, and declaring the world your own jurisdiction is not leading to solutions.

In my example, Dave is not UPS, he's a smuggler that works with drug dealers.  You're the one who brought up the cocaine analogy.

If you want to present one that is legal, go ahead, but it would work pretty much the same way.

[bluemeanie1]

a 'computing environment' is not Turing Complete, but computer languages are.

So?  Ethereum is turing complete then.  Running out of ether is part of the environment, not the language.

this poses the first problem of FALSE ADVERTISING.  These aren't turning complete scripts, it's just a bloated up dispatching environment for financial transactions.  I think they're overestimating how 'cool' this is going to be.  It's not going to be fun to make or to use. 

Yes, this is what I think is the real problem, programs are hard to understand and debug.

In law, sure judges are nondeterministic, but they don't do totally insane stuff, like in a parental custody hearing, they don't set their program counter to the wrong number and
Still, I am not sure if this is a fatal flaw, if anything it might limit scripts to what is easily comprehendable by one programmer.  That's still a lot more flexible than bitcoin's scripting system.

I don't really care how they sandbox their environment, in theory it should be a lot simpler than the JVM.  But maybe it is easier to just use the JVM and lock down everything except the few resources ethereum needs access to.  Either way, the sandbox is not going to be what holds them back, I think those already exist and are a proven concept.

The execution environment for this thing would not be very simple.  Another way to achieve this is to make the Bitcoin kernel modular and have the execution happen in a more privileged level, but those modules must be signed by various 'contract definition developers'.  The contracts then are executed by this module and only the variables need to be defined.    I think this may happen with NXT as it's natively Java and lends itself to this idea.  We have a scripting system already in Bitcoin and it's rarely used.  How many different kinds of contracts do they anticipate? 

I think you're attributing some ideas to 'Ethereum' that are really more general concepts that have been floating around for a while.  I don't see many serious dangers at the outset, seems like some overactive imaginations at work.

but as I mentioned, if they want to make this thing and offer it for free to the public then...



-bm

[bluemeanie1]

just reading this paper,



so they have a whole fee system for the various OPCODEs?

you're telling me this is going to be simple?

-bm

[bluemeanie1]

another tidbit, so theyre retailing these 'ether' credits.  Very similar model to Ripple.

[benjyz]

In my example, Dave is not UPS, he's a smuggler that works with drug dealers.  You're the one who brought up the cocaine analogy.

If you want to present one that is legal, go ahead, but it would work pretty much the same way.

If Alice and Bob transact in the year 2014 there is no "crypto-law" that applies. I used the cocaine example to illustrate that you can't violate laws at will. Alice and Bob would most likely go to jail and that would be the end of the story. In the gold example they would be violating all kinds of laws as well. In most modern capitalist societies you can't open any business whatsoever without a license. And cross-borders transactions are much more complicated. Only the most naive anarchists imaginable believe that you can simply ignore the power regime that embodies what we call law.

[behindtext]

It's like removing seat belts from cars and declaring yourself a genius for making us slightly more comfortable. 

lol!

to your point about it being monolithic: after having my devs collectively spend several man years rebuilding bitcoin from scratch (starting in late feb 2013), even having bitcoind as a reference, it's still not finished. there are myriad new features proposed in ETH that all have to be tested before they are released. i suspect that even with a pile of VC money, say >USD 10M, you would be hard-pressed to get all these features coded, tested and added.

while bitcoin is itself relatively complex code-wise, its fundamental insight is rather simple - "use proof of work as both (1) a distributed timestamp and (2) a minting/reward mechanism". if you take 10 such insights, roll them into one, then try to hack out the code, you will soon be in over your head.

[bluemeanie1]

It's like removing seat belts from cars and declaring yourself a genius for making us slightly more comfortable. 

lol!

to your point about it being monolithic: after having my devs collectively spend several man years rebuilding bitcoin from scratch (starting in late feb 2013), even having bitcoind as a reference, it's still not finished. there are myriad new features proposed in ETH that all have to be tested before they are released. i suspect that even with a pile of VC money, say >USD 10M, you would be hard-pressed to get all these features coded, tested and added.

while bitcoin is itself relatively complex code-wise, its fundamental insight is rather simple - "use proof of work as both (1) a distributed timestamp and (2) a minting/reward mechanism". if you take 10 such insights, roll them into one, then try to hack out the code, you will soon be in over your head.

Did you like my monkey picture?  great movie.

sorry not familiar with your project.  Do you have a link? (if it's NXT see below)  I've been in the Bitcoin-qt code, it's not pretty.

while ethereum has some interesting ideas, if you followed the discussion you would perhaps have different take on it.  It went something like this:



"Damn, this scripting system SUX guys!"

"ya it's got no loops or ifs, wth?"

"y u no have turing completeness?"

"can we make it turing complete?  i have big brain."

2 months later...

"we have (quasi) turing complete scripts!  now we can take over the world!"

"it's also a cloud computing platform!"

"Bitcoin is the next TCP-IP!  to arms!"



Seems to me that the cloud computing people got involved at some point and turned the thing into something it wasn't initially.

So, this project is going to take a lot of resources to do.  Developers want to be PAID, and investors want RETURNS.  It's looking very similar to Ripple at this point.  I raised this point re. Ripple many moons ago, which resulted in much consternation and gnashing of teeth:  "if it's open source, can we fork it and make our own network of XRPs? or Ethers?  Dogethereum?"  The Ripple guys didn't like that.  So if Ethereum is open source, it's possible to do this and the Ethers are only worth exactly the cost of processing power.  Something tells me though that key components of the system will not be open source- Ripple dithered on this point for some time before fully open sourcing everything(I think, it's really impossible to tell).  And basically it comes down to a key point- why is this hashing power a commodity if it serves no real purpose?  not unlike the arguments of gold bugs- gold is valuable because it's valuable, and that thinking seems to prevail at certain times and other times not.

I wrote a number of papers about p2p financial contracts before Ethereum or related projects ever even came out.  Fact is, we can do this fairly simply with something like NXT.  I think NXT is very compelling because it's a complete rewrite and the code is CLEAN java.  Innovations will happen fairly quickly in NXT(amof they ARE happening).  So we can support complex contracts simply by making the kernel modular, having a TYPE field in the TXs and the TX is processed by the module according to type.  They already have a namecoin clone and bitmessage clone in there.  No need for complex turing complete support.  Most importantly the system remains SIMPLE, PEER TO PEER, and accessible to the community.  I don't foresee Ethereum in this role.  One thing I see with this model is that it allows any sort of agreement imaginable, the fact is the users dont need or even WANT such flexibility, people want standardization in order to have fungibility.  Fungibility means marketability, and that means money generation.  Would you sign a contract written by some lawyer with terms you barely even understand?  no you wouldn't - so the number of contract types are countably finite.  We don't really NEED such a complex scripting engine, certainly if it comes at a price - simplicity.

What can we do with such contracts?  We can do financial engineering in a p2p environment.   Here's an example, the EURO that you may be holding in your hand if you live on one side of the atlantic is really a complex of debt between countries.  If any one country defaults on their obligations, then the Euro takes a hit.  It did great for a while up until the Greece incident, and I expect to see more collapse, perhaps a major collapse of epic proportions(im a Euro bear).  So if we implement the things I outlined on http://altchain, we can do things like a Euro, or create a mutual fund, because assets can be CHAINED together.  I collateralize a debt obligation, turn that credit risk into a commodity, group them together, and use this as form of payment tender for a set of e-commerce operations(that is essentially what they did with the Euro).  It's very powerful.  It can be supported in NXT 1) without any need for mining 2) fairly simple modifications save one component and I may publish that soon.  NXT has serious potential IMHO.  I was originally intending on using something called Confidence Chains, but seems pure PoS systems offer similar benefits and they are an accepted idea.

I also like Counterparty btw- but I think their future is questionable due to outside factors.  I was a critic of these block chain piggy-back ideas(eg. color coins) because they require the consent of the core bitcoin developers and in some cases the technologies interfere with the basic Bitcoin features, and I think my first lemma has been shown to be correct.  If something like Counterparty were to become widespread, it would cause a serious problem of bloat in the block chain and they would probably be forced to move to an altchain, some coalition of core devs and long-running node admins would force them off the network. In this case, they have precisely nothing on NXT(which is implementing a native CC feature).  Also some of their ideas are defective in ways that have yet to reveal themselves. 

-bm

[bluemeanie1]

also:  I notice the ethereum.org website has ZERO respect for your privacy.  They put just about every social button imaginable on there.  Clearly this thing is Silly Con Valley through and through.

http://thenextweb.com/facebook/2011/05/02/wikileaks-founder-facebook-is-the-most-appalling-spy-machine-that-has-ever-been-invented/

currently trying to find the ethereum repo, where is it?

-bm

[bluemeanie1]

so they had a link on their site labeled 'Linux Source' :



I clicked it, got a tar file and when I open it I get this?  (they also have a disclaimer on there: https://i.imgur.com/iaeKMCX.png



I dont know what this is.  It's not source code.

-bm

[Gyrsur]

*listen*

[2112]

This thread is both very interesting and very perplexing. Neither Bitcoin nor Ethereum offer a Turing-complete script execution environment.

In case of Bitcoin the limitation is enforced by the scripting language being loop-free and a limit on the length of the program. So the execution cost of the Bitcoin script is (approximately) equal to the length of the program.

In case of Ethereum the limitation is explicitly enforced by a parameter ("gas", probably meaning "petrol") to limit the energy expended on executing the script, because there isn't even approximate relationship between the length of the script and the time and energy it takes to execute it.

When I went to school everyone had to know how to transform a program to its loop-free equivalent and how that relates to the Kolomogorov complexity of the representation of the program (basically unroll all loops and compute both branches of every conditional and beware of the exponential blowout).

Thus I think the thread should be entitled something like "Script with loops or without loops (Bitcoin vs. Ethereum)". Or maybe "To compress the scripts for storage or not: that is the question!". This will better represent the discussion in this thread: it is really about tradeoff between two choices: "use lot of storage and minimally simpler interpreter" and "use much less storage but more complex interpreter".

[gmaxwell]

It isn't really a question of storage or bandwidth, since nodes are free to compress the representation they use to store (especially) or transmit to other compatible nodes. What was interesting to me is how easily/cleanly all of the ethereum examples I've seen unrolled. I'm not quite sure what I'd call it a question of... "size of the simplest serialization"?

I think the more important bit of cognition here is that what Script in a consensus system is actually doing:  99.999% of it is not computation it's _verification_ of a computation someone else performed. And verification is computationally distinct from actually computing, it's fundamentally easier.

Beyond the obvious but less practical connections to non-interactive zero-knoweldge proofs for NP statements, there are some pretty important down to earth ramifications of this.

For example, take the P2SH idea where the PubKey is a script hash and apply it recursively— so a script opcodes and interior hash nodes (you could then think of the script as a merkelized abstract syntax tree). From an implementation perspective, you can think of this as having a OP_choice which takes one serialized script and one scripthash. What you reveal to the network then is not the whole program, but just the parts covered under the taken branches, for the rest you only give their hashes. Other nodes don't care about what happened behind untaken branches, only that the branches which were taken ultimately resulted in acceptance.

Verification time then, is, as before, linear in the size of the signature.

But you've improved privacy— assuming there was enough entropy the untaken branch the public doesn't learn anything about it.

And you've removed much of the blowup in the size of the circuit from the visibility of the verifying nodes.

This kind of tool has been on my must-have-todo-list for any major revisions to Bitcoin script for since something like 2011. While looping might be a reasonable construct (though the complexity of the 'gas' stuff above is not inspiring me with confidence on that front— and complexity is very important here since it directly impacts correctness: alternative implementations of bitcoin already get script wrong over and over again, and no one is yet trying anything fancy like JIT execution of scripts) that may be worth including simply because it makes some scripts have a much more succinct serialization (e.g. consider a script implementing a lamport signature that iterates over all the bits in a hash), I think ideas like the MAST are much more interesting and more likely to be useful...

Looping isn't mutually exclusive with techniques like MAST, but there is a question of finite cognitive bandwidth.  In my opinion the only thing the looping has been really solidly demonstrated to be useful is enabling the not quite accurate and not at all relevant claim of turing completeness for marketing purposes... which itself is not even all that useful except that it enables all kinds of thoroughly confused ideas like thinking the system in question is a competitor to EC2. Misunderstanding which some promoters of some alternative systems decline to correct in what seems to be a rather convent move in terms of encouraging participation in their public investment scheme(s).

[bluemeanie1]

I'm still in the process of reviewing the 'yellow paper',  simple and p2p is NOT what this is likely to be.

He explains near the end of the paper how the scripting is used for a new sort of PoW that is resistant to commodification(the ASIC problem) and he also insinuates that the side-effect of this 'work' is somehow useful for the system(doesnt really show how this is possible).

A set of transactions, pseudo-randomly determined from the nonce value and selected from the last N blocks is taken.  N is large enough and the selection criteria are such that execution of the transactions requires some non-negligible amount of processing by the EVM. Whenever code is executed on the EVM, it is pseudo- randomly (seeded again by the nonce) corrupted before alteration. Corruption could involve switching addresses with other transactions or rotating them through in the state trie (perhaps to the next address with the same order of magnitude of funds), rotating through instructions that have equivalent stack behaviour (e.g. swapping ADD for SUB or GT for EQ), or more destructive techniques such as randomly changing opcodes. This results in a problem that both require generalised computation hardware and is sequentially memory (and perhaps even disk) hard.  Any specialised hardware to perform this task could also be leveraged to speed up (and thus drive down costs) of general Ethereum transaction processing.

does using the British spelling give you some kind of bonus points in the Bitcoin world?

I still tend to think something like NXT offers something simpler and, how should I put this: FUN?  it seems whenever VC gets invovled in these projects they turn it into something altogether incompatible with the ethos of the bitcoin world.  -bm

This thread is both very interesting and very perplexing. Neither Bitcoin nor Ethereum offer a Turing-complete script execution environment.

In case of Bitcoin the limitation is enforced by the scripting language being loop-free and a limit on the length of the program. So the execution cost of the Bitcoin script is (approximately) equal to the length of the program.

In case of Ethereum the limitation is explicitly enforced by a parameter ("gas", probably meaning "petrol") to limit the energy expended on executing the script, because there isn't even approximate relationship between the length of the script and the time and energy it takes to execute it.

When I went to school everyone had to know how to transform a program to its loop-free equivalent and how that relates to the Kolomogorov complexity of the representation of the program (basically unroll all loops and compute both branches of every conditional and beware of the exponential blowout).

Thus I think the thread should be entitled something like "Script with loops or without loops (Bitcoin vs. Ethereum)". Or maybe "To compress the scripts for storage or not: that is the question!". This will better represent the discussion in this thread: it is really about tradeoff between two choices: "use lot of storage and minimally simpler interpreter" and "use much less storage but more complex interpreter".

[bluemeanie1]

This kind of tool has been on my must-have-todo-list for any major revisions to Bitcoin script for since something like 2011. While looping might be a reasonable construct (though the complexity of the 'gas' stuff above is not inspiring me with confidence on that front— and complexity is very important here since it directly impacts correctness: alternative implementations of bitcoin already get script wrong over and over again, and no one is yet trying anything fancy like JIT execution of scripts) that may be worth including simply because it makes some scripts have a much more succinct serialization (e.g. consider a script implementing a lamport signature that iterates over all the bits in a hash), I think ideas like the MAST are much more interesting and more likely to be useful.

IMHO, the biggest drawback to this is complexity.  Building, debugging, supporting and verifying this software is not going to be cheap or fun.  Therefore it must require the involvement of investors to exist.  Can we make a simpler system that supports our needs- most certainly, I outlined it above.

Sometimes Simple Wins.  It just seems very un-Bitcoin.

-bm

[bluemeanie1]

btw- there is an Ethereum repo: https://github.com/ethereum/cpp-ethereum

haven't been able to build it though.  I do recall Ripple releasing a complex and unusable codebase as a show of face to the open source community, so as of yet Im not fully convinced.  They need to recoup *somehow*.  I assume it will be through the sale of these Ethers and maintaining a privilege over key components in the system either through typical ownership means or perhaps patents.

one way they could do this is to have the industrial strength Super Nodes running some enhanced software that is unavailable in open source.  Most of this transaction processing will not be happening on the average P2P Pete's computer.  There will be a tiered society of nodes.

-bm

[gmaxwell]

I think the complexity is manageable under certain conditions.

You have a list of operators, each has a cost. You add up the cost as you verify. Relayed transactions should carry the total cost with them, if the stated cost and the computed cost do not match exactly you reject the transaction and ban the peer.  There is currently an opcode limit in Script which is added this way, except the cost is always one and its not signaled.  A more complex opcode counter is an additional bit of consensus code you could get wrong, true, but it need not be excessively tricky, and if all transactions were carrying their own counts a counting bug would be more easily found in testing. Of course, it's best if the cost is always 1 except for a few special operations (e.g. expensive crypto operations like signature validation).

What I think really creates big challenges is when you expect the total execution time, not including single hotspots like the cryptoops, to be non-trivial. As soon as someone feels they need to diverge from the big-dumb-switch-statement style simulator  (which simply counts one each run through, and some more for certain operations) and start doing fancy template matching or JIT compilation of scripts and it becomes very easy to have hard to detect operation counting corner case bugs. But these sorts of risks can me mitigated by setting sane limits to begin with and insuring that the execution itself will never be such a bottleneck that anyone feels they need to engage in risky optimizations of consensus critical code. Since fancy (and different) execution implementations are risky regardless of things like looping operations, being mindful of complexity and avoiding the need to optimize addresses a wider set of issues than just the operation counting ones.

If things like loops actually worth doing is another question... the things I'd want to use them for in Script today can't be done for unrelated reasons.

[jonald_fyookball]

This kind of tool has been on my must-have-todo-list for any major revisions to Bitcoin script for since something like 2011. While looping might be a reasonable construct (though the complexity of the 'gas' stuff above is not inspiring me with confidence on that front— and complexity is very important here since it directly impacts correctness: alternative implementations of bitcoin already get script wrong over and over again, and no one is yet trying anything fancy like JIT execution of scripts) that may be worth including simply because it makes some scripts have a much more succinct serialization (e.g. consider a script implementing a lamport signature that iterates over all the bits in a hash), I think ideas like the MAST are much more interesting and more likely to be useful.

IMHO, the biggest drawback to this is complexity.  Building, debugging, supporting and verifying this software is not going to be cheap or fun.  Therefore it must require the involvement of investors to exist.  Can we make a simpler system that supports our needs- most certainly, I outlined it above.

Sometimes Simple Wins.  It just seems very un-Bitcoin.

-bm

I don't know much about ethereum.  But from a general member of the bitcoin community, what I'm hearing is: expensive ipo, complexity, not necessarily 100% open source, big promises...

I don't want to come off as a skeptic/cynic/hater on ethereum.  I applaud the innovative spirit
and anyone who creates something.  

[bluemeanie1]

I think you're really trivializing it.  We're talking about the building of a whole new VM emulation machine here.  There's going to have to be thread monitoring, security analysis, etc.  Think of the bottleneck we've got right now in Bitcoin-qt(as a developer of it you may not agree), this will make it 30 times worse.

We're getting away from the Keep It Simple Stupid principle here.  It is possible to have a very useful modular contract system and it doesn't require all this.  Code bloat = support costs = VC involvement = centralisation.  did I spell that right, mates?  Bitcoin is about making money creation accessible to everyone.

-bm

[bluemeanie1]

I don't know much about ethereum.  But from a general member of the bitcoin community, what I'm hearing is: expensive ipo, complexity, not necessarily 100% open source, big promises...

I don't want to come off as a skeptic/cynic/hater on ethereum.  I applaud the innovative spirit
and anyone who creates something.  

there are some intensely thought out ideas in the whitepaper.  That doesn't necessarily mean it's going to be a winner.  Sounds like another Ripple.

"All language designers are arrogant. Goes with the territory... " -Larry Wall

"not necessarily 100% open source"  and if it's anything like Ripple theyre going to do a little dance with this to keep people on the line.  Release some code, code some more privately, release a little here and there, "oh it's coming soon", "that part isn't open source", "did we say that?", etc.  Fact is there's an asymmetry here, the VCs are top down, and the community of potential users is decentralized.  Eventually though it seems Ripple lost the battle.  I heard they might be selling off to ABA or SWIFT.

-bm

[2112]

IMHO, the biggest drawback to this is complexity.  Building, debugging, supporting and verifying this software is not going to be cheap or fun.  Therefore it must require the involvement of investors to exist.  Can we make a simpler system that supports our needs- most certainly, I outlined it above.

Sometimes Simple Wins.  It just seems very un-Bitcoin.

From the purely-computer-science point of view the required interpreters, compilers, theorem-provers, etc. already exist and are well-debugged. They are available in every decent CS library under the very dirty and dusty keyword: Lisp. In one of those books there is a maxim: Those who don't know Lisp are doomed to reinvent it.

Obviously, Lisp doesn't directly plug into the Ethereum implementation. But knowing it would certainly remove lot of "fun" from reinventing the wheels for the Ethereum.

[bluemeanie1]

IMHO, the biggest drawback to this is complexity.  Building, debugging, supporting and verifying this software is not going to be cheap or fun.  Therefore it must require the involvement of investors to exist.  Can we make a simpler system that supports our needs- most certainly, I outlined it above.

Sometimes Simple Wins.  It just seems very un-Bitcoin.

From the purely-computer-science point of view the required interpreters, compilers, theorem-provers, etc. already exist and are well-debugged. They are available in every decent CS library under the very dirty and dusty keyword: Lisp. In one of those books there is a maxim: Those who don't know Lisp are doomed to reinvent it.

Obviously, Lisp doesn't directly plug into the Ethereum implementation. But knowing it would certainly remove lot of "fun" from reinventing the wheels for the Ethereum.

believe it or not I actually know how to use Lex and Yacc!  LOL.

still though, the project has a budget.  They've clearly got a sizeable marketing budget.  Have yet to see any Ethereum marketroids on here, perhaps soon...

-bm

[maaku]

Lisp is actually not ideal here. Some sort of stack-based language with strong static typing would be an optimal choice (see, for example Kitten & Joy). But yes, Ethereum is re-inventing a square wheel here.

[bluemeanie1]

Lisp is actually not ideal here. Some sort of stack-based language with strong static typing would be an optimal choice (see, for example Kitten & Joy). But yes, Ethereum is re-inventing a square wheel here.

maybe a derivative of Forth that doesn't have conditionals or loop statements?  that would make things much more manageable.

-bm

[gmaxwell]

I think you're really trivializing it.  We're talking about the building of a whole new VM emulation machine here.  There's going to have to be thread monitoring, security analysis, etc.

To add loops to script.cpp in the simplest way that achieves the goal in a hardforking change is that you add a "jump opcode" to the big switch statement which, if executing, changes the instruction pointer to a new value within the size of the script and continues execution. The patch is roughly four lines of code. Thats it, no "thread monitoring" (there is already an operation counter that will halt execution if more than 201 steps are taken), no "whole new VM", etc.

Like any change to the consensus code— which is a cryptosystem— It would, of course, require extensive review and to make it efficient you'd want to do as I said with making the nOpCount explicit, turned into a soft-forking change, or not be quite so ugly as a bare loop, etc. so a real implementation would be moderately more complex, but not like you seem to be thinking. Perhaps people in altcoins are proposing far more complicated things, but the currently published ethereum code (the older stuff that has almost nothing to do with their recent whitepapers) is pretty much precisely this "simplest thing" which I described above.

Now all the other things some people are talking about... I mean, some of these pure-whitepaper altcoins advertise features which I believe are impossible while their authors seem to have no concern that they might not be. About that stuff, who knows? But looping? Looping is not _that_ big deal it's also not obviously (to me) all that valuable either. "Meh."

[2112]

For example, take the P2SH idea where the PubKey is a script hash and apply it recursively— so a script opcodes and interior hash nodes (you could then think of the script as a merkelized abstract syntax tree). From an implementation perspective, you can think of this as having a OP_choice which takes one serialized script and one scripthash. What you reveal to the network then is not the whole program, but just the parts covered under the taken branches, for the rest you only give their hashes. Other nodes don't care about what happened behind untaken branches, only that the branches which were taken ultimately resulted in acceptance.

Verification time then, is, as before, linear in the size of the signature.

The way you describe it, I'm not sure I understand you properly. To me it reads somewhat like: a dynamic linker of scripts that uses late binding. Unlike conventional ld.so it does it not by name but by hash of the "_text" section.

Verification is then optimized because the actual linking wasn't really performed.

But getting back couple of pages to the requirements of resistance to DoS attacks (stated by Gavin), you'll still have to design your interpreter to be able to defend itself against somebody implementing a factorial or even an Ackermann function using the mutual recursion of a set of P2SH.

maybe a derivative of Forth that doesn't have conditionals or loop statements?  that would make things much more manageable.

In light of P2SH it would be more like "stack of Forth derivatives" not a "single Forth derivative".

Lisp is actually not ideal here. Some sort of stack-based language with strong static typing would be an optimal choice (see, for example Kitten & Joy). But yes, Ethereum is re-inventing a square wheel here.

I'm not trying to say that Lisp is ideal. But in school I had to maintain both Forth and Lisp interpreters and deal with the bugs and improvement requests. Lisp tends to bunch all the pain at the beginning of the project. Forth projects start easily but continue to bleed you later on.

If you consider a task: "write a program in language X that takes another program in language X and transforms it in a certain way or verifies if it satisfies a certain condition" then for X == Lisp those programs tend to be the shortest or have already been written and debugged. This is the reason why I advocated Lisp for scripting in cryptocurrencies.

[maaku]

But getting back couple of pages to the requirements of resistance to DoS attacks (stated by Gavin), you'll still have to design your interpreter to be able to defend itself against somebody implementing a factorial or even an Ackermann function using the mutual recursion of a set of P2SH.

Why? The interpreter is already protected against this. Once the opcode limit is exeeded, the execution terminates, the transaction is rejected, and the peer is DoS banned.

Lisp is actually not ideal here. Some sort of stack-based language with strong static typing would be an optimal choice (see, for example Kitten & Joy). But yes, Ethereum is re-inventing a square wheel here.

I'm not trying to say that Lisp is ideal. But in school I had to maintain both Forth and Lisp interpreters and deal with the bugs and improvement requests. Lisp tends to bunch all the pain at the beginning of the project. Forth projects start easily but continue to bleed you later on.

If you consider a task: "write a program in language X that takes another program in language X and transforms it in a certain way or verifies if it satisfies a certain condition" then for X == Lisp those programs tend to be the shortest or have already been written and debugged. This is the reason why I advocated Lisp for scripting in cryptocurrencies.

Stack-based does not mean Forth. Just like LISP does not mean Common Lisp.

I suggest you look into Joy, Cat, Kitten, or one of the many other newer generation "concatenative" languages.

[gmaxwell]

Why? The interpreter is already protected against this. Once the opcode limit is exeeded, the execution terminates, the transaction is rejected, and the peer is DoS banned.

Yep. The only issue there that I'm aware of is the issue of priority calculation... but there are straightfoward ways to address that.

[2112]

Why? The interpreter is already protected against this. Once the opcode limit is exeeded, the execution terminates, the transaction is rejected, and the peer is DoS banned.

So in other words in Bitcoin the equivalent of Ethereum's "gas limit" is a single #define (or const int)?

Stack-based does not mean Forth. Just like LISP does not mean Common Lisp.

I suggest you look into Joy, Cat, Kitten, or one of the many other newer generation "concatenative" languages.

Some links and concrete examples of advantages from you would be helpful. There is a lot of newfangled research in front-ends that I admittedly don't follow because I care too much about back-ends and overall quality and breadth of the implementations.

[bluemeanie1]

I think you're really trivializing it.  We're talking about the building of a whole new VM emulation machine here.  There's going to have to be thread monitoring, security analysis, etc.

To add loops to script.cpp in the simplest way that achieves the goal in a hardforking change is that you add a "jump opcode" to the big switch statement which, if executing, changes the instruction pointer to a new value within the size of the script and continues execution. The patch is roughly four lines of code. Thats it, no "thread monitoring" (there is already an operation counter that will halt execution if more than 201 steps are taken), no "whole new VM", etc.

Like any change to the consensus code— which is a cryptosystem— It would, of course, require extensive review and to make it efficient you'd want to do as I said with making the nOpCount explicit, turned into a soft-forking change, or not be quite so ugly as a bare loop, etc. so a real implementation would be moderately more complex, but not like you seem to be thinking. Perhaps people in altcoins are proposing far more complicated things, but the currently published ethereum code (the older stuff that has almost nothing to do with their recent whitepapers) is pretty much precisely this "simplest thing" which I described above.

Now all the other things some people are talking about... I mean, some of these pure-whitepaper altcoins advertise features which I believe are impossible while their authors seem to have no concern that they might not be. About that stuff, who knows? But looping? Looping is not _that_ big deal it's also not obviously (to me) all that valuable either. "Meh."

correct me if I'm wrong here, but it seems like you're suggesting just put a bound on the number of FLOPS, and if you exceed that they you pull some trigger that says 'BAD TX!  Dos PEER!', or some sort of punitive response.

this will give you the basic ability to loop, sure.  But as you say upgrading the script OPCODE set will be a significant deployment effort, so maybe it's best to go whole hog and group it with other desired features.

-bm

[bluemeanie1]

btw - gmaxwell, gave some more thought to your points.  I think you need to read into the latest from Ethereum.  It's a lot more than just expanding the OPCODE set.  They have a random access memory system there and other functions available to the script environment.  It's a LOT more than just expanding the OPCODEs.

I think that doing DAC properly certainly would require something like this and in that sense it's good.  Every corporation has it's own distinct operator agreement thus we would need a way to define those rules on a per DAC basis.  But perhaps there are easier ways to do this?  I wonder if we can re-purpose Java bytecodes?  Not only do you get lots of tools, lots of existing community, lots of existing security and credibility, but the engine runs natively on Android.

so the basic question is do these break anything, and can we ascribe a 'gas' price to each code?  If we can do that, we can get something like a EVM for cheap- that gives up instant compatibility with a lot of platforms.  There are other functions as well that are required.

Also I think there are some holes to some of their premises, certainly has ramifications in the realm of 'but is it Peer to Peer'?  one thing I heard them say is 'you can turn off the script engine...', implying that we leave the heavy lifting up to 'professional nodes' - essentially disenfranchising most p2p network users, which isn't very p2p is it?  there is a solution to this but I won't say for now.

Also it seems that they were trying to achieve a way to have the Work in the PoW be something useful, they intimate this in various parts of the paper, however didn't achieve it.  So for now, it's a beefed up scripting engine for Bitcoin(they also updated the algorithm using something called GHOST).

Also I suspect many parts of this wont be open source.  Expect to see lots of smoke and mirrors here.

-bm

[bluemeanie1]

also an interesting prospect: we already have Java-bytecode specific hardware, not only in Android but there was PicoJava.  http://en.wikipedia.org/wiki/PicoJava

so if Bytecode can be TX scripts, we've got a lot of stuff out of the box.  No need for VC, everything stays 'community'.  There are also open source implementations of the JVM.

-bm

[Mike Hearn]

I really don't think Java bytecodes would be appropriate for a cryptocurrency. It's a tool designed for something entirely different.

Gregory is right, MASTs seem like a very reasonable way to allow larger programs to be built without causing huge blowup inside the chain, and being able to hide parts of the program opens up interesting possibilities for carefully constructed contracts.

Anyway, I'm sure there's a ton of cool stuff we can think of for Script 2.0 (I'd quite like some kind of reflection abilities), but we barely exploit Script 1.0 today! It seems kind of weak to be running ahead of ourselves here. The right place to invest at the moment IMHO is other parts of the toolchain, to make it really easy to build slick usable GUI apps that can manipulate contracts. That's what I've been working on with bitcoinj + the wallet-template app. Good cross platform APIs + lots of documentation + reusable templates to speed up development all give bigger wins right now that a more powerful scripting language, IMO.

[bluemeanie1]

Well to clarify, Java might be USED for a specific purpose today, but the original intention was to have little bits of executable code flying around the internet that are dynamically dispatched and executed.  This vision never really seemed to happen and instead we got a enhanced C("write once run anywhere") vision.

the fact is that Java bytecodes are very similar to what Ethereum has.  It's officially a "C like language" ... sound familiar?  Perhaps we could use a subset of the bytecodes?  I'm just trying to think of ways to get this functionality for cheap.  You can already see the ivory tower being constructed over at Ethereum.

So you could create a custom compilation environment that prohibits access to most of the System classes, and instead you get a very small feature set of functions(store value, check balance, etc.).  And then you get what Ethereum gives you, plus it's supported already on millions of devices and just about every computer.  They've got a couple of other things in there that would also need to be added- some complex of crypto functions on the opcodes.  I also suspect they've patented some of these ideas.

-bm

[Mike Hearn]

I'm a big fan of the idea of revisiting Java mobile code at some point as there are now JVMs that are possibly simple enough to be secure with a heavily restricted class library. But not for cryptocurrency. It's just not needed and the format evolves faster than what we really need. Also it's needlessly verbose and hard to compile for no real good reasons. You'd do it quite differently if you redesigned it from scratch.

IMO evolving Script slowly and carefully is a way better path than trying to reuse Java.

[bluemeanie1]

have you looked at Ethereum?   It's certainly not as complex as Java, but it's coming close and certainly as things progress there it will get more complex.  People have made specialize byte-code compilers before.  It would be interesting if someone could do a comparison of EVM opcodes and JVM opcodes.  Again the goal here is - how can we get this cheap?

I do somewhat agree, we don't need all this- but a new VM execution environment?  that just seems like a problem that was invented specifically so someone could solve it and make money with it.

-bm

[Mike Hearn]

Well I'm not sure Ethereum should have such a complex VM either :-)

As an example, JVM bytecodes are extremely verbose because it maps one class to one file and then uses strings to link them together. Dalvik solves that. Also JVM bytecode is for a stack machine that then has to be compiled down to register allocation on the fly at huge cost and complexity. You could do register allocation up front for a bunch of different register counts and simply the VM considerably. Dalvik also does this.

[bluemeanie1]

here's an example of an Ethereum script:

if !contract.storage[1000]:
    contract.storage[1000] = msg.sender
    contract.storage[1002] = msg.value
    contract.storage[1003] = msg.data[0]
    contract.storage[1004] = msg.data[1]
    return(1)
elif !contract.storage[1001]:
    ethvalue = contract.storage[1002]
    if msg.value >= ethvalue:
        contract.storage[1001] = msg.sender
    datasource = contract.storage[1003]
    dataindex = contract.storage[1004]
    othervalue = ethvalue * msg(datasource,0,tx.gas-100,[dataindex],1)
    contract.storage[1005] = othervalue
    contract.storage[1006] = block.timestamp + 86400
    return([2,othervalue],2)
else:
    datasource = contract.storage[1003]
    dataindex = contract.storage[1004]
    othervalue = contract.storage[1005]
    ethvalue = othervalue / msg(dataindex,0,tx.gas-100,[datasource],1)
    if ethvalue >= contract.balance:
        send(contract.storage[1000],contract.balance,tx.gas-100)
        return(3)
    elif block.timestamp > contract.storage[1006]:
        send(contract.storage[1001],contract.balance - ethvalue,tx.gas-100)
        send(contract.storage[1000],ethvalue,tx.gas-100)
        return(4)
    else:
        return(5)

so basically you need to compute this script on the current 'global state' and hash it to verify the transactions(as I understand it).  It's certainly coming close to Java in it's complexity.  I imagine that it's optimized for object-code size and perhaps some other features.  Again what I think they might be ignoring is what it's going to take to support this and community acceptance.  Ripple had some good, 'correct' ideas but the community didn't like it.

-bm

[bluemeanie1]

Well I'm not sure Ethereum should have such a complex VM either :-)

As an example, JVM bytecodes are extremely verbose because it maps one class to one file and then uses strings to link them together. Dalvik solves that. Also JVM bytecode is for a stack machine that then has to be compiled down to register allocation on the fly at huge cost and complexity. You could do register allocation up front for a bunch of different register counts and simply the VM considerably. Dalvik also does this.

it's really much more than just a money system.  There's people on the forums making all sorts of suggestions: "Lets make a Distributed Wikipedia!".

I think it's really just an impractical use of this basic concept of a block chain.  I think they're getting carried away.  They seem to ignore the fact that in order for this to be truly p2p, every single node must execute that script and perhaps millions(or billions of them).  Of course this isn't a problem if you plan to sell the high end gear that makes this possible.  I remember for instance when color coins was at the peak of public interest there was an IBM guy hovering around, presumably he saw a market for IBM hardware there.

-bm

[bluemeanie1]

It's not unlike the Bitmessage mentality.  Bitmessage doesn't really give you much(or any) security over that of PGP, Enigmail and Anonymizers... but the devs don't want to hear it.  It's like when people discover how a block chain works they want to use it for everything, and the fact is we've got tools for secure messaging and they've been around for a while. 

There's a old saying in tech circles: "when you learn how to use a hammer, everything becomes a nail.".

-bm

[gmaxwell]

btw - gmaxwell, gave some more thought to your points.  I think you need to read into the latest from Ethereum.  It's a lot more than just expanding the OPCODE set.  They have a random access memory system there and other functions available to the script environment.  It's a LOT more than just expanding the OPCODEs.

I know they have, I was just responding to their form of "turing completeness" and not the other things. I guess we were talking past each other, sorry for that.

As far as the other things go people often don't realize that some of these mechanisms are not actually necessary and can be achieved in other ways. E.g. you don't need global "random access memory" if scripts can introspect their transactions enough to ensure that their final state is passed on in outputs— E.g. "exactly one of the outputs must be a copy of this script, plus the updated state".  Encapsulating state in this way creates good architectural isolation and makes it very easy to correctly implement reorganization logic and understand what will happen under reorganization. Obviously preserving the architecture matters a lot when you're talking about enhancements to an existing system, but the trickiness of reorganization means that I'd probably still adopt this kind of state management approach even in a totally greenfield environment. I am far from convinced that many of the people working on altcoins are even dimly aware of all the bullets Bitcoin has dodged in its design, even the ones which have been pretty widely discussed.

Likewise, any "non-deterministic" inputs to a script (such as "locktime must be at least this high") can be made deterministic by just including the input directly in the ScriptSig and having part of the criteria in the ScriptPubKey verify them.

but we barely exploit Script 1.0 today!

Exactly. I am probably more enthused about the possibilities than most, but intellectual honesty keeps me from arguing for a bunch of new features in light of the reality that what we have today is hardly used at all even though it very much could be from the perspective of the technology itself. No matter how sexy I think more expressive power might be, I can't argue for it with a straight face when we're not using what we have.  It _might_ be the case that there is an expressiveness gap where we're not quite expressive enough to get more use, but I'm seldom hearing "I'd like to do X but can't but for missing Y." and often when I do hear that we're able to find a way around it (e.g. the lottery transactions). As a result I do think that any script enhancement needs to come along with an actual application (even if its only command-line geek grade) so there is some evidence that it would get used, in addition to checking all the boxes

I have a personal Script-2.0 laundry list that I've maintained for some time (but not currently published because I'm sick and tired of white-paper only altcoins taking ideas I've invented or promoted and selling them for a profit and not even implementing them!). Something like 1/3rd of the document describes contracts which tie into the features I suggest and which I think must be implemented to prove the design wisdom of an attempted implementation of the features.

it's really much more than just a money system.  There's people on the forums making all sorts of suggestions: "Lets make a Distributed Wikipedia!".

That one amuses me, one of  biggest reason for my interest and eventual involvement in Bitcoin is that almost a decade ago some people argued that the Wikimedia Foundation shouldn't be formed because Wikipedia should just be decentralized, not only claiming it was possible but that it could be trivially implemented. I wrote one of my trademark rants on the physical impossibility of true decenteralized consensus, as consensus is a necessary component of replicating the functionality of a singular resource as opposed to a grab-bag of assorted repositories. Bitcoin challenged that view but didn't change was was possible— my views weren't overtly wrong, Bitcoin just works under different assumptions which I hadn't considered at the time... primarily the ability to use hashcash and in-system compensation to create an incentive alignment and to force participants to make exclusive choices.  It's far from clear, and— in fact, now seems unlikely— that these different assumptions are anywhere near as strong as they are for other applications as they are for Bitcoin, and the verdict is even still out on if Bitcoin's properties are even good enough for Bitcoin in the long run.

A lot of the things I've heard that crowd talk about don't make a lot of sense to me... e.g. implementing a freestanding rent extractor which does nothing you couldn't just do locally— which is a pretty common event because in that execution environment the agent can't keep any secrets from the public. It's the sort of argument that sounds good until someone not seeped in the excitement steps up and says "The Russians used a pencil.". Some of it would require the network to perform IO which you can't safely do in a consensus environment (except via trusted parties— and in which case you could just have them compute for you too, and thus keep your program private), and even the things which aren't impossible run into the pointlessness problems that some of the verifiable computing stuff does: e.g. you can ask something else to compute for you, but with millionfold overhead and a loss of privacy that makes it pretty pointless to do in almost any conceivable circumstance.

Though I'm still glad people are excited about some novel ideas.  I hope that excitement lasts once people realize that that they're not going to make it rich off of them … I hope that making the world a freer, safer, and more interesting place is enough of a motivation to retain some of that excitement. Although 15 year long winter of the cipherpunks movement suggests that some cynicism here is justified. Is all the new interest because people hadn't been exposed to these ideas— they'd never stumbled into tools like rpow or mixmaster years ago— or is it mostly because they think it's something they can cash in on? Not that I begrudge people making money, and a few will— no doubt— make a bunch, but most will not, and if its a primarily a profit motive sustaining this interest then I expect we'll have a return to the low level of progress that other tools in this space have had since the excitement in the early 90s.

[bluemeanie1]

"Real programmers can write assembly code in any language."

-Larry Wall

[telepatheic]

Anyway, I'm sure there's a ton of cool stuff we can think of for Script 2.0 (I'd quite like some kind of reflection abilities), but we barely exploit Script 1.0 today! It seems kind of weak to be running ahead of ourselves here.

I'm interested to hear people's thought on what can be done with the current scripting system. I've been messing around with it and it seems that there are only a few uses:

- More complex multisignature (where you set requirements on specific sets of people that can sign transactions using conditions e.g. of 5 possible keys require either (( key a or key b ) and c ) or ( key b and key d and key e )

- Proof of work (you can require the spender to do some hashing in order to spend the coins see http://blockexplorer.com/testnet/tx/44b9f9ff28fbfc33d4824729b2ec6f2929588faef81717e194fd7fe2a6b5d384 )

- Require the spender to solve simple maths puzzles (see http://blockexplorer.com/testnet/tx/de333be5247e7d9cfe564ffbd33e3c48dfaa0a818304347c6ecec51b57aef4e7 )

- Require the spender to know some additional piece of information (see http://blockexplorer.com/testnet/tx/c5c6b5582ff9d572296e7af3d6821f103f88386ee9f77ffae78c2db45816b80e )

- Any combination of the above.

The idea of solving maths puzzles is rather stupid as this can be reduced to a case of requiring the spender to know some additional piece of information where the puzzle itself is communicated out of band and this too can be reduced to a case where the solution forms a part of the private key required to spend the transaction. Alice knows private key A which has public key a. Bob knows the solution to a problem B which has public key b. Bob sends the funds to a+b and Alice must solve the puzzle to find B to find the required private key A+B.

So scripting only really allows proof of work and complex multi-signatures.

Can you suggest other uses?

[bluemeanie1]

it's really much more than just a money system.  There's people on the forums making all sorts of suggestions: "Lets make a Distributed Wikipedia!".

That one amuses me, one of  biggest reason for my interest and eventual involvement in Bitcoin is that almost a decade ago some people argued that the Wikimedia Foundation shouldn't be formed because Wikipedia should just be decentralized, not only claiming it was possible but that it could be trivially implemented. I wrote one of my trademark rants on the physical impossibility of true decenteralized consensus, as consensus is a necessary component of replicating the functionality of a singular resource as opposed to a grab-bag of assorted repositories. Bitcoin challenged that view but didn't change was was possible— my views weren't overtly wrong, Bitcoin just works under different assumptions which I hadn't considered at the time... primarily the ability to use hashcash and in-system compensation to create an incentive alignment and to force participants to make exclusive choices.  It's far from clear, and— in fact, now seems unlikely— that these different assumptions are anywhere near as strong as they are for other applications as they are for Bitcoin, and the verdict is even still out on if Bitcoin's properties are even good enough for Bitcoin in the long run.

A lot of the things I've heard that crowd talk about don't make a lot of sense to me... e.g. implementing a freestanding rent extractor which does nothing you couldn't just do locally— which is a pretty common event because in that execution environment the agent can't keep any secrets from the public. It's the sort of argument that sounds good until someone not seeped in the excitement steps up and says "The Russians used a pencil."

that certainly reflects my feeling about it.  Have you ever seen the episode of South Park about San Francisco?  I get the feeling that's what's going on here.

. Some of it would require the network to perform IO which you can't safely do in a consensus environment (except via trusted parties— and in which case you could just have them compute for you too, and thus keep your program private), and even the things which aren't impossible run into the pointlessness problems that some of the verifiable computing stuff does: e.g. you can ask something else to compute for you, but with millionfold overhead and a loss of privacy that makes it pretty pointless to do in almost any conceivable circumstance.

absolutely.  Consider that the BTC block chain size is thought to be problematic going forward, can you imagine what this thing is going to look like?  And they contend that it will be manageable, but something tells me they assume it will not and of course, who are you going to buy a 'solution' to this problem from?  Of course it will need all sorts of expensive management units and dedicated hardware and what not, and wait... this is peer-to-peer?  They have already admitted that most nodes will not be computing the entire chain.  I would guess only a small fraction of heavily built out nodes could possibly manage this computation.

Though I'm still glad people are excited about some novel ideas.  I hope that excitement lasts once people realize that that they're not going to make it rich off of them … I hope that making the world a freer, safer, and more interesting place is enough of a motivation to retain some of that excitement. Although 15 year long winter of the cipherpunks movement suggests that some cynicism here is justified.

and when did that winter begin?  precisely with the advent of Wired magazine(who featured the Cypherpunks on one of their early issues) and the Silicon Valley VC Tech Complex who discovered that they can do the job of our spying agencies by selling us neato tracking devices that have Flappy Bird on them.  It's fairly obvious this crowd is behind Ethereum.  Of course no one seems to know where the money is coming from and the thing is populated with the typical fresh faced tech kiddies whom you would never suspect are doing anything but improving the world for the greater good.

Is all the new interest because people hadn't been exposed to these ideas— they'd never stumbled into tools like rpow or mixmaster years ago— or is it mostly because they think it's something they can cash in on? Not that I begrudge people making money, and a few will— no doubt— make a bunch, but most will not, and if its a primarily a profit motive sustaining this interest then I expect we'll have a return to the low level of progress that other tools in this space have had since the excitement in the early 90s.

I think it's a combination of opportunism and naiveté.  Sometimes I think they generate this excitement precisely to distract from those who are doing important work- and they Cypherpunks WERE important, they ARE important... but the allure of material gain seems to take precedence over idealism.

-bm

[Brangdon]

I wrote a number of papers about p2p financial contracts before Ethereum or related projects ever even came out.  Fact is, we can do this fairly simply with something like NXT.  I think NXT is very compelling because it's a complete rewrite and the code is CLEAN java.  Innovations will happen fairly quickly in NXT(amof they ARE happening).  So we can support complex contracts simply by making the kernel modular, having a TYPE field in the TXs and the TX is processed by the module according to type.  They already have a namecoin clone and bitmessage clone in there.  No need for complex turing complete support.  Most importantly the system remains SIMPLE, PEER TO PEER, and accessible to the community.

That's a relatively centralised approach, though, in that the NXT core developers have to agree what the TYPE field means, and approve the code that goes in to support it. I imagine a goal of Ethereum is to allow permissionless innovation. They don't want arbitrary limits on scripts and they don't want application developers to have to get permission from anyone before they deploy. It's similar to the Bitcoin vision where you don't have to get permission from a credit card company before accepting payments.

[bluemeanie1]

I wrote a number of papers about p2p financial contracts before Ethereum or related projects ever even came out.  Fact is, we can do this fairly simply with something like NXT.  I think NXT is very compelling because it's a complete rewrite and the code is CLEAN java.  Innovations will happen fairly quickly in NXT(amof they ARE happening).  So we can support complex contracts simply by making the kernel modular, having a TYPE field in the TXs and the TX is processed by the module according to type.  They already have a namecoin clone and bitmessage clone in there.  No need for complex turing complete support.  Most importantly the system remains SIMPLE, PEER TO PEER, and accessible to the community.

That's a relatively centralised approach, though, in that the NXT core developers have to agree what the TYPE field means, and approve the code that goes in to support it. I imagine a goal of Ethereum is to allow permissionless innovation. They don't want arbitrary limits on scripts and they don't want application developers to have to get permission from anyone before they deploy. It's similar to the Bitcoin vision where you don't have to get permission from a credit card company before accepting payments.

true points, but consider that the TYPE could itself be very flexible while we still have the ability to support more simplistic contracts without all this dross.  We have the ability to install a scripting engine.

consider that, under the proposed model of ethereum,

1) every node will have to process every single transaction and event of every DAC, currency ledger, decentralized wikipedia article, or what have you.  Just consider what this ledger actually looks like in their vision.

2) every transaction could take up any amount of processing power according to the amount of Gas spent.  Now keep in mind the economic model makes no sense, I pay to have my big transaction live on the network, but me- mr. Node admin dont necessarily get paid to validate that huge transaction.  They've changed the economic model by introducing limitless scripts(quasi turing complete) but they still have not found a model in which this makes sense.  It might appear nifty at the outset, but eventually this ledger will get bigger and bigger and most nodes will just go SPV, and this event wouldnt necessarily pose any problems for Ethereum Inc., actually it's better for them.  TL; DR  Ethereum can't be P2P.

3) all these transactions are PUBLIC.  Now who would want that??  see my last comment.

-bm

[bluemeanie1]

btw- someone just sent me this, it's the NXT Transaction Engine Spec:  http://ciyam.org/nxt/nxt_auto.html

note: rumor has it the author of this document has 'gone rouge' and is not involved with NXT anymore.  Is he working for Ethereum?

-bm

[bluemeanie1]

an example of the sort of 'solutions' to the problem Ethereum ideas pose:

I think ultimately what you will see is more pooling. You can sign up to a pool where you simply contribute CPU shares for portions of the work that get farmed to you, which is not the entire work of the block, but just the execution of say 10 contract messages in that block. Or you contribute storage, which is not ALL the storage, but a subset which the pool operator can request from you as they need it. These sorts of schemes still erode the decentralization, but they are a step forward from the status quo.

again some of these suppositions do not account for all the issues of processing this absolutely enormous 'global state' (like a UTXO but much more frightening).  If we do need to distribute this over many machines, absolutely at this point in time not only do we lack the software for doing so- we lack the THEORY for managing this task.  These guys are just in outer space here.

-bm

[gmaxwell]

These sorts of schemes still erode the decentralization, but they are a step forward from the status quo.

I can't figure out how that was supposed to be an improvement to the "status quo" (presumably in Bitcoin). Truly decentralized mining works fine today though its not currently very popular, that text is talking about a world where it isn't economically possible.

Moreover, even accepting the motivation the solution sounds like a handwave in other ways as well: Pooling allows work delegation because of the huge ratio of work for solving vs verifying.  Script work is all verification, barring complex and insanely expensive things like proofs of computation the best I think you can do there is farm the work out to N miners and ask for the hash of the execution transcript, and if there are disagreements verify for yourself... but even that fails if the N miners are sibyls and it has N fold overhead. What am I missing here?

[bluemeanie1]

These sorts of schemes still erode the decentralization, but they are a step forward from the status quo.

I can't figure out how that was supposed to be an improvement to the "status quo" (presumably in Bitcoin). Truly decentralized mining works fine today though its not currently very popular, that text is talking about a world where it isn't economically possible.

Moreover, even accepting the motivation the solution sounds like a handwave in other ways as well: Pooling allows work delegation because of the huge ratio of work for solving vs verifying.  Script work is all verification, barring complex and insanely expensive things like proofs of computation the best I think you can do there is farm the work out to N miners and ask for the hash of the execution transcript, and if there are disagreements verify for yourself... but even that fails if the N miners are sibyls and it has N fold overhead. What am I missing here?

they do employ something like a 'hash of the execution transcript', the whitepaper mentions the hashing of the global state.  The simple fact is they don't have any of these things worked out, and either they've got people excited about a quasi-p2p contract engine or those people are just 'paid picketer' types(I suspect some of that is going on).

most of the meat of this thing is going to be figuring out how to somehow involve and incentivize this massive distributed computation. They act as though this problem is solved, and perhaps it is- but not in a p2p way.  I can't even see how on earth people are going to want to maintain this massive block chain on their own PCs.  It's simply not clear at all how they make it feasible and attractive for people to download this chain and verify blocks, it's quite a different economic function from Bitcoin because in Bitcoin, the work is the hashing.  Here the work is the actual transaction verification itself(presumably in addition to the SHA256).

They simultaneously talk about how great and powerful these features are while trivializing the huge distributed computation problems they imply.

-bm

[Brangdon]

consider that, under the proposed model of ethereum,

Yes, when I first read their stuff I found it terrifying. Each address is like a little computer, with local state, exchanging messages with other addresses, all within the block-chain. Nice academically, but seeming like a horrendously inefficient way to do computation. It made me think of trying to compute with 1-dimensional finite state automata, or Conway's Game of Life. I get the appeal but I don't think it's practical.

[bluemeanie1]

consider that, under the proposed model of ethereum,

Yes, when I first read their stuff I found it terrifying. Each address is like a little computer, with local state, exchanging messages with other addresses, all within the block-chain. Nice academically, but seeming like a horrendously inefficient way to do computation. It made me think of trying to compute with 1-dimensional finite state automata, or Conway's Game of Life. I get the appeal but I don't think it's practical.

ya it does somewhat conjure up the Wolfram works doesn't it?

the basic problem is this: entropy(σ-state) = O(∞). 

where σ-state is Ethereum's expanded UTXO concept.  in english: the application state has infinite information in it.  In addition they lack a useful economic model that offers an incentive for nodes to either store, manage and compute sigma.  They've got their wires crossed concerning PoW concepts and the work it takes to compute σ.  In bitcoin entropy(σ-state) = O(num accounts) (just eyeballing that).  Although gmaxwell has made some progress in understanding how this works: https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas



-bm

[go1111111]

Gregory is right, MASTs seem like a very reasonable way to allow larger programs to be built without causing huge blowup inside the chain, and being able to hide parts of the program opens up interesting possibilities for carefully constructed contracts.

Can someone define what MAST means in this context, for the benefit of the newbs? It's a tough term to search for.

[mmeijeri]

Merkelised Abstract Syntax Tree. Its root hash gives a summary of the whole AST, just as with a Merkle root in a block. This allows you to give the part of the script that is actually executed when spending, without having to list the whole possibly very lengthy script while still proving you've only used branches from the original AST.

[UnunoctiumTesticles]

Hope it is not too late to get some feedback on my thoughts.

My take away from the upthread is consistent with my own analysis—centralization of pools is probably positively correlated with required computation (above some threshold).

The Ethereum applications seem important and reasonably decentralized.

https://github.com/ethereum/wiki/wiki/White-Paper#applications

So pray tell me why it isn't superior to have merge-mined chains for new contract types (as we think of them) and optimize those chains rather than a generalized VM on one block chain?

Advantages are:

• Centralization is granular per contract type.
• Mining participation is optional, thus chains can compete instead of the swallowing the universe entropy(state) = O(∞)
• Failure modes are more contained.
• Incremental development and optimization.
• Market-based instead of top-down metrics (e.g. Ethereum's gas fees) as chains compete to reward miners.

Etc.

Maybe we need to make the process of starting and publicizing a merge-mined chain easier? Do we need an app store of merged-mined chains?

P.S. Apologies in advance if one post can evaporate a $36 million market cap.

Edit: even if you did want a generalized VM for those contracts which don't have enough economy-of-scale to be their own merge-mined chain, you could make that chain merged-mined. You could make variants and let the market decide which one is the winner. Perhaps Ethereum should do this, if they are not satisfied with the Bitcoin mining structure.

[JorgeStolfi]

If CPU usage to verify a transaction is NOT related to the transaction size, then you open yourself up to denial-of-service attacks. Like:

Create an Ethereum transaction with a (huge!) fee that will pay for 60 seconds of CPU execution time.
... but craft it so execution takes 61 seconds (or, heck, make it an infinite loop, maybe you'll tickle a bug in the execution termination code).

Now broadcast it.  It will be rejected for insufficient fee, but only after peers have wasted 60 seconds of CPU time. And if the transaction is rejected, the attacker won't pay the fee.

Sorry if this has been addressed before:

In Ethereum (or in Bitcoin with Turing-complete scripts), could this idea be used by a miner to delay competing miners, rather than sabotage the network with a DDOS-type attack?

Namely, the malicious miner creates a transaction with a script that takes a long time to complete, and a fee that forces it to be included in the next block; and computes the script's outcome before issuing it.  Would that give him an edge over other miners?   

[JackH]

Seems like Pieter Wuille's Tree Signatures does alot of what we wanted without relying on Turing complete scripts like Ethereum. https://blockstream.com/2015/08/24/treesignatures/

I still dont get the turing complete argument in the Etheretum project and it seems like a waste of computing resources to go down the route they propose.

[thacypha]

How come you guys did not know BitCoin was Turing complete?

[Gyrsur]

How come you guys did not know BitCoin was Turing complete?

https://bitcoin.stackexchange.com/questions/25427/the-bitcoin-scripting-system-is-purposefully-not-turing-complete-why