Tech Tuesday Development Update - 2019 Week 2: Microtransaction Lightning Poker & Location Services Oracles

Komodo Team -

This series of posts is called the Tech Tuesday Updates.

In case you’ve missed a previous edition and want to catch up, you can find all the previous Tech Tuesday updates here.

Microtransaction Blockchain Poker - Lightning Network Poker

Micro transactions, cheapest artwork sold for 1 satoshi proving LN’s use case for microtransactions. The CHIPS project has a working decentralized poker game from CLI with a GUI for testing on the horizon for alpha testing.

GPS location data stored in blockchain HOWTO

A working example from the #kmdlabs discord channel is available that tracks a wandering dog. This is an excellent tutorial.

http://rant.cryptocartography.io/anatomy-of-an-oracle/

Blockchain oracles for storing files

Komodo Platform tester TonyL has continued adding to the suite of text tools for testing. These tools are useful for GUI developers to read the flow of these advanced blockchain constructs. A working example of how to program to upload and download files to an oracle can be found here https://github.com/tonymorony/GatewaysCC-TUI/blob/master/oracles_cc_tui.py

Verus Coin’s “perfect fork” upgrades mining algorithm to enhance CPU mining dominance over secret industrial miners

As soon as the Verus community confirmed the discovery of secret mining by FPGAs, an immediate and intense effort by community devs and others on everything from the wallet to the pools, to Electrum servers, and exchanges resulted in a brand new and very different hardware equalization algorithm that somehow, the Verus Community managed to activate, in what could possibly be described as a “perfect fork”...all in just under three weeks.

Unlike past efforts in cryptocurrency to equalize hardware hash-rates across different hardware types, VerusHash 2.0 explicitly enables CPUs to gain even more power relative to GPUs and FPGAs, enabling the most decentralizing hardware, CPUs (due to their virtually complete market penetration), to stay relevant as miners for the indefinite future. To our knowledge, VerusHash 2.0 is the first algorithm to fully equalize GPUs in a way that leaves them an option for mining, but not as fast or efficient as mid-to-high CPUs.

https://medium.com/veruscoin/verus-community-responds-to-secret-fpga-mining-be5e9ce0eafb

Handbook updates: Blockchain customization parameters

  • Founders of projects can use -ac_founders instead of -ac_pubkey for some chain configurations.
  • The introduction of eras to manipulate the emission rate of block rewards is available.
  • The taxation model parameter -ac_perc can now be used in two types of configurations
  • Multi-sig pubkeys can be used for founders rewards
  • Sapling activation can be delayed to a specific block height
  • Experimental features of time locking block rewards has been included in handbook docs

https://docs.komodoplatform.com/komodo/assetchain-params.html

Marketmaker v2 update

The marketmaker v2 dev-team have given an update through the discord channels during the week with their nightly builds available at http://195.201.0.6/etomic  they do not differ from MM1 although parts have been rewritten in Rust. These are experimental builds still, please use with caution if you are willing to be a public alpha tester. You are best to make contact in #dev-marketmaker channel in discord.

The next milestones due Q1 for beta testing are:

  • Libtorrent DHT as networking layer for swap
  • New simplified swap protocol (no need for 212.5% for maker)
  • No need for ETOMIC for ETH/ERC20 swaps
  • Many other changes in codebase: less C, more Rust

Some of the advanced features of MM1 will not be implemented during this phase but basic trading functionality will be available.

Game developers (& coin communities) served better by Komodo innovation

A digibyte community member and game developer made a request for address UTXO listings for his game.  Unfortunately digibyte has not incorporated optimizations that Komodo has for requesting such functions at this time.

The reason for requesting functionality from the server was because the “problem is insight is not maintained like digibyted is and i am already having to rewrite DigiStats because of this. Would like to avoid insight if possible going forward.”

Komodo dPoW consulting engineer & Hush lead developer @dukeleto stated, sic “that the other blockchain would need to merge bitcore to be able to use addressindex. KMD + assetchains + HUSH already have these indexes. The internal functions exist at the C++ level. Merging bitcore is quite a lot of work so if a coin doesn’t already have addressindex, bitcore is the big hurdle.”

The ability for an application to query any transaction and any address using the performance boosting blockchain capabilities merged into the Komodo codebase, gives any developer using Komodo the abilities of any bitcore node, like public facing blockchain explorers.

