Ethereum (ETH) - POW/POS - Ethash

  • Ethereum Debit Card

    Ethereum debit card

    Ethereum debit card is a card that links directly to your Ethereum and keeps your money protected.

    Ethereum debit card allows you to pay, simply and securely, in person, online, over the phone or through the mail. UQUID account help you loading money into your card, keep track of your spending and  balance.

    • Ethereum debit card can be used whether you're home or away, at any time of day or night, so there's no need for cash
    • Wherever you use Ethereum debit card, you are fully protected. If, for example, you're unfortunate enough to book a holiday with an airline or travel agent that becomes insolvent, you'll generally get your money back. Similarly, if you order something that is not delivered, not as described, or arrives faulty or damaged, you’ll receive a full refund
    • It's a safe, secure way to pay, backed up by proven security technologies like Verified by Visa and Chip and PIN
    • It's more versatile than cash, and if you lose it, you can order a replacement
    • As millions of VISA customers around the world have found, you can easily use Ethereum debit card everyday, everywhere, for everything


    5 Reasons to choose UQUID Ethereum debit card




    Instant load with 0% fee


    eth anonymous debit card




    We do not require for ID or verification.


    virtual eth debit card




    You can get unlimited cards with only 1 UQUID account

    eth debit card worldwide delivery




    Our card ships free to 178 + countries with no fees. Typically within 2-3 working days

    avs eth debit card




    You can link your card with your address information. Get easy for shopping at Amazon, Uber, Skrill ...

  • An Update on Integrating Zcash on Ethereum (ZoE)

    Members of the Ethereum R&D team and the Zcash Company are collaborating on a research project addressing the combination of programmability and privacy in blockchains. This joint post is being concurrently posted on the Zcash blog, and is coauthored by Ariel Gabizon (Zcash) and Christian Reitwiessner (Ethereum).

    Ethereum’s flexible smart contract interface enables a large variety of applications, many of which have probably not yet been conceived. The possibilities grow considerably when adding the capacity for privacy. Imagine, for example, an election or auction conducted on the blockchain via a smart contract such that the results can be verified by any observer of the blockchain, but the individual votes or bids are not revealed. Another possible scenario may involve selective disclosure where users would have the ability to prove they are in a certain city without disclosing their exact location. The key to adding such capabilities to Ethereum is zero-knowledge succinct non-interactive arguments of knowledge (zk-SNARKs) – precisely the cryptographic engine underlying Zcash.

    One of the goals of the Zcash company, codenamed Project Alchemy, is to enable a direct decentralized exchange between Ethereum and Zcash. Connecting these two blockchains and technologies, one focusing on programmability and the other on privacy, is a natural way to facilitate the development of applications requiring both.

    As part of the Zcash/Ethereum technical collaboration, Ariel Gabizon from Zcash visited Christian Reitwiessner from the Ethereum hub at Berlin a few weeks ago. The highlight of the visit is a proof of concept implementation of a zk-SNARK verifier written in Solidity, based on pre-compiled Ethereum contracts implemented for the Ethereum C++ client. This work complements Baby ZoE , where a zk-SNARK precompiled contract was written for Parity (the Ethereum Rust client). The updates we’ve made involved adding tiny cryptographic primitives (elliptic curve multiplication, addition and pairing) and implementing the rest in Solidity, all of which allows for a greater flexibility and enables using a variety of zk-SNARK constructions without requiring a hard fork. Details will be shared as they are available later. We tested the new code by successfully verifying a real privacy-preserving Zcash transaction on a testnet of the Ethereum blockchain.

    The verification took only 42 milliseconds, which shows that such precompiled contracts can be added, and the gas costs for using them can be made to be quite affordable.

    What can be done with such a system

    The Zcash system can be reused on Ethereum to create shielded custom tokens. Such tokens already allow many applications like voting, (see below) or simple blind auctions where participants make bids without the knowledge of the amounts bid by others.

    If you want to try compiling the proof of concept, you can use the following commands. If you need help, see

    git clone
    cd libsnark
    sudo PREFIX=/usr/local make NO_PROCPS=1 NO_GTEST=1 NO_DOCS=1 \
       CURVE=ALT_BN128 \
       lib install
    cd ..
    git clone --recursive -b snark
    cd cpp-ethereum
    ./scripts/ && cmake . -DEVMJIT=0 -DETHASHCL=0 && make eth
    cd ..
    git clone --recursive -b snarks
    cd solidity
    ./scripts/ && cmake . && make soltest
    cd ..
    ./cpp-ethereum/eth/eth --test -d /tmp/test
    # And on a second terminal:
    ./solidity/test/soltest -t "*/snark" -- --ipcpath   /tmp/test/geth.ipc  --show-messages

    We also discussed various aspects of integrating zk-SNARKs into the Ethereum blockchain, upon which we now expand.

    Deciding what precompiled contracts to define

    Recall that a SNARK is a short proof of some property, and what is needed for adding the privacy features to the Ethereum blockchain are clients that have the ability to verify such a proof.

    In all recent constructions, the verification procedure consisted solely of operations on elliptic curves. Specifically, the verifier requires scalar multiplication and addition on an elliptic curve group, and would also require a heavier operation called a bilinear pairing.

    As mentioned here, implementing these operations directly in the EVM is too costly. Thus, we would want to implement pre-compiled contracts that perform these operations. Now, the question debated is: what level of generality should these pre-compiled contracts aim for.

    The security level of the SNARK corresponds to the parameters of the curve. Roughly, the larger the curve order is, and the larger something called the embedding degree is, and the more secure the SNARK based on this curve is. On the other hand, the larger these quantities are, naturally the more costly the operations on the corresponding curve are. Thus, a contract designer using SNARKs may wish to choose these parameters according to their own desired efficiency/security tradeoff. This tradeoff is one reason for implementing a pre-compiled contract with a high level of generality, where the contract designer can choose from a large family of curves. We indeed began by aiming for a high level of generality, where the description of the curve is given as part of the input to the contract. In such a case, a smart contract would be able to perform addition in any elliptic curve group.

    A complication with this approach is assigning gas cost to the operation. Yu must assess, merely from the description of the curve, and with no access to a specific implementation, how expensive a group operation on that curve would be in the worst case. A somewhat less general approach is to allow all curves from a given family. We noticed that when working with the Barreto-Naehrig (BN) family of curves, one can assess roughly how expensive the pairing operation will be, given the curve parameters, as all such curves support a specific kind of optimal Ate pairing. Here’s a sketch of how such a precompile would work and how the gas cost would be computed.

    We learned a lot from this debate, but ultimately, decided to “keep it simple” for this proof of concept: we chose to implement contracts for the specific curve currently used by Zcash. We did this by using wrappers of the corresponding functions in the libsnark library, which is also used by Zcash.

    Note that we could have simply used a wrapper for the entire SNARK verification function currently used by Zcash, as was done in the above mentioned Baby ZoE project. However, the advantage of explicitly defining elliptic curve operations is enabling using a wide variety of SNARK constructions which, again, all have a verifier working by some combination of the three previously mentioned elliptic curve operations.

    Reusing the Zcash setup for new anonymous tokens and other applications

    As you may have heard, using SNARKs requires a complex setup phase in which the so-called public parameters of the system are constructed. The fact that these public parameters need to be generated in a secure way every time we want to use a SNARK for a particular circuit significantly, hinders the usability of SNARKs. Simplifying this setup phase is an important goal that we have given thought to, but haven’t had any success in so far.

    The good news is that someone desiring to issue a token supporting privacy-preserving transactions can simply reuse the public parameters that have already been securely generated by Zcash. It can be reused because the circuit used to verify privacy-preserving transactions is not inherently tied to one currency or blockchain. Rather, one of its explicit inputs is the root of a Merkle tree that contains all the valid notes of the currency. Thus, this input can be changed according to the currency one wishes to work with. Moreover, if it is easy to start a new anonymous token. You can already accomplish many tasks that do not look like tokens at first glance. For example, suppose we wish to conduct an anonymous election to choose a preferred option amongst two. We can issue an anonymous custom token for the vote, and send one coin to each voting party. Since there is no “mining”, it will not be possible to generate tokens any other way. Now each party sends their coin to one of two addresses according to their vote. The address with a larger final balance corresponds to the election result.

    Other applications

    A non-token-based system that is fairly simple to build and allows for “selective disclosure” follows. You can, for example, post an encrypted message in regular intervals, containing your physical location to the blockchain (perhaps with other people’s signatures to prevent spoofing). If you use a different key for each message, you can reveal your location only at a certain time by publishing the key. However, with zk-SNARKs you can additionally prove that you were in a certain area without revealing exactly where you were. Inside the zk-SNARK, you decrypt your location and check that it is inside the area. Because of the zero-knowledge property, everyone can verify that check, but nobody will be able to retrieve your actual location.

    The work ahead

    Achieving the mentioned functionalities – creating anonymous tokens and verifying Zcash transactions on the Ethereum blockchain, will require implementing other elements used by Zcash in Solidity.

    For the first functionality, we must have an implementation of tasks performed by nodes on the Zcash network such as updating the note commitment tree.

    For the second functionality, we need an implementation of the equihash proof of work algorithm used by Zcash in Solidity. Otherwise, transactions can be verified as valid in themselves, but we do not know whether the transaction was actually integrated into the Zcash blockchain.

    Fortunately, such an implementation was written; however, its efficiency needs to be improved in order to be used in practical applications.

    Acknowledgement: We thank Sean Bowe for technical assistance. We also thank Sean and Vitalik Buterin for helpful comments, and Ming Chan for editing.

    Christian Reitwiessner


  • Ethereum swarm start script (German)

  • Geth V 1.5.8 Released with few bug fixes 

    Geth v1.5.8 is a patch release to address bugs and annoyances. For a full rundown of the changes please see the 1.5.8 milestone.

    Notable changes:

    • Gas estimation now does binary search to find the right amount of gas even in complex refund conditions where the required gas is higher that the final consumption. (#3587)
    • ECDSA signing uses a deterministic nonce. This change affects transaction signing. (#3561)
    • A new developer tool, cmd/wnode, allows testing the Whisper v5 protocol. (#3580)

    Binaries and mobile libraries are available on our download page.

  • Ethereum Wallet and Mist 0.8.9 Release - "The Wizard"

    Mist Wizard Installer

    • Full fledged Windows Installers: This version includes the new installer for Windows created by @tgerring, which lets you choose the directory to install Mist in, as well as the data-dir of the ethereum node. It's one installer for both 32 and 64-bit computers.
    Note that the data-dir is set as a parameter in Mist shortcut properties, at the installation stage; not in Mist's preferences.
    • App Signing: Mist for Mac OS X is now signed by the Ethereum Foundation.

    • Solidity Compiler: Now featuring version 0.4.8.

    Remix IDE

    Remix IDE option on menu
    0.8.9 also has a new menu entry to open Remix IDE, so now you have
    plenty of room to write your contracts without leaving Mist. Head to Develop > Open Remix IDE.


    • A test suite is born: It was about time for Mist to have a solid set of integration tests. Now we're starting to kill this debt with a Spectron#1571.

    See the full changelog at Milestone 0.8.9.

    Checksums (SHA256)


  • Ethereum (ETH) New Exchange:

  • Ethereum (ETH)  New Exchange:


  • Ethereum IoT Project Wins $100k in Dubai Blockchain Hackathon

    A startup building an ethereum-based platform for IoT applications has won $100,000 at a blockchain hackathon in Dubai

    .For more details log

  • Ethereum Parity fast sync for Ropsten testnet



    Source :

    Switch from Geth to Parity

    There appears to be a bug with Geth syncing with Ropsten testnet on some systems.  This was the case with attempting to sync the full blockchain and with the –fast flag (including using -cache=512, etc) and despite having a high powered computer with a SSD .

    After trying various workarounds for several days and getting advice on the Geth Gitter channelParity.

    I wish I had done it sooner.  Details on the the Parity WikiParity Gitter channel.

    $ bash <(curl -Lk)
    $ parity --warp --chain ropsten

    or for the live env

    $ parity --warp

    Point your browser to http://localhost:8080/web3 Javascript API for interacting with an Ethereum client.  You can install node/NPMNode.js / npm and then use it to install web3 library:

    $ sudo apt-get install nodejs
    $ npm install web3
    $ node
    > Web3 = require("web3")
    > web3 = new Web3(new Web3.providers.HttpProvider("http://localhost:8545"));

    After this point, you’ll be able to use the web3 API from with this environment, e.g.:

    > web3.eth.blockNumber

    Exit that and create a new file called parityNode.js with the following:

    repl = require("repl");
    Web3 = require("web3");
    context = repl.start("$ ").context;
    context.web3 = new Web3(new Web3.providers.HttpProvider("http://localhost:8545"));

    You can then start node.js using that script and access Parity via web3 immediately:

    $ chomd 744 parityNode.js
    $ ./parityNode.js
    > web3.eth.blockNumber

    About Author 

    Technologist and Entrepreneur on an adventure to see how Blockchain and AI will change the world!

  • Ethereum R&D Roundup: Valentine’s Day Edition

    During the last month and a half, the Ethereum core development and research teams have been building upon the progress made in the last year, and with the specter of last year’s security issues now well behind us, work has begun in full force on implementing the Metropolis hard fork.

    First, ongoing progress on the collaboration with the Zcash team and the implementation of zk-SNARKs:

    On the proof of stake front, myself and Vlad and others have continued to solidify the Casper specification and converge on a roadmap. A key focus of our work has been on a notion of “protocol armor”, which can turn many classes of traditional Byzantine-fault-tolerant consensus algorithms into “attributable-fault consensus algorithms”, where if there is a protocol failure then not only do you know that a large number of validators were faulty, but you also know whom to blame. The work has not yet been fully written out, though it will be further formalized and presented soon, and anyone interested is free to follow along at

    A post on parametrizing Casper was written here: https:[email protected]..

    We had twomeetings, and have approved the following EIPs for likely inclusion into Metropolis:

    Additionally, there were a few changes to the EIP process itself:

    Work on Mist, Swarm, ENS and associated infrastructure is continuing at a rapid pace; Swarm is now at the stage where it can serve the wallet app, though the incentivization logic is not yet in place.

    Work on programming languages is also moving forward:

    • Solidity is adding a fully specified way to access the compiler input, settings and output: https://solidity.readthedocs.i...
    • There are plans (not yet completed) to add an intermediate language to Solidity to help with understanding what the compiler does and auditing compiler output
    • In the community, the fp-ethereum functional programming initiative got some attention
    • Viper saw another round of improvements, including support for unit types (timestamp, timedelta, wei, wei per second, etc), bytearrays and more builtin functions: environment Remix added much more powerful debugging support

    Work on implementations is progressing:

    We wish everyone a happy Valentine’s day!


    Vitalik Buterin

  • Investigating Go 1.8 build issues on ARM64

    Light client

  • Author 


  • European Ethereum Development Conference: Recap

    For those of you who were lucky enough to be at EDCON in Paris last week, it was a real pleasure — it never ceases to amaze us the speed at which this ecosystem is developing, and the openness of the Ethereum community.

    Jarrad’s talk, entitled “Status: Lowering Ethereum’s Barriers to Entry,” which outlines our roadmap for the year will be available on our YouTube Channel in the coming days.

    Product Announcements & Development Updates

    Below is a very brief summary of some of the talks at the event. By no means is this a complete list, and unfortunately we could only find slides for a handful of them, so have tried to include links to each project website where applicable.

    Intro to Crypto-economics — Vitalik Buterin. View the slides here.

    Casper — Vlad Zamfir. View the slides here.

    Ethereum Governance Mechanism — Christoph Jentzsch. View the slides here.

    Ethereum Name Service — Nick Johnson. “Distributed Naming with ENS”. Set to be released on Mainnet shortly.

    SWARM— Dr. Aron Fischer. We couldn’t be more excited about this! View the slides here.

    Trustlines— Heiko Hees and the Team at Brainbot. Based on the original Ripple idea, and developed the team behind Raiden, Trustlines enables path of trust relationships that can be chained together in such a way to have payments between participants on the network that don’t know each other.

    Omise Go— Thomas Greco announced Omise Go, an E-Wallet platform, aimed primarily at the unbanked populations in Asia, and we can expect to see a token-sale to support the platform in Q2.

    JAAK Announce MΞTA — Vaughn McKenzie presented MΞTA, a decentralized open network, backed by Ethereum and Swarm, which enables organizations to capture, store, verify and communicate commercial metadata.

    Giveth — Griff Green gave an entertaining presentation about Giveth, a project aimed to better structure the incentive mechanisms behind how charities operate. Watch it on Periscope.

    Aragon — Luis Cuende and Jorge Izquierdo, the friendly team behind Aragon, gave us a glimpse of how companies and organizations can be formed and governed in the future.

    Ares Protocol by Boardroom— Nick Dodson. Governance smart-contracts for decentralized collaborative decision making. View the slides here. —Raphaël Mazet. Hyper-transparent philanthropy, where donors only pay for results. The concept being Alice can help charities raise funds in a way where donors only pay for the successful social programmes.

    StabL— Hadrien Charlanes & Vincent Eli. StabL, a Consensys spoke, aims to provide DApps and individuals access to stable values on the blockchain, an important piece of the infrastructure.— Sergey Nazarov “Give your smart contracts reliable access to critical data feeds, any web API and widely accepted payments.

    SmartPool — Loi Lee. SmartPool aims to replace the centralized pool operators with smart contracts, resulting in greater decentralization of pools, low fees, and mitigation of the transaction censorship threat. View the slides here.

    MelonPort —Mona El Isa. After a successful token launch the Melonport protocol for digital asset management has since made their work thus far open sourceView the slides here.

    Akasha — “You are paying free services in Microviolations of your privacy." Mihai Alisie presented updates on Akasha, a decentralized social media network using Ethereum + IPFS.

    William Mougayar ‘State of the Ethereum Ecosystem’ — A special thanks to William for letting us do another quick presentation at the Investor Forum Sub-conference! View the slides here.

    Etherisc — Stephan Karpischek. Decentralized insurance applications.View the slides here. — Dr. Gilles Fedak. “The Distributed Cloud: Latest Developments and Perspectives.” View the slides here.

    ETHOn — Johannes Pfeffer presents“EthOn: Introducing Semantic Ethereum.”Read the blog post.

    Streamer— Henri Pihkala. “Connecting Ethereum with the real world: How to easily create data-driven smart contracts. — Quentin de Beauchesne.“Ledgys Data Network : A Decentralized Data Marketplace.”

    Gnosis — Stefan George. “Fund Security — How to Keep Assets Safe on Ethereum.”

    Bancor — Eyal Hertzog. “A hierarchical monetary system and the foundation of a global, decentralized, autonomous exchange.” Read about the protocol.

    Oraclize — Thomas Bertani. “The Oraclize Oracle Service: Authenticity Proofs.”

    Ledger— Nicolas Bacca. “Next Generation Hardware Wallets — Interacting with Smart Contracts from Secure Hardware” View the slides here.

    Cosmos — Jae Kwon. “Cosmos, the Internet of Blockchains — how to create an network of blockchains for scalability and interoperability.” Read the whitepaper.

    Stratumn —Anuj Das Gupta & Richard Caetano. “Going beyond decentralized networks with prover-verifier systems.”Read more about it.

    ABDK Consulting — Dmitry Khovratovich. “Secure Token Development and Deployment.” View the slides here.

    Ledger Labs — Jeff Coleman.“Counterfactual instantiation: an object oriented approach to fully abstracting state channels.”

    Parity — Gavin Wood.

    “Battling the blackhats” — Joseph Chow.

    “The ‘Shanghai’-attacks” — Martin Holst Swende, Ethereum Core.

    “Towards an Extensible Blockchain” Martin Becze & Alex Beregszaszi, Ethereum Core.

    “Blockchains: the New Home of Formally Verified Software” —Yoichi Hirai, Ethereum Core.

    A Few Photos…

    A highlight for us, the PoS Panel which concluded Day 1, moderated by Rick Dudley

    Heiko Hees presenting TrustLines

    Ethereum Foundation Researcher Loi Lee presenting SmartPool

    Stabl is a stable currency project, from Consensys

    Join The Status Community

    We’re an open source project and contributors are welcome! If you’d like to learn more about Status, head on over to the Status Wiki, and come say hi in the Status Slack Channel.



  • Log in to reply

    Looks like your connection to Cryptocentral was lost, please wait while we try to reconnect.