leading zero bytes

[DerXanRam]

leading zero bytes

[mhw0]

Oh, I think, I know what the problem is. We're encoding v as uint16, and, v is less than 255. So, in bytes, it would be 00xx. Just replace both ok(eth_rlp_uint16(&rlp0, &v)); and ok(eth_rlp_uint16(&rlp1, &v)); with ok(eth_rlp_uint8(&rlp0, &v)); and ok(eth_rlp_uint8(&rlp1, &v)); and the type of v should be uint8_t in the code.

[DerXanRam]

Oh, I think, I know what the problem is. We're encoding v as uint16, and, v is less than 255. So, in bytes, it would be 00xx. Just replace ok(eth_rlp_uint16(&rlp1, &v)); with ok(eth_rlp_uint8(&rlp1, &v)); and the type of v should be uint8_t in the code.

Wow bro...finally 😃 ... I missed this response like for 4 days....

{"jsonrpc":"2.0","id":1,"error":{"code":-32000,"message":"INTERNAL_ERROR: insufficient funds"}}

Thanks a lot 🙏 ..and by the way.... i am finishing the code part that sends the raw transaction to the RPC-API, receive the response and store in json format. it uses libcurl library and no need to initiate curl(the system command).It needs cleaning and some work to make handy to use for others that use this library. once i finished i will pull request here 👍

[mhw0]

Hi @DerXanRam.

See the first 10 digits ... they differ at that point, the rest is the same.

The first four bytes represent the function selector. Can you please show me your ABI encode code?

which seems formatting issue. i try to look on the internet about the problem and i found this forum answer. They say this happens because S have leading zero byte

I think these lines are causing the error, because, both r and s values don't start with 0:

ok(eth_rlp_hex(&rlp0, &value, NULL));
// and second one
ok(eth_rlp_hex(&rlp1, &value, NULL));

try these instead:

ok(eth_rlp_uint8(&rlp0, &zero));
// and second one
ok(eth_rlp_uint8(&rlp1, &zero));

[mhw0]

Or, can you check if your actual r and s values have leading zeros?

[DerXanRam]

The first four bytes represent the function selector. Can you please show me your ABI encode code?

Here is the ABI code

char *ABIFunction()
{
	struct eth_abi abi;
	char *fn = "swapExactETHForTokens(uint,address[],address,uint)", *hex;
	char *weth = "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2";
	char *usdt = "0xdAC17F958D2ee523a2206206994597C13D831ec7";
	char *to_address = "0xa9d0a7dC416f586491f2fb596731598F937617b5";

	uint64_t path_len = 2;
	size_t hexlen;
	uint64_t amount_out_min = 0, deadline = 346744838;
	//////////////////
	eth_abi_init(&abi, ETH_ABI_ENCODE);
	eth_abi_call(&abi, &fn, NULL);
	eth_abi_uint64(&abi, &amount_out_min);
	eth_abi_array(&abi, &path_len); // open an array
	eth_abi_address(&abi, &weth);
	eth_abi_address(&abi, &usdt);
	eth_abi_array_end(&abi); // close the array
	eth_abi_address(&abi, &to_address);
	eth_abi_uint64(&abi, &deadline);
	eth_abi_call_end(&abi);

	ok(eth_abi_to_hex(&abi, &hex, &hexlen));
	ok(eth_abi_free(&abi));
	return hex;
}

try these instead:

ok(eth_rlp_uint8(&rlp0, &zero));
// and second one
ok(eth_rlp_uint8(&rlp1, &zero));

Ok bro.... testing

[DerXanRam]

Or, can you check if your actual r and s values have leading zeros?

Yea i think r have leading zero when i check on online decoder ....also another decoder ...here is the result

"r": "0x0adaf08507a56902b778f93755bb969c65ab0841f2117aaea768c03d1ecf640e"

[mhw0]

Yea i think r have leading zero when i check on online decoder ....also another decoder ...here is the result
"r": "0x0adaf08507a56902b778f93755bb969c65ab0841f2117aaea768c03d1ecf640e"

No, that's a hex value. First two digits should be zero to cause the error.

[mhw0]

Here is the ABI code

