5

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.


4

The maximum is 100 bytes and is checked and defined here: https://github.com/bitcoin/bitcoin/blob/master/src/consensus/tx_verify.cpp#L195


3

This is a 5 input one output multisig transaction. The decoding of the first sigscript ...


3

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 &...


2

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 ...


2

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.


2

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 ...


2

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"...


2

As you have found out correctly, the length field describes the following script length. Then the SigScript follows: ...


2

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


2

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 ...


2

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: ...


2

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 ...


2

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 ...


1

ECDSA signatures are not deterministic unless you are using a deterministic signature scheme. Meaning that signing the same data with the same key produce different (valid) signatures. I don't know if Bitcoinj uses such a scheme so If only the signature bytes in the transaction are different it is probably fine.


1

The script is executed during the validation of a transaction by any full node which validates it. The script denotes the spending condition, so during the verification of a transaction the node will execute the script to ensure it passes successfully and does not violate any other rules (e.g. cleanstack)


1

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 ...


1

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 ...


1

The transaction is valid. This golang code gives the correct result. You need to HASH160 51, not 1. Additionally, make sure you run the hash on 0x51, not "51" or int(51).


1

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 ...


1

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.


1

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 ...


1

Do all transactions require a siganture to be broadcasted No. Bitcoin does not require that valid transaction must have signature verification.


1

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 ...


1

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


1

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) ...


1

quickly verifying: 410404f89c713f44615ad5fdc16f1ef8628351a1cce79ee96130a0e4a6eb09d05278cef28cb002a6ad2ad53181b01d03f931538488a7a689d83684e54822305205d5ba 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 ...


1

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? ...


1

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 ...


1

You are signing a specially modified version of the transaction itself. The modified transaction involves replacing the scriptSig field temporarily with the scriptPubKey from the transaction output being spent, and leaving all other inputs' scriptSigs empty, and then appending a 4 byte signature type code. The transaction is then hashed twice with SHA256 and ...


Only top voted, non community-wiki answers of a minimum length are eligible