From: Christian Decker <decker.christian@gmail•com>
To: Johnson Lau <jl2012@xbt•hk>
Cc: bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] SIGHASH2 for version 1 witness programme
Date: Mon, 03 Sep 2018 15:53:33 +0200 [thread overview]
Message-ID: <87in3mlmaq.fsf@gmail.com> (raw)
In-Reply-To: <23B1C9E3-9C94-43A3-A543-0AF9A8C10C7E@xbt.hk>
Johnson Lau <jl2012@xbt•hk> writes:
> Great, I’ll revise it.
>
> Follow-up questions:
>
> 1. Is there any useful case which one would like to use NOINPUT with
> scriptCode and/or scriptPubKey committed? (Note that with
> taproot/MAST, scriptCode and scriptPubKey are not
> interchangeable. scriptPubKey commits to all branches, and scriptCode
> is just one script branch). If yes, we could make this configurable.
There is the poor man's malleability fix that you get if you make only
the previous outpoint rewritable, but that use-case is better covered by
segwit already, and since both of our proposals would be for segwit
outputs only, I don't see a point in doing that.
> 2. Which of the following approaches is better?
> A) sign scriptPubKey in every cases except NOINPUT
> B) sign the type (P2SH-segwit vs. Native-segwit) of scriptPubKey in every cases, including NOINPUT
> C) all of the above
> D) none of the above
What do we effectively gain by committing to the scriptPubkey type? Is
the concern here that we might run into ambiguity about whether this is
a MAST, P2SH, or similar output, allowing an attacker to sideload
unwanted effects?
> Option B is very easy to implement as SignatureHash() could
> distinguish the type by the size of scriptSig in TxTo. Option A is
> more complicated as GenericTransactionSignatureChecker needs to know
> the scriptPubKey.
>
> If the only reason for doing this is to allow hardware wallet to
> distinguish the segwit type, option B is probably enough. This is also
> compatible with eltoo.
Agreed on compatibility :-)
> Option A is useful when a hardware wallet reuses the same public key
> in different scripts, but it couldn’t be applied to NOINPUT
>
> 3. Is the proposed DUALOUTPUT somehow useful for eltoo? Eltoo use
> NOINPUT|SINGLE to allow fee pumping, since it is an
> one-input-one-output tx. This is not possible with the existing LN as
> the tx is one-input-two-output. If we had DUALOUTPUT which signs the
> matched and last output, fee-pumping would be possible in the existing
> LN.
That's a very strange concept, but it strongly relies on the structure
of the commitment, having two outputs. As soon as we have HTLCs included
in the commitment we no longer have 2 outputs (2 for the endpoints, and
1 as a base for the two-phase HTLC resolution), so this would be a
rather brittle fix or would require major restructuring of LN imho.
Cheers,
Christian
prev parent reply other threads:[~2018-09-03 13:53 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-31 18:35 Johnson Lau
2018-06-01 15:03 ` Russell O'Connor
2018-06-01 17:03 ` Johnson Lau
2018-06-01 18:15 ` Russell O'Connor
2018-06-01 18:45 ` Johnson Lau
2018-07-02 18:23 ` Gregory Maxwell
2018-08-30 20:38 ` Johnson Lau
2018-08-30 20:51 ` Christian Decker
2018-08-31 7:42 ` Johnson Lau
2018-09-03 13:53 ` Christian Decker [this message]
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=87in3mlmaq.fsf@gmail.com \
--to=decker.christian@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jl2012@xbt$(echo .)hk \
/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