Application idea - Deadman switch / access control

[cankisagun]

“Dead-Man’s Switch” is a trigger for an event that occurs when an operator becomes incapacitated. Originally, the term described a physical switch that when released, caused a machine to stop running. Now the term also refers to software that asks a user to periodically “check-in”, and releases some information if the user fails to perform this check-in within a certain amount of time.

Below is the user flow for a deadman switch built on Enigma blockchain.

1. Alice initiates the secret contract that will act as the decentralized deadman switch by:

   • storing encrypted secret (input) to the secret contract
   • defining the recipient address of the secret (input)to receive the secret when the triggering event takes place
   • defining triggering event - i.e. desired check-in interval (1 TX per month, year etc.) defined in number of blocks
   • funding a bounty for the deadman switch to be called if desired check-ins don't take place

2. Alice "checks-in" - sends a transaction to the DMS secret contract Enigma network. Alice must repeat this within the specified interval.

3. Bob is able to submit a transaction to the secret contract. If Alice ceases to "check-in" within the specified interval, Bob would submit a transaction to the secret contract to reveal the secret and collect the bounty. Secret contract compares block numbers of Bob's transactions and Alice's last "check-in" transaction to the desired check-in interval.

4. If elapsed time is greater than the interval specified by the user, Bob receives the bounty and secret contract encrypts the secret with the recipient address Alice defined in step 1. (encrypted outputs).

[cankisagun]

Access control (Dead-Man’s Switch) can also be repurposed for digital content management (DCM) or monetization in Web3.

Below is the user flow for DCM built on Enigma blockchain.

1. Alice initiates the secret contract that will act as the decentralized DCM by:

   • storing content (input) or a way to decrypt encrypted content stored on IPFS to the secret contract
   • defining a triggering payment amount - i.e. reveal the secret if 1,000 SCRT is sent to the contract

2. Bob sends a payment to the secret contract to access the content. If payment amount is equal or greater than triggering payment amount, the smart contract is triggered to share the secret with Bob using encrypted outputs.

3. The smart contract uses a symmetric encryption method (like Diffie-Hellman) - uses Bob public key and the private key of the contract to encrypt the secret

[cankisagun]

Based on issie #201 , here are some potential limitations for the DMS / access control ideas:

Dead-man's Switch - problem with time The triggering event in a DMS is time elapsed. If time elapsed (block-height) cannot be determined within the enclave, then we need a trigger system (operator or a multi-sig within the contract)

Digital content management In order to release the "secret" there has to be a payment done to the contract. The payment = price to access content. The fact that we can't verify _sentfunds seems to be an issue. I guess if the secret contract can only accept a certain transaction amount (that's equal to the price and rejects all other payments), then thus issue can be solved with the secret contract design.

Decryption information for the buyer - since we can identify message sender inside the enclave, we should be able to determine bob's address (public key) and create a symmetric decryption key for Bob. @reuvenpo let me know if I'm missing anything

[reuvenpo]

You are correct, except:

1. even if you restrict payments to a constant amount, you still have to verify them somehow, which means that you're back to square one.
2. outputs are already encrypted as part of the usual flow. If the payer is also the customer, you can just return the secret "plaintext" and our infrastructure will encrypt it.
3. if we do have a sense of time in the contract, then you don't need the incentive system you described. once the contract state indicates that a point in time has passed, it can just provide the secret to anyone that asks (or to a closed set of people that should be allowed to see the secret)

[dwarrier]

Hi,

I'm wondering about short-term workarounds for not being able to verify the block height in the secure enclave for a triggering mechanism at this time:

The triggering event in a DMS is time elapsed. If time elapsed (block-height) cannot be determined within the enclave, then we need a trigger system (operator or a multi-sig within the contract)

What if we required the secret recipient to provide a chain of block header hashes (which they could obtain from the Bitcoin or Ethereum network)?

When creating a secret, the creator would provide the block header hash of the current Bitcoin block (start block), and the amount of time that they want the secret to be inaccessible to the recipient for. This time would be converted into a number of blocks.

When a recipient wants to retrieve a secret, they have to provide block header hashes (and possibly additional data to perform the verification such as the nonces and difficulties) for the same number of blocks starting from the provided block. To make verification harder to tamper with, we would check that the target difficulty is always greater than a threshold value during verification.

Of course, they could make these up and not submit values from the actual Bitcoin network. We're assuming that anyone with the computational resources to create a valid fake chain of these block hashes would have a lot more to gain by mining Bitcoin. For example, if I wanted to prevent a recipient from accessing a secret for 1 year and a new Bitcoin block is created every 10 minutes, the work done to make a valid chain would provide 3652460/10 = 52560 blocks, which an astronomical value in block rewards.

