{"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-27\n📝 Original message:On Wed, Jun 27, 2018, 07:04 matejcik \u003cjan.matejek at satoshilabs.com\u003e wrote:\n\n\u003e hello,\n\u003e\n\u003e On 26.6.2018 22:30, Pieter Wuille wrote:\n\u003e \u003e\u003e (Moreover, as I wrote previously, the Combiner seems like a weirdly\n\u003e \u003e\u003e placed role. I still don't see its significance and why is it important\n\u003e \u003e\u003e to correctly combine PSBTs by agents that don't understand them. If you\n\u003e \u003e\u003e have a usecase in mind, please explain.\n\u003e \u003e\n\u003e \u003e Forward compatibility with new script types. A transaction may spend\n\u003e \u003e inputs from different outputs, with different script types. Perhaps\n\u003e \u003e some of these are highly specialized things only implemented by some\n\u003e \u003e software (say HTLCs of a particular structure), in non-overlapping\n\u003e \u003e ways where no piece of software can handle all scripts involved in a\n\u003e \u003e single transaction. If Combiners cannot deal with unknown fields, they\n\u003e \u003e won't be able to deal with unknown scripts.\n\u003e\n\u003e Record-based Combiners *can* deal with unknown fields. Either by\n\u003e including both versions, or by including one selected at random. This is\n\u003e the same in k-v model.\n\u003e\n\nYes, I wasn't claiming otherwise. This was just a response to your question\nwhy it is important that Combiners can process unknown fields. It is not an\nargument in favor of one model or the other.\n\n\u003e combining must be done independently by Combiner implementations for\n\u003e \u003e each script type involved. As this is easily avoided by adding a\n\u003e \u003e slight bit of structure (parts of the fields that need to be unique -\n\u003e \u003e \"keys\"), this seems the preferable option.\n\u003e\n\u003e IIUC, you're proposing a \"semi-smart Combiner\" that understands and\n\u003e processes some fields but not others? That doesn't seem to change\n\u003e things. Either the \"dumb\" combiner throws data away before the \"smart\"\n\u003e one sees it, or it needs to include all of it anyway.\n\u003e\n\nNo, I'm exactly arguing against smartness in the Combiner. It should always\nbe possible to implement a Combiner without any script specific logic.\n\n\u003e No, a Combiner can pick any of the values in case different PSBTs have\n\u003e \u003e different values for the same key. That's the point: by having a\n\u003e \u003e key-value structure the choice of fields can be made such that\n\u003e \u003e Combiners don't need to care about the contents. Finalizers do need to\n\u003e \u003e understand the contents, but they only operate once at the end.\n\u003e \u003e Combiners may be involved in any PSBT passing from one entity to\n\u003e \u003e another.\n\u003e\n\u003e Yes. Combiners don't need to care about the contents.\n\u003e So why is it important that a Combiner properly de-duplicates the case\n\u003e where keys are the same but values are different? This is a job that,\n\u003e AFAICT so far, can be safely left to someone along the chain who\n\u003e understands that particular record.\n\u003e\n\nThat's because PSBTs can be copied, signed, and combined back together. A\nCombiner which does not deduplicate (at all) would end up having every\noriginal record present N times, one for each copy, a possibly large blowup.\n\nFor all fields I can think of right now, that type of deduplication can be\ndone through whole-record uniqueness.\n\nThe question whether you need whole-record uniqueness or specified-length\nuniqueness (=what is offered by a key-value model) is a philosophical one\n(as I mentioned before). I have a preference for stronger invariants on the\nfile format, so that it becomes illegal for a PSBT to contain multiple\nsignatures for the same key for example, and implementations do not need to\ndeal with the case where multiple are present.\n\nIt seems that you consider the latter PSBT \"invalid\". But it is well\n\u003e formed and doesn't contain duplicate records. A Finalizer, or a\n\u003e different Combiner that understands field F, can as well have the rule\n\u003e \"throw away all but one\" for this case.\n\u003e\n\nIt's not about considering. We're writing a specification. Either it is\nmade invalid, or not.\n\nIn a key-value model you can have dumb combiners that must pick one of the\nkeys in case of duplication, and remove the necessity of dealing with\nduplication from all other implementations (which I consider to be a good\nthing). In a record-based model you cannot guarantee deduplication of\nrecords that permit repetition per type, because a dumb combiner cannot\nunderstand what part is supposed to be unique. As a result, a record-based\nmodel forces you to let all implementations deal with e.g. multiple partial\nsignatures for a single key. This is a minor issue, but in my view shows\nhow records are a less than perfect match for the problem at hand.\n\nTo repeat and restate my central question:\n\u003e Why is it important, that an agent which doesn't understand a particular\n\u003e field structure, can nevertheless make decisions about its inclusion or\n\u003e omission from the result (based on a repeated prefix)?\n\u003e\n\nAgain, because otherwise you may need a separate Combiner for each type of\nscript involved. That would be unfortunate, and is very easily avoided.\n\nActually, I can imagine the opposite: having fields with same \"key\"\n\u003e (identifying data), and wanting to combine their \"values\" intelligently\n\u003e without losing any of the data. Say, two Signers producing separate\n\u003e parts of a combined-signature under the same common public key?\n\u003e\n\nThat can always be avoided by using different identifying information as\nkey for these fields. In your example, assuming you're talking about some\nform of threshold signature scheme, every party has their own \"shard\" of\nthe key, which still uniquely identifies the participant. If they have no\ndata that is unique to the participant, they are clones, and don't need to\ninteract regardless.\n\n\u003e In case of BIP32 derivation, computing the pubkeys is possibly\n\u003e \u003e expensive. A simple signer can choose to just sign with whatever keys\n\u003e \u003e are present, but they're not the only way to implement a signer, and\n\u003e \u003e even less the only software interacting with this format. Others may\n\u003e \u003e want to use a matching approach to find keys that are relevant;\n\u003e \u003e without pubkeys in the format, they're forced to perform derivations\n\u003e \u003e for all keys present.\n\u003e\n\u003e I'm going to search for relevant keys by comparing master fingerprint; I\n\u003e would expect HWWs generally don't have index based on leaf pubkeys.\n\u003e OTOH, Signers with lots of keys probably aren't resource-constrained and\n\u003e can do the derivations in case of collisions.\n\u003e\n\nPerhaps you want to avoid signing with keys that are already signed with?\nIf you need to derive all the keys before even knowing what was already\nsigned with, you've already performed 80% of the work.\n\n\u003e If you take the records model, and then additionally drop the\n\u003e \u003e whole-record uniqueness constraint, yes, though that seems pushing it\n\u003e \u003e a bit by moving even more guarantees from the file format to\n\u003e \u003e application level code.\n\u003e\n\u003e The \"file format\" makes no guarantees, because the parsing code and\n\u003e application code is the same anyway. You could say I'm proposing to\n\u003e separate these concerns ;)\n\u003e\n\nOf course a file format can make guarantees. If certain combinations of\ndata in it do not satsify the specification, the file is illegal, and\nimplementations do not need to deal with it. Stricter file formats are\neasier to deal with, because there are less edge cases to consider.\n\nTo your point: proto v2 afaik has no way to declare \"whole record\nuniqueness\", so either you drop that (which I think is unacceptable - see\nthe copy/sign/combine argument above), or you deal with it in your\napplication code.\n\nCheers,\n\n-- \nPieter\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180627/fecd0346/attachment-0001.html\u003e"}