Date: Mon, 4 Jul 2016 19:27:15 -0400
From: Peter Todd <pete@petertodd.org>
To: Johnson Lau <jl2012@xbt.hk>
Message-ID: <20160704232715.GA21569@fedora-21-dvm>
References: <8AE6D76F-7808-4897-9F44-A83790545EE4@xbt.hk>
	<20160702184350.GA16656@fedora-21-dvm>
	<9E7B8E07-4F98-42DD-8A35-C55DAF78271F@xbt.hk>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9"
Content-Disposition: inline
In-Reply-To: <9E7B8E07-4F98-42DD-8A35-C55DAF78271F@xbt.hk>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Code Review: The Consensus Critical Parts of
 Segwit by Peter Todd
Precedence: list


--PEIAKu/WMn1b1Hv9
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Jul 03, 2016 at 03:20:42AM +0800, Johnson Lau wrote:
> >>> the fact that we do this has a rather odd result: a transaction spend=
ing a witness output with an unknown version is valid even if the transacti=
on doesn=E2=80=99t have any witnesses!
> >>=20
> >> I don=E2=80=99t see any reason to have such check. We simply leave unk=
nown witness program as any-one-can-spend without looking at the witness, a=
s described in BIP141.
> >=20
> > 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.
>=20
> It is trivial to softfork a new rule to require the witness must not be e=
mpty for a witness output. However, does it really make the code simpler?

The Bitcoin Core codebase, no, but it does reduce the number of special cas=
es
other codebases have to contend with.

Probably not worth changing now, but it was I think a weird design choice to
make.

> > 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.=E2=80=9D
>=20
> Actually I would like to see even shorter hash and pubkey to be used. Sto=
ring 1 BTC for a few months does not really require the security level of P=
2PKH.

How short? 128 bits? 80 bits? 64 bits?

It's hard to know what's the point where you're going to risk massive losses
due to theft... and as we've seen with the DAO, those kinds of losses can l=
ead
to very undesirable pressure for devs to act as a central authority and
intervene.

> >>> we haven=E2=80=99t explicitly ensured that signatures for the new sig=
nature hash can=E2=80=99t be reused for the old signature hash
> >>=20
> >> How could that be? That=E2=80=99d be a hash collision.
> >=20
> > Nope. The problem is it might not be a hash collission, if the actual b=
ytes
> > signed can be interpreted in two different ways, by different types of
> > signature hashes.
> >=20
> > This is the same reason the signmessage functionality prepends the mess=
age
> > being signed with the "Bitcoin Signed Message:\n" magic string.
> >=20
>=20
> In BIP143 sig, first 4 bytes is nVersion, and the next 32 bytes (hashPrev=
outs) is a hash of all prevouts. (in the case of ANYONECANPAY, the bytes fo=
llowing would be zero, as you proposed)
>=20
> In the original sig, first 4 bytes in nVersion, next 4 bytes is number of=
 inputs, and the next 32 bytes is a txid.
>=20
> For a signature to be valid for both schemes, the last 28 bytes of the ha=
shPrevouts 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 s=
uggest would not be helpful at all.

Why isn't this carefully documented in the BIPs then?

Again, as I said in my summary:

    In a number of places we either have a belt, or suspenders, when given =
the
    importance of this code we=E2=80=99d rather have both a belt and suspen=
ders.

Tagged hashing is an excellent way to absolutely sure that signatures can't=
 be
reused in different contexts; if it happens to be overkill in a specific
context, the overhead of hashing another few bytes is trivial; the gain of
being absolutely sure you haven't missed a vulnerability can't be easily
dismissed.

Equally, I think in most cases simply XORing the digest obtained by hashing
with a magic tag prior to using it (e.g. by signing it) should be sufficient
for signature applications, and the overhead of doing that is ~zero.
Essentially you can think of the magic tag that's XORed with the raw digest=
 as
making clear the intent of the signature: "this is why I think I'm signing =
this
digest"

However, the XOR option does have one potentially big downside in other
contexts, like general use in committed data structures: it's incompatible =
with
timestamping schemes like OpenTimestamps that rely on all operations being
cryptographically secure.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--PEIAKu/WMn1b1Hv9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJXevDQAAoJEGOZARBE6K+yTbMH/jR3n+36qcYSD1knvABYJjIp
gr+9O2u0E82MFH5PMAuaD+ycuFPbgYleeh7gajrdMRdL2pgUzjERCVj29miaAHZw
BnRTUJmjazZiDa82Upsra8KWDkKvRuHyzpBP6ceUkGJSgkwlnwvwVFJDvm21Gi0B
aOe0e6wRdV/YH4Ix/pdZOUgQ1lojIw+4EPGjXtnbTdH9fhB5TyTC6QbltgmNPCUl
1MXYZOX3lI98Gip7L/l4SA22o62/kh8rqE9pASfwZVL9zI7zOmb5VLV4SvvMfzgO
kOL0mZiWKHUO055s0/wShUDtXguZSafcAxkuWYjBLZ+mxukz80Jh31Dp4GF32bE=
=1cb+
-----END PGP SIGNATURE-----

--PEIAKu/WMn1b1Hv9--