Date: Sun, 24 Jun 2018 05:00:53 -0400
To: Andrew Chow <achow101-lists@achow101.com>
From: Andrea <a.raspitzu@protonmail.com>
Reply-To: Andrea <a.raspitzu@protonmail.com>
Message-ID: <VL10ISVuFyUBiT2QCjil36o2GN1xLS3r7X3m1QYqBBYetcFsYKr_H3PG2Mqy5hC7SnbxWXqy7dYQ-sb83cEuZyLdy0SpIp3lxWmhql4UPO8=@protonmail.com>
In-Reply-To: <4BLLfQQ5BFO3Z2E2NagJ5trtBmdr6if2KSR9gWpYQY2xKu6THdvk0LJbkRxr8Yie2HA17KOZIM2ljupV_H8cfVkGFFcRjOrA0b13KG9ciF4=@achow101.com>
References: <CAPg+sBhGMxXatsyCAqeboQKH8ASSFAfiXzxyXR9UrNFnah5PPw@mail.gmail.com>
	<CHCiA27GTRiVfkF1DoHdroJL1rQS77ocB42nWxIIhqi_fY3VbB3jsMQveRJOtsJiA4RaCAVe3VZmLZsXVYS3A5wVLNP2OgKQiHE0T27P2qc=@achow101.com>
	<21a616f5-7a17-35b9-85ea-f779f20a6a2d@satoshilabs.com>
	<20180621195654.GC99379@coinkite.com>
	<CAPg+sBgdQqZ8sRSn=dd9EkavYJA6GBiCu6-v5k9ca-9WLPp72Q@mail.gmail.com>
	<ljk5Z_a3KK6DHfmPJxI8o9W2CkwszkUG34h0i1MTGU4ss8r3BTQ3GnTtDTfWF6J7ZqcSAmejzrr11muWqYN-_wnWw_0NFn5_lggNnjI0_Rc=@achow101.com>
	<87zhzlbfq5.fsf@jb55.com>
	<qqrkCNKaf2L_MWkEU5F2u3Jna2QdA-bGNPDE9aU64Im0SUlIo4mfexfp8CXQSj9vEp9XM25DHSJIp4HnKFyLsflAhreppaNJQy-g1hXtjNU=@achow101.com>
	<HWG4r9Lgi0mPONMhHwAXqnGPYeqeAvarQBUlqaRa-iZeysawpb2CN76M0ywrxbhLGJirwWViKIJqwadJcjYPRdYff4ISkSYXAO4a0SWBdVA=@protonmail.com>
	<4BLLfQQ5BFO3Z2E2NagJ5trtBmdr6if2KSR9gWpYQY2xKu6THdvk0LJbkRxr8Yie2HA17KOZIM2ljupV_H8cfVkGFFcRjOrA0b13KG9ciF4=@achow101.com>
Feedback-ID: x-YXDi3m_TiFBHTDMZypFbA_HjfCQuhNiwHDBR0xli2NzJKdIoqs25GtJLT5wHvl0eyVBeRQs8LMD0l_SOtUrQ==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 174 thoughts
Precedence: list

Keeping it for future extensions is a good point, my understanding was that=
 since we always need exactly one transaction it could be part of the defin=
ition of PSBT instead of being a key-value (although it is more of a breaki=
ng change).=20


Cheers, Andrea.

=E2=80=8B=E2=80=8B

=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90

On June 24, 2018 10:28 AM, Andrew Chow <achow101-lists@achow101.com> wrote:

> =E2=80=8B=E2=80=8B
>=20
> I disagree with the idea that global types can be removed. Firstly, it
>=20
> is less of a breaking change to leave it there than to remove it
>=20
> entirely. Secondly, there may be a point in the future where global
>=20
> types would be useful/necessary. By having it still be there, we allow
>=20
> for future extensibility.
>=20
> Andrew
>=20
> On 06/24/2018 01:19 AM, Andrea wrote:
>=20
> > Hi,
> >=20
> > I think in the revised spec we can remove completely the "global types"=
 as a map or even as typed record. Since there is only one type (the transa=
ction) and it's compulsory to have one (and only one) we could just drop th=
e definition of global type and the key associated with it, simply after th=
e header + separator there must be a transaction. Having read all the discu=
ssion i also agree having per-input key derivation and per-output data is a=
 lot more handy for signers, no special feeling regarding the encoding.Look=
ing forward for the test vectors and the new spec.
> >=20
> > Cheers, Andrea.
> >=20
> > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Origina=
l Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=
=90
> >=20
> > On June 23, 2018 10:33 PM, Andrew Chow via bitcoin-dev bitcoin-dev@list=
s.linuxfoundation.org wrote:
> >=20
> > > On 06/23/2018 10:00 AM, William Casarin wrote:
> > >=20
> > > > Since we're still considering the encoding, I wonder if it would be=
 a
> > > >=20
> > > > good idea to have a human-readible part like lightning invoices[1]?
> > > >=20
> > > > I don't think that is necessary.
> > >=20
> > > > Then perhaps you could drop the magic code as well?
> > > >=20
> > > > The magic is still necessary for the binary format in order to prev=
ent
> > >=20
> > > normal transaction deserializers from accidentally deserializing a ps=
bt.
> > >=20
> > > > Also we could do a base encoding that excludes + and / characters, =
such
> > > >=20
> > > > as base62 (gmp-style). It's easier to copy/paste (double clicking a
> > > >=20
> > > > string stops at / or + in base64 encodings).
> > > >=20
> > > > While that would be ideal, I think it is better to use an encoding =
that
> > >=20
> > > most wallets already support. Most wallets already have Base64 decodi=
ng
> > >=20
> > > available so that they can decode signed messages which also use Base=
64
> > >=20
> > > encoding. I think it is unnecessary to introduce another encoding.
> > >=20
> > > On 06/23/2018 11:27 AM, Peter D. Gray wrote:
> > >=20
> > > > Personally, I don't think you should spec an encoding. It should be=
 binary only and hex for developers and JSON interfaces. My thinking is tha=
t PSBT's are not user-visible things. They have a short lifetime and are no=
thing something that is "stored" or referenced much later. Hex is good enou=
gh and has no downsides as an excoding except for density.
> > > >=20
> > > > I think what will end up happening though is that, at least in the
> > >=20
> > > beginning, PSBTs will primarily be strings that people end up copy an=
d
> > >=20
> > > pasting. Since a PSBT can get pretty large, the strings are rather
> > >=20
> > > cumbersome to move around, especially as hex. At least with Base64 th=
e
> > >=20
> > > strings will be smaller.
> > >=20
> > > > On the other hand, suggesting a filename extension (probably .PSBT?=
) and a mime-type to match, are helpful since wallets and such will want to=
 register with their operating systems to become handlers of those mimetype=
s. Really that's a lot more important for interoperability at this point, t=
han an encoding.
> > > >=20
> > > > Agreed. I will include those in the BIP.
> > >=20
> > > > Looking forward to test vectors, and I might have more to say once =
my code can handle them (again).
> > > >=20
> > > > Feedback on the BIP as it stands now:
> > > >=20
> > > > -   Appendix A needs an update, and I suggest defining symbols (PK_=
PARTIAL_SIG =3D=3D 0x02) for the numeric key values. This helps implementer=
s as we don't all define our own symbols and/or use numeric constants in ou=
r code.
> > > >    =20
> > > >     Okay.
> > > >    =20
> > >=20
> > > > -   Those tables are just not working. Might want to reformat as de=
scriptive lists, point form, or generally anything else... sorry.
> > > >    =20
> > > >     I will try my best to fix that. Mediawiki sucks...
> > > >    =20
> > >=20
> > > Andrew
> > >=20
> > > bitcoin-dev mailing list
> > >=20
> > > bitcoin-dev@lists.linuxfoundation.org
> > >=20
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev