<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><span style="color:rgb(34,34,34)">We could leave the version field outside the AONT, though, but commit to</span><br></div></div>
changing the paramaters of the AONT (in particular, the domain<br>
separation constant?) if we change the version number, so that an<br>
adversary changing the version number to "2" would just cause the client<br>
to throw an error (before version 2 exists) or be an invalid address<br>
(after version 2 exists)?</blockquote><div><br></div><div>To add an aside from a discussion with Teor: the entire "version" field could be reduced to a single - probably "zero" - bit, in a manner perhaps similar to the distinctions between Class-A, Class-B, Class-C... addresses in old IPv4.</div><div><br></div><div>Thus: if the first bit in the address is zero, then there is no version, and we are at version 0 of the format</div><div><br></div><div>If the first bit is one, we are using v1+ of the format and all bets are off, except that the obvious thing then to do is count the number of 1-bits (up to some limit) and declare that to be version number.  Once we're up to 3 or 4 or 7 or 8 one-bits, then shift version encoding totally.</div><div><br></div><div>Teor will correct me if I misquote him, but the advantage here was:</div><div><br></div><div>a) the version number is 1 bit, ie: small, for the forseeable / if we get it right</div><div><br></div><div>b) in pursuit of smallness, we could maybe dump the hash in favour of a AONT + eyeballs, which would give back a bunch of extra bits </div><div><br></div><div>result: shorter addresses, happier users.</div><div> <br></div></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><a href="http://dropsafe.crypticide.com/aboutalecm" target="_blank">http://dropsafe.crypticide.com/aboutalecm</a><br></div>
</div></div>