Creation of ContractTx (Java-SDK)

mitch_lbw · April 6, 2019, 8:24pm

Hey guys,
we’re currently working on the support of contract operations for the Java-SDK and trying to create a contractCreateTx but struggling with the details to get the contract tx successfully deployed.
If we check the resulting signed Tx with goggles against our local node it seems to be valid, but the resulting deployment ends up in a “bad request”
Does anybody have a hint what’s missing up?
Thanks and regards,
Mitch

Here is the input data passed to the RLP encoded array
abiVersion=1,
amount=0,

callData

cb_AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACC5yVbyizFJqfWYeqUF89obIgnMVzkjQAYrtsG9n5+Z6gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnHQYrA==

contractByteCode

cb_+QPvRgGgeN05+tJcdqKtrzpqKaGf7e7wSc3ARZ/hNSgeuHcoXLn5Avv5ASqgaPJnYzj/UIg5q6R3Se/6i+h+8oTyB/s9mZhwHNU4h8WEbWFpbrjAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKD//////////////////////////////////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA+QHLoLnJVvKLMUmp9Zh6pQXz2hsiCcxXOSNABiu2wb2fn5nqhGluaXS4YAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//////////////////////////////////////////7kBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEA//////////////////////////////////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA///////////////////////////////////////////uMxiAABkYgAAhJGAgIBRf7nJVvKLMUmp9Zh6pQXz2hsiCcxXOSNABiu2wb2fn5nqFGIAAMBXUIBRf2jyZ2M4/1CIOaukd0nv+ovofvKE8gf7PZmYcBzVOIfFFGIAAK9XUGABGVEAW2AAGVlgIAGQgVJgIJADYAOBUpBZYABRWVJgAFJgAPNbYACAUmAA81tZWWAgAZCBUmAgkANgABlZYCABkIFSYCCQA2ADgVKBUpBWW2AgAVFRWVCAkVBQgJBQkFZbUFCCkVBQYgAAjFaqo6ki

deposit=0,
gas=1000000000,
gasPrice=1000000000,
nonce=1,
ownerId=ak_twR4h7dEcUtc2iSEDv8kB7UFJJDGiEDQCXr85C3fYF8FdVdyo,
ttl=0,
vmVersion=3

The resulting unsgined Tx is

unsginedTx

tx_+QYXKgGhAXXumCWtYwljSCuxk5ohKg5TWIPGtNeATkAofh9VbaJyAbkFS2NiXytRUHZSZ0dnZU4wNSt0SmNkcUt0cnpwcUthR2Y3ZTd3U2MzQVJaL2hOU2dldUhjb1hMbjVBdnY1QVNxZ2FQSm5ZemovVUlnNXE2UjNTZS82aStoKzhvVHlCL3M5bVpod0hOVTRoOFdFYldGcGJyakFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUNBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBd0FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFCZ0FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBS0QvLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy93QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBdUVBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFJQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQStRSExvTG5KVnZLTE1VbXA5Wmg2cFFYejJoc2lDY3hYT1NOQUJpdTJ3YjJmbjVucWhHbHVhWFM0WUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQWdBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFQLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vN2tCUUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQWdBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFNQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFZQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFDZ0FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBTUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUJRQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUVBLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vOEFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQS8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy91TXhpQUFCa1lnQUFoSkdBZ0lCUmY3bkpWdktMTVVtcDlaaDZwUVh6MmhzaUNjeFhPU05BQml1MndiMmZuNW5xRkdJQUFNQlhVSUJSZjJqeVoyTTQvMUNJT2F1a2QwbnYrb3ZvZnZLRThnZjdQWm1ZY0J6Vk9JZkZGR0lBQUs5WFVHQUJHVkVBVzJBQUdWbGdJQUdRZ1ZKZ0lKQURZQU9CVXBCWllBQlJXVkpnQUZKZ0FQTmJZQUNBVW1BQTgxdFpXV0FnQVpDQlVtQWdrQU5nQUJsWllDQUJrSUZTWUNDUUEyQURnVktCVXBCV1cyQWdBVkZSV1ZDQWtWQlFnSkJRa0ZaYlVGQ0NrVkJRWWdBQWpGYXFvNmtpA4gbwc4ClCY4AICAgIQ7msoAhDuaygC4i2NiX0FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQ0M1eVZieWl6RkpxZldZZXFVRjg5b2JJZ25NVnpralFBWXJ0c0c5bjUrWjZnQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBbkhRWXJBPT2UFRJa

