Fascinating use case. As I understand it (and I don’t understand much in this space) this would require an “Oracle” to provide someones state (dead or alive) thereby triggering the contract that releases whatever payload. Curious to see how this system will ensure the Oracle is reporting that correctly.
The general issue with this sort of oracle is the potential to create prediction markets based on someone's dead/alive state. I'm sure you can imagine why that could become problematic.
Sure, except it's way easier and legally less risky to compromise or co-opt the "oracle" than to murder somebody.
This is the same problem every single foo-on-the-blockchain project faces: all the interfaces with the real, actual world are obvious vulnerabilities that obviate the supposed security benefits of this convoluted crypto system.
Alternatively, this could be achieved by an affirmative action on the grantor's side. For example, require a signed transaction from a particular wallet every X months, if no transaction occurs, then trigger the switch
My favorite version of this is having a list of beneficiary addresses that can request to have access to the funds; you can cancel the request at any time within some time period. No fancy token required. I built a demo of this a while back: https://github.com/smartcontracts/dead-x-wallet
Yeah, I think the problem with this is that you need some way to store data without anyone being able to read the data on the blockchain.
There must be a middle-ground between your solution (dead simple) and the OP, which I find to be overly complex with all the "Curse", "Archeologist", etc. shenanigans.
Comments
Fascinating use case. As I understand it (and I don’t understand much in this space) this would require an “Oracle” to provide someones state (dead or alive) thereby triggering the contract that releases whatever payload. Curious to see how this system will ensure the Oracle is reporting that correctly.
The general issue with this sort of oracle is the potential to create prediction markets based on someone's dead/alive state. I'm sure you can imagine why that could become problematic.
Sure, except it's way easier and legally less risky to compromise or co-opt the "oracle" than to murder somebody.
This is the same problem every single foo-on-the-blockchain project faces: all the interfaces with the real, actual world are obvious vulnerabilities that obviate the supposed security benefits of this convoluted crypto system.
Alternatively, this could be achieved by an affirmative action on the grantor's side. For example, require a signed transaction from a particular wallet every X months, if no transaction occurs, then trigger the switch
My favorite version of this is having a list of beneficiary addresses that can request to have access to the funds; you can cancel the request at any time within some time period. No fancy token required. I built a demo of this a while back: https://github.com/smartcontracts/dead-x-wallet
Yeah, I think the problem with this is that you need some way to store data without anyone being able to read the data on the blockchain.
There must be a middle-ground between your solution (dead simple) and the OP, which I find to be overly complex with all the "Curse", "Archeologist", etc. shenanigans.
Public key cryptography and using the same platform (https://www.arweave.org/) would do.
But where do you store the private key?
The private key is the dead-x-wallet contract.
I wonder what the gas costs are in comparison, contact deployment is reasonable expensive. I wonder if that's why they modeled it this way.
This is exactly what is proposed, the signed transaction is just a transaction as all transactions are signed.
The oracle is the user who's locking up the file. They have to periodically call a smart contact to show they are alive.
It won't.