Une fois n'est pas coutume, this is an up-to-date list of the mobile applications we have built over the years, to test different versions of the Bitdinar mobile wallet.

Please forgive us for the lack of inspiration for some of the designs you will see below.

And of course, none of this could be achieved without our very Belji.  

Summary

By the end of this post you will be familiar with the different iterations of the Bitdinar wallet, as well as the underlying technology or frameworks, on top of which they were built.

For the sake of clarity, we will proceed anti-chronologically.

Taler implementation - 2021

Technical specs:

# Taler Wallet
- Wallet transacting in Kudos
- Protocol: GNU Taler
- Details: Transactions are settled on a central server hosted by the GNU Taler team.
- Currency code: Kudos
- Status: Minimum viable Product

For our latest application version, we have been refactoring the GNU Taler framework, and Belji installed the client software on mobile targets.

Videos

The demonstration consists of a full transaction video, and a Point of Sales view video.

Full Transaction Video

As demonstrated, it is possible to obtain good transactional results with the available stack developed by our friends at GNU Taler.

Alright, alright. We are aware of the quality of the video, but please keep in-mind that the good devices were used for the software itself, and none of us is a professional movie maker.

Payment System - Point of Sale View

In this last video from 2021, we can see the Point of Sales view, where the the cashier might place the orders, or the customer does it directly from an self service point of sales.

Bitdinar Implementation part 2 - 2017

Technical specs

# Bitdinar Wallet
- Wallet transacting in Bitdinar
- Protocol: Bitdinar's proof of work blockchain
- Details: Transactions are settled on a blockchain record hosted by Vink-io team and the Vulpem team.
- Currency code: BTD
- Status: Proof of Concept

During the spring and summer of 2017, we focused with the Vulpem team on a seamless mobile wallet, that embodies the principles of Financial Inclusion in its User Interface.

The motives behind a minimalist approach was to facilitate the usage of digital currency to customers who might not be familiar with smartphones. Not everyone is a Bitcoin Ninja.

Videos

Iteration of the Bitdinar wallet application, running on iPhone 7 and done in June 2017:

Bitdinar mobile wallet

Before this final draft, we have had an earlier Iteration of the Bitdinar(s) wallet application, running on Android, done by April 2017.

Notice that in-between versions, we improved the payment flow, by changing the directions in which the pay/receive button behaves, so it became swipe right to pay, and swipe left to receive.

On a more relaxed note, we were still studying the amount of Bitdinar(s) to include in the logo:

Bitdinars mobile wallet

Vinkoin Implementation - 2017

Technical specs

# Vinkoin Wallet
- Wallet transacting in Vinkoins
- Protocol: Bitcoin colored coins
- Details: Transactions are settled on the Bitcoin blockchain
- Currency code: VNK
- Status: Proof of Concept

This minimal mobile wallet implementation was very interesting, since it relies on the colored coins concept.

It was possible to allocate micro amounts of Bitcoin, and peg them to atomic coins, which were then transmitted on the actual Bitcoin network, when sent between nodes. This would not be viable now, for mutiple reasons, however this technique was a precursor to the actual Lightning Network.

Pictures

Unfortunately we do not have videos of the workflow of this mobile wallet, but we kept a picture with a lot of zeros trailing.

Vinkoin Wallet Specs

This iteration was very fa from being optimal, as we needed toa access the wallet application only via browser, without mentioning the many bugs and failed attempts before getting the Vinkoins right.

However, the underlying principles were here more attractive than usability.

Bitdinar Implementation part 1 - 2016

Finally we get to the original culprit, or the very first implementation of a concept called the Bitdinar.

Technical specs

# Bitdinar Wallet
- Wallet transacting in Bitdinar
- Protocol: Bitdinar's proof of work blockchain
- Details: Transactions are settled on a blockchain record hosted by Vink-io team.
- Currency code: BTND
- Status: Proof of Concept

