public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Johnson Lau <jl2012@xbt•hk>
To: Russell O'Connor <roconnor@blockstream•io>,
	bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT
Date: Mon, 10 Dec 2018 03:13:34 +0800	[thread overview]
Message-ID: <702FE74C-119C-4D14-BCD3-85C4355356A2@xbt.hk> (raw)
In-Reply-To: <CAMZUoKkJdU0P_dVRvHn5zY6xUHYUptdK221ioQMp3FXZAerp3Q@mail.gmail.com>

The current proposal is that a 64-byte signature will be used for the default “signing all” sighash, and 65-byte for other sighash types. The space saved will allow a few more txs in a block, so I think it worths doing. However, this also makes witness weight estimation more difficult in multisig cases.

This idea of signing witness weight has been brought up before. I think the concern is the difficulty to estimate the witness weight for complex scripts, which need this feature most. So it will work when it is not needed, and will not work when it is needed.

Is there any script example that witness size malleability is unavoidable?

> On 7 Dec 2018, at 12:57 AM, Russell O'Connor via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> 
> One more item to consider is "signature covers witness weight".
> 
> While signing the witness weight doesn't completely eliminate witness malleability (of the kind that can cause grief for compact blocks), it does eliminate the worst kind of witness malleability from the user's perspective, the kind where malicious relay nodes increase the amount of witness data and therefore reduce the overall fee-rate of the transaction.  Generally users should strive to construct their Bitcoin Scripts in such a way that witness malleability isn't possible, but as you are probably aware, this can be quite difficult to achieve as Scripts become more complex and maybe isn't even possible for some complex Scripts.
> 
> Given the new fixed-sized signature of the Schnorr BIP, it becomes much easier to compute the final witness weight prior to signing.  In complex multi-party signing protocol, the final witness weight might not be known at signing time for everyone involved, so the "signature covers witness weight" ought to be optional.
> 
> 




  reply	other threads:[~2018-12-09 19:13 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-19 22:37 Pieter Wuille
2018-11-20 20:29 ` Anthony Towns
2018-11-21 11:20   ` Christian Decker
2018-11-21 17:55   ` Johnson Lau
2018-11-21 11:15 ` Christian Decker
2018-11-23  6:04   ` Anthony Towns
2018-11-23  9:40     ` Christian Decker
2018-11-24  8:13       ` Johnson Lau
2018-11-21 17:07 ` Russell O'Connor
2018-11-22 14:28   ` Johnson Lau
2018-11-22 16:23     ` Russell O'Connor
2018-11-22 20:52       ` Johnson Lau
2018-11-22 22:10         ` Russell O'Connor
2018-11-23 10:47           ` Johnson Lau
2018-11-23  5:03   ` Anthony Towns
2018-11-23 20:18     ` Russell O'Connor
2018-11-28  3:41 ` Pieter Wuille
2018-11-28  8:31   ` Johnson Lau
2018-11-29 17:00   ` Christian Decker
2018-11-29 18:29     ` Christian Decker
2018-12-06 16:57   ` Russell O'Connor
2018-12-09 19:13     ` Johnson Lau [this message]
2018-12-11 22:50       ` Russell O'Connor
2018-12-12 19:53         ` Johnson Lau
2018-12-13 16:50           ` Russell O'Connor
2018-12-13  0:05         ` Anthony Towns
2018-12-13 16:21           ` Russell O'Connor
2018-12-14  0:47             ` Anthony Towns
     [not found]         ` <CAAS2fgRma+Pw-rHJSOKRVBqoxqJ3AxHO9d696fWoa-sb17JEOQ@mail.gmail.com>
2018-12-13 16:34           ` Russell O'Connor
2018-12-09 22:41     ` David A. Harding
2018-12-11 15:36       ` Russell O'Connor
2018-12-11 17:47         ` David A. Harding
2018-12-12  9:42 ` Rusty Russell
2018-12-12 20:00   ` Johnson Lau
2018-12-12 23:49     ` Rusty Russell
2018-12-13  0:37       ` Rusty Russell
2018-12-14  9:30         ` Anthony Towns
2018-12-14 13:55           ` Johnson Lau
2018-12-17  3:10             ` Rusty Russell
2018-12-20 19:34               ` Johnson Lau
2018-12-20 23:17                 ` Rusty Russell
2018-12-21 18:54                   ` Johnson Lau
2018-12-23  4:26                     ` Anthony Towns
2018-12-23 16:33                       ` Johnson Lau
2018-12-24 12:01                         ` ZmnSCPxj
2018-12-24 21:23                           ` Johnson Lau
2018-12-16  6:55           ` Rusty Russell
2018-12-17 19:08             ` Johnson Lau
2018-12-18  4:22               ` Peter Todd
2018-12-19  0:39               ` Rusty Russell
2019-02-09  0:39                 ` Pieter Wuille
2018-12-13  0:24   ` Anthony Towns
2018-11-28  0:54 Bob McElrath
2018-11-28  8:40 ` Johnson Lau
2018-11-28 14:04   ` Bob McElrath

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=702FE74C-119C-4D14-BCD3-85C4355356A2@xbt.hk \
    --to=jl2012@xbt$(echo .)hk \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=roconnor@blockstream$(echo .)io \
    /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