nicksdjohnson's comments

Thanks!

This one is incredible! I've minted it so nobody else can grab it. If you have an Ethereum account, let me know your address so I can transfer it to you.

1T is a huge overcompensation. If you take Ethereum's estimated daily carbon output and divide it by its daily gas units (the unit by which computation is measured) and assign responsiblity that way, minting an Amulet consumes about 20KG CO2 emissions. Transferring one, about half that.

Speaking as an Ethereum core developer here - I see a lot of misdirected criticism and misunderstandings of Ethereum and the platform in the wider tech community. That said, your criticisms here are absolutely spot on; these are definite issues with Solidity as a smart contract programming language.

The only small correction I would make concerns this:

> Functions can mutate state by default. Both are overridable by explicit specifiers, much like C++ "const", but you have to remember to do so. Even then, the current implementation doesn't enforce this for functions.

When interacting with Ethereum you can do two things: send a transaction, or call a function against your local copy of the blockchain. The former is mutating, costs ether (in gas fees) and requires the transaction to be included in a block. The latter is entirely local, cost-free, and any mutations to state are ignored.

The 'constant' modifier in Solidity serves only to tag the resulting ABI of a function so that calls to it from common interfaces default to local calls instead of sending transactions. It's not intended to enforce that calls to that contract are read-only, only to indicate to callers that it should be called locally instead of creating a transaction for it.

Okay, I'll bite. What's 'centralised' about Ethereuem, without twisting the word beyond all recognition?

You seem to have very (some would say ridiculously) high standards for 'decentralised'.

If the root multisig was deleted, would it be 'decentralised' in your book?

> It claims it is a decentralised naming system, though looking deeper you will find it is just clever marketing and underneath is it is only ethereum-platform based naming for anything like your address etc. will only work in eth browsers, not all etc. which I have already mentioned in my OP.

It doesn't claim to be DNS. DNS is not the only naming system.

What's centralised about ENS?

Also, it can be used to resolve any resource you want - although you're shifting the goalposts, since that wasn't originally a requirement.

> There is not one single dapp that is decentralised and working.

Sure there is. ENS, for one example. Plenty of gambling apps for another (I don't find them particularly _compelling_, but they are there and they do work)

Censorship resistance isn't the main thing that blockchains enable; trustlessness is. If you host them on your own SQL database, people have to trust that you're acting honestly.

In all seriousness, you should lurk in the Ethereum subreddit instead.

We have our share of cheerleaders who take the black and white "this good, that bad" position without evidence, but they're not dominant, and we have a far larger proportion of developers who are interested in building cool technology and are able to look objectively at the problems involved.

But you can reason about what any possible transaction can do by reasoning about all possible inputs to your code; you don't need to know anything about how other contracts were written, since even if they are formally provable, they could send you literally any input.

Edit: Rereading your earlier comment, I understand now - you're talking about other contracts your code calls, not vice-versa. In that case, I'd point out that you're totally free to either write those contracts yourself if they're not already provably secure, or write your own code such that it's formally proved to work regardless of what those contracts do.

If you want to know what a given transaction will do, you can simply run it locally; no need for formal analysis. Formal analysis is useful for proving properties about your program like "the total balance will always equal the sum of the accounts" and "transfers never increase the sender's balance".

I don't think I follow - why would you need to reason about your callers' internal states in order to prove properties about your own contract?

But that's completely beside the point: the point is that you can't have the libertarian-utopia-chain without also getting the hacker-got-away-with-his-loot chain.

Sure it does - the marvelous thing about a turing-complete virtual machine is that you can write a decidable language that compiles to EVM bytecode.

I agree "smart contract" is a poor term, but they're way more than "conditional payment" - you can do a lot of things with them that have nothing to do with paying money.

> And my point was that if you look at ETH/ETC, the market is saying that they feel more comfortable with a known, trusted authority (i.e. small group of developers with trademarks and a conference schedule) than they do with true democratized first principles of immutable code.

But the fork wasn't a referendum on the governance model of Ethereum. If you picked ETC, you get your liberterian utopia - but you also get a chain where someone made off with 10% of the Ether supply.

> 1. The halting problem states you can't predict what a turing complete program will do, until you run it. This means to some degree, that you can't predict what your "smart" contract will do, until it does it. Thus turing completeness causes security to be far, far harder than non turing completeness. This is how you lose the millions of dollars as the DAO did after it passed audits.

While others have pointed out that this is wrong, it's worth amplifying: Turing machines are deterministic. You can run the contract locally and observe how it behaves, and it will behave the same way in the same environment elsewhere. If this wasn't the case, you couldn't have consensus at all.

> 2. Competing implementations of consensus code in different languages greatly increases breakdown of consensus. (more millions have been lost over this, and it created a fork at about 10 percent the value of the old chain.)

The DAO hard fork had nothing to do with a consensus failure. There's been one single short-lived mainnet fork due to a consensus issue, which was quickly resolved with - to the best of my knowledge - no financial loss.

Also, neither system's proof of work is based on NP-hard problems.