Bitcoin Forum
August 18, 2018, 04:24:20 PM *
News: Latest stable version of Bitcoin Core: 0.16.2  [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 59 »
  Print  
Author Topic: The Ethereum Paradox  (Read 84890 times)
AlexGR
Legendary
*
Offline Offline

Activity: 1554
Merit: 1025



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

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).
1534609460
Hero Member
*
Offline Offline

Posts: 1534609460

View Profile Personal Message (Offline)

Ignore
1534609460
Reply with quote  #2

1534609460
Report to moderator
1534609460
Hero Member
*
Offline Offline

Posts: 1534609460

View Profile Personal Message (Offline)

Ignore
1534609460
Reply with quote  #2

1534609460
Report to moderator
1534609460
Hero Member
*
Offline Offline

Posts: 1534609460

View Profile Personal Message (Offline)

Ignore
1534609460
Reply with quote  #2

1534609460
Report to moderator
BOUNTY PORTALS
BLOG
WHERE BOUNTY MANAGEMENT
MEETS AUTOMATION
SIGNATURE CAMPAIGNS
TWITTER
FACEBOOK
MEDIA CAMPAIGNS
AND MORE!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1534609460
Hero Member
*
Offline Offline

Posts: 1534609460

View Profile Personal Message (Offline)

Ignore
1534609460
Reply with quote  #2

1534609460
Report to moderator
1534609460
Hero Member
*
Offline Offline

Posts: 1534609460

View Profile Personal Message (Offline)

Ignore
1534609460
Reply with quote  #2

1534609460
Report to moderator
smooth
Legendary
*
Offline Offline

Activity: 1862
Merit: 1047



View Profile
March 15, 2016, 10:34:56 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

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
Merit: 255


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

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
Merit: 100


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

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: 924
Merit: 531

Remove The Middlemen


View Profile WWW
March 15, 2016, 11:05:59 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. 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 - don't dillute Bitcoin!
Memo: 1AHUYNJKPfY7PjVK1hNQFo5LrdGixuiybw
The simple way is the genius way - in Moore and Satoshi we trust.
AlexGR
Legendary
*
Offline Offline

Activity: 1554
Merit: 1025



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

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
Merit: 255


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

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
Merit: 100


View Profile WWW
March 15, 2016, 11:09:42 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 ...

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
Merit: 100


View Profile WWW
March 15, 2016, 11:14:26 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 ...

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: 924
Merit: 531

Remove The Middlemen


View Profile WWW
March 15, 2016, 11:16:41 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.

Yep - than you'd need a human user in front of a miner Grin

Carpe diem  -  cut the down side  -  be anti-fragile - don't dillute Bitcoin!
Memo: 1AHUYNJKPfY7PjVK1hNQFo5LrdGixuiybw
The simple way is the genius way - in Moore and Satoshi we trust.
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420
Merit: 255


View Profile
March 15, 2016, 11:23:37 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.

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: 1862
Merit: 1047



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

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: 989
Merit: 1000



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


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.

“Civilization is a hopeless race to discover remedies for the evils it produces.”
― Jean-Jacques Rousseau
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420
Merit: 255


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

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
Merit: 255


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

at least the main people should work too

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

smooth
Legendary
*
Offline Offline

Activity: 1862
Merit: 1047



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


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: 989
Merit: 1000



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

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.

“Civilization is a hopeless race to discover remedies for the evils it produces.”
― Jean-Jacques Rousseau
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420
Merit: 255


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

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: 1862
Merit: 1047



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

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

Activity: 420
Merit: 255


View Profile
March 15, 2016, 12:52:46 PM
 #680

Transactions/contracts/programs execute within a block (by being included in the block!). The block number will never change during execution.

The alarm clock works by saving a state on the block chain (recording the pending alarms), then it is invoked every time a smart contract invokes it to set an alarm. The alarm contract checks for any triggered alarms every time it is invoked by another contract.

But it is impossible for this to work with sharding and not destroy the decentralized consensus game theory.

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 59 »
  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!