<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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--'</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Right now, profiles are registered at a Mesh Service under their account name, '<a href="mailto:alice@example.com">alice@example.com</a>'. The original idea for the callsign registry was that it would provide a mapping from a profile fingerprint to an account name.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So in the new scheme, <a href="mailto:alice@example.com">alice@example.com</a> and @alice are both just friendly names for the account 'MAF3-FR5T--'. This is of course how BitCoin has always worked.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So now, Alice might host her account at <a href="http://example.com">example.com</a> but have multiple aliases pointing to her profile fingerprint and account host at multiple service providers, <a href="mailto:alice@example.com">alice@example.com</a>, <a href="mailto:the-real-alice@example.net">the-real-alice@example.net</a>, 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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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 <a href="mailto:alice@example.com">alice@example.com</a> on her business card or her callsign @alice and Bob can reach her.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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 <a href="http://example.com">example.com</a> 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. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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).</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">[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.]</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">ticket = kdf (seed, index)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The registry then performs some number of iterative hash functions on the result to create the witness value:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">witness = H(H( ... H(ticket)))</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">witness = H ( witness' )</div><div class="gmail_default" style="font-size:small">witness' = H ( witness'' )<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The witness values are then enrolled in a public ledger.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The purchaser of the carnet receives (by encrypted means) the seed, the index range, etc.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div></div></div></div></div>