From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id EB4BA1E49 for ; 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 ; Sun, 4 Aug 2019 00:15:30 +0000 (UTC) Received: by mail-yb1-f175.google.com with SMTP id z128so5913284yba.6 for ; 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: <20190802141836.15771ad6@simplexum.com> In-Reply-To: <20190802141836.15771ad6@simplexum.com> From: Jonathan Underwood Date: Sun, 4 Aug 2019 09:15:17 +0900 Message-ID: To: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
My two cents:

1. Reserved types are awe= some.
2. Varint for type is awesome.
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" 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.

More like three c= ents, but you get the idea.

I'll keep an eye o= n 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 bitcoin-= dev <bitcoin-de= v@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 l= ike
> the idea of having a prefix string (partially because they've alre= ady
> 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 everythi= ng
that does not start with "{0xFC}|{0x00}", thus any further comple= xity
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 matte= rs
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/mail= man/listinfo/bitcoin-dev


--
-----------------
Jonathan Underwood
= =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
----------------= -

=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: 0xCE5EA9476DE7D3E45EBC3= FDAD998682F3590FEA3
--000000000000245d89058f3f7dae--