* [bitcoindev] CHECKSIGFROMSTACK(VERIFY/ADD)
@ 2024-11-14 22:02 Brandon Black
2024-11-15 10:14 ` 'moonsettler' via Bitcoin Development Mailing List
2024-11-15 14:57 ` Murch
0 siblings, 2 replies; 5+ messages in thread
From: Brandon Black @ 2024-11-14 22:02 UTC (permalink / raw)
To: bitcoindev
Hi list,
As we're working toward numbering and merge for the CHECKSIGFROMSTACK
(CSFS) BIP, there are 2 open questions[1] that may be worth resolving
before it is merged as a draft:
* Should CHECKSIGFROMSTACKVERIFY (CSFSV) be added to pre-tapscript?
The proposed opcode always evaluates BIP340 Schnorr signatures
regardless of script version, so making it available in earlier script
versions makes Schnorr signatures available on those script versions for
certain use cases.
My personal thinking in initially including CSFSV in earlier script
versions was basically that it's compatible with NOP forking, so why
not. Because LNHANCE includes CTV which is designed as a NOP compatible
upgrade, also including CSFSV fits well with CTV.
The other side of the argument is that we shouldn't include
compatibility with earlier script versions unless there's a concrete
benefit to doing so. For CTV, the possibility of bare CTV is a
compelling reason to add it to earlier script versions, but there's not
a similarly compelling reason to include CSFSV.
Using a scarce NOP to provide Schnorr signed commitments to earlier
scripts may not be worthwhile.
* Should we include CHECKSIGFROMSTACKADD?
Obviously, if script multisig is going to be a common use case for
checking signatures on stack data CHECKSIGFROMSTACKADD simplifies the
corresponding scripts by a few WU per key. As MuSig2 and FROST are
progressing in standardization and implementation, I do not expect
script multisig to be a dominant use for these opcodes, so I did not
include CSFSA initially.
Here the argument is somewhat the inverse of CSFSV on legacy: We have
many OP_SUCCESSes available, so the cost of allocating one for CSFSA is
low, and the benefit is that making script multisigs with CSFSA (such as
those produced by miniscript) is simpler and less error prone.
--
I would love to hear thoughts about both of these questions from the
list, and will update the BIP and implementations of CSFS(V/A) based on
your feedback.
Thanks much!
--Brandon
[1]: https://github.com/bitcoin/bips/pull/1535#issuecomment-2111195930
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/ZzZziZOy4IrTNbNG%40console.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoindev] CHECKSIGFROMSTACK(VERIFY/ADD)
2024-11-14 22:02 [bitcoindev] CHECKSIGFROMSTACK(VERIFY/ADD) Brandon Black
@ 2024-11-15 10:14 ` 'moonsettler' via Bitcoin Development Mailing List
2024-11-15 14:57 ` Murch
1 sibling, 0 replies; 5+ messages in thread
From: 'moonsettler' via Bitcoin Development Mailing List @ 2024-11-15 10:14 UTC (permalink / raw)
To: Brandon Black; +Cc: bitcoindev
Hi Brandon,
For what it's worth, I also think signature aggregation will be the dominant
form of CSFS use. LNhance at it's core is CTV + CSFS, and so it makes sense
to have both of those available in pre-tapscript.
No strong opinion on CHECKSIGFROMSTACKADD, agree with the general reasoning.
It's a bit weird to backport Schnorr this way, and the NOP upgrade path
leaving 3 elements on the stack is also unfortunate. On the other hand,
reverting CSFSV to use ECDSA in pre-tapscript would force us to consider
implementing script multisig, to do anything really worthwhile there.
BR,
moonsettler
Sent with Proton Mail secure email.
On Thursday, November 14th, 2024 at 11:02 PM, Brandon Black <freedom@reardencode•com> wrote:
> Hi list,
>
> As we're working toward numbering and merge for the CHECKSIGFROMSTACK
> (CSFS) BIP, there are 2 open questions[1] that may be worth resolving
> before it is merged as a draft:
>
> * Should CHECKSIGFROMSTACKVERIFY (CSFSV) be added to pre-tapscript?
>
> The proposed opcode always evaluates BIP340 Schnorr signatures
> regardless of script version, so making it available in earlier script
> versions makes Schnorr signatures available on those script versions for
> certain use cases.
>
> My personal thinking in initially including CSFSV in earlier script
> versions was basically that it's compatible with NOP forking, so why
> not. Because LNHANCE includes CTV which is designed as a NOP compatible
> upgrade, also including CSFSV fits well with CTV.
>
> The other side of the argument is that we shouldn't include
> compatibility with earlier script versions unless there's a concrete
> benefit to doing so. For CTV, the possibility of bare CTV is a
> compelling reason to add it to earlier script versions, but there's not
> a similarly compelling reason to include CSFSV.
>
> Using a scarce NOP to provide Schnorr signed commitments to earlier
> scripts may not be worthwhile.
>
>
> * Should we include CHECKSIGFROMSTACKADD?
>
> Obviously, if script multisig is going to be a common use case for
> checking signatures on stack data CHECKSIGFROMSTACKADD simplifies the
> corresponding scripts by a few WU per key. As MuSig2 and FROST are
> progressing in standardization and implementation, I do not expect
> script multisig to be a dominant use for these opcodes, so I did not
> include CSFSA initially.
>
> Here the argument is somewhat the inverse of CSFSV on legacy: We have
> many OP_SUCCESSes available, so the cost of allocating one for CSFSA is
> low, and the benefit is that making script multisigs with CSFSA (such as
> those produced by miniscript) is simpler and less error prone.
>
> --
>
> I would love to hear thoughts about both of these questions from the
> list, and will update the BIP and implementations of CSFS(V/A) based on
> your feedback.
>
> Thanks much!
>
> --Brandon
>
> [1]: https://github.com/bitcoin/bips/pull/1535#issuecomment-2111195930
>
> --
> You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/ZzZziZOy4IrTNbNG%40console.
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/83CBONdqGnLg2CP1tqiIPtOaG4Lx35UTqrmRBv2hagwsMlmZAMG0e165Wq_k43h-7pgS9yDdWx8qsAAB9AxQWr_RH_CaJdDZztNvXCGM6Rc%3D%40protonmail.com.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoindev] CHECKSIGFROMSTACK(VERIFY/ADD)
2024-11-14 22:02 [bitcoindev] CHECKSIGFROMSTACK(VERIFY/ADD) Brandon Black
2024-11-15 10:14 ` 'moonsettler' via Bitcoin Development Mailing List
@ 2024-11-15 14:57 ` Murch
2024-11-15 15:33 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
1 sibling, 1 reply; 5+ messages in thread
From: Murch @ 2024-11-15 14:57 UTC (permalink / raw)
To: bitcoindev
Hi everyone,
On 2024-11-14 17:02, Brandon Black wrote:
> * Should CHECKSIGFROMSTACKVERIFY (CSFSV) be added to pre-tapscript
> […]
> My personal thinking in initially including CSFSV in earlier script versions was basically that it's compatible with NOP forking, so why not.
If there is no compelling use case or concrete benefit, I don’t think "it’s compatible, why not" is convincing motivation, especially at the cost of a NOP.
On 2024-11-14 17:02, Brandon Black wrote:
> * Should we include CHECKSIGFROMSTACKADD?
I feel similar about this. If there is currently no demand for this, and future demand also seems unlikely, I would prefer a smaller, more focused set of changes.
Cheers,
Murch
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/c91269ac-e579-4089-bf9a-fdc076e34727%40murch.one.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoindev] CHECKSIGFROMSTACK(VERIFY/ADD)
2024-11-15 14:57 ` Murch
@ 2024-11-15 15:33 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2024-11-23 19:45 ` 'moonsettler' via Bitcoin Development Mailing List
0 siblings, 1 reply; 5+ messages in thread
From: 'Antoine Poinsot' via Bitcoin Development Mailing List @ 2024-11-15 15:33 UTC (permalink / raw)
To: Murch; +Cc: bitcoindev
To add to Murch's point, from my experience working with Script in general and
trying to estimate the cost of validation of legacy script as part of the
consensus cleanup in particular, i think we should refrain from modifying legacy
Script and further complicate reasoning about the worst case unless strictly
necessary.
Best,
Antoine
On Friday, November 15th, 2024 at 9:57 AM, Murch <murch@murch•one> wrote:
> Hi everyone,
>
> On 2024-11-14 17:02, Brandon Black wrote:
>
> > * Should CHECKSIGFROMSTACKVERIFY (CSFSV) be added to pre-tapscript
> > […]
> > My personal thinking in initially including CSFSV in earlier script versions was basically that it's compatible with NOP forking, so why not.
>
>
> If there is no compelling use case or concrete benefit, I don’t think "it’s compatible, why not" is convincing motivation, especially at the cost of a NOP.
>
> On 2024-11-14 17:02, Brandon Black wrote:
>
> > * Should we include CHECKSIGFROMSTACKADD?
>
>
> I feel similar about this. If there is currently no demand for this, and future demand also seems unlikely, I would prefer a smaller, more focused set of changes.
>
> Cheers,
> Murch
>
> --
> You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/c91269ac-e579-4089-bf9a-fdc076e34727%40murch.one.
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/nRFLHRhwXER56TrZy50tJ2HmvipjteXzPfz6mEs_VmyZ5sXDNVUIUniPppSphF5SOVCQmpRZSjmBN8_eIMZEbdFgl3vJn-8XSEmpAFmj5SM%3D%40protonmail.com.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoindev] CHECKSIGFROMSTACK(VERIFY/ADD)
2024-11-15 15:33 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
@ 2024-11-23 19:45 ` 'moonsettler' via Bitcoin Development Mailing List
0 siblings, 0 replies; 5+ messages in thread
From: 'moonsettler' via Bitcoin Development Mailing List @ 2024-11-23 19:45 UTC (permalink / raw)
To: Antoine Poinsot; +Cc: Murch, bitcoindev
Dear List,
Can anyone think of a reason to keep OP_CHECKSIGFROMSTACKVERIFY as NOP5 available
in legacy script?
Currently Brandon and I are leaning towards simply removing CSFSV from LNhance and
from the CSFS BIP.
Reasoning:
* CSFS is more likely to be used in Symmetry
* In case where CSFSV is desired OP_CSFS OP_VERIFY is perfectly workable.
* Simplifies code
* Don't have an actual use case for CSFSV in legacy rn
* Upgradeable NOPs are scarce
* Backporting tapscript would bring all functionality to legacy
BR,
moonsettler
Sent with Proton Mail secure email.
On Friday, November 15th, 2024 at 4:33 PM, 'Antoine Poinsot' via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> wrote:
> To add to Murch's point, from my experience working with Script in general and
> trying to estimate the cost of validation of legacy script as part of the
> consensus cleanup in particular, i think we should refrain from modifying legacy
> Script and further complicate reasoning about the worst case unless strictly
> necessary.
>
> Best,
> Antoine
>
> On Friday, November 15th, 2024 at 9:57 AM, Murch murch@murch•one wrote:
>
> > Hi everyone,
> >
> > On 2024-11-14 17:02, Brandon Black wrote:
> >
> > > * Should CHECKSIGFROMSTACKVERIFY (CSFSV) be added to pre-tapscript
> > > […]
> > > My personal thinking in initially including CSFSV in earlier script versions was basically that it's compatible with NOP forking, so why not.
> >
> > If there is no compelling use case or concrete benefit, I don’t think "it’s compatible, why not" is convincing motivation, especially at the cost of a NOP.
> >
> > On 2024-11-14 17:02, Brandon Black wrote:
> >
> > > * Should we include CHECKSIGFROMSTACKADD?
> >
> > I feel similar about this. If there is currently no demand for this, and future demand also seems unlikely, I would prefer a smaller, more focused set of changes.
> >
> > Cheers,
> > Murch
> >
> > --
> > You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
> > To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/c91269ac-e579-4089-bf9a-fdc076e34727%40murch.one.
>
>
> --
> You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/nRFLHRhwXER56TrZy50tJ2HmvipjteXzPfz6mEs_VmyZ5sXDNVUIUniPppSphF5SOVCQmpRZSjmBN8_eIMZEbdFgl3vJn-8XSEmpAFmj5SM%3D%40protonmail.com.
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/_p-Du0dVGx1_UqtSLb7UpQRrHWP0JVQOGFeZ3-W-m8eZNNshMsW_oFXw07nAZEnP-YZO6sBn9iF-RY7qK15jxCjQPBMc4LZ-4cesUuRose8%3D%40protonmail.com.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2024-11-23 19:48 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-11-14 22:02 [bitcoindev] CHECKSIGFROMSTACK(VERIFY/ADD) Brandon Black
2024-11-15 10:14 ` 'moonsettler' via Bitcoin Development Mailing List
2024-11-15 14:57 ` Murch
2024-11-15 15:33 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2024-11-23 19:45 ` 'moonsettler' via Bitcoin Development Mailing List
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox