Karel from ArkaneNetwork asked me whether it is possible in aeternity to let another account pay the fee for a transaction.
From my point of view this is currently not possible with regular accounts. Might this be possible when using a generalized account? But it would for sure be important that the user still has full control over the account and the other account couldn’t perform any transaction without confirmation of the users account.
The question is coming up regarding user friendliness. Games and Apps could then hide even more blockchain complexity for the enduser by paying the transaction fees for them. Users would then be able to send tokens within a game while the game provider would pay their fees.
Yes, with plain regular accounts it is certainly not possible.
With generalized accounts there are more possibilities, however, all Aeternity transactions have “the acting party” paying the fee so if account A is doing a plain Spend TX, A is paying the fee.
In the end, using contracts, it should be possible to set something up. I’m thinking something along the line of the “user” being represented by a contract that is setup to trust the “game provider”'s generalized account, but also doing its own nonce handling and signature check (to avoid replay attacks)… NOTE: I haven’t spent a very long time thinking about this, so there might by holes in such a plan and care should be taken!!
As Marco already pointed out I would love to see this feature in Aeternity. Being in the frontend of making dapps more user-friendly, one of the major roadblocks I see is the need of end-users having to own AE tokens. Which might make sense from the blockchain side of thing, but not at all from the application/end-user point of view (at least not in the current age).
If I want to build a mainstream app using Aeternity I will have to force my users to get AE tokens, which is a major on-boarding hurdle. Remember those users just want to use my app, they might not know what blockchain is, what a token is, what a centralized exchange is. Let alone that they would be willing to pass a utility bill to get validated on an exchange to finally get tokens, learn how to transfer them, to finally end up back to the initial app and start the onboarding process of the app.
I hope you understand that building an app in the current state will only attract people from within the blockchain community. Or apps will be created which will have minimum blockchain integration.
But being able to pay for a user’s transactions, allows me to create dapps without expecting my end-user to fully understand blockchain and own AE tokens. I would be able to build a game running on AE where the game pays for the tx costs and the end-user pays with a credit card to the game studio. Transaction costs would then be seen as an operating cost.
Once the players are more involved in the game you can start rewarding them back with AE tokens to pull them into the blockchain ecosystem.
At the moment we are building an extension to Arkane, and this feature is a must-have. Even though Arkane supports multiple blockchains there is currently only one that is offering this functionality.
I think the latest python sdk includes an option to make the fee deductible from the amount sent instead of having the fee added to the transaction amount.
This is a feature I was waiting for for a long time to allow sweeping an account.
At the moment we are building our new product on a different chain, but I would love the have Aeternity as a viable option. So any info the decision process would be much appreciated. (Need to get a feel on the timeline)
Would “delegated account” be the right name of this feature? Or “delegated fee account”? Maybe it would be possible to mimic that with smart contract where you would have user’s account numbers or addresses managed by a smart contract but I guess you are looking for more native solution, not a wrapper.
Should be relatively straightforward to add. The most intuitive, I think, way to do it would be to add another transaction PayingForTx where you can sign (and thereby pay the fee for) any other transaction.
I.e. A would still sign the SpendTx from A to B, but C may include the SpendTx in a PayingForTx and sign it, which means that C is paying the fee. Nothing stops C from being the same as B (nor A, but that would be silly…).
And when there are native tokens, maybe even tx fee can be paid with tokens but if we get these kind of requests thought through and specified they can end up in the backlog quickly.
They could then be picked up by existing contributors or someone applies for a small development grant via www.aeternity-foundation.org for implementation.
Overall a very nice idea and i’m sure it has been voiced before (just can’t remember exactly when and where). Thank you @Karel and @hanssv.chain for answering quickly here like always!!
As I considered using Erlang to be an interesting thing and forced myself to think it may be advantage, the other side of me is worrying that there won’t be many independent contributors for Aeternity. I don’t know for sure but I guess the code is very complicated and highly difficult to maintain so if someone want to contribute he would be overwhelmed by it. There might be lower barrier to enter if the protocol would be implemented in Elixir or more widespread language like C++ or Java/Scala.
This would actually work. We might need to adjust the pruning criteria of the transaction pool though: How long would we allow these (actually invalid) transactions to remain in the pool to wait for them to be taken care of by a transaction cost payer (“C”) before they are pruned ?
I could see huge amounts queueing up, of which only a small amount will ever be signed.
Also, there might be the situation where C wouldn’t be able to take care of all the TXs he would like to. The remaining ones would be discarded then, leading to an unpleasuring user experience.
But all in all, we should tackle that. Also, the PayingForTx should be able to take a set of TXs right away
(Although here we would rely on a “perfect” transaction propagation, all referenced TXs must be in the miner’s mempool then, the more you want to handle in one PayingForTx the higher the risk will be. How many % of all TXs end up on how many % of the nodes @hanssv.chain ? (I know I should ask michal, not sure about his forum handle though) )
If I understand @hanssv.chain suggestion correctly, it’s about adding new PayingForTx support in the protocol that would be added to the mempool as valid transaction because it must be signed before posting by A, B and C together. Not that A and B post the transaction in the network and C picks up and sign. So to say, the signing is client side only.
I love the composition idea of @hanssv.chain btw (similar the GA meta )
Yes, @dincho.chain is interpreting my idea correctly. The PayingForTx is standalone and would contain the transaction(s) it is paying for.
If the inner transaction(s) are posted to the mempool is a matter of taste, the risk is that they are picked up by a miner (and the original signer pays if there is sufficient funds in that account).
but if we get these kind of requests thought through and specified they can end up in the backlog quickly.
(similar the GA meta