Pastebin of the resources discussed: https://pastebin.com/zbegGmb8

The conversation has been anonymized by default to protect the identities of the participants. Those who have given permission for their comments to be attributed are attributed. If you were a participant and would like your comments to be attributed please get in touch.

Michael Folkson (MF): This is London BitDevs, this is a Socratic Seminar. We had two events last week so it is great to see so many people on the call. I wondered if there would be lethargy after two last week. They were both great, videos and transcripts are up on BIP-Schnorr and Tim Ruffing’s presentation. Today is on CoinSwap. CoinSwap has been in the news because Chris Belcher has just got funding from the Human Rights Foundation to work on it and there seems to be a lot of enthusiasm. At least a couple of people have been getting deep into CoinSwap. A couple of guys from Wasabi have been talking about CoinSwap at the Wasabi Research Club. This is being livestreamed. There is a call currently on Jitsi. Jitsi is free, open source and doesn’t collect your data. There will be a transcript but it can be anonymized and edited so please don’t let that put you off. This isn’t an exercise to find gotchas, this is purely for educational reasons. There is a Pastebin up with the resources we will look at to bring structure to the discussion. As is normal we’ll do intros for anybody that wants to do an intro. There is a hand signal in the bottom left of your screen. If you want to do an intro, who you are, what interests or what understanding you have on CoinSwap. You don’t need to give your real name if you don’t want.

Adam Gibson (AG): I have some knowledge of CoinSwap because I did an implementation of it called CoinSwapCS a couple of years ago. I also corrected Greg Maxwell’s 2013 protocol which I don’t think many people know. I am also the author of the diagram you have at the top of your page.

Max Hillebrand (MH): I am building on different Bitcoin tools, currently focusing a lot on privacy specifically onchain with Wasabi wallet but also have been thinking about CoinSwaps for quite a while. I am very excited about the promise of Schnorr, scriptless scripts and adaptor signatures. I am even more excited that all of this is becoming possible with Schnorr-less 2PECDSA.

Openoms (O): I am contributing to the RaspiBlitz project which is a Lightning Network node implementation and a lot else. I was recently working on integrating Joinmarket on it and I have been working on a Terminal based menu called JoininBox which is helping Joinmarket CLI usage. I am generally very enthusiastic about privacy on Bitcoin and excited about the CoinSwap proposal.

Aviv Milner (AM): I am part of the Wasabi Research Club alongside Max. I am really into privacy. One thing I am really proud with, I got to interview Adam Gibson not long ago on elliptic curve math which was great.

MF: As is custom in the previous Socratics we start from basics. I will throw out a basic question. What is an atomic swap? What is an atomic swap trying to achieve? This has been discussed for years in terms of swapping coins between chains. Can anybody explain a conventional atomic swap works?

MH: A swap is about exchanging property right titles very generally speaking. There are two parties, Alice and Bob. Alice has something, Bob has something else and they want to have the thing that the other person has. They swap it, they exchange it. What makes this whole thing atomic, not in the sense that it is small but in the sense that it is binary. Either the trade happens or it does not happen. Either Alice gets the good of Bob and Bob gets the good of Alice or nothing happens at all and both retain their own goods themselves. The cool thing is that nobody can steal. It is a bulletproof property rights exchange contract. There is no possibility that Alice can have both her own good and the good from Bob. This is not possible in this scheme. It is achieved by utilizing by cryptography and Bitcoin Script in order to enforce this with some timing constraints that I am sure we will talk about.

O: The word atomic means that it is all or nothing. Max described that there is no way that the trade goes halfway forward and not all the way. That is why we call it atomic.

AG: It might be worth mentioning that the achievement of that goal is contingent on trusting that the blockchain’s so to speak clock operates correctly. For example no re-orgs or no deep re-orgs depending on how you set it up. It is not like you get the atomicity for free. It is depending on the blockchain behaving itself.

MF: You could say the same about Lightning. It is basically the same assumptions.

AG: It is the same primitive involved in at least one aspect of the Lightning Network, similar.

Bob McElrath (BM): There is a fun theorem that says atomic swaps are impossible without a trusted third party. We don’t get away from that theorem here. The two assets live on two different blockchains presumably so one solution is to put them both on the same blockchain which is the way all ERC20 swaps work. What Bitcoin does is use two interleaved timelocks, it is not actually atomic, it doesn’t happen at one point in time. One swap has to go forward and then the second one has to follow but there is a back out where if one half of the transaction doesn’t go through the other half can retrieve their coins and affect the non-execution of the swap.

MH: What theorem suggests they are impossible? Is there a difference between swapping between chains like Bitcoin and Litecoin and swapping on the same chain, Bitcoin UTXOs on the base layer?

BM: If the base layer mediates the atomicity and the atomicity happens on the base layer, there are two transactions that are confirmed simultaneously and they can only be confirmed simultaneously. Then the base layer is enforcing atomicity. In order to do that you have to have a base layer that supports multiple assets. That is what is done on many of the blockchains out there that support sub-assets if you will and the whole DeFi thing.

MF: Alex has shared in the chat a resource on understanding HTLCs.

At a high level HTLCs function as an escrow with a timelock. Once you put money into the escrow it will either execute successfully based on certain conditions or refund the payer once the timelock has expired. HTLCs are one of the primitives used on the Lightning Network. The potential for HTLCs seems boundless in my opinion.

MF: And PTLCs, we will get onto them later. nothingmuch says in the chat is that due to the Fischer-Lynch-Patterson impossibility? Or is it something specific to these swaps?

BM: I think that sounds right. This statement doesn’t necessarily apply only to cryptocurrencies, it also applies to anything else in the world including pdf files, physical objects, anything else. You can’t exchange anything electronically or otherwise without a trusted third party.

AG: It is usually referred to as fair exchange. The title of the paper was “On the Impossibility of Fair Exchange without a Trusted Third Party.” It is the same thing.

BM: In the blockchain space we outsource the third party in a couple of different ways. One interesting way is in the case of Ethereum with ERC20 tokens, the blockchain is actually mediating it and it is the rules of the blockchain that enforce the atomicity. There are ways to trust minimize that third party, the whole statechains conversation is an example of a trust minimized third party but it is still a trusted third party that enforces atomicity. Of course with HTLCs we use the timelocks.

AG: That is why I was saying at the beginning that the simplest way to understand it perhaps is the trade-off that we are trusting the blockchain clock is behaving as we intend it to in our timelocks. There is a lot you could say about this, we have said a lot of already.

https://bitcointalk.org/index.php?topic=321228.0

MF: As is custom for these historical timeline exercises the first link is a Bitcointalk post by Greg Maxwell. This is on CoinSwap. This is at the idea phase in 2013, obviously lots has changed since then. The foundation or the crux is kind of here. It is not as trust minimized as some of the designs today, is that correct?

AG: It is kind of complicated to say the least but it is not less trust minimized, the same basic thing. He chose to present it, perhaps logically, in the form of a three party protocol rather than two party. In a sense we are missing a step because I think people usually refer back to a Tier-Nolan post from a little earlier when they first talked about atomic swaps. This was Greg specifically introducing the concept that even on a single blockchain it could be a very useful construct to have this kind of atomic swap in order to preserve privacy. He was trying to explain how you could do the atomic swap without revealing the contract onchain. That is the most important concept that is being played out there. It is a little complicated, the way it is presented there. I couldn’t explain it to you right now, it was years ago I looked at this. I did actually find a mistake in it, it was quite funny telling Greg, he wasn’t too pleased. It was a minor thing. Even if there was no mistake in that layout it was written before there was such a thing and CLTV and CSV, CheckLockTimeVerify and CheckSequenceVerify. They activated years after. He was writing how to do with it with timelocks on backout contracts rather than integrating it into one script. Also it is three party that makes it more complicated.

MF: This was before timelocks?

AG: They weren’t in the code or activated.

BM: There was a nLocktime in the original Bitcoin. The CSV soft fork in 2016 added CheckLockTimeVerify and CheckSequenceVerify opcodes. That is what gave us HTLCs. The original timelock that was in Bitcoin didn’t behave in a way that anybody expected. It was not really very useful.

MF: This party Carol in the middle. There is no trust in Carol? What is the point of Carol if there is no trust required in Carol in this scheme?

AG: I haven’t read this for three years at least so I’d have to read it. It is very long and very complicated.

BM: I am not sure about this specific proposal but generally the third party is added to enforce atomicity. You can minimize trust down to only enforcing atomicity and not knowing anything else.

MF: Towards the end of Greg’s post he gives the comparison to Coinjoin which is quite interesting.

AG: Even if you just look at the introductory statements at the top of the diagram. Phase 1 “makes it so that if Bob gets paid there is no way for Carol to fail to get paid.” Of course there are such things as escrows with trust but I don’t think there is anything interesting here with regard to having trusted parties. This is about enforcing atomicity at the transaction level. The only reason it is different from a CLTV type construct is you have to use extra transactions in timelocks in the nLocktime as backouts. This isn’t about having a trusted relationship.

https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949

MF: You mentioned Adam the TierNolan scheme. This is May 2013, Greg’s was October 2013. This was before Greg’s. Could you explain the TierNolan scheme and how it differs to Greg’s?

