The Thought Process behind a Digital Currency for Micro-Transactions.

On the 23rd of April 2019, I set out to create a Digital Currency, inspired by the insurgence of other alternative currencies to Bitcoin but also unlike any other digital currency designed to date, it broke all the conventional norms; allowing instant transactions with no fees in a decentralised manner without a regular consensus model.

Around this time everyone was talking about micro-transactions and for once the Proof-of-Stake (PoS) model of consensus was becoming the popular option, even though for years prior it was rejected for having been no less centralised than any other traditional institution.

I was never a fan of PoS and still, to this day, it’s not an option I would personally be satisfied with. This is because I do not believe in a decentralised system that allocates more power to particular nodes or individuals — even if this was voted upon by the majority of network participants. I truly believe that in any fair decentralised network that everyone should have the same rights, power, stake, or influence, in the overall network and its operations. Regardless of how much value you hold in that network in currency or any other medium.

I also didn’t want to completely re-invent the wheel, I do think that Proof-of-Work (PoW) creates the best model of a truly decentralised system that we have seen to this current date, there may be some power struggles involved still but they are negligible in the ‘grand scheme of things’ such an example would be with the monopolisation of mining pools which have lead to, although few, some double-spend attacks in the past, ref #1, #2 and #3.

Another problem is that PoW is slow, too slow for instant micro-transactions. When you make a transaction on a PoW model like Bitcoin it goes through a series of confirmations, each of these confirmations is how many blocks deep your transaction is in the blockchain. On average the network of miners mines one new block every 10–60 minutes, assuming you included a reasonable transaction fee into your transaction then after 1 hour it could be confirmed ~6 times, meaning your transaction would now be 6 blocks deep in the overall blockchain, a linked list of blocks if you will.

This 𝑥 blocks deep nature of the blockchain is what grants its finalised immutability and complete trust against double-spend attacks, which is the primary concern of any decentralised monetary system.

So tasking myself with the objective to create the fastest and in turn, lightest weight digital currency system targeted at real-time micro-transactions I decided three things would have to happen;

1. The blockchain must be very minimal so that it’s growth over time is significantly reduced, this would not only increase the transaction processing speed of the network but also allow it to exist on hardware with smaller storage capacities, making it more likely for moors-law to keep ahead of the blockchain growth, which essentially proposes that the blockchain could indefinitely remain on mobile devices as storage capacities increase at a faster rate than the blockchain increases, although extremely unlikely it’s a target worth at-least trying to shoot for.
2. Transactions would have to not incur any transaction fee, as each micro-transaction has the potential to be of a very small transaction amount meaning that any standard transaction free on the network would unnecessarily complicate transactions for the end-user and interfere with the nature of the micro-transaction network.
3. Confirmations must be instant.

Compressing down each transaction is the easy part, many other protocols include superfluous attributes to each transaction often for extended or dynamic functionality such as multi-sig, smart contracts, etc.

I would only allow standard transactions, how most people use money, you can send money to one person at a time. Essentially making each blockchain entry <transaction id> <from user> <to user> <amount> <signature> which amounted to 147 bytes, allowing 7,133 transactions to be stored in one megabyte or 7 million transactions in one gigabyte. This is in comparison to Bitcoin which has an average of 496 bytes per transaction based on metrics from charts.bitcoin.com taken on the 13th of March 2021; 310.7 GB total blockchain size divided by 626 million total on chain transactions. That’s 70.4% smaller than the average Bitcoin transaction. In 2019 I calculated the figure to be around 76% smaller than the average bitcoin transaction. The reason for the fluctuation in percentage is that Bitcoin transactions can be of a variable size; on average a Bitcoin transaction is between 470 bytes and 1.7 kilobytes as where in VF Cash every transaction is exactly 147 bytes.

