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
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 94F179BA
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 28 Nov 2018 08:40:40 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sender-of-o53.zoho.com (sender-of-o53.zoho.com [135.84.80.218])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 18EFD19B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 28 Nov 2018 08:40:39 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; t=1543394439; cv=none; d=zoho.com; s=zohoarc;
b=AGUu07Al2Fo4KiLK2fLCNKXraiCFk7KZFhyMeDrAEOC/aI/13v5fhtdPmKixtB8BlRL2itczi63gwJ9ALbZyrJKU4ZFQr+YHWGs3tHQVMWwLPpG7UaaKVhgFxSsY4MTpL0fD4fAWIzXzd58dxOqJLQok9Ittghv3XlGyXChpHmE=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com;
s=zohoarc; t=1543394439;
h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results;
bh=7qExG0kMac6ZAC/Ine4AHUcZ7kjZB0CNzSSiZRYMm/k=;
b=E6dp9nRmWChCPU9voO21OjQY4CIzNMUrlVzpYqxtkxR5eSMnaquTYLH3CiXHYH2v5/wImDt1aXuWywYbNh4XwnafN7wtIkrLqp+jSwcGZgIzf8V6yekTSbAVIuqDzo/rxq0M3eK/CoBKnrmP/UPWDYVm2UJKXP9elr1fdK0eHzQ=
ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass header.i=xbt.hk;
spf=pass smtp.mailfrom=jl2012@xbt.hk;
dmarc=pass header.from=<jl2012@xbt.hk> header.from=<jl2012@xbt.hk>
Received: from [10.7.47.115] (ip-123-255-103-29.wlan.cuhk.edu.hk
[123.255.103.29]) by mx.zohomail.com
with SMTPS id 15433944376791008.2314816770382;
Wed, 28 Nov 2018 00:40:37 -0800 (PST)
From: Johnson Lau <jl2012@xbt.hk>
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Date: Wed, 28 Nov 2018 16:40:34 +0800
References: <20181128005416.GB22873@mcelrath.org>
To: Bob McElrath <bob@mcelrath.org>,
bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <20181128005416.GB22873@mcelrath.org>
Message-Id: <8690D3D0-3815-4779-A571-C75AA75F707B@xbt.hk>
X-Mailer: Apple Mail (2.3445.100.39)
X-ZohoMailClient: External
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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: Wed, 28 Nov 2018 14:24:18 +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: Wed, 28 Nov 2018 08:40:40 -0000
This is incompatible with bip-schnorr, which intentionally disallow such =
use by always committing to the public key: =
https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki
With the recent fake Satoshi signature drama, and other potential ways =
to misuse and abuse, I think this is a better way to go, which =
unfortunately might disallow some legitimate applications.
Covenants could be made using OP_CHECKSIGFROMSTACK =
(https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf) or =
OP_PUSHTXDATA =
(https://github.com/jl2012/bips/blob/vault/bip-0ZZZ.mediawiki). I think =
this is the next step following the taproot soft fork
> On 28 Nov 2018, at 8:54 AM, Bob McElrath via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> I have been working on an experimental wallet that implements Bitcoin
> Covenants/Vaults following a blog post I wrote about 2 years ago, =
using
> "Pay-to-Timelock Signed Transaction" (P2TST). (Also mentioned =
recently by
> kanzure in a talk somewheres...) The idea is that you deposit to an =
address for
> which you don't know the private key. Instead you construct a second
> transaction sending that to a timelocked staging address for which you =
DO have
> the privkey (it also has an IF/ELSE condition with a second spending =
condition
> for use in case of theft attempt). In order to do this you either =
have to
> delete the privkey of the deposit address (a difficult proposition to =
know it's
> actually been deleted), but instead one can construct a signature =
directly using
> a RNG, and use the SIGHASH to compute the corresponding pubkey via =
ECDSA
> recover, from which you compute the corresponding address. In this =
way your
> wallet is a set of P2TST transactions and a corresponding privkey, =
with a (set
> of) emergency keys.
>=20
> This interacts with NOINPUT in the following way: if the input to the
> transaction commits to the pubkey in any way, you have a circular =
dependency on
> the pubkey that could only be satisfied by breaking a hash function. =
This
> occurs with standard sighash's which commit to the txid, which in turn =
commit to
> the address, which commits to the pubkey, so this construction of
> covenants/vaults requires NOINPUT.
>=20
> AFAICT sipa's proposal is compatible with the above vaulted =
construction by
> using SIGHASH_NOINPUT | SIGHASH_SCRIPTMASK to remove the
> scriptPubKey/redeemScript from the sighash. Putting the
> scriptPubKey/redeemScript in the sighash introduces the same circular
> dependency, but SIGHASH_SCRIPTMASK removes it.
>=20
> One would probably want to provide the fee from a separate wallet so =
as to be
> able to account for fluctuating fee pressures when the unvaulting =
occurs a long
> time after vaulting. Thus you'd want to use SIGHASH_SINGLE so that a =
fee-wallet
> can add fees (or for composability of P2TSTs), and SIGHASH_NOFEE as =
well.
>=20
> P.S. Also very excited to combine the above idea with =
Taproot/Graftroot/g'Root.
>=20
> --
> Cheers, Bob McElrath
>=20
> "For every complex problem, there is a solution that is simple, neat, =
and wrong."
> -- H. L. Mencken=20
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
