From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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?= In-Reply-To: Date: Fri, 6 Dec 2019 19:47:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6CB7E73C-57C9-428B-83E6-36113B619BFB@gmail.com> References: To: ZmnSCPxj X-Mailer: Apple Mail (2.3273) X-Mailman-Approved-At: Sun, 08 Dec 2019 17:22:55 +0000 Cc: Bitcoin Protocol Discussion , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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