Topic: Heritage wallet and service - a new solution for on-chain inheritance (Read 236 times)

I'm happy to report that since release 0.6.0-beta of the Heritage Wallet CLI, you can control exactly which UTXO you want to spend using whitelist and/or blacklist or simply giving the exact list of outpoints you want to use.

Hi all,

Batch answer for everybody

No there is no multisig involved at the moment. Each script of the Taptree require a single signature, provided the timelocks are expired. For now, you can only tell "my wife first, then my first born, then my uncle, then [...]". I will introduce multisig at some point, see the first answer to hugeblack.

In principle, nothing prevents you to create the exact same wallets as the service by yourself. In fact, the Heritage wallet can be exported and if you were to try it you would find Bitcoin Descriptors with Miniscript expressions. You could then import those descriptors in Bitcoin Core and it would work as expected. The Heritage wallet can also be used independently of the service by the way. In that case, the only advantage will be that it is easier to express the Heritage Configuration object, which is then translated to Miniscript expressions by the wallet, than write said expressions yourself.
Using the service mainly give you the notifications that will remind you to reset the deadman switch (i.e. move your coins to new addresses with updated timelocks) and the notifications for your heirs. Also it will generate the PSBT for the heirs, which is not that easy without a third-party: the alternative is to make all your Descriptors available for your heirs... but you probably don't want to share that information with them while you are alive out of privacy concerns. Also, they may well not know what to do with the descriptors. You can see the service as a way to backup those descriptors and make PSBT available for your heirs to sign easily (or at least, easily-ish).



Right now, each heir get to spend ALL the bitcoins of the wallet in turn. You set the priority order by choosing the timelock duration of each (for example: 12 month for my backup wallet, 15 months for my wife, 18 months for my bro). So currently there can by no such problem as the one you describe... but you are right though: what if I want my (e.g.) 3 children to share the bitcoins equally among them? For now, I'm not sure of the solution.
I'm leaning toward a 3-3 multisig scheme, and I will introduce that possibility beginning of next year. And then we are back to your question. Maybe make it a 3-4 multisig with the service being the fourth, tasked with enforcing your will? Or a notary being the fourth? Maybe make it decaying? Honestly, all your inputs are welcome guys. I myself will never have child so...
Maybe covenants will provide a better way, but that's not for tomorrow and I did not dig too much for now.

As the first year is free, for now I did not even developed the payment processor
But the plan is to simply ask you to pay what you owe once a year to an address provided for the occasion. The yearly fee will be is your average balance throughout the year in BTC. My plan is that as long as your are not paying, you will only be able to export your wallet and go manage it elsewhere. Notifications will still be sent and heirs will still be able to generate/sign PSBT, but you will not be able to use the service if you don't pay for it.
What other details would you like to have about the service?

Quote from: hugeblack on October 14, 2024, 01:30:48 AM

What happens if the heritage-cli doesn't work (actually I can't access the code at the moment, maybe there is a problem).

I don't see what would prevent you to see the code, I can confirm it's a public Github repo. Maybe you have Internet connection issues of some sort?
Regarding the heritage-cli issue, if you think the CLI is at fault, email me as much details as you can at [email protected] and I will try to understand. Also it is in Rust, so if you launch it with

Code:

RUST_LOG=debug

env. var, it will become very verbose.

In principle, if the heritage-cli does not work, then... well. I will have to correct it. In the mean-time you should always be able to revert to the previous version. I don't see how I could messed-up the database of the service, but after all shit happens even at Google so I guess keep your own backups if you want to be extra safe.
A large part of my own holdings are managed by that service and CLI, so believe me I'm extremely motivated to keep it working

Seems like a good service but it doesn't solve the inheritance problem, the heirs still need to agree to spend, what happens if there are 4 heirs and 2 of them don't agree on spending the heir's money or on each of their shares, or can you set custom conditions like the possibility of spending a portion of the UTXO representing each heir's share of the wallet?

Can you add more details about the online service and how the fees will be deducted?

What happens if the heritage-cli doesn't work (actually I can't access the code at the moment, maybe there is a problem).

Otherwise it seems like a good service, will bookmark it.

So your heritage  plot relies on   multisig decaying  scheme, is this correct?

