Transaction kernels "feature" is specified as the first byte.
Add a new "unknown" kernel variant for all kernel feature byte >= 4.
- Plain: 0 (
- Coinbase: 1 (
- HeightLocked: 2 (
- NoRecentDuplicate: 3 (
- Unknown: >=4 (
Kernel features [0, 1, 2, 3] are implicitly sized, based on the kernel feature.
For example a NoRecentDuplicate kernel -
1 byte | 8 bytes | 2 bytes | 33 bytes | 64 bytes feature | fee | relative_height | excess commitment | signature
Kernel features >= 4 are unknown and must be explicitly sized. The two bytes immediately following the feature byte specify the size (u16) of the additional data, excluding the excess commitment and the signature.
u16 the right thing to use for size here? Would
u8 potentially be sufficient?]
1 byte | 2 bytes | [size] bytes | 33 bytes | 64 bytes feature | size | additional data | excess commitment | signature
This allows "unknown" kernels to be supported as the explicit size would allow them to be correctly serialized/deserialized.
The kernel signature message would include both size and additional data, as raw bytes, regardless of content -
Hash(feature | size | additional_data)
Consensus rules would still apply. The signature could still be verified against the excess commitment.
What about fees?
The above would simply treat an unknown kernel as having 0 fees. For a transaction to be valid it would need to contain at least additional kernel specifying the correct fee.
Alternatively we could support unknown kernels with optional fee via one of the bits in the feature byte.
An unknown kernel with fee bit set would treat the first 8 bytes of the addtional data as the fee (
u64) and the remainder as opaque.
An unknown kernel with the fee but unset would treat the full additional data as opaque.
Feature 4 (
00000100) would be an unknown kernel with 0 fee.
Feature 5 (
00000101) would be an unknown kernel with fee specified in additional data (first 8 bytes).
This would allow unknown kernels to participate in the fee related consensus rules while still allowing for the possibility of future unknown kernel variants that do not have an associated fee.
This would allow for "softfork" compatible future kernel variants.
Existing nodes would simply treat additional data as opaque yet still support kernel signature verification. Softfork nodes would be able to parse additional data and apply additional consensus rules.
For example we could introduce a DeadBeef kernel variant via the "unknown" feature byte
Existing nodes will treat additional data as opaque and simply verify the kernel signature.
Softfork consensus rule states the first 8 bytes of additional data must be
Alternatively this could be introduced via the feature byte
00000101 with the kernel including a fee.
Softfork consensus rule states the first 8 bytes of additional data represents the fee followed by
DEADBEEF in the next 8 bytes.