Generate a private key

Divide the private key into 3 shares using bitaddress.org - Split wallet method - ( I think Shamir's Secret Sharing method is used here )

Minimum share threshold needed to combine must be 2

This means if two out of the 3 shares of secret is available then the private key can be regenerated from any of the 2 out of 3 shares combined.

Share 1 = Bitcoin owners share

Share 2 = Community share

Share 3 = NOSTRKEY share

Make a specialised NOSTR Client to store and share the private key as described below.

This NOSTR client - Lets call it NOSTRKEY for now can generate a bitcoin private key and generate 3 shares for the key - NOSTRKEY client will have a NOSTR Private key and address.

In this NOSTR client the bitcoin owner can select any number of relatives/friends amongst his Multiple trusted people. Like it can be the spouse, nearest kins or friends.

Share 1 - One share of the key is kept with the owner himself or herself

Share 2 - One share of the key is kept with all the relatives/friends. This share is sent as a DM from the NOSTRKEY client to the friends and relatives etc and the share is encrypted using the friends NOSTR private key and send back as a DM to the NOSTRKEY client. So each of these

One share of the key is kept with the NOSTRKEY within NOSTR itself - The NOSTRKEY client encrypts the Share with its private key and send it as a DM to the Owner upon the key generation event.

The bitcoin owner can retrieve his private key from his own account at any time interacting with the NOSTRKEY client and combining share 1 and share 2

Suppose if the bitcoin owner lose his keys for any reason - Then he can request NOSTRKEY and any one of his friends/relatives to combine SHARE 2 and SHARE 3 to regenerate the Bitcoin Private Key

Suppose in the event of death of the owner one of the Friends or relative who is made the nominee can be transfered the bitcoin if the nominee makes a claim. In which case the SHARE 2 and SHARE 3 is combined to regenerate the private key. The nominees claim will have to be verified by 50% of the other friends and relatives added who are not nominees. So if there is one nominee and 2 friends added. then the nominee and one other friend should be making the claim

All the retrieval requests made by the friends or nominee is send to the the owner address and the regeneration event happens only after a delay of 7 days for the owner to cancel the retrieval request

The owner can retrieve the bitcoin instantly with SHARE 1 and SHARE 2

SHARE 3 can be used only with a 7 days delay on retrieval

Reply to this note

Please Login to reply.

Discussion

This is just an idea like Fedimint

How a NOSTR client and social media friends can help u in storing and retrieving the bitcoin even if u lost it.

What is Shamirs Secret Sharing Method used in BitAddress.org?

Using Shamirs Secret Sharing method u can split the bitcoin private key into any number of shares and u can define the minimum number of shares required to regenerate back the private key. U can see that this method is used in bitaddress.org Split Wallet

How to utilise this in a NOSTR Client?

The idea is to build a NOSTR client ( NOSTRKEY ) which can do the following.

Generate a bitcoin private key

Divide the private key into 3 shares using bitaddress.org - Split wallet method - ( I think Shamir's Secret Sharing method is used here )

Minimum share threshold needed to combine must be 2

This means if two out of the 3 shares of secret is available then the private key can be regenerated from any of the 2 out of 3 shares combined.

Share 1 = Bitcoin owners share

Share 2 = Community share

Share 3 = NOSTRKEY share

Share 1 is generated by NOSTRKEY and send to the Bitcoin Owner and it is encrypted by the Bitcoin owners NOSTRKEY client with the NOSTR Private key of the Bitcoin Owner

The bitcoin owner adds a nominee to his account and also few relatives or friends as his community in NOSTR

Share 2 is generated by NOSTRKEY and send to the nominee and the friends and encrypted by the respective NOSTRKEY clients using these individual friends NOSTR private key

Share 3 is encrypted with the NOSTRKEY main account private key ( There will be a NOSTRKEY account in NOSTR ) and then send as a DM to the bitcoin owners address

The bitcoin owner can retrieve his private key from his own account at any time interacting with the NOSTRKEY client and combining share 1 and share 2

Suppose if the bitcoin owner lose his keys for any reason - Then he can request NOSTRKEY and any one of his friends/relatives to combine SHARE 2 and SHARE 3 to regenerate the Bitcoin Private Key

Suppose in the event of death of the owner one of the Friends or relative who is made the nominee can be transfered the bitcoin if the nominee makes a claim. In which case the SHARE 2 and SHARE 3 is combined to regenerate the private key. The nominees claim will have to be verified by 50% of the other friends and relatives added who are not nominees So if there is one nominee and 2 friends added. then the nominee and one other friend should be making the claim

All the retrieval requests made by the friends or nominee is send to the the owner address and the regeneration event happens only after a delay of 7 days for the owner to cancel the retrieval request

The owner can retrieve the bitcoin instantly with SHARE 1 and SHARE 2

SHARE 3 can be used only with a 7 days delay on retrieval

write

preview

This is just an idea like Fedimint

How a NOSTR client and social media friends can help u in storing and retrieving the bitcoin even if u lost it.

What is Shamirs Secret Sharing Method used in BitAddress.org?

Using Shamirs Secret Sharing method u can split the bitcoin private key into any number of shares and u can define the minimum number of shares required to regenerate back the private key. U can see that this method is used in bitaddress.org Split Wallet

How to utilise this in a NOSTR Client?

The idea is to build a NOSTR client ( NOSTRKEY ) which can do the following.

Generate a bitcoin private key

Divide the private key into 3 shares using bitaddress.org - Split wallet method - ( I think Shamir's Secret Sharing method is used here )

Minimum share threshold needed to combine must be 2

This means if two out of the 3 shares of secret is available then the private key can be regenerated from any of the 2 out of 3 shares combined.

Share 1 = Bitcoin owners share

Share 2 = Community share

Share 3 = NOSTRKEY share

Share 1 is generated by NOSTRKEY and send to the Bitcoin Owner and it is encrypted by the Bitcoin owners NOSTRKEY client with the NOSTR Private key of the Bitcoin Owner

The bitcoin owner adds a nominee to his account and also few relatives or friends as his community in NOSTR

Share 2 is generated by NOSTRKEY and send to the nominee and the friends and encrypted by the respective NOSTRKEY clients using these individual friends NOSTR private key

Share 3 is encrypted with the NOSTRKEY main account private key ( There will be a NOSTRKEY account in NOSTR ) and then send as a DM to the bitcoin owners address

The bitcoin owner can retrieve his private key from his own account at any time interacting with the NOSTRKEY client and combining share 1 and share 2

Suppose if the bitcoin owner lose his keys for any reason - Then he can request NOSTRKEY and any one of his friends/relatives to combine SHARE 2 and SHARE 3 to regenerate the Bitcoin Private Key

Suppose in the event of death of the owner one of the Friends or relative who is made the nominee can be transfered the bitcoin if the nominee makes a claim. In which case the SHARE 2 and SHARE 3 is combined to regenerate the private key. The nominees claim will have to be verified by 50% of the other friends and relatives added who are not nominees So if there is one nominee and 2 friends added. then the nominee and one other friend should be making the claim

All the retrieval requests made by the friends or nominee is send to the the owner address and the regeneration event happens only after a delay of 7 days for the owner to cancel the retrieval request

The owner can retrieve the bitcoin instantly with SHARE 1 and SHARE 2

SHARE 3 can be used only with a 7 days delay on retrieval

write