When it came to instant transaction confirmation, I figured that the propagation of each transaction across the entire network had to be as fast as possible and for this reason, I would exclusively use the User Datagram Protocol (UDP) to transmit transactions. I would also limit the maximum size of peers in the network to 3072. (3072 is just a number that seemed sensible to use as of 2019 and I expect this number to increase as networking capabilities and telecommunications infrastructure improves in subsequent years to come, this might seem like a shock to you as 3072 is a relatively small number in networking by today's standards but as you read-on you will begin to grasp why this limit was chosen)

The idea is that when a transaction is made it is instantly broadcast to every peer on the network, and upon each peer receiving the transaction, if the peer had not already processed the transaction it would then repeat that transaction to 3 other online peers on the network, this way if a malicious actor attempted to send different transactions to different peers at the same time, each node would tell each other in a cascading effect to reduce bandwidth, and the majority of the network would almost instantly know about this double-spend attempt. Effectively cancelling all transactions sent from that malicious actor.

To elaborate in more detail;

• As soon as a node receives a transaction it is repeated to 3 random peers that are online; if that node has never seen the transaction before.
• Once the node processes the transaction, if it is found to be valid or a double-spend, the node broadcasts the transaction to the entire network.

So you see the initial reception of a transaction causes a network peer to relay that transaction onto other network peers in a domino-Esque cascade to reduce bandwidth, as this initial stage is marginally less important due to not having verified the quality of the transaction yet, and then once the peer processes the transaction and it is deemed to be valid or a double-spend, it then tells every peer at once. This creates a redundancy of packet loss in the UDP protocol where there once would have had no redundancy at all. There is absolutely no chance a peer will miss a transaction unless it is offline, to which case when it comes back online it will only sync off other verified peers in the network. It’s heavy on network communication per transaction, but it’s mitigated by the use of UDP and it’s an amicable trade-off for security.
(3072 nodes all re-broadcasting a transaction creates 3072 different notifications of the transaction for each node in the network, this may seem like a big number for repetition but in a UDP network this is not so large, once a node has processed the transaction it just bounces any of the excess repetitions; but you can see how this effectively eliminates packet loss)

This brings us to the second mechanism that protects the network from double spends, each unique sender address is only allowed to send one transaction every 3 seconds — this essentially means that the network will consider any other transaction made within a 3 second period as a double-spend attempt and cancel all transactions made from that address made within that 3 second period. This also means that each transaction has a 3 second confirmation period and that the UDP network is expected to propagate each transaction to 3072 nodes within roughly 3 seconds.

This transaction rate limiting has an advantageous side effect of protecting the network from spam, creating a transaction rate limit on the network of one transaction every three seconds per user without introducing any rate-limiting disincentives that regular networks use such as transaction fees.

And in this sense a 3-second delay between each transaction per account on the network is what allowed me to operate my network without any regular consensus protocol such a PoS or PoW, essentially making each of the 3072 nodes completely equal, there are no special case nodes such as miners, every node plays an identical role in the network. This means that it is a truly fair network, albeit an exclusive one in terms of its members — and who would I expect to become one of the exclusive node operators? Big institutions who process transactions for their businesses, as it would be these institutions who would be incentivised to run transaction processing servers for free to maintain their commerce. In that sense, the fee would be a hidden fee included in the prices of the products they were selling, a negligible amount. The right to run a node in the exclusive list is a first-come, first-serve basis and if your server has any downtime for over 3 hours then you lose your place in the network and someone else will take it. The server list in all respect is left to the system of natural selection.

So with all this decided, and many people telling me that my idea was “stupid” I went ahead with it anyway, because although it completely contradicted the norm, I had to see if it would work in practice. No one had ever dared make a network with no transaction fees, and instant confirmations in this manner prior but this is exactly what the growing demand required of the future micro-transaction protocols.

Once I built the network I realised there was one problem however, there was no method of distributing the currency in a decentralised manner and without this, the network was again theoretically under the control of one or a handful of institutions that would have been tasked with distribution the currency — institutions I would have to also trust with large chunks of the currency, which was, problematic for the proposed ecosystem. So I went about thinking of a solution and two weeks later I came up with a simple but effective solution which Cathy Tao coined as “PoK” or Proof-of-Key. This system was simple, but it had some advantages, first of all, it allowed the currency to be mined offline which in turn added the ability to make private transactions — before this, the network had no privacy at all, every transaction was linked to an account and although the order and dates of these transactions could not be easily identified as these details were not explicitly stored, each transaction could be associated to a single account address and traced to an origin. By introducing offline mining, users could find these pre-defined addresses which resembled pre-paid debit cards and then use them in the future at will, these digital pre-paid debit cards would have no transaction history, and for that reason when spent would be completely anonymous. Essentially you are mining ECDSA key pairs, and if the public key falls within some pseudo random distribution then you’ve won one of these pre-paid debit cards. This is secure because you have to generate public keys from private keys and not vice-versa. Thus you can’t predict what private keys you generate will produce a valid pre-paid public key.

The minting difficulty of the digital ‘pre-paid debit cards’ is controlled by anyone who holds VFC, there are two addresses that control the minting difficulty and by paying into either one will offset how easy or hard minting becomes. This minting process is how new currency is introduced into the VF Cash network. So in this respect, the minting difficulty is a decentralised voting system where the power of your vote depends on how much VFC you contributed to that vote. The voting process itself essentially ‘burns’ VFC, taking it out of the overall supply, permanently. This doubles as a good counter weight to inflation of the minting process.

But who do you trust, what if one of the nodes starts to lie, how would we detect a rogue node before it was too late? All of the nodes are expected to run on the same rule-set but even so, a rogue node cannot damage any of the other network nodes, it can only lie to users who connect to it externally, outside of the network via its REST API, so in this sense, identifying a node who is not keeping up with the rest of the network or has turned completely rogue is just a matter of spotting it and terminating it from the network (via a network wide IP block agreed upon between nodes). The network is exclusive, and once a rogue node is terminated its chances of getting back in are unlikely, this exclusivity protects the network. It’s similar to banking today, we have branches that we trust, and if a new branch opens and tells us for example that we have a balance that does not exist in the global financial system, we would not be able to spend that balance outside of that branch as the other branches would bounce the transactions. Scammers will always exist, it can be particularly hard for that very reason for anyone these days who wishes to obtain Bitcoin to do so without becoming victim to a scam. Even in Bitcoin, there are reputable sources to hold, trade, or buy Bitcoin (if you are in the know) known as exchanges, such as Binance and Coinbase. Each institution running a VF Cash node would gain this similar reputability, although unlike with Bitcoin exchanges, a VF Cash node does not hold your account hostage, they cannot cut and run with your money like a Bitcoin exchange can. The main reason a Bitcoin exchange can reserve this power over your Bitcoin is because transactions on the Bitcoin network are incredibly slow to confirm, this process could take the most part of an entire day. Bitcoin exchanges allow users to trade between a number of different digital currencies, most of which have very slow transaction times, in order for Bitcoin exchanges to give users an experience of placing instant trades between currencies you relinquish your currencies to the control of the Bitcoin exchange. You no longer control your currency, you are now at mercy of the exchange you have trusted to look after your currency for you. In a VF Cash network, there is never any need to relinquish control of your currency for more than just a single escrow transaction between two different currencies which would last just a few seconds, so in the case that a node was hacked, the worst that could happen is that any escrows placed during the heist would be taken, but not fulfilled, which users would notice and report immediately, there would be no pots of millions of currency sitting around for the hackers to instantly steal like we have seen so many times in the past of Bitcoin, most recently the Binance heist of 40 million in Bitcoin. Why? Because transactions on the VF Cash network are instant, there is never any need to relinquish your currency to avoid laboriously long transaction delays.

So that’s the thought process of how VF Cash or VFC for short came to be. It is a little known proposal of a digital payments network that could be capable of satisfying a desire for a future where instant micro-transactions between an internet of things is commonplace. I had an interest in the topic, and wanted to give it some thought.

How VF Cash secures against double-spending absolutely hangs upon the ability for all participants in the network to receive transactions in the same time period, and I agree that currently, 3 seconds may seem like cutting it tight somewhat by today’s networking standards. But that is a subject of debate; how often does the average account holder need to send a transaction, once every 10 minutes? Or possibly once every half an hour? The longer the confirmation period, the more secure the VF Cash network becomes. But this is almost synonymous with; the lower the latency between network participants, the more secure shorter confirmation periods become.

VF Cash has been running for almost two years to date and has had no operating issues; it is a stable and robust piece of software that has sadly seen more attempted attacks than genuine adoptive use so far. Yet here we are, VF Cash and its operations remain unperturbed.

If you are interested to learn more about the VF Cash project there is the GitHub page, CoinMarketCap listing, and of-course the main website VFCASH.UK which offers an online wallet and transaction explorer.

This is an idea/concept with a working and stable prototype described in this document. The network may not always exist, but as long as someone is willing to run a node and keep a backup of the public transaction chain/ledger, even if that person is you, then the network and transactions made on it will always exist. Some form of value can be associated with it as the minting of currency is a 1:1 ratio between computer resources required to mint it. Regardless do not trade real money for VF Cash.

VF Cash is not an investment as it is designed to be a depreciative currency. There is no fixed supply, and I have no idea how large the supply could get. There is also no way to measure how much currency has been minted offline.

For this reason VF Cash is not for sale.

But as far as I am aware VF Cash is the only open-source digital payments system written entirely in plain C with minimal use of external code. Additionally, it has fully multi-threaded transaction processing which is capable of a fairly significant real-time throughput.