and the resulting signed Tx is

signedTx

tx_+QZjCwH4QrhAQl7LtSvWmdU/PWBJEznxxTqGZp9avN8E+68pIOS+ImqiEQDXQ6nb9tHVLwXbGNceTRILHLjZhDMiJAP251jAArkGGvkGFyoBoQF17pglrWMJY0grsZOaISoOU1iDxrTXgE5AKH4fVW2icgG5BUtjYl8rUVB2UmdHZ2VOMDUrdEpjZHFLdHJ6cHFLYUdmN2U3d1NjM0FSWi9oTlNnZXVIY29YTG41QXZ2NUFTcWdhUEpuWXpqL1VJZzVxNlIzU2UvNmkraCs4b1R5Qi9zOW1aaHdITlU0aDhXRWJXRnBicmpBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFDQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQXdBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQmdBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUtELy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vd0FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQXVFQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBSUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUErUUhMb0xuSlZ2S0xNVW1wOVpoNnBRWHoyaHNpQ2N4WE9TTkFCaXUyd2IyZm41bnFoR2x1YVhTNFlBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFnQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBUC8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLzdrQlFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFnQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBTUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBWUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQ2dBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU1BQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFCUUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFFQS8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLzhBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUEvLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vdU14aUFBQmtZZ0FBaEpHQWdJQlJmN25KVnZLTE1VbXA5Wmg2cFFYejJoc2lDY3hYT1NOQUJpdTJ3YjJmbjVucUZHSUFBTUJYVUlCUmYyanlaMk00LzFDSU9hdWtkMG52K292b2Z2S0U4Z2Y3UFptWWNCelZPSWZGRkdJQUFLOVhVR0FCR1ZFQVcyQUFHVmxnSUFHUWdWSmdJSkFEWUFPQlVwQlpZQUJSV1ZKZ0FGSmdBUE5iWUFDQVVtQUE4MXRaV1dBZ0FaQ0JVbUFna0FOZ0FCbFpZQ0FCa0lGU1lDQ1FBMkFEZ1ZLQlVwQldXMkFnQVZGUldWQ0FrVkJRZ0pCUWtGWmJVRkNDa1ZCUVlnQUFqRmFxbzZraQOIG8HOApQmOACAgICEO5rKAIQ7msoAuItjYl9BQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUNDNXlWYnlpekZKcWZXWWVxVUY4OW9iSWduTVZ6a2pRQVlydHNHOW41K1o2Z0FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQW5IUVlyQT09rBWeCw==

mitch_lbw · April 7, 2019, 9:41am

Something what we’re wondering - if we analyze the generated tx with goggles, the contractCode and callData seem to have a different encoding type - not sure if this might matter.
f.e. same callData like above then looks like this:
cb_Y2JfQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFDQzV5VmJ5aXpGSnFmV1llcVVGODlvYklnbk1WemtqUUFZcnRzRzluNStaNmdBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFuSFFZckE9PdO8xgw=

hanssv.chain · April 8, 2019, 7:14am

This is the encoding of cb_AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACC5yVbyizFJqfWYeqUF89obIgnMVzkjQAYrtsG9n5+Z6gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnHQYrA== so something is wrong - the calldata should not be encoded twice!

Also the fee is missing in your initial example?

marco.chain · April 8, 2019, 9:25am

this is the call to our SDK which calculates the fee automatically. that’s why the fee is missing here. thanks for your response!

@mitch_lbw does that answer help you?

mitch_lbw · April 8, 2019, 5:26pm

Hi Hans,
the transaction data is what we put in first - and as @marco.chain wrote, the fee is automatically calculated (i also tried with a fixed large one).
My second post shows the transactions callData attribute when we put the signed transaction into the goggles-app - although it says, that the transaction seems to be valid, we get an “bad request” error while deploying the signedTx on the local node.
Actually we’re currently a bit stuck on whats wrong with the tx
Thanks and regards,
Mitch

hanssv.chain · April 8, 2019, 6:44pm

Another idea, too much gas? There is a gas-limit for the microblock, it is 6M, so putting in more than that will make the TX “too large” to fit in a block… (You only pay for the gas used, but you can’t say that there is more available than what can be consumed.)

mitch_lbw · April 10, 2019, 7:42pm

Hi @hanssv.chain,
we’re now able to generate a valid tx (at least for goggles-aepp) - the problem was the wrong encoding of callData and bytecode.

ValidTx

tx_+QTYCwH4QrhA7fHpT3TKdPDy1UeMJJky4b0VVlffgVZ27ZRqAoheUOCz2gVz8edbZBw6oDTz/IoxH6gkq/SJHTQnDQoFTcI6BbkEj/kEjCoBoQF17pglrWMJY0grsZOaISoOU1iDxrTXgE5AKH4fVW2icgq5A/L5A+9GAaB43Tn60lx2oq2vOmopoZ/t7vBJzcBFn+E1KB64dyhcufkC+/kBKqBo8mdjOP9QiDmrpHdJ7/qL6H7yhPIH+z2ZmHAc1TiHxYRtYWluuMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoP//////////////////////////////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC4QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD5AcuguclW8osxSan1mHqlBfPaGyIJzFc5I0AGK7bBvZ+fmeqEaW5pdLhgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA///////////////////////////////////////////uQFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQD//////////////////////////////////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//////////////////////////////////////////+4zGIAAGRiAACEkYCAgFF/uclW8osxSan1mHqlBfPaGyIJzFc5I0AGK7bBvZ+fmeoUYgAAwFdQgFF/aPJnYzj/UIg5q6R3Se/6i+h+8oTyB/s9mZhwHNU4h8UUYgAAr1dQYAEZUQBbYAAZWWAgAZCBUmAgkANgA4FSkFlgAFFZUmAAUmAA81tgAIBSYADzW1lZYCABkIFSYCCQA2AAGVlgIAGQgVJgIJADYAOBUoFSkFZbYCABUVFZUICRUFCAkFCQVltQUIKRUFBiAACMVoMDAAGGWXV0dvoAgICAAQG4YAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAguclW8osxSan1mHqlBfPaGyIJzFc5I0AGK7bBvZ+fmeoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADSA0dw=

Nevertheless the transaction is not deployed on the local node, in the log of the node i can see the following exception
Failed signature check on tx: {error,signature_check_failed}, <<203,117,82,96,10,221,9,92,153,193,25,176,249,93,38,142,201,217,51,51,207,33,69,2,202,18,56,85,53,213,202,61>>
This is a bit strange, because the goggles-aepp is able to validate the signature of the tx…

We also tried different gas and gas price values and fees, all ending up in the same node exception.
Do you have any idea where to point our noses to?
Thanks,
Mitch

hanssv.chain · April 10, 2019, 9:07pm

If the node says the signature is wrong it is probably wrong… (at least in the eyes of this particular node!)

Have you used the correct network id when signing?

marco.chain · April 10, 2019, 10:31pm

in our integrationTest we use ae_devnet as network id and our TransactionService is configured to use ae_devnet for signing. so this shouldn’t be the problem as the same Service is being used to sign a spendTx (which is published successfully). but we will doublecheck that!

is it possible that ae_devnet is an invalid network id for certain transaction types?

hanssv.chain · April 11, 2019, 7:04am

No, there is no discrimination on network id and transaction type…

If I decode and deserialize the transaction tx_+QTYCwH4... I get a signed contract create, but the signature cannot be verified with ae_devnet as the network id, so I agree with the node Very hard to tell what has gone wrong, but either you signed the wrong thing or used the wrong key (but I guess that is true for all failed signature checks so it isn’t much of an advice…)

marco.chain · April 11, 2019, 7:42am

ok now we know at least where we need to look at.

we temporarily assumed the network id is the problem but didn’t check that because as already mentioned other tests are making use of the same TransactionService instance and they should all use the same sign config which is configured to ae_devnet. probably there is somewhere a new instance of the configuration created which points to ae_uat by default

thanks!

marco.chain · June 2, 2019, 11:45am

so we are working again on this topic and we just can’t find the issue we are facing. we run goggles against our local node and it verifies our contract with the message your transaction looks good.

when we try to post exactly this transaction to the network we always get an error Bad Request with no further information.

the signedTx is:

