Would this be a realistic BIP?

[miky55]

I don't know if my idea is stupid, realistic or have already been sugested, I checked the bip list and found some related propositions like this one: BIP: 68

Motivation: Preventing unlegitimate transaction from a compromised bitcoin wallet whatever if it is cold or hot wallet

So the idea is to submit a contract with in parameters: A1:owner public address, RTL:relative time lock(probably in days) and A2:failover address (could be third party escrow or another owner address not related to the same seed)

Any outcoming transaction from A1 will be rejected by the network until an empty transaction would be brodcasted with OP_RETURN message "unlock" , any outcoming transaction between the "unlock" + RTL will also be rejected

In this lock period only transactions to A2 would be allowed


I hope you understand what I have in mind: people often write there hardware wallets mnemonic on paper and it could be compromised without they know it, adding a relative time lock will alow owner to secure there funds to another secure place once it has been compromised.

Of course I suppose it have to be part of hardfork since all the network has to implement it to be functional.

Thanks for reading, hope it wasn't so silly idea

[Quickseller]

A more simple solution would be to use multi sig, which is basically what you are proposing, except in a round about way.

[miky55]

A more simple solution would be to use multi sig, which is basically what you are proposing, except in a round about way.

I think this is not exactly for the same purpose, multisig is not as simple to use for not power user or big entity imo, it has some pitfalls (https://medium.com/shiftcrypto/the-pitfalls-of-multisig-when-using-hardware-wallets-9b0e98e4c19c)
With my solution the user will have to carry only his main key, the failover will be use only in emergency cases.

But I already see a weakness with this that could be exploit: the bad guy could also see there is a contract and monitor the "unlock" message and could be the first to boradcast after the locktime.

That's why I imagine another better solution. The contact could remain the same but instaead of using a message to unock, any outcoming transaction will be delayed between the  broadcast to broadcast + RTL. In the same period only transactions to the failover adress will be imediatly processed.

[bitmover]

So the idea is to submit a contract with in parameters: A1:owner public address, RTL:relative time lock(probably in days) and A2:failover address (could be third party escrow or another owner address not related to the same seed)
...

I hope you understand what I have in mind: people often write there hardware wallets mnemonic on paper and it could be compromised without they know it, adding a relative time lock will alow owner to secure there funds to another secure place once it has been compromised.

Of course I suppose it have to be part of hardfork since all the network has to implement it to be functional.

Thanks for reading, hope it wasn't so silly idea

I don't think the idea is silly. The thing is, you are suggesting people to store 2 seeds instead of one with this failover address.
If people lack responsibility to store one seed, they will just store 2 seeds together.

You can split your seed, use a mnemonic phrase, etc to increase security.

[goatpig]

I dont see how this is different from a CLTV setup tbh.

[miky55]

I don't think the idea is silly. The thing is, you are suggesting people to store 2 seeds instead of one with this failover address.
If people lack responsibility to store one seed, they will just store 2 seeds together.

You can split your seed, use a mnemonic phrase, etc to increase security.

Like I explain in my last answer, it is pretty different from using a multisig wallet since one key is enought for most use, the second one will be only for emergency cases. For example the main one could be even use with hot wallet and the second one stored in much safer place or even escrow service.

I dont see how this is different from a CLTV setup tbh.

I am not, an expert, could you explain me what a CLTV setup is please?

[goatpig]

CLTV == CheckLockTimeVerify

Let's you lock a script until a certain amount of time/blocks has passed. You'd build a script with OP_IF around that, with a primary multisig branch that can spend the coins with n-of-m sigs, and a second branch that unlocks after some time that invalidates the first branch and let's you spend from a singlesig script which would be your long term backup key.

You can use convoluted key/paper backup distributions for the primary branch with the knowledge that if you mess up you can spend your coins from the backup key in the future. Since there's no risk of blackholing your coins if you lose too many of the multisig keys, you can go afford to risk destroying them.

It has the same basic design as what you are proposing: stringent security requirements at first, lose backup sometimes in the future.

[miky55]

CLTV == CheckLockTimeVerify

Indeed, it seems to be the closest to my idea, if I understand you can spend the funds with only one key with ntimelock to be proceed ans multisig to be instantly.

How can it be setup? is it easy to use for not power user? Once setup the single sig transaction could be braodcast from any software or hardwre wallet?

[goatpig]

Indeed, it seems to be the closest to my idea, if I understand you can spend the funds with only one key with ntimelock to be proceed ans multisig to be instantly.

Basically, in pseudo code:

Code:

if (CLTV conditions not met)
    this script is valid
else 
    that other script is valid

The scripts can be anything you can think of. OP_IF has been around since the begining, OP_CLTV is "kinda" new, one of the most recent added op codes, and it allows you to evaluate either the block height or block time.

How can it be setup? is it easy to use for not power user?

Need a wallet that implements that scheme for you basically, unless you're looking to implement that stuff yourself. Depending the wallet's GUI, it may be very simple to do, or not. There were some talks of timelock setups a few years back, you'd have to unearth the threads.

Once setup the single sig transaction could be braodcast from any software or hardwre wallet?

You still need to provide the underlying script (these are p2sh/p2wsh nested constructs typically), so you're likely tied to the wallet unless you know your way around Bitcoin's scripting language. Hardware wallets usually can't spend from scripts they have not built themselves.