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
|
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 A76554A3;
Mon, 30 Apr 2018 17:29:00 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 100D45D3;
Mon, 30 Apr 2018 17:28:59 +0000 (UTC)
Received: by mail-wm0-f44.google.com with SMTP id x12so12187293wmc.0;
Mon, 30 Apr 2018 10:28:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:subject:date:message-id:mime-version;
bh=ky0ZW3ibgxKK26yl9wPsJABBKcZbAtiPEll7lFLeLk8=;
b=F0jTiU48mxE4ZREXL6WPLDqTSk5BmWIIQt3vaoWIamQhNAtppTQCCVLgMn5uvlApW4
U6y5W2fnQgEFU9YHMjAJno8olMxwkt1RIW3ha/HRurusF5F+s4ZFZpP8IOLkhtHQKKUn
+k08771m/TOPnwKzFwZvwRv5CczE6REAR/X/XESPTKkt2AjdpZ105LVcrJd/z9cf96Rb
XQI8RE2gWnNVyorYmoHO9WTB5Ba+bfcM5aezAV/BIiGwDvJVlgFQ9dq8BoEPKK5d0tiC
Un+QH+qEuwwj3pok3f7nSUxRecKSBpDEJJFqE4fITXrTvVh0AUFOLpqdeLv+V4i9bRgH
/Kng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:subject:date:message-id:mime-version;
bh=ky0ZW3ibgxKK26yl9wPsJABBKcZbAtiPEll7lFLeLk8=;
b=GoXrwEofLNMWjakDFO6BIqphDimoyvfOS/AfELQSrGzrECYnwwhSnO1cvxf4TVnNjR
EcClbMHzYvRIOrBzzwYm45CIozwQ7R4a+jogUYja15P1vyoE0azbYwU9CMf1aapUKQEx
OjubSuk3cjiuvd3nRDhIsWAf3mQMPXZ5pVpHUhofbE0nbHuv+dgMKhux+zUzeDrQKWuW
brrOAyn3wI3AFupcuuQhqoYKf4K+zvx2g3afQpNxTKMwc2XBFHiQITmj3mWRVDOlLtid
8qfdh7/8YWs6m57WwJx6hXpEXZKqekdoZCEcEdMfGnLl5QByV5yPvYiLiGW//pr7GF+M
GIiA==
X-Gm-Message-State: ALQs6tAh+75aqSUfMfTObxCkWM3ICLX/sFEdw38fR8Cl6VoorjgyCcMs
hiuOMc2YqslXKjWggaGe5JIxbcrw
X-Google-Smtp-Source: AB8JxZpHLs2kitwO7z2V45upENANa91eKubE0BRusJg5GDl9s2z5nV7qu/8zo6Ew+q/yw3mf+4Wy1g==
X-Received: by 10.28.128.14 with SMTP id b14mr8370723wmd.143.1525109338351;
Mon, 30 Apr 2018 10:28:58 -0700 (PDT)
Received: from localhost ([2a02:aa16:1102:5480:e99:3f63:40a2:83e9])
by smtp.gmail.com with ESMTPSA id
b185sm7698881wmb.25.2018.04.30.10.28.57
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 30 Apr 2018 10:28:57 -0700 (PDT)
From: Christian Decker <decker.christian@gmail.com>
To: lightning-dev@lists.linuxfoundation.org,
bitcoin-dev@lists.linuxfoundation.org
Date: Mon, 30 Apr 2018 18:29:53 +0200
Message-ID: <871sewirni.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: [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: Mon, 30 Apr 2018 17:29:00 -0000
Hi all,
I'd like to pick up the discussion from a few months ago, and propose a new
sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the previous
output. This was previously mentioned on the list by Joseph Poon [1], but was
never formally proposed, so I wrote a proposal [2].
We have long known that `SIGHASH_NOINPUT` would be a great fit for Lightning.
They enable simple watch-towers, i.e., outsource the need to watch the
blockchain for channel closures, and react appropriately if our counterparty
misbehaves. In addition to this we just released the eltoo [3,4] paper which
describes a simplified update mechanism that can be used in Lightning, and other
off-chain contracts, with any number of participants.
By not committing to the previous output being spent by the transaction, we can
rebind an input to point to any outpoint with a matching output script and
value. The binding therefore is no longer explicit through a reference, but
through script compatibility, and the transaction ID reference in the input is a
hint to validators. The sighash flag is meant to enable some off-chain use-cases
and should not be used unless the tradeoffs are well-known. In particular we
suggest using contract specific key-pairs, in order to avoid having any unwanted
rebinding opportunities.
The proposal is very minimalistic, and simple. However, there are a few things
where we'd like to hear the input of the wider community with regards to the
implementation details though. We had some discussions internally on whether to
use a separate opcode or a sighash flag, some feeling that the sighash flag
could lead to some confusion with existing wallets, but given that we have
`SIGHASH_NONE`, and that existing wallets will not sign things with unknown
flags, we decided to go the sighash way. Another thing is that we still commit
to the amount of the outpoint being spent. The rationale behind this is that,
while rebinding to outpoints with the same value maintains the value
relationship between input and output, we will probably not want to bind to
something with a different value and suddenly pay a gigantic fee.
The deployment part of the proposal is left vague on purpose in order not to
collide with any other proposals. It should be possible to introduce it by
bumping the segwit script version and adding the new behavior.
I hope the proposal is well received, and I'm looking forward to discussing
variants and tradeoffs here. I think the applications we proposed so far are
quite interesting, and I'm sure there are many more we can enable with this
change.
Cheers,
Christian
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012460.html
[2] https://github.com/cdecker/bips/blob/noinput/bip-xyz.mediawiki
[3] https://blockstream.com/2018/04/30/eltoo-next-lightning.html
[4] https://blockstream.com/eltoo.pdf
|
