path: root/09/0307d7d0d9fdaba6f76cd702e07c1b1bad616b

Return-Path: <gsanders87@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 7BECAC002B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  1 Feb 2023 00:37:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 5D61881584
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  1 Feb 2023 00:37:21 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 5D61881584
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=CVa2EIbN
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level: 
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id SnddLy4h2XU5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  1 Feb 2023 00:37:20 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org DD1F5814B1
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [IPv6:2a00:1450:4864:20::630])
 by smtp1.osuosl.org (Postfix) with ESMTPS id DD1F5814B1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  1 Feb 2023 00:37:19 +0000 (UTC)
Received: by mail-ej1-x630.google.com with SMTP id ud5so46766308ejc.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Jan 2023 16:37:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=kmpvVuzMwlowDFuCXYywD+e/IwE+QNJ5nnuNActGfo8=;
 b=CVa2EIbNZ4nNV8Vo/zhfMcH4sZUgur5BAnkl8DDLEj4Op+KfJR0lG8x+4q47UKzfhG
 +LGENep47kk/md5gsVeLm4yAuXmjY1pqEEMykbD8omJztfzVYH4eynDu/d9YRDGzQYRg
 16QugtbUaVXD+ptXwVgvE7N/w1rxikpBmHywdXH/itIEvlVtdUduqs4oDxFchoBmc6/H
 /6YrRm2WLc4JQRnPUfKfXHtdd9QTiRS9EihHS2Q2lqRJpUBes+vzjAiJWReWUYlU9L27
 /56P1GtWUopxlXkSxgmUUx4fmRG+aAax+wg29uC6A8v49Sg3db0JbLdbDtoWNzDjteIn
 kVDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=kmpvVuzMwlowDFuCXYywD+e/IwE+QNJ5nnuNActGfo8=;
 b=TQgbJt+42lYiMI3vNuKkKR00cxelapfwoLqGxxzuPSam2EoYaK2WBQ8bvJniAz3d3n
 PwE206SRLVweYPWB4xlNRtIAK6nKet7HF+NEYOajMQcB4a3CeeZKytieMo15gRfjSGbN
 5Qshb7bUOyRoHITsJCqlHde3kyZiUlrsETxFmlj4NLxNP8OsdvVvDYKmqM75af2Eu/pE
 fwnLnneIoHcA/JCizeF8vcKjlG3R+L5yoHEGglT4SDl08n8Med4hQ9Z5P2SvNY3R4DEm
 JLu0QmldSUx7REc5CFv5rxTGBfaoBKBa3Dzd3L0PbuTptoOHxmKYNKqeS7yxSWF3a7o9
 K8Sw==
X-Gm-Message-State: AO0yUKXZC7daB9b4CQZer5aYH7QqSZHGqZ2WI4y4vh8zrw4kSImcj5jS
 67v1/eiG3L5+amwYpYGpWvaJ8LZsCTRLeuTy20rCQtrI
X-Google-Smtp-Source: AK7set8VNAPrkYo2glwbfj2ZjX5eti+JVgBgK2Q7H+/+mco/iw6oJTMA0OJscLr+P6dkKYm3psQtuVgOYp48X2kzo7k=
X-Received: by 2002:a17:907:6087:b0:889:7bef:3a9d with SMTP id
 ht7-20020a170907608700b008897bef3a9dmr93436ejc.150.1675211837827; Tue, 31 Jan
 2023 16:37:17 -0800 (PST)
MIME-Version: 1.0
References: <e6da74da025355472a81e613fe7683b9@dtrt.org>
 <CAB3F3Dtfu+kaJ8jgi-qRiZBXvuYaEVEa32q_UPkwA5MLAP9RSg@mail.gmail.com>
 <c9ddddce1ad797671431335fe95cf2b7@dtrt.org>
In-Reply-To: <c9ddddce1ad797671431335fe95cf2b7@dtrt.org>
From: Greg Sanders <gsanders87@gmail.com>
Date: Tue, 31 Jan 2023 19:37:06 -0500
Message-ID: <CAB3F3Dtz7Sq8SCYjFn9yx_92bStJRBy0rLu_o3bHndKG9HwdrA@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>
Content-Type: multipart/alternative; boundary="000000000000846e9005f398a69b"
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: Wed, 01 Feb 2023 00:37:21 -0000

--000000000000846e9005f398a69b
Content-Type: text/plain; charset="UTF-8"

David,

I'm merely speaking in a descriptive sense. I predict that most custodians
are reluctant to whitelist
a witness version they know is insecure.

I'm not sure what's best for not colliding with future versions, I'll let
other wiser folks weigh in.

Cheers,
Greg

On Tue, Jan 31, 2023 at 6:33 PM David A. Harding <dave@dtrt.org> wrote:

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

--000000000000846e9005f398a69b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">David,<div><br></div><div>I&#39;m merely speaking in a des=
criptive sense. I predict that most custodians are reluctant to whitelist</=
div><div>a witness version they know is insecure.</div><div><br></div><div>=
I&#39;m not sure what&#39;s best for not colliding with future versions, I&=
#39;ll let other wiser folks weigh in.</div><div><br></div><div>Cheers,</di=
v><div>Greg</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" clas=
s=3D"gmail_attr">On Tue, Jan 31, 2023 at 6:33 PM David A. Harding &lt;<a hr=
ef=3D"mailto:dave@dtrt.org">dave@dtrt.org</a>&gt; wrote:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">On 2023-01-31 04:30, Greg Sanders =
wrote:<br>
&gt; Hi David,<br>
&gt; <br>
&gt; From practical experience, I think you&#39;ll find that most exchanges=
<br>
&gt; will not enable sends to future segwit versions,<br>
&gt; as from a risk perspective it&#39;s likely a mistake to send funds the=
re.<br>
<br>
Hi Greg!,<br>
<br>
I thought the best practice[1] was that wallets would spend to the <br>
output indicated by any valid bech32m address.=C2=A0 You seem to implying <=
br>
that the best practice is the opposite: that wallets should only send to <b=
r>
outputs they know can be secured (i.e., which are not currently <br>
anyone-can-spend).=C2=A0 The more restrictive approach seems kind of sad to=
 <br>
me since any problem which can result in a user accidentally withdrawing <b=
r>
to a future segwit version could even more easily result in them <br>
withdrawing to a witness program for which there is no solution (i.e., <br>
no key or script is known to spend).<br>
<br>
If it is a best practice, then I think there&#39;s a benefit to being able =
<br>
to test it even when other people&#39;s proprietary software is involved.=
=C2=A0 A <br>
wallet or service likely to follow that best practice may be more likely <b=
r>
to follow other best practices which cannot be as easily tested for.=C2=A0 =
<br>
But, if it&#39;s going to be tested, I want the testing to use the address =
<br>
least likely to cause problems for protocol developers in the future.=C2=A0=
 <br>
Do you (and others on this list) have any reason to believe OP_16 <br>
OP_PUSH2 0000 would be a problematic script, or can you think of a <br>
better script?<br>
<br>
Thanks!,<br>
<br>
-Dave<br>
<br>
[1] BIP350, emphasis in original: &quot;[...] we emphatically recommend [..=
.] <br>
ensuring that your implementation supports sending to v1 **and higher <br>
versions.**&quot;<br>
</blockquote></div>

--000000000000846e9005f398a69b--