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