From: Gregory Maxwell <greg@xiph•org>
To: jl2012@xbt•hk
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Segregated Witness features wish list
Date: Thu, 10 Dec 2015 08:26:04 +0000 [thread overview]
Message-ID: <CAAS2fgR0X1+-0UTxFWeRba84q3nz1aNHgP4jyw1Gxm+QxH3igg@mail.gmail.com> (raw)
In-Reply-To: <b13f6152767473dcf44a1d8965fdd32c@xbt.hk>
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).
next prev parent reply other threads:[~2015-12-10 8:26 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-10 6:47 jl2012
2015-12-10 8:26 ` Gregory Maxwell [this message]
2015-12-10 8:28 ` Bryan Bishop
2015-12-10 9:51 ` Gregory Maxwell
2015-12-13 15:25 ` jl2012
2015-12-13 18:07 ` Pieter Wuille
2015-12-13 18:41 ` jl2012
2015-12-10 12:54 ` Tamas Blummer
2015-12-12 0:43 ` Jannes Faber
2015-12-13 20:34 ` Rusty Russell
2015-12-14 11:44 ` Jonathan Toomim
2015-12-14 12:32 Adam Back
2015-12-14 12:50 ` Jonathan Toomim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAS2fgR0X1+-0UTxFWeRba84q3nz1aNHgP4jyw1Gxm+QxH3igg@mail.gmail.com \
--to=greg@xiph$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jl2012@xbt$(echo .)hk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox