> 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


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to