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
|
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 D1A772C
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 4 May 2018 09:15:52 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail3.protonmail.ch (mail3.protonmail.ch [185.70.40.25])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C3629299
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 4 May 2018 09:15:50 +0000 (UTC)
Date: Fri, 04 May 2018 05:15:41 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1525425348;
bh=msHIB+Kf6ZB+1GoX/IIIBQ4ItIxPNeRsd4YwyjifbmA=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=ECo6v0Knzgj8LhFKJ4O+TqPyBU2qhVeOgyuJ1ZKhD4T9YTQs9pfizGDAxrdKnmLPH
4NGKmD3H4b64pr/hWQUbw2AFe17UH2eH0cfs/SaIyv2rAtGqEFzYF+7c/2OPn32VbK
kHFmOWpOm9FYSd0pMY081if3ScsQtpQZQrAzflG4=
To: Christian Decker <decker.christian@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <qFwv4IxuQlev23nK6hMyrDz231PXkGTBGZvaa3VAQs-32VcpjR18bsKQEioxOuauD9tDCUap2DlBGbr9QD0OC9-w_55tbo25P1BjK75Xj30=@protonmail.com>
In-Reply-To: <877eongu33.fsf@gmail.com>
References: <871sewirni.fsf@gmail.com>
<CAMZUoK=V9Dii7ja6n6mpW_tWt00PuT=-9Z8XoyKOY3y0_AwK5w@mail.gmail.com>
<877eongu33.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=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
RCVD_IN_DNSWL_LOW 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 11:37:07 +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: Fri, 04 May 2018 09:15:53 -0000
Good morning Christian and list,
It seems to me, that `SIGHASH_NOINPUT` may help make some protocol integrat=
e better with existing wallets.
I remember vaguely that `SIGHASH_NOINPUT` was also mentioned before in LN d=
iscussions, 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.
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 s=
igns 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 o=
ut is signed before all parties enter into the contract).
Now, without `SIGHASH_NOINPUT`, we would first require that the initial fun=
ding transaction be written (but not signed and broadcast), and then the tx=
id to the other side. The other side then generates the backout transactio=
n (which requires the txid and outnum of the funding outpoint) and returns =
the signature for the backout transaction to the first side.
Because of this, an implementation of CoinSwap needs to have control of its=
own coins. This means that coin selection, blockchain tracking, and mempo=
ol tracking (i.e. to handle RBFs, which would invalidate any further transa=
ctions if you used coins received by RBF-able transactions while unconfirme=
d) needs to be implemented.
But it would be much nicer if instead the CoinSwap implementation could sim=
ply say "okay, I started our CoinSwap, now send X coins to address A", and =
then the user uses their ordinary wallet software to send to that address (=
obviously before the CoinSwap can start, the user must first provide an add=
ress to which the backoff transaction should pay; but in fact that could si=
mply be the same as the other address in the swap).
1. The user will not have to make a separate transfer from their wallet, t=
hen initiate a swap, then transfer from the CoinSwap implementation to thei=
r usual wallet: instead the user gets an address from their wallet, initiat=
es the swap, then pays to the address the CoinSwap implementation said to p=
ay and wait to receive the swapped funds to their normal wallet.
2. Implementing the CoinSwap program is now somewhat easier since we do no=
t need to manage our own funds: the software only needs to manage the singl=
e particular coin that was paid to the single address being used in the swa=
p.
3. The smaller number of required features for use means easier implementa=
tion and testing. It also makes it more likely to be implemented in the fi=
rst place, since the effort to make it is smaller.
4. The lack of a wallet means users can use a trusted wallet implementatio=
n (cold storage, hardware wallet, etc) in conjunction with the software, an=
d only risk the amount that passes through the CoinSwap software (which is =
smaller, since it does not have to include any extra funds to pay for fees)=
.
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 signat=
ure with `SIGHASH_NOINPUT` flag.
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 mov=
e 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 a=
ddress 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 initi=
ate the swap using their normal wallet software, the CoinSwap software moni=
tors only the address it asked the user to use, then when it appears onchai=
n (the CoinSwap software does not even need to track the mempool) it contin=
ues with the HTLC offers and preimage exchanges until the protocol complete=
s.
In a world where walletless CoinSwap exists, consider this:
1. A user buys Bitcoin from an exchange. The exchange operates a wallet w=
hich they credit when the user buys Bitcoin.
2. The user starts a CoinSwap, giving the destination address from their c=
old-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 ap=
pear 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 implementa=
tion wallet (1 transaction).
3. The user performs a CoinSwap which goes back to the CoinSwap implementa=
tion wallet (2 transactions).
4. The user sends from the CoinSwap wallet to their cold storage (1 transa=
ction). (granted, the CoinSwap implementation could offer a feature that im=
mediately transfers the swapped funds to some other wallet, but we still ca=
nnot 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.
Regards,
ZmnSCPxj
|
