Bitcoin Forum
July 19, 2019, 09:59:00 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: Dead man's switch  (Read 775 times)
mixoftix
Member
**
Offline Offline

Activity: 104
Merit: 145

..


View Profile WWW
November 15, 2018, 11:01:44 PM
 #21


use Multisignature Application in 1-of-2 method..

This is just as good as giving the other person your private key right now.

Well, look at the responsibility of involved people in both solutions. in multisignature you could engage your attorney in the process and he/she never could spend your money with his/her secondary account without your permission on contract. if you give the other person your only private key, you will lose the advantages of non-repudiation that comes with asymmetric encryption.

I think you are thinking of 2-of-2 multisig, not 1-of-2.
1-of-2 means that either of the keys can unlock the funds.

1-of-n multisig transactions are equivalent to sharing your private key with n people, as anyone can spend it.

2-of-2 multisig wouldn't work here though, unless you want to not be able to spend your coins without your attorney's permission.

No, no. this should be 1-of-2. the 2-of-2 doesn't work here. we exactly need either of the keys unlock the funds. therefore we could track abuses.

When Alice is alive uses her primary account for transactions normally. but she also creates a secondary account linked (with OR logic gate) to her primary account, and gives its security values to her attorney/trusted_person with permission to use the keys of the secondary account when she is dead. if she share her primary account with others, she can't track any abuse of her account, but with 1-of-2, you could simply track the sign of your funds to see which sign get used for a particular transaction.





من مست و تو دیوانه، مارا که برد خانه!؟
translation from Persian:
I am drunk and you are insane, who will take us home!? --Rumi
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1563573540
Hero Member
*
Offline Offline

Posts: 1563573540

View Profile Personal Message (Offline)

Ignore
1563573540
Reply with quote  #2

1563573540
Report to moderator
bob123
Legendary
*
Offline Offline

Activity: 966
Merit: 1258



View Profile WWW
November 16, 2018, 07:01:02 AM
 #22

No, no. this should be 1-of-2. the 2-of-2 doesn't work here. we exactly need either of the keys unlock the funds. therefore we could track abuses.

When Alice is alive uses her primary account for transactions normally. but she also creates a secondary account linked (with OR logic gate) to her primary account, and gives its security values to her attorney/trusted_person with permission to use the keys of the secondary account when she is dead. if she share her primary account with others, she can't track any abuse of her account, but with 1-of-2, you could simply track the sign of your funds to see which sign get used for a particular transaction.

But again.. this approach requires trust.

Yes, you could track the 'abuse' in terms of you'd know who spend these coins.
But you wouldn't be able to 'revert' it or anything else.

The coins would be gone in this scenario. The best approach is a trustless approach. And this does exclude the option of a 1of2 multisig with giving 1 key away.

mixoftix
Member
**
Offline Offline

Activity: 104
Merit: 145

..


View Profile WWW
November 16, 2018, 08:31:41 AM
Last edit: November 16, 2018, 09:06:39 AM by mixoftix
 #23

No, no. this should be 1-of-2. the 2-of-2 doesn't work here. we exactly need either of the keys unlock the funds. therefore we could track abuses.

When Alice is alive uses her primary account for transactions normally. but she also creates a secondary account linked (with OR logic gate) to her primary account, and gives its security values to her attorney/trusted_person with permission to use the keys of the secondary account when she is dead. if she share her primary account with others, she can't track any abuse of her account, but with 1-of-2, you could simply track the sign of your funds to see which sign get used for a particular transaction.

But again.. this approach requires trust.

Yes, you could track the 'abuse' in terms of you'd know who spend these coins.
But you wouldn't be able to 'revert' it or anything else.

The coins would be gone in this scenario. The best approach is a trustless approach. And this does exclude the option of a 1of2 multisig with giving 1 key away.

so, we have HASHED TIME LOCKED CONTRACTS (HTLC) in bitcoin that works with the concept of PROOF-of-Payment and even could provide *reversible* transactions to the payer or re-route it to 3rd address. this only needs to open payment channels.

more info: https://en.bitcoin.it/wiki/Hashed_Timelock_Contracts

** if there are no other technical considerations, now we have an ALICE1-ALICE2-CHARLIE relationship in a dead scenario. Alice owns two accounts, Alice1 and Alice 2. Alice will have her bitcoins accessible by submitting a random digital content with Alice1 which triggers a transaction to Alice2. if this digital content does not submit before a specified future time, then could automatically re-route to CHARLIE.

