Bitcoin Forum
December 14, 2017, 01:24:13 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 [34] 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 »
  Print  
Author Topic: The Ethereum Paradox  (Read 84474 times)
smooth
Legendary
*
Offline Offline

Activity: 1624



View Profile
March 15, 2016, 10:17:25 AM
 #661

@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? Cheesy

No, because you can't check time either, so you can't write that program!
1513214653
Hero Member
*
Offline Offline

Posts: 1513214653

View Profile Personal Message (Offline)

Ignore
1513214653
Reply with quote  #2

1513214653
Report to moderator
1513214653
Hero Member
*
Offline Offline

Posts: 1513214653

View Profile Personal Message (Offline)

Ignore
1513214653
Reply with quote  #2

1513214653
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1513214653
Hero Member
*
Offline Offline

Posts: 1513214653

View Profile Personal Message (Offline)

Ignore
1513214653
Reply with quote  #2

1513214653
Report to moderator
1513214653
Hero Member
*
Offline Offline

Posts: 1513214653

View Profile Personal Message (Offline)

Ignore
1513214653
Reply with quote  #2

1513214653
Report to moderator
AlexGR
Legendary
*
Offline Offline

Activity: 1442



View Profile
March 15, 2016, 10:26:40 AM
 #662

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).
smooth
Legendary
*
Offline Offline

Activity: 1624



View Profile
March 15, 2016, 10:34:56 AM
 #663

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.

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
March 15, 2016, 10:43:11 AM
 #664

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.

AliceWonderMiscreations
Full Member
***
Offline Offline

Activity: 182


View Profile WWW
March 15, 2016, 11:04:25 AM
 #665

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.

I hereby reserve the right to sometimes be wrong
hv_
Hero Member
*****
Offline Offline

Activity: 672


View Profile
March 15, 2016, 11:05:59 AM
 #666

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.


... and is still not solved ...

Carpe diem  -  cut the down side  -  be anti-fragile
A feature that needs more than one convincing argument is no and Satoshi owes me no proof.
My coding style is legendary but limited to 1MB, sorry but cannot come much over my C64, Bill Gates and Tom Bombadil
AlexGR
Legendary
*
Offline Offline

Activity: 1442



View Profile
March 15, 2016, 11:06:35 AM
 #667

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).
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
March 15, 2016, 11:07:32 AM
 #668

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.


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

AliceWonderMiscreations
Full Member
***
Offline Offline

Activity: 182


View Profile WWW
March 15, 2016, 11:09:42 AM
 #669

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.


... and is still not solved ...

The biggest problem recently is not using blocking entropy source.

I hereby reserve the right to sometimes be wrong
AliceWonderMiscreations
Full Member
***
Offline Offline

Activity: 182


View Profile WWW
March 15, 2016, 11:14:26 AM
 #670

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.


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

I hereby reserve the right to sometimes be wrong
hv_
Hero Member
*****
Offline Offline

Activity: 672


View Profile
March 15, 2016, 11:16:41 AM
 #671

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.


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

Carpe diem  -  cut the down side  -  be anti-fragile
A feature that needs more than one convincing argument is no and Satoshi owes me no proof.
My coding style is legendary but limited to 1MB, sorry but cannot come much over my C64, Bill Gates and Tom Bombadil
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
March 15, 2016, 11:23:37 AM
 #672

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.


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

smooth
Legendary
*
Offline Offline

Activity: 1624



View Profile
March 15, 2016, 11:29:49 AM
 #673

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.

YarkoL
Legendary
*
Offline Offline

Activity: 978



View Profile
March 15, 2016, 11:38:02 AM
 #674


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.

dev blog https://yarkol.github.io
BTC 18kHb54jqcpWEkuAkCFsGMzR6BMgYnpi2T
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
March 15, 2016, 11:44:56 AM
 #675

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.

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)

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
March 15, 2016, 11:55:20 AM
 #676

at least the main people should work too

Do Vitalik and Vlad "work"? Is delusional meandering work?

smooth
Legendary
*
Offline Offline

Activity: 1624



View Profile
March 15, 2016, 11:58:04 AM
 #677


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 Ethereum alarm clock doesn't work that way. Your program can't "loop and wait for the next block" the way AlexGR described. For one thing, the alarm clock events are a part of a separate transaction and only one transaction (logically) executes at a time.

YarkoL
Legendary
*
Offline Offline

Activity: 978



View Profile
March 15, 2016, 12:14:14 PM
 #678

Quote from: smooth

The Ethereum alarm clock doesn't work that way. Your program can't "loop and wait for the next block" the way AlexGR described. For one thing, the alarm clock events are a part of a separate transaction and only one transaction (logically) executes at a time.

I haven't looked into the alarm clock closely, but it seems to
me that AlexGR's program could be done even without that service.

Something along the lines of

while (block.number != previous_block) x += 42

But as mentioned, there is no guarantee of this succeeding
as it is up to miners to include the tx.


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.

But what is the externality here? Everyone can see that a new
block has been found.

dev blog https://yarkol.github.io
BTC 18kHb54jqcpWEkuAkCFsGMzR6BMgYnpi2T
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
March 15, 2016, 12:19:54 PM
 #679

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.

But what is the externality here? Everyone can see that a new
block has been found.

Disagreement about whether the transaction was included (and then disagreement about the derivative smart contract state transitions), which cross shards. Because not all validators validate all shards. The externality is that including a transaction or not is not deterministic but rather is determined by the longest chain rule, but there is no longest chain rule if each partition has orthogonal state (which must be the case if not all validators validate all partitions).

Indeed when there is only one partition, then there is no disagreement about how to merge state from partitions. But I was writing about the sharded case.

Remember the alarm clock is triggered by blocks, but shards don't have their own blocks. Thus the state of the alarm clock is cross-sharded state. It is an analogous reason as to why gas destroys decentralized consensus in a sharded design.

Vitalik has himself deep in a clusterfuck.

smooth
Legendary
*
Offline Offline

Activity: 1624



View Profile
March 15, 2016, 12:44:59 PM
 #680

Quote from: smooth

The Ethereum alarm clock doesn't work that way. Your program can't "loop and wait for the next block" the way AlexGR described. For one thing, the alarm clock events are a part of a separate transaction and only one transaction (logically) executes at a time.

I haven't looked into the alarm clock closely, but it seems to
me that AlexGR's program could be done even without that service.

Something along the lines of

while (block.number != previous_block) x += 42

No!

Transactions/contracts/programs execute within a block (by being included in the block!). The block number will never change during execution.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 [34] 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!