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: <fBhj5XmKd7-1Bk13TuSLkwYGGgbvdVUbSr-dOjJk9pe0cb6CdLPhCUgbIDFyCv6ua2yJJc2lpn-IX42jN2MH8FGex7oqlxb2t-UKIUjPYrA=@protonmail.com>
Date: Fri, 6 Dec 2019 08:56:52 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <AF3AF268-8E5B-481E-A5C7-205D171E90A5@gmail.com>
References: <E70934BE-E7BE-4035-BBFF-47005E25C441@gmail.com>
 <fBhj5XmKd7-1Bk13TuSLkwYGGgbvdVUbSr-dOjJk9pe0cb6CdLPhCUgbIDFyCv6ua2yJJc2lpn-IX42jN2MH8FGex7oqlxb2t-UKIUjPYrA=@protonmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] easypaysy - A layer-two protocol to send payments
 without addresses
Precedence: list

Hi ZmnSCPxj,

first of all: do you ever sleep?    ;-)


A few points about your reply:

a) The easypaysy white paper isn=E2=80=99t a final set of =
specifications.=20
Instead it is meant as a somewhat detailed draft of the ideas that can =
drive a working set of specifications.
As such, any qualified input -as in your case- is much welcome, since it =
can greatly help with the process.


b) Master accounts are included in the white paper as a feature for a =
future release.=20
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.=20
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.=20=

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.

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.

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.

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=99=
t download the Json document containing your account information.

To mitigate this issue, the white paper suggests the creation of mirror =
servers.

Page 27
---------
'The risk that the authoritative server designated within the =
EASYPAYSY_MASTER_ACCOUNT_DESCRIPTOR could become unavailable can be =
mitigated with the use of mirror servers.=E2=80=99
...
'It is conceivable that the mirror could charge for this service, =
perhaps requiring a small LN payment per request, so there will be an =
economic incentive to preserve the information associated with every =
master account ever published into the blockchain.=E2=80=99


c) I am a BIG fan of the Lightning network (see the example before). I =
wouldn=E2=80=99t like to sound as easypaysy promotes on-chain payments =
vs LN payments.
I still think there is room for both. I guess and hope that LN payments =
will grow exponentially in the future.=20
However, some large transactions and a few other uses cases will =
probably make more sense on-chain.


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).
*** However ***, your idea is sound and I can see some use cases for =
both pointing to the input and output of a TX.
In fact, the seed for easypaysy is some work I did previously, called =
=E2=80=98Bitcoin pointers=E2=80=99 (you can search the dev list for the =
link).
In there, I proposed a fuller set of features for a TX-ID, including =
both pointing to the input and the output of a TX.

This is an excerpt from the document on canonical pointers:

'It is also possible to refer to an input: and/or  :output within a =
transaction.=20
In our example, the canonical pointers that point to the first input and =
the second output of that  transaction are, respectively:

	btc@0:170.1/028-588-872 and btc@170.1:1/413-851-608'

Additionally, the specs allow for the use of attributes; quoting again:

'btc@170.1:1/179_address should return =
12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S, which is the address of the second =
output of that transaction=E2=80=99.


e) The white paper barely touches the implications the easypaysy =
protocol could have for the Lightning Network, other than citing the =
possibility of receiving an LN invoice within the Payment reply =
document.
I didn=E2=80=99t really have neither the time, nor the expertise =
required to explore further applicability for LN, although I can imagine =
some use cases.
I know you are quite the expert on LN issues, so if you would like to =
contribute your suggestions on how to shape the protocol in this regard, =
I will very much welcome your contributions.

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

Thanks again for your comments.

Regards,


Jose Femenias

jose.femenias@gmail.com
www.easypaysy.org


> On 6 Dec 2019, at 03:53, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>=20
> Good morning Jose,
>=20
>=20
>>> 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.
>> 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).
>=20
> If you have 0 Bitcoins, you need to have *some* Bitcoins from =
somewhere else (perhaps a service provider) in order to back the initial =
funding transaction output.
> If you create Master Easypaysy account by paying fiat to some service =
provider that then uses its Bitcoins to fund your Easypaysy account, but =
requires some sort of shared control over the money in it, I simply call =
this "renting" the Bitcoin, as presumably the service provider would =
want to get its coins back from you.
>=20
> If you are referring to the use of a service provider, then the =
service provider 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 account identifier somehow (i.e. end of lease).
>=20
>>=20
>>> 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,
>>=20
>> 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.
>>=20
>> 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):
>=20
> 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.
>=20
>> Anyway, when using interactive payments, the payee has the option to =
specify an LN invoice and/or a bitcoin address.
>>=20
>>> 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
> 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 transaction is what broadcasts the account information (in =
particular, the funding UTXO is a P2SH and the transaction that spends =
it is the one that reveals the 2 pubkeys you require).
>=20
> In contrast, Lightning Network requires only the funding UTXO (which =
requires that short channel IDs include the transaction output index, as =
a single funding transaction can fund multiple Lightning Network =
channels).
>=20
>> But the UTXO can be one of many in the same transaction.
>> So, you could fund multiple accounts with a single TX.
>=20
> So can Lightning Network channels: multiple channels can be funded by =
a single funding transactions (C-Lightning supports this, but not as a =
single command yet, it requires some low-level fiddling).
>=20
>>> 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.
>=20
> I suggest being Tor-centric instead.
>=20
>>=20
>>> 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.
>=20
> This does not mesh with your earlier claim:
>=20
>> But the UTXO can be one of many in the same transaction.
>=20
> 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 relevance of that restriction).
> If the funding transaction can have many UTXOs that are individually =
funding TXOs of multiple Easypaysy accounts, then you need to refer to =
*which* TXO of that funding transaction is what you are using.
>=20
>>=20
>> 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.
>>=20
>> The format of the ID in this case is: =
btc@master_idx.slave_id/checksum
>>=20
>> 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)
>>=20
>> 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.
>=20
> Why would it not be appropriate?
>=20
> In case of such a "Master TX", would it be possible for each slave to =
be independently controlled by a different party?
>=20
>=20
> Regards,
> ZmnSCPxj