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
|
Return-Path: <dave@dtrt.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id E7641C002B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 31 Jan 2023 00:02:54 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id B7C934252F
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 31 Jan 2023 00:02:54 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org B7C934252F
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id nBkNOHM-QGQG
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 31 Jan 2023 00:02:53 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 9149E41AA8
Received: from smtpauth.rollernet.us (smtpauth.rollernet.us
[IPv6:2607:fe70:0:3::d])
by smtp2.osuosl.org (Postfix) with ESMTPS id 9149E41AA8
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 31 Jan 2023 00:02:53 +0000 (UTC)
Received: from smtpauth.rollernet.us (localhost [127.0.0.1])
by smtpauth.rollernet.us (Postfix) with ESMTP id 3A5AB2800862
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 30 Jan 2023 16:02:52 -0800 (PST)
Received: from webmail.rollernet.us (webmail.rollernet.us
[IPv6:2607:fe70:0:14::a])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client did not present a certificate)
by smtpauth.rollernet.us (Postfix) with ESMTPSA
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 30 Jan 2023 16:02:51 -0800 (PST)
MIME-Version: 1.0
Date: Mon, 30 Jan 2023 14:02:51 -1000
From: "David A. Harding" <dave@dtrt.org>
To: bitcoin-dev@lists.linuxfoundation.org
User-Agent: Roundcube Webmail/1.4.10
Message-ID: <e6da74da025355472a81e613fe7683b9@dtrt.org>
X-Sender: dave@dtrt.org
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
X-Rollernet-Abuse: Contact abuse@rollernet.us to report. Abuse policy:
http://www.rollernet.us/policy
X-Rollernet-Submit: Submit ID 2484.63d85aab.c90a3.0
Subject: [bitcoin-dev] Reference example bech32m address for future segwit
versions
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: Tue, 31 Jan 2023 00:02:55 -0000
Hi y'all!,
One of the benefits proposed for bech32 (and, by extension, bech32m) is
that spender wallets shouldn't need to be upgraded to pay segwit outputs
defined in future soft forks. For example, Bitcoin Core today can pay a
bech32m address for a segwit v2 output, even though no meaning has been
assigned to output scripts matching a segwit v2 template.
However, testing this behavior in production[1] can create an annoyance
for developers of future soft forks. They will need to deal with any
existing outputs paid to the templates used in that proposed soft fork.
See, for example, some discussion by developer 0xB10C about payments to
segwit v1 addresses before activation of the taproot soft fork:
https://b10c.me/blog/007-spending-p2tr-pre-activation/
I was wondering if it would be useful to have a canonical examples of
future segwit addresses that are designed to be very unlikely to
interfere with future soft forks but which would still reasonably
exercise wallets supporting bech32m. I think of this as the rough
equivalent of the RFC2606 domain "example.com" which has been reserved
for examples in documentation.
Specifically, I'm thinking of the following addresses, one each for
mainnet and testnet:
- HRP: bc for mainnet; tb for testent
- Witness version: 16 (the last segwit version)
- Witness program: 0x0000. Two bytes is the minimum allowed
by BIP141, but it's far too small to make any sort of secure
commitment,
so I'm hoping it won't conflict with any future use
I think we should try to start with just one reserved address per
network, but if that isn't enough, I think we could allow any two-byte
witness program with witness version 16.
Outputs paid to reserved addresses will still be anyone-can-spend, so
there's no change required to Bitcoin Core or other software and those
outputs can still be cleaned out of the UTXO set. Additionally, if we
ever *really* need that address space for a soft fork, it will be
available.
Are there any objections to this idea, or suggestions for a better way
to go about it?
Thanks!,
-Dave
[1] Testing in production should be avoided because it uses block space
that could otherwise be used by actual value transfers. Also, it costs
money and pollutes the UTXO set (at least temporarily). However, when
testing whether proprietary third-party software, such as an exchange,
supports payments to future segwit versions, sometimes the only
convenient method is to actually pay the address for a future segwit
version. Additionally, my specific use case is just to write
documentation
about bech32m---but I worry that people will pay my example of a future
segwit
version address.
|
