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
About the commitment of the header to the sections. There are only the hashes of the code and data section in the header and other commitments are placed in the Data section if needed. This looks good but there might be room for an attack on the encrypted sections.
Fees are paid when the entire tx is included in the block: in the following block we decrypt the sections and do validation. If this validation fails we can avoid executing the transaction but the problem is that the wrapper’s signer has already paid the fees, suffering an economic damage.
The text was updated successfully, but these errors were encountered:
Agreed that the encrypted section can be modified by an attacker, and that this would be discovered too late. I believe this issue also applies to all other section types. For example, the ExtraData of a transaction is only fetched/validated during transaction WASM code execution (only occurring after decryption is complete). So if an attacker were to remove such a section, the wrapper fees would be taken before transaction tampering is detected. No?
Yes, I think this issue applies to all of the sections that are included in transaction. If I recall correctly what you explained me, we "encrypt" all of the sections except for the signature on the Header. Except for this signature, I think all of the other sections need a commitment in the header to prevent tampering. Note that this doesn't have anything to do with the encryption per se, we'd need the commitment even if all of the sections were in plaintext.
In short, we just need a way to verify that the payload (sections) of a transaction is the intended one
About the commitment of the header to the sections. There are only the hashes of the code and data section in the header and other commitments are placed in the
Data
section if needed. This looks good but there might be room for an attack on the encrypted sections.Fees are paid when the entire tx is included in the block: in the following block we decrypt the sections and do validation. If this validation fails we can avoid executing the transaction but the problem is that the wrapper’s signer has already paid the fees, suffering an economic damage.
The text was updated successfully, but these errors were encountered: