{"type":"rich","version":"1.0","title":"Pieter Wuille [ARCHIVE] wrote","author_name":"Pieter Wuille [ARCHIVE] (npub1tj…jtl6r)","author_url":"https://yabu.me/npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6r","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2018-06-15\n📝 Original message:Hello all,\n\ngiven some recent work and discussions around BIP 174 (Partially\nSigned Bitcoin Transaction Format) I'd like to bring up a few ideas.\n\nFirst of all, it's unclear to me to what extent projects have already\nworked on implementations, and thus to what extent the specification\nis still subject to change. A response of \"this is way too late\" is\nperfectly fine.\n\nSo here goes:\n\n* Key-value map model or set model.\n\nThis was suggested in this thread:\nhttps://twitter.com/matejcik/status/1002618633472892929\n\nThe motivation behind using a key-value model rather than a simple\nlist of records was that PSBTs can be duplicated (given to multiple\npeople for signing, for example), and merged back together after\nsigning. With a generic key-value model, any implementation can remove\nthe duplication even if they don't understand fields that may have\nbeen added in future extensions.\n\nHowever, almost the same can be accomplished by using the simpler set\nmodel (the file consists of a set of records, with no duplication\nallowed). This would mean that it would technically be legal to have\ntwo partial signatures with the same key for the same input, if a\nnon-deterministic signer is used.\n\nOn the other hand, this means that certain data currently encoded\ninside keys can be dropped, reducing the PSBT size. This is\nparticularly true for redeemscripts and witnessscripts, as they can\njust be computed by the client when deserializing. The two types could\neven be merged into just \"scripts\" records - as they don't need to be\nseparated based on the way they're looked up (Hash160 for P2SH, SHA256\nfor P2WSH). The same could be done for the BIP32 derivation paths,\nthough this may be expensive, as the client would need to derive all\nkeys before being able to figure out which one(s) it needs.\n\nOne exception is the \"transaction\" record, which needs to be unique.\nThat can either be done by adding an exception (\"there can only be one\ntransaction record\"), or by encoding it separately outside the normal\nrecords (that may also be useful to make it clear that it is always\nrequired).\n\n* Ability for Combiners to verify two PSBT are for the same transaction\n\nClearly two PSBTs for incompatible transactions cannot be combined,\nand this should not be allowed.\n\nIt may be easier to enforce this if the \"transaction\" record inside a\nPSBT was required to be in a canonical form, meaning with empty\nscriptSigs and witnesses. In order to do so, there could be per-input\nrecords for \"finalized scriptSig\" and \"finalized witness\". Actually\nplacing those inside the transaction itself would only be allowed when\nall inputs are finalized.\n\n* Optional signing\n\nI think all operation for the Signer responsibility should be\noptional. This will inevitably lead to incompatibilities, but with the\nintent of being forward compatible with future developments, I don't\nthink it is possible to require every implementation to support the\nsame set of scripts or contracts. For example, some signers may only\nimplement single-key P2PKH, or may only support signing SegWit inputs.\nIt's the user's responsibility to find compatible signers (which is\ngenerally not an issue, as the different participants in a setup\nnecessarily have this figured out before being able to create an\naddress). This does mean that there can't be an unconditional test\nvector that specifies the produced signature in certain circumstances,\nbut there could be \"For implementations that choose to implement\nsigning for P2PKH inputs using RFC6979, the expected output given\ninput X and access to key Y is Z\".\n\nOn the other hand, the Combiner and Finalizer roles can probably be\nspecified much more accurately than they are now.\n\n* Derivation from xpub or fingerprint\n\nFor BIP32 derivation paths, the spec currently only encodes the 32-bit\nfingerprint of the parent or master xpub. When the Signer only has a\nsingle xprv from which everything is derived, this is obviously\nsufficient. When there are many xprv, or when they're not available\nindexed by fingerprint, this may be less convenient for the signer.\nFurthermore, it violates the \"PSBT contains all information necessary\nfor signing, excluding private keys\" idea - at least if we don't treat\nthe chaincode as part of the private key.\n\nFor that reason I would suggest that the derivation paths include the\nfull public key and chaincode of the parent or master things are\nderived from. This does mean that the Creator needs to know the full\nxpub which things are derived from, rather than just its fingerprint.\n\n* Generic key offset derivation\n\nWhenever a BIP32 derivation path does not include any hardened steps,\nthe entirety of the derivation can be conveyed as \"The private key for\nP is equal to the private key for Q plus x\", with P and Q points and x\na scalar. This representation is more flexible (it also supports\npay-to-contract derivations), more efficient, and more compact. The\ndownside is that it requires the Signer to support such derivation,\nwhich I don't believe any current hardware devices do.\n\nWould it make sense to add this as an additional derivation method?\n\n* Hex encoding?\n\nThis is a very minor thing. But presumably there will be some standard\nway to store PSBTs as text for copy-pasting - either prescribed by the\nspec, or de facto. These structures may become pretty large, so\nperhaps it's worth choosing something more compact than hexadecimal -\nfor example Base64 or even Z85 (https://rfc.zeromq.org/spec:32/Z85/).\n\nCheers,\n\n-- \nPieter"}