From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4B55AE23 for ; 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 ; Thu, 10 Dec 2015 08:26:04 +0000 (UTC) Received: by mail-ig0-f180.google.com with SMTP id ph11so10136226igc.1 for ; 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: References: Date: Thu, 10 Dec 2015 08:26:04 +0000 X-Google-Sender-Auth: E7pjeHmCc0lNYzWkHDsZkyxILss Message-ID: From: Gregory Maxwell 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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).