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
|
Return-Path: <joseph@lightning.network>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 08284C4C
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 Feb 2016 01:08:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com
[209.85.220.50])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 86D1215B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 Feb 2016 01:08:29 +0000 (UTC)
Received: by mail-pa0-f50.google.com with SMTP id fl4so41367296pad.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 Feb 2016 17:08:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=lightning.network; s=google;
h=date:from:to:subject:message-id:mime-version:content-type
:content-disposition;
bh=ioMl5Ml7imfFw5NLA/Sy4dvSFNRbZ+TK4EoCsu6YuB8=;
b=WLud7ipmKoWcqEBbumD/yzfabdUTwqGAcQ00l7aUIOWpICk+O+btZ8i61pzEhZN5Sv
L5c65OspxbrU+iVlppr1xGLTmZPw54PeC1Ls4XEa1J6qbYdkbYuQirsP3oyDJvljg8pU
0KRr1DQjHSeSg3VjXmaUxC5eLxkbn2CkwvdtA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:date:from:to:subject:message-id:mime-version
:content-type:content-disposition;
bh=ioMl5Ml7imfFw5NLA/Sy4dvSFNRbZ+TK4EoCsu6YuB8=;
b=K/Qq2J961d2Sk9OKN81X95G9bT/nt91+srcu2CGOwHfbHF/o1GGFJsi/g8yoHkjTk4
3iJTV8tdZkzFh/hgWXQ0SN6rsugZT6p5tF9r5Z77eGRkgcWN/zp4WjPmLW01NFpR5ahS
fk6aSbLuLTUt8cUfm4tzm2GT5wBcZ+vnroF4l/a4ZmcGX2lSoTjYg8Deo86SyZ2ou0U8
PRxRNGl32wKIIGDvDjdC0pIlBp5PCoobCjUHQ3/O+p26rDc7chNLU18+/cYR9UFOjLMY
CS+OUbBxOWAQxwNxmHxavaEweNKwklHo0LUw/Jh6k4GHIJJtLw+SkDyfg00rD2j8a7Fe
Hoxw==
X-Gm-Message-State: AG10YOSAVRPmbIUEX9yfuCJ8B0iAqptQx7o+CpwP8YiSgkR2DaOKIwaiMpGtLTRbtaWFhg==
X-Received: by 10.66.62.169 with SMTP id z9mr10561089par.139.1456448909132;
Thu, 25 Feb 2016 17:08:29 -0800 (PST)
Received: from localhost ([2605:6400:20:11aa:189e:28a5:52ed:8948])
by smtp.gmail.com with ESMTPSA id
ti6sm14830856pab.4.2016.02.25.17.08.28
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLSv1/SSLv3 cipher=OTHER);
Thu, 25 Feb 2016 17:08:28 -0800 (PST)
Date: Thu, 25 Feb 2016 17:07:46 -0800
From: Joseph Poon <joseph@lightning.network>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20160226010746.GB10295@lightning.network>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU 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, 26 Feb 2016 01:18:40 +0000
Subject: [bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 26 Feb 2016 01:08:30 -0000
As Segregated Witness will be merged soon as a solution for transaction
malleability, especially with multi-party adversarial signatures, there
may be an additional use case/functionality which is helpful for
Lightning Network and possibly other Bitcoin use cases. This requires a
new SIGHASH flag inside Segregated Witness which does not sign the input
txid/index.
Segwit is very helpful in resolving malleability in pretty much every
case which matters. It is especially helpful in having solid and safe
defaults for standard Bitcoin payments; it's very difficult to mess up
if you are writing code in conjunction with the Bitcoin RPC API.
However, it is very useful for LN if there is a certain level of
outsourcibility for transactions without this 3rd party taking on
onerous costs. In LN, there is a dispute resolution period established
to prevent the counterparty from attesting an incorrect channel state
(represented by broadcasting a timelocked transaction). In other words,
if someone in a channel broadcasts an incorrect state, the output can be
redeemed by a 3rd party (but this 3rd party is not a custodian, since
the output goes to the other party in the channel).
Ideally, a 3rd-party can be handed a transaction which can encompass all
prior states in a compact way. For currently-designed Segregated Witness
transactions, this requires storing all previous signatures, which can
become very costly if individuals to thousands of channel state updates
per day. This is very possible, as fees are near-zero, the value in
atomizing all payments to many transactions becomes viable (reducing
transaction/information costs). If individuals are doing tens of
thousands of transactions per day, and one presumes something like
70-bytes of data per Commitment state in the channel, it quickly becomes
infeasible to watch on behalf of many channels without material costs.
This is especially necessary because it is highly desirable to make
keeping track of these channels be very cheap, as it allows for more
participants to be watching on one's behalf (reducing the chance of a
3rd party fail to watch). Further, it may reduce the need to notify the
3rd party for every single channel Commitment state, instead only
providing the most recent one should provide sufficient information for
all prior states (since the signature will apply for any type of
transaction), making the only updated information the revocation
secret/preimage. Without this SIGHASH flag, every single state would
need to be contacted and updated with 3rd parties. With this SIGHASH
flag, one could instead delegate outsourcing when one's client goes
offline with a single message several hundred bytes in size,
encompassing all prior states.
Of course, while running a 24/7 full-node is encouraged, I suspect many
people will not want to do so at the current time, and it needs to be
functional for those who elect to be connected intermittently. This
requires outsourcing or watching on one's behalf.
This would be achieved using a SIGHASH flag, termed SIGHASH_NOINPUT. It
does not include as part of the signature, the outpoint being spent
(txid and index), nor the amount. It however, would include the spent
outpoint's script as part of the signature. Note that this is just a
SIGHASH flag, and the outpoints are still being included as part of the
txins (if they are mutated, the new txids can be updated by the wallet
without resigning). This allows for a signature to apply to anything
with that pubkey (therefore pubkeys with this flag should not be
reused). For safety, this only applies in SegWit transactions, as segwit
provides a sufficient malleability solution, there is no incentive to
improperly use this sighash flag as a roundabout way to resolve
malleability.
This helps with 3rd-party outsourcing for watching the blockchain, as
one can provide a signature (and the most recent hash-chain of
revocation preimages), which encompasses penalty transactions for all
prior states. Functionally, this allows for opt-in wildcard inputs, but
wallets which do not require these transactions do not need to be
concerned with this flag; since they will never be signing with this
flag, they do not need to be concerned with address re-use.
I'm interested in input and in the level of receptiveness to this. If
there is interest, I'll write up a draft BIP in the next couple days.
--
Joseph Poon
|
