Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 0AE02E2D;
	Thu,  3 Oct 2019 03:08:06 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
	[185.70.40.135])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1893019B;
	Thu,  3 Oct 2019 03:08:05 +0000 (UTC)
Date: Thu, 03 Oct 2019 03:07:55 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
	s=default; t=1570072082;
	bh=c1jwRu6M32Z/ioGrIp39YlIedrsqJxAXCElI/R5Rhfc=;
	h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
	Feedback-ID:From;
	b=fJErJ1a2XVts1cbivDUr0Xzu5D54ttHJYz9m3vbGkxpGL+GNlZCxnRmGVt2ciYalu
	oM1H2Lxz4hJhnZ1PZGP45865ZAc1V3YpwgpH+Ch6yqJkdgXWn7DbrRF2hrFTSkgjGF
	3ybwMO7UpdK+/fqRmXGjXbtk/pvaTnrNL42spZG0=
To: Anthony Towns <aj@erisian.com.au>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <iKVHkY_BWc4A9e7AiuGiyYUAu9TM4yGNlTL7HQklrw6_1pW4ZpwRd-qKLox7jpmQ8QgWrj3Ovrq9sDQijMD3Q_dNivchgNfxy8zcchFYkQ4=@protonmail.com>
In-Reply-To: <20191003014758.gtgfge5yokcxkfsj@erisian.com.au>
References: <87wodp7w9f.fsf@gmail.com>
	<20191001155929.e2yznsetqesx2jxo@erisian.com.au>
	<CR-etCjXB-JWkvecjDog4Pkq1SuLUgndtSrZo-V4f4EGcNXzNCeAHRvCZGrxDWw7aHVdDY0pAF92jNLb_Hct0bMb3ew6JEpB9AfIm1tSGaQ=@protonmail.com>
	<20191003014758.gtgfge5yokcxkfsj@erisian.com.au>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, DOS_RCVD_IP_TWICE_B, FREEMAIL_FROM,
	FROM_LOCAL_NOVOWEL, 
	RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Oct 2019 03:08:06 -0000

> > let me propose the more radical excision, starting with SegWit v1:
> >
> > -   Remove `SIGHASH` from signatures.
> > -   Put `SIGHASH` on public keys.
> >     <sighash> <pubkey> OP_SETPUBKEYSIGHASH
> >
>
> I don't think you could reasonably do this for key path spends -- if
> you included the sighash as part of the scriptpubkey explicitly, that
> would lose some of the indistinguishability of taproot addresses, and be
> more expensive than having the sighash be in witness data.

Nonexistence of sighash byte implies `SIGHASH_ALL`, and for offchain anyway=
 the desired path is to end up with an n-of-n MuSig `SIGHASH_ALL` signed mu=
tual close transaction.
Indeed we can even restrict keypath spends to not having a sighash byte and=
 just implicitly requiring `SIGHASH_ALL` with no loss of privacy for offcha=
in while attaining safety against `SIGHASH_NOINPUT` for MuSig and VSSS mult=
isignature adresses.


> So I think
> that means sighashes would still be included in key path signatures,
> which would make the behaviour a little confusingly different between
> signing for key path and script path spends.
>
> > This removes the problems with `SIGHASH_NONE` `SIGHASH_SINGLE`, as they=
 are allowed only if the output specifically says they are allowed.
>
> I don't think the problems with NONE and SINGLE are any worse than using
> SIGHASH_ALL to pay to "1*G" -- someone may steal the money you send,
> but that's as far as it goes. NOINPUT/ANYPREVOUT is worse in that if
> you use it, someone may steal funds from other UTXOs too -- similar
> to nonce-reuse. So I think having to commit to enabling NOINPUT for an
> address may make sense; but I don't really see the need for doing the
> same for other sighashes generally.

As the existing sighashes are not particularly used anyway, additional rest=
rictions on them are relatively immaterial.

>
> FWIW, one way of looking at a transaction spending UTXO "U" to address
> "A" is something like:
>
> -   "script" lets you enforce conditions on the transaction when you
>     create "A" [0]
>
> -   "sighash" lets you enforce conditions on the transaction when
>     you sign the transaction
>
> -   nlocktime, nsequence, taproot annex are ways you express conditions
>     on the transaction
>
>     In that view, "sighash" is actually an extremely simple scripting
>     language itself (with a total of six possible scripts).
>
>     That doesn't seem like a bad design to me, fwiw.


Only one of the scripts is widely used, another has an edge use it sucks at=
 (assurance contracts).

Does not seem to be good design, rather legacy cruft.

Regards,
ZmnSCPxj

>
>     Cheers,
>     aj
>
>     [0] "graftroot" lets you update those conditions for address "A" afte=
r
>     the fact
>