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
186
187
188
189
190
191
|
Return-Path: <eloyesp@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 20EF4C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 22 Sep 2022 03:07:04 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id DA43582F4F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 22 Sep 2022 03:07:03 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org DA43582F4F
Authentication-Results: smtp1.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20210112 header.b=eCcznNNF
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id TEPPePurUCmW
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 22 Sep 2022 03:07:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org C0ECC82628
Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com
[IPv6:2607:f8b0:4864:20::f2c])
by smtp1.osuosl.org (Postfix) with ESMTPS id C0ECC82628
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 22 Sep 2022 03:07:02 +0000 (UTC)
Received: by mail-qv1-xf2c.google.com with SMTP id s13so5918882qvq.10
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Sep 2022 20:07:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
:date; bh=zipJCSn67B5g042fg1M1Emn8unssIC9sfS6dJj9NaGE=;
b=eCcznNNFnzY+oi+xouRF05b/wkHYMfR5FdNd1X9gXNyrq4nziwfAwXUg4EZM/bBPB6
dCkiT1Ssz91E8lLtbrNjW7FevvN89N4Qn1BPJwHVqd2SAM+EotKxXUYR3VbY953VRl9r
zvgluimAl0Q2C9LbYoQd/RTQDzlO6HXQpjRLJEOpYMSQ2hfAsWGULe7w7byVg4ghNlK/
VNXsCGOhNtF5R9J88+ThT2/4xSLTkH5AJyun3ph8XAoczihx/8Q9k97SjaD8CYCLvQL7
oLFCtTXgsYEmKdffo+24r3RErpeV5GDN3JXbIAe5AkZ5TpEi1c7HnMbGN8c2bgCY8nsR
U0zg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=to:subject:message-id:date:from:mime-version:x-gm-message-state
:from:to:cc:subject:date;
bh=zipJCSn67B5g042fg1M1Emn8unssIC9sfS6dJj9NaGE=;
b=tqsV5Zm6iwllb5i+GSEVPOHQZa1CJ8gnCPDU0Jf9YY8cM8LEjqWVgkk1UwdD1ziVlX
sobFUkFS7gqY+Jbg78UT13AkjnQXB0R9lU0TivjErErpx2cPribPLu1xMSitlNJ9LHcg
XBDuELDLhViWQSuXTjRf+2c00j9xEI24pgoTwfxjuJ3detBo0rTAm/9nobDtKQ4ZMAQ5
KTAnDmZtcsvFJyUy3HtbIBsHJvTXmC814mMd7YHxy0PRlS1FWTBMRwg1xvLQhVoU21YY
ZTKZDrAYNHgF0h58s5N6L3s9m2GebfdoD5A30LSPRmAucjkVEnHWoT4kvpxfI3Yb51je
aT3w==
X-Gm-Message-State: ACrzQf33WiuURSeL0tTMASK+jcslxzTNZHLuKzMDRKUZossUFeg2AESo
KWOS/oyic9oPv3+IS7DfEMV/GBk40EuxSVaTkplZHvi0
X-Google-Smtp-Source: AMsMyM4bGm+QoUFKpcgG4QWHMS8cJMuU7mCdXnQckmMrAKGXdvjdNtZ2HfuUcBJFETXMaXGm3zbtwC7N6rxfu2u/e+4=
X-Received: by 2002:ad4:5cec:0:b0:4ac:96fc:24e3 with SMTP id
iv12-20020ad45cec000000b004ac96fc24e3mr1013504qvb.95.1663816021416; Wed, 21
Sep 2022 20:07:01 -0700 (PDT)
MIME-Version: 1.0
From: El_Hoy <eloyesp@gmail.com>
Date: Thu, 22 Sep 2022 00:06:50 -0300
Message-ID: <CAPapNH28iCxEcTOKt3YC+zuZzxbM=AudbbYByjS3aUZAgFHUag@mail.gmail.com>
To: Bitcoin DEV <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000ed9ec505e93b5ad6"
X-Mailman-Approved-At: Thu, 22 Sep 2022 15:17:57 +0000
Subject: [bitcoin-dev] RFC for a BIP32 recurrent address derivation scheme
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, 22 Sep 2022 03:07:04 -0000
--000000000000ed9ec505e93b5ad6
Content-Type: text/plain; charset="UTF-8"
There is a known issue on bitcoin, that is that every transaction requires
a new address to prevent address reuse, making it uncomfortable to make
recurring payments, as every payment requires a new off-chain interaction.
A scheme is already mentioned on the [on the BIP32 itself][1], but it
cannot be implemented as is.
Here I propose a scheme that follows the structure described on [BIP44]
that should make it possible to send recurring payments using a single
offline interaction.
The proposed scheme is:
master / purpose' / coin_type' / contact' / index
Where the definitions of all the levels follow BIP44, except for `contact`
that is described below.
Example usage: Bob wants to make recurring payments to Carol, so he asks
her for a _contact address_, that is, an extended public key.
Bob can use that public key to generate multiple derived addresses to make
multiple recurring payments to Carol, the contact address is stored
off-chain, anyone inspecting the chain will just see normal transactions
on-chain.
## Considerations
[BIP47] tries to solve the same issue, but the solution is more complex and
involves more on-chain transactions that involve data, this implementation
simpler and requires less work to implement.
Also, the derivation path might need some adjustments for different address
types on bitcoin.
Finally, this only works in a single direction and does not make it
possible for Carol to send anything to Bob, as it would require Bob sending
her a contact address.
## Advantages
A positive side effect of using this, is that Bob can choose to send
payments to Carol using multiple outputs, giving him more privacy.
Also, those payments can be easily labeled by the receiving wallet, as they
are received.
Regards.
### References
[1]:
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#recurrent-business-to-business-transactions-nmih0
[BIP47]: https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki
"Reusable Payment Codes for Hierarchical Deterministic Wallets"
[BIP43]:
https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki#Purpose
--- Eloy
--000000000000ed9ec505e93b5ad6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">There is a known issue on bitcoin, that is that every tran=
saction requires a new address to prevent address reuse, making it uncomfor=
table to make recurring payments, as every payment requires a new off-chain=
interaction. A scheme is already mentioned on the [on the BIP32 itself][1]=
, but it cannot be implemented as is.<br><br>Here I propose a scheme that f=
ollows the structure described on [BIP44] that should make it possible to s=
end recurring payments using a single offline interaction.<br><br>The propo=
sed scheme is:<br><br>=C2=A0 =C2=A0 master / purpose' / coin_type' =
/ contact' / index<br><br>Where the definitions of all the levels follo=
w BIP44, except for `contact` that is described below.<br><br><div>Example =
usage: Bob wants to make recurring payments to Carol, so he asks her for a =
_contact address_, that is, an extended public key.</div><div><br></div>Bob=
can use that public key to generate multiple derived addresses to make mul=
tiple recurring payments to Carol, the contact address is stored off-chain,=
anyone inspecting the chain will just see normal transactions on-chain.<br=
><div><br></div><div>## Considerations</div><div><br></div><div>[BIP47] tri=
es to solve the same issue, but the solution is more complex and involves m=
ore on-chain transactions that involve data, this implementation simpler an=
d requires less work to implement.<br></div><div><br></div><div>Also, the d=
erivation path might need some adjustments for different address types on b=
itcoin.<br></div><div><br></div><div>Finally, this only works in a single d=
irection and does not make it possible for Carol to send anything to Bob, a=
s it would require Bob sending her a contact address.</div><div><br></div><=
div>## Advantages<br></div><br><div>A positive side effect of using this, i=
s that Bob can choose to send payments to Carol using multiple outputs, giv=
ing him more privacy.</div><div><br></div><div>Also, those payments can be =
easily labeled by the receiving wallet, as they are received.</div><div><br=
></div><div>Regards.</div><div><br></div>### References<br><div><br></div><=
div>[1]: <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0032.me=
diawiki#recurrent-business-to-business-transactions-nmih0">https://github.c=
om/bitcoin/bips/blob/master/bip-0032.mediawiki#recurrent-business-to-busine=
ss-transactions-nmih0</a><br></div>[BIP47]: <a href=3D"https://github.com/b=
itcoin/bips/blob/master/bip-0047.mediawiki">https://github.com/bitcoin/bips=
/blob/master/bip-0047.mediawiki</a> "Reusable Payment Codes for Hierar=
chical Deterministic Wallets"<br>[BIP43]: <a href=3D"https://github.co=
m/bitcoin/bips/blob/master/bip-0043.mediawiki#Purpose">https://github.com/b=
itcoin/bips/blob/master/bip-0043.mediawiki#Purpose</a><br><br>--- Eloy</div=
>
--000000000000ed9ec505e93b5ad6--
|
