Re: [bitcoin-dev] ScriptPubkey consensus translation

From: Mark Friedenbach <mark@friedenbach•org>
To: Gregory Maxwell <greg@xiph•org>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] ScriptPubkey consensus translation
Date: Thu, 18 Jan 2018 13:00:03 -0800	[thread overview]
Message-ID: <D41C805A-726C-40E6-8760-44D411E9E47F@friedenbach.org> (raw)
In-Reply-To: <CAAS2fgQa8hXO1VsXUnUGnfu17dM0B-Jtfa7TNW=O3M8Mt=t2eQ@mail.gmail.com>

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:
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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).
> 
> Am I missing any other arguments?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev