[HN Gopher] A Decentralized Dead Man's Switch
___________________________________________________________________
A Decentralized Dead Man's Switch
Author : th3o6a1d
Score : 53 points
Date : 2021-03-11 19:28 UTC (3 hours ago)
(HTM) web link (sarcophagus.io)
(TXT) w3m dump (sarcophagus.io)
| chanandler_bong wrote:
| The explanation of the service sounds like the rules for The
| Cones of Dunshire.
| paulhallett wrote:
| 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.
|
| Keep the terminology simple.
| juancampa wrote:
| 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.
|
| 1: https://brew.sh
| foobiekr wrote:
| It's worse because once you look it up, it's a bunch of
| forced metaphors where the priority was being cute rather
| than being useful.
| tired-dev wrote:
| There is a dire need for some less-metaphorical terminology here,
| I think.
| harryf wrote:
| 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.
| Jasper_ wrote:
| It won't.
| kfichter wrote:
| 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.
| ForHackernews wrote:
| 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.
| vinniejames wrote:
| 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
| kfichter wrote:
| 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
| BrandoElFollito wrote:
| I dream of such a system that cold be fitted on our in my body
| and wild release poison of not acknowledged.
|
| Should I become incapacited, the decision on how I end wild beef
| truly mine.
| usepgp wrote:
| You've got some wild typos in here.
| dylan604 wrote:
| I read that too, and just thought to myself "You just need
| more whiskey for that to make sense"
| glitchcrab wrote:
| I think too much whisky is the cause of the problem here,
| not the solution.
| dylan604 wrote:
| 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.
| EGreg wrote:
| 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
| addMethod(contractAddress, method, rolesForInvoking,
| rolesForEndorsing, minimum, fraction=0)
|
| 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.
|
| And you can see the code here: https://github.com/Intercoin
| Imnimo wrote:
| 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?
| fastball wrote:
| 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".
| Imnimo wrote:
| 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?
| tyingq wrote:
| I hear people complain about the cost of "gas fees" for Ethereum.
| Does this require paying those to keep the dead man switch alive?
| SahAssar wrote:
| "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."
|
| I really don't know if this is real or parody
___________________________________________________________________
(page generated 2021-03-11 23:00 UTC)