summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJose Femenías Cañuelo <jose.femenias@gmail.com>2019-12-06 19:47:38 +0100
committerbitcoindev <bitcoindev@gnusha.org>2019-12-06 18:47:47 +0000
commit0716e39d7322987b9e5a564379a304c15eb9b19a (patch)
tree34546e02b533d31efb95629ac92070364a23094a
parent2e50697ee26fc49a56e632a0530d4e528baa3715 (diff)
downloadpi-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/dbf509d627b818c7c21fef0fab7d1ca166bdd2500
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
+
+