Zamyatin, A

English

Spiral - Imperial College Digital Repository

Poster Abstract: Multisignatures forCryptocurrency-Backed Tokens?Alexei Zamyatin1 Department of Computing, Imperial College London2 SBA Researcha.zamyatin@imperial.ac.ukDespite the influx of new cryptocurrencies and academic research on distributedledgers, communication between permissionless blockchains is mostly facilitated usingcentralized liquidity providers, or exchanges.Recently, XCLAIM, a protocol for issuing, trading and redeeming cryptocurrency-backed tokens was introduced as a mechanism for trustless blockchain interoperabilityby Zamyatin et al.[7]. Thereby, users lock units a of a backing cryptocurrency A, e.g.Bitcoin [5], with an non-trusted and collateralized third party (the Issuer) and create theequivalent amount of tokens ab on an issuing cryptocurrency B, e.g. Ethereum [4]. Toredeem ab for the corresponding amount of a on chain A, users must destroy or burnthe tokens in a publicly verifiable manner on chain B. The scheme leverages hashedtime-lock contracts [1] on the backing blockchain, as well as chain relays [6] (e.g. BTCRelay [2]), collateral and smart contracts on the issuing blockchain, i.e., requires (near)Turing complete programming capabilities on chain B. While the Issuer maintains fullcontrol of the locked cryptocurrency units a for the duration of the protocol, XCLAIMguarantees that in case of Byzantine or crash failures of the Issuer, the victims will bereimbursed the equivalent monetary value of their loss from the Issuer’s collateral onchain 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 unitsof 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 createand sign a transaction Treplace updating the state of the multisiganture and present it toboth 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 versionof 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 XCLAIMusing off-chain payment channels.? This works extends upon the recently introduced XCLAIM protocol for cryptocurrency-backed tokens [7].2 A. ZamyatinReferences1. 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 smart contract 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 ZamyatinTradeEthereumChain RelayTreasuryContract2) Bob creates and signs 𝑇𝑟𝑒𝑑𝑒𝑒𝑚𝑏𝑡𝑐 , which pays him the correct amount of btc from the multisig 6) Issuer signs and publishes 𝑇𝑥𝑟𝑒𝑑𝑒𝑒𝑚 (𝐵𝐼)𝑏𝑡𝑐  spending from 𝑇𝑥𝑙𝑜𝑐𝑘 (𝐵𝐼)𝑏𝑡𝑐  paying Bob the correct amount of btc  4) The contract burns the 𝑏𝑡𝑐𝑒𝑡ℎ  and emits an “unlock” event BOB ISSUER3) Bob publishes 𝑇𝑏𝑢𝑟𝑛𝑒𝑡ℎ  in which he marks his 𝑏𝑡𝑐𝑒𝑡ℎ  for redemption and provides 𝑇𝑟𝑒𝑑𝑒𝑒𝑚𝑏𝑡𝑐   𝑝𝑘𝐼𝑏𝑡𝑐   𝑝𝑘𝐵𝑏𝑡𝑐   𝑝𝑘𝐼𝑒𝑡ℎ  𝑝𝑘𝐵𝑒𝑡ℎ  1) Bob generates Bitcoin key pair 5) Issuer sees „unlock“ eventXXXEthereumBitcoinChain RelayTreasuryContractResult: Bob replaces Alice in a new mutilsig with the Issuer, spending from the old multisig output. State not yet updated publicly. 4) Contract makes Bob owner of 𝑏𝑡𝑐𝑒𝑡ℎ  and allows Alice to withdraw the locked eth ALICE BOB5) Alice publishes 𝑇𝑤𝑖𝑡 ℎ𝑑𝑟𝑎𝑤𝑒𝑡ℎ  withdrawing 𝑒𝑡ℎ  𝑝𝑘𝐵𝑏𝑡𝑐   𝑝𝑘𝐴𝑏𝑡𝑐   𝑝𝑘𝐵𝑒𝑡ℎ  𝑝𝑘𝐴𝑒𝑡ℎ   1) Alice creates and signs 𝑇𝑙𝑜𝑐𝑘 (𝐵𝐼)𝑏𝑡𝑐 , which replaces herself by Bob in the multisig lock 2) Alice publishes 𝑇𝑜𝑓𝑓𝑒𝑟𝑒𝑡ℎ , which invokes the token transfer in the treasury contract. 3) Bob publishes 𝑇𝑡𝑟𝑎𝑑𝑒𝑒𝑡ℎ , locking 𝑒𝑡ℎ  in the treasury  EthereumBitcoinChain RelayTreasuryContract3) Alice publishes 𝑇𝑝𝑟𝑜𝑜𝑓𝑒𝑡ℎ , submitting 𝑇𝑙𝑜𝑐𝑘𝑏𝑡𝑐  for verification to the chain relay functionality of the contract 2) Alice publishes 𝑇𝑥𝑙𝑜𝑐𝑘 (𝐴𝐼)𝑏𝑡𝑐  which locks btc in a multisig with the Issuer  4) The chain relay verifies 𝑇𝑙𝑜𝑐𝑘𝑏𝑡𝑐  is included in Bitcoin’s main chain for at least 𝑡𝑐𝑜𝑛𝑡𝑒𝑠𝑡  5) Confirms inclusion to treasury ALICE ISSUER6) Contract issues 𝑏𝑡𝑐𝑒𝑡ℎand declares Alice as owner  𝑝𝑘𝐼𝑏𝑡𝑐   𝑝𝑘𝐴𝑏𝑡𝑐   𝑝𝑘𝐼𝑒𝑡ℎ  𝑝𝑘𝐴𝑒𝑡ℎ  1) Alice generates Ethereum key pair Precond.: Issuer has collateral locked in treasuryRedeemIssueProtocols*An extension of the XCLAIM protocol. Scan QR-code to read the XCLAIM paperMultisignature Locks: Improving SafetyChallengesFungibility of tokes cannot be guaranteedSubstantial amount of data stored on EthereumFund freeze still possible!1.0 1.02.0+ vs.X+1.01.0Use Bitcoin 2-of-2 multisignatures to make theft by the Issuer impossibleMultisig LockProveConfirmIssueLockOptimizationsIssuer signs all TX only when token is redeemed(P2WSH - BIP141 Segregated Witness required)Reduce Waiting TimesReduce Costs / TransactionsUTXO grouping scheme:optimistic reduction of required TX to O(1). However: interactive protocol!(A, I)(A, I) (B, I)(C, I)(B, I)(D, I)1.01.01.0 0.70.32.0(A, I)(D, I) (B, I)0.31.02.0(C, I)0.7BTC transactions = 3BTC transactions = 1BUT: Requires additional signature from A!Improve Incentives against fund freezingAdditional collateral on Bitcoin:  |                                   XCLAIM: Cryptocurrency-backed TokensIn three steps to interoperability (E.g. Bitcoin-backed tokens on Ethereum)1) Lock with Issuer2) Prove lock to Chain relay3) Issue tokensstartCollateralized commitIssue abortedInsufficient collateralbtc locked in HTLCbtc locked with IssuerTrade tokensRedeem requestedbtc releasedRedeem failed, eth reimbursedToken StatesNONEPENDING ISSUEREIMBURSEDREDEEMEDPENDING REDEEMISSUEDISSUER(Non-trusted & collateralized 3rd party)h7 = H(h5,h6)h5 = H(h1,h2) h6 = H(h3,h4)h4h3h2LOCK TXChain relay verifies TX inclusion proof and informs treasuryTreasury contract issues Bitcoin-backed ERC20 tokensBitcoin

Poster Abstract: Multisignatures for cryptocurrency-backed tokens

http://spiral.imperial.ac.uk/bitstream/10044/1/64063/2/multisignatures-poster-abstract-pre-print.pdf

Poster Abstract: Multisignatures for cryptocurrency-backed tokens

Abstract

Similar works

Full text

Available Versions

Spiral - Imperial College Digital Repository