path: root/6d/a7a88445ee7bd2caa215345dbbce6d57092886

Return-Path: <junderwood@bitcoinbank.co.jp>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id EB4BA1E49
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  4 Aug 2019 00:15:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com
	[209.85.219.175])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2115C7ED
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  4 Aug 2019 00:15:30 +0000 (UTC)
Received: by mail-yb1-f175.google.com with SMTP id z128so5913284yba.6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 03 Aug 2019 17:15:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=bitcoinbank.co.jp; s=google;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to; 
	bh=umf95io8JVTedjamn664nqd/wg/iKgZfd6NVtV8yses=;
	b=au1Yw2xkoL1cWaPRih5hZdokmbhgVlSyl3X56LFoUcrvtKErL6Zh+FlIafJqeWw2Af
	4jGn96RlxZmpCWA3eFSQJ82loK5ZNywjjnz9Sq+Dnfv40FgTttmBEiC+I45Qttp/+Fn/
	rKUgfgjku80DZgPqVhMiG3Z4lM1CyXq56jAzFRc+cOJjxDow1KBQ0AMSlp+sa9BaLzCm
	ICeX+MheHrxFf6cMiwhH5bon0qZfE9Oyn2uBxoAT7GgaLXP8jjEQ26wkUi0cp3q9L1mH
	6tQaMHZtPLUbWAXAnztPIfCjBY31iKAokpXBnWDWh/1nLVSY60+3j/zd4vOoHQHVgFM9
	PVPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to;
	bh=umf95io8JVTedjamn664nqd/wg/iKgZfd6NVtV8yses=;
	b=FMApYheTGw9VgWh5hBhpy3SX5W8K+0+9EESURY87Ux+ZHknhBobWLrqlRQZ7vplZRA
	I0ildT70mc6b7QvG5Y1DnIZXqoF1pKOthMTVV8k72ltlx8AzaxqSAFMrgNEuHr5axbDd
	RetvDQXeSGBob5EWUxcUKr2Q7qSv0bAmBKjTOl1AIr9pGuMGD42wGx+0byvSaq3dHbo0
	5SxqKKbBo0lJD/6AEXA63j2ckGLO5tpCNlq3a98SfFR5fGHKvyG3HAR2X1DB9BJxYpgu
	aOyVqjDYRYW+15P+CBSejlIS8elH4AZpCoK9H3dP/dP5PaKs2BG+VGXCfGQBYJoikv9t
	A3/w==
X-Gm-Message-State: APjAAAUIw9QzfBtxiTYd6E0YEKt0c+CPOpVfdjI4a3nv4hTERn643oCS
	sj7Qi1RvlHUQTBSyO7TrAhN/9pSvxTB08CdLpVnKG/A=
X-Google-Smtp-Source: APXvYqyvpJY4W39u8ctTV2DjMjUrhPgeURB1/P7vGwoJNTRRPG6Hq7RzLArcxFYM65fSTsmgFZS59OP8gEgnYX2rjXY=
X-Received: by 2002:a25:5e44:: with SMTP id s65mr82523476ybb.235.1564877728794;
	Sat, 03 Aug 2019 17:15:28 -0700 (PDT)
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"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Sun, 04 Aug 2019 03:34:40 +0000
Subject: Re: [bitcoin-dev] Proposed Extensions to BIP 174 for Future
	Extensibility
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Sun, 04 Aug 2019 00:15:31 -0000

--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--