{"type":"rich","version":"1.0","author_name":"npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l","author_url":"https://nostr.ae/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-06-20\n📝 Original message:\nGood morning Dave,\n\n\u003e ZmnSCPxj noted that pay-to-preimage doesn't work with PTLCs.[2] I was\n\u003e hoping one of Bitcoin's several inventive cryptographers would come\n\u003e along and describe how someone with an adaptor signature could use that\n\u003e information to create a pubkey that could be put into a transaction with\n\u003e a second output that OP_RETURN included the serialized adaptor\n\u003e signature. The pubkey would be designed to be spendable by anyone with\n\u003e the final signature in a way that revealed the hidden value to the\n\u003e pubkey's creator, allowing them to resolve the PTLC. But if that's\n\u003e fundamentally not possible, I think we could advocate for making\n\u003e pay-to-revealed-adaptor-signature possible using something like\n\u003e OP_CHECKSIGFROMSTACK.[3]\n\n\nNot a cryptographer, I just play one on the Internet, but maybe the pay-for-signature construction could work...?\n\nAssuming a PTLC has a pointlocked branch, which involves signing with MuSig(A, B).\nA offers to B the amount if B reveals the secret `t` behind `T = t * G`; A knows `T` but not `t`.\nThis is done by B handing over `R[B]` and `s'[B]`:\n\n    R = R[A] + R[B] + T\n    s'[B] = r[B] + h(MuSig(A, B) | R | m) * b\n\nThen A provides its partial signature to B.\n\n    s[A] = r[A] + h(MuSig(A, B) | R | m) * a\n\nB has to complete the signature by:\n\n    s = s[A] + s'[B] + t\n\nSince A knows both `s[A]` and `s'[B]`, once it knows `s`, it can compute `t`.\n\n\nNow, we can massage the equation for `s`:\n\n    s = r[A] + h(MuSig(A, B) | R | m) * a + r[B] + h(MuSig(A, B) | R | m) * b + t\n    ; multiply both sides by G\n    s * G = r[A] * G + h(MuSig(A, B) | R | m) * a * G + r[B] * G + h(MuSig(A, B) | R | m) * b * G + t * G\n    ; replace with public points\n    s * G = R[A] + h(MuSig(A, B) | R | m) * A + R[B] + h(MuSig(A, B) | R | m) * B + T\n\nNote that A can compute `s * G` above, because it generated `R[A]`, was given `R[B]` and `T`, and knows who `A` and `B` are.\n\nSo what A needs to do is to offer a fund that can only be claimed by leaking knowledge of `s` behind `s * G`.\nA can do this by creating a new keypair `A[p4s] = a[p4s] * G` and putting a fund into it.\n\nThen A generates an `R[A][p4s] = r[A][p4s] * G`, and computes:\n\n    R[p4s] = R[A][p4s] + s * G\n    s'[A][p4s] = r[A][p4s] + h(A | R[p4s] | m) * a[p4s]\n\nThe signed message could be a signature to `SIGHASH_NONE`, finally an actual use for that flag.\n\nA reveals publicly (in an `OP_RETURN` as you suggest):\n\n* `R[A][p4s]`\n* `s * G`\n* `s'[A][p4s]`\n* `A[p4s]` - Already the Schnorr output pubkey.\n\nIn order to complete the above signature, a third party C has to learn `s` from B.\n\nThe third party has to scan every onchain 1-of-1 signature for an `s` that matches `s * G`, so there is greater processing (point multiplies are more expensive than hashes, also there are more 1-of-1s).\nBut once learned, the third party can complete the signature and claim the funds.\nAnd A then learns `s`, from which it can derive `t`.\n\nThe third party learns about which channel (i.e. the UTXO that was spent to create the PTLC in the first place), but never learns `t` or `T`, which is a small but nice privacy bonus.\n\n\nRegards,\nZmnSCPxj"}