I have added optimized versions of contracts:
- v4.1.0-XMR-CashTokens-Optimized (c&p the linked raw json to load it to BitauthIDE)
- v4.1.0-BTC-CashTokens-Optimized (c&p the linked raw json to load it to BitauthIDE)
Contract parameters are now not at the “head” (as with contracts compiled from CashScript) but inserted where they are used. OP_IF and stack state is optimized, too, and we save 18 bytes / TX.
I changed the approach for BTC-BCH refunds to improve privacy: instead of forwarding direct to Bob’s P2PKH we now forward to a simple P2SH contract that will then forward UTXO’s contents to Bob’s P2PKH address.
This way, if happy path is used, there will be no way to tell, by just looking at BCH blockchain, whether the BCH contract was used for BTC-BCH swap or for XMR-BCH swap.
For pure BCH swaps, just remove the block of opcodes (15 bytes) that verify token state is being passed on.
Input bytecode sizes (redeem script + unlocking data) are now:
| bytecode | XMR-CashTokens | XMR-BCH | BTC-CashTokens | BTC-BCH |
|---|---|---|---|---|
| swaplock + swaplock_swap | 203 | 188 | 203 | 188 |
| swaplock + swaplock_refund_start | 131 | 116 | 131 | 116 |
| refund + refund_complete | 203 | 188 | 58 | 43 |
| refund + refund_recover | 131 | 116 | – | – |
The BTC variant of the contract is usable for swapping BCH with LTC and EVM chains, too.
For Taproot chains, we can get really small footprint on their end and also hide the fact that the TX is part of a swap (happy path will look like ordinary P2PK spend, and Taproot tweak would be used to reveal the refund when necessary).
$XMR atomic swap update. Finished the core functionality of the swap and implemented the happy path and refund path in a big integration test suite as per contract v4 by bchautist. One last push to support to v4.1 and I can start working on the Web3 dApp!