public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Johnson Lau <jl2012@xbt.hk>
To: Peter Todd <pete@petertodd.org>
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Code Review: The Consensus Critical Parts of Segwit by Peter Todd
Date: Sun, 3 Jul 2016 03:20:42 +0800	[thread overview]
Message-ID: <9E7B8E07-4F98-42DD-8A35-C55DAF78271F@xbt.hk> (raw)
In-Reply-To: <20160702184350.GA16656@fedora-21-dvm>

[-- Attachment #1: Type: text/plain, Size: 2237 bytes --]


> 
>>> the fact that we do this has a rather odd result: a transaction spending a witness output with an unknown version is valid even if the transaction doesn’t have any witnesses!
>> 
>> I don’t see any reason to have such check. We simply leave unknown witness program as any-one-can-spend without looking at the witness, as described in BIP141.
> 
> It will lead to a special case in code that does things with witness
> transactions, as we can spend a witness output without a witness.

It is trivial to softfork a new rule to require the witness must not be empty for a witness output. However, does it really make the code simpler?
> 
> Thus you could summarize the argument for the P2PKH special case as "We don't
> want to make it possible to use 160-bit commitments for multisig, which _might_
> need 256-bit security. But we do want to special-case pubkeys to save a few
> bytes.”

Actually I would like to see even shorter hash and pubkey to be used. Storing 1 BTC for a few months does not really require the security level of P2PKH.

> 
>>> we haven’t explicitly ensured that signatures for the new signature hash can’t be reused for the old signature hash
>> 
>> How could that be? That’d be a hash collision.
> 
> Nope. The problem is it might not be a hash collission, if the actual bytes
> signed can be interpreted in two different ways, by different types of
> signature hashes.
> 
> This is the same reason the signmessage functionality prepends the message
> being signed with the "Bitcoin Signed Message:\n" magic string.
> 

In BIP143 sig, first 4 bytes is nVersion, and the next 32 bytes (hashPrevouts) is a hash of all prevouts. (in the case of ANYONECANPAY, the bytes following would be zero, as you proposed)

In the original sig, first 4 bytes in nVersion, next 4 bytes is number of inputs, and the next 32 bytes is a txid.

For a signature to be valid for both schemes, the last 28 bytes of the hashPrevouts must also be the first 28 bytes of a valid txid. This is already impossible. And this is just one of the many collisions required. In such case SHA256 would be insecure and adding a zero after the nVersion as you suggest would not be helpful at all.

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 671 bytes --]

  reply	other threads:[~2016-07-02 19:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-28 16:22 [bitcoin-dev] Code Review: The Consensus Critical Parts of Segwit by Peter Todd Johnson Lau
2016-07-02 18:43 ` Peter Todd
2016-07-02 19:20   ` Johnson Lau [this message]
2016-07-04 23:27     ` Peter Todd

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=9E7B8E07-4F98-42DD-8A35-C55DAF78271F@xbt.hk \
    --to=jl2012@xbt.hk \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=pete@petertodd.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