Gregory Maxwell [ARCHIVE] on Nostr: 📅 Original date posted:2015-01-25 📝 Original message:On Sun, Jan 25, 2015 at ...
📅 Original date posted:2015-01-25
📝 Original message:On Sun, Jan 25, 2015 at 2:34 PM, Pieter Wuille <pieter.wuille at gmail.com> wrote:
> * Add it to the softfork now, and be done with it.
Initially I was of the opinion that we couldn't do that, because
soft-forks which hit transactions many nodes would relay+mine creates
a forking risk... but with the realization that imbalanced R/S plus
checksig-not would only be work with 0.10rc/git changed my mind.
Unlike two years ago miners no longer appear to be racing the bleeding
edge, and it's never show up in a release. Obviously the next RC would
also make those non-standard. And then we'll have some non-trivial
amount of time before the soft-fork activates for whatever stragglers
there are on 0.10 prerelease code to update. The deployment of the
soft-fork rules themselves will already drive people to update.
In terms of being robust to implementation differences, not permitting
overlarge R/S is obviously prudent.
So I think we should just go ahead with R/S length upper bounds as
both IsStandard and in STRICTDER.
📝 Original message:On Sun, Jan 25, 2015 at 2:34 PM, Pieter Wuille <pieter.wuille at gmail.com> wrote:
> * Add it to the softfork now, and be done with it.
Initially I was of the opinion that we couldn't do that, because
soft-forks which hit transactions many nodes would relay+mine creates
a forking risk... but with the realization that imbalanced R/S plus
checksig-not would only be work with 0.10rc/git changed my mind.
Unlike two years ago miners no longer appear to be racing the bleeding
edge, and it's never show up in a release. Obviously the next RC would
also make those non-standard. And then we'll have some non-trivial
amount of time before the soft-fork activates for whatever stragglers
there are on 0.10 prerelease code to update. The deployment of the
soft-fork rules themselves will already drive people to update.
In terms of being robust to implementation differences, not permitting
overlarge R/S is obviously prudent.
So I think we should just go ahead with R/S length upper bounds as
both IsStandard and in STRICTDER.