Date: Sat, 07 Dec 2019 04:09:52 +0000
To: =?UTF-8?Q?Jose_Femen=C3=ADas_Ca=C3=B1uelo?= <jose.femenias@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <N9-zGG_2BG2WsjQrRXInpHcn53gxQwUb-P9K5P2DL_NoZwYsNAzfgYSvgT4hAyWbmZmshWM5peZKGRmKMfDECvDifwJNUXG7tULEQPLixCU=@protonmail.com>
In-Reply-To: <6CB7E73C-57C9-428B-83E6-36113B619BFB@gmail.com>
References: <E70934BE-E7BE-4035-BBFF-47005E25C441@gmail.com>
 <fBhj5XmKd7-1Bk13TuSLkwYGGgbvdVUbSr-dOjJk9pe0cb6CdLPhCUgbIDFyCv6ua2yJJc2lpn-IX42jN2MH8FGex7oqlxb2t-UKIUjPYrA=@protonmail.com>
 <AF3AF268-8E5B-481E-A5C7-205D171E90A5@gmail.com>
 <Qul4dCoKs2JEQgCYkvdn_QYjgQ5ucpwHZCHdU7qOZ5DGYOGB7p37-s7GN6Jg_NKDzsLlGv-WkOU_mY-a1A_tygRlnhOVnJBK9nvAJ3Gs-bE=@protonmail.com>
 <6CB7E73C-57C9-428B-83E6-36113B619BFB@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
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 "bitcoin-dev-request@lists.linuxfoundation.org"
 <bitcoin-dev-request@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] easypaysy - A layer-two protocol to send payments
	without addresses
Precedence: list

Good morning Jose,


> > If the service provider retains even partial control, then it can refus=
e to cooperate with the user and the user will be unable to update his or h=
er account.
> > This is not fixable by the use of mirror servers.
>
> You are right about that too=E2=80=A6 (I wonder if some kind of MAST smar=
t contract could fix this, maybe you have a suggestion for this; I am think=
ing K of M users can override the service provider if he misbehaves)

Sybils are trivial, and a "quorum" of K users can always be manufactured fo=
r a targeted attack.
Far better to use an n-of-n, with the service provider as one of the n, and=
 use pre-signed transactions like in Lightning Network to allow unilateral =
ending of the agreement.

> What I have in mind, but haven=E2=80=99t completely figured out, in case =
of an uncooperative service provider -or just because one user decides to f=
ly solo- is the possibility for a sub-account to =E2=80=98detach=E2=80=
=99 itself from the master account.

A "graftroot transform" can be done, at the cost of moving data offchain an=
d thus requiring easypaysy to have its own overlay network.
Basically, one commits onchain (via `OP_RETURN`, sign-to-contract, pay-to-c=
ontract, or even just using P2PKH) some public key and a series of `R` valu=
es.
Then, control messages are authorized by signatures validated with the publ=
ic key, and use up individual `R`s in the series of `R` values.
(Alternately we commit just to the public key and a "next" `R` value, and e=
ach control message indicates a new public key and next `R` value that is s=
igned with the current public key and "current" `R` value, to form a chain =
of off-blockchain control messages.)

Having a precommitted series of `R` values ensures that the signer can only=
 safely use an `R` once and thus cannot otherwise attack the network by giv=
ing half of it one control message and the other half a conflicting control=
 message: if someone does so, the `R` must be reused between both conflicti=
ng control messages and this allows trivial revelation of the private key (=
i.e. a form of single-use-seal).
Presumably the private key is valuable by itself somehow.

> But, based on the private feedback I am having from two prominent figures=
 in the space, making sure the protocol is easy to implement for SPV wallet=
s is essential to encourage wallet adoption.
> A separate transport layer doesn=E2=80=99t fit well with this.

Indeed.

>
> So, maybe your suggestion will become more applicable in future iteration=
s of the protocol. I may request your help for further clarification about =
this issue, if you are so kind (as you always are).
>
> > > d) Regarding your comments on the possibility of adding the output in=
dex in the account ID, I still don=E2=80=99t see the need for the use case =
of easypaysy (since, by definition, easypaysy accounts must have exactly on=
e input and two outputs).
> >
> > Do you mean, that if the user makes a control transaction to change the=
 details of the account, then the user is forced to change the easypaysy id=
entifier?
> > My initial reading of your whitepaper is that the easypaysy identifier =
refers to the funding txo that roots the further control transactions.
> > If so, the funding txo is not necessarily a one-input two-output transa=
ction.
>
> The easypaysy identifier doesn=E2=80=99t point to the funding TXO. Instea=
d it points to the first transaction that spends the funding TXO (the TX wi=
th the OP_RETURN containing the =E2=80=98Rendezvous descriptor=E2=80=99)

Ah, I see my misunderstanding now.

Regards,
ZmnSCPXj