Okay, this resource says that transfer(address,uint256) should be a9059cbb, and the code is producing the same result. So, it's working as intended I think.

[DerXanRam]

Here is the ABI code

Okay, this resource says that transfer(address,uint256) should be a9059cbb, and the code is producing the same result. So, it's working as intended I think.

from the decoder i mentioned above, From address is my address right? But it is showing different address from the address found inside the code? or do i miss something?

[mhw0]

from the decoder i mentioned above, From address is my address right? But it is showing different address from the address found inside the code? or do i miss something?

You don't replace anything. If your function signature is transfer(address,uint256), it should be passed to eth_abi_call as is. But, when you encode the arguments, they must match the signature. For example, this is wrong:

char *sig = "transfer(address,uint256,uint256)";
eth_abi_call(&abi, &sig, NULL);
  eth_abi_address(&abi, &myaddr);
  eth_abi_bool(&abi, &b); // type mismatch, expected uint256
  // we did not pass the third argument at all
eth_abi_call_end(&abi);

[mhw0]

and after i add this correction, leading zero error gone and another error realm appeares 🥲 called

The transaction is correct, maybe it starts with 0x, not 0X?

[DerXanRam]

This is the whole code....

char *ABIFunction()
{
	struct eth_abi abi;
	char *fn = "swapExactETHForTokens(uint,address[],address,uint)", *hex;
	char *weth = "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2";
	char *usdt = "0xdAC17F958D2ee523a2206206994597C13D831ec7";
	char *to_address = "0xa9d0a7dC416f586491f2fb596731598F937617b5";

	uint64_t path_len = 2;
	size_t hexlen;
	uint64_t amount_out_min = 0, deadline = 346744838;
	//////////////////
	eth_abi_init(&abi, ETH_ABI_ENCODE);
	eth_abi_call(&abi, &fn, NULL);
	eth_abi_uint64(&abi, &amount_out_min);
	eth_abi_array(&abi, &path_len); // open an array
	eth_abi_address(&abi, &weth);
	eth_abi_address(&abi, &usdt);
	eth_abi_array_end(&abi); // close the array
	eth_abi_address(&abi, &to_address);
	eth_abi_uint64(&abi, &deadline);
	eth_abi_call_end(&abi);

	ok(eth_abi_to_hex(&abi, &hex, &hexlen));
	ok(eth_abi_free(&abi));
	return hex;
}
char *SignTransaction()
{
	char *abi_result="0x7ff36ab500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000080000000000000000000000000a9d0a7dc416f586491f2fb596731598f937617b50000000000000000000000000000000000000000000000000000000014aae8060000000000000000000000000000000000000000000000000000000000000002000000000000000000000000c02aaa39b223fe8d0a0e5c4f27ead9083c756cc2000000000000000000000000dac17f958d2ee523a2206206994597c13d831ec7";// = ABIFunction();

	struct eth_rlp rlp0, rlp1;
	struct eth_ecdsa_signature sign;
	  
	uint8_t privkey[] ={0x80, 0x3e, 0x53, 0x83, 0x51, 0x93, 0xdd, 0x6e, 
	                    0xad, 0x61, 0xa2, 0x5a, 0x74, 0x5f, 0xa6, 0x35, 
						0x86, 0xb4, 0xb2, 0xdd, 0x7b, 0x6a, 0xbe, 0x4a, 
						0x06, 0xfa, 0x7f, 0x33, 0xc1, 0x1a, 0xed, 0x81}; //real private key of the account 0xa9d0a7dC416f586491f2fb596731598F937617b5
	//ok(eth_hex_to_bytes(&privkey,keys,64));
	
	uint8_t nonce = 0x00, zero = 0x00, keccak[32], *rlp0bytes, *r, *s;
	char *gasprice = "0x04a817c800", *gaslimit = "0x5208", *value = "0x00";
	char *toaddr = "0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D", *txn;
	uint16_t chainid = 0x1, v;
	size_t rlp0len, rlp1len, siglen = 32;

	ok(eth_rlp_init(&rlp0, ETH_RLP_ENCODE));
	ok(eth_rlp_array(&rlp0));
	ok(eth_rlp_uint8(&rlp0, &nonce));
	ok(eth_rlp_hex(&rlp0, &gasprice, NULL));
	ok(eth_rlp_hex(&rlp0, &gaslimit, NULL));
	ok(eth_rlp_address(&rlp0, &toaddr));
	ok(eth_rlp_uint8(&rlp0, &zero));
	ok(eth_rlp_hex(&rlp0, &abi_result, NULL));
	ok(eth_rlp_uint16(&rlp0, &chainid));
	ok(eth_rlp_uint8(&rlp0, &zero)); //   0x,
	ok(eth_rlp_uint8(&rlp0, &zero)); //   0x,
	ok(eth_rlp_array_end(&rlp0));	 // ]

	ok(eth_rlp_to_bytes(&rlp0bytes, &rlp0len, &rlp0));
	ok(eth_rlp_free(&rlp0));

	// compute the keccak hash of the encoded rlp elements
	ok(eth_keccak256(keccak, rlp0bytes, rlp0len));
	free(rlp0bytes);

	// sign the transaction
	ok(eth_ecdsa_sign(&sign, privkey, keccak));

	// calculate v
	v = sign.recid + chainid * 2 + 35;
	r = sign.r;
	s = sign.s;

	ok(eth_rlp_init(&rlp1, ETH_RLP_ENCODE));
	ok(eth_rlp_array(&rlp1));
	ok(eth_rlp_uint8(&rlp1, &nonce));
	ok(eth_rlp_hex(&rlp1, &gasprice, NULL));
	ok(eth_rlp_hex(&rlp1, &gaslimit, NULL));
	ok(eth_rlp_address(&rlp1, &toaddr));     
    ok(eth_rlp_uint8(&rlp1, &zero));
	ok(eth_rlp_hex(&rlp1, &abi_result, NULL)); // replaced
	ok(eth_rlp_uint16(&rlp1, &v));
	ok(eth_rlp_bytes(&rlp1, &r, &siglen));
	ok(eth_rlp_bytes(&rlp1, &s, &siglen));
	ok(eth_rlp_array_end(&rlp1));

	// FIX3: this actually returns the output length
	ok(eth_rlp_to_hex(&txn, &rlp1) > 0);
	ok(eth_rlp_free(&rlp1));
	return txn;
}

