Impossible to parse UnsignedTransactionBytes in 'createATProgram' with message attached.

[deleterium]

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.

[jjos2372]

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?

[deleterium]

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.

[jjos2372]

On node code the AT creation transaction can handle it based only on the byte array here: https://github.com/signum-network/signum-node/blob/655890cfb43a88c8749aeae8032b7963ab2b02b8/src/brs/Attachment.java#L2297

Code length and all else is obtained from the bytes themselves. Number of code pages is on the byte array: https://github.com/signum-network/signum-node/blob/655890cfb43a88c8749aeae8032b7963ab2b02b8/src/brs/Attachment.java#L2312