I once heard about a team that rebuilt a whole suite of micro services using names from Lord of the Rings, but the names didn't reflect the service's functions at all, so the system was instantly unusable due to the confusing terminology.
Keep the terminology simple.
I come from construction, truck driving and concreting. If you say its a duck its a duck. I've gotten to the point I just won't recommend businesses that do that kinda stuff it makes on-boarding new users a unnecessary PITA.
I think the terminology used here does a pretty decent job of trying to explain what's going on behind the scenes.
The diagrams in the litepaper (https://sarcophagus.io/assets/pdf/sarcophagus_litepaper_v0.2...) do a good job too.
Here is a simple hypothetical:
Let's say me + my partner have a DeFi startup, and we have $1,000,000 worth of cryptocurrency in cold storage, protected by multisig. In order to prevent money from being lost if something happens, I want my partner to get a key if I die. A regular centralized safety deposit box is $100/year, but I don't trust it, so I set up this "sarcophagus" thing with $10,000 as bounty, to incentivize the archeologist nodes.
Assume that my partner is not actually trustworthy, and they want to steal the money. So they contact Archeologists nodes directly, and offer them 10% of "corpse" value if they unwrap early.
What would a rational economic actor do? From my reading the paper, it would be in their interest to _defect_ and unwrap earlier. They are going to lose their bond ($10,000 + 10%) and their reserve requirement will raise a bit -- but not too much if they don't do this frequently. And they will gain 10% of corpse value, or $100,000 in this example.
So it looks like this scheme is really not useful for any sort of high-value secrets?
It's even worse becuase if you were in contact with the nodes directly you could simulate unwrapping on a fork - here they would not suffer any economic consequences.
On the other hand there's no guarentee your partner can contact any of the node owners. The protocol doesn't provide a mechanism, nor does ethereum so it only takes 1 to not respond.
If you do not trust the recipient to act with your best interests at heart, do not use this service. I think that should probably be explained better in the documentation.
Instead of the recipient being your partner, it should be a trusted 3rd party who could be instructed to provide the key to your partner in the event of your death (it would then be up to that 3rd party to verify that you are in fact dead). You could also add all kinds of caveats here like the 3rd party should only provide the key to your partner if your death wasn't suspicious etc.
Essentially, the recipient of the key needs to be trusted. Hopefully someone who cares about YOUR legacy, not lining their pockets with whatever the contents of your sarcophagus might reveal.
You can't assume everyone is a bad actor, otherwise everyone would be murdering their parents :)
The whole premise of decentralized system is there is no need for trusted third parties.
In decentralized systems, shouldn't nodes suffer repercussions for dishonest behaviour which outweigh the potential gain? Which could mean (complete conjecture here) the archaeologist node would no longer be able to participate in the network, and would stand to lose out on more money that way.
I have no idea if the sarcophagus protocol/network actually provide the correct measures to ensure nodes can't be incentivized to do this. I would hope so though, it's like 'decentralized network 101'
Should I become incapacited, the decision on how I end wild beef truly mine.
The only case it would be useful is if they collude with the recipient. I'm not sure how this procotol disincentives this.
Either we're missing something from the unwrapping process, or there's too much trust put into the archaeologist.
"After spinning up an Archaeologist server, the operator must set their own parameters for minimum digging fees, minimum bounty, and maximum resurrection time. This will allow the Embalmer to see the minimum price in SARCO that an Archaeologist will accept in order to be cursed."
I really don't know if this is real or parody
The concept of an embalmer makes sense and rewrapping the corpse (payload) in order to keep it from being exposed.
The contract between the embalmer and the archaeologist being called a 'curse' makes sense, too. It signifies that there is a right and a wrong way for the archaeologist to lift that curse.
The only thing that doesn't really make sense is the "recipient", which is where it makes more sense to think of the corpse as a treasure chest where only the recipient has the key to open it, but I guess there's only so far you can force an analogy.
The marketing material is quite good and the explanatory material makes sense to a layman like me. Then again, maybe the bar for crypto marketing material is so low due to all the pump/dump/rug-pull schemes on the market.
As an example here (https://i.imgur.com/8Unt5fD.jpg) is a notation table for atomic swaps.
I guess this is great if you're a drug lord or living in a failed state and honest to God can't trust anyone.
In this case you're trusting asymmetric cryptography, the liveness of the EVM and the third parties is motivated by money.
The attorney just acts as the third party and is responsible for the "liveness" of your will. All the smart contact does it make things explicit.
My biggest criticism is WHY tie yourself into Arweave? It seems to me like it would be MUCH better for the contents of your sarcophagus to be something small like a 32kb TXT file, which could itself be JSON or whatever you want it to be that then points to where the files are actually stored + a decryption key.
Tying yourself to one specific storage technology instead of generic metadata that could be used for any purpose, to me seems to detract from the possibilities of what this could be used for.
Why shouldn't I just be able to put links to a google drive in here, or the password to my iCloud, or the coordinates to my buried treasure, etc.?
I understand the value proposition of Arweave, I get that, but why not let the user make the decision to use a "permanent file storage" of their choice instead of making that decision for them?
You can put a link to an external file and an encryption key in your Arweave payload.
The blockchain can already store data for you, not large chunks of data, but BTC can store 1MB which should be more than enough to put a link to Arwave, S3, ipfs, coordinates to a buried USB stick, etc.
Arweave is NOT a permanent file storage solution. All participants in the network could simply shred their hard drives.
The annoying thing is, their own stated goal is
> Our goal with this is to make secret recovery easier and more intuitive.
Then they go on to instead solve the problem of both secret recovery AND bitrot/linkrot (without truly solving the bitrot/linkrot problem, simply tying themselves to a separate project which claims that they have).
Edit:
To put it another way, if I pitch to you an interesting IP routing algorithm and then said "but you can only use Cisco routers to do it" you might question what my interest in Cisco is vs. my interest in solving the posed routing problem.
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.
One of the building blocks was the ControlContract. It was designed to be a drop-in replacement for any address that might have some ability to manage a balance or call some methods of other contract. Like a multisig wallet on Bitcoin, but much enhanced.
ControlContract basically referred to an existing CommunityContract (which was responsible for managing roles and permissions), and the owner could call something like
addMethod(contractAddress, method, rolesForInvoking, rolesForEndorsing, minimum, fraction=0)
Anyway, we then said, what if we had "succession". So the owner of the contract could itself be a ControlContract. Or they might set up some groups and then renounceOwnership(). The first group would call the shots, but if they didn't successfully call a method in a certain timeout, not even calling heartbeat() before the timeout ,then the second group became empowered. If the first group came back later then they could still get everything done immediately, and the second group would be depowered until the next time. And so on down the line. This would be like a "vice president" etc.
So yeah, we built an entire system for governing communities, that would basically be flexible enough for any sort of things like that.
And you can see the code here: https://github.com/Intercoin