Cryptocurrencies as Money

A free economy can be compared to statistical physics. There are many actors. Independent comparisons, information processing, produce local transactions, but level out into a collective valuation, collective prices, until a global market establishes in time (more or less stable) and space (over countries, continents and the planet), until the number of transaction are maximal, i.e. fulfill all needs in all remote corners of the planet. Maximum entropy is maximum information (processing) is maximum energy consumption. Limits/setbacks of growth are reached with energy limitation/exhaustion, but new sources, automation and finally AI help out.

Cryptocurrencies (short crypto, fungible and non-fungible tokens) are a very accessible interface and infrastructure for the bookkeeping of real assets by humans and/or trading bots. Cryptos can be the money of the future. What is missing yet, is the widespread adoption, which would make valuation statistical and thus stable.

Introduction

If you have a key to a lock (of a house), then you have access (to the house). The same key-lock principle is behind the private-public cryptographic key. Instead of a physical key-lock we deal with two sequences of bytes.

• The private part is the "key"
• The public part is the "lock" (but normally called "address")

In ECDSA keys, the public key can be generated from the private key. So by "key" mostly the private part is meant.

Having the key gives you ownership. Locks can be combined to produce shared ownership, where more keys are needed to unlock.

In general a token is a hash of some data. The hash of the public key(s) states ownership, either of an addable number (fungible) or of another token (non-fungible). The ownership can be redeemed using the private key(s), by creating a signature, that can be checked against the public key and thus verified by everybody.

In general a transaction has more inputs and more outputs.

Each node in the network has its own interpreter to check the signatures and do other tasks like executing smart contracts. This applies to EVM (Ethereum Virtual Machine), but also to bitcoin and its forks, like bitcoin-cash,

The private keys are stored in wallets. The wallet also cares to make new keys (HD Wallets).

The unspent transaction output (UTXO, Coin) is first created as the first transaction of a block (coinbase), as reward for mining the block. This numeric value is kept limited by network consensus thus can be used to temporarily replace other limited assets, i.e. it can function as money, as long as the network is online. To keep the network running, nodes are motivated to join and stay by block reward and fees.

A small change in data, and the hash is completely different. The network of miners accepts only blocks with a hash less than a certain number (difficulty). For that only (all) values nonce number is tried.

The difficulty avoids that one can provide all the blocks and thus have control over a chain.

Blocks are chained together by the previous block hash (hashPrevBlock). The blockchain forms a public decentralized ledger, secure, because it cannot be changed unless one is able to redo the difficulty of all blocks following the changed one and overtake the network.

The network nodes check that the difficulty is met and wouldn't accept a block otherwise. Nodes build on the longest chain.

The difficulty is adjusted regularly (every 14 days or $14*24*6 = 2016$ blocks for bitcoin) such that the network can produce no more than about one block per 10 minutes.

Money is a collective product. The consensus rules and validation are a collective product. The joint usage of the network are a collective product. Together they make a collective value, they make money (= fiat money).

Time = Value = Transaction

Value can mean:

• an element of a variable: most elementary
• a number: mostly the result of counting values in variables (information)
• human valuation/pricing: this considers human needs
• ethical value: considering human needs, but eluding pricing

The values of a variable are exclusive. The value implies the variable.

The values of the variable must occur for a variable to exist. Selection of values of the variable cycles. Every value takes time or better is a time step of the variable. One cycle is one variable, is one time.

Every variable is also an independent time.

Information is the number of values of a variable. As such information is a quantity characterizing a variable, not a value. But since variables are values for higher level, the information (extension) is an extensive value. It motivates addition and ultimately all other operations.

Most values consist of internal variables. Internal communication produces inertia, because a level has a more or less fixed speed of communication, with a maximum speed for the lowest level.

When one variable separates into more independent variables they also form independent times. The variables get out of sync without communication.

Independent times make their value combinations random. Such a system of independent variables forms an exponential number of value combinations. If $S$ is the number of identical and independent variables of size $n$, $n^S$ is the number of value combinations.

The information speed comes into play when comparing to another variable. Information/Information = time/time = information/time = energy (see earlier blog). While information is conserved, energy is not. The information stays constant even if it spreads to more variables, in the same level or vertically in the hierarchy. $pV = ST + U$ becomes $pV=ST$, if the internal information (energy) $U$ is ignored, because locked up, anyway, i.e. not spreading vertically.

A transaction is the movement of a packet to new coordinates (value = location = selection = owner). In physics, the packet is internal physical information, internal variables/times. In human economy, it is valuated/priced considering human needs. The transactions by themselves form values, a variable, in the observed level. The packet is transacted based on a price agreement. As the transaction is also with information/price (food, gas, fee, VAT), the internal value of the packet (rest mass) is lower.

• Physics: For a variable to exist, the values must occur.
• Economics: For a valuation/price to exist and persist, transactions must occur.

Note

• A transaction is a time step of economy and it has a price.
• Transactions are needed to maintain value.
• The transactions of a product represent a cycle, a variable.
• A product has inner cycles (those of components).
• Products of higher level move slower and have a higher price (mass).
• The economic pricing hierarchy builds on top of basic living cost.

Money, Pricing

In human economics, transaction of physical resources are associated with a (numerical) value through the valuation/pricing process, that takes into account the demand/need of a resource and their limited availability specific to a person or a group of people.

Valuation of a product is a comparison with other products. If one person would do that, it would create its own valuation scale. The major products an individual compares to are due to its basic needs: food, housing, clothing, ... To compare, the person simulates having the product. A product needs to be personally used to have personal value. As the person has limited time values (.e.g seconds per life), a person's total valuation is limited.

Individuals averaged over a large population, or better a large number of transactions, produces money.

We don't use gold coins any more, we are on the verge of not using paper bills any more, either. We are left with only numbers. But the numbers have a value through the trust in each other that they will redeem the number with same valuation. Like, if you helped me for a day, I give you a bill or text you a message, which remembers you, that I Owe yoU (IOU) a day of help, too.

We collect such IOU's, so we don't need to stash food ourselves, because others do it for us. We can redeem our IOU's, when we are hungry.

Money is collective trust in the promises made by others, by the society. The valuation of money rises and falls with honorable and trustworthy behavior.

Valuation varies between people, space and time. Traders calculate with the valuation of other people, and especially use the valuation differences between people (arbitrage). In order to exploit the valuation difference, the trader relies on secrecy:

• that the valuation of one party stays unknown to the other party and
• that the calculations leading to the price offered by the trader stays secret

Secrecy and trust do not go well together,

• Valuation differences, i.e. lucrative business ideas, do not stay secret long, but attract competitors.
• Companies are short-lived, if their products that don't live up to the promises.
• Outright lies, fake it till you make it, regularly lead to gigantic crashes in the finances.

Secrecy exists, but it does actually not matter so much. Even without it there is division of labor (including mental work) due to the expertise necessary and the limited time of one to do all alone. Sharing information without limit, nowadays so easy, boosts the economy.

Traders are like Maxwell demons, like are biological cells, plants, herbivores, carnivores, ..., farmers, traders, engineers, businessmen, investors, ... They all process information in a successively higher level, and can have a positive energy balance from it. Energy is information/time, the higher the level, the slower. But the information packets matter. A scientist has a long curriculum on its shoulder, like a complex protein has a long chemical pathway.

An important criterion in valuation is the marginal profit/loss ($MP = MR-MC$), i.e. profit change by one more/less customer, product or whatever other unit, because it tells in which direction to go to maximize profit.

All this comparison in an economy creates stable prices (more global prices in space as well as time).

The collective comparison produces a common currency. Although just a number, that currency is limited, because also input channels, e.g. via work, is compared to the same scale.

Pricing is not solely based on calculations or statistics, though. Also power hierarchies or human relations play a role. Sometimes prices can even be dictated.

Comparing is work and many people don't spend too much effort on it, also because the effort very quickly surpasses the value of the product. Sharing information, the rating of other people, reduces the effort considerably.

The scarcity (limited supply and demand) is an essential feature of money, just like of every other product.

Scarcity could be named stability of valuation in a statistical sense. It does not refer to one person or one product. It does not mean that an individual should suffer of scarcity. It just means that sudden collective changes of valuation through a change in trust or supply and demand brings some disruption, with winners and losers, and needs time to stabilize again.

For a (stable) valuation there need to be (many) transactions. Transactions need consensus of more people to use the currency. The currency needs to be well distributed over a large basis of users to maximize transactions.

Money, despite varying prices, still represents real resources. In accounting, the real resources are assets, while the money is equity+liability. Assets = money. But it is a local assumption, because the pricing changes. There need to be regular currency adaptations.

The price can change because of more demand of a real resource (assets), but it can also change because the money supply changes.

A sudden change in money supply will change the demand on assets, which will change their prices. The same happens when the asset supply changes. Also both supplies can change. After one-sided changes it takes some time for prices to stabilize again.

If a money supply change reflects the resource/asset supply change, then the price stays stable.

Often there is one currency but many assets. But more generally there are different types of assets, as well as different types of currencies. One can make a currency per product. The currencies have their exchange rates. To compare, one needs to convert to one currency (valuation/pricing). One common currency stays relatively stable, because averaged over many transactions.

A countries legal tender is kept stable by adapting the supply,

• either by issuing new money or
• by buying up money of its currency

A central organization has control by issuing or withholding money. The control is exerted via parameters like interest rate. More money will be issued,

• if the central bank interest is low
• if the state's public spending is high

It is not just the political authority that control the money supply. Basically, those who own, do control. So centrally owned money means central control of money supply, and so indirectly central control of average pricing of products, i.e. the inflation.

General inflation is not just due to money supply, but also by the change in pricing of important products, which are ingredients of a large portion of all products, like energy and work force.

• by central pricing agreements like that for work force
• by change of taxes
• by a change in supply, e.g. by deciding to get out of fossil energy supply
• by a change in demand

Every product is its own currency. A currency is a product like every other. But a central currency is a special product, because it is more centrally controlled than any other product.

Central control would need a lot of information to make a good control. Normally central control is associated with inadequate reaction to changes.

A transaction needs a compromise between the parties. First, the compromise was quite local to a transaction and was done through bargaining. But with more bookkeeping and calculations, larger chains of transactions are taken into account. They lead to narrower price ranges of buyers and sellers. Transactions happen if the price ranges overlap. The bookkeeping and other kind of communication over space and time, like collective price agreements or dictation, make prices more global in space and time, i.e. more stable.

Many local independent decisions normally produce a better stable result via the law of large numbers than by central control. A globally used independent, not centrally controlled, exchange currency would become stable after some time and stay stable unless disruptive events occur.

Note

• A currency is like every product.
• Transactions (supply and demand) are needed for valuation/pricing, of money as well as of real assets.
• Difference in valuation above fee produce transactions.
• Many transactions produce a stable currency in the absense of disruption.

Traditional Money Compared to Crypto

Crypto has all the qualities of traditional money:

• the paper bill number corresponds to a crypto key hash (number), but that bill/number is just the carrier of value and can be exchanged by another paper bill or crypto key (fungible)
• like the paper bill, a crypto-key has a value associated to it
• instead of putting the bill into your physical wallet, you put the crypto key into a digital wallet
• the crypto key is the record of your belonging, like the paper bill you own
• Your physical wallet or your bank account is your bookkeeping, just like the digital wallet is your bookkeeping. The wallet is like an account.

The role of money is to allow bookkeeping.

But for global/long-term bookkeeping, money needs to be stable, else one better considers it as an asset, a product.

Since crypto is not widely adopted yet, it is unstable, because not averaged over a large number of diverse transactions.

Wide adoption needs and produces stability.

Currently crypto is better considered an asset, like a physical product or like shares on a company.

Governments regard a crypto as an asset, like shares.

Shares do get quite independent from the company that issued them. Their price is rather dominated by supply and demand. Only occasionally good or bad news from the company change the behavior of traders. If the link to the company is removed then we basically are equivalent to a crypto, meaning that then both have no links to real assets other then through the valuation via supply and demand.

On the other hand many cryptos are driven by ads and influencers, with a company behind it that organizes that, and also controls the consensus centrally. This is very much like traditional shares.

Cryptos can replace traditional shares: Instead of issuing shares, a company can issue a crypto to finance itself.

• The manufacturer can have its own fungible token to express the market valuation (EIP-20) of its products.
• Or every product item can get its own non-fungible token (NFT, EIP-721, deed). It does not matter how the token is generated. It points to metadata via tokenURI that has more asset information. Ownership is not encoded in the token hash, but with separate addresses, like for fungible tokens.

Market

Market cap(italization) is coin supply times current price of one coin with respect to a FIAT currency.

Cryptos can be bought and sold in exchanges or privately.

The crypto's exchange rate, i.e. its price, depends on the limited supply and demand.

For the demand it must satisfy needs.

• Provide a money infrastructure easily usable via smartphones (or other computers)
• Keep the coin supply limited
• Serve as an exchange currency between other currencies over time or space
• Represent bookkeeping, possibly local for a product or a company
• Trade and exploit valuation differences

For supply, block reward and fee keep the network running:

• Crypto is created as reward for mining blocks: The coinbase is the first transaction of a block and it creates new output without input, i.e. new coin.
• The output can be sold for other currencies, which gives the coin a price.
• Transaction within the network do have a fee to account for the physical resources involved (electricity, computers) to reward the block miner and to avoid DoS attacks.
• Fee burning reduces the supply more, when demand is more, thus working against inflation, and possibly producing deflation.
• Buy back and burn by sending to an unusable address, is also used to reduce the supply.

All cryptos fulfill basically the same goal. That some are valued more than others is to some extend irrational speculation, to some extend limited support from wallets and crypto exchanges, to some extend lack of trust.

Currently, speculation is the major motive. This leads to unstable coins, if there are only big players, because big players decide slowly and keep a trend going, trying to drag others along and win from their movements. There are not enough independent actors to keep the coin stable.

A crypto cannot produce coin forever,

• because computers work with limited width numbers
• because any real resource is also limited
• because a unique consensus does not cover all needs
• because for scalability more networks are more efficient

Bitcoin, for example, reduces block subsidy gradually to 0. The assumption is that fee and valuation can keep the nodes online.

Scalability

The independent movements of a large population to fulfill their daily needs would make a crypto stable. That is the case for large fiat currencies.

No current crypto currency network can process that many transactions, therefore they rise the fee to keep away the masses.

Ethereum can process around 7-15 transactions per second, Bitcoin around 3-7. Second layer networks like Lightning for Bitcoin and Raiden for Ethereum, or sharding (partitioning of the database) are efforts to increase scalability, maintaining security and decentralization.

Second-layer networks reduce fees, because some communication is done off-chain.

Bitcoin has about 13000 listening nodes. A high node count produces more load for transactions, because every node needs to process them.

The fee is an important criterion to choose a crypto.

Exponential growth is a consequence of independent times/actors (Boltzmann statistics). Current exponential fees make the fee market "exponential-exponential". The fee rate should be constant. A fee competition between cryptos can help. But there is also the network competition for more hash power that asks for more reward.

Many different cryptos can be a remedy to the scalability problem. Each crypto can represent a local usage (can even be pegged to a local asset). The coins stabilize each other by exchange sites. Some exchange sites have a site-specific exchange coin as intermediary.

Trading bots can exploit valuation differences of various cryptos, level them out and thus produce a stable coin that can work as money.

Trust

A currency is an IOU. The amount of currency a person possesses, is a promise of society to redeem later with same assets.

A currency is stable if people trust in it, and they trust in it if it is stable.

You cannot trust anybody but the statistics of large number.

Individual decisions should not be made due to currency value, because it ruins statistics.

A Currency must be stable.

• A deflationary currency is bad, because it postpones transactions, and loses the link to real economy
• An inflationary currency is bad, because it prevents long-term planning.

Large fiat currencies are rather stable through the sheer amount of transactions. Stablecoin is normally pegged to to important fiat currencies like the Dollar (Tether), Euro or Yen.

Cryptos need to be trustworthy

• the network needs to be reliable and stay online all the time
• the link to real assets (NFT) must be correct
• The way programming decisions are made, whether centralized or via enhancement proposal publicly scrutinized

Trading Bot

Stability is relative, though. Just as intermediary to an exchange, a short term stability is already enough. A bot can quickly react on changes, exploit them and produce stability, for people to use.

