Re: [Bug-gnubg] Extending MatchID's and software compatibility - Good News - 6 bits free

[Michael Petch]

Howdy All,

My original tests assumed a worst case scenario that we would have to
add extra bytes to the MatchID portion. This might be the case if we
decided to put a fair bit of extra information in. We have one saving
grace of course. We are currently not using all the bits available to us.

A current MatchID is 12 characters base encoded, but only represents
66bits of data (A MatchKey currently is 66 bits). 12 characters of base
64 encoding can represent a maximum of 72 bits (12 * 6).

We have 6 bits to spare in our current encoding to do with as we please.
If we do not exceed a total of 72 bits we seem to remain compatible with
existing software. 0.14.3, 0.15, 0.90+, Gabbi(online), XG, BgBlitz

In all cases if I encode 6 extra bits of data to a MatchID and paste it,
all the software above converts the first 66 bits and ignores the
remaining 6 bits. In the case of old versions of GNUBG if you paste a
matchID encoded with an extra 6 bits it will ignore the bits AND will
update the GUI with a new MatchID computed from only the first 66 bits.
So you may paste a new MatchID but it will appear as the matchID minus
the extra 6 bits once updated in the UI. This makes sense since the
extra 6 bits are meaningless.

It appears that all software that currently generate the MatchID portion
of a GNUBGID set the unused 6 bits to zero. If one has no versioning
information in the bits, one has to take the default zeros into account
since software that we paste into won't know whether the ID was
generated from software that added extra bits or not.

In the case of Jacoby we could add it as bit 67. Since Jacoby wasn't
encoded previously (but is zero in older ids) and is generally the
default ON in Money Sessions we would have to reverse the meaning of the
flag to actually mean "NotJacoby". So if Updated software reads an ID
generated from older programs and comes across a money session it will
see the NotJacoby flag (bit 67) as being zero and assumes Jacoby is on.
If new style software sets bit 67 ON, it will signal Jacoby being off.
Old software reading new IDs will be none the wiser and just ignore the
extra data.

If we ever require more than the 6 bits  and have to extend a MatchID
beyond 12 base64 encoded characters,  then the software that currently
exists will have the issues as outline in my previous messages on the
matter.

-- 
Michael Petch
CApp::Sysware Consulting Ltd.
OpenPGP FingerPrint=D81C 6A0D 987E 7DA5 3219 6715 466A 2ACE 5CAE 3304