AG: Not me. I never understood it. I remember reading it three or four times and never quite understanding what was going on.

BM: Probably best to skip directly to how HTLCs work today and timelocks there. The other reference I would point out here is Sharon Goldberg’s talk from the MIT Bitcoin Expo this year which enhances the TierNolan proposal and adds three timelocks. It adds the feature that either party can go first. TierNolan’s proposal has to have one person going first. Broadly there are two timelocks, there is a window in which if Alice goes first she can get her coins back and if Bob does go, everything is good, it is executed. There are two timelocks there.

MF: The motivation for Greg’s scheme was as a privacy technique while the TierNolan was set up as a swap between two different cryptocurrencies?

nothingmuch: If I am not mistaken the history is as follows. First there was the Bitter to Better paper by Elaine Shi and others which introduced the idea of using swaps using hashlocks and timelocked transactions and a multisig for privacy. I believe TierNolan came after and generalized to do swaps between different blockchains. Greg’s CoinSwap post describes essentially the same thing as an atomic swap between two parties on Bitcoin specifically for privacy. A minor correction for earlier is Carol is whoever Alice wants to pay, Carol doesn’t know she is participating in a CoinSwap. It is typically meant to be Alice herself. The reason he added it was to emphasize you can also send payments from a CoinSwap without an intermediate step. I think the main innovation from a privacy point of view in the CoinSwap post over the previous protocols is the notion of a cooperative path where the only onchain footprint is the multisig outputs. None of the hash locked contracts make it onto the chain unless one of the parties defects and the refund is actually used. This is why it was a substantial improvement for privacy. I hope that that is accurate, that is my recollection.

AG: That sounds good. Maybe it nicely illustrates that while it is natural to go down a historical route in this it might actually be better educationally to look at those two basic ideas. First we could mechanically state how an atomic swap construct works without any privacy concerns. Then we could describe as Greg laid out how you take that basic construct and you overlay a certain thing on it to make it work for privacy.

AG: The basic idea of an atomic swap is this idea of a hash preimage, one side pays to a script that can only be spent out of by revealing a hash preimage. Two people are exchanging coins for whatever reason, cross blockchain or on the same blockchain, they are both able to extract two chunks of coins if they reveal the hash preimage. One of them starts with an advantage in that he knows the hash preimage. If you did it in a naive way he could claim the coins himself and then try to claim the other ones too. The basic idea of course is when you broadcast a transaction that reveals a hash preimage and the script says something like “Check that this data hashes to this previously agreed hash output.” Because you have to broadcast it in order to claim the coins that means that hash preimage by definition becomes public. A naive way to do it would be Alice has the hash preimage, tries to claim one of the outputs using the hash preimage and then Bob would see that hash preimage on the blockchain because it was published inside the scriptSig of the transaction that Alice uses to claim. He would take the hash preimage and essentially do the same thing. He would take that hash preimage and construct a valid scriptSig for the other output. He gets his one coin, they are both trying to claim one coin. The problem with that is it doesn’t have the security you want. Alice is in the preferential situation where she knows how to claim both the coins, she knows both of the hash preimages. You add another layer to it. You add that only one party can claim by adding the requirement of signing against a public key. Why do we need timeouts? If you had this setup as I described it where both sides would claim the coins if they know the preimage to a hash but also it was locked to one of their keys, it looks secure but they have a deadlock problem. If the first party refuses to reveal the hash preimage, the one that knows it, because you have had to deposit coins into these scripts the coins are locked up until that person decides to reveal it. Maybe they die or they disappear and then your money is dead. You do need a backout. The question becomes how does each side have a backout to ensure safety against the other party misbehaving. I haven’t explained that in full detail, I am sure we will at some point. How do we convert it into a private form? In talking about this you might find the diagram on Michael’s meetup page useful for this. We have got Alice and Carol and TX-0 and TX-1 on that diagram show Alice and Carol respectively funding a 2-of-2. Why do they fund a 2-of-2? Because they need to have joint control of the funds.

MF: One thing I saw going through these resources on atomic swaps, Sergio Demian Lerner had an attempt back in 2012 with a trustless exchange protocol called P2PTradeX. That was the idea that was refined and formalized by Tier Nolan in 2013. The guys at Decred worked on executing an atomic swap with Litecoin in 2017. Most of the activity seems to be swapping currencies between chains it seems until recently.

AG: The first thing we need to get clear is a HTLC. HTLC is a slightly unfortunate name, it is a correct name but it isn’t an intuitive name. Forget about coin swaps for a minute and focus on this idea that you could have a custom script that pays out if you provide a hash preimage or it pays out after a delay. Why do we want the after a delay clause? Because you don’t want to pay into a hash, something where the script says “Check if the data provided in the scriptSig hashes to this value.” We don’t want to pay into a script like that and have it sitting there infinitely because the other party walked away. The concept of backout is absolutely crucial. That is why the timelock in a hash timelocked contract (HTLC) exists. As well as paying into a hash we are paying into that or something is locked in say 100 or 1000 blocks forward or possibly time instead. Hash timelocked contract refers to that. You could think of a HTLC as a specific kind of Bitcoin script. I seem to remember that at one point some people tried to produce a BIP to standardize this but the only standardization is in certain places like Lightning. You have a script and that is cool but the idea of an atomic swap is you lock together two such scripts. It could be on different blockchains, it could be Litecoin and Bitcoin for example. Or it could be on the same blockchain. Forgetting privacy the idea is both Alice and Bob pay into such a script. Alice pays into the first one and it says “This script releases the coins if you provide the preimage to the hash or it releases, without the hash preimage, after 100 blocks.” Bob does the same. They use the same hash value in the script but they use slightly different timelocks. If you think about trading, perhaps Alice is paying 1 Bitcoin in exchange for 100 Litecoin. It should be atomic. If Bob receives 1 Bitcoin and Alice receives 100 Litecoin, if one of them happens both should happen. The idea is that when one of them happens it gets broadcast onto the chain with the hash preimage such that the other one should be able to be broadcast also. That is the core concept. The timelocks exist to make sure that both parties are never in danger of putting their coins into such a script but never getting them out again. Maybe that is the simplest explanation you can give for an atomic swap.

MF: I suspect most people know what a HTLC is but a HTLC in one direction and another HTLC going in the other direction with a link between those two HTLCs.

AG: I am not sure about the directionality. If you are thinking about HTLC in a Lightning context then obviously we have a chain of them, not just two. But it is basically the same thing. If one transaction is broadcast the other one can also be broadcast. It is only two and not 3, 4, 5 in a Lightning path.

MF: This is talking about different cryptocurrencies. The question in the chat is on moving value from a legacy address to a bech32. I suppose this is going in the direction of Chris Belcher’s CoinSwap, you are swapping coins in a legacy address for coins in a bech32.

AG: I don’t think you should focus on that yet. If you understood that, what is the advantage of doing an atomic swap from a privacy perspective?

O: The amount and timing correlation?

AG: Those are both valid points but we will get onto them more when we are trying to achieve privacy. There is a more fundamental reason why a basic atomic swap as I just described is poor for privacy.

O: The peers would need to communicate the secret out of band?

AG: They wouldn’t need to communicate the secret out of band because the whole idea is that when one of them broadcasts a transaction with the hash preimage then it is on the blockchain and the other one can simply scan the blockchain to see it. It is actually the case that in practice you would communicate the secret out of band but that is not the principal issue with an atomic swap.

BM: Everybody sees your hash preimage and can correlate them across chains.

AG: That would be the answer. You can generalize this point to just custom scripts generally. When you use some kind of exotic script and not a simple pay-to-public-key-hash or the various equivalents. Even multisig, you are revealing something about your transactions. This is the ultimate extreme of that problem. Here if we simply do a trade of one coin for another using the hash preimage, some string like “Hello”, obviously you would use a more secure string than that as a hash preimage, then that hash preimage has to appear in both of the scriptSigs of the transactions that you are using to claim the coins. By definition it has to if we do it in this simple way. That unambiguously links those two transactions on one chain or on both chains. That is terrible for privacy.

MF: We will go onto adaptor signatures, PTLCs and that kind of stuff later.

https://diyhpl.us/wiki/transcripts/london-bitcoin-devs/2019-07-03-alex-bosworth-submarine-swaps/

MF: This is Alex Bosworth’s talk at London Bitcoin Devs on submarine swaps in 2019. This is introducing a new concept where rather than swapping currencies on different chains you are swapping Bitcoin onchain for Bitcoin on the Lightning Network. This is useful in the context of submarine swaps and wanting to change your inbound, outbound capacity by making onchain transactions. nothingmuch says it makes more sense to do CoinSwap first, perhaps it does but I will stick with this as we are following the timeline. I think the discussion on submarine swaps was happening a year or two ago, there wasn’t the discussion on CoinSwap for privacy.

AG: I totally disagree. I spent a lot of time in 2017 writing a library to do it and we used it. CoinSwap was always a very minor topic. The Lightning white paper came out in early 2016, it took a long time to get the ball rolling with Lightning. During that period there were a few of us, you could see people occasionally getting excited about CoinSwap as a privacy idea but it was always difficult to get it off the ground. Perhaps we can discuss why that was at some point. I wouldn’t say CoinSwap was a thing that came after submarine swaps.

