Bitcoin Forum
December 11, 2017, 06:07:11 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 83889 times)
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


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

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.

The Bitcoin software, network, and concept is called "Bitcoin" with a capitalized "B". Bitcoin currency units are called "bitcoins" with a lowercase "b" -- this is often abbreviated BTC.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1512972431
Hero Member
*
Offline Offline

Posts: 1512972431

View Profile Personal Message (Offline)

Ignore
1512972431
Reply with quote  #2

1512972431
Report to moderator
smooth
Legendary
*
Offline Offline

Activity: 1624



View Profile
March 15, 2016, 01:03:35 PM
 #682

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.

Yes, and all of these events will all each occur within the context of one block (which includes the transaction causing them to occur). It is impossible to write a program that "executes until the next block" or whatever it was that was suggested.

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

Sure that's another issue.
YarkoL
Legendary
*
Offline Offline

Activity: 978



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


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.

dev blog https://yarkol.github.io
BTC 18kHb54jqcpWEkuAkCFsGMzR6BMgYnpi2T
smooth
Legendary
*
Offline Offline

Activity: 1624



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


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: 978



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


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.

dev blog https://yarkol.github.io
BTC 18kHb54jqcpWEkuAkCFsGMzR6BMgYnpi2T
smooth
Legendary
*
Offline Offline

Activity: 1624



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


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: 978



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


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.

dev blog https://yarkol.github.io
BTC 18kHb54jqcpWEkuAkCFsGMzR6BMgYnpi2T
smooth
Legendary
*
Offline Offline

Activity: 1624



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


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: 1792

Newbie


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

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

Activity: 420


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

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: 1792

Newbie


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

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

Good catch.
YarkoL
Legendary
*
Offline Offline

Activity: 978



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

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

dev blog https://yarkol.github.io
BTC 18kHb54jqcpWEkuAkCFsGMzR6BMgYnpi2T
smooth
Legendary
*
Offline Offline

Activity: 1624



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

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: 1442



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

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: 1624



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

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


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

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


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

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


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

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
*
Online Online

Activity: 1204


Facts are more efficient than fud


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

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

Activity: 505


View Profile
March 16, 2016, 02:07:08 PM
 #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...
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!