{"type":"rich","version":"1.0","author_name":"npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","author_url":"https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2012-11-28\n📝 Original message:The current spec is ambiguous in the case of what to do if the invoice\ncontains one output of a fixed amount and one or more outputs of an\nunspecified amount. Should the user be prompted once per output? That\nseems suboptimal. Prompted once for a value that's then randomly\ndistributed between all open-value outputs? It seems this ability of\nthe protocol is somewhat more complex than it appears. The ability to\nhave open outputs is nice for tips though.\n\nYou could consider moving pki_type and pki_data into a separate\nmessage and making both fields required, then making the pki message\noptional. Otherwise you can have pki_type set but no data or\nvice-versa. It doesn't make much difference in the end, just slightly\nimproves the automatic sanity checks produced by the proto compiler.\n\nw.r.t SIGHASH_ANYONECANPAY. I think it's best not to use this\nroutinely as it relaxes the signature checks in ways that may open\nnon-obvious holes when combined with other features. I thought we\npretty much had consensus on recursively calculating fees including\ndependents in the memory pool?\n\nPeter is correct that there are a few degrees of freedom in protobuf\nserialization, though far fewer than with JSON. I'd like to think\nupstream would be open to resolving these ambiguities.\nRe-serialization of an Invoice message in the Payment message is a\npotential source of mistakes. There's no need to ever concatenate\nthese messages and alternative implementations that don't order\nserialized fields by tag number are missing an important optimization,\nso they could be fixed. The main issue is treatment of unknown fields.\nIf/when the Invoice message is extended with other fields that are\nround-tripped through an old client, the data may get lost. JSON\ndoesn't help resolve that either, of course. There are a few\nsolutions:\n\n1) Change the type of the Invoice field in Payment to be \"bytes\" and\nset it to be the hash of the originally received binary Invoice\nmessage. Downside, requires merchants to track all outstanding\ninvoices.\n2) Ask protobufs upstream to modify the spec/implementations so\nordering of unknown fields is specified. The Python implementation\ncould be extended to support them so Python implementors don't end up\nwith accidental message downgrades.\n3) Language of the spec could be changed to explicitly state that the\nreceived Invoice may not be binary-identical to the one that was sent,\nin the case of a client that incorrectly downgrades the message. Thus\nyou'd be expected to check what the Invoice was using merchant_data\nwhich is opaque and could just be, eg, a database key on your own end.\n4) Instead of submitting the entire Invoice back to the merchant, just\nthe merchant_data could be in the Payment message.\n\nOf the four options I prefer the last. What is the use case for\nresubmitting the entire invoice anyway? Even if protobufs are improved\nso handling of round-tripping new messages through old [Python]\nclients is more rigorous, some implementors will probably convert the\nprotobuf objects into some internal forms for whatever reason (or\nserialize them to a database, etc) and they're very likely to mess up\nthe handling of unknown fields when they do it."}