Timelocked Account #61
Replies: 6 comments 33 replies
-
|
@bobbinth I'm wondering if this is what you were envisioning or I misinterpreted it? |
Beta Was this translation helpful? Give feedback.
-
|
@bobbinth From the conversation we had today, I have identified 2 use cases that we want to cover here:
So considering this, I have reframed the idea into this 1 Recoverable StateSetupMultisig 2/3 with signers:
Miden AuthAll transactions require 2 signatures,
2 PSM "Delayed Mode"Multisig with 2 thresholds and required PSM signature.
Ways of submission:
Case: Setup of a solo-account with security windowMultisig with 2 signers + PSM - H = 2, L = 1, Window: N blocks Process:
|
Beta Was this translation helpful? Give feedback.
-
|
This change could actually “kill two birds with one stone”:
Related issue: 0xMiden/protocol#2000 We could extend struct TransactionSummary {
// ...
valid_block_height_begin: Felt,
valid_block_height_end: Felt,
// ...
}Here, |
Beta Was this translation helpful? Give feedback.
-
|
Thank you all for participating the discussion above. (@bobbinth @partylikeits1983 and @MCarlomagno )
Some features discussed above might be missing for now but I would like to discuss the current capabilities & additional features: I would like to provide an overview of the current features of the implementation: This account is created by the following setup:
As I read the discussion above, the following feature is missing:
The following questions are still open for me:
I think the next step will be to implement:
|
Beta Was this translation helpful? Give feedback.
-
Delay Large Transfers: (also specified here by @bobbinth 0xMiden/protocol#2143 (comment) I would like to go further and discuss this idea. When I try to implement this inside the authentication component, I see that it’s different from the delay used for key rotation. The reason is that the procedure we call "key rotation" is actually one of the procedures inside the authentication component such as When performing a key rotation update, we can do this by proposing the key rotation, and then, during execute, calling the However, things get a bit more complicated for the “delay large transfers” part. The reason is that there is no specific procedure inside the authentication component dedicated to transfer operations. Let’s assume we “embed” the functionality of the P2ID note into the authentication component (for example To me, it seems more reasonable to implement delaying large transfers in the following way using 0xMiden/protocol#1068 With this idea, the callback returned from the faucet could enforce restrictions if the timelock has not yet expired. What do you think about this? I also think that, instead of introducing a delay for large transfers at the account component level, we could apply the following different security measures independently:
What would be your approach related to delaying large transfer? Do you have any implementation idea in your mind? |
Beta Was this translation helpful? Give feedback.
-
|
@bobbinth Before diving into my questions related to your reply: #61 (reply in thread) I would like to highlight the following: The reason why the propose/execute logic fits well in Safe Multisig is that, in the EVM, we can propose a function call without actually executing it thanks to calldata. In other words, proposing a transaction does not result in any account state change. This allows the function execution to remain pending inside a proposed (or confirmed) transaction until the required conditions are met. In Miden, however, in order to create a If we rely on the This leads me to the following questions: Should we lock the account whenever there is at least one entry in the
Before diving deeper into this direction, I am curious whether this problem could instead be addressed by leveraging notes. As an example, consider the following note script. We could define For However, I am currently stuck on how such a note could be canceled. Even if the above were possible, let us now consider a 3-of-5 multisig scenario:
The question then becomes: how can 3 approvers cancel this note within the same Cancellation would require signatures, but we can not have the signatures directly to the note itself. To support this properly, it should've been a concept such as Another possibility would be to define a For this to work, serial_num, script_root, input_commitment, vault_hash Then, any approver could therefore compute the Nullifier (possibly in the prologoue). The key question then becomes, how can we assign the associated note in the NullifierDB as a non-zero value to cancel it? Would it be possible, at the kernel level, to introduce a procedure that sets the corresponding note in the NullifierDB to a non-zero value, effectively canceling the note? I think this could be included since only people having the full access to the state can change the nullifier. Alternatively, is there a way to implement a mechanism directly in the note script itself that allows reverting/cancelling the note? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Summary
We recently had some conversations about a potential implementation of a Timelocked Multisig (authorized transactions can be executed after some delay). We can achieve this feature using private state manager in combination with existing multisig templates.
Process
timelockin number of blocks.proposed_atattribute for that transactionproposed_at+timelock>current_block.3.a. If false -> the PSM will throw unauthorized error.
3.b. if true -> the PSM will sign and return the signature for authentication.
Sequence diagram
sequenceDiagram participant U as User participant P as PSM Server participant N as Miden Network U->>P: Configure multisig (timelock = X blocks) Note over P: Persist timelock with account metadata U->>P: Push delta proposal P->>N: Query current block N-->>P: block = B₀ Note over P: proposal.proposed_at = B₀ loop Collect signatures U->>P: Sign proposal end U->>P: Execute proposal P->>N: Query current block N-->>P: block = B₁ alt B₁ < proposed_at + timelock P-->>U: Error (timelock not yet satisfied) else B₁ ≥ proposed_at + timelock Note over P: Authorized to proceed P-->>U: Ack signature for execution endBeta Was this translation helpful? Give feedback.
All reactions