




do we need this link?
3063 description >


Asset-based, fast & efficient alternative to Bitcoin

Alternative payment systems based on implementations compatible with the principles of Askemos could be build and it had several advantages:

  • faster transactions
  • better privacy
  • less traceable
  • higher security (long term and per transaction)
  • the method already enjoys legal backing ("Wechselgesetz")
  • economic backing of value

Bitcoin is a peer-to-peer distributed system designed to allow payment transactions without the need to trust a third party.

Askemos is a peer-to-peer distributed system designed to allow arbitrary transitions - explicitly including financial transactions - without the need to trust a third party.

Both provide the required non-repudiation of transition - the overlap is rather obvious. This text will compare the systems based on the original bitcoin paper and some further research.

The first sections focus on similarities and differences of the technical underpinnings. Then we describe the important difference in the way new money is created. This process is essentially a lottery in Bitcoin (which some critiques even denounce as a pyramid scheme). The herein proposed scheme models more closely traditional schemes.

We argue that the resulting system would be more adept at supporting a stable, valuable electronic currency. Not only does it operate faster than Bitcoin it requires far fewer resources to work. (A smartphone would do.) Further it creates actual, asset-backed money following the established processes and laws. (In this respect the proposal is in agreement with the remark in the bitcoin wiki : "The apparent over-pricing of bitcoin from the perspective of people engaging in short term transactions will encourage the creation and adoption of competing systems.")

Measurements against money laundering could be applied, yet the resulting money would still be more akin to traditional cash insofar as there is no public ledger of all transactions required, which is often seen as a privacy violation.

Full disclosure: the author of this memo is the author of Askemos. While I'm trying to be objective expect some bias.

Remark: beware the term "trusted". A "trusted" entity has the ability to break your assumptions (e.g., security policy). Trustworthy is the opposite concept.

A first note from the congress: I just learned about - this seems to work somewhat similar to Askemos. Just specialized to financial transactions. So far I learned:

  • The "ledger" in ripple appears to be equivalent to a "place" in Askemos.
  • A node (host) on a ripple network appears to support at most one ledger, while Askemos requires the replicates to be a property of the place.
  • I have not been able to find out how to confine transactions to a certain group of nodes.


Transactions in Bitcoin are defined as updates to the state of a coin following a well defined procedure. To compare with Askemos terms we need to replace "coin" with the more general "place" - an active container to store and manipulate arbitrary state, readily applicable to ownership and transfer of some coin - and "procedure" with "contract" or "code". At this point the similarity becomes obvious to the point that one is tempted to take Bitcoin for an Askemos system applied and specialized to financial transactions.

Bitcoin like Askemos works by digitally signing the current state together with the hash of the previous state. The result is kept available, and is distributed to various parties for independent audit.

The difference lies in the details.

Non-Repudiation - Countering Sybill Attacks

Both systems ensure non-repudiation of transitions via independent audit within a network. Any attack to convince the network to accept fraudulent records must be futile. A Sybil attack would try to do so using many auditors, which would in fact be sock puppets controlled by the attacker.

Bitcoin is an "open join", public network. Any peer can participate in the audit process. To do so the full list of transitions (the "block chain") is publicly available and copied to the peer. A cost in the Gigabyte range. Sybil attacks are countered by reducing their chance to succeed. To that end it requires proof-of-work and waits for a while after some transaction is accepted. The process takes about 10 minutes and wastes a lot of energy.

With Askemos it is also possible but entirely optional to keep the full chain of previous states and hash codes (in the form of a Merkle tree) permanently available.

This is possible because Askemos counters Sybil attacks in a different way. In general Askemos follows here the principle seen in human society, where witness is used to establish a fact in front of the legal system. There are two possible methods.

The alternative is to have witness commissioned to support a certain case. These can be related to the case - like e.g., the owner and receiver of a coin - or professional notaries.

This alternative is a "closed join" group: the group must itself keep control who joins because enough malicious members can tamper with the state of the place (coin) once they reach the two-third quorum. Furthermore above a certain number of peers, transition frequency would again become too low.

Note that "closed join" does not reduce the utility of the method to create a payment system. To the contrary as we shall see.

The closed join version has the advantage that the system can just believe the current state as kept by the quorum and therefore drop the chain of past transactions.

Since old owners of the coin may have limited interest to still witness the coins history, those could drop out from the set of commissioned peers making room for the representative of the new peer to join the group.

Liveness - Countering Denial Of Service Attacks

DoS Via Network Load

With the size of the network and the total value perceived in the payment system the probability of attacks increases. Recently Bitcoin developers are reported to even consider the use of satellites to ensure network connectivity in case of DoS.

We propose instead to resort to a different network topology. Instead of distributing the knowledge about all coins everywhere, clusters of notaries should maintain each only subsets of the whole coin base.

DoS Via Scripting

Both Bitcoin and Askemos provide a scripting layer.

To counter DoS attacks Bitcoin uses a FORTH-alike scripting system, which is not Turing complete.

Askemos builds on a Turing complete scripting system. (The " shebang" language being based on Scheme). To counter DoS via non-terminating computations, the runtime system will terminate scripts running consuming excessive amount of time.

This leaves an Askemos based system with more freedom to implement complex applications. Those will be required to implement distributed, intrusion resistant and autonomous applications as required further down to issue new coins.

Rollout Of New Versions

With Bitcoin the most of the code executed to when performing transactions is part of the client. When details (e.g., transaction fees) are to be changed, the clients must be updated.

Askemos in contrast maintains a fixed association between a running place (a process) and the contract (a program script) executed during transitions. The contract script is yet another, static place and replicated the same way within the network as the process itself. Likewise changing details would be done by issuing new money having the new properties and gradually phasing out the use of old places. We'll see below how this is easily an inherent part of the normal operation.

Forward Safety - Signatures

Bitcoin being a full protocol with a single purpose is naturally more specific than Askemos. Within Bitcoin a digital signature is always a cryptographic digital signature. Those rely on trust in a long living secret key. If this secret is compromised the bitcoin is lost.

Anticipating advances in cryptanalysis any cryptographic primitive may be broken some day. Worse even, the public depends on the benevolence of the person or agency who discovers the solution of the underlying hard problem to publish this discovery.

A payment system should not depend on such a weak premise in the long run. The whole system would become obsolete and all money becoming useless at once with no warning.

Askemos supports booked signatures. Those are a derived from circumstantial signatures during the witnessed signing process. Each peer verifies the cryptographic signature right at the time it receives it and keeps a record (again in the Merkle tree) about this verification. Optionally including the cryptographic signature as received. These booked signatures do no longer depend on the secret required to establish the signature.

See here. TODO: should this table be embedded here?

For high-value transactions is is furthermore recommended to employ additional guards. Transfer of high-value coins should for instance require a set of one time passwords (TAN). One TAN per witness (notary). These can be kept physically separate from the users representative.

This independence from cryptographic signatures plays well together with the byzantine fault tolerance of applications: loss of personal representatives does not necessarily imply loss of the money. The lost representative will harm no more than a malfunctioning one. All it takes is to issue replacements for the credentials of the owner.


As recent development has shown the privacy gained from a public key being anonymous - as mentioned in the original bitcoin paper - is not as encompassing as hoped for. Bitcoin is in this respect the opposite of the traditional banking system.

Within an Askemos network an alternate currency is easy to build. A coin would be just a place.

Instead of being public, it would have to be supported by the owner and at least three additional witnesses. (For the sake of byzantine fault tolerance. In practice it turns out to be easily possible to have more than 10 witnesses distributed over WAN and still perform transitions within less than a second.)

When the coin is spent, the receiver would join the group and one representative leave it. Only the members of the group would be able to follow the flow.

Money Creation

So far we have proposed some alternatives to the Bitcoin protocol, which would simply improve properties: faster transactions, reduced memory and bandwidth hunger, increased flexibility and reduced reliance on assumption about the feasibility of various attacks. We foresee little to no objections with respect to the desirability of these topics.

Now we will consider a matter of agenda and policy: the process by which the monetary supply is increased. The following proposal is entirely different from bitcoin.

Before we go describe the proposal, we want to remark that by design of the Askemos system, such issues are not at all part or in any way tied into the core system. They are entirely a matter of contract scripts as executed by the network. Alternatives and variations, regulatory constraints etc. could all be built into these contract scripts.

Critiques of Bitcoin

  1. Money creation (minting in Bitcoin terms) in Bitcoin is tied to the Proof-Of-Work as used to counter Sybil attacks. By design this is essentially a lottery. At the time of writing this amounts to: only those wealthy enough to own "big iron" and able to pay a huge electricity bill can reasonable hope to win in the lottery of the minting process.

    This sounds unfair.

  2. Bitcoin is due to its absolute limit of monetary units inherently deflationary. This, too, is sometimes seen as a non-desirable property. We will not discuss, whether or not this is a desirable property. Instead we want to design an alternative currency and let the users decide which one they like better.

  3. Bitcoin proponents often compare it with rare valuables like Gold being used as a currency. This argument appears to be flawed. Those precious metals have a value as raw material. In case of default the owner of the coin can still recover at least that value.

    The raw materials value of a bitcoin is zero. It's impossible to use even for decoration and jewelry.

An Alternative Model - Drafts, Banks and Currency

Within an alternative based on Askemos, we would have to come back and find a different way to issue new coins.

I'd propose here to use the age old, proven and and already legally established way to rely on bills of exchange (draft).

(Note: this section is of this article is a draft and far from ready for release. I'll need to help wrt. the legal English terms.)


A draft (as in "bill of exchange" and not to be confused with "half completed paper" here) is a debt which is valid for a limited time.

Within Askemos we can not only implement "just coins". A place could be any document. Hence it could be such a promise to pay. Since it's tamper proofed, we can rely on it without trusting any party.

The advantage of bill of exchange over bitcoin is obvious. The value of a bitcoin is purely speculative. At the time of writing we see a boom. But it's hardly reasonable. As with all speculative assets. At any time the value can drop sharply, leaving the investors with a huge loss. (Added: few days later after this paragraph was written bitcoin value about halfed within three days.)

A bill of exchange however is backed up by the liability of any party in the chain of previous holders. Therefore first party to accept a draft will already evaluate the issuers ability to pay.

A drawn draft is almost as negotiable as money is, because there are at least two liable parties. In case of default the holder has still a reasonable probability to receive the full payment or at least recover a substantial part of it.

History has seen a decline of use of drafts in the past years. This is usually attributed to the fact that electronic payment and accounting systems have struggled and failed to model practically this payment instrument. The first part of the paper outlined how this road block can be overcome.

Independent from the fashion and history of the past years, the bill of exchange is informal speaking typically considered as a required precursor to create a valuable "real" currency. We believe that it is an indispensable necessity to properly include this preliminary stage into the landscape of electronic payment systems.

This believe corresponds to the observation that computer implemented operations mirror processes in human history quasi in fast motion. By way of example compare the history of organisation within operation systems and now cloud offerings, the latter are compared by security experts (see Bruce Schneier) to the structures of feudal societies.

Best of all: The basic idea of a draft is already backed up by the legal system. Worldwide or at least almost world wide.

The rules governing a bill of exchange are simple and well understood. They establish a contract which is a perfect fit to be implemented as a contract script in Askemos. We'll implement this next.


Atop of the draft-based "pre-money" (which employs personal liability) any group interested issuing their (local) currency could easily set up a network of at least four, better seven notaries. Those would have to run a "bank" application, which would issue coins for drawn drafts.

Such money would be akin to hard cash, backed by economic assets. It would be traceable at most within the limits of the banking network even though those could trade it for money valid within other such networks. Thus it could provide much better privacy than the global ledger ever could.


The rules how precisely banks may or did accept drafts as security to issue money in some currency differ. The same will be the case with Askemos based virtual money. Rules will apply per currency.

This allows us to establish and comply with local laws regarding money laundering and control local economic incentives via supply of money. At the same time the negative side effects of a unique global currency can be avoided.



  • faster transactions
  • better privacy
  • less traceable
  • higher security (long term and per transaction)
  • legal backing of the principle
  • economic backing of value
3060 created > 2013-12-21 19:35:39 +0100
3061 creator (reg.) > jfw

14 comment