For a valuation to be stable its supply must change according to its demand. The bot can swap falling cryptos with rising ones, leveling them out. This swapping is the result of many bots buying low and selling high, but for them small amounts already matter.

Note

speculation on trends

The principle of speculation is to act before others and gain from others.

If one is first to buy in an upward trend, and first to sell in a downward trend, one earns most. If one is first in the game, one earns most.

• By convincing others their behavior is a result and thus is of course later.
• Otherwise one observes and anticipates the actions of others before they actually happen. Predictable behavior is always losing in speculation.

Buy when price is minimum, sell when price is maximum.

With slow competition:

• buy, when the price starts to increase and
• sell, when it starts to decrease

But, with fast competition, a minimum in local time, is already beyond the minimum, when the exchange serializes independent requests. Then

• buying, when the price falls and
• sell when the price rises

Fast bot competition produces so small and fast vibrations that the currency seems stable for the human eye.

Let's envision a future time where every person has its own avatar bot and their are additional bots in several levels. The ultimate demand is from humans, though. The avatar must see the human demand. For that, currencies must be pegged to real assets.

• Let's assume a currency pegged to a local electricity power station (LOCTRO).
• The demand increases locally in space and time, due to cold weather and electric heating.
• The power station decides to increase the price of LOCTRO to gain on the demand.
• A local consumer bot on electricity (BOTTRO) sees changes in LOCTRO. It exchanges LOCTRO for FARTRO (farther away power station).
• The bot is fast and humans will actually see no change in price in BOTTRO. BOTTRO is a stable mix.
• When all use more electricity, because suddenly everybody charges its electric car, a personal consumption avatar can swap BOTTRO's for other cryptos, telling the person to reduce electricity consumption, to use the bike instead of the EV.
• Investors see BOTTRO increase, such that a larger local investments makes sense. They build a new power station and power storage.
• After the investment has been payed off, competition makes BOTTRO fall and become stable again.

Bots can help stabilize local changes. Speculative human changes are local changes. Bots can help to merge the many cryptos into a stable global money.

Note

• The role of money is to allow bookkeeping.
• A crypto is like money, but the public ledger/network brings along the full infrastructure for bookkeeping.
• More cryptos with (automatic) trading between them are a remedy to the scalability problem.

DEFI and DAO

DEFI: decentralized finance

DAO: decentralized autonomous organization

Cryptos are public ledgers. This does not yet make them decentralized finance, if the consensus rules are centrally dictated. Rather it also needs organizational decentralization that distribute control over the programming of the consensus rules.

The ledger only records transactions. For transactions to increase and become statistical the coin must be distributed. Only in combination with fair organizational rules, that care for a good distribution, transactions and thus valuation of the coin becomes decentralized.

Decentralized finance usually just refers to the public ledger, and the avoidance of a third person in transactions via smart contracts. It does not refer to a fair distribution. For fair distribution the participants in transactions must care for fairness. Fairness is an ethical value of humans, but often cannot unfold due to lack of information, centrally imposed to keep the advantage and power.

The distribution of information is the first step to fairness. The following crypto properties help towards fairness:

• The ledger is public.
• Smart contracts are programmed and can be reviewed before adoption.
• Neither can be modified afterwards.
• Smart contracts can be done without the need to trust a third party.

Extra fairness effort on top of the public ledger is still needed, though. The DAO needs its own purpose, its own constitution, local consensus rules, The data for a specific DAO needs to be made conveniently manageable for its members according to the DAO's constitution.

Bitcoin is a public ledger, but it is yet mostly used by rich people that have money to speculate on ups and downs of its exchange rate. The bitcoin capital is in the hands of a few and therefore not stable.

Everything develops by proposal and acceptance/adoption. So someone needs to (centrally) develop a proposition. If others accept the proposal a consensus has been reached.

A new crypto/blockchain/DAO needs someone to start it. If it gets adopted a consensus has been reached.

But people should also verify that the further governance is decentralized else their investment is laid into the hands of a few, which is not decentralized finance any more.

Source Code

bitcoin-core was the first and is now reference implementation to many forks. The forks, like bitcoin-cash-node, share much code with bitcoin-core and regularly take over changes from bitcoin-core.

Here some central identifiers. Initial v means vector, i.e. many:

CBlock(Header): vtx (nVersion hashPrevBlock hashMerkleRoot nTime nBits nNonce)
CTransaction: vin vout nVersion nLockTime hash
CTxIn: prevout scriptSig nSequence
CTxOut: nValue scriptPubKey
COutPoint: txid n
CChain: vChain of CBlockIndex
CScriptCheck: scriptPubKey amount ptxTo nIn nFlags cacheStore txdata pTxLimitSigChecks pBlockLimitSigChecks
CTxMemPool: mapTx
CConnMan: vNodes
CNode: hSocket, vRecvMsg

Note

hash

Hashes are used for

• transactions (txid)
• public key (Pay-to-PubKey Hash = P2PKH)
• signatures (content according SigHashType + private key)
• blocks (hashPrevBlock)
• proof-of-work (POW): find a nonce that makes the block hash smaller than nBits

While POW's smaller-than task is hard, finding the data exactly hashing to a given hash is almost impossible. Hashing is a trapdoor.

Node

A bitcoin node is a bitcoind daemon running on a computer. Each node is its own time. Parallel times means parallel independent information.

To manage to maintain the consistency of many transactions, transactions are divided into blocks.

A mining node creates blocks (CBlock) that are filled with transactions (vtx) from the mempool of transactions (addTxs). The block is like a page in a ledger.

To make a common ledger, a common time, more mining nodes need to find a way to choose, who contributes the next block with transactions to the chain.

The first mining node that fulfills the proof-of-work, adds a block to to the longest chain. The frequency of blocks is controlled by the difficulty.

CBlockHeader::hashPrevBlock of each block fixes content of the previous block, because changing the content would produce a different hash that would not fit any more to hashPrevBlock of the next block. The hash brings the blocks into a sequence, a chain (vChain).

This ledger is replicated in all full nodes.

CBlock is derived from CBlockHeader and contains the transactions (vtx).

The hashPrevBlock that fulfills the nBits difficulty is based on data in the header (hashMerkleRoot, nTime, nNonce). The transactions are included in the hash indirectly via the hashMerkleRoot field.

The block chain is like its own time. The many different times of all the nodes create one common time.

The result of hashing is random. To find hashPrevBlock that meets the difficulty the hashes per second matter. Whether they are achieved in parallel or sequentially does not matter. This way many slow machines can be as fast as one fast machine. The fastest machine must not be more than 50% of the hash frequency of the whole network, else that fast machine could tamper with a block and then rebuild the chain and produce a longest chain, that would be accepted by the network.

Network

The network has a documented protocol.

Nodes in the network are characterized by permission flags like PF_MEMPOOL,...

The nodes exchange NetMsgType messages:

CConnMan::ThreadMessageHandler
    PeerLogicValidation::ProcessMessages
        ::ProcessMessage
            ::RelayTransaction
            ::ProcessGetData
            ::Process...
                CInv//ventory

A PeerLogicValidation implements the NetEventsInterface interface with SendMessages and ProcessMessages.

Only full mining nodes create new blocks. They need and others can fetch all accumulated unconfirmed transactions (NetMsgType::MEMPOOL/[GET]BLOCKTXN). Other nodes RelayTransaction one-by-one (NetMsgType::TX), so after some time all nodes will have all relevant transactions.

CInv types correspond to NetMsgType commands:

MSG_TX: NetMsgType::TX
MSG_BLOCK: NetMsgType::BLOCK
MSG_FILTERED_BLOCK: NetMsgType::MERKLEBLOCK
MSG_CMPCT_BLOCK: NetMsgType::CMPCTBLOCK
MSG_DOUBLESPENDPROOF: NetMsgType::DSPROOF

Each node constantly communicates with other nodes:

• connman->PushMessage(pfrom, msgMaker.Make(NetMsgType::TX, ...)), ...
• ProcessMessage according to the protocol, especially:
  • fetch new blocks and determine ChainActive (longest chain) (ActivateBestChain/FindMostWorkChain)
  • fetch new transactions as they need to be in the block before the block hash is created

