Ethereum forum

Discussieer en deel informatie over blockchain, bitcoin wallet, koers van de Bitcoin, Ethereum, etc.

Moderator: neku

Plaats reactie
Gebruikersavatar
neku
Premiummember
Premiummember
Berichten: 1515
Lid geworden op: 01 Jan 2017 20:21
Locatie: Antwerpen
waarderingen: 376
Contact:

Re: Ethereum forum

Berichtdoor neku » 13 Dec 2017 23:53

The aim of education is the knowledge, not of facts, but of values!



Smokey the bear
Forum verkenner
Forum verkenner
Berichten: 45
Lid geworden op: 06 Nov 2017 16:49
waarderingen: 10
Contact:

Re: Ethereum forum

Berichtdoor Smokey the bear » 09 Jan 2018 23:50

Het blijft een gokske maar ethereum op 2de plaats als coin om in het oog te houden.

https://www.bright.nl/uitlegparty/dit-z ... n-van-2018
Ik speel op de beurs, want was Clash of Clans beu

Gebruikersavatar
neku
Premiummember
Premiummember
Berichten: 1515
Lid geworden op: 01 Jan 2017 20:21
Locatie: Antwerpen
waarderingen: 376
Contact:

Re: Ethereum forum

Berichtdoor neku » 28 Aug 2018 11:40

https://blog.stellarx.com/the-great-fil ... -ethereum/

Verdoken reclame voor Stellar maar haalt wel punten aan
The aim of education is the knowledge, not of facts, but of values!

Gebruikersavatar
neku
Premiummember
Premiummember
Berichten: 1515
Lid geworden op: 01 Jan 2017 20:21
Locatie: Antwerpen
waarderingen: 376
Contact:

Re: Ethereum forum

Berichtdoor neku » 28 Aug 2018 19:50

The aim of education is the knowledge, not of facts, but of values!

Gebruikersavatar
neku
Premiummember
Premiummember
Berichten: 1515
Lid geworden op: 01 Jan 2017 20:21
Locatie: Antwerpen
waarderingen: 376
Contact:

Re: Ethereum forum

Berichtdoor neku » 29 Aug 2018 23:04

The aim of education is the knowledge, not of facts, but of values!

Gebruikersavatar
neku
Premiummember
Premiummember
Berichten: 1515
Lid geworden op: 01 Jan 2017 20:21
Locatie: Antwerpen
waarderingen: 376
Contact:

Re: Ethereum forum

Berichtdoor neku » 04 Sep 2018 10:59

Collapse of ETH is Inevitable? Ethereum’s Vitalik Buterin Disagrees

Vitalik Buterin, the founder of Ethereum, replied to a September 3, 2018, report from Techcrunch that claims that the collapse of ETH is inevitable.
No Future for ‘Gas’

According to a report from TechCrunch, the collapse of ETH is inevitable, and we should expect that ETH — the asset, not the Ethereum Network itself — will soon go to zero.

The September 3 report, written by Jeremy Rubin, a technical advisor to Stellar and co-founder of the MIT Digital Currency Initiative, claims that Ethereum as a platform will end up succeeding, despite ETH becoming worthless.

The report aims to explain the mechanism of this downfall by citing Ethereum’s original value proposition.

According to the proposition, Ethereum is a decentralized platform that runs smart contracts: applications that run precisely as programmed without any possibility of downtime, censorship, fraud or third-party interference.

These apps run on a custom built blockchain, an enormously influential shared global infrastructure that can move value around and represent the ownership of property.

Rubin also points out that there is no value proposition for ETH in the official description, and that it’s most likely due to the fact that ETH’s value seems so apparent to the Ethereum Foundation that it is hardly worth mentioning: $ETH fees (dubbed ‘Gas’) is how you pay for all this.

However, Rubin points out that as all kinds of different ERC-20 tokens are built on the Ethereum network, paying for gas in ETH would create substantial risk, third-party dependency, and artificial downwards pressure on the price of the underlying token.

Instead, he proposes paying for gas in non-ETH assets, i.e., the underlying coins. This mechanism is called “economic abstraction.” Simply put, “economic abstraction” is the idea that a blockchain protocol would allow the use of any one of a potentially unbounded number of tokens, rather than a single coin.

Later in the report, Rubin concludes that if all the applications and their transactions can run on Ethereum without ETH, there’s no reason for ETH to be valuable. The only way ETH could retain its value, he said, as if “the miners enforce some sort of racket to require users to pay in ETH.”

He also points out that miners wouldn’t be the only ones looking to get pain in non-ETH assets – risk-averse users would want to minimize their exposure to volatile assets, and token developers would see pricing in their native asset reducing the sell-pressure.
Ethereum Cofounder Disagrees

Despite massive media coverage, Rubin’s report seems to have garnered more criticism than praise. Comments on TechCrunch’sreport point out the fact that economic abstraction relies on an intermediary to accept network token and pay the gas in ETH on behalf of the user. That means that ETH is always required to run a contract or a transaction.

Vitalik Buterin, the founder of Ethereum, replied to the report in a thread on Reddit and was seemingly unimpressed with Rubin’s views.

“I have every incentive to disagree with this, but I think there are quite a few very critical economic and technical details that the article is missing,” he said, adding that “we are likely not doing full “economic abstraction.”

“One could also use intermediate solutions, where third parties create “wrapper transactions” that take the fees for operations from users that are paid in spankchain tokens, and the third parties provide the ETH to the block proposer,” he explained.

https://elevenews.com/2018/09/04/collap ... disagrees/
The aim of education is the knowledge, not of facts, but of values!

Gebruikersavatar
neku
Premiummember
Premiummember
Berichten: 1515
Lid geworden op: 01 Jan 2017 20:21
Locatie: Antwerpen
waarderingen: 376
Contact:

Re: Ethereum forum

Berichtdoor neku » 05 Sep 2018 15:09

Ethereum Foundation leaders have an in-depth discussion on their biggest challenge - scaling!

http://www.globalcryptopress.com/2018/0 ... ve-in.html
The aim of education is the knowledge, not of facts, but of values!

Gebruikersavatar
neku
Premiummember
Premiummember
Berichten: 1515
Lid geworden op: 01 Jan 2017 20:21
Locatie: Antwerpen
waarderingen: 376
Contact:

Re: Ethereum forum

Berichtdoor neku » 07 Sep 2018 20:40

Ethereum 2.0 — Who’s building it?

Ethereum’s roadmap is ambitious. In our last article, we described the Ethereum 2.0 vision.

As a recap, Ethereum 2.0 combines these key projects:

-Proof-of-stake (Beacon Chain, Casper FFG)
-Sharding
-eWASM

Once delivered, Ethereum 2.0 will support massive on-chain transaction throughput, while balancing decentralisation and security. With this foundation, Ethereum has the potential to be:

-A key piece of infrastructure for the world’s transfer of value;
-A platform for new economic systems;
-A hub for global collaboration;

Ethereum 2.0 is not being developed by a corporation; Ethereum is decentralised on multiple levels.

Vitalik says it best:

"Blockchains are politically decentralized (no one controls them) and architecturally decentralized (no infrastructural central point of failure) but they are logically centralized (there is one commonly agreed state and the system behaves like a single computer)"

Vitalik Buterin (Meaning of Decentralization)

Additionally, Ethereum is operationally decentralised (no single entity is responsible for keeping the blockchain running).

So if no one controls Ethereum, how is Ethereum 2.0 being built?

This is one of many fascinating aspects of Ethereum. It has an organic quality that hopefully will contribute to how human organisation can scale up but remain inclusive.

The Ethereum protocol describes the interactions necessary to produce the Ethereum blockchain. It is a massive open source project. A large community of researchers and implementors propose ideas, discuss, refine, and implement the Ethereum protocol. The Ethereum Foundation are influential in this process and have highly regarded researchers and implementors, but decisions are made by the community through consensus.

The software used to run Ethereum is called a client or node. Many Ethereum client implementations exist, written by different software development groups (all are open-source).

In addition to client implementations, there is an entire ecosystem of open source software projects working on building different aspects of Ethereum.

These include:

-Smart Contract Languages (Solidity, Vyper)
-RPC Libraries (web3js, ethers, Nethereum)
-Development Tools (truffle, ganache, solc, solium)

Enough context, let’s get into the meat and potatoes.

Research

There are many research topics under investigation that need to be pulled together to make Ethereum 2.0 work. These topics are publicly documented and discussed on the Ethereum Research site. Researchers and software developers get a chance to query and critique proposals.

The research topics include:

-Signature aggregation
-Random number generation
-Fork choice
-Data availability
-Light client support
-P2P communication
-Cross-shard communication & state/execution separation

Many of the topics have reached the point where they can be implemented, but there are equally as many that are in early stages and need more time to lock down.

Reference Implementation

As research topics mature they coalesce into a specification that the implementation teams are using to develop their Ethereum 2.0 clients.

To help in this endeavor, the Ethereum Foundation is developing a reference implementation client in Python. They also provide valuable community support to help implementation teams and a regular Ethereum 2.0 implementors call is run biweekly to track progress, answer questions, and reach consensus on common issues.

Beacon Chain / Shard Clients

The following teams are either researching or developing a beacon chain / shard client:

-Prysm- developed by Prysmatic Labs, written in Go. They have an excellent bi-weekly update on their progress.
-Lighthouse — developed by Sigma Prime, written in Rust.
-Nimbus — developed by Status, written in Nim.
-Lodestar — developed by Chain Safe Systems in JavaScript.
-Harmony — developed by Ether Camp, written in Java.
-Pantheon — developed by PegaSys the protocol engineering group at ConsenSys, written in Java. The team are focused on key Ethereum challenges including scalability and privacy for both public and private chains.
-Trinity — developed by the Trinity team (led by Piper Merriam), written in Python.

The teams vary in their progress implementing the Ethereum 2.0 specification. At this stage, all teams are working on building a beacon chain client, which is central to the Ethereum 2.0 vision.

The beacon chain work carried out so far includes:

-Beacon chain state data structures and persistence
-Per block state transition
-Fork choice implementation
-Validator shuffling
-Block proposer role
-Data structure serialization
-P2P protocols

An essential process being discussed is the need for a common testing language that encodes test cases — enabling researchers to define a bunch of tests with expected results that each team can use to validate their implementation against the specification, providing consistency across the different teams.

eWASM

eWASM is not specific to the Ethereum 2.0 approach. The project has been in development for some time by the eWASM team and is focused on compatibility with the current EVM. The eWASM team are assessing the implications of the new approach but the research is still quite early in regards to how execution will actually work.

In particular, it is likely that the new Ethereum 2.0 shard system will use a delayed execution model. The current EVM blockchain executes smart contract code immediately when a transaction is processed.

In the new Ethereum 2.0 shard system:

-Shards will be responsible for transaction ordering and storing data only
-An overlaid execution process will read transactions, execute code, and write back results

The execution overlay may be a layer 2 process built on top, rather than baked into the blockchain.

Summary

There are many smart talented people working on making Ethereum awesome. The research continues and solid beacon chain implementations are being developed.

https://medium.com/rocket-pool/ethereum ... 54a735442e
The aim of education is the knowledge, not of facts, but of values!

Gebruikersavatar
neku
Premiummember
Premiummember
Berichten: 1515
Lid geworden op: 01 Jan 2017 20:21
Locatie: Antwerpen
waarderingen: 376
Contact:

Re: Ethereum forum

Berichtdoor neku » 07 Sep 2018 20:58

Ethereum de laatste 2 weken in EUR

kraken-etheur-Sep-07-2018-21-57-54.png
U kunt de afbeeldingen in deze bijlage niet bekijken, registreer hier en bekijk de bijlage.
The aim of education is the knowledge, not of facts, but of values!

Gebruikersavatar
neku
Premiummember
Premiummember
Berichten: 1515
Lid geworden op: 01 Jan 2017 20:21
Locatie: Antwerpen
waarderingen: 376
Contact:

Re: Ethereum forum

Berichtdoor neku » 09 Sep 2018 11:06

Comparing ERC20, ERC223, and the new Ethereum ERC777 token standard

