Proposal for a new intern project

[grunch]

Morí

Death is something uncomfortable, usually our death is not something we want to talk about, much less in our youth, but as Bitcoiners we have to prepare our funds for that day that will inevitably come.

This project proposes a way that a btc owner can leave his bitcoins to his heirs in the event of death in a decentralized way and with the least possible complication.

The main characteristic of this proposal is that the heirs can recover the funds in the event of death but CANNOT access the funds while the btc owner lives.

Not knowing when we are going to die is what adds complexity to the matter.

As a Bitcoiner and custodians of our privacy, we need to remove the trusted third party whenever possible.

Bitcoin script allows us to carry out a method so that the heirs cannot access while the btc owner is alive, but they will after his death.

How?

We will call the btc owner Alice and the heir we will call Bob:

1. Alice generates a new private key for refund.
2. Alice creates another private key, Bob's private key, so that Bob can spend the btc after the delay of N blocks
3. Alicia gives the private key to Bob or to someone else, that other person will give the private key to Bob after Alicia's death.
4. Alice sends the funds that she is going to inherit Bob to a p2wsh address, the funds can be spent as follows:

Option 1: Alice can spend the funds at any time with the refund key
Option 2: Bob can spend the funds after N blocks have been mined

The script would be something like this:

OP_IF
    <alice_refund_pubkey>
OP_ELSE
    <bob_delay>
    OP_CHECKSEQUENCEVERIFY
    OP_DROP
    <bob_pubkey>
OP_ENDIF
OP_CHECKSIG

Example

Alice set bob_delay = 500,000 blocks, the current height is 700,000, Alice can spend the UTXO with the funds at any time, probably when the current block is reaching 1,200,000 Alice will want to spend those funds and sending them again to another address generated by this system and add another 500,000 more blocks, now Bob have to wait for the block height to 1,700,000 to be able to spend the UTXO.

If Alice does not spend the funds on the next 500,000 blocks, she is probably death and these funds can be spent by a transaction signed by Bob.

The language to use is Rust

Before start

• Research about miniscript which looks like the best way to do this kind of scripts.
• Test output descriptors compatibility between hardware wallets (trezor with hwi), other software wallets and bdk.

Milestones

• 2021-07-15: Rust CLI Bitcoin basic wallet.
  • 2021-07-07: Code a bitcoin wallet.
    • It should interact with the blockchain through a hardcoded electrum server address.
    • It should have a way of data persistence.
  • 2021-07-22: The wallet can create a random private key or work with a descriptor.
    • It should show balance and receive.
    • It should generate a psbt to be signed on a hardware wallet.
    • It should sign the psbt if the wallet have the private key.
    • It should broadcast the transaction.
• 2021-08-15: Have a CLI wallet that incorporate time-locks on the accounts.
  • 2021-07-30: Add miniscripts support.
    • This interferes with the behaviour until now, there are some things to refactor.
    • When the user add the beneficiary the system creates new accounts for receiving addresses and change addresses.
  • 2021-08-15: Testing the wallet
    • Look for bugs and fix them
    • Use descriptors from bitcoin-cli, hardware wallets, to find compatibility issues

Improvements:

Allow inherited multiples, multisig
Use Taproot / MAST to make transactions cheaper, more private and more fungible.

** Other related ideas: **
It would be very practical if current wallets add this option, that way it does not matter when the owner of btc do the inheritance plan, all his UTXOs are going to have this timelock to be spend by the heirs. Maybe doing a spec, makes it easier for current wallets to implement this.

[shannona]

Sounds like a great project, and it's actually something that we're considering right now. There are two main roadblocks.

1.) Figuring out the right balance of having the blockheight sufficiently far out. We don't necessarily need to put it so far out that the person is likely dead. In fact, that can introduce issues if the length is too far out, because the person could die, then there could be an attack on some Core cryptography, and if the funds can't be recovered within a few months, the cash is gone via another means. So what's likely needed is an ever-updating set of timelocks, sweeping the funds forward before each comes due. That might be 6 months out or a year, but more than that and we start hitting that danger.

2.) Miniscript is exactly the way to do this sort of work because it has full functionality for timelocks built-in, and that's going to make it really easy to build into addresses once the Bitcoin Core/miniscript integration is complete, which I'm hoping we'll see within the next year. Unfortunately right now you can't build descriptor-based accounts off of them ... except with the Rust-miniscript library, so that means that your proposal for the project has a lot of value as the only rational way to do this right now. It could be a great exemplar.

