* [bitcoin-dev] ScriptPubkey consensus translation
@ 2018-01-18 19:30 Gregory Maxwell
2018-01-18 19:56 ` CryptAxe
2018-01-18 21:00 ` Mark Friedenbach
0 siblings, 2 replies; 3+ messages in thread
From: Gregory Maxwell @ 2018-01-18 19:30 UTC (permalink / raw)
To: Bitcoin Dev
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?
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] ScriptPubkey consensus translation
2018-01-18 19:30 [bitcoin-dev] ScriptPubkey consensus translation Gregory Maxwell
@ 2018-01-18 19:56 ` CryptAxe
2018-01-18 21:00 ` Mark Friedenbach
1 sibling, 0 replies; 3+ messages in thread
From: CryptAxe @ 2018-01-18 19:56 UTC (permalink / raw)
To: Gregory Maxwell, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2215 bytes --]
Technically the change would be an improvement. People should be allowed to
opt-in to systems and big changes like that though, not have developers
change what their outputs mean or open them up to new security risks on
their behalf.
On Jan 18, 2018 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
>
[-- Attachment #2: Type: text/html, Size: 2955 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] ScriptPubkey consensus translation
2018-01-18 19:30 [bitcoin-dev] ScriptPubkey consensus translation Gregory Maxwell
2018-01-18 19:56 ` CryptAxe
@ 2018-01-18 21:00 ` Mark Friedenbach
1 sibling, 0 replies; 3+ messages in thread
From: Mark Friedenbach @ 2018-01-18 21:00 UTC (permalink / raw)
To: Gregory Maxwell, Bitcoin Protocol Discussion
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-01-18 21:00 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-18 19:30 [bitcoin-dev] ScriptPubkey consensus translation Gregory Maxwell
2018-01-18 19:56 ` CryptAxe
2018-01-18 21:00 ` Mark Friedenbach
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox