Bitcoin Forum
December 14, 2017, 10:56:30 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)
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
March 03, 2016, 11:27:01 AM
 #381

That doesn't matter (or actually it makes the problem I explained more obvious). The script validation and the gas spend confirmation must be atomic, which means they must be confirmed in the same partition, else validation can not be partitioned per the logic I already explained.

They will be - the gas is paid inside the same transaction which invokes the script?

edit: but, of course that does invoke the horror of double spends - since partitions are necessarily separate and unaware of each other, I can spend the same gas in multiple partitions at the same time.

You got it with your edit.

Of course the virtual machine assumes they are atomic as you first stated, but the reality of the sharding is they can't be.

Building the virtual machine was the fun, easy part. The consensus scaling was the hard part which they should have done first even before raising ICO money. That is disgraceful.

1513248990
Hero Member
*
Offline Offline

Posts: 1513248990

View Profile Personal Message (Offline)

Ignore
1513248990
Reply with quote  #2

1513248990
Report to moderator
1513248990
Hero Member
*
Offline Offline

Posts: 1513248990

View Profile Personal Message (Offline)

Ignore
1513248990
Reply with quote  #2

1513248990
Report to moderator
1513248990
Hero Member
*
Offline Offline

Posts: 1513248990

View Profile Personal Message (Offline)

Ignore
1513248990
Reply with quote  #2

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

Posts: 1513248990

View Profile Personal Message (Offline)

Ignore
1513248990
Reply with quote  #2

1513248990
Report to moderator
1513248990
Hero Member
*
Offline Offline

Posts: 1513248990

View Profile Personal Message (Offline)

Ignore
1513248990
Reply with quote  #2

1513248990
Report to moderator
1513248990
Hero Member
*
Offline Offline

Posts: 1513248990

View Profile Personal Message (Offline)

Ignore
1513248990
Reply with quote  #2

1513248990
Report to moderator
monsterer
Legendary
*
Offline Offline

Activity: 1008


View Profile
March 03, 2016, 11:29:43 AM
 #382

You got it with your edit.

Of course the virtual machine assumes they are atomic as you first stated, but the reality of the sharding is they can't be.

Building the virtual machine was the fun, easy part. The consensus scaling was the hard part which they should have done first even before raising ICO money. That is disgraceful.

The only way around this that I can see is to make Ether non fungible, which is a bit of a problem for a currency.
hv_
Hero Member
*****
Offline Offline

Activity: 672


View Profile
March 03, 2016, 12:18:07 PM
 #383

You got it with your edit.

Of course the virtual machine assumes they are atomic as you first stated, but the reality of the sharding is they can't be.

Building the virtual machine was the fun, easy part. The consensus scaling was the hard part which they should have done first even before raising ICO money. That is disgraceful.

The only way around this that I can see is to make Ether non fungible, which is a bit of a problem for a currency.

Than the circle is closed since they initially said it's not a ccy, but fuel.

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 03, 2016, 12:57:31 PM
 #384

You got it with your edit.

Of course the virtual machine assumes they are atomic as you first stated, but the reality of the sharding is they can't be.

Building the virtual machine was the fun, easy part. The consensus scaling was the hard part which they should have done first even before raising ICO money. That is disgraceful.

The only way around this that I can see is to make Ether non fungible, which is a bit of a problem for a currency.

Even that wouldn't work because as you pointed out, the entity running the script pays the gas, and that entity can not in every case have its gas balance in the partition that validates the script.

But gas never was going to work economically any way, because all the validators need to be compensated, not just the one who wins the block. Any means of equal sharing the gas between all validators will be Sybil attacked (again any arguments about changing this reality via consensus-by-betting would return to the fact that proof-of-stake or deposits are self-referential and all that entails). And any non-equal sharing means the consensus becomes centralized over time according to the rule that the one with the most resources has the most economies-of-scale.

ilia7777
Jr. Member
*
Offline Offline

Activity: 38


View Profile
March 03, 2016, 01:10:11 PM
 #385

TPTB_need_war its really hard to follow your arguments without specific example. If you understand this deep enough give us specific code example which will illustrate what you are talking about. Without an example it seems very high level abstract esoteric discussion.
stoat
Sr. Member
****
Offline Offline

