Topic: The Ethereum Paradox - page 49. (Read 99876 times)

There is no dichotomy in the case of strict partitions for asset transfers. I will not repeat myself again.

Yes, exactly the point. Excluding partitions is against consensus and leads to a divergent mess. That's the dichotomy at hand; one the one hand including partitions is sub-optimal for the block producers but on the other hand, it is essential for the network.

You can put me on ignore if you like, but you will be doing yourself a disservice if you are unable to prove to yourself that including N partitions does not increase the likelihood of a block being orphaned by some factor of N.


This is exactly why I don't like Casper; the theory is a total mess. Just do the validation inside the partition in the first place, rather than putting the cart before the horse like that.

No you don't. And you are slobbering all over the thread. I guess I have to put you on ignore again.

Excluding a partition means the coin dies and thus their block rewards become worthless. You seem to not even comprehend Nash equilibrium. Really this is getting to be too much. You constantly waste my time. And you feel no remorse.


You seem to be incapable of remembering anything I write:

I understand perfectly. Under this model, the incentive for block producers is to exclude partitions from their blocks, because every partition they include increases the chance of their block being orphaned due to double spends. In fact, this is analogous to the problem faced by Iota.


A strict partition which is invalid serves no purpose that I can see?

You apparently still haven't comprehended that for a strict partitioning that obeys the Nash equilibrium, i.e. for transactions that are never allowed to cross-partitions, then the partition doesn't need a separate PoW nor separate block chain. It can be essentially merge-mined (but in the same block chain) without impacting the Nash equilibrium for the block producers. And my other point was that strict partitioning can't exist for scripting yet it can exist for asset transfers (e.g. crypto coin transactions).


You apparently still haven't understood the point. The blocks are not invalid when a strict partition is invalid.

Of course one might argue that strict partitioning (thus by definition is without cross-partition transactions) is not that flexible. But nevertheless the point remains that there is a design which refutes your assumption.

I think we're talking cross purposes then. I was talking about Ethereum as it is now, extended to handle partitions. I maintain Casper is an all around bad idea motivated by politics.

The thread is about Ethereum's promised future version named Casper which is supposed to introduce sharding (partitions). My gosh how did you miss that.

What is 'the' design? This is a thread about Ethereum, where full nodes do validation and miners produce blocks.


A partitioned network operates exactly like two independent networks. If invalid transactions propagate throughout a network, that network is in trouble, regardless of whether there are partitions or not.


My point is that if you allow block producers to produce invalid blocks, that will be gamed by those who do validate, leading to SPV miners being pushed out of business.


No need to take that tone.

You are clearly only thinking about your design here. Merging partitions increases the strength of the network; the only problem is providing the correct incentive to do the merge.

That is uncivil accusation against your Professor.

No. As usual when you fail to understand what has been written, you fill a thread with your nonsense and you refuse to grasp your mistake even after it has been explained to you over and over and over again.

Sorry I can't tolerate this any more monsterer.

I guess this is an example to me of why very smart people don't work on very complex projects with people who are not smart enough to work efficiently. I don't like to look down on others, because I hate when others do that to me. Normally I would prefer to respond pretending I am your peer and not desiring to gain any perception from readers otherwise. But I don't know how else to react your repeated insistence to force your inability to comprehend new concepts on everyone else. I would think you might be embarrassed enough from other times where you eventually realized I was correct, to go take some quiet time and try to figure out your mistake. The problem is you think I am wrong and your lack of respect for my superior expertise, is where your noise problem originates. I don't mean that to be condescending nor uncivil. Rather I just wish you would get in touch with reality. Let me demonstrate this reality to you again as follows...

Btw, I like questions. But I also like when the person asking, actually tries to understand and think what I meant rather than just deciding to view it in only one way. And declare the Professor wrong.


#1 does not apply because the design is such that validation is split between partitions. This has been explained to you numerous times! #1 would be a design without partitions and where every full node verifies every transaction, which obviously can't scale decentralized and which due to economics that I explained will always end up centralized. It is a dead design. Bitcoin and Nxt (which is now run by a dictator) have proven these designs end up centralized as I predicted in 2013 (back when people like you said I was loony).

#2 is why the design for partitioning (or delegation of validation) has to maintain a Nash equilibrium, meaning the requirement that there exists no game theory advantage for partitions (or delegates) to lie about their validation. This point about Nash equilibrium has been explained to you numerous times!


Are you fucking blind?

Let me quote again the part that renders your underlined complaint irrelevant:


Why can't you read and comprehend what you are reading! Fuck man. It is very frustrating to deal with someone like you who can't even add 1+1 together to realize what is being said.

The point is that in the cases where Nash equilibrium is maintained, then there is no lying which renders the block invalid.

The case of strict partioning which I explained upthread does not cause the block to be invalidated if the partition lied (and I think I explained in my video too)! Did you forget that again. Do I need to go quote that upthread statement by me again! Because the partitions are independent, thus a partion can be invalidated without needing to invalidate the entire block (i.e. the next block corrects the partition in the prior block by providing a proof-of-cheating).

What you are saying makes no sense at all. There are two possibilities as I see it:

1. Invalid transactions arrive in the hands of the block producers. This implies the network as a whole has failed because invalid transaction should not be propagated.

2. Block producers produce blocks containing invalid transactions due to lack of validation. Their blocks will be orphaned by block producers which do validate, which is a net loss for those who don't, forcing these SPV miners out of business and causing centralisation.


I don't agree with this assessment either. In a partitioned system which requires a cross partition transaction, this new transaction merges the two partitions; it places a ordering constraint on both partitions which forces the new transaction to be located after the two points of dependency (both parents).

Users are going to chose randomly because they have no reference point nor game theory incentive to base some priority on choosing non-randomly which transactions to validate. And I will probably make the transaction(s) they validate be those identified by the PoW share hash they must submit with their transaction.

Users have the incentive to validate, because it is an insignificant cost (perhaps some milliseconds of work every time they submit a transaction) and they have every incentive to make sure the block chain's Nash equilibrium isn't lost by a cheating centralized verifier. Also there may be a Lotto incentive where they win some reward by revealing a proof-of-cheating. There is no game theory by which users are better off by not validating, i.e. an individual failure to validate a subsample doesn't enable the user to short the coin. That was a very clever breakthrough insight (simple but still insightful).

Note my idea could also be applied to partitioning, so if centralized validators can't scale then I would still support partitioning (and even for scripts!), but I think partitioning and reputations of multiple validators muddles the design and also muddles the economics (i.e. I think the validators will end up centralized within a partition any way due to economics).

Note also that users can't normally validate constraints from the UXTO because they aren't full nodes. So they will be depending on a full node to relay to them the correct records from the UXTO, but these can be verified (by the non-full node users) to be correct from the Merkel trees.

So this is why I said maybe Ethereum should perhaps try to hire me, but I also wrote a paragraph upthread saying basically "do not hire me". Hope readers don't think I am begging for a job. Geez.

monsterer w.r.t. to the underlined, I grow very weary of you subjecting all of us to your pretending you are some sort of expert. You may be expert on bitcoind (presumably you are given you created an exchange and btw I am ignorant of bitcoind specifics although I understand the conceptual aspects I need to know to do my design theory).

I have no idea why you can't comprehend what I already explained:


The point is the block producers only need hashes of the partitions. They don't have to verify every transaction. I explained that this maintains Nash equilibrium in certain scenarios:


It seems monsterer that you have an inflexible mind. You can only see things in one way which is what you already understand about how bitcoind works. There are other possible designs.

If validators lie so convincingly, the whole network is lying and you have a lost cause. Transactions will not propagate to the block producers in all other cases.

Apparently Ethereum is attempting to correctly use the terminology of verification vs. validation then.

Here's a little off-topic excursion regarding these words,
explaining why I brought this issue up....

In software testing community those mean different things
(verified means that the software runs without
apparent bugs, valid that it does what reads in the specs).

Somehow I got it in my head that verification in Bitcoin means checking that the
construction of the transaction is formally correct (has min txfees, no two
coinbases etc) whereas validation means checking that the inputs have
been unspent and evaluating the script. But it appears that there is no
such distinction in the documentation, and validation indeed is the same
as verification. Still I think it would be useful to assign different meanings
to these terms.

That is why I said the problem is more acute for Ethereum and verifying long running scripts. That has been one of my main points about why Ethereum can't scale (at least not decentralized).

Also realize even in the case of Bitcoin eventually scaling can outrun the costs of PoW, especially as block reward declines to 0 and assuming block size is allowed to increase so that transaction fees don't skyrocket.

Of course Bitcoin is already broken, because the Chinese mining cartel controls 65% of the hashrate and they lied about the Great Firewall of China being a problem[1] because they really want to veto block size increases so they can maximize their profits via spiraling transactions fees which I predicted in 2013. And remember my point that on the next block reward halving (this year I think) then the lowest cost miners will survive and the marginal miners will lose profitability and thus China's 65% share will increase significantly. I also believe Chinese miners are operating with near 0 cost electricity with a "wink and a handshake" charging the electricity cost to the collective society.

[1]	We know they are lying because they can put a pool abroad and send only a block hash across the GFW thus bandwidth is not an issue. They are clearly lying!

But that underlined wasn't the problem. Did you forget the point about the Nash equilibrium and all validators needing to trust that the validators from other partition didn't lie.

Agreed. This is not very compute intensive, though, compared to PoW.


My point is that validators don't lie without the entire network lying. That applies within partitions as well.

Validating (a.k.a. verifying) also means checking that it isn't a double-spend, that the funds exist (either via UXTO or account balance).

In a partitioned design, only the full nodes (a.k.a. validators) for each partition would validate and propagate the transactions for that partition. So yes you are correct to imply that partitioning means the P2P network is partitioned also (because otherwise DDoS spam amplication attacks would be plausible if peers relay that which they do not verify).

I think all that should have been clear just by thinking about the only way partitioning can work. I am just wondering why you can't deduce these sort of things and instead need to ask?

Note that validators can be computing a PoW block based on a hash of their partition and a hash of all the other partitions. Don't forget the power of Merkel trees.