public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Christian Decker <decker.christian@gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Cc: "lightning-dev@lists.linuxfoundation.org"
	<lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Continuing the discussion about noinput / anyprevout
Date: Tue, 01 Oct 2019 16:20:25 +0200	[thread overview]
Message-ID: <87tv8s7djq.fsf@gmail.com> (raw)
In-Reply-To: <-5H29F71ID9UFqUGMaegQxPjKZSrF1mvdgfaaYtt_lwI7l1OTmN_8OgcooyoMt2_XuyZ5aDljL6gEup9C7skF8iuP_NbMW_81h0tJIGbJno=@protonmail.com>

ZmnSCPxj <ZmnSCPxj@protonmail.com> writes:
> I rather strongly oppose output tagging.
>
> The entire point of for example Taproot was to reduce the variability
> of how outputs look like, so that unspent Taproot outputs look exactly
> like other unspent Taproot outputs regardless of the SCRIPT (or lack
> of SCRIPT) used to protect the outputs.  That is the reason why we
> would prefer to not support P2SH-wrapped Taproot even though
> P2SH-wrapping was intended to cover all future uses of SegWit,
> including SegWit v1 that Taproot will eventually get.

That is a bit reductive if you ask me. Taproot brings a number of
improvements such as the reduction of on-chain footprint in the
collaborative spend case, the hiding of complex logic in that case, and
yes, the uniformity of UTXOs that you mentioned. I do agree that it'd be
to make everything look identical to the outside observer, but saying
that separating outputs into two coarse-grained domains is equivalent to
throwing the baby out with the bath-water :-)

That being said, I should clarify that I would prefer not having to make
special accomodations on top of the raw sighash_noinput proposal, for
some perceived, but abstract danger that someone might shoot themselves
in the foot. I think we're all old enough not to need too much
handholding :-)

Output tagging is my second choice, since it minimizes the need for
people to get creative to work around other proposals, and minimizes the
on-chain footprint, and finally chaperone signatures are my least
preferred option due to its heavy-handed nature and the increased cost.

> Indeed, if it is output tagging that gets into Bitcoin base layer, I
> would strongly suggest the below for all Decker-Russell-Osuntokun
> implementations:
>
> * A standard MuSig 2-of-2 bip-schnorr SegWit v1 Funding Transaction Output, confirmed onchain
> * A "translator transaction" spending the above and paying out to a SegWit v16 output-tagged output, kept offchain.
> * Decker-Russell-Osuntokun update transaction, signed with `SIGHASH_NOINPUT` spending the translator transaction output.
> * Decker-Russell-Osuntokun state transaction, signed with `SIGHASH_NOINPUT` spending the update transaction output.

That is very much how I was planning to implement it anyway, using a
trigger transaction to separate timeout start and the actual
update/settlement pairs (cfr. eltoo paper Section 4.2). So for eltoo
there shouldn't be an issue here :-)

> The point regarding use of a commonly-known privkey to work around
> chaperone signatures is appropriate to the above, incidentally.  In
> short: this is a workaround, plain and simple, and one wonders the
> point of adding *either* chaperones *or* output tagging if we will, in
> practice, just work around them anyway.

Exactly, why introduce the extra burden of chaperone signatures or
output tagging if we're just going to sidestep it?

> Again, the *more* important point is that special blockchain
> constructions should only be used in the "bad" unilateral close case.
> In the cooperative case, we want to use simple plain
> bip-schnorr-signed outputs getting spent to further bip-schnor/Taproot
> SegWit v1 addresses, to increase the anonymity set of all uses of
> Decker-Russell-Osuntokun and other applications that might use
> `SIGHASH_NOINPUT` in some edge case (but which resolve down to simple
> bip-schnorr-signed n-of-n cases when the protocol is completed
> successfully by all participants).

While I do agree that we should keep outputs as unidentifiable as
possible, I am starting to question whether that is possible for
off-chain payment networks since we are gossiping about the existence of
channels and binding them to outpoints to prove their existence anyway.

Not the strongest argument I know, but there's little point in talking
ideal cases when we need to weaken that later again. 

>> Open questions
>>
>> ---------------
>>
>> The questions that remain to be addressed are the following:
>>
>> 1.  General agreement on the usefulness of noinput / anyprevoutanyscript /
>>     anyprevout. While at the CoreDev meeting I think everybody agreed that
>>     these proposals a useful, also beyond eltoo, not everybody could be
>>     there. I'd therefore like to elicit some feedback from the wider community.
>
> I strongly agree that `NOINPUT` is useful, and I was not able to attend CoreDev (at least, not with any human fleshbot already known to you --- I checked).

Great, good to know that I'm not shouting into the void, and that I'm
not just that crazy guy trying to get his hairbrained scheme to work :-)

>> 2.  Is there strong support or opposition to the chaperone signatures
>>     introduced in anyprevout / anyprevoutanyscript? I think it'd be best to
>>     formulate a concrete set of pros and contras, rather than talk about
>>     abstract dangers or advantages.
>
> No opposition, we will just work around this by publishing a common
> known private key to use for all chaperone signatures, since all the
> important security is in the `NOINPUT` signature anyway.
>
>>
>> 3.  The same for output tagging / explicit opt-in. What are the advantages and
>>     disadvantages?
>
> Strongly oppose, see above about my argument.
>
>>
>> 4.  Shall we merge BIP-118 and bip-anyprevout. This would likely reduce the
>>     confusion and make for simpler discussions in the end.
>
> Ambivalent, mildly support.
>
>>
>> 5.  Anything I forgot to mention :-)
>
> Cats are very interesting creatures, and are irrelevant to `SIGHASH_NOINPUT` discussion, but are extremely cute nonetheless.

Definitely agreed :+1:


  parent reply	other threads:[~2019-10-01 14:27 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-30 13:23 [bitcoin-dev] Continuing the discussion about noinput / anyprevout 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 [this message]
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
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=87tv8s7djq.fsf@gmail.com \
    --to=decker.christian@gmail.com \
    --cc=ZmnSCPxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=lightning-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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