<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc subcompact="no" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>

<rfc ipr="trust200902" docName="draft-vanrein-monee-reqs-00" category="std">

<front>

	<title abbrev="Monee Requirements">Requirements for Domain-Issued Currency (Monee)</title>

	<author initials="R" surname="Van Rein" fullname="Rick van Rein">
		<organization>OpenFortress.nl</organization>
		<address>
			<postal>
				<street>Haarlebrink 5</street>
				<city>Enschede</city>
				<region>Overijssel</region>
				<code>7544 WP</code>
				<country>The Netherlands</country>
			</postal>
			<email>rick@openfortress.nl</email>
		</address>
	</author>

	<date day="27" month="January" year="2022"/>

	<abstract>
	<t>Monee allows people to operate a currency under a domain name,
	using a monetary system that expresses value added, not debt.
	Currency is intentionally created where and when value is added,
	and destroyed where and when value is destroyed.  Inflation is
	possible, but revealed as a temporary blot on a currency.  New
	currencies are bootstrapped locally and may then expand in
	expanding circles.</t>
	</abstract>

</front>


<middle>

<section title="Introduction" anchor="intro">

<t>This requirements document introduces the currency design of Monee,
along with the data and procedures that are needed for it.
The design is abstract, framing the requirements of an interoperable
protocol.</t>

<t>TODO: Much of the Introduction section is interpretation, and not
technical.  Unsure whether this should stay here, but some introduction
into the underlying concepts of Monee are necessary, somewhere.</t>

<t>Monee supports two economic schools of thought;
TODO-check-literature-for-details:
it defaults to the Austrian school of economics around Mises and Hayek,
where money is fully backed, like under the gold standard;
it can also support Keynesian economy of inflation through
partial reserves as a temporary approach to growth.  A core value of
Monee is that it makes this distinction abundantly clear, and enables
markets to trade with fully backed currency with individual exceptions
being made outside of such markets and based on detailed information
about the level of inflation.  Gresham's law suggests that users
will prefer fully backed currencies.  Currencies with partial backing
complicate the negotations because of the risk involved.</t>

<t>Monee can achieve price stability, and has no need for any
interest rate.  Rather than borrowing and debt, the concept of
the currencies is to show added (real) value.  For bootstrapping
of new initiatives, early adopters may choose to share in the risk
and possibly receive a higher award upon success.  Islamic banking
bans interest, and has shown similar mechanisms to work well.</t>

<section title="History of Currencies" anchor="intro.history">

<t>During barter trade, two persons swap goods at a negotiated ratio.
Using money as an intermediate value, barter trade can be split into
two transactions.  These halves of the barter trade no longer need
to find each other to trade directly.</t>

<t>The first forms of money were coins from valuable materials like
gold or cocoa beans; or they were rare natural things like sea shells.
When these monetary forms were replaced with debt statements, they
became easier to handle.  But paper statements are easy to produce,
so it was however necessary to trust the party who issued such
debt statements.  Initially, debt statements were issued by gold smiths
who stored gold in their vaults; later, this became a service of
national banks.</t>

<t>Given the convenience of handling money, stored gold is not taken
out a lot, and it could be assumed that only a part of it would
ever be called for, which paved the way for betrayal, wherein more
debt statements were issued than covered in gold.  This is called
inflation.  More debt statements represent the same productivity
and the market mechanism renegotiates prices; after some time, the
purchasing power of a debt statement is lower.</t>

<t>Inflation used to be done in secret, and later publicly introduced
as a temporary measure.  Having learned that it is never reversed,
the democratic variant on secrecy is to present it openly but in an
incomprehensible manner.  Deflation, which is the reverse process,
calls upon the original over-spending party to destroy their debt
statements, which is a painful encounter with their over-spending;
it corrects the purchasing value, but this advantage is evenly spread
over all other debt statements.  So it calls upon a party to weaken
its own position to benefit others.  Deflation is highly unlikely
and is rarely implemented.</t>

<t>The situations worsens when inflation is not measured as a
coverage ratio of debt statements divided by its backing, but if it
rises as an annual percentage.  This means that purchasing power is
continually being eroded, and discourages long-term savings such as
pensions.  It also suggests towards fast consumption, instead of
investing in future purchasing power.</t>

<t>Since inflation benefits those who release debt statements, it
disadvantages those who work to add real human value to an economy.
The result is a financial industry that trades with excessive
amounts of money that have no relation to the amounts of money
available to people who are actually productive.  Also, without
democratic controls over how this money is spent, it has become
completely uninteresting to the financial industry to deal with
the small amounts of money involved in sustaining productivity.</t>

<t>Inflation causes current savings to reduce in purchasing power
in the future.  This is a motivation for consumption, rather
than saving or investing for future financial resilience.  This
triggers consumption, even if this is unwise in the long run and
makes humanity as a whole consume more resources than our one planet
can sustain.</t>

<t>Under inflation, people with more money than they can spend
see their posessions erode, unless they invest it somewhere.
A common structure is then to apply an interest rate to
compensate for inflation, compensate for a risk of defaulting
and perhaps add extra for profit.  Interest works as a money
pump from those who lack money to those who have it.  Contrast
this to Islamic banking, where the lender partakes in business
risk and profit, often with some control over how the investment
money is put to use.  Combining this system of investment with one
free of inflation, there would be no principal cause left to hamper
price stability.  Investing always incurs a risk, and should never
be done with money that cannot be missed; in this light, it is a
good sign that price stability takes away the pressure to invest.
Those with money to invest can use it to help develop the economic
activity of others, and may spread their risk by relating to
more than one other.</t>