Activity: 322


View Profile
March 03, 2016, 01:13:15 PM
 #386

TPTB_need_war its really hard to follow your arguments without specific example. If you understand this deep enough give us specific code example which will illustrate what you are talking about. Without an example it seems very high level abstract esoteric discussion.

Its pathetic really,  an ill (mentally and physically) and extremely jealous (old) man pouring incomprehensible and entirely premature FUD on software that no one knows the inner workings of because it isn't even released yet.


Apparently casper wont work because of some obscure mathematical principles which only this self proclaimed genius is able to understand and is incapable of explaining.

0x8d1b4e41652eacec5715dc5c4833f6b713573de6 If you agree with me, please support a friend of mine in need.
StinkyLover
Sr. Member
****
Offline Offline

Activity: 420


This industry is pure fiction


View Profile
March 03, 2016, 01:18:39 PM
 #387

TPTB_need_war its really hard to follow your arguments without specific example. If you understand this deep enough give us specific code example which will illustrate what you are talking about. Without an example it seems very high level abstract esoteric discussion.

Its pathetic really,  an ill (mentally and physically) and extremely jealous (old) man pouring incomprehensible and entirely premature FUD on software that no one knows the inner workings of because it isn't even released yet.


Apparently casper wont work because of some obscure mathematical principles which only this self proclaimed genius is able to understand and is incapable of explaining.

But yet this FUD troll 'crypto genius in his own head' will milk it for all it's worth with very long posts that no-one wants to read Cheesy
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
March 03, 2016, 01:22:36 PM
 #388

TPTB_need_war its really hard to follow your arguments without specific example. If you understand this deep enough give us specific code example which will illustrate what you are talking about. Without an example it seems very high level abstract esoteric discussion.

I ask you first where is the code example in Satoshi's white paper which explains a 51% attack? Hint: there isn't one because it doesn't have anything do with any specific implementation code, but rather is a mathematical structure.

Why don't you try to articulate what parts you understand and what parts you don't, then I will elaborate once I see where your blind spot(s) are. If you are unwilling to do so, then I will presume you are trolling (from a newbie account with 2 posts) as are the other panic-stricken trolls.

hv_
Hero Member
*****
Offline Offline

Activity: 672


View Profile
March 03, 2016, 01:26:54 PM
 #389

TPTB_need_war its really hard to follow your arguments without specific example. If you understand this deep enough give us specific code example which will illustrate what you are talking about. Without an example it seems very high level abstract esoteric discussion.

Not really needed, just watch that ETH-DEVs video upthread and try to get just a faint feeling for how close they are to a proper solution for Casper.

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
ilia7777
Jr. Member
*
Offline Offline

Activity: 38


View Profile
March 03, 2016, 01:32:25 PM
 #390

TPTB_need_war its really hard to follow your arguments without specific example. If you understand this deep enough give us specific code example which will illustrate what you are talking about. Without an example it seems very high level abstract esoteric discussion.

I ask you first where is the code example in Satoshi's white paper which explains a 51% attack? Hint: there isn't one because it doesn't have anything do with any specific implementation code, but rather is a mathematical structure.

Why don't you try to articulate what parts you understand and what parts you don't, then I will elaborate once I see where your blind spot(s) are. If you are unwilling to do so, then I will presume you are trolling (from a newbie account with 2 posts) as are the other panic-stricken trolls.

For starters explain what do you mean by saying that gas can't be partitioned ?
monsterer
Legendary
*
Offline Offline

Activity: 1008


View Profile
March 03, 2016, 01:38:11 PM
 #391

Even that wouldn't work because as you pointed out, the entity running the script pays the gas, and that entity can not in every case have its gas balance in the partition that validates the script.

All the balances would have to be local to the partition and not shared - effectively like a fork of ETH for each partition.

edit: I'm considering the possibility of whether an inter partition transfer of ETH would be possible if the partitions merged once during the transfer and then split apart again post transfer block.
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
March 03, 2016, 01:43:43 PM
 #392

Even that wouldn't work because as you pointed out, the entity running the script pays the gas, and that entity can not in every case have its gas balance in the partition that validates the script.

All the balances would have to be local to the partition and not shared - effectively like a fork of ETH for each partition.

