Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds the ability to do private atomic swap transactions between BTC and DCR using adaptor signatures. When doing atomic swaps with the original technique of unlocking coins by revealing the pre-image of a hash, the same values would appear on both blockchains, allowing anyone to link the transactions. By using adaptor signatures, this privacy vulnerability is fixed. However, some additional off-chain communication is required between the parties.
Here is some background information on Decred’s Schnorr signature implementation:
https://github.com/decred/dcrd/blob/master/dcrec/secp256k1/schnorr/README.md
Reading this article will help you get familiar with adaptor signatures (specifically read section
3–1. Single signer schnorr Adaptor signature
)https://medium.com/crypto-garage/adaptor-signature-schnorr-signature-and-ecdsa-da0663c2adc4
Decred’s Schnorr signature algorithm is currently not secure for multi-signer adaptor signatures, so the spending condition for the atomic swap contract is a 2-of-2 multisig for which one party knows one of the private keys to spend the contract on each chain. It may be possible to combine a more private MuSig contract on bitcoin with a 2-of-2 multisig on Decred, but this is left for future work. If that is done, it will not only not be possible to link the two transactions, but on Bitcoin, the atomic swap will be indistinguishable from a P2PK transaction.
The sequence of actions to perform a private atomic swap is the following
A contract output on Decred is a P2SH output with the following script:
On Bitcoin, the contract output is a P2TR output with two possible script paths, and a provably unspendable internal key. One of the script paths is a normal redeem script, and the other is a refund script. Since when spending a taproot output, only one of the scripts are revealed, third parties can only see that a 2-of-2 multisig was spent. If in future work this is improved to use a MuSig internal key, it will seem as if just a P2PK transaction was done. Decred will need an upgrade to its Schnorr signature scheme and to implement taproot before this is possible.
The following is Bitcoin's redeem script:
And the refund script:
Below are the steps required to perform a private atomic swap. Party A is trading their 2 DCR for Party B's 1 BTC.
First, party B gets a fresh address from their
dcrwallet
and sends it to Party A. Party A then uses thelockfunds
commandto create a private atomic swap contract on Decred:
Party A sends the contract and the lock trasaction to party B. Also Party A uses the
getpubkey
command inbtcatomicswap
to get a valid public key, and sends it to party A. Schnorr signatures require that a public key with an even Y is used. This is why there is a special command to get a public key.Party B then does
lockfunds
withbtcatomicswap
:After recieving all the information about each other's lock transactions, both parties run
auditprivatecontract
to confirm thatthe other party created the contract that was agreed, and then run
unsignedredemption
to create an unsigned redemption transcationthat the other party can use to create an adaptor signature.
Party A:
Party B:
Now, Party A is ready to create an adaptor signature with
initiatadaptor
. Only the Adaptor Sig is sent to Party B, if the tweak is sent to party B they can take all the funds.Party B then verifies the adaptor sig using
verifyadaptor
, and if it is valid, creates their own adaptor sig usingparticipateadaptor
and sends it to Party A.Now, Party A, with their tweak is able to decrypt Party B's adaptor signature and redeem the atomic swap using
privateredeem
:Party B, checks the block explorer, and when they see that Party A has done their redemption, Party B uses Party A's redemption
transaction and the adaptor signature they created to extract the tweak. This is done with the
extracttweak
command. Then withknowledge of the tweak, they can redeem the atomic swap.