1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id BA12FC077D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 6 Dec 2019 02:53:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id A2C6388B81
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 6 Dec 2019 02:53:47 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id R+BqV3TbahOc
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 6 Dec 2019 02:53:45 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
[185.70.40.135])
by hemlock.osuosl.org (Postfix) with ESMTPS id 4975C88A29
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 6 Dec 2019 02:53:45 +0000 (UTC)
Date: Fri, 06 Dec 2019 02:53:34 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1575600821;
bh=8hih43jqNr2TrMim/5PHNnrlr8GpGK1J7l5Xi9Qgqi8=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID:
From;
b=eyMgvqsmi4XEyqPyfr/bUGbc2wpI6nIY2FyDD7/nkvjG+SGBXHv1ZfeFurJ5+flK3
xySNeyXZ2fWCmAOLXZZik8hi5G8LkKWSQkc+Pf+EHdunqFemC/7XhCZl+i5ky2keo7
yJ7is+SVdrkSi46EsDEnWYiJFcSCSMuqpRQh56Ro=
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
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 02:53:47 -0000
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
|
