 Show Posts
|
|
Pages: [1]
|
I know, but can you tell me the specific meaning of tapscript (Many previously disabled opcodes are redefined to be OP_SUCCESS opcodes that unconditionally render the entire script valid to simplify soft fork upgrades.)? I don’t understand what OP_SUCCESS specifically redefines? How is it used?
In tapscript when the interpreter encounters one of the OP_SUCCESSx opcodes, it instantly succeeds. In the future this might change, and some opcodes might enforce restrictions - soft fork. But the future is not here yet, so nobody knows what and how exactly would happen. So there was OP_CAT at the very beginning, then it was disabled, and now inside tapscript there's OP_SUCCESS126 instead, which might change (in future tapscript version) to something else (instead of instant success). So there was OP_CAT at the very beginning, then it was disabled, and now inside tapscript there's OP_SUCCESS126 instead, which might change (in future tapscript version) to something else (instead of instant success). Where can I see this op_success126? can you give me what opcodes have been replaced by op_success? I didn't find too much useful information, can you tell me? |
|
|
|
I know, but can you tell me the specific meaning of tapscript (Many previously disabled opcodes are redefined to be OP_SUCCESS opcodes that unconditionally render the entire script valid to simplify soft fork upgrades.)? I don’t understand what OP_SUCCESS specifically redefines? How is it used?
In tapscript when the interpreter encounters one of the OP_SUCCESSx opcodes, it instantly succeeds. In the future this might change, and some opcodes might enforce restrictions - soft fork. But the future is not here yet, so nobody knows what and how exactly would happen. So there was OP_CAT at the very beginning, then it was disabled, and now inside tapscript there's OP_SUCCESS126 instead, which might change (in future tapscript version) to something else (instead of instant success). Here is the list of the codes redefined as OP_SUCCESSx, the red ones were disabled in usual script:
OP_RESERVED = 0x50,
OP_VER = 0x62,
OP_CAT = 0x7e,
OP_SUBSTR = 0x7f,
OP_LEFT = 0x80,
OP_RIGHT = 0x81,
OP_SIZE = 0x82,
OP_INVERT = 0x83,
OP_AND = 0x84,
OP_OR = 0x85,
OP_XOR = 0x86,
OP_RESERVED1 = 0x89,
OP_RESERVED2 = 0x8a,
OP_2MUL = 0x8d,
OP_2DIV = 0x8e,
OP_MUL = 0x95,
OP_DIV = 0x96,
OP_MOD = 0x97,
OP_LSHIFT = 0x98,
OP_RSHIFT = 0x99,
and everything between OP_CHECKSIGADD = 0xba,
and OP_INVALIDOPCODE = 0xff,
Thank you. Can you tell me a demonstration website with a full transaction script? |
|
|
|
I read the code, but I didn’t understand what is the purpose of this upgrade of OP_SUCCESS? Can you give me a detailed explanation? Thank you
This makes taproot upgradable. I know, but can you tell me the specific meaning of tapscript (Many previously disabled opcodes are redefined to be OP_SUCCESS opcodes that unconditionally render the entire script valid to simplify soft fork upgrades.)? I don’t understand what OP_SUCCESS specifically redefines? How is it used? |
|
|
|
There aren't any string concatenation OPs in bitcoin simply because there is no use cases for it in a payment system.
There used to be a couple of disabled OP codes in early version that are completely removed now that use to deal with string manipulation: OP_CAT, OP_SUBSTR, OP_LEFT, OP_RIGHT
There absolutely are use cases! Unfortunately the original construction could be abused to cause nodes to require petabytes of ram ... Fixing that requires imposing additional restrictions, and without planning for specific uses it can be hard to be confident that the restrictions don't break them. ... and demand for fancy use cases seems pretty limited-- which doesn't motivate people to do the design and validation work needed to reintroduce the operations. I already know about tapscript in this link ( https://bitcoinops.org/en/topics/tapscript/), but I still can’t understand it thoroughly. Can you help me? Like information that is easier to understand. Especially about Many previously disabled opcodes are redefined to be OP_SUCCESS opcodes that unconditionally render the entire script valid to simplify soft fork upgrades. Can you explain it to me in detail? I don't quite understand what this upgrade brings about the OP_SUCCESS opcode?
I don’t know if you have noticed the word redefine. I don’t understand how the disabled opcode is redefined by OP_SUCCESS.
It's very simple, the script interpreter starts with evaluating the output script being spent and when it is version 1 witness script it uses a different route for evaluation. That way it cutes the script in another method that checks the OP code to be in a certain range (including those disabled OP codes) and considers them OP_SUCCESS and simply returns true when they are in a Taproot script. In a way it is bypassing the old evaluation where these disabled OP codes are rejected. I read the code, but I didn’t understand what is the purpose of this upgrade of OP_SUCCESS? Can you give me a detailed explanation? Thank you |
|
|
|
OP_SUCCESS simply means "this script is automatically valid", it is the opposite of OP_RETURN that means "this script is automatically invalid". It is needed, because if you want to make upgrades in the future, you want a situation where old nodes consider new scripts as valid, so old nodes will see OP_SUCCESS and accept that as valid without any conditions, but new nodes will add some restrictions.
I don’t know if you have noticed the word redefine. I don’t understand how the disabled opcode is redefined by OP_SUCCESS. |
|
|
|
The first one uses Bitcoin script to implement string concatenation in the stack? I did not find a valid opcode in the latest Bitcoin script?
There aren't any string concatenation OPs in bitcoin simply because there is no use cases for it in a payment system. There used to be a couple of disabled OP codes in early version that are completely removed now that use to deal with string manipulation: OP_CAT, OP_SUBSTR, OP_LEFT, OP_RIGHT Second, how can I better learn the Bitcoin script, or can I recommend some good information?
I don't know any source that explains everything but chapter 7 of the book called "Mastering Bitcoin" has a good explanation of the standard scripts that should give you enough information about how things work: https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch07.asciidoc(You may want to start in chapter 6 where it explains transactions). For additional information and details you should check the source code and then ask questions here about any part that is unclear: https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cppI'm sorry .When I saw tapscript, I paid attention to this sentence: Many previously disabled opcodes are redefined to be OP_SUCCESS opcodes that unconditionally render the entire script valid to simplify soft fork upgrades. I don't quite understand what is the use of OP_SUCCESS opcodes? Could you explain that? |
|
|
|
Is there any opcode update details? For example, string link opcode?
As the big text you just quoted states, a new OP code called OP_CHECKSIGADD is added to replace OP_CHECKMULTISIG(VERIFY) working with Schnorr signatures. Apart from that the behavior of OP_CHECKSIG is also changed if it is inside a Taproot script as it needs a different sighash and treats signatures as Schnorr signatures not ECDSA. There are also some small changes such as OP_(NOT)IF mandate "minimal if" (the item popped by the operation has to be empty array or 1). Thank you very much for your reply. I have two questions here. The first one uses Bitcoin script to implement string concatenation in the stack? I did not find a valid opcode in the latest Bitcoin script? Second, how can I better learn the Bitcoin script, or can I recommend some good information? |
|
|
|
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.htmlHello 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.mediawikispecifies the transaction input spending rules. * https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawikispecifies the changes to Script inside such spends. * https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawikiis 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 Is there any opcode update details? For example, string link opcode? |
|
|
|
|
