Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
deleterium opened this issue Nov 15, 2022 · 3 comments
Labels
enhancement New feature or request fork-hard Fixing this will require a hard fork.

Comments

@deleterium
Copy link

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.
@ohager ohager added enhancement New feature or request fork-hard Fixing this will require a hard fork. labels Nov 15, 2022
@jjos2372
Copy link

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
Copy link
Author

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
Copy link

On node code the AT creation transaction can handle it based only on the byte array here:

AutomatedTransactionsCreation(ByteBuffer buffer,

Code length and all else is obtained from the bytes themselves. Number of code pages is on the byte array:

short codePages = buffer.getShort();

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request fork-hard Fixing this will require a hard fork.
Projects
Feature Roadmap
Awaiting triage
Development

No branches or pull requests

3 participants