From: Christian Decker <decker.christian@gmail•com>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
Chris Stewart <chris@suredbits•com>
Cc: Christian Decker via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org>,
"lightning-dev@lists•linuxfoundation.org"
<lightning-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] Continuing the discussion about noinput / anyprevout
Date: Thu, 03 Oct 2019 12:01:58 +0200 [thread overview]
Message-ID: <87imp66tbd.fsf@gmail.com> (raw)
In-Reply-To: <bMt69zMSAH_2zekGjg56k6MWFMwWkjKMdUjqHQ5eN7c5ONixWZ0s2wW4HmILeVjImt6Z2K5fPa6GKGLP_HWThCzFIIu53wvEKTDrGg-YpOQ=@protonmail.com>
ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> writes:
> Good morning lists,
>
> Let me summarize concerns brought up:
>
> * Chris concern, is that an ordinary UTXO that is not allocated for `SIGHASH_NOINPUT` use, is inadvertently spent using `SIGHASH_NOINPUT`.
> * My concern, is that unless a UTXO allocated for `SIGHASH_NOINPUT` use, is *indeed* used with SIGHASH_NOINPUT`, it should look exactly the same as any other SegWit v1 output.
>
> I propose the below instead:
>
> * Do ***NOT*** allocate SegWit v16 for `SIGHASH_NOINPUT`.
> * Instead, allocate SegWit v1 Tapscript v16 for `SIGHASH_NOINPUT`.
>
> Then, on usage:
>
> * Exchange hoards can be protected by simple MuSig bip-schnorr SegWit v1 outputs, or a NUMS Taproot internal point with a MAST branch Tapscript v0 `OP_CHECKSIG_ADD` sequence.
> * Decker-Russell-Osuntokun constructions are backed by a n-of-n MuSig Taproot internal point, with a MAST branch containing a Tapscript v16 with `OP_1 OP_CHECKSIG`.
>
> This solves both concerns:
>
> * Ordinary UTXOs not allocated for `SIGHASH_NOINPUT` use simply do not commit to any Taproot that has a Tapscript v16 branch, and thus `SIGHASH_NOINPUT` is unuseable to claim it.
> * If a UTXO used for an offchain protocol ends up in a cooperative-resolution state, nobody has to know that a Tapscript v16 branch existed that could have used `SIGHASH_NOINPUT`.
>
> Again, my objection to output tagging is that it is **publicly visible** as soon as the funding transaction is confirmed onchain that this is a special output used for a Decker-Russell-Osuntokun construction, greatly damaging privacy.
> But if this fact is kept secret *unless* the very specific case of unilateral uncooperative enforcement, then it is quite fine with me.
>
> Would this alternate proposal hold better muster?
Intriguing idea, this would be an invisible tagging, since the opt-in to
noinput and friends is hidden inside the committed script, which only
gets revealed whenever we actually need it.
For eltoo this would mean that the funding output would be invisibly
tagged, and the cooperative close would use the taproot pubkey, while
the uncooperative close, which would require noinput opt-in, reveals the
script, proving prior opt-in, and provides a matching signature.
If I'm not mistaken this would require AJ's alternative pubkey encoding
(0x01 or 0x00 prefixed pubkey) to make the opt-in visible, correct?
next prev parent reply other threads:[~2019-10-03 10:33 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-30 13:23 [bitcoin-dev] " Christian Decker
2019-09-30 16:00 ` ZmnSCPxj
2019-09-30 23:28 ` ZmnSCPxj
2019-10-01 14:26 ` Christian Decker
2019-10-01 14:45 ` Anthony Towns
2019-10-01 15:42 ` ZmnSCPxj
2019-10-01 14:20 ` Christian Decker
2019-10-01 15:35 ` ZmnSCPxj
2019-10-03 9:42 ` Christian Decker
2019-10-01 12:23 ` Chris Stewart
2019-10-01 13:31 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2019-10-03 10:01 ` Christian Decker [this message]
2019-10-03 9:57 ` Christian Decker
[not found] ` <CACJVCgJ9PL-2jTS71--tXsa=QkK+f5_ciYLwv468WUno=XXAig@mail.gmail.com>
2019-10-01 14:27 ` Ethan Heilman
2019-10-01 15:14 ` Chris Stewart
2019-10-03 10:30 ` Christian Decker
2019-10-01 15:59 ` [bitcoin-dev] " Anthony Towns
2019-10-02 2:03 ` ZmnSCPxj
2019-10-03 1:47 ` [bitcoin-dev] [Lightning-dev] " Anthony Towns
2019-10-03 3:07 ` ZmnSCPxj
2019-10-03 15:05 ` [bitcoin-dev] OP_CAT was " Ethan Heilman
2019-10-03 23:42 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2019-10-04 0:48 ` Ethan Heilman
2019-10-04 5:02 ` Jeremy
2019-10-04 7:00 ` ZmnSCPxj
2019-10-04 18:33 ` Jeremy
2019-10-04 11:15 ` Peter Todd
2019-10-04 18:40 ` Jeremy
2019-10-05 15:49 ` Peter Todd
2019-10-06 8:46 ` ZmnSCPxj
2019-10-06 9:12 ` Peter Todd
2019-10-06 7:02 ` Lloyd Fournier
2019-10-09 16:56 ` Andrew Poelstra
2019-10-02 15:11 ` [bitcoin-dev] " s7r
2019-10-03 11:08 ` Christian Decker
2019-10-05 10:06 ` Anthony Towns
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=87imp66tbd.fsf@gmail.com \
--to=decker.christian@gmail$(echo .)com \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=chris@suredbits$(echo .)com \
--cc=lightning-dev@lists$(echo .)linuxfoundation.org \
/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