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
|
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 0AE02E2D;
Thu, 3 Oct 2019 03:08:06 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
[185.70.40.135])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1893019B;
Thu, 3 Oct 2019 03:08:05 +0000 (UTC)
Date: Thu, 03 Oct 2019 03:07:55 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1570072082;
bh=c1jwRu6M32Z/ioGrIp39YlIedrsqJxAXCElI/R5Rhfc=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=fJErJ1a2XVts1cbivDUr0Xzu5D54ttHJYz9m3vbGkxpGL+GNlZCxnRmGVt2ciYalu
oM1H2Lxz4hJhnZ1PZGP45865ZAc1V3YpwgpH+Ch6yqJkdgXWn7DbrRF2hrFTSkgjGF
3ybwMO7UpdK+/fqRmXGjXbtk/pvaTnrNL42spZG0=
To: Anthony Towns <aj@erisian.com.au>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <iKVHkY_BWc4A9e7AiuGiyYUAu9TM4yGNlTL7HQklrw6_1pW4ZpwRd-qKLox7jpmQ8QgWrj3Ovrq9sDQijMD3Q_dNivchgNfxy8zcchFYkQ4=@protonmail.com>
In-Reply-To: <20191003014758.gtgfge5yokcxkfsj@erisian.com.au>
References: <87wodp7w9f.fsf@gmail.com>
<20191001155929.e2yznsetqesx2jxo@erisian.com.au>
<CR-etCjXB-JWkvecjDog4Pkq1SuLUgndtSrZo-V4f4EGcNXzNCeAHRvCZGrxDWw7aHVdDY0pAF92jNLb_Hct0bMb3ew6JEpB9AfIm1tSGaQ=@protonmail.com>
<20191003014758.gtgfge5yokcxkfsj@erisian.com.au>
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, DOS_RCVD_IP_TWICE_B, 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
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
"lightning-dev@lists.linuxfoundation.org"
<lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] Continuing the discussion about
noinput / anyprevout
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: Thu, 03 Oct 2019 03:08:06 -0000
> > let me propose the more radical excision, starting with SegWit v1:
> >
> > - Remove `SIGHASH` from signatures.
> > - Put `SIGHASH` on public keys.
> > <sighash> <pubkey> OP_SETPUBKEYSIGHASH
> >
>
> I don't think you could reasonably do this for key path spends -- if
> you included the sighash as part of the scriptpubkey explicitly, that
> would lose some of the indistinguishability of taproot addresses, and be
> more expensive than having the sighash be in witness data.
Nonexistence of sighash byte implies `SIGHASH_ALL`, and for offchain anyway=
the desired path is to end up with an n-of-n MuSig `SIGHASH_ALL` signed mu=
tual close transaction.
Indeed we can even restrict keypath spends to not having a sighash byte and=
just implicitly requiring `SIGHASH_ALL` with no loss of privacy for offcha=
in while attaining safety against `SIGHASH_NOINPUT` for MuSig and VSSS mult=
isignature adresses.
> So I think
> that means sighashes would still be included in key path signatures,
> which would make the behaviour a little confusingly different between
> signing for key path and script path spends.
>
> > This removes the problems with `SIGHASH_NONE` `SIGHASH_SINGLE`, as they=
are allowed only if the output specifically says they are allowed.
>
> I don't think the problems with NONE and SINGLE are any worse than using
> SIGHASH_ALL to pay to "1*G" -- someone may steal the money you send,
> but that's as far as it goes. NOINPUT/ANYPREVOUT is worse in that if
> you use it, someone may steal funds from other UTXOs too -- similar
> to nonce-reuse. So I think having to commit to enabling NOINPUT for an
> address may make sense; but I don't really see the need for doing the
> same for other sighashes generally.
As the existing sighashes are not particularly used anyway, additional rest=
rictions on them are relatively immaterial.
>
> FWIW, one way of looking at a transaction spending UTXO "U" to address
> "A" is something like:
>
> - "script" lets you enforce conditions on the transaction when you
> create "A" [0]
>
> - "sighash" lets you enforce conditions on the transaction when
> you sign the transaction
>
> - nlocktime, nsequence, taproot annex are ways you express conditions
> on the transaction
>
> In that view, "sighash" is actually an extremely simple scripting
> language itself (with a total of six possible scripts).
>
> That doesn't seem like a bad design to me, fwiw.
Only one of the scripts is widely used, another has an edge use it sucks at=
(assurance contracts).
Does not seem to be good design, rather legacy cruft.
Regards,
ZmnSCPxj
>
> Cheers,
> aj
>
> [0] "graftroot" lets you update those conditions for address "A" afte=
r
> the fact
>
|
