UPDATE: - Article updated to account for nSequence flaw. See section on Security Concerns.
TLDR; The previously discussed implementation of the Singleton Token Model had a flaw which made it impractical for day-to-day use. I have modified the token model construction to retain it’s key properties, while making it practical for everyday use. The solution combines client-side ECDSA verification, SPV and the non-final transaction pool of a mining node into an efficient protocol for miner-validated tokens that can be authenticated client-side without an expensive retracing of the token history. We retain the properties of miner-validation, client-side authentication and non-permissioned, trustless P2P exchange.
Caution: This is a thought-experiment at the moment. I have not written any code to validate the method I detail here. Please read this with a critical eye, and provide feedback as necessary.
By way of demonstrating one of the key aspects of the token protocol, we will now proceed to describe the construction of a “mini-ledger”. Our ledger will have the following properties:
We link rows in the ledger by signing over three-out-of-four fields and storing the signature in the fourth field. In Figure 1 we generate a signature over the highlighted portions of rows (1) and (2), and store the signature in the second column or row (2).
We continue to do this iteratively for each row. E.g. row (2)’s signature is generated by signing the fields in row (2) along with the field in the first column of row (3). We then store row (2)’s signature in the second column of row (3)
For each of the rows we can have a different signatory. That would mean e.g. that signatory #1 has their signature in row(2), column(3) etc.
By doing this, we are indelibly linking the rows together, and one can’t remove any of the rows without ruining the signatures.
Recall now, that in order to spend a Bitcoin UTXO, we usually generate a signature for (input #1) in Figure 2 using a SIGHASH algorithm of our choosing.
Combining the concepts from (Step 1) and (Step 2), we get an immutable “mini ledger”. To firm up our mini-ledger scheme we will assume that each row in the ledger represents a transfer of ownership, and that the ledger can be appended to only. Removal or modification of any rows in the middle, or at the end will break the signature chain and invalidate the ledger.
We use an ECDSA signature scheme, and require that the signatures for the “mini ledger” be generated with the same key that signed the spending condition for the input in the preceding row.
Therefore, the signature in row 2, must be generated using the private key that is used to create the signature for in_1 (input #1), signature in row 3 is generated with private key used for in_2, etc.
NOTE that we can accomplish this ledger construction by using a Signature scheme of (SIGHASH_ANYONECANPAY | SIGHASH_SINGLE), which ensures that we only sign row-by-row for the UTXO spend, and allows for additional rows to be added to our ledger.
Our intention with our redesigned Singleton Token is now to :
The transfer proceeds exactly as the first transfer has done.
The token transfer process represents a potential scenario where loss-of-funds could occur. Above we propose a simple timelock scheme alongside miner-validation to secure funds. This could be enhanced further by layering in a 2/2 multisig into the exchange, but that’s beyond the scope of this post.
It is important to have a secure protocol that leverages the non-Final Transaction Pool to append a new entry to the mini-ledger. The non-Final Transaction Pool is used as intended; a temporary space to allow for miner-validation of a transaction’s inputs and outputs.
Notice that combining the two signature schemes allows:
IMPORTANT: There exists the potential for an earlier holder of the token to broadcast the transaction and force the token to be settled on-chain. This is because we cannot assert an nSequence lock with how we are chaining signatures. One way to fix this is for the Issuer to use an OP_PUSH_TX covenant that enforces an active nSequence. That way, the Issuer’s initial UTXO will never pass miner validation.
Alternately, the new recipient of a token can require that the previous ownership of a token must include at least one nSequence covenant enforced by a UTXO.
Our modified Singleton Token scheme combines several aspects of Bitcoin to arrive at a solution. With each token transfer our off-chain mini-ledger grows by a small amount. The size of growth depends on whether the token protocol calls for additional meta-data in the outputs. At a minimum, each new Input + Output should add around 200 bytes of data to the ledger (estimated).
The modest growth of the mini-ledger along with the computational expense of performing client-side ECDSA verification over a number of iterations must be kept in mind when considering if this protocol is a good fit for your project.