Hello! I will introduce myself a little as requested here: Grin-Substack
I am an independent software developer currently focusing on cryptocurrency although I started with stuff like 3D graphics programming with Vulkan API. I consider myself relatively proficient in the following languages: C, C++, Rust, JavaScript, Python. I want to create products that will allow people to on-ramp to more decentralized projects, such as grin, as there is a lot of money trapped in centralized captured coins. The idea of having atomic swaps while using the MimbleWimble protocol really fascinated me to the point where I spent several nights studying and taking notes the documentation. The combination of trust-less, decentralized, and anonymous makes it a perfect medium for helping people escape centralized intermediaries.
I have a good mental grasp on the version of the atomic swap on the grin docs page, however as I have read this is a bad version of it since it requires the person on BTC to initiate and also requires 2 transactions. That being said I also noticed that the conversation about the “to-be-reviewed” atomic swap by gene seems to be left off with Tromp telling him that a re-write should be considered: Atomic Swaps by GeneFerneau · Pull Request #83 · mimblewimble/grin-rfcs · GitHub and this was last discussed in 2021.
Since this is the current situation, I am wondering if there is an implementation of the “bad” atomic swap that is verifiable? I understand why it is bad, but I think in order to make progress here it might be necessary to start with the most unoptimized approach. If there is no implementation of the “bad” version I find it unlikely that we would achieve the most optimal approach on the first try. Not to mention the “bad” version has really well documented steps while this current PR does not.
Effectively I want to do some work to get atomic swaps working, and I feel as if it comes down to whether or not it will be worth it for me to start auditing this: Atomic Swaps by GeneFerneau · Pull Request #83 · mimblewimble/grin-rfcs · GitHub or is it probably better to work on a better documented version(starting with unoptimized swaps)? I’m willing to do both just not sure what the actual state of this is. I am worried that since no one has seemed to touch the repo for two years, that it may be way out of step with the current Rust implementation. Let me know your thoughts.
I am new to developing on Grin and would really appreciate any help leading me in the right direction, thanks.
In a future where a swap market exists between Grin & BTC, I imagine you would want both types of swaps. Swaps initiated by the BTC seller AND swaps initiated by the grin seller, even if it requires the BTC seller to send two transactions.
So, IMO, it would be a good idea to start with the well understood v1 proposal. Then you might be in a better position to flesh out and implement the v2 proposal. And then with both types of swaps, we can have a swap market with makers and takers on both sides.
Yes I agree, it should be initiate-able from either chain. The main problem I am considering is the adoption of the optimized swap approach. Even though it’s clearly better I think it just makes sense to start from something that I understand fully how to implement. Also from there it might become obvious what changes need to be made to optimize the setup.
Ah, I see. In my own engineering experience, I prefer to start with well understood suboptimal solutions first, and iterate towards more optimal solutions later. But, without knowing more about the specifics of either swap protocol, I can’t comment further.
Thanks for your input, the basic swap method is here if you are interested:
bottom of the page:
Atomic Swap
This setup relies on a time locked contract combined with a check for 2 public keys. On Bitcoin this would be a 2-of-2 multisig, one public key being Alice's, the second being the hash of a preimage that Bob has to reveal. In this setup, we consider public key derivation x*G to be the hash function and by Bob revealing x, Alice can then produce an adequate signature proving she knows x (in addition to her own private key).
Alice has grins and Bob has bitcoin. They would like to swap. We assume Bob created an output on the Bitcoin blockchain that allows spending either by Alice if she learns a hash pre-image x, or by Bob after time Tb. Alice is ready to send her grins to Bob if he reveals x.
First, Alice sends her grins to a multiparty timelock contract with a refund time Ta < Tb. To send the 2-of-2 output to Bob and execute the swap, Alice and Bob start as if they were building a normal trustless transaction as specified in section 2.1.
Alice picks a random nonce ks and her blinding sum rs and sends ks*G and rs*G to Bob.
Bob picks a random blinding factor rr and a random nonce kr. However this time, instead of simply sending sr = kr + e * rr with his rr*G and kr*G, Bob sends sr' = kr + x + e * rr as well as x*G.
Alice can validate that sr'*G = kr*G + x*G + rr*G. She can also check that Bob has money locked with x*G on the other chain.
Alice sends back her ss = ks + e * rs as she normally would, now that she can also compute e = SHA256(M | ks*G + kr*G).
To complete the signature, Bob computes sr = kr + e * rr and the final signature is (sr + ss, kr*G + ks*G).
As soon as Bob broadcasts the final transaction to get his new grins, Alice can compute sr' - sr to get x.
Notes on the Bitcoin setup
Prior to completing the atomic swap, Bob needs to know Alice's public key. Bob would then create an output on the Bitcoin blockchain with a 2-of-2 multisig similar to alice_pubkey secret_pubkey 2 OP_CHECKMULTISIG. This should be wrapped in an OP_IF so Bob can get his money back after an agreed-upon time and all of this can even be wrapped in a P2SH. Here secret_pubkey is x*G from the previous section.
To verify the output, Alice would take x*G, recreate the bitcoin script, hash it and check that her hash matches what's in the P2SH (step 2 in previous section). Once she gets x (step 6), she can build the 2 signatures necessary to spend the 2-of-2, having both private keys, and get her bitcoin.
(for anyone following I corrected Alice’s variable xs from the docs writeup to rs. this seems to be a small typo that i confirmed with tromp over keybase a little while ago)
I want to update that I am very close to successfully implementing the atomic swap protocol using chains that enable scripted spending conditions as it will allow me to easier reason about the implementation (this means I wont screw up as much when working on the grin version). The implementation above is semi incomplete, there are a couple of small (but significant) oversights that make it confusing upon first glance at how the operations in the swap are accomplished. I have implemented a python example that fills in the missing operations and will post it here upon polishing so that other people can see how the atomic swap operations play out step by step.
