<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 1, 2021 at 9:21 PM jrzx via cryptography <<a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>On Tuesday, January 26, 2021 11:24 PM, Ray Dillinger <<a href="mailto:bear@sonic.net" target="_blank">bear@sonic.net</a>> wrote:<br></div><div>> What you're checking with the
authority about is the potential for inconsistent additional<br></div><div>> uses
of the token. If you check with an authority and discover there
was a particular chain<br></div><div>> height where the authority's chain and the
token's chain show different spends for<br></div><div>> example, you can figure
out who double spent it, revoke their cert, and sue them for<br></div><div>> counterfeiting. But you don't need the authority's help to see
that the record of spends<br></div><div>> from minting to you is well-formed, and
the double-spend->revoke feature, combined with<br></div><div>> certs NOT being
freely available, should keep instances of double spending very
rare.<br></div><div> <br></div><div>"Certs not being freely available" is the number of the beast problem that crypto currency attempts to address.</div></blockquote><div><br></div><div class="gmail_default" style="font-size:small">The original Haber Stornetta patent is title 'Catenate certificate'. It was conceived as a PKI. And that is how I am now looking to apply it in my TKI.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">What I do not do is (1) proof of work, (2) pretend to mint currency or (3) pretend a ledger based system provides anonymous cash.</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 am almost done with the support code for the service, here is how I see Mesh callsigns working:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">1) The callsign catalog is maintained as an append only log authenticated by means of a Merkle tree that is periodically signed by the registry authority and cross notarized with other logs on a regular basis. This results in a very high social work factor for anyone trying to modify entries after a few hours have elapsed.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">2) The registry does not provide lookup services directly. These are provided by separate providers who maintain complete, realtime copies of the log maintained by the registry. This insulates the registry from DoS attacks and ensures that the worst case scenario for the registry is it stops accepting new registrations. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Third party lookup services are chosen by the user and MAY offer anti-abuse filtering services. I have no interest in Boris Johnson or his ilk censoring my content but I might well pay a Comodo or a McAfee or the like to curate callsigns to eliminate known bad actors that might harm me.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">3) A callsign registry entry maps a name (e.g. @alice) onto a public signature verification key fingerprint (MER2-ER...) and a service provider. The only case in which a registration needs to be updated by the user is when they change service providers. The signature verification key is the root of trust under which the name is interpreted.<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">3a) (2) and (3) combined eliminate over 99% of the cost of running the registry. It is the thinnest of thin registries. This is important because I will be funding the running costs for at least the first several years myself. I do not want to have to take VC or other funds to do this. So the cost of running the registry has to be manageable even in the case of a success disaster.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">3b) The callsign registry forms a key-centric PKI. The cost of validation is avoided in the first instance by making issue of names coextensive with the registration of keys. No ambiguity in the interpretation of @example or @alice or @bob can arise from the use of the callsigns.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">4) Service providers are identified by callsign. Service discovery is effected by either a DNS name (<a href="http://example.com">example.com</a>) or by the IP address of authoritative DNS
servers for the domain example._mmm. Thus, Mesh applications can continue to function even in the case that a service provider's DNS registration is deleted or interfered with.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">5) 'In ordinary circumstances' registrations are for life. The only circumstance in which callsigns are reassigned is in cases of an intellectual property dispute over the name itself. And such reassignment does not cause redirection of previous bindings.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">5a) What this means is that if Alice exchanges contact information with @bob and the callsign is subsequently reassigned because of an IPR dispute, the contact information in Alice's contact directory is unchanged and her instant messages, etc. go to the Bob she exchanged contact info with. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">5b) Obviously names such as @skype and @telegram and @microsoft have pre-existing semantics implied from their existing use in the world. These MUST be interpreted in the way people expect or bad things will happen.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">6) The registry authority is a not-for profit. Callsign registrations of 'long' names are performed on a cost recovery basis which 'should' be no more than $0.10 per name. Shorter names cost more. The surplus from the registration fees goes to fund development of open source resources to support the Mesh infrastructure (code, specifications, courses, etc). This should preclude attempts to set up rival registries unless the original registry commits a significant breach of good faith.</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 how do we use this? One of the most important is for contact exchange. This is not a new proposal of course. But each and every time a contact exchange app becomes really popular, a Google or the like steps in, buys it up and shuts it down. These companies do not want to empower users with the ability to switch between communications providers without cost, I do.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So Alice meets Bob and they bump their phones, as a result, Alice gets Bob's contact info:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">@Bob {<br></div><div class="gmail_default" style="font-size:small"> Signature: MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ</div><div class="gmail_default" style="font-size:small"> MSP: [<a href="http://example.com">example.com</a>, <a href="http://example.net">example.net</a>]</div><div class="gmail_default" style="font-size:small"> DNS: [<a href="mailto:bob@example.com">bob@example.com</a>]</div><div class="gmail_default" style="font-size:small"> Tel: [+1 666 555-0199]</div><div class="gmail_default" style="font-size:small"> Mesh: [bob@skype, bob42@telegram, bob69@signal, ... ] }</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The point here is that the Mesh namespace federates and disambiguates the rest.
<a href="mailto:bob@example.com">bob@example.com</a> is interpreted relative to the ICANN root.
bob@skype is interpreted relative to the Mesh callsign registration for @skype which will only be registered so that it goes to the place users reasonably expect.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Notice here that Skype, Signal, Telegram, etc, get their TLDs in mesh space for a few thousand bucks, most of which will be engineering time working out how to make the connection between Mesh callsign space and their infrastructure 100% solid. There will never be a renewal fee. And that is critical for Bob and Alice because they don't want their names to rely on the demands from ICANN's yacht fund for increased rents.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">My plan is to preallocate certain callsigns to ensure they go to the right people and organizations. @LewisHamilton should go to exactly one person. And given the anti-abuse mechanisms in the Mesh, Hamilton could use that as his callsign for both his family and his fans. He just has to authorize the two sets differently.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">That won't be perfect, nothing ever is. But we can try. One possibility would be to run the proptype registry for a year and allow people to propose names of people that should be reserved.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"></div></div></div>