[Concept] Anticipation Pool - Off-chain scaling using miner-validated transaction forwarding

[Jakob Widmann]

Hello everyone,

I've been thinking extensively about how we could scale Bitcoin, particularly looking for alternatives to Lightning's limitations. My main frustrations with Lightning are the need for watchtowers, and routing complexities that arise from channel liquidity limitations. I wondered if we could leverage the existing mining infrastructure instead of building separate systems.

My goal was to find a scaling solution that:

• Eliminates watchtower requirements by using miners (who are already always online)
• Avoids channel-based routing complexities
• Guarantees eventual settlement
• Creates natural economic incentives for all participants

I'm not a Bitcoin developer, but I wanted to share this concept with the community to see if others think it could work and how it might be implemented. I'm particularly interested in feedback on the technical feasibility.

Here's the concept:

Anticipation Pool

Anticipation transactions (ATX) are pre-signed Bitcoin transactions that are forwardable to anyone without immediate blockchain settlement.

Here's how it works:

Instead of publishing transactions to the mempool to add them to the blockchain, you create a pre-signed ATX that goes into a special pool called the anticipation pool, managed by miners. Once enough miners have validated your ATX and added it to the pool (validation threshold to be determined, e.g., 10-30% of hashpower depending on amount), the recipient can consider it "confirmed". Double-spending is prevented because miners timestamp and validate each forward, with first-seen winning, and check against the anticipation pool, mempool and blockchain to ensure the outputs haven't been spent elsewhere.

The ATX has a timelock (e.g. 30 days), during this time only the recipient can publish it to the mempool, forward it to someone else (including to themselves), or split it to multiple people. Each forward or split resets this timelock, giving the new recipient the same time window. After the timelock expires, miners can publish it to the mempool (collecting the fees when it's mined).
To prevent storage bloat, only the current ATX state is kept, so when you forward or split a payment, the old ATX is deleted and only the new one(s) are stored in the pool.

The incentive for miners to manage the pool comes from the fee structure: every time someone forwards an ATX, the fee amplifies. Suggested formula: (current fee × amplification factor, e.g., 1.1) + original fee, with the exact factor needing optimization to balance scalability with miner incentives. So, if you receive 1000 sats with a 10 sat fee, forwarding costs an additional 11 sats. This amplification ensures that N forwards always cost more than N separate on-chain transactions, making pool management profitable for miners. The fees are deducted from the transaction amount itself, meaning that on each forward the additional fees reduce the recipient's amount. The original fee should have minimum requirements (potentially based on recent fee rates per byte from previous blocks, multiplied by the transaction size) to prevent gaming the system. When publishing to the mempool, recipients can voluntarily add additional fees to meet current network fee requirements for faster confirmation.

The validation thresholds, timelock duration, exact amplification factor, minimum fee requirements, and fee distribution for splits are all parameters that need to be optimized through testing.

The fee amplification creates natural economic pressure to settle on-chain rather than forward indefinitely. Recipients must decide: settle on-chain, or pay increasing fees to forward. If they don't settle or forward, miners can publish the ATX to the mempool and claim the accumulated fees after the 30-day timelock expires. When the fees would exceed the transaction amount on the next forward, the ATX becomes unforwardable and miners can immediately publish it regardless of the remaining timelock. The whole system self-regulates through pure economics rather than complex rules.

I'd appreciate any thoughts on:

• Technical feasibility
• The signing and validation mechanism for forwarding/splitting - how does a recipient create and sign a valid forward transaction that miners will accept as replacing the previous one?
• Whether this would require a soft fork, hard fork, or could work with proposed covenant designs
• Potential attack vectors I haven't considered
• Economic incentive analysis
• Optimal parameters: validation thresholds, timelock duration, amplification factor, minimum fee requirements, and fee distribution for splits

I’d appreciate any feedback, even though it’s not laid out in a very technical way.

Jakob Widmann