</section><!-- anchor="intro.history" -->

<section title="Monee as Transparant Currency" anchor="intro.transparent">

<t>Monee permits inflation, but only as a local property of a currency,
and it is blatantly clear.  This clarity will usually limit trading
partners to those who want to support a new business initiative, and
who are willing to take a temporary risk while it is starting.  As
long as the value added exceeds the value taken for it, there is a
possibility for profit, which allows the currency to deflate and
evolve to one that is fully backed.</t>

<t>From then on, there is no longer a need to risk inflation and
price instability when trading with this currency; as long as
growth takes a careful pace, it can be fully backed by
confirmations of having added value.  By constraining trading
partners until this point, it is now beneficial to the currency
issuer to deflate it to the point where value has been added.
Any excess value can be spent freely in trading, both in support
of uncertain new initiatives and for everyday trading with fully
backed Monee currencies.</t>

<t>TODO: Find a way to represent interest, outlandish as it may be to Monee.</t>

</section><!-- anchor='intro.transparent" -->

<section title="Monee as Network Currency" anchor="intro.monee">

<t>Monee uses network connectivity to allow people to trade directly,
and express offering of value by minting
their own currency.  Value is considered to have been added when it
is confirmed by another who cancels some of their own currency in
return for it.  This might be called a trade, but the currency is
an expression of value added rather than a debt statement; under
the Monee system, being rich is the same as having been useful to
others.</t>

<t>Monee needs to establish a market mechanism, both to find the
exchange ratios between currencies and to establish trust in any
statements made for a currency.  The exchange ratio must leave
room for mutual profit, so the ratio is not the same in both
directions, but comparing them is a possible factor to consider
when evaluating trust.  Other elements of this trust evaluation
are the degree of overlap in mutually trusted relations.  Parallel
and sequential paths via such relations can be used to derive a
suggested trading ratio between the currencies.  This information
is free for interpretation by anyone (and their software should help
with this) and will depend on individual taste and the level of
risk that one can tolerate.  In the absense of inflation it does
seem reasonable to expect price stability by default.</t>

<t>Contrast that with speculation, like on markets for bulk
goods (rice, beans, ...) which works by predicting their
future prices and trading them through bond futures, causing
a rise in the sales price of such bulk goods.  This benefits
traders but is financed with inflated money and can raise the
cost of living for the poorest on the planet.  Such derived
financial products are difficult to make with Monee.  Debt
is transferrable, but that is not true for confirmations of
value-adding, nor for promises of such future confirmations.
Without interest, many financial derivatives are impossible.
Price stability takes away most gambling power, because it
makes Monee currency owners less prone to accept uncertainty,
in the interest of their own purchasing power.
TODO:IS:ALL:THIS:CORRECT?</t>

</section><!-- anchor="intro.monee" -->

<section title="Monee as Humane Currency" anchor="intro.humane">

<t>Monee currencies work like a wallet.  Currency increases in
return for work, and it decreases when taking out value added
by others.  This is how everyday money works.  The difference
is that the wallet has its own currency, which is created when
and where value is added, and destroyed when and where value
disappears.</t>

<t>Being empowered to create currency astounds many, but it
allows Monee to express added value, rather than owning someone
else's debt; Monee has a more constructive approach to money.
Most considering money creation get naughty, imagining the
minting of piles of money, but they soon realise that money is
not a purpose of its own.  Their real wish is purchasing power,
which calls for trust in the currency, and inflation backfires
on that.  Inflation has bad karma in Monee, and modesty forbids
from boundless creation of currency.  This makes Monee a tool for
achieving price stability.</t>

<t>The ability to create money is an open invitation to people
to think about how they can earn it.  Put differently, how they
can be producers rather than mere consumers driven by market
powers.  Even the backfiring effect of inflation should not be
a show-stopper, because it is simpler than monetary restrictions
imposed by banks, employers and governments.  Most people can
be useful to others in ways that they themselves find trivial;
it is social and economical to let that develop.  Variety in
currencies has been shown before to empower people who failed to
function under the stifled mechanisms of national currencies.</t>

<t>A vital part of Monee is that it can be bootstrapped from
small communities, without any call on outside funding.
Barter trade is the simplest way to establish trust between
local peers, but more elaborate schemes can also be founded
in local trust.  An initial currency may be inflationary,
and show for it, but locality can provide an alternate basis
of trust and help a new initiative to get started by sharing
in its risk.  To this end, promises to future payments may be
considered acceptable, as an explicit inflationary form of
spending but possibly at a different exchange ratio than would
have been the case without inflation.  All this can be done
without a bank.</t>

<t>Note how this means that interest is not required under
Monee.  Interest is a problematic concept, because it rises
at an exponential pace while pumping funds from those who
need it to those who already have it.  To achieve price
stability, one should not engage in offerings with interest
rates but instead be open to differentiated pricing to reflect
variations in risk.</t>

<t>Most businesses generate a profit at some point, and this
allows them to deflate their currency.  Since inflation is
blatantly obvious, it quickly becomes a personal wish to get
it out of the way.  Providers who started off with inflated
currency will see the gradual drop in inflation and that
would keep them happy.  In general, businesses may need to
pop in and out of inflation, and the amount of inflation
can be taken as a sign of some despair.</t>

