nicksdjohnson

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.

Every single Ethereum dev I know - and pretty nearly everyone else in the community - owns far more ETH than they do DAO, if they own any DAO at all. So this 'explanation', which I see over and over again, just doesn't scan: The financially rational thing for anyone in that position to do is to maximise the value of the ether they have, not to try and rescue a proportionally small amount held in DAO tokens.

Disclaimer: I recently joined the Ethereum-go team. I have 30 ether worth of DAO tokens (and about 500 ether not invested in anything).

Hard as it may be to believe, there's a difference between things that don't interest you personally and things that are junk. And the existence of things that don't interest you somewhere does not automatically mean that everything there is crap.

Don't see the sort of kits you like being made? Join us! Innovate, and design your own!

Really? I see:

A DIY weather station kit that feeds its data to the Raspberry Pi: https://www.tindie.com/products/tmhrtly/airpi-kit/

DIY Amplifiers: https://www.tindie.com/products/diyourfaceoff/fully-assemble...

A DIY 8x8 LED games console: https://www.tindie.com/products/hotchk155/sixtyfourpixels-lo...

DIY musical instruments: https://www.tindie.com/products/hotchk155/le-strum-hack-it-y...

TTL Tennis for Two: https://www.tindie.com/products/wmbuchholz/ttl-tennis-for-tw...

Thanks for the thought. We don't accept donations, but if you like any of the stuff we sell on Tindie (https://www.tindie.com/stores/arachnidlabs/), feel free to buy it!

VIDs and PIDs are 16 bits, not 8.

It's signed "Executive Director"; regardless of their internal organisation, it's a statement from USB-IF.

tl;dr: You've set up the challenge in such a way that demonstrating any of the threat models against which client side crypto is weak would require compromising other layers of security first that are out of scope for the challenge.

The word was 'contrite'. You didn't set a time limit on your contest.

I'm guessing you're talking about the SRAM-based alternative I discussed at the end? Yes, that would be an option, as would an SD card. 64Mb would be enough for plenty of 256 kilobit slices.

I do prefer the idea of using EEPROM if I was going down that route, though, so it'd be more like a CPLD than an FPGA. I just need a good way to load the only bit of remaining discrete state - the output enables - on startup. My best idea thus far is to dedicate half the EEPROM to configuration data, store the latch states at address 0, and use two RC networks to create rising edges first on a register latch pin then on the highest address pin to latch in the config before enabling the EEPROM in 'operating mode'.

I got them done at Hackvana (hackvana.com, or #hackvana on irc.freenode.net); similar prices to Seeed, and excellent customer service.

I'm not sure about the maximum speed. The flipflop, for instance, has a delay of 14ns; if we take that as average, each slice has to go through 5 parts (input mux, LUT, flipflop, async select mux, output enable) for a total delay of 70ns, so in theory one slice could do about 14MHz. Since it's a ripple counter, I guess we should divide that by the number of slices, so 4MHz seems like a reasonable upper bound.