Who am I
My name is Gene Ferneau, and I’m a developer and cryptographic engineer. My focus is on privacy-enhancing technologies and cryptocurrencies.
I have been following Grin for a while, and want to become more involved with the project’s development.
What is the project
This project aims to create a
no_std library for performing adaptor signature atomic swaps between Grin and Bitcoin.
Atomic swaps are a great way for the decentralized exchange of cryptocurrencies. They remove the need for arbitrage and custodial exchanges.
Recently, Aumayr et al. authored the paper “Generalized Bitcoin-Compatible Channels” which formalizes earlier work on adaptor signatures, introduced by Poelstra for use in scriptless scripts. The main focus of Aumayr’s paper is on generalized payment channels with application to Payment Channel Networks, like Bitcoin’s Lightning Network. Essentially, instead of Hash Time Lock Contracts, adaptor signatures are used to construct the contracts neccesary for payment channels.
Partial signatures are made on channel creation, revoke/punishment, state update, and closure contracts. If either party “adapts” the partial signatures into full signatures, the “witness” (private key) for the full signature is revealed to the other party. By revealing the secret, if either party breaks the contracts,
the other party is able to punish, or force close the contracts. The witnesses are also used by both parties in the update and “peaceful” closure of payment channels.
Codifying the rules with adaptor signatures allows for secure and private construction of payment channels. Removing the need for HTLCs also enhances privacy of on-chain transactions, since adaptor signatures are indistinguishable from normal signatures to outside observers.
Atomic swaps using adaptor signatures can be seen as a special case of payment channels, and can be performed between cryptocurrencies using Schnorr or ECDSA signatures.
The theoretical basis for ECDSA-Schnorr adaptor signatures comes from Hybrid Anonymous Multi-Hop Locks from Malavolta’s et al. work “Anonymous Multi-Hop Locks for Blockchain Scalability and Interoperability”.
In addition to adaptor signature contracts, online watchtowers are needed to constantly monitor the Grin and Bitcoin blockchains for on-chain transactions.
If either party attempts to break the contract of the Funding and/or Commit transaction(s), e.g. the transaction does not appear within a certain time threshold, the watchtower must notify the other party to cancel the swap.
On the Grin side of the swap, Schnorr signatures will be used, with ECDSA on the Bitcoin side. Schnorr signatures are currently being considered for activation on Bitcoin, so Schnorr-Schnorr adaptor signatures will also be possible in the future. For some time, ECDSA will still provide a larger anonymity set for Bitcoin transactions.
Providing a secure option to users for choosing Schnorr or ECDSA on the Bitcoin side is a future goal for the project, after implementing ECDSA-based atomic swaps.
The library should be able to be integrated into the main grin-wallet implementation, and other Rust wallets like Ironbelly.
With some work, C interfaces can also be exposed to enable integration with C/C++ wallets like Grin++ and Bitcoin Core.
Implement cryptographic primitives needed for adaptor signatures
- use secp256k1 and/or secp256k1-zkp as much as possible
- use bitcoin-hashes as much as possible
- Pedersen commitments
- Fischlin transformation
- NIZK proof of exponent using Fischlin transformation
- NIZK proof of exponent for partial ECDSA signatures
- Schnorr signatures
- Partial Schnorr signatures
- ECDSA signatures
- Partial ECDSA signatures
Implement on-chain Grin transactions for atomic swap contracts
Implement on-chain Bitcoin transactions for atomic swap contracts
- use rust-bitcoin as much as possible
- Funding transaction
- Commit transaction
Implement adaptor signatures for Grin-Bitcoin side of the swap
- Schnorr-ECDSA adaptor signature multisigs
Implement adaptor signatures for Bitcoin-Grin side of the swap
- ECDSA-Schnorr adaptor signature multisigs
Implement watchtowers for monitoring on-chain transactions
- may or may not be
no_stddepending on need to interact with the OS
- Ensure Funding transaction appears on chain within a certain blockheight delta threshold
- Watch for Commit transactions being signed to claim funds on the opposing blockchain
- If timeout occurs, reclaim own funds from the Commit transaction
- may or may not be
Expose C interfaces for C/C++ Grin and Bitcoin wallets
- Any wallet able to consume a C API should also be able to use these interfaces
Full documentation of the public API and details of the project
- Documentation efforts will be ongoing throughout the life of the project
Test suite including unit and fuzz tests
Integration and functional tests using Grin and Bitcoin testnets
- Testing efforts will be ongoing throughout the life of the project
Outline of atomic swap transaction flow
GRN fnd -> <- rcv BTC fnd -> <- rcv GRN
2-of-2 multisig on funding and commit transactions
Gary is the Grin funder
Blair is the Bitcoin funder
- Gary sends Blair their proof of ownership for outputs used in the swap
- Gary’s proof also includes a bulletproof proving the output is at least as large as the agreed swap amount + fees
- Blair sends Gary their proof of ownership for outputs used in the swap
- Each party verifies the other party’s proof of ownership
- Gary creates a (unsigned) funding transaction with the outputs in the proof
- Blair completes their half of the interactive transaction, and sends to Gary
- Blair creates a (unsigned) funding transaction with the outputs in the proof
- Blair sends the transaction to Gary
- Each party verifies the other’s unsigned funding transaction
- Each party creates their half of the multisig on the other party’s funding transaction
- Each party verifies the other’s multisig on the funding transaction
- Each party creates a commit transaction sending coin to the other party
- Gary creates a partial signature on their half of the BTC-GRN commit transaction
- Blair creates a partial signature on their half of the GRN-BTC commit transaction
- Each party verifies the other party’s partial signature
- Gary signs their half of the multisig on the GRN-BTC commit transaction
- Blair signs their half of the multisig on the BTC-GRN commit transaction
- Each party verifies the other’s signature on the commit transactions
- Each party completes their half of the multisig on their own funding transaction, and posts to the respective blockchain
- After the height lock expires on the commit transaction, each party adapts their partial signatures
- Adapted signatures reveal the spending secret for the other party to claim their funds
Commit transactions will use a lock height to ensure sufficient time for funding transactions to appear on their respective blockchains. Aumayr et al. use a value of 3 blocks. Since Grin’s block schedule is shorter than Bitcoin’s, a lock height equal to 3 Bitcoin blocks should be used on the Grin side (i.e. 30 blocks).
The funding transaction needs a conditional lock height on the Grin side to ensure Gary can retrieve their coins after a certain time (e.g. Blair fails to post their funding transaction). Similarly, the Bitcoin funding transaction should have a conditional lock height. The lock height should be higher than the time expected for an honest completion of the swap protocol.
If, at any stage, verification of signatures and/or proofs fail, the protocol must be stopped. Any timelocked funds should allow the lock to expire, and reclaim the funds.
Bitcoin multisignatures may either be implemented using multisig contracts, or 2P-ECDSA threshold signatures.
- Grin multisig - multiparty outputs
- Grin multiparty timelocks
- Bitcoin multisig
- Bitcoin timelocks
Further research is needed to fully implement the atomic swap protocol, and the protocol outlined above may change during implementation.
I have done my best to perform due dilligence in my research so far, but some details only come up during implementation.
The future is uncertain, and for any number of reasons, I may be unable to finish the project.
My plan is to provide in-depth documentation, and clearly understandable code.
Good documentation will be beneficial by making it easier:
- for review / feedback
- for other projects to integrate the library
- in case I need to hand off work to another person / team.
Timelines are difficult for research-intensive projects. The best estimate I can give for an optimistic timeline is ~3-4 months for a minimum-viable-product.
There could also be unknown problems that come up, that may mildly or drastically extend the timeline.
I am requesting 40.000 EUR equivalent in BTC, based on the 60-day rolling average at the time of payout.
I would prefer payouts based on milestones achieved to prevent an all-or-nothing situation.
I am open to suggestions on funding amount, and payout schedule.
Being new to the Grin community, I would understand hesitance over my competence to complete a long-term project. So, I am very open to discussion about possibilities for increasing funders’ confidence in my abilities.