Next to the well-known ERC20 standard, other standards exist which try to improve the original standard. ERC223 is focused on security seeking to solve an ERC20 critical bug which has caused the loss of millions of dollars. ERC777 focuses on a wider set of transaction event handling functions and mass adoption

You are all familiar with ERC20 tokens as you probably own a couple, distributed by some kind of token sale. But did you know many more standards exist besides ERC20? Ethereum has a long history of developed standards.

To give you a better idea of what ERC means, it stands for “Ethereum Request for Comment”. This is a proposal submitted for discussion and suggestions to the actual standard. The number (like 20) refers to an issue number on code sharing platform Github. First, let’s take a look at the ERC20 standard.

What exactly is the ERC20 standard?

The advent of ERC20 tokens revolutionized the cryptocurrency market and opened the door to the plethora of ICO cryptocurrency projects the world witnessed during 2017. Introduced in 2015, the ERC20 code outlines a specific list of rules that a given Ethereum based token has to deploy, simplifying the process of programming the functions of tokens on Ethereum’s blockchain. Basically, ERC20 tokens are special forms of smart contracts that utilize Ethereum’s blockchain.

The most prominent examples of ERC20 tokens include Bancor, EOS, Tronix, BNB, VeChain, and Bankex.

Before the innovation of the ERC20 standard for Ethereum tokens, coders had to create specific implementation standards for developing a token and launching it on Ethereum’s network. Nevertheless, the ERC20 token code have simplified the process of creation of tokens, thanks to a streamlined protocol and smart contract standards. The ERC20 code alleviated the complexity associated with implementation of token’s smart contracts, which significantly reduced the possibility of breaking token’s contracts.

As of April 2018, there are 66,468 ERC20 token contracts, thanks to the uniformity of token code provided by the ERC20 standard, which made it easy for cryptocurrency exchanges to list various tokens on their trading platforms. As such, the ERC20 standard has helped the crypto community overcome liquidity problems that could have associated such an enormous number of Ethereum based tokens.

ERC20 token functions:

ERC20 code outlines six specific functions for tokens, which are

1- Getting the total supply of tokens via the “totalSupply” function

2- Retrieving the token balance of another account associated with the “_owner” address via the ” balanceOf(address _owner) constant returns (uint256 balance)” function.

3- Sending a specific amount of tokens “_value” to a given address via the “ transfer(address _to, uint256 _value) returns (bool success)” function.

4- Sending a specific amount of tokens “_value” from one token (contract) address to another token (contract) address via the “transferFrom(address _from, address _to, uint256 _value) returns (bool success)” function.

5- Enabling a specific account to withdraw tokens from one’s account repeatedly, while predefining the upper limit for the amount of tokens to be withdrawn with the “_value” parameter. This can be achieved via the “approve(address _spender, uint256 _value) returns (bool success)“. The upper limit for withdrawal, i.e. the “_value” parameter, can be overwritten when the function is recalled.

6- Returning the residual amount of tokens, within the preset amount defined by the upper limit allowed to be spent by the “_spender” to withdraw from the account of the “_owner“. This can be executed via the “allowance(address *_owner*, address *_spender*) constant returns (uint256 remaining)” function.

These six functions defined by the ERC20 code represent cornerstone functionality issues, which include how these tokens will be transferred between different accounts, and how users can retrieve data associated with a given ERC20 token. These group of functions are prescribed to ensure that Ethereum based tokens will function similarly within any part of Ethereum’s platform. As such, all crypto wallets that are compliant with the ether coin will also support tokens based on the ERC20 standard.

Critical bug:

ERC20 is the first token standard of Ethereum. As is often the case with new code, it contains some bugs or logical mistakes. ERC20 assumes two ways of performing a token transaction. First of all, the transfer function lets you send tokens to someone’s address. If you want to deposit tokens to a smart contract, you should use the combination ‘approve + transferFrom’. You should authorize this contract to withdraw your tokens via the approve function. Then, you need to call a function of a contract that will handle your deposit and withdraw your tokens via the transferFrom function.

