MIME-Version: 1.0
References: <mailman.437.1564598007.27056.bitcoin-dev@lists.linuxfoundation.org>
	<CACL8y1tOn_U2YjpzGuRebv=2=tvaEYwR2yMCK_4girJ4WtZ1Ug@mail.gmail.com>
	<I3Yq3q73tNvEF-Ubis-0A_OPB84-NdRMLUMmMPnQMEazrWw3Q25yGNHVUt5nMOtdD3ISlJj3efNJaLwQjTsvQI1ToF7stRabWo1SYiZjg9U=@achow101.com>
	<YgIGlecoK1dbkfdP7mhW_qtJfGfamClPl_0ALhGovnXTPfcQlQDqAiMgeUvSIUVfzblz8oh4zix90pxIj0j3ppvQxDOpCJztJ62vvXn1yO4=@achow101.com>
	<20190802141836.15771ad6@simplexum.com>
In-Reply-To: <20190802141836.15771ad6@simplexum.com>
From: Jonathan Underwood <junderwood@bitcoinbank.co.jp>
Date: Sun, 4 Aug 2019 09:15:17 +0900
Message-ID: <CAMpN3mJy4TF+ayWV7aXWFwzeQUdrvX5zKsYi4k+dCEp89ZPH0w@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000245d89058f3f7dae"
Subject: Re: [bitcoin-dev] Proposed Extensions to BIP 174 for Future
	Extensibility
Precedence: list

--000000000000245d89058f3f7dae
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

My two cents:

1. Reserved types are awesome.
2. Varint for type is awesome.
3. BIP174 should specify a specific type for all (global, input, and
output) which means "see the BIP numbered in the next byte" so we can have
some sort of BIP43-ish system for BIP174... POR COMMITMENT and my current
signature protocol proposal should go in there.

More like three cents, but you get the idea.

I'll keep an eye on the bips repo. If someone wants to ping me once things
settle down I'll implement it.

Thanks,
Jon

2019=E5=B9=B48=E6=9C=882=E6=97=A5(=E9=87=91) 20:34 Dmitry Petukhov via bitc=
oin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

> =D0=92 Thu, 01 Aug 2019 19:01:06 +0000
> Andrew Chow <achow101-lists@achow101.com> wrote:
>
> > I spoke to some people OOB and they said that they didn't really like
> > the idea of having a prefix string (partially because they've already
> > implemented some proprietary types by simply squatting on unused
> > types). Matching the prefix string adds additional complexity to the
> > parser code.
>
> I do not oppose the idea of "{0xFC}|{private_type}" strongly, but I
> would like to note that for those who do not want to deal with
> additional complexity of handling a prefixed string, they can simply
> not use it at all. Since this is a private construction, and their
> private format specifies 'no prefix', they can just ignore everything
> that does not start with "{0xFC}|{0x00}", thus any further complexity
> regarding the prefix is also ignored. The only added complexity is one
> condition check: second_byte_of_the_key !=3D 0
>
> My other argument for conflict-avoidance prefix as a first thing after
> 0xFC is that the set of future users of PSBT and private types is
> most likely much larger than the current set of those who already
> implemented proprietary types on their own, and thus the overall benefit
> for the whole industry will likely be bigger when 'i do not want
> conflict avoidance' decision have to be explicit, by setting the prefix
> to 0x00, and the set of possible conflicting types are limited only to
> those entities that made this explicit decision.
>
> Regarding the 'squatted' types, it seems to me that this only matters
> in the discussed context if they squatted on 0xFC type in particular.
> In other cases, they will need to implement changes anyway, to be
> compatible with the BIP. Maybe they could consider that one additional
> condition check is a small burden, and maybe they can tolerate that,
> for the benefit of reducing possibility of interoperability problems
> between other future PSBT/private types implementors.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


--=20
-----------------
Jonathan Underwood
=E3=83=93=E3=83=83=E3=83=88=E3=83=90=E3=83=B3=E3=82=AF=E7=A4=BE =E3=83=81=
=E3=83=BC=E3=83=95=E3=83=93=E3=83=83=E3=83=88=E3=82=B3=E3=82=A4=E3=83=B3=E3=
=82=AA=E3=83=95=E3=82=A3=E3=82=B5=E3=83=BC
-----------------

=E6=9A=97=E5=8F=B7=E5=8C=96=E3=81=97=E3=81=9F=E3=83=A1=E3=83=83=E3=82=BB=E3=
=83=BC=E3=82=B8=E3=82=92=E3=81=8A=E9=80=81=E3=82=8A=E3=81=AE=E6=96=B9=E3=81=
=AF=E4=B8=8B=E8=A8=98=E3=81=AE=E5=85=AC=E9=96=8B=E9=8D=B5=E3=82=92=E3=81=94=
=E5=88=A9=E7=94=A8=E4=B8=8B=E3=81=95=E3=81=84=E3=80=82

=E6=8C=87=E7=B4=8B: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3

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

<div dir=3D"ltr">My two cents:<div><br></div><div>1. Reserved types are awe=
some.</div><div>2. Varint for type is awesome.</div><div>3. BIP174 should s=
pecify a specific type for all (global, input, and output) which means &quo=
t;see the BIP numbered in the next byte&quot; so we can have some sort of B=
IP43-ish system for BIP174... POR COMMITMENT and my current signature proto=
col proposal should go in there.</div><div><br></div><div>More like three c=
ents, but you get the idea.</div><div><br></div><div>I&#39;ll keep an eye o=
n the bips repo. If someone wants to ping me once things settle down I&#39;=
ll implement it.</div><div><br></div><div>Thanks,</div><div>Jon</div></div>=
<br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">2019=
=E5=B9=B48=E6=9C=882=E6=97=A5(=E9=87=91) 20:34 Dmitry Petukhov via bitcoin-=
dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.linuxfoundation.org</a>&gt;:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex">=D0=92 Thu, 01 Aug 2019 19:01:06 +0000<br>
Andrew Chow &lt;<a href=3D"mailto:achow101-lists@achow101.com" target=3D"_b=
lank">achow101-lists@achow101.com</a>&gt; wrote:<br>
<br>
&gt; I spoke to some people OOB and they said that they didn&#39;t really l=
ike<br>
&gt; the idea of having a prefix string (partially because they&#39;ve alre=
ady<br>
&gt; implemented some proprietary types by simply squatting on unused<br>
&gt; types). Matching the prefix string adds additional complexity to the<b=
r>
&gt; parser code.<br>
<br>
I do not oppose the idea of &quot;{0xFC}|{private_type}&quot; strongly, but=
 I<br>
would like to note that for those who do not want to deal with<br>
additional complexity of handling a prefixed string, they can simply<br>
not use it at all. Since this is a private construction, and their<br>
private format specifies &#39;no prefix&#39;, they can just ignore everythi=
ng<br>
that does not start with &quot;{0xFC}|{0x00}&quot;, thus any further comple=
xity<br>
regarding the prefix is also ignored. The only added complexity is one<br>
condition check: second_byte_of_the_key !=3D 0 <br>
<br>
My other argument for conflict-avoidance prefix as a first thing after<br>
0xFC is that the set of future users of PSBT and private types is<br>
most likely much larger than the current set of those who already<br>
implemented proprietary types on their own, and thus the overall benefit<br=
>
for the whole industry will likely be bigger when &#39;i do not want<br>
conflict avoidance&#39; decision have to be explicit, by setting the prefix=
<br>
to 0x00, and the set of possible conflicting types are limited only to<br>
those entities that made this explicit decision.<br>
<br>
Regarding the &#39;squatted&#39; types, it seems to me that this only matte=
rs<br>
in the discussed context if they squatted on 0xFC type in particular.<br>
In other cases, they will need to implement changes anyway, to be<br>
compatible with the BIP. Maybe they could consider that one additional<br>
condition check is a small burden, and maybe they can tolerate that,<br>
for the benefit of reducing possibility of interoperability problems<br>
between other future PSBT/private types implementors.<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div dir=
=3D"ltr"><div>-----------------<br></div><div>Jonathan Underwood</div><div>=
=E3=83=93=E3=83=83=E3=83=88=E3=83=90=E3=83=B3=E3=82=AF=E7=A4=BE=E3=80=80=E3=
=83=81=E3=83=BC=E3=83=95=E3=83=93=E3=83=83=E3=83=88=E3=82=B3=E3=82=A4=E3=83=
=B3=E3=82=AA=E3=83=95=E3=82=A3=E3=82=B5=E3=83=BC</div><div>----------------=
-</div><div><br></div><div>=E6=9A=97=E5=8F=B7=E5=8C=96=E3=81=97=E3=81=9F=E3=
=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8=E3=82=92=E3=81=8A=E9=80=81=E3=82=
=8A=E3=81=AE=E6=96=B9=E3=81=AF=E4=B8=8B=E8=A8=98=E3=81=AE=E5=85=AC=E9=96=8B=
=E9=8D=B5=E3=82=92=E3=81=94=E5=88=A9=E7=94=A8=E4=B8=8B=E3=81=95=E3=81=84=E3=
=80=82</div><div><br></div><div>=E6=8C=87=E7=B4=8B: 0xCE5EA9476DE7D3E45EBC3=
FDAD998682F3590FEA3</div></div></div></div></div></div>

--000000000000245d89058f3f7dae--