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
|
Return-Path: <eth3rs@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 145601028;
Thu, 3 Oct 2019 15:06:31 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com
[209.85.214.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 93A1B19B;
Thu, 3 Oct 2019 15:06:30 +0000 (UTC)
Received: by mail-pl1-f177.google.com with SMTP id u20so1662916plq.4;
Thu, 03 Oct 2019 08:06:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=4Emj6sK+VwQQIMdbafYSaKH3m3nbTNVtpA8pddr5OOI=;
b=gZiHg11iGbWQ98k9gw4GI7CnBNWnkW1+LdW4QC+xjudy8Ff9q0K+p1B4mpWoymPs+6
DCfceG159PZyA4WE+3Sr8xYTfJsWTa/d9hvKNWDSf/GThct3DWWKuMp+RVtSdso7fU5t
+vHZW8INBmsDBvaR4Sg4JJY9gkgUuU1lDXB/qZuFdulFsRQe8fLEob4f09BNn9OImABG
JW2IOIRluN4j+gbYQ3NT5lXGVAc5XQNXLUqTH38+oUJdmEAoUL5/6JItJneNgLsx6i4q
5QDJwh42Eic0pbfZcGV+dOB5p5KXo44RCw+T/jCorMw4oSYxPM9PTPa1fCOcQFy/u3u0
+m8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=4Emj6sK+VwQQIMdbafYSaKH3m3nbTNVtpA8pddr5OOI=;
b=FRkc4rQHp6SESJEr/fC59pOFqUPO4uHr02q0oN0HJegxNYDMng/cpw8+3gP4b+0wTN
NTaugzoXWlFk5GWhYNWAnDw7aaA8hZekaQiQIwe6TpDVfkMdtCp6tPiJrJOpuDLn+qig
4bJlLaZBo/9FDpfDGmj7SJUXBEmYqYnGtSW8KW5uMbcDo22xvobA8t3SUOjwsIQtaaqp
YT8LPnofph7DLC8gsOWWHxXYfOT0RzVRdCsYq+tlFudBBcEFaJRXSss3OSrOzsVoL+xL
5sdJIZ9O5iB+pbZKz+eihOUVD9EdmmpS2IeJ+xzCm4xCh0+KQOtqIpThghtOLZ9s7+gi
u/6w==
X-Gm-Message-State: APjAAAXrLITBOZ86TqlEzWj54TaJg5nlX5/TyZM2pC/bABmuciYIOh7E
fzW5OhtFOW8TUqsOaLhR1Ypm5Eh/NIEoZEkJ3+31TOuPTwQ=
X-Google-Smtp-Source: APXvYqxnjx8o4o1Se+uh8mTpFGwXap31thSMX2JLCjvUpZBltJ2EGvD9gIF4HfBlEghhZ1EtkXfnSjuVXBpTVAllcg8=
X-Received: by 2002:a17:902:9349:: with SMTP id
g9mr9707543plp.71.1570115189457;
Thu, 03 Oct 2019 08:06:29 -0700 (PDT)
MIME-Version: 1.0
References: <87wodp7w9f.fsf@gmail.com>
<20191001155929.e2yznsetqesx2jxo@erisian.com.au>
<CR-etCjXB-JWkvecjDog4Pkq1SuLUgndtSrZo-V4f4EGcNXzNCeAHRvCZGrxDWw7aHVdDY0pAF92jNLb_Hct0bMb3ew6JEpB9AfIm1tSGaQ=@protonmail.com>
In-Reply-To: <CR-etCjXB-JWkvecjDog4Pkq1SuLUgndtSrZo-V4f4EGcNXzNCeAHRvCZGrxDWw7aHVdDY0pAF92jNLb_Hct0bMb3ew6JEpB9AfIm1tSGaQ=@protonmail.com>
From: Ethan Heilman <eth3rs@gmail.com>
Date: Thu, 3 Oct 2019 11:05:52 -0400
Message-ID: <CAEM=y+XbP3Dn7X8rHu7h0vbX6DkKA0vFK5nQqzcJ_V+D4EVMmw@mail.gmail.com>
To: ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, DOS_RCVD_IP_TWICE_B, 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
Cc: "lightning-dev@lists.linuxfoundation.org"
<lightning-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] OP_CAT was Re: 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 15:06:31 -0000
To avoid derailing the NO_INPUT conversation, I have changed the
subject to OP_CAT.
Responding to:
"""
* `SIGHASH` flags attached to signatures are a misdesign, sadly
retained from the original BitCoin 0.1.0 Alpha for Windows design, on
par with:
[..]
* `OP_CAT` and `OP_MULT` and `OP_ADD` and friends
[..]
"""
OP_CAT is an extremely valuable op code. I understand why it was
removed as the situation at the time with scripts was dire. However
most of the protocols I've wanted to build on Bitcoin run into the
limitation that stack values can not be concatenated. For instance
TumbleBit would have far smaller transaction sizes if OP_CAT was
supported in Bitcoin. If it happens to me as a researcher it is
probably holding other people back as well. If I could wave a magic
wand and turn on one of the disabled op codes it would be OP_CAT. Of
course with the change that size of each concatenated value must be 64
Bytes or less.
On Tue, Oct 1, 2019 at 10:04 PM ZmnSCPxj via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Good morning lists,
>
> Let me propose the below radical idea:
>
> * `SIGHASH` flags attached to signatures are a misdesign, sadly retained from 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 coordinate).
> `OP_CHECKSIG` and friends then look at the *public key* to determine sighash algorithm rather than the signature.
>
> As we expect public keys to be indirectly committed to on every output `scriptPubKey`, this is automatically output tagging to allow particular `SIGHASH`.
> However, we can then utilize the many many ways to hide public keys away until 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 internal pubkey".
> * `pubkey` may be 33-byte public key, in which case the `sighash` byte is just 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 sighash byte is removed) i.e. `SIGHASH_ALL` implicit.
>
> This retains the old feature where the sighash is selected at time-of-spending 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, letting the `SIGHASH` flag be selected at time-of-signing, but only if the SCRIPT specifically is formed to do so.
> This is malleability-safe as the signature still commits to the `SIGHASH` it 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
