public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

From: "David A. Harding" <dave@dtrt•org>
To: Greg Sanders <gsanders87@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Reference example bech32m address for future segwit versions
Date: Tue, 31 Jan 2023 13:33:13 -1000	[thread overview]
Message-ID: <c9ddddce1ad797671431335fe95cf2b7@dtrt.org> (raw)
In-Reply-To: <CAB3F3Dtfu+kaJ8jgi-qRiZBXvuYaEVEa32q_UPkwA5MLAP9RSg@mail.gmail.com>

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.**"

next prev parent reply	other threads:[~2023-01-31 23:33 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 [this message]
2023-02-01  0:37     ` Greg Sanders
2023-02-01  1:13     ` Anthony Towns

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=c9ddddce1ad797671431335fe95cf2b7@dtrt.org \
    --to=dave@dtrt$(echo .)org \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=gsanders87@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox