You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The original scheme [0] and this spec seem to be easily exploitable via a rogue key attack. If Alice (or Bob) choose their public key Pub_Alice with a known representation in the form of Pub_Alice = a*G -s_i*G, then the discreet log of Pub_{Ai} = Pub_Alice + s_i*G is just a and so the funds could be taken by Alice (regardless of what s_i the oracle reveals).
I came up with an answer to my question. If you reuse the public key for the output of the funding transaction then this provides an implicit proof of knowledge of the Public key preventing this attack (which this spec does). Unfortunately this breaks one of the key privacy properties of the scheme. Since the funding is OP_CHECKMULTISIG 2 A B 2 and the "settlement" transaction conditioned on A + S_i (where S_i is the oracle "message key"). It's easy for any blockchain observer to figure out what the bet was on seeing as they know both A and S_i.
The original scheme [0] and this spec seem to be easily exploitable via a rogue key attack. If Alice (or Bob) choose their public key
Pub_Alice
with a known representation in the form ofPub_Alice = a*G -s_i*G
, then the discreet log ofPub_{Ai} = Pub_Alice + s_i*G
is justa
and so the funds could be taken by Alice (regardless of what s_i the oracle reveals).Is this assessment correct?
[0] https://adiabat.github.io/dlc.pdf
The text was updated successfully, but these errors were encountered: