From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D1A772C for ; Fri, 4 May 2018 09:15:52 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail3.protonmail.ch (mail3.protonmail.ch [185.70.40.25]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C3629299 for ; Fri, 4 May 2018 09:15:50 +0000 (UTC) Date: Fri, 04 May 2018 05:15:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1525425348; bh=msHIB+Kf6ZB+1GoX/IIIBQ4ItIxPNeRsd4YwyjifbmA=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=ECo6v0Knzgj8LhFKJ4O+TqPyBU2qhVeOgyuJ1ZKhD4T9YTQs9pfizGDAxrdKnmLPH 4NGKmD3H4b64pr/hWQUbw2AFe17UH2eH0cfs/SaIyv2rAtGqEFzYF+7c/2OPn32VbK kHFmOWpOm9FYSd0pMY081if3ScsQtpQZQrAzflG4= To: Christian Decker , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <877eongu33.fsf@gmail.com> References: <871sewirni.fsf@gmail.com> <877eongu33.fsf@gmail.com> Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 04 May 2018 11:37:07 +0000 Subject: Re: [bitcoin-dev] BIP sighash_noinput X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 09:15:53 -0000 Good morning Christian and list, It seems to me, that `SIGHASH_NOINPUT` may help make some protocol integrat= e better with existing wallets. I remember vaguely that `SIGHASH_NOINPUT` was also mentioned before in LN d= iscussions, when the issue of transaction malleation was considered (before= SegWit, being totally uncontroversial, was massively adopted). The sketch= below, I believe, is somewhat consistent with how it could have been used = in funding a channel. Consider a CoinSwap protocol. Each side writes a transaction that pays out= to an ordinary 2-of-2 multisig address. But before each side writes and s= igns that transaction, it first demands a timelocked backout transaction to= let them recover their own funds in case it falls through (more generally,= every offchain protocol has a similar setup stage where some way to back o= ut is signed before all parties enter into the contract). Now, without `SIGHASH_NOINPUT`, we would first require that the initial fun= ding transaction be written (but not signed and broadcast), and then the tx= id to the other side. The other side then generates the backout transactio= n (which requires the txid and outnum of the funding outpoint) and returns = the signature for the backout transaction to the first side. Because of this, an implementation of CoinSwap needs to have control of its= own coins. This means that coin selection, blockchain tracking, and mempo= ol tracking (i.e. to handle RBFs, which would invalidate any further transa= ctions if you used coins received by RBF-able transactions while unconfirme= d) needs to be implemented. But it would be much nicer if instead the CoinSwap implementation could sim= ply say "okay, I started our CoinSwap, now send X coins to address A", and = then the user uses their ordinary wallet software to send to that address (= obviously before the CoinSwap can start, the user must first provide an add= ress to which the backoff transaction should pay; but in fact that could si= mply be the same as the other address in the swap). 1. The user will not have to make a separate transfer from their wallet, t= hen initiate a swap, then transfer from the CoinSwap implementation to thei= r usual wallet: instead the user gets an address from their wallet, initiat= es the swap, then pays to the address the CoinSwap implementation said to p= ay and wait to receive the swapped funds to their normal wallet. 2. Implementing the CoinSwap program is now somewhat easier since we do no= t need to manage our own funds: the software only needs to manage the singl= e particular coin that was paid to the single address being used in the swa= p. 3. The smaller number of required features for use means easier implementa= tion and testing. It also makes it more likely to be implemented in the fi= rst place, since the effort to make it is smaller. 4. The lack of a wallet means users can use a trusted wallet implementatio= n (cold storage, hardware wallet, etc) in conjunction with the software, an= d only risk the amount that passes through the CoinSwap software (which is = smaller, since it does not have to include any extra funds to pay for fees)= . With `SIGHASH_NOINPUT`, we can indeed implement such a walletless CoinSwap = (or other protocol) software. We only need to provide the public keys that= will be used in the initial 2-of-2, and the other side can create a signat= ure with `SIGHASH_NOINPUT` flag. The setup of the CoinSwap then goes this way. The swapping nodes exchange = public keys (two for each side in this case), they agree on who gets to mov= e first in the swap and who generates the preimage, and then they agree on = what the backout transactions look like (in particular, they agree on the a= ddress the backout transactions spend) and create signatures, with `SIGHASH= _NOINPUT`. In particular, the signatures do not commit to the txid of the = transaction that they authorize spending. The CoinSwap sofwares then turn = around to their users and say "okay, send to this address", the users initi= ate the swap using their normal wallet software, the CoinSwap software moni= tors only the address it asked the user to use, then when it appears onchai= n (the CoinSwap software does not even need to track the mempool) it contin= ues with the HTLC offers and preimage exchanges until the protocol complete= s. In a world where walletless CoinSwap exists, consider this: 1. A user buys Bitcoin from an exchange. The exchange operates a wallet w= hich they credit when the user buys Bitcoin. 2. The user starts a CoinSwap, giving the destination address from their c= old-storage wallet. 3. The CoinSwap tells the user an address to send to. The user withdraws = money from the exchange using that address as destination (1 transaction) 4. The user waits for the CoinSwap to finish, which causes the funds to ap= pear in their cold-storage wallet (1 transaction). If CoinSwap implementations all needed their own wallets, then instead: 1. A user buys Bitcoin from an exchange. 2. The user withdraws the funds from the exchange to a CoinSwap implementa= tion wallet (1 transaction). 3. The user performs a CoinSwap which goes back to the CoinSwap implementa= tion wallet (2 transactions). 4. The user sends from the CoinSwap wallet to their cold storage (1 transa= ction). (granted, the CoinSwap implementation could offer a feature that im= mediately transfers the swapped funds to some other wallet, but we still ca= nnot get around the transfer from the exchange to the CoinSwap wallet) A drawback of course, is that `SIGHASH_NOINPUT` is an unusual flag to use; = it immediately paints the user as using some special protocol. So much for= `SIGHASH_NOINPUT` CoinSwap. Regards, ZmnSCPxj