Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1225149D for ; Sun, 1 Oct 2017 20:39:16 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pf0-f196.google.com (mail-pf0-f196.google.com [209.85.192.196]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4FADC467 for ; Sun, 1 Oct 2017 20:39:15 +0000 (UTC) Received: by mail-pf0-f196.google.com with SMTP id f84so3717722pfj.3 for ; Sun, 01 Oct 2017 13:39:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=friedenbach-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/xqh2X7ZwqJyJBM/v+rL88GJg/QtuRFK4us16alWSwk=; b=OO2isP94cw5Xf6ncoEQJym3ga3afr/ugDzgQ977++9efRLkQ2cjBpk92hJjgqiolBj SSUQ66XBUCaCKUGOmuFlyAdQ3cisH9NkY7RdPbYKSNYXjdWB2GjuE4R5eX3tjLeoisZy AkEg47fimD0KSbUL7O6uqjxQScetaBB3nPc6DD21NTGPYQTCZN0kR42p9NiQERD/6fQO +AxZLgvuAE41HwAYhongZEzB/DGaR/4ZaSh6sXTkelnj9RoV6b4ANNDrYgLbSh1L1/5X 7QCGSU8xaFAE+o6xkuCL3Ve0BNPcVx72njMdLO7CM0cpna8g6xhT/JHzE2PpQZkJCTTt Jizw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/xqh2X7ZwqJyJBM/v+rL88GJg/QtuRFK4us16alWSwk=; b=bN5TSK+tMhGvB0O7rE8nGVfsSQmu4sx3p+Hr0JXm4GkUjqQ+NdKCy+km9NVn+0y5pF fW7gQIdyPPV6wOGQUPOoIJ5LKRQi+yt/bi2FGmjP5JTLAXDHTn1LvDCh0AzdQYU3WmcO dymMcSkLj1j/MVkdjLA4x82v2E43UND6SRxia5xpwWQYc3RXriA/RnOwAoMDvoiPrqbJ 9dVNLRjNJguFEEaIAAlXeqfOIpxZrenNjZ0GH0EA7w/fQX7cvHT2l1p7aIBrwnaC7qTp zjJSZhdmK3x9vW3PKGP1BBM7ccN7/JTxWpnkn44TttjKLkd7ak6JDYg0zfqzFPsopSVt d5ww== X-Gm-Message-State: AHPjjUjm4H8dt7gGyr2M5StL0vrkS/vD/UnpRxCXQRo0oDmuIuxTLVQM kEPH9zxA0q23kT3Bp5x6nnevnDcNQYY= X-Google-Smtp-Source: AOwi7QChZLOh+RXAFPAUCGVWUiHhZ5AM5ipNnpZAkIB7B9Vfftp83biPi+BG4mof+Zg7CtNk+ZRkDw== X-Received: by 10.98.159.76 with SMTP id g73mr12731341pfe.293.1506890354777; Sun, 01 Oct 2017 13:39:14 -0700 (PDT) Received: from [192.168.1.125] (c-73-241-30-225.hsd1.ca.comcast.net. [73.241.30.225]) by smtp.gmail.com with ESMTPSA id d7sm1238712pgf.20.2017.10.01.13.39.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Oct 2017 13:39:13 -0700 (PDT) Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (1.0) From: Mark Friedenbach X-Mailer: iPhone Mail (15A402) In-Reply-To: Date: Sun, 1 Oct 2017 13:39:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201710010113.30518.luke@dashjr.org> <5A220A8D-3A85-49D0-8DB2-6BDEC362EAEB@friedenbach.org> <201710010247.42180.luke@dashjr.org> <460EDF1F-2BFD-4DBE-A921-73469C2EA9B9@friedenbach.org> To: Russell O'Connor X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MIME_QP_LONG_LINE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Version 1 witness programs (first draft) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Oct 2017 20:39:16 -0000 > On Oct 1, 2017, at 12:41 PM, Russell O'Connor wr= ote: >=20 > Creating a Bitcoin script that does not allow malleability is difficult an= d requires wasting a lot of bytes to do so, typically when handling issues a= round non-0-or-1 witness values being used with OP_IF, and dealing with non-= standard-zero values, etc. Script validation flags of the correct place to do this. We already have pol= icy validation flags that check for these things. They were not made consens= us rules with Segwit v0 mainly due to concern over scope creep in an already= large overhaul, of my memory is correct. Script versions and quadratic hash= ing fixes where the minimum necessary to allow segwit to activate safely whi= le still enabling future upgrades that would otherwise have been hard forks.= We knew that we would be later changing the EC signature scheme to be somet= hing that supported signature aggregation, and that would be more appropriat= e time to discuss such changes. As we are considering to do now (although wi= tness versions means we don=A1=AFt need to omnibus the script upgrade here e= ither, so a v1 before signature aggregation is ready is fine IMHO). In any case if there is any general witness malleability due to opcode seman= tics that it=A1=AFs not fixed by one of our existing policy flags, that is a= bug and I would encourage you to report it. > I'll argue that I don't want my counter-party going off and using a very d= eeply nested key in order to subvert the fee rate we've agreed upon after I'= ve signed my part of the input. If we are doing multi-party signing of inpu= ts we need to communicate anyways to construct the transaction. I see no pr= oblem with requiring my counter-party to choose their keys before I sign so t= hat I know up front what our fee rate is going to be. If they lose their ke= ys and need a backup, they should have to come back to me to resign in order= that we can negotiate a new fee rate for the transaction and who is going t= o be covering how much of the fee and on which inputs. Arguing that every single user should be forced to restart an interactive si= gning session. That=A1=AFs a very strong statement based on something that I= would say is a preference that depends on circumstances. What about an optional commitment to witness size in bytes? The value zero m= eaning =A1=B0I don=A1=AFt care.=A1=B1 I would argue that it should be a maxi= mum however, and therefor serialized as part of the witness. The serializati= on of this would be very compact (1 plus the difference between actual and m= aximum, with zero meaning not used.)=