tx_+QTmCwH4QrhACoRggcOsoye3P18WAS8Aq6a9sv4QWm1FqQ8QobSM3SCJfkLh6pt2lFkygTKTtFptVyvc2eGsu8LcQBjt1BMTA7kEnfkEmioBoQF17pglrWMJY0grsZOaISoOU1iDxrTXgE5AKH4fVW2icgG5A/j5A/VGAqB43Tn60lx2oq2vOmopoZ/t7vBJzcBFn+E1KB64dyhcufkC+/kBKqBo8mdjOP9QiDmrpHdJ7/qL6H7yhPIH+z2ZmHAc1TiHxYRtYWluuMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoP//////////////////////////////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC4QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD5AcuguclW8osxSan1mHqlBfPaGyIJzFc5I0AGK7bBvZ+fmeqEaW5pdLhgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA///////////////////////////////////////////uQFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQD//////////////////////////////////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//////////////////////////////////////////+4zGIAAGRiAACEkYCAgFF/uclW8osxSan1mHqlBfPaGyIJzFc5I0AGK7bBvZ+fmeoUYgAAwFdQgFF/aPJnYzj/UIg5q6R3Se/6i+h+8oTyB/s9mZhwHNU4h8UUYgAAr1dQYAEZUQBbYAAZWWAgAZCBUmAgkANgA4FSkFlgAFFZUmAAUmAA81tgAIBSYADzW1lZYCABkIFSYCCQA2AAGVlgIAGQgVJgIJADYAOBUoFSkFZbYCABUVFZUICRUFCAkFCQVltQUIKRUFBiAACMVoUzLjAuMIMDAAGHFaqpnrhYAICAgINbjYCEO5rKALhgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACC5yVbyizFJqfWYeqUF89obIgnMVzkjQAYrtsG9n5+Z6gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/tVBgA==

here the screenshots:

@hanssv.chain: any ideas whats going wrong here?

hanssv.chain · June 2, 2019, 3:14pm

Too much gas? 6000000 won’t fit in a microblock. Also VMVersion 196609 looks strange… And where is the ABI-version? Though neither of these should give you a “Bad Request” that sounds more like you are doing something wrong at the HTTP API layer?!

I’m not in front of a computer so I can’t decode the actual TX…

marco.chain · June 2, 2019, 4:01pm

thx for the quick response!

when I remember right you told me that 6m is the maximum amount of gas to be used, but I might be wrong here. I updated the example and am using the same calldata and bytecode https://testnet.contracts.aepps.com/ uses.

again, goggles (running against local node with ae_devnet as network_id) tells me that the transactions is valid. but when broadcasting I still get the StatusCode 400 and StatusMessage Bad Request:

the tx is:

tx_+QTnCwH4QrhAPkb9Tl69q/Mhgk/HaNSHL7aQm/hGrRqfQx81aE6PQYyzd42zRgshTITCq6LgMbsdDuDgE4gQ93jJcGeTxV2ZBrkEnvkEmyoBoQF17pglrWMJY0grsZOaISoOU1iDxrTXgE5AKH4fVW2icgG5A/j5A/VGAqClWrUhvava6D5SS0e99ZJDw/fkclAczqqKSoG7UPCC1PkC+/kBKqBo8mdjOP9QiDmrpHdJ7/qL6H7yhPIH+z2ZmHAc1TiHxYRtYWluuMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoP//////////////////////////////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC4QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD5AcuguclW8osxSan1mHqlBfPaGyIJzFc5I0AGK7bBvZ+fmeqEaW5pdLhgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA///////////////////////////////////////////uQFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQD//////////////////////////////////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//////////////////////////////////////////+4zGIAAGRiAACEkYCAgFF/uclW8osxSan1mHqlBfPaGyIJzFc5I0AGK7bBvZ+fmeoUYgAAwFdQgFF/aPJnYzj/UIg5q6R3Se/6i+h+8oTyB/s9mZhwHNU4h8UUYgAAr1dQYAEZUQBbYAAZWWAgAZCBUmAgkANgA4FSkFlgAFFZUmAAUmAA81tgAIBSYADzW1lZYCABkIFSYCCQA2AAGVlgIAGQgVJgIJADYAOBUoFSkFZbYCABUVFZUICRUFCAkFCQVltQUIKRUFBiAACMVoUzLjAuMIMEAAGHA+c5twdoAIJOIICAggPohEGQqwC4YAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAguclW8osxSan1mHqlBfPaGyIJzFc5I0AGK7bBvZ+fmeoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJ9wl8Y=

here the goggles screenshots:

EDIT:

ok so as above mentioned the API says Bad Request with Reason invalid Tx and when we check the logs of the node we get a signature_check_failed

node_1      | 16:24:44.221 [info] Failed signature check on tx: {error,signature_check_failed}, <<91,163,4,185,255,160,75,16,65,201,152,243,191,221,168,76,229,0,180,127,106,70,230,194,114,14,80,85,53,211,129,111>>

