2022-02-17 22:33:27 -05:00
|
|
|
|
<!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;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
dl {counter-reset: item1;
|
|
|
|
|
|
margin-left: 1.5em;
|
|
|
|
|
|
padding-left: 0;
|
|
|
|
|
|
margin-top: 0pt;
|
|
|
|
|
|
margin-bottom: 0pt;
|
|
|
|
|
|
padding-top: 0pt;
|
|
|
|
|
|
padding-bottom: 0pt;
|
|
|
|
|
|
top: 0pt;
|
|
|
|
|
|
bottom: 0pt;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
dt {
|
|
|
|
|
|
margin-top: 6pt;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
dt:before {
|
|
|
|
|
|
counter-increment: item1;
|
|
|
|
|
|
content: counter(item1) ". ";
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
a:hover {
|
|
|
|
|
|
color: #FF0000;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
</style><title>The Internet Money Solution</title></head><body>
|
|
|
|
|
|
|
|
|
|
|
|
<p><a href="./index.html"> To Home page</a> </p>
|
|
|
|
|
|
|
|
|
|
|
|
<h1>The Internet Money Solution</h1><p>
|
|
|
|
|
|
|
|
|
|
|
|
To transfer money, transfer promises made by very creditworthy
|
|
|
|
|
|
well networked entities.</p><p>
|
|
|
|
|
|
|
|
|
|
|
|
Swift, the electronic interbanking system, the system banks
|
|
|
|
|
|
use to communicate with each other, describes the service it
|
|
|
|
|
|
provides as secure authenticated store and forward non
|
|
|
|
|
|
repudiable messages with proof of delivery – a bank cannot
|
|
|
|
|
|
deny sending the message, nor deny receiving it. </p><p>
|
|
|
|
|
|
|
|
|
|
|
|
The system has about ten thousand members and handles about
|
|
|
|
|
|
twenty million messages a day, too many for a bitcoin like
|
|
|
|
|
|
system. Your store would grow at about four gigabytes a
|
|
|
|
|
|
day.</p><p>
|
|
|
|
|
|
|
|
|
|
|
|
To handle this in a system based on a global hash: </p><p>
|
|
|
|
|
|
|
|
|
|
|
|
The global hash for each time period is shared by almost
|
|
|
|
|
|
everybody, as are all the nodes near the root. Each member
|
|
|
|
|
|
only needs to retain the near root data, the data that they
|
|
|
|
|
|
care about, and paths from the data that they care about to
|
|
|
|
|
|
the root. </p><p>
|
|
|
|
|
|
|
|
|
|
|
|
Ann maintains a signed hash of all messages sent from Ann to
|
|
|
|
|
|
Bob, also a signed hash of all messages received from Bob.
|
|
|
|
|
|
These hashes get incorporated into the global hash that is
|
|
|
|
|
|
shared by everyone. </p><p>
|
|
|
|
|
|
|
|
|
|
|
|
So when Ann sees a mismatch between messages Bob sent, and
|
|
|
|
|
|
messages Ann received, asks Bob to fix the mismatch. </p><p>
|
|
|
|
|
|
|
|
|
|
|
|
To the extent that Ann’s record of messages sent, agrees with
|
|
|
|
|
|
Bob’s record of messages received for messages sent some
|
|
|
|
|
|
time ago, we have non repudiation and guarantee of delivery.
|
|
|
|
|
|
</p><p>
|
|
|
|
|
|
|
|
|
|
|
|
If ten thousand members, then two hundred million hashes
|
|
|
|
|
|
every time period, but we special case the hash of no messages
|
|
|
|
|
|
sent or received between Ann and Bob in a given time period,
|
|
|
|
|
|
so that it does not take up any significant space in the tree
|
|
|
|
|
|
or computational resources. It is a virtual hash, not a real
|
|
|
|
|
|
hash. </p><p>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Everyone stores the current hash for each pair, which,
|
|
|
|
|
|
if no messages have been sent in the last few time
|
|
|
|
|
|
periods, is the same as the hash from some time ago, and if no
|
|
|
|
|
|
messages have ever been sent, is represented by the null hash.
|
|
|
|
|
|
Conceptually we have a lot of nulls, but these are efficiently
|
|
|
|
|
|
represented, as a sparse matrix, so that we don’t waste
|
|
|
|
|
|
storage or communication managing huge numbers of mostly null
|
|
|
|
|
|
entries. </p><p>
|
|
|
|
|
|
|
|
|
|
|
|
In addition to the encrypted pairwise messages, we also have
|
|
|
|
|
|
messages to the public, signed but not encrypted. This
|
|
|
|
|
|
enables one to find the characteristics of the owner of the
|
|
|
|
|
|
key, usually used to look for a key owner with certain
|
|
|
|
|
|
characteristics. The primary function of this is to ensure
|
|
|
|
|
|
that everyone sees the same key for the entity called Bob as
|
|
|
|
|
|
Bob does, since the hash of all public messages by Bob go into
|
|
|
|
|
|
the global hash, and everyone sees the same global hash.
|
|
|
|
|
|
</p><p>
|
|
|
|
|
|
|
|
|
|
|
|
All of this would be simple if the hashes were static, if we
|
|
|
|
|
|
were managing an immutable data structure, but we are of
|
|
|
|
|
|
course managing a mutable data structure with an immutable
|
|
|
|
|
|
past. Each hash continually changes. </p><p>
|
|
|
|
|
|
|
|
|
|
|
|
An ever changing hash is represented by a time tree of hashes.
|
|
|
|
|
|
</p><p>
|
|
|
|
|
|
|
|
|
|
|
|
We have a hash for the period 0 milliseconds to 2^64-1 milliseconds,
|
|
|
|
|
|
which is itself a hash of the two hashes, one for the period 0
|
|
|
|
|
|
seconds to 2^63-1 milliseconds, and the other for the period 2^63
|
|
|
|
|
|
seconds to 2^64-1 milliseconds. </p><p>
|
|
|
|
|
|
|
|
|
|
|
|
And the hash for the period the period 2^63 seconds to 2^64-1
|
|
|
|
|
|
seconds is itself a hash of the two hashes, one for the period
|
|
|
|
|
|
2^63 seconds to 3*2^62-1 seconds, and one for the period
|
|
|
|
|
|
3*2^62 seconds to 2^64-1 seconds. </p><p>
|
|
|
|
|
|
|
|
|
|
|
|
And so on and so forth. Hashes for the past are immutable,
|
|
|
|
|
|
and signed. Hashes for periods that incorporate the future
|
|
|
|
|
|
are also signed, but are listed as provisional and only
|
|
|
|
|
|
covering data up to such and such a time. They are useful
|
|
|
|
|
|
because they incoporate hashes of times that are strictly in
|
|
|
|
|
|
the past. </p><p>
|
|
|
|
|
|
|
|
|
|
|
|
To bind the entire past, one needs the signed mutable hash for
|
|
|
|
|
|
the smallest period including all of the past, plus the hashes
|
|
|
|
|
|
nearest the root that cover all of the past. </p><p>
|
|
|
|
|
|
|
|
|
|
|
|
Thus the hash for the entire past is typically only larger
|
|
|
|
|
|
than the hash for a single time period by a factor of log base
|
|
|
|
|
|
two of the current time. </p><p>
|
|
|
|
|
|
|
|
|
|
|
|
The signature on the mutable hash acts as a signature on all
|
|
|
|
|
|
past immutable hashes. </p><p>
|
|
|
|
|
|
|
|
|
|
|
|
The hash for a single time period is an ordinary hash, like
|
|
|
|
|
|
SHA2. The hash for the entire time period is a small number
|
|
|
|
|
|
of such hashes forming a tree, and ending in a signature of
|
|
|
|
|
|
the root of the tree. </p><p>
|
|
|
|
|
|
|
|
|
|
|
|
Any data that anyone supplies then has to have a path leading
|
|
|
|
|
|
from its local all time hash to this global all time hash.
|
|
|
|
|
|
</p><p>
|
|
|
|
|
|
|
|
|
|
|
|
If 256 bit single time hashes, an all time hash is about one
|
|
|
|
|
|
kilobyte, but updates are only thirty two bytes or so. So our
|
|
|
|
|
|
global data structure is quite large, but updates quite
|
|
|
|
|
|
slowly. If ten thousand members, our global data structure is
|
|
|
|
|
|
about a hundred gigabytes, assuming every entity interacted
|
|
|
|
|
|
with every other. If every member interacted with every other
|
|
|
|
|
|
member in a given time period, the update would be three
|
|
|
|
|
|
gigabyes, which would be intolerable. Interacting with a
|
|
|
|
|
|
single member requires ten thousand thirty two byte
|
|
|
|
|
|
notifications, which is tolable, but starting to get
|
|
|
|
|
|
expensive. </p><p>
|
|
|
|
|
|
|
|
|
|
|
|
To remedy the problem, members for groups, and groups of
|
|
|
|
|
|
groups and groups of groups of groups. So you don’t track the
|
|
|
|
|
|
hashes for every interaction between every member, but rather
|
|
|
|
|
|
most such interactions get aggregated into the interaction
|
|
|
|
|
|
between group and group. </p><p>
|
|
|
|
|
|
|
|
|
|
|
|
Of course, having secure non repudiable messaging with proof
|
|
|
|
|
|
of delivery is only a foundation for a financial system.
|
|
|
|
|
|
Swift builds a financial system on top of that by making sure
|
|
|
|
|
|
that all entities are very highly rated. </p><p>
|
|
|
|
|
|
|
|
|
|
|
|
Ripple, however, addresses a system where some entities are
|
|
|
|
|
|
rated to some people and not others, where not everyone has
|
|
|
|
|
|
good ratings, and opinions about ratings differ, where perhaps
|
|
|
|
|
|
some entities are well placed to ensure payment of what is
|
|
|
|
|
|
owed, and others less well placed. </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
|
2022-02-18 15:59:12 -05:00
|
|
|
|
Commons Attribution-Share Alike 3.0 License</a></p>
|
2023-08-25 19:38:32 -04:00
|
|
|
|
</body></html>
|
