The Ethereum Paradox

[YarkoL]

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.

[smooth]

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]

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

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.

[smooth]

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

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]

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.

[smooth]

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]

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

[TPTB_need_war]

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]

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

Good catch.

[YarkoL]

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

[smooth]

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.

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

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

[AlexGR]

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

[smooth]

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]

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]

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]

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]

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]

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]

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]

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.