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
|
Return-Path: <federicotenga@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 47EE7CBE
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 24 Jul 2018 12:05:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yw0-f173.google.com (mail-yw0-f173.google.com
[209.85.161.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AC1C0A8
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 24 Jul 2018 12:05:29 +0000 (UTC)
Received: by mail-yw0-f173.google.com with SMTP id k18-v6so1412191ywm.11
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 24 Jul 2018 05:05:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to;
bh=yxmrekdzPKB2CVFpsMeQqKuAlR7fsgrkVq+RxpwUcZw=;
b=tIcgdKN6RUhPYqd5q+r0yqvafit99a+foVSMP39Vk307DvW57eHHQ1J7N1j98NfP0n
zKoIGNEivCiPIEQ47f4awI+fCtEad0CW0b3MIqpxE3sYMubaT9i4KQaRdci0E9SmhqVQ
Fj7JzRX73yqP0oOSiHXskp7js7irKkZyH3pMjc4R4ap/jJUftRdm/8nw6TSO6HTYG+ws
wFWcOQNuWzPtPdkFZsTkLDtc5+xRygKPRBYVpd8ryiPCPRc7grJyi5+tShX7O8XI4ktp
1xjxPE6NGdI/a7pCDeggtOWVxso61kpssnSnnB5M1VuwQfsDBeUzU0FSNMV3bPeF46oW
ZVow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=yxmrekdzPKB2CVFpsMeQqKuAlR7fsgrkVq+RxpwUcZw=;
b=jguYltBNJyj9kBQrOQWQ8X4pnwgEN+EIreC7Y9zeklSM5MiMXwGi3LV/kpHsEzcc8h
bUbUYcmokHtDg7fa2r1nPSVFi/oVz8JjCtBlAcPF2lLLzPNPaMpf95X63AJcPBrRVwqe
7EzVO5WcJCiTCcPp5wjRyGsVGHyfznJAiOJAa4BOmsT/KBZR9LurdlzgosYZDRmKZPXA
Aicr85RNlDWt5jRsC1MPfzozpv/JrHzcd6RpLlsWhsbwwfTLFCLFDaPkqUPlZD7u3J7x
ckz58rtPmrUCPWJOZxm+ypUn/wNKt6fdrusx+2eFbbkXN/TfZHCdF7l+mn+dL8rzIjIm
x+eA==
X-Gm-Message-State: AOUpUlH+SV7U9qt0T9u0vwfCez8AsQTcWFEUY+CkBkufT1UGlz1pR+SW
Dk6AM9h+K5DtOy6GU2wFjPg55/G2fRGeXl7JP5tzVDIV
X-Google-Smtp-Source: AAOMgpc9qmkiyhU9DLMOL49r7QrKFJ3t+veniS6WJQJGCmcOcHE3pPgwPnRCR2IBun5Dzomb5iF+acBaJBlotMAAFgU=
X-Received: by 2002:a81:73c4:: with SMTP id
o187-v6mr8461585ywc.260.1532433928468;
Tue, 24 Jul 2018 05:05:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a25:5e0b:0:0:0:0:0 with HTTP; Tue, 24 Jul 2018 05:05:27
-0700 (PDT)
From: Federico Tenga <federicotenga@gmail.com>
Date: Tue, 24 Jul 2018 14:05:27 +0200
Message-ID: <CAP=-fx5Jgw0OEAGaEYKOLWTMay5XFfpsMVBMGXzQ4N1WSOR47A@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000f2d7e80571bd93cf"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 24 Jul 2018 12:58:20 +0000
Subject: [bitcoin-dev] URI scheme with optional bech32 address
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Tue, 24 Jul 2018 12:05:30 -0000
--000000000000f2d7e80571bd93cf
Content-Type: text/plain; charset="UTF-8"
Hello everyone,
With my team we are working on a walleting application which ideally will
generate a bech32 address when receiving from a bech32 compatible wallet,
and a P2WPKH-nested-in-P2SH address when receiving for a legacy wallet.
However, it is of course impossible for the payee to know in advance the
technological capabilities of the payer, so a solution could be to encode
in a Bitcoin URI both bech32 and P2SH addresses in a way that legacy
wallets only see the P2SH address, while new wallets can also see the
bech32 address and use it to perform the transaction.
In particular, to keep compatibility with BIP21, the <address> field of the
URI can be used for the P2WPKH-nested-in-P2SH address and a new field (e.g.
<segwitaddress> or <bech32address>), which will be ignored by legacy
wallets, can be used to encode the bech32 address. The assumption here is
that the wallets using such scheme will monitor incoming transaction both
on the P2SH address and on the bech32 address.
I did some research around and I did not find any proposal addressing the
same issue, so my questions are (i) does anybody already proposed something
going in the same direction and (ii) do you see any major drawback in the
BIP21 compatible scheme proposed in this message?
Thanks in advance,
Federico
--000000000000f2d7e80571bd93cf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello everyone,<br><br>With my team we are working on a wa=
lleting application which ideally will generate a bech32 address when recei=
ving from a bech32 compatible wallet, and a P2WPKH-nested-in-P2SH address w=
hen receiving for a legacy wallet. However, it is of course impossible for =
the payee to know in advance the technological capabilities of the payer, s=
o a solution could be to encode in a Bitcoin URI both bech32 and P2SH addre=
sses in a way that legacy wallets only see the P2SH address, while new wall=
ets can also see the bech32 address and use it to perform the transaction.<=
br><br>In particular, to keep compatibility with BIP21, the <address>=
field of the URI can be used for the P2WPKH-nested-in-P2SH address and a n=
ew field (e.g. <segwitaddress> or <bech32address>), which will =
be ignored by legacy wallets, can be used to encode the bech32 address. The=
assumption here is that the wallets using such scheme will monitor incomin=
g transaction both on the P2SH address and on the bech32 address.<br><br><d=
iv>I did some research around and I did not find any proposal addressing th=
e same issue, so my questions are (i) does anybody already proposed somethi=
ng going in the same direction and (ii) do you see any major drawback in th=
e BIP21 compatible scheme proposed in this message?</div><div><br></div><di=
v>Thanks in advance,</div><div><br></div><div>Federico<br></div><br></div>
--000000000000f2d7e80571bd93cf--
|
