OP_IF consumes a number from the top of the stack.
The OP_IF will evaluate to true if the number is not 0, and to false if the number is 0.
H/T for this answer by David Schwartz, and to Pieter Wuille for getting me on the right track.
The scriptSig field of a coinbase transaction is special. It doesn't need any signatures at all, as no coins are being spent. The ability to produce new coins, which that input represents, is inherent to the protocol - every block is allowed some fixed amount of produced coins. Requiring a signature on it would be wasteful and pointless. Which key should we ...
The size is encoded as Compact size. These can be up to 9 bytes long and encode a size of anything between zero to 18446744073709551615 bytes.
The rules are (according to serialize.h) :
* Compact Size
* size < 253 -- 1 byte
* size <= USHRT_MAX -- 3 bytes (253 + 2 bytes)
* size <= UINT_MAX -- 5 bytes (254 + 4 bytes)
* size &...
Your signature is not correct. First of all, its length can't be 74 bytes long. According to the Bitcoin wiki:
Signatures are either 73, 72, or 71 bytes long, with probabilities approximately 25%, 50% and 25% respectively, although sizes even smaller than that are possible with exponentially decreasing probability.
Having said that, it seems that you ...
The issue is, scriptsig contains the actual redeemScript instead of the serialized script as a push. The second error, the redeemscript contains an extraneous 0x00 value that should not be there as this is a simple CHECKSIG.
41 hex equals 65. So the following string should be 65 bytes, but it is 66 bytes. As arubi lined out, there is an error with the double "04" - it only needs one.
Quick proof: when I verify the pubkey, I ...
Segwit is a soft fork. A supermajority of miners have agreed that they will not include such transactions in their blocks, and will orphan any block that does include such a transaction.
If you send such a transaction to a legacy node, it will see it as a valid unconfirmed transaction, but the network will never confirm it.
Potentially, if there are ...
Okay, turns out my research has led me to answer my own question, mainly from here though it did lack a bit of explanation or didn't explain, I think, as clearly as it could. So here's my reading/interpretation/translation thereof. (Go to that page to see the source of my data if need be).
NOTE: This process may have changed after the addition of "segwit"...
Signing the same piece of data with the same key typically produces different signatures unless you are using a deterministic signature scheme. Check if that is the case with the library you are using for signing.
EDIT: Seems like python-ecdsa supports deterministic signatures
Is it safe to store bitcoins in this address with this scriptsig ?
That is actually the scriptPubkey, and it is only safe if you use a safe redeemScript.
A P2SH script is a Pay-to-Script-Hash script, meaning when you spend the coins, you must provide the script (and the hash must match), but this script you provide, called the redeemScript must also ...
You must provide a scriptSig that, when executed with scriptPubKey results in a true (or any nonzero item) on the stack (and passes all verification ops).
The scriptPubKey you need to satisfy (with a scriptSig) is:
2 OP_CHECKSEQUENCEVERIFY f45d94733d430261962932e0c847075195916a04 OP_CHECKSIG
(note this is not the redeemScript)
There main problem is:
When an input redeems a P2PKH output (pay to an address starting with a 1), the format of the input script (the scriptSig) is: [signature] [public key]. Because public keys are included in both standard input scripts (redeeming P2PKH outputs) and output scripts (P2PK), the Script.getPubKey() method has been written to return the public key in either input ...
The R value is the result of EC point multiplication between the k value (known as the nonce) and the secp256k1 curve's generator point. It is effectively the public key for k. The only way that an R value can repeat is if k is also the same. Given that k is a 256 bit number and is supposed to be chosen completely randomly, k should not repeat unless the ...
The data to be signed is called Hash Preimage. Then you sign the double SHA256 of hash preimage, which is 256-bits long. Before hashing, the data must be formed as shown in this answer. If you're signing a SegWit transaction, the contents of the preimage changes, as defined in BIP 143.
Then you can use the formulae here, Eq. 2:
(x1, y1) = k × G(x, y) mod p
ECDSA signing is not deterministic. A random number k "nonce" is used for signing, and a different nonce must be used for every signature made with the same private key. (Otherwise, the private key could be extracted by a 3rd person.) This could be a random number, as it's in your case. However, never systems generate nonce deterministically, usually using ...
So I have resolved the issue, first a huge thanks to pebwindkraft for the direction and link to look at. Based on his breakdown of a transaction I was able to figure out where I was going wrong. I was missing the correct hex to unlock the previous transaction, once that was entered in the correct spot of the serialized transaction, it was broadcasted ...
Here you have an example of a transaction spending from a P2PKH output and creating a P2SH output with an OP_1.
And here you have the counterpart, a transaction spending from the first one (with an input script '0151') and generating a P2PKH output.
I've created both using a Python library i'm coauthor of. You can check it out here.
Transactions do not require a signature to be valid. Signatures are just a way of ensuring that the transaction is not going to be spent by anyone, but just by the person who holds the correct private key and therefore, is able to perform a valid signature.
Here you have an example of a transaction spent without signature. tx1 is a transaction spending from ...
Your raw transaction is just completely wrong. Just pushing OP_TRUE to the stack does not make any output spendable; you still need to execute the output script. The combined script (input script and output script together) results in a failure/OP_FALSE so the input is invalid. Thus the transaction is invalid.
Looking at the output you are trying to spend ...
it's a lot easier, just omit the "fd". Here is the explanation from the bitcoin developers webpages.
Assuming you have the value in an array (tx_array) and a pointer into the array (tx_array_ptr), here is an (unixoide shell script) code example:
# var_int is defined as:
# value size Format
# < 0xfd 1 uint8_t
# <= 0xffff 3 ...
You can also do Pay-to-Public-Key.
But public keys are bigger in size that public key's hash. Thus, Pay-to-Public-Key-Hash was invented by Satoshi to make bicoin addresses shorter.
Compressed public key - 33 bytes
Public key hash - 20 bytes
While I haven't verified the signature, upon inspection of the encoding I think I can see what is wrong. Let's break down the scriptSig briefly and I'll show you:
8a (total number of bytes to follow)
46 (the signature is 0x46 bytes long *THIS IS WHERE THE ISSUE IS*)
30 (compound DER type)
44 (0x44 bytes following)
02 (integer type)
20 (0x20 bytes long)
Let's ignore the high-s value in the signature for now : 46022100dc6c14b905647fc0efde3d37079853bb1cedbcdf2cfdecac6665a3b8b8b2395d022100b13412fae64c9b6341096acf3578d93ab450c23dd6361701ceb21cef6d80100201
The pubic key push seems malformed. Why the extra 0x04 after the 0x41 bytes push?
yes, it is. For each input you create a raw transaction with the pubkey script in the scriptsig "slot". Then this raw tx gets seigned. Each input has a different "source" (previous input tx and previous input "outpoint"), since they are hashed before signing, it creates a different result. A sample how to do this for two inputs is shown here:
How to sign ...