📅 Original date posted:2017-07-14
📝 Original message:(copying from GitHub per jonasschnelli's request)
I can understand the desire to keep all reference strings to the nice
14-character version by keeping the data payload to 40 bits, but it
seems to place artificial limitations on the format (year 2048 & 8191
transactions). I also understand that this might be addressed with
Version 1 encoding. But current blocks are not that far from having
8191 transactions.
You could go with a variable-length encoding similar to Bitcoin's
variable ints and gain the benefit of having a format that will work
for very large blocks and the very far future.
Also, the Bech32 reference libraries allow encoding from byte arrays
into the base-5 arrays native to Bech32. It seems like bit-packing to
these 40 bits might be overkill. As an alternative you could have one
bit-packed byte to start:
# First two bits are the protocol version, supporting values 0-3
V = ((protocol version) & 0x03) << 6
# Next two bits are magic for the blockchain
# 0x00 = Bitcoin
# 0x01 = Testnet3
# 0x02 = Byte1 is another coin's magic code (gives 256 options)
# 0x03 = Byte1-2 is treated as the coin magic code (gives 65280 more options)
M = (magic & 0x03) << 4
# Next two bits are the byte length of the block reference
B = ((byte length of block reference) & 0x03) << 2
# Final two bits are the byte length of the transaction index
T = ((byte length of transaction index) & 0x03)
# Assemble into the first byte
Byte0 = V | M | B | T
This gives you up to 3 bytes for each block and transaction reference,
which is 16.7 M blocks, or year 2336, and 16.7 M transaction slots.
Data part: [Byte0][optional magic bytes 1-2][block reference bytes][tx
reference bytes]
So the shortest data part would have 3 bytes in it, with the reference
version 0 genesis coinbase transaction having data part 0x050000.
I know this is a departure from your vision, but it would be much more
flexible for the long term.
Clark
Clark Moody [ARCHIVE] /
npub1nr…0hypj
2023-06-07 18:04:38
in reply to nevent1q…uj0v
Author Public Key
npub1nr02dq8fsgnt758nyp29waulhwwhj6j9gmlsqsknlwjem2hu8twqp0hypjPublished at
2023-06-07 18:04:38Event JSON
{
"id": "dc657fdd95b98df6e4392efd716369adc5f0477ebbd4f41448d7cb2550c2d981",
"pubkey": "98dea680e98226bf50f3205457779fbb9d796a4546ff0042d3fba59daafc3adc",
"created_at": 1686161078,
"kind": 1,
"tags": [
[
"e",
"e93374326def94ddbb5cd764578195edda54c4fe03db08b2dc75b62044682d1d",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2017-07-14\n📝 Original message:(copying from GitHub per jonasschnelli's request)\n\nI can understand the desire to keep all reference strings to the nice\n14-character version by keeping the data payload to 40 bits, but it\nseems to place artificial limitations on the format (year 2048 \u0026 8191\ntransactions). I also understand that this might be addressed with\nVersion 1 encoding. But current blocks are not that far from having\n8191 transactions.\n\nYou could go with a variable-length encoding similar to Bitcoin's\nvariable ints and gain the benefit of having a format that will work\nfor very large blocks and the very far future.\n\nAlso, the Bech32 reference libraries allow encoding from byte arrays\ninto the base-5 arrays native to Bech32. It seems like bit-packing to\nthese 40 bits might be overkill. As an alternative you could have one\nbit-packed byte to start:\n\n# First two bits are the protocol version, supporting values 0-3\nV = ((protocol version) \u0026 0x03) \u003c\u003c 6\n# Next two bits are magic for the blockchain\n# 0x00 = Bitcoin\n# 0x01 = Testnet3\n# 0x02 = Byte1 is another coin's magic code (gives 256 options)\n# 0x03 = Byte1-2 is treated as the coin magic code (gives 65280 more options)\nM = (magic \u0026 0x03) \u003c\u003c 4\n# Next two bits are the byte length of the block reference\nB = ((byte length of block reference) \u0026 0x03) \u003c\u003c 2\n# Final two bits are the byte length of the transaction index\nT = ((byte length of transaction index) \u0026 0x03)\n# Assemble into the first byte\nByte0 = V | M | B | T\n\nThis gives you up to 3 bytes for each block and transaction reference,\nwhich is 16.7 M blocks, or year 2336, and 16.7 M transaction slots.\n\nData part: [Byte0][optional magic bytes 1-2][block reference bytes][tx\nreference bytes]\n\nSo the shortest data part would have 3 bytes in it, with the reference\nversion 0 genesis coinbase transaction having data part 0x050000.\n\nI know this is a departure from your vision, but it would be much more\nflexible for the long term.\n\n\nClark",
"sig": "e9e4d9eb7cfc7b4fdbe650f30a2685f003cec4468b5a1ad6e7f413223229152c019ea5fc7c5404d5f9ace3fe5cdcb27023c16e3666e1bde09e68cb4ef19b5faa"
}