Date: Fri, 06 Dec 2019 17:16:44 +0000
To: =?UTF-8?Q?Jose_Femen=C3=ADas_Ca=C3=B1uelo?= <jose.femenias@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <Qul4dCoKs2JEQgCYkvdn_QYjgQ5ucpwHZCHdU7qOZ5DGYOGB7p37-s7GN6Jg_NKDzsLlGv-WkOU_mY-a1A_tygRlnhOVnJBK9nvAJ3Gs-bE=@protonmail.com>
In-Reply-To: <AF3AF268-8E5B-481E-A5C7-205D171E90A5@gmail.com>
References: <E70934BE-E7BE-4035-BBFF-47005E25C441@gmail.com>
 <fBhj5XmKd7-1Bk13TuSLkwYGGgbvdVUbSr-dOjJk9pe0cb6CdLPhCUgbIDFyCv6ua2yJJc2lpn-IX42jN2MH8FGex7oqlxb2t-UKIUjPYrA=@protonmail.com>
 <AF3AF268-8E5B-481E-A5C7-205D171E90A5@gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] easypaysy - A layer-two protocol to send payments
	without addresses
Precedence: list

Good morning Jose,

> Hi ZmnSCPxj,
>
> first of all: do you ever sleep? ;-)

It seems possible, that, I do not.


> b) Master accounts are included in the white paper as a feature for a fut=
ure release.
> The roadmap is not set yet, but I=E2=80=99d like to include a first relea=
se of the protocol that only covers the most basic features, to make it sim=
pler and safer for wallet developers.
> Master accounts aren=E2=80=99t a priority, since they are more oriented t=
owards scaling the proposal, and that is far from being a problem yet.
> So, this feature is not well defined for now. However, as presented in th=
e white paper, the =E2=80=98service provider=E2=80=99 has really no control=
 over your money.
>
> He would basically do a just a few things:
>
> -   Aggregate the account info (up to 2048 individual accounts per master=
 account).
> -   Hash every account info, sort them, and calculate the Merkle root of =
a tree containing them all.
> -   Create a JSON document containing the information of all the sub-acco=
unts included in the pack.
> -   Make that JSON document publicly available, probably with a https: UR=
L (That=E2=80=99s called an Authoritative server)
> -   Finally, create and publish a TX that contains a pointer to the Autho=
ritative server, and the Merkle root of the set of accounts.
>
>     The service provider would have NO control whatsoever of your funds, =
nor can he block payments, etc.
>     There is some sort of delegation, but no trust involved here. The Mer=
kle root protects agains any attempt of tampering with the account data.

This does not seem to mesh well with the other non-Master parts of the prot=
ocol, where further updates on the single account backed by a funding TXO a=
re performed by spending the funding TXO and creating a transaction with `O=
P_RETURN`.

In addition, I would like to suggest as well that instead of `OP_RETURN`, y=
ou could instead use "sign-to-contract".

Sign-to-contract is simply that, when signing, instead of selecting a rando=
m `r` and computing `R` as `R =3D r * G`, you select a random `r` and a con=
tract or other message `c`, and compute `R` as `R =3D r * G + h((r * G) | c=
) * G`.
Then the user can provide the message `c` independently of the signature, v=
ia another mechanism, and reveal `r * G` and `c` and point to the signature=
 as a commitment to the message `c`.
Although, it does have the drawback that using sign-to-contract require a d=
ifferent layer / overlay network to broadcast messages `c`, but it does red=
uce the cost on the blockchain layer, which is always a good thing.
Similar issues are faced by the RGB project, for instance, and defiads expl=
icitly uses a separate overlay network when transmitting advertisements (bo=
th RGB and defiads use the opposite pay-to-contract, which tweaks the pubke=
y rather than the ephemeral `R`).

>
>     The account=E2=80=99s TX won=E2=80=99t ever disappear from the blockc=
hain, so your account info will always be there.
>     Worst case scenario, the service provider disappears and users can=
=E2=80=99t download the Json document containing your account information.
>
>     To mitigate this issue, the white paper suggests the creation of mirr=
or servers.

How about control transactions on top of the funding txo?
Who is able to make further control transactions?
If the service provider gives the user full control of the control transact=
ions on top of the funding txo, then it outright loses the money it put in =
the funding txo and might as well operate as a full exchange.
If the service provider retains even partial control, then it can refuse to=
 cooperate with the user and the user will be unable to update his or her a=
ccount.

This is not fixable by the use of mirror servers.


> d) Regarding your comments on the possibility of adding the output index =
in the account ID, I still don=E2=80=99t see the need for the use case of e=
asypaysy (since, by definition, easypaysy accounts must have exactly one in=
put and two outputs).

Do you mean, that if the user makes a control transaction to change the det=
ails of the account, then the user is forced to change the easypaysy identi=
fier?

My initial reading of your whitepaper is that the easypaysy identifier refe=
rs to the funding txo that roots the further control transactions.
If so, the funding txo is not necessarily a one-input two-output transactio=
n.
If not, then each time a control transaction changes the details of the eas=
ypaysy identifier, the identifier itself is changed.0


> If you are interested, please contact me, preferably privately since I wo=
uldn=E2=80=99t want to become much too off topic in this dev-list

I still do not see why it would be off-topic to the devlist.

Regards,
ZmnSCPxj