Very nice! Exciting to see this. I'll update the first post with a link.
The version 1 transactions was kept for compatibility sake. I don't plan on changing the format of version 2 transactions. I added the "text:" part in the beginning of the comment so that people could adopt the convention for their own kind of transaction comments, for example "encrypted:HGKJHGYXBgjh5j" or "url:http://example.com" or "reference:12345" or whatever they choose.
For now it's a good add because it allows this sort of easy trapping of the message for folks that aren't comfortable fliflopping between bases and encodings.
The more people can work with it the more people will be attracted to it, for sure. An update that returned it as a parameter of the RPC-JSON transaction data would make adoption easy. At the moment it's a bit of a (realtively easy) trick.
1. grab TX hex
2. Convert to ASCII using common tutorial funciton or native language function
3. use regex to split the ASCII translation of the hex at "text:"
4. second half of the split is the text message. (if one exists)
A check for transaction version may improve overall software efficiency but isn't necessary as a v2 transaciton may not have a message anyways.
Sound reliable enough, with your knowledge of how it actually works?
Are there cases where it will catch "garbage" after the message in the hex?
If it's always the end the length bytes only matter when you're already making sense of the rest of the hex. If you don't parse the actual hex into transaction data locally (and very few will) they're essentially at a random location it seems to me.
Also not to seem awful but I'm totally up for bounties and tips
F6cSj818K2b1DsQWMDVZDRck6TaiNfxEm7
Show Posts
