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 A353915 for ; Fri, 4 May 2018 11:09:20 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr0-f181.google.com (mail-wr0-f181.google.com [209.85.128.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 98435F8 for ; Fri, 4 May 2018 11:09:19 +0000 (UTC) Received: by mail-wr0-f181.google.com with SMTP id o2-v6so17748006wrj.13 for ; Fri, 04 May 2018 04:09:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=ZYAy04m5dkB13CK5826CO81FE2CxyAS9d7BTG9bEU8w=; b=kNuRUnLkF2IoQD7NF4LtwLRzcw0VpZROubQgo+aN+5jr32eeH5PEnHSefGzphElGXo SZxL8VVCfpS1B3FCTX+qY1M4FgdWIAG+YK5V1ZP/GI4bOqu9OLEvT2O5SO1GLhBXwBCu acJqRPsV9HQu4HpbFOdU4hHoV9HOLbAQqp4RSGWvzCyxnNiOVOEgadhdiIoC/6cCYwhS f/z4/g/uoKK434CQHinBwcE04gvmlapX6xzuMo+kktzVuSOkHva1Qr0tzFSCjqddTcFU izVDKX1KVcVrbO+/Az93qO+R9stCMMLzWHdoMODlP0rOBO+pHGuVekbT2bZ8IGnbjnSg 1aRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=ZYAy04m5dkB13CK5826CO81FE2CxyAS9d7BTG9bEU8w=; b=fghYt82lUnFzDnpalgxHUDH34jtsRay0RY/W90rGhMGKSBcAawAnOy3WXoMjGHjXkr mMG7jQS9yle+E0DNYdAWXqfN3OINktwEVp/jvzPl7JQESCz8YlwWsQTYpjYQxwXlO0vu 12oEdKgk36fqnvy5+ETxcJt3UrRf1U9IteILGyL3VJk4zgl5iThR/uCxEcLTW9Ac8OW0 R80q3qPhrrOZc8+bpfM2JlXlpEBvMy/QIUP7l5Yj1IX9lrLMY8ws66Kjr/MQ4r4atfvW DRJjFFmD/rvViTfnptFgoWtj+Z6GnsChkeIUGAR+koVVJ5dnGGt0V97biIDBmQLrMyAa xg2g== X-Gm-Message-State: ALQs6tD5ovQXcrUPCLPu9sLQc1//nHZAsiCKLaX6576N4NkXcv4uG20j cHo4AbMfeVAaYR5iwcgWUNA= X-Google-Smtp-Source: AB8JxZprVBJL3YVC6rA8U4ga9Wt5MSUJEn0hLQf3FIzwxsMfb8pJrONqHjUTjn9Mzr9FxQC3RBiIQA== X-Received: by 2002:adf:db0b:: with SMTP id s11-v6mr20137363wri.241.1525432158070; Fri, 04 May 2018 04:09:18 -0700 (PDT) Received: from localhost ([2a02:aa16:1102:5480:e99:3f63:40a2:83e9]) by smtp.gmail.com with ESMTPSA id e50-v6sm41245711wre.4.2018.05.04.04.09.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 May 2018 04:09:16 -0700 (PDT) From: Christian Decker To: ZmnSCPxj , Bitcoin Protocol Discussion In-Reply-To: References: <871sewirni.fsf@gmail.com> <877eongu33.fsf@gmail.com> Date: Fri, 04 May 2018 13:09:09 +0200 Message-ID: <87vac3fzje.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org 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 11:09:20 -0000 ZmnSCPxj writes: > It seems to me, that `SIGHASH_NOINPUT` may help make some protocol > integrate better with existing wallets. Depends on which end of a transaction the existing wallet is: existing wallets will refuse to sign a transaction with an unknown sighash flag, but if the wallet is creating the output that'll later be spent using a `SIGHASH_NOINPUT` transaction it won't (and shouldn't) care. > I remember vaguely that `SIGHASH_NOINPUT` was also mentioned before in > LN discussions, 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. I consider `SIGHASH_NOINPUT` to be a poor-man's malleability fix, since it comes with some baggage. Without trying to undermine my own proposal, but address reuse in combination with binding through script, can lead to very unexpected results. You need to be very careful about where you allow rebinding, hence the warnings in the proposal. > 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 signs 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 out is signed before all parties > enter into the contract). > > ... > > 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 signature with `SIGHASH_NOINPUT` flag. I was wondering whether we could actually skip one communication round w.r.t. the previously described CoinSwap protocol, but it turns out we need to at least exchange public keys before actually moving any funds. Would have been nice to do spontaneous CoinSwaps. > 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 move 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 address 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 initiate the > swap using their normal wallet software, the CoinSwap software > monitors only the address it asked the user to use, then when it > appears onchain (the CoinSwap software does not even need to track the > mempool) it continues with the HTLC offers and preimage exchanges > until the protocol completes. > > In a world where walletless CoinSwap exists, consider this: > > 1. A user buys Bitcoin from an exchange. The exchange operates a > wallet which they credit when the user buys Bitcoin. > 2. The user starts a CoinSwap, giving the destination address from > their cold-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 appear 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 > implementation wallet (1 transaction). > 3. The user performs a CoinSwap which goes back to the CoinSwap > implementation wallet (2 transactions). > 4. The user sends from the CoinSwap wallet to their cold storage (1 > transaction). (granted, the CoinSwap implementation could offer a > feature that immediately transfers the swapped funds to some other > wallet, but we still cannot 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. By providing a new use-case you are contributing to the obfuscation of this technique. The more normal the use of `SIGHASH_NOINPUT` becomes the less an observer can learn from it being used. In combination with MAST, Taproot or Graftroot we can further hide the details of the executed protocol :-)