> On 8 Jun 2016, at 15:29, Luke Dashjr <l...@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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
