Both answers by James C. and sanket1729 are very good, but I wanted to give a very high-level answer:
Miniscript is an intermediate more structured representation for actual Bitcoin Scripts. It is useful as a toolbox because it simplifies static analysis of scripts, and things like generic signing.
The policy language is intended to simplify designing ...
Miniscript doesn't compile down to script. It encodes a subset of all Bitcoin script. It is a (very crafty) template language which reduces the Bitcoin script language to specific script expressions which are composable, which means the properties of a miniscript expression only depend on the property of its children. Properties include malleability, ...
At a high level:
The policy is compiled to Minsicript.
Miniscript is encoded to bitcoin Script. (One to One Mapping)
Bitcoin Script is decoded back to Miniscript. (One to One Mapping)
Policy and Miniscript can both be lifted to another representation
for static analysis.
Following invariants are respected in Miniscript:
Let ms be a miniscript, s be ...
There is no way to enforce a rule regarding the nature of an output when an input is spent. You will have to enforce this off chain in some manner, perhaps through multisig schemes where one key is held by a rule engine that will only sign the tx if your requirements are met.
Let's run through the program.
The stack starts as <A sig> <A pubkey>.
You run OP_DUP. The stack is now <A sig> <A pubkey> <A pubkey>.
You run OP_HASH160. The stack is now <A sig> <A pubkey> <A pubkeyhash>.
You push (A expected pubkeyhash). The stack is now <A sig> <A pubkey> <A pubkeyhash> &...
Bitcoin uses a stack based language due to which the logical condition that will execute the IF or ELSE statements comes prior to the operator IF or ELSE. Let's take both your cases one by one and see how it gets executed on the stack.
Case 1: ScriptSig: 0 <Alice's signature> <Bob's signature> 0
The stack starts at 0 <Alice's signature> &...
This is because CSV and CLTV are NOP opcodes that were redefined in a softfork.
As a softfork can only change the validity of transactions from valid to invalid, the only effect this redefinition was allowed to have is making the script abort in some conditions, and keep acting like NOP otherwise.
NOP does not pop anything off the stack, and as a result, ...
Those transactions spend Pay-To-Pubkey outputs. These are not special or strange and are actually the very first kind of outputs to ever exist in Bitcoin. These outputs simply do not have an associated address type which is why block explorers do not show an address for them.
Also, just because a block explorer can't show an address type does not mean that ...
I assume the scriptPubKey is contained in a UTXO, and therefore embedded in the blockchain. Since, this is the script used to unlock the input.
Is a scriptSig also embedded in the blockchain?
They're part of transactions, and transactions in their entirety are part of the blockchain. All data that is directly or indirectly needed to ...
This transaction actually does have a signature check. Instead of OP_CHECKSIG, it's OP_CHECMULTISIG as the script is a multisignature script. The script in this case is the redeemScript which is provided in the input itself. To see this OP_CHECKMULSITIG, you need to decode the redeemScript.
The redeemScript is:
Standard output scripts are defined by this function (which calls the solver function to perform the actual script matching). The standard output scripts are as follows:
A script beginning with an OP_RETURN and only pushes at most 80 bytes data to the stack
Bare multisig up to a 3-of-3 multisig
Any other script will be non-...
As noted in BIP 143, the CODESEPARATOR opcode operates by truncating the scriptCode value that is included in the digest. While rarely used, CODESEPARATOR does provide a method to create signatures that are bound to specific code paths taken by Script, even when the same pubkey key used for redeeming the UTXO.
If the scriptCode were removed from the digest ...
You only need to use OP_PUSHDATA1 if you are trying to push more than 75 bytes of data onto the stack.
For pushing smaller sized values onto the stack, you can use the opcodes 0x01 to 0x4b to indicate the number of bytes being pushed. Thus, to push a single byte of value 210 (0xD2) onto the stack, you would use the byte sequence 0x01 0xd2.
To push a 16-bit ...
CVarInt encoding is only used in the storage of the UTXO set internally, and never in the P2P protocol. CCompactSize is used in a number of places, including the number of transactions per block, the number of inputs and outputs per transaction, and the length of scripts.
If you're parsing block data, you will never encounter a CVarInt. If you're running ...
Is Script also used to validate block, network, or any other data?
No. Scripts are only included in transactions and can only read some data from the transaction and the block the transaction is included in. Scripts are only used for transaction validation as they specify the conditions required to spend an output.
Seem like there are a lot of OP codes ...
The main issue about using a non-segwit inputs in the funding transaction or a p2sh output as the channel anchor is the transaction malleability.
The recovery guarantee before a channel is funded relies on the commitment transaction building on top of the funding transaction. If the funding transactions txid were to be malleated, the commitment transaction ...
Most of the output addresses follow one of the following 'standard outputs':
P2PK: scriptPubKey: <public_key> OP_CHECKSIG. Output pays the public key directly and hence does not have a direct address.
P2PKH: scriptPubKey: OP_DUP OP_HASH160 <hash160 of pubkey> OP_EQUALVERIFY OP_CHECKSIG. For this kind of output you just need to ...
It has always been the case that the full Bit Machine would be "exposed" by allowing arbitrary Simplicity. This is because the combinators that let you compose the high-level jets are exactly the same combinators that define low-level Simplicity. Thus even if only a few high-level jets are chosen to be exposed, it would still be the case that the low-...
I've been looking for a tool to experiment with bitcoin script for a while now, and I finally finished developing one myself.
BitAuth IDE is an open source project for designing advanced scripts for bitcoin and bitcoin-like cryptocurrencies. It’s both a learning sandbox and a tool for designing new kinds of wallets.
It includes a live-updating, ...
The number 20 seems to originate from this commit : 8c9479c6bbbc38b897dc97de9d04e4d5a5a36730, also tagged as v0.3.12, which introduced the term 'SigOps". Sadly, I don't see any mention of this change in the commit message itself, or in this version's release note, and there isn't any documentation.
We see that both a limit for a maximum number of sigops in ...
It's possible, but:
It's much slower
Pubkey recovery for this kind of application is arguably patented
For a "signature only" scriptpubkey, we already have p2pk. Hopefully in the future, segwit programs will have bare pubkeys in the scriptpubkey, allowing for similar (and more advanced) constructions.
The actual script implemented on Lightning Network is a little bit different from what you quoted. This is the script below and the specification is here
# Penalty transaction
I've created that transaction on ...
All fields in a Bitcoin transaction are little-endian encoded except for the signature fields and the public key fields which are both DER and big-endian encoded since they were originally produced by an external library that uses these encodings.
Would it be prudent/responsible for the BIP 68 Standard to make it
clear whether the bit-encoding is ...
Inside scripts sometimes you need to push an arbitrary length of bytes on top of the stack. Example: pushing public key after signature inside scriptsig. In these cases you use special operators called OP_PushDataX or OP_PushBytesX telling the interpreter that X number of bytes should be pushed to the stack. You won't find these names in any library because ...
I don't think this is possible. Most, if not all, block explorers and blockchain indexers do not completely disassemble scripts and index them so that they are searchable. No software or service I know of allows you to search by opcode use in a transaction. It would be pretty useless for a service to provide this as probably no one would actually use it and ...
The following scriptPubKey describes the desired contract:
OP_DUP OP_HASH160 <Bob's pubKeyHash>
<now+30 days> OP_CHECKLOCKTIMEVERIFY OP_DROP
OP_DUP OP_HASH160 <Victor's pubKeyHash>
Bob can spend the output using the scriptSig <Bob's signature> <Bob's pubKey> OP_TRUE