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
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
|
Return-Path: <jose.femenias@gmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id B2167C077D;
Fri, 6 Dec 2019 18:47:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 9FA6387A9D;
Fri, 6 Dec 2019 18:47:47 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id UV01qn7oj7Gg; Fri, 6 Dec 2019 18:47:43 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com
[209.85.221.65])
by whitealder.osuosl.org (Postfix) with ESMTPS id CE47A876EE;
Fri, 6 Dec 2019 18:47:42 +0000 (UTC)
Received: by mail-wr1-f65.google.com with SMTP id c9so8880164wrw.8;
Fri, 06 Dec 2019 10:47:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=l9dbOZGEKIhWyfMvL6tSHl3RTe43P+nypyCTYRR/Js4=;
b=nWZ7+GUxCddOw9wD3+eub9BTrMMBoiRHmL3vRKOU5ZqxI0BvUJo0Y/gFonsh7YBapi
zxjBe0ZDb/OBIGv8PHcyIYjlZw0zEKEV/HTeqFByfOAZTt4ehbQDSZ8WJIWkpyJ8B/9B
//omOFGYtg/9WyDafHKST8it6Uy/1Jrq0T4kOvG39V0M3UsxtIn1ExHfUyZrqgKS9+bt
0BCDi7sYuXe6QNdqxwq37U3GB+u8ViUy9QndyCOBtSlEuCHUgJzMYresWeMl4yTIJy9u
5ayY8ujFJqb4f3+zQOvi4ALMAvzpMnl+gggV5cgwJq7u5ngOuOlbuBi+YgdQ1hfrBFQJ
uEbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=l9dbOZGEKIhWyfMvL6tSHl3RTe43P+nypyCTYRR/Js4=;
b=rHoy/ydw7wlctWG3HvNUzF0wNk0GTcuAZ/ZwlwmMwMMYZsmFVOxaahd1NrbxqDvtTP
rJpLrRObmKdV4UTD4gH0nXGq68STEgNysLJaHR0K3Jo9tzHaJrqNLfVrnktZZnt6DYz0
GP8pis7r42qStKGubQiRz5xnwu+mdEhUQH/GVt/zsxxJL2WgK4AkLZLCriGtPCgEnB2f
1oWQWEgc/Ykj4M/VkogevuWvrXy03EP5zgNqYqXqDB92x+RXYjyZO3T6HHYX/On2KI3T
4Z/G2bKoCLpBrsR1i4/fcNJp+k0e/qhX+HODXV9ol+ElFlXCjLi4TRY3hJAlJ4AqNPJr
rHHQ==
X-Gm-Message-State: APjAAAVXcegrgC5qLAzuEc0i2nK9e5Vq61YlupS6exeODVii/J10oY1p
y74AGaXu7c2u92tPIlJd0lM=
X-Google-Smtp-Source: APXvYqy/d6kt9b40wGqWQcYTUhSepyR/85vifOx+8LkBJtqCDCEViobdl1wbpTsvTfRaxicTUq9rmQ==
X-Received: by 2002:a05:6000:1248:: with SMTP id
j8mr16499155wrx.44.1575658060858;
Fri, 06 Dec 2019 10:47:40 -0800 (PST)
Received: from [192.168.1.35] ([178.60.38.49])
by smtp.gmail.com with ESMTPSA id l7sm16969607wrq.61.2019.12.06.10.47.39
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Fri, 06 Dec 2019 10:47:40 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: =?utf-8?Q?Jose_Femen=C3=ADas_Ca=C3=B1uelo?= <jose.femenias@gmail.com>
In-Reply-To: <Qul4dCoKs2JEQgCYkvdn_QYjgQ5ucpwHZCHdU7qOZ5DGYOGB7p37-s7GN6Jg_NKDzsLlGv-WkOU_mY-a1A_tygRlnhOVnJBK9nvAJ3Gs-bE=@protonmail.com>
Date: Fri, 6 Dec 2019 19:47:38 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <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>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
X-Mailer: Apple Mail (2.3273)
X-Mailman-Approved-At: Sun, 08 Dec 2019 17:22:55 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@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: Fri, 06 Dec 2019 18:47:47 -0000
Hi ZmnSCPxj,
>> It seems possible, that, I do not.
Haha, I=E2=80=99am starting to believe that=E2=80=99s not a joke ...
>>=20
>> This does not seem to mesh well with the other non-Master parts of =
the protocol, where further updates on the single account backed by a =
funding TXO are performed by spending the funding TXO and creating a =
transaction with `OP_RETURN`.
>>=20
>>=20
You are right. The lifecycle of a regular easypaysy account states that =
you spend its TXO circularly as many times as you want, specifying =
changes in its OP_RETURN (you can=E2=80=99t change the Identity or Value =
key).
When you want to revoke an account, you simply spend its last update (if =
any) to a different address (not the one it was funded originally with).
> 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 =
transactions 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.
Nope, he will keep control of the TXO keys.
> 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 account.
>=20
> 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 =
smart contract could fix this, maybe you have a suggestion for this; I =
am thinking K of M users can override the service provider if he =
misbehaves)
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 fly solo- is the possibility for a sub-account to =E2=80=98detach=E2=80=
=99 itself from the master account.
The sub-account holder would do so by:
a) Funding the multisig 2-of-2 address composed of his Id_key + =
Value_key, included in the common JSON file, not the Master TX. (And =
yes, in this event he will need to buy some btc, because life is =
hard...)
b) Publishing his own update, much like a regular easypaysy account =
does.
In any case, the account ID never changes, it would always keep pointing =
to the original place where it appeared on the blockchain.=20
User wallets would have to query for the multisig address of a =
particular account to check whether the account is detached or not.
As as side note, I expect most easypaysy accounts to choose only =
non-interactive payments, since they have fewer requirements than their =
interactive counterparts; so -in most cases- the majority of users =
won=E2=80=99t ever have to update their accounts.
So, even if the =E2=80=98service provider=E2=80=99 goes away or becomes =
uncooperative, it is just business as usual for the sub-account owners, =
and they can work just fine with the mirrors.
(Again, all of these is speculative for now. I hope scalability will =
become an issue for easypaysy one day, but I think we=E2=80=99ll have =
time to work out the best solution by then)
>> In addition, I would like to suggest as well that instead of =
`OP_RETURN`, you could instead use "sign-to-contract=E2=80=9D=E2=80=A6.
I really need to study this further before I can express an informed =
opinion on your suggestion.
On the other hand, for Master accounts I don=E2=80=99t think cost or =
space should be a problem, since both can be shared among up to 2048 =
sub-accounts.
For regular accounts, it could be.
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 wallets is essential to encourage wallet adoption.
A separate transport layer doesn=E2=80=99t fit well with this.=20
So, maybe your suggestion will become more applicable in future =
iterations 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 =
index 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 one input and two outputs).
>=20
> 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 identifier?
>=20
> 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 =
transaction.
>=20
The easypaysy identifier doesn=E2=80=99t point to the funding TXO. =
Instead it points to the first transaction that spends the funding TXO =
(the TX with the OP_RETURN containing the =E2=80=98Rendezvous =
descriptor=E2=80=99)
So, you are right in that the funding TXO doesn=E2=80=99t need to be a =
one-input, two-output transaction.
> If not, then each time a control transaction changes the details of =
the easypaysy identifier, the identifier itself is changed.
Nope. The easypaysy identifier always points the placement in the =
blockchain of the first transaction that spends the funding TXO, not the =
TXO itself (please read page 3, =E2=80=982.3 Account ID=E2=80=99).
Further updates (performed by spending its single non-zero output to the =
same address) must be verified by wallets (by asking for the payment =
history of the funding address; but they never change the account ID, by =
convention).
So, for example, (I=E2=80=99m following the example in page 13 of the =
white paper):
a) TX #3b00367=E2=80=A64af, in block 859253, that has j outputs and k =
outputs, has an output (k) that sends funds to the 2-of-2 multisig =
address =E2=80=983NhgE9=E2=80=A6bqs=E2=80=99.=20
This is the address that the Identity_key + Value_key can spend.
b) Several blocks later, TX #2a01fe=E2=80=A6aab2, in its single input, =
spends the TXO with another TXO the same address =E2=80=983NhgE9=E2=80=A6b=
qs=E2=80=99.=20
It sends all of the funds (minus the fee) in its first output (the =
2nd is the OP_RETURN).
This TX (called the ep_root_tx in the protocol) appears in block =
859368 at, let=E2=80=99s say position 349. So its permanent ID will be =
(obviating the checksum):=20
=20
btc@859368.349
This is the ID you share with your potential payers. Whenever they =
want to send funds to you, they will look up the 349th transaction at =
block 859368.=20
They don=E2=80=99t need to check the funding TX at all. They only =
have to check the signature of the ep_root_tx, because that=E2=80=99s =
the part of the TX where they can find both the Identity_key and the =
Value_key.
Since this TX, by definition of the protocol, can only have a single =
input, there will be a single signature in it, so there is no need for =
its easypaysy ID to include a pointer to the input in the TX.
c) A few more blocks later, appears TX #72f1ed=E2=80=A6bade8 a similar =
1-input 2-output TX, that updates its OP_RETURN with a new =E2=80=98Rendez=
vous descriptor=E2=80=99 (in the example, it changes the email endpoint)
d) Finally, the user revokes the account by spending the output in c) to =
a different address (17He...A45n).
>> If you are interested, please contact me, preferably privately since =
I wouldn=E2=80=99t want to become much too off topic in this dev-list
>=20
> I still do not see why it would be off-topic to the devlist.
Since the easypaysy proposal is about a layer-2 protocol, I am not sure =
the developers in this list want to see this much detail about something =
that maybe doesn=E2=80=99t affect them at all.
Hopefully I am wrong and this is relevant for many of the list =
subscribers.
Again, thanks for your time and contributions.
Best regards,
Jose
> On 6 Dec 2019, at 18:16, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>=20
> Good morning Jose,
>=20
>> Hi ZmnSCPxj,
>>=20
>> first of all: do you ever sleep? ;-)
>=20
> It seems possible, that, I do not.
>=20
>=20
>> b) Master accounts are included in the white paper as a feature for a =
future release.
>> The roadmap is not set yet, but I=E2=80=99d like to include a first =
release of the protocol that only covers the most basic features, to =
make it simpler and safer for wallet developers.
>> Master accounts aren=E2=80=99t a priority, since they are more =
oriented towards 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 the white paper, the =E2=80=98service provider=E2=80=99 has really no =
control over your money.
>>=20
>> He would basically do a just a few things:
>>=20
>> - 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-accounts included in the pack.
>> - Make that JSON document publicly available, probably with a =
https: URL (That=E2=80=99s called an Authoritative server)
>> - Finally, create and publish a TX that contains a pointer to the =
Authoritative server, and the Merkle root of the set of accounts.
>>=20
>> 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 =
Merkle root protects agains any attempt of tampering with the account =
data.
>=20
> This does not seem to mesh well with the other non-Master parts of the =
protocol, where further updates on the single account backed by a =
funding TXO are performed by spending the funding TXO and creating a =
transaction with `OP_RETURN`.
>=20
> In addition, I would like to suggest as well that instead of =
`OP_RETURN`, you could instead use "sign-to-contract".
>=20
> Sign-to-contract is simply that, when signing, instead of selecting a =
random `r` and computing `R` as `R =3D r * G`, you select a random `r` =
and a contract 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, via 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 different layer / overlay network to broadcast messages `c`, =
but it does reduce the cost on the blockchain layer, which is always a =
good thing.
> Similar issues are faced by the RGB project, for instance, and defiads =
explicitly uses a separate overlay network when transmitting =
advertisements (both RGB and defiads use the opposite pay-to-contract, =
which tweaks the pubkey rather than the ephemeral `R`).
>=20
>>=20
>> The account=E2=80=99s TX won=E2=80=99t ever disappear from the =
blockchain, 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.
>>=20
>> To mitigate this issue, the white paper suggests the creation of =
mirror servers.
>=20
> 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 =
transactions 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 account.
>=20
> This is not fixable by the use of mirror servers.
>=20
>=20
>> 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 easypaysy (since, by definition, easypaysy accounts must have =
exactly one input and two outputs).
>=20
> 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 identifier?
>=20
> 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 =
transaction.
> If not, then each time a control transaction changes the details of =
the easypaysy identifier, the identifier itself is changed.0
>=20
>=20
>> If you are interested, please contact me, preferably privately since =
I wouldn=E2=80=99t want to become much too off topic in this dev-list
>=20
> I still do not see why it would be off-topic to the devlist.
>=20
> Regards,
> ZmnSCPxj
> On 6 Dec 2019, at 18:16, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>=20
> Good morning Jose,
>=20
>> Hi ZmnSCPxj,
>>=20
>> first of all: do you ever sleep? ;-)
>=20
> It seems possible, that, I do not.
>=20
>=20
>> b) Master accounts are included in the white paper as a feature for a =
future release.
>> The roadmap is not set yet, but I=E2=80=99d like to include a first =
release of the protocol that only covers the most basic features, to =
make it simpler and safer for wallet developers.
>> Master accounts aren=E2=80=99t a priority, since they are more =
oriented towards 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 the white paper, the =E2=80=98service provider=E2=80=99 has really no =
control over your money.
>>=20
>> He would basically do a just a few things:
>>=20
>> - 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-accounts included in the pack.
>> - Make that JSON document publicly available, probably with a =
https: URL (That=E2=80=99s called an Authoritative server)
>> - Finally, create and publish a TX that contains a pointer to the =
Authoritative server, and the Merkle root of the set of accounts.
>>=20
>> 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 =
Merkle root protects agains any attempt of tampering with the account =
data.
>=20
> This does not seem to mesh well with the other non-Master parts of the =
protocol, where further updates on the single account backed by a =
funding TXO are performed by spending the funding TXO and creating a =
transaction with `OP_RETURN`.
>=20
> In addition, I would like to suggest as well that instead of =
`OP_RETURN`, you could instead use "sign-to-contract".
>=20
> Sign-to-contract is simply that, when signing, instead of selecting a =
random `r` and computing `R` as `R =3D r * G`, you select a random `r` =
and a contract 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, via 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 different layer / overlay network to broadcast messages `c`, =
but it does reduce the cost on the blockchain layer, which is always a =
good thing.
> Similar issues are faced by the RGB project, for instance, and defiads =
explicitly uses a separate overlay network when transmitting =
advertisements (both RGB and defiads use the opposite pay-to-contract, =
which tweaks the pubkey rather than the ephemeral `R`).
>=20
>>=20
>> The account=E2=80=99s TX won=E2=80=99t ever disappear from the =
blockchain, 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.
>>=20
>> To mitigate this issue, the white paper suggests the creation of =
mirror servers.
>=20
> 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 =
transactions 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 account.
>=20
> This is not fixable by the use of mirror servers.
>=20
>=20
>> 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 easypaysy (since, by definition, easypaysy accounts must have =
exactly one input and two outputs).
>=20
> 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 identifier?
>=20
> 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 =
transaction.
> If not, then each time a control transaction changes the details of =
the easypaysy identifier, the identifier itself is changed.0
>=20
>=20
>> If you are interested, please contact me, preferably privately since =
I wouldn=E2=80=99t want to become much too off topic in this dev-list
>=20
> I still do not see why it would be off-topic to the devlist.
>=20
> Regards,
> ZmnSCPxj
>=20
|