{"type":"rich","version":"1.0","title":"matejcik [ARCHIVE] wrote","author_name":"matejcik [ARCHIVE] (npub18g…sgac3)","author_url":"https://yabu.me/npub18g04tf4qudcsna6qfcrm55s39axx3ymrunr65gxen4rctm0zv24sasgac3","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2018-06-19\n📝 Original message:hello,\nthis is our second e-mail with replies to Pieter's suggestions.\n\nOn 16.6.2018 01:34, pieter.wuille at gmail.com (Pieter Wuille) wrote:\n\u003e * Key-value map model or set model.\n\u003e \n\u003e This was suggested in this thread:\n\u003e https://twitter.com/matejcik/status/1002618633472892929\n\u003e \n\u003e The motivation behind using a key-value model rather than a simple\n\u003e list of records was that PSBTs can be duplicated (given to multiple\n\u003e people for signing, for example), and merged back together after\n\u003e signing. With a generic key-value model, any implementation can remove\n\u003e the duplication even if they don't understand fields that may have\n\u003e been added in future extensions.\n\u003e \n\u003e However, almost the same can be accomplished by using the simpler set\n\u003e model (the file consists of a set of records, with no duplication\n\u003e allowed). This would mean that it would technically be legal to have\n\u003e two partial signatures with the same key for the same input, if a\n\u003e non-deterministic signer is used.\n\nStrongly agree with this.\n\nJust to note, we should probably use varint for the \u003ctype\u003e field - this\nallows us, e.g., to create “namespaces” for future extensions by using\none byte as namespace identifier and one as field identifier.\n\n\u003e \n\u003e On the other hand, this means that certain data currently encoded\n\u003e inside keys can be dropped, reducing the PSBT size. This is\n\u003e particularly true for redeemscripts and witnessscripts, as they can\n\u003e just be computed by the client when deserializing. The two types could\n\u003e even be merged into just \"scripts\" records - as they don't need to be\n\u003e separated based on the way they're looked up (Hash160 for P2SH, SHA256\n\u003e for P2WSH). The same could be done for the BIP32 derivation paths,\n\u003e though this may be expensive, as the client would need to derive all\n\u003e keys before being able to figure out which one(s) it needs.\n\nIt could be nice if the output scripts records would be ordered the same\nas their corresponding outputs. But what if the Creator doesn’t want to\ninclude a script for an output? Perhaps the Script record should have a\n\u003cvout\u003e field to match it to the appropriate output.\n\nAs for input scripts, we suggest that they are per-input and not\nincluded in the global record, see the other thread.\n\n\u003e \n\u003e One exception is the \"transaction\" record, which needs to be unique.\n\u003e That can either be done by adding an exception (\"there can only be one\n\u003e transaction record\"), or by encoding it separately outside the normal\n\u003e records (that may also be useful to make it clear that it is always\n\u003e required).\n\nThis seems to be the case for some fields already - i.e., an input field\nmust have exactly one of Non-witness UTXO or Witness Output. So “adding\nan exception” is probably just a matter of language?\n\n\nWe’d also like to note that the “number of inputs” field should be\nmandatory - and as such, possibly also a candidate for outside-record field.\n\n\u003e \n\u003e * Ability for Combiners to verify two PSBT are for the same transaction\n\u003e \n\u003e Clearly two PSBTs for incompatible transactions cannot be combined,\n\u003e and this should not be allowed.\n\u003e \n\u003e It may be easier to enforce this if the \"transaction\" record inside a\n\u003e PSBT was required to be in a canonical form, meaning with empty\n\u003e scriptSigs and witnesses. In order to do so, there could be per-input\n\u003e records for \"finalized scriptSig\" and \"finalized witness\". Actually\n\u003e placing those inside the transaction itself would only be allowed when\n\u003e all inputs are finalized.\n\nAgreed! Also increases clarity, which is desired.\n\n\u003e * Derivation from xpub or fingerprint\n\u003e \n\u003e For BIP32 derivation paths, the spec currently only encodes the 32-bit\n\u003e fingerprint of the parent or master xpub. When the Signer only has a\n\u003e single xprv from which everything is derived, this is obviously\n\u003e sufficient. When there are many xprv, or when they're not available\n\u003e indexed by fingerprint, this may be less convenient for the signer.\n\u003e Furthermore, it violates the \"PSBT contains all information necessary\n\u003e for signing, excluding private keys\" idea - at least if we don't treat\n\u003e the chaincode as part of the private key.\n\u003e \n\u003e For that reason I would suggest that the derivation paths include the\n\u003e full public key and chaincode of the parent or master things are\n\u003e derived from. This does mean that the Creator needs to know the full\n\u003e xpub which things are derived from, rather than just its fingerprint.\n\n\nWe don’t understand the rationale for this idea. Do you see a scenario\nwhere an index on master fingerprint is not available but index by xpubs\nis? In our envisioned use cases at least, indexing private keys by xpubs\n(as opposed to deriving from a BIP32 path) makes no sense.\n\nMaybe this folds into the proposal for generic derivation below, or\nsomething like implementation-specific derivation methods?\n\nbest regards\n\nJan Matejek\nTomas Susanka\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 819 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180619/70447694/attachment-0001.sig\u003e"}