Technically this is not a mobile wallet application as it comes as binary to set up on a desktop machine, or server. However it is a wallet, that transacts, validates and interacts with mining Bitdinar.

For this very very first iteration of Bitdinar, we have forked a primitive peercoin stack which claimed to provide proof of stake consensus. In truth, it was a bitcoin fork, and we mined the first Bitdinar according to the proof of work.

Pictures

Here too, we just kept a very bad quality image of the first ever Bitdinar mined.

First Bitdinar Mined

This first version helped us understand the dynamics of a crypto-crrency software, and its build dependencies.

The network was composed of 2 machines, one in Berlin and the other one in Tunis. If both machines were off, the network would stall, and if one machine was connected, it was effectively representing 100% of the minimg pool available.

Conclusion

That is the end of this small time travel. During this technical journey we have been able to build software, but most importantly we built, and have been blessed by, a community around the concept of Bitdinar.

This post is an early investigation into the topic of unikernels.

By the end of this entry, you will be able to understand unikernels and the logic behind architecture, before studying the use-case of an application such as Bitdinar, and finally test a small MirageOS webserver implementation.

For a detailed technical description of Pantera OS in its latest stage, it is possible to jump to part 2, where we discuss the Rust implementation.  

Pantera OS

Our software product is the Pantera Operating System, or Pantera OS for short, an exceptionally secure software intended for critical financial operations.

Pantera OS is named after an exceptional animal, the Pantera, to outline its stealth abilities and speed of execution.

To mimic the predator in code, our software proposal is a custom and minimal container, for which internal computation can be tightly restricted, and its exposure to the internet highly limited if not completely disconnected, without affecting its performance.

Critical Security by Design

In this section, we will discuss if a unikernel Operating System satisfies the conditions of security and performance aforementioned, and if it is possible for a unikernel to operate as reliable banking software.

Requirements

Critical infrastructure, as in the banking sector, implies the need for a minimalist architecture, and a better compartmentalization of its critical components. Equally so, a physical bank would be harder to manage if it had non-existent, or extremely complex, security infrastructure.  

To support these propositions, the minimal approach has been adopted by several stacks and Operating Systems such as Qubes OS, to emtnion a single example, so we do not have the burden of reinventing the wheel.

Nevertheless, we have been motivated by such innovations, seeing a substantial benefit for our audience and customers.

We will discuss in the following post such stack, or in other terms the implementation of a Mirage OS virtual machine, to demonstrate the traits that embody at best our development philosophy, and apply it to the container logical component.

For the more technically involved audience, it is possible to read about Mirage OS project here.

Architecture Overview

The overview below provides an idea of how unikernels would fit within the landscape of containers in the wild.

The purpose of this architecture is to expose a reduced attack vector for external attackers, and limit the scope of actions of internal hostile actors, while increasing the intrusion monitoring capacity.

The possibility of using shared memory resources is drastically limited at low level. As we see in the overview, and for a similar application size, unikernels combine the benefits of containerization, with the flexiblity of hypervisor orchestration. Kernel resources (Memory) are not shared, and interactions with the hardware go through the unified hypervisor API, regardless of the kernel in-use.

Such systems can be configured to not include any accessible user interface, e.g. operate headless. However, such modular systems can be adapted to desktop environments. For instance, at User Interface level, like in Qubes OS, the clipboard (copy / paste) workflow is set at a sane but secure mode, where taking files from one container to another requires an additional step.  

More closely into the internals, we can expect an enhanced security as the result of refactoring the necessary software libraries, in a more compact fashion, and in a relatively safer language.

Comparison

For instance, we can proceed to a trivial but visually significant comparison. Let's count the lines of code of the regular Linux Kernel usually written in C and C++, against the Mirage OS kernel written in Ocaml.

For the the Kernel and the Cryptography primitives, we can see below the difference between the regular Linux kernel size, against the size of the Mirage OS implementations:  

(the following numbers are in thousands of lines of code - k LOC)

And if we combine all required components to build a full kernel, we get the following total:

When we combine this programming paradigm, with the safety features of the OCaml language, we can obtain the type safety, gain in performance and reduction in attack surface.

Unikernels

A "Unikernel" Operating System operates as a functioning software container, computing a compact kernel, which runs directly on a hypervisor or hardware without an intervening OS such as Linux or Windows.

I came up with this less-than-scientific definition for the sake of clarity, but the wikipedia entry covers well the topic.

Nevertheless, our commercial objective is to provide our customers with the most relevant custom software stack, that lives on custom hardware, to satisfy strict requirements.

Real World Applications

Pantera OS is intended as a banking Operating System that runs a custom financial logic, while containing its dependencies and its content in a specific layout.  

It can operate as an algorithmic trading engine for a trading firm, or operate as a digital vault (Hardware Security Module) for a bank that requires a Public Key Infrastructure for example.

Our go-to example application will be running the necessary stack, to properly operate the Bitdinar software.

La Poste Tunisienne

Pantera OS can be deployed as the core back-end of a digital bank.

We are refactoring the kernel itself, to interpret the specific business processes of the bank, into algorithmic processes. Specifically, we are refactoring the network stack, to establish secure connections to-and-from the contained kernel.

Under the Hood

To capture a large scope of business requirements, we will assume that our system will need the following objects to function properly:

• Business logic: Custom and off-the-shelf software libraries.
• Cryptographic artifacts, functions and primitives, when intended for key storage.
• Networking logic, when intended to serve files on network.
• Configuration files.

In this context, our system follows a software containment paradigm, as a minimal library unikernel system, by removing all unnecessary components in a modular fashion.

Kernel Application

We will not cover the details of the kernel in this post, as it is still work-in-progress.

However to provide some context, for the following technical demonstration we can assume that access to the container is constrained, and specific kernel components are re-factored for specific needs, upstream at host hypervisor level, and downstream for internal components such as the networking stack.

For this demonstration, we test an implementation of a Mirage OS based webserver, which is a installed and mounted the same way any other kernel application would be.

MirageOS is a library operating system that constructs unikernels for secure, high-performance network applications across a variety of cloud computing and mobile platforms. Mirage OS is a serious contender to become the target stack for Pantera OS

Installation

To download Mirage OS on Debian:

$ sudo apt update
$ sudo apt install opam
$ opam init
$ opam install mirage

By porting our kernel to Mirage OS, we will guarantee that our software is running under restrictive conditions.

For this example, we will use a ported webserver, that runs on a Xen Hypervisor.

Performance

Let us see what gains are expecting in terms of boot process speed.

Here is a comparison between a Mirage Firewall AppVM vs a Minimal-Fedora Firewall AppVM, performed on a Lenovo C1X1 machine running a Xen hypervisor:

• Debian based firewall or sys-firewall

[user@dom0 ~]$ \time -f "Program: %C\nTotal time: %E\nUser Mode (s) %U\nKernel Mode (s) %S\nCPU: %P" qvm-start sys-firewall

Output:

Total time: 0:09.21User 
Mode (s) 0.04
Kernel Mode (s) 0.01
CPU: 0%

Mirage OS based Firewall or mirage-firewall

[user@dom0 ~]$ \time -f "Program: %C\nTotal time: %E\nUser Mode (s) %U\nKernel Mode (s) %S\nCPU: %P" qvm-start mirage-firewall

Output:

Total time: 0:01.71
User Mode (s) 0.05
Kernel Mode (s) 0.00
CPU: 3%

Here we notice a substantial gain in speed in the boot process, from 0:09.21 seconds for the Debian VM, to 0:01.71 seconds for the Mirage OS VM.

In terms of CPU usage, the CPU consumption of the Mirage OS test machine peaks at of 3%, and null % for the other machine.  

Conclusion

Thank you for making so far in the post, hoping it was informative without getting into too much details.

