path: root/02/f61882eabba918d43a37e410e9ce0110832b58

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 EB8C3C077D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  6 Dec 2019 07:56:57 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id C7A918825E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  6 Dec 2019 07:56:57 +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 cLc4Z7wjdaSk
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  6 Dec 2019 07:56:56 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com
 [209.85.128.45])
 by whitealder.osuosl.org (Postfix) with ESMTPS id 7E97487D95
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  6 Dec 2019 07:56:56 +0000 (UTC)
Received: by mail-wm1-f45.google.com with SMTP id q9so6770560wmj.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 05 Dec 2019 23:56:56 -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
 :content-transfer-encoding:message-id:references:to;
 bh=/+JI8+SUVrj7me6sMKYysIRacnr0LMWOwJfLvkWupz0=;
 b=CBO8cfGPFOYEmFV1YEGS1+xTGCr5SYnzA3qG8DBFQPIgps5zGTkaFXeCFjfC7FzGRM
 5EdjPm2aMKVm71nZQg2Fd/6YLIMBlMO0Hg70k1D/6WZCv/UbMrfPt53Qnj40IwDTrDJe
 Zfy5x0XQDCmmS12dJ8aainrq2HsplsZnI+8PMwWkTZhswCL5nreCM+6hrRHDpjrcSBGf
 DDxN/MUqQVDTqGr4q09xe1XzbERVsDSiyTeD5e7bk67KPKrksNcrXOJd6APhbZau7Slm
 bOya42P1R5fKYw8PNbe34g0sHsdj8M4YrzERnHb4flpaY+kyQ9b/Hdo0ds67BuAeBEY4
 HRiQ==
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
 :content-transfer-encoding:message-id:references:to;
 bh=/+JI8+SUVrj7me6sMKYysIRacnr0LMWOwJfLvkWupz0=;
 b=driZAzUTN65vi9TRq8XnLAQMqfCmLf8kr/JQV8vPd8PlSx4lOXqSXsCaIfMR9Ktg7I
 klm707KKzAq5io+rC42lLLAbDDF8wcRDFBLZgyFketcE70ofViBO4LstEuU8x24GIOE+
 TLkU56bcKlVsRPaFTHNuda7nXd60SELR4sdGl0hw5yJRRfWfP1ns2ex3hT/xpZzOqRMl
 bNa54VIULyx9HmTrPOeFL12u+/R4I8VCYGlk00Hkr2Dby1EYT+gc/E8BA5NTRiktpI7x
 xWgb+TiUyxbFQDq2bMm3ADKtyxqBWdTk7oBigqb5On7o3YEk/yXWSJG/+zsmATXhkVNq
 DzIA==
X-Gm-Message-State: APjAAAWTCQ1YeqPOseiSrnB+7lZsaKgx0onOEe3bcUpmE2/CcNOZxAkP
 2dqq6kw9Ve+ERFmyBzCRtlE6HeGQ
X-Google-Smtp-Source: APXvYqxwQ+2tlSANx5R+NGbjHzYKILknAsoqKB+S0ANEmwPQc0JFwfc3Tqq0YR+lYJxJR1BIs4/FUQ==
X-Received: by 2002:a1c:7911:: with SMTP id l17mr9502565wme.44.1575619014437; 
 Thu, 05 Dec 2019 23:56:54 -0800 (PST)
Received: from [192.168.1.35] ([178.60.38.49])
 by smtp.gmail.com with ESMTPSA id n12sm2546306wmd.1.2019.12.05.23.56.53
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Thu, 05 Dec 2019 23:56:53 -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: <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
X-Mailer: Apple Mail (2.3273)
X-Mailman-Approved-At: Fri, 06 Dec 2019 13:40:59 +0000
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 07:56:58 -0000

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