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
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8E46F415
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <decker.christian@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <m5Ua4d2y8oTgZSOxMUZiWJHunZpA1_mShgxNAGaEL5IGr4toYhuj-7ls7FQDKhidiYwbCaZf171_74eVXaNvlOyIQIW30maAQB3kdp8vNGk=@protonmail.com>
In-Reply-To: <87vac3fzje.fsf@gmail.com>
References: <871sewirni.fsf@gmail.com>
<CAMZUoK=V9Dii7ja6n6mpW_tWt00PuT=-9Z8XoyKOY3y0_AwK5w@mail.gmail.com>
<877eongu33.fsf@gmail.com>
<qFwv4IxuQlev23nK6hMyrDz231PXkGTBGZvaa3VAQs-32VcpjR18bsKQEioxOuauD9tDCUap2DlBGbr9QD0OC9-w_55tbo25P1BjK75Xj30=@protonmail.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 <bitcoin-dev@lists.linuxfoundation.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 <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: 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
|