Another question. Bitcoin Core is known to support Miniscript notations when constructing complicated descriptors including multisig ones thus ^{(in my view)} someone ^{(who would be interested to utilize multisig decaying for his heritage plan)} could  build relevant descriptor ^{(like this one tr(InternalKey,thresh(3,pk(Key1),s:pk(Key2),s:pk(Key3),snl:after(Timelock1),snl:after(Timelock2)))} and import it to Botcoin Core. Correct me If I'm wrong, if not,  what is advantage of you approach compared with this?

I see. It wasn't clear since i only found text "Sent to self" on one of the screenshot.


IMO it's somewhat important since,
1. Your software/service generate HD wallet.
2. Currently your software/service mainly attract enthusiast or geek who usually also pay attention to their privacy.


It's more complicated than i initially thought. But i expect few user would appreciate having choice between saving fee or preserve privacy.

That's understandable. If you plan to market this product to the average joe the explanation needs to be as simple as possible to attract their interest. It's hard to sell a product if people don't understand it unless you're fine with being niche.

Yeah, I can see why they don't put that on their priority list. Hopefully, it will come sooner than later.

For now I clarified that there is a challenge due to HW devices limitations, explaining in more details require to establish a lot of base knowledge. I will probably do it in video in the next months.

Eventually they will all have to come around. After all, Taproot is not going anywhere so they are bound to propose something. But in the Trezor case, you can see on the Github Issue that it did not move for years. And I can confirm that currently the Trezor communication protocol with the firmware is unable to handle Taproot scripts: the signature request simply lacks the required fields. Long story short, Trezor support is not for tomorrow 

My pleasure. Though I will admit I'm developing this alone for a year now so I need external feedback badly  

I browse the list, only Liana is comparable to what I do, i.e. on-chain dead-man switch. I'm not sure how the others operate, but the fact that they can propose "No need" or "Enter PIN" as Timelock Refresh Method makes it clear that it is not on-chain and therefor not that non-custodian.

I'm voluntarily trying to not make any reference to FIAT. That being said, your feedback is noted.

No. As my service does not handle the funds or allow to switch between FIAT and BTC, I don't believe I need to adhere to any KYC process. I may be proved wrong in the future, but that's not a concern for me any time soon. You are free to use any email you want, but there will be an email verification process with a code.

The limitation is more implicit: I don't believe someone with less than 0.5btc could possibly be interested in doing something as advanced as what I propose. I'm doing all I can to make it easier, but using advanced Bitcoin Scripts comes with a lot of constraints and challenges. I'm personally willing to go through them because I strongly believe in the cipher-punk philosophy underlying Bitcoin and I really get a kick knowing I have a perfect setup allowing me full-control over my coins AND the possibility of backup access and transmission. I believe there are others like me and hope they will find value in my service, but I have no illusion that I'm talking about no more than a few thousands people worldwide.

You are partially correct.
There are of course change addresses. They are generated on the fly when you request a PSBT. All very standard, they are derived from the appropriate BIP32 derivation path, separated from the "main" derivation path.
But for now there is no control over the UTXO that are included in the TX. I don't exclude to add more feature on that front, but tbh it's not a short term roadmap item. Do you think it is important?

What I have in mind on the front of PSBT creation is more related to the privacy challenges that poses the deadman switch approach. Consider the situation where the dead-man switch is about to expire: you have to reset it by moving coins on freshly created addresses with updated timelocks. But when you do that, you consume all your UTXO in one transaction, which creates an obvious link between all the previous addresses. Which means that anyone that have sent you coins before may be able to know your balance. Which is bad. And not that simple to solve.
What I will end-up proposing is a way to create multiple PSBT (in the most extreme form, one PSBT for each of your UTXO) that you can sign and then the service would broadcast them randomly over some amount of time. That will mitigate the problem, but of course the total fee paid will be higher than with a single TX.

I'm not interested to try your wallet/service. But i must admit that amount of details you shared is impressive compared with most new wallet/services. Anyway, here are some of my thoughts and questions.
1. Are you are of existence of similar inheritance software or service? https://thebitcoinhole.com/inheritance list 7 of such software/service, where 6 of them seems to be non-custodial.
2. Regarding minimum amount when using your service, IMO specifying certain fiat value (e.g. $30/year) is more user-friendly than saying 0.5 mBTC/year.
3. Are there any limitation of who can register/use your service? Do you allow anonymous registration (e.g. using VPN and email address belong to privacy email services)?
4. Looking at guide to send Bitcoin on https://btcherit.com/docs/send-and-receive, it seems there's no feature to choose UTXO and no mention of any change address. Is my understanding correct?

Thanks for the reply, although I can't verify most of them right now since I don't have the technical knowledge for that. It would be a good idea to post that explanation on your website IMO.

According to the GitHub link, it seems like there might be similar implementations for Trezor or other wallets in the future. If I do want to try your service I'm willing to suffer through the burdensome process or wait until other wallets support your required scripts.

Thanks for the feedback, I updated the doc to clarify that I recommend using a hardware wallet, not especially Ledger over others. But it happens that Ledger devices are currently the only one that can work with Taproot scripts as far as I know.

Please correct me if you believe me wrong, I would be happy to add support for more HW products.

As far as I know, Ledger HW are the only ones capable of signing transactions with Taproot UTXO if the descriptor contains scripts, i.e. For example, Trezor advertise support for Taproot, but that only works for descriptors without scripts, i.e. and they do not plan to support more anytime soon[1].

As the Heritage wallet rely on Taproot scripts, Ledger is simply the only HW that is able to sign transactions generated by the wallet to the best of my knowledge.
I believe Coldcard is in the process of upgrading their firmware to support Taproot signing, so it may become supported if, like Ledger, they plan on supporting any descriptors and not only simple ones or standard multisig.

Sorry about that, I'm yet to write this blog-post.

I can highlight the big idea though: if you do not use a Ledger HW, then it means your seed is stored on your computer (unless you know of another HW that support Taproot signing, then I would be happy to support it). So if you don't want your seed to "touch" the Internet, that means your computer should be air-gaped. Then it means that when you need to sign a transaction, you will have to copy a PSBT back and forth, probably using a USB stick. The Heritage service and wallet support doing so of course, but that's a big hit on usability.
Using a HW allows a simpler signature process because the wallet software can be connected to the Internet and take care of retrieving the PSBT, ask the HW to sign it and then broadcast it.
That is what this schema describe:
https://btcherit.com/docs/why-heritage#fnref7

So currently, there are 3 main setups you could use with the service:
1. seed on an air-gaped computer => very secure, but burdensome to use because you need to copy PSBT back and forth each time you want to send bitcoins: for example, generate the PSBT from the service website, then copy it to your air-gaped computer to sign it, then copy it back for broadcast (if you are a very advanced user, you could make this setup easier using QubesOS[2][3], that was actually my setup for years);
2. seed on a computer connected to the network => less secure, but sending bitcoins is easy as the wallet can generate, sign and broadcast the transaction in one go;
3. seed on a hardware-wallet device => very secure, yet sending bitcoins is easy because the Heritage wallet can still generate the PSBT, ask the HW to sign it and broadcast the transaction in one go;
That is the compromise I had in mind when I wrote the tutorial. Does that make sense?


[1] https://github.com/trezor/trezor-firmware/issues/2258
[2] https://www.qubes-os.org/
[3] https://forum.qubes-os.org/t/how-to-set-up-a-split-bitcoin-wallet/19017

Is there any specific reason why Ledger is suggested here? I checked your website and it doesn't mention any details on the compromise you've mentioned here[1]. I don't think Ledger is a good choice for an HW after their recent updates, why not suggest other wallets or air-gapped devices? I'm surprised you also mentioned that using other wallets would lower the security of the setup.

[1] https://btcherit.com/docs/create-wallet

I'll assume you are fairly familiar with Taproot high-level principle, mainly key path spend vs script path spend.

On the pure Bitcoin front, the wallet works with a deadman-switch: you set Taproot scripts spend-path, each corresponding to one of your heirs, each with a timelock you decide. As the owner, you use the key spend-path anytime you want. In order to reset the deadman switch, you just spend your coins, thus moving them on a new address with updated timelocks. If you cannot spend using the key path, for whatever reason, then the timelocks of the scripts spend-path will expire and allow your heirs to spend. More on that in https://btcherit.com/docs/why-heritage

Note that it also works as a backup access solution if you lose your "main" keys: you create a backup wallet and use it as your first heir (does it answer your point on preventing loss, or did I misunderstood?).

The service does not hold any private key, in that sense it is non custodian: it has no way of spending the funds. If you use the service, it will store the Bitcoin Descriptors of your wallet, i.e. all the inheritance configurations you created. As such, the service knows exactly what are your addresses, what funds they currently hold and at what point in time the alternative script spending paths will open. Using these informations, the service knows when it needs to start urging you to reset the deadman switch (currently 30days before the first script spending-path opens). If you don't do so and a script spending path opens, then it notifies the corresponding heir, then the next, then the next, ...
The service currently notifies by email only, but at some point it could also use phone numbers for examples. Of course, you are providing the contact infos of your heirs to that effect.

If one of your heirs register with the service using an email address you declared for them, they will see their inheritance (provided their corresponding script path is open, else they don't see anything). The service will be able to generate the appropriate unsigned transaction so that they can claim the coins. It is expected that they have the corresponding seed/wallet in order to sign it. Currently, without a wallet GUI, it may be unrealistic to expect a non-technical heir to retrieve the coins using only the CLI, even with the doc available. That's why I'm currently developing one.

What the service offers is mainly two things:
 - Track and remember your Descriptors, so it can generates the appropriate unsigned-tx when needed;
 - Track coins and timelocks in order to notify owners and heirs appropriately.
It does not cost anything to fiddle around in the web interface if you want to, it may gives you a better idea of the expected usage.

Here is how I used the service: I have 3 heirs, 1 backup wallet and two relatives. For each heir (including my backup), I generated a mnemonic and wrote it in sealed enveloppes that I gave to them. I made it so they can visually verify the enveloppe has not been opened.
In the service, I declared each heir using an Extended Public Key derived from each mnemonic and I arranged them in the order and with the delays I wanted.
If at some point one of my heir lost their envelope, or think it may have been compromised, I can just make a new one and update my inheritance configuration.

For now that's it, and I have ideas to make it better:
 - possibility for a user of the service to publicly provide an extended public key, so that others can easily reference them as heir.
 - notification of the owners if an heir signal their mnemonic has been compromised.

I don't really know if I'm clear, sorry if not, please keep poking me

EDIT: More direct answer to your questions:
This reply and https://btcherit.com/docs/why-heritage should be informative, please come back with more questions if you have some.

You declare your heirs in the service with, basically, an Extended Public Key and email address(es). The service knows when the timelocks expire and notify the corresponding heir by email when that happen. In the future, SMS notifications, phone calls, postal mail or even in-person are on the table, but for now its only email (i.e. the cheapest). Please tell me if you have requests on this topic.

The service DO NOT touch your private keys. That remains you and your heirs responsibility. But when using Bitcoin scripts, there is another challenge: not loosing the scripts. It is especially important with Taproot. As an heir, you need to know your exact script, and all the intermediate values of the Taptree MAST in order to recompute the TapTweak correctly if you want to spend, having only your private key to sign the transaction is far from enough. The service is there to abstract that away: as an heir, you will receive a PSBT that contains the information you need, nothing more. In particular, an heir may not know how many other heirs exist or who they are.
At some point in the future, the service may provide a "just send me bitcoins" way of inheriting, by asking the heir to provide their mnemonic and a destination address. But I think doing so now would send mixed messages so I will not do it in the foreseeable future. I remember to well the shit-storm Ledger took when they proposed their backup solution, for now I prefer to go with "the service does not touch private keys, ever".
Let me know your toughts!

See the end of my reply about my setup with 3 heirs.
Also, the Heritage wallet creation tutorial (https://btcherit.com/docs/create-wallet) is in fact exactly my setup. Please tell me if you want to know more.

Can you give more information about this and how it works or expected to work?
By what means will notifications be sent and how will recipients of the notification be set up?

If the wallet is to be completely non custodian, how do you plan to facilitate inheritance? This has been keenly discussed on this forum and I'll like to hear your own strategy to prevent loss.

Hello there,

I created a non-custodial inheritance wallet/service for Bitcoin that is called the "Heritage wallet" (because I'm french and that's the french word for inheritance).
The wallet is Taproot-enabled, fully written in Rust and open-source under the MIT license, the service is based on the open-source libraries with additional closed-source code.

The service can be found here: https://btcherit.com/
The wallet itself here: https://github.com/crypto7world/heritage-cli
The libs underlying everything here: https://github.com/crypto7world/btc-heritage

The service and wallet are in beta-phase. I'm personally using it since February 2024 to manage my holdings and I'm now looking for external feedback.
I'm in the process of developing a GUI for the wallet, but right now it is only a CLI so be advised that it is only suitable for tech-savy users and should not be used by beginners.

If you are looking for a rational on why the service was created, I wrote a blog post: https://btcherit.com/docs/why-heritage
I will be happy to take questions and remarks, that's why I'm posting.

The wallet software is there mainly to manage private keys, including with a Ledger device (which is advised). It can also manage synchronizations, broadcasts and everything else on its own if you provide it with a BitcoinCore or Electrum node, but usually you will want to use the service for this (of course, the wallet can communicate with it).
The service goal is to simplify the management of heirs and inheritances, mainly by sending notifications to both owners and heirs, backuping descriptors so they are never lost and providing synchronization/broadcast with its internal Bitcoin nodes.

The wallet is free to use, the service will be billed at 0.05% of holdings per year, with a minimum (note that the exact amounts can still be discussed).

Please feel free to provide any comment you may have!