at least the main people should work too
Do Vitalik and Vlad "work"? Is delusional meandering work?
Topic: The Ethereum Paradox - page 26. (Read 99908 times)
Do Vitalik and Vlad "work"? Is delusional meandering work?
Guarantees
Will the call happen?
There are no guarantees that your function will be called. This is not a shortcoming of the service, but rather a fundamental limitation of the ethereum network. Nobody is capable of forcing a transaction to be included in a specific block.
The Alarm service has been designed such that it should become more reliable as more people use it.
However, it is entirely possible that certain calls will be missed due to unforseen circumstances.
Will the call happen?
There are no guarantees that your function will be called. This is not a shortcoming of the service, but rather a fundamental limitation of the ethereum network. Nobody is capable of forcing a transaction to be included in a specific block.
The Alarm service has been designed such that it should become more reliable as more people use it.
However, it is entirely possible that certain calls will be missed due to unforseen circumstances.
This is an example of what I was writing about upthread where I said externalities destroy the Nash equilibrium and create a Prisoner's dilemma for validators when there is sharding.
I am not going to write down the complete explanation. Just think about it.
(And remember from upthread that sharding is flawed for another more ubiquitous reason, which is the gas can't be sharded without destroying decentralized consensus)
No you can't. Programs can only look at blocks in the past, not the future and there is no "until a block is found" operation.
Check Ethereum Alarm Clock
"An ethereum contract that facilitates scheduling function calls for a specified block in the future."
But you'd have to cap the number of your operations, true.
The primary reason that smart contracts are basically useless, is because a block chain can't form a consensus about anything external, except for signatures transactions that are authorized by public key cryptography to modify block chain state.
I'm sure they have some not very widespread uses but the "virtual computer" concept is definitely useless, so far.
Quote
It can only form a consensus about block chain state transformation with the clock period being blocks and the longest chain rule.
Still, if the clock period is block, and, code-wise, can be used as a ...clock, then there is a clock.
So, say, I write a program which says "I add 42 to 42 to 42 to 42 ...until next block is found".
No you can't. Programs can only look at blocks in the past, not the future and there is no "until a block is found" operation. More practically if there were, a program that tried to do a long-running loop like that would likely run out of gas (which results in state rollback and loss of gas). Programs have to be small and simple.
Some people don't understand how random numbers work. Or that there are different qualities and kinds of randomness.
When I first started programming the random function required a seed and always gave the same result with the same seed. Modern languages often pick a seed for you if you don't, and people often assume that means there is some magic way for a computer to pull a number out of thin air.
There have been many exploits resulting from random numbers not having a seed that is selected from an adequate entropy pool.
When I first started programming the random function required a seed and always gave the same result with the same seed. Modern languages often pick a seed for you if you don't, and people often assume that means there is some magic way for a computer to pull a number out of thin air.
There have been many exploits resulting from random numbers not having a seed that is selected from an adequate entropy pool.
... and is still not solved ...
An adequate entropy pool can be obtain from the user's mouse movements.
The problem is with the operating system's entropy pool and the API for accessing it. Avoid it entirely if you want to be very sure.
Avoiding it entirely can be dangerous if you don't know what you are doing.
Lot of people in Linux land use /dev/urandom when they should be using /dev/random
Accessing the blocking entropy pool has issues as well.
Doing anything expecting random numbers and not knowing what you are doing is going to result in failure.
On servers or fresh after install (when ssh key is generated) that's highly problematic. That was the fairly recent raspberry pi problem.
That is one of the corner cases. Now Linux I believes saves entropy between reboots. I don't remember all the issues. I would need to read up on it again. Afair one of the issues is we can't know the quality of the entropy in the blocking pool and we can't know if it has perfect forward security.
Some people don't understand how random numbers work. Or that there are different qualities and kinds of randomness.
When I first started programming the random function required a seed and always gave the same result with the same seed. Modern languages often pick a seed for you if you don't, and people often assume that means there is some magic way for a computer to pull a number out of thin air.
There have been many exploits resulting from random numbers not having a seed that is selected from an adequate entropy pool.
When I first started programming the random function required a seed and always gave the same result with the same seed. Modern languages often pick a seed for you if you don't, and people often assume that means there is some magic way for a computer to pull a number out of thin air.
There have been many exploits resulting from random numbers not having a seed that is selected from an adequate entropy pool.
... and is still not solved ...
An adequate entropy pool can be obtain from the user's mouse movements.
The problem is with the operating system's entropy pool and the API for accessing it. Avoid it entirely if you want to be very sure.
Yep - than you'd need a human user in front of a miner
Some people don't understand how random numbers work. Or that there are different qualities and kinds of randomness.
When I first started programming the random function required a seed and always gave the same result with the same seed. Modern languages often pick a seed for you if you don't, and people often assume that means there is some magic way for a computer to pull a number out of thin air.
There have been many exploits resulting from random numbers not having a seed that is selected from an adequate entropy pool.
When I first started programming the random function required a seed and always gave the same result with the same seed. Modern languages often pick a seed for you if you don't, and people often assume that means there is some magic way for a computer to pull a number out of thin air.
There have been many exploits resulting from random numbers not having a seed that is selected from an adequate entropy pool.
... and is still not solved ...
An adequate entropy pool can be obtain from the user's mouse movements.
The problem is with the operating system's entropy pool and the API for accessing it. Avoid it entirely if you want to be very sure.
Avoiding it entirely can be dangerous if you don't know what you are doing.
Lot of people in Linux land use /dev/urandom when they should be using /dev/random
On servers or fresh after install (when ssh key is generated) that's highly problematic. That was the fairly recent raspberry pi problem.
They don't want to use /dev/random because it blocks and may take too long and is a bad user experience but I think a key made from insufficient entropy can lead to a worse user experience.
But kind of going off-topic, I don't see ethereum as a platform for doing that kind of stuff anyway.
It will be continued issue with Internet of Things.
Some people don't understand how random numbers work. Or that there are different qualities and kinds of randomness.
When I first started programming the random function required a seed and always gave the same result with the same seed. Modern languages often pick a seed for you if you don't, and people often assume that means there is some magic way for a computer to pull a number out of thin air.
There have been many exploits resulting from random numbers not having a seed that is selected from an adequate entropy pool.
When I first started programming the random function required a seed and always gave the same result with the same seed. Modern languages often pick a seed for you if you don't, and people often assume that means there is some magic way for a computer to pull a number out of thin air.
There have been many exploits resulting from random numbers not having a seed that is selected from an adequate entropy pool.
... and is still not solved ...
The biggest problem recently is not using blocking entropy source.
Some people don't understand how random numbers work. Or that there are different qualities and kinds of randomness.
When I first started programming the random function required a seed and always gave the same result with the same seed. Modern languages often pick a seed for you if you don't, and people often assume that means there is some magic way for a computer to pull a number out of thin air.
There have been many exploits resulting from random numbers not having a seed that is selected from an adequate entropy pool.
When I first started programming the random function required a seed and always gave the same result with the same seed. Modern languages often pick a seed for you if you don't, and people often assume that means there is some magic way for a computer to pull a number out of thin air.
There have been many exploits resulting from random numbers not having a seed that is selected from an adequate entropy pool.
... and is still not solved ...
An adequate entropy pool can be obtain from the user's mouse movements.
The problem is with the operating system's entropy pool and the API for accessing it. Avoid it entirely if you want to be very sure.
The primary reason that smart contracts are basically useless, is because a block chain can't form a consensus about anything external, except for signatures transactions that are authorized by public key cryptography to modify block chain state.
I'm sure they have some not very widespread uses but the "virtual computer" concept is definitely useless, so far.
Quote
It can only form a consensus about block chain state transformation with the clock period being blocks and the longest chain rule.
Still, if the clock period is block, and, code-wise, can be used as a ...clock, then there is a clock.
So, say, I write a program which says "I add 42 to 42 to 42 to 42 ...until next block is found".
The result of the addition will be different for a slow vs a fast cpu (the faster cpu will have reached a higher number).
Some people don't understand how random numbers work. Or that there are different qualities and kinds of randomness.
When I first started programming the random function required a seed and always gave the same result with the same seed. Modern languages often pick a seed for you if you don't, and people often assume that means there is some magic way for a computer to pull a number out of thin air.
There have been many exploits resulting from random numbers not having a seed that is selected from an adequate entropy pool.
When I first started programming the random function required a seed and always gave the same result with the same seed. Modern languages often pick a seed for you if you don't, and people often assume that means there is some magic way for a computer to pull a number out of thin air.
There have been many exploits resulting from random numbers not having a seed that is selected from an adequate entropy pool.
... and is still not solved ...
Some people don't understand how random numbers work. Or that there are different qualities and kinds of randomness.
When I first started programming the random function required a seed and always gave the same result with the same seed. We knew that random wasn't really random, but dependent upon the seed we gave it. How we changed that seed was critical. Increment by 1 or something predictable and the results were predictable.
Modern languages often pick a seed for you if you don't, and people often assume that means there is some magic way for a computer to pull a number out of thin air.
There have been many exploits resulting from random numbers not having a seed that is selected from an adequate entropy pool.
When I first started programming the random function required a seed and always gave the same result with the same seed. We knew that random wasn't really random, but dependent upon the seed we gave it. How we changed that seed was critical. Increment by 1 or something predictable and the results were predictable.
Modern languages often pick a seed for you if you don't, and people often assume that means there is some magic way for a computer to pull a number out of thin air.
There have been many exploits resulting from random numbers not having a seed that is selected from an adequate entropy pool.
It's just an example, trying to understand how a random function would work.
Simple.
The entropy for the seed would come from the proof-of-work hash that wins the block. All other validators would respect this entropy.
Let's say randomizing numbers is out of the question.
It is not out-of-the question. The randomness of a number is determined by the source of the entropy. Proof-of-work has a high entropy.
No, because you can't check time either, so you can't write that program!
Hmmm...
a) That sounds extremely crippled
b) That sounds extremely broken if the result is ...forking (I'm not sure that it can keep things deterministic when there are tens if not hundreds of possible triggers for indirectly randomizing things).
The primary reason that smart contracts are basically useless, is because a block chain can't form a consensus about anything external, except for signatures transactions that are authorized by public key cryptography to modify block chain state. Block chains can only form a consensus about block chain state transformations with the clock period being blocks and the longest chain rule.
If it were possible to introduce state into the block chain that could not be objectively verified by all validators, then the Nash equilibrium is lost, a Prisoner's Dilemma is created, and consensus is no longer convergent.
Augur is an example of attempting to form consensus about external state (the outcomes of prediction markets) by employing reputation of participants. Essentially they attempt to build a new consensus system on top of Ethereum's block chain consensus. But the problem is those two consensus systems can not be orthogonal, because validators of Ethereum have to be able to agree on the objective state on the block chain of Augur data. Notwithstanding that the Byzantine Generals Problem can't be solved with reputation and propagation, due to Sybil attacks.
Everything Ethereum is a delirium. Delusional just like Vitalik staring off into blank space when he speaks.
I don't understand what you mean by censoring code. There is a virtual machine and the virtual machine instructions are all deterministic. There is no instruction that could produce a random value.
+Quote
No, because you can't check time either, so you can't write that program!
Hmmm...
a) That sounds extremely crippled
I guess that is debatable. It isn't (marketing hype about "world computer" aside) intended to run all general programs. It is intended to run programs useful for smart contracts.
Quote
b) That sounds extremely broken if the result is ...forking (I'm not sure that it can keep things deterministic when there are tens if not hundreds of possible triggers for indirectly randomizing things).
Well it is risky, but there's a lot of effort behind making sure those triggers don't exist, multiple security reviews, etc. So far no one has found a way to do it, at least not in the wild.
I don't understand what you mean by censoring code. There is a virtual machine and the virtual machine instructions are all deterministic. There is no instruction that could produce a random value.
+Quote
No, because you can't check time either, so you can't write that program!
Hmmm...
a) That sounds extremely crippled
b) That sounds extremely broken if the result is ...forking (I'm not sure that it can keep things deterministic when there are tens if not hundreds of possible triggers for indirectly randomizing things).
@AlexGR, everything in Ethereum is deterministic. There are no operations that have different results on different nodes. At least if everything works properly. If not then it can fork the chain.
Aha, that's closer to the answer I was hoping for. Thanks.
Ok, so is it censoring code that it doesn't like or something?
I don't understand what you mean by censoring code. There is a virtual machine and the virtual machine instructions are all deterministic. There is no instruction that could produce a random value.
Quote
Now let's do something else. I'm adding a constant number (not random), let's say the number 42, for 1 entire second. Everything is given / predetermined: a) The number to add (42) and b) how long I want it to perform what I want (1000 msecs). The result though is different because one pc will have made 500 million additions, another will have made 10 billion additions, depending their cpu power.
Can I fork the network now?
Can I fork the network now?
No, because you can't check time either, so you can't write that program!
@AlexGR, everything in Ethereum is deterministic. There are no operations that have different results on different nodes. At least if everything works properly. If not then it can fork the chain.
Aha, that's closer to the answer I was hoping for. Thanks.
Ok, so is it censoring code that it doesn't like or something?
Let's say randomizing numbers is out of the question.
Now let's do something else. I'm adding a constant number (not random), let's say the number 42, for 1 entire second. Everything is given / predetermined: a) The number to add (42) and b) how long I want it to perform what I want (1000 msecs). The result though is different because one pc will have made 500 million additions, another will have made 10 billion additions, depending their cpu power.
Can I fork the network now?
if Ethereum is a distributed computing platform
It isn't; it's a replicated/redundant computing platform.
If I make a simple program to get a random number from 1 to 100, or base my program on a randomizer, how can that be repeated in every single node? Shouldn't they give different outputs? How can that be validated?
Let's say I want to make a betting app, based on the random rolling of dice. How can that work?
Can't you grab it out from latest block hash?
You can, if you want the result to be able to be manipulated by miners.
@AlexGR, everything in Ethereum is deterministic. There are no operations that have different results on different nodes. At least if everything works properly. If not then it can fork the chain.
Let's say I have a very simple program to run on the "distributed computing platform" of ethereum.
The program does one thing.
Provide an output of a random number (from 1 to 100)
How can that work on different nodes, and have them ....validating the same thing?
Unless it doesn't allow that type of functionality.
The program does one thing.
Provide an output of a random number (from 1 to 100)
How can that work on different nodes, and have them ....validating the same thing?
Unless it doesn't allow that type of functionality.
Fault-tolerant is a good term I think. Perhaps that helps define its (possible) utility too.
Agreed. That's more accurate.
Jump to: