Blockchain Engineering - class of 2022 - Team Atomic Swap

[synctext]

One idea we have is to implement atomic swaps between Ethereum and Bitcoin and use ipv8 to find people willing to trade with each other. Maybe TrustChain could be used to keep track of past transactions.

👏 Atomic swap is a great primitive for understanding blockchain. Goal is to get code running on Android devices, using non-custodial approaches, using pure Peer-2-Peer technology, no server permitted. First task is to implement an old algorithm for atomic swaps from over 8 years ago fully operational in Kotlin code. Read about hashlocks. There is some existing Bitcoin script you might re-use. Use the Taproot multisig ability, native Schnorr support now.
Explore other options; is CoinJoin cool?

Approach: Use the Kotlin Superapp as foundation. Store commitments on Trustchain {code} and use IPv8 for coordination between the 3 parties. Superior approaches are obviously very welcome. Please re-use as much as existing code as possible.

Milestone: install your app on 3 devices. Activate the 3 different roles on each devices. Transfer a minimal amount of real Bitcoins. Wait hours... Success!?! 🥇

The expected deliverables are:

• A working end-to-end demo of your functionality.
• A small readme.md writeup, describing your product, challenges, and design decisions.
• A merged and reviewed pull request to the superapp repository.

References:

• Background on blockchain-based trading, including atomic swaps (see Figure 2).
  
• In the superapp, we are using the bitcoinj library. Documentation can be found here.

[devos50]

Meeting notes (21-02-21):

• Discussed general project expectations and organization.
• Please post weekly updates in the GitHub issue.
• Feel free think about the next steps.
• Please integrate your protocol in one of the existing applications. Idea: re-use the existing application for liquidity pool trading - give an option when opening the app: “liquidity pool trading” and “Atomic Swap trading”. Also, re-use the Bitcoin wallet logic that’s there already.
• Focus on the “basic atomic swap”, proposed by TierNolan.
• Think about how to show this to the end user. Atomic swaps are interactive and require coordination and interactiveness, so you should inform the user when something bad happens.
• Can we use QR codes to complete the atomic swap?

Task for the next meeting:

• Understand the basic atomic swap protocol, including the disadvantages.
• Next, look at the implementation of a basic atomic swap. For the atomic swap, you need to be able to issue HTLC (hash-timelock transactions) to the Bitcoin network.
  • In parallel, you also need a coordination mechanism to exchange the hashes of the secret, and possibly to exchange the Bitcoin transactions between the two trading parties.
• Focus on BTC - BTC atomic swaps.
• Workload division suggestion: 2 students work on atomic swaps + Bitcoin Script, 2 students focus on TrustChain + IPv8, and one student on the GUI side.

[rahimklaber]

Week 3 progress

Atomic swap:

