From: =?utf-8?Q?Jose_Femen=C3=ADas_Ca=C3=B1uelo?= <jose.femenias@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <E70934BE-E7BE-4035-BBFF-47005E25C441@gmail.com>
Date: Thu, 5 Dec 2019 21:00:03 +0100
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] easypaysy - A layer-two protocol to send payments
 without addresses
Precedence: list

Hi ZmnSCPxj

first of all, excuse me for my delayed answer.=20

I think I posted to the wrong address the first time (I=E2=80=99m mainly =
a lurker in the list, so I make gotchas like that=E2=80=A6)

Let me address your points.

> It also means that to register an account, you need to either own some =
Bitcoins, or rent some Bitcoins to serve as signalling (and then =
potentially have to change your account identifier later when the lease =
expires).=20

I don=E2=80=99t understand what you mean by =E2=80=98renting=E2=80=99 =
Bitcoins.=20
Once you commit the account transaction, the account ID never changes.
(Also, you don=E2=80=99t need to own Bitcoins if you use a Master =
Easypaysy Account. See my comments later on).


> Finally, use of the blockchain layer is costly; given that payees must =
be online at any time payers wish to pay, it may do better to just use =
Lightning instead,

That is not the case.=20
When using non-interactive payments, the payee doesn=E2=80=99t need to =
be online at all.
Even for interactive payments, it depends on the protocol you use.

For Bitmessage, or email, or even MQTT you don=E2=80=99t need to be =
online simultaneously. (The interactive protocol(s) is still open, =
however, those are just some hypothetical examples):

Anyway, when using interactive payments, the payee has the option to =
specify an LN invoice and/or a bitcoin address.


> which has the same requirement, but moves payments to a separate layer =
as well, and requires only a single onchain transaction to construct a =
channel (easypaysy seems to require at least 2, one to anchor the =
account pubkeys, the other to give the basic "activation" information =
for the account).=20

Easypaysy accounts don=E2=80=99t need 2 TXs. They need funding plus a TX =
for the account information itself.
So, you need an UTXO -to fund the account- and a TX.=20
But the UTXO can be one of many in the same transaction.=20
So, you could fund multiple accounts with a single TX.


> Also, one of the contact-information protocols supported should =
probably be Tor hidden services, instead of `https`. Tor hidden services =
have better useability (no need for port forwarding or registering DNS =
from some centralized service), with privacy as a bonus.=20
Easypaysy is protocol agnostic (for now). So, Tor is definitely a =
possibility.


> Further it seems insufficient to only encode block and tx index. I =
think it should also encode output index, to also allow a single =
transaction to anchor multiple accounts. Also consider using the =
Lightning encoding of identifying an output: 543847x636x2=20
There is really no need to specify an additional output.
If I am right, you can=E2=80=99t have more than one OP_RETURN per =
transaction.

On the other hand, as you can see in the white paper =E2=80=9C4.2 Master =
accounts=E2=80=9D, these type of accounts allow for up to 2048 accounts =
per transaction.

The format of the ID in this case is: btc@master_idx.slave_id/checksum

The master_idx is an ordinal pointer (not positional) to the Master TX, =
while the slave_id points to one of the 2048 transactions within the =
account (whose information is stored elsewhere, protected by a Merkle =
root committed in the Master Tx)

There is a little bit more to it that seems appropriate to discuss here, =
please have a look at page 25 of the white paper.

Thanks for your input.


Best regards,

Jos=C3=A9 Femen=C3=ADas=