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
|
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 1CC62E85
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Dec 2018 16:21:53 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9D87583E
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Dec 2018 16:21:52 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; t=1545409310; cv=none; d=zoho.com; s=zohoarc;
b=TsjddjaH+mzvOT3MtHUQeQWcnpITgOvqY0u2Za+n/9kSlyD30DnaeuDBOg2Y3dgxL2IaS+7InB7Up6zmtUR9e2hGsjyLDtLK5aBwZ2VurSm3MmI9COPkyQByTjim51U04LicicNIp7Sb05jdcc4lKVDakZ2q2Tinhh4+iNwXQmI=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com;
s=zohoarc; t=1545409310;
h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results;
bh=fIj5zWzo0fft0Je5u3vQHI8Bb01YP8NDQ/0AW6N5fx8=;
b=Q8prILr1+AWxSNtSBTKl7oA0HrQBL2uI9TQGho06+v7bBEojw0wTX4KrorU+StBYOwmmvnSGOu0m5O6imAVFAeuPR78pQJ018Ec+zx3gl85gQs8KW7guQS3TNZG5EoMlAF+jLC6BXCWk9WOUMApvJAhbpvTBNXlAdpVhNZEiAKg=
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.8.0.105] (n218103234118.netvigator.com [218.103.234.118])
by mx.zohomail.com with SMTPS id 1545409308634549.3261268469297;
Fri, 21 Dec 2018 08:21:48 -0800 (PST)
Content-Type: text/plain;
charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: Johnson Lau <jl2012@xbt.hk>
In-Reply-To: <87woo3uo4m.fsf@gmail.com>
Date: Sat, 22 Dec 2018 00:21:42 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <96D7F9F7-4D1B-42ED-A82C-E714F3AED047@xbt.hk>
References: <9F8C0789-48E9-448A-A239-DB4AFB902A00@xbt.hk>
<CAPv7TjYRVUGWCyFweootbMCJEkyFG4YOJ+M_N_N4j_t043bUfw@mail.gmail.com>
<87efadp3rl.fsf@gmail.com>
<195B4583-CE97-4C3A-9582-3C0C013CC1E9@xbt.hk>
<871s6cw1vt.fsf@gmail.com>
<34A8F2C4-4732-4BE7-84F5-699B8D709D06@xbt.hk>
<87woo3uo4m.fsf@gmail.com>
To: Christian Decker <decker.christian@gmail.com>
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: Fri, 21 Dec 2018 23:30:36 +0000
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Safer NOINPUT with output tagging
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, 21 Dec 2018 16:21:53 -0000
> On 21 Dec 2018, at 7:15 PM, Christian Decker =
<decker.christian@gmail.com> wrote:
>=20
> Johnson Lau <jl2012@xbt.hk> writes:
>=20
>> I think the use of OP_CSV (BIP112) is not needed here (although it
>> doesn=E2=80=99t really harm except taking a few more bytes). All you =
need is
>> to sign the settlement tx with a BIP68 relative locktime. Since this
>> is a 2-of-2 branch, both parties need to agree with the relative
>> locktime, so it is not necessary to restrict it through OP_CSV
>=20
> I keep forgetting about BIP68, but you're right, that should be
> sufficient for our use-case and would safe us a few bytes.
>=20
With taproot, this actually saves a lot more than a few bytes. For each =
update, you will make 3 signatures. One is a SIGHASH_ALL spending the =
setup TXO with no locktime. One is a NOINPUT spending a previous update =
TXO with absolute locktime. One is a NOINPUT spending the latest update =
TXO with relative locktime. For the first and third signatures, you will =
just sign directly with the scriptPubKey, without revealing the hidden =
taproot script. The second signature will reveal the taproot script, but =
it is needed only when someone published an outdated update tx.
|
