MIME-Version: 1.0
References: <87imblmutl.fsf@rustcorp.com.au>
 <20201008145938.vrmm33f6sugdc7qm@ganymede>
In-Reply-To: <20201008145938.vrmm33f6sugdc7qm@ganymede>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Thu, 8 Oct 2020 11:21:47 -0400
Message-ID: <CAMZUoKk1FA_imTcf+Y8WiW9CbNPvMKyfW6B3-qxXGBCvAX0i9A@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000a0e7fd05b12a6427"
Subject: Re: [bitcoin-dev] Progress on bech32 for future Segwit Versions
	(BIP-173)
Precedence: list

--000000000000a0e7fd05b12a6427
Content-Type: text/plain; charset="UTF-8"

On Thu, Oct 8, 2020 at 11:00 AM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Rather than go through that again, I'd prefer we use the
> backwards compatible proposal from BIPs PR#945 and, if we want to
> maximize safety, consensus restrict v1 witness program size, e.g. reject
> transactions with scriptPubKeys paying v1 witness programs that aren't
> exactly 32 bytes.
>

Adding some kind of relay policy rule would be easier than a consensus
rule, and maybe effective enough.  (This comment is not intended to endorse
any one proposal over another.)


> Hopefully by the time we want to use segwit v2, most software will have
> implemented length limits and so we won't need any additional consensus
> restrictions from then on forward.
>

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

<div dir=3D"ltr"><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"g=
mail_attr">On Thu, Oct 8, 2020 at 11:00 AM David A. Harding via bitcoin-dev=
 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex">Rather than go through that again, I&#39;d prefer w=
e use the<br>
backwards compatible proposal from BIPs PR#945 and, if we want to<br>
maximize safety, consensus restrict v1 witness program size, e.g. reject<br=
>
transactions with scriptPubKeys paying v1 witness programs that aren&#39;t<=
br>
exactly 32 bytes.<br></blockquote><div><br></div><div>Adding some kind of r=
elay policy rule would be easier than a consensus rule, and maybe effective=
 enough.=C2=A0 (This comment is not intended to endorse any one proposal ov=
er another.)<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">
Hopefully by the time we want to use segwit v2, most software will have<br>
implemented length limits and so we won&#39;t need any additional consensus=
<br>
restrictions from then on forward.<br>
</blockquote></div></div>

--000000000000a0e7fd05b12a6427--