nothingmuch: The main innovation in CoinSwap was the observation that you could do a cooperative multipath spend and keep the information offchain. I believe that was the main insight that these kinds of things could happen offchain. You could have a binding set of transactions that makes assurances to both parties without ever making it to the blockchain so long as both parties cooperate. By having an incentive to cooperate, in this case fees, that is how you gain privacy. The hash preimage is never revealed if both parties actually follow through with the protocol.

AG: I am not sure about the multipath aspect. There has been discussion about that at various points. Almost everything else I totally agree with.

nothingmuch: I shouldn’t have used that word because multipath is overloaded. I meant the different contingencies that may arise.

MF: It felt like there was a lot more conversation going on around submarine swaps than CoinSwap. The privacy wiki has a small section on it. But when I was looking at resources on this I was seeing very few resources on CoinSwap. Perhaps it was all being done behind closed doors.

AG: The public’s imagination was captured principally by the concept of an atomic swap, especially in the middle of the craze we experienced from 2016 to 2018. Partly because of all the altcoins and everybody got very excited about how you could trade trustlessly. Lightning exploded in some sense amongst a certain group of people between 2017 and 2018 when it went live on mainnet. Alex being the fountain of incredible ideas that he is, pushed this submarine swap idea. It is just another variant but it is a more complex variant of the things we are discussing here. It might make more sense to go atomic swap, CoinSwap and then talk about the more exotic things.

https://github.com/AdamISZ/CoinSwapCS

AG: I wrote code and built it in 2017. That repo is probably more interesting for the Issues list than for the code. I went through Greg Maxwell’s post in detail and it took me like 2 days before I eventually realized that there was an error in what he wrote. That is only important in that it let me write down what the protocol should be. You have this on your diagram. Greg’s basic idea was to have an atomic swap, both parties have an exotic script that I have already described, pay to a hash or to a timelock. Then have this overlay which is what nothingmuch was describing. This is a very important principle, we are seeing it in Taproot, all kinds of contracting ideas. If the two parties cooperate then the conditions of the contract do not need to be exposed to the world. Instead you overlay on top of the contract completion a simple direct payout from a 2-of-2 multisig to whatever destination. On the meetup diagram it is the transactions at the top, the TX-4 and TX-5 that pay from the 2-of-2 directly to Carol’s keys and directly to Alice’s keys. CoinSwapCS was just me thinking I can actually concretely make a code example of how you could have CoinSwap servers and clients. This is perhaps something that we will get onto with Chris Belcher’s description recently, we talked about timeouts and how it depends on the clock of the blockchain, the nature of it is it is a two step protocol. The initial funding phase and then when that is committed then you can build these contracts. You need to commit into shared control. In that specific version of the protocol Alice pays into a 2-of-2 with Alice and Carol. Carol also pays into a 2-of-2 with Alice and Carol after of course having pre-agreed transactions that spend out of it just like many of these contracting systems. I coded that up where I had Carol as a server and Alice would be querying Carol and saying “Can I do a CoinSwap for this amount?” They arrange the transactions and they set it up. It is a two phase thing. Fundamentally it is more interactive than something like a Coinjoin where you are just preparing and arranging a single transaction or more importantly a single phase. As I explained in CoinjoinXT it could be multiple transactions. It is still a single negotiation phase in Coinjoin. With CoinSwap it is a lot more powerful of a technique because what you end up with is histories not being merged but histories being completely disconnected. The trade-off is you have cross block interactivity. Part of that cross block interactivity is you have to trust the blockchain not to re-org which you means you have to wait not just ten minutes but quite a long time between these phases of interactivity. One of my blog posts nearly three years ago was on how CoinSwap work, the different types of them. With later blog posts I talked about the Schnorr variants and so on. It is all about that basic concept that you have an atomic swap, because you are using multisigs you can overlay it with a direct spend out to the two parties so that what appears onchain is not a hash or anything, it just looks like an ordinary payment. But it is multisig and this is something that Chris Belcher has tried to address in his write up.

MF: Some of the issues to tee up the discussion of Chris’ proposal. There are a few interesting things here. One is this tweak, this is the bug you found in Greg’s initial design?

AG: Yeah that was me explaining what the problem was with the original post. It is all in the weeds, I wouldn’t worry about it, it is details.

MF: Your blog post, you talk about some problems that I’m assuming Chris would have had to addressed as well. One of them was malleability. Is that an issue we should discuss?

AG: Not really because that was solved with SegWit. This was around the time of activation so we were trying to figure out whether we needed to address non-SegWit or not. Much like Lightning.

MF: It is exactly the same concept.

AG: Yeah.

https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017898.html

MF: This is Chris’ mailing list post from May of this year. There’s also the gist with more details on the design. How does this proposal differs from your work Adam in 2017?

AG: It wasn’t just me, many others were enthusiastic back then. How is this different to what goes before? It isn’t really. It is a fuller fleshing out of the key ideas. A couple of things that he has added into the mix. It is a long post and it has several ideas. Using ECDSA two party, what this means is because we need to use multisig but we don’t really want to use ordinary multisig. The thinking behind this is subtle. When you do a Coinjoin in the current form like Wasabi, Joinmarket, Samourai etc you are doing a completely non-steganographic protocol. In other words you are not hiding that you are doing the protocol which means that the anonymity set of the participants in this privacy protocol is transparently the set of participants at least at the pseudonym level that went in. The specific set of addresses that went into the protocol. When you try to move to a more steganographic hiding protocol, with something like CoinSwap specifically you are hoping to not make it obvious that you have done that. As has been discussed at great length in the context of Payjoin and other things there is a huge benefit if we can achieve the goal of having any one of these protocols be steganographic because it could share a huge anonymity set rather than a limited one. If you want to achieve that goal with CoinSwap the first step is to use an overlay contracting system such that the outputs in the cooperative case at least are not exposing things like hash preimages or other custom scripts. At the least you want the outputs to be let’s say 2-of-2 multisig. The reason he is mentioning and expounding on ECDSA two party, he is talking about specifically the scheme of Yehuda Lindell where you use somewhat exotic cryptography such as the Paillier cryptosystem in order to achieve the goal of a 2-of-2 multisig inside a single ECDSA key. If you achieve that goal then you are going to create such a CoinSwap protocol in which all of the transactions at least at this level look like existing single ECDSA keys which is basically all the keys we have today apart from a few multisigs here and there.

BM: I guess the things that have changed since 2013, first of all we got CSV, timelocks are way better. Secondly we got Lindell’s two party ECDSA protocol and the multiparty ECDSA protocol which it doesn’t use Paillier, it uses ElGamal instead which is more compatible with …curves. Both are good for this, different security assumptions. The third thing which is I’m not sure is used here is adaptor signatures. We are going to talk about PTLCs in a minute. That hash preimage reveal is deanonymizing by itself. With adaptor signatures which you can do with both Schnorr and ECDSA you can reveal that preimage in a manner that only the recipient can find it.

MF: This is the ECDSA-2P section in Chris’ design.

BM: He doesn’t really talk about it all. It uses Lindell’s proposal.

MF: This is to have a 2-of-2 multisig with only one signature going onchain before we get Schnorr. It is space savings onchain as well as the adaptor signature property of superior privacy, not having that script telling the world exactly what is going on.

BM: That’s right. The price you pay for that is more rounds of communication between the sender and receiver. There are some zero knowledge proofs that need to communicated. I’m not sure what the count of the number of rounds is. It is at least three. For offchain payment protocols it is not that big a deal. If you look at MuSig and Schnorr you have a similar number of rounds in the protocol anyway because they have to decide upon the nonce for a group sourced Schnorr signature.

nothingmuch: A paper by Malte Moser and Rainer Bohme called “Anonymous Alone?” is an attempt to quantify these what they call second generation anonymity techniques on Bitcoin. It contains an interesting bit of data, an upper bound for how many CoinSwaps could be going on. It is only an upper bound under the assumption that multisigs that co-exist and are of a similar amount, coincide in time on the blockchain, any pair of those is potentially a CoinSwap. That is how they quantify the anonymity set. I think that that gives an intuition for all of the main ideas that Belcher proposed. This is the multiparty ECDSA stuff that makes the scripts less distinguishable. It is the introduction of routing which means that it is not necessarily a two party arrangement. And the splitting of amounts into multiple transactions so that the onchain amounts are decorrelated.

AG: Because of that paper they were making an assumption that multisig is going to be a fingerprint of CoinSwaps and this removes that fingerprint. That is one aspect?

nothingmuch: That paper tried to quantify how many users of privacy techniques are there. It addresses Coinjoins, stealth addresses and CoinSwaps. For CoinSwaps because the data is offchain all they can really do is give an upper bound how much CoinSwapping is occurring under some fairly strong assumptions. The first of these is that any CoinSwap is going to be anchored into two UTXOs that coincide in time that are either 2-of-2 or 2-of-3 and where the amounts are relatively close.

