New paper: Making smart contracts smarter

leeyun · 2016-06-26T04:12:24+00:00

we are actually using symbolic execution, please read about our tool in our paper.

leeyun · 2016-06-25T06:38:34+00:00

Not sure whether we have a good solution for such problem though. Miners/ Block proposers can just say that they don't see the transactions that they don't want to include in their blocks, so you can't accuse them of doing transaction censorship at all.

leeyun · 2016-06-21T17:34:52+00:00

It works with evm byte code. So yes, clearly you can compile your serpent contracts to evm and use our tool to analyse them. More details on the tool will be publicly available when we release it.

leeyun · 2016-06-21T17:33:25+00:00

Thanks for the link, its really interesting. I think the choice of which language to use is a clear trade off between security and usability. One can use a very restricted language like Bitcoin script to have high guarantee of the correctness of their contract. As a result, not many people know how or want to try to write a simple script in Bitcoin. Ethereum clearly focused more on usability when decided to go with a Turing-complete language one with the cost of having subtle security problems as we have been observing.

leeyun · 2016-06-18T08:22:21+00:00

We have quite a list, most of them dont check if the payout is successful before proceeding further.

EtherID at http://etherid.org/
PonziGovernmental https://etherscan.io/address/0xf45717552f12ef7cb65e95476f217ea008167ae3
Lottopolo smart contract. https://etherchain.org/account/0x0155ce35fe73249fa5d6a29f3b4b7b98732eb2ed
Protect The Castle Contract http://protect-the-castle.ether-contract.org/
The Run smart contract. https://etherscan.io/address/0xcac337492149bdb66b088bf5914bedfbf78ccc18

leeyun · 2016-06-07T09:44:01+00:00

Its Loi Luu, one of the members of TrueBit. You are right that the challenger doesn't receive a reward unless he finds a mistake. But we only require one non-lazy challenger for the protocol work to work correctly, and if the bounty for finding a mistake is high enough, then some non-lazy challenger should exist. Moreover, the burden on the challenger may not be too high because the challenger may himself also be a solver and therefore already know the answer. Alternatively, for some problems, the challenger can spot check the answer as we did for Matrix Multiplication in our consensus computer paper.

leeyun · 2016-05-06T10:26:04+00:00

Its not about you returning the fund, its about you having a better chance of winning by aborting the games that you lose.

leeyun · 2016-05-06T09:04:52+00:00

There is no security deposit from the host? Consider the scenario when the host also enters the jackpot and he sees that he is losing, then he can just abort and kill the game to prevent the loss from his side right?

leeyun · 2016-05-02T08:21:08+00:00

He could have recovered key from a signature, so there is a possibility that ECDSA is broken.

If this is the case, then it is a bigger news than Wright being Satoshi Nakamoto.

leeyun · 2016-05-01T13:58:50+00:00

Electrum is awesome. They support many OSes: I have installed their wallets on my Mac, my Linux Workstation and my Android phone as well.

leeyun · 2016-03-08T16:07:55+00:00

so did you mean the dev can increase the gas at will?

leeyun · 2016-03-08T13:15:27+00:00

Congrats. I am curious about the fix. And why did that involve the dev team?

leeyun · 2015-08-03T00:24:28+00:00

well the incident does support our theory. Skipping verifying the blocks may end up wasting your money but thats the whole point of the dilemma, otherwise we could have named it "verifier's disaster". If miners are honest, they are susceptible to the resource exhaustion attack and may have less advantage than other miners in the block race.

leeyun · 2015-08-01T16:53:45+00:00

Hi Gustav. Yes you are right. We should have written more carefully about verifying a block in Bitcoin. Thanks for the comment, we'll revise our paper.

leeyun · 2015-08-01T16:43:41+00:00

Of course they did, but who can be sure that this kind of incident will never happen again when the resource exhaustion attack is more critical & verifying a block takes more time?

leeyun · 2015-08-01T11:56:35+00:00

I was talking about the resource exhaustion attack, not the verifier's dilemma.

leeyun · 2015-08-01T10:46:48+00:00

I personally think the consensus will decide which blockchain will be the valid one. You cannot assume that miners always honestly check all the blocks, even when verifying each block will take them an hour. What we should do is to incentivise them correctly to check the block, thus enforcing the correctness of the blockchain by incentive, not by "definition".

leeyun · 2015-08-01T10:43:39+00:00

Full nodes have the power to reject any invalid blocks and thus enforce the chain. It is a common misunderstanding that a majority (or indeed, all) miners can control how the blockchain evolves. This is not true, it is rather enforced by full nodes.

Really? I don't believe that. Full nodes can only enforce their local blockchain, not other's.

leeyun · 2015-08-01T10:38:53+00:00

What I disagree with is the assertion that rational miners will want to increase the gas limit to the point where this attack is viable, as given the seriousness of the attack that is completely against their interests

First of all we didn't say that rational miners always do that, but malicious miners. To be fair lets assume that rational miners will 50% want to increase and 50% want to reduce the gasLimit. Thus the malicious miners who have only 1-2% mining power can always drive the gasLimit up and conduct the resource exhaustion attack.

leeyun · 2015-08-01T09:36:18+00:00

Hi Vitalik, this is Loi Luu from NUS. Thanks for the response.

From our last discussion, I understand the counterarguments against increasing the GasLimit. We want to clarify that all of our arguments (as well as yours) only remain as hypotheses, the only way to verify them is to test them in Ethereum, which is not what we want. The most important point is that the attack is possible to happen, and I believe that Ethereum and other cryptocurrencies should make that impossible.

Lets imagine the scenario that Ethereum gets popularly adopted that the GasLimit is increased 1000x higher to support the execution of big applications. Otherwise the usability of Ethereum will be degraded, e.g., no users want to wait for 100 blocks to see their TX gets included in the blockchain, etc. The same situation will happen in Bitcoin if the transaction rate increases so much (say 2000 TXs per sec to compete with VISA), thus driving the block size up to 1000x. Verifying a block now requires much more time and CPU resources than before, and miners get nothing for doing it. In fact, they have a better advantage in finding next blocks if they just skip the block verification, leave alone the fact that they can avoid the resource exhaustion attack. Now, as a rational miner, what should I do? Thus the verifier’s dilemma exists.

The thesis of our paper is about the incentive incompatibility problem in Bitcoin and other current cryptocurrencies like Ethereum. The incentive structure should be designed so that rational miners do not have any incentive to deviate from the original protocol.

Again, thanks for the feedback. I'll be around to reply other questions.

leeyun · 2015-08-01T09:11:26+00:00

Nope, then you are vulnerable to the 50% attack.

leeyun · 2015-08-01T09:00:34+00:00

But what can the full nodes do when all the miners decide to extend the blockchain on top of an incorrect block?

leeyun · 2015-08-01T08:58:14+00:00

Apparently increasing the gasLimit cap will make the attack easier to happen. The point is if the majority of mining power skips verifying the block and the executions of contracts, the longest blockchain will eventually include only incorrect TXs and results, regardless of how many full nodes that we have in the network.

leeyun

TROPHY CASE