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
The attachment spec for transaction type 22, subtype 0 (createATProgram) is fields 'name', 'description' and 'creationBytes'. While name and description have a byte or a short to specify the field length, there is no size information for creationBytes.
This would not be a problem if all fields in creationBytes had defined sizes, but due to the strange length for field 'data', a transaction with just 1 datapage can have the 'data length' zero if there is no 'data' or if 'data'.length == 256.
This is not a problem in the node, because the attachment is stored in a specific database field, so the 'creationBytes' size is know, and the correct data length can be assumed from buffer size in that specific case.
But, when trying to parse the unsigned bytes without access to the database, the data stream can have additional bytes for the attachments defined on flags bits (i.e: 'message').
In this very specific case, it is impossible to parse the unsignedTransactionBytes.
Possible corrections
New attachment version for transaction type 22 subtype 0, adding size info for creationBytes field.
Update creationBytes version, use current unused reserved location (short) to indicate total size
Develop a new creationBytes version, creating a new data structure without the messy code for code length and data length.
The text was updated successfully, but these errors were encountered:
Is this for checking if the transaction bytes match when you get the transaction bytes from the node? In that case the sender already knows all the information (which is being checked). Assuming this is the case, is it not possible to parse the content?
It possible, but the goal is to have a function that can parse unsignedTransactionBytes without any prior info. In theory, the transaction bytes shall contain all information within its bytes. If this is not possible, then there is a problem in the implementation logic.
Currently the workaround is to assume that there is no [messageToEncrypt | encryptedMessageData | messageToEncryptToSelf | encryptToSelfMessageData], what is true almost always.
The attachment spec for transaction type 22, subtype 0 (createATProgram) is fields 'name', 'description' and 'creationBytes'. While name and description have a byte or a short to specify the field length, there is no size information for creationBytes.
This would not be a problem if all fields in creationBytes had defined sizes, but due to the strange length for field 'data', a transaction with just 1 datapage can have the 'data length' zero if there is no 'data' or if 'data'.length == 256.
This is not a problem in the node, because the attachment is stored in a specific database field, so the 'creationBytes' size is know, and the correct data length can be assumed from buffer size in that specific case.
But, when trying to parse the unsigned bytes without access to the database, the data stream can have additional bytes for the attachments defined on flags bits (i.e: 'message').
In this very specific case, it is impossible to parse the unsignedTransactionBytes.
Possible corrections
The text was updated successfully, but these errors were encountered: