ARK A Platform for Consumer Adoption updated info



  • ARK Rust — A new way to interact with the ARK blockchain

    We are nearing completion of our Software Development Kit (SDK) Roadmap, here is our latest and 16th addition — the Rust SDK.

    We are attempting to make it as easy as possible for developers to jump into blockchain development by incorporating all of the major programming languages that we can. Allowing the Rust programming language to be able to interact with the ARK Blockchain opens up one more additional tool for developers to work with ARK.

    Hundreds of companies, large and small, use Rust in production for a variety of tasks. Those tasks include command line tools, web services, DevOps tooling, embedded devices, audio and video analysis and transcoding, cryptocurrencies, bioinformatics, search engines, Internet of Things applications, machine learning, and even major parts of the Firefox web browser.

    Rust is proving to be a productive tool for collaborating among large teams of developers with varying levels of systems programming knowledge. Low-level code is prone to a variety of subtle bugs, which in most other languages can be caught only through extensive testing and careful code review by experienced developers. In Rust, the compiler plays a gatekeeper role by refusing to compile code with these elusive bugs, including concurrency bugs. By working alongside the compiler, the team can spend their time focusing on the program’s logic rather than chasing down bugs.

    To learn more about Rust visit their site at:  https://www.rust-lang.org/

    Features of Rust

    • zero-cost abstractions
    • move semantics
    • guaranteed memory safety
    • threads without data races
    • trait-based generics
    • pattern matching
    • type inference
    • nominal runtime
    • efficient C bindings

    ARK Rust

    Like all our rewritten SDKs Rust follows SoC (Separation of Concerns) design pattern where we separate Client and Crypto code in 2 libraries.

    With this latest addition we are almost done covering all major programming languages. The last ones on the list are C and C++, which will be done in the upcoming weeks.

    Here are some of our officially supported SDKs:

    If you want to get involved with development be sure to check our GitHub Bounty and our developmental guidelines.

    If you want to dive deeper into Rust and it’s abilities, give the official Rust 2018 book a read at https://doc.rust-lang.org/book/2018-edition/foreword.html



  • Major Mobile Wallet Update — With New Features!

    It has been a few months since our last ARK Mobile Wallet update. Since then, we have been hard at work fixing bugs and developing a huge slate of new features!

    To download the latest version you can follow the notification you will receive from Google Play or App Store that there is a new version available. You can also use the links below for manual update or installation (it might a few hours for update to appear depending on your country and schedule of release from App Store or Google Play):

    Android Jelly Bean devices (4.1 to 4.3.1) are no longer supported as they no longer receive security updates from Google. KitKat support will also be removed in the next iteration of the app since it is now considered deprecated from Google updates.

    Changes in Numbers

    Since our last release of ARK Mobile Wallet on March 12th we had:

    • 23 different developers contributing to the Core.
    • 166 files changed in the Core repository.
    • 233 commits to the Core repository.
    • 1,163 lines of code deleted from the Core.
    • 5,218 lines of code added to the Core.

    New Features

    • Adding ARK-based blockchains to the Mobile Wallet

    A popular request was for the addition of different ARK-based networks to the Mobile Wallet, similar to the current Desktop Wallet. Now, other ARK-based projects can be added from within the mobile wallet! This opens doors for developers to test their custom bridgechains using the mobile wallet. Simply input an IP from one of their node IPs/domains and the wallet will automatically obtain all of the necessary information for you to use that network.

    To add an ARK-based blockchain, first click “Create a new profile”, then “Show Advanced”, “Custom” and “Create”. The same process can be done from the “Settings” screen if you are already logged into a profile. If you previously added a custom network and just want to add a new profile attached to that network, you can select it from the drop-down menu.

    Adding custom network within new profile screen
    • V2 Network Ready

    One of the biggest updates is compatibility with our new Core v2. Also, the new Mobile Wallet is now ready to use with our DevNet network v2! When creating a network it automatically checks if it is v1 or v2 so you can import other V2 ready networks into the mobile app!

    • Dark Mode Option

    A huge request was for dark mode (mostly by Travis, who is a dark theme fanatic). Now, those with sensitive eyes, vampires, metal fans, and followers of the Dark Lord can appreciate even more darkness in their life! Special thanks to our community developer ‘Dated’ for taking the time to incorporate our designer Oleg’s dark theme design.

    You can enable this option under “Settings” by clicking on “Dark Mode” (to switch back to light mode just press again).

    Dark Mode can activated under Settings
    • Validate Passphrase (BIP39) When Importing Account

    When importing your passphrase into the mobile wallet, if you enter a non BIP39 passphrase, you will get an error message if the passphrase or the number of words is invalid. Also, there is now a switch to enter custom (non BIP39) passphrases if you are using a custom based passphrase.

    Improved UI and optional custom BIP39 switch
    • Passphrase BIP39 Word Suggestions

    When importing your passphrase there is now an auto-complete feature that shows possible words from the BIP39 list as you enter characters. Click the word to complete the entry making it easier and less prone to errors when importing passphrases.

    Word suggestions from the BIP39 list
    • Add Optional Amount to Receive Screen

    Pressing the + button in the lower right corner gives you an option to ‘Receive’ ARK by entering how much you want to receive (either in ARK or fiat currency). A QR code with all parameters is automatically generated for you to share with who you are requesting payment from (use the share icon in the upper right corner to share it).

    Request a specific payment amount
    • Generate and Import Passphrase in All Possible BIP39 Languages

    This is a feature that allows you to generate and import passphrases in any language (from the possible languages defined in BIP39 wordlist). This can be selected in ‘Settings’ under ‘Wordlist language’.

    Setting other language passphrase option
    • Allow the User to Hide/Show the Passphrase While Inputting

    Improved security on wallet import by allowing hiding of the passphrase with a hide/show icon option.

    Hide / Show passphrase option

    Other Fixes and UI improvements

    • Changing peer of the network — many users had trouble when trying to switch from a bad peer to a good new one, making them have to clean local storage. This has now been resolved and peer change should work as intended.
    • PIN confirmation added when removing wallet — when removing wallet from the app you are now required to input PIN to confirm removal (note that the passphrase will be deleted from the app as well, so make sure you have it backed up).
    • Add address checks when sending — when sending ARK to another address it now checks if the provided address is in correct form and lets the user know if it is not.
    • Show loading screen— added loading window with the spinner when applicable.
    • Make wallet labels unique & fix bugs — Fixed bug that wallet label was not updated “on same screen” and fixed bug that “address” was returned for wallets.
    • Removing read only wallets — there was an error where you could not remove read only wallets from the app. This has now been resolved.
    • Delete confirmation show contact name — when deleting a contact from the list there is now a confirmation window.
    • Shorten addresses in send transaction input field — when sending ARK the address is now shortened, similar to the explorer so you can check the first and last few characters of the address. This is also done when scanning from QR code.
    • Fixed issue that if you don’t allow the camera the app hangs — if you didn’t give permission to the mobile wallet to use your camera for QR, the app froze. This has now been resolved.
    • Unique profile names — enforces uniqueness of profile names to differentiate them.
    • Remove gray square — in some screens a small gray square was visible at the edge of the screen and has now been removed.
    • Keep wallet name when converting watch-only wallet to full wallet.
    • Clean up style on PIN modal & normalize spacing.
    • Added info that 24 hour price is for BTC and show BTC 24 hour change next to BTC value.

    And numerous other patches, resolved code conflicts and dependencies updates!

    New Languages

    • French
    • Korean
    • Bulgarian
    • Czech
    • Italian
    • Portuguese

    Special thanks to all of the community contributors who made this new wallet a possibility and we hope you’ll continue rocking!

    One of the features we will be working on for the next update is implementing support for Ledger hardware devices on Android. There is currently no Ledger support for iOS as this integration requires an OTG cable, more information can be found here: https://support.ledgerwallet.com/hc/en-us/articles/115005463729-OTG-Kit-adapters-for-your-Ledger-devices

    How Can I Help With Development or Report Issues?

    If you want to help, get involved and earn some extra ARK be sure to give ARK GitHub Development Bounty a read and get coding:

    Follow us on social media ( Twitter | Facebook | Reddit ), join our community ( Slack | Discord ) and stay tuned to our blog on Medium and on Steemit.



  • ARK Core v2 Testing: Dynamic Fees

    Recently, the basic elements of ARK dynamic fees were outlined in the October 2nd blog post. Now, we present a guide for enabling and testing the new fee structure as we delve into the technical side of dynamic fees in the upcoming release of ARK Core v2.

    Dynamic fees allow delegates to set their own minimum acceptable fees for transactions and let users specify the maximum fees they are willing to pay for a transaction. The resultant “marketplace” allows for competition among delegates in setting fees, lets users choose the fee needed for the speed of their transaction, and ultimately keeps fees low for the end user.

    This post goes deeper into the technical aspects of dynamic fees and take a look at dynamic fee files with regard to their setup and testing using the Tester CLI to send custom transactions via shell. Dynamic fee testing can be done right now on DevNet and with this blog post we are officially starting our first targeted testing.

    If you have any questions please join our Slack (#devnet) channel, you will then be able to question ARK developers and request additional guidance if needed.

    Technical Breakdown

    A more detailed technical breakdown is described in the AIP proposal for Dynamic Fees.

    Looking at the inclusion scenario from the node process, the steps are:

    1. Send and process transaction payload from the client/sender

    Figure 1: Sending and processing of transactions on the node

    2. Forger requests transaction from the pool

    When the Forger pulls the transactions from the pool, the transactions are checked to see if they match. Methods are called according to the sequence diagram below.

    Figure 2: Forger requesting transactions from the node

    For example a basic transfer transaction with payload looks like this:

    // dynamic transaction payload
     {
        "verified":true,
        "id":"afaa18bfc29762b7b5172fa1f71ea7471c0d9e6dcf2992638865ecb4b3d1f26b",
        "version":1,
        "timestamp":47674390,
        "senderPublicKey":"03d7dfe44e771039334f4712fb95ad355254f674c8f5d286503199157b7bf7c357",
        "recipientId":"DBm8ZgZvaDhgba9jyFNVwDGD8ysbN3w8Tv",
        "type":0,
        "vendorFieldHex":"5449443a2030",
        "amount":"200000000",
        "fee":"270",
        "signature":"3044022045b1ffc09a0eb03e50b64bb98290308f44b19899014b5d656daf290a95dc174f02200f3b084c79caf02d9338ac89951db7889c899c455195cdfe62167e133d47f4e3",
        "data":{
           "version":1,
           "network":30,
           "type":0,
           "timestamp":47674390,
           "senderPublicKey":"03d7dfe44e771039334f4712fb95ad355254f674c8f5d286503199157b7bf7c357",
           "fee":"270",
           "vendorFieldHex":"5449443a2030",
           "amount":"200000000",
           "expiration":15,
           "recipientId":"DBm8ZgZvaDhgba9jyFNVwDGD8ysbN3w8Tv",
           "signature":"3044022045b1ffc09a0eb03e50b64bb98290308f44b19899014b5d656daf290a95dc174f02200f3b084c79caf02d9338ac89951db7889c899c455195cdfe62167e133d47f4e3",
           "vendorField":"TID: 0",
           "id":"afaa18bfc29762b7b5172fa1f71ea7471c0d9e6dcf2992638865ecb4b3d1f26b"
        }
     }

    Translated to a serialized version of this payload:

    // serialised transaction Transfer
    // serialised.length = 160
    {"serialized":
      {
        "type":"Buffer",
        "data":[255,1,30,0,22,116,215,2,3,215,223,228,78,119,16,57,51,79,71,18,251,149,173,53,82,84,246,116,200,245,210,134,80,49,153,21,123,123,247,195,87,14,1,0,0,0,0,0,0,6,84,73,68,58,32,48,0,194,235,11,0,0,0,0,15,0,0,0,30,72,161,107,90,67,151,232,118,184,105,194,229,52,233,123,39,157,230,102,177,48,68,2,32,69,177,255,192,154,14,176,62,80,182,75,185,130,144,48,143,68,177,152,153,1,75,93,101,109,175,41,10,149,220,23,79,2,32,15,59,8,76,121,202,240,45,147,56,172,137,149,29,183,136,156,137,156,69,81,149,205,254,98,22,126,19,61,71,244,227]
      }
    }

    The length of the serialized transaction is 160 bytes. This length is taken into the calculation formula outlined in the AIP-16 proposal.

    The size of a transaction varies and is related to vendorField size. The transaction type is included in the dynamic fee calculations, since a vote or delegate registration transaction requires more processing power. This is where the dynamicOffset plays a role. Offsets are defined in the network settings (network.json). Default values look like this:

    // Found in networks config folder in crypto/lib/networks
    "dynamicOffsets": {
        "transfer": 100,
        "secondSignature": 250,
        "delegateRegistration": 500,
        "vote": 100,
        "multiSignature": 500,
        "ipfs": 250,
        "timelockTransfer": 500,
        "multiPayment": 500,
        "delegateResignation": 500
     }
    // Fees can be enabled and disabled based on setting below. Meaning that from block 10 onwards 
    // the dynamic fees will be active.
     {
        "height": 10,
        "fees":{
          "dynamic" : true
        }
      }

    Dynamic fee is calculated according to the formula implementation, as can be seen here:

     /** Calculates delegate fee for processing and forging if transaction
      * @param {Number} Fee price per byte in ARKTOSHI as set by forger/delegate in delegate.json setting feeMultiplier
      * @param {Transaction} Transaction for which we calculate dynamic fee
      * @returns {Number} Calculated dynamic fee in ARKTOSHI
      */
      calculateFee (feeMultiplier, transaction) {
        if (feeMultiplier <= 0) {
          feeMultiplier = 1
        }
        // we get the transactions offset for a transaction type and 
        // calculate the dynamic fee based on AIP Formula
        return (this.get(transaction.type) + (transaction.serialized.length)) * feeMultiplier
      }

    And finally, the process of retrieving a transaction from the pool is
    seen in the following code snippet. This code is executed according to
    each transaction before returning to the forger (Figure 2 — Forger requesting transactions from the node), method checkIfDynamicFeeMatch(transactions).


    /**
     * Determine if transaction matches the accepted fee by delegate or max fee set by sender
     * @param {Transaction} Transaction - transaction to check
     * @return {Boolean} matches T/F
     */
     module.exports = (transaction) => {
      const transactionFee = transaction.fee.toNumber()
      const staticFee = feeManager.getForTransaction(transaction)
      const blockchain = container.resolvePlugin('blockchain')
      const feeConstants = config.getConstants(blockchain.getLastBlock().data.height).fees
      if (!feeConstants.dynamic && transactionFee !== staticFee) {
        logger.debug(`Received transaction fee '${transactionFee}' for '${transaction.id}' does not match static fee of '${staticFee}'`)
        return false
      }
      if (feeConstants.dynamic) {
        const calculatedFee = dynamicFeeManager.calculateFee(config.delegates.dynamicFees.feeMultiplier, transaction)
        if (transactionFee < config.delegates.dynamicFees.minAcceptableFee) {
          logger.debug(`Fee declined - Received transaction "${transaction.id}" with a fee of "${transactionFee}" which is below the minimum accepted fee of "${config.delegates.dynamicFees.minAcceptableFee}" by this delegate.`)
          return false
        }
        if (calculatedFee > transactionFee) {
          logger.debug(`Fee declined - Received transaction "${transaction.id}" with a fee of "${transactionFee}" which is below the calculated fee of "${calculatedFee}".`)
          return false
        }
        if (transactionFee > staticFee) {
          logger.debug(`Fee declined - Received transaction "${transaction.id}" with a fee of "${transactionFee}" which is higher than the static fee of "${feeManager.get(transaction.type)}".`)
          return false
        }
        logger.debug(`Transaction "${transaction.id}" accepted with fee of "${transactionFee}". The calculated fee is "${calculatedFee}".`)
      }
      return true
    }

    Help Us Test

    New features and core functionalities were tested by our team internally. However, public testing is essential to review all of the usage scenarios and edges cases from a fresh perspective (developers aren’t always the best testers). Wallets incorporating dynamic fees will be available prior to v2 MainNet release, currently only CLI tools will be available for testing on DevNet.

    Everyone is invited to our DevNet to perform proper testing (join our Slack, channel #devnet) — from dynamic fees to multsig transactions and anything else you can think of. The more we test the better the foundation is for our new Core v2.

    If you find a bug, please provide in-depth and detailed information on our GitHub Core repository (click), where all the instructions are already waiting for you.

    Delegates

    All delegates running nodes will have an option to customize fees in the config file according to the network they are running their node for (eg. DevNet Dynamic Fee configuration file).

    Intro to Core Tester CLI

    ARK Core v2 comes equipped with a built in testing suite. Presuming ARK Commander was used to install Core we can move into the Tester directory:

    cd ~/ark-core/packages/core-tester-cli

    From here you can run commands for sending test transactions across the network. They all have built in validation/tests to make sure the transactions are processed correctly.

    To send one or more transactions, you simply run the commands and adjust the parameters. As you can see, the first command starts the tester and tells it which transaction it will run. The “\” at the end means end line and more parameters (commands) will follow. Each parameter starts with “--” and ends with “\” specifying that there are more parameters coming. When you reach the last parameter there is no “\” at the end. For example to generate 2 transactions you would run the following command:

    ./bin/tester transfer \
    -n 2 \
    --base-url http://167.114.29.34 \
    --passphrase "your 12 word passphrase"

    In the example above, n represents the number of transactions you wish to send, base-url is node IP being broadcasted to (replace that with your Node’s IP) and passphrase is the wallet you wish to send transactions from.

    By executing the command you get the following output in your terminal:

    If we check the transactions in the dexplorer.ark.io we can see that two transactions where confirmed and forged:

    The core-tester-cli package comes with the following commands:

    1. ./bin/tester transfer - Send multiple transactions
    2. ./bin/tester second-signature - Create wallets with second signature
    3. ./bin/tester delegate-registration - Create multiple delegates
    4. ./bin/tester vote - Create multiple votes for a delegate
    5. ./bin/tester multi-signature - Create multiple multi-signature wallets

    The tester-CLI suite stores the address and passphrase of every wallet created in the ~/ark-core/packages/core-tester-cli/test-wallets file. You can open the file simply by opening it with your editor. For example:

    nano ~/ark-core/packages/core-tester-cli/test-wallets

    Our core-tester-cli has some basic help and parameter included. If you write:

    ./bin/tester -h

    You get basic help and if you write:

    ./bin/tester COMMAND NAME -h

    You’ll get more detailed information about parameters and command.

    You can also read the commands and their respected values here:

    https://github.com/ArkEcosystem/core/tree/develop/packages/core-tester-cli/bin/tester#L23

    Setting the dynamic fee parameters in generated transactions

    Each of the commands has a list of parameters (see the link above). One of the parameters allows specification of a custom fee that the user is willing to pay for the processing of the transaction.

    The transfer command contains the option `--transfer-fee` where the exact fee can be specified arktoshi.

    ./bin/tester transfer \
    -n 2 \
    --base-url http://127.0.0.1 \
    --transfer-fee 5000 \
    --passphrase "your 12 word passphrase"

    You can also specify random limits for `--transfer-fee` parameters. For example you can specify a transfer-fee range as follows:

    --transfer-fee 1000–5000

    This will randomly select different values for the fees in the provided range between 1000 and 5000 arktoshi.

    If you are looking at your logs output you will see the following messages:

    Let’s run the following command generating 10 transfer transactions with random fees between 29000 and 50000 arktoshi.

    ./bin/tester transfer \
    -n 10 \
    --base-url http://127.0.0.1 \
    --transfer-fee 29000–50000 \
    --passphrase "your 12 word passphrase"

    In the above example fees will be randomly generated for each of the 10 transactions ranging from 29000–50000 arktoshis. This is great for testing limits and min accepted fees.

    If you are running custom ports for API and P2P you have 2 flags available for that (they are defaulted to 4002 and 4003 as we are running this on devnet):

    --api-port 4003 \
    --p2p-port 4002 \

    How do I set fees for other transaction types in Core Tester CLI?

    Each transaction has its own parameter in the core-tester-cli package. Look at the tester command file where all the parameters are visible. In general, we have the following options for dynamic-fee setup related to different transaction types.

    1. ./bin/tester transfer with parameter --transfer-fee
    2. ./bin/tester second-signature with parameter --signature-fee
    3. ./bin/tester delegate-registration with parameter --delegate-fee
    4. ./bin/tester vote with parameter --vote-fee
    5. ./bin/tester multi-signature with parameter --multisig-fee

    How do I configure my node to accept dynamic fees?

    Last but not least, you need to enable your node (your delegate) to accept dynamic fees. A detailed approach is written in the AIP-16 proposal.

    There are two main steps to configure and enable dynamic fees.

    1. Setting your fee parameters as a delegate

    A delegate can define his formula parameters for feeMultiplier and limit incoming transactions with the minAcceptableFee value. All settings are in ARKTOSHI per byte. Delegate settings can be found in delegates.json.

    Assuming core-commander was used to install core, your network config file can be opened with the following command:

    nano ~/.ark/config/delegates.json

    And there you have options to change feeMultipler or minAcceptableFee.

    “dynamicFees”: {
     “feeMultiplier”: 1000,
     “minAcceptableFee”: 30000
     }

    If you change it don’t forget to restart your Core process to load updated settings.

    2. Turning on dynamic fees

    Turn on dynamic fees in your network configuration file. Assuming core-commander was used to install core, your network config file can be opened with the following command:

    nano ~/.ark/config/network.json

    By setting the value of dynamic to true and defining a new milestone and the block height from which the settings should go into effect, we can enable or disable the dynamic fees on the node level.

    For example the settings below will enable the dynamic fee acceptance from block height 10 onwards:

    "height": 10,
    "fees": {
      "dynamic": true

    The example below will disable dynamic fee processing from block 20 onwards:

    "height": 20,
    "fees":{
      "dynamic": false

    All fees will be calculated according to static fees defined in network.json.

    If you change it don’t forget to restart your Core process to load updated settings.

    This covers basic usage and testing of dynamic fees. See you in #devnet channel on Slack!

    Remember we are also running GitHub bounty program for all pull requests that get merged :  https://blog.ark.io/ark-github-development-bounty-113806ae9ffe


  • ARK Core E2E Testing Automation

    The new Ark V2 Core is much more sophisticated software than our soon to be deprecated Node core. As such, when we designed the system, one of the most important priorities was having great test coverage. With that in mind, we went a step further.

    ARK E2E or ARK End-To-End testing is a custom developed framework by our dev team which enables the writing and running of end-to-end tests in a more automated mode.

    ARK E2E GitHub repository: https://github.com/ArkEcosyste...

    ARK core is already well-covered by unit tests, but with blockchain protocols, this is simply not enough when you want to make sure that it will behave correctly in “real life” environments. Nodes going up, syncing with the network, sometimes getting connection issues, or being shut down - these are the kinds of things that can happen and should be properly handled by the network and thus thoroughly tested. After all, it’s why we do manual testing on DevNet and internal TestNet.

    Automated testing helps to identify issues before they hit DevNet and give the ability to quickly pinpoint where things went wrong, like introducing new code and seeing how it will behave when introduced outside of local testing. All of this is good development practice, but automating some of these “real life” scenarios can only help us improve the quality of our product.

    That’s why we are bringing automation to these situations — this is called “end-to-end”. Its main feature is to generate and launch a fully functional custom network on your machine, with a configurable number of forging nodes.

    On top of this custom network is the testing framework. It allows you to look into the blockchain events in real time and execute actions, like creating transactions and broadcasting it to the network. These end-to-end tests are configured on our continuous integration tool to be run every night. It will pull up the develop branch with the latest commits, run the network from it (current default configuration is 5 nodes) and execute the actions/tests. Going forward, this framework will automate testing scenarios like double spending, double forging, spamming, and other situations.

    What we used to test manually will now be tested every night so we will be able to react quickly when something is wrong and we will progressively add more and more end-to-end tests over time.

    This will not replace manual testing, but it is a new tool in our arsenal that will further improve the quality and resilience of our blockchain core.

    If you want to learn more about ARK E2E back-mechanics you can read “ARK E2E Technical Details”.




  • ARK Core: Testathon Summary for Core v2

    ARK Core Testathon has ended after a full week of testing! Here is a recap including our participants’ findings and developments made by the team.

    Our first Testathon was a great success! Multiple bugs were discovered and subsequently fixed in the PRs. This discovery and correction process gave our core dev team many great ideas for future improvements. Here are a few of the most notable issues and fixes from this week-long event.

    One of the first things tested was mass spamming and breaking of the network (special thanks to Marc for helping with this part), revealing the need to improve how the transaction pool handles incoming transactions. Initially, every transaction was accepted into the pool increasing the time to verify new upcoming transactions. This increased load resulted in forgers missing blocks. After improvements, only transactions that meet a nodes criteria to enter its pool are included. All other transactions are further broadcasted until accepted by a node. If no nodes accept the transaction it gets dropped. Following implementation of this fix, the network was spammed by our testers who sent several thousand transactions at a time and the network performed brilliantly.

    A GitHub issue was reported by user wownmedia relating to a check done on the VendorField for its length. This check was not being performed properly for special UniCode characters. Further investigation from our team resulted in implementing a proper check on the VendorField and stricter validation on the length of the field.

    During the Testathon we have also found state machine inconsistencies in some edge cases that our Core team has been working on resolving over the past few days.

    Participants

    We would like to thank each and every person who helped test the new Core — be it reporting issues or, providing solutions, helping with running devnet nodes or just providing moral support in the channel. Thank you all (not just the one listed for bounties)!!

    Eligible submissions for the Testathon bounty are as follows:

    Github User : paroxysm

    Github User : Dated

    Github User : JeremiGendron

    Github User : zillionn

    Github User : thomas-neuman

    Github User :wownmedia

    All of the above go into the random drawing for the ARK Branded Ledger Nano S that will occur on the November 15th at 4PM CET. (http://www.randomresult.com/ticket.php?t=971229VWNR3)

    What was happening before and after the Testathon?

    Before the Testathon and following its completion our team continued to improve the Core, focusing on issues discovered prior, during and after testing periods. Here is a quick summary of the biggest recent changes:

    • Refactored fork handling (changes include peers grouped by height, refreshed after a forking and checked for common blocks).
    • Peer ban after fork (when entering a fork due to a bad block from a peer, that peer is now correctly banned. Previous bans were too short. Additionally, all peers are refreshed and those without common blocks are now suspended).
    • Transaction ping and rebroadcast (removed the isBroadcasted flag and instead introduces a transaction ping counter which is incremented whenever a transaction is received from a peer while it is in the transaction pool. While the ping count is 0, we assume the transaction was not properly broadcasted. On startup all transactions from the pool where the ping count is 0 will be rebroadcasted).
    • Reverted not matching dynamic fee state (before this change even if the transaction was not accepted in the pool, the sender state was applied — which in turn resulted in the wrong state of the sender and denying of later transaction).
    • Avoid that transactions below the minimum fee enter the pool (if fee doesn’t match the recipient pool, it is not allowed to enter the pool. Transaction will be broadcasted to other peers).
    • Added update counter (previously we would always check the peers when missing blocks, this change introduces a counter to only check if we keep missing blocks consecutively. It should take care of unwanted rollbacks and other issues).
    • Properly verify the payload length of blocks (the payload length was checked against undefined, which would always result in false and allow blocks to be broadcasted that are bigger than the allowed size. You could for example forge blocks that contain more transactions than the allowed maximum).
    • Added SSL support (added configuration options for SSL for your node to serve API data via SSL connection).
    • Only call checkLater if not called yet ( When the blockchain is ready it callscheckLater to wait 60000 ms before syncing with the network again. If a forger wakes up a relay to sync with the network it will end up issuing another checkLater. Over time the checkLater calls stack up and ripple since each checkLater ends up callingcheckLater).
    • Improved behaviour when network is missing blocks (removes unnecessary code and improves how missing blocks are handled. Also changes that more offences stay banned until expired when recovering from a fork).
    • Correctly update lastDownloadedBlock (the lastDownloadedBlock was not correctly updated in manageUnchainedBlock and thus effectively prevented the chain from advancing under certain circumstances).
    • Added Core Vote Report package (adds an optional package to generate the popular vote report https://explorer.ark.io/VoteReport.txt based on in-memory data which will show real-time data).
    • Added Core Elasticsearch package (adds an optional elasticsearch integration to provide more powerful searching capabilities for large datasets).
    • Made shutdown more graceful (The exit handler now emits a shutdown event to stop the blockchain. Fixes the blockchain so it can be stopped from all states, so it really stops processing blocks when requested, waits 1 second to let a round properly finish, with the more consistent shutdown, a table rebuild is only triggered when the wallets cannot be verified. A rebuild can take a few seconds on devnet, while the verification only takes a few hundred milliseconds).
    • Make sure all numerical inputs are positive (in some instances it was still possible to pass in negative values which shouldn’t be possible).
    • Require Node 10 as minimum engine (with implementation of ARK’s snapshotting system we made a minimum requirement of running NodeJS 10+ for ARK Core).
    • Added Hapi Rate Limit plugin (Added as hapi-rate-limit rate-limiting/throttling plugin.
    • Stop plugin setup on container shutdown (when the exit handler is running it was still possible that new plugins would be registered).
    • Reduce number of loops when reading/writing transaction bytes (Writing transaction bytes in Block.serializeFull requires three loops and two loops when reading. Both are replaced with a single loop which achieves the same).
    • allow P2P config without headers (allows the P2P /config endpoint without the need for the port, nethash or version endpoint).
    • Stateful data storage (introduces a new storage for the blockchain state. It caches the last processed blocks (100 by default). getCommonBlocks and getBlocks have been changed to make use of the cache and they will only fallback to the database if necessary).
    • Stricter API validation (added stricter API validation to make it more clear to the user what parameters are allowed and what they should be).
    • Don’t accept forger as peer (added an additional header which is used by forgers so that they don’t get erroneously accepted as a peer only to end up getting banned).
    • Use 1e8 instead of math.pow (Replaces Math.pow(10, 8) with 1e8 as it is quicker to type and yields the same result, just a syntax change).
    • Handle unexpected transaction errors in guard (invalidates a transaction when an unexpected errors occurs instead of returning a code 500).
    • Added rate limit offence (added a check for status 429 (rate-limit) in case that code ever comes up with a peer).
    • Added ability to skip initial peer discovery (Starting nodes with --network-start will already skip the peer discovery but it will also skip a bunch of other things in regards to the state-machine. The --skip-discovery flag will allow a node to be started in normal mode and skip the initial peer discovery like --network-start does without any of the side effects).

    We have also started to implement stricter coding rules for Core and added new plugins to further enhance our Core foundation including:

    • Stricter JavaScript styling rules (following AirBnB specifications).
    • Implementation of the Flow into the Core, which is a static type checker for JavaScript that identifies problems as you code and catches bugs that might otherwise go unnoticed (not only saving time, but helping uncover bugs).
    • Setup Snyk to stay on top of known security issues and vulnerabilities in npm modules.
    • Added support for error tracking and monitoring via Sentry or Bugsnag so node maintainers can provide better feedback if they decide to use a proper monitoring service for their node.

    And now for the one thing everyone has been waiting for… an announcement to announce an announcement. With final testing, pending improvements and fixes that our Core team is currently doing as you read this, we can say with confidence that next week we will announce Core v2 MainNet release date— stay tuned!



  • ARK Core v2 — MainNet Launch!

    The time has come. ARK Core v2 is now ready for launch. We are proud to announce the final and now official release date of Wednesday, November 28th. On this day we will break the champagne across the bow as the completely new vessel leaves dry dock and begins the voyage into the oceans of decentralization.

    The Core v2 codebase is entirely new and has been developed from scratch. It has been through relentless testing and is now finely tuned and ready for launch on MainNet to become the the backbone of our blockchain.

    Before getting into the details of ARK v2, it is important to explain the why behind the what — to describe our inspiration for building v2 and how it advances the larger goals of the ARK Ecosystem.

    Since long before the ARK genesis block, our goal has been to provide the same accessibility and scalability for custom blockchains as WordPress provides for custom websites. Coupled with ARK’s interoperability features and modular construction, this makes for the perfect ecosystem of interconnected plug-and-play chains. Our primary objective behind the development of v2 was to identify ways we could move the ARK code base closer to these goals.

    The procedural, step-by-step approach of the v1 code base would need to be replaced with an all new lightweight and modular design. Under such an architecture, nearly all aspects of the ARK code base could be modified, extended or replaced quickly and easily. Think of it like building with LEGO blocks. If you simply add or replace LEGOs to your project, you can create something completely new. In turn, this approach would allow blockchain developers maximum flexibility in aligning their bridgechains to reflect their organizational priorities.

    With this strategy in mind we set about rewriting the ARK Core from the ground up. From the programming practices adopted to the JavaScript dependencies chosen, our continual focus has been to write efficient, modern and highly readable code.

    Our work at ARK has been in service of a simple, yet powerful truth: The easier it is to read and understand code, the easier it is to extend it. This approach is perhaps most evident in our new plugin system, where nearly all node functionality can be customized as easily as installing a plugin on a WordPress site. Across all of the changes listed below, you will find that accessibility and extensibility are prevalent themes as we strive to create the world’s premiere blockchain development platform.

    What Will The New Core Bring?

    • Dynamic fees — most noticeable for end users is the addition of dynamic fees enabling delegates set their own fees for different transaction types. Users have the option to modify and pay fees they are comfortable with for sending transactions.
    • Plugin system — ARK is the first blockchain protocol released that allows you to easily develop customized modules or plugins, to leverage the power of blockchain. The majority of ARK’s processes have been decoupled, modularized and developed as plugins. Only a few lines of code are required to add or remove new plugins to the system. Our goal of developing the ‘WordPress of blockchains’ has been realized. You can now develop your own plugins and easily include them into your own blockchain.
    • Increased TPS (Transactions per Second) and TPB (Transactions per Block)— Transactions that can be included in a single block are increased from 50 to 150. The total increase in TPS is threefold from 6.25 to 18.75. This is not a TPS limit and can be easily raised in the future. Currently this level of throughput is more than adequate. For bridgechains, this value is completely customizable.
    • New API — A much more powerful API provides additional endpoints, is much more stable and follows latest API standards, giving developers more options to get necessary information and interact with ARK’s blockchain.
    • Webhook support — Webhooks allow applications to provide other applications with real-time information. A Webhook delivers data immediately as it happens as opposed to a typical API where polling must occur very frequently and inefficiently to get real-time data.
    • Better transaction pool management — a newly developed transaction pool (transactions are kept in this pool before inclusion in the blockchain) is leveraging the power of memory and SQLite, providing superior stability, reliability and a foundation for future optimizations.
    • Better verification systems — the legacy code has multiple drawbacks with how blocks and transactions are verified and included in the blockchain. The new Core verifies database integrity at the start of each node process, checking its validity and continuing with much improved efficiency and handling. These actions also bring additional security to ARK and we all know how important that is for blockchain projects.
    • Speedier rebuilds & synchronizations — starting your own node from block 0 with the new system is much faster. Previously, rebuilding from 0 to current block height (~ 6,450,000 blocks) required around 50 hours. ARK Core v2 can do it in approximately 12 hours (depends on the server specifications and overall network state). As a result, synchronizing becomes much faster when stopping and starting the node process, or when rebuilding from a snapshot.
    • Better decentralization through new snapshot system—the old code was very dependent on the ARK team for snapshots when building or rebuilding a node. An all new local snapshot system has been developed allowing node operators to use their own copies of the database when needed. When starting a new node or rebuilding a node due to errors, local copies will allow for fast and safe synchronization and will reduce dependence on the ARK team. This development brings wider decentralization to the ARK ecosystem and is a much safer and faster way for nodes to recover in case of emergencies.

    How Will The Transition Occur?

    On November 28th 2018 our team and delegates will coordinate a switch to the new Core by installing the new Core on servers. This is a hardfork, which means that it will NOT be backwards compatible with the old code. All node operators will need to replace their old deprecated ARKNode code with ARKCore. Old nodes will NOT be able to communicate with new nodes, as they will be automatically banned. The upgrade process may result in small network downtimes — please bear with us.

    End users will only need to install updated wallets that support the new protocol (either Desktop or Mobile Wallet). Current desktop and mobile wallets will be updated and all information and guides will be available prior to launch.

    Along with ARK Core v2 comes a totally new Desktop Wallet also built from scratch! The new wallet will provide dynamic fee settings right out of the box. More information will become available as we near the release.

    There will be plenty of time for exchanges to transition to the new protocol, however exchanges may be intermittently down during this process. We will be providing assistance to all exchanges during this transition. Fortunately, the new Core is much easier to integrate, and by default comes with a JSON-RPC plugin.

    If any exchange is reading this — contact us if you want to integrate with ARK! We appreciate each addition and can help with integration and technical support.

    JSON-RPC Docs :  https://docs.ark.io/guidebook/core/json-rpc.html#installation
    JSON-RPC API: https://docs.ark.io/api/json-rpc/

    What’s Next for ARK Core?

    Following the MainNet launch, our first focus will be to monitor and address any issues or bugs that may arise. After that our focus will be on building Core v2.1, our next major release for ARK due for release in early 2019.

    Core v2.1 includes new transaction types such as timelocks, updated multisignatures, multipayment support, increased size for SmartBridge field from 64 to 256 chars and will allow “Push.Button.Blockchain.” to be fully realized with bridgechain interoperability options. More information on v2.1 will be released in several upcoming blog posts.

    Tell Me More, ARK!

    OK, this is what we have in store before the end of 2018:

    • ARK Pay — ARK Pay will be a simple open-source library that will provide merchants and vendors the ability to easily implement and start accepting ARK as means of payment in online shops. This will be an officially supported plugin developed in JavaScript. Examples for popular frameworks like Vue.js and React will be available and everything will be open source and well documented for anyone to implement it. Release is due in a few weeks.
    • ARK Desktop Wallet v2 —a new desktop wallet built from scratch brings in a new codebase, improved UI, dynamic fee support and much more. Release is due with the release of Core on Mainnet.
    • Whitepaper v2 — rewritten whitepaper that will cover ARK basics, and go into more details of some of the aspects of it, along with our near and far end vision for ARK. Expected completion and release towards the end of the year. Depending on when we complete the final v2.1 (and beyond) technical specifications, WP v2 may be delayed to Q1 2019 to allow time to include the updated technical details.


  • Community Spotlight — November 2018 Edition

    November is a wrap! We at ARK are proud of our determined and bright community, and our monthly Community Spotlight newsletter will keep you apprised on some notable community activities. Let’s dive into just some of the ways the ARK community shined in November 2018.

    ARK Q4 2018 Infographic by ACC and Community Member ‘dvdptr’

    FEATURED COMMITS

    As they say, the best things happen with help. That’s why ARK runs monthly bounty programs for coders who contribute to our codebase on the ARK Ecosystem GitHub. Independent programmers can work side by side with our international team and make the ARK toolkit even more powerful and stable. Earn ARK mainnet tokens for ‘commits’ (completed tasks) and win larger monthly ARK prizes as well.

    Here are some featured commits for November. Features may not be live until the next update:

    • GitHub member ‘dated’ added emoji support to the vendor field in the ARK Explorer repo. You can bring your own unique expression to your transactions. How cool is that? Additionally, ‘dated’ also optimized the French flag in the explorer. While not a monumental feat, it’s a good opportunity to bring up ARK’s ties to France, with ARK CEO and cofounder FX Thoorens actively working with the French government on crypto-friendly legislation, and ARK.io being a registered business entity in France.
    • GitHub member ‘highjacker’ updated documentation for V1 and V2 usage. The ARK toolkit is very well documented and you can jump into ARK documentation here. ‘Highjacker’ also worked on French translations over in the Explorer repo.
    • GitHub member ‘ciband’ was hard at work cleaning up API code and fixed Windows support in the C++ library.
    • GitHub member ‘whitehat’ ran testing and chores throughout Core, explorer, and some libraries. Testing is paramount to ARK, and ARK recently held a community-wide Testathon with Testathon results. ARK also conducted E2E testing.
    • GitHub member ‘zillion’ addressed multiple fixes, refactors, and features.
    • GitHub members ‘JeremiGendron,’ ‘Paroxym,’ ‘ vmunich,’ ‘ thomas-neuman,’ ‘ arkmoon,’ ‘ roks0n,’ ‘ brtastic,’ Pedro-Souza,’ ‘ geops22,’ ‘ Nigui,’ and ‘patt007’ handled numerous tasks, fixes, chores, and features across multiple repos.

    All these contributors have a very long list of accomplishments for November, and helped ensure all the t’s were crossed and i’s were dotted in preparation for the ARK v2 release which took place in late November. Not all things in coding are glorious, but the community devs certainly shined this month!

    Multiple coders are contributing to the ARK toolkit 24/7, and you can, too — it’s fun, rewarding, and you can earn and win ARK tokens, as well!

    This guide will show you how to get started.

    NOTABLE REDDIT POSTS

    The Ark Ecosystem Subreddit is a great place to seek ARK knowledge, and you can always find new and engaging content there. New to ARK? Check out my Welcome to ARK Reddit Post with simple instructions to follow.

    Here are some notable November posts:

    You can browse more content and contribute your own voice to the ARK Subreddit- who knows, you may even receive an ARK tip from a community member using Delegate Cryptology’s intuitive ArkTippr Reddit tipbot.

    NOVEMBER 2018 PODCASTS

    Arkv2 Testathon, Hackathons, Halloween Clues, Justin Renken w/ Altcoin Magazine Oct 29 2018 Travis Walker On The Cast Talking WCC Poker Tournament Oct 31, Ark v2 & 2.1, Aces & More Justin Renken — Interoperability Panel — World Crypto Con 2018 Las Vegas Nov 2, 2018 ARK V2 Compilation Show (ARKv2 Mainnet Upgrade Date Is Nov 28 2018!) Community Questions, 30 Days Of ARK Reddit Campaign & Nexus Interview

    COMMUNITY SERVICE SPOTLIGHT

    Some members mentioned in the community newsletter are ARK delegates, who secure the ARK network and provide community services. Their inclusion in the newsletter is in no way an endorsement from ARK.io to vote for specific delegates, and you should always do your own research and consider all the options when choosing a delegate for whom to vote. ARK.io does not run the ARK network.

    Here’s the November 2018 Community Service Spotlight:

    Delegate CYJ’s What is ARK DPoS Video

    ARK COMMUNITY COMMITTEE

    30 Days of ARK Campaign, running throughout December on Reddit.ARK.io

    Dubbed ‘30 Days of ARK,’ this month long campaign is running on the ARK Subreddit and asks everyone to provide their thoughts and opinions on 30 ARK concepts. Delegate ‘Jarunik’ has graciously provided ONE THOUSAND ARK you will earn proportionally by word count for the entire campaign. Anyone can learn about ARK straight from the mouth of the community, as well as earn ARK by contributing content. Read details, rules, and submissions here. After the campaign is over, the ACC will come together to design a community website resource that immortalizes these submissions, making it even easier for future newcomers to catch up on ARK.

    To join the ACC, locate me on Discord.ARK.io which by the way, just increased its powers significantly with new bots, features, and feeds, courtesy of CMO Travis Walker’s oversight. ACC Projects are funded after the fact and pay is not guaranteed (fun is, though).

    ARK COMMUNITY FUND

    If you have an idea for an ARK project, small or large, and you are looking for funding, consider submitting a proposal to the ARK Community Fund for review. The ARK Community Fund started as a community initiative, and the elected board reviews ideas and projects that enhance ARK. Their website is ArkCommunity.Fund.

    The opportunities that ARK Ecosystem provides are ever growing, and there are many ways you can get in on the action. To reach me, you can contact me on the ARK Slack or Discord: @Justin (doubled1c3).

    Looking forward to December!



  • ARK and Bugcrowd Go Hunting!

    ARK is pleased to announce the acquisition of security and penetration testing services from Bugcrowd — the planet’s premier crowd sourced security platform! Highly skilled and trusted white hat hackers from all over the world will try to breach the ARK hull and attempt to expose vulnerabilities before they pose a risk to the ARK Ecosystem.

    Working with Bugcrowd, ARK can tap into a global community of over 100,000 expert researchers who use varying techniques to identify 7 times as many critical issues, 80% faster than traditional solutions can.

    The list of Bugcrowd customers includes world class companies like Netflix, Tesla, Dash, Binance, Netgear, Pinterest, Atlassian, Invision, Motorola, Hewlitt-Packard, Barracuda Networks, Western Union, Fiat/Chrysler, Digital Ocean…. and the list goes on and on.

    ARK is taking advantage of a full array of services offered by Bugcrowd, including both private and public programs. The private program should begin this week, while the public program will begin in early January 2019. Final features and further details will be announced later on when the public programs begin. First item on deck for testing will be the release of our new ARK v2 Core!

    How it Works

    A Bugcrowd Security Researcher discovers and submits a finding to Bugcrowd. This submission is reviewed for uniqueness, tested, reproduced and once validated, is quickly escalated to the ARK Team. In turn, we review and patch the finding. Findings that may be critical are pushed to our team in under 24 hours. ARK can directly converse with the researchers, and we have access to all conversations between the security researchers and Bugcrowd. As a result, critical bugs get fixed and patched much sooner than less critical ones.

    Vulnerability Rating Taxonomy

    ARK will be using Bugcrowd’s VRT, a resource that outlines Bugcrowd’s baseline priority rating. Included are certain edge cases for vulnerabilities that are frequently seen. To arrive at this rating, Bugcrowd’s security engineers start with generally accepted industry impact and further consider the average acceptance rate, average priority, and commonly requested program-specific exclusions (based on business use cases) across all of Bugcrowd’s programs.

    Bugcrowd’s VRT is an invaluable resource for bug hunters as it outlines the types of issues that are normally seen and accepted by bug bounty programs. We hope that being transparent about the typical priority level for various bug types will help program participants save valuable time and effort in their quest to make bounty targets more secure. The VRT can also help researchers identify which types of high-value bugs they have overlooked, and when to provide exploitation information (POC info) in a report where it might impact priority.

    Why Crowd Sourced Security?

    There is a disconnect between the motivations of network attackers, and those of developers and security defenders. Crowd sourced security eliminates this imbalance by harnessing white hat security researchers to find and eliminate vulnerabilities, providing rapid and focused results. The most critical attack surfaces are examined including web and API interfaces on server/cloud, mobile and IoT platforms. The security researchers are trusted and highly vetted, diffusing the concerns of risk associated with crowd sourced security.

    An External View

    While the ARK team and the community know the blueprint of their ship quite well, it is often the eyes of outside examiners who can provide a fresh look from a different angle. Bugs and security vulnerabilities can be found that may never have been apparent to the ARK team. The massive increase in efficiency of crowd sourced pen-testing will allow ARK to reach maximum security in far less time than if we rely on an internal team. Ultimately, it is our highest priority to provide the most secure platform possible to the users of ARK.

    If you are a young researcher willing to learn more in the ways of cybersecurity, Bugcrowd offers a University program where you can learn the skills of the cyber jedi.



  • ARK Desktop Wallet v2.1.0 Released




    A new version of the ARK Desktop Wallet has been released. The best ARK wallet just got even better thanks to your input! Many of the improvements and new features are a direct result of community feedback, testing and bug reporting.

    It has only been two weeks since the release of version 2 of our Desktop Wallet and there have already been several improvements and bug fixes. A sincere Thank You to the community developers who have helped ARK in the past and continue to support us.

    The new wallet is available for download at: https://github.com/ArkEcosystem/desktop-wallet/releases

    Hashes for 2.1.0. of Desktop Wallets (SHA256)

    • Linux (Ark.Desktop.Wallet-2.1.0.tar.gz)  70d5dcda709caf84ddef9a82c1118755be44b72d52785aad4130e127a64d84d7
    • MacOS (Ark.Desktop.Wallet-2.1.0.dmg) 58fe5c8c7683a83ea0857f294e00502fee81204eaf5471d8b040209c06de0291
    • Ubuntu (Ark.Desktop.Wallet-amd64–2.1.0.deb)  7f6b50aa010915bdf79f9a11478dfd5dfc7d962cb0dd1598bde4ef4acf53675f
    • Windows X86 (Ark.Desktop.Wallet-x86–2.1.0.exe 1685233b81d79bd9b40e1d95f8f3b1dbe97b34821a8ee4da6fe2af9826accd53
    • Windows X64 (Ark.Desktop.Wallet-x64–2.1.0.exe) 24323e0203371e0acc705cc2202e8f83a2ddb1802d0b57c5967fd63734c8424a
    • Linux-AppImage (Ark.Desktop.Wallet-x86_64–2.1.0.AppImage) 915068ceb520cb195b4a39c4cad552cb304980f83795fee4fdb4b3e9f902b4b2

    What was fixed or added?

    • Renaming Ledger wallets — it is now possible to rename your Ledger wallets from the default name to a customized name. You can set the name by opening a Ledger wallet, clicking the three vertical dots on the right and selecting “Wallet name” to rename it.
    You can now rename your Ledger wallets
    • Including Ledger wallets in the total balance — The total balance of all wallets, including Ledger wallets is now displayed at the top of the wallet overview page.
    Total balance now takes into account your Ledger wallets
    • Optional caching of the Ledger wallets — gives the option of caching Ledger wallets to speed up initial loading. This is useful for users with multiple Ledger addresses. This is off by default and the switch can be found on the “My wallets” page when a Ledger is plugged in. If the option is turned off, all cached Ledger wallets for that profile are removed from the cache.
    Option to cache Ledger wallets (saving to local storage)
    • Update Ledger in the background — In the settings menu you can now choose to Update Ledger addresses in the background. Turning this on will continue to update all ledger addresses while in the main transaction screen. This runs a process in the background to determine if transactions have been processed. If off, pending/expired transactions will only show when viewing a specific Ledger wallet address.
    Option to update Ledger in the background for up to date data
    • Rebroadcast expired transactions — After the default expiration of 45 minutes, expired transactions can now be rebroadcast with a simple click of the “Resend” button. Alternatively, you can choose to discard the transaction.
    Resend or discard expired transaction
    • Adding Changelly as an option to purchase ARK — Changelly is now integrated with the v2 wallet. After the release of the v2 wallet, we received many questions asking when Changelly would be re-implemented and we heard you loud and clear. This integration of Changelly is a basic version that will mimic the performance you are familiar with from v1 of our desktop wallet. Our next release will feature a new and blended design that better matches the aesthetic of the rest of the wallet.
    You can now purchase ARK from within ARK Desktop Wallet
    • Properly validate fields when populated by AIP 13 (URI Scheme) — if you are using ARK’s URI scheme it now properly validates fields and makes it possible to send a TX. URI scheme plays a big role in our upcoming ARK Pay module.
    Properly validates and fills up all fields that were obtained from URI link
    • Show full time of the transaction —the full date and time are now shown for transactions.
    Shows peer you are currently connected to
    • Shows “Rank” inside voted banner — SelectingDelegates on the wallet page now displays a banner the bottom showing the delegate and rank for whom you are currently voting.
    Now also showing rank of the voted delegate
    • Obtain and display the balance of contacts — you can now view balances of the added contacts on the “My contacts” page.
    Balance of the contacts is now displayed
    • Recipient search case insensitive — for better UI experience we made recipient case insensitive (was sensitive before).
    Searching for recipient is now case insensitive
    • Display helper text when a known address is recognized — when the address is a known address, a helper text will be displayed under the Recipient field.
    Shows a text below the field if its recognised wallet
    • Inputting small numbers into the input field — the input of small numbers has been corrected. For example, 1e-7 now is properly displayed as 0.0000001.
    Before / After
    • Option to enable or disable chart on the dashboard — you can now disable or enable the price chart on the dashboard in settings.
    Option to enable or disable chart
    • Add avatar profile “more” icon — Alerts to the presence of a profile page when clicking on the Avatar in the lower left corner.
    “More” icon
    • Separate logo in the sidebar — for better aesthetics we have separated the logo from the menu.
    P.S. Clicking on the logo takes you to the dashboard
    • Chart buttons hover background color — there was no visual feedback when hovering over the chart header buttons. We have added it for a better UI experience.


Log in to reply
 

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