From: Anthony Towns <aj@erisian•com.au>
To: "David A. Harding" <dave@dtrt•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Cc: Greg Sanders <gsanders87@gmail•com>
Subject: Re: [bitcoin-dev] Reference example bech32m address for future segwit versions
Date: Wed, 1 Feb 2023 11:13:49 +1000 [thread overview]
Message-ID: <Y9m8zcsC2LxtptDf@erisian.com.au> (raw)
In-Reply-To: <c9ddddce1ad797671431335fe95cf2b7@dtrt.org>
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
prev parent reply other threads:[~2023-02-01 1:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-31 0:02 David A. Harding
2023-01-31 14:30 ` Greg Sanders
2023-01-31 23:33 ` David A. Harding
2023-02-01 0:37 ` Greg Sanders
2023-02-01 1:13 ` Anthony Towns [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y9m8zcsC2LxtptDf@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=dave@dtrt$(echo .)org \
--cc=gsanders87@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox