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