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>
Subject: Re: [bitcoin-dev] ScriptPubkey consensus translation
Precedence: list

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