MIME-Version: 1.0
Sender: gmaxwell@gmail.com
In-Reply-To: <b13f6152767473dcf44a1d8965fdd32c@xbt.hk>
References: <b13f6152767473dcf44a1d8965fdd32c@xbt.hk>
Date: Thu, 10 Dec 2015 08:26:04 +0000
Message-ID: <CAAS2fgR0X1+-0UTxFWeRba84q3nz1aNHgP4jyw1Gxm+QxH3igg@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
To: jl2012@xbt.hk
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Segregated Witness features wish list
Precedence: list

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).