Chris & I have started working on a document for this. It's here:
https://hackmd.io/1roaXXS-TNWydh2BRsEdAw

It's a rough draft; I haven't even done a full edit yet. It's not necessarily our complete thoughts on the topic. But it talks about timelocks as you're suggesting, describes the miniscript, and talks about sweeping options. I think you'll find it helpful for moving forward.

[shannona]

My other general question is what form the project will take. Library? Command-line tool? Sample code? Address Generator?

Fundamentally, our main goal is to propose methodologies that create a high level of responsible key management and offer them to other developers, so the question would be, what will be more likely to do so.

[grunch]

Hi Shannon, thanks for taking the time to review this proposal, it's a happy coincidence that you are researching this topic at this precise moment.

I agree with you about figuring the balance having the blockheight far out, that was something I didn't considered and I'm glad you mention it. I'm not sure if is a real threat the possibility of an attack to some core cryptography but to be fair, we don't really know and makes sense to be open to that possibility, also there is a possibiltiy that quantum computation change some things in the future.

I've been studying miniscript last days and yes it looks like the perfect solution for this, and BDK rust library works like a charm.

I read your document about timelocks, there is a lot of interesting info about this same topic but still don't get how to sweep funds progressively, also I get confused when you talk about accounts, I find it more specific to talk about UTXO and spent output.

The idea of Morí is to have at first a CLI tool, cause this way non developers can use it independently, just following the readme instructions.

[shannona]

1. ACCOUNTS. Here's the definition from our multisig article: "Account. A sequential list of addresses that have state in the form of transactions that can be summed into a balance. An account is not the same thing as a wallet: a wallet is an application, while an account is a holder of value." It has a lot of our current terminology: https://github.com/BlockchainCommons/Gordian/blob/master/Docs/Multisig.md#appendix-v-functional-multisig-terms

Our fundamental example of an account is traditionally, what's been called an "HD Wallet", or more recently, what's been called a "Descriptor Wallet". In other words, an account is where people will be generating lots of different addresses from a seed to maintain their pseudonymity. The best solution for timelock custody is if we can protect all of those addresses rather than individual UTXOs. I believe we should be able to do that by creating "descriptor wallets"/accounts using miniscript and BDK to incorporate timelocks, then deriving addresses from that script, but it's untested at the moment and only possible in minisig-rust or BDK, not in bitcoin-cli.

2.) SWEEPING FUNDS PROGRESSIVELY. The fundamental idea is that it's costly to sweep funds. It's been very costly at some points in the previous few years. So we'd love to never sweep funds. To accomplish this, we always have two timelocked accounts, one with the timelock 0-6 months out and the next with the timelock usually 7-12 months out. Whenever we spend funds from either account, the change goes into account #2. Eventually we either empty account #1 or we're forced to sweep it into #2 because the timelock of account #1 is fast approaching. We then create an account #3 that has a timelock which is preferably six months out from account #2, but never any more than 12 months total out. We then continue the process with accounts #2 and #3.

3.) CLI TOOL. Sounds like a solid choice to me, as it can be a reference, an example, and a tool.

4.) THE THREAT OF CORE COMPROMISES. Yeah, it's unclear how big of a threat it is, but it is clear that the threat increasing the longer the span of time is, so we just need to find a compromise on how long to use timelocks that's relatively constrained (but not so short as to be annoying)

[grunch]

Great I get it now, the sweeping funds progressively is the same thing I had in mind to sweep funds but still is expensive, what do you think about using taproot/MAST to make this more fungible, private and cheap? do you think that would add too much complexity to this project?

We will have taproot on November 😄

There are already taproot libraries on rust? I must say that I have no idea on how to work with MAST but I find it a very fun project to learn and be working on.

[shannona]

It does look like Taproot is likely to get locked in over the next few weeks.

Personally, I'd love to see something as cutting-edge as Taproot, but I'd be concerned it might be too much for the project's first cut. Maybe @ChristopherA has an opinion?

[ChristopherA]

We should ask around the bitcoin-core folks what the status of miniscript based descriptors in bitcoin-core might be. Sooner because it is really useful with taproot? Or later as we'll be preoccupied implementing the rest of taproot and musig 2?