• Breaking News

    Sunday, December 17, 2017

    Home Unlabelled Ethereum I've gained ownership of /r/Etherium, which previously had no mods and was rampant with scammers. If the mods of /r/Ethereum would like ownership I'd be happy to hand over

    Ethereum I've gained ownership of /r/Etherium, which previously had no mods and was rampant with scammers. If the mods of /r/Ethereum would like ownership I'd be happy to hand over

    December 17, 2017

    Ethereum I've gained ownership of /r/Etherium, which previously had no mods and was rampant with scammers. If the mods of /r/Ethereum would like ownership I'd be happy to hand over

    I've gained ownership of /r/Etherium, which previously had no mods and was rampant with scammers. If the mods of /r/Ethereum would like ownership I'd be happy to hand over

    Posted: 17 Dec 2017 08:26 AM PST

    I've set up a redirect so anyone visiting will be redirected here. Many thanks to the Reddit admins for giving it to me as there were over 5,000 subscribers.

    I've sent a couple of mod mails but not had a response so I'll at least make this post so everyone is aware.

    Thanks all

    Jack

    submitted by /u/jack
    [link] [comments]

    OMG (OmiseGO) Token now LIVE in the Bancor Network for continuous, decentralized and automated liquidity. Check out the web app to convert OMG, BNT, ETH and other tokens directly from your Web3 wallet.

    Posted: 17 Dec 2017 03:37 AM PST

    Maker Dai

    Posted: 17 Dec 2017 09:22 AM PST

    Why is nobody talking about it? Where can I get more information about the release of the Dai today. Any idea exactly what time it goes live and when it will be listed on exchange?

    submitted by /u/BudDePo
    [link] [comments]

    Ethereum Co-founder Joe Lubin interviewed by The Daily Show's Ronny Chieng for cryptocurrency bit

    Posted: 17 Dec 2017 05:31 PM PST

    Notes from Ethereum Core Devs Meeting #29 [12/01/17] and #30 [12/15/17]

    Posted: 17 Dec 2017 04:54 PM PST

    I got behind on notes so I am going to post notes to both meeting #29 and #30 in this super long post. The notes are also located here.

    NOTE: The next core dev meeting will be January 12th due to the holidays. Agenda is located here.

    Ethereum Core Devs Meeting 29 Notes

    Meeting Date/Time: Friday 12/01/17 at 14:00 UTC

    Meeting Duration: 1 hour

    GitHub Agenda Page

    Audio/Video of the meeting

    Agenda

    1. Testing Updates a. Fuzzer updates. b. New transaction tests folder structure.
    2. Shall we require CC0 notices in EIPs?
    3. New Project: JSON RPC Proxy / eth-agent a. Discussion: https://github.com/ethereum/cpp-ethereum/issues/4563 b. Proof of Concept: https://github.com/chfast/json-rpc-proxy/releases/tag/v0.1.0a1
    4. Does it remain the case that the Yellow Paper is intended to be Ethereum's formal specification?
    5. POA Testnet unification [Update]
    6. Core team updates.

    Notes

    Video starts at 4:03

    [6:05] 1. Testing Updates

    a. Fuzzer updates

    Go and Rust clients can work with it and Guido is working on integrating cpp-ethereum. Guido is also working on a bignum fuzzer to make sure bignum libraries are aligned across the clients. Smart contract fuzzing has been discussed, as has fuzzing the network stack, but it has not started yet.

    [8:56] b. New transaction tests folder structure.

    There have been changes to the transaction tests to help organize it better and be more representative of the different categories. More technical detail in the call.

    [11:00] 2. Shall we require CC0 notices in EIPs?

    We agreed that the requirement for CC0 notice should be made going forward. Yoichi made a pull request on EIP 1 to change that. Existing EIPs that do not have the copyright will need to change and we can create PRs for them that they just have to give written permission to change.

    [35:10] 3. New Project: JSON RPC Proxy / eth-agent

    a. Discussion: https://github.com/ethereum/cpp-ethereum/issues/4563 b. Proof of Concept: https://github.com/chfast/json-rpc-proxy/releases/tag/v0.1.0a1 cpp-ethereum components are being separated into separate projects. Components that are not required to run an Ethereum node may be split from the core cpp-ethereum code. The first component to be split off are the HTTP server that is in the client. The JSON RPC proxy can sign transactions for you which acts like an account management component in a way. An update to EthStats which moves it to the shared tooling projects may also be in the works soon.

    Separating the account management from the client will help lessen the security overhead of the Ethereum node operators. geth is planning on slowly moving away from account management and Martin is working on an account management tool with a public API that doesn't take passwords. It instead requires interaction with a custom UI and sending remote transactions to the tool.

    [14:56] 4. Does it remain the case that the Yellow Paper is intended to be Ethereum's formal specification?

    Ben brought up some questions (linked in the title) about the future of the Yellow Paper and it's place as the official specification for clients.

    Ben's questions:

    Question: does it remain the case that the YP is intended to be Ethereum's formal specification?

    If yes, then it should be noted that the YP is currently significantly out of date.

    a. What is the plan for bringing the YP up to date post-Byzantium?

    b. What is the process and ownership for maintaining the YP going forward?

    c. Should updating the YP be made part of the EIP finalization process?

    d. To facilitate c., Should EIPs be required to include a pull request to the Yellow Paper (if relevant) before they are accepted?

    e. When consensus failures are discovered (e.g. during the recent fuzz testing), how can we make sure that the YP is updated where necessary?

    If no,

    a. What replaces the YP as the authoritative specification of Ethereum?

    b. Is the YP worth maintaining as a resource that is descriptive rather than prescriptive? If so, the questions above still stand.

    Having changes to the Yellow Paper or other formal spec. be merged before certain EIPs are accepted is a good idea.

    Gavin Wood maintains the Yellow Paper and there are a list of contributors to the Yellow Paper on GitHub. The Yellow Paper doesn't have a copyright which opens up some confusing legal issues for those wanting to fork the Yellow Paper or make unofficial changes that are not merged by Gav. Biggest concern is it is unclear who can legally merge pull requests without legal concerns being attached. There are currently pull requests for the Yellow Paper to bring it up to date. The Yellow Paper isn't a complete specification of everything needed to build a client and some expressed opinions that the Yellow Paper is difficult to read. KEVM is a formal specification written in K that can be execute test cases that may be a candidate to replace the Yellow Paper. KEVM is licensed under UIUC/NCSA License. Afri is going to reach out to Gavin to ask about updating and licensing the Yellow Paper include him in this conversation.

    Piper suggested having a developer grant for a group that keeps the Yellow Paper or other formal spec. up to date. Currently Dev Grants (Ethereum Foundation grants program) is not active, but may be active in the future.

    [43:24] 5. POA Testnet unification [Update]

    No updates.

    [43:51] 6. Core team updates.

    • Parity - Working on release 1.5. No major new features. Mostly working on stabilizing stuff. Improvements on database layer are also happening, specifically replacing the database layer with a new type of database. They are working on Parity multi-sig issue and preparing a list of different approaches on how we can address the problem. They will present a list of proposals at the next core dev meeting. "We will discuss them with the community and see where it goes from there."
    • geth - New release with no major changes. Working on improving the block tracing.
    • cpp-ethereum - Still is post-Mexico mode from Devcon3. Mostly cleaning up some stuff from the Byzantium hard fork. Yoichi has been going through and updating EIPs. Discussion is ongoing with Pawel and Andrei about a roadmap for features. Dimitry has been updating the testing framework. Shout out to Martin H.S, cdetrio, Guido, and other who are contributing to the fuzzer framework
    • Harmony - Migrated client to RocksDB. Work is basically complete on making Harmony compatible.
    • ethereum-js - No updates.
    • pyEVM - Big GitHub migration from Piper's GitHub to Ethereum Foundation's GitHub. Repos have been re-named to make it more clear what each one does. Pretty far along with implementing the light client protocol. Early alpha release of the client (currently called Trinity) expected in the next month. Integration with Hive and JSON-RPC specs are still left to do. The research team is working on moving their Casper implementation to pyEVM.
    • pyethapp - There is Casper research testnet utilizing pyethereum.
    • EWASM - Roadmap has been created. Aim to launch a preliminary testnet by the end of January.
    • Solidity - Release made the day before that had some improvements including fully implemented ABI encoding/decoding (will require specifying experimental release in the header). Really focusing on the SMT solver in Solidity for the next release.

    Martin H.S mentioned that there is someone working on a C# Ethereum client that is passing almost all state tests and VM tests. Estimates are that it will be complete in a couple of months. At this point it is still in a private repository, but if people want to help out reach out to Martin and he will connect you.

    Attendance

    Afri Schoedon (Parity), Alex Beregszaszi (EWASM/Solidity), Anton Nashatyrev (ethereumJ), Christian Reitwiessner (cpp-ethereum/Solidity), Dimitry Khokhlov (cpp-ethereum), Hudson Jameson (Ethereum Foundation), Lefteris Karapetsas (Raiden), Marek Kotewicz (Parity), Martin Holst Swende (geth/security), Nick Johnson (geth), Paweł Bylica (cpp-ethereum), Piper Merriam (pyEVM), Yoichi Hirai (EVM)

    Ethereum Core Devs Meeting 30 Notes

    Meeting Date/Time: Friday 12/15/17 at 14:00 UTC

    Meeting Duration: 1 hour

    GitHub Agenda Page

    Audio/Video of the meeting

    Reddit thread

    Agenda

    1. Testing Updates.
    2. Digital cats caused network congestion this month. Meow. a. Why did this happen and what solutions are available to prevent future network congestion? See comments below for some ideas. b. Stateless Clients proposal. c. Would having minimum system requirements to set up an optimal client/full node help? d. Is the bottleneck is not just disk bandwidth, but specifically sequential disk bandwidth? e. Vitalik has some ideas around gas cost changes and scalability-relevant client optimizations.
    3. Plans on Quantum-resistant cryptography and any plans to include it in the next update?
    4. Introduction to K-EVM team (Everett H.)
    5. Does it remain the case that the Yellow Paper is intended to be Ethereum's formal specification?
    6. Parity stuck ether proposals.
    7. POA Testnet unification [Update]
    8. Core team updates.

    Please provide comments to add or correct agenda topics.

    Notes

    Video starts at [00:03].

    [00:33] & [22:37] 1. Testing Updates

    Yoichi is doing some clean-up of Byzantium test cases. Dimitry is currently working on changing the test source format into YAML. Final tests will still be JSON, this only affects the test source. Those who write tests can use YAML and use multi-line contract source code and write comments.

    [1:12] 2. Digital cats caused network congestion this month. Meow.

    [1:22] a. Why did this happen and what solutions are available to prevent future network congestion? See comments below for some ideas.

    The gas limit was 6.7 million and crypto kitties used 1-2 million gas per block worth of demand. Usage pushed the transaction fees higher due to demand. Miners upped the gas limit a bit, but usage has grown even more and we are now at an 8 million gas limit and blocks are basically full.

    [2:20] b. Stateless Clients proposal.

    Alexey Akhunov described a stateless protocol design. Vitalik has been pushing the stateless protocol paradigm a lot because it is the direction they are looking at for sharding research. Stateless clients means that instead of the client storing the entire state the client would just store the state root and it would be the responsibility of the miners or transaction senders to package up with the block or the transaction the witness blocks. Witness blocks contain merkle branches that prove that all of the parts of the state required for processing all transactions in that block, and computing the next state root. Although this is theoretically viable, it would require a lot of substantial changes to gas costs and other factors described here. Other optimizations include the making it so we can access Patricia tree nodes in parallel and bumping cache sizes. Low effort scaling solutions could potentially be included in Constantinople.

    A complete discussion on these issues is included here.

    c. Would having minimum system requirements to set up an optimal client/full node help?.

    Discussed tangentially in subsection b.

    [24:12] d. Is the bottleneck is not just disk bandwidth, but specifically sequential disk bandwidth? .

    Vitalik asks: Are random SSD reads parallizable? Would it take less time to perform 20 random reads than doing a single read? This may help with optimization to do multiple tree reads in parallel. Although it is not fully clear, it appears to be faster, but does it help with DBs like LevelDB? In theory it is likely fast, but in practice it depends on the DB and things like pre-loading the data into a cache or performing computations while pre-loading the data. In geth it may not make a difference because of the way LevelDB works. Alexey Akhunov volunteered to do some benchmarks to answer some of these questions.

    [31:07] e. Vitalik has some ideas around gas cost changes and scalability-relevant client optimizations.

    Main point: Vitalik thinks state reads are underpriced and pointed out some other scalability improvements that are quick wins.

    1. Increase the price of blockchain reads.
    2. EIP 648: Parallelization.
    3. Two account destroying/dust clearing EIPs (168/169).

    Martin HS wondered what the impact of increasing price on blockchain reads would have on the amount of gas used per block and fill up blocks more quickly. Vitalik says that he thinks the purpose of re-pricing is to improve the worst case rather than the average case. We still need to encourage devs to write their contracts better, but the more important thing is being pro-active about risks of actual attacks on the network. Risk of attack on the network is lower this year compared to last year. An attack that fills even a third of the block gas limit would end up making TX fees rise to $2 or more and burn through a million of dollars in a few days, but is still something worth being concerned about.

    State channels are something that is a non-protocol, off-chain solution for scaling that Dapp developers should be paying attention to.

    [35:52] 3. Plans on Quantum-resistant cryptography and any plans to include it in the next update?.

    Account abstraction is not "necessary", but there isn't really a point on creating a single quantum proof algorithm, but using account abstraction would make it more general and what they are using for Casper. There is an Ethereum Research thread going on talking about the tradeoffs in account abstraction that needs more commentary.

    [38:32] 4. Introduction to KEVM team (Everett H.)

    Everett Hildenbrandt, Daejun Park, and Phil Daian gave introductions to themselves and KEVM.

    KEVM is a formalization of the EVM in the K language. K is an operational semantics framework that gives you a bunch of software dev tools once you formalize your language in K. KEVM is executable and testable so it can generate and pass state tests. It can be eventually used to generate test cases by the specification rather than by a client such as cpp-ethereum. Some experimental prototypes to extend the EVM with some high-level languages have occurred, most recently Daejun has been helping a lot on the semantics of Viper. Goal is to provide some formal tools for the Viper language which involves formalizing the Viper language on top of KEVM (translating the Python version of Viper into a mathematically definition in K). A number of tools are created from this formalization of Viper including proving compiler correctness and migration of Solidity contracts into Viper using bytecode comparison. More information is included in this blog post. Additionally there has been work on compilation from KEVM to a web based and human readable documentation of the KEVM semantics. It is meant to be like the Yellow Paper, but it can be fully compiled into a full implementation of the EVM. It is called "The Jello Paper" and can be found here. The KEVM project is split across two entities: The University of Illinois (U.S) and Runetime Verification Inc.

    [47:12] 5. Follow-up: Does it remain the case that the Yellow Paper is intended to be Ethereum's formal specification?.

    Ben Edgington from Consensys's Pegasys protocol engineering team and Daniel Ellison from Consensys who has been working on LLL and language research introduced themselves.

    Afri reached out to Gavin about the Yellow Paper and Gavin said he would be happy to place the Yellow Paper under a Creative Commons license. He hadn't done it yet because he has been busy, but will find time in 2 weeks to do it. The topic was brought up of the possibility of having more than 1 formal specification for Etheruem. KEVM is testable and executable so if there were to be another executable or testable specification you could check interoperability between two specifications, but currently there is a not a way to do this with the Yellow Paper. It would be possible to get a merge of the two specifications, combining elements, such as the English prose from the Yellow Paper with some of the elements of the KEVM. It isn't necessarily bad to have multiple specifications, but it would be bad to have it too fragmented. The first step for the Yellow Paper seems to be to apply a license so it can get up-to date. The KEVM team is interested in moving KEVM to Ethereum Foundation ownership.

    [57:36] 6. Parity stuck ether proposals.

    No official/formal statement today, but Parity has heard the community feedback loud and clear.

    [58:27] 7. POA Testnet unification [Update]

    No updates.

    [9:29] 8. Core team updates.

    • Parity - Parity is replacing RocksDB with a custom database layer called "ParityDB". Attempts to optimize RocksDB over the last 6 months proved to not be fruitful so they are making the switch. More information on that can be found on their GitHub. We are having some problems keeping up with mainnet, but are working to fix that.
    • geth - Nick has been working some potential improvements to not write as much to disk with the idea to keep the state diffs of the last 100 or so blocks in memory (similar to Parity) which would raise memory requirements, but decreases disk I/O. geth is exploring other database solutions and so far hasn't found any silver bullet DB replacement. Although doing some optimizations like disabling the background miner would help, there are some people who rely on the "pending state" details that the miner enables for APIs.
    • cpp-ethereum - No major updates. Work in progress on refactoring the database layer to easily swap databases and enable optimizations. Recently implemented a script to proxy HTTP RPC request to IPC sockets in order to get rid of the HTTP server in the client. This code can be used with other clients. Improvements have been implemented in the CLI.
    • ethereum-js - No updates. Looking forward to EWASM testnet. Lots of maintencance and merging of PRs.
    • Harmony - Database layer is almost done being moved from LevelDb to RocksDB. Created a new pruning mechanism. Soon will focus on the Casper testnet.
    • pyEVM - No major updates. Getting closer to major alpha release.
    • pyethapp - No updates.

    NOTE: The next core dev meeting will be January 12th due to the holidays. Agenda is located here.

    Attendance

    Afri Schoedon (Parity), Alex Beregszaszi (EWASM/Solidity), Alex Van de Sande (Mist/Ethereum Wallet), Andrei Maiboroda (cpp-ethereum), Anton Nashatyrev (ethereumJ), Ben Edgington (Consensys/Pegasys), Casey Detrio (Volunteer), Christian Reitwiessner (cpp-ethereum/Solidity), Daejun Park (KEVM), Daniel Ellison (Consensys/LLL), Dimitry Khokhlov (cpp-ethereum), Everett Hildenbrandt (KEVM), Hudson Jameson (Ethereum Foundation), Jared Wasinger (ethereumJS/Testing), Jutta Steiner (Parity), Lefteris Karapetsas (Raiden), Marek Kotewicz (Parity), Martin Holst Swende (geth/security), Mikhail Kalinin (Harmony), Nick Johnson (geth), Paweł Bylica (cpp-ethereum), Péter Szilágyi (geth), Philip Daian (Runtime Verification/IC3), Piper Merriam (pyEVM), Vitalik Buterin (Research), Yoichi Hirai (EVM)

    submitted by /u/Souptacular
    [link] [comments]

    Blockchain Holiday Gifts: Moon Land

    Posted: 17 Dec 2017 04:23 PM PST

    Zamfir's Triangle - Reasonably low latency to finality, reasonably large number of validators, and reasonably low overhead.

    Posted: 17 Dec 2017 12:28 PM PST

    Just for fun ICO generator. Try it yourself ;)

    Posted: 17 Dec 2017 06:55 AM PST

    Decentraland shows the potential of blockchain and VR combined

    Posted: 17 Dec 2017 07:15 AM PST

    Just sent a transaction. It took less than 10 minutes and cost less than 75 cents. Traditional USD FED Wires take up to 10x longer and cost up to 50x more.

    Posted: 17 Dec 2017 07:02 PM PST

    Please convince me that this isn't the future.

    submitted by /u/Timelapze
    [link] [comments]

    Canaries as smart contract Interfaces on Ethereum - ERC Proposal

    Posted: 17 Dec 2017 08:16 AM PST

    ETHDENVER: Hackathon & Workshops - February 16th-18th

    Posted: 17 Dec 2017 05:55 PM PST

    The CFTC’s Physical Delivery of a Virtual Currency Definition- a must know for the cryptocurrency community

    Posted: 17 Dec 2017 11:30 AM PST

    The Top 10 Best Ethereum Wallets (2018 Edition) - For those who keep asking

    Posted: 17 Dec 2017 10:39 AM PST

    Hey guys bought some Ether but I’m nervous.

    Posted: 17 Dec 2017 04:08 PM PST

    So I bought some Ether today and I went to go send it into my wallet and this is the wallet you get off of the official Ethereum website. Anyway This is where I think I messed up so I made a wallet got everything set up then I sent my Ether to my wallet just before it was done syncing and nothing has showed up yet. Now the wallet is taking an extremely long time to download 221 blocks. Did I lose my ether?

    TLDR: Sent Ether to the official ethereum wallet before it was done syncing and nothing has shown up in the wallet.

    submitted by /u/C0SM0NAUT_CAT
    [link] [comments]

    How fast is POS?

    Posted: 17 Dec 2017 03:53 AM PST

    Ethereum's cap currently seem to be around 1Mtx/day with a reasonable (expensive but while waiting for sharding) fee. Sharding might not happen until 2019 but POS will come before that. Demand will be huge for 2018, at exponential growth and dapp launches minimum operation demand (decentralized exchanges, games etc) should go to at least 10Mtx/day.

    So everything else equals where will POS put us?

    The foundation is long term which is good but they are also pragmatic, are there any low hanging mitigation plans for 2018 or can we expect fees to quickly rise to $10?

    Can more be done with block size/gas limit without sacrifice? Faster clients? Etc etc?

    submitted by /u/fs_swe
    [link] [comments]

    Casper The Friendly Ghost (CTFG)and Casper the Finality Gadget(CFFG)

    Posted: 16 Dec 2017 11:18 PM PST

    Federated Byzantine Agreement (e.g. Stellar) vs. Plasma-PoS chains (e.g. OMG)

    Posted: 17 Dec 2017 11:54 AM PST

    I wanted to get feedback from the ETH community on some of the architectural and scaling differences between BFA style consensus algorithms like SCA and Plasma based PoS chains.

    Stellar for instance promises essentially free transaction fees but requires more hardware of "servers" using the network. The "roll your own trust tolerance" approach seems like a reputational mechanism to converge into centralization.

    OMG is permissionless and requires no servers, running on ordinary laptops, but charges an as yet undetermined fee.

    What are the fundamental differences of these constructions? What makes one more or less preferable for different implementations?

    submitted by /u/Omiseguy
    [link] [comments]

    John Wise, founder of LOCI, will be hosting an AMA tomorrow!

    Posted: 17 Dec 2017 09:18 AM PST

    Ether prices for buying and selling via IDeal in The Netherlands updated in real-time!

    Posted: 17 Dec 2017 07:40 AM PST

    sent .006 eth to exodus

    Posted: 17 Dec 2017 08:03 AM PST

    never used eth before, need it in this wallet to send another coin, what do I need to know about sending small amounts like this?

    submitted by /u/VanquishAudio
    [link] [comments]

    Am I able to download Ethereum wallet on a Raspberry Pi running Ubuntu?

    Posted: 17 Dec 2017 11:08 AM PST

    Title. I just wanna make sure that I am able too before I start my project. If I am able too, would there be any problems doing so? If not, how can I work around the problem?

    Edit: Would like to download the regular wallet on the Ethereum website or Jaxx

    submitted by /u/T_ech
    [link] [comments]

    Tokenplex - an open-source portfolio management and technical analysis service for crypto-currencies.

    Posted: 17 Dec 2017 07:22 PM PST
    Read more
    at

    1 comment:

    1. UnknownMarch 14, 2018 at 1:16 AM

      Hello!!!! How to make money with HashFlare 2018 https://hashflare.io/r/56BFA7D6 mining Bitcoins https://www.youtube.com/watch?v=Yv8Ws_T7S2I !!!!!!

      ReplyDelete