Send with attestation and send to attestation, MVP use-case of attestation

victor.zhang · November 28, 2019, 12:03am

This article about LinkDrop protocol introduces a method to send tokens without the receiver having Ethereum address, aimed at solving onboarding issue:

It looks similar to TokenScript's attestation work, which enables one to send a token to another by email address without knowing the recipient Ethereum address:

github.com

AlphaWallet/blockchain-attestation/blob/master/use-cases/email-address-attestation.md


# Problem

A user, Alice, wishes to send ethers to Bob who doesn't have an Ethereum address. Alice, however, knows something of Bob that can be attested. e.g. Bob's email address.

The knowledge to be attested, e.g. email, can't be learned from an observer with access to the Ethereum blockchian.

# Protocol

1. Alice prepare by learning Bob's email address 𝑥, picking a 𝑠,
calculating ℎ(ℎ(𝑥, 𝑠)) as 𝑧.

2. Alice signs a message that asks her smart contract to pay out if
    someone sends a transaction which contains:

    - a 𝑦 where ℎ(𝑦) = 𝑧, and

    - a known authority's signature that binds 𝑦 to the signer of the
      transaction

This file has been truncated. show original

The work was part of the undergoing in the weekly TokenScript Thursday work-group meetings. Today is Thursday again, shall we talk about it this evening?

To me, it seems LinkDrops model (“Send with attestation”) requires a secure channel to delivery, but no requirement for the receiver. The attestation protocol (“send to attestation”) doesn’t care the secure channels but requires the receiver have or can get an attestation.

weiwu.zhang · November 27, 2019, 11:59pm

Let's say the problem that needs to be solved here is to send someone a token without knowing his email address.

In solving that problem, in LinkDrop model, it's assumed that there is a secure (confidential) way to deliver the link to the end-user and that opening the link in a browser does not leak the link. These assumptions are not true since there are multiple points of potential leaks:

Android/iOS's leak through link handling.
If a link is sent by email, the Email software which may have a link redirector.
The web server that opens the link has to be secured, or the log leaks.

Generally speaking it's not good to make a security assumption that is different than other IT systems. In most IT systems, link itself is not treated as secret.

As you observed a "send-to-attestation" protocol in the TokenScript's attestation work allows Alice to send a token to Bob through an attestation Bob has (or will have), without knowing Bob's Ethereum address. Alice (the sender) has to know something of Bob that bob can proof. Typically, an email address, since that's how people send hyperlinks.

In short, in send-to-attestation model there is no weakness to lose the token even if every connection is insecure (or in public); in their Linkdrop model there is such a weakness, but they do allow the use of MagicLink in absence of an attestor (email address attestor) with the ASSUMED security of the link.