<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">&lt;<a href="mailto:pete@petertodd.org" target="_blank">pete@petertodd.org</a>&gt;</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&#39;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&#39;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&#39;m basically doing that but to make things be all the same size I&#39;m including the bit inline, sacrificing one bit of security. Actually I&#39;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 &#39;this is a middle node but the children are not included&#39;. 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>