Yes, you need to use the QR code scanner on the website, or you need to manually decode the bytes in the QR code using descriptor-codec.

Fixed! Thanks for pointing that out.

Makes sense. Thanks for the response!

I do think there is a distinction between a protocol with off chain data vs. one that is completely onchain + an open source indexer. With the latter, at least, I wouldn't have to worry about the transaction history disappearing. Nor would I have to constantly interact with a centralized issuer in order to publish my transactions and verify other's balances.

If the functionality to "disavow" or freeze and unfreeze addresses is the chief concern (which I understand it is), it seems like that can be accomplished by tweaking a protocol like runes to allow the issuer to freeze and unfreeze addresses in an in-protocol manner. All the data would still be onchain, so there would be no risk of data getting lost, and it would be easy for others to sync and verify.

I'd be curious to learn why the Lightning Labs team elected not to go down this route.

Of course not. In all monetary systems that exist at present, the purchasing power of the economy's money does not come close to the economy's total wealth. As you say in your posts, and to parrot Benjamin Graham, price is not value. Price is simply what someone is willing to pay at the margin. Unless you take a long-term perspective, where the market is a true weighing machine, prices do not necessarily reflect fundamental value.

The point of this post is to demonstrate how and why bitcoin can self-regulate an economy under a bitcoin standard. Previously, I thought that in a hyperbitcoinized economy, bitcoin will become more valuable relative to all other assets during times of crisis, and less valuable relative to other assets when the economy overheats. The result would be that bitcoin debts become harder to service during times of crisis and easier to service when the economy overheats.

If, however, bitcoin is valued at the maximum extent possible, at parity with all other assets, it will always have the same value relative to total wealth, and it can never become more valuable on a relative basis, even during a crisis. This leads to counter-cyclical price signals that promote economic stability.

No money has ever been valued at parity with all other assets before. Bitcoin certainly is not valued that way today, but there is nothing to prevent it from being valued that way in the future. This post tries to show why bitcoin can be a stabilizing unit of account under the premise that it is a constant fraction of total wealth, but this can only be achieved if bitcoin cannot become more valuable on a relative basis. Hence the assumption that a hyperbitcoinized economy maximizes bitcoin's relative value.

What is the maximum purchasing power of bitcoin in aggregate? The total sum of all assets in the economy. That is what I'm calling total real wealth.

If the purchasing power of bitcoin in aggregate is total real wealth, a unit of bitcoin always purchases the same fraction of total wealth in the economy.

What that means is that the price of an asset stays the same if and only if it's value relative to all other assets stays the same. If an asset becomes less valuable relative to all other assets, its price goes down. Conversely, if an asset becomes more valuable relative to everything else, its price goes up.

Hope that helps!

Thanks!

Yes! Every possible pair of fingerprints is hashed and appended to the encrypted data. That way you can easily find it with any pair of seeds, without exposing the master fingerprints onchain.

The goal of this project is to eliminate the need for the average user to do anything beyond backing up their seeds. You can certainly put the descriptor on Nextcloud or a hosted cloud provider, but you're creating unnecessary risk. If the data gets purged, or if you die and your heirs don't know how to access it, your funds could be lost.

A 2-of-3 multisig should be recoverable with only 2 seeds - anything else is an added liability.

Nostr relays can't guarantee data availability, unfortunately. You can broadcast to multiple relays to improve redundancy, but relays can purge data at any time, or go offline completely. Inscribing the data on Bitcoin solves this problem.

Thanks for the support. I see this first and foremost as a solution to a UX problem. A whole ecosystem already exists guiding users through the process of creating and backing up seeds, either on paper or on metal. Asking an already cautious user to back up additional data offline doesn't make for the best user experience and adds additional risk, where none needs to exist. Why go through the hassle when your descriptor can be inscribed once and forgotten about? A third party provider could even do this behind the scenes during setup, making for a more seamless user experience.

People are rightfully weary of applications that involve inscribing data on Bitcoin, either because they congest the network or because they get priced out when fee rates go up. In this case, the data is directly related to the security of user's funds, and the actual amount of data is small. The cost of inscribing is the same as making ~4 taproot transactions, so if you can afford a multisig, you can probably afford to inscribe your descriptor.

I should clarify that the data is inscribed in a taproot witness, not in a OP_RETURN output. The difference is minor, since I create the reveal transaction with a single OP_RETURN output, which avoids bloating the UTXO set. Meanwhile, we benefit from the witness discount and avoid the 80 byte OP_RETURN limit.

I wasn't familiar with opreturnbot.com before - thanks for sharing! Looking at it, I'd say the general idea is the same, except the message is stored in a taproot inscription rather than in a OP_RETURN output, so you're not limited to 80 characters.

Two other minor differences:

Hope this helps!

Take a look at https://offline.cash. I haven't used them, but from my understanding, they ship multisig notes where one key is encrypted by the manufacturer and one key is provided by the first holder, who loads the funds. To claim the funds, you have to cut the note to access the manufacturer key and then ping their server to decrypt it.

Can't attest to the security of this setup but might be worth looking into.

A good consumer product does not require human onboarding.

The consumer downloads the app, and the rest should be seamless and intuitive to follow, walking the user through the onboarding process step by step in a way that does not require outside human intervention.

You’re correct that this application could tell the user to send funds to an address, and then once received, to transfer those funds to a multisig output. But that’s not intuitively how a vault should work. It shouldn’t require a special application to move funds into, with an intermediate location before they can be moved.

The consumer is taught that funds are stored at addresses. This is analogous to bank accounts and easy for the consumer to pick up. Why break that analogy if we don’t need to?