من مست و تو دیوانه، مارا که برد خانه!؟
translation from Persian:
I am drunk and you are insane, who will take us home!? --Rumi
apexcrypto
Newbie
*
Offline Offline

Activity: 9
Merit: 0


View Profile
November 17, 2018, 04:33:29 PM
 #24

Why not just encrypt your seed with PGP, put the encrypted text in your will, and store the
password in your bank safe deposit box. You could even give the recipient a BIP39 password now, without the seed
so that only they can access the btc if/when the seed is decoded, presumably after you are dead and
your safe deposit box has been opened.
aleksej996
Sr. Member
****
Offline Offline

Activity: 476
Merit: 327


Do not trust the government


View Profile WWW
November 17, 2018, 08:32:33 PM
 #25

so, we have HASHED TIME LOCKED CONTRACTS (HTLC) in bitcoin that works with the concept of PROOF-of-Payment and even could provide *reversible* transactions to the payer or re-route it to 3rd address. this only needs to open payment channels.

more info: https://en.bitcoin.it/wiki/Hashed_Timelock_Contracts

** if there are no other technical considerations, now we have an ALICE1-ALICE2-CHARLIE relationship in a dead scenario. Alice owns two accounts, Alice1 and Alice 2. Alice will have her bitcoins accessible by submitting a random digital content with Alice1 which triggers a transaction to Alice2. if this digital content does not submit before a specified future time, then could automatically re-route to CHARLIE.

It is unnecessary to use hashed timelock contracts if you can use simple a simple timelock value in transactions.
You shouldn't make things more complicated then they need to be.

Using timelock you will be able to use any kind of transaction (segwit, legacy,multisig) it doesn't need no special conditions.
Also you will have better support with more wallets and miners supporting it.

There really shouldn't be any need to complicate things like this. This is a very simple and old problem.

Why not just encrypt your seed with PGP, put the encrypted text in your will, and store the
password in your bank safe deposit box. You could even give the recipient a BIP39 password now, without the seed
so that only they can access the btc if/when the seed is decoded, presumably after you are dead and
your safe deposit box has been opened.

This should also work in it's own way. It is simpler to setup then using timelocks, although it moves a bit of complexity to the party that receives the inheritance.

It is also slightly less secure since it depends on trust of seed words not being obtained prior to the persons death.
So it's not as insecure as putting a private key in a will, since anyone would be able to steal it.
However from the perspective of a user that holds the password, the security is the same as if that was the private key.

So in conclusion, not as elegant, but perhaps easier to setup for the person that is writing a will.
aliashraf
Hero Member
*****
Offline Offline

Activity: 854
Merit: 641


View Profile
November 17, 2018, 08:52:59 PM
Last edit: November 17, 2018, 09:56:13 PM by aliashraf
 #26

There are many ways if he rely on trusted people or 3rd party which already mentioned by others.

Otherwise, the closest things that i could think is using P2SH transaction/bitcoin script where the receiver only can claim the Bitcoin after n days/blocks. To prevent claim abuse while he's still alive, he could remake the script with different timelock before current timelock is "expired".
The rough code should look like this (i'm still learning bitcoin script, so most likely it's inaccurate) :
Code:
OP_IF
    <Alice's Public Key> OP_CHECKSIG
OP_ELSE
    <90 days> OP_CSV DROP <Bob's Public Key> OP_CHECKSIG
OP_ENDIF
With above modification (DROP opcode is mandatory here and added by me), this is the ultimate solution.

That said, besides including its hash in the output script of her P2SH transaction, Alice has to give above redeem script to Bob somehow and she should keep updating Bob regularly about the latest redeem script version. One solution may be to treat the whole process like part a formal will. In 90 days after Alice has passed, Bob would be able to claim the balance using the latest redeem script he has received.

The code shows the beauty of CHECKSEQUENCEVERIFY opcode and its wide range of applications. unlike legacy nLockTime alternative which is transaction level and prevents the whole transaction from getting into blockchain and being effective, OP_CSV provides locking mechanism for tx outputs which makes such applications possible.

