Allow transaction fee being payed by another account

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).

Ah okay, got you. Yes, that should work out. The SDKs could get a SignAndPost function, that would make wallet providers like baseapp and waellet sign and POST a tx to some API, which should - if the tx is accepted by the payer - return a TX receipt. Additional authentication info shouldn’t even be necessary, the backend should already be aware of the user’s (wallet)address/pubkey and could use ecverify to ensure the TX to be paid for is originated from a legitimate source.

The inner transaction is also signed, so it is also self contained, no need to keep track of user’s pubkey, etc. to verify it is legit. (Though keeping track of what accounts may get their TXs payed for is probably a good idea :slight_smile: )

1 Like

This is the first real case I see of a DDoS in the network. Because those transactions could overflow the mempool.

Now to add insult to injury, what if it allowed to exchange the token for ae, so someone could absorb the tokens for AE by paying the transaction fee? Sounds risky, and complicated, but I am pulling a James Ko / Whyarewehere42 and just throwing a silly idea against the wall. :stuck_out_tongue:

as @dincho.chain mentioned these transactions would only be added to the mempool if fully signed by all participants beforehand. haven’t you read that in the thread history? :thinking:

I said DDoS as this can possibly saturate the mempool. Because those transactions won’t be written until after they all signed it. So, wouldn’t those stay in the mempool until either discarded or completely signed by everyone? hence… likely mempool saturation.

Perhaps you haven’t read my message completely in the history? :thinking:

Saturating the mempool is trivial, that can be done without a new transaction type…

Only fully signed transactions are normally allowed into the mempool, and that was what I intended the PayingForTx to be, so the mempool aspect of this is not very exciting I think.

Now this is a useful response. so you are saying the me pool can be saturated with no issues but it is also able to handle it? That’s good to know

Yesterday we were discussing this topic and I made a proposal for it. It looks that it’s similar to what’s discussed here:

I think it is complementary - what is proposed in this thread would work slightly differently - it would be offline, but on the other hand it would work also for a non-GA account.

Yes, it’s complementary.

PayingForTx requires two signatures, two transactions and interaction between two wallets (to create 2 signatures).

In my proposal, there is no interaction required (only one signature and one transaction) Everything stays in the smart-contract. But there is additional gas cost for executing the smart contract function. Would be great to have a very cheap deserializtion.

No, the end result is just one transaction - the PayingForTx - the first actual TX is just the payload of the this outer TX.

@hanssv.chain as this topic is coming back to life again. are there already plans to integrate this feature into the core protocol?

I think it made it onto the agenda for the next hard-fork. There is nothing firm yet and the time scale is rather vague though…

2 Likes

Speculating further, if Generalized accounts are given more power to inspect the transaction, it should be possible to combine a PayingForTx with a GAMetaTx i.e. “signing” the “paying for” by a GA - this should solve all the suggested use-cases I think…

2 Likes

Great to see this discussion happening here in the forum!

this feature will also be available after the upcoming hardfork right?

regarding generalized acounts:

  • currently the contract behind a GA is “set in stone” right? or is it somehow possible to update/change the logic or state afterwards?

how would you combine this? we would need a predefined list of authorized signees with additional logic to prevent abuse right? or would it be possible to update the authorized signees?

It is a normal contract, you can update its state etc.

1 Like

is it also possible to proxy the authorize method to provide an upgradeable authorize method?

No, authorize calls are not allowed to go “to the chain”, i.e. no remote calls, no spends, nothing like that.