The Mirage OS stack is a serious stack to consider for critical infrastructure. It provides a ground to optimal programming, and provides an infinity of possibilities to satify stricter requirements.  

Stay tuned, for the second part of this post, where we will take another turn and implement a similar approach to compact kernels.

Note: For the fans of generative art, the first picture is the flyer for a Refik Anadol exhibition back in 2018. I chose it because it depicts well the contemplation process.  

Today we are going to talk about our first hardware research project, and I am very glad to introduce to the world Marg0t, a 6502 computer that says "Asslema!"*

A 6502 Computer for Fun and Profit

Marg0t is a hand-made computer built from scratch, and which does very basic operations, i.e. display a hard-coded text on a small screen.

The main purpose of the project is not to build a high performance machine, nor to provide a sophisticated approach to hardware and software programming.

The machine built and programmed serves the purpose of building the most abstract architecture of a computer, in order to understand the fundamentals in a slow but precise manner.

Knowledge Base

To sum up the knowledge base acquired, we will decompose the several sections of the project into hardware and software sections, before laying down the possible applications.

In general terms, building the computer covers a significant array of fields, from setting up the environment, to the choice of the right hardware, besides the programming and mathematical concepts that are covered.

Hardware Components

In the following section, we will cover the main components of the systems which form the core "organs" of the machines, if we wanted to use a medical analogy.

1. Central Processing Unit (CPU):

The central Processing Unit is the equivalent of the brains of the computer. As its name indicates, it is the unit that is tasked to interpret the different instructions, i.e. digital signals, and process them according to the programmer's code.

For Marg0t, the CPU is composed of two hardware components:

1. The W65C02S 8–bit Microprocessor: The current version (from Western Design Center inc.) has a fully static core and officially runs at speeds up to 14 MHz when powered at 5 volts. The Wikipedia page covering the chip provides further information about the chip, its history and features.
2. The W65C22 Versatile Interface Adapter (VIA): As its name indicates, it's a versatile chip, that works well when coupled with the 65C02 microprocessor. In our case, we used it for latching the data from the processor, to the appropriate I/O ports.

2. Read Only Memory (ROM):

The Read Only Memory, is the place where we can store our program, or instructions, so the processor can fetch and execute them.

For our project, we used the 28C256 256K Parallel EEPROM manufactured by Atmel.

EEPROM (also E²PROM) stands for electrically erasable programmable read-only memory, and is a type of non-volatile memory used in computers, integrated in micro-controllers for smart cards and remote keyless systems, and other electronic devices to store relatively small amounts of data, while allowing individual bytes to be erased and reprogrammed.

This specific chip was a lot of fun to play with, since it is the component that is actually programmable, i.e. where the program lives.

I actually had to purchase an additional pair of the chip, as its handling requires removing it, and re-placing it on the bread board, which can easily break the pins.

Optimization:

With the three previous chips, it was possible to display the text on the screen. However the code, written in Machine code and Assembly language, was far from being optimal in terms of performance, and speed of execution (i.e. number of clock cycles to display the message correctly).

For further optimization we needed to build a stack for the CPU, i.e. a form of memory that we can read from, and write-to. The microprocessor has a built-in stack pointer that can find the relevant address of a value, or in other words point to the location of the value in the stack, and use it (or reuse it).

This has the benefit of pushing "redundant" instructions onto the stack, and/or retrieve them if required. In this manner, the code becomes more efficient by using subroutine calls.

3. Random Access Memory (RAM):

As explained above, The Random Access Memory will constitute the stack (or memory), where we will be able to store parts of the code for optimal performance.

Marg0t uses a HM62256B Series chip, which is a CMOS static RAM manufactured by Hitachi, and where it is possible to store 256K bits (or 32K bytes) of data.

4. Time for a Diagram:

In the following schematics, you can see how these components are supposed to be connected with each other:

4. Other components and setup:

