š
Original date posted:2019-11-13
š Original message:Good morning all,
It seems to me that adding the length for checksumming purposes need not require the length to be *actually* added in the address format.
So, currently, below is my understanding of bech32 validation:
* Run BCH checksum on witness program.
* Compare checksum to checksum in address.
* If the checksum matches:
* If version is 0, validate that the witness program is length 20 or 32.
* Else accept.
* If the checksum does not match:
* Reject
Let me propose then:
* Run BCH checksum on witness program.
* Compare checksum to checksum in address.
* If the checksum matches:
* If version is 0, validate that the witness program is length 20 or 32.
* Else validate that the witness program is length 32.
* If the checksum does not match:
* Get the length of the witness program.
* Prepend the length to the witness program.
* Run BCH checksum on concatenated length | witness program.
* Compare checksum to checksum in address.
* If the checksum matches:
* Accept.
* Else reject.
A writer of bech32 addresses would then:
* If the witness program is length 32, or witness version is 0 and witness program length is 20, use a non-length-prefixed checksum.
* Otherwise, use a length-prefixed checksum (but not include the length in the address, just change the BCH checksum).
This has the following properties:
* The bech32 address format is retained, and no explicit length is added.
* There are now two checksum formats: one with just the witness program, the other which validates with the witness program length.
* Readers that do not understand the new checksum format will simply reject them without mis-sending to the wrong witness program.
Is the above acceptable?
Regards,
ZmnSCPxj
ZmnSCPxj [ARCHIVE] /
npub1g5ā¦3ms3l
2023-06-07 18:21:38
in reply to nevent1qā¦q6vf
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-07 18:21:38Event JSON
{
"id": "d9138944aa5aeb57189fa3f5f2c66ebf0e337c8460b4db11be2d077d7e47e0b6",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686162098,
"kind": 1,
"tags": [
[
"e",
"264ef70035b4322705af56ece91da287e8a2ce6ab384f8f06caee3ab0450477c",
"",
"root"
],
[
"e",
"48499ceb991c4e46689cfa9167409f7c26b254a6940662f0bc7bc2e1a61baf4b",
"",
"reply"
],
[
"p",
"98dea680e98226bf50f3205457779fbb9d796a4546ff0042d3fba59daafc3adc"
]
],
"content": "š
Original date posted:2019-11-13\nš Original message:Good morning all,\n\nIt seems to me that adding the length for checksumming purposes need not require the length to be *actually* added in the address format.\n\nSo, currently, below is my understanding of bech32 validation:\n\n* Run BCH checksum on witness program.\n* Compare checksum to checksum in address.\n * If the checksum matches:\n * If version is 0, validate that the witness program is length 20 or 32.\n * Else accept.\n * If the checksum does not match:\n * Reject\n\nLet me propose then:\n\n* Run BCH checksum on witness program.\n* Compare checksum to checksum in address.\n * If the checksum matches:\n * If version is 0, validate that the witness program is length 20 or 32.\n * Else validate that the witness program is length 32.\n * If the checksum does not match:\n * Get the length of the witness program.\n * Prepend the length to the witness program.\n * Run BCH checksum on concatenated length | witness program.\n * Compare checksum to checksum in address.\n * If the checksum matches:\n * Accept.\n * Else reject.\n\nA writer of bech32 addresses would then:\n\n* If the witness program is length 32, or witness version is 0 and witness program length is 20, use a non-length-prefixed checksum.\n* Otherwise, use a length-prefixed checksum (but not include the length in the address, just change the BCH checksum).\n\nThis has the following properties:\n\n* The bech32 address format is retained, and no explicit length is added.\n* There are now two checksum formats: one with just the witness program, the other which validates with the witness program length.\n * Readers that do not understand the new checksum format will simply reject them without mis-sending to the wrong witness program.\n\nIs the above acceptable?\n\nRegards,\nZmnSCPxj",
"sig": "521391d89f7261911feecbf674f1cb9ada5ca3d6605e977ddbca2844a7e97b9808c425a45c44442cdea4fc82992e03891c8035240a8e1ceb6c9d7be54af3648a"
}