CIP-???? | Wallet api.signTxs() method

[MartinSchere]

Motivation

Currently, there is no way to sign multiple transactions in bulk, and the experience of signing a chain of transactions is suboptimal. This is because the standard signTx method does not provide the wallet with a way to resolve a (yet) nonexistent input.

Description

We propose the addition of a signTxs method that enables wallets to create an array of interconnected transactions and sign them all at once. This new method improves the signing experience by allowing for bulk transaction signing.

[L-as]

Transactions cannot share the same inputs (unless these are reference inputs), so input selection has to be performed carefully.

Some times you send off mutually exclusive transactions of which only one can succeed. This is very useful for that. Hence, I request that you remove this artificial limitation.

[MartinSchere]

@L-as Edited!

[L-as]

LGTM but why all the formatting changes?

[MartinSchere]

My formatter I guess, we are missing a .editorconfig in this repo (cc @KtorZ)

[KtorZ]

I have no particular issue with this change and the motivation behind it. Yet I have an issue with the lack of versioning / extension mechanism on CIP-0030.

CIP-0030 has been effectively implement by many wallet providers and dapps alike as of today. So altering the current interface makes it hard to track what version wallet providers are supporting and what functionalities can DApps actually expect.

[rphair]

@KtorZ - didn't we discuss at one of the CIP meetings, around the time CIP-0030 was merged, some kind of versioning system that would allow wallets to indicate or query support for certain features? If I'm not simply remembering incorrectly, whatever happened to that?

[Scitz0]

@KtorZ - didn't we discuss at one of the CIP meetings, around the time CIP-0030 was merged, some kind of versioning system that would allow wallets to indicate or query support for certain features? If I'm not simply remembering incorrectly, whatever happened to that?

Further discussion about the extension/versioning of CIP-30 can be had here:
#446

[Scitz0]

Can we get the editors group to look at this one again?

We are about to add this extension to CIP-30 in Eternl and I want to do it the "proper" way by having it added as an extension to CIP-30. That would mean giving this CIP its own CIP number. Dapps would then request access to it the established way by providing extension object in enable call. It would be up to the wallet to decide if this should yield an additional request for access in addition to cip30 but from our perspective it wouldn't and if cip30 access is granted, it would automatically allow signTxs() as well.

Any changes to the text needed to finalize this CIP?
If so, please specify what.

[rphair]

@Scitz0 so we can all agree on exactly what is most urgently needed, please see the current discussion about namespacing (#577) and make a comment there (cc @Ryun1). It could be what what you are looking for will be accomplished by naming your extension points uniquely: though the current plan is to group these into a cipXX type namespace & so indeed this would likely need a unique CIP number.

[Scitz0]

I have looked at that namespacing PR yes and would make this available under api.cipXX.signTxs() to align with that PR.

[rphair]

@Ryun1 @KtorZ @MartinSchere I assume this means this PR would have to be re-cast as an independent CIP so it can be assigned its own CIP number?

[Ryun1]

I assume this means this PR would have to be re-cast as an independent CIP so it can be assigned its own CIP number?

Yes, this PR should be changed to be a new CIP 🙏

[Scitz0]

I will whip up a new CIP PR based on content from this one later tonight or tomorrow.

[rphair]

Superseded by #587 with the same purpose & scope.