• Created a basic desktop ui for testing.
• Able to submit a swap contract, but having trouble claiming it.
  • We are using a contract that kind off combines claiming and redeeming into one script (https://bcoin.io/guides/swaps.html)
  • We got claiming (with hash) to work, but not redeeming (with timelock).
• Bitcoinj is hard to use / understand for custom scripts.
  • We need to use the same keypair for creating and redeeming an input (?), but bitcoinj derives a new keypair after every tx.
  • Signing something manually is hard to understand and cumbersome.
  • We ended up using https://github.com/ACINQ/bitcoin-kmp for manually signing.

IPv8:

• Familiarised with kotlin-ipv8 library
• Implemented basic app for creating a community, viewing peers and and broadcasting a message
• Designed the algorithm/steps for the communication between two peers for the swap, will implement for next week
• Patched the app to support newer android versions (12)

Android:

• The initial plan was to extend the existing liquidity pool app in the Trustchain superapp by adding a toggle there to allow users to switch between the liquidity pool and atomic swap trading. However, that would make the application even more cluttered than it currently is.
• Instead, a separate atomic swap application was created. In order to avoid copy pasting the code, two separate Gradle library modules were created: common-bitcoin and common-ethereum. The code responsible for handling Bitcoin and Ethereum wallets and blockchain interactions has been moved to these libraries from the liquidity app module. This means that the behaviour of the liquidity app remains unaltered and the newly created atomic swap one c

[devos50]

Meeting notes 02-03-2022:

• Made a separate app for atomic swaps; the liquidity pool app not deemed suitable for this primitive.
• Splitted the code into two libraries to avoid code duplication.
• There is more code in the Superapp related to Bitcoin wallet logic. The liquidity pool has separate Bitcoin wallet functionality.
• (Dan + Ion) Looked into IPv8.
• Implemented basic app in a custom community, sending network messages works!
• Basic idea of how to implement an atomic swap is there.
• (Mariana + Rahim) Focussed on Bitcoin Script and Atomic Swaps.
• Basic Atomic Swap in Bitcoin Script has been implemented.
• For now, do not broadcast the transaction to the network but just gossip them around between the involved peers.
• There has been a transaction submitted to the testnet.
• Timelock functionality is not working correctly yet.
• There are some confusing elements in the Bitcoin scripts that are being generated.
• Please post a screenshot of your testing application + link to the Bitcoin transaction in the testnet.

Next sprint goals:

• One or two students spend the next sprint on unifying the Bitcoin wallets in the Superapp.
• Get the basic atomic swap up and running + give a demo next meeting.

[rahimklaber]

Basic atomic swap with yourself:

Me and Mariana got an atomic swap contract to kindoff work.

Instead of using multiple transactions, one transaction is used to create an output that can either be reclaimed (timelock) or claimed (hash).

OP_IF

<0> // this doesn't work. need to figure out why.
OP_CHECKSEQUENCEVERIFY
OP_DROP
<key.public_key>
OP_CHECKSIGVERIFY

OP_ELSE
OP_SHA256
<hashed_secret>
OP_EQUALVERIFY
<key.public_key>
OP_CHECKSIGVERIFY
OP_ENDIF 

contract creation tx : https://www.blockchain.com/btc-testnet/tx/a07c39fb50b017ca4927750167b5f5bc9f798cf7a37e97fdd1010265f29a70b2

using contract as input tx: https://www.blockchain.com/btc-testnet/tx/91ef3ebc4124b970e6c66f47717d088e911d703b6e9a717a8d310980eff2c207

try "try swap" button creates the swap contract and prints out the tx hash and key used to create the transaction.

the "try to refund" button claims the tx with the hash preimage. You need to give it the privatekey we used to create the contract, transaction hash and output index of the contract. That info is then used to spend the contract.

[ibabalau]

Week 4 progress update

Atomic swap:

• Started using a private Bitcoin network for faster testing.
• Got atomic swap contract to work completely.
  • Apparently the bitcoin mainnet does not allow non-standard transactions, while the testnet does. So now we use a P2SH script for the atomic swap.
  • Figured out how to use bitcoinj, so not using the other library anymore.
  • Added code in the android app to start a swap and claim it.

IPv8:

• Implemented communication algorithm for atomic swap between two ipv8 peers from swap community
• Started looking into adding Trust Chain transaction validation, but not yet fully working
• Ran into some problems when integrating it in superapp.

Android:

• There was an idea to refactor the existing common Bitcoin wallet service so that it’s in the separate common-bitcoin library. However, there are numerous cyclic dependencies we didn’t notice before - classes from the common library use the Bitcoin wallet and the wallet itself uses the same classes. Therefore, we decided it’s infeasible to do the refactor from the perspective of time, left the Bitcoin wallet service in the main common library and moved only the liquidity pool app’s Bitcoin wallet wrappers to common-bitcoin library
• Unlike with Bitcoin, the Ethereum wallets were straightforward to extract to the separate common-ethereum library. However, their usages in the liquidity pool app use hardcoded values for the wallet password and keys, so we didn’t use them. What’s more, there was no common Ethereum wallet service, so we created it in a similar fashion to the Bitcoin one. It is in the common-ethereum instead of the common one, which will prevent the misuse, since the common library classes are naturally isolated from the common-ethereum ones.
• In the GUI the wallet screen for the atomic swap app has been implemented and integrates with both Bitcoin and Ethereum wallet services (displays the balance and allows for copying the address)
• In order to make the development easier, we’ve set the development environment for both the local Bitcoin blockchain (appropriately configured Bitcoin Core instance) and the Ethereum one (Docker container with geth, running in developer mode). The Android emulator communicates with them through the network interface that connects the emulator with the host operating system. In the production build they will point at well known Bitcoin and Ethereum production blockchain nodes instead.
• In order to streamline the development, we will look into creating Bitcoin Docker container, just like it was done with Ethereum

[devos50]

Meeting notes 08-02:

• Atomic swap in Bitcoin script working 🎉 . Had to use P2SH to make the Bitcoin mainnet accept transactions.
• Please try to submit a transaction to the mainnet when the code is fully integrated and tested in the Superapp.
• How to test this kind of stuff? Think about how to test this. Integration test? Unit test?
• Final demo: BTC <-> ETH atomic swap
• Used Docker to setup an Ethereum Docker instance (https://github.com/kponichtera/trustchain-superapp/blob/atomic-swap-app/docker/ethereum/docker-compose.yml).
• Identified cyclic dependencies related to the Bitcoin Wallet in the Superapp 👏
• Working methodology: “make it hard to screw up”.
• Started working on the GUI - first screen is done.

Focusses for the next sprint:

• Next week: demo time?
• Please post a screenshot of your screens on your ticket.
• Try to test the simple atomic swap with BitcoinJ.
• Document the process of setting up a special (containerised) Bitcoin instance and show how to connect to it from the Superapp.
• Please create an issue documenting the cyclic dependency issue with the Bitcoin wallet.
• Look into the TrustChain logic, get familiar with the code and create some simple transactions.
• Wrap up the work on atomic swaps.

[marianasamardzic]

Week 6

Atomic Swap:
Btc:

• Made some unit tests for the bitcoin swap code. Basically we create a fake transaction to fund the wallet and then allow the wallet to spend unconfirmed transactions. The tests currently test whether the swap outputs can be claimed or reclaimed.
• Connected ipv8 and bitcoin code. It is now possible to perform atomic swap between two parties if they both have the Swap tab opened on their devices. Currently only the initiator can claim the money back. Tested only on regtest.

Eth:

• Created a contract for hash timelocks in solidity and generated a java wrapper of the contract.
• Generated java wrappers seem to not support payable solidity functions (?), which means that we can’t fund the swap. It seems that it should be possible, but for some reason it doesn’t work.
• IPv8:
• Fixed errors that appeared when merging IPv8 code with the rest of the app
• Looked into Trustchain, tested some basic scenarios wish creating a proposal block, validating it and sending back an accept block
• Still need to clarify some details including:
• what are blocks are gonna store
• What do we check during validation phase
• validation/error scenarios - do we cancel the transaction/notify the user?

Alice wants to trade 1BTC for 1BTC. This is her starting balance.

Bob receives a trade offer from Alice and accepts it.

Alice receives an accept message from Bob. She creates the swap transaction and publishes it on the blockchain.

After her transaction gets confirmed by 4 blocks, she gets notified and sends the transaction hash to Bob.

Alice has 1BTC withdrawn from her balance.

Bob gets all the information he needs from Alice and creates his own transaction and publishes it on the blockchain.

After his transaction gets confirmed by 4 blocks, he gets notified and sends a message to Alice containing his transaction’s hash.

After Bob sends Alice a message notifying her that he created the swap transaction, Alice creates a transaction with which she can claim the money.

Her claim transaction gets confirmed.

Alice has 1BTC added to her balance.

[kponichtera]

Android:

• We discussed the GUI requirements and settled on two extra screens: one for making the swap offer and broadcasting it in the Trustchain community and another one for browsing the available swap offers. The screens are WIP.
• The issue about wallets has been created in the superapp’s repository
• Bitcoin Docker node container implemented side by side with Ethereum one. Both are documented how they are to be used (eg. how to start them and send money)
• We’re thinking of deploying both of them on the publicly available virtual machine, to make the testing on real devices easier. However, if we were do that, the containers have to be hardened to avoid exposing too much API to the outside world (eg. the RPC administrative calls)

[devos50]

Meeting notes 15-03-2022:

• Posted screenshot updates on the ticket.
• There are some issues connecting to the Ethereum docker container.
• First unit test created.
• IPv8 messaging part fully works! 🎉
• Great work on the UI! Can use a bit of polish. 😅
• Can it also work if the user does not have the atomic swap screen open? Or in the background even?
• TODO for later sprint? Show a list of prior atomic swaps, including the status (ongoing, failed, succeeded).

Proposal for TrustChain block structure:

• First create a block where Alice/Bob both agree to make an upcoming atomic swap. Include the amount of money being transferred and the source wallet addresses of both parties. Let Bob make this proposal because he has the opportunity to lock Alices’ capital.
  • Check if Alice/Bob has enough funding before the confirmation block is created?
• The remainder of the protocol is left as exercise for the students. I would like to see these details back in the final README.md deliverable.

Suggestions for next sprint:

• Please post an issue to the Web3j repository describing your problem. Or jump into their Discord server and talk to the devs directly?
• Get the first TrustChain transaction + checks up and running.

[ibabalau]

Week 7

• Atomic swap:

  • Btc

    • Implemented the logic of observing the transaction which contains the secret in it
    • Implemented the logic of claiming the money by the person that accepted the trade offer

  • Eth

    • Fixed the issue with web3j not generating correct wrappers for payable functions. I just modified the wrapper myself.
    • Got the swap contract to work. I can lock ether, claim it and reclaim it.
    • Not doing eth <-> eth swaps since the contract I wrote does not support that.
    • Couldn’t test the code since the web3j dependency for testing is broken : Could not find org.hyperledger.besu:* hyperledger/web3j-unit#51.

• IPv8 & TrustChain:

  • Integrated Trustchain into AtomicSwapCommunity
  • Created proposal, validation and accept block functions
  • Validation still needs some work + need to notify user when validation fails

• Android & DevOps:

  • Verified security of Geth instance and exposed Bitcoin and Ethereum nodes on the external server to make it easier to test it on multiple phones and emulators
  • Developed swap screen
  • Attached the logic of making swap into the GUI
  • Development of trade offers screen is WIP, a mock-up design is ready to be connected to the backend and the offer list

[devos50]

Meeting notes 22-03-2022:

• Validation of blocks is failing.
• Created blocks are visible in the TrustChain explorer! 🎉 👏
• Next steps? Trust layer on top of atomic swaps. Estimate the reliability of a counterpart.
• More work has been made on the screen to initiate atomic swap.
• Geth instance up and running.
• Testing infrastructure (Web3J) is not working very well, missing dependencies.
• Code quality not up to standards yet. Please keep in mind that we expect a merged PR at the end of this course.
• Do not consider cancelling an atomic swap for now.
• (optional) show a trust score (the number of successful atomic swaps) when Alice proposes an atomic swap proposal to Bob.
• Persistence of data is probably out of scope for now.

Next steps:

• Wrap on the Ethereum <-> BTC atomic swap. Demo will be ready next week with 85% confidence :).
• Please start working on refactoring/improving the code so it will be ready for review/merge.

[rahimklaber]

Week8

Atomic swap:

• Got Ethereum <-> Bitcoin swaps to work.
• Refactored Ethereum and Bitcoin code.

IPv8 & TrustChain:

• Finished trustchain implementation, blocks now appear as signed in the Trustchain explorer
• Refactored some code
• TODO
  • send proposal block when trade is completed (integrate with main app)
  • Add TRUST score for each user (number of successful past transactions)

Android & DevOps:

• Designed trade offers screen
• Implemented trade offers screen data handling
• TODO: fetch and display the offers from Trustchain

[devos50]

Meeting notes 29-03-2022:

• BTC <-> ETH atomic swap worked (once) :tada
• BitcoinJ / Bitcoin backend are unreliable. Solution: spam "create blocks".
• The block reward seems to go down quickly. Is there a configuration option that you can change?
• ETH <-> ETH is harder to achieve, requires changes to the smart contract.
• Can you estimate the cost of a full atomic swap (e.g., costs for ETH transactions + BTC transactions). Please post these numbers on your ticket.
• Currently assume that the application always keeps running.
• Please add a reject button to the dialog.
• TrustChain block is only created when the atomic swap ended. Using IPv8 overlay to create trade proposals.

For the next sprint:

• Finish up the E2E demo. 95% confidence that the demo will work next week :)
• Please focus on writing a (concise) README.md. Document how to make it run! Add some usage instructions.
• Send an email to prof. Pouwelse to schedule a final demo in week 3.10 (or later).
• Please give a small demo of your final product (BTC <-> ETH swap).
• Add some testing, probably you have to use mocking to get some tests up and running.
• (Optional, if there is time) crawl the chain of the counterparty, count the number of successful atomic swaps and display it.

