public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Jeremy <jlrubin@mit•edu>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)
Date: Sun, 02 Jun 2019 05:35:43 +0000	[thread overview]
Message-ID: <cf6u26qQgi-J4oe6u_eiBYJVoktC38pFkGFbeqhu5_OcUACFrpyy-d7wLzaGZh6h6hE6c2CbZmKAeiK3-bz8unKGrFMdZldOEk15PdadSKo=@protonmail.com> (raw)
In-Reply-To: <CAD5xwhjSj82YYuQHHbwgSLvUNV2RDY0b=yMYeLj-p6j7PpS9-Q@mail.gmail.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




  reply	other threads:[~2019-06-02  5:35 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-01  5:35 Jeremy
2019-06-02  5:35 ` ZmnSCPxj [this message]
2019-06-02 14:32 ` Russell O'Connor
2019-06-02 21:32   ` Jeremy
2019-06-05  9:30 ` Anthony Towns
2019-06-06  7:30   ` ZmnSCPxj
2019-06-18 20:57     ` Russell O'Connor
2019-06-20 22:05       ` Anthony Towns
2019-06-23  6:43         ` Jeremy
2019-07-08 10:26           ` Dmitry Petukhov
2019-10-03 23:22             ` Jeremy
     [not found]       ` <CAD5xwhj8o8Vbrk2KADBOFGfkD3fW3eMZo5aHJytGAj_5LLhYCg@mail.gmail.com>
2019-06-23 13:11         ` ZmnSCPxj
2019-06-24 14:34         ` Russell O'Connor
2019-06-24 18:07           ` Jeremy
2019-06-24 18:48             ` Russell O'Connor
2019-06-24 22:47               ` Jeremy
2019-06-25 17:05                 ` Russell O'Connor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='cf6u26qQgi-J4oe6u_eiBYJVoktC38pFkGFbeqhu5_OcUACFrpyy-d7wLzaGZh6h6hE6c2CbZmKAeiK3-bz8unKGrFMdZldOEk15PdadSKo=@protonmail.com' \
    --to=zmnscpxj@protonmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=jlrubin@mit$(echo .)edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox