Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 817F8CDA for ; Fri, 22 Jun 2018 22:28:41 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BCBB575D for ; Fri, 22 Jun 2018 22:28:40 +0000 (UTC) Date: Fri, 22 Jun 2018 18:28:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=achow101.com; s=protonmail; t=1529706518; bh=+ID8y2QwNFkDiA5X8AyUqFA93XQBIG7qhK+I0GLp1H8=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: From; b=q+SLAFmC0CcHoisKChvGL8B0EP7ur7VOUatq6/FWwM3AfgVsadMyu8LoH5b6ayBE7 UtRxO4iiUpQo+b1Z2g6l8SD8NrZDE6UOK8PO98LQiocQUJsxh0gF7bBm3v83UW46M/ zw8cqO3OlbUfp0X4ejmQlrb0Or74+YJJg7aVSLbE= To: Bitcoin Protocol Discussion From: Achow101 Reply-To: Achow101 Message-ID: In-Reply-To: References: <21a616f5-7a17-35b9-85ea-f779f20a6a2d@satoshilabs.com> <20180621195654.GC99379@coinkite.com> Feedback-ID: VjS95yl5HLFwBfNLRqi61OdL1ERZPmvMbZRH2ZcBR7SKVUVYPgv7VJsV9uoyC4vIfjYnW8hPXGuLTycZbh49Zw==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org 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: Fri, 22 Jun 2018 22:28:41 -0000 Hi all, After reading the comments here about BIP 174, I would like to propose the = following changes: - Moving redeemScripts, witnessScripts, and BIP 32 derivation paths to per-= input and per-output data I think that by moving these three fields into input and output specific ma= ps, the format will be easier to read and simpler for signers to parse. Instead of having to be ab= le to parse entire scripts and extract pubkeys, the signer can simply look at which pubkeys ar= e provided in the inputs and sign the input based upon the presence of a pubkey for which the signer= has a privkey. A neat trick that fits well with this model is that a plain pubkey (one tha= t is not part of a BIP 32 derivation) can still be put in a BIP 32 derivation path field where the va= lue is just the fingerprint of the pubkey itself. This would indicate that no derivation needs to be do= ne from the master key, and the master key is just the specified key itself. Additionally, by having the redeemScript and witnessScript readily availabl= e in the input, signers do not need to construct a map to find a redeemScript or witnessScript and = can instead just look directly in the input data. There is also no need to include the hashes of = these scripts, so the key is just the type. This also allows us to enforce the requirement for only o= ne redeemScript and one witnessScript per input easily by continuing to follow the generic rule of = unique keys. By using input specific and output specific fields, there is no need for th= e input index and the input count types as all inputs will be accounted for. - Finalized scriptSig and scriptWitness fields To determine whether two PSBTs are the same, we can compare the unsigned tr= ansaction. To ensure that the unsigned transactions are the same for two PSBTs with data for the same tx,= we cannot put scriptSigs or scriptWitnesses into it. Thus for each input, two new fields have been adde= d to store the finalized scriptSig and finalized scriptWitness. - Mandatory sighash The sighash type field will be changed from a recommendation to a requireme= nt. Signatures will need to=20 use the specified sighash type for that input. If a Signer cannot sign for = a particular sighash type, it must not add a partial signature. - Encoding I have decided that PSBTs should either be in binary or encoded as a Base64= string. For the latter, several Bitcoin clients already support Base64 encoding of data (for signed message= s) so this will not add any extra dependencies like Z85 would. A draft of the revised BIP can be found here: https://github.com/achow101/b= ips/blob/bip174-rev/bip-0174.mediawiki If these changes are satisfactory, I will open a PR to the BIPs repo to upd= ate the BIP tomorrow. I will also create test vectors and update the implementation PR'ed to Core. Andrew