Max's Blog+Forum

Max's Blog+Forum


Max's Blog

Max's Blog

Factum Money

Bitcoin is a disruptive technology, and since time immemorial disruptive technologies have challenged our existing theories and demanded improvement. I'm not going to beat around the bush trying to make Bitcoin conform to our existing schemas. We need to rethink what makes types of money that particular type; not look into why Bitcoin can function as a currency - that is already well understood. I'll outline what I think are the important constituents of money that help differentiate them today. We'll then look into how Bitcoin fits in, hopefully in such a way that convinces you Bitcoin is truly novel.

Broadly, the three well understood forms of money are as follows: fiat money, commodity money (CM), and commodity-backed money (CBM). People will often separate the former with the latter two based on the notion of 'intrinsic value'. While we can agree that all three have value, we also know that the value of fiat money is derived from legislation: not an intrinsic property.

While this categorisation schema works for the above, I believe there is a more pertinent distinction to be made: that of non-monetary use-value; i.e. the money type in question has some primary purpose other than to simply exchange value between parties. The primary use of fiat money is to exchange value, we can therefore see that not only does fiat not have any non-monetary use-value, but that the use-value of fiat money is fundamentally bound to the exchange-value. On the other hand, we see that CM and CBM derive their use value not just from exchange, but also from the intrinsic properties of the commodity itself. Therefore we can categorise these three forms of money as before, but with the determinant being non-monetary use-value.

The second property I'd like to introduce is the concept of 'deferred value', and 'direct value'. Ultimately you can think of these as 'an IOU', or 'not an IOU' respectively.

Deferred value is seen in both commodity-backed money, and fiat money. Both are not so much valuable because of what they are, but because of what they entitle the user to. This is easy to see in the case of commodity-backed money, such as a gold certificate, as it is redeemable for a commodity (in this case, gold). However, in the case of fiat money, it is not directly redeemable for any particular commodity, but is legislated that it has value. Put in another way: fiat money entitles the user to some value. We should consider that if the legislatory environment surrounding either of the above were to collapse, they would respectively become useless. Commodity money can never truly reach zero value, but both CBM and fiat can, and so participating in such systems is like passing a hot potato; it's okay as long as you're not the one to get burnt. This is part of the nature of deferred value.

On the other hand, direct value implies that the received value is intrinsically tied to the received object. In the case of commodity money - say, rice - it is trivial to see that the value of rice (that you can eat it) is bestowed to the recipient immediately upon receipt.

By viewing the property of non-monetary use-value in light of deferred or direct value, we can see that while a gold certificate may have no particular non-monetary uses in and of itself, by acting as a method of deferred value it can inherit non-monetary use value from the commodity it is tied to.

As a visual summary, here is what we've talked about so far:

Deferred Value    | Direct Value    |
commodity-backed  | Commodity       | Has non-monetary
Money             | Money           | use value
Fiat Money,       |                 | No non-monetary
Generic IOUs (e.g.|                 | use value
paypal-us-dollars)|                 |

Enter Bitcoin: the rule breaker, the status quo usurper. You might have noticed there is one particular combination of the above properties that has not been covered by traditional monetary systems. It's tempting to fill in the blank with Bitcoin; but we should remember that Bitcoin is merely an example of this missing puzzle piece, just as the US Dollar is just an example of fiat currency.

Definition: Factum Money

A stand-alone money system in which each unit, by its intrinsic properties alone, necessarily holds a non-zero value.


Factum loosely translates from latin as 'done'; a play on words, as fiat loosely translates as 'let it be so'. Factum also lends itself to 'fact based currency': because of each individuals' knowledge of the system, it is able to be used to exchange value; an appropriate description.

To gain an intuitive understanding of what this really means, let us diverge from the topic for a moment to discuss aliens. (Bear with me!) It's an assumed property of the universe that no matter where you are spatiotemporally the number pi will be constant. You can express this in various ways; but the simplest is that the ratio between the radius and circumference of a perfect circle is always constant. I suggest that Factum Money has a similar property: that regardless of position in space and time, society, culture, species, or any other physical differences, true Factum Money is able to transfer value. Doubtless each instance of factum money can have local environmental factors that prohibit its use; Bitcoin is known to lack quantum computing resistance and will fail if SHA256 is broken, just as Litecoin relies on Scrypt. However, due to the particular conditions of today, Bitcoin is able to transfer value, and holds the mantle of 'Factum Money'.

Filling in the blank, we now we have a table that looks like this:

Deferred Value     | Direct Value    |
commodity-backed   | Commodity       | Has non-monetary
Money              | Money           | use value
Fiat Money         | Factum Money    | No non-monetary
Generic IOUs (e.g. | e.g. Bitcoin    | use value
paypal-us-dollars) |                 |

There's a great deal left to explore within this idea; of particular interest (which I'll explore in a follow up post) is what this actually means for Bitcoiners, and how we can predict and take advantage of this model. Cryptocurrency has many facets that have so far only been theoretically explored, in particular perfect money laundering, and distributed exchanges. I'll largely be exploring distributed exchanges in my next post.

Changed my mind

I think I've changed my mind about Bitcoin as money. Particularly: it's a fiat currency (factum money is just fiat in disguise), and I don't think it's sound money anymore. Just because it doesn't have government backing doesn't mean that it isn't fiat.

The reason for the change-of-mind is that I've started reading Theory of Money and Credit by Mises (TMC). I don't think Mises would be in favor of Bitcoin; how does one answer what is the origin of Bitcoin's value? -- I don't think there's a substantive answer.

Related discussion: (this post and on).

I am planning on writing a post about this soon (after I finish and understand TMC).

Addendum by u/max after 2021-12-02 21:38:02 UTC 1 day
Attribution re changing my mind: Why did I start reading TMC?

Elliot criticized this post for not giving proper attribution:

@Max blogged:
I think I’ve changed my mind about Bitcoin as money. Particularly: it’s a fiat currency
The reason for the change-of-mind is that I’ve started reading Theory of Money and Credit by Mises (TMC).
Related discussion: (this post and on).
This doesn’t give proper credit. It makes it sound like your idea that you came up with after you started reading the book on your own initiative. “Related discussion” doesn’t communicate “where I got the idea, and the book recommendation, from someone else”.

I started reading TMC entirely because Elliot referenced it in the original 'related discussion' link. Elliot's original post:

Bitcoin is not a commodity money. Its value is meant to come from being a medium of exchange and that’s it. That’s bad. See Mises (Theory of Money and Credit) and Reisman (Capitalism) on commodity and fiat money.

Particularly: That’s bad. was the bit to convince me that it was worth reading TMC. The idea that Bitcoin (or anything) trying to be something other than commodity money was bad: I got that from Elliot. I was especially interested in reading TMC because I first learnt about Mises through articles and discussion around Bitcoin-as-money (prior to writing n/2002) and Elliot's comment implied there was a conflict between Mises's ideas and the reasons I thought Bitcoin was sound money (I now agree there is a conflict there). I thought (and, IMO, many Bitcoiners did and still do think) that Mises would have liked Bitcoin -- I was convinced otherwise by the first ~7 chapters of TMC which seem pretty cut-and-dry WRT the important qualities of the origin of the value of a money.

Additionally wrt other unattributed ideas: re-reading the original factum money post; most of the foundational ideas (like non-monetary use-value) seem to be lifted from TMC, or at least they're descendants of ideas in TMC and elsewhere too (IDK enough about the history of econ ideas to know what they're descendants of, exactly). And, ofc, I was way less rigorous with them than Mises is in TMC.

There's also at least one thing I said that Mises refuted in TMC -- we also know that the value of fiat money is derived from legislation; I haven't closely re-read OP to know if there are more. That mistake is a key point behind my argument in n/2002 that Bitcoin isn't fiat, which is the excuse to invent factum money. I now think the entire bottom row of the table in n/2002 is all fiat:

Deferred Value     | Direct Value    |
commodity-backed   | Commodity       | Has non-monetary
Money              | Money           | use value
Fiat Money         | Factum Money    | No non-monetary
Generic IOUs (e.g. | e.g. Bitcoin    | use value
paypal-us-dollars) |                 |

A Light URL Minifier using Flask and Redis

Lambsfry is a URL minifier like or

GitHub repo

Demo -

Introducing Factum Exchange

Note: this post is easier to read on GitHub due to the fixed width ascii diagrams.

