Skip to content

Latest commit

 

History

History
21 lines (20 loc) · 5.68 KB

faq.md

File metadata and controls

21 lines (20 loc) · 5.68 KB
Raw

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? (Note: this was written before taproot activation on 14.11.2021).
  • 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). With a proper adaptor signature it is possible to construct DLCs also only with ECDSA but at the cost of higher complexity (and lower privacy). The extreme case would be simple ECDSA everywhere. Using 2-of-2 multisig with your public key and some random public key you've got from the oracle. Then oracle publishes the private key. But such a scheme would not be very "discreet". So as described in next paragraph you can do "key adaptation" to hide the fact that you are using a value from the oracle. But that is also not a DLC since oracle could disclose multiple private keys. You can imagine that Schnorr forces the oracle to be (more) honest.
  • Q: What are adaptor signatures?
  • A: An adaptor signature (or signature adaptor) is an additional signature which is combined with an initial signature to reveal a secret piece of data. It is like an additional encryption of a signature such that the other party can verify that is a correct signature but cannot directly use it.
  • Keys can always be "adapted". The first well known example of such a scheme is Homomorphic Payment Addresses and the Pay-to-Contract Protocol which introduces the P2C (pay-to-contract) protocol. The idea is that if you have public key P you can add diff*G and the corresponding private key will be x+diff (since (x+diff)* G = x * G + diff*G). Now if you take diff to be a hash of some ToS you can make sure spending party knows about it (or else it wouldn't be able to calculate the value diff).
  • However here the trick is that you operate on existing signatures (you don't have signers' private key!). With ECDSA a combination is very hard (https://medium.com/crypto-garage/adaptor-signature-on-ecdsa-cac148dfa3ad). The best option you have is to use multisig and use two or more separate signatures.
  • With Schnorr on the other side this is easy since s is linear. You can basically just sum two or more s values for the same R together (but there are some important caveats that are explained in Mu-Sig scheme - so please don't roll your own crypto).
  • An exciting possibility here are PTLC (Point Time Locked Contracts) instead of HTLC (Hash Time Locked Contracts) which are able to hide the fact that it is the same payment that is being routed offchain. See here.
  • Q: How can DLCs enable hash rate derivatives (https://suredbits.com/hashrate-derivatives-with-dlcs-coinbase-put-contracts/), e.g. put contract for miners? 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) 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 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. (TODO: you might want to improve this answer)
  • 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).
  • Q: How to distinguish ECDSA from Schnorr signature?
  • A: Very hard without actually verifying the signature, since both produce 2 values that look similar. ECDSA signature is longer - usually 71 to 72 bytes while Schnorr signature is 64 byte long when used with Bitcoin. However there is no need to distinguish both signature schemes since Schnorr is used just with version 1 witness script (in v0 as well as legacy scriptSig ECDSA will continue to be used).