What if you deposit tokens by accident to a contract with the transfer function? The transaction will succeed but this transaction will not be recognized by the recipient contract. For example, if you send tokens to a decentralized exchange contract, then the exchange contract will receive your tokens but it will not credit this tokens to your exchange token balance. Moreover, if the decentralized exchange contract does not implement an emergency token extraction function, then it’s impossible to get your tokens back in any case, resulting in a permanent loss of the tokens. Due to this bug, the Ethereum ecosystem has lost millions of dollars already.


Why are we still using the ERC20 standard?

Reddit user u/Dexaran, creator of the ERC223 standard, is one of the first developers who notified the community about the aforementioned bug. We asked him why ERC20 is still so widely used, even when knowing about this critical bug. He gave the following reasons:

-Because of criminal irresponsibility of token developers for their deeds.
-Because Ethereum Foundation is still promoting the ERC20 token standard even when it is known to contains bugs. The same situation as it was with TheDAO previously. They need to say “Stop this now” but they will not.
-Because the main reason for token development is fund grabbing, rather than product creation.
-Because using a different standard will lead to higher network effects. This is not what we really need given that the Ethereum network already has scalability issues.

ERC223 standard

The ERC223 standard was proposed by u/Dexaran who helped creating this article. ERC223 is a token standard that allows token transfers to behave exactly as ether transactions. ERC223 utilizes event handling (considers a transaction an event) to prevent tokens from being lost in unhandled transactions. This improved standard resolves the ERC20 critical bug by making the transfer function throw an error on invalid transfers and canceling the transaction so no funds are lost. In short, ERC223 focuses on security.

Additions and problems

ERC223 adds an additional data parameter to the transfer function, to allow for more complex operations than just a token transfer.

Dexaran’s main concern is that too many people can lose their tokens by sending them to contracts using the transfer function, not the approve and transferFrom methods as earlier discussed. His solution is to modify the transfer method to check whether the receiving address is a contract (i.e. contains data) or not. If it is a contract, then it assumes that there is a tokenFallback function to call it back. The main weakness is that if the tokenFallback does not exist, then the receiving contract’s fallback function will be called and the sent tokens may still be lost.
ERC777 standard

ERC777 is a new fungible token standard that relies on ERC820 (Contract pseudo-introspection registry) and tries to solve ERC20’s problems, such as lack of transaction handling mechanisms that led to the loss of millions of dollars from the Ethereum ecosystem. In short, ERC777 focuses on adoption by offering a wide range of transaction handling mechanisms.
Benefits

The main advantage of ERC777 is that it uses a new method of recognizing the contract interface. This standard assumes that there is a central registry of contracts on Ethereum’s network (this is defined in ERC820). Everyone can invoke this registry to know if a certain address (it doesn’t matter if this address is a contract or not) supports a certain set of functions i.e. `interface`.

One of the main problems of Ethereum is the inability to know what functions the contract implements. ERC820 is intended to solve this. ERC777 takes advantage of this approach, which is definitely a good idea.

On the other hand, you can create a token that will implement ERC20’s default functions alongside with the new ERC777 functions without overrides (and optionally inherit ERC20’s critical bug). This can guarantee a good network effect for this new token standard and faster adoption. As practice shows, the main goal of token developers is to raise money which assumes that they need to push their tokens to exchanges. It is easier for exchanges to support a token that implements legacy ERC20 functions (it doesn’t matter if these functions contain bugs or not) without any research on newer functionalities of new token standards. The easier it is for exchanges to support tokens on a new standard, the more developers will use it. This boosts the adoption of ERC777, while ERC223 lacks this property.

What’s different?

This token standard defines a completely new set of functions i.e. `send` functions instead of `transfer` functions. `authoriseOperator` instead of `approve`. `tokensReceived` handler function instead of `tokenFallback` handler function.

Such an approach can guarantee that the functions of this standard will not cross and override with functions of any other token standard, thus it is possible to make a token that will be compatible with ERC777 and ERC820 standards simultaneously.

At last, ERC777 standardizes Mint and Burn functionality of tokens.

Points of failure and security concerns