hanssv.chain · June 2, 2019, 4:36pm

Yes, the gaslimit for the micro block is 6M, but your transaction does not have zero size and zero base gas, so you can’t use all that 6M for contract gas… (rater around 5.5M is max gas)

So, I checked and just like last time we discussed this, the transaction does not seem to be correctly signed for ae_devnet:

(aeternity_ct@localhost)16> ETx = <<"tx_+QTnCwH4QrhAPkb9Tl69q/Mhgk/HaNSHL7aQm/hGrRqfQx81aE6PQYyzd42zRgshTITCq6LgMbsdDuDgE4gQ93jJcGeTxV2ZBrkEnvkEmyoBoQF17pglrWMJY0grsZOaISoOU1iDxrTXgE5AKH4fVW2icgG5A/j5A/VGAqClWrUhvava6D5SS0e99ZJDw/fkclAczqqKSoG7UPCC1PkC+/kBKqBo8mdjOP9QiDmrpHdJ7/qL6H7yhPIH+z2ZmHAc1TiHxYRtYWluuMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoP//////////////////////////////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC4QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD5AcuguclW8osxSan1mHqlBfPaGyIJzFc5I0AGK7bBvZ+fmeqEaW5pdLhgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA///////////////////////////////////////////uQFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQD//////////////////////////////////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//////////////////////////////////////////+4zGIAAGRiAACEkYCAgFF/uclW8osxSan1mHqlBfPaGyIJzFc5I0AGK7bBvZ+fmeoUYgAAwFdQgFF/aPJnYzj/UIg5q6R3Se/6i+h+8oTyB/s9mZhwHNU4h8UUYgAAr1dQYAEZUQBbYAAZWWAgAZCBUmAgkANgA4FSkFlgAFFZUmAAUmAA81tgAIBSYADzW1lZYCABkIFSYCCQA2AAGVlgIAGQgVJgIJADYAOBUoFSkFZbYCABUVFZUICRUFCAkFCQVltQUIKRUFBiAACMVoUzLjAuMIMEAAGHA+c5twdoAIJOIICAggPohEGQqwC4YAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAguclW8osxSan1mHqlBfPaGyIJzFc5I0AGK7bBvZ+fmeoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJ9wl8Y=">>.
<<"tx_+QTnCwH4QrhAPkb9Tl69q/Mhgk/HaNSHL7aQm/hGrRqfQx81aE6PQYyzd42zRgshTITCq6LgMbsdDuDgE4gQ93jJcGeTxV2ZBrkEnvkEmyoBoQF17"...>>
(aeternity_ct@localhost)17> {ok, SerTx} = aeser_api_encoder:safe_decode(transaction, ETx).
{ok,<<249,4,231,11,1,248,66,184,64,62,70,253,78,94,189,
171,243,33,130,79,199,104,212,135,47,182,144,...>>} 
(aeternity_ct@localhost)18> SigTx = aetx_sign:deserialize_from_binary(SerTx).                                                                                                                                                                          {signed_tx,{aetx,contract_create_tx,aect_create_tx,1182, 
{contract_create_tx,{id,account,
<<117,238,152,37,173,99,9,99,72,43,177,147,154,33,42,14, 83,...>>},                                                                                                                                                                                                                                       1, 
<<249,3,245,70,2,160,165,90,181,33,189,171,218,232,62,82,
                                       75,71,...>>,
                                     #{abi => 1,vm => 4},
                                     1098660000000000,0,0,1000,1100000000,
                                     <<0,0,0,0,0,0,0,0,0,0,0,...>>,
                                     20000}},
           [<<62,70,253,78,94,189,171,243,33,130,79,199,104,212,
              135,47,182,144,155,248,70,173,26,159,67,...>>]}