One consideration which affects the feasibility of this approach is the amount of data the recipient would need to send in a message (or series of messages) for verification. Assuming ~52560 blocks created per year and 80 bytes for the size of a block header, this would be about 80*52560/(10^6) = 4.2048 MB of data sent to verify a secret made inaccessible for a year. Unfortunately, this would scale linearly with the amount of time that a secret is kept inaccessible for. However, a secret creator could "renew" the secret by submitting a different start block after a year as part of the check in process in order to keep this amount of time relatively low.

Given the potentially large size of the message, the cost of executing this verification inside a secret contract function may also be too much to make this approach practical. I'm not sure how to come up with an estimate on that.

There's a related paper on time-lock encryption which I've only read a couple pages of that discusses the idea of using the Bitcoin block data as a "computational reference clock". This paper doesn't assume a protocol like Secret Network exists of course, so I was hoping applying that concept here would be easier.

I would appreciate any criticism or thoughts on using an approach like this.

[reuvenpo]

I don't see any immediate theoretical issues with this approach. You are correct that the message size for a year-long delay would be too big, but it should be easy enough to split the message into smaller chunks and incrementally progress the internal "clock" until you finish proving that enough time has elapsed.

That being said, Bitcoin today is a behemoth that consumes obscene amount of energy just to keep working. Personally, I'd prefer finding a cheaper method of tracking time. Of course, tracking time by reading the state of Bitcoin doesn't influence Bitcoin's power consumption, but it does mean that I don't believe it would be a sustainable time keeping mechanism long term. Bitcoin will eventually be forced to switch to a PoS mechanism (I hope) just like Ethereum 2, at which point this clock will break.

But yeah, as a short term solution it will probably work, but should have to have built in measures for indicating its reliability is reduced, based on what is going on with Bitcoin.

[dwarrier]

Thank you for the feedback, Reuven!

You are correct that the message size for a year-long delay would be too big, but it should be easy enough to split the message into smaller chunks and incrementally progress the internal "clock" until you finish proving that enough time has elapsed.

That's a good point. Initially I was thinking the gas cost to execute the computations over all message chunks would be excessive as well, but I'll assume this isn't an issue given that Secret Network is trying to make complex computations feasible in general.

That being said, Bitcoin today is a behemoth that consumes obscene amount of energy just to keep working. Bitcoin will eventually be forced to switch to a PoS mechanism (I hope) just like Ethereum 2, at which point this clock will break.

Interesting outlook! I agree that Bitcoin's block production mechanism may change, but I'd really hope that it takes more than a few years, and that Secret Network would have a native solution for verifying the block height before that happens.

The time-based triggering mechanism is fairly important in the dead man's switch functionality. If Bitcoin is using up so much power already to provide a secure, publicly available, and uncensorable reference clock, it seems reasonable to use it for this particular application as long as the approach to apply it isn't flawed.

This approach could use the Ethereum 2 beacon chain, but new blocks are created every 12-15 seconds there AFAIK, which could be a 40-50x increase on the amount of data we would have to send for verification. I can't think of a way offhand to avoid needing data for every block to perform that step.

should have to have built in measures for indicating its reliability is reduced, based on what is going on with Bitcoin.

Would you mind clarifying what you mean by built in? I'm imagining something like a hard limit on the max time a secret creator can make the secret inaccessible to the recipient for (e.g. 2 years), and clear warnings of the risks involved and the underlying dependency on Bitcoin's block production. I'm not sure what more can be done since Secret Network isn't aware of the Bitcoin network at all.

[reuvenpo]

My intention in that last bit was basically that the DMS contract should have a way to be disabled by the admin/controller. Say Bitcoins block creation algorithm changes, or we found a better way to manage time - it should be possible to defuse the switch.

[dwarrier]

I see, that makes sense.

I'm not sure if this is what you meant by disabling the contract, but I don't think a single controller should be able to either release secrets immediately to all recipients, or prevent all recipients from retrieving secrets. As a user, I wouldn't trust an application which is set up that way. As a possible alternative, I think this application could still be useful if there was a controller that could call a single "disable" action that does the following (this is just an example and isn't exhaustive):

1. Immediately prevents new secrets from being created
2. Prevents the start block from being modified when a secret creator checks in (though they can still change the recipient(s) or delete the secret)
3. Allows all recipients to access secrets after a significant delay regardless of the delay specified by the secret creator (e.g. 1 year after the timestamp of the start block provided for each secret). This delay should be hardcoded, immutable, and specified up front to all users.

Ideally no one would have the ability to do any of these things, but I agree that this particular contract would be a temporary solution, and there should be rules in place that enforce the time frame that it's being used for.

[reuvenpo]

ahhh, i was thinking in terms of instantiating a separate contract for each DMS (They will all be based on the same code, just re-instantiated for each user). Then each contract has one admin, which controls the one secret, and needs to independently update that clock. In this model, it makes sense that i'd want to defuse my own DMS. You model is more efficient, because updating time needs to be done once for all contracts, but this can be achieved by creating a separate time oracle contract (based on the bitcoin ledger), which the DMS contracts can query whenever someone tries to retrieve the secret, and whenever the admin "clicks the switch" to keep it alive. This time oracle can then be used across the secret contract ecosystem.