Of course, there is a bunch of other components that were necessary to build the computer, and make it function properly. However I will not go through all of these elements in this post.

If we had to mention one single component, it would be the "logic gates", which are the fundamental component of any computer, transistor or chip. In my humble opinion, it is the essence of computing.

Personally, the most fun and educative part of the project was the debugging process, using a logic analyzer, as it was possible to diagnose "in-vivo" the machine, by single-stepping the clock.

For this project, I used 3 different machines:

1. A Debian VM for EEPROM programming.
2. A Raspberry Pi 4 for debugging, and Arduino programming.
3. A Windows machine to follow the tutorials, and listen to music.

Software and Programming Languages

In order to make the computer effectively speak, and display messages, the project covered different software stacks, which are leveraged by different programming languages.

The diagram below gives a fair abstraction of the different levels at which any programming would operate, in order to interact with the hardware.

The diagram itself gives an abstraction of the C programming language, even though we did not use it yet in the project.

Machine code is binary (1's and 0's) code that can be executed directly by the CPU.

Assembly code is plain-text and (somewhat) human read-able source code that mostly has a direct 1:1 analog with machine instructions. This is accomplished using mnemonics for the actual instructions, registers, or other resources. Examples include JMP and MULT for the CPU's jump and multiplication instructions.

Unlike machine code, the CPU does not understand assembly code. You convert assembly code to machine with the use of an assembler or a compiler, though we usually think of compilers in association with high-level programming language that are abstracted further from the CPU instructions.

Building a complete program involves writing source code for the program in either assembly or a higher level language like C++.  

The source code is assembled (for assembly code) or compiled (for higher level languages) to object code, and individual modules are linked together to become the machine code for the final program.

Applications

This section covers the for-profit aspect of the "Project :: Marg0t".

We are still a research and development company, that is focused on financial applications, and state-of-the solutions in this space.

However, given the length of the blog post, I will lightly describe the applications, in which we can use the knowledge acquired.

Customization:

Custom systems are at the core of our value-chain.

"Project :: Marg0t" was built with the intention of being the most abstract form of these systems.

Our scope covers custom operating systems, custom hardware, and the hybrid Systems-on-Chips, which can be comprehended, adapted and developed for the needs of our customers.

Security:

We consider critical systems as the baseline for our products, and we understand the highly exigent requirements in this space.

Marg0t is an abstraction of the novel techniques that are possible to secure critical systems, i.e. trusted execution environments, hardware-assisted cryptography, and embedded system hardening.

Algorithmic trading:

This is my personal favorite application, since it is the space where we can mix and use techniques from the financial, engineering and mathematical realms.

By building Marg0t, I personally learned a lot about computers systems. However, I specifically acquired a more profound knowledge about time-sensitive systems, hardware timing requirements, and software design that relies on hardware to execute time-sensitive operations.  

FIN

At the moment of writing this entry, the "Project :: Marg0t" is still on-going, and I still have to wrap my head around the many topics covered.

I hope you enjoyed reading this blog post, as much as I enjoyed working on it.

Of course, here is a small video of the Marg0t in-action:

*"Asslema!" is a specifically Tunisian word that means "Hello", and in this context it is used as substitute to "Hello World!".

Appendix:

The 65C02 8-bit microprocessor, along with the other components that compose Marg0t, part of the retro programming culture.

The first version of the 65C02 chip, the 6502, was introduced in 1975, and knew an almost immediate success for its affordable price tag of $25, and competitive computation speed.

The 6502 almost single-handedly forced the price of processors to drop, helping launch the personal computer revolution. (Chip Hall of Fame - IEEE)

According to the same article, the chip, and its variants went on to become the main brains of seminal computers like the Apple II, the Commodore 64, and the BBC Micro, not to mention game systems like the Nintendo Entertainment System and the Atari 2600 (also known as the Atari VCS).

The 65C02 chip, still in-production, enjoys a large adoption among hobbyists, and is adopted in commercial embedded systems.