Live data from Hacker News

Final Steps

blog.ethereum.org

101–104 of 104 posts

Re: Final Steps

#101
post #93

Earlier quoted context omitted.

There's a lot of humanity problems solving talk in cryptocurrency land. I think it's because the people that run in that scene can finally glimpse what this technology can do, when wielded correctly. That said, there's still a lot to do before we replace the government with a crypto contract! Ethereum uses a cryptocurrency under-the-hood called 'ether', which pays for 'gas': compute resources like networking, storage…

You mean script, not scrypt.

Yes! Habit.

Re: Final Steps

#102
post #28

Earlier quoted context omitted.

Some important properties of ethereum: 1. A program written in ethereum can execute code at a predetermined point in the future, and there is as close to 100% certainty as possible that the code will execute as written (i.e. as long as a single ethereum user remains in the world at that date everybody's code is guaranteed to run exactly as written, even if it involves moving money between accounts.) 2. All computer p…

>4. Program authors are forced to explicitly document ahead of time all situations in which their program code might be modified in the future Can you point me to a resource that explains this in more detail? I think I've gotten the gist of how Ethereum works, and have gone through a tutorial of Solidity, but I'm unclear how versioning will work in Ethereum (even though I do have some guesses for how it could be impl…

If you want your contract to be updateable, you can have the contract store an address of a contract which is the part you might want to change. Then, to update the contract, you upload the new version of the contract ( or contract component) , and make the address that the first contract stores point to the new one.

Uh...

Users interact directly with contract A.

Contract A stores a address which currently points to contract B, and uses whatever contract it currently points to to accomplish whatever it needs to do for users.

To update the part of Contract A, upload an updated contract C, and send A a message to tell it to change the address it stores to point to contract C instead.

Contract A only changes where the address points if whatever conditions it was designed to use for that are met.

And, of course, you don't have to use this "point to another contract" thing.

That's just if you need part of the contract to be updateable under some conditions, which you might not need.

Re: Final Steps

#103
post #18

Earlier quoted context omitted.

Ether is a "computational currency." You earn it by running computations on your computer. You spend it by purchasing processing power on other people's computers. The computation is software defined, so that customized "distributed apps" are possible. This is my outsiders understanding. I think there are potentially a lot of things that could be gotten wrong here - from the specific implementation and security measu…

> But it's one of several such experiments with using the blockchain Well, using a blockchain. Its not using "the blockchain" in the usual sense; Ethereum is specifically using an alternative to the Bitcoin protocol and blockchain, not built on top of it.

Bitcoin isn't "the blockchain" any more than Internet Explorer is "the browser". When people talk about "X in the browser" it's understood that they mean any generic implementation of a web browser.

Re: Final Steps

#104
post #41

Earlier quoted context omitted.

How is Ethash compute intensive relative to Cuckoo Cycle? EDIT: Ethash does 1 SHA3 at the beginning, 1 SHA3 at the end, and 64 rounds of FNV1-32 x 32. Verification considers the intermediate digest, so really 1 SHA3 to verify. You do more SHA3 rounds if you don't store the dataset, but this is a memory trap-door (and would require ignoring the mixDigest); the verification cost is still negligible. In our mining pools…

"Compute bound" refers to proof generation (mining), not to verification. It looks like ethash does the following computations per random memory access: p = fnv(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes newdata = [] for j in range(MIX_BYTES / HASH_BYTES): newdata.extend(dataset_lookup(p + j)) mix = map(fnv, mix, newdata) I admit this doesn't look much more involved than Cuckoo's single siphash-2-4, but per…

I had someone run some tests where ethash was accessing only 1KB rather than the whole 1GB of dag, and runtime fell by 40%. So that's roughly the fraction of time spent on memory latency in the single threaded cpu miner. That's less than the 67% measured for Cuckoo Cycle, but still rather high. So I should say that ethash is almost memory-bound, and certainly much more so than other memory oriented hash functions.
Post reply on HN