[cankisagun]

@dwarrier do you have interest in building this? This can be a possible grant recipient

[dwarrier]

ahhh, i was thinking in terms of instantiating a separate contract for each DMS This time oracle can then be used across the secret contract ecosystem.

Separate contract instances for each secret creator sounds like a reasonable approach as well. I'm still not sure whether using the same time reference data across all contracts is a good idea. The advantage is that this data would only need to be submitted once (see concerns about this below) and would save on gas costs for recipients, but as either a secret recipient or creator I don't like the idea that a third party could interfere with the secret retrieval process. Deciding on this doesn't seem to be a blocker though, since it could even be made configurable (e.g. for each secret, the sender chooses to use a central time oracle or have the recipient provide the time reference information themselves).

@dwarrier do you have interest in building this? This can be a possible grant recipient

I would be interested, but I have some concerns about whether this particular approach would be practical to use. Mainly I'm worried that anyone submitting time reference data would have to individually sign dozens of transactions if we need to split up this data across multiple calls. It may turn out that the gas fee to do the hashcash verification is also fairly high, but that's less of a problem to me than the usability aspect.

Would you be able to help me answer the following questions? I'm assuming there's no way to write large amounts of data directly to secret contract storage, so we'd have to pass it over one or more calls.

1. What's the maximum amount of data that can be sent in a single Secret Network transaction (call to a secret contract)?
2. Is there a way to batch multiple transactions so they can be approved by the user with a single signing action?

[reuvenpo]

About trusting a third party - contract code is public and immutable (code migrations are not supported, by design) so you can know what the code is, and no one can mess with it. The oracle contract can be designed so that anyone can update it. That way as long as someone cares about bitcoin time, all applications that use the time data keep working.

About whether or not the fundamental approach is right, Its possible to experiment with a PoC on the testnet (or even the local development node) to get an initial idea of the feasibility of this idea.

About writing large amounts of data, that's also something to experiment with. The cost depends on how you do it.

And to answer your questions:

1. I'm not sure, on the order of magnitude of a few megabytes. The contract runtime itself has just around 12MB of heap available per contract.
2. Yes. it's not implemented in secretjs yet though, afaik. CC: @assafmo

[dwarrier]

The oracle contract can be designed so that anyone can update it.

This is what makes me uneasy-- if a single malicious actor can cause the time reference contract to reflect a state that isn't consistent with the Bitcoin network by passing in fake data, this would affect everyone. It seems safer for all secret creators and recipients if each recipient could only provide time reference data for the secrets made available to them. Of course, it's possible that a malicious actor could publicly release the fake time reference data for any recipient to use, in which case this wouldn't matter. We could also design the time reference contract so that it requires the same data to be submitted by multiple parties and possibly introduce a penalty/reward system, but I won't focus on that right now.

About whether or not the fundamental approach is right, Its possible to experiment with a PoC on the testnet

Okay, I agree. I think the first step is to create a simple time reference contract that implements this mechanism, and can provide the time reference to other contracts.

I'll start working on this. I don't have much experience with the SN ecosystem yet, but I think this task is straightforward enough for me to get a basic implementation together. I'll aim to have something within a week or so (if not, I'll post updates/ questions).

And to answer your questions:

Thanks for the answers, Reuven! A few MB for the current max amount of data passed in a transaction is more than I expected, so that's reassuring. It's also good to know there will be a way to sign multiple transactions at once. I'd like to keep tabs on the state of work for that, since I think it's an important feature to incorporate in general for any contract potentially receiving large amounts of data from users.

[cankisagun]

@dwarrier feel free to join our discord if you are not already there :) chat.scrt.network

[dwarrier]

Thanks Can! Will do.

[dwarrier]

Update: I have a rough first pass of this here. It passes unit tests, but I haven't gotten a chance to try this in a local dev node yet. I also need to clean the contract up a bit, so I'll do both of those and post again when I've done some experimentation.

[cankisagun]

Great! Keep us posted

On Sat, Mar 20, 2021 at 9:13 PM dwarrier @.***> wrote:

Update: I have a rough first pass of this here https://github.com/dwarrier/secret-network-timekeeper/blob/main/src/contract.rs#L98. It passes unit tests, but I haven't gotten a chance to it this in a local dev node yet. I also need to clean the contract up a bit, so I'll do both of those and post again when I've done some experimentation.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/enigmampc/SecretNetwork/issues/29#issuecomment-803509277, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADXUAAZX6II7VYUOKHBTLF3TEVW7ZANCNFSM4K53UF2A .

-- Can Kisagun Cofounder www.enigma.co | Start building with Enigma https://blog.enigma.co/the-developer-quickstart-guide-to-enigma-880c3fc4308