fred/wallet
1
0
Fork 0
forked from cheng/wallet
Code Pull Requests Activity

typos, and adaption to the new layout

Browse Source 
Slight updates to libraries, Christianization
of sox_accounting.
This commit is contained in:
reaction.la 2023-11-24 22:22:16 +00:00
parent ed1f395eb9
commit 94df1b856e
No known key found for this signature in database
GPG Key ID: 99914792148C8388
7 changed files with 234 additions and 172 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

60
docs/libraries.md
View File

@ -1,5 +1,7 @@
---
title: Libraries
sidebar: true
notmine: false
...
A review of potentially useful libraries and utilities.
@ -124,6 +126,33 @@ does not represent the good stuff.
# Peer to Peer
## Freenet
Freenet has long intended to be, and perhaps is, the social
application that you have long intended to write,
and has an enormous coldstart advantage over anything you could write,
no matter how great.
It also relies on udp, to enable hole punching, and routinely does hole punching.
So the only way to go, to compete, is to write a better freenet within
freenet.
One big difference is that I think that we want to go after the visible net,
where network addresses are associated with public keys - that the backbone should be
ips that have a well known and stable relationship to public keys.
Which backbone transports encrypted information authored by people whose
public key is well known, but the network address associated with that
public key cannot easily be found.
Freenet, by design, chronically loses data. We need reliable backup,
paid for in services or crypto currency.
filecoin provides this, but is useless for frequent small incremental
backups.
## libp2p
[p2p]:https://github.com/elenaf9/p2p
{target="_blank"}
@ -1791,7 +1820,7 @@ Javascript is a great language, and has a vast ecosystem of tools, but
it is controlled from top to bottom by our enemies, and using it is
inherently insecure.
It consists of a string (which is implemented under the hood as a copy on
Tcl consists of a string (which is implemented under the hood as a copy on
write rope, with some substrings of the rope actually being run time typed
C++ types that can be serialized and deserialized to strings) and a name
table, one name table per interpreter, and at least one interpreter per
@ -1869,14 +1898,39 @@ from wide character variants and locale variants. (We don't want locale
variants, they are obsolete. The whole world is switching to UTF, but
our software and operating environments lag)
Locales still matter in case insensitive compare, collation order,
canonicalization of utf-8 strings, and a rats nest of issues,
which linux and sqlite avoids by doing binary compares, and if it cannot
avoid capitalization issues, only considering A-Z to be capitals.
If you tell sqlite to incorporate the utf library, sqlite will attempt to
do case lowering and collation for all of utf-8 - which strikes me
as something that cannot really be done, and I am not at all sure how
it will interact with wxWidgets attempting to do the same thing.
wxWidgets does *not* include the full unicode library, so cannot do this
stuff. But sqlite provides some C string functions that are guaranteed to
do whatever it does, and if you include the UCL library it attempts
to handle capitalization on the entire unicode set\
`int sqlite3_stricmp(const char *, const char *);`\
`sqlite3_strlike(P,X,E)`\
The UCL library also provides a real regex function on unicode
(`sqlite3_strlike` being the C equivalent of the SQL `LIKE`,
providing a rather truncated fragment of regex capability)
Pretty sure the wxWidgets regex does something unwanted on unicode
`wString::ToUTF8()` and `wString::FromUTF8()` do what you would expect.
`wxString::c_str()` does something too clever by half.
On visual studio, need to set your source files to have bom, so that Visual
Studio knows that they are UTF‑8, need to set the compiler environment in
Visual Studio to UTF‑8 with `/Zc:__cplusplus /utf-8 %(AdditionalOptions)`
And you need to set the run time environment of the program to UTF‑8
with a manifest.
with a manifest. Not at all sure how codelite will handle manifests,
but there is a codelite build that does handle utf-8, presumably with
a manifest. Does not do it in the standard build on windows.
You will need to place all UTF‑8 string literals and string constants in a
resource file, which you will use for translated versions.
@ -1909,6 +1963,8 @@ its system functions, which should make it easy.
wxWidgets provides `wxRegEx` which, because wxWidgets provides index
by entity, should just work. Eventually. Maybe the next release.
But,since if you are supporting Sqlite unicode capitalization,
you are including the UCS library, which supplies a regex operator.
# [UTF8-CPP](http://utfcpp.sourceforge.net/ "UTF-8 with C++ in a Portable Way")

1
docs/manifesto/scalability.md
View File

@ -87,6 +87,7 @@ transaction outputs that you are spending.
Which you do by proving that the inputs are part
of the merkle tree of unspent transaction outputs,
of which the current root of the blockchain is the root hash.
## structs
A struct is simply some binary data laid out in well known and agreed format.

29
docs/manifesto/social_networking.md
View File

@ -1105,7 +1105,7 @@ people will start Sovcorps. So to get a foot in the door, we have to cherry pick
and snipe little areas where the big network is failing, and once we have a foot
in the door, then we can get rolling.
### elevator pitch:
## elevator pitch:
Grab a privacy niche where Monero cannot operate, because of its inherent
lack of smart contracts and social networking capability, due to the nature of its
@ -1114,7 +1114,7 @@ Then take over Monero's niche by being a better Monero.
Then take over Bitcoin and Nostr's niche by being a better Bitcoin and a better Nostr,
because recursive snarks can do lots of things, such as smart contracts, better than they can.
### failure of previous altcoins to succeed in this strategy
## failure of previous altcoins to solve Cold Start.
During the last decade, numberless altcoins have attempted to compete with
Bitcoin, and they all got crushed, because the differences between them and
@ -1123,17 +1123,17 @@ Bitcoin really did not matter that much.
They failed to differentiate themselves from bitcoin. They could
not find a niche in which to start.
Ether did OK, because they supported smart contracts and bitcoin did not,
but now that bitcoin has some limited smart contract capability,
they are going down too, because bitcoin has the big network advantage.
Ether did OK, because they supported smart contracts and Bitcoin did not,
but now that Bitcoin has some limited smart contract capability,
they are going down too, because Bitcoin has the big network advantage.
Being the biggest, it is far more convertible into goods and services
than any other. Which means ether is doomed now that bitcoin is
than any other. Which means Ether is doomed now that Bitcoin is
doing smart contracts.
Monero did OK, because it is the leading privacy coin. It has a niche, but
cannot break out of the not very large niche. Because its privacy mechanism means it is
a worse bitcoin than bitcoin in other respects.
a worse Bitcoin than Bitcoin in other respects.
And the cold start problem means we cannot directly take over that niche either.
@ -1145,13 +1145,15 @@ network, and without the rest of the network needing to know what that
contract is or be able to evaluate it. Because of its privacy mechanism,
Monero cannot do contracts, which prevents atomic exchange between Monero
and Bitcoin, and prevents Monero from doing a lightning network that would
enable fast atomic exchange between itself and other networks.
enable fast atomic exchange between itself and Bitcoin lightning.
So if we get a niche, get differentiation from Monero and Bitcoin,
we can then break out of that niche and eat Monero, being a better
privacy coin, a better Monero, and from the Monero niche eat Bitcoin,
being, unlike Monero, a better Bitcoin.
## Solving the cold start problem
### Bitmessage
The lowest hanging fruit of all, (because, unfortunately, there is
@ -1163,16 +1165,17 @@ on discussion groups, but is widely used
because it does not reveal the sender or recipient's IP address.
In particular, it is widely used for crypto currency payments.
So next step is to integrate payment mechanisms, which brings us
a little closer to the faint smell of money.
So next step, after capturing its abandoned market niche,
is to integrate payment mechanisms, in particular to integrate
core lightning, which brings us a little closer to the faint smell of money.
### Integrating money.
### Integrating money
So we create a currency. But because it will be created on sovcorp model
So we create our own currency. But because it will be created on sovcorp model
people cannot obtain it by proof of work - they have to buy it. Which
will require gateways between bitcoin lightning and the currency supported by
by the network, supporting atomic lightning exchange
and gateways between the conversations on the network and nostr.
and gateways between the conversations on the privacy network and the conversations on nostr.
# Development sequence

10
docs/manifesto/sox_accounting.md
View File

@ -3,7 +3,7 @@ title: >-
Sox Accounting
...
Accounting and bookkeeping is failing in an increasingly low trust world
of ever less trusting and ever less untrustworthy elites, and Sarbanes-Oxley
of ever less trusting and ever less trustworthy elites, and Sarbanes-Oxley
accounting (Sox) is an evil product of this evil failure.
Enron was a ponzi scam that pretended to be in the business of buying and
@ -83,7 +83,7 @@ disreputable accounting students and the investors who had hired them.
So there was in practice a great deal of overlap between very respectable
accountants asking government to force business to use their services and
naive idiots asking government to force business and accountants to
naïve idiots asking government to force business and accountants to
behave in a more trustworthy manner.
And so, we got a huge bundle of accounting regulation, Sarbanes-Oxley.
@ -112,6 +112,12 @@ feet, the things in your hands, and what is before your eyes, with the result
that they tend to track the creation of holiness and ritual purity, rather than
the creation of value.
From the seventeenth century to the nineteenth, bookkeeping was explicitly Christian.
The immutable append only journal reflected God's creation, the balance of the books
was an earthly reflection of the divine scales of justice and the symmetry of God’s creation.
When the dust settled over the Great Minority Mortgage Meltdown it became apparent that
the books of the financial entities involved had little connection to God's creation.
But the biggest problem with Sarbanes-Oxley is not that it has failed to
force publicly traded companies and their accountants to act in
a trustworthy manner, but that it has forced them to act in an untrustworthy

17
docs/setup/set_up_build_environments.md
View File

@ -3631,6 +3631,10 @@ Private video conferencing
[To set up a Jitsi meet server](andchad.net/jitsi)
## Tox (TokTok)
A video server considerably more freedom oriented than Jitsi
## [Zeronet](https://zeronet.io/docs)
Namecoin plus bittorrent based websites. Allows dynamic content.
@ -3645,15 +3649,6 @@ Non instant text messages. Everyone receives all messages in a stream, but only
Not much work has been done on this project recently, though development and maintenance continues in a desultory fashion.
# Tcl Tk
## Freenet
An absolutely brilliant and ingenious language for producing cross
platform UI. Unfortunately I looked at a website that was kept around for
historical reasons, and concluded that development had stopped twenty years ago.
In fact development continues, and it is very popular, but being absolutely
typeless (everything is a conceptually a string, including running code)
any large program becomes impossible for multiple people to work on.
Best suited for relatively small programs that hastily glue stuff together - it
is, more or less, a better bash, capable of running on any desktop, and
capable of running a gui.
See [libraries](../libraries.html#freenet)

195
docs/wallet_implementation.md
View File

@ -1,41 +1,26 @@
<!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>
<link rel="shortcut icon" href="../rho.ico">
<title>Wallet Implementation</title>
</head>
<body>
<p><a href="./index.html"> To Home page</a> </p>
<h1>Wallet Implementation</h1><p>
---
lang: en
title: Wallet Implementation
---
The primary function of the wallet file is to provide a secret key for
a public key, though eventually we stuff all sorts of user odds and ends
into it.</p><p>
into it.
In Bitcoin, this is simply a pile of random secrets, randomly generated, but obviously it is frequently useful to have them not random, but merely seemingly random to outsiders. One important and valuable application of this is the paper wallet, where one can recreate the wallet from its master secret, because all the seemingly random secret keys are derived from a single master secret. But this does not cover all use cases.</p><p>
In Bitcoin, this is simply a pile of random secrets, randomly generated, but obviously it is frequently useful to have them not random, but merely seemingly random to outsiders. One important and valuable application of this is the paper wallet, where one can recreate the wallet from its master secret, because all the seemingly random secret keys are derived from a single master secret. But this does not cover all use cases.
We care very much about the case where a big important peer in a big central
node of the internet, and the owner skips out with the paper key that owns the
peer’s reputation in his pocket, and sets up the same peer in another
jurisdiction, and everyone else talks to the peer in the new jurisdiction,
and ignores everything the government seized.</p><p>
and ignores everything the government seized.
The primary design principle of our wallet is to bypass the DNS and ICANN, so
that people can arrange transactions securely. The big security hole in
Bitcoin is not the one that Monero fixes, but that you generally arrange
transactions on the totally insecure internet. The spies care about the
metadata more than they care about the data. We need to internalize and secure
the metadata.</p><p>
the metadata.
We particularly want peers to be controlled by easily hidden and transported
secrets. The key design point around which all else is arranged is that if
@ -48,12 +33,11 @@ has moved except for the cops who grabbed his now useless hardware. (Because
the secrets on that hardware were only valuable because their public keys
were signed by his keys, and when he starts up the new hardware, his keys
will sign some new keys on the peer and on the slave wallet on that hardware.)
</p><p>
We also want perfect forward secrecy, which is easy. Each new connection
initiation starts with a random transient public key, and any identifying
information is encrypted in the shared secret formed from that transient public
key, and the durable public key of the recipient.</p><p>
key, and the durable public key of the recipient.
We also want off the record messaging. So we want to prove to the recipient
that the sender knows the shared secret formed from the recipients public key
@ -63,18 +47,18 @@ sender’s durable private key. But the recipient, though he then knows the
message came from someone who has the sender’s durable private key, cannot
prove that to a third party, because he could have constructed that shared
secret, even if the sender did not know it. The recipient could have forged
the message and sent it to himself.</p><p>
the message and sent it to himself.
Thus we get off the record messaging. The sender by proving knowledge of two
shared secrets, proves to the recipient knowledge of two secret keys
corresponding to the two public keys provided, but though the sender proves
it to the recipient, the recipient cannot prove it to anyone else.</p><p>
it to the recipient, the recipient cannot prove it to anyone else.
The message consists of transient public key in the clear, which encrypts
durable public key. then durable public key plus transient public key encrypts
the rest of the message, which encryption proves knowledge of the secret key
underlying the durable public key, proves it to the recipient, but he cannot
prove it to anyone else.</p><p>
prove it to anyone else.
The durable public key may be followed by the schema identifier 2, which
implies the nickname follows, which implies the twofitytwo bit hash of the
@ -83,11 +67,11 @@ pseudonym sending the message. But we could have a different schema, 3,
corresponding to a chain of signatures authenticating that public key, subject
to timeouts and indications of authority, which we will use in slave wallets
and identifiers that correspond to a corporate role in a large organization,
or in iff applications where new keys are frequently issued.</p><p>
or in iff applications where new keys are frequently issued.
If we have a chain of signatures, the hash is of the root public key and the
data being signed (names, roles, times, and authorities) but not the signatures
themselves, nor the public keys that are being connected to that data.</p><p>
themselves, nor the public keys that are being connected to that data.
When someone initiates a connection using such a complex identity, he sends
proof of shared knowledge of two shared secrets, and possibly a chain of
@ -95,17 +79,17 @@ signatures, but does not sign anything with the transient public key, nor the
durable public key at the end of the chain of signatures, unless, as with a
review, he wants the message to be shared around, in which case he signs the
portion of the message that is to be shared around with that public key, but
not the part of the message that is private between sender and receiver.</p><p>
not the part of the message that is private between sender and receiver.
To identify the globally unique twofitytwo bit id, the recipient hashes the
public key and the identifier that follows. Or he may already know, because
the sender has a client relationship with the recipient, that the public key
is associated with a given nickname and globally unique identifier.</p><p>
is associated with a given nickname and globally unique identifier.
If we send the schema identifier 0, we are not sending id information, either
because the recipient already has it, or because we don’t care, or because we
are only using this durable public key with this server and do not want a
global identity that can be shared between different recipients.</p><p>
global identity that can be shared between different recipients.
So, each master wallet will contain a strong human readable and human writeable
master secret, and the private key of each nickname will be generated by
@ -113,7 +97,6 @@ hashing the nickname with the master secret, so that when, in some new
location, he types in the code on fresh hardware and blank software, he will
get the nickname’s public and private keys unchanged, even if he has to buy or
rent all fresh hardware, and is not carrying so much as a thumbdrive with him.
</p><p>
People with high value secrets will likely use slave wallets, which perform
functions analogous to a POP or IMAP server, with high value secrets on their
@ -124,7 +107,7 @@ message containing the obfuscation shared secret, which is based on the
master wallet secret and an,the first integer being the number of the
transaction with the largest transaction in that name known to the master
wallet, an integer that the slave wallet increments with every request for
value. The master wallet needs to provide a name for the slave walle, and to
value. The master wallet needs to provide a name for the slave wallet, and to
recover payments, needs that name. The payments are made to a public key of
the master wallet, multiplied by a pseudo random scalar constructed from the
hash of a sequential integer with an obfuscation secret supplied by the master
@ -132,17 +115,17 @@ wallet, so that the master wallet can recover the payments without further
communication, and so that the person making the payment knows that any
payment can only be respent by someone who has the master wallet secret key,
which may itself be the key at the end of chain of signatures identity,
which the master wallet posesses, but the slave wallet does not.</p><p>
which the master wallet posesses, but the slave wallet does not.
For slave wallets to exist, the globally unique id has to be not a public
key, but rather the twofiftytwo bit hash of a rule identifying the public key.
The simplest case being hash(2|public key|name), which is the identifier used
by a master wallet. A slave wallet would use the identifier hash(3|master
public key|chain of signed ids) with the signatures and public keys in the
The simplest case being hash(2\|public key\|name), which is the identifier used
by a master wallet. A slave wallet would use the identifier hash(3\|master
public key\|chain of signed ids) with the signatures and public keys in the
chain omitted from the hash, so the durable public key and master secret of
the slave wallet does not need to be very durable at all. It can, and
probably should, have a short timeout and be frequently updated by messages
from the master wallet.</p><p>
from the master wallet.
The intent is that a slave wallet can arrange payments on behalf of an identity
whose secret it does not possess, and the payer can prove that he made the
@ -154,34 +137,33 @@ unchanging identity identity authorized to make offers on behalf a long lived
identity, but not the secret for an identity authorized to receive money on
behalf of a long lived identity. The computer readable name of these
identities is a twofiftytwo bit hash, and the human readable name is something
like receivables@_@globally_unique_human_readable_name, or
sales@_@globally_unique_human_readable_name. The master secret for
_@globally_unique_human_readable_name is closely held, and the master secret
like receivables@\_@globally_unique_human_readable_name, or
sales@\_@globally_unique_human_readable_name. The master secret for
\_@globally_unique_human_readable_name is closely held, and the master secret
for globally_unique_human_readable_name written in pencil on a closely held
piece of paper and is seldom in any computer at all.</p><p>
piece of paper and is seldom in any computer at all.
For a name that is not globally unique, the human readable name is
non_unique_human_readable_nickname zero_or_more_whitespace
42_characters_of_slash6_code zero_or_more_whitespace. </p><p>
42_characters_of_slash6_code zero_or_more_whitespace.
Supposing Carol wants to talk to Dave, and the base point is B. Carols secret is the scalar <code>c</code>, and her public key is elliptic point <code>C=c*B</code>. Similarly Dave’s secret is the scalar <code>d</code>, and his public key is elliptic point
<code>D=d*B</code>.</p><p>
Supposing Carol wants to talk to Dave, and the base point is B. Carols secret is the scalar `c`, and her public key is elliptic point `C=c*B`. Similarly Dave’s secret is the scalar `d`, and his public key is elliptic point
`D=d*B`.
His secret scalar <code>d</code> is probably derived from the hash of his master secret with his nickname, which we presume is "Dave".</p><p>
His secret scalar `d` is probably derived from the hash of his master secret with his nickname, which we presume is "Dave".
They could establish a shared secret by Carol calculating <code>c*D</code>, and
Dave calculating <code>d*C</code>. But if either party’s key is seized, their
They could establish a shared secret by Carol calculating `c*D`, and
Dave calculating `d*C`. But if either party’s key is seized, their
past communications become decryptable. Plus this unnecessarily leaks metadata
o people watching the interaction.</p><p>
o people watching the interaction.
Better, Carol generates a random scalar <code>r</code>, unpredictable to anyone
else, calculates <code>R=r*B</code>, and sends Dave <code>R, C</code> encrypted
using <code>r*D,</code> and the rest of the message encrypted using <code>
(r+c)*D</code>.</p><p>
Better, Carol generates a random scalar `r`, unpredictable to anyone
else, calculates `R=r*B`, and sends Dave `R, C` encrypted
using `r*D,` and the rest of the message encrypted using ` (r+c)*D`.
This gives us perfect forward secrecy and off-the-record.</p><p>
This gives us perfect forward secrecy and off-the-record.
One flaw in this is that if Dave’s secret leaks, not only can he and the people communicating with him be spied upon, but he can receive falsified messages that appear to come from trusted associates.</p><p>
One flaw in this is that if Dave’s secret leaks, not only can he and the people communicating with him be spied upon, but he can receive falsified messages that appear to come from trusted associates.
One fix for this is the following protocol. When Carol initiates communication
with Dave, she encrypts only with the transient public and private keys, but
@ -189,7 +171,7 @@ when Dave replies, he encrypts with another transient key. If Carol can
receive his reply, it really is Carol. This does not work with one way
messages, mail like messages, but every message that is a reply should
automatically contain a reference to the message that it replies to, and every
message should return an ack, so one way communication is a limited case.</p><p>
message should return an ack, so one way communication is a limited case.
Which case can be eliminated by handling one way messages as followed up by
mutual acks. For TCP, the minimum set up and tear down of a TCP connection
@ -200,102 +182,99 @@ want to establish keys as early in the process as we can while avoiding the
possibility of DNS attacks against the connection setup process. If
communication only ensues when both sides know four shared secrets, then the
communication can only be forged or intercepted by a party that knows both
sides durable secrets.</p><p>
sides durable secrets.
We assume on public key per network address and port – that when she got the port
associated with the public key, she learned what which of his possibly numerous
public keys will be listening on that port.</p><p>
public keys will be listening on that port.
Carol calculates <code>(c+r)*D</code>. Dave calculates <code>d*(C+R)</code>, to arrive at a shared secret, used only once.</p><p>
Carol calculates `(c+r)*D`. Dave calculates `d*(C+R)`, to arrive at a shared secret, used only once.
That is assuming Carol needs to identify. If this is just a random anonymous client connection, in which Dave responds the same way to every client, all she needs to send is <code>R</code> and <code>D</code>. She does not need forward secrecy, since not re-using <code>R</code>. But chances are Dave does not like this, since chances are he wants to generate a record of the distinct entities applying, so a better solution is for Carol to use as her public key when talking to Dave <code>hash(c, D)*B</code></p><p>
That is assuming Carol needs to identify. If this is just a random anonymous client connection, in which Dave responds the same way to every client, all she needs to send is `R` and `D`. She does not need forward secrecy, since not re-using `R`. But chances are Dave does not like this, since chances are he wants to generate a record of the distinct entities applying, so a better solution is for Carol to use as her public key when talking to Dave `hash(c, D)*B`
Sometimes we are going to onion routing, where the general form of an onion routed message is [<code>R, D,</code> encrypted] with the encryption key being <code>d*R = r*D</code>. And inside that encryption may be another message of the same form, another layer of the onion.</p><p>
Sometimes we are going to onion routing, where the general form of an onion routed message is \[`R, D,` encrypted\] with the encryption key being `d*R = r*D`. And inside that encryption may be another message of the same form, another layer of the onion.
But this means that Dave cannot contact Carol. But maybe Carol does not want to be contacted, in which case we need a flag to indicate that this is an uncontactable public key. Conversely, if she does want to be contactable, but her network address changes erratically, she may need to include contact info, a stable server that holds her most recent network address.</p><p>
But this means that Dave cannot contact Carol. But maybe Carol does not want to be contacted, in which case we need a flag to indicate that this is an uncontactable public key. Conversely, if she does want to be contactable, but her network address changes erratically, she may need to include contact info, a stable server that holds her most recent network address.
Likely all she needs is that Dave knows that she is the same entity as logged in with Dave before. (Perhaps because all he cares about is that this is the same entity that paid Dave for services to be rendered, whom he expects to keep on paying him for services he continues to render.) </p><p>
Likely all she needs is that Dave knows that she is the same entity as logged in with Dave before. (Perhaps because all he cares about is that this is the same entity that paid Dave for services to be rendered, whom he expects to keep on paying him for services he continues to render.)
The common practical situation, of course is that Carol@Name wants to talk to Dave@AnotherName, and Name knows the address of AnotherName, and AnotherName knows the name of Dave, and Carol wants to talk to Dave as Carol@Name. To make this secure, have to have have a a commitment to the keys of Carol@Name and Dave@AnotherName, so that Dave and Carol can see that Name and AnotherName are showing the same keys to everyone.</p><p>
The common practical situation, of course is that Carol@Name wants to talk to Dave@AnotherName, and Name knows the address of AnotherName, and AnotherName knows the name of Dave, and Carol wants to talk to Dave as Carol@Name. To make this secure, have to have have a a commitment to the keys of Carol@Name and Dave@AnotherName, so that Dave and Carol can see that Name and AnotherName are showing the same keys to everyone.
The situation we would like to have is a web of public documents rendered immutable by being linked into the blockchain, identifying keys, and a method of contacting the entity holding the key, the method of contacting the identity holding the key being widely available public data.</p><p>
The situation we would like to have is a web of public documents rendered immutable by being linked into the blockchain, identifying keys, and a method of contacting the entity holding the key, the method of contacting the identity holding the key being widely available public data.
In this case, Carol may well have a public key only for use with Name, and Dave a public key only for use with AnotherName.
If using `d*C` as the identifier, inadvisable to use a widely known `C`, because this opens attacks via `d`, so `C` should be a per host public key that Carol keeps secret.
If using <code>d*C</code> as the identifier, inadvisable to use a widely known <code>C</code>, because this opens attacks via <code>d</code>, so <code>C</code> should be a per host public key that Carol keeps secret.</p><p>
The trouble with all these conversations is that they leak metadata – it is visible to third parties that `C` is talking to `D`.
The trouble with all these conversations is that they leak metadata – it is visible to third parties that <code>C</code> is talking to <code>D</code>.</p><p>
Suppose it is obvious that you are talking to Dave, because you had to look up Dave’s network address, but you do not want third parties to know that *Carol* is talking to Dave. Assume that Dave’s public key is the only public key associated with this network address.
Suppose it is obvious that you are talking to Dave, because you had to look up Dave’s network address, but you do not want third parties to know that <em>Carol</em> is talking to Dave. Assume that Dave’s public key is the only public key associated with this network address.</p><p>
We would rather not make it too easy for the authorities to see the public key of the entity you are contacting, so would like to have D end to end encrypted in the message. You are probably contacting the target through a rendevous server, so you contact the server on its encrypted key, and it sets up the rendevous talking to the wallet you want to contact on its encrypted key, in which case the messages you send in the clear do not need, and should not have, the public key of the target.
We would rather not make it too easy for the authorities to see the public key of the entity you are contacting, so would like to have D end to end encrypted in the message. You are probably contacting the target through a rendevous server, so you contact the server on its encrypted key, and it sets up the rendevous talking to the wallet you want to contact on its encrypted key, in which case the messages you send in the clear do not need, and should not have, the public key of the target.</p><p>
Carol sends `R` to Dave in the clear, and encrypts `C` and `r`\*`D`, using the shared secret key `r`\*`D` = `d`\*`R`
Carol sends <code>R</code> to Dave in the clear, and encrypts <code>C</code> and <code>r</code>*<code>D</code>, using the shared secret key <code>r</code>*<code>D</code> = <code>d</code>*<code>R</code></p><p>
Subsequent communications take place on the shared secret key `(c+r)*D = d*(C+R)`
Subsequent communications take place on the shared secret key <code>(c+r)*D = d*(C+R)</code></p><p>
Suppose there are potentially many public keys associated with this network address, as is likely to be the case if it is a slave wallet performing Pop and Imap like functions. Then it has one primary public key for initiating communications. Call its low value primary keys p and P. Then Carol sends `R` in the clear, followed by `D` encrypted to `r*P = p*R`, followed by `C` and `r*D`, encrypted to `r*D = d*R`.
We can do this recursively, and Dave can return another, possibly transient, public key or public key chain that works like a network address. This implies a messaging system whose api is that you send an arbitrary length message with a public key as address, and possibly a public key as authority, and an event identifier, and then eventually you get an event call back, which may indicate merely that the message has gone through, or not, and may contain a reply message. The messaging system handles the path and the cached shared secrets. All shared secrets are in user space, and messages with different source authentication have different connections and different shared secrets.
Suppose there are potentially many public keys associated with this network address, as is likely to be the case if it is a slave wallet performing Pop and Imap like functions. Then it has one primary public key for initiating communications. Call its low value primary keys p and P. Then Carol sends <code>R</code> in the clear, followed by <code>D</code> encrypted to <code>r*P = p*R</code>, followed by <code>C</code> and <code>r*D</code>, encrypted to <code>r*D = d*R</code>.</p><p>
Bitcoin just generates a key at random when you need one, and records it. A paper wallet is apt to generate a stack of them in advance. They offer the option of encrypting the keys with a lesser secret, but the master secret has to be stronger, because it has to be strong enough to resist attacks on the public keys.
We can do this recursively, and Dave can return another, possibly transient, public key or public key chain that works like a network address. This implies a messaging system whose api is that you send an arbitrary length message with a public key as address, and possibly a public key as authority, and an event identifier, and then eventually you get an event call back, which may indicate merely that the message has gone through, or not, and may contain a reply message. The messaging system handles the path and the cached shared secrets. All shared secrets are in user space, and messages with different source authentication have different connections and different shared secrets.</p><p>
On reflection, there are situations where this is difficult – we would like the customer, rather than the recipients, to generate the obfuscation keys, and pay the money to a public key that consists of the recipients deeply held secret, and a not very deeply held obfuscation shared secret.
Bitcoin just generates a key at random when you need one, and records it. A paper wallet is apt to generate a stack of them in advance. They offer the option of encrypting the keys with a lesser secret, but the master secret has to be stronger, because it has to be strong enough to resist attacks on the public keys.</p><p>
This capability is redundant, because we also plan to attach to the transaction a Merkle hash that is the root of tree of Merkle hashes indexed by output, in Merkle-patricia order, each of which may be a random number or may identify arbitrary information, which could include any signed statements as to what the obligations the recipient of the payment has agreed to, plus information identifying the recipient of the payment, in that the signing key of the output is s\*B+recipient_public key. But it would be nice to make s derived from the hash of the recipients offer, since this proves that when he spends the output, he spends value connected to obligations.
On reflection, there are situations where this is difficult – we would like the customer, rather than the recipients, to generate the obfuscation keys, and pay the money to a public key that consists of the recipients deeply held secret, and a not very deeply held obfuscation shared secret.</p><p>
Such receipts are likely generated by a slave wallet, which may well do things differently to a master wallet. So let us just think about the master wallet at this point. We want the minimum capability to do only those things a master wallet can do, while still being future compatible with all the other things we want to do.
This capability is redundant, because we also plan to attach to the transaction a Merkle hash that is the root of tree of Merkle hashes indexed by output, in Merkle-patricia order, each of which may be a random number or may identify arbitrary information, which could include any signed statements as to what the obligations the recipient of the payment has agreed to, plus information identifying the recipient of the payment, in that the signing key of the output is s*B+recipient_public key. But it would be nice to make s derived from the hash of the recipients offer, since this proves that when he spends the output, he spends value connected to obligations.</p><p>
When we generate a public key and use it, want to generate records of to how it was generated, why, and how it was used. But this is additional tables, and an identifier in the table of public keys saying which additional table to look at.
Such receipts are likely generated by a slave wallet, which may well do things differently to a master wallet. So let us just think about the master wallet at this point. We want the minimum capability to do only those things a master wallet can do, while still being future compatible with all the other things we want to do.</p><p>
One meaning per public key. If we use the public key of a name for many purposes, use it as a name. We don’t use it as a transaction key except for transactions selling, buying, or assigning that name. But we could have several possible generation methods for a single meaning.
When we generate a public key and use it, want to generate records of to how it was generated, why, and how it was used. But this is additional tables, and an identifier in the table of public keys saying which additional table to look at.</p><p>
And, likely, the generation method depends on the meaning. So, in the table of public keys we have a single small integer telling us the kind of thing the public key is used for, and if you look up that table indicated by the integer, maybe all the keys in that table are generated by one method, or maybe several methods, and we have a single small integer identifying the method, and we look up the key in that table which describes how to generate the key by that method.
One meaning per public key. If we use the public key of a name for many purposes, use it as a name. We don’t use it as a transaction key except for transactions selling, buying, or assigning that name. But we could have several possible generation methods for a single meaning.</p><p>
Initially we have only use. Names. And the table for names can have only one method, hence does not need an index identifying the method.
And, likely, the generation method depends on the meaning. So, in the table of public keys we have a single small integer telling us the kind of thing the public key is used for, and if you look up that table indicated by the integer, maybe all the keys in that table are generated by one method, or maybe several methods, and we have a single small integer identifying the method, and we look up the key in that table which describes how to generate the key by that method.</p><p>
So, a table of public key private key pairs, with a small integer identifying the use and whether the private key has been zeroed out, and a table of names, with the rowid of the public key. Later we introduce more uses, more possible values for the use key, more tables for the uses, and more tables for the generation methods.
Initially we have only use. Names. And the table for names can have only one method, hence does not need an index identifying the method.</p><p>
A wallet is the data of a Zooko identity. When logged onto the interent is *is* a Zooko triangle identity or Zookos quandrangle identity, but is capable of logging onto the internet as a single short user identity term, or logging on with one peer identity per host. When that wallet is logged in, it is Zooko identity with its master secret and an unlimited pile of secrets and keys generated on demand from a single master secret.
So, a table of public key private key pairs, with a small integer identifying the use and whether the private key has been zeroed out, and a table of names, with the rowid of the public key. Later we introduce more uses, more possible values for the use key, more tables for the uses, and more tables for the generation methods.</p><p>
We will want to implement the capability to receive value into a key that is not currently available. So how are we going to handle the identity that the wallet will present?
A wallet is the data of a Zooko identity. When logged onto the interent is <em>is</em> a Zooko triangle identity or Zookos quandrangle identity, but is capable of logging onto the internet as a single short user identity term, or logging on with one peer identity per host. When that wallet is logged in, it is Zooko identity with its master secret and an unlimited pile of secrets and keys generated on demand from a single master secret.</p><p>
Well, keys that have a time limited signature that they can be used for certain purposes in the name of another key are a different usage, that will have other tables, that we can add later.
We will want to implement the capability to receive value into a key that is not currently available. So how are we going to handle the identity that the wallet will present?</p><p>
A receive only wallet, when engaging in a transaction, identifies itself as Zooko identity for which it does not have the master key, merely a signed authorization allowing it to operate for that public key for some limited lifetime, and when receiving value, requests that value be placed in public keys that it does not currently possess, in the form of a scalar and the public key that will receive the value. The public key of the transaction output will be s\*B+`D`, where s is the obfuscating value that hides the beneficiery from the public blockchain, B is the base, and `D` is the beneficiary. B is public, s\*B+`D` is public, but s and `D` are known only to the parties to the transaction, unless they make them public.
Well, keys that have a time limited signature that they can be used for certain purposes in the name of another key are a different usage, that will have other tables, that we can add later.</p><p>
And that is another usage, and another rule for generating secrets, which we can get around to another day.
A receive only wallet, when engaging in a transaction, identifies itself as Zooko identity for which it does not have the master key, merely a signed authorization allowing it to operate for that public key for some limited lifetime, and when receiving value, requests that value be placed in public keys that it does not currently possess, in the form of a scalar and the public key that will receive the value. The public key of the transaction output will be s*B+<code>D</code>, where s is the obfuscating value that hides the beneficiery from the public blockchain, B is the base, and <code>D</code> is the beneficiary. B is public, s*B+<code>D</code> is public, but s and <code>D</code> are known only to the parties to the transaction, unless they make them public.</p><p>
The implementation can and will vary from one peer to the next. The canonical form is going to be a Merkle-patricia dac, but the Merkle-patricia dac has to be implemented on top of something, and our first implementation is going to implement the Merkle-patricia dac on top of a particular sqlite database with a particular name, and that name stored in a location global to all programs of a particular user on a particular machine, and thus that database global to all programs of that particular user on that particular machine.
And that is another usage, and another rule for generating secrets, which we can get around to another day.</p><p>
Then we will implement a global consensus Merkle-patricia dac, so that everyone agrees on the one true mapping between human readable names, but the global consensus dac has to exist on top of particular implementations run by particular users on particular machines, whose implementation may well vary from one machine to the next.
The implementation can and will vary from one peer to the next. The canonical form is going to be a Merkle-patricia dac, but the Merkle-patricia dac has to be implemented on top of something, and our first implementation is going to implement the Merkle-patricia dac on top of a particular sqlite database with a particular name, and that name stored in a location global to all programs of a particular user on a particular machine, and thus that database global to all programs of that particular user on that particular machine.</p><p>
A patricia tree contains, in itself, just a pile of bitstreams. To represent actual information, there has to be a schema. It has to be a representation of something equivalent to a pile of records in a pile of database tables. And so, before we represent data, before we create the patricia tree, have to first have a particular working database, a particular implementation, which represents actual data. Particular database first, then we construct universal canonical representation of that data second.
Then we will implement a global consensus Merkle-patricia dac, so that everyone agrees on the one true mapping between human readable names, but the global consensus dac has to exist on top of particular implementations run by particular users on particular machines, whose implementation may well vary from one machine to the next.</p>
In every release version, starting with the very first release, we are going to have to install a database, if one is not already present, in order that the user can communicate with other users, so we will have no automagic creation of the database. I will manually create and install the first database, and will have a dump file for doing so, assuming that the dump file can create blobs.
<p>A patricia tree contains, in itself, just a pile of bitstreams. To represent actual information, there has to be a schema. It has to be a representation of something equivalent to a pile of records in a pile of database tables. And so, before we represent data, before we create the patricia tree, have to first have a particular working database, a particular implementation, which represents actual data. Particular database first, then we construct universal canonical representation of that data second.</p>
A receive only wallet contains the public key and zooko name of its master wallet, optionally a thirty two byte secret, a numbered signed record by the master wallet authorizing it to use that name and receive value on the master wallet secret and its own public key.
<p>In every release version, starting with the very first release, we are going to have to install a database, if one is not already present, in order that the user can communicate with other users, so we will have no automagic creation of the database. I will manually create and install the first database, and will have a dump file for doing so, assuming that the dump file can create blobs.</p>
A zooko quandrangle identifier consists of a public master key, a globally accepted human readable name globally accepted as identifying that key, a local human readable petname, normally identical to the global name, and an owner selected human readable nickname.
<p>A receive only wallet contains the public key and zooko name of its master wallet, optionally a thirty two byte secret, a numbered signed record by the master wallet authorizing it to use that name and receive value on the master wallet secret and its own public key.</p>
A contact consists of a public key, and network address information where you will likely find a person or program that knows the corresponding private key, or is authorized by that private key to deal with communications.
<p>A zooko quandrangle identifier consists of a public master key, a globally accepted human readable name globally accepted as identifying that key, a local human readable petname, normally identical to the global name, and an owner selected human readable nickname.</p>
So, first thing we have to do is create a wxWidgets program that accesses the database, and have it create Zooko’s triangle identities, with the potential for becoming Zooko’s quandrangle identities.
<p>A contact consists of a public key, and network address information where you will likely find a person or program that knows the corresponding private key, or is authorized by that private key to deal with communications.</p>
# Proving knowledge of the secret key of a public key
<p>So, first thing we have to do is create a wxWidgets program that accesses the database, and have it create Zooko’s triangle identities, with the potential for becoming Zooko’s quandrangle identities.</p>
Our protocol, unlike bitcoin, has proof of transaction. The proof is private, but can be made public, to support ebay type reputations.
<h2>Proving knowledge of the secret key of a public key</h2><p>
Our protocol, unlike bitcoin, has proof of transaction. The proof is private, but can be made public, to support ebay type reputations.</p>
Supposing you are sending value to someone, who has a big important reputation that he would not want damaged. And you want proof he got the value, and that he agreed to goods, services, or payment of some other form of money in return for the value.
<p>Supposing you are sending value to someone, who has a big important reputation that he would not want damaged. And you want proof he got the value, and that he agreed to goods, services, or payment of some other form of money in return for the value.</p>
Well, if he has a big important reputation, chances are you are not transacting with him personally and individually through a computer located behind a locked door in his basement, to which only he has the key, plus he has a shotgun on the wall near where he keeps the key. Rather, you are transacting with him through a computer somwhere in the cloud, in a big computing center to which far too many people have access, including the computer center management, police, the Russian mafia, the Russian spy agency, and the man who mops the floors.
<p>Well, if he has a big important reputation, chances are you are not transacting with him personally and individually through a computer located behind a locked door in his basement, to which only he has the key, plus he has a shotgun on the wall near where he keeps the key. Rather, you are transacting with him through a computer somwhere in the cloud, in a big computing center to which far too many people have access, including the computer center management, police, the Russian mafia, the Russian spy agency, and the man who mops the floors.</p>
So, when "he", which is to say the computer in the cloud, sends you public keys for you to put value into on the blockchain, you want to be sure that only he can control value you put into the blockchain. And you want to be able to prove it, but you do not want anyone else except you and he (and maybe everyone who has access to the data center on the cloud) can prove it except you make the data about your transaction public.
<p>So, when "he", which is to say the computer in the cloud, sends you public keys for you to put value into on the blockchain, you want to be sure that only he can control value you put into the blockchain. And you want to be able to prove it, but you do not want anyone else except you and he (and maybe everyone who has access to the data center on the cloud) can prove it except you make the data about your transaction public.</p>
You are interacting with a program. And the program probably only has low value keys. It has a key signed by a key signed by a key signed by his high value and closely held key, with start times and timeouts on all of the intermediate keys.
<p>You are interacting with a program. And the program probably only has low value keys. It has a key signed by a key signed by a key signed by his high value and closely held key, with start times and timeouts on all of the intermediate keys.</p><p>
So he should have a key that is not located in the datacenter, and you want proof that only the holder of that key can spend the money – maybe an intermediate key with a timeout on it that authorizes it to receive money, which signs an end key that authorizes the program to agree to deals, but not to receive money – the intermediate key authorized to receive money presumably not being in the highly insecure data center.
So he should have a key that is not located in the datacenter, and you want proof that only the holder of that key can spend the money – maybe an intermediate key with a timeout on it that authorizes it to receive money, which signs an end key that authorizes the program to agree to deals, but not to receive money – the intermediate key authorized to receive money presumably not being in the highly insecure data center.</p>
<p style="background-color : #ccffcc; font-size:80%">This document is licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">CreativeCommons Attribution-Share Alike 3.0 License</a></p>
</body>
</html>
This document is licensed under the [CreativeCommons Attribution-Share Alike 3.0 License](http://creativecommons.org/licenses/by-sa/3.0/){rel="license"}

40
docs/writing_and_editing_documentation.md
View File

@ -94,6 +94,24 @@ Since markdown has no concept of a title, Pandoc expects to find the
title in a yaml inline, which is most conveniently put at the top, which
renders it somewhat legible as a title.
Thus the markdown version of this document starts with:
```markdown
---
title: >-
Writing and Editing Documentation
# katex
...
```
## Converting html source to markdown source
In bash
```bash
fn=foobar
git mv $fn.html $fn.md && cp $fn.md $fn.html && pandoc -s --to markdown-smart --eol=lf --wrap=preserve --verbose -o $fn.md $fn.html
```
## Math expressions and katex
@ -154,15 +172,19 @@ For it offends me to put unnecessary fat in html files.
### overly clever katex tricks
$$k \approx \frac{m\,l\!n(2)}{n}%uses\, to increase spacing, uses \! to merge letters, uses % for comments $$
spacing control
: $$k \approx \frac{m\,l\!n(2)}{n}%uses\, to increase spacing, uses \! to merge letters, uses % for comments $$
$$k \approx\frac{m\>\ln(2)}{n}%uses\> for a marginally larger increase in spacing and uses \ln, the escape for the well known function ln $$
$$ \exp\bigg(\frac{a+bt}{x}\bigg)=\huge e^{\bigg(\frac{a+bt}{x}\bigg)}%use the escape for well known functions, use text size sets$$
size control
: $$ \exp\bigg(\frac{a+bt}{x}\bigg)=\huge e^{\bigg(\frac{a+bt}{x}\bigg)}%use the escape for well known functions, use text size sets$$
$$k\text{, the number of hashes} \approx \frac{m\ln(2)}{n}% \text{} for render as text$$
text within maths
: $$k\text{, the number of hashes,} \approx \frac{m\ln(2)}{n}% \text{} for render as text$$
$$\def\mydef#1{\frac{#1}{1+#1}} \mydef{\mydef{\mydef{\mydef{y}}}}%katex macro $$
katex macro used recursively
: $$\def\mydef#1{\frac{#1}{1+#1}} \mydef{\mydef{\mydef{\mydef{y}}}}%katex macro $$
## Tables
@ -385,10 +407,9 @@ You change a control point, the effect is entirely local, does not
propagate up and down the line.
If, however, you have a long move and a short move, your implied control
point is likely to be in a pathological location, in which case you have to
follow an S curve by a C curve, and manually calculate the first point of
the C to be in line with the last two points of the prior curve.
point is likely to be in a pathological location, so the last control point
of the long curve needs to be close to the starting point of the following
short move.
``` default
M point q point point t point t point ... t point
```
@ -434,7 +455,8 @@ choice of the initial control point and the position of the t points, but you ca
down the line, and changing any of the intermediate t points will change
the the direction the curve takes through all subsequent t points,
sometimes pushing the curve into pathological territory where bezier
curves give unexpected and nasty results.
curves give unexpected and nasty results. Works OK if all your t curves
are of approximately similar length.
Scalable vector graphics are dimensionless, and the `<svg>` tag's
height, width, and ViewBox properties translate the dimensionless