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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1YiE6K-0002FY-LA
for bitcoin-development@lists.sourceforge.net;
Wed, 15 Apr 2015 03:34:56 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.169 as permitted sender)
client-ip=209.85.213.169; envelope-from=gmaxwell@gmail.com;
helo=mail-ig0-f169.google.com;
Received: from mail-ig0-f169.google.com ([209.85.213.169])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YiE6J-0008Ct-Hj
for bitcoin-development@lists.sourceforge.net;
Wed, 15 Apr 2015 03:34:56 +0000
Received: by igblo3 with SMTP id lo3so31405567igb.0
for <bitcoin-development@lists.sourceforge.net>;
Tue, 14 Apr 2015 20:34:50 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.42.129.73 with SMTP id p9mr29002808ics.48.1429068890214;
Tue, 14 Apr 2015 20:34:50 -0700 (PDT)
Received: by 10.107.15.82 with HTTP; Tue, 14 Apr 2015 20:34:50 -0700 (PDT)
In-Reply-To: <CABHVRKTNFoLm9LEO=ctT_UP9zW7QOMQzVXitKC=PAzj=HG9OHg@mail.gmail.com>
References: <CABHVRKTNFoLm9LEO=ctT_UP9zW7QOMQzVXitKC=PAzj=HG9OHg@mail.gmail.com>
Date: Wed, 15 Apr 2015 03:34:50 +0000
Message-ID: <CAAS2fgTndnSoSx8==EVvP_mMHX=TEMV0whN7s3RBoMYyYDmzJw@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Stephen Morse <stephencalebmorse@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YiE6J-0008Ct-Hj
Cc: bitcoin-development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Build your own nHashType
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 15 Apr 2015 03:34:56 -0000
On Wed, Apr 8, 2015 at 7:50 PM, Stephen Morse
<stephencalebmorse@gmail.com> wrote:
> Seeking feedback on a proposal that will allow a transaction signer to
> explicitly specify what is to be serialized for the signature hash. The
> basic idea is to make the nHashType general enough that we won't need a new
> sighash flag every time a new use case comes up.
>
> If implemented into bitcoin (via a soft fork), this would make malleability
> almost a non-issue (the TXID referenced by inputs just need to be updated
> previous TX changes) and would enable hardware wallets to securely sign
> without needing to download/process each transaction it spends from.
I'm not sure if I'm super fond of that particular non-programmatic but
many options approach; It sort of has the problem that there are
relatively few useful options that don't rapidly extend into a choose
your own adventure with too many options to count; so you take a
complexity penalty perhaps without a matching functionality payoff.
but thats not why I'm commenting...
I wonder if anyone noticed that any sighash masking that eliminates
the txin txid enables covenants?
Covenants are payments which constrain their future payments (like
deed covenants), I've written about them in the past
https://bitcointalk.org/index.php?topic=278122.0 ... they can
sometimes be pretty useful but are also potentially a irritating hit
to fungibility, at least if used stupidly.
the approach here is that you make the scriptpubkey contain "[push:
0x30, 0x06, 0x02, 0x01, 0x04, 0x02, 0x01, 0x04, flags] [push pubkey
resulting from pubkey recovery] OP_CHECKSIG" and set the flags to
match only the things you want to enforce in the spending transaction
hash them up and recover the EC public point. You can think of that
construct as giving a you a OP_MASKED_TRANSACTION_HASH_EQUALS ... the
recovered pubkey is just a kind of message hash, though a weird and
expensive to compute one.
I don't currently see how to get a perpetual covenant out of it-- e.g.
a coin that anyone can spend, but only to its same scriptpubkey, (the
obvious way requires the ability to be able to checksig stuff on the
stack) though I wouldn't be shocked if it were possible with a
sufficiently complex sighash flag and nothing else.
|
