<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Feb 22, 2017 at 5:26 PM, Peter Todd <span dir="ltr"><<a href="mailto:pete@petertodd.org" target="_blank">pete@petertodd.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
A commitment scheme needs only have the property that it's not feasible to find<br>
two messages m1 and m2 that map to the same commitment; it is *not* required<br>
that it be difficult to find m given the commitment. Equally, it's not required<br>
that commitments always be the same size. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So a perfectly reasonable thing to do is design your scheme such that the<br>
commitment to short messages is the message itself! This adds just a single bit<br>
of data to the minimum serialized size(1) of the commitment, and in situations<br>
where sub-digest-sized messages are common, may overall be a savings.<br></blockquote><div><br></div><div>Yes I'm basically doing that but to make things be all the same size I'm including the bit inline, sacrificing one bit of security. Actually I'm sacrificing two bits of security, to allow for four values: terminal, middle, empty, and invalid. Invalid is used internally when a value has yet to be calculated lazily and in proofs to mean 'this is a middle node but the children are not included'. One effect of this is that the root of a set containing a single value is just that value with the two high order bits of the first byte reset to the appropriate value.</div><div><br></div></div></div></div>