reddit discussion : http://www.reddit.com/r/Bitcoin/comments/1ylvcp/the_ethereum_scam/

cobracobra Member Posts: 18
Post edited by StephanTual on

Comments

  • kershykershy Member Posts: 46
    understandable skepticism and justified fear that people could lose their money.... but this is not about selling a finished product. It's about crowdfunding a great effort which will be 100% transparent and where the investors may end up with something valuable. I have not seen any promises of getting a guaranteed return on your investment and that is not what this is about.
  • StephanTualStephanTual London, EnglandMember, Moderator Posts: 1,282 mod
    Like any other project, due diligence is not only required, it's imperative. Skepticism is healthy and questions around 'is turing completeness dangerous' , 'who are the founders', 'what initiatives will you support' are not only welcomed, they are encouraged.

    On the other hand, calling any project 'scam' and 'vaporware' with no backing argument is not only juvenile, it borders on libel. The fact that the account was deleted shortly after posting tells me there's more to that post that meet the eye, but hey, what can you do :)
  • FreddyFenderFreddyFender Member Posts: 39
    edited February 2014
    I just read through the entire thread and found that the tone was hopeful and supportive among most recognizable redditors. The Altcoin Fanboys are trying hard to be influential with policy, startup and mining specifications, but that is expected. It is very humorous to see self-proclaimed experts get almost every fact wrong and then be brought down to "well, it needs to be explained better!" Vitalik et. al. are doing a fine job explaining it - we just need more help in the 'understanding it' phase. Some Bitcoin proponents are using a wait and see attitude for now, but I am impressed with the concept, affiliation, potential, and degree to which we see commitment to the project.
  • StephanTualStephanTual London, EnglandMember, Moderator Posts: 1,282 mod
  • wemeetagainwemeetagain Member Posts: 30
    I've been having a bit of dialogue with him via reddit PM. Here's our interactions thus far, posted for consideration and open dialogue:

    hi j,

    I just wanted to address the value of using a 'turing complete' language for the contract scripts.

    Without using a turing complete scripting language, you end up needing a separate blockchain for almost every different type of decentralized application.

    eg: If you want a distributed DNS, you need a Namecoin. If you want a distributed DNS that uses different parameters, you need a Namecoin2. You want multiple different addresses to be able to edit the DNS entry? thats Namecoin3. (maybe you're even able to reuse part of the network, but you have to fork a new project each time)

    Having a turing complete language allows for the flexability to build any type of app logic on top of a single blockchain. That means you end up having a more secure network.

    So each contract can be as simple of complex as it wants to be (within the memory + economic limits) and each one represents its own shared, globally consistant state. Each contract can represent a wholly different application/database/purpose, relevant only to the users of the application that builds off of it, as well as optionally build off one another by reading the state of other contracts or even by making transactions(altering the state) of other contracts.

    One initial 'concrete' idea I have building off what's possible is that of a decentralized means of restricted-access p2p session initialization for WebRTC. One contract is a key-value storage linking ethereum addresses to public keys. Another is a nameserver/key-value storage that stores an ethereum address as the key and WebRTC session metadata encrypted with various other public keys as a list as the value. Perhaps there could even be a third contract that linked an ethereum address to a list of other ethereum addresses or public keys. Of course you need logic to be able to only allow the address holder to edit his key storage. And logic to delete metadata from keys for which you no longer want to provide the session data.

    What you get from all this? A completely decentralized mechanism for letting 'friends' connect with mutual 'friends' via WebRTC.

    How would it work? So the first contract lets a user link a public key to an 'identity'. When a user would set up an account, they'd send a transaction to the contract with a public key (or keys) as data alongside the transaction. The contract logic would store the keys under that address (so that friends can store data that is only visible to that user).

    The second contract stores the signalling information needed to connect via WebRTC. Whenever the user went online/had their networking info change, they would send a transaction with the necessary session metadata needed to connect to them via WebRTC. The contract logic would lookup the keys from the third contract and store the encrypted forms of the session metadata under that address.

    The third contract stored the 'friend list' of the user. The user could send a transaction signalling to add or delete addresses. The contract logic would add or delete addresses from that address' storage space.

    So after the user has updated his session metadata, the user can search through the friend list of the third contract and lookup the session metadata on the second contract for each one found. Since the user owns the private key, the one of the metadatas from each entry can be decrypted and the user can then attempt to connect to each one.

    Of course, once connected, you'd want to do some sort of handshake with the keys to make sure the connection is legit, but there you have it.

    The first and third contracts can be reused for other applications, as well.

    So to reiterate, the benefit of having a turing complete scripting language is to make the contracts as flexible as possible, reuse as much code as possible, through looking at other contract state, and maintain all of it on a single network that doesn't have to be forked for every new feature.

    Peace.
    ----
    Thanks for taking the time to write this up. I have a different perspective on this. I'm mobile right now but I'll follow up in more detail tomorrow.

    (later)
    My concern about a general purpose programming language to implement various features primarily revolves around complexity. The complexity will invariably lead to bugs in the script code and these bugs will then becom embedded into a blockchain and be irreversible.

    Your concern is that protocol changes will inevitably lead to 'forks' of a blockchain.

    If we decided that the goal was to develop a cryptocurrency in such a way that the protocol could easily be revised for the entire ecosystem, that would be a better solution. I would rather that specific well defined protocols be used to implement desired features.

    Even if you agree that a general purpose virtual machine has value and merit, why would you invent a new one? This is pretty much a solved problem anyway. There are numerous open source VM based scripting languages which have all kinds of security built into them. Why invent a new one? It can't simply be because you want cryptographic specific features, because all existing scripting languages are easily extensible.
    ----
    You only need ethereum for situations where you need arbitrary, but verifiable logic to manipulate the internal state of a globally consistant, trustless/decentralized database. In bitcoin terms, we've moved the script logic from a transaction to a 'contract'.

    Bitcoin can to a certain extent do more complicated functions, but it was not built for that purpose. It focuses on features to simply move bitcoins around type of logic.

    It looks like Ethereum is trying to solve a different goal though. This is simply trying to build a network that can act with verifiable, manipulable state that solves the byzantine-generals problem Proof-of-Work-style. It builds off of the original idea of bitcoin's transaction system of simply sending a value from one address to another. This allowed the world to believe that X 'address' owns N 'bitcoins'.

    With ethereum, now what the world can believe entire stored state of a contract that can be manipulated according to the rules programmed in it, with similar assurities to bitcoin. (This solves problems that are hard to solve in a decentralized way otherwise.)

    To address your concern about the complexity possible leading to bugs becoming irreversible, I definitely agree with you. I imagine that there will be many buggy contracts, especially at the beginning. Ethereum is a playground, allowing anything within its storage/language limits. I tend to think its not an issue though, because I think it will be resolved by formation of common program design patterns/libraries/contracts.

    The developers have also mentioned developing reference implementations of useful contracts.

    > If we decided that the goal was to develop a cryptocurrency in such a way that the protocol could easily be revised for the entire ecosystem, that would be a better solution.

    I agree. The ecosystem can also be thought of as the users of a contract, though.

    So the way I see it, the 'protocol' that ends up being 'defined and revised' is the interlocking of modularized contracts (or single contracts) for different uses. The systems can be ever expanded by adding new, improved, different featured, contracts. However brittle these 'programs' are, they still solve a problem only solveable using ethereum or the like. Ethereum is simply the sandbox to play within.

    So yes, there are already general purpose virtual machines already, but none of the ones I know can be run trustlessly, like bitcoin.

    Now, will it actually be useful? Will the fees be so high that only miniscule, trivial contracts can be run economically? That is really the question I have right now. And the answer is.. lets see, lets experiment.
  • wemeetagainwemeetagain Member Posts: 30
    ----
    Thanks for the detailed response. Since making my original post I have decided to sync and build the source code, and see if there is something I can do to contribute constructively.

    What I'm learning right away is a difference between what the media hype has been about the project and the actual implementation. The media hype goes on to some lengths about an open ended Turing complete virtual machine but the actual implementation is a highly customized and limited implementation of a very restrictive expression of code possibilities.

    This is quite a different message I think. And I'm not being critical of that either. If it's a very limited scope VM, that probably addresses a lot of the concerns that arise from a wide open system. However, it hasn't really come across that way in the media hype. If it was presented as, "We are proposing a limited, restricted, tightly controlled, and highly customized VM to provide access to just features needed for cryptographic contracts", that I have far less of an issue with.

    Thanks,
    J
  • chris613chris613 Member Posts: 93 ✭✭
    That's a valid criticism of the representation, I think. IMO a majority of people who view the "Introducing Ethereum" video will probably come away thinking that an ethereum contract can do anything that javascript, flash, or java can do. The concerns about security are obvious in that context.

    While I haven't yet started poking the VM for vulnerabilities, the design of the language is such that I'm no longer as worried about security as a theoretical matter. A couple of reasons:
    * No I/O APIs at all exist for reaching outside the VM to any existing computing resource
    * No modification (or event introspection) of the code segment is supported (baring a VM vuln of course)

    The problem, essentially, is that so many people who ought to know better actually have no idea what 'turing complete' really means, and they assume it means a lot more than it actually does. Even a cursory lookup will be misleading, people see things like "universal" and "all computable functions" and just assume that means 3D video games on the blockchain. ;) Reading about the idea of data feeds leads people to suspect that ethereum can execute web requests, and leads to a whole slew of assumptions and questions that are totally moot since this isn't at all how it works.

    I don't really know the solution, but it seems that clearer descriptions of what a contract really can and can't do might help. Perhaps a clear graphical representation that shows the little VM and the entirety of the inputs (tx data, current block data, and contract storage) and outputs (mktx calls and local contract storage).
  • chris613chris613 Member Posts: 93 ✭✭
    Wow, so reading this: https://us.v-cdn.net/5021640/uploads/FileUpload/67/594a96f36286ebc2a65179b987c5c2.png it looks like you CAN read/write the code segment? I will have to go try this.
Sign In or Register to comment.