BM: There is one aspect of all this which is a pet peeve of mine. Belcher’s example has Alice dividing 15 Bitcoin into 6 plus 7 plus 2. What we need to do in order to get this is we need to be doing binary decompositions of value. 16 million satoshis plus 8 million satoshis, using a binary decomposition you can get any value you want. Each set of binary decompositions becomes its own anonymity set. That’s the best you can possibly do as far as the anonymity set. But if everybody is dividing their value arbitrarily down to the satoshi you have a very strong fingerprint and a very strong ability to correlate. If I ask the question “How many pairs of outputs on the blockchain can I sum to get a third output on the blockchain?” Maybe these two are engaged in a CoinSwap. The ability to do that is still extremely strong.

AG: That is a very good point. I would make the argument in the Joinmarket scenario it is not necessarily as easy as you might think because you tend to get a lot of false positives. But I think your fundamental point is almost certainly correct.

nothingmuch: This is a bit of digression. I have been thinking about what I have been calling preferred value series. It generalizes to more than just binary but to any minimum Hamming weight amount, it could be decimal as well, it could be decimal with preferred value series. The intuition there is that if you have a smaller set of amounts that you can combine together to create arbitrary amounts then the likelihood that those amounts will have an anonymity set is much larger. The issues with that are if you need a UTXO for every significant bit in your amount, let’s say the average Hamming weight of an amount is 5 significant integers or something then you create a substantial overhead. We haven’t shared anything yet because as a group we haven’t come to consensus about that. For the unrelated stuff about Wabisabi and Coinjoins this is definitely the approach I have in mind and I am happy to share. Finally there is a way to make it practical without necessarily having that problem of this is 5x, 10x UTXO bloat factor.

BM: There is definitely a bloat factor there. The way this is handled in traditional markets is if you try to buy certain kinds of stock you can only buy stocks in lots of hundred shares. On the foreign exchange markets in lots of hundred thousand dollars. I envision that if a trading market were to arise in this manner there would be a minimum lot size significantly larger than the dust limit. You are obviously not going to go down to satoshi because you can’t make a single satoshi output because you can’t spend it and it is below the dust limit. Something like 8 million satoshis, 16 million satoshis would probably end up being the minimum lot size and then you do binary decomposition above that.

nothingmuch: The transaction structure in mind, I’m only speaking for myself here, is the Coinjoins where you have different mixing pools for those Hamming weight amounts, every power of two, that occur as parts of larger Coinjoin transactions. You can imagine a perfect Coinjoin that has a nice switching network topology and there would be representative inputs and outputs of every such class. If you have a Coinjoin transaction that is constructed in this way then in theory this gives you a blinding factor for all of the other arbitrary amounts. This is based on the Knapsack papers definitions of a non-derived sub transaction, the idea of how many different ways are there of combining assuming that all of the inputs and outputs are self spends inside a Coinjoin. A Payjoin breaks this heuristic. If you do the sudoku attack where you constrain things and find partitions of the transaction that balance to zero the idea there is that you always have ambiguity in that case. Every possible amount could be an arbitrary composition of those Coinjoin elements that have that power of two. The reason I’m bringing it up is that I think it is really relevant for this case because a big problem with CoinSwap coordination generally is that if two users are swapping history then one of them in theory gets a tainted history. Unless there is a common understanding that taint is no longer a valid assumption then there may be an disincentive for people to offer swaps because if you don’t know the provenance of the coin you are swapping against maybe you lose fungibility in that transaction. In this case if there are Coinjoins that allow the creation of fungible values of arbitrary amounts you can do a CoinSwap where one side of the CoinSwap is an output from such a Coinjoin I think that creates a very complementary onchain scenario. Users can swap arbitrary amounts without having a very strongly identifiable footprint.

BM: That’s absolutely right. That is what concerns me greatly about these CoinSwap proposals. It is literally a swap. I am going to give you my UTXO, you are going to give me yours. Some of the other proposals, statechains, have the same property where I am going to get a new UTXO. If there is a pool of UTXOs out there and one of them came from a darknet and is blacklisted somehow, somebody is going to get that UTXO, they are going to get the full UTXO and it is going to be a bad one. This is a strong disincentive to use such a system. Whereas with a Coinjoin I have 100 inputs and 100 outputs and I don’t know which is which and so each one is tainted 1 percent. With the CoinSwap proposal one UTXO that somebody is going to get and it might be you, is tainted at the 100 percent level and the others are not tainted at all.

MF: I had exactly the same thought. Let’s say you’ve got completely clean Bitcoin straight from being mined versus Bitcoin that has been through an identified drug mixer you are not going to be too happy swapping those two. Unless as soon as you get your Bitcoin you do loads of transactions to yourself so that you beat the taint score or the taint measure that people like exchanges use.

nothingmuch: I don’t think that is robust because it is pretty easy to do modular decomposition of graphs. You can identify a strongly connected component that originates from a small set of outputs. Even if it is a larger graph it is still equivalent to a single transaction in that case. Unless you are actively mixing with other users’ history I don’t think that approach buys you much in terms of privacy. It may be a very effective way to get past simple heuristics of exchanges but I would caution against actually thinking about that as a privacy enhancing technique.

MF: I am talking about the CoinSwap being the privacy technique. But let’s say you got the short straw, you’ve gone into the CoinSwap and you’ve got these “tainted” Bitcoin. You then need to get them untainted if you want to go into an exchange or you want to use a merchant that has restrictions on which Bitcoin they will accept.

nothingmuch: That process of untainting, it works today just because the heuristics the exchanges use are very crude. They are only doing this as a cost saving measure to reduce liability anyway. If this becomes more common then all they have to do is slightly ramp up the computational difficulty of identifying these graphs of self spends or whatever. It is not a difficult problem to identify those because the subgraphs are disjoint. If there are no transactions connecting it to the rest of the transaction graph it is fairly easy to isolate.

MF: On the YouTube shinobius monk says “I demand an immediate in depth comment from everyone on how to deal with the timing issues of successive CoinSwaps hitting chain in short time period.” Filling up blocks with too many CoinSwaps?

I think what he says is that CoinSwaps can be identified if they are hitting the chain in a very short period and maybe the amounts can be correlated. How do you know they are CoinSwaps? I don’t know, maybe there are ways to guess.

AG: Is he talking about timing correlation? I think this relates back to something I was thinking we should definitely discuss which is what are the practicality issues around CoinSwap? I think people should take note of an interesting historical fact that in late 2013 Greg Maxwell made two very similar long Bitcointalk posts, one called Coinjoin and one called CoinSwap. I think Coinjoin was implemented in some form or another within one month of the Coinjoin post but when I looked at it in early 2017, four years later, nobody had implemented CoinSwap at all.

It is because there was a Coinjoin bounty.

AG: I don’t think so. I think fundamentally CoinSwap is a more powerful protocol but there are some practicality issues that we should start discussing assuming that everyone on the call now understands what a CoinSwap is.

MF: shinobius also says “You arguably don’t get atomicity in the sense of state guarantees across two different proof of work chains.” I’m assuming that it is due to re-orgs, I think that is his point there.

AG: It is definitely worse because you are dealing with two clocks, it is significantly more messy. It is kind of the same basic problem I guess.

MF: There are a lot more re-orgs on other chains with less proof of work. It depends on how s*** your s***coin is. Josh Smith brings up the blockchain space issue which is mitigated by having one signature onchain with ECDSA-2P or Schnorr.

AG: It depends what you are comparing it to. Think about it in comparison to Coinjoin as a privacy technology. It is fundamentally a lot more fungibility per byte onchain. It is difficult to quantify but it must be partly because of this steganographic thing, what is your anonymity set if you do a 50 party Coinjoin? You could say my anonymity set is 50. But what is your anonymity set if you do a CoinSwap properly such that nobody even knows it is a CoinSwap. It is either a lot or you can’t define it. It is pretty efficient which is one of the main reasons Chris Belcher, myself and many other people were always very interested in CoinSwap even if we thought it was quite difficult to implement.

nothingmuch: Furthermore it has a positive sum type interaction. When you CoinSwap you are also helping the privacy of every non-CoinSwapped output that has the same script type.

AG: We discussed in Payjoin the same dynamic.

MF: Another question from shinobius. “Belcher’s idea of routing amounts through successive CoinSwaps and the impracticality of staggering the time between individual transactions in a chain of CoinSwaps for intervals that are too long.” This was a clarification for the previous question. Having too many successive CoinSwaps and staggering the time if there is an overlap between one CoinSwap that you are engaging in and the next CoinSwap.

https://gist.github.com/chris-belcher/9144bd57a91c194e332fb5ca371d0964#routing-coinswaps-to-avoid-a-single-points-of-trust

MF: The problem that I understand routed CoinSwaps is addressing is if I do a CoinSwap with Adam and Adam is a malicious party, a chain surveillance company, then I am telling Adam what my history is which isn’t ideal from a privacy perspective. But if you have this circle where everyone is doing CoinSwaps with each other and there are multiple parties you now have to worry about all of them colluding rather than one malicious party. How does this routed CoinSwap work?

I think we can believe that assumption is correct. It is more important to explore how that assumption changes other properties of CoinSwaps if it changes them at all. There is a problem with two party CoinSwaps because the other person learns the history. It might be a more interesting question to explore accepting the solution works. Does it ruin the user experience? Does it do something else other than merely fixing the problem? Is it harder to implement?

AG: I haven’t thought about this much. I think Chris talked about some of the issues on the CoinSwapCS repo a couple of years ago. I remember him talking about this and multi-transaction. This addressing a privacy problem, it seems to me we are looking at exactly what we see on the Lightning Network. It is not exactly the same but it is almost exactly the same mechanic. We are going to have staggered timeouts to make sure that no party is every in a position where they could lose on both ends of the trade. It addresses a privacy problem in that same way where every participant in the route doesn’t know for sure the originator.

nothingmuch: I think it would be useful to go over the privacy issues with Lightning first as it stands today with HTLCs. If we assume that the routing is only a problem for CoinSwap makers much like the public Lightning graph is not considered to be a privacy issue. When you do a routed payment you are making a HTLC with the first party in the route and giving them an incentive to enter a HTLC with the next party. But along the entire path even though anonymity is guaranteed everybody shares the same secret. We mentioned it earlier, the PTLCs as a solution to this, also anonymous multihop locks and a bunch of other approaches. If I’m not mistaken Belcher doesn’t go into detail about how routing is supposed to work. The implication is that it uses adaptor signatures.

AG: Anonymous multihop locks is actually the same thing. It uses points to achieve the security proof to avoid the wormhole attack but of course it has other excellent properties.

nothingmuch: I am not 100 percent on the details to explain how you can use adaptor signatures to create something that is equivalent to a whole route sharing the same preimage without that secret actually being shared by all parties.

AG: You are just talking about the general idea of point timelocked contracts? In the anonymous multihop locks paper they explain how you can have a tweak to the nonce essentially at every hop such that every party subtracts has their own single secret and it is added along the path so that everyone gets the same guarantee as they would if everyone just used one secret. But each person’s secret is different using the linearity of Schnorr. You can think of it as using the linearity of Schnorr to make it so that we are not all using the same hash preimage, we are all using something like a hash preimage that is locked together. But each of our numbers is different. We talk about adaptor signatures, are we talking about using CoinSwap of the type that was initially proposed by Andrew Poelstra? I wrote it up in the blog post “Flipping the scriptless script on Schnorr”. We are talking about using an adaptor signature to affect a CoinSwap so that instead of worrying about the hash preimages all being onchain so someone can connect them. Because the equivalent of a hash preimage is actually embedded inside of the nonce in this adaptor signature it means that nobody sees it anyway. It means we don’t need this overlay protocol, we can make a much simpler CoinSwap. Are we doing that kind of thing across multiple hops but we are using ECDSA adaptor signatures? Is that what we are doing?

BM: I don’t know that adaptor signatures are required or used here. My understanding of Belcher’s proposal was that Alice who is doing the CoinSwap is actually mediating multiple CoinSwaps at the same time. Two of the people she is mediating, Bob and Charlie, Bob doesn’t know Charlie exists. It is centrally routed around Alice as opposed to the linear chain that happens on Lightning.

AG: There are two parts. There is a multi transaction part where Alice parallelizes. Then there is a routing part. He talks about them in two separate sections. And he talks about combining multi transaction and routing together. Routing CoinSwaps to avoid a single point of trust then you’ve got combining multi-transaction with routing. First it is multi transaction CoinSwaps to avoid amount correlation. That is just Alice and Bob making multiple CoinSwaps between those two parties. Then there is routed CoinSwaps, there is shows an actual chain Alice, Bob, Charlie, Dennis. Finally it talks about combining multi-transaction with routing. Between Alice and Bob they have multi-transaction and between Bob and Charlie they have multi-transaction and so on. It is both effects that are being talked about. In terms of adaptor signatures, he is only talking about adaptor signatures in this document in connection with Succinct Atomic Swaps. He is not including that in the proposal. You would have different hash preimages in each of the hops along a route here. That is different to Lightning.

MF: It is not a route is it? It is a circle from Alice to Bob to Charlie and back to Alice. It is not like a Lightning payment where I am trying to get to a destination and there are a bunch intermediaries helping me get it to that destination. It is almost like a ring signature?

AG: I disagree. I don’t think it is fundamental that Alice is sending to Alice in that example. Think of it as Alice’s source and Alice’s destination. If her destination happens to be something that she owns then it is but it is not fundamental to what is going on.

MF: A question on the YouTube from shinobius. “Isn’t the idea to just chain the transactions together without signing/submitting the first “funding” for the routed CoinSwap? That’s what I inferred from the proposal”

AG: I think you guys must be right. The whole thing must be atomic. We are still in the situation where only in the cooperative case would we have proper privacy. Perhaps that reveals that we have extra fragility if we have multiple participants. You already have the concern when you do a single CoinSwap between two participants that if the other guy doesn’t respond in time you are going to have to publish onto the blockchain. It is going to be obvious you did a CoinSwap and you maybe didn’t want that. I am worried that if you have a lot of participants the potential for at least one party to drop out. That would just affect that hop? If you had four hops and the guy who is third along drops out and doesn’t respond then maybe two of the four hops end up broadcasting the hash to chain.

nothingmuch: The parties could in that case choose to still settle cooperatively but the entire route may learn. Suppose Alice sends to Bob who sends too Carol. Carol sends the final payment and then Carol defects and reveals the hashlock. This is what I mistakenly assumed earlier that Chris was relying on adaptor signature. In that case Bob will still learn where Alice’s funds went. Whereas in the optimal case Bob has no idea where the final payment is sent. He only knows that he is sending to Carol.

AG: Mentioning adaptor signatures makes a lot of sense because it does take away that problem. Then there is the question of whether in a ECDSA context, given recent work by Lloyd Fournier those kind of single signer ECDSA things might work. We can do adaptor signatures with ECDSA, that Lindell thing?

Ruben Somsen (RS): I believe that is possible. Lloyd’s work is specific to single signer ECDSA. You wouldn’t have the privacy that Belcher wants. Generally speaking my intuition would be if you have a multiparty protocol it will either be like Lightning where you have A depends on B depends on C. Or you are going to have the protocol that you wrote up, Multiparty S6. I think you’d need to use one of either in order to make it work. Belcher writes up a bunch of variations on how to do CoinSwaps.

AG: It is either going to be a chain or it is going to be a big network all connected. That S6 thing, it is kind of a chain anyway.

RS: That would be a way to do adaptor signatures.

AG: The point me and nothingmuch were arriving that is if you are going to do this kind of onchain chain of swaps, Lightning uses offchain chains of swaps HTLCs, if there is one link in the chain that defects it is going to be revealing information onchain. You get that with two parties but the risk is much lower. If you have six parties the risk gets higher and higher. If you were to use adaptors then it would avoid that problem because you don’t have the defection problem in the adaptor signature CoinSwap because the preimage is embedded in the nonce.

RS: I agree with that. Any third party wouldn’t be able to figure out what the preimage is.

AG: If he is going to use ECDSA-2P which the proposal is, this makes a lot of sense because it shares the anonymity set, then maybe wedge in adaptor signatures even if it is a weird ECDSA variant of adaptor signatures if that is possible.

RS: I believe it is compatible with 2P-ECDSA.

BM: It definitely is.

RS: Very generally speaking I think it makes sense to use adaptor signatures. Even in the non-cooperative case you are going to end up with less block space usage so why not if it is possible?

AG: We talked about routing. What about multi-transaction?

I am wondering if I completely misread the entire section of routing through multiple transactions in Belcher’s proposal. What I took away the write up on GitHub was that you effectively have the taker coordinating between multiple makers with these intermediary UTXOs that are two party ECDSA addresses. You coordinate that route, get all the things to the end of it signed and then you sign and fund it to compare it to Lightning. That is binary, succeeds or fails with 2P-ECDSA preventing anything conflicting from being signed. You could even enforce staggering delays of hitting the chain with the nLocktime field.

BM: Doesn’t every party have to create a funding transaction? The original proposal had four total transactions. As I understand it Belcher’s proposal has two transactions total per swap. One transaction per party. I think that means in the routing network there is one funding transaction per entity and then you have to close it out. This whole routing network is not offchain like Lightning is. It is all onchain.

nothingmuch: I believe that is correct. In this regard the difference between Lightning goes away. In Lightning the preimages are shared peer-to-peer but the route is derived by the sender. Here because everybody is.. broadcast network, the blockchain itself, the parties along the route don’t have to communicate with each other directly like they do in Lightning. Everything is mediated by Alice.

AG: Alice must be choosing the set of participants.

nothingmuch: Yes. That is also true of Lightning.

AG: Source routing.

nothingmuch: The difference is in this scenario because there isn’t the offchain aspect, Bob and Carol are not in some sort of long term arrangement between them in a payment channel. The only situation where they need to coordinate with each other is in case the payment doesn’t go through. They have the blockchain for that because it is onchain.

BM: The original proposal had four transactions. Alice swaps with Bob. Both Alice and Bob have to create a funding transaction. At the end of the swap they have an exit transaction where they retrieve to their wallet. It is four total transactions. Using the notion that Chris Belcher talked about, swapping private keys where it is effectively a 2-of-2 multisig, at the end of the process I am going to give you one of the two private keys and you already have the other one. Now you have unilateral control and doesn’t need to go onchain.

AG: I think you are talking about Succinct Atomic Swaps which is Ruben Somsen’s thing.

https://gist.github.com/RubenSomsen/8853a66a64825716f51b409be528355f

RS: There are two things about the Succinct Atomic Swap. The thing you are talking about now is possible with regular atomic swaps as well. You do the swap, you don’t broadcast the final transaction, you just give each other your key of the funding transaction. The problem you have then is that there is still this refund transaction that becomes valid after some period of time. But it allows you to direct the outputs towards whatever you want before that timelock expires.

BM: You are still going to have to exit onchain so we are still talking four total transactions. You can delay the final exit but I cannot reuse that commitment transaction for another swap. If Alice and Bob set up the two commitment transactions that have to be executed or cancelled and if I want to swap with Charlie I need to create a new commitment transaction involving Charlie’s key.

RS: The point there is that it is another funding transaction. You go from funding transaction to funding transaction and you skip the settlement phase because you have full control over the UTXO and can start funding again. As long as you react before that timelock expires, before the refund transaction becomes valid you can direct the funds anywhere you want including another swap. That is the basic premise, if you have a server that does a lot of swapping or you want to swap a bunch of times then you do not have two transactions, you only have one transaction per swap. Succinct Atomic Swaps are a separate thing where you don’t have the timelock on one of the two outputs that you are swapping. That gives you some additional benefits because then that one doesn’t expire.

BM: Worst case scenario there are four transactions per swap, best case scenario two transactions per atomic swap.

RS: The worst case is that your swap doesn’t go through. If your swap doesn’t go through it is four transactions.

BM: I was really hoping this was doing swaps offchain.

AG: That brings up the interesting question which is raised in the document which is how does this compare with Lightning? Shouldn’t we just use Lightning and he talks about several angles to that.

BM: Let’s assume there are multiple Lightning Networks here, one on Bitcoin and one on Litecoin and I can swap between those two. Isn’t that far superior? I don’t think anyone has really done that except in small experiments.

AG: This isn’t attempting to replace cross blockchain swapping or trading. It is attempting to provide a new functionality for privacy in Bitcoin. The question of why we don’t we just use Lightning I think is a good one but it is addressed specifically in a whole section in the document. His first advocacy for this approach really surprised me. It wasn’t the first one I would think of. “CoinSwap can be adopted unilaterally and is onchain.” He is pointing out that in a world where your friendly local Bitcoin exchange or similar company decides not to adopt Lightning and you are sat there twiddling your thumbs getting annoyed with them, this can be done today and doesn’t require anyone’s permission. If you can make payments via either a CoinSwap or some complex routed CoinSwap then you don’t need the permission of the recipient of the payment. It is an interesting point to lead with. He makes a couple of other points about liquidity and size. When I was looking at this in 2017 and writing code for it I was thinking is it worth looking into this as a separate technology considering Lightning in 2017 was being developed actively and was almost ready for prime time? It may only have a small role but it might have a role simply because it might be able to support larger sizes. It could be a more heavy protocol. It doesn’t have the same advantages as an actual offchain protocol but it creates a privacy effect similar to what Lightning does and perhaps for a very large payment. He also talks about sybil resistance and he is talking about fidelity bonds there, something he worked on recently. We recently merged that code into Joinmarket although it isn’t active yet. The idea of fighting sybil attacks with fidelity bonds is interesting. I haven’t thought that through in the context of CoinSwap, how that is different. He makes two or three arguments as to why it is still an interesting thing even though Lightning exists.

BM: I don’t buy his argument that onchain is good. Onchain payments are dead. We should not be using them, we should be using Lightning everywhere. It is going to take time for the market to adopt that. The argument that somebody is still using BitPay from 2014 is not a good argument.

AG: Onchain consumer payments are dead, I would almost but not entirely agree with you and are not a particularly interesting thing. They exist in small pockets, that is fine. Bitcoin is not just consumer payments.

RS: I think it is fundamentally different. With Lightning you have a channel and you still have to open the channel. When you are opening it it won’t be clear until after you’ve closed the channel how much of that money is going to be yours. But it is clear that is a UTXO you are controlling. Before you open the Lightning channel you still need some kind of privacy. At the very least swapping into a Lightning channel or something along those lines seems useful to me. I think it is orthogonal in a sense and there does seem to be a use case even if Lightning becomes amazing and perfect and everybody uses only Lightning. I think it still helps with privacy in the sense that you still have some onchain footprint.

nothingmuch: I would go further. It is not just orthogonal it is also composable. This is exactly why I thought it is better to wait to bring up submarine swaps because that is exactly the use case. You are still swapping on Bitcoin but you are swapping an onchain and an offchain balance.

MF: To be clear, Chris Belcher’s design is fully onchain. Everything is hitting the chain and the part of the document which Adam was discussing is comparing it to Lightning. Chris is saying there is not enough liquidity on Lightning. If you want to do large amounts Lightning is not up to the job and perhaps never will be for large amounts.

BM: That is a very valid argument. Lightning also forces you to put your keys online to a certain extent. It maybe very useful for retail payments but is not going to be useful for high volume traders. Does this give you better properties as far as keeping your keys offline that Lightning? I think it does.

AG: It is a sliding scale really. It does yeah. You could do this entirely with a hardware wallet for example.

BM: Not necessarily. The 2P-ECDSA has multiple rounds of communication. That means you have to put your keys online too.

nothingmuch: These differences are not fundamental though. It is a spectrum of design choices and implementation choices and a function of the adoption. I think it is difficult to speculate at our current vantage point in the present whether Lightning is going to have liquidity issues in two, three years time.

MF: If we are to move briefly onto submarine swaps, when you are swapping Bitcoin onchain for Bitcoin on Lightning then the liquidity issue really comes into play because you could expect it to be a large amount onchain and a smaller amount on Lightning yet if you are doing it for privacy reasons that amount needs to be the same. Amounts that make sense economically to be transferred onchain are not necessarily going to be the same amounts that are being transferred on Lightning.

nothingmuch: What I can see in my mind in an ideal future people having access to Coinjoins, to CoinSwaps, to Lightning with public as well as private channels for various different purposes. Depending on your threat model per payment you can choose your desired level of finality or desired level of hot wallet security, desired level of privacy etc. None of these trade-offs are fundamental to any of these technologies. In principle it is more of a question of implementation. Right now it is very impractical to say you have fluidity with these things. We can envisage a situation where you have a smart wallet that only has watching keys and manages your funds. If you are going to make a very small payment it may make it via Lightning. If you are going to make a large payment to a party who you don’t trust it is going to do an onchain CoinSwap to give you stronger privacy and stronger finality. It also lets you move your balance a hot wallet and a cold wallet or something like that. The entire spectrum is in principle available. It is just a matter of actually implementing that.

MF: Ruben is discussing in the chat submarine swaps plus statechains. I don’t think we have time to go into statechains.

RS: That’s a whole other topic, maybe next time.

AG: Can we address the serious practical question, CoinSwaps are an idea, they are pretty old. What is going to be the motivation? I think we all agree that it could really improve fungibility and privacy. Whether Lightning is better than it or not is not really the issue because at the end of the day we have to do transactions onchain anyway. People might say “I don’t want to do a CoinSwap because I might get a dirty UTXO.” There is that and then it is a pain. You are going to sit around and wait 100 blocks? Nobody wants to wait 100 blocks to anything at all.

MF: Where is that 100 blocks coming from?

AG: I just made that up but the point is you have to be safe from re-orgs whereas you don’t with an ordinary payment.

MF: In practice Bitcoin doesn’t have too many re-orgs more than a block or two. That applies to s***coins but for Bitcoin that is not a problem.

AG: If you are paying for a house how many confirmation? It is a large amount and we are largely talking about larger amounts here. Maybe it isn’t 100 blocks, maybe that is ridiculous. Maybe it is 50. There is cross block interactivity. I am setting aside all the complexity involved with things like ECDSA-2P multisig which is a very exotic construction. What is the practical reality here? Is it going to be implemented? How are we going to get people to use it? Is a market mechanism an important part of getting people to use it? That might overcome people’s concerns on that being a dirty UTXO. If there is a market incentive to accept a “dirty” UTXO maybe it flips the whole perception. What are the actual practicalities here? Is it going to happen?

MF: That incentive question sounds the same Joinmarket doesn’t it?

AG: He mentions it in the document as I recall.

I think that CoinSwaps have a lot of potential synergies with Coinjoins in the sense of a way to maintain individual anonymity post Coinjoin with those UTXOs as they fragment. Eventually you could hoover them back into a Coinjoin and repeat a synergistic cycle between the two. After a Coinjoin you have to be vigilant with that otherwise you undo the gains from the Coinjoin.

RS: I believe the change outputs in a Coinjoin have amounts that aren’t the same as everybody else’s. That becomes a tainted UTXO that you can’t spend together with your Coinjoined coins. Maybe for that change amount it would make sense to do a CoinSwap or something along those lines.

In a general sense of a way to further disconnect your post Coinjoin spending activity. Even keeping things isolated trying to do things like Payjoin, eventually things are going to narrow themselves down in a long enough time horizon. CoinSwap is another postmix tool in that situation.

AG: I am not sure it really answers my question. That is an interesting area of discussion of how you can make even more powerful constructions but I am asking about practicality. Will people to do this and what are the vectors to decide whether we will end up getting people doing this or not?

MF: I don’t like as the number of parties increasing the chances of it failing increase. You have the same dynamic on Lighting where the more hops you have on your route the more chance that one of those hops isn’t going to work and so your payment is going to fail. This is even worse because at least in Lightning all the intermediaries are playing the role of a routing node and most routing nodes what they are supposed to be doing. In this sense it is creating a privacy scheme where people don’t really know what they are doing. Someone could drop out and make the CoinSwap fail. As the parties increase I can’t see this being a good scheme.

Maybe people selling tainted coins on the dark market to people with clean coins who want to patronize dark markets.

AG: Belcher has a section on Liquidity market. It is just the flip side to what if I participate in a CoinSwap, I’m a normal person doing it in a normal way, and I end up with a direct 100 percent taint to some criminal activity. It is a very valid question. The point Bob was making was when you do Coinjoins you don’t get this binary either it is totally a criminal coin or it is not. You get this 1 percent taint or 2 percent taint or whatever which is something people can stomach more easily. I am ideological about this but most people are not like me. It is a concern in practice, in reality whether we have this binary taint problem.

RS: Isn’t the goal to make it so that everybody’s coins are tainted? The heuristic needs to break. You are paying someone with a 100 percent tainted coin according to some heuristic but then it is not a 100 percent tainted coin because you are not involved with that. We need enough people to do this in order for the heuristic to break so this can no longer be a reliable way of doing business. One thing I am thinking of, more to your question, if we have things like Payswap where you are paying a merchant and simultaneously doing a swap. If the merchant receives some tainted coin and they want to go to an exchange with those tainted coins what do you expect? Either we have this whitelist system where you only take the coins that some authority said are clean and everybody checks off the list. Or it becomes unmanageable. I hope it becomes unmanageable but I do agree to your point it is something that people are going to think about. Do I want to swap my coins if I have a reasonably ok coin and I am going to get some really bad coin from the dark market or something? That is definitely a concern. The previous point on tainted coins and untainted coins, two of these markets. That is a real disaster. There needs to be some flow that allows those two to intermingle in a way that is not traceable. If you really have two separate coins, clean ones and black ones, that is going to be terrible.

I think CoinSwaps on Coinjoins makes it much more practical because you don’t have to worry about the amounts anymore. That is a huge win there because you are doing equal amounts anyway. On the other hand what is the downside here? The only downside I can see is that now you don’t have this cumulative effect of CoinSwap obfuscating all the transactions on the blockchain. I would argue that wouldn’t happen anyway because wallet fingerprinting. Coinjoin is a wallet fingerprint and it still happens but only on the Coinjoin outputs. I can imagine a future where there are very small Coinjoins, very fast and this is good for 99 percent of the people. For those 1 percent who are the Julian Assanges of this world they might do a CoinSwap on those equal amounts. Everyone is happy, grandma can use Coinjoins with very little user experience or drawbacks.

BM: I agree. I think the answer is either or, it is both. I think the next interesting question what is the best way to combine these two? Can I make my commitment to a CoinSwap also be the input to a Coinjoin? Or the output from a Coinjoin be an input to a CoinSwap? I think that is the next iteration of this set of ideas that combines the best of both worlds.

AG: I think an interesting model is the CoinjoinXT thing, one of the things I had with it at that time when I was trying to figure out how do we address amount correlation across multiple transactions, I realized if you have a Lightning channel open as one of the endpoints… Think of a CoinjoinXT as a multi transaction Coinjoin. But it wouldn’t have to be a Lightning channel open, it could just as easily be a CoinSwap.

BM: I guess there are three concepts here. You’ve got Coinjoins, CoinSwaps and Lightning channel opens and closes. In principle any of those three could be any of those other three. The output of a Coinjoin could be a Lightning opening, it could be a CoinSwap. I should be able to compose these things. The extent to which we are successful in creating a protocol which naturally composes those three things and picks which one is best for the circumstance and increases the anonymity set of all three while decreasing the taint of all three as well, that is the ideal case.

Which should come first? CoinSwap or Coinjoin? Which makes more sense?

BM: We already have Coinjoin and Lightning.

RS: I like the argument of Coinjoining first and then using the result in a CoinSwap. That seems pretty good in the sense that you do have some anonymity already. Whoever receives that UTXO is not going to receive a fully tainted UTXO, it is already mixed with other Coinjoins.

nothingmuch: For completeness, submarine swaps also bridge the gap. That pertains to Adam’s point about CoinjoinXT. You can effectively have a Coinjoin transaction where one of the outputs is a submarine swap that moves some of the balance into a Lightning channel just like you can have a CoinSwap transaction either funded or settled through a Coinjoin. An interesting post from the Bitcoin dev mailing list recently is about batched CoinSwaps where you have a single counterparty as a maker servicing multiple takers’ CoinSwaps simultaneously which again blurs the boundary between Coinjoins and CoinSwaps.

https://gist.github.com/RubenSomsen/c9f0a92493e06b0e29acced61ca9f49a

RS: The main thing here is that with a regular atomic swap you set up a channel with Alice and Bob on two UTXOs. Then there is some kind of secret, one party can take the coin from the other party and simultaneously reveal their secret. That secret allows the other side to happen as well. With Succinct Atomic Swaps there are two secrets and they are both inside of one UTXO. The second UTXO is literally just a combination of those two secrets. Alice has a secret, Bob has a secret. Either the first UTXO gets refunded Alice and then Alice’s secret is revealed or Bob takes it and Bob’s secret is revealed. That determines who gets the second UTXO. Either they both get refunded or they do the swap. This creates this very asymmetric shape where one side has all the transaction complexity where ideally if everyone cooperates it is just a single transaction. If people don’t cooperate it ends up being roughly three transactions. On the other side it is literally is one transaction that settles immediately as soon as the timelocked transaction has completed.

MF: We discussed earlier that Chris Belcher’s CoinSwap, everything is going onchain and that is creating a cost and impact on block space. One of the key differences between CoinSwap and Succinct Atomic Swaps is more stuff is going offchain and less needs to go onchain. You have cut it down to two transactions.

RS: Cutting it down to two transactions, that is already possible in the original atomic swap as well if you assume either you are going to transact again before the timelock or you are trusting your counterparty not to try to claim the refund. There is always a refund transaction on a regular atomic swap. You can set it up in such a way where it becomes like a Lightning channel. If you try to claim the refund there is a relative timelock that starts ticking. If you respond before that relative timelock ends the refund can be cancelled. You do the swap, there is still the risk that your counterparty tries to claim the refund. If they do so you have to respond with yet another transaction. The downside to that is that it becomes three transactions. The worst case on the traditional atomic swaps would be both sides try to claim the refund transaction. If you want the channel to be open indefinitely, at that point you would have to respond. You could have a worst case of six onchain transactions. That seems pretty terrible. That is one way of doing it if you want to do the traditional style. You want to make it two transactions only. You assume that the refund transaction will never be attempted to be claimed. But with Succinct Atomic Swaps one side is literally settled. Once you learn the secret the money is yours. Or if you tell the counterparty your secret then they have the UTXO. It is one or the earlier. You only have this watchtower-like transaction where you have to pay attention on one of the two sides. That cuts the worst case down to four transactions. It is either equivalent to regular atomic swaps or if you don’t want the watchtower construction and you do want to settle then it is going to be three transactions. It is superior in most ways if what you are doing is a regular swap, one person to another. With multi swap protocols or even the partially blind atomic swap those protocols don’t seem to play well with Succinct Atomic Swaps. That is the downside. It depends on how fancy your atomic swap needs to be. If it is just a one on one swap it seems like Succinct Atomic Swaps are almost always superior.

MF: As long as you’ve got the online requirement. Chris’ CoinSwap doesn’t need the online requirement or the watchtower requirement.

RS: Even without that it is three transactions versus four transactions. Even without the online requirement it is still superior. What Chris is doing is saying “Let’s swap and then let’s swap again.” That way you need two transactions instead of four transactions. That is true but that is also true of Succinct Atomic Swaps. It depends on what your use case is. If you are constantly swapping then it doesn’t really matter. Only the final transaction you might want to consider doing a Succinct Atomic Swap because then at least one of the two parties doesn’t have to close out their swap session. It seems to be superior in most other cases.

nothingmuch: I wouldn’t say it is a requirement to be online rather it is a choice. You can choose to save on one transaction if you stay online but you don’t have to which is not the case for Lightning. With Lightning if there is a non-cooperative close you must stay online.

RS: It would be like closing your Lightning channel. You could choose to close your Lightning channel. You don’t have to be online. It is similar in that sense. You have the option to close it out.

AG: I think nothingmuch’s point is important there. Because there is a punishment mechanism there is a game theoretic aspect to a Lightning channel that doesn’t exist in a pure atomic swap or CoinSwap.

MF: That’s because you are keeping your channel open for a long period of time. In a swap you are just doing one swap, you are not opening a swap channel.

