æternity | POS/POW blockchain to unlock the Internet of Value



  • Aeternity - Post Multisig Contract Attack Bounties






    Thoughts on what is next for æternity blockchain and beyond.

    About two weeks ago we became victim of a bug of an Ethereum “smart contract” written by one of the most reputable companies in the Ethereum space. The problem was not the wallet itself, nor the private keys, but the smart contract, which was supposedly an especially secure multi-signature contract used by many projects in the space. A multi-signature contract is a contract where several parties need to sign to create a transaction of ETH to another Ethereum account.

    Some might feel sympathy for the attacker. He/she showed again, that it is very difficult to write a secure smart contract on Ethereum — without a team of researchers, formal verification experts and a test-framework behind. In this particular hack, the attacker was able to simply exchange the owners of the multisig contract, by sending a transaction on the public Ethereum network, which made himself the owner. As a second step, he was able to transfer all the ETH out to his account.

    “The Lord giveth, and the Lord taketh away.”

    Because of this incident we lost control of over 82k ETH (worth about 18m CHF or USD at the time). We at Aeternity had to discuss again about how to proceed and also about the maturity of the Ethereum ecosystem. This would have never happened with Bitcoin, we figured, where there has not been a single incident where a multisig-contract got hacked.

    Further, remaining questions are whether the cause of the problem is Solidity (as a language), Ethereum (as a platform) or the negligence of the developer of the multisig wallet contract that was hacked, or a simply a human error.

    No doubt, æternity suffers from this incident. But we don’t give up and believe that in the future blockchain technology and smart contracts will be one of the biggest enablers in this world, especially for the developing regions. We proceed to implement our vision of a more scalable, more user-friendly, more secure, and more decentralized blockchain platform.

    Since inception, we at æternity blockchain believe that smart contracts should be done another way. The idea that every JavaScript developer should write a financial application is possibly one of the worst in this century. Contracts calling contracts calling contracts are hard to verify — without the right tools at least. At æternity, we currently use a dialect of Forth (like Bitcoin script) and a dialect of Lisp to write smart contracts in, which are in from each other isolated state channels. We will further explore methods of writing even more secure smart contracts and will put more efforts into creating the right tools to verify contracts.

    New Bounties by æternity

    To engage further with the community, we are announcing following bounties:

    1. Return-the-ETH-bounty (10% of returned ETH)

    Anyone, either the black hat or a white hat guy/girl/group, who returns us the ETH originating from our attacked contract address to the below address, can keep 10% of the ETH. This bounty is potentially worth several millions and is valid for everybody who returns the ETH back to the below address. We are working with the local authorities and newly on-boarded professionals to assist us.

    Dear exchanges and dear crypto-crowd, please help us get the ETH back — you will be highly rewarded. As an immediate step, please blacklist the root address and all child-addresses of the attacker.

    Dear Multisig Contract attacker, if you are reading this, please know that we are serious about building a better, more secure smart contract platform. A truly decentralized one and one which scales. We are asking you kindly to return the ETH you took from the æternity project to the below address, and we will stop any further legal actions.

    Ethereum Account 0x541dE0Cd1F7eef8bdae28FBB146298EEfa993A25 Info
    The Ethereum BlockChain Explorer, API and Analytics Platformetherscan.io

    Feel also free to send messages to this address.

    Timeframe: Unlimited.

    2. Taint Analysis Tool (4 ETH)

    Whoever writes a script (nodeJS preferred), which is capable to track ETH movements on the Ethereum blockchain, will receive 4 ETH. The script should take one root address as an input, request data from Etherscan, and then follow the transactions to the next addresses, where the ETH get sent to. It should auto-update. It should have a JSON API and an simple HTML interface, so that exchange and other people can easily track the movements of ETH. Open Source license, preferably MIT. Development should happen in public.

    This tool will also help to track down the recent phishing attacks.

    Bonus (2 ETH): get etherscan.io to have this taint analysis implemented into their service, in a publicly accessible way.

    Bonus (1 ETH): make it possible that community members comment on the addresses via a third party identity provider.

    Good things about such a attack: The attacker will not be able to spend such big amounts. Fiat-gateways are monitored. Ethereum transactions are fully public and can be tracked easily. To a certain amount laundering is possible though. But humans make errors all the time.

    For this reason, it is important, that all of you, dear members of the crypto community, try to help to annotate the transactions of the ETH which got hacked. If we work together we can catch not only the Multisig Contract attacker, but also the group behind the recent phishing attacks and make the crypto-sphere a generally more secure place.

    Timeframe: 1 week (extension possible).

    Community efforts trying to track down the attackers ETH

    3. Attack analysis on public testnet blockchains (5 ETH)

    The attacker might have not been careful when he did his first attempts to hack the multisig wallet contracts. He/she might have done some attempts on public testnet blockchains where he first deployed a multisig contract and then tried to attack it. Goal for this task is to write a script, which hooks into the currently available public ETH-style blockchains and finds the attack pattern. The person who gets the bounty should deliver himself an analysis of all the available ETH testnet blockchains as well as the ETC blockchain. This should happen as a public blog post. Additionally, the origin of the ETH, which were used for the attack, should be traced back.

    Timeframe: 1 week (extension possible).

    Path Forward for æternity’s AE Token Contract

    Allocation of the æternity Blockchain AE Tokens

    The AE tokens will be initially allocated exactly as announced in earlier official statements. æternity will not have more, nor less AE tokens because of the attack.

    Launch of the æternity AE token contract on Ethereum

    The recent hack had caused us to be very busy and made us consider restructuring the token distribution method, e.g. via using the ColoredCoins protocol on BTC or LTC. We will continue with the creation of a very simple ERC20 token contract on Ethereum. We expect the launch of the AE token contract during August. However, this did not halt our progress with the platform as can be seen in our GitHub and development updates.

    We understand our community and that it takes more time than anticipated, but be patient, we are working very hard to assure the success of æternity platform and the delivery of it in the most efficient way.

    Please subscribe to our email newsletter or check our blog, if you want to stay updated on the exact date of the AE token launch.

    Read more about the Hack

    Dissecting the two malicious Ethereum messages that cost $30M (but could’ve cost $100M)
    An step-by-step analysis of the Ethereum messages/transactions used by the Black Hat and the White Hat to seize $30M…medium.com
    Ethereum is Doomed | Satoshi Nakamoto Institute
    As some have noted, I did not understand Ethereum very well when I wrote my previous article that touched on it. I…nakamotoinstitute.org
    Parity’s Wallet Bug is not Alone
    The bug in the Parity multisig wallet that caused the loss of $30M has the same root cause as a bug in the BitGo…hackingdistributed.com
    A hacker stole $31M of Ether — how it happened, and what it means for Ethereum
    Yesterday, a hacker pulled off the second biggest heist in the history of digital currencies.medium.freecodecamp.org
    Parity Wallet Hack Explained — Steemit
    At around 12:19 pm UTC today, 153,037 ETH (30M USD) was stolen from Edgeless Casino, Aeternity, and Swarm City. The…steemit.com
    Solidity has far worse problems than not being an advanced research language. Ju… | Hacker News
    Everything is 256 bits wide, including the “byte” type. This means that whilst byte[] is valid syntax, it will take up…news.ycombinator.com

    Bugs have happened also before the æra of the blockchain…

    NASDAQ’s Glitch Cost Facebook Investors ~$500M. It Will Pay Out Just $62M. IPO Elsewhere.
    When Twitter or Dropbox go public, they should remember May 18, 2012. The SEC has approved NASDAQ’s payout of $62…techcrunch.com
    List of software bugs — Wikipedia
    Many software bugs are merely annoying or inconvenient but some can have extremely serious consequences — either…en.wikipedia.org

    If you have anything to comment, please do so here on Medium. Thank you!

    …and let the Lord giveth back.





  • Dev Team Meeting Notes

    Follow the progress and current focus of æternity’s development team.

    All meeting notes are stored in GitHub and shared by the dedicated Twitter account of æternity’s CTO, Joel Reymont. The collection of notes below is an overview and will be updated once a week.

    Project Board  Project Milestone

    Meeting Notes 13–09–2017

    Summary

    1. Settle on the proof of account balance.

    2. Use websockets for the local communications with the node. The node-to-node API will use HTTP.

    3. Update the design section of the wiki.

    Meeting Notes 12–09–2017

    Summary

    1. Include proofs of account balance modifications in the block to avoid processing the blockchain since genesis to build the account tree.

    Meeting Notes 11–09–2017

    Summary

    1. Discard SHA256 PoW.
    2. Start the Dumb blockchain sprint. The goal is to have a fully functional blockchain with limited functionality, i.e. just block mining. We’ll make it release 0.1 and put it out there for people to play with.

    Meeting Notes 08–09–2017

    Summary

    1. Treat Cuckoo Cycle access as a limited resource.
    2. Build a finished product every sprint. Epoch will be a blockchain in progress but fully working at the end of each sprint, always gaining new features. Users will be able to download the software and run it, confirming that it meets the goals defined for the sprint.
    3. Start the Dumb blockchain sprint next Monday.

    Meeting Notes 08–09–2017

    Summary

    1. We have a new member of the team.
    2. Cuckoo Cycle PoW is done and waiting to be merged.
    3. We are still clarifying the state of the world.
    4. Start new milestone next Monday.
    5. Label closed tickets in this sprint according to how long it took to finish them.

    Meeting Notes 07–09–2017

    Summary

    1. We have a new member of the team.
    2. Cuckoo Cycle PoW is done and waiting to be merged.
    3. We are still clarifying the state of the world.
    4. Start new milestone next Monday.
    5. Label closed tickets in this sprint according to how long it took to finish them.

    Meeting Notes 06–09–2017

    Summary

    1. Added unit tests to Cuckoo cycle, they are working. Verification is taking too long.
    2. Use extranonce when nonce overflows.
    3. Add new transactions while mining a block.
    4. Implement service to hold blocks and headers in memory.
    5. Build state of the world by processing the blockchain since inception.
    6. Update state of the world when receiving blocks.

    Meeting Notes 05–09–2017

    Summary

    1. Finished in-memory merkle trees.
    2. Compile the Cuckoo Cycle and test today. Use NIFs to integrate with Erlang.
    3. Proceed with block implementation. Track time and difficulty.
    4. Backlog local caching of state of full nodes, no persistence between restarts for now.
    5. Light nodes will ask full nodes for proof of balance.
    6. Put block design on the wiki.

    Meeting Notes 05–09–2017

    Summary

    1. Extend sprint 1 by another week.
    2. Estimate tickets when assigning them at the standup. Need a few more sprints to make it happen.
    3. Clarify assumptions more frequently.
    4. Use John Tromp’s C/C++ library for the Cuckoo Cycle PoW. Integrate it with Erlang.
    5. We need Ethereum-like state trees but do we need a proof of absence? Discuss.

    Meeting Notes 31–08–2017

    Summary

    1. Discard peering design as too complex. Keep it simple!
    2. Be bold, don’t be afraid to make mistakes! Challenge authority but have good arguments ready.
    3. Daily standup meetings are obligatory. Excuses accepted.
    4. Settle on a good Merkle trees approach. No persistence needed as trees will be serialized with blocks.
    5. Serialize blocks in a format easily parsable by Javascript clients.
    6. Persist blocks in RocksDB.
    7. Investigate storing proofs with transactions.
    8. Understand Merkle Patricia trees and their use in Ethereum.

    Meeting Notes 30–08–2017

    Summary

    1. Follow a PR checklist. Make sure commits are squashed, message is good, tests, docs, etc. are present.
    2. Reuse existing Cuckoo Cycle PoW code rather than write our own from scratch.
    3. Add RocksDB to the project skeleton and start on Merkle trees.
    4. Implement SHA256 mining.
    5. Collectively review and poke holes in the peer and sync design.
    6. Interview 2 more Erlang developers.

    Meeting Notes 29–08–2017

    Summary

    1. We are on track but haven’t reached cruising speed of development yet.
    2. Avoid estimate labels for the first few sprints and until we settle into a steady rhythm.
    3. No over-engineering. We are short on time so we want to do things right but not strive to make them perfect.
    4. PRs should come with unit and/or integration tests. Assign new tickets and add them to the current sprint as PRs are merged.
    5. Hold technical discussions in Github tickets.

    Meeting Notes 28–08–2017

    Summary

    1. Use the Monday standup for sprint planning and the Friday one for a recap of that week.
    2. Revisit the sprint throughout the week, adding or removing tasks.
    3. Give it a few weeks to calculate our average development speed then try to estimate the project.
    4. Some tickets may be too general and will serve as a tracking umbrella for others.

    Meeting Notes 25–08–2017

    Summary

    1. Use Github for project management: Label tasks as small, and Medium or large Group tasks into sprints/milestones.
    2. Create tickets/issues for known tasks.
    3. Figure out the project timeline.
    4. Investigate using LevelDB for data storage.

    Meeting Notes 25–08–2017

    Summary

    1. Deliver on the vision in the original whitepaper, i.e. implement payment channels, oracles and smart contracts.
    2. Revise the original whitepaper to focus on the above. Remove non-essential stuff like betting markets implemented over channels.
    3. Question all assumptions, e.g. whether nodes should communicate over HTTP, what the API should be, whether users need to pay to maintain accounts, etc.
    4. Do it better and faster than before.
    5. Develop in the open, after taking the old repo private to avoid confusing users.
    6. Ensure token distribution in the genesis block.
    7. Ensure voting on code upgrades (governance).


  • Aeternity - State of development: Week of Oct 30th, 2017

    Check out the latest news from the development front.

    We coded up a storm last week and re-integrated the changes. We are also freeing up and focusing on making our release testing setup even more comprehensive.

    Mainnet & Testnet

    We are all meeting in Malta next week to design and plan the mainnet release, as well as to release the testnet. It’s going be an all-hands-on-deck testing effort this week to make sure the testnet release goes smoothly.

    We are kicking some cans down the road and accumulating some technical debt to release the testnet on time. Rest assured that we’ll do everything possible to tie all the loose ends in the first sprint after the release.

    New Team Members

    We are expanding and adding a couple more Erlang heavyweights to the team. It’s safe to say that we have cornered the market for top-notch Erlang talent now!

    New Project Management System

    Our coordination burden has drastically increased with our fast pace and expanded team so we switched to Pivotal Tracker from GitHub project management. We’ll keep our source code on GitHub, though, and the Pivotal Tracker is open for everyone’s review.

    Please continue posting your problems, suggestions or feature requests to GitHub Issues.



  • æternity - Devlopment Update 


    Release 0.10.0 is out!

    With much dedication and patience, this week we managed deliver our next release — 0.10.0. The release focuses on optimizing and improving the security of the peers synchronization protocol by reducing the amount of data exchanged between them and ensuring the synchronization is resilient to network failures.

    But there is more. In addition to the work on æternity’s sync protocol, the new release:

    • Eases verification of the Coinbase transaction, by including the mining reward within it. This impacts both the consensus and the persisted DB;
    • Makes the lookup of blocks/headers by height faster by introducing an index in the DB. This impacts the persisted DB;
    • Fixes an attack vector, in which a malicious node can claim to be at height one million ahead with higher difficulty. Before this fix, a peer would have to read all one million headers and start building the chain before they are able to detect the node’s malicious behavior. If this attack is done repeatedly, it could completely deplete the node’s memory. The fix allows a peer to determine if the node is malicious and break all further communications with it.

    In parallel, we are continuing our work on the VM and the Sophia smart contract language, we are continually making progress on implementing state channels that will make our smart contracts fly and harden the security of peer-to-peer communications by finalizing the integration of the Noise security framework.

    Your support is always welcome and its best form is code and/or ideas. Show us what you got!

    Here is a photo of us, looking forward to your commits :)




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