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
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E889EC9E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 4 Sep 2018 16:57:40 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f43.google.com (mail-oi0-f43.google.com
[209.85.218.43])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 615CB7E0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 4 Sep 2018 16:57:40 +0000 (UTC)
Received: by mail-oi0-f43.google.com with SMTP id k12-v6so8053049oiw.8
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 04 Sep 2018 09:57:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=NmLuAyXmKjYY3Is/lQ6G1Ve/MK/4Nd9sFHG5qThxDiw=;
b=U/d/IKJTGeJ9dPERLPxXhz0fcnRnkVlIyUpa0lPpaY9OSyFk7F0ZpiH6B1/zwox86o
0ruhFvoZYbbyQlP2hhiUlL8kg1ZLKIQGlk6RSVXkyXSXLI9q083jno/81mC5q1K/LMnl
AWjiV4ymUtFZAafVt8+oM+E6/mA7AzS5A1XLINGGjXhDi/FzYzHKg0rx/ut18qhn7PDt
HD1R6unn+8EfVUegWOjrnSoScI640jjUhkgS3xDZduq2sXQAUnqTOe72/kb7GFLe/y96
qSAKlngtC+sYGQyzdTwZo1jEALLlCRTzX1WoIus6kVnT/KlyI2UxeZTCumvBVEk8kN5L
W9rA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=NmLuAyXmKjYY3Is/lQ6G1Ve/MK/4Nd9sFHG5qThxDiw=;
b=KOIrm8SjGs36jY9Pd+NP5HW3ypX4SurWQmgcwNvVHQTRafugE2L5t/n5ho0I7JM0H1
NAt2UffVVuT+1jMFs3irP7U/ezHwZYNVkxhn5YJkLlgF9Kc50nNCKJ3h33emsFr/gge6
wjA4R/wtOqgWaQF1SGLvgffoNNkMAPAUzRIbJISKdt7fZtGUNraio7kFA/fSfFq9F3XO
MCXRltch6orU14x2LPhac1S2/pDhQa8kiIXWSJpnG1IZkbfxMEM7LwxDx46KWpHgOlNR
6UG6aNOp7Vf2VkVzxdmbXsoXaAjV5BcoFAq5/X+kAoCq0E720n+RCyEFE5imDb02s0kf
Yztg==
X-Gm-Message-State: APzg51BQoUsVuquh98DR16HTlyUHzFIj5Y4qNaAvREVh8hkBMV1rWGaL
jXRRwWCk82dUUUCg361RAVEdPq92CPEnVyH7Hb0=
X-Google-Smtp-Source: ANB0VdaV01TFQT8by1WeCACXqW6LV0ae12zJtVETocVNvq5kMHsnwGqhUoAZK9qbP5C+Qzda4THi7JyW+7RIk6zYmzQ=
X-Received: by 2002:aca:b256:: with SMTP id
b83-v6mr27193405oif.235.1536080259525;
Tue, 04 Sep 2018 09:57:39 -0700 (PDT)
MIME-Version: 1.0
References: <CAFLuHNFD8vTyYfF+64e2Xs_HympQs4ufzSAxQ96jkLZg=pdm7A@mail.gmail.com>
In-Reply-To: <CAFLuHNFD8vTyYfF+64e2Xs_HympQs4ufzSAxQ96jkLZg=pdm7A@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Tue, 4 Sep 2018 09:57:28 -0700
Message-ID: <CAPg+sBhiMPAc4tzsMVBjGuG2RqKLTrD9F0vm9rvpp6DrSm3T1Q@mail.gmail.com>
To: Alex Bosworth <alex.bosworth@gmail.com>,
Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000003730bb05750e8e38"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
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: Tue, 04 Sep 2018 19:19:38 +0000
Subject: Re: [bitcoin-dev] Extending BIP174 for HTLCs
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: Tue, 04 Sep 2018 16:57:41 -0000
--0000000000003730bb05750e8e38
Content-Type: text/plain; charset="UTF-8"
On Tue, Sep 4, 2018, 04:32 Alex Bosworth via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I've been experimenting with a format tag for BIP 174 to help support
> HTLC scripts I've been working with.
>
I've been thinking about this as well.
A useful way to look at it IMHO is to see a hash as the analogue of a
public key, and the preimage as the analogue of a signature.
That would suggest adding two fields to PSBT:
* A request for the preimage of a given hash (similar to the pubkey/path
field currently)
* A revealed preimage for a given hash (similar to the partial signature
field currently).
The workflow would in this case would be:
* An updater recognizes an output/script as being one that requires a
preimage, and adds a preimage request field to the input (along with pubkey
fields for all involved keys).
* A "signer" who knows the preimage sees the request field, verifies he's
willing to divulge the secret, and adds a preimage field (along with any
signatures he may be able to create).
* A finalizer who is compatible with the type of hashlock script combines
all signatures and preimages into a final scriptSig/witness stack.
An obvious difficulty is having updaters and finalizers which are
compatible with all possible variations of hashlocks and other scripts.
Not sure on the best format for this, but what I have been thinking
> about is a new input type that defines elements that should be
> inserted in the final p2sh/p2wsh stack such as a preimage or a refund
> path flag.
>
That's one approach to reducing the complexity of the finalizer: adding
information about the composition of the scriptSig to the PSBT itself.
However, I don't think that approach scales very well (you'd need new
fields for all kinds of new script constructions). In particular, dealing
with multiple possible satisfactions may complicate things, especially when
the number of combinations is intractable.
I've been working on another approach that doesn't involve changes to PSBT,
but instead uses an easily-parsable subset of script (which includes
and/or/threshold/pubkey/locktimes/hashlocks). I hope to publish something
soon about it.
Cheers,
--
Pieter
--0000000000003730bb05750e8e38
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, =
Sep 4, 2018, 04:32 Alex Bosworth via bitcoin-dev <<a href=3D"mailto:bitc=
oin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a=
>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've been experime=
nting with a format tag for BIP 174 to help support<br>
HTLC scripts I've been working with.<br></blockquote></div></div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">I've been thinking about this a=
s well.</div><div dir=3D"auto"><br></div><div dir=3D"auto">A useful way to =
look at it IMHO is to see a hash as the analogue of a public key, and the p=
reimage as the analogue of a signature.</div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">That would suggest adding two fields to PSBT:</div><div dir=
=3D"auto">* A request for the preimage of a given hash (similar to the pubk=
ey/path field currently)</div><div dir=3D"auto">* A revealed preimage for a=
given hash (similar to the partial signature field currently).</div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">The workflow would in this case wou=
ld be:</div><div dir=3D"auto">* An updater recognizes an output/script as b=
eing one that requires a preimage, and adds a preimage request field to the=
input (along with pubkey fields for all involved keys).</div><div dir=3D"a=
uto">* A "signer" who knows the preimage sees the request field, =
verifies he's willing to divulge the secret, and adds a preimage field =
(along with any signatures he may be able to create).</div><div dir=3D"auto=
">* A finalizer who is compatible with the type of hashlock script combines=
all signatures and preimages into a final scriptSig/witness stack.</div><d=
iv dir=3D"auto"><br></div><div dir=3D"auto">An obvious difficulty is having=
updaters and finalizers which are compatible with all possible variations =
of hashlocks and other scripts.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Not sure on the best format for this, but what I have been thinking<br>
about is a new input type that defines elements that should be<br>
inserted in the final p2sh/p2wsh stack such as a preimage or a refund<br>
path flag.<br></blockquote></div></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">That's one approach to reducing the complexity of the finaliz=
er: adding information about the composition of the scriptSig to the PSBT i=
tself. However, I don't think that approach scales very well (you'd=
need new fields for all kinds of new script constructions). In particular,=
dealing with multiple possible satisfactions may complicate things, especi=
ally when the number of combinations is intractable.</div><div dir=3D"auto"=
><br></div><div dir=3D"auto">I've been working on another approach that=
doesn't involve changes to PSBT, but instead uses an easily-parsable s=
ubset of script (which includes and/or/threshold/pubkey/locktimes/hashlocks=
). I hope to publish something soon about it.</div><div dir=3D"auto"><br></=
div><div dir=3D"auto">Cheers,</div><div dir=3D"auto"><br></div><div dir=3D"=
auto">--=C2=A0</div><div dir=3D"auto">Pieter</div><div dir=3D"auto"><br></d=
iv></div>
--0000000000003730bb05750e8e38--
|
