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 AF58A10E9 for ; Wed, 26 Sep 2018 19:46:00 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender-of-o53.zoho.com (sender-of-o53.zoho.com [135.84.80.218]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1991A756 for ; Wed, 26 Sep 2018 19:45:59 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1537991157; cv=none; d=zoho.com; s=zohoarc; b=oTNZg84DHeJTWC7DVoPe62vkxg8nIhmF1iy+aY8SG1oTVzr0lSud2h0hoWIjL5QU6Os9woC20d1bgWkhMk5Ph+zGoIxQZwbFG5M72gHHfG/Fsacu1ExYFWR3jlZ0aMdzWC5/nlLgtSht64Kz1cqiiREx1UIO3CnhqVARf7EsiNM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1537991157; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=/9G8G5PMSzxJ4seLGxaPLY6So7fV21zlcxG3X+Eg0nU=; b=Vddse6DbgxBFnXAnKw9EfUez+6kE51cQK4X7FcJ2kGVHzjmvbpAb4phwLwzi9odRmlpxZPfk1ywdwEwWj3sz22vHIiBe1rOGdsUIY0dxz7AbkjwP+w/Mi6WIzF6k4gwwZEvRInx6B1W6HUJ4m+oIXIZYsg/dm1ukVundxEXziBU= ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass header.i=xbt.hk; spf=pass smtp.mailfrom=jl2012@xbt.hk; dmarc=pass header.from= header.from= Received: from [10.8.0.103] (n218103136198.netvigator.com [218.103.136.198]) by mx.zohomail.com with SMTPS id 1537991154801179.20495452136674; Wed, 26 Sep 2018 12:45:54 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Johnson Lau In-Reply-To: Date: Thu, 27 Sep 2018 03:45:49 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <871sewirni.fsf@gmail.com> To: Jonas Nick , bitcoin-dev X-Mailer: Apple Mail (2.3445.8.2) X-ZohoMailClient: External X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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 X-Mailman-Approved-At: Wed, 26 Sep 2018 20:40:12 +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: Wed, 26 Sep 2018 19:46:00 -0000 In BIP143, the nSequence of the same input is always signed, with any = hashtype. Why do you need to sign the sequence of other inputs? > On 26 Sep 2018, at 5:36 PM, Jonas Nick via bitcoin-dev = wrote: >=20 >> At the risk of bikeshedding, shouldn't NOINPUT also zero out the >> hashSequence so that its behaviour is consistent with ANYONECANPAY? >=20 > There is a good reason for not doing that. If NOINPUT would sign the > hashSequence then it would be possible to get rid of OP_CSV in eltoo = update > scripts. As a result update scripts could be taprootified because the = more > common branch (settlement) would be just a 2-of-2 multisig. Applying = taproot > would then make unilateral settlement look like a single pubkey spend = and avoid > having to reveal the unexecuted (update) branch. >=20 > Eltoo update transaction outputs consist of two branches, update and > settlement, where the update branch can be spend by a more recent = update > transaction if an obsolete update transaction ends up spending the = funding > output. The settlement branch is a 2-of-2 multisig with a relative = timelock > using OP_CSV. Removing OP_CSV is possible because both parties = signature is > required to spend the update transaction. They will only sign if the = input has > the right sequence numbers which is sufficient to enforce the timeout = (BIP68) - > assuming they are covered by the signature. >=20 > There's a catch: hashSequence includes the sequence numbers of all = transaction > inputs. That's not a problem for eltoo because settlement transactions = only > have one input. The update mechanism with update transactions relies = on being > able to bump the fee by unilaterally adding inputs and and change = outputs to > the transaction. That's also not a problem because update spends do = not use > relative timelocks and they are signed with SINGLE. So whenever = NOINPUT is > combined SINGLE the hashSequence should be zeroed. This is in fact = what a > minimal change to the current NOINPUT implementation would naturally = do (see > below). However, that's error-prone when using NOINPUT in other = contexts so in > general it would be better if NOINPUT would only sign the sequence = number of > the corresponding input. >=20 > Another downside of this approach is that you can never rebind to an = output > with an OP_CSV that requires a larger sequence number, unless you also = sign > with SIGHASH_SINGLE. It's difficult to imagine application where this = would be > an issue. >=20 > This is the modification to the NOINPUT implementation > (https://github.com/cdecker/bitcoin/commits/noinput) which makes eltoo > unilateral closes taprootifiable: > +++ b/src/script/interpreter.cpp > @@ -1223,7 +1223,7 @@ uint256 SignatureHash(const CScript& scriptCode, = const CTransaction& txTo, unsig > hashPrevouts =3D cacheready ? cache->hashPrevouts : = GetPrevoutHash(txTo); > } >=20 > - if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) = !=3D SIGHASH_SINGLE && (nHashType & 0x1f) !=3D SIGHASH_NONE && !noinput) = { > + if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) = !=3D SIGHASH_SINGLE && (nHashType & 0x1f) !=3D SIGHASH_NONE) { > hashSequence =3D cacheready ? cache->hashSequence : = GetSequenceHash(txTo); > } >=20 > On 5/1/18 4:58 PM, Russell O'Connor via bitcoin-dev wrote: >> At the risk of bikeshedding, shouldn't NOINPUT also zero out the >> hashSequence so that its behaviour is consistent with ANYONECANPAY? >>=20 >=20