If I counted correctly, attachments start at byte 45.
I think your math is a bit out - looks more like 126 to me - James make sure you find out *correctly* how to determine this (i.e. do *not* hard-code a "magic number").
Even I know not to do that!
I just abandoned using the issue_getTransactionBytes since issue_getTransaction returns it as the "message" field.
I do have some hardcoded parsing stuff to deal with current complexity of JSON. I just didnt want to load in the hansen stuff, it seemed like overkill for the current API JSON requests.
As long as the API doesn't change the nesting depth of the JSON responses, it should be fine. I am also assuming bitcoind responses wont change format. All this is for initial alpha release. Verifying actual peer multisig gateway functionality is what I want to get implemented first. I am using AM data as hints as to what the gateways should do. They are querying the local bitcoind to get the actual unspent amounts, etc.
Of course, we will have to make the gateways sign their response AM's as it would not be good if a client processed an AM with a spoofed deposit address!
It would probably make things a lot safer if all gateway AM's are signed. I think GET_COINDEPOSIT_ADDRESS, NOTIFY_PENDING_DEPOSIT and WITHDRAWAL_REQUEST are ok to broadcast in plaintext, but no sense in letting gateway_AM spam. I think this is what the NXT token is for? I dont see how it would be safe though cuz after the first time it is used, everyone would see it and can use it to spoof.
Maybe if the "website" is actually the destination NXT acct + current block, it would always be different and only the account owner would be able to generate it. If this works, I can put a validation into all AM's to prove that it originates from the NXT account holder (including the gateways), but I dont see a generate token API call, just decode token.
James