ERC777 implements the `authoriseOperator`function which allows someone to manage tokens on your behalf. Dexaran explained to us that he thinks this method is deprecated and should not be used. In addition, authorizing someone to manage tokens on your behalf hurts the network’s bandwidth and requires more gas. `authoriseOperator` already represents one transaction, and another transaction is required to perform the “authorized withdrawal”. So, two transactions are required to perform a transfer which can be done with just one transaction.

Next, the ERC777 standard contains an optional flag to prevent stuck tokens by performing some checks about the ITokenRecipient interface, and to check if the address is whitelisted. As this standard is focused on security of a network that handles tokens that are worth millions of dollars, it’s not a good thing to make these checks optional.
Other standards

There are many other standards like ERC827 which combines some advantages of ERC223 with legacy ERC20 functions. The ERC664 standard focuses on the modularity of the token standard. This standard allows token contracts to be upgradeable, but it has inherited the ERC20 critical bug. Other standards include ERC721, ERC677, and ERC820, but they are less well-known.
Compatibility between standards

We asked Dexaran which standards are backward compatible. He told us we first should understand what ‘backward compatibility’ stands for: “Backward compatibility is a property of a system, product, or technology that allows for interoperability with an older legacy system, or with input designed for such a system.”

ERC20 & ERC223: ERC223 tokens are compatible with ERC20. Everything that is designed to properly work with ERC20 (like wallets) can work with ERC223 as well. The only exception here are contracts that are relying on approve + transferFrom token deposit patterns. However, it is possible to implement approve + transferFrom functions with ERC223 tokens, even if they are not included in the standard right now. As for wallets and any third party services that are not smart-contracts, they support ERC223 automatically because the input call data of ERC20 token is valid for ERC223.

ERC20 & ERC777: You can find the following statement in the ‘Backward Compatibility’ section of the ERC777 proposal: “This EIP does not introduce backward incompatibilities and is compatible with the older ERC-20 token standard.”

However, Dexaran told us the exact opposite and gave us this example: “Such wallets and services as MetaMask, Mist, and MyEtherWallet are working with ERC20 tokens. The input that is designed for the ERC20 token is a contract call that contains encoded parameters and a function signature. Function calls in the Ethereum Virtual Machine are specified by the first four bytes of data sent with a transaction. These 4-byte signatures are defined as the first four bytes of the hash of the canonical representation of the function signature. This means that `transfer(address, uint256)` and `send(address, uint256)` functions will have different signatures. As a result, the input designed for the ERC20 token will not be valid for the ERC777 token.” As we use our definition of backward compatibility, ERC777 is not compatible with the ERC20 token standard.
When to use which standard

ERC20: Reddit user u/Dexaran gave us this sarcastic advice, “When you want your investors to lose money because of bugs.”

ERC223: This token standard is also usable alongside with ERC777. ERC777 has some elegant features that ERC223 lacks, but the logic of ERC223 is straightforward compared to ERC777 which can guarantee that it cointain much less error-prone code. Moreover, ERC223 is not relying on any central service which means that your ERC223 token will only depend on your own implementation. As we have mentioned earlier, ERC223 aims at security improvements, but this rendered ERC223 tokens non-compliant with the ERC20 standards.

ERC777: This token standard is already usable. On the other hand, ERC777 has some security concerns as mentioned above. They also rely on central contract registry which is a security concern as well. A central registry can make developer’s life easier but it also acts as a central point of failure exactly as it was with Parity Multisig. All the Parity Multisigs relied on a central code library. It happened that there was a bug in the library and it was exploited. As a result, all the Parity Multisigs crashed. In addition, ERC777 defines a new set of functions. This is an attempt to allow token developers to make their tokens compatible with both ERC20 and ERC777 standards simultaneously for the sake of adoption. This means that a developer can inherit a bug of ERC20 in ERC777, but it allows a developer to use more transaction handling events.

In general: All tokens have a similar use case – ICO. I would say that ERC223 and ERC777 are trying to solve one problem of ERC20 in different ways. ERC223 is already taking its niche in Ethereum Classic instead of the ERC20.

https://www.cointelligence.com/content/ ... -standard/
The aim of education is the knowledge, not of facts, but of values!