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
|
Return-Path: <dave@dtrt.org>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 2C469C002B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 31 Jan 2023 23:33:18 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id EE7BD41886
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 31 Jan 2023 23:33:17 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org EE7BD41886
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001,
RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 88_siJiWjvnU
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 31 Jan 2023 23:33:16 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 98B2241882
Received: from smtpauth.rollernet.us (smtpauth.rollernet.us [208.79.240.5])
by smtp4.osuosl.org (Postfix) with ESMTPS id 98B2241882
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 31 Jan 2023 23:33:16 +0000 (UTC)
Received: from smtpauth.rollernet.us (localhost [127.0.0.1])
by smtpauth.rollernet.us (Postfix) with ESMTP id 1194F280085D;
Tue, 31 Jan 2023 15:33:14 -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;
Tue, 31 Jan 2023 15:33:13 -0800 (PST)
MIME-Version: 1.0
Date: Tue, 31 Jan 2023 13:33:13 -1000
From: "David A. Harding" <dave@dtrt.org>
To: Greg Sanders <gsanders87@gmail.com>
In-Reply-To: <CAB3F3Dtfu+kaJ8jgi-qRiZBXvuYaEVEa32q_UPkwA5MLAP9RSg@mail.gmail.com>
References: <e6da74da025355472a81e613fe7683b9@dtrt.org>
<CAB3F3Dtfu+kaJ8jgi-qRiZBXvuYaEVEa32q_UPkwA5MLAP9RSg@mail.gmail.com>
User-Agent: Roundcube Webmail/1.4.10
Message-ID: <c9ddddce1ad797671431335fe95cf2b7@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 2b99.63d9a539.ac7a2.0
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [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 23:33:18 -0000
On 2023-01-31 04:30, Greg Sanders wrote:
> Hi David,
>
> From practical experience, I think you'll find that most exchanges
> will not enable sends to future segwit versions,
> as from a risk perspective it's likely a mistake to send funds there.
Hi Greg!,
I thought the best practice[1] was that wallets would spend to the
output indicated by any valid bech32m address. You seem to implying
that the best practice is the opposite: that wallets should only send to
outputs they know can be secured (i.e., which are not currently
anyone-can-spend). The more restrictive approach seems kind of sad to
me since any problem which can result in a user accidentally withdrawing
to a future segwit version could even more easily result in them
withdrawing to a witness program for which there is no solution (i.e.,
no key or script is known to spend).
If it is a best practice, then I think there's a benefit to being able
to test it even when other people's proprietary software is involved. A
wallet or service likely to follow that best practice may be more likely
to follow other best practices which cannot be as easily tested for.
But, if it's going to be tested, I want the testing to use the address
least likely to cause problems for protocol developers in the future.
Do you (and others on this list) have any reason to believe OP_16
OP_PUSH2 0000 would be a problematic script, or can you think of a
better script?
Thanks!,
-Dave
[1] BIP350, emphasis in original: "[...] we emphatically recommend [...]
ensuring that your implementation supports sending to v1 **and higher
versions.**"
|
