You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A company may want to pay validator fees for a user and/or explicitly authorize protected actions on behalf of a user.
Proposal 1:
New instruction type that allows paying fee with explicit signature
Proposal 2:
Multiple transaction signers with either sign fee and main separately or assign signatures to instructions
Proposal 3:
Since signers know what they are signing, we could perhaps simply have a list of signers of the transaction. Each would not sign unless they were happy with the calls i.e. know. that the transaction does not have any unforeseen state changes, so there may not be a need to have find-grained/per-instruction signers. This needs to be evaluated.
The radix transaction model has a list of signers and each signer generates a virtual public key badge at runtime. A notary PK is specified in the UnsignedTransaction. One or more signers sign to create a SignedTransaction. Then the "notary" signs the to create a NotarizedTransaction. The notary has the final say as to if the transaction should be submitted and prevents the malleability of the other signers.
The text was updated successfully, but these errors were encountered:
I also like the idea of having a Relayer. Basically I have Mikecoin, and I want to send Mikecoin. I then create a transaction spending Mikecoin along with some fees (in mikecoin) to a relayer. The relayer collects a bunch of mikecoin transactions, makes a payment of mikecoin to themselves and publishes it, paying the XTR fees. It then at a later stage swaps the mikecoin for XTR.
It would be nice to have an indexer that is easily configured to run as a relayer for mikecoin transactions
Problem/Use case
A company may want to pay validator fees for a user and/or explicitly authorize protected actions on behalf of a user.
Proposal 1:
New instruction type that allows paying fee with explicit signature
Proposal 2:
Multiple transaction signers with either sign fee and main separately or assign signatures to instructions
Proposal 3:
Since signers know what they are signing, we could perhaps simply have a list of signers of the transaction. Each would not sign unless they were happy with the calls i.e. know. that the transaction does not have any unforeseen state changes, so there may not be a need to have find-grained/per-instruction signers. This needs to be evaluated.
The radix transaction model has a list of signers and each signer generates a virtual public key badge at runtime. A notary PK is specified in the
UnsignedTransaction
. One or more signers sign to create aSignedTransaction
. Then the "notary" signs the to create aNotarizedTransaction
. The notary has the final say as to if the transaction should be submitted and prevents the malleability of the other signers.The text was updated successfully, but these errors were encountered: