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 8E46F415 for ; Fri, 4 May 2018 14:25:56 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-1857040132.protonmail.ch (mail-1857040132.protonmail.ch [185.70.40.132]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6C511F8 for ; Fri, 4 May 2018 14:25:55 +0000 (UTC) Date: Fri, 04 May 2018 10:25:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1525443950; bh=YXYiqOhYGEwZ15fJQiWbz1eKQiIbzC94KqVo9TA9wlQ=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=QfDE5ukCh5XNCGHrrxOn7SpiI9lwTP39YsXUT9aI6JIiRCbrAtFjqk6oxGUCGfwWQ 81F2IJcDhLpVQAf62aBytt54peFqiIwNcXfdgi3AeizRPNoTU8nld0+quX5OsE42JU R+7v3rIp+o3Z2s2nhjWHZY3pZzZMrOOOgLmTY7mk= To: Christian Decker From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <87vac3fzje.fsf@gmail.com> References: <871sewirni.fsf@gmail.com> <877eongu33.fsf@gmail.com> <87vac3fzje.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=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL 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 14:27:17 +0000 Cc: Bitcoin Protocol Discussion 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 14:25:56 -0000 Good morning Christian, > ZmnSCPxj ZmnSCPxj@protonmail.com writes: >=20 > > It seems to me, that `SIGHASH_NOINPUT` may help make some protocol > >=20 > > integrate better with existing wallets. >=20 > Depends on which end of a transaction the existing wallet is: existing >=20 > wallets will refuse to sign a transaction with an unknown sighash flag, >=20 > but if the wallet is creating the output that'll later be spent using a >=20 > `SIGHASH_NOINPUT` transaction it won't (and shouldn't) care. > Yes, the intent is that specialized utilities (like the CoinSwap I gave as = an example) would be the ones signing with `SIGHASH_NOINPUT`, with the exis= ting wallet generating the output that will be spent with a `SIGHASH_NOINPU= T`. The issue is that some trustless protocols have an offchain component, wher= e some kind of backoff transaction is created, and the creation involves th= e 3 steps (1) make but do not sign&broadcast a funding tx (2) make and sign= a backoff transaction that spends the funding tx (3) sign and broadcast th= e original funding tx. This holds for Poon-Dryja, your new eltoo Decker-Rus= sell-Osuntokun, and CoinSwap. Commodity user wallets and exchange wallets = only support the most basic "make tx, sign, broadcast", and integrating wit= h the generalized funding transaction pattern is not possible. `SIGHASH_NO= INPUT` allows us to make the backoff transaction first, then make the fundi= ng transaction via the usual "make tx, sign, broadcast" procedure that comm= odity wallets implement. > > A drawback of course, is that `SIGHASH_NOINPUT` is an unusual flag to > >=20 > > use; it immediately paints the user as using some special protocol. > >=20 > > So much for `SIGHASH_NOINPUT` CoinSwap. >=20 > By providing a new use-case you are contributing to the obfuscation of >=20 > this technique. The more normal the use of `SIGHASH_NOINPUT` becomes the >=20 > less an observer can learn from it being used. In combination with MAST, >=20 > Taproot or Graftroot we can further hide the details of the executed >=20 > protocol :-) Thinking about it further, it turns out that in the cooperative completion = of the protocol, we do not need to sign anything using `SIGHASH_NOINPUT`, b= ut can use the typical `SIGHASH_ALL`. Indeed all generalized funding transa= ction patterns can be updated to use this: only the initial backout transac= tion needs to be signed with `SIGHASH_NOINPUT`, all others can be signed wi= th `SIGHASH_ALL`, including the protocol conclusion transaction. 1. In CoinSwapCS, TX-0 and TX-1 are funding transactions. The backoff tra= nsaction is the TX-2 and TX-3 transactions. Only TX-2 and TX-3 need be sig= ned with `SIGHASH_NOINPUT`. TX-4 and TX-5, which complete the protocol and= hide the swap, can be signed with `SIGHASH_ALL`. 2. In Poon-Dryja, the backoff transaction is the very first commitment tra= nsaction. Again only that transaction needs to be signed with `SIGHASH_NOI= NPUT`: future commitment transactions as well as the mutual close transacti= on can be signed with `SIGHASH_ALL`. 3. In Decker-Russell-Osuntokun, the backoff transaction is the trigger tra= nsaction and the first settlement transaction. The trigger transaction can= sign with `SIGHASH_NOINPUT`. Then only the final settlement (i.e. mutual = close) can be signed with `SIGHASH_ALL`. Thus if the protocol completes cooperatively, the only onchain evidence is = that a 2-of-2 multisig is spent, and signed using `SIGHASH_ALL`, and the mo= ney goes to some ordinary P2WPKH addresses. The advantage, as I mentioned, is that these protocols can be implemented u= sing "walletless" software: the special protocol software runs the protocol= up to the point that they get the backoff transaction, then asks the user = to pay an exact amount to an exact address. This has a number of advantage= s: 1. RBF can be supported if the wallet software supports RBF. In particula= r without `SIGHASH_NOINPUT` the protocol would require renegotiation of a n= ew backoff transaction in order to support RBF (and in particular the proto= col spec would need to be designed in the first place to consider that poss= ibility!), and would become more complicated since while a new backoff tran= saction is being negotiated, the previous version of the funding transactio= n may get confirmed. With `SIGHASH_NOINPUT` all the specialized protocol s= oftware needs to do, is to watch for a transaction paying to the given addr= ess to be confirmed deeply enough to be unlikely to be reorganized: there i= s no need to renegotiate a backoff transaction, because whatever transactio= n gets confirmed, as long as it pays to the address with a given amount, th= e signature for the backoff transaction remains valid for it. 2. Wallet software of any kind can be used in conjunction with special pro= tocol software of any kind. Hardware wallets do not need to implement LN: = the LN software starts a channel and gives a P2WSH address that hardware wa= llets know how to pay to. Ditto for exchange wallets. Etc. And if a futu= re protocol arises that uses the funding transaction pattern again, then ag= ain existing wallets can integrate with those protocols via P2WSH address. 3. Special protocol software need not implement even basic wallet function= ality: they can just focus on the specific protocol they implement. Consid= er how until late last year c-lightning needed a separate RPC command to in= form it that it received funds, and a few months ago we had many issues wit= h UTXOs in our database getting out of sync with the blockchain (why we imp= lemented `dev-rescan-outputs`). Regards. ZmnSCPxj