mirror of
https://github.com/aljazceru/dlc-intro.git
synced 2025-12-17 05:54:20 +01:00
More DLC
This commit is contained in:
66
dlc.md
66
dlc.md
@@ -1,20 +1,72 @@
|
|||||||
## Discreet Log Contracts
|
## Discreet Log Contracts
|
||||||
|
|
||||||
is a wordplay on the "discrete logarithm problem" and the fact that oracles
|
is a wordplay on the "discrete logarithm problem" and the fact that oracles are discreet - they are not even aware of the actual bet. It was presented in the paper [Discreet Log Contracts](https://adiabat.github.io/dlc.pdf) by Thaddeus Dryja who is also one of the creators of lightning network.
|
||||||
are discreet - they are not even aware of the actual bet. It was
|
|
||||||
presented in the paper [Discreet Log Contracts](https://adiabat.github.io/dlc.pdf) by Thaddeus Dryja who is also one of the creators of lightning network.
|
|
||||||
|
|
||||||
### Refresher
|
### Refresher
|
||||||
|
|
||||||
s = k - h * d
|
s = k - h * d
|
||||||
R = k*G
|
R = k*G
|
||||||
|
|
||||||
Instead of just publishing public key P (P = d*G) we also publish R ahead of time.
|
|
||||||
|
|
||||||
|
|
||||||
### Operations
|
### Operations
|
||||||
|
|
||||||
Alice and Bob bet
|
Alice and Bob want to bet against each other, Olivia is the oracle
|
||||||
|
|
||||||
|
Olivia just publishes one R for that particular bet (she commits to a R value). All possible outcomes need to be known in advance!
|
||||||
|
|
||||||
|
Now anyone can calculate
|
||||||
|
si * G. Let's say the bet is "heads" vs. "tails".
|
||||||
|
|
||||||
|
so
|
||||||
|
- sHEADS * G = R - hash("heads" || R)*O
|
||||||
|
- sTAILS * G = R - hash("tails" || R)*O
|
||||||
|
|
||||||
|
R is the published value, O is Olivias public key
|
||||||
|
|
||||||
|
For Alice and Bob it is very similar to lightning channel: they create a 2/2 multisig output.
|
||||||
|
|
||||||
|
#### Bailout
|
||||||
|
|
||||||
|
Before that block is transmitted to the blokchain they make sure each peer signs a bailout transaction. So Alice can whitdraw her part after a timelock, and vice-versa for Bob.
|
||||||
|
|
||||||
|
#### Contract
|
||||||
|
|
||||||
|
Alice bets on "heads" and creates an output that can be spent using private key ai
|
||||||
|
|
||||||
|
Public key Ai is defined as A + sHEADS * G
|
||||||
|
so it is her public key but skewed e that (sHEADS * G) which is publicly known (depending on R from Olivia).
|
||||||
|
Bob verifies that the value is correct and signs the transaction Alice gave him (since he knows Alice can't possibly know the private key and will know it just if she won)
|
||||||
|
|
||||||
|
Then also Bob creates a spend from the multisig: he uses bi and in the tx you can see public key Bi which is B + sTAILS * G. Now Alice verifies the same way and eventually signs.
|
||||||
|
|
||||||
|
Those two transactions are never broadcasted on-chain (similar to bailout tx).
|
||||||
|
|
||||||
|
#### Settlement
|
||||||
|
|
||||||
|
Olivia reveals either sHEADS or sTAILS. If she reveals both of them (or more than one in case there more than two options) her private is compromised (can be factored out since same R and thus also k was used).
|
||||||
|
|
||||||
|
Only she can reveal them because o (her private key) must be used for signing.
|
||||||
|
|
||||||
|
Say Olivia publishes sHEADS.
|
||||||
|
|
||||||
|
Now Alice can compute private key ai which is just a + sHEADS.
|
||||||
|
Only she knows her private key a, so this value doesn't help anyone.
|
||||||
|
But she can now sweep the funds.
|
||||||
|
|
||||||
|
In fact she has to, because if she waits time-lock could expire and Bob could
|
||||||
|
get his stake back (due to the presigned "bailout" transaction).
|
||||||
|
|
||||||
|
If Olivia just disappears after time-lock both Alice and Bob get their stake back.
|
||||||
|
|
||||||
|
#### Problems
|
||||||
|
|
||||||
|
Olivia has no incentive to publish the results, it is only her reputation that suffers.
|
||||||
|
|
||||||
|
She must use a random k each time. Using the same k twice - she loses her private key.
|
||||||
|
|
||||||
|
If must be possible to enumerate all possible outcomes in advance (for price this can get messy). You can then use a certain discretization.
|
||||||
|
|
||||||
|
Only one outcome can win (or none), if there are combinations you need to create a power-set. (User can still bet on multiple outcomes, but care has to be taken by peers if that creates a sure bet). Like Bob woudn't sign Alice
|
||||||
|
a bet on "heads" and then also "tails", since he knows this way he will just
|
||||||
|
lose his money.
|
||||||
|
|
||||||
[Previous - Schnorr](./schnorr.md)
|
[Previous - Schnorr](./schnorr.md)
|
||||||
@@ -2,7 +2,7 @@
|
|||||||
|
|
||||||
An elliptic curve is defined by formula:
|
An elliptic curve is defined by formula:
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
@@ -10,7 +10,7 @@ a and b are parameters that define the curve and are carefully tuned.
|
|||||||
|
|
||||||
Secp256k1 curve (defined through Standards for Efficient Cryptography) used by Bitcoin (and others) has the formula
|
Secp256k1 curve (defined through Standards for Efficient Cryptography) used by Bitcoin (and others) has the formula
|
||||||
|
|
||||||
 (a = 0, b = 7) and looks like this:
|
 (a = 0, b = 7) and looks like this:
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
|
|||||||
@@ -61,7 +61,7 @@ If it isn't you can factor out d - which is your private key!
|
|||||||
### MuSig (n/n)
|
### MuSig (n/n)
|
||||||
|
|
||||||
Unlike ECDSA Schnorr signatures are linear and can be combined.
|
Unlike ECDSA Schnorr signatures are linear and can be combined.
|
||||||
It is possible to compress multiple public keys into one and then
|
It is possible to "compress" multiple public keys into one and then
|
||||||
also signers can cooperate and produce master private key for spending the funds.
|
also signers can cooperate and produce master private key for spending the funds.
|
||||||
|
|
||||||
### Ring signatures
|
### Ring signatures
|
||||||
@@ -69,8 +69,7 @@ also signers can cooperate and produce master private key for spending the funds
|
|||||||
[Abe, Okhubo, Suzuki](https://cryptoservices.github.io/cryptography/2017/07/21/Sigs.html) usage of Schnorr signatures
|
[Abe, Okhubo, Suzuki](https://cryptoservices.github.io/cryptography/2017/07/21/Sigs.html) usage of Schnorr signatures
|
||||||
|
|
||||||
Idea is that you have participants P1, P2 ... Pn
|
Idea is that you have participants P1, P2 ... Pn
|
||||||
At least one of them needs to sign and signature is valid, but you can't know
|
Anyone can sign but you can't know which of them was it.
|
||||||
who signed.
|
|
||||||
|
|
||||||
[Previous - ECC](./ecc101.md)
|
[Previous - ECC](./ecc101.md)
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user