<t>When businesses mature, they will start looking for more
customers.  This would be a gradual process, based on an
expanding network where potential customers judge their
connectivity to a new business relation based on overlap in
networks.  Initially a new business may be mostly isolated
from anyone else, but it is normal for the network to spread
and bring new customers in reach.  This may call for more
uncertainty, increasing with distance.</t>

<t>This mostly repeals branding strategies of marketing; the
network offers word-of-mouth as a better recommendation,
and there is little use to instignate some perceived value to
give the product a superficial gleam; this would work when
customers are disconnected, but connections between them may
easily lead to ridiculing an inaccurate gleam.  In short,
this model is not a yellow-brick road to World Domination.
It is not expected to scale at an exponential pace, or to a
monstrous size.  This may make it more supportive of diversity
and less of monotonicity.</t>

</section><!-- anchor="intro.humane" -->

<section title="Monee as Transition Currency" anchor="intro.transition">

<t>Inflated currencies erode purchasing power.  Such currencies 
are unfit to save money in, but the same effect eases the
burden of payback on a loan.  Governments are aware of this, and
sustain loans over very long periods, if not indefinitely.</t>

<t>Monee can offer price stability, and is therefore likely to
become a currency of choice for everyday trading (according to
Gresham's law).  It is also a more likely form of savings,
possibly with 100% backing by commodities such as gold.</t>

<t>This may cause users to move away from inflating currencies,
which can be tolerated if it happens at a calm pace.  Cash
withdrawal pulls inflated portions away from financial markets,
but if those are expected then it is feasible to prepare
for the change.  In the asymptotic case, only loans would
remain in these inflationary systems.  These could be based
with 100% covering commidities that the banks take out of
circulation.</t>

<t>Monee can also be used to express inflationary national
currencies, posted under the domain names of (central) banks.
This would release vital trading information in an easily
understood form, and may be seen as part of democratic
accountability.  It may also be used for risk assessment
while trading it with Monee currencies.  Monee considers
a (central) bank as any other user who mints their own
currency.</t>

<t>Governments are encouraged to interact with Monee and not
force their citizens to convert to an inflationary currency.
History has often shown that it empowers citizens to welcome
alternate currencies, provided they can be normally earned and
spent.  Being able to interact with one's government in terms
of these alternate currencies offers great protection in
times that a national currency fails.  This yields protection
from such catastrophies as runs on a bank, attacks on banking
infrastructure, hyperinflation and bursting bubbles.  This
protecion works for citizens as well as their government.</t>

<t>This transition may well remove funds from financial
markets.  This should reduce investments with unbacked
currency that drive up prices of bulk goods such as corn
and soy.  It will also improve the ratio between the
circulated debt and any commodities held by (central) banks,
and thereby deflate their currency.  The trick is now to
use this change to remove inflation completely, and grow
into a fully backed currency.  The adoption of Monee as a
payment system for everyday trade is likely to incraase
sensitivity for partial reserve, and make a currency less
acceptable if it is inflationary.  After all, under Monee
a (central) bank is just another creator of money.</t>

<t>It is a good idea to have standardised exchange options,
which remove money from one system and inject it into another.
The exchange task may involve a mix of accounted storage of
cash with audited destruction of superfluous cash.  Such
things might be organised by individuals, under guidance of
a bank's statements as to what no longer constitutes legal
tender, but this is could be a bit messy; it does not
benefit monetary stability if people start posting videos
in which they give public proof of an exchange by burning
uniquely numbered bank notes.  Standard exchange options
should be helpful to smoothen any such transition.</t>

<t>Assuming that everyday trading converts to one with
stable prices, it would be riskful to take out loans that
incur an interest rate.  The model of Islamic banking is
the more attractive form of external funding, bringing
participation and financial guidance instead of relentless
payment obligations with a worst-case risk of bankruptcy.</t>

<t>This transition is expected to reestablish trust in the
financial industry, and a gradual process as described above
is probably a more desirable process than waiting for the
rupture of banks and their currencies.</t>

</section><!-- anchor="intro.transition" -->

</section><!-- anchor="intro" -->

<section title="Currency Identitification and Naming" anchor="currid">

<t>Monee currencies are identified by a public key and it has a
starting time that is incorporated into every signature with the key.
Signatures are used to commit to balance sheets and transactions.
Detached signatures are summarised in a distributed hash table,
rendering the signed information undeniable because the currency
looses control over publication locations.</t>

<t>Besides an identity, a currency can have any number of names
that consist of a domain name and a currency name.  The currency
name may be prefixed with "+monee+" (without quotes) to form a
user name; for a domain name ecb.int and currency name euro,
a URL-style name +monee+euro@ecb.int can be used with
protocols like email, chat or telephony.  The domain name is
used to locate a database that can provide balance and transaction
details to match the signature information found in the distributed
hash table.  Aliases could exist, but the signing key that forms
the identity is the only way to engage in minting transactions.</t>

<t>During its life, a currency may add or remove names.  There
may be multiple consecutive names, but for the same identity
they must represent the same information.  In times when a
currency has no name, it cannot be operated.  This specification
considers only domain-based names, but future extensions may add
variants.  Not all implementations may be able to connect to all
names of a currency, and the domain-based form should be a fair
default scheme for most general uses.</t>

</section><!-- anchor="currid" -->

<section title="Balance Information and Transaction Information" anchor="balance">

<t>To support the functions of a Monee system, parties must learn
of each other's currencies by way of a balance sheet with standard
items that software can evaluate to guide policy-based decisions.
The information that is made available aims to balance between the
privacy of individual trades and the purpose of establishing how
a currency developed in history.</t>

<t>Transactions take place on two balance sheets at the same time,
and each has its own currency and value.  In addition, conflict
resolution may call for third party involvement.  The following
symbols will be used to change the balances in the respective
currencies used for the role:
<figure><artwork><![CDATA[
VAR   CURRENCY/ROLE   MEANING

 $1   producer        amount of currency
 $2   consumer        amount of currency
 $3   arbiter         amount of currency
 #1   producer        arbitration fee
 #2   consumer        arbitration fee
 #3   arbiter         arbitration fee
]]></artwork></figure></t>

<section title="Basic Balance and Transactions" anchor="balance.basic">

<t>This is an example of a basic balance sheet for a Monee currency:
<figure><artwork><![CDATA[
Liquid     123   Minted         7
                 Valued       116
         -----              -----
Debit      123   Credit       123
]]></artwork></figure>
Transactions often make an atomic change to two balances:
<figure><artwork><![CDATA[
1.Liquid  123   1.Minted     7          2.Liquid  479  2.Minted    0
                1.Valued   116                         2.Valued  479
        -----            -----                  -----          -----
1.Debit   123   1.Credit   123          2.Debit   479  2.Credit  479
]]></artwork></figure></t>

<t>TODO: Find a way to represent interest, outlandish as it may be to Monee.</t>

<t>In this picture, the posts have the following meaning:
<list style="hanging" hangIndent="6">
<t hangText="Minted">is the amount of currency that is
	currently created, without having been confirmed as
	"value added" by another currency.</t>
<t hangText="Liquid">is the amount of currency available
	for spending.  Since it rises along with Minted, this
	value is increased as part of inflation.</t>
<t hangText="Valued">is the amount of currency free from
	inflation.  This value equals the Debit sum minus
	the inflation, which is found in all other Credit
	posts.  In this simple balance sheet,
	Valued = Liquid - Minted.</t>
</list>
In this simple balance sheet, inflation is defined by Minted.</t>

<t>The following table summarises transactions that operate on these
balance sheets:
<figure><artwork><![CDATA[
TRANSACTION   PRECONDITION        UPDATES

create                            1.Minted += $1, Liquid += $1

destroy       $1 <= 1.Minted,     1.Minted -= $1, Liquid -= $1
              $1 <= 1.Liquid

value         $2 <= 2.Valued,     2.Valued -= $2, 2.Liquid -= $2,
              $1 <= 2.Liquid      1.Valued += $1, 1.Liquid += $1

devalue       $1 <= 1.Valued,     1.Valued -= $1, 1.Liquid -= $1
              $1 <= 1.Liquid

barter2       $1 <= 1.Minted,     1.Valued += $1, 1.Minted -= $1,
              $2 <= 2.Minted      2.Valued += $2, 2.Minted -= $2
]]></artwork></figure>
Note how value does not change 2.Minted but just adds the value as new
liquidity.  Minting is a currency-local operation.  Devaluation exists
for symmetry but does not usually make any sense; it deletes information
about approval.  Barter trade is mutual value-addition.  The pattern is
simple, with an example shown for 2 people.  Unlike the value transaction,
the barter operation does not implicitly create currency.  The reason is
that barter trade always occurs with both parties present.</t>

<t>Note how barter trade offers an elegant mechanism for bootstrapping
currencies; first each currency mints currency to represent goods
available for barter trade, and after completing the barter trade they
have shown the value of the goods they traded by way of the currency.</t>

<!-- Nice illustration:
     https://en.wikipedia.org/wiki/File:Barter-Chickens_for_Subscription.jpg
-->

</section><!-- anchor="balance.basic" -->

<section title="Bootstrap Balance and Transactions" anchor="balance.bootstrap">

<t>As an extension to the basic balance, this adds a few posts that
help to bootstrap a currency:
<figure><artwork><![CDATA[
Liquid     123   Minted         7
                 Promised       6
                 Future        20
                 Valued        90
         -----              -----
Debit      123   Credit       123
]]></artwork></figure>
Transactions often make an atomic change to two balances:
<figure><artwork><![CDATA[
1.Liquid  123   1.Minted     7          2.Liquid  479  2.Minted    0
                                                       2.Promised  6
                1.Future    20
                1.Valued    96                         2.Valued  473
        -----            -----                  -----          -----
1.Debit   123   1.Credit   123          2.Debit   479  2.Credit  479
]]></artwork></figure></t>

<t>In this picture, the posts have the following meaning:
<list style="hanging" hangIndent="6">
<t hangText="Promised">is the amount of currency that we used
	to confirm added value in other currencies.  Normally
	that would lower the Liquid post, but initially that
	may be too low and so the Promised post is increased.
	Soon after the Liquid is high enough, both the Liquid
	and Promised posts will be reduced.  Promise!</t>
<t hangText="Future">is the amount of currency for added value,
	but the ones expressing that needed to raise their
	Promised post instead of lowering their Liquid post.
	The value in Future moves to Liquid at the same time
	as the reduction of Liquid and Promised in the other
	currency.</t>
<t hangText="Valued">is the amount of currency free from
	inflation.  In this simple balance sheet,
	Valued = Liquid - ( Minted + Future + Promised )
	although the total amount of appreciation is
	then Valued + Future, but assuming that might take
	in a risk from this currency.</t>
</list>In this balance sheet, inflation is defined by Minted + Promised + Future.</t>

<t>This example balance shows the two sides of a promise in one
balance sheet; this is not always combined.  Once in stable operation,
a currency is likely to have no Promised post left, but it may still
support others through the Future post.  Those others then have the
matching Promised post.</t>

<t>The following table summarises the new transactions that operate
on these balance sheets:
<figure><artwork><![CDATA[
TRANSACTION   PRECONDITION        UPDATES

promise       $2 <= 2.Minted      2.Promised += $2, 2.Minted -= $2,
                                  1.Future   += $1, 1.Liquid += $1

monetise      $2 <= 2.Promised,   1.Future   -= $1, 1.Valued += $1,
              $2 <= 2.Valued,     2.Promised -= $2, 2.Minted += $2,
              $1 <= 1.Future      2.Valued   -= $2, 2.Minted += $2
#TODO# CHECK THIS CAREFULLY, DISAPPEARS TWICE FROM 2.Credit?!?

deliver       $2 <= 2.Promised,   2.Promised -= $2, 2.Liquid -= $2,
              $2 <= 2.Liquid,     1.Future   -= $1, 1.Valued += $1,
              $1 <= 1.Future
#TODO# CHECK THIS CAREFULLY, DOES NOT DISAPPEAR FROM 2.Valued?!?

defect        $1 <= 1.Future      1.Future   -= $1, 1.Minted += $1
              
#DROPPED# $2 <= 2.Liquid,\n$2 <= 2.Promised,   2.Promised -= $2, 2.Liquid -= $2,
]]></artwork></figure>
Note how promises show up as inflation until they are delivered by
the consumer or monetised by the producer; promises are like
holding a promise to payment without having turned
it into money.  Defecting on a promise is considered a destructive
step to take, but it stops weighing on this inflation post.</t>

</section><!-- anchor="balance.bootstrap" -->

<section title="Conflict Balance and Transactions" anchor="balance.conflict">

<t>It would be harmful to stability if a statement of added value could
be retracted.  On the other hand, trading conflicts are a reality that
should be dealt with.  In fact, showing (unresolved) conflicts as part
of the balance information can provide useful information.  This option
exists for those currencies who intend to promise confliction resolution
to simplify the formation of new trust.</t>

<t>Disputes should not be a one-sided mechanism to overpower a currency.
Disputes made by parties who complain all the time must be considered of
lower impact on a currency's trustworthiness than complaints by parties
who rarely complain.</t>

<t>A complaint about falsely provided information, such as suppressing
a transaction or forking another sequence of balances is considered
well-founded, and can be formally verified.  Temporary downtime of a
database may end up as unfounded when the currency comes up in
reasonable time.</t>

<t>Procedures to settle a conflict may start with an attempt by the
currency issuer to correct any problems.  When this is not considered
reasonable, a mutually agreeable third party may be asked to provide
arbitrage.  To enable such settlements, the parties should allow the
third party to control the currency booking, which they reserve on
special balance posts.  The arbiter may require additional funding of
the procedure by the loosing party.</t>

<t>When trading conflicts is raised after a party adds value to our
currency, we need a few more balance posts:
<figure><artwork><![CDATA[
Liquid     123   Minted         7
                 Argued         0
                 Debated        3
                 Arbiter        1
                 Valued       112
         -----              -----
Debit      123   Credit       123
]]></artwork></figure>
Transactions often make an atomic change to two balances, and not
shown here, may even update the balance of an arbiter:
<figure><artwork><![CDATA[
1.Liquid  123   1.Minted     7          2.Liquid  479  2.Minted    0
                                                       2.Argued    1
                1.Debated    3
                1.Arbiter    1
                1.Valued   112                         2.Valued  478
        -----            -----                  -----          -----
1.Debit   123   1.Credit   123          2.Debit   479  2.Credit  479
]]></artwork></figure>
Note that the Argued post is on the
client side of an argument while Debated and Arbiter sit
on the serving side.</t>

<t>In this picture, the posts have the following meaning:
<list style="hanging" hangIndent="6">
<t hangText="Argued">is the amount of currency that was
	subtracted from Valued in exchange for services,
	but that is now being questioned.  The other side
	will first save the value in their Debated post
	and may later move it into their Arbiter post.
	When settled, Argued is reduced by the amount and
	either Valued or Minted is raised.</t>
<t hangText="Debated">is the amount of currency that was
	Valued but later gave rise to discussion.  This
	may apply to all or part of the added value.  It
	may be resolved between the two currencies, or a
	mutually agreeable third may be asked to listen
	in.  When settled, Debated is reduced by the
	amount and either Liquid is reduced or Valued
	is raised again.</t>
<t hangText="Arbiter">is the amount of currency that was
	Debated but with no mutual resolution it has been
	forwarded to a third party for arbitrage.  When
	settled, Arbiter is reduced by the amount and
	either Liquid is reduced or Valued is raised
	again.</t>
<t hangText="Valued">is the amount of currency free from
	inflation.  This value equals the Debit sum minus
	the inflation, which is found in all other Credit
	posts.  In this simple balance sheet,
	Valued = Liquid - ( Minted + Argued + Debated + Arbiter ).</t>
</list>
In this balance sheet, inflation is defined by
Minted + Argued + Debated + Arbiter.
The reason to include Debated is that it is not Valued and may be
a sign of inflation.  Individual policies for trust in currencies
may of course override this, and choose to not take Debated into
account as part of inflation.</t>

<t>The conflict resolution operations reference a prior transaction,
but they introduce their own values for $1 and $2 which must not
be higher than in the referenced transaction, and whose ratios must
match that of the original transaction.</t>

<t>The following table summarises the new transactions that operate
on these balance sheets:
<figure><artwork><![CDATA[
TRANSACTION   PRECONDITION        UPDATES

debate        $1 <= 1.Valued      1.Debated += $1, 1.Valued -= $1,
                                  2.Argued  += $2, 2.Liquid += $2

settleF       $1 <= 1.Debated,    1.Debated -= $1, 1.Minted += $1,
              $2 <= 2.Argued      2.Argued  -= $2, 2.Valued += $2

settleU       $1 <= 1.Debated,    1.Debated -= $1, 1.Valued += $1,
              $2 <= 2.Argued,     2.Argued  -= $2, 2.Minted += $2

escalate      $1 <= 1.Liquid      1.Arbiter += $1, 1.Liquid -= $1

rulingF       $1 <= 1.Arbiter,    1.Arbiter -= $1, 1.Minted += $1,
              $2 <= 2.Argued      2.Argued  -= $2, 2.Minted += $2,
                                  1.Minted  += #1, 3.Valued += #3  TODO:BALANCE

rulingU       $1 <= 1.Arbiter,    1.Arbiter -= $1, 1.Valued += $1,
              $2 <= 2.Argued      2.Argued  -= $2, 2.Minted += $2,
                                  2.Minted  += #2, 3.Valued += #3  TODO:BALANCE
]]></artwork></figure>
After a debate is opened, the two parties may reach a mutual
settlement, and if that fails then the Debate can be escalted
to a mutually agreed Arbiter to pass a ruling.  The settle and
ruling transactions can be any composition of F/U partials, for
founded/unfounded.  Arbitration costs an amount #3 which is
split over #1 and #2, and also into F/U partials.  The ratios
between $1 and $2 (and $3) is always the same as in the debated
transaction, as is the case for #1, #2 and #3.  After handling
a conflict, funds may be dumped in Minted, which may then be
cleaned up locally by destroying that amount of currency; take
note that a few changes in one transaction may add up.</t>

<t>Monee may develop to standardise conflict resolution procedures
and funding mechanisms.</t>

</section><!-- anchor="balance.conflict" -->

<section title="Balance and Processes" anchor="balance.process">

<t>Operations on balances are restricted to a few well-known
transactions.  These transactions have preconditions.  In addition,
some transactions are follow-ups on other transactions and must
be the only follow-up.</t>

<t>Yet another constraint on transactions is that they are signed
by a deciding party, which is usually the one whose currency is
disadvantaged.  The other party can keep a copy and has proof at
any future time if a transaction was to be removed.</t>

<t>The following table shows per transaction who will sign the transaction
and for follow-up transactions which other kind it may reference:
<figure><artwork><![CDATA[
TRANSACTION   SIGNER     REFERENCES

create        producer   -
destroy       producer   -
barter        TODO:??    -
value         consumer   -
devalue       producer   -

promise       consumer   -
monetise      producer   promise
deliver       consumer   promise
defect        producer   promise

debate        consumer   value
debate        TODO:??    barter
settle        producer   debate
escalate      producer   debate
escalate      consumer   debate
escalate      consumer   settle
ruling        arbiter    escalate
]]></artwork></figure></t>

</section><!-- anchor="balance.process" -->

<section title="Storage Considerations" anchor="balance.storage">

<t>Transactions occur in all currencies impacted by them.
One currency is generally disadvantaged, and this is the one
to sign the transaction.  The other end can use the signature
to enforce the existence of the transaction.  It is considered
an offense if such a transaction is removed from either side,
and a reason for corrective measures, possibly even discrediting
the failing currency so spending it becomes difficult.</t>

<t>Old trading history may be summarised to accommodate privacy,
as long as it continues to assure inclusion of past transactions.
Bloom filters tuned to a low risk of false positives accommodate that.
The entries would be hashes of issuer-signed agreements with
others, which those others may at any time test for presence
of a transaction.</t>

<t>Balances and intervening transactions are combined into a
Merkle tree.  This is helpful for verifying that no changes
were made in previously committed records.  Committing such
balances is done by signing the Merkle tree outcome with the
currency's public key and publishing the result.</t>

<t>The Merkle values are computed as follows:
<list style="symbols">
<t>The initial Merkle hash is computed over the starting time
and the public key.  The initial balance is not explicitly
incorporated; its balance posts are all-zero and its timestamp
is the starting time.</t>
<t>Other currencies may be referenced by this same hash,
computed with their starting time and public key, and
also no initial balance.</t>
<t>Each transaction is hashed as its binary representation
followed by the binary representation of the new balance,
including the hash over its starting time and public key.</t>
<t>Each balance is hash as its binary representation, including
the timestamp for the balance, the balance posts and a Bloom
filter incorporating all the binary representations of other
currencies changed in transactions since the preceding balance.</t>
<t>After one or more transactions, a new Merkle hash is computed
over the previous Merkle hash, a list of transaction hashes in
time order and a balance hash that applies at the end.</t>
</list>
The last value is signed by the currency's public key, and
published in the distributed hash table as a follow-up to the
prior Merkle hash for the then-latest balance.  New currencies
start by publishing the initial Merkle hash to make such a
then-latest balance available.
</t>

</section><!-- anchor="balance.storage" -->

<section title="Technology Considerations" anchor="balance.techno">

<t>Merkle trees are sensitive to their input formatting;
this should be a canonical form, with a unique representation
for every combination of data values.  The traditional format
for such security requirements has long been DER, and newer
approaches have stuggled with these requirements, so DER still
seems like the best option.  DER includes framing of the
encoded data.</t>

<t>To retrieve data from a remote server, we can benefit from
abilities such as search, synchronise and access control.
It is useful to point to a database server from DNS records
<xref target="RFC2782"/>.
There is only one portable database protocol that goes this
far with its standardised support, and that is LDAP
<xref target="RFC4511"/>.
It also happens to integrate well with DER (it uses the more
general BER format for the protocol).</t>

<t>The publication of data in a distributed hash tree calls
for a network; ideally, this is a generally agreed-upon form,
such as Kademlia (which currently is not standardised).  The
contents of Kademlia would point from one signed Merkle tree
to the next one.  An interesting variation might be GNUnet,
which more difficult to attack because its route starts with
a few random legs.</t>

</section><!-- anchor="balance.techno" -->

</section><!-- anchor="balance" -->

<section title="Paths between Currencies" anchor="paths">

<section title="Evaluating a Foreign Currency" anchor="paths.eval">

<t>TODO</t>

<t><list style="symbols">
<t>Inflation of a currency is defined as the sum of Minted and Promised
posts.  It should not be considered relative to Valued and/or Future,
because scaling with current size expresses support for exponential growth,
which may impair diversity.  To benefit stability and quality, it is better
to consider inflation as a ratio of the considered ValueAddition.</t>
<t>Minting is a sign of inflation, and must be considered carefully.
Liquid businesses have it set to 0, young businesses may be a bit higher,
but it is a sign of growth and that may interfere with diversity.
If minting is allowed to be a percentage, it would support exponential
growth, rather than a linear pace from fixed minting where individual
attention can be applied.  When considering minting, consider it in
relation to the value that is about to be added.</t>
<t>Futures are a sign of being helped out to develop or grow.  It is
a sign that others expressed trust, although it matters who they are
and whether they are actually trying to pay on their promise.  This
means that Futures are something to consider carefully, but not to
reject too quickly.  It depends on the willingness to investigate.</t>
<t>Promises are a sign of having started to help out others, but when
the Value post is high enough, then a Promise is a sign that this work
is not finished, stopping the supported party from getting started.</t>
<t>When the distributed hash table points to a newer balance, consider
what caused this surprise.  Your cache may need updating, but the
currency's database should never be behind.</t>
<t>Trust should be combined with the above to derive a risk estimate.
The precise computation is a matter of local taste.  When clients
decide what the norms are, then sellers can choose how selective they
want to be.  The model should not load the decision code into clients,
so as not to replicate the privacy assaults that have become the norm
under HTTP.</t>
<t>Exchange rates that differ wildly in the two directions may be
considered suspect.  See the next section for suggestions of a
trading ratio.</t>
</list></t>

<t>Monee may develop to standardise requirement profiles.  This
probably starts with choices between software configurations.</t>

</section><!-- anchor="paths.eval" -->

<section title="Suggesting a Trading Ratio" anchor="paths.ratio">

<t>Any expression that a foreign currency has added value is paired
to a reduction in a visiting currency.  This calls for an exchange
rate between the two currencies.  A prior exchange rate could serve
as a hint, especially because a system without inflation can offer
price stability.  In lieu of such history it can be useful to suggest
an exchange ratio.</t>

<t>Suggested trading ratios are never more than a suggestion; they
may be accepted or rejected by either side.  The best derivations
consider a risk for various trading ratios, thereby giving grounds
for negotiation and even supportive of policy automation; payments
for online media access can be more riskful than for physically
sending gold nuggets.</t>

<t>Any paths between the two currencies can be taken into account,
but the relationships for adding value form a directed graph, and
the opposite relationship is strictly unrelated.  Sequential paths
between the two currencies can each suggest a ratio, and these may
be multiplied to find the path's overall ratio.  Parallel paths
may be taken as alternatives, and a (weighted) average, possibly
with standard deviation, can be used to combine their suggestions.
Finally, overlapping portions of parallel paths may be applied
with a reduced weight to allow equal impact by all legs.</t>

<t>Monee may develop to standardise ratio calculations.  This
probably starts with choices between software configurations.</t>

</section><!-- anchor="paths.ratio" -->

<section title="Trusting Currency Information" anchor="paths.trust">

<t>Monee is not different from other currencies when it comes to trust,
but a network of individual currencies does need to evaluate trust more
carefully.  Central banks conceal the relations of their currency to
other currencies and, increasingly, debt of bankrupt nations and
financial crisis circumventions.  Their currency is a package deal,
and we can take it or leave it.  Monee allows everyone to make their
own decisions while trading.</t>

<t>The reason why people trust money is rather pragmatic: "Will it
buy me what I need?" and, as part of that, "Will it still be good
in the future if I accept it now?"  To be accepted, alternative
currencies always need to take care of this, even if the default
currency is in a deep crisis; mistrust in an old system does not
make people accept a new system until these issues are addressed.</t>

<t>A conservative approach to these questions is 100% backing in
an asset such as gold.  It is a sufficient condition, but not a
necessary one.  Care should be taken not to resort to debt papers,
and continue to focus on added value, but other than that it may
well be possible to weave asset-backed value notions into a Monee
currency.</t>

<t>Monee currencies may choose to add value that may be replicated
easily, such as growing organic tomatoes, being attentive to another
person's problems and so on.  These things add value without
suffering from the poor replication properties of classic money.
This is why Monee allows users to mint their own currency.  It
simply makes no sense to centralise that function where it has
no bearing on the value added, and where a lure to abuse would
be created.</t>

<t>When spending Monee, the question is if the person who offers
to add value will indeed add that value, if proper conflict handling
is in place in case they do not, and whether others have had trust
in this offering.  What matters most in this situation is whether
the appreciation of added value is meaningful to the prospective
consumer.</t>

<t>This is why they need to explore the paths from their
currency to that of the producer, and see if there is overlap with
people whose judgement they value.  These people are the foundation
of the upcoming trade.  There might also be intermediates that are
considered counter-indications, but that mechanism should be used
with care; this could create a destructive business opportunity
consisting that adds negative judgement to a (competitor's)
currency.  Likewise, conflict handling is a useful measurement of
problematic trading, but if a conflict comes from a customer who
raises many conflicts relative to positive outcomes, then their
conflicts are not very informative.  Such statusses may in fact
be verified by the producer before offering or accepting a trade.</t>

<t>The network over which parties trade is, at least in principle,
a personal network.  Communities may form, both locally or founded
on a shared mindset, and function as a hop towards the parties that
all others are trading with.  A person may trust such a network and,
if the feeling is mutual, such a network may trust the person too.
This adds extra trust validation paths that allows new trading to
take place.  Note how this does not start from a global scale, but
rather allows networks to grow.</t>

<t>In the end, the implementation of trust policies is personal,
and Monee simply provides the desired information to make reasonable
judgements.  Software for Monee is likely to provide options with
parameter tuning, and may even support scripting plugins for individual
regimens.  To producers, this means that they could be up to anything.
The need to protect web browsers from agressive web sites suggests that
customers should dictate the rules, and producers should be welcomed
to follow if they want.</t>

<t>Monee may develop to standardise trust policies.  It would be a
consumer's choice which one to accept, a standardised one or a
personal policy.</t>

</section><!-- anchor="paths.trust" -->

</section><!-- anchor="paths" -->

<section title="Security Considerations" anchor="security">

<t>TODO: Trust in information being supplied, specifically completeness.</t>

<t>TODO: Where to find information that discredits a currency.</t>

</section><!-- anchor="security" -->

<section title="IANA Considerations" anchor="iana">

<t>None.</t>

</section><!-- anchor="iana" -->

</middle>


<back>

<references title="Normative References">
<?rfc include="reference.RFC.2782.xml"?>
<!--
<?rfc include="reference.RFC.3962.xml"?>
<?rfc include="reference.RFC.4033.xml"?>
<?rfc include="reference.RFC.4120.xml"?>
<?rfc include="reference.RFC.4556.xml"?>
<?rfc include="reference.RFC.5280.xml"?>
<?rfc include="reference.RFC.5349.xml"?>
<?rfc include="reference.RFC.6010.xml"?>
-->
<!-- EXTERNAL RFC
<?rfc include="reference.RFC.6112.xml"?>
-->
<!--
<?rfc include="reference.RFC.6234.xml"?>
<?rfc include="reference.RFC.6698.xml"?>
-->
<!-- TOO LENGTHY
<?rfc include="reference.RFC.6806.xml"?>
-->

<!--
<reference anchor='DNSTXT'>
<front>
<title abbrev="krealm">Declaring Kerberos Realm Names in DNS (_kerberos TXT)</title>
<author initials="R" surname="Van Rein" fullname="Rick van Rein">
<organization>InternetWide.org</organization>
<address>
<postal><street>Haarlebrink 5</street><city>Enschede</city><region>Overijssel</region><code>7544 WP</code><country>The Netherlands</country></postal>
<email>rick@openfortress.nl</email>
</address>
</author>
<date day="11" month="September" year="2015"/>
<abstract>
<t>This specification defines methods to determine Kerberos realm
   descriptive information for services that are known by their DNS
   name.  Currently, finding such information is done through static
   mappings or educated guessing.  DNS can make this process more
   dynamic, provided that DNSSEC is used to ensure authenticity of
   resource records.</t>
</abstract>
</front>
</reference>
-->

</references>

<references title="Informative References">
<?rfc include="reference.RFC.4511.xml"?>
<!--
<?rfc include="reference.RFC.6717.xml"?>
<?rfc include="reference.RFC.3579.xml"?>
<?rfc include="reference.RFC.4121.xml"?>
<?rfc include="reference.RFC.5246.xml"?>
<?rfc include="reference.RFC.7055.xml"?>
-->
</references>

</back>

</rfc>
