
Just Enough Bitcoin for Ethereum - ConsenSys
https://medium.com/@ConsenSys/time-sure-does-fly-ed4518792679
======
wanderfowl
Etherium sounds like a great idea, and a great approach. But I'm afraid it's
going to end up like GPG: Technically awesome, strong, capable, and useful -
but completely out of reach of most of the people you'd want to use it with.

Every time I read a "Getting started with Ethereum" guide which involves 7
steps just to buy Bitcoin (from a site nobody's heard of) and then set up a
wallet, I watch the number of potential users dropping like a rock.

I hope very much that it succeeds enough to justify its learning curve, as
it's an interesting idea. But I suspect that outside of a few _very_ small
markets where it offers the ability to do something completely impossible with
any other method, having an ethereum interface for your product or service
will be roughly equivalent to GPG signing all your emails: People in the know
weren't that concerned anyways, and nobody else knows enough to care.

~~~
d23
Someone really has to get a simple proof of concept application made that any
dummy can understand and run on their own. I'm a developer that bought
ethereum, and even after reading their materials after the launch I couldn't
be bothered with trying to get it running or understanding it. That doesn't
bode well for the long-term success of the project.

~~~
nullz
There are a few projects working on this. One problem is key management and
giving the app a connection to the blockchain. If you do key management in the
webapp and read from the blockchain via a centralized API, thats not much of
an improvement over existing systems. Ethereum core's solution to this is a
special browser, but it is still under development. I'm working on a
project[0] that takes this on, but is still a couple months out from a public
beta. Its a bit of a hack but it manages a zero-install solution by having a
sort of browser-in-browser that intercepts transaction signing requests and
provides access to blockchain data. Can't wait to get it out there.

[0]: [https://metamask.io/](https://metamask.io/)

------
rabbyte
I'm investing and developing a product on Ethereum, not affiliated with the
project or developers, so I'll give my sense of things. We're in an era of
rapid experimentation. It feels a bit like a shared developer box without any
libs or tooling so people are busy working out the best way to approach common
problems.

I know it sounds like marketing but it does remind me of the early days of the
web, like 95, before the web was serious business. It's all toys and gizmos,
the hacker equivalents to water ripple effects, with frameworks coming in to
help people build more interesting and production-quality things.

Very basic questions persist such as how to best store large data files (ipfs
looking like the clear winner), how to reference them, how to design a
currency, how to avoid designs that are too stiff or get stuck in a state
where they can't be easily updated, how to express an application model in
smart contract form, how to best represent a user account, etc. If that sounds
fun, jump in, if you were wanting something that matched the hype, wait a few
months. Apps on Ethereum can be as expressive and polished as the apps you use
today, and can even be designed just as _centralized_ as the apps you use
today, but with properties you would typically think of only belonging to
Bitcoin.

------
aaron-lebo
I watched Ethereum for several months after the initial announcement and was
really excited about it. I know the network went live recently and it
surprises me how little it's been discussed at places like HN.

How are things going as far as tech, adoption, etc for Ethereum for those in
the know?

~~~
mannykannot
I am curious how one goes about verifying that these "trustless transactions
of arbitrary (turing-complete!) complexity" will have the behavior that you
expect (as a participant) or intend (as an author) for them to have, and that
they are proof from subversion by a malicious counter- or third party. After
all, this is not exactly a solved problem anywhere else Turing-complete
complexity is employed, and it would seem to nullify the point of
trustlessness if you are relying on someone else's word on this matter.

~~~
drdeca
Well, the compiled code is available, and if they provide the source code, you
can verify that it compiles to the code on chain (or, you can analyze the code
on chain without the source code of the contract, but that is harder).

The source code for the contract can be made to have a proof of correctness in
it, or, as it is probably not all that long, if you look at the source code
long enough you can be sufficiently convinced that it runs how you expect it
to.

Regarding the problems with turing completeness, any transaction is guaranteed
to finish within a particular number of steps, because the transaction
includes an amount of "gas", which puts a limit to how many steps the contract
will run. If it runs out of gas before finishing, all the changes in the state
are reverted (but the person still pays the gas cost). If it finishes, then
the extra "gas" is returned. (the transaction specifies some "gas cost", which
is how much ether per gas or gas per ether (idr) , and some amount of ether,
which is the max cost the transaction is allowed to take. There aren't "gas
balances", any "gas" that is transferred just is ether at the end. Its just a
unit of how much computation, and the gas price is how much they are willing
to pay per amount of computation. I feel like I didn't explain this well...)

Checking that the contracts were run correctly is done by anyone verifying the
block which contains the contract call. If the miner runs the contract
incorrectly, then the people verifying the block will not accept the block as
valid, so people won't mine on the block, so it wont end up in the main chain,
so the miner will not receive anything from mining the block, and what happens
in the wrong execution wont effect anything.

I'm not sure if this explanation has been very clear, but I hope it has been
clear enough. I can try again if it isn't though.

~~~
mannykannot
Thank you for your reply, but I have to say that I think it understates the
problem.

>The source code for the contract can be made to have a proof of correctness
in it..

Has this capability already been implemented for the Ethereum contract
language(s)? If so, I would greatly appreciate a link, as my admittedly
cursory search did not find it (there is some discussion of verification of
the Ethereum infrastructure, but that is merely a precondition to contract
verification.)

Even so, I think it is significant that only a tiny fraction of today's
software is written this way, and only a tiny fraction of all developers know
how to do it. Someone has to write these contracts.

>... or, as it is probably not all that long...

Ethereum's promoters are imagining nothing less than a revolutionary new
economy, with vast networks of interacting contracts. The amount of contract
software implicit in these dreams is huge.

>If you look at the source code long enough you can be sufficiently convinced
that it runs how you expect it to.

The steady stream of security vulnerabilities that are being found in ordinary
software shows that this is not an effective technique. If you are a software
developer, imagine doing your work in an environment where any bug of yours
could cause you, personally, to lose a significant amount of money.

Nor do I think 'gas' completely solves this problem. Now your analysis has to
cover the issue of whether your contract, or any of those it is dependent on,
will run out of gas before completion. In most cases, and particularly in
networks of dependent transactions, reverting back to the initial state is not
a viable outcome (imagine that happening on the last payment of your mortgage
on a house.) I can imagine that running out of gas on some obscure corner case
might be used by an attacker as as a means to disrupt a network of dependent
transactions.

~~~
drdeca
Afaik, no, proofs of correctness are not currently implemented in the
languages that are used. Some of them iirc have a way to do that in part, but
currently the languages aren't set up for full proofs of correctness. (But,
iirc, some things can be shown)

It is planned though.

Ok, yes, I suppose that the contracts will/would eventually get kind of long.
As it is now though, It hasn't taken me /all/ that long to read the contracts
I've looked at. (But perhaps I've only bothered to look at the ones short
enough to read )

Regarding finding security flaws despite people looking carefully: yes, that
seems a good point. I think proofs of correctness will be important for
important contracts. However, many contracts logic is not really all that
complicated. A contract can be powerful without being complicated, I think.
Because of this, I think much of the time the proofs should not be too hard to
write.

Regarding running out of gas:

Well, yes, if the transaction you send does not have enough gas, and you
needed it to run, that could be a problem. But, if you run the transaction
locally, and use that to estimate the amount of gas which needs to be used
(might not be exact if the state of the contract changes in a way that your
transaction needs more computation, but for reasonable contracts I think this
would not be much), and one can provide extra gas in case this happens (the
extra gas will be refunded), to have a high confidence that it will be enough.

But, if the transaction is important, one would be watching what happened
carefully anyway, to make sure the transaction gets in the chain, regardless
of the complications from the computations in the transaction. If, counter to
your expectations, the gas you provided did not end up being enough, then you
would be able to notice this, and, though you would be out that gas cost, you
could just send the transaction again with more gas.

The block times are very short (under a minute), so you probably wouldn't have
to wait long to send the transaction again with more gas. Most of the gas
costs shouldn't be too large, so unless the transaction you are sending is
very time sensitive, or very computationally expensive, a transaction running
out of gas shouldn't be /too/ much of a problem?

I think you make some good points btw, just explaining my understanding of how
those things are addressed.

Also, I'm not sure, but it seems you might have a small confusion about gas.
Gas is included in the transaction, not stored by a contract over time. Gas
only exists within the context of a particular transaction, the token which is
actually exchanged is ether. You might have just been choosing not to mention
the details of that though.

~~~
nivertech
I think @mannykannot misunderstands the purpose of gas in Ethereum. It's only
purpose is a solution to the Halting Problem [1]. Alternative solution could
be disallowing jumps backwards / loops or limiting time of the computation.

Why is it the problem? Because contract with something like while(1){}; will
render the entire network of nodes useless.

1\.
[https://en.m.wikipedia.org/wiki/Halting_problem](https://en.m.wikipedia.org/wiki/Halting_problem)

~~~
mannykannot
I am well aware of the purpose of gas. What I have not seen is any argument
(from @drdeca or anyone else) that gas materially simplifies the problem of
verifying that a contract behaves properly (from your perspective, as one of
the parties to the contract) in all circumstances. The fact that it will
always halt is only a tiny step along that road, and if it halts as a result
of running out of gas, that is strong evidence that it has not worked as
intended.

An example may be useful. Suppose I tell you that I have written an Ethereum
contract whereby people can loan me money, and after a year, I will pay them
back double. Before you enter into one such contract with me, I hope it would
cross your mind to wonder if I might actually be running a Ponzi scheme. Don't
worry, I say, Ethereum has this gas feature that means the transaction will
always halt. How much more confident should that information make you feel?

As for your alternatives, gas is essentially the same as limiting the time of
computation. If backwards jumps were disallowed, the language would not be
even approximately Turing-equivalent.

~~~
nivertech
1\. Gas mechanism has nothing to do with tamper-proofing transactions, thats
what blockchain (or more correctly hashchain) is for.

2\. There are Turing-complete languages which only allow loops with known
number of iterations.

3\. Check my presentation, If you want to understand Ethereum programming
model:

[http://www.slideshare.net/mobile/nivertech/ethereum-vm-
and-d...](http://www.slideshare.net/mobile/nivertech/ethereum-vm-and-dsls-for-
smart-contracts)

IMO Ethereum is just a first step in the right direction, the real solution
will need to be much more scalable.

~~~
mannykannot
> 1\. Gas mechanism has nothing to do with tamper-proofing transactions, thats
> what blockchain (or more correctly hashchain) is for.

I am not sure why you are mentioning this here, but if this is what you think
I am misunderstanding about gas, perhaps you could point out where you think I
made this mistake.

>2\. There are Turing-complete languages which only allow loops with known
number of iterations.

You did not originally write "loops with known number of iterations", you
wrote "disallowing jumps backwards / loops".

> 3\. Check my presentation, If you want to understand Ethereum programming
> model.

Based on your contributions to this thread so far, I am not very confident
that I will find my specific question addressed, but if you give me a specific
slide number to start at, I will give it a look.

BTW, do you have an answer to the question I posed in the second paragraph of
my previous post?

~~~
nivertech
_An example may be useful. Suppose I tell you that I have written an Ethereum
contract whereby people can loan me money, and after a year, I will pay them
back double. Before you enter into one such contract with me, I hope it would
cross your mind to wonder if I might actually be running a Ponzi scheme. Don
't worry, I say, Ethereum has this gas feature that means the transaction will
always halt. How much more confident should that information make you feel?_

Again, it has nothing to do with gas. You just need to review/audit the
contract's source and EVM code and be sure it doesn't have backdoors.

For simplicity, you can think about Ethereum Transaction as an RPC call to
Ethereum contract, where in addition to arguments (Data), you can also
transfer a monetary value (in Ether) and provide fuel (Gas) for contract
execution. Gas price (in Ethers) serves the same function as Bitcoin Tx fee.

Gas mechanism is just an implementation detail.

EDIT:

Regarding the contract example you mentioned "unsecured loan", I'm not sure it
can be implemented as a "Self-enforcing contract", which is a proper term for
"Smart Contracts". If a contract depends on your will or ability of repaying
the loan, then it's not a self-enforcing contract. Somebody need to provide a
collateral. It doesn't make sense for you to put up a 1001 Ether collateral to
take 1000 Ether loan.

With smart property represented on the Blockchain you will be able to put up
your car or apartment as a collateral for a loan, then it can be made self-
enforceable. But it's not there yet.

The only way I can see for it to be implemented is with your own token, which
will be devaluated each time somebody not repaying the loan in full.

~~~
mannykannot
I don't think you have ever read the entire thread here. It was drdeca who
first introduced gas into the discussion, apparently suggesting that it
somehow either solved, or at least mitigated, the verification problem (he was
vague about exactly how he thought it helped), and it was I who responded that
it made no fundamental difference. The whole point of the example was to
demonstrate that gas does not materially simplify the verification problem.

You appear to have replied to the wrong person in your first post in this
thread. Did you mean to say that @drdeca, not @mannykannot, misunderstands the
purpose of gas?

------
otl1248
Is this a press release?

------
LukeHoersten
Bitcoin is a solution. Ethereum is an experiment. Both noble pursuits.

~~~
fragsworth
That's glossing over quite a lot of details.

~~~
LukeHoersten
Definitely a generalization but I think that's how it's viewed by many from
30k ft. I should have made it clearer that I was making an observation about a
perception not my own views.

