Why Nostr? What is Njump?
2023-06-07 18:00:33
in reply to

praxeology_guy [ARCHIVE] on Nostr: šŸ“… Original date posted:2017-04-26 šŸ“ Original message:Johnson Lau, > not change ...

šŸ“… Original date posted:2017-04-26
šŸ“ Original message:Johnson Lau,

> not change the commitment structure as suggested by another post

Not sure if you realize my proposal is backwards compatible. We could also merge the two arrays, which would be harder to compress, but a more simple format. Below I gave an example of how this would be backwards compatible.

1-byte - OP_RETURN (0x6a)
1-byte - Push the following 36 bytes (0x24)
4-byte - Commitment header (0xaa21a9ed)
32-byte - Commitment hash: Double-SHA256(witness root hash|witness reserved value*)
variable bytes - Extension roots: array of {extension identifier, extension root length, extension root}
bytes onwards: Optional data with no consensus meaning

* "witness reserved value" _must_ also go in the input's scriptSig/witness field

Here is an example of the "Extension roots" with this format:
Extension roots: 2, {0, 0, []}, {1, 0, []}

size = 2 // two elements in Commitment hash
{ext.id = 0, length = 0, empty} // First element is the wtxid merkle root hash, must be calculated, not specified here
{ext.id = 1, length = 0, empty} // Second element is the "witness reserved value", which is found in the scriptSig

Later after all the miners upgrade, we could stop using the ext.id = 1 and also stop putting the unneccesary value in scriptSig.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170426/b8487e38/attachment-0001.html>;
Author Public Key
npub1hzkv59ax7ax80nv2fzvcgmveqyk3k5sg9gq695n48l9scenf5c9sa7nzv7