[Android] Web3J and wallet-core signatures don't match

[bigman212]

Describe the bug
I am trying to replace Web3J method to sign transactions with the one from wallet-core. Signature from wallet-core is declined with the message from Web3 when calling sendRawTransaction:

java.lang.IllegalArgumentException: Unsupported v parameter: 0
      at org.web3j.crypto.Sign.getRecId(Sign.java:307)
      at org.web3j.crypto.transaction.type.Transaction1559.asRlpValues(Transaction1559.java:89)
      at org.web3j.crypto.TransactionEncoder.asRlpValues(TransactionEncoder.java:137)
      at org.web3j.crypto.TransactionEncoder.encode(TransactionEncoder.java:116)

To Reproduce
Steps to reproduce the behavior:

1. Create a code that signs transaction using web3j
2. Create a code that signs transaction using trust-core
3. assert equality from signatures

Expected behavior
Signatures are valid, Web3j can send signed transaction from trust-core

Additional context
I have created a simple test that allows to check behaviour:
example.txt
Where:

1. web3J - raw transaction created with the help of Web3j
2. signUsingWeb3j - method that generates signature using web3j
3. signUsingWalletCore - method that generated signature using trust-core using the same transaction from web3j

The first assert fails like this:

Also Web3J doens't require to pass in the tx type: transfer or erc20 transfer, but trust-core does. Maybe I don't correctly configure builders?

[satoshiotomakan]

Hi @bigman212, thank you for creating the issue!
Could you please share the expected signature for the given transaction, and the raw transaction itself that is returned by Web3j? This would help me a lot to figure out what's missing.

[bigman212]

@satoshiotomakan here you go:

r=0x32b137fc7cd0385af6f22a8eca23627df3547a7c8e93a4a61676f30ddb4436a9
s=0x746756fc48bd499d45ca75d523b97e4bd79404903d847ad975be5d62c655b186
v=0x1b

raw = 0x02f852012e84055d4a8085073e4ced8082635694a358b8d0d382ee175c63e9a56f5b1806b8dfecc3865af3107a4000a4a1903eab0000000000000000000000000000000000000000000000000000000000000000c0

[bigman212]

sorry for disturbing, @satoshiotomakan any updates?