https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002316.html
上面是原始文章，里面提及的DLEQ是指一个证明离散对数相等的Sigma算法（上文中有pdF链接）：G、Y、R'和R是群元素，可以证明知道 k : k*G = R' and k * Y = R
和MW等使用Schnorr签名不同，本算法基于ECDSA算法，要点是需要提供秘密y后才能构成一个符合要求的ECDSA签名。提供的方法不需要是直接提供y，可以是另外的信息，但提供这个另外的信息后y事实上可以计算出来。
对方有一个秘密y, Y=y*G公开； x是本方私钥， X = x*G 是公钥, G是基点，m是待签名消息, x_coord()表示取椭圆曲线点的横坐标。
// Sign such that y = DLOG(Y) is needed to complete signature
AdaptorSign((x,X),Y,m):
1. Choose d' randomly, P' = d'*G
2. R = d'*Y; // 预示着在最终形成的签名中真正对应的随机数将是 (d'*y)，而不是d'
3. proof = DLEQ_prove((G,P'),(Y, R))
4. s' = d'⁻¹ * (H(m) + x_coord(R) * x)
4. return (R, P', s', proof)
和椭圆曲线签名算法相比，可以看出这里蕴含一接近于用私钥x和随机数(d'*y)对m的签名(r, ss)：
r = x_coord(R) = x_coord(d'*y*G)
ss = s' = [H(m) + x_coord(d'* y * G) * x] * d'⁻¹ // 这里不完全到位，应该乘以d'⁻¹*y⁻¹
所以后续的算法就是要在对方基于y协作的情况下能够在这里的基础上拼凑出完整的ECDSA签名
// Verify Adaptor signature is correct for the given message and keys
// 验证这里给出的是一个合法的待完善的Adaptor signature,但本身不是合法签名
AdaptorVerify(X, Y, m , (R, P', s', proof))
1. DLEQ_verify((G,P'),(Y, R))
2. return x_coord(P') == x_coord(s'⁻¹(H(m) * G + x_coord(R) * X))
// 对方合作以最终形成合法签名
AdaptorComplete(y, (R, P', s', proof))
s = s'y⁻¹
return (x_coord(R),s)
r = x_coord(R) = x_coord(d'*y*G)
s = [H(m) + x_coord(d'* y * G) * x] * d'⁻¹ * y⁻¹
此刻方为：用私钥x和随机数(d'*y)对m的ECDSA签名
// Extract y from the completed adaptor, 签名补上之后，y是可以公开计算的
AdaptorExtract(s',s, Y)
y' = s⁻¹s' // 用到的参数公开可得
return y' * G == -Y ? -y' : y'; // Deal with ECDSA malleability
通过本算法，可以结合时间锁，要求对方提供一个preimage，但这个preimage不再是HASH的preimage，而是离散对数问题的解——而且现在使用的签名算法是ECDSA，不需要是Schnorr签名。
基于这种签名技术，可以用来支撑 SAS（简单原子互换）
https://gist.github.com/RubenSomsen/8853a66a64825716f51b409be528355f#file-succinctatomicswap-svg
其中 sigSuccessAlice 看上去step 0里面准备的时候alice是完全不提供任何部分准备的（因为这个是一个adaptor signature，在所需的secretBob不知道时原可准备半拉给到Bob，但文章里面的设计看上去是连半拉都不给对方准备）
由于ALT链上没有超时回退设计，如果完成STEP 2后，BTC链上ALICE玩失联，最终Bob会拿到BTC，而ALT链上的币就永远锁在那里了。ALICE就算回来也拿不到这些钱了。
基于Schnorr的adaptor signature可以看这里：
