Sigil Signals

Sigil Signals Using nSequence Transaction Input Field

Introduction

The Sigil Protocol leverages the Bitcoin nSequence field to encode specific protocol signals. This mechanism ensures clear lightweight protocol identification for processing of Sigil-related transactions without disrupting native Bitcoin transactions. The Sigil Signals are used for efficient filtering of Bitcoin transactions without needing to first check if there is an Ordinals inscription or Rune metadata in OP_RETURN, which would require a more resource intensive indexer. Importantly, there is no increase in txn size.

Sigil Signals maintains the standardness of bitcoin transaction processing, ensuring broad compatibility with existing Bitcoin infrastructure. Extending the purpose of the nSequence 4 byte data field does not interfere with known usages such as Relative Locktime and Replace-by-Fee (RBF).

nSequence History

The nSequence was introduced in the original Bitcoin implementation by Satoshi Nakamoto. The initial idea was to enable updates to transactions before they were finalized, allowing for more flexible and dynamic transaction management, but the field was never fully utilized in the early stages of Bitcoin.

In 2016, new Bitcoin Improvement Proposals (BIPs) were introduced that repurposed the nSequence field.

Relative Locktime

BIP 68 repurposed nSequence to support relative locktime, allowing transactions to specify a minimum age (in blocks or time) before they could be included in a block. BIP 68 defined how nSequence bits would be interpreted to enable this functionality.

Replace-by-Fee (RBF)

BIP 125 introduced RBF which allowed transactions to be flagged as replaceable if they had an nSequence value below a certain threshold (0xFFFFFFFE), enabling users to increase transaction fees to speed up confirmation times.

• Bits 0-15: Represent the relative locktime value.

• Block-Based Locktime: If bit 22 is 0, the value in bits 0-15 is interpreted as the number of blocks.

• Time-Based Locktime: If bit 22 is 1, the value in bits 0-15 is interpreted as the number of seconds (with a granularity of 512 seconds).

Sigil Encoding with nSequence

The existing uses of nSequence as defined in BIP 68 (Relative Timelock), BIP 125 (Opt-in Replace-by-Fee) do not conflict with Sigil's proposed use of the lower bytes for signaling. Sigil's reserved ranges are specifically chosen to be compatible and coexist with these established usages:

1. BIP 68 uses bits 0-15 for the locktime value and bit 22 to distinguish between time-based and block-based locks. Sigil's signals do not interfere with these lower bits when used in conjunction with relative timelocks.

2. BIP 125 considers transactions with nSequence values below 0xFFFFFFFE as replaceable. Sigil's signals, being in the lower bytes, maintain compatibility with RBF signaling.

Sigil Reserved Flag Ranges - 0x40-0x49 | 0x80-0x89

Sigil utilizes a reserved range of flags to represent different types of signals and actions within the Sigil Protocol, as needed. These flags will be part of expanding the protocol through iterations and versions over time. The range of flags will be reduced to a more conservative range and this is only a proposal for this draft version of this document.

Sigil Runic Unicode Character

By default, Sigil incorporates the runic character ᛋ into the 4-byte space for additional data encoding. This character is used as the Sigil Protocol logo and will be present if/when there is no need for other data beyond the flags. Other runics or emojis may also be used by the protocol to represent specific protocol actions or operations.

Default Sigil Encoding

• Prefix Flag: 0x40

• Runic Character: ᛋ (E1 9B 8B)

• Encoded as UINT32:

  • Big-Endian: 0x40E19B8B

    • Decimal: 1086485259

  • Little-Endian: 0x8B9BE140

    • Decimal: 2344816320

Combining Sigil Signals with RBF and Relative Locktime

Overview

• Replace-by-Fee (RBF): Transactions with nSequence values below 0xFFFFFFFE (4294967294 in decimal) are considered replaceable.

• Relative Locktime: BIP 68 specifies that bits 0-15 of nSequence are used for locktime, with bit 22 indicating whether the locktime is in blocks or seconds.

Examples

Sigil Signal with RBF and Block-based Relative Locktime

Requirements:

• Sigil Signal: Prefix flag 0x40 and runic character "ᛋ" (E19B8B)

• RBF: nSequence value below 4294967294

• Relative Locktime (blocks): Specify a minimum block age

Encoding:

• Prefix Flag: 0x40 (64 in decimal).

• Runic Character: E19B8B (encoded in little-endian as 8B9BE1).

• Relative Locktime: 100 blocks (0x0064).

Combined Encoding:

• Bits 0-15: Relative locktime value (0x0064).

• Bit 22: Set to 0 for block-based locktime.

• Bits 23-30: Reserved for future use.

• Bit 31: Not set (0).

• Little-Endian (Raw Binary Hexadecimal): 0x9B8B6400

• Decimal: 1684235008

Sigil Signal with RBF and Time-based Relative Locktime

Requirements:

• Sigil Signal: Prefix flag 0x40 and runic character "ᛋ" (E19B8B).

• RBF: nSequence value below 4294967294.

• Relative Locktime (time): Specify a minimum time duration in seconds.

Encoding:

• Prefix Flag: 0x40 (64 in decimal).

• Relative Locktime (time): 512 seconds (0x02), bit 22 set to 1.

Combined Encoding:

• Bits 0-15: Relative locktime value (0x0002).

• Bit 22: Set to 1 for time-based locktime.

• Bits 23-30: Reserved for future use.

• Bit 31: Not set (0).

• Little-Endian (Raw Binary Hexadecimal): 0x9B8B0240

• Decimal: 2600466112

---

Sigil BIP and Metaprotocol Inclusivity

There could and maybe should be a BIP number assigned for using nSequence field for arbitrary metaprotocol use and an attempt to manage and reserve/register nSequence flag assignments.

Regardless, Sigil Protocol will proceed in much the same way many new protocols on Bitcoin have proceeded..... With respect for current standards/conventions and being a non-intrusive non-disruptive metaprotocol design. The Sigil Protocol defines it's logic and rules and in this case reserves certain flag ranges used within nSequence field as being Sigil-specific transactions.