Date: Fri, 06 Dec 2019 02:53:34 +0000
To: =?UTF-8?Q?Jose_Femen=C3=ADas_Ca=C3=B1uelo?= <jose.femenias@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <fBhj5XmKd7-1Bk13TuSLkwYGGgbvdVUbSr-dOjJk9pe0cb6CdLPhCUgbIDFyCv6ua2yJJc2lpn-IX42jN2MH8FGex7oqlxb2t-UKIUjPYrA=@protonmail.com>
In-Reply-To: <E70934BE-E7BE-4035-BBFF-47005E25C441@gmail.com>
References: <E70934BE-E7BE-4035-BBFF-47005E25C441@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
Subject: Re: [bitcoin-dev] easypaysy - A layer-two protocol to send payments
	without addresses
Precedence: list

Good morning Jose,


> > 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 potentiall=
y have to change your account identifier later when the lease expires).
>
> I don=E2=80=99t understand what you mean by =E2=80=98renting=E2=80=99 Bit=
coins.
> 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 Easypay=
sy Account. See my comments later on).

If you have 0 Bitcoins, you need to have *some* Bitcoins from somewhere els=
e (perhaps a service provider) in order to back the initial funding transac=
tion output.
If you create Master Easypaysy account by paying fiat to some service provi=
der that then uses its Bitcoins to fund your Easypaysy account, but require=
s some sort of shared control over the money in it, I simply call this "ren=
ting" the Bitcoin, as presumably the service provider would want to get its=
 coins back from you.

If you are referring to the use of a service provider, then the service pro=
vider at least partially controls your account and if it ceases to exist or=
 refuses to continue doing business with you, you need to transfer your acc=
ount identifier somehow (i.e. end of lease).

>
> > 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 Ligh=
tning instead,
>
> That is not the case.
> 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 onlin=
e simultaneously. (The interactive protocol(s) is still open, however, thos=
e are just some hypothetical examples):

You could indicate use of some kind of pay-to-contract, then have the payer=
 send the contract text to the payee so that the payee can claim the funds =
later.

> Anyway, when using interactive payments, the payee has the option to spec=
ify 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 chan=
nel (easypaysy seems to require at least 2, one to anchor the account pubke=
ys, the other to give the basic "activation" information for the account).
>
> 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.

Yes, that is why I count it as 2 transactions: one transaction to host the =
funding UTXO that is referred to in the account identifier, and the other t=
ransaction is what broadcasts the account information (in particular, the f=
unding UTXO is a P2SH and the transaction that spends it is the one that re=
veals the 2 pubkeys you require).

In contrast, Lightning Network requires only the funding UTXO (which requir=
es that short channel IDs include the transaction output index, as a single=
 funding transaction can fund multiple Lightning Network channels).

> But the UTXO can be one of many in the same transaction.
> So, you could fund multiple accounts with a single TX.

So can Lightning Network channels: multiple channels can be funded by a sin=
gle funding transactions (C-Lightning supports this, but not as a single co=
mmand yet, it requires some low-level fiddling).

> > Also, one of the contact-information protocols supported should probabl=
y be Tor hidden services, instead of `https`. Tor hidden services have bett=
er useability (no need for port forwarding or registering DNS from some cen=
tralized service), with privacy as a bonus.
>
> Easypaysy is protocol agnostic (for now). So, Tor is definitely a possibi=
lity.

I suggest being Tor-centric instead.

>
> > Further it seems insufficient to only encode block and tx index. I thin=
k it should also encode output index, to also allow a single transaction to=
 anchor multiple accounts. Also consider using the Lightning encoding of id=
entifying an output: 543847x636x2
>
> 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 transac=
tion.

This does not mesh with your earlier claim:

> But the UTXO can be one of many in the same transaction.

My understanding is that the account identifier refers to the funding TXO (=
and funding transactions do not have an `OP_RETURN`, so I fail to see the r=
elevance of that restriction).
If the funding transaction can have many UTXOs that are individually fundin=
g TXOs of multiple Easypaysy accounts, then you need to refer to *which* TX=
O of that funding transaction is what you are using.

>
> 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, w=
hile the slave_id points to one of the 2048 transactions within the account=
 (whose information is stored elsewhere, protected by a Merkle root committ=
ed 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.

Why would it not be appropriate?

In case of such a "Master TX", would it be possible for each slave to be in=
dependently controlled by a different party?


Regards,
ZmnSCPxj