From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 2E992C077D for ; 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 ; 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 ; 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 ; 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?= From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <6CB7E73C-57C9-428B-83E6-36113B619BFB@gmail.com> References: <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-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: 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