CIP 11 Discussion: Shorten Transaction Type ID Namespace

Development Counterparty
1

We can save 3 bytes of space in every transaction by shortening the number of bytes allocated to the message type ID from 4 bytes to 1 byte.

This is of particular importance to CIP 9 in order to all the memo field to be 32 bytes and still fit within an 80 byte OP_RETURN message.

Please review or provide any technical commands at https://github.com/CounterpartyXCP/cips/pull/25/files.

Thanks.

1 Like
2

Good proposal.

  1. I’ll add that it saves tx fees too. Right now the optimal tx fee (xchain.io) is 361 sat/b. That’s $0.009 per byte, i.e. almost three cents saved from three less bytes.

  2. How about also allowing a shorter alternative to the CNTRPRTY prefix?

3

That’s a possibility. It needs to be long enough to avoid accidentally triggering a message.

4

What’s the consequence if it does?

I mean, for example, if the prefix is simply two bytes, CP, random data would indeed trigger sometimes (prob 1/65536).

Almost certainly the CP protocol would then invalidate it since the rest of the data is random. But then, of course, there’s this tiny chance all the remaining data will line up to a valid transaction … which must never happen! I don’t know the exact probability of this occurring. Is it one in billion? Then it’s still too risky IMO. If it’s less than one in a quadrillion, I think the saved space is worth it.

Calculating this should be feasible.

Also keep in mind that each byte saved makes the transaction cheaper. Right now it can be as much as 0.9 cents per byte.

Something else to take into account? More to it than I mentioned here?

5

2^6 is over 281 trillion. So the chances of accidentally creating an OP_RETURN (or series of public key hashes is 1 in 281 trillion with only 6 bytes.)

There are a total of 230 million bitcoin transactions in existence.

Also keep in mind that only transactions with enough data to form a valid counterparty transaction even have a chance of accidentally trigger something. AND the address has to have counterparty assets in it to do anything with assets. AND the transaction ID and format needs to be valid.

I am totally comfortable bumping this down to 6 bytes if the maintainers are on board.

1 Like
6

agreed on shortening the prefix from 8 to 6 bytes.
the chance of a collision with random data is, as you wrote, just 1 in 281 trillion with a 6 byte prefix.
and even if there is a collision, the remaining bytes must align to form a valid counterparty message, which
i’m pretty sure, in itself has a chance of 1 in a trillion or quadrillion of happening.

also, keep in mind that reducing the tx size by two bytes saves ~1-2 cents in today’s high fee environment