[Cryptography] A payment scheme for the Mesh

[Phillip Hallam-Baker]

Current status on the Mesh is that the applications are passing unit tests
and alpha tests. Will be making a demo reel next week. So folk can see for
themselves just how much easier applying threshold techniques makes PKI.

The initial release will be the line mode tools. Integration into a Web
browser is stalled waiting on the next release of WebView2 and Maui. No
point implementing functionality Microsoft is working on delivering.

The major infrastructure component that remains unimplemented is the naming
and callsign infrastructure. And thinking about that has caused me to think
through some new design issues.


So to explain what follows, every Mech profile has a unique profile
signature key that is the root of trust for validating all assertions under
the profile. So Alice's profile will have a fingerprint 'MAF3-FR5T--'

Right now, profiles are registered at a Mesh Service under their account
name, 'alice at example.com'. The original idea for the callsign registry was
that it would provide a mapping from a profile fingerprint to an account
name.

I now think that is all mistaken and that Mesh Services should only know
and use the profile fingerprint and nothing else. Why should a Mesh Service
even need to know that they are servicing Alice?

So in the new scheme, alice at example.com and @alice are both just friendly
names for the account 'MAF3-FR5T--'. This is of course how BitCoin has
always worked.

So now, Alice might host her account at example.com but have multiple
aliases pointing to her profile fingerprint and account host at multiple
service providers, alice at example.com, the-real-alice at example.net, etc.
There is no canonical name. A callsign is simply a name that is serviced by
a distributed name resolution service that takes its registrations from the
callsign registry.

In this scheme, account 'forwarding' is simply a matter of updating the
alias records at the various places they are registered. Unlike SMTP, there
is never a need for message forwarding. Redirection takes place in the name
resolution scheme.

The net is that users never need to interact with either the public key
values or the fingerprints 'MAF3-FR5T-' directly. Humans only need to
interact with human friendly names, or scan QR codes. And even that only on
first contact. As far as Alice is concerned, she can put alice at example.com
on her business card or her callsign @alice and Bob can reach her.


I still think there is value to the callsign system because there will be a
need for some sort of directory that provides 'change of address'
information for when example.com crashes and burns and goes out of business
without providing a forwarding service. Or for that matter, has its data
center struck by a missile fired by Putin's Fascist Forces.

I also need a central peering point to mesh together everyone's personal
notary chains so that the ultimate source of authority for the validity of
the signature on any document Alice verifies will be Alice herself (for the
time interval between her earliest and her latest cross-notarization).


Since I reject Proof of Work as the spawn of Satan, I am going to need some
mechanism to rate throttle callsign registrations. The simplest approach is
to charge a fee which can then go to a foundation to fund the operation of
the registry. Longer names will be almost free, shorter names will sell for
exponentially increasing premiums and allow people to show their patronage
of the foundation. All names will be for life with no renewal fees, the
only cause for reassignment being IPR challenge via UDRP. After
all, @microsoft must point to the Redmond club or bad things happen.

[One feature I did like in Libra was the currency basket idea but not the
implementation which was stupid. There needs to be a concept of equity in
pricing.]

So how to collect a large number of small payment amounts? I think a
variation of the S/KEY, Pedersen Phone Tick Modus, Rivest/Shamir Payword
scheme is indicated.

Since I can't collect payments of $0.10 economically, my plan is to sell a
'carnet' of 50 or more coupons for $5 plus handling fees. So for the price
of a latte, you can establish multiple account aliases for yourself and
still have plenty left over to give out to friends and family according to
their needs.

Presale of the carnets has another effect, it means that carnet holders are
insulated from future price rises and can even sell their unused tickets if
the registry attempted to raise prices. It also provides a means of
pre-funding the capital equipment needed to bootstrap the registry.

My cryptography goal here is for the payment system to be transparent so
everyone can see that they have not been cheated. Even though the amount of
money may be small, there will be arguments.


So to create a carnet, the registry creates a random seed 'seed' and runs
it through a KDF with a sequence of numbers [1..50] as identifiers for each
ticket.

ticket = kdf (seed, index)

The registry then performs some number of iterative hash functions on the
result to create the witness value:

witness = H(H( ... H(ticket)))

For the time being, will leave the number of iterations TBD because each
iteration provides a means of fixing up after a breach. For future use, we
define witness' witness'' etc as follows:

witness = H ( witness' )
witness' = H ( witness'' )

The witness values are then enrolled in a public ledger.

The purchaser of the carnet receives (by encrypted means) the seed, the
index range, etc.


A ticket can be spent directly or given to another person to use. In either
case, the spender presents their registration request and the token,
witness'. The registry checks that the witness value is correct. If it is,
the registration is granted and the ticket is recorded as having been used.
The claim value witness' is entered into the registry for transparency.

The user waits for the next update to the registry. If the registry behaves
correctly and the registration is correctly entered, the process is
complete.

But what if the registry is asked to register @alice for Alice but instead
uses the witness value to register @mallet to Mallet's fingerprint?

If Alice doesn't complain within some fixed interval, the answer should
probably be 'nothing at all'. But if the time interval is short, there
should be some arbitration process available so as to keep the registry
accountable.

My proposal for this situation is that Alice submit a complaint to an
arbiter that operates under a multi-phase process using the values
witness'', witness''' etc. foru authentication. This is similar to Micali's
fair contracts scheme in which the arbiter is only involved in the case
that there is a default.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20220402/ca924488/attachment.htm>