Address index RPC (remote procedure calls) is an example of a make or break feature for some use cases, that is pre-integrated into Komodo. Without it you have to recreate all the explorer logic (& not introduce bugs in doing so).

Maybe DGB would be interested in providing their users and investors a pegged and fungible tokenized version of their coin on an independent blockchain secured by bitcoin’s hashrate using Komodo technology. The advantage of this solution for a coin like Digibyte would be they the ability to leverage the Custom Consensus framework to create unique modules, special nodes for oracles to make off-chain data available on the blockchain, and interactivity, like blockchain-based games.

A tokenized asset locked by a gateway mechanism to their coins provides fungibility between a smart platform and their existing ecosystem and infrastructure.

Location services blockchain collaboration squashes bugs

The reality of massive software upgrades is that developers are not perfect and sometimes bugs are introduced. One bug that was caught was when the Oracles custom consensus module is invoked, it creates a UTXO-- one for each oracle. So far not a problem, this is normal behavior. Where the bug was obvious for #kmdlabs was when the “dragon hound application” (a location services blockchain application using leaflet.js) from community member @smk762 created hundreds of oracles across many blocks as the application was running.

The #kmdlabs channel were observing longer than usual sync times of a small blockchain and it was from a block propagation error.

Notary operator and #kmdlabs channel co-captain @blackjok3r made a pull request last week to fix the sync problem.

Iguana (bitcoin C language implementation) bug fix after sapling upgrade

Iguana began life as a bitcoin wallet implementation in C. C was chosen because it was lead developer jl777’s expert language. C provides two key benefits:

  1. Low level implementation means very high performance for low resource consumption
  2. Embedded use cases

Iguana is also a multi-coin wallet. In the early days of cryptocurrency, it was known as the fastest syncing multi-chain wallet in existence.

The iguana codebase does a number of things than being only a wallet. It is the software that runs:

  • Co-ordinates the notarization process amongst the Notary Nodes
  • Marketmaking (version 1) for the atomic swap DEX network
  • Transaction blasting API
  • Stenography API
  • Streaming media API

After the sapling upgrade, one important function had erratic behaviour - transaction splitting. This process is turning 1 UTXO into any number, for example turning 1 EMC2 into 100 x 0.01 EMC2 less the transaction fees for the EMC2 network.

This transaction splitting plays an important role in efficiently allowing the notary network to send multi-sig transactions from a template. The already complex set of events to co-ordinate a notary transaction between 13 nodes runs much smoother when all nodes are participating with the same size UTXO. It is one less negotiation step in the p2p communications.

After a full 24 hours of debugging at a very low level (hex) across the Iguana and Komodo code bases, Komodo developer Decker (infamous for his “LARP avatar from a 90s game”) found the erratic behaviour and tested it before releasing to the Notary operators to test.

Notary operators competitively work together, so when the call comes to test a bug fix, node by node testing occurs. In this case it’s a matter of including a new remote repository and cherry-picking the bug fix.

git remote add decker https://github.com/DeckerSU/SuperNET git fetch decker git cherry-pick 37bbdbe52a5411d42d30a87bab8586fa687a1a86 maybe need to do git cherry-pick --continue pkill -15 iguana

Recompile and restart the iguana process. This bug fix has been included in iguana codebase and cherry-picking no longer required.

On the subject of notary operators & git, Duke Leto (Komodo core dev, dPoW integration consultant & HUSH lead developer) from team chainstrike fixed a bug in git software and has attended a git conference. Which is a nice seg into the next section...

Komodo & Hush developer contribution to upstream zCash

When a project is open source, it’s very easy to “take take take” with no giving back. Komodo is appreciative of the work done, sometimes in collaboration, of both upstream and downstream projects. Through December, Duke Leto has been creating a ZIP (Zcash Improvement Protocol) describing the structure of the wallet.

Here it is: https://github.com/leto/zips/blob/zip400/zip-0400.rst

Note: The KMDLABS discord channel (#kmdlabs) is dedicated to testing innovations, upgrades, new features and is a great way to get the necessary skills and knowledge for being a competent Notary Node operator.

Interested in GUI dApps development? Discord's #cc_gui channel will be where most of the work will take place in the coming weeks.

Thank you Komodo (& ecosystem) developers, what an exciting week!