Date: Sun, 02 Jun 2019 05:35:43 +0000
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
Subject: Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)
Precedence: list

> 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