iris
Post
View thread root โ†’
User Avatar
Fair Opossum
๐Ÿ“… Original date posted:2018-11-23 ๐Ÿ“ Original message:On Wed, Nov 21, 2018 at 12:07:30PM -0500, Russell O'Connor via bitcoin-dev wrote: > Given that we want to move away from OP_CODESEPARATOR, because each call to > this operation effectively takes O(script-size) time, we need a replacement for > the functionality it currently provides.  While perhaps the original motivation > for OP_CODESEPARTOR is surrounded in mystery, it currently can be used (or > perhaps abused) for the task of creating signature that covers, not only which > input is being signed, but which specific branch within that input Script code > is being signed for. Would it be sufficient to sign the position within the script of the last OP_CODESEPARATOR? That is, if your script is: DUP DUP CHECKSIG CODESEP CHECKSIG CODESEP CHECKSIG with the idea being that it can be spent by providing any pub key and three different signatures by that key, with the first sig committing to a "codesep position" of 0, the second a "codesep position" of 4, and the third a "codesep position" of 6? In each case, the signature also commits to the full (possibly masked) script as well. I think that covers all the behaviour you can currently achieve with CODESEP (which is pretty limited since every sig effectively commits to the full redeem script, and you can't commit to subsets of the signature/witness), and it keeps the things you can do with the various features a bit orthogonal: NOINPUT -- lets the sig apply to different transactions OP_MASK -- lets the different txes have variations in the script the sig applies to CODESEP -- lets you require different sigs for different parts of a single script MAST[0] -- provides alternative scripts, doesn't affect sigs IF/etc -- provides control flow within a script, doesn't affect sigs Cheers, aj [0] (I think I'm going to claim "MAST" stands for "merkelized alternative script tree" these days, since they're not "abstract syntax trees")
0
0
User Avatar
Russell O'Connor [ARCHIVE]
๐Ÿ“… Original date posted:2018-11-23 ๐Ÿ“ Original message:On Fri, Nov 23, 2018 at 12:03 AM Anthony Towns <aj at erisian.com.au> wrote: > On Wed, Nov 21, 2018 at 12:07:30PM -0500, Russell O'Connor via bitcoin-dev > wrote: > > Given that we want to move away from OP_CODESEPARATOR, because each call > to > > this operation effectively takes O(script-size) time, we need a > replacement for > > the functionality it currently provides. While perhaps the original > motivation > > for OP_CODESEPARTOR is surrounded in mystery, it currently can be used > (or > > perhaps abused) for the task of creating signature that covers, not only > which > > input is being signed, but which specific branch within that input > Script code > > is being signed for. > > Would it be sufficient to sign the position within the script of the > last OP_CODESEPARATOR? That is, if your script is: > > I think that covers all the behaviour you can currently achieve with > CODESEP (which is pretty limited since every sig effectively commits > to the full redeem script, and you can't commit to subsets of the > signature/witness), and it keeps the things you can do with the various > features a bit orthogonal: > Thanks for bringing this up. I was thinking the same thing as well, that yes that should be sufficient to cover the semantics of OP_CODESEPARATOR. Though to be more precise you would sign the position of the last _executed_ OP_CODESEPARATOR. That said, while I agree the above is a superior realization of the OP_CODESEPARATOR, given that we are probably going to support OP_CODESEPARATOR inside legacy P2SH scripts indefinitely, it is probably better to keep the existing akward implementation of OP_CODESEPARATOR in future versions of Script. (At least until we decide to stop mangling the Script consensus code with more and more flag combinations and decide it is better to cut and paste code for new versions of Script to help ensure we don't make consensus changes to legacy behaviour). > [0] (I think I'm going to claim "MAST" stands for "merkelized alternative > script tree" these days, since they're not "abstract syntax trees") > :thumbs-up: Sorry for hijacking the thread about OP_MASK and friends. -------------- next part -------------- An HTML attachment was scrubbed... URL: <lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181123/d6f9489a/attachment-0001.html>
0
0