The Singleton Token Model

TLDR; There exists a way of modelling UTXO tokens within BitcoinSV, which I call the Singleton Token Model. This token model solves the Back-to-Genesis problem by holding a single token-transaction in a non-final state in perpetuity, and never creating a connected list of transactions to represent token history. Tokens can be transferred peer-to-peer without a trusted intermediary or server-side authenticator. The only obstacle to this token model is that it requires an unbounded non-final transaction pool, which basically asks the mining network to provide double-spend protection for FREE. Read about the Non-Final Transaction Pool

This method of modelling tokens was shared with me by Jake Jones of the BitcoinSV Academy

The Singleton Token Explained

The fundamental idea behind the Singleton Token is that part of the token is perpetually held in a non-final state. I.e. part of the token can never settle on-chain to be included in a block. At the same time, we want the token to be transferrable in a P2P manner, while having the token’s authenticity attested or validated by the mining network.

We split the token into two parts :

• The On-chain Token Identity Transaction
• The Off-chain Token Ownership Transaction

We need to ensure that :

1. there exists an unbreakable link between the on-chain and off-chain transactions
2. the off-chain transaction can have it’s ownership transferred without breaking the link to the on-chain transaction

Non-finality of Ownership Transaction

In order to prevent the Ownership Tx of the token from ever being included in a block, the owner sets the nSequence number of the Ownership Tx’s (second input) to a value less than UINT_MAX. Having the nSequence less than UINT_MAX will activate the nLocktime, and prevent the transaction from block inclusion until either the nLocktime has expired, or the nSequence value has been set to UINT_MAX thereby invalidating the transaction’s interlock.

Note that if we were to ever have an on-chain commitment of the Ownership Transaction, that we would be spawning a chain of transactions, which would lead us straight into the Back-to-Genesis problem.

Locking token identity

Referring to Figure 1, notice that the issuer applies (SIGHASH_SINGLE | ANYONECANPAY) over the first input of the Token Ownership Tx to prevent defacement of the token by a third-party.

The issuer’s signature with (SIGHASH_SINGLE | ANYONECANPAY) covers :

• only the non-script fields from (input #1), excluding the nSequence number; those are:
  • The Transaction ID of the Token Identity Tx
  • The Index of the output in the Token Identity Tx
• the Script fields from the first Output in the Token Identity Tx
• all the Output fields of the (output #1) in the Token Ownership Tx
• The version and locktime fields in the Token Ownership Tx

Refer to the Signature Schemes Section in the Developer Guide to get a refresher on how the SIGHASH algorithm works.

With the issuer’s signature thus applied, the token identity is locked and secured against third-party alteration or defacement.

P2P transfer

Note that the issuer’s signature in the Non-finality section deliberately excludes signing over additional inputs and outputs not related to token identity.

This allows for third-party ownership of the token. Upon issuance the (input #2) is either funded by the recipient of the token, or by the sender (issuer on first transfer).

The (output #2) is locked to only be spendable by the current owner of the token.

IMPORTANT NOTE: The (input #2) and (output #2) is NOT there to allow the owner of the token to create a NEW on-chain spending transaction. \\ Instead, this is used to prove ownership of the token, and to allow the

Token transfer occurs by REMOVING the (output #1)

The above image represents A naive p2p transfer protocol. The important thing to note is that there is one external call to the mining network by the recipient, which tests the spendability of the token and provides double-spend protection.

Note that this is an insecure way to transfer tokens. It is advised that you establish a payment channel of some sort to facilitate the token transfer.

Token Security

The security of this token rests entirely on being able to broadcast this token into the non-final transaction pool, and having it held there in perpetuity, or until it’s redemption when it will become settle into a block.

Once this token is broadcast into the non-final pool, it becomes vulnerable. One attack against this token would be to

• copy the token and modify the (input #2) and (output #2)
• wait for the token to be evicted from the Transaction Pool without settling
• broadcast the modified transaction and thus either destroy the token, or claiming the associated redemption

With the token settlement being potentially deferred in perpetuity, and thereby never earning the mining network any fees, there exists an economic incentive for the mining network to aggressively evict inactive transactions (nSequence or nLocktime not updated) from the non-final Transaction Pool

Token storage

The Singleton Token will never be accepted into a block, and the token holder can’t take advantage of on-chain storage by default. A solution to this would be to wrap the token in a spendable data output transaction, and locking the output to an address the token holder controls e.g.

 OP_PUSHDATA [Serialized Token Ownership Tx] OP_DROP [P2PKH LOCK]

In this way, the owner’s wallet also protects against potential mempool evictions of the non-final Token Ownership Tx transaction.

Conclusion

The Singleton Token Model is a bit of a hack. This model uses the Non-Final Transaction Pool in a manner that tries to leverage the mining network’s double-spend protection without actually paying for this protection.

The Non-Final Transaction Pool is useful for use as a short-lived double-spend-protected P2P payment channel.