Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

> 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 out 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 pubkey 2-of-2 of the receiver and its channel counterparty.
The Taproot hides a single script alternative, a `OP_SECURETHEBAG` that ensures it is paid out to a pure script (i.e. Taproot internal key is a NUMS point), 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 with `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. close-only factories.
The above revocation trick only works with two participants, and it would be largely pointless to have 2-participant factories (unless you were e.g. transporting 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 output set.
`SIGHASH_NOINPUT` lets the signatories introduce a new possible output set later.

One might compare `OP_SECURETHEBAG` to MAST, while `SIGHASH_NOINPUT` is comparable 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.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, June 1, 2019 1:35 PM, Jeremy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi All,
>
> OP_CHECKOUTPUTSHASHVERIFY is retracted in favor of OP_SECURETHEBAG*. OP_SECURETHEBAG does more or less the same thing, but fixes malleability issues and lifts the single output restriction to a known number of inputs restriction.
>
> OP_CHECKOUTPUTSVERIFY had some issues with malleability of version and locktime. 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-secure-the-bag.mediawiki
> Implementation: https://github.com/JeremyRubin/bitcoin/tree/secure_the_bag
>
> A particularly useful topic of discussion is how best to eliminate the PUSHDATA and treat OP_SECURETHEBAG like a pushdata directly. I thought about how the interpreter works and is implemented and couldn't come up with something noninvasive.
>
> Thank you for your review and discussion,
>
> Jeremy
>
> * Plus the name is better