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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 632BFDC3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 2 Jun 2019 05:35:51 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch
[185.70.40.136])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6E7B819B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 2 Jun 2019 05:35:50 +0000 (UTC)
Date: Sun, 02 Jun 2019 05:35:43 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1559453748;
bh=ovNnGZWrIA6lJ1TipLbCtTR+XqkKf1S7p9QwXNiKLf4=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID:
From;
b=qb3jpI1uZ+xJm/5jYKXVXEbw1cH2Ahf2LVqKv1RX09fF5nb66FY4mgDbB0g7wPhSI
pcEhP4T1IUsGpna3scQkfucjn3Ahl6eZuFOIWmO/2R6wb/xsAEhMgHDbbRYwMlcs6r
HYwzdHh694UNSyp15vpX2QvhE+lyu4RKgLi1+HDA=
To: Jeremy <jlrubin@mit.edu>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <cf6u26qQgi-J4oe6u_eiBYJVoktC38pFkGFbeqhu5_OcUACFrpyy-d7wLzaGZh6h6hE6c2CbZmKAeiK3-bz8unKGrFMdZldOEk15PdadSKo=@protonmail.com>
In-Reply-To: <CAD5xwhjSj82YYuQHHbwgSLvUNV2RDY0b=yMYeLj-p6j7PpS9-Q@mail.gmail.com>
References: <CAD5xwhjSj82YYuQHHbwgSLvUNV2RDY0b=yMYeLj-p6j7PpS9-Q@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
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
X-Mailman-Approved-At: Sun, 02 Jun 2019 13:20:57 +0000
Subject: Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)
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: Sun, 02 Jun 2019 05:35:51 -0000
> Using an OP_SECURETHEBAG Taproot, the recipient may even give the sender =
an address which makes a channel unbeknownst to them.
This requires special design to be safe.
Every offchain protocol requires a backout transaction to be created before=
the funding transaction output is committed onchain.
This backout transaction ensures that the funder of the channel can back ou=
t if the other side aborts the protocol.
For Poon-Dryja channels this is the initial commitment transaction.
The continued operation of the protocol requires the initial commitment to =
be revoked at the next update.
So we need a plausible backout for the receiver first.
To do so, we make the funding transaction address a Taproot with internal p=
ubkey 2-of-2 of the receiver and its channel counterparty.
The Taproot hides a single script alternative, a `OP_SECURETHEBAG` that ens=
ures it is paid out to a pure script (i.e. Taproot internal key is a NUMS p=
oint), the scripts forming a revocable output to the receiver (let receiver=
claim with `OP_CHECKSEQUENCEVERIFY`, or counterparty to revoke immediately=
if it knows revocation key).
This is essentially a walletless channel open, which I described before wit=
h `SIGHASH_NOINPUT`.
Channel factories using `OP_SECURETHEBAG` cannot be updated (i.e. not able =
to close channels and reuse funds to open new channels offchain), i.e. clos=
e-only factories.
The above revocation trick only works with two participants, and it would b=
e largely pointless to have 2-participant factories (unless you were e.g. t=
ransporting HTLCs separately from DLCs in two channels of the same factory)=
.
Channel factories based on the Decker-Russell-Osuntokun mechanism ("eltoo")=
allow reorganizing channels offchain, without hitting the chain at all.
These need `SIGHASH_NOINPUT`/`SIGHASH_ANYPREVOUT`.
For channel factories, `SIGHASH_NOINPUT` is better.
`OP_SECURETHEBAG` requires the funding output to commit to a particular out=
put set.
`SIGHASH_NOINPUT` lets the signatories introduce a new possible output set =
later.
One might compare `OP_SECURETHEBAG` to MAST, while `SIGHASH_NOINPUT` is com=
parable to Graftroot.
MAST has a fixed set of alternatives, while Graftroot allows signatories to=
add new alternatives later.
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Saturday, June 1, 2019 1:35 PM, Jeremy via bitcoin-dev <bitcoin-dev@list=
s.linuxfoundation.org> wrote:
> Hi All,
>
> OP_CHECKOUTPUTSHASHVERIFY is retracted in favor of OP_SECURETHEBAG*. OP_S=
ECURETHEBAG does more or less the same thing, but fixes malleability issues=
and lifts the single output restriction to a known number of inputs restri=
ction.
>
> OP_CHECKOUTPUTSVERIFY had some issues with malleability of version and lo=
cktime. OP_SECURETHEBAG commits to both of these values.
>
> OP_SECURETHEBAG also lifts the restriction that OP_CHECKOUTPUTSVERIFY had=
to be spent as only a single input, and instead just commits to the number=
of inputs. This allows for more flexibility, but keeps it easy to get the =
same single output restriction.
>
> BIP: https://github.com/JeremyRubin/bips/blob/op-secure-the-bag/bip-secur=
e-the-bag.mediawiki
> Implementation: https://github.com/JeremyRubin/bitcoin/tree/secure_the_ba=
g
>
> A particularly useful topic of discussion is how best to eliminate the PU=
SHDATA and treat OP_SECURETHEBAG like a pushdata directly. I thought about =
how the interpreter works and is implemented and couldn't come up with some=
thing noninvasive.
>
> Thank you for your review and discussion,
>
> Jeremy
>
> * Plus the name is better
|
