1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
|
Return-Path: <gmaxwell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 4B55AE23
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 Dec 2015 08:26:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com
[209.85.213.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D60ACE5
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 Dec 2015 08:26:04 +0000 (UTC)
Received: by mail-ig0-f180.google.com with SMTP id ph11so10136226igc.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 Dec 2015 00:26:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:date:message-id:subject
:from:to:cc:content-type;
bh=wr+aSn/S3CxcfBYtJHM4zKSJGpORzXbeUEmIpTrDfH8=;
b=JPILHrBE/rUs4hOOOaSYbzRDjn7UbUz/SM7JVaS1tNlcHIXQlJhienYwjLlpDlYagV
Ia76Rclo6xVKdIFgBK7u6p3RdMeaMJchovWv6zuK/VzD0a1zWWEw9QufCBM2Pfb27Ola
+qV5XVDZY//p0aIkTdjfYKnGgmSIrLmOQMlH4KZexJJK9HaJFUr31JYdngpzxVHUbvax
u84M1THDKWj/Jv1vt/lFh8jAYrTcZl9PZsG0hZEOYraxsZoGy9SlqtvYX2jmDqC3zAlf
h3Wzjw6ZCtsKBfXruswTXJFqPsYq+vKdcotEjb1WfDjkDCssdUaCQRXEQu25aOrhNZU5
ItmQ==
MIME-Version: 1.0
X-Received: by 10.50.56.114 with SMTP id z18mr14705062igp.62.1449735964412;
Thu, 10 Dec 2015 00:26:04 -0800 (PST)
Sender: gmaxwell@gmail.com
Received: by 10.107.192.70 with HTTP; Thu, 10 Dec 2015 00:26:04 -0800 (PST)
In-Reply-To: <b13f6152767473dcf44a1d8965fdd32c@xbt.hk>
References: <b13f6152767473dcf44a1d8965fdd32c@xbt.hk>
Date: Thu, 10 Dec 2015 08:26:04 +0000
X-Google-Sender-Auth: E7pjeHmCc0lNYzWkHDsZkyxILss
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
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Segregated Witness features wish list
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Dec 2015 08:26:05 -0000
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).
|
