Askemos

Help: This page shows how the referencing
vocabulary definitions are maintained and interlinked for
controlled consistency of documentation. Click on the hyperlinks
to see how the terms are defined within the Askemos architecture.
more… Tip: Remember the back-button!

This page has three main sections. (Note that the listings could
be empty.)

The first item displays a term, URL, text or picture.

Followed by a (still unordered) listing of statements about
this subject. (for details follow ">"-link)

Separated by a horizontal rule a "reverse" listing of
statements referring to this item in object position.

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 ripple.com
- 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

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.

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.

Privacy

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

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.

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.

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.)

Drafts

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.

Banks

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.

Currency

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.

Conclusion

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