Snowblossom Docs
Explorersnowblossom.orgGitHub
/
Docs › Reference › Proposals (SIPs)

Proposals (SIPs)

Protocol changes are proposed as Snowblossom Improvement Proposals and decided by miner signalling in the coinbase. The mechanism is deliberately minimal: a proposal has a number, miners put that number in motions_approved or motions_rejected of the blocks they mine, and the result is read off the chain. Six SIPs have been adopted.

How voting works

  • Every coinbase carries CoinbaseExtras.motions_approved and motions_rejected (lists of proposal numbers). Miners set them with vote_yes=1,2 / vote_no=3 in the miner config; pools set them in pool.conf and thereby vote on behalf of their miners. Blocks that carry no vote are not counted.
  • The adopted convention: a proposal passes when, over a window of 1,000 blocks, at least 25 % of blocks vote and more than 50 % of the votes are in favour.
  • Nothing in consensus reads the votes. The developers implement a passed proposal in a release and, for hard-forking changes, set an activation height in NetworkParams roughly 90 days out so node operators can upgrade. Non-forking changes (like SIP-2's work weighting) can be adopted by nodes at any time.
  • The explorer's votes page tallies signals over recent blocks.

SIP-1 - Fix block reward halving time

Status
passed implemented in 1.1.2 (2018)
Type
consensus (reward schedule)

During testing the halving interval had been set to one year instead of the intended four, which would have put 97 % of the supply into circulation within five years and capped it at 5,256,000 SNOW. The proposal restored the four-year interval (210,240 blocks) and the ≈ 21,024,000 cap. Although clearly a bug, the team chose a vote over a unilateral change. The first halving then occurred at block 210,240 (6 May 2022).

SIP-2 - Increase work weighting for higher fields

Status
passed at block 7,289
Type
chain selection (no fork)

Attack it closes: a miner with substantial but minority hash rate forks privately just before a snow storm, keeps difficulty high enough to stay ahead of the public chain (whose hash rate drops as miners migrate to the new field) but low enough not to activate the new field, then publishes a heavier chain. The fix multiplies each block's work by 4activated_field, so a chain on a newer field outweighs any chain on an older one unless the attacker sustains four times the network's hash rate. Nodes do not need to agree on work sums, so this was deployed without an activation height.

SIP-3 - Output locking and extra data

Status
passed at block 22,157; active from block 35,000 (6 Jan 2019), release 1.4.0
Type
hard fork

Added TransactionRequirements{required_block_height, required_time} on outputs (an output cannot be spent before the given height/time) and allowed extra data on outputs - for_benefit_of_spec_hash and the ids claims - with no protocol meaning. Together they allow staking funds behind social identities, the basis of Snowblossom Channels' name registration. Before height 35,000 outputs with these fields are invalid.

SIP-4 - Optional input value

Status
passed (~block 134,400); enforced from block 151,680 (25 Mar 2021), release 1.8.0
Type
hard fork (new validation rule)

Adds TransactionInput.value. When non-zero, validation requires it to equal the value of the output being spent, so an offline signer can see the full amounts (and the fee) of a transaction without a UTXO set. It also enabled the Rosetta API's offline /construction/parse. The wallet does not set the field by default.

SIP-5 - Sharding (“Snowblossom Braid”)

Status
passed at block 198,613 (approved 14 Feb 2022); active from block 211,600 (15 May 2022), release 2.0.0 “Wee Big Shards”
Type
hard fork (header version 2)

Brought in the shardo branch: an L1 scaling design in which the chain splits into a binary tree of shards under load, cross-shard transfers by committed root hashes, a revamped P2P block sync based on previews, and the 2.0 version number. It had run for months on testnet and the dedicated shard test networks, which split from one shard into several under load as designed. Node operators had to upgrade before the activation height; the on-disk database was compatible apart from a one-time summary re-index. Known gaps at the time: clients may need several nodes after a split, and the explorer needed shard-aware summaries (since done). See Sharding.

SIP-6 - Post-quantum cryptography

Status
adopted without objections; active from block 358,700 (5 Mar 2025), release 2.2.0 “Post Quack Chillin”
Type
hard fork (new signature types)

Adds three signature algorithms from the NIST PQC process: Dilithium (lattice; public key 2,616 B, signature ≈ 4,627 B), Falcon (lattice, compact; 915 B / ≈ 655 B) and SPHINCS+ (hash-based, so safe even if lattice cryptography breaks; 52 B / 7,856 B), compared with ECDSA's 33 B / 71 B. Signatures of the SPHINCS+ and Dilithium types are rejected before the activation height. Users choose whether to use them (wallet types pqc1, pqc_lite); migrating means sending coins to a new wallet. Risk noted in the proposal: the algorithms are young and BouncyCastle's implementations could still change. See Quantum resistance.

Ideas that were discussed but not proposed

  • Time-shifted multisig: announce a transaction with only a subset of signatures so the UTXOs are provisionally locked, and complete the signatures later - removing the race with a quantum attacker between broadcast and confirmation. Would need a new address-spec hashing format and expiry rules.
  • Light validation of shards: prove a block valid to a header-only node with UTXO trie fragments (shard-notes.md).
  • Distributed privacy mixer and Snow Payments and Auth (micro-payments for web content) from the road map.