> On 8 Jun 2016, at 15:29, Luke Dashjr <luke@dashjr.org> wrote:
> 
> On Wednesday, June 08, 2016 5:57:36 AM Johnson Lau via bitcoin-dev wrote:
>> Why not make it even bigger, e.g. 75 bytes?
> 
> I don't see a sufficient answer to this question. Pieter explained why >75
> would be annoying, but 75 seems like it should be fine.
> 
>> In any case, since scripts with a 1-byte push followed by a push of >40
>> bytes remain anyone-can-spend, we always have the option to redefine them
>> with a softfork.
> 
> It's not that simple, since this is preventing use of the witness field for
> such scripts. With this limit in place, any such a softfork would suddenly
> require either two different witness commitments, or disabling the previous
> witness transaction format.
> 
> Luke

This is exactly why I proposed to extend the definition. My initial proposal was extending it to 33 bytes to effectively allow 16*256 new script versions, assuming we will keep using 32 bytes program hash.

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’t see how 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’t want to make it unnecessarily lenient.