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
168
|
Return-Path: <decker.christian@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A353915
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 4 May 2018 11:09:19 +0000 (UTC)
Received: by mail-wr0-f181.google.com with SMTP id o2-v6so17748006wrj.13
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <decker.christian@gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <qFwv4IxuQlev23nK6hMyrDz231PXkGTBGZvaa3VAQs-32VcpjR18bsKQEioxOuauD9tDCUap2DlBGbr9QD0OC9-w_55tbo25P1BjK75Xj30=@protonmail.com>
References: <871sewirni.fsf@gmail.com>
<CAMZUoK=V9Dii7ja6n6mpW_tWt00PuT=-9Z8XoyKOY3y0_AwK5w@mail.gmail.com>
<877eongu33.fsf@gmail.com>
<qFwv4IxuQlev23nK6hMyrDz231PXkGTBGZvaa3VAQs-32VcpjR18bsKQEioxOuauD9tDCUap2DlBGbr9QD0OC9-w_55tbo25P1BjK75Xj30=@protonmail.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 <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 11:09:20 -0000
ZmnSCPxj <ZmnSCPxj@protonmail.com> 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 :-)
|