[rahimklaber]

I estimated the gas costs for Ethereum and the fees for Bitcon.

Claiming money from the contract costs 42907 gas.
At the current price of 78 gwei per gas, this would cost 0.003470 ETH, which would cost ~ 11 USD.

Locking ETH costs 113950 gas.
At the current price of 78 gwei per gas, this would cost 0.009215 ETH, which would cost ~ 29.75 USD.

Locking Bitcoin takes ~ 223 bytes.
Assuming 4 Satoshi per byte (https://btc.network/estimate), this would cost 0.39 USD

claiming Bitcoin takes ~ 306 bytes.
Assuming 4 Satoshi per byte (https://btc.network/estimate), this would cost 0.56 USD

As far as I know, we are not doing segwit transactions.

[devos50]

Meeting notes 08-04-22:

• Almost fully functional E2E demo of the BTC <-> ETH atomic swap given 🎉 👏.
• Encountered a few other bugs, including one bug with the Bitcoin block listener.
• E2E demo will be done with two real phones.
• TrustChain app doesn’t run on Android 12.
• Trust score considered out of project scope - takes more time to develop.
• Suggestion for the course: TrustChain light app. There is no documentation - maybe a collective TrustChain tutorial/IPv8 would help.
• Legacy-driven development: having to look at the source code in order to further develop an app.

Final actions:

• Open a PR to the master branch of the main Superapp repository. Make sure the PR is in a reviewable state, meaning no dead/comment out code, clean commit history etc.
• Include a README.md in your PR. This should include your approach, challenges, novelty (the new things you considered, e.g., TrustChain accounting), and some future work. Keep this README.md brief and concise.
• Polishing the UI (e.g., dialogs, remove debug information etc).
• Please add some basic unit testing. Mock the interactions with the library.

[devos50]

Final demo has been given 🎉 . The Superapp now has support for atomic swaps between BTC/ETH wallets.

To make the conditional grade that I gave official, please open a PR today or tomorrow so it can be reviewed and merged. 👍