CIP-0030 | deprecate signTx & add chain signing

[SebastienGllmt]

The signTx endpoint for the dApp connector needs to change. The way we used to have a list of arguments with an optional argument makes any breaking change in the future extremely tedious. It's much better to just provide a JSON object so we can add new features to it

One of the reasons I want to do this is so that we can add the ability for dApps to request signing a chain of transactions. We can achieve this by having the dApp itself provide hints about the contents of the input for the next transaction even if they don't appear on-chain yet.

FAQ

Q: Can't wallets just keep track of pending txs so they know how to sign other transactions in the chain
A: This doesn't work in the generic sense. Here are some cases where this approach would fail:

• Some of the inputs may not belong to the user (ex: the dApp may have its own transactions it needs to broadcast as part of its flow)
• There is no guarantee the dApp submits transactions through the wallet's submit endpoint

[SebastienGllmt]

The main part I'm not entirely sure about is whether or not these input hints should be the full transaction or just the tx body. For chaining transactions, you just need the tx body. For things like data hints of script hints, we could make these separate fields instead of putting this all as part of the same field (esp. if we think providing hints for these things may require building mock transactions). Open to thoughts on this.

[longngn]

I have a question, why can't we just sign continuing txs by calling signTx multiple times? Does the wallet implementation check for existing input and throw error if inputs don't exist whenever we call signTx? If this is the case, then isn't the solution is to change the wallet implementation to not check for existing inputs?
On a side note, to support chaining tx, I think we would also need support on the infrastructure side (i.e. Blockfrost) to submit multiple txs in a single API call to the same node

[SebastienGllmt]

@longngn if the wallet doesn't have access to the input, it can't know which input should be signed with which key

[SebastienGllmt]

I asked around and it seems nobody needs the full tx so just the tx body should be enough for everyone

[MarcelKlammer]

To present the user will all information about a transaction, including metadata, I would like to see transactions instead of transaction bodies as hints.

[SebastienGllmt]

@MarcelKlammer do you have any use case in mind that would require seeing the metadata of the transaction that created the input that is being consumed in the tx?

[MarcelKlammer]

Apart from Allowing to review all non on-chain transactions at once that let to this input, no.

[MarcelKlammer]

Apart from Allowing to review all non on-chain transactions at once that let to this input, no.

[mangelsjover]

This is on hold until the governance path can be discussed on CIP 30.

[KtorZ]

@SebastienGllmt would you mind providing a quick update on that one? Is still relevant / has it been added to CIP-0030 implementations already?

[SebastienGllmt]

This is still an important CIP that should be implemented. It just got caught up in the CIP30 governance discussion and so it stalled waiting for a decision on that front despite the PR being approved by other wallet providers

[rphair]

That's good to know @SebastienGllmt but then this needs a rebase on CIP-0030 in master particularly after the changes in #446. I tried to resolve the merge conflict but it would have involved taking material from both sides & so would have had to ask you to proofread the result anyway.

[Ryun1]

Hey @SebastienGllmt ,

This proposal was discussed today in CIP editors call 68. Are you still interested in pursing this amendment or perhaps there has been a work around discovered? because as it stands I do not think it is advisable to continue to alter CIP-30. Rather I would strongly recommend any more alterations to CIP-30 utilize the extensibility mechanism introduced in #446. This is to avoid the past issues of versioning of CIP-30 for both dApps and wallets, see #446 for discussions.

I would suggest packaging this in with other CIP-30 amendments (such as #443 and/or maybe #206) to create a multi-functional CIP-30 extension. I mentioned this idea in this issue comment. Would you be willing to pursue something like this?

[MartinSchere]

We would like to re-visit this PR. It's important now that more dApps are using transaction chaining.

[Unity-ADA]

We would like to re-visit this PR. It's important now that more dApps are using transaction chaining.

Agreed, this PR would benefit the whole of Cardano if it was merged

[Ryun1]

Although I agree that transaction chaining is a great feature to support, altering the CIP-30 base API would be a mistake, due to lack of versioning.
Instead, this would make a great CIP-30 extension, if someone wishes to take this forward.
Although, with the landscape of #587 this might not be needed.

Due to the age of this PR and it not fitting with the current landscape of CIP-30 extensions, I think we can move to close it cc @rphair @Crypto2099

[rphair]

In sympathy with #209 (comment) and the last comments from @Ryun1 I'm closing this by quorum but please @Crypto2099, @SebastienGllmt please re-open (after a proper rebase) if there's a need & someone can carry this forward.