📅 Original date posted:2019-05-21
📝 Original message:Regarding Tapscript, the specification calls for the final value of the
stack being a single non-false value:
The tapscript is executed according to the rules in the following section,
> with the initial stack as input
> II. If the execution results in anything but exactly one element on
> the stack which evaluates to true with CastToBool(), fail.
>
Perhaps it is worth taking this opportunity here to remove a minor wart of
the Script language and instead require the stack to be exactly empty upon
completion.
In addition to removing a potential malleability vector, I expect it would
simplify development of Bitcoin Script. A rule requiring an empty stack
means that the conjunction (logical and) of two policies can be implemented
by the simple concatenation of Bitcoin Scripts. This combined with the
taproot ability to form the disjunction (logical or) of policies by having
multiple Merkle branches, means that the translation of a policy written in
disjunctive normal form (the logical ors of logical ands of primitive
policies) can be straightforwardly translated to a taproot of tapscript.
That said, I think the developers of miniscript <
http://bitcoin.sipa.be/miniscript/miniscript.html>; are in a much better
position to comment on whether my above intuition is correct given that
they've had to implement a host of various calling conventions. I
understand that at least some of this complexity is due to Bitcoin Script's
one element stack rule.
Scripts under the old one element rule can be translated to the new rule by
adding an OP_VERIFY operation to the end of the script; however it is
likely that this OP_VERIFY can be folded into the previous operation
yielding an OP_EQUALVERIFY or OP_CHECKSIGVERIFY in many cases.
Even if we choose not to implement the empty stack rule, we should at least
require that the last element be 0x01 to remove a potential malleability
vector and bring it in line with MINIMAL_IF semantics.
Thanks.
On Mon, May 6, 2019 at 2:36 PM Pieter Wuille via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello everyone,
>
> Here are two BIP drafts that specify a proposal for a Taproot
> softfork. A number of ideas are included:
>
> * Taproot to make all outputs and cooperative spends indistinguishable
> from eachother.
> * Merkle branches to hide the unexecuted branches in scripts.
> * Schnorr signatures enable wallet software to use key
> aggregation/thresholds within one input.
> * Improvements to the signature hashing algorithm (including signing
> all input amounts).
> * Replacing OP_CHECKMULTISIG(VERIFY) with OP_CHECKSIGADD, to support
> batch validation.
> * Tagged hashing for domain separation (avoiding issues like
> CVE-2012-2459 in Merkle trees).
> * Extensibility through leaf versions, OP_SUCCESS opcodes, and
> upgradable pubkey types.
>
> The BIP drafts can be found here:
> * https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki
> specifies the transaction input spending rules.
> * https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki
> specifies the changes to Script inside such spends.
> * https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki
> is the Schnorr signature proposal that was discussed earlier on this
> list (See
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016203.html
> )
>
> An initial reference implementation of the consensus changes, plus
> preliminary construction/signing tests in the Python framework can be
> found on https://github.com/sipa/bitcoin/commits/taproot. All
> together, excluding the Schnorr signature module in libsecp256k1, the
> consensus changes are around 520 LoC.
>
> While many other ideas exist, not everything is incorporated. This
> includes several ideas that can be implemented separately without loss
> of effectiveness. One such idea is a way to integrate SIGHASH_NOINPUT,
> which we're working on as an independent proposal.
>
> The document explains basic wallet operations, such as constructing
> outputs and signing. However, a wide variety of more complex
> constructions exist. Standardizing these is useful, but out of scope
> for now. It is likely also desirable to define extensions to PSBT
> (BIP174) for interacting with Taproot. That too is not included here.
>
> Cheers,
>
> --
> Pieter
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190521/d6d438b1/attachment.html>;
Russell O'Connor [ARCHIVE] /
npub1dw…8plrw
2023-06-07 18:18:02
in reply to nevent1q…h2af
Author Public Key
npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrwPublished at
2023-06-07 18:18:02Event JSON
{
"id": "4790fd42ce892a91b0b99a37a417043036ca2e63c0521cf657eae0074bee027f",
"pubkey": "6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d",
"created_at": 1686161882,
"kind": 1,
"tags": [
[
"e",
"529e6716629ef4dd1bd1d9c3d84f71d38c914b08c03dc5a4b202d3977e8e4410",
"",
"root"
],
[
"e",
"d9f7581ec758041a1a05e23280f419924781e32e5b6921f29cf83f8f52e19ad0",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 Original date posted:2019-05-21\n📝 Original message:Regarding Tapscript, the specification calls for the final value of the\nstack being a single non-false value:\n\nThe tapscript is executed according to the rules in the following section,\n\u003e with the initial stack as input\n\u003e II. If the execution results in anything but exactly one element on\n\u003e the stack which evaluates to true with CastToBool(), fail.\n\u003e\n\nPerhaps it is worth taking this opportunity here to remove a minor wart of\nthe Script language and instead require the stack to be exactly empty upon\ncompletion.\n\nIn addition to removing a potential malleability vector, I expect it would\nsimplify development of Bitcoin Script. A rule requiring an empty stack\nmeans that the conjunction (logical and) of two policies can be implemented\nby the simple concatenation of Bitcoin Scripts. This combined with the\ntaproot ability to form the disjunction (logical or) of policies by having\nmultiple Merkle branches, means that the translation of a policy written in\ndisjunctive normal form (the logical ors of logical ands of primitive\npolicies) can be straightforwardly translated to a taproot of tapscript.\n\nThat said, I think the developers of miniscript \u003c\nhttp://bitcoin.sipa.be/miniscript/miniscript.html\u003e are in a much better\nposition to comment on whether my above intuition is correct given that\nthey've had to implement a host of various calling conventions. I\nunderstand that at least some of this complexity is due to Bitcoin Script's\none element stack rule.\n\nScripts under the old one element rule can be translated to the new rule by\nadding an OP_VERIFY operation to the end of the script; however it is\nlikely that this OP_VERIFY can be folded into the previous operation\nyielding an OP_EQUALVERIFY or OP_CHECKSIGVERIFY in many cases.\n\nEven if we choose not to implement the empty stack rule, we should at least\nrequire that the last element be 0x01 to remove a potential malleability\nvector and bring it in line with MINIMAL_IF semantics.\n\nThanks.\n\nOn Mon, May 6, 2019 at 2:36 PM Pieter Wuille via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Hello everyone,\n\u003e\n\u003e Here are two BIP drafts that specify a proposal for a Taproot\n\u003e softfork. A number of ideas are included:\n\u003e\n\u003e * Taproot to make all outputs and cooperative spends indistinguishable\n\u003e from eachother.\n\u003e * Merkle branches to hide the unexecuted branches in scripts.\n\u003e * Schnorr signatures enable wallet software to use key\n\u003e aggregation/thresholds within one input.\n\u003e * Improvements to the signature hashing algorithm (including signing\n\u003e all input amounts).\n\u003e * Replacing OP_CHECKMULTISIG(VERIFY) with OP_CHECKSIGADD, to support\n\u003e batch validation.\n\u003e * Tagged hashing for domain separation (avoiding issues like\n\u003e CVE-2012-2459 in Merkle trees).\n\u003e * Extensibility through leaf versions, OP_SUCCESS opcodes, and\n\u003e upgradable pubkey types.\n\u003e\n\u003e The BIP drafts can be found here:\n\u003e * https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki\n\u003e specifies the transaction input spending rules.\n\u003e * https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki\n\u003e specifies the changes to Script inside such spends.\n\u003e * https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki\n\u003e is the Schnorr signature proposal that was discussed earlier on this\n\u003e list (See\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016203.html\n\u003e )\n\u003e\n\u003e An initial reference implementation of the consensus changes, plus\n\u003e preliminary construction/signing tests in the Python framework can be\n\u003e found on https://github.com/sipa/bitcoin/commits/taproot. All\n\u003e together, excluding the Schnorr signature module in libsecp256k1, the\n\u003e consensus changes are around 520 LoC.\n\u003e\n\u003e While many other ideas exist, not everything is incorporated. This\n\u003e includes several ideas that can be implemented separately without loss\n\u003e of effectiveness. One such idea is a way to integrate SIGHASH_NOINPUT,\n\u003e which we're working on as an independent proposal.\n\u003e\n\u003e The document explains basic wallet operations, such as constructing\n\u003e outputs and signing. However, a wide variety of more complex\n\u003e constructions exist. Standardizing these is useful, but out of scope\n\u003e for now. It is likely also desirable to define extensions to PSBT\n\u003e (BIP174) for interacting with Taproot. That too is not included here.\n\u003e\n\u003e Cheers,\n\u003e\n\u003e --\n\u003e Pieter\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190521/d6d438b1/attachment.html\u003e",
"sig": "7dbbc70cbc204d96af24f4ac972510613551108330600465a2fc158ed5605920f0441976e5267ee5a418b000a3da9e88186931d77343d37b87fb863ae1268e83"
}