Size limit of message attached to transaction + other questions

General Discussion
#1

I need to know, beforehand, how big can the attachment to transactions in NEM in bytes. This is important because I need to program myself to limit it when creating services on top of NEM.

Another thing, what is the process of creating the addresses from the private key? Couldn't find an whitepaper (maybe I'm blind)

#2

I need to know, beforehand, how big can the attachment to transactions in NEM in bytes. This is important because I need to program myself to limit it when creating services on top of NEM.

Another thing, what is the process of creating the addresses from the private key? Couldn't find an whitepaper (maybe I'm blind)


Right now we limit messages to be 512 bytes.

Addresses get created from public keys. Here is some code:

[code]
private static final int NUM_CHECKSUM_BYTES = 4;

private static String generateEncoded(final byte version, final byte[] publicKey) {
// step 1: sha3 hash of the public key
final byte[] sha3PublicKeyHash = Hashes.sha3(publicKey);

// step 2: ripemd160 hash of (1)
final byte[] ripemd160StepOneHash = Hashes.ripemd160(sha3PublicKeyHash);

// step 3: add version byte in front of (2)
final byte[] versionPrefixedRipemd160Hash = ArrayUtils.concat(new byte[] { version }, ripemd160StepOneHash);

// step 4: get the checksum of (3)
final byte[] stepThreeChecksum = generateChecksum(versionPrefixedRipemd160Hash);

// step 5: concatenate (3) and (4)
final byte[] concatStepThreeAndStepSix = ArrayUtils.concat(versionPrefixedRipemd160Hash, stepThreeChecksum);

// step 6: base32 encode (5)
return Base32Encoder.getString(concatStepThreeAndStepSix);
}

private static byte[] generateChecksum(final byte[] input) {
// step 1: sha3 hash of (input
final byte[] sha3StepThreeHash = Hashes.sha3(input);

// step 2: get the first X bytes of (1)
return Arrays.copyOfRange(sha3StepThreeHash, 0, NUM_CHECKSUM_BYTES);
}
[/code]

On the test net the "version" is 0x98.
#3

thanks for the code Jaguar, is there any chance the size of the message could be lifted (before the need of a hard fork)? I guess having to gzip binary content to fit payload application data in 512 bytes can be kinda limiting, don't you think?

#4

thanks for the code Jaguar, is there any chance the size of the message could be lifted (before the need of a hard fork)? I guess having to gzip binary content to fit payload application data in 512 bytes can be kinda limiting, don't you think?


I think it is set for V1, but it might be increased in the future.
#5

thanks for the code Jaguar, is there any chance the size of the message could be lifted (before the need of a hard fork)? I guess having to gzip binary content to fit payload application data in 512 bytes can be kinda limiting, don't you think?


we might have longer messages too in future (but it's a bit different topic).
keep in mind currently this is mostly to allow adding data to transaction, so in most cases this is more than enough.