Hacker News Reader

Disclaimer. I have skin in the game. I've been developing on the platform since the Frontier launch and I have some Ether holdings.

1. Checksums are available via the mechanism in https://github.com/ethereum/EIPs/issues/55

2. I don't have any experience mining. Maybe someone else can answer this.

3. If I recall correctly, this is being fixed in Serenity. Transaction validity will no longer require ether to be submitted with the transaction allowing miners to accept transactions that are paid for during their execution.

4. Ethereum only left Alpha/Beta on March 14th 2016, roughly two months ago. Until then there were clear warnings posted that there were likely to be bugs. I'm not aware of anyone losing money due to protocol errors. The losses I've read about are predominantly user error and errors in 3rd party software.

5. This seems like a clear lack of understanding of the intentional design of the system. If you could directly make HTTP queries from smart contracts it would be impossible to reach consensus on what the result of code execution was because two clients could get two different responses from the same query. Everything that the EVM executes has to be 100% deterministic. Take a look at http://www.oraclize.it/ for an example of how communication with the outside world can be done.

I hope that clears things up.

Account number checksums have been added, by using capitalization. 0xdEAdBeEF will be flagged invalid if the capitalization isn't correct.

Windows 1.0 had a vastly larger list of why it sucked. So did the early web, early versions of DOS, early hobbyist PCs, early microprocessors, heh, perhaps even von Neumann's IAS machine.

Use cases embody the most obvious value potential of a technology. If the various "it sucks" obstacles can be bridged, the value potential of the use cases gets realized.

So it follows that if the use cases are valid and highly valuable, and the problems can theoretically be bridged (at even a high cost), then there is very good chance that the problems will be addressed in the near future.

Well, addressed enough (pointing to Windows 3.1).

If you were saying this about blockchains in general, then I'd agree that this is a baby step in some awesome engineering.

But I'm talking explicitly about Ethereum. In that case it is awful, bad, no good software. I'm comparing it to our other proof-of-concept that seems to work rather well and avoid all those pitfalls: Bitcoin.

Bitcoin has been in production for seven years. In its first year it wasn't nearly so polished.

I think checksumming of addresses was very early there, at least it was in late 2010 when I first used bitcoin. It is quite basic thing and easy to implement. It should help people avoid losses and possible problems caused by trivial mistakes.

They were hoping a name registration scheme would catch on and people would largely use that instead of using addresses directly. It hasn't happened so far, so now they've added checksums (using capitalization).

To clarify, "they" here means Ethereum. Ethereum has checksums.

In fairness, Windows 1.0 wasn't advertising itself as the future of finance or using the inability of third parties to intervene to retrospectively fix errors as its chief selling point.

BOOM! You called it. Further, an interpreter that works, basic checksumming/hashing for integrity of most important data... things like this are mandatory minimums for something like this. I mean, the academic prototypes I find being done by undergrads often have more than that. These people's game-changing platform doesn't have the basics that undergrads throw together in weeks using widely available libraries as building blocks?

Doesn't inspire confidence.

Undergrads don't start with a formal spec and develop four independent client implementations simultaneously in different programming languages.

No, they develop at least one with minimum, basic features their formal spec depends on. Then another. Then another. Then another. Then, they have four.

Alternatively, several of them develop several components in parallel with constant communication to keep them in sync and with a spec. These have the minimum, basic requirements.

Then, there's security-focused products that... going by your statement... start with a formal spec that ignores basic, integrity checks then develop four implementations simultaneously also missing basics. "Not a great plan." (Tony Stark)

Can some explain how a block-chain scales? If every transactions needs to be stored on all market participants computers doesn't that blow up pretty quickly?

Think of it as an append-only database with 512 KB chunks. Once a chunk is written, it has a hash associated to it.

The next chunk will have the first line to the previous hash, showing data continuity.

Yeah, it's more complicated than that, but that's the raw essential basics.

There are a number of proposals. In bitcoin, sidechains (separate blockchains that get anchored to the main chain) are oft-touted, as is the lightning network. The idea is that only the most important / highest value transactions make it onto the main blockchain.

There are other approaches as well. Most actors don't need all past transactions- just the valid spendable outputs. Old txs could be pruned. You can also apply ideas from regular databases, like sharding.

The basic answer is that transactions are small and not everyone needs to store the whole chain. Even now storing the whole blockchain is slightly 'enthusiast'. I think it might go more in this direction in the future, but at the same time the cost of storing the entire blockchain on an SSD and the bandwidth to sync with the bitcoin blockchain are nearly trivial (the blockchain stands now at 75GB).

I think the likely evolution in the future is that most people won't store the blockchain, but that there will be multiple separate currencies and enthusiasts will store the blockchain for the ones they use or are interested in.

70gb in 7 years.. including cryptographic witness which is soon going to be segreted..

It doesn't. That's why they're dumb and will never succeed. You can only hand wave it away while raking in the VC money for so long...

Where is the VC money coming from in a crazy we funded project?

Just keeping the storage requirement down is pretty easy, at least on Ethereum. One of the clients (the Rust version) already prunes old history.

A more difficult task is making it so nodes don't have to see all the ongoing transactions. Ethereum is attempting that with a sharding scheme.

At present, as far as I know all of the scalability plans for Ethereum are theoretical. That said the plan thus far is:

Light Client Support allows for running a node that does not sync the full chain, but rather downloads and verifies only the small parts necessary to send transactions and read state.

Proof-of-Stake replaces Proof-of-Work which opens up options for things like parallelization.

Sharding is a plan to split the blockchain into many smaller chains that are all linked but operate largely independently, allowing for horizontal scaling of the network. Transactions within a shard are synchronous. Transactions across shards are asynchronous.

If you want a challenge and can contribute, some details are:

EIP 105 (Serenity): Binary sharding plus contract calling semantics

https://github.com/ethereum/EIPs/issues/53

Very technical open discussion here:

https://gitter.im/ethereum/research

I believe they also have weekly Google Hangout on Mondays.

There's a stackexchange with technical answers to most of these questions, such as:

http://ethereum.stackexchange.com/questions/191/how-can-i-se...

For #3, an introduction is:

https://blog.ethereum.org/2015/12/24/understanding-serenity-...

and the improvement proposal is: https://github.com/ethereum/EIPs/issues/28

For #1, there are checksums now, but the more interesting question and challenge is how would a decentralized registry/DNS be designed, that has reasonable anti-incentives for squatters?

https://github.com/ethereum/EIPs/issues/26

Regarding the gambling in your number 5, wouldn't the house generate a secret number (as randomly as it wishes), encrypt it, post it to a gambling contract, let people place bets on it, and finally reveal the decryption key to the contract?

> 5. The "Smart Contract" code is completely trapped within the Eth system. I can't query a website and check data from there, nor can I generate random numbers, nor can I do anything that isn't explicitly on the blockchain. That directly implies that gambling apps and similar are completely deterministic and knowable. Effectively, gambling on Eth isn't a random chance with an edge to the house; it's a mathematical guarantee that the house wins, and you lose.

Wouldn't the proof of work hashes be a good distributed source of entropy?

Possibly, but I can have my client delay-submit successful work as to game the system.

And when Ethereum switches to Proof-of-Stake, bad shit will happen. (Mainly, its when you wager eth coin on the fact you have a correct-work. Its not hard to see the badness from that...).

Not an expert, and this is limited in what you could use it for, but for gambling purposes, couldn't this be dealt with by using the next X hashes after the bet is placed, where X is a large enough number that the likelihood of the better being able to produce that many successful blocks in advance is nil.

So, at the simplest, you take a bet, and then use the next two hashes for your random seed to get a result. Even if a miner found a solution for the next hash and withheld it long enough to make a bet, he wouldn't have enough information to do better than random chance. And as I understand it, the entire blockchain relies on the fact that one miner shouldn't be able to generate two blocks faster than the rest of the mining pool. Increasing from two grants even greater certainty.

Of course, the trade off here is that you have to wait for X blocks to be generated after a random number is requested and before being able to use it. So, your gambler has to sit around a bit to find out if they win, rather than instant feedback. (Of course, for gambling, you can hide this with some pretty animations of a roulette wheel, dice, horses running, etc.)

I believe that's open to tampering by miners (more easily than a sybil attack, IIRC).

Yes, and there are gambling apps that use the block hashes. Miners have the option of throwing away blocks they don't like, but are likely to lose the block reward if they throw away a valid block hoping to find a better one. So as long as it's not a huge payoff, it works fine.

www.coindesk.com/turing-complete-smart-contracts/