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 --]
next prev parent 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 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$(echo .)hk \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pete@petertodd$(echo .)org \
/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