1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 2E992C077D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 7 Dec 2019 04:10:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id 1D73385198
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 7 Dec 2019 04:10:12 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id n1BUP_Edy4yX
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 7 Dec 2019 04:10:10 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40141.protonmail.ch (mail-40141.protonmail.ch
[185.70.40.141])
by fraxinus.osuosl.org (Postfix) with ESMTPS id 459DA87728
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 7 Dec 2019 04:10:08 +0000 (UTC)
Date: Sat, 07 Dec 2019 04:09:52 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1575691799;
bh=gFpIDYo4w3+XsSqT/IeoAbWjpAw9WQSA0BVupuxGY2s=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=ALmAR7fKBHzw8tUX+kAaifqMrL7WY5ZNGMqcFiwAMMP2N8gckc96KIZj2wwC29jtV
Fh/r8I8HmO8ul4FfPK9Gr1ohR3n+9DFrV31s2syH3iWe+qJ2KByH4lsQLcWSmTx2p3
21umoG02rbd7wjkSswFowJnE0oZqJtkU1h2NqZbs=
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Dec 2019 04:10:12 -0000
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
|
