Atomic swaps support in chainstate

[azarovh]

This PR contains types required for the implementation of the following atomic swaps algorithm. Most of the business logic will be handled by the wallet (which will be done in a separate PR).

1. A generates a secret x
2. A creates TX1: transfer N coins to B with TxOutput::AtomicSwap. It reveals H(x) in the output and can be spent if B knows x or 2-of-2 multisig is signed by A&B but only after 48 hours.
   • Nothing is published nothing to reverse
   • If A publishes TX1 now he can lose access to his funds without possibility to refund because B could just ignore the process and not sign his part of refund multisig.
   • If A reveals incorrect H(x) then 2 scenarios are possible
     • B ignores the process and A’s funds are stuck
     • B follows the process then he will send his coins to A in TX3 with output that cannot be spent by A. Both can refund.
3. A creates TX2: TxOutput::Transfer N coins from TX1 back to A with 2-of-2 Destination::ClassicMultisig. Multisig is signed by A.
   • Same
4. A sends TX2 to B. B signs TX2 and return it to A. Now multisig is fully signed but can be accepted only in 48 hours.
   • Nothing is published nothing to reverse
   • B can safely sign TX2 because even if submitted immediately the tx would be rejected because of timelock.
   • Now that B signed TX2 the funds from TX1 could be returned to A after 48 hours even if B quit.
   • How long should A wait for B to sign? B could delay the process; need to decide on a safe gap
5. A submits TX1.
   • If B ignores the process A can return his funds in 48 hours
6. B creates TX3: transfer M coins to A with TxOutput::AtomicSwap. It can be spent if A knows x (which he knows) or multisig is signed by A&B but only after 24 hours.
   • If B ignores the process A can return his funds in 48 hours
   • If B publishes now he can lose the funds. B’s funds are now in control of A (who knows x); A just spends B’s coins right away then wait 48 hour and get his refund..
   • If B uses larger timelock again he is increasing the risk of losing coins.
7. B creates TX4: TxOutput::Transfer M coins from TX3 back to B. Multisig is signed by B.
   • Same
8. B sends TX4 to A. A signs TX4 and return it to B.
   • How long should B wait for A to submit? A could delay the process; need to decide on a safe gap
9. B submits TX3.
   • Both can refund
   • Now A has 24 hours to spend from TX3 and reveal the secret.
10. A spends coins from TX3. Input signature contains both signature and x which reveals the secret to B.
    • A is forced to reveal x, otherwise spending wouldn’t be authorized
11. B spends coins from TX1. B monitors txs and when he see TX3 he took x from there and singes TX1.

This is an adaptation of the original algorithm from here: https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949

TODOs:

• add fork
• support in simulation test
• support in API server
• support in wallet

[TheQuantumPhysicist]

This is still a change I don't like. Do you still need this after having introduced mintscript? Can you please revert all the changes in this file?

[azarovh]

The reason I did this is because I want PartiallySignedTransaction to implement this trait and unify signature verification.

[TheQuantumPhysicist]

Another round done. Please address the comments.

[TheQuantumPhysicist]

This file has to go eventually. I haven't checked and I don't understand why it still exists. I was told it's used in tests. Maybe it's time to kill it.

[azarovh]

Yes it's used only in tests. I'd do it as a separate task