Digix Core Dev Update News
Digix (DGX) 2.0 Token Now LIVE on Testnet!
Digix Update — Mar 17th 2017
KC Chng (CEO)
Code Review and DigixDAO ETC Proposal There would be a couple more redeployments and refactoring of our contracts internally on the Kovan testnet prior to submission to smart contract auditors for review. In the meantime, we are currently sourcing for 1 to 2 Ethereum Smart Contract auditors to review our code. In lieu of time needed to request and negotiate for the availability of appropriate Ethereum Smart Contract auditor/s, we will simultaneously take the time to begin a refund proposal of the ETC within DigixDAO. The audit process, as highlighted in our roadmap, could take upwards of 45 working days, and depending on any major bugs or issues found, could either be shorter or longer than estimated. We will keep everyone posted as we move along. As the code is being reviewed, we will also be making optimizations to our front end and UI concurrently. A bit of background as to why there is ETC in DigixDAO, the Ethereum chain underwent a “hard fork” on July 20th 2015 (at block 1,920,000), which unintentionally caused a “chain split”, and spawned the alternative parallel chain “Ethereum Classic”. As a result of this split, all balances existing before the hard fork remained on both chains, and as of March 2016, the DigixDAO balance consists of 465,134 of Classic Ether (ETC) The ETC Withdrawal proposal V1.0 will be released this Wednesday for comment. Digix and Consensys Presentation next week: Mar 21 2017 Chris Hitchcott will speak on Digix’s tech stack (which includes Truffle, an Ethereum Development Framework by Consensys). Andrew Keys will also present a keynote special on Consensys and the Enterprise Ethereum Alliance. This will be live-streamed at the SGInnovate offices where we are working out of. For those in Singapore, please sign up for the event at https://www.meetup.com/Ethereu... Dev Update Anthony Eufemio (CTO) I have added functionality for assets to be added to different collections via a Doubly Linked List. This is required for the asset system user experience which will allow us to list assets for specified use cases. This includes listing the custodian delivery queue, listing of assets that have been minted and are part of the gold token pool, listing of assets that have failed the quarterly audit checks, listing of assets that are in the customer redemption queue, as well as every user’s owned assets. I have refactored the contracts so that moving them from one list to another depending on their status is done atomically which takes a significant amount of time as certain considerations have to be made including gas utilization (i.e. preventing gas exhaustion type attacks for non-atomic operations), preventing race conditions, and other security related precautions. We’ve also changed the primary identifier for Assets from an unsigned integer into an address type to allow users to directly interact with each asset as if there were individual contracts with its own ABI without having to go through the AssetUserInterface. We’ve also been moving some of our infrastructure services out of DigitalOcean and into Microsoft Azure under the Microsoft BizSpark Plus program. As Azure newbies we’re trying to learn the how to properly configure our Azure instances for best performance and security, as well as writing automation tools for provisioning new hosts as needed. Chris Hitchcott (Digix Core Dev) This week I’ve been working mostly on implementing the UI for Vendor and Custodian “backoffice” system for registering, accepting and redeeming PoA assets. The associated Smart Contracts were created by Anthony, and I deployed them to Kovan for UI testing. The UI uses the Spectrum environment, which allowed for a developer-friendly easy experience even with the (somewhat) complicated workflow. The “Digix Assets” dapplet is a standalone module that inherits all the benefits of Spectrum’s existing infrastructure. One of the interesting patterns implemented by Anthony in the Proof of Asset (PoA) smart contract system is that of a “Doubly Linked List” — it allows for infinite recursion of a collection by recording their neighbour IDs. In terms of creating a UI, it means calling a contract method to get the next or previous item in a given list, then calling the next item to get the next item, and so on. By leveraging the existing web3-redux implementation and combining it with the react component architecture, this allowed me to create a generic “DLL Paginator” component (which is now part of Spectrum core), that can be re-used throughout the Digix suite. It handles the logic for fetching items (based on passed async methods), and showing UI for pagination.
AssetList component, passing in contract methods to get the items from DLL
I also took advantage of Spectrum’s transaction signing system, which allowed me to register specific UI components to display users alongside account-specific components for signing transactions (e.g. a password input for encrypted keystores, QR code for cold storage, or message for hardware wallets), and passing generic data to it via web3-redux.Passing UI data to web3-redux to be shown in the hooked transaction signing modal
The whole point of creating this UI is to make it super easy for each party (be it vendor, custodian or auditor) in the PoA system to be able to make transactions securely and conveniently. I’m told that one of the pain-points during the beta version was having to educate these users on how to interact with the contracts — hopefully having a simple and straightforward interface like the one created help will make it more intuitive.
I also put together a little video update showcasing the process:
endor and Custodian User Interface
Also, shoutout to Tim from the Truffle team for having us up on http://truffleframework.com/. I cannot recommend Truffle enough, and it’s been solidly deploying (and importing via npm) the Digix contract system to Kovan (and will continue to for mainnet).
Weekly dev commits
- 1c2d24f — [feature] expose is_owner() function in ACOwned
- 2dd73ca — [maint] bump version, redeploy
- 0c7923b — Merge branch ‘master’ of github.com:DigixGlobal/core2-storage-library-contracts
- e8c4b52 — [feature] AssetCustodianInterface getter functions
- fce0e9a — [maint] bump version to 0.0.4
- a0eb101 — [maint] deploy to kovan
- 3e853a2 — [maint] update readme to include asset interface documentation
- d659318 — [feature] Asset storage payment days
- 61f1579 — [feature] Custodian interface
- c17c363 — [maint] bump verison
- 380d0b3 — [maint] re-deploy to kovan
- aadf0e6 — [maint] update @digix/truffle-lightwallet-provider
- 3123af2 — [hotfix] Fix custodian queue asset listing
- 43015b4 — [wip] intermittent issues with contracts not being deployed.
- fce9d6d — [maint] remove superfluous List library (use DoublyLinkedList)
- 319fb94 — [feature] change asset ID to address type
- 2c24dbf — [feature] use updated cacp that exposes is_owner()
- 0592138 — [maint] rebuild
- b411da5 — [maint] fix build
- a20acf1 — [maint] use new version
- c4bf186 — [maint] use new version
- 7294eae — [maint] update deps
- 7fb7812 — [wip] custodian ui, butter-up all existing transaction modal UI
- 0b0107d — [wip] custom signing UI; beautiful transactions!
- 1516a5a — [wip] implement new getDefaultAddress, for nicer DX
- a1ce59b — [bugfix] pass required props to assetList children
- 7598ee2 — [wip] weights dropdown
- e70192c — [wip] use updated contracts, modularised interfaces, UI enhancements
- 32f5b83 — [wip] misc cleanup for release
- d074948 — [wip] [minor] add react key in dll list, cleanup
- 14af6f2 — [wip] implement double-linked-list paginator for assets
- 8fc2a2e — [wip] refactor keystoreModal process; use session model, fix modal scrolling
- acf631f — [wip] new/all toggle UI
- 93feee7 — [wip] DefaultAddressSelector — don’t show the list if there are no addresses
- 39d36ee — [maint] update version of asset contracts
- 9414956 — [wip] prefix session store
- 258d27d — [wip] major ORM update; session defaultAddress, addresses now fk, not many, (Default)AddressSelector
- 591a470 — [maint] subprovider back to application/json
- 682347f — [bugifx] resolve syncronous actions in keystoreModal
- 0059917 — [wip] delete asset transactions
- 970e513 — [wip] txData UI tweak
- 6f89ce6 — [feature] transaction modal onClose event
- 733a264 — [wip] IPFS image upload & viewing
- 47b49af — [wip] misc stringUtils; (parseBigNumber format, parseHex)
- 2f4b71f — [wip] use gram weight instead of nanograms in UI
- 536c85e — [wip] basic pagination for assets interface
- b52b481 — [wip] import v3 wallets
- 3e26101 — Merge branch ‘refactor’ into feature/keystore-import
- f31859f — [wip] use generic signing modal for digix assets
- 56a6ab3 — [wip] use generic signing modal with tokens
- 5469769 — [feature] generic transaction signing modal
- 89da6eb — [feature] add pollingInterval
- 1d7a4da — [bugfix] manually check for bigNumber
- b809484 — [maint] clean up console.log
- 52e27de — [feature] add getDefaultAddress for decorating from field
- a87e834 — [bugfix] render error.message if it’s available, rather than [object Object]
- 2e37e4e — [bugfix] multiple scrolling modals
- 7556119 — [bugfix] trigger onClose on success
- a9526da — [feature] initiallyOpen; child passed setError, setLoading
Ethereum Singapore Meetup - Digix presenting Truffle, Enterprise Ethereum Alliance
DigixDAO ETC Withdrawal Proposal V1.0 - Mar 22 2017
As DigixDAO raised funds before the Ethereum hard fork, it holds an equal balance of 465,134 ETH and ETC. Digix wishes to create a withdrawal system that allows DGD holders (on the ETH chain) to withdraw ETC from DigixDAO, proportional to their token balance.
As DGDs on the ETC chain are not honored by DigixDAO, a process (similar to the “whitehat” withdrawal contract) is proposed, which will be used to allow DGD holders on the main chain to:
- Vote on whether the proposed solution should be accepted
- Submit an address to receive their ETC proportion (to prevent replay attacks)
- Should the vote pass, receive ETC proportional to their DGD holdings
We are releasing this proposal for public discussion and feedback, with development to begin only whilst third party auditors are reviewing the DGX 2.0 core contracts, which remains our main priority.
In March 2015 DigixDAO raised 465,134 Ether (valued at the time, at 5.5m USD) in return for a distribution of 2 million DGD tokens. In response to an unrelated security incident (“TheDAO Hack”), the Ethereum chain underwent a “hard fork” on July 20th 2015 (at block 1,920,000), which unintentionally caused a “chain split”, and spawned the alternative parallel chain “Ethereum Classic”. As a result of this split, all balances existing before the hard fork remained on both chains, and as of March 2016 the DigixDAO crowdfund balance consists of 465,134 in both Ether (ETH) and Classic Ether (ETC).
Due to already-exploited “replay attack” concerns, DigixGlobal announced before (link) the hard fork that DGD tokens will reside on the main chain that is supported by the Ethereum Foundation, and as such, balances of “DGD Classic” became (and still are) valueless.
This meant that the ETC balances are not directly related to DigixDAO governance proposals. However, the same mechanism that allows DigixGlobal to transfer the crowdsale balance into the Digix Governance contracts (once they are published) could allow for the balance of ETC to be transferred into another custom contract (such as a multisig wallet or withdrawal contract), which would then allow the ETC blance to be withdrawn safely.
Without on-chain governance tools available at the time of the hard fork, Digix could not receive a clear mandate from DGD holders on the moving of ETC funds, and both the ETC and ETH funds have remained in the Digix crowdsale contract. Ever since, much community discussion have occurred and there appears to be a general consensus among DGD holders that action should be taken on the additional ETC balance as a priority.
A security mechanism was built in to the original crowdfund contract for unforeseen situations such as a hard fork, which allows DigixGlobal to withdraw the crowdfund in the case of emergency. This mechanism can be used on the to withdraw the ETC.
After discussion internally and within the DGD holder community, there is a number of potential options for utilising the ETC:
- “Burning” (or leaving the ETC in the abandoned “Classic Crowdfund” contract forever)
- Using the ETC in the same way DigixDAO would ETH by:
- Trading the ETC into ETH and adding to the DigixDAO ETH pool
- Trading into DGX, DGD or other Crypto assets and transferring ownership to DigixDAO
3. Refunding ETC to DGD holders
Option one (1) was quickly ruled out as a waste of contributed funds.
Option two (2) presents problematic operational complications and legal obligations to DigixGlobal at this early stage, including:
- The process of directly selling the ETC on exchanges for ETH (opening up the possibility of frontrunning accusations) and/or
- Time needed to source an OTC buyer who is willing to publish the transaction record and entering into a contractual agreement at a defined price which could lead to further mispricing accusations
- Taking a legal custodial role in the trading and re-distribution process
- Seeking and financing legal advice on the above overall process in Singaporean jurisdiction
If DigixGlobal either directly or indirectly took the role of trading ETC into any other asset, it would present significant financial and legal difficulties reduces the separation between DigixGlobal and DigixDAO, as well as present complications regarding fairness of the trade(s) being made. Ultimately, this would burden operations and potentially put the entire Digix project at risk at this nascent stage.
In light of the above difficulties, an option was needed that absolved DigixGlobal of any direct role in the trading of ETC. Option three (3), to allow DGD holders to reclaim the ETC, is the only remaining approach, and has past precedent (happening similarly with “The DAO withdraw contract” and subsequent “whitehat” withdraw contract).
In the spirit of DigixDAO and to preserve a legal compartmentalisation, DGD holders must be able to “vote”, in order for DigixGlobal to receive a mandate on the actions taken to transfer the ETC funds to various parties. In practice, this means that any voting or withdraw contract should have a “no” vote option, whereby the proposal is vetoed and no immediate action is taken in the case that a majority of voters (based on DGD balance) vote “no” (and a revised proposal is created at a later stage).
As the DigixDAO governance model (including Smart Contracts deployed on the main chain for voting) is not yet available, an alternative is presented that utilises components of:
- On-chain Voting Contract
- A “CarbonVote” to reduce complexity of locking DGDs
- Manual withdrawal processing
- Withdrawal contract on ETC chain (perpetually available for non-voters)
Given that the outcome of this vote will not hook-in with the DigixDAO governance model (as ETC cannot be directly controlled by the ETH DigixDAO), a less complex and more convenient mechanism is proposed for tallying votes.
Inspired by http://carbonvote.com/, a “CarbonVote” system is proposed. CarbonVote was used in the past by the Ethereum Foundation to determine the default behaviour of the Geth client during the decision making process of the hard-fork.
It is proposed that a similar CarbonVote system is set up by DigixGlobal to facilitate the decision making process for the ETC withdraw, allowing for DGD holders to simply and atomically send a zero-value transaction to an on-chain voting contract without sending their entire DGD balance. On the “closing block”, an off-chain ‘snapshot’ of votes will be tallied up based on the DGD balance of the voters on that block (thereby preventing double spends), with each DGD being each worth one vote. This tally is verifiable by third parties, and a CSV tally of votes will be published to IPFS.
This proposed solution is the best balance of convenience, security and simplicity, whilst removing the risk of the vote process being “hacked” (as DigixGlobal will simply ignore the results should any unforeseen exploits be used in the voting mechanism).
Some additional specifics:
- Those who participate in the voting process regardless of “yes” or “no” vote, will receive ETC to the provided ETC address should the vote pass as “yes”.
- To prevent spam, a minimum amount of 1 ETC (4.4 DGD) per account will be considered as a “valid vote” at the “closing block”.
- Gas fees will be paid by the recipient account on the ETC chain and deducted from the withdrawal payment.
- In the interests of fairness, the batched “refund” transactions (the transactions made to transfer the reclaimed ETC to voter’s addresses) will be created and published in batches in a random order, the seed of which will be generated on the block hash of the “closing block”
- Open sourced voting Smart Contract with one method (deployed to ETH chain): vote(bool _approve, address _etcAddress);
- UI for voting & displaying vote results
- Instructions for voting with Mist / Parity / MyEtherWallet / LedgerNano
- Open source script for taking the ‘snapshot’ of the “closing block” and tallying votes
- Open source script using the block hash of the “close block” for randomised sorting of refund transactions
- Withdrawal contract on ETC chain for unclaimed funds (to be developed at a later stage if the vote passes)
After the initial refund process, there is a high likelihood that a portion of DGD holders will have not participated — either because they have forgotten about their DGD balance, are dis-engaged with the ecosystem, have too small a balance to consider it worthwhile engaging in the voting process (although this may change should the price of ETC increase), or simply didn’t have time to participate in the original main-chain refund process. The result is that some proportion of the ETC will inevitably remain unclaimed.
There are 3 options as to what happens to this unclaimed ETC:
- The remaining balance is divided up proportionally to the participating voters
- The remaining balance is given to DigixGlobal
- A post-vote withdrawal contract is published on the ETC chain to allow non-participants to reclaim ETC for perpetuity
Options one (1) would and two (2) use up all the remaining ETC at the end of the voting process, but as some proportion of DGD holders may not participate, it would be seen as unfair and present legal / political issues. Therefore option three (3) is the only reasonable course of action.
Option three (3), whilst less convenient to participate in than the initial vote (and requires publishing transactions on the ETC chain from the same account as the ETH chain), would provide a perpetual pathway for non-participating DGD holders to claim their proportion of the remaining ETC.
This contract would be developed and deployed only if the vote passes, the specifics of which will be confirmed at a later date, but will most likely be in the form an EIP20 “Redeem Token”, which would be added to the balance of the non-participating voters on the ETC chain. This token would be transferable (to allow users to avoid replay attacks), and have the option of being “burned” (to prevent double spends); thereby returning an ETC balance proportional to the tokens that are burned. Costs associated with deploying and setting up the ledger for this contract (gas fees), will be deducted from this withdraw contract’s balance.
Instructions on how to perform this withdrawal safely will be published, but no commitments in terms of developing a dedicated UI will be made by DigixGlobal.
There will be several milestones throughout the process of this withdrawal proposal process
- A period for community to discuss and critique this proposal
- Only after the completion of the DGX 2.0 contract system ( whilst they are being audited by third parties), and depending on the outcome of the discussions, a to-be-determined period for the development of the contracts and UI required for the voting process
- The voting window itself (a period of one month is proposed, with one week’s notice before it begins)
- Should the voting pass, an additional two weeks for the votes to be tallied, verified and for the withdrawal processing script to be initiated
- A short period for the processing of withdrawal transactions (in random order)
- A-to-be determined amount of time for the implementation of the non-participant withdrawal contract (on ETC chain).
This particular voting proposal is important and significant for DigixDAO as it is a precursor to governance and voting when DigixDAO governance contracts are deployed. It will allow all DGD holders to publicly ‘beta test’ and gain valuable insights on DGD voting, interest and participation in the near future. In short, we will be able to use this current, low risk proposal to better enhance and improve upon our DigixDAO governance model.
The development of this system could also be utilised in future for similar (or emergency) decision making votes, and importantly does not require the transfer of DGD for participation, yet still accurately reflects the decision making of DGD holders.
Voting via DGD listed Exchanges
We will be reaching out to centralized DGD listed exchanges (Bittrex, Yunbi and Gatecoin) to improve the efficiency of voting on this proposal.
- Yunbi is on board with facilitating the refund process by taking a snapshot of their balance sheet in line with with the withdrawal contract (TBC if they will provide an option for their users vote)
- Bittrex tbc
- Gatecoin tbc
As DigixGlobal is independently ran with these exchanges, we can only propose that they provide a simple UI to perform voting on their platform or automatically crediting ETC balances of DGD holders based on a timestamp, so that users who store DGDs on DGD related exchanges do not need to withdraw their tokens to participate in the voting process. We cannot guarantee that they will adopt this approach at this moment and will make further public announcements if and when they do so.
DigixDAO Crowdsale address
By refunding the ETC, DigixGlobal will need to take security measures to protect the ETH currently within the DigixDAO crowdsale address. The private keys for this particular address will have to move out of cold storage and for the very first time be online to refund the ETC (as it shares the same address as the ETH), hence, a security precaution is needed where it is necessary for the ETH funds to be moved into a new crowdsale address. The new crowdsale address will be posted, published, and updated on Etherscan to replace the current DigixDAO crowdsale address.
PDF Version athttps://www.digix.io/docs/Digi...
Digix Dev Update — April 8th 2017
Kc Chng (CEO)
Digix Core Code Review
As mentioned in the last update, DappHub has agreed to performing a code review of Digix’s Core contracts.
As an extra pair of eyes, we have also gotten Vincent Eli’s agreement to take a look at our digix core contracts. Vincent is the founder of S3 Labs and CTO of StabL (A Consensys project). Vincent, being an experienced Ethereum developer with a PhD in decision / game theory, would definitely help us navigate or advice on any potential pitfalls (if there are any) in our smart contracts.
DappHub devs have begun a quick overview into our repository, and have estimated it could take between 4 to 6 weeks to do a full security audit. We will await their quotation for this project, and find a suitable date and time to begin, estimated no later than 1st May. When the formal audit begins, we will act on the ETC refund proposal.
We will, as usual, keep everyone informed of our progress.
Anthony Eufemio (CTO)
Last Sunday I gave a talk at UC Berkeley with the Blockchain @ Berkeley crowd on how to code ICS/CACP using the Digix development tools and truffle. The talk can be found here. (https://livestream.com/accounts/24422201/events/7219413).
Last week we have sent off our DigixCore 2.0 contracts to DappHub for an initial 3rd party code review. I am also doing my own run through the entire 1300 lines of solidity code to ensure quality, writing more unit tests, and adding NatSpec documentation.
Chris Hitchcott (Core Dev)
I was hoping to get this week’s Spectrum update released last Saturday, but I unfortunately was caught off guard by an unusually intense illness that took the most part of last week to recover from. I am now back in action, and apologies for the delay.
Anyways, since the last update I’ve been working intensely on Spectrum, specifically completing the integration of Ledger Nano and Offline Signing (via QR code) support. Check out this video for a run down:Spectrum
There’s also a live demo available at:https://spectrum-alpha.digixdev.com/.We’ve even thrown in the Digix PoA UI we showed in an earlier update as an example dapplet (including the pdf/jpg/png/ipfs combiner), although it’s in read-only mode as the contract system only allows specific addresses to interact with it.
Right now there are a few caveats — some reasons why you shouldn’t be using Spectrum for anything serious right now:
- EIP155 support is implemented but not fully tested across multiple networks (and Kovan currently accepts transactions from other chains, so will need to be forked)
- I haven’t been able to test Ledger Nano with different firmware versions yet — it’s only tested with firmware 1.2.0.
- If you try and have hundreds of accounts with hundreds of tokens, you’ll probably run into some rendering performance bottlenecks (the app feeling sluggish). This will be addressed using redux middleware to batch requests / updates in a future update
- Browser support; we’ve only tested with Chrome and Android so far. Some of the features such as offline mode are unlikely to work on iOS; probably never, as it’s up to Apple to support web standards on iOS.
Finally, I also released the react-ledger-container package, which includes some enhanced behaviour for interacting with the ledger in a react app (automatically connecting, fetching config, pausing the polling to sign transactions, etc), which will make maintenance and integration easier in the future.
- f5fdc0f — [maint] bump npm version
- f705d09 — [feature] contract checker
- 01c0693 — [maint] update CACP package
- d21b9c7 — [feature] remove factories and use assembly to create adhoc addresses
- 6316f14 — [feature] end to end testing for Vendor Interface
- 4a90363 — [feature] Custodian delivery listing
- 2d9ae06 — [feature] marketplace order preocessing
- 1ad7b6c — [feature] List marketplace items in Vendor Interface
- 7bc1f97 — [wip] cleanup for dappsys guys
- eafe825 — [feature] Product registration
- 7cbbae2 — [feature] Authority registration and query
- 539b6c7 — [maint] build
- 2c2850c — [maint] update slack invite link
- 8d9ba44 — [bugfix] expose raw ethLedger object to childProps
- 2c1f680 — [maint] minor tweak to chainId logic for eip155 (needs testing)
- 553ff6d — [features] implementation of eip155 (untested)
- 1898dd4 — [maint] update readme / package.json
- c1b5c48 — [wip] inital commit; implenent container with polling & signTransaction
- 9d2f241 — [wip] minor update to landing page
- 8e22456 — [wip] re-enable tokens, use infura
- 8fc1cf9 — [bugfix] allow cold address scannign with no existing addresses
- bc13d78 — [wip] bump react-ledger-container version, show version in address list
- 399543b — [wip] add tx info to all tx ui
- 4aa4e55 — [wip] tx ui for (base) tokens
- fed77e9 — [wip] better keystore menu, minor refactor
- bf7fcd6 — [wip] landing modal warning, misc markup tweaks
- 29696a1 — [wip] add immediate checksum feedback to addressInput
- 5c2a048 — [wip] remove header from qr code scanner modal
- cd5b5c1 — [wip] add qr code scanner to address input
- 6351e48 — [wip] more tweaks
- 63928e8 — [wip] minor ui/css tweaks
- 8b3fec6 — [wip] basics for nicer accounts dropdown
- 2aff8ae — [wip] update web3 to 0.18.4
- fe46bb0 — [wip] rename ‘create’ buttons
- 6c5ff4f — [wip] add chainId to tx data
- d9a3ada — [wip] validate existing addresses before inserting keystore
- bec166f — [wip] import cold storage accounts via QR code
- 3a32d5b — [wip] explicitly export web3Util methods
- 1565880 — [wip] multiple addresses per cold storage keystore
- d389cf3 — [wip] misc. refactoring of keystore managmenet
- e39e9f3 — [wip] enable digix_assets dapplet, show read-only message
- d036d34 — [wip] make defaultAddress not mandatory
- 20c1dbb — [wip] add babel-eslint dep to package.json
- f099116 — [wip] add shrinkwrap
- e7de38b — [wip] complete nicer offline signing workflow
- 937377d — [bugfix] use ledgerContainer in creationForm
- 7a5bb20 — [wip] basic working offline signing (needs nicer UI)
- 69213a2 — [wip] use @digix/react-ledger-container
- 9b4c23d — [wip] minor cleanup; fix webpack linking
- 81a6ed2 — [wip] validation for tokens/networks
- 85bb7a5 — [wip] export all web3 helpers from stringUtils
- 4a4bf0a — [wip] move modal form submit buttons into ezmodal
- 8e99bf5 — [maint] update ezmodal version, replace change with formChange & drop target api
- fbe1807 — [wip] clean up ledger transaction sigining, add onReady to ledgerContainer
- 7d232e9 — [wip] ledger nano support (needs a little cleaning up)
- 68804d9 — [wip] ledger nano crud
- 18646a9 — [wip] complete UI for creation
- 4a63476 — [wip] add modal option for networks_token_selector to show modal button
- 4967dd1 — [maint] refactor networks & defaultNetworks into token selector
- 640b9a0 — [bugfix] deleting keystores doens’t flip out
- 2a750f4 — [wip] begin integration with keystore modal
- 7f741ef — [wip] minor pagination refactor
- 4d3f489 — [wip] paginated ledger addresses (+ fix HD path)
- 1922133 — [wip] ledger nano accounts selector
- 7372a9b — [wip] refactor v3 & redux provider to expect signed tx
- 8a30ca7 — [wip] add addHexPredix to stringUtils
- 7fdab30 — [wip] rename headers
- d6bb22e — [feature] add dynamic header text, bump version
- 3337a35 — [feature] only show done button if no submit action passed
- 6ac12dc — [bugfix] properly show error messages & show error for non-asnyc submits
- c8bad40 — [feature] add hidden submit button to forms, disable with disableHiddenSubmitButton 😬
- 7ee25a3 — [maint] remove change in favor of formChange (with optional target), bump minor version
Digix Dev Update — Apr 15 2017
KC Chng (CEO)
We want to clarify Digix’s position on the ETC held within DigixDAO. Any token holders who own DGD tokens will be able to indefinitely withdraw from it. Chris has been working on the smart contract code in preparation of the ETC refund which he will share in detail below, which we hope to implement by May 1st. DappHub has come back with a quotation, and we will request for quotation from 1 or 2 other audit firms who kindly offered to help us do a code review before making the decision.
Anthony Eufemio (CTO)
Was out this week due to personal/family related issues. Will return on Monday.
Chris Hitchcott (Ciore Dev)
In terms of the toolchain, I added support for Doxity to work with truffle imports, which means we can easily generate natspec docs once again (before it relied on solidity compiler, which was fine until we upgraded to using truffle imports).
I also created an MVP IPFS pinning service. This is a little web service that uses ecrecover to authenticate requests for ‘pinning’ documents to IPFS, and then publishing the hash of those pinned documents to other nodes for redundancy. We’re currently using Kovan to maintain a registry of whitelisted addresses and IPFS hashes, which means that we can easily spin up more of these pinning service applications to provide additional redundancy and QoS for the IPFS docs that are part of the Digix system (such as those uploaded by the vendors, custodians and auditors).
I did some minor cleaning up of tests, and added new examples in Solidity and ES7 (using async/await) for a much cleaner syntax for writing new tests. In most cases, this async syntax can replace Contest, as whilst it’s much more readable than promises (in some cases even less verbose than Contest), it retains flexibility of having native JS rather than the contest’s rigid domain-specific methods. It’s also going to come in very useful when web3 1.0 comes out (as methods will be promisified and ready for await).
Finally, I also spent a little time in preparation for the etc withdraw process — part of which requires discovering the balances of all DGD holders on a specific block. I’ve created a script that reads all the Purchase and Claim events from the crowdsale, and then Transfer events from DGD Token, so I can track addresses and spit out of a report of ownership at a specific block (which requires a full ‘archive’ ethereum node without tree-pruning).
- 82d35b5 — [wip] StorageCore test
- e77a39f — [maint] update deps (use new tempo), es7 tests for LibraryUser payment_date
- 40e302c — [maint] add TestLibraryUser.sol
- 5fe8712 — [maint] optimize packaging (don’t incude docs), use testrpc accounts in development
- f0737d4 — [maint] rebuild, make migrations a bit faster
- ce499a0 — [maint] ignore node_modules
- ad4ddb5 — [maint] build docs with new doxity
- 493a3e2 — Update README.md
- 9c74b04 — Update README.md
- 3c352c2 — [feature] truffle support!
- 95ad317 — [bugfix] fix default repo in src
- 728edf6 — Merge pull request #12 from akru/patch-1 Like a bug in default source URI
- df0519c — [wip] initial commit
- 1236e6d — bump version
- 36e371f — [maint] refactor into les smethods
- 275ba43 — [feature] initial commit, basic logger / regsitry concept, tests
- c5ebdee — [bugfix] readme fix
- a8c6df2 — [maint] typo
- f1e04b5 — [maint] set default port to 3000, use updated contract
- 2294d4b — [feature] enabled pinning; mvp
- fa8169d — [wip] update readme
- 4526828 — [wip] initial commit; basics of web server, eth registry integration, signature verification
- 756dcd5 — [maint] strip down functionality, drop support for non-testrpc
Dev Update May 1st 2017
KC Chng (CEO)
This week Shaun and I were at the ABA blockchain workshop in Jakarta to promote Digix. We were given a booth along with 5 other startups to promote and show case what we do. Several good connections were made in Jakarta (gold dealers, virtual currency exchanges, asset managers) and we look forward to deepen our relationship with them for future partnerships.Digix in Jakarta
This week we have covered significant ground in our Solidity contracts and successfully solved the stack-depth and gas exhaustion issues we have brought up at last week’s security update. We accomplished this by doing the following:
- Wrapping variables used in our controller contracts around nested structs. This pattern is an elegant solution and makes our controller code much more readable by 3rd party code reviewers and security auditors.
- We have made a business decision to remove transferable asset cards. While this is arguably a cool feature to have, we feel that there are not many real world use cases for this feature and it only adds an extra layer of complexity to our code. The added benefit of removing this feature is that our 3rd party security auditors and code reviewers have one less thing to worry about.
Our code will be ready to be delivered to our code reviewers and security auditors by next week. We have found several individuals and companies that we feel have the capabilities to do comprehensive and meaningful security audits on our code base. We will know more details as to how long the full audit will take by next week after they complete their initial review and give us their timeline estimates.
Chris Hitchcott (Core Dev)
This week I worked on the ETC redemption contract and scripts, please see the repo for more information.
Enterprise Ethereum Alliance Press Release — Digix Joins the EEA
Bittrex announces support for DGD token holder’s ETC refund redemption, snapshot block #3,800,000
DigixDAO (DGD) will credit the Ethereum Classic (ETC) held within DigixDAO from the Ethereum (ETH) hard fork back to DGD holders. Bittrex users will be credited approximately 0.23255 ETC for each DGD token held in their exchange accounts at ETH block 3,800,000. The block is estimated to occur at approximately 5/31/2017.
Bittrex will credit the ETC tokens and enable the market when the smart contract claim process has been completed by Bittrex. The DGD market will be re-enabled and all orders cancelled within 48 hours after ETH block 3,800,000.
Note: Bittrex will be closing our DGD wallet and market within two hours of the ETH block 3,800,000 to take accurate snapshots of balances. If your deposits are not settled (e.g. marked as pending) by 5/31/2017, you may not be credited with ETC.
Please note that Bittrex will need to wait for the DigixDAO to successfully complete their own snapshot of ETH block 3,800,000 and the deployment of the ETC redemption smart contract.
We would like to thank the DigixDAO team for working closely with us.
The DigixDAO team has put out a detailed description of the process:
ANN: ETC Refund from DigixDAO — Snapshot Block fixed at #3,800,000 https://medium.com/@Digix/etc-refund-from-digixdao-snapshot-block-fixed-at-block-3-800-000-36e40cc13e48
Digix ETC Redemption User Guide https://github.com/DigixGlobal/etc-redemption/blob/master/guide/GUIDE.md
Digix Dev Update Jun 3 2017 — Unabridged
KC Chng (CEO)
We are happy that the refund process has executed as expected. To any users who still have issues redeeming their rightful ownership of ETC due to the unintended consequences of the hard fork, please ping us on Slack or reddit, and we will do our best to respond to you as soon as we can.
Some of the common issues encountered and clarifications:
1) not enough ETC gas for calling the redemption function. Please make sure you have enough ETC to do so.
2) DGD-Redemption tokens are distributed to the same address (where DGDs are kept on the main chain at block #3,800,000) on the classic chain. When you generate your private keys on the main chain, you also have ownership of the same keys and public address on the classic chain.
3) If you are using Mew with a Trezor or Ledger Nano , please make sure your HD Derivation path is similar on the ETC chain as it is on the ETH chain.
4) Refund will be ongoing for a year before DGD token holders decide what to do with the unclaimed balances.
5) Please see the guide if you have not already done so at https://github.com/DigixGlobal/etc-redemption/blob/master/guide/GUIDE.md
Regular development updates will resume as the main message for the past 2 weeks was to have everyone aware and focused on the ETC refund. We have also included what was done for the past 2 weeks as well in this week’s update.
Concurrently with the security audit done by Smartpool founders, we are working on integrating the front end of our marketplace with our core contracts. We expect minor changes, if not, none, to our core contracts.
Digix has also begun looking for additional core developers to join our team. Stay tuned for further announcement of new hires within the next 2 months.
Several new partnerships are in the works in preparation for the launch of our marketplace. We will follow up with some new announcements this coming week.
Community building efforts
Shaun Djie, Digix’s CCO, took the time to present Digix’s journey and tech stack at a Microsoft’s Start Up Day sponsored event last week at BASH@71 Ayer Rajah. We were very happy to see that the number of blockchain enthusiasts growing in Singapore.
Thank you for the kind words Andrew
We also hosted Indorse and Status.im at the SGI offices to a full turnout last week.At SGInnovate
This coming monday, Michael Wheuler from INFURA & MetaMask would be presenting their product at a ConsenSys Asia Pacific sponsored event. Please catch the live stream at https://www.youtube.com/watch?v=N784-1G6ZZY&ab_channel=DigixGlobal
Anthony Eufemio (CTO)
The security audits are currently ongoing with Smartpool.io. We have been in private discussions about the codebase and working closely together to complete this very important step before our launch.
Code Quality Audits
We are going to be engaging DappHub to perform a separate audit of our codebase that deals with the code quality. The focus of this audit is not to find security vulnerabilities which is the scope of the security audits performed by SmartPool but to ensure that our codebase is coherent, has good test coverage, and bug free.
This week we will be describing the set of user stories that will be needed to complete the development of the Digix Gold Marketplace. The Marketplace consists of a few server side APIs that allow us to handle customer physical gold bar orders, uploading and approval of KYC documents, as well as the back-office services which will be consumed by the Spectrum enhanced version of our Marketplace.
Chris Hitchcott (Digix Core Dev)
What a fun packed week it’s been. Many projects worked on, including the ETC Redemption Dry Run deployment and code review (thanks Vincent), Digix Explorer Interface (+ integration with Vendor & Custodian views), IPFS coolness and general tweaking and testing.
Let’s start off with IPFS: one nice improvement is that we’re figured out a better way of storing proof of asset docs on IPFS. Admittedly kind of obvious, instead of saving the hash of the PoA document on chain, we’re now saving the hash of a JSON file containing metadata to (potentially many) other data fields, including other IPFS content hashes. This linked data structure means we get infinite storage and flexibility in terms of what is uploaded as proof of asset (such as the ability to store picture galleries, videos, etc) with infinite future-poofing and no extra Solidity. Nice pattern!
One more IPFS related thing is that we’re going to be publishing deployments of spectrum on IPFS now and then as we roll out test DGX 2.0 features (like the assets explorer).
Which brings me to the assets explorer: I’ve completed an MVP for the explorer view and actions in the DGX 2.0 PoA system. Multiple categories, ID searching, Pagination, Sorting, it has it all.
It’s also more closely integrated with the other Vendor and Custodian views, which also had an API update, and inherits the pagination and sorting.
IPFS DEPLOYED DEMO RELEASE: https://gateway.ipfs.io/ipfs/QmPFrQEtrF9gtYAMFFdGRnPw3Bos5aMPCVEeZQjTdoxBeN/
Next week I’ll be working on integrating a multisig wallet into Spectrum, not just as a dapplet, but as an *account type*, which means it’ll be cleanly integrated into just about every transaction type, and provide a really neat UI for multisig transactions, which can be initiated by any of the existing keystore types (including hardware wallets).
This week I have been implementing the MultiSig keystore type for Spectrum, using Consensys’ https://github.com/ConsenSys/MultiSigWallet contract (which is being used by the Golem team to store ~440,000+ ETH).
This feature allows for the deployment and management of this contract, and seamlessly integrates into Spectrum’s existing accounts system. Uniquely, the multisig keystore type will automatically ‘proxy’ a given transaction, automatically finding a relevant owner’s signing address (to initiate the transaction) and transforming the transaction data formatted to submit to the Multisig. This makes signing transactions via a the multisig contract wallet a lot simpler to end users, as they never have to meddle around with contract data. It also works in combination with the Ledger nano, so you can easily sign super securely (if you are insanely paranoid you could even sign via ledger via a cold account via a multisig).
Whilst this integration is is functionally complete, unfortunately I’ve not been able to finish the styling for everything (still have some JSON output that needs to be tabulated) and have an event on Friday, so I will leave the polishing until Sunday (and will release another distribution on IPFS). In the meantime, please see the WIP screenshots below:
New Keystore Creation Menu
MultiSigs are added to keystores list like a normal account
Click the account config to manage Multisig Contract Config, Owners and Transactions (paginated and categorised)
When signing with the Multisig keystore type, users can select which ‘owner’ account initiates the transaction, and UI is displayed based on the selected address’ keystore type.
Finally, I also had a bit of an experiment day last Sunday and came up with a very simple proof of concept called DGXi — the “i” stands for interface. This contract is a token wrapper for DGX, that allows people to hold an value that decreases in value over time, but keeps the same number — kind of the opposite of DGX, which decreases in number but remains 1:1 gold value.
There are no plans to do anything with this concept as of yet, but it could be very useful for exchanges and dapps that don’t want to implement their own demurrage fee calculations (as it allows people to deposit and withdraw with a like-for-like token that simply decreases in value deterministically via fixed ‘inflation’, paying the fees on withdrawal). If anyone is interested in looking at the contract code, it’s at https://github.com/DigixGlobal/DGXi/blob/master/contracts/DGXi.sol.
This week started by wrapping up the Multisig wallet UI talked about last week, which will now be included in future release of spectrum.
I then deployed the final version of the ETC refund contract (which required a forked version of truffle-compile to disable the optimiser as per the suggestion of the code review), and made some small tweaks to the ETC redemption dapplet. It now awaits block 3800000, when the snapshot will take place.
I also spent some time on a faucet service, which uses a registry on Kovan to whitelist users and enable DGD holders to withdraw a small amount of ETC in order to execute the redemption step. This service is a one time service, available to DGD holders at https://digixparity04.digix.io/faucet/0x<enter_your_address_here>
The majority of this week was taken up by the ETC redemption process, which included various tweaks to the UI, updating the guide, providing support and importantly actually executing the redemption process steps — deploying, capturing, minting, etc. I also made some updates to the faucet that helped DGD holders get a small amount of ETC to make their claim.
I spent a small amount of time on Spectrum; implementing a neat little addition for that extra bit of security when generating private keys: the option of providing random entropy via dice rolling — optionally replacing `crypto.randomBytes`. This also implements an XOR transform to reduce the effect of biased dice. (https://www.reddit.com/r/Bitcoin/comments/22nezb/just_got_my_16_sided_dice_extra_secure_paper/cgopcvx/)
- 78d1fa1 — Merge pull request #15 from yudilevi/patch-1 Added a missing comma in the sample .doxityrc file
- 76b64ac — Added a missing comma in the sample .doxityrc file
- eb4c575 — [maint] deploy to classic
- 28fbb75 — [maint] remove multisig, keep multisig integration tests
- f8b964a — Merge commit ‘b143daaae1e458d2d2544cb08a03483919230d33’
- 2e9804b — [maint] disable optimizer, rebuild
- 6913b0d — [maint] contract data checking
- 22eb84d — [feature] spectrum: ui tweaks
- f05ebe1 — [maint] minor filesystem organisation
- a449552 — [maint] ipfs dists
- 82e1e71 — [maint] fix deps
- 8803329 — [maint] cleanup, deps
- 182f2c0 — [feature] allow changing owner in transaction
- 40a0919 — [feature] multisig deployer
- 0c482f5 — [feature] show network selector if web3 not passed to transaction modal
- 1b99227 — [maint] random ipfs deploy
- e5fb8d6 — [maint] bump verison, remove spectrum dep
- 1f14474 — [maint] update readme
- 0a0885b — [feature] tabulate json data in tx info
- 4c8d39d — [feature] sepectrum: dynamic contract, UI tweaks
- 540bfc3 — [maint] fixes
- 1d2663a — [maint] fix script, redeploy
- e67e728 — [maint] redeploy
- 023c0eb — [wip] cleanup, text edits, fix deploy
- bacb461 — [feature] allow passing `classic` to provide faucet to classic
- 0540ce3 — [feature] population script
- 32926bb — [feature] add onboarding script
- 9a1b6cf — [wip] minor text update
- f7bb43c — [feature] faucet http server
- e39402b — [feature] initial commit; registry contract + tests
- e833c710 — [test] AssetInfoStorage
- cea8832 — Update GUIDE.md
- 8e9e724 — Update GUIDE.md
- 5ee3666 — Update GUIDE.md
- 0b929d9 — Update GUIDE.md
- 31e1ccc — Update GUIDE.md
- 955656f — Merge commit ‘b0ff47c44b58187b6ecad09acbb294353c1fd07b’
- d423f51 — [maint] update guide
- b0ff47c — Update GUIDE.md
- 9ff80dc — Update GUIDE.md
- 7018792 — Update GUIDE.md
- 4971a50 — [maint] fix time estimate
- 4cf7c34 — [maint] update IPFS hash
- 58fe6c4 — [maint] UI updates for live contract
- 5c4dae5 — Update GUIDE.md
- 748eca1 — Merge commit ‘f02dde3254fcdcdc9d6cf525f0b91ebb3df8dfb7’
- 8d38286 — [maint] add reports
- f02dde3 — Update GUIDE.md
- fe8c5cb — Update GUIDE.md
- fdc624d — Update GUIDE.md
- d720ed7 — Update GUIDE.md
- 62b3083 — Update GUIDE.md
- 44eece3 — Update GUIDE.md
- eeadeee — [maint] update addresses
- 702290f — [maint] add accounts
- c60dff4 — [maint] add source code link
- bece299 — [maint] fix readme link
- a509167 — [maint] build, update ipfs hash
- 83ff7b9 — [maint] add app to guide
- 64d102f — [maint] minor ui fix + formatting
- b774ac9 — [wip] comment out wallet test (not used)
- 0f8f67f — [maint] fix formatting
- 9654092 — [maint] add exchanges info
- be66536 — [maint] add faucet info
- 98ca3fe — [maint] update readme
- 448a3dc — [maint] rebuild docs
- 689e138 — [maint] rebuild docs, update readme, guide
- cf9e2e0 — [maint] fix versions & shrinkwrap
- d4405f9 — [maint] built & migrate without optimizer
- e4f27e4 — [maint] more step-1 data
- e072f23 — [maint] update heading text
- 3d47d52 — [maint] update to use live contract, use top-up keys
- 467ceeb — [maint] whitelist npm publish dirs
- 49d6e00 — [maint] update readme regarding multisigs
- 5814f01 — [maint] add entropy fields for randomData generation
- e4a843d — [maint] remove redemption + overlay
- eee380d — [maint] build
- fb0f2b6 — [maint] redeploy
- c125ba6 — [maint] update token address in tokens list
- b1b4c0e — [maint] new build
- 200e752 — [maint] ipfs build
- 71f74cf — [maint] bump etc-redemption and build
- 0b3c677 — [maint] update overlay, ipfs deploy
- 9493503 — [maint] fixed deps and added shrinkwrap
- c94a0e6 — [maint] ipfs deploys
- eae25aa — [maint] add ipfs deploy script
- 960f4fc — [maint] publish IPFS dists
- 0683f2b — [maint] only use ETC
- eee0d28 — [maint] fix linked deps, whitelist published to `src`
- dcf140e — [maint] logging
- af68d4b — [hotfix] temp hardcode the list
- 9cf6865 — [hotfix] temp fix for faucet
- 9135a69 — [maint] use kovan
- c43bcba — [bugfix] set gas
- f3e150a — [maint] redeploy
- 24f47b7 — [maint] make populating much more efficient
Digix Dev Update Jun 12 2017
Debit Card Payment Partnerships
We are now partnered with 2 virtual currency debit card payment companies to increase the adoption of DGX, namely, TenX and Tokencard. This means that in the very near future, you can pay for your latte in Digix Gold tokens or a basket of currencies consisting of DGX when the Bancor protocol goes live.
Organized a meetup for the 0x team in Singapore
Will and Amir was in town this week and we helped host an event regarding their 0x protocol. The recorded video will be posted this week. Their protocol would make it an ease for anyone to trade virtual currency tokens p2p without a centralized entity (including our tokens of course).
Community Managers nominated
We are in the process of expanding the Digix team and we have reached out to a few candidates we feel suited for this. They will be responsible to help with managing our social media presence and Q and As on slack and reddit. This will be an appropriate time to do so as we move closer to launch.
Chris Hitchcott (Core Dev)
Amongst various roadmap insights, we have designed a new, more streamlined marketplace interface contract (encapsulating the price feed and invoicing system into a more elegant Smart Contract rather than requiring a traditional web service + coinify invoicing integration). The new design significantly reduces infrastructure requirements by removing the need for a marketplace application server, whilst bringing additional security, scalability and integration benefits (and will allow DAO/ICO/Exchanges to make on-chain DGX purchases directly from the marketplace). The time I spent on coding yielded an additional 87 unit test cases to bring test coverage for the storage contracts to 100%.
Weekly Dev Commits
## core2 ### email@example.com:DigixGlobal/core2-storage-library-contracts.git
- 6854a287 — [test] Controller - 9bc0aad9 — [test] AssetStatus - 4cc2c20e — [test] TokenLoggerCallback - 42fb1f65 — [test] AssetDisaplay, AssetLoggerCallback - fdd25414 — [maint] build - ffd468c7 — [test] MarketplaceStorage - 618bb0a4 — [test] CoreStorage happy path - 3bf86c24 — [maint] remove old tests - ad56d3d2 — [maint] project re-org - 23627c40 — [minor] lint - 690020ac — [maint] compile - fbe7b223 — [test] AssetIndexStorage - caa9fa2c — [test] don’t migrate when running test
## etc-refund ### firstname.lastname@example.org:DigixGlobal/etc-redemption.git
- cea8832 — Update GUIDE.md - 8e9e724 — Update GUIDE.md - 5ee3666 — Update GUIDE.md - 0b929d9 — Update GUIDE.md
## spectrum ### email@example.com:DigixGlobal/Spectrum.git
- 5814f01 — [maint] add entropy fields for randomData generation - e4a843d — [maint] remove redemption + overlay
## whitelist-faucet ### firstname.lastname@example.org:DigixGlobal/whitelist-faucet.git
- dcf140e — [maint] logging - af68d4b — [hotfix] temp hardcode the list - 9cf6865 — [hotfix] temp fix for faucet - 9135a69 — [maint] use kovan - c43bcba — [bugfix] set gas - f3e150a — [maint] redeploy - 24f47b7 — [maint] make populating much more efficient
Digix Dev Update — 19th Jun 2017
Kc Chng (CEO)
Community Managers Appointed
Hugh (“Hughlang”) and Magnus (“Souleye”) will be helping out in our public Digix reddit / slack channels. They have been long term supporters of Digix, have been around since the beginning, and have understood quite well what Digix is creating. As such, it is with great pleasure that I welcome them as Digix’s Community Managers. They will assist Digix in answering any queries or FAQs in the Digix slack or reddit and manage the community.
Local Intern Hired
We have hired an intern at Digix. Please welcome Y.S Chang, who is currently a student at Singapore University of Social Sciences (SUSS) with a Major in Accounting. He will assist Digix with research, event planning, and other miscellaneous activities that can spur his knowledge on Ethereum in return for contributing his time and resources to Digix.
Chang working on a hard problem at SGInnovate
Anthony Eufemio (CTO)
Ongoing Security Audits
This week, our third party auditors at SmartPool have provided the first complete report for our security audits a week earlier than expected! However, as all good security audits go they did find a few security concerns that we are going to work through to resolve. We will be engaging them for a secondary and final security audit once we have resolved the issues that were shared with us. What we need to do now is to have the auditors to provide us with a risk assessment that will help us categorize these issues into following:
- Is it a vulnerability that can be exploited?
- Is it a quirk that doesn’t have any serious implications?
- Can the issue be mitigated without code changes?
- Is it a theoretical attack?
- Is the attack economically feasible?
*The key tenet at Digix is that we will not launch broken code, because the repercussions and reputational / financial damage are permanent to the whole Ecosystem. We will only launch secure code that we are confident in, as evident in our recent ETC redemption contracts that were deployed 3 weeks ago, and has seen over 80% of redemptions successfully executed within the month of deployment. We value security over rushed delivery, and will continue to update our supporters regularly on our developmental progress.
Trusted Offline Price Feeds
We have been developing a new way to run fully run our marketplace on-chain while being able to provide real time price feeds. This new method allows us to have a trusted price feed that can be used for on-chain ethereum contracts without having to spend any gas to keep an up-to-date real time price feed. This pattern is also useful for other things that we are planning on building on top of DigixCore in the future.
Global Fee Controls
We have added a way to globally disable our demurrage and transaction fees as a way to increase user adoption. The idea is that we needed our contracts to be able to have the option to disable or modify the fee schedule at any time as a way to encourage mass adoption of our platform. This requires some minor code changes and an additional controller and interface so that we can eventually tie this into the DigixDAO governance system and allow votes on demurrage/transaction fees.
Chris Hitchcott (Digix Core Dev)
I began the week by additional additional test coverage for the core2 controllers and interfaces, with end-to-end Token Interface (EIP20) tests added (including some failing tests to be fixed by Anthony that were pointed out by the security view). There were also some minor updates the digix website and to fix truffle-lightwallet-provider due to external dependency changes (thanks to an updated web3-provider-engine).
Spectrum: Towards an Open Source Release
With updates to the contract APIs pending security review (including guaranteed TBC changes to the way pagination will work), our frontend development pipeline was freed up; so focus has shifted away from developing specific dapplets and I have once again been working on Spectrum’s core functionality (which has been a growing laundry list of features as more ideas and technologies appear; such as ENS integration, “time machine” mode, message signing, and some TBA bonus services for DGD holders).
Several parties have been interested in using Spectrum’s codebase for their own Dapps, and the I have been spent time preparing Spectrum for it’s imminent open source release. This week’s effort included a range of bugfixes, refactoring, linting, optimizations and administration tasks, including categorising the existing TODOs into issues, and creating milestones for the next planned major releases. From now on I will be using “github projects” to track progress.
The goal is to have Spectrum open sourced by next Friday, when I will also be announcing a program to encourage open source contributions.
- ea25b2f2 — [maint] add spectrum UI
- 8aec02f2 — [test] add MockCoreStorage set fee methods
- acffb06b — [test] smaller balances for readability
- 6aad07d0 — [maint] remove old test
- f705331a — [test] minor comments fix
- 67ded284 — [test] TokenInterface (failing)
- 12a9f30 — [maint] update copy, build
- 4a6bfe6 — [maint] update fees
- bd730ad — [maint] refactor webpack conig fixes #11
- 649c499 — [maint] add `webpack-pwa-manifest`; fixes #40
- b102131 — [maint] add resource hints plugin fixes #55
- 29f4446 — [maint] add SRI plugin fixes #54
- 165ec02 — [maint] move digix assets to core2 repo fixes #60
- 12bcb7d — [maint] update deps
- b232120 — [maint] noopener fix
- 2d81501 — [maint] use rel=”noopener” on external links
- cc73c7e — [maint] don’t bother with github.io pages (security risk)
- f802e3c — [maint] attempt to fix docs
- a88a3c8 — [maint] attempt to fix docs symlink
- 34780a3 — [maint] attempt to fix docs symlink
- 34bb4d5 — [maint] update build, deps, eslint, use npm 5; fixes #59 #56
- 1a9ae25 — [maint] build, fix entropy settings
- dc4d753 — [maint] fix deps & bump to 0.0.13
- 0b3bce9 — [maint] simply subprovider, bump libs
- 844c3f3 — [maint] update deps, compatability with eth-block-tracker (new provider engine)