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.
Topic: Turing complete language vs non-Turing complete (Ethereum vs Bitcoin) - page 5. (Read 34821 times)
February 05, 2014, 10:14:41 PM
February 05, 2014, 09:34:48 PM
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.
February 05, 2014, 08:52:48 PM
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.
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.
February 05, 2014, 08:48:35 PM
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. February 05, 2014, 08:03:45 PM
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/
February 05, 2014, 07:44:42 PM
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.
February 05, 2014, 07:08:34 PM
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.
February 05, 2014, 06:59:37 PM
But what if the voting mechanism is flawed/insufficient/exploitable? Changing it requires a hard-fork.
February 05, 2014, 03:37:42 PM
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.
February 05, 2014, 03:36:58 PM
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.
February 05, 2014, 03:36:08 PM
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/
February 05, 2014, 02:17:45 PM
Consensus is tied to fee calculation in etherium, so there is no mechanism for adjusting fees later without a hard fork...
February 05, 2014, 01:14:00 PM
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. February 05, 2014, 05:03:22 AM
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.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.
February 05, 2014, 01:56:54 AM
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.
February 04, 2014, 11:01:28 PM
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?
February 03, 2014, 05:17:07 PM
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.
February 03, 2014, 03:07:59 PM
Is there a hard limit to the execution time of a transaction or is it capped only by his attached fee?
February 03, 2014, 03:04:28 PM
I've put "On Transaction Fees, And The Fallacy of Market-Based Solutions" on my to-think-about-deeply list.
..which is this article
http://blog.ethereum.org/2014/02/01/on-transaction-fees-market-based-solutions/
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.
February 03, 2014, 10:42:52 AM
In Ethereum, you have entities called contracts, where contracts have their own balances, and are activated every time you send a transaction (think: money with an optional message attached) to them. The contract has 16 computational steps for free to give it wiggle room to determine whether a transaction is even worth processing; after this, every computational step that the contract takes costs it 1x BASEFEE (or more for specialized data access or crypto ops). If the contract goes bankrupt halfway through the computational process, it just stops halfway through.
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.
Jump to: