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
|
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 DB5F5C077D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 5 Dec 2019 20:00:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id D5F66883CC
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 5 Dec 2019 20:00:10 +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 OntKRdxR28WL
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 5 Dec 2019 20:00:07 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com
[209.85.128.54])
by whitealder.osuosl.org (Postfix) with ESMTPS id C63B2883AA
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 5 Dec 2019 20:00:06 +0000 (UTC)
Received: by mail-wm1-f54.google.com with SMTP id n9so4758495wmd.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 05 Dec 2019 12:00:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:content-transfer-encoding:mime-version:subject:message-id:date
:to; bh=JcbtfzBD7Xs6wnBNJ2yKHRtJYY9+eTgyX7w7coe0g/Q=;
b=rvhoF5w3ij66S8pb2Qv4jPJ+AoCKJI6FsPbOeeeXmsRvebKpuQIdLtdaFO9BBMVxqj
44MnqIUxFFlLA8sImgkBUVQ0oa4WbEwWdm5C9JB1bp3OpORCj0cEaH+ULSNjibhscsaI
55VCCo7Nq4/sK5OPftzMRzmQLF0dwC+LIlcK7n52Yz9GQdKGEkQAVf+0EpYCApq7qJFI
yNFhnlUvH43L15jnd8FRWaAP97TymmX5x9LEF2biMwNE4N0f/mw6+GeXq7LF0zyEdpu4
07iGP1/zxl5Hhf9HHKuQwqVii7arI4j3gmNWceYO+sGaXqKQf8XR9nGwA7JXdKPGQj6E
xdng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:content-transfer-encoding:mime-version
:subject:message-id:date:to;
bh=JcbtfzBD7Xs6wnBNJ2yKHRtJYY9+eTgyX7w7coe0g/Q=;
b=o8tuKlWY9MhKbZlmwKPfotgfjCgIDrvDQkriPm4FqGjL4uJ3wRQJsIdI27WyUc23dx
Rrwav+hbxjI67hDE9qwobnF1xqG/JvRQjuNrJf+Nir5x2UDTnpm0BG3av6iaS4dk9Xcc
4ece2VNem+qwBJh7vqG5EGKiLJPFSr0eUn7nhWLX/iUrxFB+MTbMW5+SwNjgvIu5vvW7
SH66iS4oH8Gc6OUClGrlQSWz97dVPyp/d6fXJFlRDZNt9WV9eg/Vgq9QMN87C78NUg54
lfARmXube3W9rA8pCBMRLKesNwiTtLjCyc3wPEILKGA9IbSgs7SFi5fADiCA54mygY0y
/60g==
X-Gm-Message-State: APjAAAXhU9U6ur2FKLJPNx9katDVS3hEPmNVf4ZJVZ1KNDzuy34kneEu
xNNBgy88sbA8oTb5eRS13SMB1Gmg
X-Google-Smtp-Source: APXvYqxeTk80MVJGjfIDjF1UrvlpSwWmwd082+4ZIoGK9scK8NuLD6zHYpwhHV22UI9v3pEFB5Cppw==
X-Received: by 2002:a1c:9e58:: with SMTP id h85mr7103868wme.77.1575576004917;
Thu, 05 Dec 2019 12:00:04 -0800 (PST)
Received: from [192.168.1.35] ([178.60.38.49])
by smtp.gmail.com with ESMTPSA id d9sm12809520wrj.10.2019.12.05.12.00.04
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 05 Dec 2019 12:00:04 -0800 (PST)
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
X-Mailer: Apple Mail (2.3273)
X-Mailman-Approved-At: Thu, 05 Dec 2019 20:23:28 +0000
Subject: [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: Thu, 05 Dec 2019 20:00:11 -0000
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=
|
