SIP: 33 Layer: Consensus (soft fork) Title: Dilithium Coin Address Signature Author: Brian Burrell < firstname.lastname@example.org > Status: Proposed Type: Standards Track Created: 2019-08-30
The usage and methodology of the signing process is consistent with ECDSA. A pubkey is about 2.5k bytes and signature is also about 2.5k. The dilithium signing method is proposed to exclusively use the signature witness method having the affect of the longer signature not costing an additional tx fee.
The manner in which pubkey and script IDs is consistent with regular transactions. The witness v0 method is essentially identical to the dilithium witness program except that is verified using the dilithium-3 algorithm and that the public key and signature components of the segwit signature are larger in size. Note that the dilithium-3 signature, which is 2701, exceeds the traditional script maximum element size of 520 bytes.
The dilithium public key, stored in the wallet and used in transactions, is prefixed with a single byte set to the constants 0x3. This single-byte prefix is embedded for future extensions. Using the set of script ops above, the sender will include a keyid (28 bytes) and the receiver will include the full pubkey and signature.
The new signature method is exclusively isolated to a single witness program. The witness program version "14" is utilized in order to distinguish a dilithium signed transaction. Given a 20-byte key ID; a witness v14 destination address script would be "0x14 ". This is interpreted equivalent to a "OP_HASH160 OP_EQUALVERIFY" with the witness version being set to 14.
Note that a traditional witness script is not utilized (due to exclusive bech32 method). In addition, the signing method is reserved for use with the bech32 address format. As the bech32 specifies a particular witness program version, a receiver coin address can be specified that implies the signature will be stored on the segwit portion of the transaction (no counted against total block size) and that a dilithium algorithm must be used in order to verify the transaction as an subsequent input.