DLC oracle publicly computable R-points

dlc3point.txt

The sigantures in DLC need a pre-committed R point as well as pubkey point.

Oracle pubkey = A, R
value message = v
signature = s
(generator point G)

Contract participants compute oracle point P

P = sG = R - h(v, R)A

and add P to their own keys for price-specific transactions within the contract.

The oracle's (A, R) pair can only sign a single price without revealing the private key for A (& R).  This means that for every different product and time, different R points will need to be published.
The A point can be shared among all the signatures and should be to indicate that it's the same oracle doing the signing.

The R points aren't exactly huge, but it's a bit annoying to have to request them all.  Also, you really should request them all, because otherwise you reveal which products / times you are interested in trading.

A nicer way to do it is to have the oracle's different R points be computable from publicly available data.  This is possible using the same construction as the DLC signatures themselves, except in this case the oracle must never reveal the actual signature.

## method

The oracle publishes three points, A, B and Q.  The oracle knows the discrete logs (private keys) of all 3 of these points.  They should be independent, so if Q = 2A or something bad things will happen.

They also sign off on an agreed / standardized method to encode messages regarding the product (what thing they're reporting the value of), time (when they'll report it) and final value.  Split this into two messages: t is the type and timing data, and v is the value data that the oracle reports.

Clients can enumerate the t message they're interested in, and compute the R point from t.

R = Q - h(t, Q)B

once they have R, they can compute the oracle signature points P

P = R - h(v, R)A

for the oracle to sign, they first compute k

k = q - h(t, Q)b

then use it to sign v

s = k - h(v, R)A

the oracle will reveal s, but never reveals k.  This allows then to re-use B and Q for all the different type messages t.   With this system, the DLC clients can store a 97 byte oracle (A, B, Q) set and derive any point from that.
In practice they need some indication that the oracle is actually *aware* of the t the clients want them to report on, and intends to actually sign the value v then.  So there's some other data needed than just the A, B, Q points.  But over the long term, if the clients know that the oracle always is signing e.g. the price of the dollar every day at 5pm, they can maintain just those points and make many contracts with that data, and not request more data from the oracles to construct the contracts.  (signature s scalars still need to be broadcast by the oracle to report the value)

two points instead of 3:
you could just set B = A, and it seems to work fine.  You can factor out the a after the signature happens, so

s = q - h(t, qG)a - h(v, R)a = q - (h1+h2)a

which doesn't actually seem dangerous since you still don't know q or a.  But just the fact that you can do *something* feels like to stay safe, maybe the k calculation not use a at all.  Then it's

s = q - h(t, qG)b - h(v, qG - h(t, qG)bG)a
  
  = q - h1b + h2a

which doesn't let you factor out the a and add the two hashes.