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 C7950C5C for ; Sat, 23 Jun 2018 18:27:19 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from smtp105.ord1c.emailsrvr.com (smtp105.ord1c.emailsrvr.com [108.166.43.105]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 55BAE722 for ; Sat, 23 Jun 2018 18:27:19 +0000 (UTC) Received: from smtp22.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp22.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id A4BE0E016F; Sat, 23 Jun 2018 14:27:18 -0400 (EDT) X-Auth-ID: peter@coinkite.com Received: by smtp22.relay.ord1c.emailsrvr.com (Authenticated sender: peter-AT-coinkite.com) with ESMTPSA id C3752E0154; Sat, 23 Jun 2018 14:27:16 -0400 (EDT) X-Sender-Id: peter@coinkite.com Received: from coinkite.com ([UNAVAILABLE]. [216.223.137.93]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:465 (trex/5.7.12); Sat, 23 Jun 2018 14:27:18 -0400 Date: Sat, 23 Jun 2018 14:27:15 -0400 From: "Peter D. Gray" To: Achow101 , Bitcoin Protocol Discussion Message-ID: <20180623182715.GC893@coinkite.com> Reply-To: Peter Gray References: <21a616f5-7a17-35b9-85ea-f779f20a6a2d@satoshilabs.com> <20180621195654.GC99379@coinkite.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline In-Reply-To: Organization: Coinkite Cryptobank (www.coinkite.com) User-Agent: Mutt/1.6.0 (2016-04-01) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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: Sat, 23 Jun 2018 21:19:03 +0000 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: Sat, 23 Jun 2018 18:27:19 -0000 --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 22, 2018 at 06:28:33PM -0400, Achow101 wrote: > After reading the comments here about BIP 174, I would like to propose th= e following changes: >=20 > - Moving redeemScripts, witnessScripts, and BIP 32 derivation paths to pe= r-input and per-output data =2E.. I like this. I agree it's making things easier and it's more flexible. > - Finalized scriptSig and scriptWitness fields >=20 > To determine whether two PSBTs are the same, we can compare the unsigned = transaction. To ensure that the > unsigned transactions are the same for two PSBTs with data for the same t= x, we cannot put scriptSigs or > scriptWitnesses into it. Thus for each input, two new fields have been ad= ded to store the finalized scriptSig > and finalized scriptWitness. =2E.. To be honest, I don't understand the reasons/implications of this change, b= ut it seems harmless. > - Mandatory sighash =2E.. Good improvement. > - Encoding >=20 > I have decided that PSBTs should either be in binary or encoded as a Base= 64 string. For the latter, several > Bitcoin clients already support Base64 encoding of data (for signed messa= ges) so this will not add any extra > dependencies like Z85 would. =2E.. 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 that PSBT's= are not user-visible things. They have a short lifetime and are nothing so= mething that is "stored" or referenced much later. Hex is good enough and h= as no downsides as an excoding except for density. 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 registe= r with their operating systems to become handlers of those mimetypes. Reall= y that's a lot more important for interoperability at this point, than an e= ncoding. > A draft of the revised BIP can be found here: https://github.com/achow101= /bips/blob/bip174-rev/bip-0174.mediawiki > If these changes are satisfactory, I will open a PR to the BIPs repo to u= pdate the BIP tomorrow. I will also > create test vectors and update the implementation PR'ed to Core. =2E.. Looking forward to test vectors, and I might have more to say once my code = can handle them (again). Feedback on the BIP as it stands now:=20 - Appendix A needs an update, and I suggest defining symbols (PK_PARTIAL_SI= G =3D=3D 0x02) for the numeric key values. This helps implementers as we do= n't all define our own symbols and/or use numeric constants in our code. - Those tables are just not working. Might want to reformat as descriptive = lists, point form, or generally anything else... sorry. > Andrew > _______________________________________________ --- Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG: A3A31B= AD 5A2A5B10 --UlVJffcvxoiEqYs2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJbLpEDAAoJEKOjG61aKlsQpH0H/A8HAYThrP91Jz0Rfk11Rh8I P/OH22ld+SBlu6ggsMOoQaBGNSVj9XxtMXhLUAbjtwmEPjxfpUPLdq/H07recIJ/ KDEyujj+8T0q1UjuVeixBAifq21QkgHyjHZUXXcuC7f1doELrqba5Mqi4/IBjRfa 9c//fzY8JI5CPs2VkgvNTjTH0j2953DDZ66nKo6cS7uTCp4KmCRCd0ud/NYdKecu DrUcru7nI1yLdSBpNjjx44LQF7pexl89oCtmIZE6vra+bPFubjlrQU/UOpjuruJB FWmbt1El+Sf4lOxCK4B/En0FfMFbiU6e6TrS5+Dw58W7/5JfJPac5Z+a/O4Vy4o= =JJkP -----END PGP SIGNATURE----- --UlVJffcvxoiEqYs2--