I like this idea, but this is suffering from too many buzz words that it's almost too difficult to understand. Embalmer, Curse, Archeologist? There's some pretty thin analogies to draw from. This won't make the system easier to understand, and it might actually affect adoption.
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.
Homebrew [1] suffers from the same issue and it's horrible. What the hell is a keg, a cask? what is pouring? a cellar? what? I've been using it for years and I haven't bother to find out, but the fact that it's not immediately obvious is a sign of bad UX IMO.
Their usage of cookbooks and recipes is actually fine. Kitchen can be confusing sometimes but generally still fine... Knife is the most confusing of all. But what I really hate about Chef terms is they make searching with DDG really difficult.
I haven't even thought of rubygems and I deal with them every day. I'm curious now - they don't seem like a comparable issue for some reasons. Maybe because it's just one level? The language is Ruby which is arbitrary and the packages are gems which is connected in naming, but there's nothing more in language itself, right?
Couldn't agree more! I've been down voted like hell on HN for mentioning how much difficulty I have with names of products in the Tech realm, got down voted hard for pointing out Cider was a dumb name for a program...legit its a name for a drink, thats been around longer than the program. What the hell is with Techies and not being able to come up with their own names for stuff?
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.
It looks like "reserve requirement" is at most 100% -- so if Archeologist misbehaves, they only lose a small multiple of the contract fees? This seems pretty crazy even you fully buy into rational actors model.
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?
From reading the litepaper I have the same understanding.
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.
Yes, honestly, you should assume that the recipient is also an archaeologist.
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.
Do you also trust that the recipient will keep their emails secure?
Edit: Moreover, if we assume that there could be a bad actor that wants to know your secret, you have now endangered that 3rd party by giving them your secret.
Again, another scenario: You might trust that 3rd party now, but not in a years time (when, hopefully, you're still alive). Well, the good news is, you never revealed your secret to that 3rd party and you have no obligation to continue making them the recipient of your secret.
> You might trust that 3rd party now, but not in a years time (when, hopefully, you're still alive)
Then you don't want blockchain-based technology. Remember, the data is still on the chain, and can never be deleted - the paper is pretty clear about it.
So in a year's time if the 3rd party contacts the archeologist, they can arrange to truncate the chain and unseal the key. Yes, the archeologist is not going to get paid on-chain by the protocol, but the secret is still out.
Really looks like the bank's safe deposit is a much better solution if your data is valuable.
I still think you might be throwing the baby out with the bathwater; though I admit there's a lot more bathwater than baby, especially when compared with first glance.
The problem with your scenario is that the recipient of the payload is not trustworthy.
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 :)
But if there is a trusted 3rd party, why would I need that whole sarcophagus system? Let's just cut out the extra step and give the key to 3rd party directly. May buy that safe deposit box at the bank, it is pretty cheap.
The whole premise of decentralized system is there is no need for trusted third parties.
Disclaimer: I haven't read any the technical details of how this works.
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'
right, but if we attain equilibrium with their amount of whiskey, then we have a better chance of understanding. just like listening to the 2 people that have been at the bar all day. they understand each other perfectly, but to someone less inebriated, it's total non-sense/jiberish. so, for science, more whiskey is needed.
The recent autoincorrect made available from Apple is driving me absolute bonkers. On macOS version of Messages is infuriating on how slowly it updates the text as I type, and then goes off and changes things before it even finishes what I've typed. On iOS, it is infuriating in different ways
What gets me about autocorrect is that it's a system which "recovers" from minor mistakes of trivial significance by occasionally turning them into gigantic, opaque mistakes that completely prevent comprehension. (See above.)
Imagine if the solution to "10% of the time, when I boot up my computer, it takes an extra second or three to boot" were "the unpredictable lag in booting is gone, but, 0.5% of the time, when you boot your computer, it will melt. Don't keep it near anything flammable."
The cost of autocorrect failing once is far higher than the total benefit of every success you ever get out of it. Who thought this tradeoff made sense?
Maybe this question just reveals that I don't totally understand the underlying system here, but what stops the archaeologist from just unwrapping the sarcophagus off-chain? They don't get paid by the contract, but what if someone who is interested in my secret just pays them in cash?
Right, I get that, but presumably I don't want the recipient to have it unless the switch goes off, or else I wouldn't be using this system - I'd have just given it to the recipient unencrypted.
That's why the archaeologists are supposed to be a disinterested third party, you essentially pay them (and they forfeit their collateral) to not unwrap it.
I think the archeologists need to agree to unwrap sarcophagus, so the logic is the same as any other blockchain – anyone with 51% control can do whatever they want, otherwise you need coordination between parties that are only incentivized to act "properly".
Oh, I didn't get that from the whitepaper. They seem to use 'archaeologist' singular a lot of the time when it's unclear if they actually mean plural. So is it like some sort of n-of-k encryption where you need a majority of the archaeologists' keys to unwrap the outer layer?
"An Archaeologist is a third-party, disinterested, incentivized service provider. They operate the Archaeologist server, post bonds in SARCO, resurrect files when needed, and are rewarded for good behavior (They are also harshly punished for bad behavior)."
"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."
There are some very bad analogies used in crypto, but I don't consider this one of them.
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.
This doesn't sound appealing to me. A dead man's switch is exactly the kind of thing I want in the hands of some tiny number of people I trust deeply. This is why we pay attorneys and assign living trusts, who are already punished for bad behavior by bar committees and law enforcement agencies.
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.
I like this idea, probably because I have seen a lot of bad ones lately and there is some original thought gone into it.
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?
Yes but according to the protocol you MUST use Arweave to do so.
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.
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.
Yes, apart from the outline'd protocol fees you would need to pay gas fees to create and maintain the casket. There is also a theoretical break even for archaeologists if gas fees rose above the reward.
At Intercoin, we have been building all kinds of distributed applications on the Ethereum blockchain, that would be useful for communities, governance, voting, etc. (You can read about them at https://intercoin.org/applications)
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
Basically, it would let some roles in the community invoke the calls, and others to endorse the all. As long as the minimum number of people with the right role endorsed (including the invoker) and at least the right fraction of people with that role, the contract would then CALL that method with the parameters of the invoker. We even allowed people with simple wallets to send a tiny amount of ethereum, like 0.0000001928 where 1928 was the invokeId, to endorse a call.
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.
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.