{"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-27\n📝 Original message:hello,\n\nOn 26.6.2018 22:30, Pieter Wuille wrote:\n\u003e\u003e (Moreover, as I wrote previously, the Combiner seems like a weirdly\n\u003e\u003e placed role. I still don't see its significance and why is it important\n\u003e\u003e to correctly combine PSBTs by agents that don't understand them. If you\n\u003e\u003e have a usecase in mind, please explain.\n\u003e \n\u003e Forward compatibility with new script types. A transaction may spend\n\u003e inputs from different outputs, with different script types. Perhaps\n\u003e some of these are highly specialized things only implemented by some\n\u003e software (say HTLCs of a particular structure), in non-overlapping\n\u003e ways where no piece of software can handle all scripts involved in a\n\u003e single transaction. If Combiners cannot deal with unknown fields, they\n\u003e won't be able to deal with unknown scripts.\n\nRecord-based Combiners *can* deal with unknown fields. Either by\nincluding both versions, or by including one selected at random. This is\nthe same in k-v model.\n\n\u003e combining must be done independently by Combiner implementations for\n\u003e each script type involved. As this is easily avoided by adding a\n\u003e slight bit of structure (parts of the fields that need to be unique -\n\u003e \"keys\"), this seems the preferable option.\n\nIIUC, you're proposing a \"semi-smart Combiner\" that understands and\nprocesses some fields but not others? That doesn't seem to change\nthings. Either the \"dumb\" combiner throws data away before the \"smart\"\none sees it, or it needs to include all of it anyway.\n\n\u003e No, a Combiner can pick any of the values in case different PSBTs have\n\u003e different values for the same key. That's the point: by having a\n\u003e key-value structure the choice of fields can be made such that\n\u003e Combiners don't need to care about the contents. Finalizers do need to\n\u003e understand the contents, but they only operate once at the end.\n\u003e Combiners may be involved in any PSBT passing from one entity to\n\u003e another.\n\nYes. Combiners don't need to care about the contents.\nSo why is it important that a Combiner properly de-duplicates the case\nwhere keys are the same but values are different? This is a job that,\nAFAICT so far, can be safely left to someone along the chain who\nunderstands that particular record.\n\nSay we have field F(key,value), and several Signers produce F(1,1),\nF(1,2), F(1,3).\n\nA key-based Combiner will pick exactly one to pass along. A record-based\nCombiner will pass all three.\n\nIt seems that you consider the latter PSBT \"invalid\". But it is well\nformed and doesn't contain duplicate records. A Finalizer, or a\ndifferent Combiner that understands field F, can as well have the rule\n\"throw away all but one\" for this case.\n\nTo repeat and restate my central question:\nWhy is it important, that an agent which doesn't understand a particular\nfield structure, can nevertheless make decisions about its inclusion or\nomission from the result (based on a repeated prefix)?\n\nActually, I can imagine the opposite: having fields with same \"key\"\n(identifying data), and wanting to combine their \"values\" intelligently\nwithout losing any of the data. Say, two Signers producing separate\nparts of a combined-signature under the same common public key?\n\n\u003e In case of BIP32 derivation, computing the pubkeys is possibly\n\u003e expensive. A simple signer can choose to just sign with whatever keys\n\u003e are present, but they're not the only way to implement a signer, and\n\u003e even less the only software interacting with this format. Others may\n\u003e want to use a matching approach to find keys that are relevant;\n\u003e without pubkeys in the format, they're forced to perform derivations\n\u003e for all keys present.\n\nI'm going to search for relevant keys by comparing master fingerprint; I\nwould expect HWWs generally don't have index based on leaf pubkeys.\nOTOH, Signers with lots of keys probably aren't resource-constrained and\ncan do the derivations in case of collisions.\n\nAlso, you need to do the derivation and checking anyway, because what if\nthere is a mismatch between the key and the value?\n\nI liked @achow101's idea about supporting non-derived keys, but I\nassumed that you would match them based on the master fingerprint too?\n\nI wouldn't be against including the full master public key (probably\nwithout chaincode) instead of the fingerprint, as you proposed earlier.\nBut including both the leaf pubkey and the fingerprint seems weird.\n\n\u003e If you take the records model, and then additionally drop the\n\u003e whole-record uniqueness constraint, yes, though that seems pushing it\n\u003e a bit by moving even more guarantees from the file format to\n\u003e application level code.\n\nThe \"file format\" makes no guarantees, because the parsing code and\napplication code is the same anyway. You could say I'm proposing to\nseparate these concerns ;)\n\nregards\nm.\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/20180627/386870f6/attachment.sig\u003e"}