wallet/docs/net_money.html
reaction.la 5238cda077
cleanup, and just do not like pdfs
Also, needed to understand Byzantine fault tolerant paxos better.

Still do not.
2022-02-20 18:26:44 +10:00

174 lines
7.7 KiB
HTML
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<!DOCTYPE html>
<html lang="en"><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {
text-align:center;
}
</style><title>Net Money</title></head><body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Net Money</h1><p>
Net money. Net money that is reasonably liquid, that many
people acquire, that many people spend, money that is
readily convertible to worthwhile goods and services. Dont
worry about blinding and all that. Once any sort of net
money is flowing in large amounts, all that stuff then
becomes possible and desirable. If there is no liquidity,
nobody cares about blinding, and if you have blinding it
does you no good anyway without liquidity. </p><p>
Once we get that, we will shortly get it all. As long as we
do not have that, we have very little. </p><p>
Digicash failed because it was proprietary. For net money to
be a success we need a standard for transferring promises to
pay that is separate from the software issuers, and thus
separate from the issuers of promises to pay or deliver. It
has to be a standard such that anybody can play, anyone can
write software that will interoperate with software written
by others, and anyone can issue promises to deliver anything,
so that Ann, Bob, and Carol can transfer and exchange
promises between each other subject only to the need to trust
each other, without needing permissions or licenses from
anyone else. </p><p>
And it has to have software that is competitive with existing
methods of transferring value. </p><p>
Credit cards are very competitive for transactions of modest
size, because of the additional services, in particular
dispute arbitration and resolution provided by the card
issuers, and because of their large installed base. Smaller
players cannot hope to compete in that area. </p><p>
We have however no adequate means for small payments, five
dollars to fractions of a cent. This offers a fertile
opportunity for the development of net money. </p><p>
We also have no entirely satisfactory means for large low
margin payments. </p><p>
The large payment problem could be addressed by some system
that provided a tight connection between internet money and
US dollars in US banks, or, better, a system that provided a
tight connection between internet money and US dollars in non
US banks, or, if we had a large and liquid micropayment
system, it could be provided by a tight connection between
micro and macropayments. </p><p>
If several banks in some moderately popular banking haven
allowed people to transfer funds instantly and cheaply from
one account to another within the haven, through digitally
signed messages passing through https protocol, this would
make it possible to readily solve the large payment problem
by offering the means to create a tight connection between
net dollars and offshore dollars. If this were done then the
revolution would ensue within a few years. So far none have
been willing to do this, perhaps out of fear of reprisals,
more likely out of sheer inertia. </p><p>
The offshore dollar system is probably larger and more
liquid, and is certainly considerably more free, than the
onshore dollar system, but it is inconvenient for modest
payments. People use it primarily for transfers of many
thousands of dollars. Also the connection between the
offshore dollar and the onshore dollar is weak, because it is
inconvenient, slow, and costly, to transfer dollars between
the offshore and onshore banking systems. </p><p>
I see no possibility that anyone will be permitted to create
a strong connection between an internet dollar and the
onshore dollar, whereas it is quite possible that someone
will get away with creating a strong connection between the
internet dollar and the offshore dollar. </p><p>
Alternatively, (and perhaps more likely) a satisfactory
solution to the micropayment problem automatically brings in
its train a solution to the large payment problem, since the
software must accumulate many small promises into a few large
promises, and provide means to transfer these large promises
through numerous intermediaries, thus a large volume of
micropayments will create the liquidity for macropayments.
We do not need the banks to win this one, though they would
be very handy. </p><p>
Large promises to pay could acquire value not through a fast
and cheap connection to the banking system, whether onshore
of offshore, but through a fast and cheap connection to the
micropayment system, resulting in an internet dollar that
derives its liquidity from the internet market, and is
coupled to the US dollar no more strongly, and no less
strongly, than the offshore dollar is coupled to the onshore
dollar. </p><p>
Of course for this to work, we will need a large and liquid
market for aggregated micropayments. The existing finance
systems for self publishing, dirty pictures, and gambling,
really do not work very well, so there seems an obvious and
large market for micropayments. </p><p>
One cent, or half a cent, is probably the sweet spot for
pages and dirty picture, with quarters being the sweet spot
for games and gambling. </p><p>
Obviously pay pages cannot and should not be searched by
search engines, so the typical design would be a free,
searchable, index page containing lead in paragraphs and pay
links to the non free pages on the site, or a collection of
free summary pages each containing a pay link to the
corresponding non free page, or (better) both a free index
page and also a collection of free summary pages. </p><p>
We want the payment system to introduce no additional delays
when we click on a link, so the index page should cause any
necessary negotiations between the browser and server so that
the server is ready to accept the coins of this particular
user, so that the user can get the pay page with a single
message, a single URL containing a coin. The server then
immediately starts downloading the page without waiting for
any further messages to complete, and simultaneously attempts
to deposit the coin. </p><p>
Suppose you are browsing dirty pictures, and both you and the
server are clients of the same token issuer. Then the token
issuer knows that you are browsing the dirty picture pages,
and knows how much money the dirty picture issuer is making.
</p><p>
But for the scheme to be successful, we need many token
issuers, and the means to transfer aggregated token values
between issuers, so that in general the entity that takes
your bank money and provides you with net money, and the
entity that takes the dirty pictures servers net money and
provides it with bank money, will be very different entities,
probably in very different jurisdictions, separated by a
chain of intermediaries, who have an economic incentive to
aggregate transactions, thus obscuring individual spending
and getting. </p><p>
If any creditworthy person can issue tokens, privacy is not
such a big problem, and if the aggregated values representing
large numbers of tokens are readily transferable in a large
liquid market intermediary market, it is not a problem at
all, since the dirty picture issuer and the guy looking at
the dirty pictures are likely to be anonymous to the token
issuer. </p><p>
Micropayments have not failed. They have not yet been tried.
We still have not seen a scheme attempted that had all the
requirements that real net money will need. It is simply
quite a bit of work to design these things, and to get them
deployed in a form that ordinary mortals can use. </p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body></html>