प्रोटोकॉल

पूरा स्पेसिफ़िकेशन proxy-shopping-go में docs/spec.md है। यह पेज ज़रूरी बातों का सार देता है।

कुंजियाँ

सभी कुंजियाँ एक ही मनेमोनिक (BIP39) से निकाली जाती हैं, हर काम के लिए एक (सभी secp256k1)।

काम	पाथ
पहचान (Nostr)	m/44'/1237'/0'/0/0 (NIP-06)
libp2p	m/7333'/0'/0'
BTC ऑर्डर कुंजी (उपयोगकर्ता (user), प्रॉक्सी शॉपर (shopper))	m/7333'/1'/{idx}' (idx ऑर्डर ID के हैश से आता है)
BTC ऑर्डर कुंजी (एस्क्रो (escrow))	m/7333'/2'/{idx}। xpub सार्वजनिक है, इसलिए एस्क्रो के ऑफ़लाइन रहते हुए भी दूसरे इसे निकाल सकते हैं
BTC वॉलेट	m/84'/1'/0'/0/0
EVM	m/44'/60'/0'/0/0

भरोसा

kind	किसके हस्ताक्षर	सामग्री
30500	कोऑर्डिनेटर (coordinator)	ऑपरेटर को डेलिगेशन; revoked से रद्द
30501	ऑपरेटर (operator)	क्षेत्र × शॉपर × एस्क्रो सूची, सुझाए गए रिले और चेन एंडपॉइंट
30502 / 30503	शॉपर / एस्क्रो	प्रोफ़ाइल (शुल्क, नकद वाले क्षेत्र, xpub, भुगतान पाने के पते)
10050	सभी	वे रिले जहाँ कोई मैसेज प्राप्त करता है

कौन-सा नया है, यह v टैग का वर्ज़न तय करता है (आम तौर पर हस्ताक्षर के समय का UNIX समय)। कुछ भी एक्सपायर नहीं होता। इवेंट Nostr रिले और libp2p gossipsub दोनों पर चलते हैं; Go नोड एक पर मिली चीज़ को दूसरे पर आगे भेज देते हैं।

मैसेज

मैसेज NIP-59 से लपेटे जाते हैं (gift wrap → seal → सामग्री)। सामग्री एक हस्ताक्षरित इवेंट (kind 5400) होती है, ताकि विवाद में एस्क्रो तीसरे पक्ष के रूप में उसे सत्यापित कर सके।

• एक मैसेज प्राप्तकर्ता के कम से कम k (डिफ़ॉल्ट 2) इनबॉक्स रिले पर जाता है।
• प्राप्तकर्ता ack से जवाब देता है; भेजने वाला तब तक दोबारा भेजता है जब तक उसे यह न मिल जाए।
• एक मैसेज ज़्यादा से ज़्यादा 28000 बाइट का होता है। स्क्रीनशॉट जैसे बड़े सबूतों का सिर्फ़ हैश से हवाला दिया जाता है; विवाद में वे attachment मैसेज के रूप में टुकड़ों में एस्क्रो को भेजे जाते हैं।

order.request + order.escrow_key → order.quote → order.accept → (funding) → order.funded + escrow.notice
→ order.purchased → order.shipping → order.release → order.completed
cancel and refund: order.cancel (before funding), order.refund (cooperative refund from the shopper)
other: ack (receipt), chat
dispute: dispute.open → dispute.evidence_request → dispute.evidence (+ attachment) → dispute.ruling → dispute.countersigned
report: report (to the operator)

BTC (P2WSH)

OP_IF
  OP_2 <user> <shopper> <escrow> OP_3 OP_CHECKMULTISIG
OP_ELSE
  OP_IF   <T1> OP_CHECKLOCKTIMEVERIFY OP_DROP <shopper> OP_CHECKSIG
  OP_ELSE <T2> OP_CHECKLOCKTIMEVERIFY OP_DROP <user> OP_CHECKSIG
  OP_ENDIF
OP_ENDIF

T1 < T2 (ब्लॉक ऊँचाइयाँ)। अगर उपयोगकर्ता कभी सामान मिलने की पुष्टि नहीं करता और T1 बीत जाता है, तो शॉपर अकेले फ़ंड ले सकता है। अगर शॉपर गायब हो जाए, तो T2 के बाद उपयोगकर्ता अकेले उन्हें वापस ले सकता है। एस्क्रो को T1 से पहले विवाद पर फ़ैसला देना होता है।

USDC (Safe v1.4.1)

• हर ऑर्डर को तीन मालिकों और दो की सीमा (threshold) वाला एक Safe मिलता है।
• इसका पता CREATE2 से आता है, इसलिए ऑर्डर ID से इसे पहले ही निकाला जा सकता है।
• टाइमलॉक एक Safe मॉड्यूल (PSEscrowModule) के रूप में लागू हैं।
  • t1 के बाद शॉपर claimByShopper से फ़ंड ले सकता है।
  • t2 के बाद उपयोगकर्ता refundToUser से उन्हें वापस ले सकता है।
• भुगतान और फ़ैसले EIP-712 से हस्ताक्षरित SafeTx होते हैं। फ़ैसले के बँटवारे में MultiSendCallOnly इस्तेमाल होता है।

पहचान को कुंजियों से जोड़ना

हर ऑर्डर अनुरोध (order.request) में एक key_proof होता है: मल्टीसिग में जाने वाली चेन कुंजी (BTC ऑर्डर कुंजी या EVM अकाउंट) का एक हस्ताक्षर, जो दिखाता है कि वह उसी व्यक्ति की है जिसकी Nostr पहचान है। इसके बिना कोई दूसरी पहचान उपयोगकर्ता की पब्लिक कुंजियाँ अपने अनुरोध में कॉपी करके एस्क्रो से दावा कर सकती थी कि वही उपयोगकर्ता है।

डिलीवरी का पता

पता एक बार इस्तेमाल होने वाली कुंजी K से एन्क्रिप्ट किया जाता है (XChaCha20-Poly1305)।

• K को NIP-44 से शॉपर के लिए और, अलग से, एस्क्रो के लिए लपेटा जाता है।
• एस्क्रो वाली कॉपी अनुरोध का हिस्सा नहीं होती: वह शॉपर को order.escrow_key में दी जाती है (अनुरोध में सिर्फ़ उसका हैश होता है)। विवाद में शॉपर (या उपयोगकर्ता) इसे एस्क्रो को देता है, इसलिए बिना विवाद वाले ऑर्डरों का पता एस्क्रो नहीं पढ़ सकता।

क्षेत्र

कोड प्रीफ़िक्स से मिलाए जाते हैं: JP > JP-13 (टोक्यो) > JP-13-13104 (शिंजुकु)। नगरपालिका स्तर पर जापान के स्थानीय सरकार कोड इस्तेमाल होते हैं।