From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 29 Oct 2025 03:36:54 -0700 Received: from mail-oi1-f187.google.com ([209.85.167.187]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vE3Xx-0002jK-N1 for bitcoindev@gnusha.org; Wed, 29 Oct 2025 03:36:54 -0700 Received: by mail-oi1-f187.google.com with SMTP id 5614622812f47-44f78a8a66bsf267672b6e.0 for ; Wed, 29 Oct 2025 03:36:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1761734207; x=1762339007; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=4uaUBLyYRhjGTraKoE1Nmpi7RqlNyEIusG6XqTUbgrY=; b=wJbsSOcmh3WmDybKSEC+ZAvaRECzPNBKuiDLO6dZrIZSWzp8y0+N6sa67OjLDej2Md HfdBvmkAoQR8wP1mzpbf/1ewwYn8SWc2b9tmlTWT0BbzJAmly0cc8lmrR94E/iPnk4gz 496dxywdeNt3oZxg01DTqfMo7jnjfNSFy3GfHk1Tj8pAURF+EDBxCEv3jX0YvyGRSL69 S/dsFUKrTHnFuYac7fgwutLZ0f82luzW/MdBgoA2oC3575Zj03IvXTVopHoQdNr7s7KN Zp6bT4NlEUbeJSmLypXcawicTp3Qbo45RXRmBA3IFahgEaRXuLRFZhXeQEKLUkw/TuI4 8Sbw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761734207; x=1762339007; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=4uaUBLyYRhjGTraKoE1Nmpi7RqlNyEIusG6XqTUbgrY=; b=PtROiMxbaHHMAL2oHXoCwOWDdAA3LZqdAhri/yw4+yTCptOMr71HeGWPAldjbsdaUV SOl/OfyEtc39F6UJgzjKV3Uk1CQKpxnePV3I/lS+nouVePGapRQLOOEd5Ka3SdfrkzY/ jm+XT2XldkSSiKKN4muKQv0J9vKXmOq7vnw/A3D6PBNdfJkXkLmqniGEnbj4WJQD2rKt lMNKC6K/fjr+lRC7THGn36NvhL/uUD10CPben7EdqM0nZXVRsBpyZ//fs7Wmn1Q7W/u5 1H/BQWEpoU/+9uqtoUJLkbgBDGfWNGJ2px6eTmYzZv3x7A7KanleZ+XIRQBgU67uNurM ZYrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761734207; x=1762339007; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=4uaUBLyYRhjGTraKoE1Nmpi7RqlNyEIusG6XqTUbgrY=; b=piyu3Oc4KRdInrxFpELJyqpocQuHuUBY6QEtMCDT7WMOQuNWpTqNrKxXZ/2m5vzfYq bi72yTi2QheowBNnFmEM1zSDhRgRr6KvCHGV9fWZH0gW+vZHDrxOn9VxBBIns2IpSb9y LZsvw/2eKpayoJ0/A7huUiwribkchKJnS6IhEBsnJTr5dBv5o8FKumR9W/SMlC7EAwbT NIE5tZhUV+b3L6x2FdLlTCyLKDB5K1vv2yRxE53ET8Ar2m/yfbIcM1QKp7nJPHZC/rU8 +A6f4bYerrqKVuOdNAb8Qa9x7+KRxORkUj8bZOetnfvZfvhG6wwqN8fvL664MIDdxP/+ V2xw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUTdiGV0OtnDJAkPEszYnwr5WWyoGi7E957G+EojFQIDWICaP0JVTuFmE675RbJvRGeKCcvNcdl6GcJ@gnusha.org X-Gm-Message-State: AOJu0Yy6AdzbhssxCulG0WC7SZqpZngFHm/q0L6EM+YIIOb1dZOrjZlf ouFShBntzpqI9YBjU3z56UdwFRJpHnMsBa/IQDSVs+4FYkHGG2VeY1MJ X-Google-Smtp-Source: AGHT+IFDL5Q1sSZYXnxAwVZi/u8fQLH4xueVQI68uhM9ri1EZsudengrEUC5dwod6/xhka7Jdiltrg== X-Received: by 2002:a05:6870:c1d0:b0:345:ecd6:8b7 with SMTP id 586e51a60fabf-3d74829e4c8mr617754fac.11.1761734206967; Wed, 29 Oct 2025 03:36:46 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+ZBJM5Ni/WzFoFgxPcOIYBmcpm5NRhcfL1ncF4nJWqu0A==" Received: by 2002:a05:6870:241f:b0:3d5:92b8:659d with SMTP id 586e51a60fabf-3d592b86a41ls916633fac.0.-pod-prod-01-us; Wed, 29 Oct 2025 03:36:42 -0700 (PDT) X-Received: by 2002:a05:6808:1311:b0:44d:c08a:e039 with SMTP id 5614622812f47-44f7a41e774mr1367688b6e.10.1761734073633; Wed, 29 Oct 2025 03:34:33 -0700 (PDT) Received: by 2002:a05:690c:55c3:20b0:720:768:1935 with SMTP id 00721157ae682-786295c8cf7ms7b3; Wed, 29 Oct 2025 03:22:42 -0700 (PDT) X-Received: by 2002:a05:690c:6a04:b0:74e:a5d3:d95 with SMTP id 00721157ae682-78628e6024fmr22489267b3.22.1761733362190; Wed, 29 Oct 2025 03:22:42 -0700 (PDT) Date: Wed, 29 Oct 2025 03:22:41 -0700 (PDT) From: Jakob Widmann To: Bitcoin Development Mailing List Message-Id: <55e36b59-76c2-4ffc-8f36-9a9a0c2fc02bn@googlegroups.com> Subject: [bitcoindev] [Concept] Anticipation Pool - Off-chain scaling using miner-validated transaction forwarding MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_96258_323375023.1761733361855" X-Original-Sender: jweb.git@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_96258_323375023.1761733361855 Content-Type: multipart/alternative; boundary="----=_Part_96259_493306993.1761733361855" ------=_Part_96259_493306993.1761733361855 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello everyone, I've been thinking extensively about how we could scale Bitcoin,=20 particularly looking for alternatives to Lightning's limitations. My main= =20 frustrations with Lightning are the need for watchtowers, and routing=20 complexities that arise from channel liquidity limitations. I wondered if= =20 we could leverage the existing mining infrastructure instead of building=20 separate systems. My goal was to find a scaling solution that: - Eliminates watchtower requirements by using miners (who are already=20 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=20 community to see if others think it could work and how it might be=20 implemented. I'm particularly interested in feedback on the technical=20 feasibility. Here's the concept: *Anticipation Pool* Anticipation transactions (ATX) are pre-signed Bitcoin transactions that=20 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=20 blockchain, you create a pre-signed ATX that goes into a special pool=20 called the anticipation pool, managed by miners. Once enough miners have=20 validated your ATX and added it to the pool (validation threshold to be=20 determined, e.g., 10-30% of hashpower depending on amount), the recipient= =20 can consider it "confirmed". Double-spending is prevented because miners=20 timestamp and validate each forward, with first-seen winning, and check=20 against the anticipation pool, mempool and blockchain to ensure the outputs= =20 haven't been spent elsewhere. The ATX has a timelock (e.g. 30 days), during this time only the recipient= =20 can publish it to the mempool, forward it to someone else (including to=20 themselves), or split it to multiple people. Each forward or split resets= =20 this timelock, giving the new recipient the same time window. After the=20 timelock expires, miners can publish it to the mempool (collecting the fees= =20 when it's mined). To prevent storage bloat, only the current ATX state is kept, so when you= =20 forward or split a payment, the old ATX is deleted and only the new one(s)= =20 are stored in the pool. The incentive for miners to manage the pool comes from the fee structure:= =20 every time someone forwards an ATX, the fee amplifies. Suggested formula:= =20 (current fee =C3=97 amplification factor, e.g., 1.1) + original fee, with t= he=20 exact factor needing optimization to balance scalability with miner=20 incentives. So, if you receive 1000 sats with a 10 sat fee, forwarding=20 costs an additional 11 sats. This amplification ensures that N forwards=20 always cost more than N separate on-chain transactions, making pool=20 management profitable for miners. The fees are deducted from the=20 transaction amount itself, meaning that on each forward the additional fees= =20 reduce the recipient's amount. The original fee should have minimum=20 requirements (potentially based on recent fee rates per byte from previous= =20 blocks, multiplied by the transaction size) to prevent gaming the system.= =20 When publishing to the mempool, recipients can voluntarily add additional= =20 fees to meet current network fee requirements for faster confirmation. The validation thresholds, timelock duration, exact amplification factor,= =20 minimum fee requirements, and fee distribution for splits are all=20 parameters that need to be optimized through testing. The fee amplification creates natural economic pressure to settle on-chain= =20 rather than forward indefinitely. Recipients must decide: settle on-chain,= =20 or pay increasing fees to forward. If they don't settle or forward, miners= =20 can publish the ATX to the mempool and claim the accumulated fees after the= =20 30-day timelock expires. When the fees would exceed the transaction amount= =20 on the next forward, the ATX becomes unforwardable and miners can=20 immediately publish it regardless of the remaining timelock. The whole=20 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=20 does a recipient create and sign a valid forward transaction that miners= =20 will accept as replacing the previous one? - Whether this would require a soft fork, hard fork, or could work with= =20 proposed covenant designs - Potential attack vectors I haven't considered - Economic incentive analysis - Optimal parameters: validation thresholds, timelock duration,=20 amplification factor, minimum fee requirements, and fee distribution for= =20 splits I=E2=80=99d appreciate any feedback, even though it=E2=80=99s not laid out = in a very=20 technical way. Jakob Widmann --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 55e36b59-76c2-4ffc-8f36-9a9a0c2fc02bn%40googlegroups.com. ------=_Part_96259_493306993.1761733361855 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello everyone,

I= 've been thinking extensively about how we could scale Bitcoin, particularl= y 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 requi= rements by using miners (who are already always online)
  • Avoids channel-based routing complexities
  • <= span lang=3D"EN-US">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.

He= re's the concept:

Anticipation Pool

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

Here's how it w= orks:

Instead of publishing transactions = to the mempool to add them to the blockchain, you create a pre-signed ATX t= hat goes into a special pool called the anticipation pool, managed by miner= s. Once enough miners have validated your ATX and added it to the pool (val= idation threshold to be determined, e.g., 10-30% of hashpower depending on = amount), the recipient can consider it "confirmed". Double-spending is prev= ented because miners timestamp and validate each forward, with first-seen w= inning, 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 re= cipient can publish it to the mempool, forward it to someone else (includin= g to themselves), or split it to multiple people. Each forward or split res= ets this timelock, giving the new recipient the same time window. After the= timelock expires, miners can publish it to the mempool (collecting the fee= s when it's mined).
To prevent storage bloat, only the current ATX sta= te 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 struc= ture: every time someone forwards an ATX, the fee amplifies. Suggested form= ula: (current fee =C3=97 amplification factor, e.g., 1.1) + original fee, w= ith the exact factor needing optimization to balance scalability with miner= incentives. So, if you receive 1000 sats with a 10 sat fee, forwarding cos= ts an additional 11 sats. This amplification ensures that N forwards always= cost more than N separate on-chain transactions, making pool management pr= ofitable for miners. The fees are deducted from the transaction amount itse= lf, meaning that on each forward the=C2=A0additional fees reduce the recipi= ent's amount. The original fee should have minimum requirements (potentiall= y based on recent fee rates per byte from previous blocks, multiplied by th= e transaction size) to prevent gaming the system. When publishing to the me= mpool, recipients can voluntarily add additional fees to meet current netwo= rk fee requirements for faster confirmation.

The validation thresholds, timelock duration, exact amplification facto= r, minimum fee requirements, and fee distribution for splits are all parame= ters that need to be optimized through testing.

The fee amplif= ication creates natural economic pressure to settle on-chain rather than fo= rward indefinitely. Recipients must decide: settle on-chain, or pay increas= ing fees to forward. If they don't settle or forward, miners can publish th= e ATX to the mempool and claim the accumulated fees after the 30-day timelo= ck expires. When the fees would exceed the transaction amount on the next f= orward, the ATX becomes unforwardable and miners can immediately publish it= regardless of the remaining timelock. The whole system self-regulates thro= ugh pure economics rather than complex rules.

I'= d appreciate any thoughts on:

  • Technical feasibilit= y
  • The signing and validation mechanism for for= warding/splitting - how does a recipient create and sign a valid forward tr= ansaction 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
  • Econom= ic incentive analysis
  • Optimal parameters: vali= dation thresholds, timelock duration, amplification factor, minimum fee req= uirements, and fee distribution for splits

I=E2=80=99d appreciate any feedback, even though it=E2=80=99= s not laid out in a very technical way.

Jakob Widmann

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/55e36b59-76c2-4ffc-8f36-9a9a0c2fc02bn%40googlegroups.com.
------=_Part_96259_493306993.1761733361855-- ------=_Part_96258_323375023.1761733361855--