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
|
Return-Path: <aj@erisian.com.au>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 739A9C002B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Feb 2023 01:14:00 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 3B83960D91
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Feb 2023 01:14:00 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 3B83960D91
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001,
UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id pTBfcaW8iRKi
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Feb 2023 01:13:59 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org C725F60759
Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193])
by smtp3.osuosl.org (Postfix) with ESMTPS id C725F60759
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Feb 2023 01:13:58 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))
id 1pN1hB-0001oO-N8; Wed, 01 Feb 2023 11:13:54 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Wed, 01 Feb 2023 11:13:49 +1000
Date: Wed, 1 Feb 2023 11:13:49 +1000
From: Anthony Towns <aj@erisian.com.au>
To: "David A. Harding" <dave@dtrt.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <Y9m8zcsC2LxtptDf@erisian.com.au>
References: <e6da74da025355472a81e613fe7683b9@dtrt.org>
<CAB3F3Dtfu+kaJ8jgi-qRiZBXvuYaEVEa32q_UPkwA5MLAP9RSg@mail.gmail.com>
<c9ddddce1ad797671431335fe95cf2b7@dtrt.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <c9ddddce1ad797671431335fe95cf2b7@dtrt.org>
Cc: Greg Sanders <gsanders87@gmail.com>
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: Wed, 01 Feb 2023 01:14:00 -0000
On Tue, Jan 31, 2023 at 01:33:13PM -1000, David A. Harding via bitcoin-dev wrote:
> I thought the best practice[1] was that wallets would spend to the output
> indicated by any valid bech32m address.
I think it depends -- if the wallet in question is non-custodial and
might not be upgraded by the time witness v2 addresses are in use, then
being able to send to such addresses now makes sense.
If it's a custodial wallet where the nominal owner of the coins isn't
the one signing the tx, then I could see a pretty strong argument to not
allowing sending to such addresses until they're in use: (a) nobody will
be running the old software, since the custodian can just force everyone
to upgrade (eg, by deploying a new version of their own website), and (b)
signing a tx to send the bitcoins you're holding on Bob's behalf to an
address that will just get them stolen could be considered as negligence,
and you might end up forced to make Bob whole again.
So maybe the argument is:
* is this a custodial wallet? then what's the point of testing a
scenario that's likely years away -- the custodian will probably have
changed their system entirely by then anyway
* is it a non-custodial wallet? then it's worth testing -- you might
not be able to find compatible software in future to move your
private keys and have to dig up the current software and use it. will
it still work? but in that case, you ought to be able to capture the
tx it generates before broadcasting it, and don't need to publish it
on chain, and then it doesn't matter what script you use?
(For libraries and non-wallet software like block explorers or alternate
node implementations, it's a different matter)
Cheers,
aj
|
