Top-up ritual to extend duration

[cygnusv]

This requires some small additions to Coordinator and the FeeModel. See #86 (comment)

[cygnusv]

• Ritual authorities may want to allow/disallow third parties to top-up and extend a ritual duration. We need to create a flag in the ritual struct in the Coordinator for this. I'd propose that the default is to disallow extension, but open to discussion. Note that the "sponsor" that tops up doesn't gain any sort of power in the ritual; the authority remains the same.
• 2 types of top-ups:
  • Stable top-up: ritual is extended for a duration that's within the deauthorization horizon for all cohort members
  • Catalytic top-up (sorry, can't think of a less exotic name): the desired extension is beyond
• We need to define a maximum extension. This only affect each individual extension, so a ritual could potentially live forever assuming it's extended regularly, but it shouldn't be possible to extend a contract for an absurd duration in one go. This has the implication that we also need a consistent maximum duration for ritual initialization.

[jdbertron]

In my scenario, the end-user fetches the ritual to encrypt their own data, for someone else to retrieve a year later. i.e. Alice=Enrico. Alice dies and suddenly the condition allows any Bob to decrypt Alice's data. But Alice doesn't own the ritual.
Obviously, if the ritual isn't funded, this is a problem, since the data becomes undecryptable forever.

[cygnusv]

In my scenario, the end-user fetches the ritual to encrypt their own data, for someone else to retrieve a year later. i.e. Alice=Enrico. Alice dies and suddenly the condition allows any Bob to decrypt Alice's data. But Alice doesn't own the ritual. Obviously, if the ritual isn't funded, this is a problem, since the data becomes undecryptable forever.

I think this can be safely implemented:

• You mention that Alice doesn't own the ritual, so Alice can just renounce to the authority. Although I'm wondering what happens if Alice is still alive in the future but just changes her mind – shouldn't her remain the authority in any case?
• The ritual can be configured by Alice to accept top ups, as proposed in this issue, and she can arrange to have an out-of-protocol procedure to perform this TXs (something like a bot or even better, an MEV-triggered auto-extending contract)

[jdbertron]

* You mention that Alice doesn't own the ritual, so Alice can just renounce to the authority. Although I'm wondering what happens if Alice is still alive in the future but just changes her mind – shouldn't her remain the authority in any case?

* The ritual can be configured by Alice to accept top ups, as proposed in this issue, and she can arrange to have an out-of-protocol procedure to perform this TXs (something like a bot or even better, an MEV-triggered auto-extending contract)

Sorry I wasn't clear. Maybe there's a distinction between owning the ritual and being the authority ?
Alice is our end user and they won't pay for a ritual each, it's too much, so Alice is never the authority, we are. We just authorize her as an encrypter of her own data (asynchronously, after the fact).
I'll have to look up what the MEV-triggered auto extending contract means.
I think allowing external top-ups is good enough for us here.

[cygnusv]

Sorry I wasn't clear. Maybe there's a distinction between owning the ritual and being the authority ?

No, it's the same thing. I think I understand now what's the confusion – I'll explain below.

Alice is our end user and they won't pay for a ritual each, it's too much, so Alice is never the authority, we are. We just authorize her as an encrypter of her own data (asynchronously, after the fact).

I think using the name "Alice" here is what got me confused. To be honest, I've been pushing towards transitioning away from the Alice/Bob/Enrico narrative, particularly from Alice, since it actually tells you nothing about the role in the system and can lead to misunderstandings.

Having said that, and after re-reading your explanation, what I understand is that bqETH is the authority, your users are encryptors, which you as the authority can individually authorize, and each encryptor will define the conditions for their own consumers. Is that right?

I'll have to look up what the MEV-triggered auto extending contract means. I think allowing external top-ups is good enough for us here.

Sorry if I was a bit cryptic there, it was a spur-of-the-moment idea and I was on my phone. Let me explain that a bit. A simple approach to trigger permissionless Ethereum transactions is writing and operating a bot that just fire these transactions; of course, this has the complication that you need to run this script periodically (maybe in your case is not a complication, though). A more complex approach is making use of the fact that there's a pool of MEV bots in Ethereum looking for profit and sometimes you just need a bit of bait. Imagine you write a contract that you can simply keep funded and that only has a public method that does two things: (1) tops ups your ritual when some condition is satisfied, e.g., if your ritual is 1 week about to expire, and (2) gives a small tip to anyone that calls the contract. This way you don't need to run anything, you just need to be sure your contract is funded for enough top-ups plus tips.

[jdbertron]

Yep, you understood correctly. And yes, the MEV idea is a possibility for funding. Thanks !

[arjunhassard]

Ritual authorities may want to allow/disallow third parties to top-up and extend a ritual duration. We need to create a flag in the ritual struct in the Coordinator for this. I'd propose that the default is to disallow extension.

I thought about this a little more and I'm concerned this gives too much power (or misuse surface) to the cohort authority, in that they could deliberately or inadvertently undermine the 6 month global availability horizon in its utility as a safety feature. I.e. if they disallow third parties to top-up, then in the event they discontinue sponsorship, there's no recourse for end-users or other stakeholders to extend the ritual beyond whatever is time is remaining. Perhaps we can universally force ritual extension to become permissionless as soon as a payment is missed – if one month passes without the authority/sponsor paying, then anyone can become the sponsor, but during those rolling 30 days, only the authority can be the sponsor.

Catalytic
"conditions in which organisms are degenerating toward sterility, as a result either of too wide cross-breeding or of too narrow inbreeding"
this sounds like a very niche criticism of insiders/cartel control of a network and driving it towards obsoletion

[jdbertron]

Maybe it's a flag at origination.

…

On Nov 10, 2023 at 8:25 AM, Arjun Hassard ***@***.***> wrote: > > > Ritual authorities may want to allow/disallow third parties to top-up and extend a ritual duration. We need to create a flag in the ritual struct in the Coordinator for this. I'd propose that the default is to disallow extension. > > I thought about this a little more and I'm concerned this gives too much power (or misuse surface) to the cohort authority, in that they could deliberately or inadvertently undermine the 6 month global availability horizon in its utility as a safety feature. I.e. if they disallow third parties to top-up, then in the event they discontinue sponsorship, there's no recourse for end-users or other stakeholders to extend the ritual beyond whatever is time is remaining. Perhaps we can universally force ritual extension to become permissionless as soon as a payment is missed – if one month passes without the authority/sponsor paying, then anyone can become the sponsor, but during those rolling 30 days, only the authority can be the sponsor. > > > Catalytic > "conditions in which organisms are degenerating toward sterility, as a result either of too wide cross-breeding or of too narrow inbreeding" > this sounds like a very niche criticism of insiders/cartel control of a network and driving it towards obsoletion > > — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>