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
|
Return-Path: <bob@mcelrath.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 51D9C25A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 28 Nov 2018 14:04:17 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mcelrath.org (moya.mcelrath.org [50.31.3.130])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1845863D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 28 Nov 2018 14:04:15 +0000 (UTC)
Received: from mcelrath.org (localhost [127.0.0.1])
by mcelrath.org (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id
wASE4EL0026301
(version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256
verify=NOT); Wed, 28 Nov 2018 14:04:14 GMT
Received: (from mcelrath@localhost)
by mcelrath.org (8.14.4/8.14.4/Submit) id wASE4DPL026298;
Wed, 28 Nov 2018 14:04:13 GMT
X-Authentication-Warning: mcelrath.org: mcelrath set sender to
bob@mcelrath.org using -f
Date: Wed, 28 Nov 2018 14:04:13 +0000
From: Bob McElrath <bob@mcelrath.org>
To: Johnson Lau <jl2012@xbt.hk>
Message-ID: <20181128140412.GC22873@mcelrath.org>
References: <20181128005416.GB22873@mcelrath.org>
<8690D3D0-3815-4779-A571-C75AA75F707B@xbt.hk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8690D3D0-3815-4779-A571-C75AA75F707B@xbt.hk>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 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:30 +0000
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
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 14:04:17 -0000
We are also prototyping the OP_CHECKSIGFROMSTACK mechanism using Liquid/Elements.
Given uncertainty about which features will actually be deployed on mainnet,
we're exploring all possibilities so as to provide feedback about the "best" way
to implement a covenant/vault, also including the OP_CHECKOUTPUTVERIFY
originally proposed by Eyal et al. That's 3 ways to implement a covenant/vault,
if there's others I'd be happy to hear about it. ;-) Thanks for the
OP_PUSHTXDATA ref, I'm reading now... Personally I think the
OP_CHECKSIGFROMSTACK is probably the most elegant mechanism.
Thanks for the feedback!
Johnson Lau [jl2012@xbt.hk] wrote:
> 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:
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > P.S. Also very excited to combine the above idea with Taproot/Graftroot/g'Root.
> >
> > --
> > Cheers, Bob McElrath
> >
> > "For every complex problem, there is a solution that is simple, neat, and wrong."
> > -- H. L. Mencken
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
>
> !DSPAM:5bfe5494217527839717631!
--
Cheers, Bob McElrath
"For every complex problem, there is a solution that is simple, neat, and wrong."
-- H. L. Mencken
|
