For example, I send you the message "CIA" encrypted using this scheme. Theoretically, it should be impossible for any third party to prove that I send "CIA", because I can give up a different decryption key that decodes the ciphertext to, say, "NSA". Similarly, on the receiving end, you can give up a different decryption key that decodes the ciphertext to, say, "FBI".
This scheme also means it is impossible for a third party to discover who is giving up the 'truth' in such scenarios (for example if I told the truth and decrypted the ciphertext into "CIA", while you lied and decrypted the ciphertext into "FBI", the third party has no way to know which one is correct, or if either of them are fake).
Mono-deniable gives a duress code only to the sender, or only to the recipient.
The paper claims an additional category of bi-deniability, such that your duress code and your counterparty's duress code produce different plaintexts, rather than the same plaintext. It is unclear from the abstract whether it is possible to have a bi-deniable scheme without this property (which does not also require prior coordination between parties).
As others note, it parses as bi-deniable -- it can decrypt on both ends into two plaintexts with plausbility.
But yes, I initially parsed it as Biden-y-able, which is surprisingly fitting [1] given Biden's ability to get away with any gaffe[2], which is analogous to what bideniable encryption gets you. So, a good mnemonic at least...
(Relatedly, I used to think git reflog parsed as re-flog "because you're only using this if you did something so stupid you want to flog yourself twice".)
[1] I hate the word "apropos".
[2] https://www.theatlantic.com/politics/archive/2014/09/why-joe...