Nakamoto Design - Method of Enforcing Inclusion of 0 Fee Signer Transactions

[AshtonStephens]

This is a research discussion on how we might implement the tracking of 0 Fee singer transactions that need to be included in the block without prior to signer acceptance.

[jcnelson]

The method of doing this is straightforward: stacker signers don't sign a block unless it includes the zero-fee transactions. Thus, miners are obliged to include them in order to get their coinbase.

First, signers would coordinate via StackerDB to produce the requisite transactions (such as a challenge response). Once they have the transaction, they store it into a designated slot within their StackerDB instance. Second, when a miner goes to produce a block, it polls that slot in the StackerDB instance to see if there are one or more such transactions that must be included. If so, then the miner downloads them and adds them to the block it's producing. Third, the miner produces and signs the block, and sends it to Stackers for sign-off (via StackerDB). Finally, the Stackers verify that the zero-fee transactions that were placed in the StackerDB back in step one are present in the block. If the block has the requisite transactions, then Stackers (1) sign the block, (2) broadcast the block via the p2p network, and (3) store the signed block header in a designated StackerDB slot to ACK the miner's block and thus signal to it that the next block can be produced. If the block does not have the requisite transactions, then Stackers instead sign a NACK message and place it in the same designated StackerDB slot. The NACK would include the requisite transactions (or perhaps a pointer to them), so the miner knows to try again but with the requisite transactions.

Implicit in all of this is the fact that both Stackers and miners use StackerDBs to communicate. Stackers write their pending zero-fee transactions to the Stacker-controlled StackerDB (e.g. the one governed by .pox-4), and miners write their pending blocks to the miner-controlled StackerDB (e.g. the one governed by .miners). Stackers' and miners' nodes subscribe to both StackerDBs, so both Stackers and miners will see each other's messages.