In my [first post]( in the factum series I looked at Factum Money, a new category of money which has no non-financial use (or if there is a non-financial use, it is a distance second when ranked by utility), and has no extrinsic requirement to hold value. That is to say, the main utility of Factum Money is as money, and we can see this by looking at the properties of said money and nothing more.

Commodity money and commodity backed money have common non-financial uses and often this is their primary use, and it is thus trivial to see they are not factum money. Fiat money (such as common government issued monies in use today) has no substantial non-financial use, however, by looking solely at the construction of fiat money we can see that it is not guaranteed to have a non-zero value. Most (if not all) of the time fiat money will acquire value through the exercise of authority, which almost ubiquitously takes a legal form.

Bitcoin, however, satisfies both requirements; it is a purely financial instrument (though it's technical implementation leads to other uses, like storing data in the blockchain) and one can see that Bitcoin has a non-zero (or should we say intrinsic) value by a pure examination of the internal mechanism.

Markets and Exchange

Money is a multidimensional problem. Sending value to other parties is all good and well, but there must exist a means of exchanging between monies; without One World Currency there will exist some merchants who won't accept your preferred flavour of money and some clients who don't have any of the flavours you accept.

Traditionally currencies are exchanged in an environment outside the system of money itself. They are walled off from the outside and require specific entry and exit procedures. These procedures are a method of deferring value (mentioned in the first in the factum series). Take the best known BTC/USD exchange: MtGox. The deposit process, for both USD and BTC, involves P1 (the first party) relinquishing their funds, and in return they are issued fungible tokens that operate within the MtGox environment, but are incompatible with any other payment network. These tokens have the unique property (belonging to none of their parents) of being exchangeable for other tokens (denominated in a different currency) on the market provided by MtGox. Thus tokens from P1 are swapped for tokens from P2 (the second party), and both parties direct the value back into their original forms, and the exchange is complete.

By issuing tokens for USD or BTC, MtGox are deferring the value. Put another way, the tokens only have value because of something we know about then outside of their construction: there is a legal gateway allowing value to flow into and out of the MtGox zone.

Because of the similarity in the constructions of tokens in these markets, and the construction of fiat money and commodity backed money, I feel it is appropriate to label these systems Fiat Exchanges. Two forms of fiat money are being traded. No real BTC is traded on the MtGox exchange, only MtGox-BTC -- a petty shadow by comparison.

There exists, however, another form of exchange. In this form the monies themselves are exchanged; not tokens in a segregated environment. When the two of us exchange gold coins for silver, the exchange takes place in an environment native to the subjects of the exchange (in this case the real world). A factum exchange that operates using Bitcoin would satisfy the same criterion; the exchange takes place in an environment native to the subjects of the exchange (the blockchain). Transactions on the Bitcoin network and transactions involved in the exchange are one and the same (in this hypothetical exchange system).

These exchanges, whether they involve real world objects or cryptocurrencies, will be labelled Factum Exchanges. In these cases, the ability for exchange to occur is built into the payment networks -- in the case of gold it is the physical transfer, in the case of Bitcoin it is a transaction on the network. When a factum exchange operates over factum money (and possible some fiat money) there should be no possibility of any particular exchange being censored, blocked, regulated, etc. There should only be two possibilities: the exchange fails (and the original money is returned) or the exchange succeeds (and both parties swap as agreed).

It is possible to host a factum exchange over fiat currencies. An exchange in person, or through banking networks, can be called a factum exchange because value is not deferred from the subjects of the exchange.

A Note on Cryptocurrencies

Although Bitcoin is a form of factum money, not all crypto currency needs to be. One can easily imagine a crypto currency minted by a central bank, and although mining might be decentralised, supply of the money is still regulated by the bank (even with distributed wealth generation). This would count as fiat currency because there is zero assurance (excepting legal agreements) that the currency won't be inflated through the roof. If the private key were compromised this would be an inevitability.

Cryptocurrency could even be a form of commodity backed money, but we shan't explore that here.

Exchange and Distributed Exchange

The Bitcoin community has felt the thorns of regulation for some time. Traditional methods of currency exchange are stifling growth and promoting unhealthy markets (such as we're seeing in the exchange differential between USD/BTC markets on MtGox, Bitstamp, and BTC-e). The Bitcoin community owes it to itself to build tools to better allow for this exchange, and to investigate what is going wrong currently (so we know how and to build, and the purpose of such tools).

The current system looks like this: (using MtGox as an example)

 P1-->MTG-------+                                +--MTG-->P2
USD             |                                |
 P2==>MTG-----+ |                                | +--MTG==>P1   (insert joke here
______________|_|________________________________|_|____________  about never get-
              | |                                | |              ting fiat out of
              | |                                | |              MtGox)
MTGOX         | |                                | |
              | +-M>P1(BTC)----#X->P2(BTC)-D>MTG-+ |

-   : Path of Action, horizontal
|   : Path of Action, vertical
+   : Path of Action, corner; if two paths intersect, their direction is unchanged
.   : Path of Funds in Escrow
>   : Transaction to
#   : Order Placed
•   : Block Produced (alt 8)
X   : Exchange Matched
@   : Proof of Payment
&   : Escrow Unlock
=   : Stress on Path of Action (e.g. Regulation)
M   : Mint coins/tokens
D   : Destroy / Unmint

Cn  : for an integer n, custom action, details provided with graph

P1  : The First Party, always refers to the same people
Pn  : for any integer n, as above
En  : for any integer n, a special escrow account, details provided with graph
PN  : The Nth Party, can be anyone and can be a different party every time
ABC : Three letter abbreviation of a real world entity.

RULES - The following excludes paths and transactions:
- When two icons appear next to each other they are simultaneous. Their order
    preserves causality.
- When two icons are in the same column they are simultaneous.
- If two icons are in adjacent columns but different rows they are not
    necessarily simultaneous.
- If two icons are adjacent and there is a third in a column shared with one of
    these icons, all three are simultaneous.

The regulatory efforts are applied to the fiat entry and exit points, with = indicating where those stresses are felt. The MtGox infrastructure requires value to be deferred into compatible tokens, which is the choke point in this system. If direct person to person transactions in USD were used instead, the regulator pressure would fall away. Unfortunately this isn't able to be checked from within the MtGox infrastructure, and thus relies on manual verification, in turn allowing for a number of attacks that make the system too burdensome to use.

The First Distributed Exchange: Ripple

A system such as Ripple looks like this:

 P1-->BTS---+                                 +-BTS->P2
USD         |                                 |
 P2==>BTS-+ |                                 | +-BTS=>P1
          | |                                 | |
          | |                                 | |
RIPPLE    | |                                 | |
          | +--M>P1(BTC)-#----X>P2(BTC)-D>BTS-+ |

-|+ : Path of Action, horizontal,vertical,corner
>   : Transaction to
#   : Order Placed
X   : Exchange Matched
=   : Stress on Path of Action (e.g. Regulation)
M   : Mint coins/tokens
D   : Destroy / Unmint

It is nearly identical to MtGox, and involves using a payment processor to cash in and out. Bitstamp (BTS) was chosen here as it is a 'gateway' into the Ripple system for both Bitcoin and USD. It can be replaced with any other gateway, though additional steps are required. Ultimately this provides no advantage over the traditional model (see MtGox, above) besides that there are more options to cash in and out (though you have to exchange Bitstamp-USD for OtherGateway-USD as the two aren't fungible). I guess you'd say it's better than MtGox, but not substantially.

Cross Chain Trade

This algorithm is taken from the Contracts page.


-|+ : Path of Action, horizontal,vertical,corner
>   : Transaction to
•   : Block Produced (alt 8)
X   : Exchange Matched

E1 and E2 are both transactions to the following output:
Redeemed by:
    [X] [Sig]

C1 - P1 tells P2 about the transaction
C2 - P1 tells P2 the secret (X) OR P1 spends the TX, making the secret public.

Cross chain trade looks fairly simple, but in reality there is no market built behind it, so much of the communication is manual. This might be solved with some distributed layer over the top, but there is still the issue of P1 keeping X secret, locking funds away forever. There has been a suggested solution to this that involves timeout periods. This makes things a little more difficult:

LITECOIN |    /    \  /    \  /    \

-|+ : Path of Action, horizontal,vertical,corner
>   : Transaction to
•   : Block Produced (alt 8)
X   : Exchange Matched

E1 and E2 are both transactions to the following output:
        [PubkeyYou] OP_CHECKSIGVERIFY OP_HASH256 [HashOfX]
        2 [PubkeyYou] [PubkeyMe] 2 OP_CHECKMULTISIG
Redeemed by:
    0 [Sig] [Sig]
    1 [Y] [X] [Sig]

The flow of information between the Cn events are shown with slashes.
C0 - P2 tells P1 [HashOfY]
C1 - P1 telling P2 the E1 transaction, and [HashOfX], unsigned, and providing
     a reversal transaction R1.

    * R1 is locked for 48 hours
    * Rn is a reversal transaction from En>Pn. It has a lock time far in the future,
      and far from the time the lock time of the other reversal, if it is known.

C2 - P2 verifying E1, signing and returning R1, P2 also tells P1
     about the E2 tx, unsigned, and provides R2.

    * R2 is locked for 24 hours

C3 - P1 verifies E2, inspects R2, signs, and returns. P1 signs R1 and
     signs and broadcasts E1.
C4 - P2 verifies E1 has been broadcast, signs
     and broadcasts E2. P2 tells P1 [Y]
C5 - P1 tells P2 [X], either explicitly or by spending the transaction

In this case the trade will never fail: after R2 becomes active it is unsafe for P1 provide the secret X. Thus, if P1 is unable to redeem E2 she can wait for R1 become active. By placing the burden of providing the secret on P2, the transaction with the first reversal is guaranteed to occur first.

However, the cost of using this method is great; many confirmations are required for individuals to be certain they are safe executing the next step and there is a great deal of time for either party to renege on the transaction after the terms of exchange are set. Furthermore a reorganisation on one chain could lead to one party with both sides of the transaction.

Other Distributed Fiat Exchanges (Hypothetical)

None of these have been completed to my knowledge. They typically allow the creation of assets backed by some value (fiat), or offered IPO style (possibly fiat or factum).

Typically, a generic fiat exchange (GFiX) will take the following form:

 P1-->BTS---+                         +-BRK-->P2
USD         |                         |
 P2==>BRK-+ |                         | +-BRK==>P1
          | |                         | |
          | |                         | |
GFiX      | |                         | |
BTC       | +-M>P1-#-•...•X&>P2-D>BRK-+ |
          |               |             |
USD       |               |             |

-|+ : Path of Action, horizontal,vertical,corner
.   : Path of Funds in Escrow
>   : Transaction to
#   : Order Placed
•   : Block Produced (alt 8)
X   : Exchange Matched
&   : Escrow Unlock
=   : Stress on Path of Action (e.g. Regulation)
M   : Mint coins/tokens
D   : Destroy / Unmint

BRK : Broker

Existing and Future Factum Exchanges


Note: Marstercoin is a layer over Bitcoin (data stored in TXs on the Bitcoin network) and thus blocks occur at the same time. Note: The following may be incorrect. I've scraped together some information but details of the spec are pretty thin.

 P1----------C1#-•X-->P2 •

C1 - Buyer selects order to fill

In english:

  • An order is placed on the Mastercoin network (sell)
  • A buyer finds and decides to fill that order (buy)
  • They publish the order, and away the next block
  • When the next block arrives the orders are matched and the Mastercoin asset goes into pseudo-escrow
  • Once P1 pays P2 in the required specific manner, Mastercoin unlocks the escrow and transfers the assets to P1

One issue is the buyer (of MSC) is able to renege on the trade before it is complete; this, however, is an issue with any asynchronous exchange. The process here is simpler than other asynchronous models because it is only possible to trade between Bitcoin and Mastercoin, and Mastercoin has interchain awareness to Bitcoin; when an order is filled (and paid for) the Mastercoin chain can release funds automagically. A 'pledge' system could easily be implemented to indicate one's intent to purchase. A market system could be implemented to remove the need to choose an order to fill.


Marketcoin is a hypothetical currency/market I've begun to set out here

            +-- P1 places an order on the MKC network to buy (with pledge)
            |    +-- Exchange matched, unacknowledged on bitcoin network
            |    |     +-- P1 sends coins to P2 as agreed
            |    |     |   +-- BTC block mined
BITCOIN            +---------+
 P1---------+----X-+-P1>P2 • |
MARKETCOIN  #    |           @
        |        |           | +-- When an MKC block is mined,
        |        |           |     the MKC in escrow is released to P1
        |        |           +-- P1 provides proof of tx to MKC network
        |        +-- MKC Block produced, exchange matched
        |            P2's funds put in escrow
        +-- P2 places an order on the MKC network to sell

In english:

  • P2 places bid
  • P1 places ask (with pledge)
  • When an MKC block is created and the orders are matched, P2's MKC is put into escrow, redeemable by P1
  • P1 then transfers correct amount of BTC to P2
  • A Bitcoin block is mined including this transaction
  • P1 provides proof of payment to the Marketcoin network
  • When an MKC block is mined, the MKC in escrow is released to P1

Currently, P1 can technically renege on the trade before transacting to P2. However, the order P1 places on the Marketcoin network (this is one of many possible implementations) require a fee to be paid (in MKC) that is proportional to the change of value in the last 24 hours (as that is the escrow length). If the trade times out the pledge is given to P2, so P2 is guaranteed to either make the trade, or receive compensation better than the best case scenario considering the last 24 hours. That is a powerful incentive to trade. This requirement of pledges is not required in symmetric exchange. Proof of payment is another issue; it may be possible to automate this process with deep scanning of the foreign blockchain, but this could easily be too intensive a task, and requires marking transactions on the foreign chain. Manual proof of payment is sufficient at this stage, and with software automation, not a burden at all.

Methods of Operation for Distributed Cross-Chain Exchanges

Asymmetric Exchange

As it stands, Marketcoin is asymmetric.

An asymmetric exchange has different rules on both sides. In the case of Marketcoin, it hosts the order book for both currencies, and Altcoin is unaware of it. This means asymmetric exchanges are backwards compatible (they can be made to 'read' a great many forms of blockchain), so a web between all currencies can be created with only asymmetric exchanges.

As mentioned before, the Marketcoin graph:

BITCOIN              +---------+
 P1---------+------X-+-P1>P2 • |
MARKETCOIN  #      |           @

Using Marketcoin to move between currencies other than Marketcoin is a little more of a burden as the process must be repeated:

BITCOIN              +---------+
 P1---------+------X-+-P1>P2 • |
MARKETCOIN  #      |           @       +--------#--•X.............•&>P3
 P2-----#---------•X.............•&>P1-+  #         |           @
LITECOIN                                  |         | +---------+
 P3---------------------------------------+---------X-+-P3>P1 •

An ideal asymmetric exchange built into two cryptocurrencies looks like:

YCOIN             |  

What is important is this is the only way this could happen. Bitcoin hosts the exchange and Litecoin 'reads' the exchange from the Bitcoin blockchain. This is about half-way to a symmetric exchange where both coins have both functionalities. We explore this graph in more detail later on.

Ignorant and Knowledgable Asymmetric Exchange

There is a clear difference between Marketcoin and an ideal asymmetric exchange. This is because in an ideal case, both chains have interchain awareness and can verify transactions on the other chain. In the case of Marketcoin and an existing cryptocurrency (say Bitcoin), the foreign coin is unable to read the local market (hosted entirely by Marketcoin). I call this ignorant asymmetric exchange, because Bitcoin is ignorant of the fact it is even occurring.

In the counter-case that a foreign chain is aware of the local chain, we can offload buy orders to the foreign chain, which can then enable some escrow like function to guarantee trades are atomic. I call this knowledgable asymmetric exchange. However, to guarantee determinism in such an exchange, buy orders will only be matched once they are learnt about by the other chain, and can only be canceled with the permission of the other chain (they will either be cancelled or a trade will occur before the cancelation takes place).

Combining Fiat Exchange with Factum Asymmetric Exchange

Consider a distributed Generic Fiat Exchange (GFiX). Often such an exchange will have a core cryptocurrency operating beneath the user-defined assets (think Ripples, BitShares, Freicoins, etc) and so should be compatible with a distributed cryptocurrency exchange. Then presume this chain also supports ignorant asymmetric exchange. In such a case it would be possible to buy arbitrary assets on the GFiX using Bitcoin in a trustless, multistep manner. In the best case where Xcoin supports asymmetric cross-chain trade in a similar way to Marketcoin and an asset market, you would experience the following process:

BITCOIN              +---------+
 P1---------+------X-+-P1>P2 • |
XCOIN       #      |           @
 P2-----#---------•X.............•&>P1---#-•X>P3    }
____________________________________________|_____  } Walled off Market
XCOIN-ASSET                                 |       }
 P3----------------------------------#-•...•X&>P1   }

-|+ : Path of Action, horizontal,vertical,corner
.   : Path of Funds in Escrow
>   : Transaction to
#   : Order Placed
•   : Block Produced (alt 8)
X   : Exchange Matched
@   : Proof of Payment
&   : Escrow Unlock

Symmetric Exchange

A symmetric exchange is one where both networks run identical rule sets. Each hosts one half of two exchanges - a 'bid' and an 'ask' order book. Consider MKC and XC, two crypto coins. In the case of MKC, the 'ask' order book is for XC/MKC (the MKC chain is authoritative) and the bid order book is for MKC/XC (the XC chain is authoritative). Likewise, the XC chain hosts an 'ask' order book for MKC/XC (XC chain authoritative), and a 'bid' order book for XC/MKC (MKC chain authoritative).

Technically this is equivalent to two knowledgable asymmetric exchanges running on both chains.

A 'brief' explanation of one possible symmetric exchange

Each market's deterministic execution is decided by the authoritative chain, based on best-effort updates shared between chains.

Side note: If you imagine a cryptocoin hosting 10 markets, not every market needs to be updated every block, in addition, preventing updates increases liquidity at the cost of transaction time. For fledgling, unpopular markets this may well be a positive thing, and evidence in favour of only including market updates for the markets you care about - after all, you'll need to be running those clients. In addition, a very flexible update method such as this lends itself to better compatibility with block chains progressing at different rates.

These best effort updates relay specific information about both order books.

In the case of the 'ask' order book - the market the local coin has authority over - all known but excluded bid updates (from the foreign chain) are amalgamated into a chunk and deterministically matched against the 'ask' order book. The details of the trades made are recorded and packaged into a market update, which is then relayed back to the foreign blockchain in a best-effort fashion. Market updates are recorded in the merkel root (or a similar device) and secured in a chain so one can not be omitted. These are in turn recorded under the full block chain headers of the foreign chain. The deterministic matching happens over one market update. If a local block happens to contain three foreign market updates then all three are lumped and evaluated against the local order book deterministically. This leads to the fairest exchange between all parties concerned. The corresponding market update, when relayed back to the foreign blockchain, alerts the chain which cross-chain escrow transactions may be released and in what proportions (if there is a change address, for example).

In the case of the 'bid' order book - the market the local coin has no authority over - once orders are made the coins are locked and in escrow. All new or changed bid orders are added to the market update. After this update is recorded in the blockchain, in order to maintain foreign blockchain authority, if the user wishes to cancel the order they will have to wait for the foreign chain to recognise and acknowledge the request (one must broadcast a cancel message, record this in a market update, have the foreign coin register this in a market update, and then have the local blockchain recognise that it is finally safe to release the coins from escrow). During this time it is possible the order may be filled and the cancel message will fail.


Let us examine an ideal distributed exchange which operates exclusively on cryptocurrencies; and the path of value (for a Bitcoin/Litecoin trade) looks like:

LITECOIN          |  

LITECOIN          |  

That is to say, in the first case, an order is placed on the Litecoin network (ask for BTC or bid LTC) and recorded in a block. At some other point an order is placed on the Bitcoin network (bid BTC or ask LTC) which overlaps with the previous order on the other blockchain. When this second order is recorded in a block, it is known to have matched with the order on the Litecoin network (deterministically) and is automatically sent (or assigned) to the receiving party. At the next block on the Litecoin network the trade is learned of and the other transaction is performed so the Litecoins are transferred to the receiving party.

Moving form Xcoin to Zcoin through Ycoin - all of which support symmetric exchange:

YCOIN             |  
ZCOIN                         |

By voting on which market updates to accept (from which other cryptocurrencies) and which markets to run, it will be possible to create a dynamic mesh of markets, forming many possible paths between any cryptocurrencies. (In the worst situation, a coin can run an asymmetric market and use that to trade into and out of foreign block chains.)

Finding Efficiency

Every novel technology developed will be hindered by regulation in a unique way. The 'directness' of transferring fiat to crypto is a worry for a number of people (the same people as are behind the steering wheel of regulation). They feel they need to remain insulated from the untested Bitcoin. Perhaps they would feel more comfortable with a bridging technology, such as a cryptocoin pegged to a parent currency, that just so happens to natively interact with a distributed market.

Lets have a look at that, shall we?

 P1==>BRK---+                      +==>P2
            |                      |
CRYPTO:     |                      |
CRYPTO-AUD  |                      |
BITCOIN                |

This, however, will likely not be the first iteration. It is elegant, quick, and efficient, but there are likely to be many sticking points before that can be realised. Firstly, Bitcoin doesn't support knowledgeable asymmetric exchange, and there is a strong possibility that too much regulatory pressure will require CRYPTO-AUD to ship without an exchange. Therefore the first iteration might look something a little more like:

 P1==>BRK---+                          +==>P2
            |                          |
CRYPTO:     |                          |
CRYPTO-AUD  |                          |
MARKETCOIN          #  | +---------@       +--#-•X.............•&>P3
 P2------------#------•X.............•&>P1-+ #   |  +-------@
BITCOIN                                      |   |  |
 P3------------------------------------------+---X--+->P1 •

Not as pretty. Compared to a our current fiat exchanges, this doesn't look that appealing. That said, legally CRYPTO-AUD is far more comparable to a traditional payment processing system such as PayPal. By exploring the edge cases of regulation we can help find the inconsistencies and assist its evolution. An attack on Bitcoin by a Government will necessarily involve shutting down the flow of fiat into Bitcoin as much as possible. One strategy is to create useful technologies that are too similar to existing tech (PayPal, Visa) so we can stand on some very resilient legal precedents and standards if these systems are challenged. These middle ground crypto networks, then, cannot be made illegal without negatively effecting the current corporate monopoly because they are designed to resemble them so much. Whether that's possible is another matter.


We know that regulatory pressure can be applied to restrict a flow of Dollars/Yen/Euros anywhere. While this investigation into distributed exchange didn't identify how to expunge regulatory pressure, it did yield at least one other method of allowing value to move from Fiat to Bitcoin: distributed cross-chain markets for cryptocurrency. By building a PayPal-like network built on Bitcoin and minted/destroyed in the same fashion as PayPal (deposit -> mint, withdraw -> destroy). Ultimately some legal entity must be responsible for the cash-in/out process, but this can now safely be entertained without needing to worry about the regulation surrounding running an exchange - provided there is a cross-chain market out there already.

In addition to this, we've looked at the minimum ideal for a market and found that it is readily achievable with knowledgable asymmetric exchange (better yet, symmetric exchange). We've briefly looked at one way this can be achieved, providing a fast, resilient, cross-chain market that operates as a close to perfect market. We have not investigated this suggestion deeply, though (don't worry, that's coming soon). By extrapolating this across all coins (or even just a few) we can see an interconnected web of markets bridging the gaps between chains.

Where To?

For cryptocurrency to succeed a distributed exchange must be developed linking them together. By leveraging interchain awareness we can build factum exchanges that operate in the domain of the currency itself. Atomic exchange that is intwined in cryptocurrency is a strong motivator for adoption, and by creating a web of markets the canonical boundaries between *coins will be removed.

Efficient atomic cross chain trade is a necessity for the long term viability of cryptocurrency. Using an asymmetric exchange, any user of a *coin can move value into an alternate chain, letting them take advantage of any new innovative features produced on other chains.

Addendum by u/max after 2021-10-27 12:25:22 UTC almost 8 years

Found an old wordpress blog where this was hosted:

How to Secure a Blockchain with Zero Energy

Originally published in the Bitcoin Magazine on January 15th, 2014. Reposted here on 1st April, 2014.

Proof of Work (PoW) is the only external method of powering the distributed consensus engine known as a blockchain. However, at least two alternatives have been proposed, and both are internal to the network (Proof of Stake (PoS), and Proof of Burn (PoB)). This is important as it uses virtual resources obtained within the network as a substitute for PoW, meaning they these methods consume virtually no energy, which has been a concern of late. The figures suggested will only occur in a system of absolute equilibrium (the market is saturated with the most efficient ASICs that are possible to produce), though even if the reality is one or two orders of magnitude lower than predicted, it is still alarming and still must be addressed.

Proof of Stake and Proof of Burn

Both PoS and PoB use similar mechanisms. The auditor makes a sacrifice - in the case of PoS it is coindays (which are difficult to acquire; also a good measure of economic activity), and in the case of PoB it is coins themselves (which are also difficult to acquire). Ultimately, any Proof of {something} must require a cost, whether that be electricity, coin days, or coins themselves.

Herein I suggest a fourth method, very similar to how a term deposit works (in that dusty old banking system).

Monetary Velocity and Value of Money

The equation of exchange tells us that as velocity increases the price should decrease, and when prices decrease the value of each unit of currency increase - this is only the case provided the monetary supply remains constant. In a late-stage currency we would expect a relatively low level of monetary inflation / deflation (as opposed to price inflation / deflation - an important distinction), so we'll discard the concern of constant monetary supply.

In a Proof of Stake fuelled network one is required to hold currency for some time before it is able to be used to mint a block. Because it cannot be used in a transaction it is essentially removed from the monetary supply as it is unavailable for a period of time (not technically true because one can spend it up until it is used to mint a block, be the economic effect is the same either way in terms of velocity). Because the money supply will effectively (but doesn't actually) decrease, prices should also fall by a small amount. One can imagine the network saying Here is a small reward for temporarily removing your coins from the supply and making us all a little more wealthy, *in addition to auditing and securing the network*.

Proof of Burn is used in a similar fashion: coins are destroyed in an unspendable transaction which is not immediately obvious to the network (the author suggests using a P2SH address). At some later date this is revealed and used to create a block. The miner is then rewarded with new coins and/or transactions fees (presumably more than the coins they've burned, else they've made a loss). This is like the network saying Here's a small reward for temporarily removing your coins from the supply and making us a little more wealthy, *in addition to auditing and securing the network*. Huh, that sounds familiar.

While they may sound very similar, there are a few differences in terms of public knowledge. In both cases it is unknown how many coins have been left waiting in the wings (similar to how it is impossible to tell how many bitcoins have been lost or abandoned over the years), though PoB provides a little more specificity allowing us to determine a narrower range of candidates (unspent P2SH addresses) than PoS (which includes all unspent transactions). The volume of coins in each case is also an indicator, as in both cases there will be some effective minimum required. However, PoB implies the number of coins burnt cannot be set in advance as both the date of redemption and volume of burnt coins are unknown. PoS does not destroy coins and so any extra volume of coindays destroyed is less important. These differences are subtle, but may become important as the systems are explored more deeply.

Economically speaking, the basis of both proofing systems relies on relinquishing the ability to use coins for some time. In PoS this is voluntary and the funds are spendable at any time, whereas in PoB uses a rather more permanent operation so the user commits immediately to mining a block in the future, regardless of whether it is profitable or not (provided they meet the difficulty requirement, else the coins may be lost forever; perhaps pooled mining might alleviate this concern, though), but the length of time till that utility will be used is unknown. In this case, as the ability to use coins is relinquished, there is no possibility they will increase monetary velocity and thus should (in theory) increase the value of the each coin in the total supply.

Proof of Deposit

Proof of Deposit (or PoD) fills a medium between the two methods. Simply put, PoD blocks have a difficulty proportional (or equal) to the amount of coins that must be offered for ‘deposit’ and have a known block reward. Deposited coins remain untouchable for some length of time and the block reward is delivered to the miner (either immediately or over a period of time like a dividend or interest payments). As there is one deposit per block there are a limited number of deposits available each year, and if deposits are appearing too fast then the return must be too high, so the difficulty is increased (which implies the return is lowered) and thus demand decreases. Our personified network might once again say “Here’s a small reward for temporarily removing your coins from the supply and making us a little more wealthy, in addition to auditing and securing the network.”

That’s getting awfully familiar…

Why yes, it is. This should come as no surprise, though. What resources are there internal to a currency besides the currency itself? Economically speaking, there’s very little substantive difference between these three methods, and their monetary implications are very similar; the main difference is the physical actions that help it propagate. If, however, humans are psychologically biased to one way over another, then those physical actions are exactly the things that will count in a showdown between these proofing methods.

Does it even work?

This is really the only important question here. If none of these schemes work, do we have a reason to care? A discerning reader like yourself might have noticed something peculiar about these three methods: you need money to make money. Without internal resources existing the network has no fuel.

Peercoin mitigates this concern by using both PoW and PoS in combination to create new blocks. Over time PoW blocks become less frequent and PoS blocks become more frequent, so it should eventually lead to an energy efficient network (or at least more so than the Bitcoin network). Whether this will pan out or not is difficult to say; the reward for attacking Peercoin is far lower than a well executed attack on Bitcoin, and without an increase in Peercoin’s popularity and/or accessibility we might never discover how easy an attack really is.

Where to from here?

The possibility of a zero energy currency is not something that should go without research, but should also be approached with a degree of scepticism. It has been argued that monetary monocultures contribute to financial instability due to the lower resilience of a homogeneous system (compared to one of high diversity). Is it possible that a reliance on internal states causes instability more generally, even in a currency that has no resistance to opt in to or out of? If it is still the case, can we build several different sorts of these systems together to help provide that resilience? Can one network’s security rely on actions in one or several other distinct currencies? These are important economic questions that may have profound consequences for the future of finance; they are novel because systems of this precision have been impossible under legal frameworks, and never before has any person been able to create a truly global currency in their garage. Experimentation is the future of currency, and I am excited to watch it happen.

Efficient Reorgs on Cryptonets

Every PoW driven cryptonet has a state. The state of Bitcoin (and forks) is the particular set of Unspent Transaction Outputs (UTXOs) at the time - essentially the set of all Bitcoin able to be spent.

When a new block arrives, the usual process to update the state is simple:

{% highlight text %} Start with S[n,0] (state at block n) Apply the first transaction from the new block (B[0]) to S

S[n,k] + B[k] -> S[n,k+1] for all k in B

S[n+1,0] = S[n,max(k)+1] {% endhighlight %}

However, what happens when a new block arrives causing a reorganisation of the main chain?

{% highlight text %} . 3a← 4a <-- 3a and 4a are not in the main chain currently ↙ 1 ← 2 ← 3 ← 4 <-- 3 and 4 are in the main chain

5a arrives, causing the reorg:

1 ← 2 ← 3a← 4a← 5a <-- New main chain ↖ 3 ← 4 <-- Old main chain, 3 and 4 no longer in the main chain

In this case block #2 was the lowest common ancestor (a pivot point) of the two competing chains 3a->5a and 3->4. {% endhighlight %}

The problem of reorgs

Let's presume the distance from the lowest common ancestor (LCA) and the new head is n.

Bitcoin et al solve the issue by stepping backwards through time.

Since Bitcoin transactions spend outputs, and outputs may be spent only once, playing the blockchain backwards is trivial:

{% highlight text %} for each transaction: remove it's outputs from the list of UTXOs. add the outputs it spends to the list of UTXOs. {% endhighlight %}

And bam! You can then play time forward from the LCA to calculate the new state. How nice.

What happens, though, when we move to a cryptonet that only operates on balances and doesn't use the input/output system of Bitcoin?

Well, provided we're recording every transaction it's quite simple. A transaction moving X coins from A to B results in A-=X and B+=X. That is trivial to reverse. However, the caveat is that we must record every transaction. Once we start including complex mechanisms within the protocol that produce transactions that are not recorded but simply implied, we can no longer play time 'backwards' as S[m] depends on S[m-1] and without knowing S[m-1] to calculate the implied transactions, we can't play time backwards. Of course, if we know S[m-1] we don't need to do any of this anyway, so we're sort of stuck. Examples of this sort of mechanism can be found in the way contracts create transactions in Ethereum and the market evaluation in Marketcoin.

Remembering S[m-1] is easy but what if the reorg is of length 2, or 3, or 10? We can't just remember all the states.

So, we can see that we have a problem.

Efficiently remembering states

The intuitive solution (to me, at least) is to know some but not all states at strategic intervals between the genesis block and the current head. When a reorg of length n occurs, the network has already committed to evaluating n new states. I define 'efficient' here to mean evaluating no more than 2n new states (in the worst case). Unfortunately, this means we'll need to remember about 2*log(2,h) states, where h is the height of the chain head. All the UTXOs in Bitcoin take up a few hundred meg of RAM, so for 500,000 blocks we're looking at no more than 40 states, but that's still ~10 GB of space (by Bitcoin's standards) which isn't ideal. It's unlikely that we'll see long reorganisations, but we'd still be storing half of the figures mentioned above, which, while better, isn't perfect.

One solution may be to record the net implied change of state as the last transaction, but that solution might be more painful than the cure, and requires introducing extra complexity into the network architecture, which I'm against, so we won't consider this option here.

In addition to the above constraint on 'efficient', we also require that for each block building on the main chain we should only have to calculate one new state (the updated current state). This implies that when we step through the blockchain, we only ever forget cached states, with the exception of the new state produced by the next block.


{% highlight text %} Current head is of height n.

A[n] = {cached states at height n}

Block n+1 arrives:

assert A[n] is a superset of {all a in A[n+1] s.t. a is not of height n+1} {% endhighlight %}

Thus A[n+1] can be described as the set of some or all of the states in A[n] and the state at n+1, and therefore our collection of states does not requrie regeneration on each new block.

I propose a solution below that has a number of desired properties:

  • A reorg of length n requires computing no more than 2n states
  • Space efficient: k states saved where ld(h) <= k <= 2*ld(h)
  • Incremental: only one new state has to be calculated for each new block

{% highlight text %} Initial conditions: - Reorg length: n - Current height: h >= 3 - i = 0; i < h

2k < h - i <= 2k+1 is always the case for some k if h-i == 2: set k to 1. (it would otherwise be 0)

After finding k, and while h-i > 1: 1. Cache states at height i + 2k and i + 2k-1. 2. i += 2k-1 {% endhighlight %}

and in python: (testing all combinations up to 213)

{% highlight python %} import math

h = 3 states = set([1,2])

while h <= 2*13: newStates = set() # find largest k s.t. 2k < h i = 0 while h-i >= 2: k = math.log(h-i)//math.log(2) newStates.add(int(2k)+i) newStates.add(int(2(k-1))+i) i += int(2*(k-1)) ts1 = set(states) # temp set for testing superset requirement ts1.add(h) # add the current state (instead of removing it from newStates) assert ts1 >= newStates # ts1 is a superset of newStates l = list(newStates) # temp list just to print l.sort() print(h, math.log(h)//math.log(2)+1, len(l), l) states = newStates h += 1 {% endhighlight %}

Because of the ~log(n) space requirement a very fast block time is not a major concern. A chain with a target time of 1 minute requires about 1.5x the storage capacity of an equivelant chain with a target time of 10 minutes in the first year, and this ratio rapidly approaches 1 in the following years.

That said, after the first year with a 1 minute block time, we'd be storing around 30 states. If we ignored all states more than 2000 blocks deep (a day and a bit) we're still storing more than 15, which isn't a particularly great optimisation. (When we have events like the Fork of March 2013 we would like clients to adjust quickly and efficiently).

I have some ideas about state-deltas to try and solve this issue (which is ungood, but not doubleplusungood) but that can wait for a future post.

A General Introduction to Marketcoin

Originally published at

Eleven months ago I started planning Marketcoin and since then I've not described the updated design. It has changed significantly since I first described it, and is far superior in many aspects.

Herein I'll describe what Marketcoin is designed to do, sometimes with little or no justification to how it is achieved. The implementation is highly technical and does not belong in a general introduction.

Marketcoin is an idea that manifests in a novel fashion. It's a bit like Bitcoin, and a bit like Mastercoin, and a bit like Ethereum, but also like none of them in many ways. It's not any one single network, but many that are able to communicate and transfer value from chain to chain. They're able to share a common unit of a consistent value across all chains supporting the correct standard. It is self pruning and selects on the most efficient markets, while still enabling diversity and innovation. It is a parallel cryptonet designed to span the Internet and enable trustless trade between both old and new chains.

Markets can be hosted anywhere, on any chain, but there will be a central hash rate source where most market-chains live by default, known as the Grachten. A market-chain may host many markets but the central unit is always common. This communal living is an important design decision for market-chains because it provides an environment where high quality markets can grow that have some level of mutual quality assurance due to their competitive environment. A high quality neighbourhood is important as chains will have to communicate to move the central unit between them; remember that confidence in the chain is inversely proportional to required confirmations, so less secure chains will naturally be slower to interact with their peers. Just as Namecoin is merge-mined with Bitcoin, market-chains can be merge-mined with the Grachten. Unlike the Namecoin / Bitcoin relationship, though, the Grachten has limited space, and it becomes more and more difficult to produce blocks as a miner attempts to include more data. For this reason cryptographic authentication is deferred to the Grachten, providing a competitive environment where market-chains can prove their efficiency. The more coins stored on that chain the higher the block reward is, increasing the incentive for a miner to mine that chain. Two chains competing for the same currency pair will each hinder the efforts of the other, so once one gains a majority the weaker will atrophy until it is discarded.

The main idea of Marketcoin is to provide a fair and unbiased market on which to trade various cryptocurrency and other smart properties. In the same way a human watches the Bitcoin blockchain to wait for payment, Marketcoin watches the Bitcoin blockchain to confirm trades. Since there is some internal unit and an external unit, it is conceptually easy to see that an exchange can take place.

The actual market design used in a market-chain can be of the community's choosing, however, a blockchain provides unique challenges that traditional market structures do not neatly fit. The proof of concept (PoC) due out in the near future will demonstrate a design based on a modified call market. Since orders must be inserted into the order book whether they are executed immediately or not, no distinction is made between orders waiting in the order book and orders made immediately. Due to the near perfect-information state of cryptonets, it's likely a market will react to an order before it is executed - helping to create liquidity and competition around every trade.

A typical market-chain will experience the following phenomena:

  • Every minute or two a market update will be produced, solidifying orders still floating around the network and helping to prevent manipulation on the part of miners - orders are added to the order-book but not executed.
  • Every 15 minutes or so the market will execute, clearing all overlapping trades. This aspect is similar to a call market. Part of the design requires that this cannot be predicted.
  • Orders will be prioritised in terms of how good a 'deal' they are. A user wishing to sell the central unit for very little, or buy at a high price will be preferenced over a user who is less generous in their offer.
  • The highest bid is matched with the lowest ask, and the price of the trade is decided to be the average of the two offers. One or both of the trades is consumed fully and the remainder is added to the top of the respective order-book.
  • This continues until there is no overlap between bids and asks.
  • As a consequence there is no longer a spread in the market, but an uncertainty in the price appears instead. (During simulations this was ~0.3% at a maximum, and usually less; since this is less than or on par with most exchange fees it's counted as negligible. As liquidity rises this error will fall, except in times of volatility.)
  • Furthermore, a large trade at a good price will generate a lot of interest, and the potential of profit will cause traders to actively compete for a slice of the trade.
  • To compete traders must make a generous offer in the other direction, and so their competition benefits the market as a whole, both by increasing liquidity and by helping to maintain price stability.
  • Due to the uncertainty of the market, it is possible to have two opposing trades in the same execution and make a profit (it is also possible to make a loss). Whether this is an advantage or disadvantage is relative to the user in question.

There is a possibility of miners using their power to manipulate the orderbook slightly in their favour before offering a block, however, execution is always at the beginning of a block ensuring only existing orders are executed, preventing too much manipulation on the part of a miner. They can, however, manipulate the orderbook very slightly with every block they produce, so that if the next block happens to invoke an execution they will be slightly advantaged. By analogy, this is the high frequency trading of Marketcoin - both are simply having a say when it most counts.

It should be evident at this point that novel market structures are easily implemented under Marketcoin, allowing the most efficient and desired market structure to emerge. This is an excellent example of the neutrality of Marketcoin's design.

While one market-chain may only support a few currency pairs (more may prove too cumbersome), other market-chains are easy to create and can maintain a two-way peg with the central unit provided a standard is followed. This standard dictates a few aspects important to the network. For example, the rate of central unit generation as a block reward should be proportional to the number of central units stored on that chain and inversely proportional to the block frequency of that chain. Since market-chains are designed to coexist on shared hashing power they have a natural resilience to changes in block production times, and the reward adjusts accordingly.

Creating a new market-chain will be extremely accessible (we're going to provide a library) but maintaining one is very costly (you have to convince people to mine it in a competitive environment). Because of this combination, I anticipate there will be a great evolutionary synergy, whereby there is no central Marketcoin chain and the central unit exists between many chains, abandoning them as they become insignificant and jumping on those that prove useful, novel, or advantageous. The unit of value will be extricated from the confines of just one blockchain, allowing for innovation not just in market structure but blockchain technology - all without needing hard-forks.

Marketcoin is designed to be the solution to distributed exchange: from an ethical launch to evolutionary agility, we want to cover every base to ensure the longevity of such an ambitious project.


The Ethereum devs have been mentioning microchains lately so I figured it was time to write up what my thoughts on this sort of thing have condensed into; they might differ from Gav Wood's thoughts.

As a note, I didn't coin the term microchain, though I've heard Gavin Wood use it (and Stephan Tual). I didn't have a term and I think this is perfect.

The point of a microchain is to provide a shared scalable PoW 'container' - a chain meant for nothing else but wrapping data in a PoW. Typically this has been done in a roundabout way (see AuxPoW or Mastercoin/Counterparty) that requires a lot of data, and is not efficient for any 'piggy-backing' chains hanging off the main chain. This isn't a huge issue; insofar as - in the case of AuxPoW - proofs just go from 80 bytes to ~500 bytes (unless you're using P2Pool or Eligius then it's a bunch more). This is because the whole chain from block hash to PoW must be included, which is Hash(Header(MerkleTree(Coinbase(ScriptSig(BlockHash))))). Ugh!

Additionally AuxPoW has a number of design flaws: using 'chain-ids' to dictate positions in merkle trees is just ugly. The point is to ensure uniqueness in the proof - that you can't secretly include two different block hashes (since data in a merkle tree can be hidden) and later launch a doublespend attack. It's trivial to see that a merkle patricia tree (MPT) is the better solution here as key-uniqueness is guaranteed.

Another flaw is the indirect and bulky nature of the proofs as described above.

A further flaw is the reliance on a central chain: Namecoin will never exist without Bitcoin (or at least requires a hardfork) and necessitates the use of the Bitcoin chain. It would be nice to have a system of merged mining that is coin-agnostic (doesn't favour Bitcoin, basically). Hardforks are bad, lets avoid them.

A related flaw is the dictation of data structure which favours bitcoin-forks. It introduces needless complexity for a ground-up chain to implement AuxPoW.

All in all, using AuxPoW has a lot of side effects, and it'd be nice to be able to avoid them.

Basic microchains

These are minimum structures to fairly support merged mining and general data-inclusion.

(The code is written to be roughly compatible with Encodium.

Intra-chain view

{% highlight python %} class Block: branch = MerklePatriciaBranch.Definition() header = BlockHeader.Definition() transactions = Transactions.Definition()

def valid_proof(self): root = branch.calculate_root(genesis_hash, header_hash) return root < {% endhighlight %}

Inter-chain view

{% highlight python %} class MicrochainBlock: tree = MerklePatriciaTree.Definition( List.Definition( KeyValuePair.Definition( GenesisHash.Definition(), Hash.Definition() ) ) )

def proof_of_work(self): return self.tree.root {% endhighlight %}


  • Ensure genesis keys diverge as quickly as possible; Put a cap on proof length to avoid bloat for fun - putting two very similar keys can create a worst-case proof.

  • Change MicrochainBlock's proof of work to: def pow(self): return hash(self.tree.root + nonce) - this means we have O(1) updates to PoW whereas without this a k,v pair in the MPT must be altered, which is an O(log n) complexity update.

More complex forms

There are a few more alterations I've been thinking of, especially:

  • Making microchains into a blockchain of their own (and the metadata is included in the tree like everything else - this metadata governs targets, difficulty, etc) which will aggregate mining power in a more formal manner. Additonally it means that a chain can just not worry about PoW, and simply take an authenticated list of hashes from the parent chain (for better or worse). And...

  • Deregulating block frequency on merged chains and allowing the microchain to govern update frequency. Which ties into...

  • Competition within the tree. By this I mean merged mining an additional chain incurs some cost, this drastically alters the incentive structures around attacking networks and merged mining (haven't done the math yet to figure out if it even can be benefcial).

Those three points mean the microchain could support many merged chains, and their block frequencies would be governed by how often they are mined in the microchain (and lower frequency means higher reward per block), and with added competition that means they will reach an equilibrium which allows a direct measurement of percieved economic value. More detail another day.


A brief introduction to Ethereum. ~ 20 min.

Bitcoin - Payment Protocol
Technical overview of Bitcoin as a payment protocol and a look into Bitcoin's script system.





Making Money (lost)

Part 1 is primarily concerned with the money creation process (fiat money, fractional reserve banking, and interest) and who benefits from this.
Part 2 is a conceptual introduction to Bitcoin, why it is such a significant achievement, and why it is superior to our current monetary systems.

On Fair Compromise in Price Matching Engines

PDF download

I set the date of n/2036 to the date I made the video, but I don't think that was right. The video was posted, then, sure, but I didn't make the post then. I made the post ~now. I don't think I'll date things that way in future.

Also, I said I post-dated the post, but post-dating refers to dating something in the future (which this wasn't). It was just normal-dating.

Where to find my recent work

I've been focusing on philosophy more lately. During late January I decided to post my self-unendorsement video. I've been adding to my microblog regularly. That is where you should go to find my latest work. I post almost everything I produce to that thread.

For the past few days I have been doing making daily updates to my makeup vlog and will continue doing that for the next week and a bit. I've also created a vanity URL for the playlist: I link the playlist for these videos (and most videos individually) in my microblog, too.

I will continue posting to my microblog. I consider my blog at mostly deprecated -- I don't anticipate posting much here until I find a new blog system.

New Site (Blog/Forum)

If you've visited my site before, you might notice it's different now. It's a complete forum -- the blog part is done through permissions.

The structure is a tree and based on discussion at It's highly customizable and supports things like CNAMEs for sub-forums (which can be ~disconnected from the main forum tree via permissions).

Every node in the tree supports RSS feeds. Hit the RSS button or add .feed to the end of a URL to get the feed.

I've made an Open Discussion node at /n/88 -- you can post whatever there.

Nodes can be viewed as any other type of node; atm there are 3 types: root, index, and topic. Add /as:<view> to the end of a node's URL to view it via that method, e.g. The main forum-nodes have descriptions but -- atm -- those aren't shown except via view-as or the RSS feeds.

Addendum by u/max after 2021-08-28 08:33:19 UTC 1 minute

ATM you need to register an account to post/reply, but anon comments are mb on the cards -- just not a priority right now.

I Support Elliot Temple (regarding ongoing harassment from CritRats; a group lead by DD)

For a summary of the harassment against Elliot and other members of the Fallible Ideas community, see

For the full context of this post, see David Deutsch Harassment Update (, including the comments of that post.

Fan support regarding this major problem would be appreciated.

Source:; published May 22 2021

I support Elliot Temple. Elliot is right, this is a major problem.

The harassers (a small number of CritRats close to DD) are unwilling to take steps to deescalate the situation. They are unwilling to take even the most reasonable of steps to at least coexist in peace. AFAICT, one of Elliot's main goals is to be left alone (by CritRats) so that he can pursue his philosophy work. Elliot's actions are consistent with that goal.

Here is an outline of David Deutsch's position. DD was ET’s mentor, colleague and close friend for over 10 years. He is the leader of a community; they don't have an official name, usually they're referred to by the name CritRats. CritRat is a contraction of Critical Rationalism, the name of Popper's philosophy. This informal group, including DD, tolerate the harassment (or worse).

If you were DD and had written The Beginning of Infinity, a book that claims:

[...] success at making factual, scientific discoveries entails a commitment to all sorts of values that are necessary for making progress. The individual scientist has to value truth, and good explanations, and be open to ideas and to change. The scientific community, and to some extent the civilization as a whole, has to value tolerance, integrity and openness of debate.

— BoI Ch 5, p121 (emphasis mine)

If you had written that, given numerous reports that repeated harassment was being done in your name, do you think it would be reasonable to, say, write a tweet along the following lines? I've recently heard allegations of harassment targeting Elliot Temple by a small number of my fans. I unequivocally denounce harassment, against Elliot or anyone else. It's immoral and, if it is happening, it needs to stop. A tweet like this is not much; it doesn't even acknowledge that a problem exists (just that if it does exist, it should stop). Is that not a reasonable minimum to expect from a philosopher?

DD doesn't post to forums or blogs anymore, AFAIK. He does post to twitter, though. Not one of DD's 10.9k+ tweets mentions 'Harassment'. At what point does this kind of avoidance become negligent? At what point does the issue become bad enough that the leader of the community has a responsibility to make at least some gesture speaking out against bad behavior?

Earlier this year, Elliot had to disable open comments on his blog (after 18 years and over 20,000 comments1) due to the harassment.

When that happened, Elliot provided me with an account (as I'm sure he did for other members of the CF/FI community). Why is this important to say publicly?

[Anonymous:] When critrats inevitably discuss this thread in private, I wonder if they'll consider the restraint you've shown (over years). I mean, those quotes at the end are all at least 10 years old. A decade.

[Elliot:] I fear they'll just say you're my sock puppet and ignore your point. What proof is there that I ever gave anyone else an account?

I'm not a sockpuppet — that's obvious to anyone even vaguely familiar with my history.

DD's tacit approval2 of harassment is unacceptable. It should stop. Offending CritRats should stop. It's not okay.


  2. It's actually worse than just tacit approval. From

    I found out from multiple community members that DD personally contacted them (over 5 years ago) and tried to recruit them to his side and turn them against me. DD did this in writing and I've received documentation.
    I haven't seen that evidence, but I trust that Elliot is being honest. Throughout the ongoing harassment, Elliot has repeatedly shown restraint and respect, and I have no reason to doubt his account of the situation. I've also witnessed the harassment first hand -- in that instance LessWrong moderators acknowledged curi (Elliot) was being harassed when they banned both him and the sockpuppet

Addendum by u/max after 2021-09-11 06:05:03 UTC 23 minutes

This comment (#5) was made by me:

Why I Live (draft 2)

Why do you live?

I live to use my mind to improve my life.


By thinking.

About what?

Ideas worth living for.

Max's Microblog

Self-hosted replacement for

climbing update (28 aug)

I started doing outdoor bouldering about a week ago (we've been in lockdown for the last ~2 months). I found an unclimbed wall that's close enough to home (for current exercise-distance restrictions) and have been working on that recently. I've posted some videos of this to my max's bouldering playlist on YT. I've also documented the wall on theCrag:

Before lockdown I was 4-5 weeks in to my 'send all the purples' goal at my gym (purples are bouldering routes of a particular grade) -- my gym resets a few sections of wall every week and has a 6 week cycle.

Optimal encoding of permutations

This is a repost of a post I made to reddit on June 13th 2017. I found it again recently and wanted to document it here.

The Problem (what's the optimal encoding?)

You have a known list of n candidates on a ballot. In the act of voting, the voter must number each candidate from 1 to n, using each number once. The voter is thus describing a transformation on the list of candidates into a particular permutation. What is the minimum number of bits needed to exactly describe any order, and the method?

My naive approach is to count (from the left) the number of 'jumps' each candidate must take to arrive in their ranked position skipping any previously ranked candidates.

So if we had 3 candidates: cs = ['c1', 'c2', 'c3'] and a list of ranks rs = [2, 3, 1] we'd do this (where zip(cs, rs) matches candidates to ranks):

  • First, c1 should be in the 2nd position, which is 1 move from the far left open spot. Since c1 could move 2 positions though we need to use 2 bits. Record 01
  • Second, 'c2' needs to be in 3rd position, which is also 1 move from the far left open spot (since we skip over the filled position from step 1). Because 'c2' could only move a maximum of 1 jump, we only need 1 bit: record 1.
  • Third, 'c3' trivially fits into the last space, so we need 0 bits.

Our final result is 011.

To decode the permutation, take N bits in the sequence ceil(log(2, n)), ceil(log(2, n-1)), ceil(log(2, n-2)), ..., ceil(log(2, 2)), which is [2, 1, 0] in our case. Use those bits (in this case ['01', '1']) to move each candidate into open spots.

By numerical analysis this method very closely fits O(n Log n) space complexity. (total_bits = 0.89 * n * log(2, n) seems to describe the pattern very closely).

The exact number of bits used will be t = Sigma(i=2, n)( ceil(log(2, i)) ).

It occurs to me that simply listing the positions is O(n log n) too, but the exact number of bits required is t = ceil(log(2, n))*n which is more than my method.

Reddit user tilrman pointed out:

With n candidates, there are P(n) = n! permutations. Each voter selects one of these permutations, so a vote can be represented by an integer [0, n!-1].

2 more comments follow in that branch before I posted my soln

My Solution

clarification: in "base factorial" I'm using base in the same way as base 10 (our number system) or base 2 (binary numbers).

Basic idea is to use factoradics - sort of like base factorial where the kth integer is in [0, k] and to convert back to base 10 you'd multiply it by k!. e.g.: 3210 is 0*1! + 1*2! + 2*3! + 3*4!. Also 4321 + 1 = 10000 which is 1*5! = 120 in base 10.

These numbers uniquely enumerate permutations for a list of n unique elements and allow one to 'read' the permutation from the number. e.g. [a, b, c, d, e] in permutation 2310 leads to [d, c, a, e, b]. Put a in 2+1th free slot, put b in 3+1th free spot, put c in 1+1th free slot, put d in 0+1th free slot, put e in the last spot.

This means we can map all integers in [0, n!-1] to a unique permutation (via modulo-ing and subtracting successive factorials), and back again quickly and efficiently (though arbitrarily sized integers (e.g. in python or haskell) make this much easier than small integers - 150! is like 110 bytes long as a raw integer)

Finally a sanity check: for a list of k elements we have a maximum count of (k-1) (k-2) ... (k-k+1) where each bracketed expression is a digit. If we add 1 we end up with 1 followed by k zeros, which corresponds to k!, and so our maximum integer is 1 less at k!-1 which is what we expect :)

Louis Rossmann Vids

I like a lot of Louis Rossmann's videos and his thoughts.

This topic is for discussing and collecting good ones. Here's two; one recent, one old

*Freedom* and *Universality* are linked

I think freedom and universality must have some deep connection.

If you have the freedom to do something, that means -- wrt that context -- you can do whatever you like. You're unconstrained; that aspect cannot (or at least should not) be a bottleneck.

That gives you some unboundedness wrt method, or content, or whatever the freedom relates to. Freedom of speech removes a bound on speech. Freedom of thought removes a bound on thought.

Freedom enables universality; and without certain freedoms, you cannot have certain universalities.

I thought that freedom and thinking were like orthogonal; both necessary for philosophy and good life, but neither sufficient. Now I suspect there's more there than I realized.

climbing goals - gyms reopen

Climbing gyms (and everything else) have just reopened (for the vaccinated) in Sydney, following a ~3.5 month lockdown. Now that climbing is frequent and regular again, I've been reconsidering climbing goals.

Before lockdown, my goal was to send every new grade 31 (out of 6) problem, every week, for 6 weeks (I'd done 5 weeks when lockdown started). 6 weeks is a full rotation, so achieving this means that I would have consistently been able to project any purple in 2-3 sessions. The purpose of this goal was to emphasise consistency over results (better to do be capable of any grade 3 problem than some grade 3 and some grade 4).

The current goal I've settled on is to send every grade 3 climb (in the gym) in a week -- there's about 24 or so (give or take depending on what gets set). I sent 10 this morning (over about 2hrs). I don't think I'd have been able to do that if I hadn't done some outdoor climbing during lockdown, tho. So far, so good. I have been going through them methodically, with a few exceptions (picking ones I thought I could do towards the end of the session, for example). So far no grade 3 has been particularly challenging, though crowd-beta has helped a bit. Major bottleneck atm (session-to-session) is probably endurance -- going to monitor that and take corrective action if it doesn't improve this week.

  1. the problems are color-graded, so grade 3 of 6 is purple, and 4 of 6 is black. there's no precise conversion to V-grades, but I guess purple is V2-5 and black is V4-? (6 or 7, maybe). 


Correction: I sent 13 / 25 purples (grade 3) on Monday.

I sent 9 of the remaining 12 this morning. so only 3 left for Friday morning -- lots of buffer!

I also sent my first grade 5 (yellow)!


I sent just 1 of the remaining 3 purples on Friday.

The current goal I've settled on is to send every grade 3 climb (in the gym) in a week

WRT this goal, I could go again this weekend, but I think it'd be better to rest. That means I'll fail the goal. What happens wrt the goal then?

The purpose of the goal was to build consistency and mastery of a particular grade. Or maybe, that's what the goal aligned with -- it wasn't, in and of itself, to master the grade. Rather, it was a breakpoint that I chose which aligned with master. If I didn't meet it, then it's a criticism of the idea that I've mastered that grade. Mastering a grade isn't a quality I'd lose unless I stopped climbing, though (or had some injury or something). So what does failing this goal really mean?

Well, I'm not yet inconsistent when it comes to purples (since I had been sending them all prior to lockdown) -- so more time's needed to determine that. It is a criticism of mastery though; it means there are still bottlenecks at this grade.

The reason I chose the original parameters that I did -- 1 week to send every new purple for a full cycle -- was that 1 week allowed for reasonable buffer, and a full cycle meant ~25 new climbs. New routes are set Tuesday-Thursday, so 4 days of the week were the period of stability before the next wave. Once those new climbs were set, a failure to send one that was taken down is a decisive criticism of both consistency and mastery. Also, sending all the new routes (before the next wave was set) meant that I'd have excess capacity to try new climbs, or work on bottlenecks.

Even without sending every purple, I still have excess capacity -- different climbs use different resources. And since I shouldn't lose the ability to send-every-purple if I keep improving, why would I ever stop?

I think mb goals like this are sometimes motivating (they have been to me) but there's a problem if you get invested in them. That's because failing a goal is, like, something to take personally. But that isn't what these sort of goals are really about. A goal like this is a regular opportunity to take a benchmark -- and mb find a weakness in your abilities that you didn't know was there. Knowing about that is a good thing! If you don't know it's there (or if you know and ignore it) then it becomes a thing you can't rely on. That's a problem if it ever needs to be foundational to other, more advanced knowledge. (Like, it's a dependency.)

This is consistent (and I think related) with a different idea: achievement of goals is pointless if you're not challenged. There's no point in me setting a goal if I know it's already too easy. The achievement is hollow.

Moreover, if there are always meaningful goals to choose -- meaningful problems to solve -- then choosing goals that are foregone conclusions must be meaningless. My guess is that -- for some projects -- it is moral to choose meaningful goals, and immoral to deliberately choose meaningless goals when meaningful ones could be chosen instead. (Sometimes those projects/decisions only impact a single person, in which case they're probably amoral -- that's okay. Morality is about interpersonal harm, and people are free to live their own lives (wrt themselves) how they wish. People are also under no obligation to maximize morality -- just to not act immorally -- so provided there's no malice, most goals are okay.)

Getting back to purples: I think new climbs is an important breakpoint, so I'm going to monitor that going forward. I'm also thinking I'll adopt the send-every-purple-every-week goal again, indefinitely -- it's a useful warning sign of bottlenecks, and means there's some variance in my excess capacity (which I can use to my advantage). Maybe a good breakpoint to re-evaluate at is some level of consistency with blacks, like sending >50% each week. That seems reasonable atm.

Addendum by u/max after 2021-10-23 03:59:29 UTC 7 days
I was so very wrong about morality and interpersonal harm.

I've read Galt's speech.

In n/10017 (the parent of this post) I said:

Sometimes those projects/decisions only impact a single person, in which case they're probably amoral -- that's okay. Morality is about interpersonal harm, [...].

I was so very wrong about this. Morality does concern one's actions, since some actions are right and some are wrong. But morality is not about harm (interpersonal or otherwise), at least, no more so than it is about rocks.

I am starting to understand.

I'm not sure enough, yet, to say what morality is about -- I could try, but I don't want to rush it. I want know it before I claim to know it. Soon, I will be sure enough.

I'm grateful that JustinCEO (on the CF forum) noticed this part of n/10017 and challenged me on it, and I'm grateful that he and ingracke found it worth their time to discuss it with me.

I am grateful for Ayn Rand -- her life, her works, and most of all: her mind. Right now, I'm grateful particularly for Atlas Shrugged.

I have a special gratitude for Elliot, not only for his participation in the above-linked thread (among many other things, too many to list here), but also -- and, right now, primarily -- for his labor, dedication and ideas that safeguard the closest thing I've ever known to a sanctuary.

Why do I express my gratitude? I admire their virtues. Why am I grateful? Their virtues have allowed me to profit, and I will continue to. And I know that they have and will, too.


Of those two problem purples, I sent one on Monday evening, and one on Thursday evening. There were 6 new purples this week (3x set on Tuesday, and 3x on Thursday). On Wednesday morning I sent the 3x new purples that were set on Tuesday, and on Thursday evening I sent the 3x purples that were set that day (and 2x of the blacks that were set that day, too).

I made a video of 43 attempts at a particular boulder, played over the top of eachother at the same time.


Source code:

The method is documented in the repo readme.

`giphy-dl` script (in the style of youtube-dl for giphy)

make sure to chmod +x it and should just work (provided you have curl and extended grep support)

#!/usr/bin/env bash


if [ -z "$FILENAME" ] || [ -z "$2" ]; then
  echo "usage: $0 GIF_NAME GIPHY_URL_OR_CODE"
  exit 1

CODE_FROM_URL=$(echo "$GIPHY_CODE_OR_URL" | egrep -o 'media\/([A-Za-z0-9]{12,})\/giphy' | cut -d '/' -f 2)

if [ -z "$CODE_FROM_URL" ]; then
  CODE_FROM_URL=$(echo "$GIPHY_CODE_OR_URL" | egrep -o '[A-Za-z0-9]{12,}')

echo "saving to: $FILENAME.mp4"
echo "dling gif from: $GIPHY_CODE_OR_URL"
echo "giphy code: $CODE_FROM_URL"

curl "$CODE_FROM_URL/giphy.mp4" --output "$FILENAME.mp4"

xdg-open "$FILENAME.mp4" || true
self limiting lets you maintain excap

e.g., governor

  • relevant to learning
  • redlining in a controlled env can be useful for like measuring progress or something, but that shouldn't be the norm
  • by maintaining excap one can ensure there's room to move -- buffer. that's important while learning b/c you're focusing on creating new organization of knowledge and reorganizing existing knowledge. trying to learn without excap is like trying to do tetris with no v-space. with lots of v-space tetris is manageable, but it gets hyperbolically harder as you approach the top.

re long-running learning conflict: the more exploratory side means exhausting excap quickly (manageable when surveying, but not when trying to complete a project).

ffmpeg script: mod-video-speed

this script will speed up (or slow down) video and audio via ffmpeg.

put the following in e.g., ~/.local/bin/mod-video-speed and chmod +x it.

#!/usr/bin/env python3

import subprocess
import sys, re

this_file = sys.argv[0]
filename = this_file.split('/')[-1]
args = sys.argv[1:]

if len(args) != 3:
  print(f'Error: need 3 args but you provided {len(args)}. {args}')
  print(f'\n\tUSAGE: {filename} INFILE OUTFILE SPEED')
  print(f'\n\tINFILE: input file (source)\n\tOUTFILE: output file (destination)')
  print(f'\tSPEED: the speed of the output video in the format `2x` or `1.43x` -- must end with `x`')

in_file = sys.argv[1]
out_file = sys.argv[2]
speed_raw = sys.argv[3]
speed_pattern = r'([0-9]+\.?[0-9]*)x'
speed_re = re.match(speed_pattern, speed_raw)
if speed_re is None:
  print(f"Error: SPEED argument did not match `{speed_pattern}`\n\nExamples: `1x`, `0.5x`, `123.456x`, `99x`")
speed = float(speed_re[1])
pts_speed = 1./speed
print(f"Processing {in_file} and modifying video speed to {speed}, outputting to {out_file}.")

ffmpeg_cmd_list = ['ffmpeg', '-i', in_file, '-filter_complex',
                   '-map', '[v]', '-map', '[a]', out_file]
print(f"Running ffmpeg cmd: {' '.join(ffmpeg_cmd_list)}")

license: public domain

sydney boulder series 2021 results archive

archiving for my own future purposes + i don't know if this is replicated anywhere else on the web.

  • round 1:
  • round 2:
  • round 3:
  • round 4:
  • combined 1,2,3,4:
  • combined 1,2,3:
  • participant info pack:
Open Discussion

You can post whatever you like here. Also, anyone else can post whatever they like, too.

This section is inspired by

You will never be punished, censored or moderated based on your ideas. You can disagree with whatever you want, advocate whatever you want, and even flame people. The most anyone will do to you is write words back or stop listening. Messages are neutral ground where everyone is equal; there are no special privileges.