diff --git a/dlc.md b/dlc.md index 590ea3f..5aa7a88 100644 --- a/dlc.md +++ b/dlc.md @@ -37,7 +37,7 @@ so R is the published value, O is Olivias public key -this values (points on the eliptic curve) are called **encryptors** +this values (points on the eliptic curve) are called ** yptors** ### Channel @@ -60,15 +60,23 @@ Then also Bob creates a spend from the multisig: he uses bi and in the tx you ca Those two transactions are never broadcasted on-chain (similar to bailout tx). They are called **contract execution transactions (CETs)**. +#### Liveness argument (DoS prevention) + +In practice bailout and CETs are combined and thus the scheme differs a bit from Lightning network. Both parties exchange all CETs before even broadcasting the initial 2-of-2 multisig. That is Alice holds a tx that can be spent by her "tweaked private key" or by Bob after a timelock. + +If that wasn't the case one party could hold the other hostage. Like Alice signs everything from Bob, but then Bob refuses to do the same. Now Bob can either win or lose, but Alice can only lose (since she doesn't have her transaction signed by Bob). + +Additionally the loser could broadcast the wrong CET to the network. It will be a valid spend of the UTXO, but nobody will be able to claim the funds. This is another DoS scenario that is mitigated by the fact that in such a case other party can claim all the funds (similar to the penalization step in Lightning). + #### 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 key 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. +Only she can reveal them because **o** (her private key) must be used for signing. -Say Olivia publishes sHEADS. +Say Olivia publishes **sHEADS**. -Now Alice can compute private key ai which is just a + 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. diff --git a/schnorr.md b/schnorr.md index e17aaeb..0d55179 100644 --- a/schnorr.md +++ b/schnorr.md @@ -1,6 +1,7 @@ ## Schnorr Signature Scheme -![Claus-Peter Schnorr](./Claus-Peter_Schnorr.jpg). +![Claus-Peter Schnorr](./Claus-Peter_Schnorr.jpg) + (Image: Claus-Peter Schnorr - from Wikipedia) It was invented by german mathematician Claus-Peter Schnorr. @@ -9,7 +10,7 @@ Unfortunately he patented the scheme in 1988 (patent expired in February 2008). ### Signature -Signature is the pair (R, s) that must be in a certain relation (very similar to ECDSA just that s is calculated differently) +Signature is the pair (R, s) that must be in a certain relation We choose a random integer k and calculate @@ -64,9 +65,17 @@ k is called nonce since it must be used exactly once If it isn't you can factor out d - which is your private key! +### Difference with ECDSA + +In ECDSA calculation of s involves a division by k (which is not publicly known). + +If you have a formula: a + b + c and multiply it by G you can calculate it either as (a+b+c)*G or as a*G + b*G + c*G + +if you look at a as private key and a*G as public key this means that you can either combine multiple private keys and transform them to the corresponding public key but you can also directly combine multiple public keys to the same combined public key. That is the beauty of Schnorr that cannot be done with other signature schemes. + ### MuSig (n-of-n) -Unlike ECDSA Schnorr signatures are linear and can be combined. It is possible to "compress" multiple public keys into one and then also signers can cooperate and produce "master" private key corresponding to the master public key for spending the funds. +This way it is possible to "compress" multiple public keys into one and then also signers can cooperate and produce "master" private key corresponding to the master public key for spending the funds. ### Ring signatures