geth is the the command line interface for running a full Ethereum node implemented in Go. It is the main deliverable of the Frontier Release. Frontier is the first in a series of releases that punctuate the roadmap for the development of Ethereum. Frontier will be followed by ‘Homestead’, ‘Metropolis’ and ‘Serenity’ throughout the coming year, each adding new features and improving the user friendliness and security of the platform.
By installing and running geth, anyone can take part in the ethereum frontier live network and
mine real ether
transfer funds between addresses
create contracts and send transactions
explore block history and much much more.
Geth is supported on Linux, Mac Os and Windows platforms. It is used to mine Ethereum's token (ETH) in Proof of Work (PoW) protocol. But, now team Ethereum is preparing to switch from Proof of Work (PoW) to Proof of Stake (PoS) protocol. Release of Geth 1.6.1 is a step closer to the switch. Ethereum developer's team proposed for a smooth transition from PoW to PoS, there should be a Hybrid protocol that uses key features of both protocols and then with consensus, it can be taken forward to PoS.
For those who are planning to continue with Ethereum even after the switch from POW to POS, will have to download the upgraded software (geth) at their client. This upgraded software will inform every client that at some point in future, with consensus mechanism there will be the change from Proof of Work to Proof of Stake version. There will be the 'last block' of POW and the 'first block' of POS. It will be a kind of hard fork which has to be done based on consensus protocol. There may be disagreement on the 'last block' at the time POW blockchain fork but eventually one chain will win and everyone will agree on it. This will be finalized by the bonded validators of Proof of Stake.
Geth 1.6.1 released on May 4, 2017 is mostly a bug fix release adding various polishes throughout the codebase.
Highlights of the release are the capability to iterate over a contract's storage entries via the RPC; transitioning Whisper to protocol v5 along with bundled diagnostics tools; and shorthand connectivity to the Rinkeby test network.
- debug_storageRangeAt RPC supports iterating over contract storage entries (#14350).
- Switch Whisper to protocol v5 (#14387), ship diagnostic tool (#14414).
- Add --rinkeby flag to quickly connect to the Rinkeby testnet (#14418).
- Support disabling USB hardware wallet lookups (#14357).
GitHub faucet bot protection (#14339) and funding tiers (#14402).
- Add explicit SSH server key management for puppeth (#14398).
geth init and geth removedb operate on both full and light chains (#14412).
For a detailed rundown, please consult the 1.6.1 milestone.
#geth #ethereum #blockchain #etherworld #pos
Ethereum Name Service (ENS)
Project ENS was initially planned to be launched in mid-March, but because of critical bugs, it failed on testnet for ethereum apps. Later, a reworked ENS registrar was released on the Ropsten (testnet) network, after the results of two audits detailing the issues that led to the aborted launch, but it again failed. On April 20, 2017, Chris Remus (Team member of ENS project) posted the postmortem of ENS launch.
ENS is live on Ethereum Mainnet as of 1100 UTC on May 4, 2017.
Ethereum Name Service (ENS) is a distributed, open, and extensible naming system built using smart contracts based on the Ethereum blockchain. The primary goal of ENS is to resolve human-readable names, like ‘myname.eth’, into machine-readable identifiers, including Ethereum addresses, Swarm and IPFS content hashes, and other identifiers. A secondary purpose is to provide metadata about names, such as ABIs for contracts, and whois information for users.
ENS eliminates the need to copy - and worse, type - long hexadecimal addresses. With ENS, anyone will be able to send money to your friend at 'aardvark.eth' instead of '0x4cbe58c50480...', interact with your favorite contract at 'mycontract.eth', or visit a Swarm-hosted site at 'swarmsite.eth'.
ENS can be used to resolve a wide variety of resources. The initial standard for ENS defines resolution for Ethereum addresses, but the system is extensible by design, allowing more resource types to be resolved in future without the core components of ENS requiring upgrades.
ENS now live on Ethereum Mainnet
Earlier this week, Chris Remus announced in his post that “The ENS team, Nick Johnson and Alex Van Sande and myself as ENS community launch manager, believe ENS is ready for relaunch. We’re pleased to announce the relaunch is scheduled to happen on May 4, 2017 at 1100 UTC.”
How ENS works?
One can register Domain name on ENS Registrar on the Ethereum Mainnet. It allows to check the availability of Ethereum name and if not available , one can request it. Once a name is requested, a period of 72 hours begins in which anyone can put a sealed bid for it and send the necessary funds (minimum of 0.01 ether). This period is followed by a 48 hour one (the "Reveal Period") in which bids must be revealed. Any bid that is not revealed during Reveal Period results in the loss of its related funds. The highest bidder after all bids are revealed during this Reveal Period becomes the registrant of the name, and the ether they sent to the contract will be refunded immediately, minus the value required to outbid the second highest bidder. The remaining funds are kept locked in a contract for at least a year, after which they can be withdrawn by the registrant upon releasing rights of use of the name. Names with registrants are controlled only by their registrants, who can transfer or release the name until it needs to be renewed.
The algorithm used to decide how long people need to wait is random. It's the keccak256 hash of the name they want to register, expressed as a time between now and 8 weeks from the time of request.
All bids are secret, someone watching transactions can see who sent the bid and the amount of money sent, but not what auction the bid is for. The 'bid anonymity' box offers the opportunity to send extra ether on top of original bid (which gets sent back as soon as you reveal) to disguise even the amount of the bid, providing extra secrecy.
How can I bid for my domain?
Bids can be submitted without any information tying them to their intended auction. The only info on a masked bid is the amount of value sent with it (which can be more than the amount of the bid), the address of the sender, and the masked bid hash. Since this is an auction, it is expected that most public hashes, like known domains and common dictionary words, will have multiple bidders pushing the price up. When someone submits a bid, he can choose to send more ether along with it that will be returned when he reveals regardless of the outcome. This serves to mask the actual amount of the bid, so someone looking at someone else's bid can only tell that he is bidding at most that much.
It's additional blinding. Someone may be able to make educated guesses about the names you're bidding on based on what auctions you've opened, or there could be an especially high profile and valuable name up for auction. In either case, this helps disguise the true amount of your bid.
In short, we aren't allowed to unseal our bids until the reveal phase because it simplifies the contract and provides fewer opportunities for nasty bugs and edge cases.
There is a list on the dApp site, showing the name that are available. The twitter bot has a dictionary of common names it checks for, just like the DApp. If your name isn't in that list, it won't tweet it.
The details of interim and permanent registrars can be found here.
ENS will help us save from copy paste the address everytime we need to provide it. It's our choice name, so will be in mind all the time.
For more updates, technical blogs and general discussion on Blockchain Technology and Ethereum, please follow us @ether_world (Twitter) , EtherWorld_co (reddit.com) and EtherWorld (Facebook).
#Cryptonews #ENS #Ethereum #blockchain
Most recent version of Solidity (Ver. 0.4.11) is released today, May 3, 2017. It is now available for developers to download or even use it in browser for smart contract developments.
As reported in Reddit by user : chriseth,
"*This release fixes a bug in the optimizer (more about this on the blog), introduces the standard JSON interface, adds interface contracts and implements some additional safety checks."
Features included in this release are:
Implement the Standard JSON Input / Output API
Support interface contracts.
C API (jsonCompiler): Add the compileStandard() method to process a Standard JSON I/O.
Commandline interface: Add the --standard-json parameter to process a Standard JSON I/O.
- Commandline interface: Support --allow-paths to define trusted import paths.
Note: the path(s) of the supplied source file(s) is always trusted.
- Inline Assembly: Storage variable access using _slot and _offset suffixes.
- Inline Assembly: Disallow blocks with unbalanced stack.
- Static analyzer: Warn about statements without effects.
- Static analyzer: Warn about unused local variables, parameters, and return parameters.
- Syntax checker: issue deprecation warning for unary '+'
The best way to try out Solidity now is using Remix.
Solidity is statically typed, supports inheritance, libraries and complex user-defined types among other features. It is possible to create contracts for voting, crowdfunding, blind auctions, multi-signature wallets and more.
It can be started using Solidity in the browser with no need to download or compile anything.
Remix is one of the available solidity integration. It is a browser-based IDE with integrated compiler and Solidity runtime environment without server-side components.
Solidity is still under development. So please do not hesitate and open an issue in GitHub if you encounter anything strange.
#solidity #Ethereum #cryptonews #blockchain #EVM
Ethereum based VISA-DEBIT card - “TokenCard”
The biggest challenge of cryptocurrency today is the ease of usability. People are investing money in buying cryptocurrency but it is saved as assets. Since there is no simpler way of using it to buy and sell goods, it is not frequently used as a currency. In absence of fundamental use of a 'currency' , IRS issued guidelines for 'Virtual Currency' referring it as 'Property'. It states that “Virtual Currency Is Treated as Property for U.S. Federal Tax Purposes; General Rules for Property Transactions Apply”.
One of the best solution to the aforesaid problem is “TokenCard”. Today, May 2, 2017, DigixGlobal & Monolith Studio in partnership launches the initial token sale for “TokenCard” powered by smart contracts.
100% MVP cards were claimed and 42.3 m tokens were created in less than an hour of the start of the event. Token creation event is closed now, still additional contribution will be received for 24 hrs. 166.7K / 65K Ether has been received by the time of news reporting. It is a huge success for “TokenCard”.
TokenCard is a blockchain based VISA-DEBIT card that uses Ethereum network for payment. TokenCard will allow token holders to use Ether as well as other ERC20 tokens to purchase items anywhere that accepts VISA debit cards. Each TokenCard is backed by a personal smart contract. It allows Ether and other ERC20 compliant tokens to be spent, including stable coins. These smart contracts ensure deposited funds remain in full control of the user, without compromising on usability. It is powered by gold-backed debit card and is usable at payment terminals around the world, including ATMs. Whenever the TokenCard is swiped, the transaction incurs a 1% licensing fee which accrues to the TKN Asset Contract. The licensing fee is denominated in the token used, however, TKN backed swipes don't incur a licensing fee.
TokenCard is a depositless Ethereum token-based debit card & platform with three elements:
- The Token™ Contract Wallet: secures users' assets and enforces user-set spending and security parameters.
- Your physical TokenCard™: connects your Contract Wallet to the VISA® network — enabling online payments, PoS transactions and ATM withdrawals, using ERC20 tokens in the Token™ Contract Wallet.
- The mobile Token App: neatly unifies the process, offering a clean, intuitive experience and empowering users to finally go bankless, wherever they are.
TKN creation Period
The TKN creation period commenced today, May 2, 2017 and was planned to last maximum 7 days as per the initial estimate, but since the cap is reached today, additional contributions will be accepted for 24 hours, in case users missed a very short window for TKN creation. It create 42.3m of TKN for sale in exchange for ETH, fiat and other tokens from our initial token partners and no more tokens will be created thereafter. Digix announced, that an additional 5% bonus of TKNs will be generated when participants use DGDs during the launch.
Key features of TokenCard
- Revolutionary - User can buy groceries in DGX, ETH, DAI or any supported tokens.
- User controlled - User never has to deposit with TokenCards, ever. Tokens are secured inside a contract wallet under user's control.
- No Compromises — User retains the security and control of a contract wallet while gaining the utility of a global payments network.
Advantages of TokenCard
- User Friendly — Designed in a way that anyone at any level can quickly use without having to master the underlying blockchain technology.
- On the Fly Information — Whenever a user swipes his card, a transaction entry will simultaneously appear in his Token App™ displaying business name, establishment type, amount spent (local fiat amount and token), and transaction location using Google Map's API.
- Token-to-Token — Users can re-balance their token portfolio anytime with the in-app token-to-token exchange. No need to withdraw and deposit funds into a centralized exchange! Simply exchange tokens within the Contract Wallet with a click.
- Fiat-to-Token — With sufficient liquidity parameters, it also provides an in-app fiat-to-token exchange option. This feature allows users new to the token economy with an accessible on-ramp to not only this platform, but to the Ethereum token economy at large.
TokenCard and Bancor Partnership
In addition to this big event today, an another announcement of upcoming partnership between TokenCard, the first smart contract powered debit card, and Bancor , the first protocol for intrinsically tradable smart tokens is made by the The Bancor Protocol .
Bancor Protocol is a standard for a new generation of cryptocurrencies called smart tokens. The Bancor protocol enables built-in price discovery and a liquidity mechanism for tokens on smart contract blockchains. These “smart tokens” hold one or more other tokens in reserve and enable any party to instantly purchase or liquidate the smart token in exchange for any of its reserve tokens, directly through the smart token’s contract, at a continuously calculated price, according to a formula which balances buy and sell volumes. The partnership will allow smart tokens to be spent with TokenCards, and will offer TokenCards to Bancor’s end-users using and issuing smart tokens which will seamlessly work with TokenCard’s VISA Debit.
“This is a perfect match as TokenCard offers a solution enabling Ethereum tokens to be spent in real-world commerce, and Bancor is bringing the ability to issue liquid Ethereum tokens to the end-user. Both companies and their customers stand to benefit from a stronger bridge between the new and traditional economies” - Mel Gelderman, CEO of TokenCard.
DigixGlobal Ltd. is a Singapore based company which is one of the first Decentralised Autonomous Organizations (DAO) having Ethereum Blockchain as underlying technology. About a year ago, DigixGlobal raised almost half a million ether coins only hours after the opening of “the first decentralized crowdsale on the Ethereum Blockchain” according to Anthony Eufemio, CTO at DigixGlobal. DigixGlobal has a proof of asset (PoA) protocol for an Ethereum-backed gold tokenization system. The crowd sale created two million DigixDAO Tokens (DGD) which are different from the gold backed DGX tokens. The Digix crowdsale is one of three better-known crowdsales to come out of ethereum’s ecosystem which, due to its smart contracts platform, allows for new decentralized business models. Digix tokens (DGX) are created through a “Minter Smart Contract” by using Ethereum’s smart contract platform with each token representing 1g of gold and divisible up to 0.001g.
About Monolith Studio
The Monolith Studio is a Web3 venture production studio to be registered in Switzerland. It is exploring ways to materialize Ethereum’s transcendental potential by creating next generation Ethereum powered products and platforms for the end-user, on the Web3. The TokenCard is its first project.
TokenCard is positioning themselves to be a leader in Ethereum transfers to the fiat world. It aims over time to bring about a world which makes access to tokens far easier, far more intuitive, with far less friction than it is today.
#TKN #Cryptonews #TokenCard #Ethereum #MonolithStudio #DigixGlobal #Blockchain #Bancor #ICO
Ethereum is second best leading blockchains today with a value of about $ 82 per Ether and a market cap of more than $ 7.3 B. One of the key factors behind the success of Ethereum is its core development team.
Henry Ford once said,
“Coming together is a beginning; keeping together is progress; working together is success.”
Ethereum community is continuously putting efforts to make Ethereum platform stronger, safer and simpler to work with. To keep the entire team and world together on same page, they have Ethereum core developers meeting twice a month. Last 'All Core Devs: Meeting 14 ' took place on April 21, 2017. The meeting included discussion on various Ethereum Improvement Proposals (EIP) and Metropolis updates. The video and transcript of the meeting are available at GitHub.
Highlights of the meeting are
EIP 186: Reduce ETH issuance before proof-of-stake
The reward (issuance of Ether) is going to come down once Ethereum community will start the PoS switch. The difference between cutting it down to even to take the bottom end 2.5 and just pushing it all the way back up to 5 and in terms of Metropolis, it’s going to be something like 2-3 million Ether.
EIP86 (a.k.a EIP-208), there is a difference between the EIP pull-request and the implementations. Which should be fixed?
There are two ways to create contract, one of them is external and other one is with create opcode. So, part of the EIP accounts the scheme for addresses that get created externally gets changed. But as far as the create opcode, there can be two main reasons to change that -
• One of them is consistencies.
• Other is that the scheme works even if contracts are creating other contracts and not just the mechanism from the outside.
These implementations, these pull requests change the create instructions and they add a new create instructions.
After Metropolis, there will be three ways an address for new contract is generated.
- Create transactions: generates an address from the code hash
- Create opcode generated by ROP concatenating sender and nonce
- A new create instructions to generate it from.
EIP 98: removing medstate from receipts - go & cpp implemented option 2, Parity seems to have went with option 1
- EIP 98 is the one which removes the intermediate state.
- There are two options in EIP specifications
Removing the root hash altogether from their RLP structure
Replacement with zero hash Looking at the code, it was noticed that parity seems to modify RLP structure and go just replace it with zero hash.
- Team decided to remove it completely because it seems more cleaner and ready to deploy it.
EIP 96 is about blockchain and state root change, In this, the contract is inserted into the state when the transition happens and it changes the state root. Reasoning for making them separate is because these addresses for EIP 96 is not actually a real precompile; it’s just a prenode regular contract with a piece of prenode regular code that happens to have a privilege status in the protocol.
Metropolis testing and client implementation updates
- For testing of EIPs for Metropolis - A file on Google Docs is available that is updated with test cases that are already implemented and are marked in green. To do list and status of other tasks are also available there.
- Metropolis Clients implementations - Looking at the PR it looks like it’s almost done.
- Parity - Mostly done, just one EIP that needs to be implemented on the return data.
- Pythereum – Metropolis features implementation is started. The revert opcode is passing all the tests, there is implementation of EIP 86 although it is old so it may not be fully compliant with all the related stuff that team agreed on but that will be very easy to change once the test is there. EIP 96 and EIP 98 are theoretically implemented back when Vitalik was doing some experimentations for Casper, but it may be reparametrized a little bit. There are still couple of EIP those aren't done, so static calls are not done on them either.
- Update on C++ - Progress are half the way through, three EIPs are still not started, three are implemented and merged.
- Ethereum JS - It is a work in progress; team hasn't done any Metropolis related stuff so far except for one.
- Block time - If Ethereum community gets out the fork by June 25, 2017 and hash power stays as it is now then block time will not go above 19s.
- Timeline for Metropolis - There is still too much uncertainty to get on a hard date right now. Thats why development team decided to make no commitments and just to get stuff running and passing tests with medium – high priority. Once it gets clearer and get all closer towards it then they may agree to a date.
EIP 599: 'Valid until block' field for transactions
- Nick suggested to add an optional field which specifies that the transaction must be mined before they stay in block. And any transaction whose block number is before the current block number is discarded as it may not be relied and any transactions whose include before block number is too far in the future should be treated as hostile and generally not relied.
- The idea is in addition to make DAO attack harder also allows people to publish transaction they now believe be executed quickly or not at all good for operations.
- The existing transactions will still be fine with this proposal. Nodes must accept the blocks that contains transactions with fa future time stamps or with block numbers and with no block numbers, they would generally try to avoid relying them.
- Update the proposal according to EIP 232 for the next meeting.
Next meet is scheduled at Friday 5/5/17 at 14:00 UTC.
#crypto #ethereum #metropolis #EIP #blockchain
AlphaBay is one of the largest dark-net marketplace in the world. In March 2017 it announced that they are working on Ether payment functionality in AlphaBay Marketplace and will start accepting Ethereum as one of its payment methods effective from May 1, 2017.
According to an announcement made yesterday on reddit, Ethereum transactions are now live in AlphaBay Marketplace with 250k+ listings. One can now deposit, withdraw and tumble Ethereum on AlphaBay. Additionally they have improved the search engine by allowing “-” (a hyphen) in front of words to exclude them from search.
As per the text,
"----- Hash: SHA512 We are happy to announce that Ethereum transactions are now live on AlphaBay! You can now purchase your drugs using Ethereum. The minimum deposit and withdrawal amount is 0.1 ETH. Just like Bitcoin transactions, addresses will change after each deposit and will remain valid for 7 days after the first transaction. Sending coins to an expired address will result in loss of your coins. We strongly advise against manually typing addresses since Ethereum, unlike Bitcoin, does not have a checksum validation in its addresses so a single wrong character will result in an expensive mistake. Withdrawal processing time is around 10 minutes. Fee is 0.01 ETH for withdrawals. It is also recommended to check the PGP proof of ownership of your address before sending coins to ensure that you are not using a phishing link or malware. Additionally, we have designed a mixer that will allow you to mix your Ethereum in order to hide the origin of the coins. The mixing is done automatically so simply depositing and withdrawing your coins will mix them. However, for a better obfuscation, you should use a second service as well. The mixer can only work as well as the number of users making use of it. As a bonus, we upgraded our search engine to allow adding an hyphen in front of a search term to exclude listings containing this word. You can now use terms like "-guide -ebook" to exclude unwanted listings. -----"
However, many people think that introducing Ether payment is not worthy because, it may not be used frequently. Looking at the current price spike of Ether, no one would be interested in paying Ether worth of $1000 at dark-net when they know that tomorrow he might realize that he ended up paying $1500 for the same product. Some people also give the reasoning that its not fair to consider Ethereum as currency at all and it should be considered as commodity and trading with commodity is certainly not a very efficient mode of transaction. This thought is in align to IRS guidelines for 'Virtual Currency'. It states that“Virtual Currency Is Treated as Property for U.S. Federal Tax Purposes; General Rules for Property Transactions Apply”. Some may have doubts that use in dark-net market may damage the image of Ethereum and this is one thing the Dash / Monero type coins seem better for; because this is not one of the best use cases of digital currency.
Positive aspect of this news is that there is another successful implementation of Ethereum. It is a very good example of decentralization also that it is not being controlled where and how it should be used. Though, few users think that it would be better to have waited till integration of zk-SNARKS for more privacy. Best part is digital currency is growing, people are encouraged to use Ethereum for transaction. How successful or unsuccessful payment implementation in AlphaBay is, will be something that we have to wait and watch.
#crypto #blockchain #ethereum #alphabay #darknet
SEC approved review of Bitcoin ETF
The Securities and Exchange Commission (SEC) has rejected an application to create an Exchange-Traded Fund (ETF) tied to the price of Bitcoin proposed by Cameron and Tyler Winklevoss on Friday, March 10, 2017. A couple of weeks later, Bats BZX Exchange, Inc. (the “Exchange”) submitted a petition for review pursuant to Rule 154(c) of the Securities and Exchange Commission’s Rules of Practice. After a month of wait, SEC finally responded with granting the order to review the petition .
In a release SEC states that
“On March 24, 2017, pursuant to Rule 430 of the Rules of Practice,10 BZX filed a petition for review of the Disapproval Order. Pursuant to Rule 431 of the Rules of Practice,11 BZX’s petition for review of the Disapproval Order is granted. Further, the Commission hereby establishes that any party to the action or other person may file a written statement in support of or in opposition to the Disapproval Order on or before May 15, 2017.”
The ETF, initially proposed by investors Cameron and Tyler Winklevoss, offered an Index to track price of Bitcoin. It aims to provide an effortless way for investors to bet on the future price movement of Bitcoin, which has gone through several volatile swings. Investors, though, will pay for the work that the Winklevoss’s company will do to maintain and secure the Bitcoin held by the ETF. SEC rejected the proposal stating, "The commission notes that Bitcoin is still in the relatively initial stages of its development and that, over time, regulated Bitcoin-related markets of significant size may develop."
The breaking news of reviewing ETF acted as a catalyst to BTC price against US dollars. Yesterday, BTC reached all time high of $1345 per BTC and is expected to go further.
SEC seeking public comments about Ethereum ETF
Similar activities are also being reported from camp Ethereum. According to a release by SEC, an Ethereum ETF filed by EtherIndex LLC , a Delaware limited liability company is also under consideration.
Subject to approval, The EtherIndex Ether Trust will be the first exchange-traded product (“ETP”) in the United States that seeks to track the price of Ether - the cryptocurrency that powers the Ethereum network. It will issue EtherIndex Ether shares which represent units of fractional undivided beneficial interest in and ownership of the Trust. Investors unaware of Ethereum and Blockchain concept will also get an opportunity to access the Ether market through a traditional brokerage account. Prior to this offering, there has been no public market for the shares.
Ethereum ETF is not yet approved, though word in market is that SEC is secretly considering it. According to a recent release by SEC,
As stated in the release, “The investment objective of the Trust would be for the Shares to track the price of ether as measured by the price of ether in US dollars reported by the Global Digital Asset Exchange (“GDAX”) as of 4:00 p.m., Eastern Time (“GDAX Price”). The NAV of the Trust would be calculated each business day based on the GDAX Price. “
Many had doubts that Ethereum ETF will be rejected because of the same reason as that of BTC, the unregulated market. But, SEC sees it differently.
As reported, “According to the Exchange the private keys that control the Trust’s ether would be secured by the Custodian and stored completely offline in a “cold storage” system. The Exchange represents that the Custodian’s cold storage system is founded on the principles of (i) building defense-in-depth against external threats, (ii) protecting against human error, and (iii) guarding against misuse of insider access. The Custodian’s cold storage mechanism involves generating private keys on an “air-gapped” computer (i.e., a computer that has never been connected to the internet), then splitting these keys into segments using a special algorithm to ensure that no one individual knows how the key was fragmented, and finally distributing these fragments geographically so that no one entity can access the cold storage without the other individuals contributing their fragment of the key.
According to the Exchange, the Custodian maintains insurance against theft and electronic compromise in an amount that exceeds the average value of ether that it holds online at any one time. The Exchange also represents that the Trust may hold cash for short periods in connection with the creation and redemption process and to pay certain fees, expenses, and liabilities. “
It is speculated that ETF version of Ethereum will soon get approval as SEC is seeking Public Written Comments about Ethereum. It's likely to increase the value of Ether as a digital commodity when approved as it will provide shareholders with exposure to the daily change in the US dollar price of Ether. The news has already provoked investors and Ether price against USD. It has touched $70 per Ether mark and is expected to continue rising.
Please share your opinion in comment about which will get SEC's approval to form ETF?
#crypto #Bitcoin #Ethereum #ETF #SEC #news
The Minimal Slashing Condition is a set of rules to work with many hashes and some number of nodes to finalize a block. It is carefully designed that if two incompatible blocks are finalized, then no matter how such a situation arises, there MUST exist some set of validators, with total size equal to at least 1/3 of recent active validator set, which sent messages that trigger some slashing condition.
A key goal of Casper (Proof of Stake) is that of achieving “economic finality”.
“A block B1 is economically finalized, with cryptoeconomic security margin $X, if a client has proof that either (i) B1 is going to be part of the canonical chain forever, or (ii) those actors that caused B1 to get reverted are guaranteed to be economically penalized by an amount equal to at least $X.” - Vitalik Buterin
Economic finality refers to one of two conditions:
- The condition where a sufficient number of validators have signed cryptoeconomic claims of the form "I agree to lose X in all histories where block B is not included". This gives clients assurance that either
(i) B is part of the canonical chain, or
(ii) validators lost a large amount of money in order to trick them into thinking that this is the case.
- The condition where a sufficient number of validators have signed messages expressing support for block B, and there is a proof that if some B' != B is also finalized under the same definition then validators lose a large amount of money. If clients see this, and also validate the chain, and validity plus finality is a sufficient condition for precedence in the canonical fork choice rule, then they get an assurance that either
(i) B is part of the canonical chain, or
(ii) validators lost a large amount of money in making a conflicting chain that was also finalized.
It is accomplished in Casper by introducing the concept of 'bonded validators; requiring validators to submit deposits in order to participate, and taking away their deposits if the protocol determines that they acted in some way that violates rules.
'Slashing Condition' is the set of rules which if violated by the validators in Casper, will end up slashing (deleting) the deposits. Slashing conditions are kind of law to the validators that they are not supposed to break. An honest validator follows the protocol (that defines a set of slashing conditions), that is guarenteed not to trigger any of the conditions that may end up loosing his deposit.
If a validator sends a signed message of the form
["PREPARE", epoch, HASH1, epoch_source1]
and a signed message of the form
["PREPARE", epoch, HASH2, epoch_source2]
where HASH1!= HASH2 or epoch_source1!= epoch_source2, but the epochvalue is the same in both messages, then that validator’s deposit is slashed (ie. deleted)
An honest validator is not supposed to send “PREPARE” message twice in the same epoch. “PREPARE” and “COMMIT” are terms borrowed from traditional Byzantine-fault-tolerant consensus theory. They are considered as being two different types of messages that are used in achieving consensus in Casper. Consensus will require two rounds of agreement, where PREPARE represents the first round and COMMIT represents the second round.
The intention is to make 51% attacks extremely expensive, so that even a majority of validators working together cannot roll back finalized blocks without undertaking an extremely large economic loss.
Slashing conditions need to satisfy two conditions:
- Accountable safety: It states that if two conflicting hashes get finalized, then it must be provably true that at least 1/3 of validators violated some slashing condition. This brings the idea of “economic finality”. If this happens, then we have mathematical proof that a large set of validators must have violated some slashing condition. "Evidence" of this fact can be sent into the Casper contract; expecting evidence is simultaneously easy to detect, and will effectively be submitted by a miner (because "stealable"). The validator's entire deposit will be destroyed except 4%, which is given to the evidence submitter as a "finder's fee".
Algorithm 1: every validator has exactly one opportunity to send a message of the form ["COMMIT", HASH]. If 2/3 of validators send a COMMIT for the same hash, that hash is finalized. Sending two COMMIT messages violates a slashing condition.
Now, if HASH1 and HASH2 both get finalized, then that means that each one has 2/3 commits, and so there must be 1/3 overlap, so 1/3 of validators get slashed (Diagram: Safety Proof A). It is an obvious proof that this algorithm is safe . But it is not plausibly live: if 1/2 commit A and 1/2 commit B (this could happen accidentally), then 1/6 of validators must voluntarily slash themselves in order to finalize a hash (Diagram: Safety Proof .
Diagram*: Safety Proof A
Diagram*:Safety Proof B
Plausible liveness: It states that unless at least 1/3 of validators violated some slashing condition, there must exist a set of messages that 2/3 of validators can send which finalize some new hash without violating some slashing condition. It means, “it should not be possible for the algorithm to get ‘stuck’ and not be able to finalize anything at all”.
Algorithm 2: every validator has exactly one opportunity to send a message of the form ["COMMIT", HASH, epoch]. If 2/3 of validators send a COMMIT for the same hash with the same epoch number, that hash is finalized. Sending two COMMIT messages with different hashes with the same epoch number violates a slashing condition.
This gets around the problem in the previous algorithm, as if during one epoch we get a 50/50 situation then we can simply try again in the next epoch. But this introduces a safety flaw (no more safety): two different hashes can get finalized in different epochs (Diagram: Safety Proof C).
Diagram*: Safety Proof C
This is nontrivial, but possible to get both finalized in different epochs at the same time, it requires 4 slashing conditions, plus 1000 lines of code for Yoichi to formally prove that it actually works. These four slashing conditions are explained in Minimal Slashing Conditions by Vitalik.
If two hashes are both part of the same history then they can both get finalized, and in fact an ever-growing chain where more and more hashes at the end of the chain get finalized, then it is working as intended (Non conflicting hashes). The issue arises if hashes that are not part of the same history are conflicting. However, there is a proof that the four slashing conditions prevent two conflicting hashes from being finalized unless at least 1/3 of validators get slashed (Conflicting hashes).
Diagram*: Non conflicting hashes & Conflicting hashes
Economic rewards are added for the validators to send these PREPARE and COMMIT messages, so that enough messages get sent in time for finalization to actually happen.
Plausible liveness means that we theoretically can always finalize something, but we're repeatedly getting unlucky and never end up finalizing anything. To solve the problem of plausible liveness and ensure help achieve liveness, a mechanism is proposed called Proposal Mechanics. It proposes hashes, which the rest of the machinery (with PREPARE and COMMIT messages) then tries to finalize. But it may be faulty sometimes, so it’s the job of the slashing conditions to ensure that even if the proposal mechanism is faulty, there are no safety failures and the protocol can finalize something once the proposal mechanism stops being faulty.
Practical Byzantine Fault Tolerant (PBFT) is used to establish consensus in blockchain systems. This is one of the potential solutions to the Byzantine-fault-tolerant consensus algorithms, of which Minimal Slashing Condition is a key component.
In PBFT, every view (roughly equivalent to an epoch) is assigned a single validator, and that validator is free to propose whatever they want; they may misbehave by proposing nothing, proposing invalid hashes or proposing multiple hashes, but the other parts of the PBFT machinery ensure that such actions are not fatal, and the algorithm eventually switches over to the next epoch.
In PBFT, we can combine slashing conditions with different kinds of proposal mechanisms, if they satisfy below conditions:
the proposal mechanism must propose one hash per epoch, and it must be a valid hash.
the hashes must form a chain; that is, a hash submitted for epoch N must have a parent that was submitted for epoch N-1, a 2nd degree ancestor that was submitted for epoch N-2, etc.
the hashes must be hashes that the slashing conditions do not prevent validators from finalizing.
Fork choice rule
Rule that allows a blockchain to serve as the proposal mechanism for a consensus algorithm is called as a Fork choice rule. It is a function, evaluated by the client, that takes as input the set of blocks and other messages that have been produced, and outputs to the client what the “canonical chain” is. “Longest valid chain wins” is a simple fork choice rule and works well for PoW. GHOST is a more complicated and is there in Casper PoS.
Start off with HEAD being the genesis block.
Find the valid descendant of HEAD that has 2/3 prepares and the largest number of commits
Set HEAD to equal that descendant and go back to step 2.
When step 2 can no longer find a descendant with 2/3 prepares and any commits, use the blockchain’s underlying fork choice rule (longest-chain, GHOST, whatever) to find the tip.
A specific condition which help clients determine that a particular hash is finalized and can not be reverted back is called as 'Finality Condition'. A 'hash' is decided if 'COMMIT' message is received from two third of the active validators pool.
“A HASH is finalized if, for some particular epoch number, there exists a set of signed messages of the form
["COMMIT", epoch, HASH]
and if you add up the deposited balances of the validators that created these signed messages then you get an amount that is more than 2/3rd of the total deposited balances of the current active validator set.” - Vitalik Buterin
In other words, we can say “the hash was committed in some particular epoch by 2/3 of validators”, or “the hash has 2/3 commits in some particular epoch”. This finality condition is implemented in Casper version 1.
In full node, determining that a given hash is finalized is a two-step process of
(i) checking for the 2/3 commits, and
(ii) checking that the chain up to the hash is valid.
To make finality work for light clients, there are two approaches.
to add another kind of message that nodes can send (call it ["ATTEST", HASH, epoch] ), which has the effect that if this message is submitted into a chain where the given hash actually is the hash at that epoch, the validator gets a small reward, but if it is not then they pay a large penalty.
to give light clients access to various cryptoeconomic techniques that will allow them to verify data availability and validity very efficiently with the help of some weak honest minority assumptions; this will likely involve a combination of erasure codes and interactive verification.
Diagram* - Diagrams taken from Minimal Slashing Conditions by Vitalik.
#crypto #ethereum #blockchain #minimalslashingcondition #pbft #finalityconditions #economicfinality
- The condition where a sufficient number of validators have signed cryptoeconomic claims of the form "I agree to lose X in all histories where block B is not included". This gives clients assurance that either
Coinbase, a digital asset exchange company is in process of launching an Ethereum based mobile messaging application. Brian Armstrong, Co-Founder and CEO at Coinbase, introduces “Token” to the world via Medium.
“Token” is a mobile application that works on open protocols inspired by another app called 'WeChat', that is driving a large volume of digital payments in China. It is an open financial system with a combination of a private and secure messaging app, a user controlled Ethereum wallet and a browser for Ethereum apps.
Token runs on phone and allows to access an open network; its architecture is similar to a web browser. It has a built-in reputation system which lets one knows who can be trusted. Every user and app builds reputation over time as they transact with others on the platform.
Token is built with a vision of providing financial services to billion peoples of developing world who have a cell phone, but don’t have access to a bank account. It will make it easier for people to build and use Ethereum applications. Token will probably shift digital currency from being just a speculative investment to being a payment network for useful goods and services.
“Delivering financial services by mobile phone could benefit billions of people by spurring inclusive growth that adds $3.7 trillion to the GDP of emerging economies within a decade.” - McKinsey Global Institute
It is an open source system. The developer's preview of Token is released using testnet Ethereum on April 18, 2017, so there is no real money to lose if one encounter an issue. Developer who wants to test it can install the Token app on Android and iOS. Developer documentation and discussion forum are also available for those who are interested in building an application.
Token is built over Ethereum instead of Bitcoin because of very high transaction fees for small payments. Team envision a large number of small payments happening with Token, so started with Ethereum. In the future, they may also support other digital currencies, as it's still unclear which digital currency will work best for long term.
Mobile money is growing. Several countries have revolutionized payments like WeChat in China, PayTM in India, MPESA in Kenya, and others. 'Token' enables a global payment network based on open standards, with a goal to provide access to financial services to everyone and that every country becomes interoperable.
#cryptonews #Ethereum #Token #coinbase #blockchain #messagingapp #news #testnet