A bit of a meandering answer to the question, and to answer a side question: fundamentally what is a scaling solution?
OP_CTV does not increase the block space. Transactions using generally will use more block space actually (although it need not be a large amount), and relay can be optimized to equivalent.
But scaling is more than just a block size ...
In general, changes to policy rules are not specified in BIPs. They're up to individual clients anyway.
BIP16 is not obsolete, though its description of the standardness rules in Bitcoin Core is outdated by now. However, its consensus rules (i.e., what is valid in a block, not what will be relayed as individual transactions) are unmodified since it ...
A P2SH locking script on an output has the following structure:
OP_HASH160 <scripthash> OP_EQUAL
The address comes for this comes from the <scripthash>, creating a "3address". This is the standard format for a P2SH, so you can identify it and work out the address from there.
You have made a mistake in the transaction data that you signed. For P2SH, you actually have to sign the redeemScript, not the scriptPubKey. You have to sign it as if that redeemScript were the scriptPubKey.
There is another mistake in your redeemScript as well. An OP_CHECKMULTISIG requires you to push the number of signers needed, then the keys, then the ...
Because the address you are using is a P2SH-P2WPKH address as you mention (sh (wpkh ())), you get the output
It is talking only about the top level (P2SH), because it is a P2SH address, regardless of what the script "inside" it encodes. It doesn't "see" the underlying P2WPKH when ...
Your redeemScript contains the length byte for it. The redeemScript is really just a script without any prepended length byte. So for your script, it is
Note how it begins with 52 and not 47.
How P2SH works is that ...
Yes. Many of the malleability sources listed in BIP 62 still exist today. Most (if not all) are not standard, i.e. most nodes will not relay transactions that exploit them, but they are not consensus rules. So a miner can still perform malleability attacks.
I understand that: in "asm" i have RedeemScript. In txinwitness i have my signature and the pubblic key. Correct?
Correct. in a P2SH-P2WPKH the witness contains the signature and the public key, and the script signature contains the redeem script.
is it correct to say that, as an additional condition, to unlock a UTXO P2SH-P2WPKH, compared to a P2PKH, ...
You cannot. While both message and transaction signing use ECDSA and double sha256, signed messages slightly modify the message such that it is impossible to create a signature that works for that key in a transaction.
Specifically, bitcoin signed messages are prefixed with the string Bitcoin Signed Message:\n (\n is the newline character, not literally \ ...
To answer your first question:
A P2SH transaction activates a special rule in Bitcoin nodes. When a Script_Publick_Key comes with this pattern:
OP_HASH_160, <HASH>, <OP_EQUAL>
then the node runs the information in a different way.
First, it runs as it usually does. It puts the ScriptSig on top of the Script_Public_Key. The ScriptSig must ...
You are computing just the P2SH address for the segwit script. However it is not just P2SH, it is a Segwit script wrapped inside of a P2SH. You actually have to first take the witnessScript (the multisig script or segwit redeemScript) and make a P2WSH output script with it. Then this script becomes the redeemScript for the P2SH script.
I want to understand how P2SH (no multisig) works
To understand that you first have to realize that despite what bitcoin wiki says bitcoin script evaluation is not as simple as running a Forth-like language. More precisely it is not 1) read 2) run. Instead it is more like 1) read 2) interpret (decide how to run) 3) construct the entire script based on 2 4) ...
Your redeemScript is incorrect. You need to push the public key to the stack by prepending it with its length. Otherwise the script interpreter will try to interpret the pubkey as opcodes, which is incorrect. Just putting the pubkey there does not work because the script interpreter does not know that those bytes are for a public key.
You cannot. Bitcoin Core cannot reason about arbitrary scripts and does not have the capability to sign for them. As such, it cannot create arbitrary scripts and store them.
You can create the script yourself and import it into a wallet using importmulti. This will only add the script to the wallet to be tracked. This will only let your wallet see ...
From what I understand, a non-SegWit P2PH address is obtained by hashing the redeem script
I had the same problem and I have resolved it with this C++ code, and I think this code is self-describing.
If you have the ScriptPubKey extract from the blk file, this is code calculate the correct address P2SH.
string opcode = hex.substr(0, 2);
Let's go over this step by step. Suppose say you want to lock some bitcoins in a 2-of-3 multi-sig.
Create a multi-sig script: OP_2 <pub_key 1> <pub_key2> <pub_key3> OP_3 OP_CHECKMULTISIG.
Hash the multi-sig script with HASH160 which gives you multi-sig_scripthash.
Base58Check the multi-sig_scripthash with version 0x05 ...
You might want to review BIP16 (pay to script hash)
The signature is not included in the redeem script, typically just the public key. (Your script could be anything, all I know is it has a CHECKSIGVERIFY in it, so I'm answering broadly...)
The INPUT SCRIPT aka scriptSig of the transaction ...