-
Notifications
You must be signed in to change notification settings - Fork 1.2k
relaxing timepoint constraint for multisig #2735
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
Changes from 10 commits
Commits
Show all changes
19 commits
Select commit
Hold shift + click to select a range
5a11e1c
relaxing timepoint constraint for multisig
ozgunozerk 72a2125
documentation fixes
ozgunozerk 27a54ef
improve docs
ozgunozerk b5c8889
cancel without timepoint extrinsic
ozgunozerk 643f20d
suggested documentation improvement
ozgunozerk cd02b50
enforcable optional timepoint
ozgunozerk 6077b6b
typo
ozgunozerk 305e90c
migrations
ozgunozerk 983c2d6
Merge branch 'master' into multisig-relax-timpoint
ozgunozerk efb41c1
tests
ozgunozerk 32e6d86
multi block migrations
ozgunozerk 5072048
Merge branch 'master' into multisig-relax-timpoint
ozgunozerk 0dfa81b
prefix
ozgunozerk b1ec993
fix cargo check errors
ozgunozerk 73b1fd6
Merge branch 'master' into multisig-relax-timpoint
ozgunozerk 675dc26
import MigrationId
ozgunozerk 0a694b2
Merge branch 'master' into multisig-relax-timpoint
ozgunozerk 2346f13
storage version added
ozgunozerk c835da5
Merge branch 'master' into multisig-relax-timpoint
ozgunozerk File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally i think that the level of security should be decided upon by the approvers - not the creator.
Now the creator can trick the approvers into also approving all future versions by using
None.When the timepoint is always present, then the approvers can decide ad-hoc if they want to approve just this single call by sending
Some(_), or if they want to also approve all future versions of this by usingNone.This is very similar to immortal transactions.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a UI dev using these pallets a lot, this sounds like worsening the DX:
Zooming out, this PR was supposed to make DX better. My opinion is that it's not the case. As an implementer, I used to send
Nonewith the first tx, and managed to find the timepoint for the subsequent approvals, it's 1 call to make. It was actually easier than having to think about all this IMHO.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Tbaut, valid points, I mostly agree, but mostly.
Here is my take (from the issue #2541):
In short, with the current state of this PR, we achieve the following:
timepointis clearly explained.timepointis not a necessity anymore for the most use cases)As to your points:
I'd argue against you have to understand more. This PR does not introduce a new concept.
Timepointwas already there, and the purpose of thetimepointhas not changed. We are just making it optional because for the most multisigs, timepoint is an overkill. In other words, this PR just makes the purpose of everything clear imo.Yes, you need to. But examples and reasonings behind those are explained clearly in the docs. I'd again argue against worse UX, because previously we still had to provide timepoint, and the reason for that was not clear. The explanation for the
timepointshould have been there in the UX in the first place imo.Yes, if anyone has a suggestion on the defaults, I'm all ears.
I believe it still does, a lot!
If you don't care about the
timepoint, you can still sendNoneand everybody else will sendNone. Previously, this was not possible, even for the multisigs that do not needtimepoint, every approver had to providetimepointand finding thetimepointis not easy as I explained above from the perspective of the approvers.From my perspective, when zoomed out:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I should probably have said it from the beginning. I think this first assumption, that it's hard to get the timepoint of a multisig tx, is IMHO, wrong. Maybe because of the api you're using. It's literally one state call, that you must do in any case to know the currently pending multisig txs. Then the info is in the storage, here's an example of a pending multisig tx:

Let's not confuse things. DX is my experience implementing this, UX is the experience of users of my application. I want to build applications that have good UX, and I don't want to feature creep them by adding options that users have no idea about. I should take the best decision for them. If the best decision is the safest decision at no additional cost for my users, and a minimal cost for me (my DX, my time) then I should include the timepoint... because.. it isn't hard IMHO.
Now I'm not willing to die on this hill, I just left this comment to give my opinion. To me it's a feature creep. I've implemented this in JS, there's been millions of hard things, retrieving the timepoint wasn't one of them. It's
api.query.multisig.multisigs.entries(address)-> iterate over the stroage, thenstorage[1].toJson().when. I may be missing something, it may be hard in other languages, but it would mean that getting the pending multisig txs is also hard to start with.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand your concerns. I just wanted to fully explain my reasoning above, that's all!
Thanks for the conversation, appreciated 👍 🙏
This PR is old, and the related issue was opened when I first tried to understand the
multisigpallet back then. I still thinktimepointas is, will be confusing for newcomers. And maybe I don't know how to do it, but from what I recall, one cannot easily approve a multisig in a browser (polkadotjs app). As you mentioned, they have to execute some code afaik:And I just think this requirement shouldn't be there in the first place for the majority of the multisigs (or at least, there should be an explanation on the UI side on why timepoint is required).
But after all, these are my subjective takes :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're mistaking. UIs have all they need to find and fill the timepoint. If Pjs apps isn't good at something, it's not with the timepoint, it's with the
callData. Which is a whole other beast. And this is worked around by many UIs including one I build, Multix, more info about this workaround here. Now this issue is the subject of an RFC: polkadot-fellows/RFCs#74