Ambiguous batch format

[Wollac]

According to the Channel Format section, rlp_batches is the concatenation of the RLP-encoded batches. This is somewhat misleading, as rlp_batches is not

batch1_version ++ rlp_encode([..]) ++ ... ++ batchn_version ++ rlp_encode([..])

(similar to a list of EIP-2718 transactions), but instead

rlp_encode(batch1_version ++ rlp_encode([..])) ++ ... ++ rlp_encode(batchn_version ++ rlp_encode([..]))

It should be made clear in the spec that rlp_batches is the concatenation of the RLP-encoded strings batch_data, where batch_data = batch_version ++ content as described in the section Batch Format.

And perhaps more importantly, it should be made clear what is supposed to happen during decoding, if the "byte envelope" is larger than batch_version ++ content. For example, if for rlp_encode(batch1_version ++ rlp_encode([..])) resulting in

b85000f84da0dbf6a80fef073de06add9b0d14026d6e5a86c85f6d102c36d3d8e9cf89c2afd3840109d8fea0438335a20d98863a4c0c97999eb2481921ccd28553eac6f913af7c12aec0410884647f5ea9c0

the following (adding a bunch of useless zeros) would also be valid:

b85800f84da0dbf6a80fef073de06add9b0d14026d6e5a86c85f6d102c36d3d8e9cf89c2afd3840109d8fea0438335a20d98863a4c0c97999eb2481921ccd28553eac6f913af7c12aec0410884647f5ea9c00000000000000000

If different implementations handle this decoding differently, it could lead to a chain fork.