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 EF5F4D15 for ; Tue, 19 Jun 2018 09:38:32 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from bitcoin.jonasschnelli.ch (bitcoinsrv.jonasschnelli.ch [138.201.55.219]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 0E05917E for ; Tue, 19 Jun 2018 09:38:31 +0000 (UTC) Received: by bitcoin.jonasschnelli.ch (Postfix, from userid 1002) id D9EC615E5291; Tue, 19 Jun 2018 11:38:30 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 Received: from [192.168.2.165] (226.218.173.83.static.wline.lns.sme.cust.swisscom.ch [83.173.218.226]) by bitcoin.jonasschnelli.ch (Postfix) with ESMTPSA id 9A87315E4E89; Tue, 19 Jun 2018 11:38:30 +0200 (CEST) From: Jonas Schnelli 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: To: Pieter Wuille , Bitcoin Protocol Discussion In-Reply-To: Message-Id: <011F22E3-0116-4769-88FB-0CB675E5BCD5@jonasschnelli.ch> X-Mailer: Apple Mail (2.3445.8.2) X-Virus-Scanned: clamav-milter 0.99.4 at bitcoinsrv.jonasschnelli.ch X-Virus-Status: Clean Subject: Re: [bitcoin-dev] BIP 174 thoughts 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: Tue, 19 Jun 2018 09:38:33 -0000 --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--