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
|
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 40DCE2818
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 2 Oct 2019 02:03:53 +0000 (UTC)
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 8E202189
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 2 Oct 2019 02:03:52 +0000 (UTC)
Date: Wed, 02 Oct 2019 02:03:43 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1569981830;
bh=8PdzcP4EQtz7VSC2reC2pAg5xm/hEszQeeIlWJlEb4I=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=d9yT5iZ3s8+eblGWitSPWIWf6mIA3tSANQ4kMNR18AuuIknoe/XvWW6ClnEthDgVV
14y47DbudGKetAieU/hwsn1SpCzcUdSUCbJukkULu/ZhFTrJX6fA/XbOCRJW2geTE0
TcbBggkWGia9//cv7W7mDS9wW7RS0uFPXQD/jI7o=
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <CR-etCjXB-JWkvecjDog4Pkq1SuLUgndtSrZo-V4f4EGcNXzNCeAHRvCZGrxDWw7aHVdDY0pAF92jNLb_Hct0bMb3ew6JEpB9AfIm1tSGaQ=@protonmail.com>
In-Reply-To: <20191001155929.e2yznsetqesx2jxo@erisian.com.au>
References: <87wodp7w9f.fsf@gmail.com>
<20191001155929.e2yznsetqesx2jxo@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: "lightning-dev@lists.linuxfoundation.org"
<lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-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: Wed, 02 Oct 2019 02:03:53 -0000
Good morning lists,
Let me propose the below radical idea:
* `SIGHASH` flags attached to signatures are a misdesign, sadly retained fr=
om the original BitCoin 0.1.0 Alpha for Windows design, on par with:
* 1 RETURN
* higher-`nSequence` replacement
* DER-encoded pubkeys
* unrestricted `scriptPubKey`
* Payee-security-paid-by-payer (i.e. lack of P2SH)
* `OP_CAT` and `OP_MULT` and `OP_ADD` and friends
* transaction malleability
* probably many more
So let me propose the more radical excision, starting with SegWit v1:
* Remove `SIGHASH` from signatures.
* Put `SIGHASH` on public keys.
Public keys are now encoded as either 33-bytes (implicit `SIGHASH_ALL`) or =
34-bytes (`SIGHASH` byte, followed by pubkey type, followed by pubkey coord=
inate).
`OP_CHECKSIG` and friends then look at the *public key* to determine sighas=
h algorithm rather than the signature.
As we expect public keys to be indirectly committed to on every output `scr=
iptPubKey`, this is automatically output tagging to allow particular `SIGHA=
SH`.
However, we can then utilize the many many ways to hide public keys away un=
til they are needed, exemplified in MAST-inside-Taproot.
I propose also the addition of the opcode:
<sighash> <pubkey> OP_SETPUBKEYSIGHASH
* `sighash` must be one byte.
* `pubkey` may be the special byte `0x1`, meaning "just use the Taproot int=
ernal pubkey".
* `pubkey` may be 33-byte public key, in which case the `sighash` byte is j=
ust prepended to it.
* `pubkey` may be 34-byte public key with sighash, in which case the first =
byte is replaced with `sighash` byte.
* If `sighash` is `0x00` then the result is a 33-byte public key (the sigha=
sh byte is removed) i.e. `SIGHASH_ALL` implicit.
This retains the old feature where the sighash is selected at time-of-spend=
ing rather than time-of-payment.
This is done by using the script:
<pubkey> OP_SETPUBKEYSIGHASH OP_CHECKSIG
Then the sighash can be put in the witness stack after the signature, letti=
ng the `SIGHASH` flag be selected at time-of-signing, but only if the SCRIP=
T specifically is formed to do so.
This is malleability-safe as the signature still commits to the `SIGHASH` i=
t was created for.
However, by default, public keys will not have an attached `SIGHASH` byte, =
implying `SIGHASH_ALL` (and disallowing-by-default non-`SIGHASH_ALL`).
This removes the problems with `SIGHASH_NONE` `SIGHASH_SINGLE`, as they are=
allowed only if the output specifically says they are allowed.
Would this not be a superior solution?
Regards,
ZmnSCPxj
|
