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
|
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 35DA9927
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 23 Nov 2018 09:40:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com
[209.85.208.53])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D5E9F5E2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 23 Nov 2018 09:40:30 +0000 (UTC)
Received: by mail-ed1-f53.google.com with SMTP id h50so9752383ede.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 23 Nov 2018 01:40:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:cc:subject:in-reply-to:references:date:message-id
:mime-version; bh=uQkJpSVVLSYJpAsz9OJSI4nnKuF0ZGCmzwMZ7akkfFY=;
b=ri/r3du9HSOHhY2T5I4+bHhlijPlcJ0tPeO6kY9SogReQtJfgBnMy7NpU/c1+7t2Q7
4whywEoLxt7LJzxZ/DovSXiYNE3D/ajpN+uK7+fxuEDU5i1ZUuH42jl/elwOstSdFO8R
h4zILf1LY1ilSCCi6FVu+4KwSBmLKSOcQIAyr0QOWWLDw324eE7hYbpFq22ycRRKupoa
8kjd8tB6jE1r1w5Oo6n2Qcrk8qtxjCAg/oyUqc6Y7bvEiOkf/GIEin4LMEu8bI9XJFuh
Gc4nQxWrMQAakLfJt4St0iBSuRF0oPoJZ4+VsGJExR3LdKjlQKbjl9TsERBUQY8ULoDx
j/HA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date
:message-id:mime-version;
bh=uQkJpSVVLSYJpAsz9OJSI4nnKuF0ZGCmzwMZ7akkfFY=;
b=O+LDNuncBn01qvU1/aO0lwlOqYtp6xMBhKnm2Rq4vCM3lpBKFfQhFuzRSFeEXX/tl+
7UUmX0qBW0ZA36IHFkJkry16fWLVLLrqIaGRyxIXlbsZDloAZrxiUyQZm1YbZaTerSjw
kmCt7Q1CGPiohRHpZ/NcJ2LV1rWBVjQHfIPMb+JGZ+VsTryrsVd5DpwMadq37xFtisnK
HbEkTsA0+nBBocjPUhvxaYfgrDWVJDWSPDwC+P0crRiT5VGXl+yslAkgCJZQPVp4maHt
IAdOJ3RGw8tCjtsmBc4jfpppmQgCPD5eooima9s91Rodhi66T1oqmvFM0CJRGgGI3f0/
2dGw==
X-Gm-Message-State: AA+aEWZtTzAAeJyxxRAvS65Gti5Y2FuEak5nG8SkG8PuZI87yQt+M3Mm
CfYc5Jk4uPxkBRkEXc///Yk=
X-Google-Smtp-Source: AFSGD/XUQlxD1ALCaktjKjRNtfnjpNbVYtnlx+bwzDpnVnyEo/pmtwdKPa5Wuis95/H/5OF8Xi78Gg==
X-Received: by 2002:a50:9724:: with SMTP id c33mr12489019edb.288.1542966029300;
Fri, 23 Nov 2018 01:40:29 -0800 (PST)
Received: from localhost ([2a02:aa16:1102:5480:1115:8f2f:6db1:5c0a])
by smtp.gmail.com with ESMTPSA id
s5-v6sm7309259eji.25.2018.11.23.01.40.27
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
Fri, 23 Nov 2018 01:40:28 -0800 (PST)
From: Christian Decker <decker.christian@gmail.com>
To: Anthony Towns <aj@erisian.com.au>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <20181123060404.fu4eyzcynbppmjcy@erisian.com.au>
References: <CAPg+sBhuPG-2GXc+Bp0yv5ywry2fk56LPLT4AY0Kcs+YEoz4FA@mail.gmail.com>
<87k1l6d6lb.fsf@gmail.com>
<20181123060404.fu4eyzcynbppmjcy@erisian.com.au>
Date: Fri, 23 Nov 2018 10:40:20 +0100
Message-ID: <878t1kcet7.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
X-Mailman-Approved-At: Sat, 24 Nov 2018 02:17:49 +0000
Subject: Re: [bitcoin-dev] Safer sighashes and more granular 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: Fri, 23 Nov 2018 09:40:32 -0000
Anthony Towns <aj@erisian.com.au> writes:
> Commiting to just the sequence numbers seems really weird to me; it
> only really prevents you from adding inputs, since you could still
> replace any input that was meant to be there by almost any arbitrary
> other transaction...
It's a really roundabout way of committing to the inputs, I
agree. I'm actually wondering if it makes sense to correct that
additional blanked field in BIP118 at all since it seems there is no
real use-case for NOINPUT that doesn't involve blanking the
`hashSequence` as well.
> I could see this *maybe* making sense if you at least committed to the
> values of each input's outpoint; since that would be an actual constraint?
BIP118 still commits to the value of the input being spent, i.e.,
6. value is not being blanked in the current proposal. This is on
purpose since we commit to the outputs, not committing to the input
values could end up with unexpected fees.
>> As for your proposal, I really like the `sighash_scriptmask` proposal,
>> and committing to the fees (with the `nofee` escape hatch) also works
>> seems also a nice fix. My one concern is that introducing a new opcode
>> to mask things in the sighash looks like a similar layering violation as
>> `codeseparator` was, but that's just a minor issue imho.
>
> I think OP_MASK is okay as far as layering goes, if you just think of it
> as a (set of) multibyte "OP_MASKED_PUSH" opcode(s). So when you
> pseudocode a script like:
>
> <n> OP_CSV OP_DROP <p> OP_CHECKSIG
>
> and then decide <n> needs to be masked, you rewrite it as:
>
> [n] OP_CSV OP_DROP <p> OP_CHECKSIG
>
> indicating n is masked, and don't worry about the exact bytes that will
> encode the push, anymore than you currently worry about whether it's
> OP_0, OP_1..16, <1..75>+1..75-bytes, PUSHDATA[1,2,3]+n+n-bytes.
>
> As long as OP_MASK only applies to a PUSH and it's an error for OP_MASK
> not to be immediately followed by that PUSH, I think that all works
> out fine.
Agreed, that makes more sense :-)
|
