From: Luke Dashjr <luke@dashjr.org>
To: Johnson Lau <jl2012@xbt.hk>
Date: Wed, 8 Jun 2016 16:45:10 +0000
User-Agent: KMail/1.13.7 (Linux/4.1.18-gentoo; KDE/4.14.16; x86_64; ; )
References: <A7E9BC23-6860-4B31-9D4E-11F771A5E581@xbt.hk>
	<201606080729.24789.luke@dashjr.org>
	<D192E876-1A4F-4B06-86F6-54F1BDEC857D@xbt.hk>
In-Reply-To: <D192E876-1A4F-4B06-86F6-54F1BDEC857D@xbt.hk>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201606081645.12598.luke@dashjr.org>
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP141 segwit consensus rule update: extension of
	witness program definition
Precedence: list

On Wednesday, June 08, 2016 8:23:51 AM Johnson Lau wrote:
> If someday 32 bytes hash is deemed to be unsafe, the txid would also be
> unsafe and a hard fork might be needed. Therefore, I don=E2=80=99t see ho=
w a
> witness program larger than 40 bytes would be useful in any case (as it is
> more expensive and takes more UTXO space). I think Pieter doesn=E2=80=99t=
 want to
> make it unnecessarily lenient.

There is no harm in being lenient, but it limits the ability to do softfork=
=20
upgrades in the future. I appreciate Pieter's concern that we'd need to do=
=20
more development and testing to go to this extreme, which is why I am only=
=20
asking the limit raised to 75 bytes.

Luke