public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Anthony Towns <aj@erisian.com.au>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
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
Date: Thu, 3 Oct 2019 11:47:58 +1000	[thread overview]
Message-ID: <20191003014758.gtgfge5yokcxkfsj@erisian.com.au> (raw)
In-Reply-To: <CR-etCjXB-JWkvecjDog4Pkq1SuLUgndtSrZo-V4f4EGcNXzNCeAHRvCZGrxDWw7aHVdDY0pAF92jNLb_Hct0bMb3ew6JEpB9AfIm1tSGaQ=@protonmail.com>

On Wed, Oct 02, 2019 at 02:03:43AM +0000, ZmnSCPxj via Lightning-dev wrote:
> So 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. 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.

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.

Cheers,
aj

[0] "graftroot" lets you update those conditions for address "A" after
    the fact


  reply	other threads:[~2019-10-03  1:48 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
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     ` Anthony Towns [this message]
2019-10-03  3:07       ` [bitcoin-dev] [Lightning-dev] " 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=20191003014758.gtgfge5yokcxkfsj@erisian.com.au \
    --to=aj@erisian.com.au \
    --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