105
The goal was to build a complete new python blockchain codebase with simplicity in mind. The protocol design structure should be as simple as possible (keep it simple strategy). New developers can have an effortless entry access to the protocol. On May 1st in 2017 the first Proof-of-Work block has been generated. Realizing the need for custom node features while not pushing these features to uninvolved nodes introduced a plugin system which optionally extends main chain.
Fair Launch
The Bismuth blockchain had no initial coin offering, no pre-mining, no pre-launch and no air-drops.
Hypernode Side-chain
The hypernode (Proof-of-Stake) side-chain was launched in August 2018 and is observing the main chain, accumulating Key Performance Indicators within the hypernode chain. The main chain and the hypernode chain operate in an almost independent way, with a different rule set.
The current total supply is ca. 30,420,000 BIS. In the year 2030, the total supply will be ca. 48 million Bismuth and after block 7,100,000, 2% tail emission.
Chain Security
The Bismuth blockchain uses a feedback control strategy to calculate the difficulty adjustment in the mining process of each block. In combination with this feedback controller Bismuth uses the longest chain rule to determine consensus.
Multiple address schemes
In July 2019 Bismuth introduced the support for several cryptographic primitives, ECDSA, Ed25519 and RSA.
BIS transfer transactions
Sending BIS transaction from one user to another. Users can add a message to the transaction. Prepending the message by "msg=" will mark the transaction as a message for client apps. Without "msg=", the transaction will be shown as a normal tx, but the message is still visible in openfield
Example transaction.
block_height, // (int) block # of the matching transaction
timestamp, // (str, .2f) timestamp of the transaction
from, // (str) sarah's address
to, // (str) John's address
amount, // (str, .8f) 10.00000000
signature, // (str) signature of the tx by Sarah
pubkey, // (str) public keykey of Sarah
blockhash, // (str) hash of the block, hex format, 56 hex chars
fees, // (str, .8f) 0.01000000
reward // (str, .8f) 0.00000000
operation // (str, max 30 char) - Empty for regular tx
openfield // (str) extra data field, can be used as Message - Example: My 10 BIS to John.
Abstract Transactions
The Bismuth protocol allows abstract transactions. These are 0 BIS transactions, and data that is only understandable by the dApps which participate in that protocol. The "operation" field is used as a "command" operator. The convention is to use strings formatted as ”class:operation” to allow for easy classification, like a namespace. The "data" field then holds the associated (short) data. Developers can define their own operations, but have to make sure that their protocol does not use already used namespaces.
Example abstract transaction
block_height, // (int) block # of the matching transaction
timestamp, // (str, .2f) timestamp of the transaction
from, // (str) sender - hex format, 56 hex chars
to, // (str) recipient - hex format, 56 hex chars
amount, // (str, .8f) Usually 0.00000000 but could be used as part of the protocol. Not advised though.
signature, // (str) signature of the tx
pubkey, // (str) public keykey of the sender, base64 encoded
blockhash, // (str) hash of the block, hex format, 56 hex chars
fees, // (str, .8f) fees for that tx
reward // (str, .8f) 0.00000000
operation // (str, max 30 char) - A selector for that abstract transaction
openfield // (str) extra data field
Coinbase Transactions
A COINBASE transaction is the last transaction of every block. It's created by the miner who found a nonce with the matching difficulty and forged that block. The coinbase transaction can be selected by "reward > 0" and may be used to get a block's timestamp.
Bismuth Pillars
Bismuth stands on three pillars that differentiate it from other crypto-currencies.
1. The Real World Principle
Some chains live in an idealist world where everything can be made perfect, where code fixes everything and users are experts able to understand complex algorithms, their bug free implementation, compile from source, then make no error using the tool. The solutions designed in that spirit are bound to fail because they ignore the real world, real users, and use case of the tool. The inter- faces with the real world (users, oracles, network) are not perfect, and Bismuth has to account for that.
There is no need to design a super complex algorithm which ensures a consensus to reach immutability when what it secures is not fail free. The complexity of the code should reflect the real world use case. As an example, Bismuth does not use transaction hashes. The block hash verifies all the transactions contained in it.
2. Need to store
Because of the real world principle, some data needs to be stored in the chain. Users do not need to use tricks to do that like they do with BTC or ETH. Some things just HAVE to be stored on chain, let’s not try to hide that, and ease the user’s job. Bismuth supports by default two abstract fields - operation and data - users can leverage to build any protocol, however complex, on top, while keeping a good level of performance.
However, storing everything on chain because, we have a chain, is kind of the hammer problem: if all you have is a hammer, you see every problem as a nail. That is why some cryptocurrencies are so focused on scalability issues: they want to store everything on chain, and it is just too much. Bismuth’s philosophy is to store only what needs to be stored on the main chain, and no more. Still, following the real world principle, on chain storage is not strongly discouraged.
Scalability is an application design issue. By ensuring you store only what needs to be, you avoid - from the start - many scalability and long term issues. Why store full documents for proof when you can store only their hash? Store proofs instead of data. Use checkpoints, signatures, fingerprints.
Bismuth also aims to provide a practical framework to store more aside the chain, while still benefiting from the chain safety.
3. Clear line of trust
Cryptocurrencies often define themselves as ”trustless”. This is ignoring the real world principle.
What is stored in a chain is not necessarily ”true”. It is just supposed to be immutable once stored, and requires some hidden trust anyway: in the code, in the bootstrapped data, in the underlying algorithm, in majority of other peers, in service providers. On-chain contracts are not magical, they are not perfect. They can have bugs, the virtual machine (VM) can change, they rely on oracles, you still have to trust but you do not always know what or who you trust.
Bismuth does not try to hide the fact that you sometimes have to trust, and we try to make that clear. When you use a private bis contract like Zircodice or Dragginator for instance, you trust its operator. You still can have a history of the transactions and verify that the operator did what he was supposed to.
The Bismuth execution model and abstract protocols also go in that direction. Not only you know what you have to trust, but you can choose who you trust. In the case of a protocol, you can freely choose the implementation you trust the more, the certifier that suits you, and so on. It is not some magical immutable contract stored on chain, with possible bugs, proxies, backdoors and no way of fixing when it goes wrong.
In other words ”clear line of trust” means that when you have to trust something or someone, you know what/who you have to trust. Bismuth is not presented as trustless, whereas you implicitly trust several layers and people.
Bismuth Value proposal
The Bismuth value proposition can be summarized as follows:
• Lightweight: The node is lightweight and does not require a powerful CPU and a lot of RAM.
• Perfect fit for developers, scholars and academics.
• The codebase is quick to handle and develop upon.
• Allows for fast prototyping of use cases.
• Easy to tweak and experiment on
• Multiple access layers and clients API in several languages are available.
Bismuth is tailored for developers:
• Use of python means it is largely accessible to an ever growing base of developers.
• Python is currently the language of choice for universities, students, academics, data and machine learning scientists.
• Python does not need time consuming compilation steps. Tweak and test.
• Bismuth allows for interaction at many levels of its infrastructure, from direct DB access - pure SQL - to API clients in several languages.
• Bismuth node comes with hooks and filters, allowing for easy to write plugins, in pure python code - no new language to learn.
• Bismuth Wallet also comes with pluggable crystals, so dApps can be seamlessly integrated in the wallet.
• Bismuth Abstract transaction model and protocols allow for virtually any application to be run on top of Bismuth.
