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

[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.