> 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
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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
