Atomic + MASTs There has been a lot of talk recently about . What hasn’t gotten much attention, though, are the privacy implications. The current way they get implemented, . MASTs (Merkleized Abstract Syntax Trees) have been described generally as a privacy improvement. This example shows a practical and significant privacy improvement (assuming MAST gets integrated into Bitcoin). atomic swaps are not very private The community at this point is generally concerned more with ease of use than privacy. For example, all transaction are . These are surely being saved and used by coin tracking services. I suspect that most users would opt for enhanced privacy if given the opportunity. Shapeshift public All Shapeshift transactions are public are even from a perspective. As they are currently used, the trade is permanently and publicly recorded on the blockchain. Coin trackers at any point in the future can trace a transaction across blockchains. Lets examine how a based cross-chain swap currently works. Atomic swaps worse privacy CLTV Today’s atomic swaps With the above procedure, both parties’ coins are returnable if the other party disappears. Either the timer expires, and they get their coins back, or x is revealed and both Alice and Bob can claim coins. The atomic part is where Alice publicly reveals x on the W chain. Bob can find x, since it is now public, and use that to claim his coins. Alice cannot take the W coins without giving Bob the missing piece needed to take the Y coins. While safe, it has the disadvantage of publicizing that these are the same transaction. The presence of both Hash(x) (shown as x=?) and x on both transactions shows they are linked. Keep in mind, the value of the is to in the event of after the process has begun. If there is cooperation throughout the transaction, the parties can act together to finalize. It would look like this: atomic swap prevent loss non-cooperation Cooperative atomic swap available today This is still not private, since the hash of x appears in both chains. They would use different pubkeys on the different chains, so the pink key on chain W would differ from the pink key on Y, but the x value must be the same on both chains. MAST allows the first transaction to be rewritten so that only one of the three redeem conditions needs to be revealed. In the cooperative case, neither x nor hash(x) needs to be revealed publicly on Blockchain Y. Both Alice and Bob will know the all the redeem conditions to protect themselves, but won’t reveal unless needed. Here is how the first transaction would be constructed: Merkle tree of possible spending options MAST allows us to instead represent this script as a tree. The combining of colors represents hashing. The brown hash at the top is what locks up the coins. The coins can be spent if a proof that colors (hashes) can be combined to a leaf color which matches a spend condition. Also, the tree can be unbalanced, where a shorter proof (smaller cheaper transaction) is used in the common cooperative case. In the below example, they show that blue and pink combine to make a violet multisig. They then show violet and orange make brown. Thus after proving pink and blue are allowed, 2 of 2 signatures from Alice and Bob can move the coins. This looks like any ordinary MAST based 2 of 2 multisig on the blockchain. The public sees none of the fancy protection parts, just the orange hash. The important part is The public can’t even see that it’s a swap transaction. neither x nor hash(x) appears on Blockchain Y, increasing privacy. Cooperative private atomic swap with MAST In the situation where Alice disappears, then still his . Bob has the yellow x published in Blockchain W. non-cooperative Bob can retrieve coins Uncooperative Alice atomic swap Alice is protected too. If Bob disappears before starting his transaction, can a after a timeout period. Alice get refund Uncooperative Bob atomic swap There are multiple open proposals for how to implement MAST, each with different tradeoffs. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/014932.html https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki#hashed-time-lock-contract This example is just scratching the surface. So much more is possible, and we are just getting started. Far more complex contracts can be created in the future using MAST, more complex than can be imagined today. Additionally, if Schnorr signatures get added to Bitcoin, things can get even more private. One optimization would be to collapse the multisig transaction down to what looks like a , hiding even more information about the transaction. If both chains support Schnorr, then can be combined with MAST for even more privacy (see page 31). The swap would appear as unrelated 1 of 1 transactions on both chains. The explicit x revelation could be substituted with elliptic curve math. The link between transactions would again only be detectable in the non-cooperative situation. single signature Simultaneous Scriptless Signatures Thanks to Mark Friedenbach, Russell O’Connor, Paul Snow, & Justin Hanneman for feedback and additional insights. Discussion . here Brian Deery serves as the Chief Scientist at Factom, a data layer for the Bitcoin blockchain. He also co-founded Factom. Brian can sometimes be heard at on , where the hosts have named him . Let’s Talk Bitcoin The Crypto Show Dances With Bitcoin Follow him on Twitter at . https://twitter.com/deery_me
