Good day, Keagan and all!

It's my deepest pleasure to announce the publication at Toptal's Technology Blog of an article on Formosa. There you will find a concise explanation on how it works. Since the system is, in fact, very simple --- and a special word of thank-you is due to Toptal's editing team and their extraordinary power of synthesis --- any IT professional can completely understand it in less than the indicated 10 minutes.

I avail to continue to make the case for it in the dissertative paragraph below. It is presented as an indented list to make references easier:

  1. Formosa uses simple, fixed grammatical structure of sentences; allowing for...
    1. easy implementation;
    2. customized themes;
    3. keeping legacy BIP39 properties; like 
      1. checksum bits;
      2.  uniformly high entropy density of entropy density; which allows for 
      3. efficient auto-complete; and, therefore, 
      4. resistance to side-channel attacks. Speaking of which, 
    4. Resistance to side-channel attack can be even further improved with an interface that destroys any connection between what is typed and the resulting seed. Notice (and a fully functioning prototype of it is already in place) that such an interface relieves the requirement for first two letter uniqueness in sublists of possible terms, which further increases the average quality of sentences.
  2. Bitcoin already is lost at a higher rate than it is mined. Consider the level of emotional pain of a non-technical individual who finally understands and adopts the premises of Bitcoin, and then puts up the work of going self-custodial, only to, some time later, undergo the Tantalian penalty of losing their patrimony, while knowing that it can still be traced in the Blockchain and can still hypothetically be recovered if, as, for example, in the case KBA, they relived the faded anxiety-arising memory of the seed word list 'just one more time'. Don't you agree that chances are this individual won't want to have Bitcoin ever again?

Some will, then, point out that KBA let's the tenant more vulnerable to wrench attack, and that is right. I'll then avail to mention that to the day, we lack defenses to coercion that don't violate Kerckhoff's principle by critically relying on obscurity. The only reason this is not yet a critical issue is we take for granted 3 passive defenses to coercion (also relying on obscurity):
  1. Obscurity per se: the 5-dollar wrench attacker has to know the basics of BTC before trying to rob it from someone;
  2. Anonymity: even an coercing adversary who does know how to use BTC has to spot a potential victim among a crowd of non-users;
  3. Plausible deniability: even when passing 1 and 2, a coercing adversary may be fooled by a credible denial by their victim;
By definition, those defenses tend to disappear with diffusion of knowledge, and impose a conflict of interest in our community and each BTC holder individually: collaborating for spread of adoption of BTC makes it use under self-custody less viable due to being more vulnerable to coercion.

My take on this is we should build a solution for coercion-resistance that is not reliant on obscurity. Also, assuming such solution is effective, it should have KBA as basis since threat of destruction of PBA hardware is a leverage that can be used by a coercing adversary.

Yuri S Villas Boas

------- Original Message -------
On Saturday, May 20th, 2023 at 1:08 AM, yurisvb@pm.me <yurisvb@pm.me> wrote:

Good day, Keagan and all!

First of all, thank you for your feedback! Yes, I made it so that Formosa does accomplish that: BIP39 is a particular case; a degenerate 'theme' in which you have sentences of just 11 bits (instead of 33 in a typical Formosa sentence), and they are made up of just one (11 bits) word with no syntactic structure. The sublist of possibilities for this one field does not impact and is not impacted by any other (because there is no other). Therefore it is rather a list (without 'sub') and it consists of the original BIP39 word list.

In addition to that, we make it so that themes (including BIP39) are convertible into one another. The conversion is straightforward: just map the words back into the array of bits that originated it and derive the new seed from it using the new theme. This is why I made sure to have sentences have a number of bits multiple of 11. Moreover, in order to enable forwards and backwards compatibility and facilitate adoption, we set the original BIP39 as standard for key derivation. Meaning: in order to derive keys from a seed, we first convert back to BIP39 and then proceed the KDF step as originally specified in BIP39. This way legacy addresses can be kept even if a user wants to choose a theme. Finally, as a bonus, one could argue that a hyper customization would allow for a(n additional, dispensable, non-critical) layer of obscurity (which, therefore, wouldn't violate Kerckhoff's principle). Example: consider, for example, that a one hyper-customized seed could be (just an extra tool) more easily stenographed in human speech or written text.

I hope this answers your objections concerning loss of standardization. Thank you for bringing about the issue of coercion resistance! Here is my response to that: a user willing to avoid the additional vulnerability to coercion that an effective brain wallet would ensue could just not put up the effort to memorize the seed for long term, and just take advantage of the easier transcription and checking (ie: short-term memorization). Right now I could anticipate a response in the lines of "Such a format might as well be so much easier to long-term memorize that a user either ends up doing that accidentally, and/or the denial of that becomes less plausible.". If that is the objection, well, thank you, and, however self-serving it is my saying it, I tend to agree that that would, in fact, be the case. My response to it is that:
  1. knowledge-based authentication, whether or not for Bitcoin, still have some properties that possession-based authentication doesn't. Whatever master password you memorize, in whatever context, you'd better have an efficient format, with uniformly high entropy density (and even possibly checksum), and not having to resort to a silly meme about a staple, a battery and a horse.
  2. Mitigating the shortcomings of KBA can arguably be done better with 2FA, instead of PBA. Having a superior format just as beneficial as before.
  3. Once again, thank you for bringing up coercion resistance! I'd like to point out to an elephant in the room: To this day, and to the best of my knowledge there is no scheme, protocol or ceremony that simultaneously achieves self-custody and coercion resistance with non-obscurity. IMHO this is an critical problem for various reasons and I'll be making a thread about it shortly.

Thank you again for your inputs and be my guest to further debate your points! I hope this could have been of help!

Faithfully yours, Yuri S VB.

------- Original Message -------
On Friday, May 19th, 2023 at 11:24 PM, Keagan McClelland <keagan.mcclelland@gmail.com> wrote:

Good day Yuri,

This is a very cool idea. After reviewing the repository it seems that there lacks a BIP style specification for this, so it is possible that some of my takeaways may not be correct but I figured I'd comment with some observations anyway. Feel free to correct me where I've made a mistake.

I think to make an idea like this work it would be necessary for it to "extend" BIP39 rather than "replace" it. What I mean by this is that BIP39 is heavily entrenched in the ecosystem and so in order for you to sidestep the need to get everyone in the ecosystem to adopt a new standard, you'd want this process to be able to output a standard BIP39 seed sequence. This becomes even more important when you allow these different "themes" that are mentioned later in the document. The notion of themes practically precludes the standardization of the technique since customization really is the antithesis of standardization.

The largest value proposition of these schemes is that it allows significant wallet interoperability. This is achieved if process for translating these phrases to the underlying wallet seed is deterministic. Themes may prove to make this harder to solve. I also do not believe that themes meaningfully increase the ability to remember the phrase: the fact that the phrase has a valid semantic at all is a massive step up from an undifferentiated sequence of words that is the current state of BIP39. The benefits afforded by the themes here are little by comparison.

Overall, I think exploring this idea further is a good idea. However, there may be concerns about whether the increased memorability is a good thing. It would certainly make $5 wrench attacks more viable, not less. I can't help but ask myself the question whether more Bitcoin is lost because of seed phrases not being memorized, or because of social engineering exercises used to scrape these phrases from the brains of users. I have a hunch that loss is a larger problem than theft, but it is a very real possibility that a wide deployment of this type of tech could change that.

Stay Inspired,
Keags

On Tue, May 2, 2023 at 6:05 AM Yuri S VB via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Dear colleagues,

The following is a password format that improves upon BIP39 by allowing meaningful, themed sentences with a regular grammatical structure instead of semantically disconnected words, while keeping the same entropy/checksum and total bits/non-repeating leading digits ratios (of 32/1 and 11/4 respectively).

https://github.com/Yuri-SVB/formosa

Anecdotal experiments suggest that less than one hour of moderate concentration is enough for long term memorization of 128 + 4 bits (equivalent to the 12 words standard of BIP39) if a theme of interest is employed.

I hereby offer it to your scrutiny as a Bitcoin Improvement Proposal. Please don't hesitate to ask whatever issue about the project there might be.

Faithfully yours, Yuri S VB.

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev