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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
