Poster Abstract: Multisignatures for -Backed Tokens?

Alexei Zamyatin

1 Department of Computing, Imperial College London 2 SBA Research [email protected] Despite the influx of new and academic research on distributed ledgers, communication between permissionless is mostly facilitated using centralized liquidity providers, or exchanges. Recently, XCLAIM, a protocol for issuing, trading and redeeming cryptocurrency- backed tokens was introduced as a mechanism for trustless interoperability by Zamyatin et al.[7]. Thereby, users lock units a of a backing cryptocurrency A, e.g. [5], with an non-trusted and collateralized third party (the Issuer) and create the equivalent amount of tokens ab on an issuing cryptocurrency B, e.g. [4]. To redeem ab for the corresponding amount of a on chain A, users must destroy or burn the tokens in a publicly verifiable manner on chain B. The scheme leverages hashed time-lock contracts [1] on the backing blockchain, as well as chain relays [6] (e.g. BTC Relay [2]), collateral and smart contracts on the issuing blockchain, i.e., requires (near) Turing complete programming capabilities on chain B. While the Issuer maintains full control of the locked cryptocurrency units a for the duration of the protocol, XCLAIM guarantees that in case of Byzantine or crash failures of the Issuer, the victims will be reimbursed the equivalent monetary value of their loss from the Issuer’s collateral on chain B. In this extending work, we discuss how multisignatures can be used to further im- prove the safety properties of the XCLAIM protocol, preventing theft of locked units of the backing crpyptocurrency altogether, at the costs of reduced performance. Specifi- cally, instead of cryptographically transferring ownership of units a of the backing cryp- tocurrency to the Issuer, a is locked using e.g. a multisignature output in Bitcoin [3]. This prevents the Issuer from withdrawing the locked a without the user’s consent (i.e., stealing), while the user still cannot withdraw the funds before burning ab. The im- proved safety, however, makes trading of ab more complex, as transfer of token owner- ship on chain B must now be mirrored on chain A: if Alice wants to transfer ab to Bob, she must replace herself with Bob in the multisig on A. To this end, she must create and sign a transaction Treplace updating the state of the multisiganture and present it to both Bob and the Issuer in a publicly verifiable manner, e.g. by uploading the transac- tion as data on chain B. In the presented poster, we outline the multisignature version of the XCLAIM protocol and discuss possible improvements in terms of performance, cost reduction and privacy. Finally, we discuss the current disadvantages of using mul- tisignatures and give an outlook on their applicability in future extensions of XCLAIM using off-chain payment channels. ? This works extends upon the recently introduced XCLAIM protocol for cryptocurrency- backed tokens [7]. 2 A. Zamyatin

References

1. Bitcoin Wiki: Hashed Time-Lock Contracts. https://en.bitcoin.it/wiki/ Hashed_Timelock_Contracts. Accessed: 2018-05-16. 2. Btc relay. https://github.com/ethereum/btcrelay. Accessed 2018-04-17. 3. Bitcoin community. Multisignature. https : / / en . bitcoin . it / wiki / Multisignature. Accessed: 2018-05-23. 4. V. Buterin. Ethereum: A next-generation and decentralized application plat- form. https://github.com/ethereum/wiki/wiki/White-Paper, 2014. Ac- cessed: 2016-08-22. 5. S. Nakamoto. Bitcoin: A peer-to-peer electronic cash system. https://bitcoin.org/ bitcoin.pdf, Dec 2008. Accessed: 2015-07-01. 6. Vitalik Buterin. Chain interoperability. https://static1.squarespace.com/ static / 55f73743e4b051cfcc0b02cf / t / 5886800ecd0f68de303349b1 / 1485209617040/Chain+Interoperability.pdfi, 2016. Accessed: 2017-03-25. 7. A. Zamyatin, D. Harz, J. Lind, P. Panayiotou, A. Gervais, and W. J. Knottenbelt. Xclaim: Inter- operability with cryptocurrency-backed tokens. Cryptology ePrint Archive, Report 2018/643, 2018. https://eprint.iacr.org/2018/643. Multisignatures for Cryptocurrency-backed Tokens* Alexei Zamyatin

*An extension of the XCLAIM protocol. Scan QR-code to read the XCLAIM paper

XCLAIM: Cryptocurrency-backed Tokens Multisignature Locks: Improving Safety Optimizations

In three steps to interoperability (E.g. Bitcoin-backed tokens on Ethereum) Use Bitcoin 2-of-2 multisignatures to make theft by the Issuer impossible 1) Lock with Issuer ISSUER Issuer signs all TX only when token is (Non-trusted & Reduce Waiting collateralized 3rd Times redeemed party) (P2WSH - BIP141 Segregated Witness required) 2) Prove lock to Chain relay Issue

h7 = H(h5,h6)

h5 = H(h1,h2) h6 = H(h3,h4) Chain relay LOCK TX h2 h3 h4 verifies TX Lock Prove UTXO grouping scheme: inclusion proof and Confirm optimistic reduction of required TX to informs treasury Multisig O(1). However: interactive protocol! Lock 2.0 2.0 3) Issue tokens Reduce Costs / (A, I) (A, I)

Treasury contract 1.0 1.0 Transactions 1.0 0.3 0.7 issues Bitcoin-backed (A, I) (B, I) (D, I) (B, I) (C, I) ERC20 tokens 1.0 0.3 0.7

(D, I) (B, I) (C, I)

BTC transactions = 1 BTC transactions = 3 BUT: Requires additional Token States Challenges signature from A! Issue aborted

Trade REDEEMED Substantial tokens Fungibility of Fund freeze btc locked in btc amount of data still possible! HTLC released tokes cannot be Additional collateral on start NONE ISSUED guaranteed stored on Ethereum Bitcoin: PENDING Improve Incentives 1.0 1.0 Insufficient Redeem REDEEM 1.0 1.0 against fund freezing collateral requested | Collateralized commit btc locked Redeem failed, REIMBURSED + vs. + PENDING with Issuer eth reimbursed ISSUE 2.0 X

Protocols Issue Trade Redeem

4) The chain relay verifies 푇푏푡푐 is included 4) Contract makes Bob Ethereum 푙표푐푘 Ethereum X in Bitcoin’s main chain for at least 푡 owner of 푏푡푐 and allows 푒푡ℎ Ethereum 4) The contract burns X X 푐표푛푡푒푠푡 Precond.: Issuer has 푒푡ℎ 3) Bob publishes 푇푡푟푎푑푒 , collateral locked in Alice to withdraw the locking 푒푡ℎ in the treasury the 푏푡푐푒푡ℎ and emits an Chain 5) Confirms inclusion to Treasury treasury Chain locked eth Treasury Chain “unlock” event Treasury Relay treasury Contract Relay Contract Relay Contract 5) Issuer sees 1) Alice generates „unlock“ event Ethereum key pair 푒푡ℎ 6) Contract issues 푏푡푐푒푡ℎ and 5) Alice publishes 푇푒푡ℎ 3) Bob publishes 푇푏푢푟푛 in which he marks his 푒푡ℎ 푒푡ℎ 푒푡ℎ 푤𝑖푡 ℎ푑푟푎푤 푒푡ℎ 푝푘 푝푘 푝푘퐴 푝푘퐵 푒푡ℎ 푏푡푐 푒푡ℎ 퐴 declares Alice as owner 퐼 withdrawing 푒푡ℎ 푝푘퐵 푏푡푐푒푡ℎ for redemption and provides 푇푟푒푑푒푒푚 푝푘퐼

푒푡ℎ 푏푡푐 3) Alice publishes 푇푝푟표표푓 , submitting 푇푙표푐푘 for 푒푡ℎ 2) Alice publishes 푇표푓푓푒푟 , which invokes the token verification to the chain relay functionality of the transfer in the treasury contract. 푏푡푐 contract 2) Bob creates and signs 푇푟푒푑푒푒푚 , which pays him the correct amount of btc from the multisig 푏푡푐 1) Alice creates and signs 푇푙표푐푘 (퐵퐼), which ALICE ISSUER ALICE BOB BOB 1) Bob generates ISSUER replaces herself by Bob in the multisig lock Bitcoin key pair

푏푡푐 푏푡푐 푏푡푐 푏푡푐 푏푡푐 푏푡푐 푝푘퐴 푝푘퐼 푝푘퐴 푝푘퐵 푝푘퐵 푝푘퐼

2) Alice publishes 푇푥푏푡푐 which locks btc in a multisig with Issuer signs and publishes 푇푥푏푡푐 spending 푙표푐푘 (퐴퐼) Result: Bob replaces Alice in a new mutilsig with the Issuer, spending from the old 6) 푟푒푑푒푒푚 (퐵퐼) the Issuer 푏푡푐 Bitcoin Bitcoin multisig output. State not yet updated publicly. Bitcoin from 푇푥푙표푐푘 (퐵퐼) paying Bob the correct amount of btc