diff options
author | Jose Femenías Cañuelo <jose.femenias@gmail.com> | 2019-12-06 19:47:38 +0100 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2019-12-06 18:47:47 +0000 |
commit | 0716e39d7322987b9e5a564379a304c15eb9b19a (patch) | |
tree | 34546e02b533d31efb95629ac92070364a23094a | |
parent | 2e50697ee26fc49a56e632a0530d4e528baa3715 (diff) | |
download | pi-bitcoindev-0716e39d7322987b9e5a564379a304c15eb9b19a.tar.gz pi-bitcoindev-0716e39d7322987b9e5a564379a304c15eb9b19a.zip |
Re: [bitcoin-dev] easypaysy - A layer-two protocol to send payments without addresses
-rw-r--r-- | af/dbf509d627b818c7c21fef0fab7d1ca166bdd2 | 500 |
1 files changed, 500 insertions, 0 deletions
diff --git a/af/dbf509d627b818c7c21fef0fab7d1ca166bdd2 b/af/dbf509d627b818c7c21fef0fab7d1ca166bdd2 new file mode 100644 index 000000000..e25b1a1f1 --- /dev/null +++ b/af/dbf509d627b818c7c21fef0fab7d1ca166bdd2 @@ -0,0 +1,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 + + |