This commit is contained in:
Gregor Pogačnik
2021-09-17 12:05:23 +02:00
parent 699038401a
commit a895a589b8

12
faq.md
View File

@@ -1,13 +1,13 @@
## Frequently asked (tricky) questions and answers
- 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 (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.
- 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 (except possibly 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 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
- 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 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).
- 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).