Bitcoin Forum
April 24, 2024, 11:51:32 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
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 99808 times)
YarkoL
Legendary
*
Offline Offline

Activity: 996
Merit: 1012


View Profile
March 15, 2016, 02:28:51 PM
 #681


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.


Ok, that was sloppy. When initializing the contract,
define cutoff = block.number + N. Then increment while
block number <= cutoff. And if you're lucky, you get to
do that N times.

“God does not play dice"
"The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime." -- Satoshi
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714002692
Hero Member
*
Offline Offline

Posts: 1714002692

View Profile Personal Message (Offline)

Ignore
1714002692
Reply with quote  #2

1714002692
Report to moderator
smooth
Legendary
*
Offline Offline

Activity: 2968
Merit: 1198



View Profile
March 15, 2016, 02:38:25 PM
 #682


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.


Ok, that was sloppy. When initializing the contract,
define cutoff = block.number + N. Then increment while
block number <= cutoff. And if you're lucky, you get to
do that N times.

I'm not sure what you are trying to accomplish, but this will simply count how many times the contract is executed before it expires. Nothing random about that, its just a counter.

YarkoL
Legendary
*
Offline Offline

Activity: 996
Merit: 1012


View Profile
March 15, 2016, 02:56:21 PM
 #683


I'm not sure what you are trying to accomplish, but this will simply count how many times the contract is executed before it expires. Nothing random about that, its just a counter.


This

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

Although I'm not incrementing until next block (which would execute only once), but until block is
at certain height.

“God does not play dice"
smooth
Legendary
*
Offline Offline

Activity: 2968
Merit: 1198



View Profile
March 15, 2016, 03:20:01 PM
 #684


I'm not sure what you are trying to accomplish, but this will simply count how many times the contract is executed before it expires. Nothing random about that, its just a counter.


This

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

Although I'm not incrementing until next block (which would execute only once), but until block is
at certain height.

As I said, all that will do is count how many times the contract is involved. How is that useful?

YarkoL
Legendary
*
Offline Offline

Activity: 996
Merit: 1012


View Profile
March 15, 2016, 03:26:14 PM
 #685


As I said, all that will do is count how many times the contract is involved. How is that useful?

By incrementing, I meant adding 42 to a variable (ok, sloppy terminology again).

Not useful at all, but if I understood
you, you said it was impossible to do.

But perhaps you meant, impossible to
increment repeatedly within a single block interval.

“God does not play dice"
smooth
Legendary
*
Offline Offline

Activity: 2968
Merit: 1198



View Profile
March 15, 2016, 03:58:40 PM
 #686


As I said, all that will do is count how many times the contract is involved. How is that useful?

By incrementing, I meant adding 42 to a variable (ok, sloppy terminology again).

Not useful at all, but if I understood
you, you said it was impossible to do.

But perhaps you meant, impossible to
increment repeatedly within a single block interval.

No and it is not impossible to do that. A contract can be called multiple times in a block. It can also increment repeatedly during one execution. What it can't do is increment a nondeterministic number of times.

The discussion was about a nondeterministic output for use as a random number generator. The suggestion was to loop (an unknown number of times) until the next block is solved. That can't be done.
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2142
Merit: 1009

Newbie


View Profile
March 15, 2016, 04:14:25 PM
 #687

Doesn't the discussed problem mean that Ethereum is not Turing-complete?
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420
Merit: 257


View Profile
March 15, 2016, 04:20:17 PM
 #688

Doesn't the discussed problem mean that Ethereum is not Turing-complete?

In theory, nothing is. Our computers don't have infinite memory.

Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2142
Merit: 1009

Newbie


View Profile
March 15, 2016, 04:22:16 PM
 #689

In theory, nothing is. Our computers don't have infinite memory.

Good catch.
YarkoL
Legendary
*
Offline Offline

Activity: 996
Merit: 1012


View Profile
March 15, 2016, 05:17:09 PM
 #690

The discussion was about a nondeterministic output for use as a random number generator. The suggestion was to loop (an unknown number of times) until the next block is solved. That can't be done.


My bad. Sloppy reading, sloppy day.

However, I still think you could use block hash(es) as long
as the cost of generating proof-of-work to meet some predetermined
sequence exceeds the benefit from doing so.

More intricate attempt to get around this:
https://forum.ethereum.org/discussion/2031/randao-a-dao-working-as-rng

“God does not play dice"
smooth
Legendary
*
Offline Offline

Activity: 2968
Merit: 1198



View Profile
March 16, 2016, 01:10:56 AM
 #691

The discussion was about a nondeterministic output for use as a random number generator. The suggestion was to loop (an unknown number of times) until the next block is solved. That can't be done.


My bad. Sloppy reading, sloppy day.

However, I still think you could use block hash(es) as long
as the cost of generating proof-of-work to meet some predetermined
sequence exceeds the benefit from doing so.

Yes, but unfortunately it is likely impossible to determine what benefit might be achieved (across multiple contracts). I think TPTB has commented on this.

Quote

Also sort of works, but has other issues. Even in the best case the cost will be high.
AlexGR
Legendary
*
Offline Offline

Activity: 1708
Merit: 1049



View Profile
March 16, 2016, 02:20:28 AM
 #692

Also sort of works, but has other issues. Even in the best case the cost will be high.

If you know a way to break the system, even a "high" cost can be pretty low.

- Short the market (millions of dollars in a billion usd marketcap)
- Pay thousands of USD as a "price" to break it
- Break it
- Create market panic
- Close the short

Turn the "cost" to profit Cool
smooth
Legendary
*
Offline Offline

Activity: 2968
Merit: 1198



View Profile
March 16, 2016, 02:44:26 AM
 #693

Also sort of works, but has other issues. Even in the best case the cost will be high.

If you know a way to break the system, even a "high" cost can be pretty low.

I was unclear. I meant the cost (in terms of on-chain contract execution) to generate usable random numbers using this sort of multiparty protocol, not the cost to attack.

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420
Merit: 257


View Profile
March 16, 2016, 05:15:54 AM
 #694

Bottom line is that the block chain is applicable for recorded state transitions that can be proved to be correct from data internal to the block chain. It is not applicable to anything which requires subjectivity about data external to the state in the block chain.

So most everything people are proposing for Dapps, can't work without breaking the objective census mechanism and thus destroying the Nash equilibrium security of the consensus due to a Prisoner's dilemma over which is the consensus choice.

And validation will always end up centralized for any block chain (smart contracts or crypto currency) no matter which consensus design is chosen.

Ethereum will crash and burn eventually. For a while, they might be able to keep the market fooled with technobabble and centralized training wheels.

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420
Merit: 257


View Profile
March 16, 2016, 06:01:38 AM
 #695

Bottom line is that the block chain is applicable for recorded state transitions that can be proved to be correct from data internal to the block chain. It is not applicable to anything which requires subjectivity about data external to the state in the block chain.

So most everything people are proposing for Dapps, can't work without breaking the objective census mechanism and thus destroying the Nash equilibrium security of the consensus due to a Prisoner's dilemma over which is the consensus choice.

And validation will always end up centralized for any block chain (smart contracts or crypto currency) no matter which consensus design is chosen.

Ethereum will crash and burn eventually. For a while, they might be able to keep the market fooled with technobabble and centralized training wheels.

This even applies to the Internet of Things as you (or a hacker or the manufacturer) can program your things to lie, correct?

I was thinking on how to defend autonomous cars from hackers and thought a decentralized consensus network offered the best chance of secure/safe driving, but reading your posts, makes me think that it will either be a state system or off-ramped to a corporate system, but it can't be decentralized because the blockchain can only verify its chain in a decentralized manner--hope I'm reading this aspect correctly.

The only way to have an external data feed that is not binary is to delegate to a centralized source, because even if we use reputation (or stake deposits) to prevent Sybil attacks and take a vote, the problem is that such a vote only surely converges to a majority outcome if the choices are only binary (e.g yes or no). Otherwise we can get forks which disagree on the consensus choice.

So conceptually an Augur-like prediction market could work if the bet outcomes are binary. But this reputation consensus has to be integrated with the block chain consensus and can't be orthogonal to it. Augur's mistake is building a reputation consensus on top of Ethereum's separate (but not orthgonal!) consensus protocol, which thus destroys the Nash equilibrium and creates a Prisoner's dilemma over which is the consensus choice.

But an additional problem, is that reputation systems are a power vacuum that ultimately centralize to a winner-take-all due to the Iron Law of Political Economics.

And the flaws of proof-of-stake have been enumerated.

I'd be interested in seeing a proof-of-work consensus for binary outcome predication bets. But that will have serious problems if the binary outcomes are not objectively clear to all miners.

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420
Merit: 257


View Profile
March 16, 2016, 06:04:48 AM
 #696

Dapps, can't work without breaking the objective census mechanism and thus destroying the Nash equilibrium security of the consensus

And validation will always end up centralized for any block chain (smart contracts or crypto currency) no matter which consensus design is chosen.

Ethereum will crash and burn eventually. For a while, they might be able to keep the market fooled with technobabble and centralized training wheels.

Who cares,

the contract will still get processed

the central controller has no incentive to steal anyone's money and scatter the billion dollar community that was just created

community size is worth more than tech, case in point: bitcoin

"decentralization" is overrated

distributed liability is all that really matters today. In other words, having the ability to move the physical geographic location of the central node to another country without service disruption in order to escape government control is all that matters. That my friends is what the average Joe considers "adequate decentralization"

Nobody gives a shit about John Nash.

So until there is a better non-vaporware alternative to Ethereum (when they eventually crash and burn), the hype continues unabated

You don't seem to understand the failure caused by vested interests (case in point: Bitcoin's scalepocalypse) which makes your $billion adoption market implausible, which was the reason we needed decentralization. Case in point: Apple Pay's inability to scale because it competes against other vested interests.

Market caps are not adoption valuation. They are greater fool illusions, especially when one can't even calculate a P/E ratio in the case of crypto trash. When five MAD men carrying box cutters and riding camels buy ETH from themselves to create the illusion of a $billion market cap, I know crypto has turned into a cess pool going no where.


generalizethis
Legendary
*
Offline Offline

Activity: 1750
Merit: 1036


Facts are more efficient than fud


View Profile WWW
March 16, 2016, 06:44:07 AM
 #697

Dapps, can't work without breaking the objective census mechanism and thus destroying the Nash equilibrium security of the consensus

And validation will always end up centralized for any block chain (smart contracts or crypto currency) no matter which consensus design is chosen.

Ethereum will crash and burn eventually. For a while, they might be able to keep the market fooled with technobabble and centralized training wheels.

Who cares,

the contract will still get processed

the central controller has no incentive to steal anyone's money and scatter the billion dollar community that was just created

community size is worth more than tech, case in point: bitcoin

"decentralization" is overrated

distributed liability is all that really matters today. In other words, having the ability to move the physical geographic location of the central node to another country without service disruption in order to escape government control is all that matters. That my friends is what the average Joe considers "adequate decentralization"

Nobody gives a shit about John Nash.

So until there is a better non-vaporware alternative to Ethereum (when they eventually crash and burn), the hype continues unabated

You don't seem to understand the failure caused by vested interests (case in point: Bitcoin's scalepocalypse) which makes your $billion adoption market implausible, which was the reason we needed decentralization. Case in point: Apple Pay's inability to scale because it competes against other vested interests.

Market caps are not adoption valuation. They are greater fool illusions, especially when one can't even calculate a P/E ratio in the case of crypto trash. When five MAD men carrying box cutters and riding camels buy ETH from themselves to create the illusion of a $billion market cap, I know crypto has turned into a cess pool going no where.



The slow game (or so fast you lose your lunch money) game of "I'm making money; who cares if the tech is real or not?" is dangerous, not only for your bank account, but for those of us who want to look in the mirror and see that we are being as truthful as possible to ourselves in life. Lying to oneself by ignoring the flaws of a technology in an attempt for short term financial gains is the Russian roulette of bag-holding-- more luck than skill and more "you got what you deserve, dumbass"  than "I admire his courage."

tromp
Legendary
*
Offline Offline

Activity: 976
Merit: 1076


View Profile
March 16, 2016, 02:07:08 PM
 #698

When five MAD men carrying box cutters and riding camels buy ETH from themselves to create the illusion of a $billion market cap, I know crypto has turned into a cess pool going no where.

They can't just be buying from themselves. All the miners must be paid as well...
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420
Merit: 257


View Profile
March 16, 2016, 06:55:05 PM
 #699

Bottom line is that the block chain is applicable for recorded state transitions that can be proved to be correct from data internal to the block chain. It is not applicable to anything which requires subjectivity about data external to the state in the block chain.

So most everything people are proposing for Dapps, can't work without breaking the objective census mechanism and thus destroying the Nash equilibrium security of the consensus due to a Prisoner's dilemma over which is the consensus choice.

And validation will always end up centralized for any block chain (smart contracts or crypto currency) no matter which consensus design is chosen.

Ethereum will crash and burn eventually. For a while, they might be able to keep the market fooled with technobabble and centralized training wheels.

This even applies to the Internet of Things as you (or a hacker or the manufacturer) can program your things to lie, correct?

I was thinking on how to defend autonomous cars from hackers and thought a decentralized consensus network offered the best chance of secure/safe driving, but reading your posts, makes me think that it will either be a state system or off-ramped to a corporate system, but it can't be decentralized because the blockchain can only verify its chain in a decentralized manner--hope I'm reading this aspect correctly.

The only way to have an external data feed that is not binary is to delegate to a centralized source, because even if we use reputation (or stake deposits) to prevent Sybil attacks and take a vote, the problem is that such a vote only surely converges to a majority outcome if the choices are only binary (e.g yes or no). Otherwise we can get forks which disagree on the consensus choice.

So conceptually an Augur-like prediction market could work if the bet outcomes are binary. But this reputation consensus has to be integrated with the block chain consensus and can't be orthogonal to it. Augur's mistake is building a reputation consensus on top of Ethereum's separate (but not orthgonal!) consensus protocol, which thus destroys the Nash equilibrium and creates a Prisoner's dilemma over which is the consensus choice.

But an additional problem, is that reputation systems are a power vacuum that ultimately centralize to a winner-take-all due to the Iron Law of Political Economics.

And the flaws of proof-of-stake have been enumerated.

I'd be interested in seeing a proof-of-work consensus for binary outcome predication bets. But that will have serious problems if the binary outcomes are not objectively clear to all miners.

Whoops:

"The other thing we added was the ability to create multiple-choice markets. In the alpha we only had binary yes or no markets."

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420
Merit: 257


View Profile
March 16, 2016, 07:00:43 PM
Last edit: March 16, 2016, 07:20:25 PM by TPTB_need_war
 #700

When five MAD men carrying box cutters and riding camels buy ETH from themselves to create the illusion of a $billion market cap, I know crypto has turned into a cess pool going no where.

They can't just be buying from themselves. All the miners must be paid as well...

I bet the mining is largely a set of insiders who were told to borrow money and mine the shit out of it, because they would be part of the P&D. So I do believe the majority of the miners are cooperating with those who are executing this P&D.

Mining with GPUs doesn't mean widely held.

hv_ conjectured upthread that the Chinese are trying to obtain ETH in order to monopolize the coming switch to proof-of-stake consensus in Casper. Thus they would not be selling and they may be involved in the P&D by taking huge short positions, so they can scoop up the coins cheaply.

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:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!