<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">On Wed, May 19, 2021 at 12:52 PM Natanael <<a href="mailto:natanael.l@gmail.com">natanael.l@gmail.com</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto">Establishing that broad consensus of knowledge exists across many entities without centralization is literally the main innovation of Bitcoin via proof of work. But like PHB mentioned for his Mesh system, knowing that you share a common association between a name and a public key isn't enough to establish an identity, as you still have no trust anchor (although it simplifies the task). In addition to his Mesh, there also trusted timestamping and transparency logs (<a href="http://keybase.io" target="_blank">keybase.io</a> uses the latter) which shows alternative ways to implement this capability through federated entities (using distributed knowledge as rollback prevention/detection).</div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">The Mesh doesn't impose a trust model, it provides a toolkit to support multiple models as required by different circumstances. The validation criteria Alice applies to Bob are different according to what she wants to do with him, arrange dinner, buy his yacht, invest in his mutual fund, ask his advice as her bank manager, etc. </div><br></div><div><div class="gmail_default" style="font-size:small">Notarizing validation events is very powerful as the cost of backdating an attack is essentially infinite. The Mesh part is the Mesh formed by cross notarization of the notary logs. So Alice sends her log apex to her Mesh Service Provider, which in turn sends its notary apex to the callsign registry, which sends its apex to the MSP which sends its apex back to Alice. At this point, Alice is her own root of trust for notarizing all events prior to the time she sent her apex value.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">[NB this is only one form of notarization allowed but it is easiest to explain with respect to a single node everyone is two degrees of connection away from.]</div><div class="gmail_default" style="font-size:small"><br></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto">Stuff like checking for low entropy names and pseudonym age in a system like this is only a heuristic at best for detecting a MITM or Sybil attack. Trust anchors are important.</div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">And for certain transactions, the real question is not 'is this secure' but 'who will make me whole'. Credit card transactions are easy to secure as every transaction is insured.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The Madoff scheme demonstrates why this form of safeguard is important - Ponzi schemes are always sure fire bets until they aren't. </div><br></div><div><br></div><div> </div></div></div>