Whe using to 0x00 prefixed addresses it'll return following error from GETH.

rlp: input string too short for common.Address, decoding into (types.DynamicFeeTx).To

I think that's the reason of recently introduced patch to remove leading 0's from strings. Seems that geth client can't decode addresses with 0's removed. So this seems to be in accordance with specification, but geth still can't read the data encoded according to specs when address is shorter than "normal".

I think string in PHP is utf8 bytes. Consider the following code:

$buffer = new Buffer('abcàê߀abc', 'ascii');
echo $buffer->length(); // 15

if you dump you'll see:

  array(15) {
    [0]=>
    int(97)
    [1]=>
    int(98)
    [2]=>
    int(99)
    [3]=>
    int(195)
    [4]=>
    int(160)
    [5]=>
    int(195)
    [6]=>
    int(170)
    [7]=>
    int(195)
    [8]=>
    int(159)
    [9]=>
    int(226)
    [10]=>
    int(130)
    [11]=>
    int(172)
    [12]=>
    int(97)
    [13]=>
    int(98)
    [14]=>
    int(99)
  }

It should be 10 and looks like:

  array(10) {
    [0]=>
    int(97)
    [1]=>
    int(98)
    [2]=>
    int(99)
    [3]=>
    int(224)
    [4]=>
    int(234)
    [5]=>
    int(223)
    [6]=>
    int(172)
    [7]=>
    int(97)
    [8]=>
    int(98)
    [9]=>
    int(99)
  }

In nodejs:

• Ascii:

new Buffer('abcàê߀abc', 'ascii');
<Buffer 61 62 63 e0 ea df ac 61 62 63> // [97, 98, 99, 224, 234, 223, 172, 97, 98, 99]

• Utf8 (like the array above)

new Buffer('abcàê߀abc', 'utf8');
<Buffer 61 62 63 c3 a0 c3 aa c3 9f e2 82 ac 61 62 63> // [97, 98, 99, 195, 160, 195, 170, 195, 159, 226, 130, 172, 97, 98, 99]

How to fix it?

When I try to serialize transaction object, I found that if nonce is zero, the serialized transaction was wrong.

Because web3p/rlp encode 0 to 0x00, and ethreumjs/rlp encode 0 to 0x80.

Still find more detail in rlp wiki.

I have a hard time getting together your encoding and other tests. E.g:
https://github.com/ethereum/web3.js/blob/cd1cfd9db6cacb494884a1824f8562c6440f85df/test/coder.decodeParam.js

What types are currently supported?

rlp: input string too long for uint64, decoding into (types.LegacyTx).Nonce

Failed to sendRawTransaction: transactionData=Array
(
    [from] => 0xCeE4892B23d6944CF5804Ab1038B2963Cd67d73E
    [nonce] => 0xa0
    [to] => 0x754eb48013f5ff2a3bb746b33a878bdd12595ef4
    [gas] => 0x8fde
    [gasPrice] => 0x156ba09800
    [value] => 0x0
    [chainId] => 3
    [data] => 0xa9059cbb00000000000000000000000032e62b619209b3398fdb2931371ba090059d57000000000000000000000000000000000000000000000000056bc75e2d63100000
)

The same code worked OK for the same wallet address, but stopped at the 160th nonce value.
Tested on Ropsten network.

Add support to multidimensional array in buffer.

If the string is 0x1234523623 or 0x[Numbers]
rlp encode retrun wrong data, because 0x was removed before calling toBuffer
Buffer will decode the string as numeric string.

hi @sc0Vu , i encounter Incorrect result when encode with 2 hex characters (1 byte)

for example, echo $rlp->encode("0xd0");

expected result should be 81d0, not d0.

transaction: Array
(
    [from] => 0xC14DeDeC7c21Fdd07e319Ef633606bFaaEB51F64
    [nonce] => 0xfa
    [to] => 0x1cb6138c21ac288e3e79e258d70112192c1bbdcc
    [gas] => 0x5208
    [gasPrice] => 0x0713fb3000
    [value] => 0x0de0b6b3a7640000
    [chainId] => 100
)

signedTransaction: 0xf86cfa850713fb3000825208941cb6138c21ac288e3e79e258d70112192c1bbdcc880de0b6b3a764000080eca093268b50f343ded33740d6a479a62a0e19d0ac624ba12d5fdd1056a0f91757a4a0460b277a83ee7c6a1ff81dd34d04da104d8eb6668cd84ef39880cd383ceafe22

Related to #21. Worked OK till some threshold nonce value and stopped then. xdai chain was tested in this case.

I try to encode number 1000, it should return 8203e8 but return 8103e8.

After traced step by step, I found that the buffer length of 1000 was wrong, it always return 1:

object(Web3p\RLP\Buffer)#323 (2) {
  ["data":protected]=>
  array(1) {
    [0]=>
    int(1000)
  }
  ["encoding":protected]=>
  string(4) "utf8"
}