P.S.
I just don't get it by the way, why should we continue arguing once the solution has been presented?. The post I quoted from @ETFbitcoin was submitted few hours after op, I suppose.
ETFbitcoin
Legendary
*
Offline Offline

Activity: 1708
Merit: 1862

Use SegWit and enjoy lower fees.


View Profile WWW
November 18, 2018, 05:17:32 AM
 #27

There are many ways if he rely on trusted people or 3rd party which already mentioned by others.

Otherwise, the closest things that i could think is using P2SH transaction/bitcoin script where the receiver only can claim the Bitcoin after n days/blocks. To prevent claim abuse while he's still alive, he could remake the script with different timelock before current timelock is "expired".
The rough code should look like this (i'm still learning bitcoin script, so most likely it's inaccurate) :
Code:
OP_IF
    <Alice's Public Key> OP_CHECKSIG
OP_ELSE
    <90 days> OP_CSV DROP <Bob's Public Key> OP_CHECKSIG
OP_ENDIF
With above modification (DROP opcode is mandatory here and added by me), this is the ultimate solution.

I keep forgetting add DROP OP_DROP as i confused when to use it, thanks for the correction Smiley

That said, besides including its hash in the output script of her P2SH transaction, Alice has to give above redeem script to Bob somehow and she should keep updating Bob regularly about the latest redeem script version. One solution may be to treat the whole process like part a formal will. In 90 days after Alice has passed, Bob would be able to claim the balance using the latest redeem script he has received.

The code shows the beauty of CHECKSEQUENCEVERIFY opcode and its wide range of applications. unlike legacy nLockTime alternative which is transaction level and prevents the whole transaction from getting into blockchain and being effective, OP_CSV provides locking mechanism for tx outputs which makes such applications possible.

Aside from process where Bob give his public key to Alice for first time, Alice could write a script which :
1. Make exactly same script, expect timestamp/block height modified for next 90 days
2. Spend Bitcoin from older P2SH transaction and send it to same address with new script
3. Send newer script to Bob (through email perhaps)

Additionally, Alice could send the script only one time to Bob and said she always add value for OP_CSV time with +12960 (block) or +7776000 (timestamp) every transaction "refresh", so continues communication or 3rd party dependency can be removed as Bob simply need to know how many "refresh" happens.

P.S.
I just don't get it by the way, why should we continue arguing once the solution has been presented?. The post I quoted from @ETFbitcoin was submitted few hours after op, I suppose.

No idea, HeRetiK and me already give the solutions through different method.

mixoftix
Member
**
Offline Offline

Activity: 104
Merit: 145

..


View Profile WWW
November 18, 2018, 08:26:32 AM
 #28

It is unnecessary to use hashed timelock contracts if you can use simple a simple timelock value in transactions.
You shouldn't make things more complicated then they need to be.

simply, just in the case Alice has complicated scenarios for her will.

--------------------

but there is one serious question here about "Transaction malleability":
https://en.bitcoin.it/wiki/Transaction_malleability

which of solutions above are not vulnerable to malleability?

من مست و تو دیوانه، مارا که برد خانه!؟
translation from Persian:
I am drunk and you are insane, who will take us home!? --Rumi
bob123
Legendary
*
Offline Offline

Activity: 966
Merit: 1258



View Profile WWW
November 18, 2018, 03:28:14 PM
Merited by mixoftix (1)
 #29

It is unnecessary to use hashed timelock contracts if you can use simple a simple timelock value in transactions.
You shouldn't make things more complicated then they need to be.

simply, just in the case Alice has complicated scenarios for her will.

--------------------

but there is one serious question here about "Transaction malleability":
https://en.bitcoin.it/wiki/Transaction_malleability

which of solutions above are not vulnerable to malleability?


Transaction malleability doesn't influence the scenario and the outcome of the transaction.

What transaction malleability basically is, is that you can take a broadcasted transaction and change a 'value' (not possible to change receipent/amount/fee) to generate a new hash ('basically same' transaction, just a different hash).

This is a problem for not-that-good coded exchanges which rely on the transaction hashes when withdrawing funds.


But this doesn't have any influence in this scenario since it doesn't change anything important.

aliashraf
Hero Member
*****
Offline Offline

Activity: 854
Merit: 641


View Profile
November 18, 2018, 09:24:27 PM
Last edit: November 18, 2018, 10:00:49 PM by aliashraf
Merited by Stedsm (4), ETFbitcoin (1)
 #30


Additionally, Alice could send the script only one time to Bob and said she always add value for OP_CSV time with +12960 (block) or +7776000 (timestamp) every transaction "refresh", so continues communication or 3rd party dependency can be removed as Bob simply need to know how many "refresh" happens.
I afraid there are some flaws in this paragraph:

One should note that CHECKSEQUENCEVERIFY is a relative lock time operator. For Alice to "refresh" his script there may exist two different reasons:
1)She needs to spend part of her balance and leave the remaining for Bob to inherit just in case.
2) she just wants to make it possible for another period.

In either case the "90d" parameter doesn't need to be changed (unless Alice might want to reconsider her policy), timer is reset and starts ticking from the moment the new script is confirmed. Bob should supply this constant number, 90d, in his redeem transaction in nsequence field (in spite of the fact that he needs to supply the raw script which again carries this parameter) as a result, bitcoin doesn't let Bob transaction in the blockchain, unless its input (hopefully Alice latest tx output) is aged at least 90 days (no script processing involved yet). When the time comes and Bob transaction is basically ready to be confirmed, bitcoin runs the script he has provided (as its hash is used in Alice P2SH transaction) and the script checks the nsequence field (second access into this field) for being matched with "90d" parameter of op_CSV, ... it is how it works.

Still Alice needs to refresh Bob in both cases!  

It is because Alice has to expose her public address every time she spends her latest tx and as a best practice she needs to avoid reusing it in the new transaction. It implies new script pattern and new hash hence Bob should be informed about this new hash (remember? Alice is using P2SH address in her transaction) and its raw script.
OmegaStarScream
Staff
Legendary
*
Offline Offline

Activity: 1722
Merit: 1364


Hire BOUNTYPORTALS>Bounty management goo.gl/XKv9TK


View Profile
November 22, 2018, 09:20:23 AM
 #31

I appreciate everyone suggestions and apparently, the way to go would be using time-locked transactions.

I'm afraid I haven't given all the details so would it change anything If for example, he wants to send a certain amount on a weekly basis until all funds left his wallet? or the same logic should apply?

aliashraf
Hero Member
*****
Offline Offline

Activity: 854
Merit: 641


View Profile
November 22, 2018, 09:54:58 AM
Merited by OmegaStarScream (2)
 #32

I appreciate everyone suggestions and apparently, the way to go would be using time-locked transactions.

I'm afraid I haven't given all the details so would it change anything If for example, he wants to send a certain amount on a weekly basis until all funds left his wallet? or the same logic should apply?
Not a big deal. Though my question would be whether "he" wants to pertain access to his funds to be able to stop the weekly payment process (like when the heir behaves improperly or passes away because of an accident or somethin)? If positive (more likely) he could just make a transaction with multiple outputs with the same script as what @etfbitcoin has proposed with OP_CSV parameter adjusted to <7 days>, <14 days>, ... for each P2SH output and they follow the same relative lock time logic discussed above thread.

Note that there would be multiple redeem scripts that should be handed to heir and should be kept uptodate if the owner decides to interrupt or revise his policy.


Warning:
Avoid any solution that somehow requires a third party service, a trustee, anything other than your legacy wallet api, otherwise you are ignoring the whole purpose of what you have paid for: bitcoin.


Ucy
Sr. Member
****
Online Online

Activity: 924
Merit: 275


★Bitvest.io★ Play Plinko or Invest!


View Profile
November 22, 2018, 05:20:03 PM
Last edit: November 22, 2018, 05:50:03 PM by Ucy
 #33

The problem with some of the suggestions here is that the coins will be released to the Next of kin If you're in a coma, kidnapped or in jail.

Maybe we could have a program that makes inquiries from lots of relatives and family members about your current state (dead/alive) whenever you become non-responsive. It should be a questionnaire with simple Yes/No answer. If  majority of the family members/relatives  say you are alive then it keeps holding the coins. If majority says you're dead then the coin is released to your Next of kin.



BITVEST DICE
HAS BEEN RELEASED!


▄████████████████████▄
██████████████████████
██████████▀▀██████████
█████████░░░░█████████
██████████▄▄██████████
███████▀▀████▀▀███████
██████░░░░██░░░░██████
███████▄▄████▄▄███████
████▀▀████▀▀████▀▀████
███░░░░██░░░░██░░░░███
████▄▄████▄▄████▄▄████
██████████████████████
▀████████████████████▀
▄████████████████████▄
██████████████████████
█████▀▀█▀▀▀▀▀▀██▀▀████
█████░░░░░░░░░░░░░▄███
█████░░░░░░░░░░░░▄████
█████░░▄███▄░░░░██████
█████▄▄███▀░░░░▄██████
█████████░░░░░░███████
████████░░░░░░░███████
███████░░░░░░░░███████
███████▄▄▄▄▄▄▄▄███████
██████████████████████
▀████████████████████▀
▄████████████████████▄
███████████████▀▀▀▀▀▀▀
███████████▀▀▄▄█░░░░░█
█████████▀░░█████░░░░█
███████▀░░░░░████▀░░░▀
██████░░░░░░░░▀▄▄█████
█████░▄░░░░░▄██████▀▀█
████░████▄░███████░░░░
███░█████░█████████░░█
███░░░▀█░██████████░░█
███░░░░░░████▀▀██▀░░░░
███░░░░░░███░░░░░░░░░░
▀██░▄▄▄▄░████▄▄██▄░░░░
▄████████████▀▀▀▀▀▀▀██▄
█████████████░█▀▀▀█░███
██████████▀▀░█▀░░░▀█░▀▀
███████▀░▄▄█░█░░░░░█░█▄
████▀░▄▄████░▀█░░░█▀░██
███░▄████▀▀░▄░▀█░█▀░▄░▀
█▀░███▀▀▀░░███░▀█▀░███░
▀░███▀░░░░░████▄░▄████░
░███▀░░░░░░░█████████░░
░███░░░░░░░░░███████░░░
███▀░██░░░░░░▀░▄▄▄░▀░░░
███░██████▄▄░▄█████▄░▄▄
▀██░████████░███████░█▀
▄████████████████████▄
████████▀▀░░░▀▀███████
███▀▀░░░░░▄▄▄░░░░▀▀▀██
██░▀▀▄▄░░░▀▀▀░░░▄▄▀▀██
██░▄▄░░▀▀▄▄░▄▄▀▀░░░░██
██░▀▀░░░░░░█░░░░░██░██
██░░░▄▄░░░░█░██░░░░░██
██░░░▀▀░░░░█░░░░░░░░██
██░░░░░▄▄░░█░░░░░██░██
██▄░░░░▀▀░░█░██░░░░░██
█████▄▄░░░░█░░░░▄▄████
█████████▄▄█▄▄████████
▀████████████████████▀




Rainbot
Daily Quests
Faucet
ETFbitcoin
Legendary
*
Offline Offline

Activity: 1708
Merit: 1862

Use SegWit and enjoy lower fees.


View Profile WWW
November 22, 2018, 05:42:26 PM
 #34

The problem with some of the suggestions here is that the coins will be released to the Next of kin If you're in a comma or in jail.

Maybe we could have a program that makes inquiries from lots of relatives and family members about your current state (dead/alive) whenever you become non-responsive. It should be a questioner with simple Yes/No answer. If  majority of the family members/relatives  say you are alive then it keeps holding the coins. If majority says you're dead then the coin is released to your Next of kin.

You're right, but unfortunately your idea required middle-man/3rd-party while this topic's goal is to achieve "Dead man's switch" without middle-man/3rd-party.

But if the family members can be trusted, then we could use HLTC to achieve it where the parent create HTLC where parent can claim the coin immediately or the successor can claim the coins after n days and followed with few additional signature from family member.

Pmalek
Legendary
*
Offline Offline

Activity: 1008
Merit: 1105



View Profile
November 22, 2018, 07:29:22 PM
 #35

The problem with some of the suggestions here is that the coins will be released to the Next of kin If you're in a coma, kidnapped or in jail.

Maybe we could have a program that makes inquiries from lots of relatives and family members about your current state (dead/alive) whenever you become non-responsive. It should be a questionnaire with simple Yes/No answer. If  majority of the family members/relatives  say you are alive then it keeps holding the coins. If majority says you're dead then the coin is released to your Next of kin.
But then there is another problem. That solution could result in the coins not getting released to the next of kin in time or ever if the majority of the family want that for any reason.

