Skip to content

Conversation

ajtowns
Copy link

@ajtowns ajtowns commented Oct 6, 2022

Here's what I've been thinking of... It has two main differences: it encodes the type as a delta, which enforces a canonical encoding (lowest types go first), and it's slightly more compressed.

I think what you've currently got encodes:

  • type = [0, 2**14), length(value) = 1,2,3 -- 2 bytes + length(value)
  • type = [0, 2**14), length(value) = 0 or [4,253] -- 3 bytes + length(value)

I guess I find the "enforce canonical ordering by encoding as types as a delta" the most compelling part.

I found the RecordLowerBitMask stuff hard to follow as it's currently explained, fwiw.

...

Alternatively, perhaps doing a custom encoding with VarInt would be both clear and fine:

x = read_bytes(1)
y = read_VarInt()
type = last_type + (y << 6) + (x >> 2)
size = x & 0x3
if size == 3: size += read_VarInt()
value = read_bytes(size)

So your encoding is always:

  • base_type_size : 1 byte (6 bits for type, 2 bits for size)
  • extended_type : VarInt
  • extended_size : optional VarInt (type_size & 3 == 3)
  • value : size

That's still pretty compressed, and gives a canonical encoding/ordering...

@ariard ariard force-pushed the 2022-07-bip-annex branch from b61fcdf to df5af5b Compare October 10, 2022 05:58
@ariard ariard force-pushed the 2022-07-bip-annex branch 2 times, most recently from 6f3dcc2 to 9dc3f74 Compare January 17, 2023 00:33
@ariard
Copy link
Owner

ariard commented Jan 17, 2023

Thanks for the feedback here! Finally addressed and added comments on open issues back on the BIP PR: bitcoin#1381

@ariard ariard closed this Jan 17, 2023
ariard pushed a commit that referenced this pull request Aug 24, 2025
Add backwards compatibility section
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants