Topic: Turing complete language vs non-Turing complete (Ethereum vs Bitcoin) - page 5. (Read 34758 times)

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.

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)"


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.

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.

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.

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/

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.

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

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

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

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

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/

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

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.

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.

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?

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

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

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

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.

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.