This is how i call the rpc on my terminal using this doc guide

curl https://eth-mainnet.blastapi.io/b871b6ef-cdc2-4c11-b791-9fcaf4da878d -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params":["0xf9014b808504a817c800825208947a250d5630b4cf539739df2c5dacb4c659f2488d80b8e47ff36ab500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000080000000000000000000000000a9d0a7dc416f586491f2fb596731598f937617b50000000000000000000000000000000000000000000000000000000014aae8060000000000000000000000000000000000000000000000000000000000000002000000000000000000000000c02aaa39b223fe8d0a0e5c4f27ead9083c756cc2000000000000000000000000dac17f958d2ee523a2206206994597c13d831ec7820025a00adaf08507a56902b778f93755bb969c65ab0841f2117aaea768c03d1ecf640ea031b675c1d7e61b8768c44675d33d1a9f6d5970d2ca2ae4ebeecf3529c2b38188"],"id":1}'

and this is the RPC response
{"jsonrpc":"2.0","id":1,"error":{"code":-32000,"message":"read V: rlp: non-canonical integer format"}}

[DerXanRam]

and after i add this correction, leading zero error gone and another error realm appeares 🥲 called

The transaction is correct, maybe it starts with 0x, not 0X?

I double check that... and because i use terminal it is easy to differernciate O or o and 0(zero) 👍 :

[DerXanRam]

Oh, I think, I know what the problem is. We're encoding v as uint16, and, v is less than 255. So, in bytes, it would be 00xx. Just replace ok(eth_rlp_uint16(&rlp1, &v)); with ok(eth_rlp_uint8(&rlp1, &v)); and the type of v should be uint8_t in the code.

Testing...

[mhw0]

Please, be careful when using this library with real money. I don't guarantee anything. If you have any other questions, I've just opened a discussion. Have a great day!