TODO: Consider Space Efficient Output Format

[Psifour]

"Decide whether or not we should encode transfer outputs as ceil(log2(output_count))-length bit strings instead of varints, since we know the number of transaction outputs. Saves space but somewhat tricky."

[summraznboi]

This only practically saves space in the 128-255 outputs scenario, where the output could be encoded as 1 byte instead of 2. Given that the protocol doesn't really allow us to specify that many transfer instructions anyways due to 83 byte limitation in OP_RETURN output, I don't see this as being a practical saving only varint consistency.

[Psifour]

I also support the consistency of varints, but only for the sake of consistency.

I view it as highly likely that this may reignite discussion over standardness rules and their place within Bitcoin. As it is only an isStandard rule (not a consensus rule), I prefer to leave it out of my mental model.

[summraznboi]

I completely agree, just providing additional arguments from a practical space-saving ratio POV for those that might be otherwise swayed by “most compressed is best”.

[casey]

This only practically saves space in the 128-255 outputs scenario, where the output could be encoded as 1 byte instead of 2. Given that the protocol doesn't really allow us to specify that many transfer instructions anyways due to 83 byte limitation in OP_RETURN output, I don't see this as being a practical saving only varint consistency.

The idea is that instead of encoding the output as a byte string, we encode it as a fixed-length bitstring. Also, keep in mind that the OP_RETURN length limit is subject to change. If the protocol is popular enough, then the length limit would likely be increased.

I think simplicity is a good idea, so that's a knock against doing this. Also, I realized that we can use "invalid" outputs, e.g., an output value which is greater than the last valid output index, for additional operations, like spreading all the coins in a transfer directive evenly among all OP_RETURN outputs. See #20.