1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id AF58A10E9
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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=<jl2012@xbt.hk> header.from=<jl2012@xbt.hk>
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 <jl2012@xbt.hk>
In-Reply-To: <feff454d-2cc2-2104-5c6c-69630506bd56@gmail.com>
Date: Thu, 27 Sep 2018 03:45:49 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <D3D0114C-0D5C-4EE4-AD48-B046551BAAD4@xbt.hk>
References: <871sewirni.fsf@gmail.com>
<CAMZUoK=V9Dii7ja6n6mpW_tWt00PuT=-9Z8XoyKOY3y0_AwK5w@mail.gmail.com>
<feff454d-2cc2-2104-5c6c-69630506bd56@gmail.com>
To: Jonas Nick <jonasdnick@gmail.com>,
bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 =
<bitcoin-dev@lists.linuxfoundation.org> 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
|
