path: root/af/dbf509d627b818c7c21fef0fab7d1ca166bdd2

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