Cascading Discreet Log Contracts: Oracle Signatures as Contract-Activation Secrets
Hello Delving Bitcoin,
I’m sharing a whitepaper proposing Cascading Discreet Log Contracts, or cDLCs.
The main claim is narrow:
A DLC oracle signature scalar can be used not only to settle a parent DLC, but also as the hidden scalar of adaptor signatures that activate a child DLC funding transaction.
Let the oracle’s attestation for outcome x be
with public attestation point
For a bridge transaction B_e spending a parent outcome output into a child DLC funding output, each required signature is prepared as a Schnorr adaptor signature using
With e = H(R^* \| P \| m_e), the adaptor verifies before oracle resolution:
After the oracle publishes s_x, any holder of the required adaptor state computes
and obtains a valid Schnorr signature:
So the same scalar s_x does two things:
- completes the parent DLC outcome signatures;
- completes the bridge transaction that funds the child DLC.
Before s_x is known, completing B_e requires either forging the required Schnorr signatures or finding \log_G(S_x). After s_x is published, the bridge is completable by any party holding the complete prepared adaptor state.
This gives a native Bitcoin construction:
No new opcode, covenant, or consensus change is required. Bitcoin validates only ordinary signatures and timelocks; the cascading semantics are carried by the oracle scalar and pre-signed adaptor state.
The attached paper formalizes the construction, the security boundary, the required state-retention assumptions, and the machine-checked algebra in Ada/SPARK.
The specific review request is:
Under the stated assumptions, is the claim correct that a DLC oracle attestation scalar can serve as the adaptor secret for a child-funding bridge transaction, thereby allowing one DLC outcome to activate another DLC without consensus changes?