Point Time Locked Contract point lock को समयबद्ध refund path से जोड़ता है: adaptor signature पूरा होने पर संबंधित scalar खुलता है, जिससे पिछला सहभागी अपना signature पूरा करता है, जबकि timelock के बाद धन वापस लिया जा सकता है; यह protocol building block है, आज का मानक Lightning payment type नहीं।
HTLC की सफल शाखा साझा hash के preimage की जानकारी पर निर्भर होती है; PTLC इसके बदले point T = t·G और ऐसी adaptor signature प्रयोग करता है जो scalar t से ही पूरी हो सकती है। समय वाली शाखा बनी रहती है: settlement न होने पर sender timeout के बाद धन वापस ले सकता है। [1]
Receiver एक गुप्त scalar चुनकर उसका point प्रकाशित करता है। पड़ोसी nodes की हर जोड़ी अपने point lock से बंधे अधूरे signatures बनाती है; receiver के अंतिम signature पूरा करते ही adaptor और valid signature का अंतर scalar खोलता है और route पर पीछे की ओर settlement संभव करता है। [1]
Sender हर hop के लिए अलग random scalar जोड़ सकता है और nodes उनके points क्रमशः घटाते हैं। मिलीभगत करने वाले दो routing nodes को सामान्य HTLC जैसा एक payment hash नहीं दिखता; फिर भी amount, timing, expiry या topology से संबंध जोड़ा जा सकता है। [4]
BIP 340 Schnorr signatures को linear equation देता है, जिससे signature adaptors को ECDSA की तुलना में अधिक सहजता से जोड़ा जा सकता है। Aggregated key के साथ सफल on-chain spend सामान्य signature जैसा दिख सकता है, पर वास्तविक space saving channel construction, multisignature protocol और emergency path पर निर्भर है। [2]
सुरक्षा केवल point और timelock पर निर्भर नहीं है। Implementation को adaptor सत्यापित करना, signature को message और key से सही बाँधना, nonce बचाना, scalar सुरक्षित निकालना, refund path बनाए रखना और peer interruption संभालना होता है; गलती key leak या धन हानि करा सकती है। [1]
मौजूदा मूल BOLT #2 अभी भी update_add_htlc, update_fulfill_htlc और htlc_signature बताता है। इसलिए केवल Bitcoin पर Taproot और BIP 340 सक्रिय होने से PTLC सामान्य Lightning Network की interoperable सुविधा नहीं बनता; सहमत messages, channel states और compatible implementations चाहिए। [3]
2025 की developer चर्चा बताती है कि सामान्य libraries में MuSig2 adaptor signatures और स्वतंत्र Schnorr adaptors के लिए mature standardized tooling नहीं है। PTLC तकनीकी रूप से विकसित प्रस्ताव है, पर सार्वजनिक tooling और specification की स्थिति व्यापक deployment का दावा करने नहीं देती। [5]
PTLC routed payments की decorrelation, proof of payment, atomic multipath payments और कुछ swaps सुधार सकता है। यह अकेले channel availability, liquidity, state loss, malicious timing या पूर्ण anonymity हल नहीं करता; लाभ को onion routing और channel design के साथ आँकना चाहिए। [4]
पूरी तस्वीर के लिए इस प्रविष्टि के साथ यह भी पढ़ें HTLC, Schnorr Signature, Lightning Network, Taproot, Payment Channel, Lightning Routing. इस प्रविष्टि का उल्लेख यहाँ भी है Trampoline Routing.
01क्या सामान्य Lightning Network आज HTLC की जगह PTLC इस्तेमाल करता है?+
साझा interoperable आधार के रूप में नहीं। वर्तमान BOLT specifications अब भी HTLC messages और signatures परिभाषित करती हैं। PTLC को अतिरिक्त cryptographic tooling, protocol messages, state transitions और implementations की सहमति चाहिए; केवल Taproot activation ने यह migration नहीं किया।