Aug 24 - Aug 31, 2026
This method, designated as SPc, incorporates the Silent Payments protocol outlined in BIP352. It employs a static public address system comprising a scan key and a spend key for each miner. This setup is critical as it addresses the risk associated with exposing transaction histories through traditional methods that use extended public keys. In the proposed framework, miners submit their Silent Payment addresses through the Stratum v2 protocol upon establishing a connection with a mining pool. The pool then records these addresses in its accounting database to correctly assign hashrate credits.
A significant technical challenge within SPc involves adapting coinbase transactions, which traditionally lack inputs, to support Silent Payments. This adaptation utilizes a nonce derived from block height combined with a pool-specific public key to secure transactions. Miners' public keys are embedded in the coinbase script, replacing traditional identifiers to facilitate cryptographic operations necessary for determining payment recipients. However, this system introduces complexities in payout computations and may require changes in payout structures to accommodate smaller miners, similar to solutions like Ocean’s BOLT12 Lightning Network payments. Additionally, managing the number of payouts included in a single coinbase transaction is crucial to avoid problems such as dust outputs.
For broader acceptance and development of SPc, community engagement is essential. Platforms like GitHub serve as valuable resources for accessing test vectors and refining SPc specifications towards a formal Bitcoin Improvement Proposal (BIP). Furthermore, understanding the compatibility of digital wallets with Silent Payments is crucial. Wallets must either inherently support such transactions or require updates to process them effectively. Clear communication about these technical prerequisites can aid users and miners in seamlessly integrating and utilizing this new transaction method.
Another aspect of transaction management involves the encoding of block height in the coinbase scriptSig as per BIP34, which currently consumes significant transaction data space. With block heights now requiring four bytes for encoding, only about 62 bytes remain available for extranonce within the maximum allowed 100 bytes. This space constraint could tighten further as block heights increase beyond 16,777,215, potentially necessitating additional bytes. The ongoing increase in BIP34 encoding costs underscores the evolving challenges in managing transaction space efficiently. These developments highlight the need for continued innovation and adaptation in cryptocurrency technologies to maintain functionality and user privacy amidst growing technical demands.
TLDR
We’ll email you summaries of the latest discussions from high signal bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.
We'd love to hear your feedback on this project.
Give Feedback