diff --git a/README.md b/README.md index fe14f07..474e8c1 100644 --- a/README.md +++ b/README.md @@ -5,4 +5,6 @@ They offer a way to implement financial smart contracts on Bitcoin and what is m Outline: -First we need go through some [Eliptic Curve Cryptography Basics](ecc101.md). Then we tackle [Schnorr Signature Scheme](./schnorr.md) and finally explain [Discreet Log Contracts](./dlc.md). \ No newline at end of file +First we need go through some [Eliptic Curve Cryptography Basics](ecc101.md). Then we tackle [Schnorr Signature Scheme](./schnorr.md) and finally explain [Discreet Log Contracts](./dlc.md). + +You might want to check out the [FAQ](./faq.md) as well. \ No newline at end of file diff --git a/dlc.md b/dlc.md index 96ce839..76ded7d 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 elliptic curve) are called **encryptors** ### Channel diff --git a/ecc101.md b/ecc101.md index 14a51a8..17b63c9 100644 --- a/ecc101.md +++ b/ecc101.md @@ -51,9 +51,9 @@ From k -> kP is easy (we just do the adding or actually doubling) but kP -> k is Usually we are given a standard curve (like Secp256k1) and some generator point G. Note: in principle any G is good but we cannot trust just any parameters because peer might know something about G beforehand (there were attacks abusing the blind trust of G sent by other party). -Basically random integer x can be a private key, while P = x*G is the public key. And knowing P or G doesn't help in any way to find out x. This is the eliptic curve discrete logarithm problem that is believed to be computationaly hard. +Basically random integer x can be a private key, while P = x*G is the public key. And knowing P or G doesn't help in any way to find out x. This is the elliptic curve discrete logarithm problem that is believed to be computationaly hard. -Private key is usually a 256 bit long integer. It appears that P would have 512 bits (256 bits for x and 256 bits for y coordinate), but it actually suffices to use just one coordinate (due to the nature of eliptic curves) and one additional bit. So the representation of P is just 257 bits long. +Private key is usually a 256 bit long integer. It appears that P would have 512 bits (256 bits for x and 256 bits for y coordinate), but it actually suffices to use just one coordinate (due to the nature of elliptic curves) and one additional bit. So the representation of P is just 257 bits long. [Previous - main page](./README.md) diff --git a/faq.md b/faq.md index 26e1faa..8b2be0a 100644 --- a/faq.md +++ b/faq.md @@ -2,11 +2,12 @@ - Q: How can DLCs already work in practice given that Taproot has not yet activated on mainnet and we thus don't have Schnorr signatures yet? A: In fact only the oracle (Olivia) needs to use Schnorr signatures and -this data is all off-chain. So it doesn't depend on Bitcoin at all. Alice and Bob just need to tweak their public and private key in a provable way. For ECDSA there is a complex solution **adapter signatures** (https://medium.com/crypto-garage/adaptor-signature-on-ecdsa-cac148dfa3ad). But an easy hack since combination of keys is hard with ECDSA is just to use multisig. So Alice can use her key and the encryptor as a seperate key. And the fact public key is private key times G (point on elliptic curve) is the same no matter what signature scheme is used. +this data is all off-chain. So it doesn't depend on Bitcoin at all (except as an opaque OP_DATA for distribution). Alice and Bob need to tweak their public (and private key) in a provable way. For ECDSA there is a complex solution **adapter signatures** (https://medium.com/crypto-garage/adaptor-signature-on-ecdsa-cac148dfa3ad). But an easy hack since combination of keys is hard with ECDSA is just to use 2-of-2 multisig. So Alice can use her key and the **encryptor** as a seperate key. Schnorr will just make the transaction smaller (and more private). The fact public key is private key times G (point on elliptic curve) is the same no matter what signature scheme is used. -- Q: How can DLCs enable hashrate derivates (https://suredbits.com/hashrate-derivatives-with-dlcs-coinbase-put-contracts/). Coinbase cannot be spent first 100 blocks which means you also can't open a 2-of-2 multisig? -A: Actually I forgot to mention https://github.com/fiksn/dlc-intro/blob/master/dlc.md#liveness-argument-dos-prevention in the talk. There is no need to even transmit the 2-of-2 on-chain. In that case other party can just double spend the UTXO and thus make sure the 2-of-2 can never be commited. And thus all agreements based on that are void. That could be abused by the losing party to pretent nothing happened and get her stake back. But for 100 blocks I am confident that other party cannot cheat that way. So I just need to make sure that afterwards there is no race-condition. (TODO how can we prevent that?) +- Q: How can DLCs enable hash rate derivates (https://suredbits.com/hashrate-derivatives-with-dlcs-coinbase-put-contracts/)? Coinbase cannot be spent first 100 blocks which means you also can't open a 2-of-2 multisig. +A: Actually I forgot to mention https://github.com/fiksn/dlc-intro/blob/master/dlc.md#liveness-argument-dos-prevention in the talk. There is no need to even transmit the 2-of-2 on-chain. In that case other party can just double spend the UTXO and make sure the 2-of-2 can never be commited. This way all agreements based on that are void. That could be abused by the losing party to pretend nothing happened and get her stake back. But for 100 blocks I am confident the other party cannot cheat that way. And the contract is settled exactly at block maturity. So counterparty of the miner (market maker) just needs to make sure the 2-of-2 multisig is really mined in 101th block. Using +child-pays-for-parent as contract is settled anyway market maker can optimize for the inclusion of the transaction. Another way would be to have something similar to [Anchor Channels](https://lightning.engineering/posts/2021-01-28-lnd-v0.12/) and you can outbid counterparty in the race. However since the other side is a miner, there is a high possibility he can create a block to double spend his previous transaction. So I guess this cheating cannot be totally prevented but this is very visible on the blockchain and thus could carry a reputational cost for the miner. - Q: How do timelocks on Bitcoin work? -A: Each transaction has **nLockTime** field which means do not include this transaction in a block until constraint is met. If the value is < 500000000 it means minimal block height and higher numbers means minimal mean timestamp (as reported by miners in the block). You can transmit transactions with wrong nLockTime but they will never be included in any block, similarly as if you specified a too low fee. BIP65 in 2015 also included an opcode OP_CHECKLOCKTIMEVERIFY to programmatically check that in script. Actually it will just compare nLockTime to the specified value (but as mentioned too high value will not work on the blockchain anyway). BIP68 also brought **nSequence** reporuposing and BIP112 OP_CHECKSEQUENCEVERIFY which can be used to obtain a relative-timelock (depending on when previous UTXO was included in a block). + A: Each transaction has **nLockTime** field which means do not include this transaction in a block until constraint is met. If the value is < 500000000 constraint means minimal block height and higher numbers means minimal mean timestamp (as reported by miners in the block). You can transmit transactions with wrong nLockTime but they will never be included in any block, similarly as if you specified a too low fee. BIP65 in 2015 also included an opcode OP_CHECKLOCKTIMEVERIFY to programmatically check the condition in script (using OP_IF and OP_ELSE). Actually it will just compare nLockTime to the specified value (but as mentioned too high value will not work on the blockchain anyway). BIP68 also brought **nSequence** repurposing and BIP112 OP_CHECKSEQUENCEVERIFY which can be used to obtain a relative-timelock (depending on when previous transaction was included in a block).