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
|
Return-Path: <adam.back@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id AC5E9F9F
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 28 Feb 2018 23:36:07 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f181.google.com (mail-qt0-f181.google.com
[209.85.216.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 16955E7
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 28 Feb 2018 23:36:07 +0000 (UTC)
Received: by mail-qt0-f181.google.com with SMTP id z14so5338748qti.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 28 Feb 2018 15:36:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:reply-to:in-reply-to:references:from:date:message-id
:subject:to:cc:content-transfer-encoding;
bh=37J98srGwsFQesRBuBhmx057vi1uFvrTDxgb50wGVBg=;
b=TDxIrC/L6J05Ii11B1sZj78ASpiIRtQWLonnoD31JAwgqp+4ZgqxDeBP25VmeAPD93
tUjsiuhW+d+xDfUIbcRndZO56vxkKofjRdr+SbPkFTAUyp8nM7ilycjDX79ueo63RdK3
uMCMFgILvBszmfCEGPEMnNEz4t26BdES8C3KDO1m5gYxQOHkifkqOViu3BaZrk+/bZu7
LjrNYibvtIOtzpgYeZfceI1O0p2rg8q0TIxBKpUkZ/iVdrqhznSUXPcSqZzblCtJE4rq
3G2Xe2/msDIXJ/ZhRqa/z2U+JlnXYMr/MzsqKjMh5mxs8X2KNMETMI4UPci5a4gigYum
Jprw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:reply-to:in-reply-to:references
:from:date:message-id:subject:to:cc:content-transfer-encoding;
bh=37J98srGwsFQesRBuBhmx057vi1uFvrTDxgb50wGVBg=;
b=YRWBO8WTqrs4JgBNUJQKEc845lDgBSVj2Q32E/65G7Co+EwUp7BglB6zz7t9LnLzZt
BqSX9qbCV1RLKfreFsza0WowKUp4OHI83ggnrvhJ3ySeYDSiVdbR2xgYvFrZuFRB9eau
RWcS1jEDaZ/+WPa980bIZdT9KT4vORN2MqV5FqlPr3hpVzjPrkbYohI7r7QtyBpgjHXL
0fq7kwVXNKF6tBCcUInUL2P6D+CC0LElFw9tnsRD6lf5IeWobazgMlpiK+TH+IWrWDa+
npaqCJ4LusQ//h57esQaF/Xw/bFxMf0x324uyTlePtCgBjzG/lGczEdERParGa0NNVAi
OrTQ==
X-Gm-Message-State: APf1xPAzBPSZI02TEAVCy0jirrYbsG6FGSe75VG7QzgyEnbwOahl50Lq
YGFeg+C6v8FGWaV5Dt95NM2hZCn0dtYgb3/yqpA=
X-Google-Smtp-Source: AG47ELudtKxA562hnqhj6hqufLlCA55L/qP3xLaWB30WMO20WY6N+tQ6zd+vQoMpQCiNT9AIhouZTTfgja1nKFRCHDU=
X-Received: by 10.200.0.209 with SMTP id d17mr27270126qtg.336.1519860966108;
Wed, 28 Feb 2018 15:36:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.149.243 with HTTP; Wed, 28 Feb 2018 15:36:05 -0800 (PST)
Reply-To: adam@cypherspace.org
In-Reply-To: <20180228223044.GA31415@erisian.com.au>
References: <CALJw2w4hKCAJY5U7Li82FbHHnXZKjcZ0Cw67V+=WxvknkY=Zxg@mail.gmail.com>
<CALJw2w7BQcMEHDa=mx6Gf_JQP603D_hpPq1YN5Em1cfsr4BDAw@mail.gmail.com>
<20180228223044.GA31415@erisian.com.au>
From: Adam Back <adam.back@gmail.com>
Date: Thu, 1 Mar 2018 00:36:05 +0100
Message-ID: <CALqxMTHHnMdbjovZh70bODj2RzEB53SY8MGMa_i1ty1H-1EXMg@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: =?UTF-8?B?44Ki44Or44OgIOOCq+ODvOODq+ODqOODj+ODsw==?= <karl@dglab.com>
Subject: Re: [bitcoin-dev] Simple lock/unlock mechanism
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 Feb 2018 23:36:07 -0000
Coincidentally I had thought of something similar to what Kalle posted
about a kind of software only time-lock vault, and described the idea
to a few people off-list. Re. Root incompatibility, if the key is
deleted (as it must be) then a delegated signature can not be made
that bypasses the CSV timeout restriction, so Root should not be
incompatible with this. I think it would be disadvantageous to mark
keys as Rootable vs not in a sighash sense, because then that is
another privacy/fungibility loss eroding the uniformity advantage of
Root when the delegate is not used.
One drawback is deleting keys may itself be a bit difficult to assure
with HD wallet seeds setup-time backup model.
As Anthony described I think, a simpler though less robust model would
be to have a third party refuse to co-sign until a pre-arranged time,
and this would have the advantage of not requiring two on-chain
transactions.
With bulletproofs and CT rangeproofs / general ECDL ZKPS there is the
possibility to prove things about the private key, or hidden
attributes of a public key in zero-knowledge. Kind of what we want is
to place private key covenants, where we have to prove that they are
met without disclosing them. For example there is a hidden CSV and it
is met OR there is no hidden CSV so it is not applicable.
Adam
On 28 February 2018 at 23:30, Anthony Towns via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Wed, Feb 28, 2018 at 04:34:18AM +0000, =E3=82=A2=E3=83=AB=E3=83=A0 =E3=
=82=AB=E3=83=BC=E3=83=AB=E3=83=A8=E3=83=8F=E3=83=B3 via bitcoin-dev wrote:
>> 1. Graftroot probably breaks this (someone could just sign the
>> time-locked output with a script that has no time-lock).
>
> Making the graftroot key be a 2-of-2 muSig with an independent third part=
y
> that commits to only signing CLTV scripts could avoid this. Making it
> 3-of-3 or 5-of-5 could be even better if you can find multiple independen=
t
> services that will do it.
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
