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 

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, 

5.  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 

3.  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, <> 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 
> <> 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 
> > <> 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).
> > > 

> > >
> > > 

> > > 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
> > >
> > >

Attachment: publickey - - 0x535F445D.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature

bitcoin-dev mailing list

Reply via email to