Tuur Demeester's Ethereum claims


#65

Rejected
Plasma is dead: https://www.coindesk.com/as-plasma-stalls-snarks-become-new-hope-for-scaling-ethereum

Plasma isn’t dead: https://blockchainatberkeley.blog/plasma-isnt-dead-7d0b8c16ad2e

Plasma is very real and very much still actively under development, despite a few iterations live in wild, ex. Loom Network, Bankex implementations of Plasma Cash. One need only look at ethresear.ch and filter on the Plasma tag to see as much.

Additional implementations in R&D including:

Plasma XT: https://ethresear.ch/t/plasma-xt-plasma-cash-with-much-less-per-user-data-checking/1926

Plasma Snapp: https://ethresear.ch/t/plasma-snapp-fully-verified-plasma-chain/3391


#66

I tend to disagree here. I’m what you all would probably consider a lay person (not dev, not an engineer, not a scientist or researcher, just a dude with an InfoSec background), but I’m able to digest and follow directions for technical processes, so maybe not. I have three nodes running on basically spare devices I had lying around including a Lenovo X1 Carbon from 2013 with a 256gb SSD. SSDs are relatively cheap these days. Yea you can’t run a full node on a raspberry pi that I know of, but we also have to think about why a regular user would run a full node. Satoshi envisioned regular users relying on SPV/light clients. Not every user needs a full node. I think for the spectrum of users that need a full node, the requirements are still well within the bounds of affordable and “easy enough.”


#67

Confirmed w/ caveat - Weak subjectivity is a valid concern for PoS-based chains. However, Vitalik has provided mitigations that are incorporated into the current spec https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/ . Additional mitigations in the event of a mass exit scenario being discussed on ethresearch https://ethresear.ch/t/exploring-worst-case-scenarios-in-eth-2/4566/10


#68

Rejected - This is an overgeneralization of all PoS. PoS was abandoned by the Bitcoin community due to nothing-at-stake and chain reorg attacks. https://bitcointalk.org/index.php?topic=1382241.0 Casper has mitigations such as slashing to mitigate nothing-at-stake, a computational resource requirement ( C ) for running a validator (which are limited to 32eth deposits, meaning for every 32ETH you wish to stake you must run 1 additional validator of cost 1C), and an inactivity leak to prevent liveness denial attacks. Additionally epochs with checkpoint prevent deep chain reorgs and in 1.x/2.0 the PoW chain is used to provide finality.


#69

Unconfirmed - Seems to be an unsubstantiated opinion. Casper FFG contract was was in peer review and formal verification before it was deprecated (https://github.com/runtimeverification/verified-smart-contracts). Casper specs in general have been routinely updated and posted to arxiv, and dispersed for peer review. Even incomplete CBC as noted earlier. No evidence to back this claim. Runtime Verification / Phil Daian may be able to shed more light.


#70

Refuting argument:

@vbuterin on Reddit yesterday:

I try to credit people whenever I can; half my blog and ethresear.ch posts have a “special thanks” section right at the top. Sometimes we end up re-inventing stuff, and sometimes we end up hearing about stuff, forgetting it, and later re-inventing it; that’s life as an autodidact. And if you feel you’ve been unfairly not credited for something, always feel free to comment, people have done this and I’ve edited.


#71

Confirmed w/ caveat - PoS is not being presented as a “utopia of perpetual income.” It’s also not “free money” as most Bitcoiners wrongly claim. There are devops requirements and computation resource requirements to run a validator. Downtime = loss of locked ETH, opportunity cost of locking up ETH/capital, etc.

Also, I question anyone who thinks basically ten lines of code is a major deterrent. Ethereum Classic didn’t seem to be deterred by it, and they forked it out as any fork with capable developers could easily do: https://www.google.com/amp/s/bitcoinmagazine.com/articles/ethereum-classic-hard-forks-diffuses-difficulty-bomb-1484350622/amp/


#72

Rejected - Any blockchain is subject to hard-forks that can “fork anything away.” Even Bitcoin despite its staunch position against hard forks. This is an oversimplification of a complex process. Nodes must agree and update or can abstain, users must switch/adopt, and market must value. The premise that Ethereum developers can simply fork things out at will and retain its users, nodes, not suffer a contentious split, and still retain its value in the market is silly.


#73

Rejected - Tuur seems to be inferring this on his own. I can find no reference to claims that Solidity can be picked up and used as easily as Javascript. The choice to use jscript-like syntax was for ease of on-boarding, but no one claimed it was as easy to develop smart contracts as javascript applications. The information here seems to preach it as absolutely not being as easy as traditional javascript app development: https://solidity.readthedocs.io/en/latest/


#74

Confirmed w/ caveat - This is a sensationalist argument that keeps making the rounds. Is there any point in lay persons running full nodes if they don’t understand what it does, or how they can use it to verify in the first place? Satoshi advocated regular users use SPV light clients http://satoshinakamoto.me/2010/05/18/re-ummmm-where-did-my-bitcoins-go/#selection-57.0-61.146 why is Ethereum held to a different standard for normal users? I consider myself a lay person having a liberal arts degree and working primarily in infosec and have synced 3 full block verifying nodes within the last three months (130gb chain data size, on consumer grade PCs/laptops with standard SSDs that cost me 50 buck each). One even on a Windows 10 machine with the simplified configuration .toml generated from Parity’s toml generator (https://paritytech.github.io/parity-config-generator/ ), vs the others on Linux with command line arguments. I don’t think ‘parity —no-warp —cache-size 1024’ is beyond anyone’s capability who is familiar with CLI. Takes some time to sync (4ish days now) but so do Bitcoin full nodes. Screenshots of the Windows 10 node: https://twitter.com/cyber_hokie/status/1056894307670614018?s=21

Also: https://twitter.com/killerstorm/status/1053156669893591042?s=21


#75

Partially Confirmed - Full ARCHIVAL Node requirements are centralizing to services like Infura. Unclear what effect that has as non-archival nodes can broadcast and that is far less centralized. Historical balance look ups and intermediate state information would rely on those services. It’s not impossible to run an archival node if you need to, people are just electing to trust archival node providers which is their prerogative. Trust is after all a highly personal choice and a risk based decision.

However, the part about the Ethereum community claiming that warp sync nodes being “just as good as a full node” is something Tuur’s mind must have cooked from a lack of basic understanding. No one has ever made that claim and he is clearly mistaking warp sync nodes for “no-warp” full nodes which fully verify all blocks on sync. Pruned nodes also fully verify all blocks, only state is pruned. https://twitter.com/5chdn/status/999054207293493249?s=21


#76

Confirmed w/ caveat - “Institutional hard-forks” attempts to diminish how forks work and imply a central entity can force rules on nodes. This shows a lack of insight in how forks proceed and galvanize over time. Nodes run code… it is their prerogative. Other “figures” are irrelevant and signaling tools (e.g. carbonvote) are simply for practical decision making of client dev teams, and are not concrete (client devs can after all deploy whatever code they want). If nodes do not agree they can hold out or downgrade. ETC’s mere existence proves this point. There is no such thing as a “forced” hard fork. Participants will always do what is in their best interest / aligns with their motives in accordande with the greater game at hand. Always. Even with a difficulty bomb deterrent. The minority can always fork off (whether they survive is another question entirely). Nodes upgrade/don’t, users follow the side that aligns with their interests, market values accordingly. There is an irrational fear of the uncertainty surrounding hard forks, and as we know Bitcoin loathes uncertainty even if it means putting up with an unsilent minority that questions every move the core developers make. Why wouldn’t you want to give them a route out? How soon we forget the events of SegWit 2x, the lobbying, the signaling (#UASF) that had the same effect Tuur is protesting here.


#77

Rejected - The agreement was to help advise on the VEB’s own blockchain projects and research as a SME. Nothing to do with the Ethereum public blockchain or EF specifically: www.coindesk.com/misunderstanding-vitalik-buterin-create-new-entity-russian-bank-deal

There are 8 active client dev teams, and more researchers than ever before. Vitalik’s voice has shrunk as he has stepped back further and further into a “just another researcher” role. Anyone who thinks Ethereum is centralized to Vitalik doesn’t listen to the All Core Devs, ETH 2.0 implementers, or Plasma Implementers calls I would guess.

A wild Vitalik appears! He whispers in your ear “runnnn myyyy codeee.” A wild Vitalik vanishes!


#78

Rejected - No evidence of credentials provided either way. Has he collected CVs? Look at guys like Vitalik, Greg Colvin, Nick Johnson, Justin Drake, Virgil Griffith, Raul Jordan, Phil Daian, Joseph Poon (you know that guy who conceptualized Lightning Network) and many more, this just doesn’t hold water.


#79

Rejected - Gish galloping? I’ve never seen anyone refer to Lucius as pivotol to Ethereum scaling in any way. Also, Rchain is not an “Ethereum scaling company,” it’s technically a competitor, and a completely separate blockchain platform, https://www.rchain.coop


#80

Rejected - Preethi already noted the current working position of the SEC.

However the rest is kind of laughable and shows very little research. There were testnets and open source github repos https://blog.ethereum.org/2015/05/09/olympic-frontier-pre-release/. Also, the Ethereum repos were created in early 2014. For example the first Go-Ethereum POC was added in February 2014 https://github.com/ethereum/go-ethereum/releases?after=poc5-rc1


#81

Refuting argument:

The lightning network grew during 2018 to hold $2mil worth of BTC. MakerDAO on Ethereum grew considerably more (https://twitter.com/sassal0x/status/1072248386114412545).

Status: Confirmed w/ caveat - The lightning networks growth can only be considered “rapid” if you compare it against itself. Other services, such as MakerDAO and Compound, grew considerably more.


#82

Supporting argument:

Plasma is dead: https://www.coindesk.com/as-plasma-stalls-snarks-become-new-hope-for-scaling-ethereum

Refuting argument:

Plasma isn’t dead: https://blockchainatberkeley.blog/plasma-isnt-dead-7d0b8c16ad2e

Plasma development is increasing at a rapid pace (https://github.com/ethhub-io/ethhub/blob/master/ethereum-roadmap/layer-2-scaling/plasma.md) with multiple teams developing with it (https://medium.com/loom-network/plasmachain-gamechain-socialchain-the-loom-network-universe-expounded-5c672617a333) and implementations/specs being figured out.


#83

Refuting arguments:


#84

Supporting argument:

“Marketing hype” may be referencing the Enterprise Ethereum Alliance (EEA) or a lot of the work that teams building on top of Ethereum are doing. Obviously the ICO craze led to a lot of hype but this has nothing to do with Ethereum itself.

Refuting argument:

Outside of the above supporting argument, there doesn’t seem to be any other direct marketing hype from the Ethereum Foundation, core developers or other prominent community members.