And then how would a user who has his gas in partition 536 run a script that runs only in partition 1279?

Hint: he can't. Thus you would have entirely broken Ethereum with your suggestion.

edit: I'm considering the possibility of whether an inter partition transfer of ETH would be possible if the partitions merged once during the transfer and then split apart again post transfer block.

I already explained that cross-partition spending is possible (i.e. won't destroy the Nash equilibrium) only if validation of all partitions is done by all validators, which thus defeats the scaling advantages of making partitions (shards).

You even agreed with this upthread wherein you stated that validators can't decide which block to mine on if they don't validate all transactions in the block.

Edit: in case this isn't clear, let me remind readers and you that I had explained upthread that when validator that is responsible for validating only his own partition has to accept a spend from a partition he did not validate, then he has no way to know if that balance from the other partition was a lie or not. Thus he can't accept it, because his reward may be compromised if later it is shown that he accepted an invalid balance from a partition he did not validate.

ilia7777
Jr. Member
*
Offline Offline

Activity: 38


View Profile
March 03, 2016, 02:01:31 PM
 #393

Let me ask a stupid question here. How a user can have gas in one partition and not to have gas in another ? Are you saying that a user had spent his gas but it didn't get validated by the system ?
monsterer
Legendary
*
Offline Offline

Activity: 1008


View Profile
March 03, 2016, 02:08:16 PM
 #394

I already explained that cross-partition spending is possible (i.e. won't destroy the Nash equilibrium) only if validation of all partitions is done by all validators, which thus defeats the scaling advantages of making partitions (shards).

You even agreed with this upthread.

I agree in general, but I wonder if there is more to this than it first seems. Yes it is true that merging two partitions into a block will need the block producer to validate both partitions to construct his new block, but that's not to say he necessarily has to keep validating both - if the partitions split apart again afterwards, for example that wouldn't be necessary.

You could formalise this such that an inter partition spend requires the source and destination partitions to merge for the transfer block only, thereby defining a partial order and only incurring an ephemeral increase in validation costs.
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
March 03, 2016, 02:27:38 PM
 #395

I already explained that cross-partition spending is possible (i.e. won't destroy the Nash equilibrium) only if validation of all partitions is done by all validators, which thus defeats the scaling advantages of making partitions (shards).

You even agreed with this upthread wherein you stated that validators can't decide which block to mine on if they don't validate all transactions in the block.

Edit: in case this isn't clear, let me remind readers and you that I had explained upthread that when validator that is responsible for validating only his own partition has to accept a spend from a partition he did not validate, then he has no way to know if that balance from the other partition was a lie or not. Thus he can't accept it, because his reward may be compromised if later it is shown that he accepted an invalid balance from a partition he did not validate.

I agree in general, but I wonder if there is more to this than it first seems. Yes it is true that merging two partitions into a block will need the block producer to validate both partitions to construct his new block, but that's not to say he necessarily has to keep validating both - if the partitions split apart again afterwards, for example that wouldn't be necessary.

You could formalise this such that an inter partition spend requires the source and destination partitions to merge for the transfer block only, thereby defining a partial order and only incurring an ephemeral increase in validation costs.

And then the partition that has accepted the transfer of gas from a partition that it did not validate now will have all its derivative transactions (and scripts) subject to reversal if later someone shows evidence that the balance was a lie.

You are writing nonsense (and you should know it which is why I am not being entirely polite ... please don't feed the damn trolls because you are not careful to think before typing).

stoat
Sr. Member
****
Offline Offline

Activity: 322


View Profile
March 03, 2016, 02:29:42 PM
 #396

I already explained that cross-partition spending is possible (i.e. won't destroy the Nash equilibrium) only if validation of all partitions is done by all validators, which thus defeats the scaling advantages of making partitions (shards).

You even agreed with this upthread.

I agree in general, but I wonder if there is more to this than it first seems. Yes it is true that merging two partitions into a block will need the block producer to validate both partitions to construct his new block, but that's not to say he necessarily has to keep validating both - if the partitions split apart again afterwards, for example that wouldn't be necessary.

You could formalise this such that an inter partition spend requires the source and destination partitions to merge for the transfer block only, thereby defining a partial order and only incurring an ephemeral increase in validation costs.

And then the partition that has accepted the transfer of gas from a partition that it did not validate now will have all its derivative transactions (and scripts) subject to reversal if later someone shows evidence that the balance was a lie.

You are writing nonsense.


Vitalik and co. Will shard gas all over your nonsense FUD.

0x8d1b4e41652eacec5715dc5c4833f6b713573de6 If you agree with me, please support a friend of mine in need.
monsterer
Legendary
*
Offline Offline

Activity: 1008


View Profile
March 03, 2016, 02:38:55 PM
 #397

And then the partition that has accepted the transfer of gas from a partition that it did not validate now will have all its derivative transactions (and scripts) subject to reversal if later someone shows evidence that the balance was a lie.

You are writing nonsense (and you should know it which is why I am not being entirely polite ... please don't feed the damn trolls because you are not careful to think before typing).

Read what I wrote again more carefully Smiley
stoat
Sr. Member
****
Offline Offline

Activity: 322


View Profile
March 03, 2016, 02:51:36 PM
 #398

Do not reply to the panic-stricken technologically illiterate trolls.

How am I panic stricken.  I'm loving life right now.  You're the one who is literally dying of stress

0x8d1b4e41652eacec5715dc5c4833f6b713573de6 If you agree with me, please support a friend of mine in need.
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
March 03, 2016, 03:20:29 PM
 #399

And then the partition that has accepted the transfer of gas from a partition that it did not validate now will have all its derivative transactions (and scripts) subject to reversal if later someone shows evidence that the balance was a lie.

You are writing nonsense (and you should know it which is why I am not being entirely polite ... please don't feed the damn trolls because you are not careful to think before typing).

Read what I wrote again more carefully Smiley

Read what I wrote again more carefully. And make a rebuttal if you have one. Adding noise to the thread by writing this "read again" doesn't help at all. I read it already. I already explained why it doesn't make any sense. Where is your nonsense rebuttal?

Edit: for the source and destination partitions to merge (even for the history and not the future), means they need to validate each other's history. That is my point that then separate validation is lost. Thus the entire scaling advantage of partitioning is lost. Read again what I wrote! How can you not remember something I wrote just a few posts above:

I already explained that cross-partition spending is possible (i.e. won't destroy the Nash equilibrium) only if validation of all partitions is done by all validators, which thus defeats the scaling advantages of making partitions (shards).

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
March 03, 2016, 03:20:48 PM
 #400

Let me ask a stupid question here. How a user can have gas in one partition and not to have gas in another ? Are you saying that a user had spent his gas but it didn't get validated by the system ?

I need to start by explaining everything about block chains. You are ostensibly lacking the very basic levels of technical understanding. But there are no stupid questions if they are sincere. Probably many readers would have a similar confusion.

Normally the way a block chain works (whether it be proof-of-work or proof-of-share) is that there is one ordering of transactions and blocks that the system forms a consensus on. The key point is that every validator validates every transaction and every block, thus each validator can be sure that there is nothing invalid is the consensus ordering. Note that any particular ordering is arbitrary as there are other orderings that are also valid, but the consensus chooses one ordering from the many arbitrary valid possible orderings. The consensus never chooses an invalid set of transactions nor an invalid ordering.

But when every validator has to validate everything, then the block chain can't scale and remain decentralized.

So Ethereum proposed to shard (partition) the validation such that scripts are assigned to a partition and can only operate on block chain state that has been validated for that partition. Any state stored on the block chain for other partitions is only validated for those other partitions. In short, partitions can't share state, because the validators can't assume that state they did not validate is valid. Because such an assumption would put the validators in a Prisoner's Dilemma game theory wherein the Nash equilibrium collapses.

So thus gas balances being a block chain state could only be spent within their own partition. So thus if you as a user have your gas balance stored in partition 536 and you want to run a script in partition in 1279, then you can not (not without entirely breaking the mathematical model of the security of Ethereum).

The only way to fix that is to not do sharding. Period.

Thus Ethereum can't scale decentralized. Period. There is no fix they can do (at least not anything they are contemplating ... although I have an idea of how to solve this problem with unprofitable mining but I am the only person with that idea).

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!