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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id DF8E2C087F
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 2 Dec 2019 21:10:30 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id C779885D8D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 2 Dec 2019 21:10:30 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 9ahkgTEGrkZK
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 2 Dec 2019 21:10:29 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch
[185.70.40.130])
by fraxinus.osuosl.org (Postfix) with ESMTPS id BBDE185D41
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 2 Dec 2019 21:10:28 +0000 (UTC)
Date: Mon, 02 Dec 2019 21:10:19 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1575321025;
bh=Epd+HtyVGB4sSHfWA+9dNLo5fsjxgRhz3EsNBC2bCJY=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID:
From;
b=Rp774MDQWcgJzXKDCbY20UyVE5Byn00Ufm2kuy1NQ+MlqSaDXQxAoIggdvUXG8v7Y
WAFzfB0326yfWwz26ViNgytAtR4myEGucXgsiXFmTCz2g7fFCrNoMM1PRUxdNZUDLF
kQEd4QPldfoyT42I1hl+z2GqZWFZ/z3JOEneDLE0=
To: Tim Blokdijk <tim@timblokdijk.nl>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <S7L8Cy5mIxjdkhJ-iRPFVsXDWiabzgSGFonO_KreVL-O67tab79Zxm_h1bH6cp4qrZY3tqi6kODvjGdX4OHh_OYip19EWEglb5KmAuWIZ-Y=@protonmail.com>
In-Reply-To: <55cb9731-e7fb-0bfa-0cba-391ff81d263a@timblokdijk.nl>
References: <mailman.1377.1575015939.25512.bitcoin-dev@lists.linuxfoundation.org>
<e300549d-4890-3cf2-e514-76bb778abef2@gmail.com>
<55cb9731-e7fb-0bfa-0cba-391ff81d263a@timblokdijk.nl>
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: Mon, 02 Dec 2019 21:10:31 -0000
Good morning Tim, and Jose,
> Just a quick question, this is fully decentralized?
>
It broadcasts information over `OP_RETURN` on the blockchain layer, thus de=
centralized as long as the blockchain layer is decentralized.
It also means that to register an account, you need to either own some Bitc=
oins, or rent some Bitcoins to serve as signalling (and then potentially ha=
ve to change your account identifier later when the lease expires).
`OP_RETURN` does have size limits (imposed by `isStandard`), I do not remem=
ber exact numbers, and any data would need to fit.
Finally, use of the blockchain layer is costly; given that payees must be o=
nline at any time payers wish to pay, it may do better to just use Lightnin=
g instead, 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 accoun=
t pubkeys, the other to give the basic "activation" information for the acc=
ount).
It may be useful to consider defiads, which does *not* use `OP_RETURN`, but=
instead uses pay-to-contract, and sends the advertisement data over a sepa=
rate overlay network.
The use-case is mildly different, but ultimately defiads is about connectin=
g potential buyers to potential sellers, and sending data about how to get =
paid would have to be part and parcel of how defiads ultimately works.
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.
Further it seems insufficient to only encode block and tx index.
I think it should also encode output index, to also allow a single transact=
ion to anchor multiple accounts.
Also consider using the Lightning encoding of identifying an output: 543847=
x636x2
Regards,
ZmnSCPxj
> Greetings,
>
> Tim Blokdijk
>
> Op 02-12-19 om 15:00 schreef Jose Femenias via bitcoin-dev:
>
> > Hi,
> >
> > I have just released an early preview of easypaysy, a protocol for Bitc=
oin, that I have been working on for the past few months.
> >
> > (In case you are wondering, easypaysy stands for EASY - PAYment- SYstem=
...)
> >
> > Long story short, easypaysy is a layer-two protocol that allows the cre=
ation of non-custodial accounts directly on the blockchain, so that bitcoin=
addresses can fully disappear from the user experience.
> > In lieu of addresses, users send payments to permanent account IDs.
> >
> > Account IDs are implicitly assigned by the mining process, and come in =
several flavors, like in these examples:
> >
> > Canonical ID:=C2=A0=C2=A0=C2=A0 btc@543847.636/577
> > Mnemonic ID:=C2=A0=C2=A0=C2=A0 btc@cancel-mind.exhibit/motion
> > Domain ID:=C2=A0=C2=A0=C2=A0 btc@example.com/motion-custom
> >
> > (Note: Domain IDs are optional and require extra configuration)
> >
> > The protocol allows both interactive and non interactive payments.
> > All payments are non-repudiable, and it is possible to implement pull-p=
ayments as well as chargebacks.
> >
> > Most of the protocol is quite advanced, but I have refrained from speci=
fying some of the details, until the interested parties can give their feed=
back.
> >
> > For more information, you can see the white paper and a short introduct=
ory video at:
> >
> > https://www.easypaysy.org
> >
> > or directly, by following these links:
> >
> > White paper at https://www.easypaysy.org/assets/easypaysy_white_paper.p=
df
> > Introductory video at https://www.youtube.com/watch?v=3DAOGBdyZbyoA
> >
> > You can also get in contact with me in at:
> >
> > jose.femenias@gmail.com
> >
> > or using the project's email at:
> >
> > easypaysy@gmail.com
> >
> > Best regards.
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