(aeternity_ct@localhost)19> Bin = aetx:serialize_to_binary(aetx_sign:tx(SigTx)).
<<249,4,155,42,1,161,1,117,238,152,37,173,99,9,99,72,43, 
177,147,154,33,42,14,83,88,131,198,180,215,...>> 
(aeternity_ct@localhost)20> NetworkId = <<"ae_devnet">>.                                                                                                                                                                                               <<"ae_devnet">> 
(aeternity_ct@localhost)21> NetBin = <<NetworkId/binary, Bin/binary>>.
<<97,101,95,100,101,118,110,101,116,249,4,155,42,1,161,1,
117,238,152,37,173,99,9,99,72,43,177,147,154,...>>
(aeternity_ct@localhost)22> [Sig] = aetx_sign:signatures(SigTx).
[<<62,70,253,78,94,189,171,243,33,130,79,199,104,212,135, 
47,182,144,155,248,70,173,26,159,67,31,53,104,...>>]  
(aeternity_ct@localhost)23> {ok, [PK]} = aetx:signers(aetx_sign:tx(SigTx), unused). 
{ok,[<<117,238,152,37,173,99,9,99,72,43,177,147,154,33, 
42,14,83,88,131,198,180,215,128,78,64,40,...>>]} 
(aeternity_ct@localhost)24> enacl:sign_verify_detached(Sig, NetBin, PK). 
{error,failed_verification}

I’m not familiar with Goggles so I don’t know what it (tries) to do… How do you sign the transaction?

marco.chain · June 2, 2019, 4:54pm

mhh this is going to be crazy xD

can you tell me the tool you use to check against the signature and network?

we use the same signing method that we use for the spendTx (which works )

it looks like this:

@Override
  public Tx signTransaction(final UnsignedTx unsignedTx, final String privateKey)
      throws CryptoException {
    byte[] networkData = config.getNetwork().getId().getBytes(StandardCharsets.UTF_8);
    byte[] binaryTx = EncodingUtils.decodeCheckWithIdentifier(unsignedTx.getTx());
    byte[] txAndNetwork = ByteUtils.concatenate(networkData, binaryTx);
    byte[] sig = SigningUtil.sign(txAndNetwork, privateKey);
    String encodedSignedTx = encodeSignedTransaction(sig, binaryTx);
    Tx tx = new Tx();
    tx.setTx(encodedSignedTx);
    return tx;

and we are sure that we use the correct networkId.

we just created a transaction for the testnet ae_uat and again goggles says the transaction is fine but we get the same error.

this is the testnet-tx:

tx_+QToCwH4QrhAXJk/+CKZKW7NMnhdVDeeDDG3xCw7ermUnY5/ottmYi6fY02q4nDKaGzPm7z6qi9nJ/o9k54XZ9jq/FfcDZ87DbkEn/kEnCoBoQELtO15J/l7UeG8teE0DRIzWyorEsi8UiHWPEvLOdQeYYIygrkD+PkD9UYCoHjdOfrSXHaira86aimhn+3u8EnNwEWf4TUoHrh3KFy5+QL7+QEqoGjyZ2M4/1CIOaukd0nv+ovofvKE8gf7PZmYcBzVOIfFhG1haW64wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACg//////////////////////////////////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPkBy6C5yVbyizFJqfWYeqUF89obIgnMVzkjQAYrtsG9n5+Z6oRpbml0uGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//////////////////////////////////////////+5AUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAP//////////////////////////////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//////////////////////////////////////////7jMYgAAZGIAAISRgICAUX+5yVbyizFJqfWYeqUF89obIgnMVzkjQAYrtsG9n5+Z6hRiAADAV1CAUX9o8mdjOP9QiDmrpHdJ7/qL6H7yhPIH+z2ZmHAc1TiHxRRiAACvV1BgARlRAFtgABlZYCABkIFSYCCQA2ADgVKQWWAAUVlSYABSYADzW2AAgFJgAPNbWVlgIAGQgVJgIJADYAAZWWAgAZCBUmAgkANgA4FSgVKQVltgIAFRUVlQgJFQUICQUJBWW1BQgpFQUGIAAIxWhTIuMS4wgwQAAYcD5zm3B2gAgICAgw9CQIQ7msoAuGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAILnJVvKLMUmp9Zh6pQXz2hsiCcxXOSNABiu2wb2fn5nqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0S7mh

also when we put in this transaction in our local goggles it says we have the wrong network_id and vice versa.

we just cannot find the problem

marco.chain · June 2, 2019, 5:10pm

Ok so as above mentioned the API says Bad Request with Reason invalid Tx and when we check the logs of the node we get a signature_check_failed

node_1      | 16:24:44.221 [info] Failed signature check on tx: {error,signature_check_failed}, <<91,163,4,185,255,160,75,16,65,201,152,243,191,221,168,76,229,0,180,127,106,70,230,194,114,14,80,85,53,211,129,111>>

we think the network_id cannot be the reason. maybe we are handling the RLP-array wrong? this is being built like this:

@Override
	protected Bytes createRLPEncodedList() {
		Bytes encodedRlp = RLP.encodeList(rlpWriter -> {
			rlpWriter.writeInt(SerializationTags.OBJECT_TAG_CONTRACT_CREATE_TRANSACTION);
			rlpWriter.writeInt(SerializationTags.VSN);
			byte[] ownerWithTag = EncodingUtils.decodeCheckAndTag(this.ownerId, SerializationTags.ID_TAG_ACCOUNT);
			rlpWriter.writeByteArray(ownerWithTag);
			rlpWriter.writeBigInteger(this.nonce);
            rlpWriter.writeByteArray(EncodingUtils.decodeCheckWithIdentifier(this.contractByteCode));
			rlpWriter.writeBigInteger(calculateVersion()); // abi + vm
			rlpWriter.writeBigInteger(this.fee);
			rlpWriter.writeBigInteger(this.ttl);
			rlpWriter.writeBigInteger(this.deposit);
			rlpWriter.writeBigInteger(this.amount);
			rlpWriter.writeBigInteger(this.gas);
			rlpWriter.writeBigInteger(this.gasPrice);
			rlpWriter.writeByteArray(EncodingUtils.decodeCheckWithIdentifier(this.callData));
		});
		return encodedRlp;
	}

hanssv.chain · June 3, 2019, 8:52am

I’m just using the plain Erlang-functions in an Erlang shell. This is very similar to what the node does, so it isn’t very surprising that the node comes to the same conclusion {error,signature_check_failed}…

I can’t see anything obviously wrong in the RLP code or in signTransaction - what I can provide is the correct serialization of the unsigned transaction, i.e. binaryTx in signTransaction.

For the first transaction (ae_devnet) -

[249,4,155,42,1,161,1,117,238,152,37,173,99,9,99,72,43,
  177,147,154,33,42,14,83,88,131,198,180,215,128,78,64,40,
  126,31,85,109,162,114,1,185,3,248,249,3,245,70,2,160,
  165,90,181,33,189,171,218,232,62,82,75,71,189,245,146,
  67,195,247,228,114,80,28,206,170,138,74,129,187,80,240,
  130,212,249,2,251,249,1,42,160,104,242,103,99,56,255,80,
  136,57,171,164,119,73,239,250,139,232,126,242,132,242,7,
  251,61,153,152,112,28,213,56,135,197,132,109,97,105,110,
  184,192,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,32,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,0,0,3,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,96,0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,160,255,255,
  255,255,255,255,255,255,255,255,255,255,255,255,255,255,
  255,255,255,255,255,255,255,255,255,255,255,255,255,255,
  255,255,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,184,64,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,32,0,0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,249,1,203,160,
  185,201,86,242,139,49,73,169,245,152,122,165,5,243,218,
  27,34,9,204,87,57,35,64,6,43,182,193,189,159,159,153,
  234,132,105,110,105,116,184,96,0,0,0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,32,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,3,255,
  255,255,255,255,255,255,255,255,255,255,255,255,255,255,
  255,255,255,255,255,255,255,255,255,255,255,255,255,255,
  255,255,255,185,1,64,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,32,0,0,0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,3,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,96,0,0,0,
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  160,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,192,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,5,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,255,255,255,255,255,255,
  255,255,255,255,255,255,255,255,255,255,255,255,255,255,
  255,255,255,255,255,255,255,255,255,255,255,255,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,3,
  255,255,255,255,255,255,255,255,255,255,255,255,255,255,
  255,255,255,255,255,255,255,255,255,255,255,255,255,255,
  255,255,255,255,184,204,98,0,0,100,98,0,0,132,145,128,
  128,128,81,127,185,201,86,242,139,49,73,169,245,152,122,
  165,5,243,218,27,34,9,204,87,57,35,64,6,43,182,193,189, 
  159,159,153,234,20,98,0,0,192,87,80,128,81,127,104,242,
  103,99,56,255,80,136,57,171,164,119,73,239,250,139,232,
  126,242,132,242,7,251,61,153,152,112,28,213,56,135,197,
  20,98,0,0,175,87,80,96,1,25,81,0,91,96,0,25,89,96,32,1,
  144,129,82,96,32,144,3,96,3,129,82,144,89,96,0,81,89,82,
  96,0,82,96,0,243,91,96,0,128,82,96,0,243,91,89,89,96,32,
  1,144,129,82,96,32,144,3,96,0,25,89,96,32,1,144,129,82,
  96,32,144,3,96,3,129,82,129,82,144,86,91,96,32,1,81,81,
  89,80,128,145,80,80,128,144,80,144,86,91,80,80,130,145,
  80,80,98,0,0,140,86,133,51,46,48,46,48,131,4,0,1,135,3,
  231,57,183,7,104,0,130,78,32,0,0,130,3,232,132,65,144,
  171,0,184,96,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,32,185,201,86,242,139,49,73,169,245,
  152,122,165,5,243,218,27,34,9,204,87,57,35,64,6,43,182,
  193,189,159,159,153,234,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]

And for the testnet transaction -

[249,4,156,42,1,161,1,11,180,237,121,39,249,123,81,225,
  188,181,225,52,13,18,51,91,42,43,18,200,188,82,33,214,
  60,75,203,57,212,30,97,130,50,130,185,3,248,249,3,245,
  70,2,160,120,221,57,250,210,92,118,162,173,175,58,106, 
  41,161,159,237,238,240,73,205,192,69,159,225,53,40,30,
  184,119,40,92,185,249,2,251,249,1,42,160,104,242,103,99,
  56,255,80,136,57,171,164,119,73,239,250,139,232,126,242,
  132,242,7,251,61,153,152,112,28,213,56,135,197,132,109,
  97,105,110,184,192,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,0,0,0,32,0,0,0,0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,3,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,96,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  160,255,255,255,255,255,255,255,255,255,255,255,255,255,
  255,255,255,255,255,255,255,255,255,255,255,255,255,255,
  255,255,255,255,255,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,184,64,0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,32,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  249,1,203,160,185,201,86,242,139,49,73,169,245,152,122,
  165,5,243,218,27,34,9,204,87,57,35,64,6,43,182,193,189,
  159,159,153,234,132,105,110,105,116,184,96,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,32,0,
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  0,0,3,255,255,255,255,255,255,255,255,255,255,255,255,
  255,255,255,255,255,255,255,255,255,255,255,255,255,255,
  255,255,255,255,255,255,185,1,64,0,0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,32,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,3,0,0,
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  0,96,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,160,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,0,192,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,5,0,0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,255,255,255,
  255,255,255,255,255,255,255,255,255,255,255,255,255,255,
  255,255,255,255,255,255,255,255,255,255,255,255,255,255,
  255,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,3,255,255,255,255,255,255,255,255,255,255,255,
  255,255,255,255,255,255,255,255,255,255,255,255,255,255,
  255,255,255,255,255,255,255,184,204,98,0,0,100,98,0,0,
  132,145,128,128,128,81,127,185,201,86,242,139,49,73,169,
  245,152,122,165,5,243,218,27,34,9,204,87,57,35,64,6,43,
  182,193,189,159,159,153,234,20,98,0,0,192,87,80,128,81,
  127,104,242,103,99,56,255,80,136,57,171,164,119,73,239,
  250,139,232,126,242,132,242,7,251,61,153,152,112,28,213,
  56,135,197,20,98,0,0,175,87,80,96,1,25,81,0,91,96,0,25,
  89,96,32,1,144,129,82,96,32,144,3,96,3,129,82,144,89,96,
  0,81,89,82,96,0,82,96,0,243,91,96,0,128,82,96,0,243,91,
  89,89,96,32,1,144,129,82,96,32,144,3,96,0,25,89,96,32,1,
  144,129,82,96,32,144,3,96,3,129,82,129,82,144,86,91,96,
  32,1,81,81,89,80,128,145,80,80,128,144,80,144,86,91,80,
  80,130,145,80,80,98,0,0,140,86,133,50,46,49,46,48,131,4,
  0,1,135,3,231,57,183,7,104,0,0,0,0,131,15,66,64,132,59,
  154,202,0,184,96,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,0,0,32,185,201,86,242,139,49,73,169,
  245,152,122,165,5,243,218,27,34,9,204,87,57,35,64,6,43,
  182,193,189,159,159,153,234,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]

marco.chain · June 3, 2019, 9:08am

we will check whether the UnsignedTx is being serialized correctly. thanks!

mitch_lbw · June 6, 2019, 2:56pm

Thanks @hanssv.chain - after decoding your binary tx we found the issue - we’ve written deposit and amount as integer instead of byte in our RLP array. After changing this in our RLP array generation we’re finally able to deploy a contract tx. Many thanks