forked from cheng/wallet
184 lines
6.7 KiB
HTML
184 lines
6.7 KiB
HTML
<!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
|
||
Commons Attribution-Share Alike 3.0 License</a></p>
|
||
</body></html> |