AG: There aren’t multiple states. The whole idea with that offchain protocol you have to overwrite a previous state without going to the blockchain. You use a punishment mechanism. With CoinSwap we just use the blockchain always.

MF: With Succinct Atomic Swaps you do have that punishment like mechanism.

AG: Yes which is the key point. It is a very beautiful protocol, I was really impressed reading it. That’s the crux of the matter. It does have a punishment mechanism to achieve its goal.

RS: nothingmuch’s point is you can choose to close it and then it is a three transaction protocol. It is an optional thing. There are two tricks. One is the asymmetric swap where one transaction doesn’t even need a timelock so you don’t need to worry about it. The second trick is the watchtower requirement. The watchtower requirement is completely separate. You can transfer that watchtower requirement to a regular atomic swap but then you have the watchtower requirement on both UTXOs that you are swapping. In order to have some kind of watchtower requirement you would have to have yet another transaction. There needs to be a trigger transaction that starts your claim to a refund. You broadcast one transaction and that signals “If you don’t do anything I am going to get my refund.” The party that is the rightful owner after a swap, Bob has the UTXO that Alice first created. Alice can claim the refund. Bob has to respond before Alice succeeds in claiming her refund.

MF: You briefly mentioned Jonas Nick’s partially blind atomic swap using adaptor signatures. With PTLCs you are getting the privacy in that you are not having a script onchain. What additional privacy are you getting from this partially blind atomic swap?

RS: I think it is already outdated because there is this other paper called A2L which is a better version from what I am told. The general idea is you have one party in the middle that facilitates swaps. Alice, Bob and Carol, they all propose a swap to the server S. On the other side the server doesn’t really know if they are swapping with either Alice, Bob or Carol. But it is an atomic swap. The end result is similar to a Coinjoin, a blind Chaumian Coinjoin but there is no single transaction on the blockchain. Instead you just see separate transactions like 1 Bitcoin transfers or something. There are two things I should mention that might be of interest. You can use MuSig on one of the swap transactions, the one that doesn’t require a timelock. You are not actually ever spending from it. It can be a regular, single key ECDSA UTXO. You can do Succinct Atomic Swaps on that. For one of the two UTXOs. The one that requires the timelocks where you reveal the secret you cannot do it. You would need a 2P-ECDSA or something there. On the other side it can be single key MuSig. You reveal half of the key and then that is efficient. That is very useful for privacy. The second thing that that does is because you are never signing from it if you want to fund that with a Coinjoin that is possible. That is possible today. That would be a very interesting way of doing it. You set up a Succinct Atomic Swap and then on one side you do the complex timelocked transactions. On the other side you fund it through a Coinjoin. Normally you would need to know the txid or something along those lines because you need to create a transaction spending from it before you start the protocol. That is not necessarily here at all. You could fund it through a Coinjoin or something along those lines.

AG: Yeah because usually we have to symmetrically fund these two multisigs.

https://github.com/MaxHillebrand/research/blob/master/ExternallyFundedSuccinctAtomicSwaps.md

MF: Max you have this research Externally Funded Succinct Atomic Swaps based on Ruben’s Succinct Atomic Swaps. Perhaps you could explain what use case you are addressing here and how it works?

MH: This is utilizing Succinct Atomic Swaps with one tweak in the user experience. A very important one with consequences. There is a client and a server relationship. The server coordinates the swap and the client utilizes the swap. This is the first thing. However the second aspect is that if might be that the user is CoinSwapping the coin that he is receiving in the future. There is a setup transaction where the coordinator commits Bitcoin into a swap script. This is at point time 1. Later at point 2 the user can send any Bitcoin from anywhere to a specific address that the coordinator can spend from. The interesting part here is that second transaction that triggers the setup transaction, this does not have to be from the user itself. This is very interesting. In the original Succinct Atomic Swap this was the Litecoin side of the chain basically. This side does not have to speak the CoinSwap proposal because it just sends to a regular address. Here a user or a different person who pays the user in our context can do so directly into a CoinSwap address. This would mean at a UX level that the user receives non-anonymous coins from anyone and instantly, as soon as he receives it, he gains access to funds out of a CoinSwap which presumably has a lot of anonymity. Therefore the user buys onchain privacy very quickly by swapping a coin which has a lot of privacy in any transaction that he receives the Bitcoin.

RS: Maybe I can give one example that I am thinking of now that might clarify for people. Obviously I have talked to Max so I know what he is talking about. I can imagine it is complicated to follow. The end result is that for instance what you could do is withdraw from an exchange and the money that the exchange is sending is funding a CoinSwap. The address that the exchange is sending to is not actually where you are receiving the money because you are instantly swapping those coins. That would be one example of what you are achieving.

MH: Yes exactly. This is the very nice thing about this aspect because one side of this Succinct Atomic Swap is very stupid basically. It is just a single key address that anyone can fund. This makes it easier in this sense. There are two important downsides that we should consider talking about. The first is that the server needs to go first. This has financial implications. If this is supposed to be a company or a user seeking to be profitable he will have to open a payment channel to a new user which is most likely an anonymous Tor identity with no reputation. Therefore there is a denial of service risk in the sense that an attacker creates multiple identities and lets the server open multiple swaps to the user, a malicious actor in this case, this will be very capital intensive. There is a need to figure out how to make a fee that will pay the service provider in advance when he is committing coins into the swap.

RS: It seems like Lightning would be perfect for that. You send a payment to open a channel and you even pay for the adversarial closing of that channel. If the channel is not closed adversarially you give a partial refund minus whatever fees you are charging.

MH: There is one more important thing to note. Because the server goes first and a potential third party, external user is going to fund the CoinSwap, the tricky thing is the server does not know exactly how much Bitcoin the third party funder is going to send to the user. It might be any amount. It could be 0.1 Bitcoin, it could be 10 Bitcoin. The server does not know in advance.

RS: I do think it depends on the example though. The example I just gave of withdrawing from an exchange and then immediately swapping, in that case you would know how much you are planning to withdraw ahead of time. It depends on what your use case is. Do you have a specific use case in mind where you are not certain how much money you are going to receive? Is it a payment from a customer? What are you thinking?

MH: In the case of the exchange yes you might figure it out. But it will change in nuances, how high will be the transaction fee and how much will be in the output that you get. The example that I had was Alice and Bob go to a restaurant and Alice needs to pay back. Bob knows that roughly 100,000 satoshis will come on but he doesn’t know if it is 950,000 or 110,000 for example. It is not exactly clear how many Bitcoin will be put into this thing. This is very tricky to figure out. What do you guys think? Is this a problem? To not know how much Bitcoin will be swapped in advance and knowing the setup?

MF: You mean a problem for this third party, this privacy expert?

MH: I think it is mainly a problem for the swap partner.

RS: One thing I am thinking is you can cancel the swap if you are not satisfied with the amount. Then before you are satisfied with the amount maybe you can do some kind of additional Lightning payment. It makes it more complex when you require the Lightning Network. A Lightning payment if the amount is not exactly what you were expecting. There is a little bit of a trust factor there. Or you can make it so that the Lightning payment only goes through if the swap goes through. That should be possible I think. That also relies on a secret. Maybe you can solve it like that but obviously you get a lot of overhead trying to utilize the Lightning Network while doing a swap. That may be not be very practical but that would be one way of doing it.

MH: It is an interesting approach. What Ruben and I figured out eventually was that if the amount is actually unknown then what the service provider can do is instead of sending to a regular swap, 2-of-2 pre-signed refund transaction, he uses a payment channel which has the interesting aspect that if the user Alice somehow thinks that she will receive under 1 Bitcoin but above 0.5 Bitcoin. The service provider can open a payment channel of 1 Bitcoin to the user with all of the money on the side of the server. When an external funder, Carol comes along and pays Alice 0.7 Bitcoin she pays this into an address that the server can spend. But only after they negotiate a payment channel update in that channel where the user will have 0.7 and the server 0.3. I am still not exactly sure if this actually works. To have a Succinct Atomic Swap with that payment channel set up on one side. This changes the timeline a bit of the amounts because there still needs to be one more payment channel update after the transaction is received from the third party funder.

RS: To very briefly summarize, the idea is to allow somebody to make a payment and instead of receiving it on that address you are receiving it on a CoinSwap. You are using that amount immediately to swap. The other side of the swap can be a channel where every time you do a swap you move a little bit of the balance of that Lightning channel to the other side. You can then use that same channel for multiple swaps. After maybe three payments are received now the channel is full and you close the channel. Something along those lines.

MH: Making a payment in this scheme as a user of that coin was just swapped is basically closing the channel in the cooperative closing transaction. And what someone could do potentially, I am still not sure, is to do splicing. You close the channel in the input and then you open a channel again in the output of a transaction. Even better maybe would be to swap some balances. If the user has two channels open to the server, one smaller and one larger, then the user could swap the value of the smaller channel into the larger channel with an atomic swap, a Lightning Network channel update, and then close the smaller channel. In a way that there is no change. As soon as the server and client are online and can communicate I think they can negotiate nice swapping ceremonies.

RS: I believe it is theoretically possible.

MH: The very nice thing with 2P-ECDSA and adaptor signature ECDSA is that this all looks like single public keys and nothing else in the cooperative case. This is fantastic.