aliashraf
Hero Member
*****
Offline Offline

Activity: 854
Merit: 641


View Profile
November 22, 2018, 08:24:49 PM
Merited by ETFbitcoin (1), pebwindkraft (1)
 #36

The problem with some of the suggestions here is that the coins will be released to the Next of kin If you're in a coma, kidnapped or in jail.

Maybe we could have a program that makes inquiries from lots of relatives and family members about your current state (dead/alive) whenever you become non-responsive. It should be a questionnaire with simple Yes/No answer. If  majority of the family members/relatives  say you are alive then it keeps holding the coins. If majority says you're dead then the coin is released to your Next of kin.
It would be easy to improve the redeem script in the suggested P2SH lock time above-thread to enforce m of n multisig:
Code:
OP_IF
    <Alice's Public Key> OP_CHECKSIG
OP_ELSE
    <90 days> OP_CSV DROP 2 <Bob's Public Key> <Carol's public key> <Daniel's public key> 3 OP_CHECKMULTISIG
OP_ENDIF
Ucy
Sr. Member
****
Online Online

Activity: 924
Merit: 275


★Bitvest.io★ Play Plinko or Invest!


View Profile
November 23, 2018, 10:31:38 AM
 #37

The problem with some of the suggestions here is that the coins will be released to the Next of kin If you're in a coma, kidnapped or in jail.

Maybe we could have a program that makes inquiries from lots of relatives and family members about your current state (dead/alive) whenever you become non-responsive. It should be a questionnaire with simple Yes/No answer. If  majority of the family members/relatives  say you are alive then it keeps holding the coins. If majority says you're dead then the coin is released to your Next of kin.
But then there is another problem. That solution could result in the coins not getting released to the next of kin in time or ever if the majority of the family want that for any reason.

The family members don't need to know the purpose of the question. All they need to know is that the program was created by the owner to be sent out in the future in the time of his death or disappearance. There should be some kind of proofs that confirm it is coming from the real owner.


The owner could even program it to do a lot of things like to release the coins if he becomes absent for too long.



BITVEST DICE
HAS BEEN RELEASED!


▄████████████████████▄
██████████████████████
██████████▀▀██████████
█████████░░░░█████████
██████████▄▄██████████
███████▀▀████▀▀███████
██████░░░░██░░░░██████
███████▄▄████▄▄███████
████▀▀████▀▀████▀▀████
███░░░░██░░░░██░░░░███
████▄▄████▄▄████▄▄████
██████████████████████
▀████████████████████▀
▄████████████████████▄
██████████████████████
█████▀▀█▀▀▀▀▀▀██▀▀████
█████░░░░░░░░░░░░░▄███
█████░░░░░░░░░░░░▄████
█████░░▄███▄░░░░██████
█████▄▄███▀░░░░▄██████
█████████░░░░░░███████
████████░░░░░░░███████
███████░░░░░░░░███████
███████▄▄▄▄▄▄▄▄███████
██████████████████████
▀████████████████████▀
▄████████████████████▄
███████████████▀▀▀▀▀▀▀
███████████▀▀▄▄█░░░░░█
█████████▀░░█████░░░░█
███████▀░░░░░████▀░░░▀
██████░░░░░░░░▀▄▄█████
█████░▄░░░░░▄██████▀▀█
████░████▄░███████░░░░
███░█████░█████████░░█
███░░░▀█░██████████░░█
███░░░░░░████▀▀██▀░░░░
███░░░░░░███░░░░░░░░░░
▀██░▄▄▄▄░████▄▄██▄░░░░
▄████████████▀▀▀▀▀▀▀██▄
█████████████░█▀▀▀█░███
██████████▀▀░█▀░░░▀█░▀▀
███████▀░▄▄█░█░░░░░█░█▄
████▀░▄▄████░▀█░░░█▀░██
███░▄████▀▀░▄░▀█░█▀░▄░▀
█▀░███▀▀▀░░███░▀█▀░███░
▀░███▀░░░░░████▄░▄████░
░███▀░░░░░░░█████████░░
░███░░░░░░░░░███████░░░
███▀░██░░░░░░▀░▄▄▄░▀░░░
███░██████▄▄░▄█████▄░▄▄
▀██░████████░███████░█▀
▄████████████████████▄
████████▀▀░░░▀▀███████
███▀▀░░░░░▄▄▄░░░░▀▀▀██
██░▀▀▄▄░░░▀▀▀░░░▄▄▀▀██
██░▄▄░░▀▀▄▄░▄▄▀▀░░░░██
██░▀▀░░░░░░█░░░░░██░██
██░░░▄▄░░░░█░██░░░░░██
██░░░▀▀░░░░█░░░░░░░░██
██░░░░░▄▄░░█░░░░░██░██
██▄░░░░▀▀░░█░██░░░░░██
█████▄▄░░░░█░░░░▄▄████
█████████▄▄█▄▄████████
▀████████████████████▀




Rainbot
Daily Quests
Faucet
OmegaStarScream
Staff
Legendary
*
Offline Offline

Activity: 1722
Merit: 1364


Hire BOUNTYPORTALS>Bounty management goo.gl/XKv9TK


View Profile
December 03, 2018, 09:26:30 AM
 #38

The problem with some of the suggestions here is that the coins will be released to the Next of kin If you're in a coma, kidnapped or in jail.

Maybe we could have a program that makes inquiries from lots of relatives and family members about your current state (dead/alive) whenever you become non-responsive. It should be a questionnaire with simple Yes/No answer. If  majority of the family members/relatives  say you are alive then it keeps holding the coins. If majority says you're dead then the coin is released to your Next of kin.

Having funds released in these cases is fine. It doesn't necessarily have to be death, being away for long time as a trigger could work as well. The less people or services used in the process, the better.

MagicByt3
Full Member
***
Offline Offline

Activity: 280
Merit: 171


View Profile
December 05, 2018, 06:25:47 AM
 #39

The problem with some of the suggestions here is that the coins will be released to the Next of kin If you're in a coma, kidnapped or in jail.

Maybe we could have a program that makes inquiries from lots of relatives and family members about your current state (dead/alive) whenever you become non-responsive. It should be a questionnaire with simple Yes/No answer. If  majority of the family members/relatives  say you are alive then it keeps holding the coins. If majority says you're dead then the coin is released to your Next of kin.

Having funds released in these cases is fine. It doesn't necessarily have to be death, being away for long time as a trigger could work as well. The less people or services used in the process, the better.

If you were planning on creating something for this purpose you could craft some kind of software that the user must interact with in a specific time frame say 30-60 days using some form of keys.
This way would allow use of encryption to "authenticate" the user and to execute the payments or release info if the user failed to submit a key in a set time frame the software could either broadcast a transaction that could be stored encrypted and becomes decrypted and broadcast if the user fails to interact or submit a key or token to the software in a set period.

Or the keys could be held in encrypted container format and the decryption key is released if there is no interaction with the software in the specific time frame.



░░░░░░░░WASABI-WALLET Protect your privacy !!░░░░░░░░

░░░░░░░░CKPOOL.ORG!░░░░░░░░
MagicByt3
Full Member
***
Offline Offline

Activity: 280
Merit: 171


View Profile
December 16, 2018, 12:05:14 AM
Merited by ETFbitcoin (1)
 #40

I had a quick search about for similar things that might be good reference points to create a system for this purpose.

I found this email that has something interesting in it.

https://mailing-list-archive.cryptoanarchy.wiki/archive/1995/09/b15b1c8ebf07eff21cc1f67e7002a4a47c90d635e234bd863352ab37b36cbbe5/

7. National Semiconductor's "Commercial Cryptography Ideas
      for Success" (9 pp. of large type) This contains
      graphics of the CAKE program and a "Proposed NIST Escrow
      Certificate Heirarchy" which cannot be easily
      distributed by us, so we offer this by fax.

There was also some relation to the idea of.

You could use a trusted parties. p  then incorporate a threshold scheme or signature structure in order to hide the key (k) to your encrypted message enck(M).
Whenever you don't update those trusted parties, after (t) time, they can connect to each other and if they reach the threshold or can sign with the correct signatures it then releases the key k

p(k)~enck(M)~(t)

https://faculty.nps.edu/dedennin/publications/Descriptions%20of%20Key%20Escrow%20Systems.htm

another good reference for descriptions of Key Escrow systems.



░░░░░░░░WASABI-WALLET Protect your privacy !!░░░░░░░░

░░░░░░░░CKPOOL.ORG!░░░░░░░░
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!