Re: [bitcoin-dev] ScriptPubkey consensus translation

[Mark Friedenbach <mark@friedenbach.org>]

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