ZeroMQ or zmq is an additional optional protocol to broadcast transactions and blocks.

Transactions

Each of the transactions vtx in a CBlock have

• many inputs (vin)
• many outputs (vout)

A transaction can

• split the vin[i] to more vout[j], to take only part of a vout[n].nValue addressed by vin[i] and keep the rest via one's own change address, or it can
• combine more vin[i] (previous vout[k].nValue) to one new vout[j].nValue.
• or mix otherwise

vin is the n'th vout of another transaction (txid), referenced via prevout:COutPoint{txid;n}.

The unspent coin is important for validation.

cacheCoins:CCoinsMap is a map from vin[m].prevout to Coin{TxOut{nValue,scriptPubKey}} (CCoinsViewCache::FetchCoin()). This map is also stored in a leveldb .lvl database (CDBWrapper). The CBlockTreeDB is also stored in a leveldb database.

The Coin can be fetched from a CTxMemPool with mempool.get(txid).vout[n]. mempool holds enough transactions to check yet unstable blocks (COINBASE_MATURITY) against double spending.

Older transactions are secured in blocks by hashPrevBlock. Many blocks are serialized into one .blk file.

The sum of all vout[].nValue, i.e. GetValueOut(), minus the sum of all the vout[vin[].prevout], i.e. GetValueIn(), is fee.

Fee

The fee of a transaction is Σoutput - Σinput. The fees of all transactions mined into a block contribute to the coinbase, together with the subsidy. The fees are not linked to its original transaction via address keys. The coinbase has no input, but its output is subsidy+fee.

When mining a block the transactions are ordered high fee first. With more transaction available than fitting into a block those with higher fee are chosen, while the others wait for the next block.

There is a blockMinFeeRate(DEFAULT_BLOCK_MIN_TX_FEE_PER_KB) to accept to block and a GetMinFee() to accept a transaction into the transaction pool (g_mempool). The latter is influenced by the maxMemPoolSize configuration. The largest fee of the transaction falling out becomes the minimum of those allowed in. GetMinFee() gets exponentially smaller with a half life of 12 hours (or 6 or 3 depending on how fast the traffic goes down).

The users decide on the fees, but it is a guess, because if too low the transaction will not get into a block. A stuck transaction can be manually prioritisetransaction'ed, thus circumventing currently higher fees. But for that you need RPC access to a node.

The number of blocks in the network are kept at a constant rate (e.g. 1 / 10 min). With constant block size, even a larger network cannot serve more transactions. A larger network only produces more load for transactions.

In nature exponential behavior comes from independent times. The resource usage of a transaction can be considered constant (proportional to the number of network nodes). But those doing transactions are independent and thus produce an exponential memory usage. In the presence or constant memory, the fee will have an exponential behavior, shutting out an exponentially growing number of smaller fee transactions.

getmempoolinfo informs about the current GetMinFee().

GetMinFee() is a rate per KB. The actual fee is GetMinFee().GetFee(<transaction size in bytes>).

On Ethereum the fee required to make transaction go through is called gas. EIP-1559 burns a base fee. Miners only get the difference to the base fee. The base fee changes with the traffic. Burning the base fee means more is burned the more traffic. The supply becomes smaller, when the demand becomes higher. This increases the price of the coin (deflationary coin/token).

Script

Bitcoin has no fields for addresses one spends money to or from. The addresses are buried in a script indirectly addressing public keys as hashes. To redeem a vout[i]->vin[j] from one transaction to another, the following script composition must evaluate to true (done by CScriptCheck):

[ <vin[j].scriptSig> ]  [ <vout[i].scriptPubKey> ]

The first part comes from the later transaction's vin[j].

There are more variants, the most frequent one is P2PKH.

P2PK:

[ <signature> ]    [ <public key> OP_CHECKSIG ]

P2PKH:

[ <Signature> <Public Key> ] [ OP_DUP OP_HASH160 <public key hash> OP_EQUAL OP_CHECKSIG ]

P2SH allows to provide the public keys (or locks) in a script only when actually spending:

[ <only push data to stack> <script> ] [ OP_HASH160 <script hash> OP_EQUAL ]

e.g.:

[ <signature> {<pubkey> OP_CHECKSIG} ] [ OP_HASH160 <hash of {<pubkey> OP_CHECKSIG>}> OP_EQUAL ]

The hash prevents linking an UTXO to the public key and avoids that future more powerful computers can infer the private key from the public. Hashes are also smaller and thus easier to be communicated on paper or screen printout, either via binary-to-text encoding like base58 or a QR code.

ECDSA cryptography (secp256k1 for Bitcoin) allows to recover the public key from the private key. So only the private key needs to be saved.

The public key can also be recovered from a signature and the message/hash that was signed. This is actually how <signature> <public key> OP_CHECKSIG works. To redeem, OP_CHECKSIG needs to have access to the private key. How the hash for the signature is created is known by SigHashType. The last byte of the signature encodes sigHashType for SignatureHash(), VerifySignature(). SignatureHash in script/interpreter.cpp shows what is signed. sigHashType can decide that more of the transaction than just vout[i]->vin[j] is signed, normally sigHashType=SIGHASH_ALL, i.e. the whole transaction is signed in each vout[i]->vin[j] link.

Everybody can recreate the same hash using the same data in the same order, but only the owner of the private key can make a signature of the hash fitting to he public key it contains.

When redeeming, the signature can be published, so that everybody can verify that the token was redeemed righteously (scriptSig).

SignSignature can be used to fill vin[i].scriptSig, i.e. to redeem a transaction.

The sigHashType used in scriptSig does not depend on scripPubKey, i.e. OP_CHECKSIG will succeed if the public key fits to the signature, independent of the content that was signed.

Token

In general the hash of some data is called token. For example, in pay-to-public-key-hash (P2PKH), the public key is the essential part in scriptPubKey. It is thus an ownership token.

EIP-20 (ERC-20) is a specification of fungible tokens on the ethereum network. Coins are fungible tokens: They don't identify an asset. 200000 compatible tokens exist. They are all traded on the Ethereum network, and can thus be exchanged against each other. UNI from uniswap is such a ERC-20 token.

EIP-721 specifies non-fungible token (NFT, deed). The value of NFT's is in its links to physical assets or other non-copyable items like contracts (mortgages and the like).

It is interesting that NFT's are used for images and other things that have no link to real assets, but that consist of data only, and can be copied easily.

OpenSea is a marketplace for NFT's.

Wallet

Coins is an unspent output of transactions (UTXO, COutPoint). To use coins one needs to have

• the private key fitting to the public key hash in scriptPubKey (for P2PKH)
• the transaction hash (txid)
• the index n into vout of txid

The public bitcoin site one can queried with a key hash, i.e. with an address, e.g.:

https://www.blockchain.com/btc/address/1EwpnNBdFJykwxp6X8v9AfZnup9bgmrLE1

Wallets can find transactions with importprivkey.

ScanForWalletTransactions allows to find the COutPoint{txid,n} for the private keys it contains. A wallet then stores the transaction hashes for its keys.

So what is important is only the keys. Only keys need backup.

For anonymity a new key is used for every transaction output.

With HD Wallets (HD = hierarchical deterministic), keys are generated from a seed and thus only the seed needs backup. With it the wallet can construct the keys and then query the blockchain.

Using the same HD wallet, the seed (key, phrase) can be used to regain access to all coins. The HD wallet name should be backed up, too, or the key derivation path.

Non-custodial software wallets:

Bitcoin: Bitcoin, Electrum, Pywallet, ...

Lightning: eclair, breez, muun, ...

ERC-20: bitbox, coinomi, metamask, zengo, brd, edge, trust bitpay (open source, visa functionality, segwit, schnorr)

Mining

Choose one time line (block chain) for more separate times (nodes).

• Make adding a block hard enough by proof-of-work (POW) to last enough human-relevant time to accumulate transactions (10 min).
• Make it easy to check the POW result.
• A random POW algorithm (trial-error) makes two parallel similar nodes about twice as fast, because twice as many trials are done.
• If none of the nodes is faster than the rest together it is impossible to overtake the longest chain.
• A node adds a block to the longest chain (= chain with most work).
• Longest chain with POW is the main consensus rule to choose the common time (ChainActive).
• ActivateBestChain/FindMostWorkChain decides to switch ActiveChain.
• Transactions (and its fees) count only in a matured ChainActive.

POW loop:

• try a nonce until the block hash becomes smaller then a arith_uint256 bnTarget, constructed from nBits (difficulty).

  The arith_uint256 type is used to represent a block hash. SetCompact constructs a large arith_uint256 bnTarget number from a compact uint32_t nBits.

• GetNextWorkRequired calculates nBits, CheckProofOfWork checks.

• A node mines in response to generatetoaddress.

  CreateNewBlock() create a CBlockTemplate, on which one finds nNonce, then ProcessNewBlock()/ActivateBestChain()/ConnectTip()/ConnectBlock()

getblocktemplate is

• an RPC API function
• a protocol

getblocktemplate allows to do mining separately:

• the miner asks the server about some fixed data (nVersion, hashPrevBlock, nTime, nBits) that needs to go into the block via getblocktempate.
• The miner can change hashMerkleRoot, nTime, nNonce to produce a hash that meets nBits difficulty.
• The miner calls submitblock on the server.

For a pure mining implementation in an ASIC, libblkmaker can be used to call getblocktemplate to a server. Then the miner can be simple, concentrating only on changing values to meet the difficulty (mining).

A bitcoin full node (server) can have more miners. This is called a mining pool. The full node is the server. It redistributes the reward to the miners.

Consensus

Apart from fulfilling the difficulty on longest chain, there are other relevant rules that decide, whether transactions and blocks are accepted by the network (MAX_MONEY, MedianTimePast(), ...). The coin is the result of the network consensus rules. The consensus rules decide, which transactions and blocks are accepted. The consensus rules are like a parallel program producing one time: the blockchain.

The nodes could have completely different implementations, if the behavior is the same. Two different implementations would need long testing against each other to produce the same behavior. The nodes are controlled by different parties, but they still choose the same implementation to produce the same behavior. The implementation of peers is not visible, though. If advantages are detected, individual nodes slightly change implementation and behavior here and there. The network adapts slowly by introducing new rules and checks them starting from a specific height or MedianTimePast() time. The upgrades have are named after BIPs or get special names, like taproot.

Changes in the behavior need to be taken over by all nodes simultaneously, or they are backward incompatible.

hard fork

If more nodes do not agree on the new rules, the transactions and/or blocks are mutually not accepted any more, which is a hard fork of the network and the into separate branches.

soft fork

In a soft fork changes need to have backward compatible behavior, to allow communication until almost all nodes are upgraded.

Fork above refers to chain forks. The software that creates a chain can also be forked. The software fork can possibly create a completely new chain with its own genesis block.

RPC Command

After starting, bitcoind exposes its interface as RPC. The RPC names and parameters are also command line arguments of bitoin-cli.

To list commands:

bitcoin-cli help

The simplest way to send money:

bitcoin-cli sendtoaddress [address] [amount]

Further information:

• bitcoin-from-cli tutorial
• In the source code scan for RPCHelpMan.

Watch Me Learn Haskell

I use some good software written in Haskell (Xmonad, Pandoc, ...) and, keen for a new adventure, I delved into it.

The community provides great help for newcomers:

• brief Typeclassopedia OOP_vs_type_classes Monads_as_computation Lists_and_strings FFI (wiki)
• tutorial syntax haskell2010 do (onlinereport)
• How to write a Haskell program
• user_guide
• reference
• Truth_values, arrows (wikibooks)
• learnyouahaskell
• realworldhaskell
• schoolofhaskell
• WIWIKWLH
• learnxinyminutes
• Awesome Haskell
• types
• haskell-by-types
• cheatsheet
• riptutorial
• extensions
• rosetta code
• Write Yourself a Scheme in 48 Hours

Mind-setting

To mum you can say: Make me a cake, please. To your sister you may need to say: Open the lowest drawer. Take the deep bowl. ...

Programming can be easy and it can be hard. A computer does know very little by itself. So it is hard to tell it what to do. The hard side is to organize, what you need to say to the computer.

The words and the way to organize things can vary between programming languages.

Variable vs Type

Variable comes from "vary", which is the Latin-rooted word for change.

Why a value changes does not matter for the concept of variable,

• along (no causality) or due to (causality) space or time or color or whatever
• by itself (no causality) or by choosing or selection (causality)

Variable is synonymous to alternatives or choice.

I walk. I run. Both have the "I". This makes "walk" and "run" the values of this variable.

So variable arises due to a common context in which

1. values exclude each other
2. values can be selected individually
3. values can be distinguished

Each of these mean the same. But lets settle with 1, with exclude (exclusive), to characterize (the values of) a variable.

What is a variable in one context is a value in another.

There is a history of various wording with similar to same meaning. variable-value is same as or similar to

• a-the
• level of indirection
• set-element (set theory)
• type-term (type theory)

The modelling in mathematics/software involves many levels of indirection. variable-value is a general concept that links the layers.

Type is the aspect that maps the real variable to the representation variable in a computer. Type as the implementation. Type refers to the

• amount of memory used for a variable and
• the encoding of the values of the variable

The choice of type is restricted by

• the requirements of the real variable and
• the types offered by the specific computer (language)

In Haskell you can specify the type separately, also later. If you omit it, Haskell will normally make a choice for you.

:{
v::Double
v = 1
:}
v

When you program you map a real variable hierarchy to a type hierarchy.

• In C-like languages the type describes a memory area (plus methods in OOP). A variable is an instance of such a type, i.e. a memory location with a specific address. Assignment is placing a value (a bit combination) to the memory area. The name identifies the typed memory area, the variable. This is static typing.
• In Python or R, the name identifies a value. The name is a variable in the sense that it can address different values of whatever type. The type associated with a name can change during run time. Assignment is basically naming. This is also called dynamic typing. If there are typing problems, this is only found during runtime (duck typing).

Functional languages are also statically or dynamically typed. Haskell is statically typed, Scheme and Clojure are dynamically typed.

Variable vs Function

Values normally are not random, but occur due to values of other variables. Value occurrences are a function of values from other variables.

Variable-value thus becomes function-(function application). function application is the selection of the value. This is the smallest building block of computing. Computing consists of (execution of) functions, i.e. the mapping from variable to variable.

All values of variables do occur (are exhaustive). The function f is all the couples f={(v,w)|vin V land win W land text{unique}(w)}.

In Haskell this is:

import Data.Char
:{
f 1 = 11
f 2 = 22
f x | x >= 10 = digitToInt (head (show x))
:}
f 23
f 2
f 0 -- Exception: ... : Non-exhaustive patterns in function f

Variables are more fundamental than functions, because you need to have choice first. The function maps this choice, the independent variable(s), to the target variable.

The function does not completely define the target variable, if not surjective. If not surjective the target variable might arise from more functions. The target variable would thus motivate a variable of functions towards it.

The function looses information, if not injective. Then, a common target value links source values, i.e. it produces a topological structure in the source variable.

There are also relations between variables that are not functions, i.e. that are not unique in either direction. Functional description can be restored by introducing new structure variables whose values combine original values according relation.

This produces complexity applicable only for specific contexts and does not have the generality needed in programming. Programming is about choosing, about the values.

Category theory avoids the complexity by not looking at internals: A well defined object gets mapped to another object or itself (id) by a morphism. Morphisms need to be composable associatively (a path uniquely defines the target object).

I use variable instead of set to emphasizing that the important quantity is the exclusive choice the variable allows (the value).

In Haskell the choice is done by a data construction. There can be more data constructors for one type. This allows to use different data layout within one type, while still being statically type checked (ADT).

The object in Category theory could be the value or the variable. The former is a dynamic variable (immutable), the latter is static variable (mutable). The Haskell types are static, but the variables are dynamic.

In Haskell the = is a mapping rather than an assignment. Every application generates a new variable. Every generated value is associated with new memory allocation. To avoid that in critical code, Haskell also has mutable types.

Function composition

Haskell allows to compose functions without mentioning the arguments. This is called pointfree style, as values in mathematics are often called points. No argument values means no points. Ironically the usual composition operator is the point (.).

-- pointfree
sc = sum . sequence [(**2) . sin, (**2) . cos]
sc 2 -- 1.0
-- in this case better:
sc x = (sin x)**2 + (cos x)**2

pointfree is only shorter, if the return value is forwarded to the next function. For other situations there are other function compositions. Functions composing other function are called higher order functions or combinators.

In Haskell a lot of effort goes into the design of function compositions (Monad, Kleisli, Arrow, ...) to allow the elegant pointfree style.

The fundamental building block of computing is function application (selection), but immediately next in importance is how to compose them in a widely applicable way.

Wide application means good abstraction. Abstraction is compression. Compression means coping with less resources, less space, less time, less code, less energy. So effort is well spent, if it allows describing something in a more compressed way.

Functional Programming

Programming is based on mathematics, which is older than computers. We encounter variable-value, functions, etc. in all languages, but especially functional languages like Haskell push you to think mathematically. Code reuse demands abstraction. A good programmer needs to think abstractly, mathematically.

Many languages assume and work on an outside world. This outside world gives instructions their meaning. The "open the lowest drawer" example assumes a kitchen, which can be changed. One can open a drawer, etc ...

A purely functional style describes everything as functions. A function maps input to output without changing the input. In our example, a kitchen would be input and a kitchen with an open drawer would be output.

An output becomes a new input to another function. This function composition produces a time sequence, a natural thread of execution. If there were more cooks (more threads), they would all develop their own kitchens. No coordination needed, which makes things a lot easier. (In Haskell the kitchen would be a Monad.)

A programming style is a way to organize things. Languages can be used for more styles, but their syntax and libraries favor a specific style. A style that is shared in a community is called a paradigm.

Most people are first introduced to languages that favor an imperative style.

• Functions in non-functional languages change memory. They have side effects. Some languages call functions more appropriately "procedure" or "subroutine".
• Functions in functional programming languages don't change anything. They only map values to other values. They are mathematical functions.

The functional style passes functions around, instead of data.

Haskell tries hard to make you think purely functionally.

Syntax

BNF-syntax of Haskell: BNF

Syntax described by template Haskell: TH

Typing

A simple function type (signature) is:

fun:: Int -> Double

Unlike in C or Java this is a function without side effects, which makes it easier to test.

Not only types, but also variables of types (kind) are possible:

fun:: a -> b

:kind (->)
(->) :: * -> * -> *

-> accepts all type (* = all types). -> maps from two kinds (input) to a third kind (output). -> has other usages as well.

Application is done via a space: fun some_value. There are different types of applications:

• application of function
• application of constructor
• application of constraint

A constructor constructs a type. It is like a function signature without implementation, that can be applied to actual argument values, though. Since it cannot map the actual arguments, it just holds them. Therefore it is like a record in DB jargon, or a struct in C.

The implementation for the signature fun:: a -> b would be fun pat = rhs.

• pat could be just a letter, e.g. x, which is a variable for any actual argument value during application.
• Or pat could be a constrained pattern to address contained variables like x:xs or AConstructor x.

The rhs is the last entry in the function type definition. The expression for rhs depends only on the lhs arguments (e.g. on x). Within the code of rhs further functions with variables can be declared.

Via this containment of functions, context is built.

If the rhs introduces new variables, the application of a function is the application of context.

Currying: fun application is like walking along a path between variables. A (partial) walk on the path (a section), i.e. partial application, produces a function, that walks the rest of the path.

flip or infix notation allows to curry also on the second argument.

Many functions in Haskell are of higher orders. Higher order functions combine (compose) functions to new functions (combinators) without the need to mention the variables.

In:

( . ) :: (b -> c) -> (a -> b) -> a -> c

• ( . ) has two lhs arguments
• (b -> c) and (a -> b) match functions

When applying ( . ) you don't need to mention the variables of type a, b, ....

In:

(<*>) :: Applicative f => f (a -> b) -> f a -> f b

• f is constrained to the Applicative class.
• The constraint between :: and => is called Context.
• The actual f must be a data type that is instance of Applicative and cannot be a single function.
• f with space is a pattern for an application. Here it is a constructor application for the type implementing Applicative.
• f (a -> b) is the pattern for the first argument to extract f, a, b.
• f a is the pattern for the second argument.
• The last argument f b is the type of the return value.

In:

(<$>) :: Functor f => (a -> b) -> f a -> f b

• (<$>) has two lhs arguments
• (a -> b) is the pattern for the first argument: a function.
• f a is a constructor pattern for the second argument: a data type.
• f stands for a class (= variable of types = kind)
• Functor is a class.
• Functor f constrains f to types with the Functor class

The implementation of (<$>) would construct a value using an actual f constructor.

[] is a type, which implements both, Applicative and Functor.

Usage:

[ (*3), (*6) ] <*> [3]
((*) <$> [ 3, 6]) <*> [3]
-- -> [9,18]

In Haskell a lot of typing is done via function signatures:

• functions :: signature
• class is more signatures (interface)
• a data or newtype type can be made instance of more classes

:{
data ABType = ABType
class AClass a where
  afun:: a -> a
class BClass b where
  bfun:: b -> b
instance AClass ABType where
  afun = id
instance BClass ABType where
  bfun = id
fun:: ABType -> Int
fun ab = 1 -- just to make the compiler happy
:}

• id is the Haskell function for identity
• Type and class names must start with capital letter.

ABType is a type constrained to two classes:

fun:: ABType -> Int

is equivalent to:

fun:: (AClass ab, BClass ab) => ab -> Int  -- Int is a type

Actually using (AClass a, BClass b) => would need the FlexibleContexts extension.

Int is a type that is constraint to these (type) classes:

:info Int
type Int :: *
data Int = GHC.Types.I# GHC.Prim.Int#
        -- Defined in ‘GHC.Types’
instance Eq Int -- Defined in ‘GHC.Classes’
instance Ord Int -- Defined in ‘GHC.Classes’
instance Enum Int -- Defined in ‘GHC.Enum’
instance Num Int -- Defined in ‘GHC.Num’
instance Real Int -- Defined in ‘GHC.Real’
instance Show Int -- Defined in ‘GHC.Show’
instance Read Int -- Defined in ‘GHC.Read’
instance Bounded Int -- Defined in ‘GHC.Enum’
instance Integral Int -- Defined in ‘GHC.Real’

Keywords

The top level declarations, ordered by importance, are:

<gendecl> | <fundecl> | data | instance | class | module | newtype | type | default

• gendecl: Function signature (fun ::) or fixity.
• fundecl: Functions use no keyword (read from left to right)
• data, type, newtype are data related (read from right to left)
• class, instance are type related
• module, default are organizational

Keyword meaning:

• module .. where is used to specify what is exported by a file, then where and the details follow
• default(Int) or used in extensions, like DefaultSignatures
• data atype = rhs introduces a type name that on the right hand side has possibly more constructor names
• newtype Key = Int similar to data, but only one constructor allowed, which is seen by the compiler, but not in runtime
• type Key = Int creates a type synonym for the user, which is not seen by the compiler
• class <Aclass> <params> where is a container of function signatures
• instance <Aclass> <atype> where declares an implementation of a class for a type. Implementation can be done automatically using deriving.

Data

data can have named values (enum):

data Move = Walk | Run
let move = Walk

speed Walk = 5
speed Run = 10

:t speed
-- -> speed :: Num p => Move -> p

Constructors Walk, Run map to a type (Move). Literals have a type. Haskell can infer the function signature.

Note the difference between type (data,newtype,type) and constraint (class,instance):

• type (Move here) is directly used in the signature
• p is constrained to class Num, which is more general, than using type Int or Double.

Constructors can be parametrized:

data Person = Person String Int deriving (Show)
let guy = Person "Buddy" 44

The parameters (fields) can be named, but actually it is naming the accessor function.

data Person = Person { nickname :: String, age :: Int} deriving (Show)
let guy1 = Person "Buddy" 44
let guy2 = Person { nickname = "Jo", age = 33}
nickname guy2
-- -> "Jo"
guy2 { age = age guy2 + 1}
-- -> Person {nickname = "Jo", age = 34}

data with one constructor and more fields is called a record.

