Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5646FE08 for ; Thu, 18 Jan 2018 21:00:07 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pf0-f174.google.com (mail-pf0-f174.google.com [209.85.192.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 388C9171 for ; Thu, 18 Jan 2018 21:00:06 +0000 (UTC) Received: by mail-pf0-f174.google.com with SMTP id e76so15614364pfk.1 for ; Thu, 18 Jan 2018 13:00:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=friedenbach-org.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=sayvxnOgJtaao51vot7Q+0GrOUzCBEc3KZG57xy5eb4=; b=kGJRtHEhGIjPkEONj1DzMDyC35sObml3M+/U5tAwgkYhSmI2gVeCcZSyuc/eUs7YIK K/v1xGODm/s06wRGNJcAjZUKLDpv5qYI8AsKED3HPHsna06uoWqt3DIH5JVFmNGOPxe3 QMUxhAMDXQ2PiKeYdCRy4yUAyl9/iRI70saubrrFOU5+vHsZBFBFIy0JiQJjNALnVvH2 lHTW+CDFK1OQKQaUPVYMA3nmUEldJXGy9q1CRCTDqXCXVHazWguU1M9B86+GPRovZc4P Lo2SVjpUrhCkpD7bUZSIdddWiTakFBT+2DH+GLogOjvUfatlpk47Xf1sd/SkyYtZWCzM vw5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=sayvxnOgJtaao51vot7Q+0GrOUzCBEc3KZG57xy5eb4=; b=MryP/Y3CM2+Bh9vqYPgnIxdswwbR9SoeLbwLmHEiVKSwiAT8UoIN1G1Uq8df3mtyTU CVabhdey9wvK/cLalbj73Oj2l2oL0PKWXjrW2xZjdCbLaKz/c92/mj7c98PtUz2aj8aZ ARZEWxN9oX8FXt/5XBcSUf60lw1qEhi3h4mWI9v/28ThuxABwBVA/Y7dqa/TZqWUEV+I lqBbVtWDnOcg4hnAleyBu3xn1N1xT+67Zhdwu1vmzdUvEaJtC3Hw5U017+wijZMHfv1E cOR6xZzhaIu+3cDWKJ5mNxxXslTO16v7G0anJnES9+W0pQsJ5uKULEaldG/T4zQ7j1AM HWGA== X-Gm-Message-State: AKwxytfyKLoHJLm+zKvbcRMvpPdGgZ/qsTvIv8a06keibiDEWMTXnldj XzFWqTExFgLEgef/rcktLi11yCxjC4g= X-Google-Smtp-Source: ACJfBotkh1JyaGnkKzjIZTfwgVj7yVV4kPgm+sS5XtvL35IJw8XqiuzKzZcbZEoeX2Oj/wh+PUH9KA== X-Received: by 2002:a17:902:8a97:: with SMTP id p23-v6mr402196plo.74.1516309205662; Thu, 18 Jan 2018 13:00:05 -0800 (PST) Received: from ?IPv6:2601:646:8080:4dbb:9a2:1c1e:aaf8:7e8c? ([2601:646:8080:4dbb:9a2:1c1e:aaf8:7e8c]) by smtp.gmail.com with ESMTPSA id u195sm12770517pgb.64.2018.01.18.13.00.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jan 2018 13:00:05 -0800 (PST) From: Mark Friedenbach Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 18 Jan 2018 13:00:03 -0800 References: To: Gregory Maxwell , Bitcoin Protocol Discussion In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.5.20) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 18 Jan 2018 21:38:51 +0000 Subject: Re: [bitcoin-dev] ScriptPubkey consensus translation 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: Thu, 18 Jan 2018 21:00:07 -0000 The downsides could be mitigated somewhat by only making the dual = interpretation apply to outputs older than a cutoff time after the = activation of the new feature. For example, five years after the initial = activation of the sigagg soft-fork, the sigagg rules will apply to = pre-activation UTXOs as well. That would allow old UTXOs to be spent = more cheaply, perhaps making some dust usable again, but anyone who = purposefully sent funds to old-style outputs after the cutoff are not = opened up to the dual interpretation. > On Jan 18, 2018, at 11:30 AM, Gregory Maxwell via bitcoin-dev = wrote: >=20 > A common question when discussing newer more efficient pubkey types-- > like signature aggregation or even just segwit-- is "will this thing > make the spending of already existing outputs more efficient", which > unfortunately gets an answer of No because the redemption instructions > for existing outputs have already been set, and don't incorporate > these new features. >=20 > This is good news in that no one ends up being forced to expose their > own funds to new cryptosystems whos security they may not trust. When > sigagg is deployed, for example, any cryptographic risk in it is borne > by people who opted into using it. >=20 > Lets imagine though that segwit-with-sigagg has been long deployed, > widely used, and is more or less universally accepted as at least as > good as an old P2PKH. >=20 > In that case, it might be plausible to include in a hardfork a > consensus rule that lets someone spend scriptPubkey's matching > specific templates as though they were an alternative template. So > then an idiomatic P2PKH or perhaps even a P2SH-multisig could be spent > as though it used the analogous p2w-sigagg script. >=20 > The main limitation is that there is some risk of breaking the > security assumptions of some complicated external protocol e.g. that > assumed that having a schnorr oracle for a key wouldn't let you spend > coins connected to that key. This seems like a pretty contrived > concern to me however, and it's one that can largely be addressed by > ample communication in advance. (E.g. discouraging the creation of > excessively fragile things like that, and finding out if any exist so > they can be worked around). >=20 > Am I missing any other arguments? > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev