Skip to content

RFP-003: unblock atomic swaps, add LEZ primitive status#48

Open
fryorcraken wants to merge 2 commits intomasterfrom
adaptor-sig-update
Open

RFP-003: unblock atomic swaps, add LEZ primitive status#48
fryorcraken wants to merge 2 commits intomasterfrom
adaptor-sig-update

Conversation

@fryorcraken
Copy link
Copy Markdown
Collaborator

Summary

  • Removes the "blocked pending LEZ timelock support" banner — BlockValidityWindow and TimestampValidityWindow exist on logos-execution-zone main today. Replaces it with a "ready to start" status.
  • Adds an LEZ Primitive Status section so applicants can reason about the LEZ side without auditing the source themselves: file-cited inventory of present primitives (BIP-340 Schnorr, WitnessSet 2-of-2, validity windows, clock program, SHA-256), two design constraints (Schnorr verify at the witness/auth layer not as an in-guest syscall; no native n-of-m threshold), and two open questions applicants should confirm early (s-malleability after acceptance; validity-window enforcement timing).
  • Tightens Bitcoin references: adds DLC-specs AdaptorSignature.md (canonical spec with test vectors), Aumayr et al. 2021 (formal security defs), and secp256kfun/ecdsa-fun. Fixes the Fournier link (one-time-vrfone-time-VES).

The functional/usability/reliability requirements are unchanged.

Test plan

  • Render RFPs/RFP-003-atomic-swaps.md and confirm the new section anchors and table render correctly
  • Sanity-check the file paths cited under "LEZ Source Pointers" and "LEZ Primitive Status" against logos-execution-zone main
  • Confirm the new external links (DLC-specs, Aumayr et al., one-time-VES, secp256kfun) resolve

🤖 Generated with Claude Code

fryorcraken and others added 2 commits May 1, 2026 14:01
The "blocked pending LEZ timelock support" banner is no longer accurate —
BlockValidityWindow and TimestampValidityWindow exist on
logos-execution-zone main. Replace it with a "ready to start" status and
add an LEZ Primitive Status section so applicants can reason about the
LEZ side without first auditing the source: file-cited inventory of
present primitives (BIP-340 Schnorr, WitnessSet 2-of-2, validity
windows, clock program, SHA-256), the two design constraints (Schnorr
verify lives at the witness/auth layer not as an in-guest syscall; no
native n-of-m threshold), and two open questions applicants should
confirm early (s-malleability after acceptance; validity-window
enforcement timing). Tighten Bitcoin references with DLC-specs
AdaptorSignature.md, Aumayr et al. 2021, and secp256kfun; fix the
Fournier link.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The "no native n-of-m threshold" constraint was overstated. WitnessSet
validates every (sig, pubkey) pair independently, so a guest program
can apply its own threshold policy over the validated signer set with
no syscall needed. The actual constraint is narrower: a program cannot
verify an *arbitrary* (message, sig, pubkey) triple — e.g. a stored
signature from prior off-chain coordination. The swaps in this RFP do
not hit that case.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant