On Thu, Dec 10, 2015 at 6:47 AM, jl2012--- via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > It seems the current consensus is to implement Segregated Witness. SW opens > many new possibilities but we need a balance between new features and > deployment time frame. I'm listing by my priority:
> 2. Deployment time frame: I prefer as soon as possible, even if none of the > following new features are implemented. Thanks, I agree there. A point to keep in mind: Segregated Witness was specifically designed to make script changes / improvements / additions / total rewrites no harder to do _after_ SW then they would be do do along with it. For many people the "ah ha! lets do this" was realizing it could be a pretty clean soft-fork. For me, it was realizing that we could structure Segwit in a way that radically simply future script updates ... and in doing so avoid a getting trapped by a rush to put in every script update someone wants. This is achieved by having the 'version' byte(s) at the start of the witness program. If the witness program prefix is unrecognized it means RETURN TRUE. This recaptures the behavior that seems to have been intended by OP_VER in the earliest versions of the software, but actually works instead of giving every user the power to hardfork the system at any time. :) This escapes much of the risk in script changes, as we no longer need to worry about negation, or other interactions potentially breaking things. A new version flag can have its whole design crafted as if it were being created on a clean slate. Optimizing layout and such I think makes sense, but I think we should consider any script enhancements completely off the table for SW; otherwise the binding will delay deployment and increase complexity. I want most of those things too (a couple I disagree with) and a few of them we could do quite quickly-- but no need to bind them up; post SW and esp with version bits we could deploy them quite rapidly and on their own timeframes. > Multiplication and division may still considered to be risky and not very > useful? Operations like these make sense with fixed with types, when they are over arbitrary bignums, they're a complexity nightmare... as demonstrated by Bitcoin. :) RE: OP_DUPTOALTSTACK yea, I've wanted that several times (really I've been sad that there isn't just a stack flag on every manipulation instruction). _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
