From: Jonas Schnelli <dev@jonasschnelli.ch>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_69D51711-72FB-48AE-A48E-0D1E70487810";
	protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Date: Tue, 19 Jun 2018 11:38:24 +0200
References: <CAPg+sBhGMxXatsyCAqeboQKH8ASSFAfiXzxyXR9UrNFnah5PPw@mail.gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAPg+sBhGMxXatsyCAqeboQKH8ASSFAfiXzxyXR9UrNFnah5PPw@mail.gmail.com>
Message-Id: <011F22E3-0116-4769-88FB-0CB675E5BCD5@jonasschnelli.ch>
Subject: Re: [bitcoin-dev] BIP 174 thoughts
Precedence: list


--Apple-Mail=_69D51711-72FB-48AE-A48E-0D1E70487810
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> * Key-value map model or set model.
> * Ability for Combiners to verify two PSBT are for the same =
transaction
> * Optional signing
> * Derivation from xpub or fingerprint
> * Generic key offset derivation
> * Hex encoding?

I think all of Pieters points are valid and reasonable thought, though =
I=E2=80=99m unsure if it would be worth changing the =
existing-implementation-breaking things like the k/v set model.
AFAIK things like non-hex-encoding or generic key offset derivation are =
extensions and would not break existing implementations.

Further thoughts on BIP174 from my side.

Key derivation in multisig:
=46rom my understanding, the signers and the creator must have agreed =
=E2=80=93 in advance to the PSBT use case =E2=80=93 on a key derivation =
scheme.
BIP32 derivation is assumed, but may not always be the case.
Sharing xpubs (the chaincode) may be a concern in =
non-trust-relationships between signer(s) and the creator (regarding =
Pieters xpub/fingerprint concerns).
Providing the type 0x03, the bip32 derivation path is one form of a =
support to faster (or computational possible) derivation of the required =
keys for signing a particular input.
=46rom my point of view, it is a support of additional metadata shared =
between creator and signer and provided from the creator to the signer =
for faster (or computation possible) key deviation.

I think it could be more flexible (generic) in BIP174.
It could be just a single child key {32-bit int}, or just a keypath =
({32-bit int}]{32-bit int}=E2=80=A6) which is very likely sufficient for =
a HWW to derive the relevant key without the creation of a lookup-window =
or other =E2=80=9Emaps".
It could even be an enciphered payload which was shared during =
address/redeem-script generation and =E2=80=9Eloops=E2=80=9C back during =
a signing request.

Maybe I=E2=80=99m overcomplicating things, but for practical multisig =
with HWWs, a simple BIP32-child-key-index or BIP32-keypath derivation =
support field should be sufficient.
A generic =E2=80=9Ederivation support field=E2=80=9C, provided from the =
signer to the creator during address-generation that just =E2=80=9Eloops=E2=
=80=9C back during the PSBT use-cases is probably a overkill.


Thanks
=E2=80=94
/jonas


--Apple-Mail=_69D51711-72FB-48AE-A48E-0D1E70487810
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEyhopCNzi8TB0xizeHrd2uwPHki0FAlsozxEACgkQHrd2uwPH
ki29ng/+KM1LxAo0BUmak4k8KNhNLl/ZzRV3fSGjNB0xCuxsTBhuyK0srEL4fLyc
9tBPCN0iRpITS3xJvB0v7Zz3EqQ7unzlOKOobFdG/02CeI7/S/Z8VVw3s7Qakz8v
pRKshGIUoLzegnikTwQirIuHB9cQbvTF/Nn73ZBHBH5YAR5dduX4o62yU3AwTcWv
hwrmdWPmBajpOEZcf98uoAKN67Ye+7MF4H/BfYDhYNOu71SpIxrEcLMITsTrqBRj
psQq3wK9u7IV67f64FFLomYFFgtP34rrOowYFKeM901qEw3Ue/f4grklyjtovr0G
5M7SYPs3QU7OhYgOVTpy0Tq0BXpiUGPgwuQR+FlL03i7267peDYpbRpjhGZyV02w
zU71Js3s+MgfMa2egft8r8M9Wf96L1ZBkZsnCvdzwLdGi3OEDQ9sY2pcUl1inTa7
yP1wWBJGGT8pdV2t+ONWGSTEgSlFIyOWssNj4EIokczJfsVBBj15wUKxk6R9kEt+
uGzSgq+6TBHi2v9fePCklFVNFQb0/dqYkHF7ftZhdx4guhkuOCrxPJVU5imCE7ec
RxFVKRIfNlI2HfubFMuFplM6AOuDb811Z9FcbubdBNEZnTp3v8px+v1LCDB1LOu1
1xJmmBemPjY+teJgLzN5aoHoRAKMfL8r5Fuvz3VKNVKCdWrcIyM=
=/bTl
-----END PGP SIGNATURE-----

--Apple-Mail=_69D51711-72FB-48AE-A48E-0D1E70487810--