Technical terminology & concepts in BYTOM: Cheatsheet for Developers & Users

9 min readApr 19, 2019

Knowing BYTOM doesn’t need to be difficult

Getting to experience a whole new Blockchain system & cryptocurrency, among the many others in the market, can be a daunting task. Every system has its own strengths and niches, each one does something differently to stand out from the rest, each one uses its own special terminology. Users can find this overwhelming.

This is also the case for developers, especially ones coming from more traditional, non-blockchain backgrounds, or ones that haven’t been in the space for long. And how can you develop your blockchain project on BYTOM effectively, if you’re not confident with the terminology?

It is for this reason that I’ve gathered a lexicon of BYTOM terminology, a cheatsheet of different terms that will be useful to you, either as a Dev or a User, and would’ve definitely helped me when I started developing on BYTOM! I’ve also tried to include charts & graphs wherever I think they help with the explanation.

We will begin with the more general concepts, and move on to the developer-specific ones.

If you’re in crypto, chances are you’re familiar with Public Key Cryptography (wiki). It forms the security behind most cryptographic systems.

You know the importance of your private key, and that if you lose it or expose it to the public, people can get access to your funds. But you might have also experienced people in BYTOM’s sub-reddit, discord or Telegram channel recommending you to be careful with giving our your root public key or xpub, too. Why is that?

Well first of all, the root keys are your initial Private key and Public key — also called master keys. In reality, your root public key is created using your master private key, so in essence, only your root private key is really important here. Your master public key — again, also known as your xpub — extended public key, is calculated through applying EdDSA- Ed25519 on your SHA512 master private key. More info for nerds, here (wiki)

But why should I also be careful of where I give my xpub? It’s my public key! How else can I receive BTM on my wallet if people don’t know by Public Key?

Remember that BYTOM, as with many other mature and serious cryptocurrency systems, not only respects transparency and security, but also anonymity. If people know of your one and only Master Public Key — xpub, they can keep track of your payments, in-going or out-going. This breaches anonymity.

BYTOM takes care of this by creating secondary (children) public keys. You’ve probably seen the “Create address” button on your BYTOM wallet:

BYTOM allows you to create “chidren”/derived addresses whenever you like, and as with Bitcoin, it is considered good practice to use them only once, then create a new one (whenever someone wants to send you a payment). It is mathematically improbable to run out of new addresses, or hit an existing one.

You are the master of all these children addresses, and you control the funds sent to each and every one of them — however, people cannot see/calculate that the children addresses were derived from your xpub, therefore preserving your anonymity.

Like many other Developer-oriented blockchains, BYTOM allows programmers to write and deploy Smart Contracts onto the chain. Smart Contracts are pieces of script, fully transparent to everyone, that perform conditional operations and transfers on chain assets — much like a user can make a transaction on the BYTOM blockchain, Smart Contracts lock or unlock and transfer assets based on logical arguments.

Smart Contracts are written in the Equity language, a high-level scripting language that is probably also Turing Complete (wiki), but I haven’t bothered to prove it.

Tensority is the Consensus mechanism for BYTOM. It’s the algorithm according to which blockchain participants decide on if a new block is valid or not.

Bitcoin uses its well-known Proof of Work — PoW consensus mechanism, other coins like NEO use dBFT (a subset of Proof of Stake — PoS). BYTOM also uses a specialized PoW algorithm, with a different approach: They want to keep it ASIC-friendly, and promote ecosystemic growth and health. ASIC stands for Application-Specific Integrated Circuit (wiki) and they’re the specialized clusters of processors that do one thing very well (Hashing — “Mining”), and do everything else really inefficiently (unlike your computer’s general-purpose CPU).

For Bitcoin’s PoW, ASICs waste (on purpose) a lot of effort and energy to find correct hashes for blocks, and get rewarded. BYTOM pushes this one step further. What if all that work could also be used for something else, and the ASIC itself needn’t be so weirdly specific?

BYTOM’s Tensority uses Matrix multiplications and transpositions to generate work for its Proof of Work Scheme. You know what other field in Computer Science primarily does Matrix multiplication and transposition calculations, all the time? Artificial Intelligence.

BYTOM’s PoW approach with Tensority seeks to:

Enable hardware acceleration on AI systems through ASIC’s that are simultaneously mining for BYTOM (load sharing or 2-birds-with-1-stone calculations).
Stimulate AI hardware advancement and chip manufacturing in general, as an incentive.
Allow for AI ASICs to be used for PoW calculations, and vice-versa — Thus, reducing fully specialized machine and allowing for a more general, economical approach to PoW.

For the more mathematically inclined among you, BYTOM has released an Academic paper on the specifics of the Tensority algorithm, available on their main site. Don’t worry about the size, the paper itself is about 20 pages long. The rest of the 100 pages are the Data dump appendix, that they had to include in the paper.

BYTOM operates multiple chains. The most well-known one is the main chain, the one you have your BTM on, also called the Mainnet.

For developers wanting to explore and develop, there is a chain that works identically with the main chain, called the Testnet. This is where all of us developers start coding and deploying/trying out our Smart Contracts, before pushing our projects on the Mainnet. BYTOM also operates the GM chain, but I haven’t had a chance to explore that yet.

The Testnet also has a faucet. An automated system that gives you Testnet BTM assets to use for your Smart Contracts, pay your gas costs and play around while developing. They work the same way as Mainnet BTM, but of course, don’t have a monetary value. Faucet is accessible through Blockmeta, direct link here.

This is one of the most misunderstood concepts, and I’ll try to keep my description short. BYTOM’s UTXO model is similar to Bitcoin’s UTXOs.

UTXO stands for Unspent Transaction ( TX) Output. Let’s imagine a simplified Transaction, one of the concepts that you’re probably very familiar with, as a crypto user.

A Transaction has two distinct elements: One Input and one or more Outputs.

Inputs describe where the transferred asset is coming from. Who’s providing it!
Outputs describe where it goes.

Consider the classical “Alice wants to send you some BTM example:

The UTXO “remains” in your control. Your private key can use it, and therefore create a new transaction to spend the 100BTM, whenever you wish. After all, they’re yours.

The example above is oversimplified, but it aims to show you that the UTXO of a transaction is what you control to “use” your funds. Your account probably has multiple UTXOs, one for each incoming transaction of BTM or other BYTOM assets you have received.

The smarter ones among you might have noticed something. Considering the fact that one UTXO becomes Input for a new transaction, then that transaction’s Output becomes Input for another etc etc… And you know that Blocks on the blockchain are bundles of transactions, nothing more… Well, where are the coins themselves?

This is one of the core concepts of the Blockchain, same in BYTOM as it is in Bitcoin. A Blockchain only needs to keep track of transactions. “Coins” don’t really exist, instead they are only data in an endless continuation of valid transaction Inputs and Ouptuts, from one user to the next, then the next etc.. A more complete version of the chart above would be this (for example, in case I wanted to spend 50 of my 100 BTM):

A BYTOM Node is a computer connected to the BYTOM network, actively participating in the BYTOM ecosystem and blockchain.

Running a node means exactly that. When you’ve got your wallet client open, you’re running a node. When you’ve turned mining mode ON in your wallet, you’re participating even more, by actively doing work and trying to find blocks ( see 3. Tensority).

For developers: you can run a node by running bytomd (has a web interface) or bytomcli (strictly console) on your system, available in BYTOM's official GOLANG implementation. Both of these clients will open an API (listening on localhost:9888) and Websockets (endpoints at ws://localhost:9888/websocket-subscribe). You can use the API as an entryway to the BYTOM blockchain, either to get chain information, to create, sign and broadcast transactions, to deploy Smart Contracts, anything you might need.

BYTOM is active and undergoing expansion and development daily. To organize their progress and milestones, as well as to listen to the community’s ideas and criticisms, BYTOM utilizes Improval Proposals (BMIPs) to discuss, brainstorm and finally develop improvements to their protocol.

BMIPs are available on this official repository.

One of BYTOM’s milestones is to utilize multiple parallel blockchains (that may or may not carry the same assets, and may mirror each other in some parts) to share the load of transaction validation and generally balance operations between specialized chains.

BYTOM has begun achieving this milestone, and Vapor is one of their Sidechains.

Your deployed Smart Contracts do not execute on your machine, they run on the BYTOM blockchain through an abstracted decentralized Virtual Machine. When a developer compiles a Smart Contract (before deploying it on the chain), you actually translate your code into Operation Codes (OP_CODES), which means logical instructions for the Virtual Machine.

Without getting too technical here, I believe the misunderstanding of these basic transaction types stems from erroneous translation.

Action type: ISSUE is used primarily to register and create custom assets on the BYTOM blockchain
Action type: SPEND_ACCOUNT, also read as “Spend from account”, acts as Transaction INPUT. As we said before, only one Input per Transaction is allowed, so guess how many SPEND_ACCOUNT actions we can have: One, of course! Also see: UTXOs.
Action type: CONTROL_ADDRESS, also read “Control with address”. This acts as transaction OUTPUT, it specifies who is the new owner/controller of the assets of the transaction. Also see: UTXOs
Action type: RETIRE is used to “destroy” an asset. That means, it just makes it so that the new UTXO for the transaction ALWAYS fails. The assets transfered through this action are now inaccessible forever, and therefore can be considered retired, destroyed.

For example, a simple transaction/transfer of a full-UTXO-spend contains two actions: One Spend, one Control. If you want”spare change”, you need a second Control, back to yourself. You spend the full UTXO, you let the receiver control some, you control the rest. That wasn’t so bad, was it?

You’ve probably seen this a lot when trying to build or sign transactions through the API. The derivation path is the byte value that was used with your xpub (Master public key) to create one of your child public keys (also see Section 1), usually the numerical order of the created address (First created child address has "derivation_path": ["010100000000000000", "0100000000000000"], second one has "derivation_path": ["010100000000000000", "0200000000000000"], etc.

The child public key you need was created by xpub + derivation_path, so to produce a valid signature, you need to specify the correct derivation_path.

Quorum is the number of signatures needed for the transaction to be considered correct. The term “quorum” in a business sense means “the minimum number of people required to make a decision on an issue”. Don’t forget, BYTOM also supports Multi-signature wallets ( X-of-Y signature system, just like Bitcoin). So, a"quorum":1 is a single-signature wallet, more than that is, well, multisig.

Originally published at http://github.com/Agouri/Bluechain/wiki

Technical terminology & concepts in BYTOM: Cheatsheet for Developers & Users

Knowing BYTOM doesn’t need to be difficult

Written by Dimitris Sfounis