Ethereum (ETH) - POW/POS - Ethash
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
NO FEE DEPOSIT
Instant load with 0% fee
We do not require for ID or verification.
MULTI CARDS BUY SUPPORT
You can get unlimited cards with only 1 UQUID account
FAST AND FREE DELIVERY
Our card ships free to 178 + countries with no fees. Typically within 2-3 working days
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 https://gitter.im/ethereum/pri...
git clone https://github.com/scipr-lab/libsnark.git cd libsnark sudo PREFIX=/usr/local make NO_PROCPS=1 NO_GTEST=1 NO_DOCS=1 \ CURVE=ALT_BN128 \ FEATUREFLAGS="-DBINARY_OUTPUT=1 -DMONTGOMERY_OUTPUT=1 \ -DNO_PT_COMPRESSION=1" \ lib install cd .. git clone --recursive -b snark https://github.com/ethereum/cpp-ethereum.git cd cpp-ethereum ./scripts/install_deps.sh && cmake . -DEVMJIT=0 -DETHASHCL=0 && make eth cd .. git clone --recursive -b snarks https://github.com/ethereum/solidity.git cd solidity ./scripts/install_deps.sh && 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.
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.
Ethereum swarm start script (German)
Geth V 1.5.8 Released with few bug fixes
- 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"
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-dirof the ethereum node. It's one installer for both 32 and 64-bit computers.
Note that the
data-diris 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 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.
Ethereum-Wallet-macosx-0-8-9.dmg a244daa82abd4e607672dc375e5b5060266104f81f12045e199265e92655c8c3 Ethereum-Wallet-linux32-0-8-9.deb 0d37b4710b6eab39467df4dd3587c693c40f54cae919e815693cb14c92836586 Ethereum-Wallet-linux32-0-8-9.zip 9b61e43c0ec1655de04382f67c99f518cf854bc57f89cd7a63d9d93752723d01 Ethereum-Wallet-linux64-0-8-9.deb 53c6a839859c5ba824fbaff427326e05e6b238d05387ff61a83041e9bfb81dfc Ethereum-Wallet-linux64-0-8-9.zip 2ee9a5d3ac0a4eb944f9d397392a77e7fda45439ae787e13684bdef58d29b538 Ethereum-Wallet-win32-0-8-9.zip 7df2f1e8ba097aefe65fe8310024e61ccecc6b91cf34f916d38f396c1ff37fb0 Ethereum-Wallet-win64-0-8-9.zip a46f09c1b63e63c8e42fea96bc184dc508381cfe29672c6417d37230966a6493
mist-installer-0-8-9.exe 959bbe051f63f3a4e2336b69308e9b6a5e8564b68ae361c3aad3d55cb03e6ee3 Mist-linux32-0-8-9.deb 97b2ee47159bf32772fe21704f72333d0a597181282ec546f43494546f48e417 Mist-linux32-0-8-9.zip ab62752d235bafc878bd68e461be45c6d45d7d746883c6b3b79fdddf4ea1c15b Mist-linux64-0-8-9.deb 9657a9261e25173087eda29499db88aed7adcb4344ead914eaa692093c55ba62 Mist-linux64-0-8-9.zip 2d19445afc242b6337c5681627b9a21aca5ba5b7aa60cc7ba683e2f5d9bea6bb Mist-macosx-0-8-9.dmg 3d09306f8e53e315da73571d52adf15adfd4c30e43a8b4251099bc5f7aeda986
- 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
Ethereum (ETH) New Exchange:
Ethereum (ETH) New Exchange:
ETH LISTED ON:
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 http://www.xbt.money/ethereum-...
Ethereum Parity fast sync for Ropsten testnet
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 https://get.parity.io -Lk) $ parity --warp --chain ropsten
or for the live env
$ parity --warp
$ 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 743397
Exit that and create a new file called parityNode.js with the following:
#!/usr/bin/node 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 743397
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:
- The full series of “zk-SNARK explainer” posts from myself is now finished, see https:[email protected][email protected]s:[email protected]/exploring-elliptic-curve-pairings-c73c1864e627 and https:[email protected]/zk-snarks-under-the-hood-b33151a013f6https://blog.ethereum.org/2017/01/19/update-integrating-zcash-ethereum/
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 https://gitter.im/ethereum/casper-scaling-and-protocol-economics.
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:
- http://github.com/ethereum/EIPs/issues/86http://github.com/ethereum/EIPs/issues/100 (uncle mining incentive fix)
- https://github.com/ethereum/EIPs/issues/196https://github.com/ethereum/EIPs/issues/197 (elliptic curve pairings, the key ingredient for on-chain zk-SNARK verification)
- https://github.com/ethereum/EIPs/issues/198https://github.com/ethereum/EIPs/pull/206 (REVERT opcode, equivalent to the “throw” keyword in Solidity but without burning extra gas)
- https://github.com/ethereum/EI... (blockhash refactoring, serving the triple duty of (i) simplifying consensus logic, (ii) allowing the BLOCKHASH opcode to refer much further back, and (iii) enabling much more efficient and secure light client initial-syncing protocols)
Additionally, there were a few changes to the EIP process itself: https://www.reddit.com/r/ether...
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: https://github.com/ethereum/viper/commits/masterdevelopment environment Remix added much more powerful debugging support
Work on implementations is progressing:
- The cpp-ethereum project is experimenting with the performance of the EVM. Some results suggest that the EVM might be able to get up to a small linear factor close to “raw metal” with the more structured EVM 1.5 modelhttps://github.com/ethereum/go-ethereum/releases/tag/v1.5.9
- Work on integrating the recent pyethereum changes into pyethapp is continuing: https://github.com/ethereum/py...
We wish everyone a happy Valentine’s day!
Ethereum dairy of Week 7
- EVM Fuzzing https://github.com/ethereum/go-ethereum/pull/3672https://github.com/ethereum/go-ethereum/pull/3654
bugcommand to open issues on GH https://github.com/ethereum/go-ethereum/pull/3684https://github.com/ethereum/go-ethereum/pull/3680
- Fix Ledger on OSX, require less fuss on Windows https://github.com/ethereum/go-ethereum/pull/3681https://github.com/karalabe/hid
- Investigating Go 1.8 build issues on ARM64 https://github.com/golang/go/issues/19137
- implemented request distributor & fixed blocking requests https://github.com/ethereum/go-ethereum/pull/3660
StateTests converted to blockchain tests and now running on hive. Found a couple of issues which are now fixed. Metropolis tests are on the way. CPP ropsten node is now on morden.io
- chunk integrity check improvements https://github.com/ethereum/go-ethereum/pull/3665https://github.com/ethereum/go-ethereum/pull/3651
- swarm process catches SIGTERM gracefully shuts down https://github.com/ethereum/go-ethereum/pull/3649https://github.com/ethereum/go-ethereum/pull/3645
- proximity order trees: https://github.com/ethereum/go-ethereum/pull/3644
- Improvement in the internal API
- Breakpoint Manager
- Debugging using source location (and not only bytecode)
- Writing remix tutorial
- integration with geth
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.
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.
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.
Alice.si —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.
SmartContract.com — 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.
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.
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.”
Ledgys.net — Quentin de Beauchesne.“Ledgys Data Network : A Decentralized Data Marketplace.”
Gnosis — Stefan George. “Fund Security — How to Keep Assets Safe on Ethereum.”
Oraclize — Thomas Bertani. “The Oraclize Oracle Service: Authenticity Proofs.”
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