PTLC - Revision history

NotATether: Move deployment paragraph under Deployment

2026-09-13T07:30:49Z

Move deployment paragraph under Deployment

← Older revision		Revision as of 07:30, 13 September 2026
Line 8:		Line 8:

	An adaptor signature is a Schnorr signature encrypted to a point ''T''. Completing the signature reveals the discrete logarithm of ''T'', which the receiver can reuse as proof across a chain of PTLCs. Onion routing can still hide the destination, but each hop's lock point can be derived so intermediaries cannot match payments by a shared hash. Refund paths keep a timeout similar to HTLCs so stalled payments can be cancelled on chain if needed.		An adaptor signature is a Schnorr signature encrypted to a point ''T''. Completing the signature reveals the discrete logarithm of ''T'', which the receiver can reuse as proof across a chain of PTLCs. Onion routing can still hide the destination, but each hop's lock point can be derived so intermediaries cannot match payments by a shared hash. Refund paths keep a timeout similar to HTLCs so stalled payments can be cancelled on chain if needed.

			== Deployment ==

	Deploying PTLCs on Lightning also needs invoice and proof-of-payment formats that are not built solely around preimages, plus channel commitment layouts that can carry point locks. Research prototypes and wallet experiments exist, but public routing still settles with [[Hash Time Locked Contracts]]. Related scriptless constructions include atomic swaps that exchange adaptor signatures instead of hash preimages.		Deploying PTLCs on Lightning also needs invoice and proof-of-payment formats that are not built solely around preimages, plus channel commitment layouts that can carry point locks. Research prototypes and wallet experiments exist, but public routing still settles with [[Hash Time Locked Contracts]]. Related scriptless constructions include atomic swaps that exchange adaptor signatures instead of hash preimages.

	~~== Deployment ==~~

	Proof of payment under HTLCs is the preimage. Under PTLCs it is knowledge of a scalar tied to the payment point. Accounting systems and watchtowers that key state by payment hash would need parallel identifiers during a migration. Multi-path payments would likewise need point commitments that still allow partial success and failure across shards.		Proof of payment under HTLCs is the preimage. Under PTLCs it is knowledge of a scalar tied to the payment point. Accounting systems and watchtowers that key state by payment hash would need parallel identifiers during a migration. Multi-path payments would likewise need point commitments that still allow partial success and failure across shards.
Line 18:		Line 18:

	Interoperable public routing will lag wallet prototypes until BOLT feature bits, invoice fields, and commitment formats are agreed and widely implemented.		Interoperable public routing will lag wallet prototypes until BOLT feature bits, invoice fields, and commitment formats are agreed and widely implemented.


	== See also ==		== See also ==

NotATether: Add Adaptor locks and Deployment sections

2026-09-13T07:30:20Z

Add Adaptor locks and Deployment sections

← Older revision		Revision as of 07:30, 13 September 2026
Line 2:		Line 2:

	An HTLC locks coins to the preimage of a hash. Every hop of a routed Lightning payment typically uses the same hash, which can let observers correlate those hops. A PTLC instead locks to a curve point and unlocks via an adaptor signature. Per-hop blinding can give each intermediary a different point, so adjacent hops need not share a common lock value. On-chain, cooperative settlement can stay off chain as with HTLCs. A force-close under Taproot need not reveal a shared payment hash the way a HASH160 HTLC script can.		An HTLC locks coins to the preimage of a hash. Every hop of a routed Lightning payment typically uses the same hash, which can let observers correlate those hops. A PTLC instead locks to a curve point and unlocks via an adaptor signature. Per-hop blinding can give each intermediary a different point, so adjacent hops need not share a common lock value. On-chain, cooperative settlement can stay off chain as with HTLCs. A force-close under Taproot need not reveal a shared payment hash the way a HASH160 HTLC script can.

			== Adaptor locks ==

	Taproot and BIP340 made Schnorr adaptor constructions practical on Bitcoin. Lightning still routes with HTLCs because interoperable hops, invoices, and proof-of-payment flows are built around preimages. Mixed HTLC and PTLC paths would be needed during any transition.		Taproot and BIP340 made Schnorr adaptor constructions practical on Bitcoin. Lightning still routes with HTLCs because interoperable hops, invoices, and proof-of-payment flows are built around preimages. Mixed HTLC and PTLC paths would be needed during any transition.
Line 8:		Line 10:

	Deploying PTLCs on Lightning also needs invoice and proof-of-payment formats that are not built solely around preimages, plus channel commitment layouts that can carry point locks. Research prototypes and wallet experiments exist, but public routing still settles with [[Hash Time Locked Contracts]]. Related scriptless constructions include atomic swaps that exchange adaptor signatures instead of hash preimages.		Deploying PTLCs on Lightning also needs invoice and proof-of-payment formats that are not built solely around preimages, plus channel commitment layouts that can carry point locks. Research prototypes and wallet experiments exist, but public routing still settles with [[Hash Time Locked Contracts]]. Related scriptless constructions include atomic swaps that exchange adaptor signatures instead of hash preimages.

			== Deployment ==

	Proof of payment under HTLCs is the preimage. Under PTLCs it is knowledge of a scalar tied to the payment point. Accounting systems and watchtowers that key state by payment hash would need parallel identifiers during a migration. Multi-path payments would likewise need point commitments that still allow partial success and failure across shards.		Proof of payment under HTLCs is the preimage. Under PTLCs it is knowledge of a scalar tied to the payment point. Accounting systems and watchtowers that key state by payment hash would need parallel identifiers during a migration. Multi-path payments would likewise need point commitments that still allow partial success and failure across shards.

	Adaptor-signature PTLCs assume Schnorr and preferably Taproot channel commitments so force-closes do not leak a reusable hash. Legacy HTLC scripts can remain for peers that lack the feature bits. Until BOLTs define those bits and invoice fields, public pathfinding continues to advertise HTLC-based routes.		Adaptor-signature PTLCs assume Schnorr and preferably Taproot channel commitments so force-closes do not leak a reusable hash. Legacy HTLC scripts can remain for peers that lack the feature bits. Until BOLTs define those bits and invoice fields, public pathfinding continues to advertise HTLC-based routes.

			Interoperable public routing will lag wallet prototypes until BOLT feature bits, invoice fields, and commitment formats are agreed and widely implemented.


	== See also ==		== See also ==

NotATether: Add Taproot channel and BOLT status caveat

2026-09-13T07:27:52Z

Add Taproot channel and BOLT status caveat

← Older revision		Revision as of 07:27, 13 September 2026
Line 10:		Line 10:

	Proof of payment under HTLCs is the preimage. Under PTLCs it is knowledge of a scalar tied to the payment point. Accounting systems and watchtowers that key state by payment hash would need parallel identifiers during a migration. Multi-path payments would likewise need point commitments that still allow partial success and failure across shards.		Proof of payment under HTLCs is the preimage. Under PTLCs it is knowledge of a scalar tied to the payment point. Accounting systems and watchtowers that key state by payment hash would need parallel identifiers during a migration. Multi-path payments would likewise need point commitments that still allow partial success and failure across shards.

			Adaptor-signature PTLCs assume Schnorr and preferably Taproot channel commitments so force-closes do not leak a reusable hash. Legacy HTLC scripts can remain for peers that lack the feature bits. Until BOLTs define those bits and invoice fields, public pathfinding continues to advertise HTLC-based routes.

	== See also ==		== See also ==

NotATether: Add proof-of-payment and multipath migration notes

2026-09-13T07:27:50Z

Add proof-of-payment and multipath migration notes

← Older revision		Revision as of 07:27, 13 September 2026
Line 8:		Line 8:

	Deploying PTLCs on Lightning also needs invoice and proof-of-payment formats that are not built solely around preimages, plus channel commitment layouts that can carry point locks. Research prototypes and wallet experiments exist, but public routing still settles with [[Hash Time Locked Contracts]]. Related scriptless constructions include atomic swaps that exchange adaptor signatures instead of hash preimages.		Deploying PTLCs on Lightning also needs invoice and proof-of-payment formats that are not built solely around preimages, plus channel commitment layouts that can carry point locks. Research prototypes and wallet experiments exist, but public routing still settles with [[Hash Time Locked Contracts]]. Related scriptless constructions include atomic swaps that exchange adaptor signatures instead of hash preimages.

			Proof of payment under HTLCs is the preimage. Under PTLCs it is knowledge of a scalar tied to the payment point. Accounting systems and watchtowers that key state by payment hash would need parallel identifiers during a migration. Multi-path payments would likewise need point commitments that still allow partial success and failure across shards.

	== See also ==		== See also ==

NotATether: Expand See also links

2026-09-12T21:11:18Z

Expand See also links

← Older revision		Revision as of 21:11, 12 September 2026
Line 14:		Line 14:
	* [[Taproot]]		* [[Taproot]]
	* [[MuSig]]		* [[MuSig]]
			* [[FROST]]

	== External links ==		== External links ==

NotATether: Add deployment status and invoice caveats

2026-09-12T21:11:16Z

Add deployment status and invoice caveats

← Older revision		Revision as of 21:11, 12 September 2026
Line 6:		Line 6:

	An adaptor signature is a Schnorr signature encrypted to a point ''T''. Completing the signature reveals the discrete logarithm of ''T'', which the receiver can reuse as proof across a chain of PTLCs. Onion routing can still hide the destination, but each hop's lock point can be derived so intermediaries cannot match payments by a shared hash. Refund paths keep a timeout similar to HTLCs so stalled payments can be cancelled on chain if needed.		An adaptor signature is a Schnorr signature encrypted to a point ''T''. Completing the signature reveals the discrete logarithm of ''T'', which the receiver can reuse as proof across a chain of PTLCs. Onion routing can still hide the destination, but each hop's lock point can be derived so intermediaries cannot match payments by a shared hash. Refund paths keep a timeout similar to HTLCs so stalled payments can be cancelled on chain if needed.

			Deploying PTLCs on Lightning also needs invoice and proof-of-payment formats that are not built solely around preimages, plus channel commitment layouts that can carry point locks. Research prototypes and wallet experiments exist, but public routing still settles with [[Hash Time Locked Contracts]]. Related scriptless constructions include atomic swaps that exchange adaptor signatures instead of hash preimages.

	== See also ==		== See also ==

NotATether: Add adaptor-signature mechanism paragraph

2026-09-12T21:11:14Z

Add adaptor-signature mechanism paragraph

← Older revision		Revision as of 21:11, 12 September 2026
Line 4:		Line 4:

	Taproot and BIP340 made Schnorr adaptor constructions practical on Bitcoin. Lightning still routes with HTLCs because interoperable hops, invoices, and proof-of-payment flows are built around preimages. Mixed HTLC and PTLC paths would be needed during any transition.		Taproot and BIP340 made Schnorr adaptor constructions practical on Bitcoin. Lightning still routes with HTLCs because interoperable hops, invoices, and proof-of-payment flows are built around preimages. Mixed HTLC and PTLC paths would be needed during any transition.

			An adaptor signature is a Schnorr signature encrypted to a point ''T''. Completing the signature reveals the discrete logarithm of ''T'', which the receiver can reuse as proof across a chain of PTLCs. Onion routing can still hide the destination, but each hop's lock point can be derived so intermediaries cannot match payments by a shared hash. Refund paths keep a timeout similar to HTLCs so stalled payments can be cancelled on chain if needed.

	== See also ==		== See also ==

NotATether: PTLC: add Hash Time Locked Contracts to See also

2026-09-12T02:39:23Z

PTLC: add Hash Time Locked Contracts to See also

← Older revision		Revision as of 02:39, 12 September 2026
Line 6:		Line 6:

	== See also ==		== See also ==
			* [[Hash Time Locked Contracts]]
	* [[Lightning Network]]		* [[Lightning Network]]
	* [[Taproot]]		* [[Taproot]]

NotATether: PTLC stub — point time locked contracts vs HTLC

2026-09-09T13:45:32Z

PTLC stub — point time locked contracts vs HTLC

New page

A '''Point Time Locked Contract''' ('''PTLC''') is a conditional payment that can be claimed by completing a Schnorr signature adaptor (equivalently, by revealing the discrete logarithm of a curve point), or refunded after a timeout. PTLCs are designed to replace hash time locked contracts (HTLCs) in [[Lightning Network]] routing and related atomic-swap style protocols so that hops do not share a single payment hash. As of 2026 they remain a design and implementation effort on top of Taproot-capable channels. They are not a completed BOLT that has replaced HTLCs on the public Lightning network.

An HTLC locks coins to the preimage of a hash. Every hop of a routed Lightning payment typically uses the same hash, which can let observers correlate those hops. A PTLC instead locks to a curve point and unlocks via an adaptor signature. Per-hop blinding can give each intermediary a different point, so adjacent hops need not share a common lock value. On-chain, cooperative settlement can stay off chain as with HTLCs. A force-close under Taproot need not reveal a shared payment hash the way a HASH160 HTLC script can.

Taproot and BIP340 made Schnorr adaptor constructions practical on Bitcoin. Lightning still routes with HTLCs because interoperable hops, invoices, and proof-of-payment flows are built around preimages. Mixed HTLC and PTLC paths would be needed during any transition.

== See also ==
* [[Lightning Network]]
* [[Taproot]]
* [[MuSig]]

== External links ==
* [https://bitcoinops.org/en/topics/ptlc/ Bitcoin Optech: PTLC]
* [https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki BIP340: Schnorr signatures for secp256k1]
* [https://download.wpsoftware.net/bitcoin/wizardry/mw-slides/2018-05-18-l2/slides.pdf Scriptless scripts slides (Poelstra)]

[[Category:Technical]]
[[Category:Privacy]]