Ideally, we want to tie every output to the input that spends it, so it can't be double-spent. But this can't be done before the input exists, so the output must be tied to an intermediary, which gets tied to the input when it's created. This introduces a degree of trust, and a degree of risk.

In this blockless consensus scheme, the intermediary is a ticket. Tickets are created by mediators, who serve the same role as miners. A ticket contains the txid and index of the target output, a confirmation public key, and a payment address. The mediator use a double-key algorithm to create their confirmation pubkey, similar to the one used to create a payment address. They have to scan over a range of private keys until they find one that produces a public key that contains at least one leading zero. They publish their ticket as proof, which everyone adds to their ticket pool.

When the owner of an unspent output creates a transaction to spend it, they must include, in each input, the most difficult pubkey available in the ticket pool for the corresponding output, and create a coinbase output with each mediator's payment address. These input/coinbase pairs always appear first in the transaction, with the same index values, and are sorted by difficulty in ascending order. The owner must sign each input independent of the others, in case any of them need to be replaced. After the owner publishes the transaction, the mediators confirm it by signing the inputs that contain their pubkeys. All but the last mediator signs their input independently. The last mediator signs everything. To minimize network traffic, inputs are signed in the order of their index values.

There's no limit to the number of tickets per unspent output, but an input can only have one unique confirmation pubkey, so pubkeys can't be used more than once, and cannot coexist in multiple tickets at once. There's no limit to the difficulty of a confirmation pubkey, so mediators can constantly work to upgrade their tickets with more difficult pubkeys. The effort required to upgrade a pubkey increases exponentially with it's difficulty, so the coinbase reward should scale exponentially as the zero count increases linearly. After an output is spent, all unused pubkeys can be presented in new tickets for other unspent outputs, so the work isn't wasted.

In the absence of a consensus protocol, a p2p network has no method of resolving double spend attacks consistently, by always accepting the same transaction. A simple decision is all the network requires. A miner performs this function by choosing which transaction to include in their block, while the mediator chooses which transaction to sign. The question is whether a signature is as secure as a block hash. Just as a block hash is a checksum on the block and every block before it. the last signature in a transaction is a checksum on the transaction, and every input is chained to a previous transaction. But a signature is still no iron-clad guarantee of the absence of a double-spend transaction, and neither is a block hash. Just as a malicious mediator can sign more than one input at a time, a malicious minor can solve more than one block at a time. With a good rule set that covers all possible outcomes, a network using either protocol can mitigate the misbehavior, but there is always a risk that a payee can be fooled. The only real difference between a signature and a block hash is the speed. A signature takes milliseconds, and only delays a single transaction, while a block hash can take hours, and delays everything.

Usually, all a mediator must do is sign the first input they see that contains their pubkey. If they sign more than one input for the same output, their ticket is destroyed because it can never happen by accident. If a mediator fails to sign their input within a reasonable time, a few seconds perhaps, the owner can simply replace the ticket for that input. If an attacker uses different tickets in each double-spend transaction, the pubkey with the lowest difficulty is discarded. This scenario might also happen unintentionally when a ticket is replaced. The more inputs a transaction has, the longer it takes to get confirmed because the more it has to travel around the network. If multiple transactions contain multiple double-spends, each with different tickets, the last mediator's should see all transactions before they have the opportunity to sign one, and they should sign only if the transaction that contains their pubkey also has the most combined difficulty. If a mediator sees a transaction that contains a weaker pubkey for the same output they have a stronger pubkey for, it serves as advanced warning.