data Shape location size = Rectangle location size | Circle location size deriving Show
:t Rectangle
-- -> Rectangle :: location -> size -> Shape location size
data Size = Small | Medium | Large deriving Show
data Location = Inside | Outside deriving Show
let ri = Rectangle Inside
:t ri
-- -> ri :: size -> Shape Location size
let ris = ri Small
:t ris

You cannot do Shape Inside Small, because ambiguous.

Different data constructors (rhs) are grouped by the common type constructor (lhs). This is called algebraic data type (ADT).

data can use recursion.

Code

An example

data Speed = Slow | Fast
data Move s = Walk s | Run s

:{
speed:: Num a => Move Speed -> a
speed (Walk Slow) = 5
speed (Walk Fast) = 10
speed (Run Slow) = 11
speed (Run Fast) = 15
:}

speed (Run Fast)
-- -> 15

:t speed
-- -> speed :: Num a => Move Speed -> a

lhs

Function: One or more declarations that map from the left-hand-side (lhs) to the right-hand-side (rhs).

' can be part of a function name. Combinations of !#$%&*+./<=>?@\^-~| and Unicode symbols can be used as function symbols (fop).

Every lhs = rhs has its own namespace. So never consider the argument naming when comparing two (related) declarations, because it just confuses you, if you see the same name for unrelated things.

lhs can be infix:

pat `fun` pat = rhs
pat fop pat = rhs

Or prefix:

fun pat = rhs
(fop) pat = rhs

lhs can contain guards (|). There can be a where at the end of the guards:

-- in ghci :{:} is needed
:{
aad a|a<0  = a-1
aad a|a>0  = a+1
aad a|otherwise = a
:}
-- equivalent to
:{
aad a|a<0  = a-1
     |a>0  = a+1
     |otherwise = a
:}
aad (-1) -- use () with negative numbers
-- -> -2
aad 1
-- -> 2
aad 0
-- -> 0

lhs can contain patterns with sub-patterns (pat). Patterns are built of:

_
(Constructor _) -- brackets is a good idea!
n@(Constructor _) -- rhs uses n
[a]
(x:xs)
!pat -- match now, not lazily
~pat -- always match (irrefutable), if you know it to succeed

n, a, x, xs are arbitrary names that can be used in the rhs. Constructor refers to an actual constructor. _ is anything.

Patterns are evaluated lazily by default. Lazy can mean a lot of memory consumption. It evaluates until the first constructor is found and then needs to remember the arguments (thunks) before trying other evaluation paths. Using ! avoids that.

rhs

The rhs declaration is an expression (exp) with helper declarations either before:

fun pat = let ... in exp

or after:

fun pat = exp where
  ...

The helper declarations can be in layout style:

... where
  recl1
  ...
  declN

or

where {decl1;...;declN}

where can also be used in class and instance declarations.

exp is application of functions

• fun a b or a `fun` b or (fop) a b or a fop b. To name functions with symbols (fop) is normal in Haskell.
• fun $ pat avoids brackets by reducing fixity to 0 (see :info $)
• fun $! pat evaluates pat before applying fun

Fixity of an operation is set with infixl|infixr|infix <fixity> <fop>.

:{
fsum (x:xs) y = fsum xs $! (x+y) -- same as: (x+y) `seq` fsum xs
fsum [] y = y
:}
fsum [1..100] 0

These can use patterns on the left side:

• = is a mapping
• <- names values from a generator
• -> replaces = in local scopes (e.g lambda \x -> x*x)

Some other operators:

• == and /= mean equal or not equal
• \ introduces a lambda function (function without name)
• : prepend element in a list (1:[2])
• | is a guard, used in declarations and list comprehensions
• .. generates a sequence of values based on a partial sequence
• . module.sub-module or, with spaces, composes functions

let s = [x*x | x <- [1, 3 .. 9]]
s !! 2
-- -> 25
zip [1 ..] s
-- -> [(1,1),(2,9),(3,25),(4,49),(5,81)] 
take 3 $ [0,5 .. ]
-- -> [0,5,10]
cycle [3,6 .. ] !! 4
-- -> 15
iterate (1+) 2 !! 3
-- -> 5

Further, code can contain:

if exp then exp else exp

case exp of {alternatives}

do {statements}

• Only if-then-else has expressions.
• case alternatives are maps that use -> instead of =.
• statements use <-, if at all, and can use = only in an optional where.

do is syntactic sugar for a Monad binding operator (>>=), which forwards output of the function in the previous line to the input of the function in the next line, to allow imperative style fragments. It is not imperative, though, but function composition. Function composition is Haskell's way of a sequence, intermitted with let or where for cases in which not the full output is needed as input. Monad is detailed further down.

Class

class contains function types and possibly default implementations. Class is short of type class, in the sense that more types are instances of a class.

An instance provides implementations of the functions of a class for a specific data type. Instances for one class can be scattered across many modules. import xyz() imports only the instances.

class A1 a where f:: a -> a
class A2 a where g:: a -> a
data D = D Int
data E = E Int
instance A1 D where f (D n) = D (n+1)
instance A2 E where g (E n) = E (n+2)

:{
ff:: A1 a => a -> a
ff u = u
:}

dd = let d = D 3 in ff d
dd = let e = E 3 in ff e -- error: No instance of (A1 E)

If we make E an instance of A1, there is no error:

instance A1 E where f n = n
dd = let e = E 3 in ff e

When a module imports a class, its functions become public.

The function is constrained to the class, in which the function was declared.

Prelude>   :info (<*>)
type Applicative :: (* -> *) -> Constraint
class Functor f => Applicative f where
  ...
  (<*>) :: f (a -> b) -> f a -> f b
  ...
        -- Defined in ‘GHC.Base’
infixl 4 <*>
Prelude>   :info (<$>)
(<$>) :: Functor f => (a -> b) -> f a -> f b
        -- Defined in ‘Data.Functor’
infixl 4 <$>

Starting from ghc/libraries/base/Prelude.hs one can follow included modules. ghc/libraries/base/GHC/Base.hs declares:

Semigroup, Monoid, Functor, Applicative, Monad, Alternative, MonadPlus

Here some example usages for Prelude classes:

:info Semigroup
[1,2] <> [4,5]
-- -> [1,2,4,5]
:info Monoid
[1,2,3] <> []
-- -> [1,2,3]
:info Functor
(+10) <$> [1,2,3] -- or fmap
-- -> [11,12,13]
:info Applicative
(+) <$> [1,2] <*> [3,4] -- same infixl 4
-- -> [4,5,5,6]
1 <$ [1,2,3]
-- -> [1,1,1]
liftA2 (+) (Just 1) (Just 2)
-- -> Just 3
(+) <$> Just 1 <*> Just 2
-- -> Just 3

Since functions are passed around in Haskell, type classes have functions that accept functions as arguments and apply them to the data. This result in classes (Functor, Applicative, Monad, ...) that you don't see among the interfaces of data oriented languages.

The full usage intention behind a class cannot be read from the function signature. Additional laws (see Typeclassopedia) can be the basis for further thinking to grasp the intended generality.

(<>) :: Semigroup a => a -> a -> a is binary. That we stay within the same type (a) (closedness) makes sure that the associative law stays. The associativity law (a <> b) <> c == a <> (b <> c) allows to infer

• that the time sequence does not matter (one could calculate chunks of a chain in any order or in parallel) and
• that consequently the space sequence fully identifies the result

A law like this is quite general, but still reduces all possible cases quite a bit, and thus has information.

Monoid adds the empty. A neutral element allows usage of the concept where there is nothing fitting to it. The neutral 0 allowed the transition from roman numerals, where the quantity grouping had to be named, to position coded numbers, where you place a 0 in a position, if the value of the position is not there.

(<$>) :: Functor f => (a -> b) -> f a -> f b

• injects a function a -> b (first argument)
• into a constructed/derived type (second argument)

<$> is also called fmap (functor map). A functor maps one category into another. This is also called lifting (liftA, liftA2, ...).

(<*>) :: Applicative f => f (a -> b) -> f a -> f b assumes a lifted function, which is then applied in the new category.

• <$> lifts the arguments and applies the function.
• pure just lifts, without looking at the arguments.
• <*> only applies.

So Applicative splits a Functor's fmap into two parts.

import GHC.Base
( (*) <$> [2, 3] ) <*> [6,7]
liftA2 (*) [2,3] [6,7]
-- all -> [12,14,18,21]
fmap (*10) [6,7]
liftA (*10) [6,7]
pure (*10) <*> [6,7]
-- all -> [60, 70]
pure (*10) *> [6,7]
[6,7] <* pure (*10)
-- all -> [6, 7]

import Control.Applicative
:{
digit :: Int -> String -> Maybe Int
digit _ []                     = Nothing
digit i (c:_) | i > 9 || i < 0 = Nothing
              | otherwise      = if [c] == show i then Just i else Nothing
:}
digit 0 "01"
-- -> Just 3
digit 1 "01"
-- -> Nothing
binChar s = digit 0 s <|> digit 1 s
binChar "01"
-- -> Just 0
binChar "10"
-- -> Just 1

Alternative adds the idea of Monoid to the Functor-Applicative line, with <|> instead of <> (Typeclassopedia). It also implements some and many. They are only useful for types where the constructor calls a function that processes input: a parser.

• some stops when the first empty is constructed, and
• many continues recursive application of the constructor beyond empty

Monad

A monad constructs and forwards context.

In a functional programming language context is built via the parameters of contained functions.

import Control.Monad
:info Monad

(>>=) :: m a -> (a -> m b) -> m b
(>>) :: m a -> m b -> m b
return :: a -> m a

In:

(>>=) :: Monad m => m a -> (a -> m b) -> m b

• m is a constructor of a type that is instance of the Monad class
• m a is NOT a constructor application but a pattern matching to extract m and a
• a -> m b is a pattern against a function with target m b. Let's call it k.
• >>= needs to map to what k maps to, i.e. apply k a. The implementation from Maybe: (Just x) >>= k = k x

In a do

• a <- exp [args]; nextexp stands for exp >>= (\a -> nextexp)
• exp [args] constructs a value that would be pattern matched using m a
• >>= composes a <- exp [args] with the next expression
• >> composes exp; nextexp

return :: Monad m => a -> m a

return is basically the same as m, but since m can be any constructor it is good that we can refer to it generally with this one name.

-> is a Monad

-> constructs a type via lambda encapsulation (currying).

instance Monad ((->) r) where
    f >>= k = \ r -> k (f r) r

• f is the application so far (a lambda)
• k is the next ->
• k is applied to what was before (f r) and what comes after (r)

IO is a Monad:

do {putStr "Hi"; putStrLn " there!"; }
putStr "Hi" >> putStrLn " there"
readLn >>= print

[] is a Monad

You can use this to do SQL like queries.

sel prop vals = do {val <- vals; return (prop val);} -- @val <- vals@ needed
data Name = Name { firstName ::String , lastName :: String } deriving Show
children = [ Name "Audre" "Lorde", Name "Leslie" "Silko", Name "Jo" "Silko"]
sel firstName children
-- -> ["Audre","Leslie","Jo"]
import Control.Monad -- for guard
wh test vals = do {val <- vals; guard (test val); return val; }
wh (\s->'A'==(head s)) (sel firstName children)
data Family = Family { name ::String } deriving Show
families = [ Family "Lorde", Family "Silko" ]
jn d1 d2 p1 p2 = [ (d,e) | d<-d1, e<-d2, p1 d == p2 e]
jn families children name lastName
sel (firstName.snd) (wh (((==) "Silko").name.fst) (jn families children name lastName))
q s j w = s (w j)
q (sel (firstName.snd)) (jn families children name lastName) (wh (((==) "Silko").name.fst))

State is a Monad

import Control.Monad.State
runState (do { put 5; return 'X' }) 1
-- -> ('X',5)
evalState (gets (+1)) 1

Maybe is a Monad

import Data.Maybe
catMaybes [Just 3, Nothing, Just 9]
-- -> [3,9]

:{
printLengthPrint :: Int -> Maybe Double
printLengthPrint = \w -> Just (show w)    -- :: Int -> Maybe String
               >>= \x -> Just (length x)  -- :: String -> Maybe Int
               >>= \y -> Just (2.0 ^^ y)  -- :: Int -> Maybe Double
:}
printLengthPrint 32
-- -> Just 4.0
:{
f :: Int -> Maybe String
f = Just . show
g :: String -> Maybe Int
g = Just . length
h :: Int -> Maybe Double
h = Just . (2.0 ^^)
:}
import Control.Monad
plp1 = h <=< g <=< f
plp1 32
plp2 = f >=> g >=> h
plp2 32

Monad transformer

A Monad transformer constructs a Monad from other monads.

The monad transformer library (mtl) is part of the ghc.

Extensions

The Haskell standard gets updated only every 10 years. Development in between can get activated via extensions.

{-# <EXTENSION>, ... #-}
-- or GHCi:
:set -X<EXTENSION>

Here some common ones from the GHC extension list:

• OverloadedStrings: When using Data.Text instead of String
• FlexibleInstances: nested types in head of instance
• FlexibleContexts: class context of kind class (Cls1 a, Cls2 a) => ...
• AllowAmbiguousTypes: let call decide and not ambiguity checker
• ViewPatterns: include function result in pattern match
• PaternSynonym: e.g. pattern NoBlending = #{const SDL_BLENDMODE_NONE} :: CInt
• RecordWildCards: f (ARec{..}) = e1 ... instead of f (ARec e1 ...) = e1 ...
• NamedFieldPuns: when matching against less fields: f (ARec{ex}) = ex instead of f (Arec{ex=ex}) = ex
• DeriveFunctor: deriving Functor derives functor instance
• TypeApplications: specify type when called, e.g. show (read @Int "5")
• BangPatterns: f (!x,y) strict (not lazy) in x but not in y
• MultiParamTypeClasses implies FunctionalDependencies: class C a b ...| a b -> c
• LambdaCase: \case { p1 -> e1; ...; pN -> eN } for \p -> case p of {...
• BlockArguments: when (x>0) do ... instead of when (x>0) (do ...)
• MonadComprehensions: [ x+y | x <- [1..10], y <- [1..x], then take 2 ] (comprehension for all monads)
• RebindableSyntax: bind to whatever in scope and not to Prelude
• TransformListComp: in list comprehension then f [by|using field] (f=sortWith|group|..)
• GADTs: constructors as parametrized constrained type functions
• TypeFamilies: type function within class to let instance compute the type
• TemplateHaskell: compile-time macros to generate Haskell code

24 GHC Extensions gives alternative examples to some extensions.

Haskell has no Sequence, Loop, OOP

Object-oriented programming (OOP) gives different data a common interface to be passed to functions. In Haskell, interfaces are called (type) classes and they give different data a common way to inject (e.g. liftM) and compose functions on it (e.g. >>=).

Haskell is about composing functions:

• sequences are replaced with function compositions
• loops are replaced with recursive function compositions
• if-then-else and case could be functions

Compared to OOP in Haskell:

• type class is what interface is in OOP.

  class can also have function implementations (default implementations).

• data or newtype is the object type called class in OOP.

  • They can have more constructors and recursive constructors
  • They can have fields that are
    • other data types (corresponds to OOP inheritance)
    • functions (runtime polymorphism in OOP)

• An instance constrains a data type to a class.

Note the shift of meaning of class and instance respect to OOP:

• OOP: interface - class - constructor to memory
• Haskell: class - instance, data - constructor to memory

Pattern matching is a way to associate code to data without an instance declaration.

There is the Lens library to allows access fields in OOP style (needs an install: cabal install --lib microlens-platform).

Generic programming in called parametrized polymorphism in Haskell, as it is done via parametrizing types and classes

• parametrized data (ADT), extended through GADTs
• parametrized class, extended through MultiParamTypeClasses

GHC.Generics allows to derive instance methods for user classes based on a generic implementation, similar to .. deriving (Eq,Ord,Show) for built-in classes.

Extensions:

• DeriveGeneric: deriving Generic generates instance Generic <usertype> ...
• DefaultSignatures: change signature of class default implementations
• DeriveAnyClass: allows deriving (<UserClass>)

Then there is template meta-programming with TemplateHaskell, to create Haskell code on the fly, like a C macro.

Epilogue

To program functionally, in data and code, express yourself with

• pattern matching functions
• recursion
• currying
• pointless

It is a path with problems, too, and their solutions, an evolutionary branch of programming.