Summary of AMA Monday, 13th August with our Development and Security team led by CA333 (DevSec)

You can read the full AMA here.

An AMA stands for “Ask Me Anything,” which is an internet term used to describe an interview that occurs between the hosts and all the other users who want to ask questions.

Q1: Are you planning a two factor authentication for Agama login and for the transactions? And assuming Bitcoin is successfully attacked, can Komodo secure itself via another blockchain? (source).

No — it is not planned as of now. Let me explain to you why: a 2FA key is always linked to a specific dataset (usually unique userdata stored in a centralized database of the centralized service/app you want to log in) — it does provide an additional security layer for centralized systems. The big question here — what happens if the attacker gains your login-credentials but NOT your 2FA? The attacker cant log in. Ok now lets look at Agama. Agama is based on decentralized technology and doesnt store any userdata/login-creds in a centralized system. The only login data is your privatekey or Agama Seed. Now lets say we implement 2FA onto Agama (which we actually could do regardless of the sense) — what would happen if someone gathers your Seed/privkey but NOT the 2FA? The attacker will be able to fully clear your wallets and rob you 100%. In this case the traditional 2FA wouldnt help at all — it wouldnt add any additional security layer. One option to do this would be some sort of new dynamic blockchainbased-2FA — this is something that wasnt invented yet but its fully practical and possible to implement from a technical point of view. So in this case you d for example need to invent a new 2FA derivation path algorithm that is taking as input only one single private-key — and it would deliver a new dynamic key (=2FA key) each N blocks or seconds based on this privkey. Based on an initial timestamp this new 2FA-derivation-path algorithm would always know which 2FA-key to show you — and any application/wallet could use the same data to verify the key. This would work pretty well as the worlds first native blockchainbased 2FA technology. Of course you d need to pack it into a secure chip that is utlizing this algorithm — and there you go. We, the Komodo Platform coreteam, are offering a bounty of 25.000 USD + a fulltime job offer for the successful implementation of the above described technology on top of Komodo. (functional prototype fulfills the reqs).

Q2: When Ledger Nano S will be fully supported to get access to Komodo interest rewards and to have access to jumblr? (source).

We are in touch with the ledgerHQ developers and informed them about all necessary modifications in order to natively support the Komodo Interest/Reward system. At the current point of time the ledger system called BOLOS ( = a blockchain operating system which represents the base layer of the ledger HW family — it is similar to an SPV network sys) does not natively support the interest tech. We will keep the community updated on this topic. Also keep in mind that it is possible to store your KMD on a ledger and to collect the reward with an extra step through https://www.youtube.com/watch?v=nKBdGI8pu7M or a special software https://github.com/KomodoPlatform/bip39 → please make sure you follow general/common security guidelines! ALWAYS use offline computer for this sort of tasks! ask KMD support for help if you don't know what you re doing!

Q3: Can the team give some insight in how a listing takes place, what kind of security implications this has and how KMD solutions, wallets/dpow have an impact on stuff like this? (source).

Interesting question! The listing takes place by the KMD dev team and our DEX engineers and we never charged/charge a listing fee. We have dedicated DEX experts assigned to this task. The process is a review of the to be listed token by checking the source code, devteam, projects purpose, “ideological compatibility”, etc. Sometimes we do an independent listing without any external request or community intervention. Its probably also interesting to know that we do process/consider all listing requests regardless of potential volume or community size. In this regard we be believe in equality.

Q4: What differentiates central exchanges from decentralized exchanges from a security standpoint? I assume that for a DEX the security aspect mainly lies with how secure the infrastructure is from the person that is using the DEX? Or does a DEX itself also have several security precautions? (source).

From a security standpoint we think the biggest difference is in the technological aspect — the underlying base/function-scheme of a DEX is based on cryptography (mathematics) and decentralized blockchain-technology (trustless p2p tech) while a CEX is based on centralized technologies and database systems with read/write functionalities that allow you to modify already stored data. As an example — in a DEX system i couldn’t fake your balance nor rob the users accounts by emptying the hotwallets. In a DEX i can’t do any of this (if the DEX does what it was conceived and developed for) — in a DEX your balance and all trades (=swaps) are based on blockchain/p2p tech and ECDSA sec-level cryptography — means if your keys don’t hold any funds than your private key also can’t create a transaction because of the lacking funds. Our barterDEX (market maker) is based on a special cross chain atomic swap protocol. So when a “trade” takes place there are multiple transactions/events taking place to ensure the security and remove any counterparty risk — below you can find the steps of such a cross chain atomic swap:

0)alice pays the barterDEX fee 1)bobdeposit takes place 2)alicepayment gets issued 3)bobpayment gets issued 4)alicespend — this is the actual swap 5)bobspend — this is the actual swap 6)refund of bobdeposit (ensures that bob doesn’t scam alice)

So yes — this protocol implementation and other security related tasks and precautions do provide a basic security layer to the user. But using any decentralized and p2p/blockchain-based technology we do assume that a users infrastructure is fully secured — after all, if your computer is infiltrated all hope is lost anyway (tr0jan/keylogger could even grab your 2fa code when you type it in and empty all your accounts and wallets everywhere in realtime). We are as always happy to support and assist our users in the process of securing their infrastructure and devices. For this service please contact Rick in our Komodo discord. Another difference from a security standpoint is that if a CEX (= centralized server infrastructure/cluster) gets infiltrated/hacked that most likely ALL users/accounts will be affected. If one user of the DEX has an insecure system/infrastructure than only his/her node will be affected. The rest of the network will remain fully functional and secure.

Q4: Will there be a grandma friendly GUI based market maker/liquidity provider app in the future? Or will this remain something to be done through CLI?

Yes, we have a set of various GUI applications in development and evaluation stage. For barterDEX/marketmaker you could have a look on HyperDEX which is the flagship DEX GUI and currently in development stage. There is a alpha version out and the devs and community are very active and don’t mind going an extra mile for their users. https://github.com/atomiclabs/hyperdex/releases We also have a dev DEX app called barterDEX GUI which also is being maintained — https://github.com/KomodoPlatform/BarterDEX/releases Please feel free to join our discord server and to request more infos on this topic from our GUI experts: https://discord.gg/3rzDPAr

Q4: In order to contract with untrustworthy opponents, it is necessary to ask a reliable company or organization to supervise the smart contract code. The conclusion is that a traditional legal market is needed to coordinate legal disputes between these supervisory companies and users. What does the development team think about this problem?