Skip to content

Latest commit

 

History

History
60 lines (36 loc) · 2.97 KB

0030-ensure-index-less-than-length-in-since.md

File metadata and controls

60 lines (36 loc) · 2.97 KB
Raw
Number Category Status Author Created
0030
Standards Track
Proposal
Ian Yang <@doitian>
2021-02-04

Ensure That Index Is Less Than Length In the Input Since Field Using Epoch With Fraction

Abstract

This document proposes adding a new consensus rule to verify the since field in the transaction.

As described in the RFC17, Transaction valid since, when a transaction input uses the epoch with fraction in the since field, the value is an encoded rational number E I/L, where

  • E is the epoch number.
  • I is the block index in the epoch.
  • L is the epoch length.

This RFC requires that when any transaction uses the epoch with fraction as the unit, the encoded number E I/L is valid only if

  • I is less than L, or
  • I and L are both zero.

If any since field is invalid, the transaction is rejected.

Motivation

The since field prevents the transaction from being mined before an absolute or relative time.

When the since field uses epoch with fraction number as the unit, the value is an encoded rational number E I/L. If it is a relative time, the rational number is used as it is. But when it is the absolute time, the special rule, Absolute Epoch With Fraction Value Normalization as mentioned in RFC17, requires normalizing the number to E+1 0/1 when I equals to or is larger than L. This document suggests adding a new rule to verify that when since uses epoch as the unit, it must ensure that the index I is less than the length L.

Specification

This RFC adds a new verification requirement on the transaction since field.

When an input since field is present, and the metric_flag is epoch (01), the value part is the encoded number E I/L. No matter whether the relative flag is relative or absolute, the number is valid if and only if

  • I is less than L, or
  • I and L are both zero.

There are no changes to the rules in RFC17, except that Absolute Epoch With Fraction Value Normalization is no longer needed.

Test Vectors

When since uses the absolute epoch 99 360/180, and the current epoch is 100 0/180, the transaction is mature using the old consensus rule but is invalid using the new rule.

Deployment

The deployment can advance in two stages.

The first stage will activate the new consensus rule, starting from a specific epoch. The mainnet and testnet will use different starting epochs and all other chains will use the new rule from epoch 0.

The second stage is optional. After the new rule is active, and the blocks in the chain before activation can also pass the new consensus rule, the old rule is redundant and can be safely removed.

Backward compatibility

The new rule is stricter than the old one thus it can be deployed via a soft fork. When most mining nodes have upgraded to the new version, the old version full nodes can keep up to date. Blocks generated by old version mining nodes may be rejected by new version full nodes.