* [bitcoindev] [Concept] Anticipation Pool - Off-chain scaling using miner-validated transaction forwarding
@ 2025-10-29 10:22 Jakob Widmann
0 siblings, 0 replies; only message in thread
From: Jakob Widmann @ 2025-10-29 10:22 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 5302 bytes --]
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
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/55e36b59-76c2-4ffc-8f36-9a9a0c2fc02bn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 6227 bytes --]
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2025-10-29 10:36 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-10-29 10:22 [bitcoindev] [Concept] Anticipation Pool - Off-chain scaling using miner-validated transaction forwarding Jakob Widmann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox