diff options
| author | Mark Friedenbach <mark@friedenbach.org> | 2018-01-18 13:00:03 -0800 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2018-01-18 21:00:07 +0000 |
| commit | 823052ab05ea415afd37d785e8be6f142f3caafe (patch) | |
| tree | f5a52dad7eee06f40b5c23f00a24bba08333cc3a /65/3035ec434b668c55cf64a6ab5a15297f34f1dd | |
| parent | da51a0c43b9d539a1c1f6e1a4a97f2d8dda62c3b (diff) | |
| download | pi-bitcoindev-823052ab05ea415afd37d785e8be6f142f3caafe.tar.gz pi-bitcoindev-823052ab05ea415afd37d785e8be6f142f3caafe.zip | |
Re: [bitcoin-dev] ScriptPubkey consensus translation
Diffstat (limited to '65/3035ec434b668c55cf64a6ab5a15297f34f1dd')
| -rw-r--r-- | 65/3035ec434b668c55cf64a6ab5a15297f34f1dd | 130 |
1 files changed, 130 insertions, 0 deletions
diff --git a/65/3035ec434b668c55cf64a6ab5a15297f34f1dd b/65/3035ec434b668c55cf64a6ab5a15297f34f1dd new file mode 100644 index 000000000..41aed95dc --- /dev/null +++ b/65/3035ec434b668c55cf64a6ab5a15297f34f1dd @@ -0,0 +1,130 @@ +Return-Path: <mark@friedenbach.org> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 5646FE08 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 18 Jan 2018 21:00:06 +0000 (UTC) +Received: by mail-pf0-f174.google.com with SMTP id e76so15614364pfk.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <mark@friedenbach.org> +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: <CAAS2fgQa8hXO1VsXUnUGnfu17dM0B-Jtfa7TNW=O3M8Mt=t2eQ@mail.gmail.com> +To: Gregory Maxwell <greg@xiph.org>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +In-Reply-To: <CAAS2fgQa8hXO1VsXUnUGnfu17dM0B-Jtfa7TNW=O3M8Mt=t2eQ@mail.gmail.com> +Message-Id: <D41C805A-726C-40E6-8760-44D411E9E47F@friedenbach.org> +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 <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, 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 = +<bitcoin-dev@lists.linuxfoundation.org> 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 + + |