Hot answers tagged

65

Note: I went out and learned about how the OP_RETURN opcode works at the byte level in a bitcoin transaction. I’m writing it here so that others can learn quickly. First, a brief history of why we’re even talking about OP_RETURN. Back in 2013 different players in the bitcoin ecosystem were trying to include bits of information into transactions so that they ...


39

First of all two matching scripts are used in two different transactions, one that transfers funds to an address (Transaction A) and one that spends those funds (Transaction B). The scriptPubKey is created by the user that creates Transaction A. It basically adds a claiming condition to the output that is being created. A user may only claim and thus spend ...


32

Scripts are one of Bitcoin's more clever features. The most obvious way to implement a crypto-currency is to make a transfer be to a public key. To claim the transfer, you sign with the corresponding private key. This is not the way Bitcoin works. When you send Bitcoins (the out of a transaction), you send them to a script. When you claim Bitcoins (the in) ...


25

If a full implementation of the scripting language were in place, then pretty much all of the following could be implemented. However, there are serious security concerns with some of these and they warrant further analysis before finding their way into the clients. The referenced Scripts link in the original question contains several script examples ...


18

Script was in the first version of Bitcoin. Satoshi developed Bitcoin in private before releasing the fully-usable Bitcoin 0.1, and he said very little about his thought-process, so we'll probably never know exactly why many things were done the way they were. Script had several serious bugs when Bitcoin was first released, and some bugs still exist. It's ...


16

Pay-to-PubKey (P2PK) and pay-to-PubKey-Hash (P2PKH) were both introduced in the original Bitcoin 0.1 release. P2PK was used by default for mining and payments received using the interactive IP-to-IP payment protocol; P2PKH was intended for use in non-interactive payments---but P2PKH transactions take up more space in the blockchain than P2PK. Is this space ...


15

The standard client will not relay non-standard transactions. However, if you get them directly to a miner that accepts them, clients will process them correctly and the transaction will work. You can send your transactions to 173.242.112.53. This is a server run by Eligius that will relay all valid transactions and they will include even non-standard ...


15

SHA1 was never commonly used in Bitcoin, but it there is at least one notable use of it, a P2SH script created by Peter Todd to allow anyone to pay to an address that could be spent by anyone proving they had found a SHA1 collision. This bounty was claimed using the published results of several security researchers who generated such a collision. ...


12

Your conflict is caused because you are hashing different values in the two situations. >>> import hashlib >>> hashlib.sha256("1").hexdigest() '6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b' Your online tools are showing the hash of the string "1". >>> hashlib.sha256("\x01").hexdigest() '...


11

The P2SH, as defined in BIP 16, states that The purpose of pay-to-script-hash is to move the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer. The benefit is allowing a sender to fund any arbitrary transaction, no matter how complicated, using a fixed-length 20-byte hash that is ...


11

the output address is derived solely from the output script starting from step 4 in the wiki like so: first add leading zeros: 0012ab8dc588ca9d5787dde7eb29569da63c3a238c then hash with sha256 (if you look in the wiki this is actually part of the OP_HASH160 operation) to give: e158c4be10913422dadcf1c36843020ebb3ffe9d0cb13fb9e8c0a564a53c7832 then hashed ...


11

As others have said, there is no real need for Bitcoin scripting to be more complex than it is, as its complexity is more than enough for its intended applications; but the main reason is that not allowing some features (such as loops) in a language makes it completely deterministic: you can know for sure when and how a given program will end; you can't f.e. ...


10

If scripts were Turing-complete, you could construct a fairly short script that took an extremely long time to run (a la the Busy Beaver) or contained an infinite loop. This would tend to result in a denial of service against everyone on the network, when they tried to verify the transaction. And there would be no general way to tell whether a script ...


9

These are the scriptPubKey's that are standard, arranged in order of popularity: P2PKH (Pay to public key hash) OP_DUP OP_HASH160 <20 bytes of public key hash> OP_EQUALVERIFY OP_CHECKSIG P2SH (Pay to script hash) OP_HASH160 <20 bytes of script hash> OP_EQUAL P2PK (Pay to public key) This is now mostly unused, except by miners, but there are ...


8

The statements are not on the stack, they're in the script. They start immediately after the OP_IF. They end at the first OP_ELSE or OP_ENDIF, assuming there isn't a nested OP_IF or OP_NOTIF. So it looks like this // script to put a number on the stack OP_IF // script that runs only if the number isn't zero OP_ENDIF // script that runs no matter what or: /...


8

The current development direction (January 2013) is to tighten up the IsStandard() checks even more. For example, we would like all signatures to conform to a very strict, canonical encoding to make life more difficult for potential attackers. Allowing more opcodes or opcode patterns (or all opcodes/patterns) to be considered IsStandard() is certainly ...


8

You're correct so far, you just stopped before you were finished. As BIP16 says, it "defines additional validation rules that apply only to the new transactions" -- specifically, "{serialized script} is popped off the initial stack, and the transaction is validated again using the popped stack and the deserialized script as the scriptPubKey." So: 1) The ...


8

Addresses are really just shorthands for particular scripts. The standard address type (starting with a '1' on mainnet) does in fact correspond to the exact type of script you gave above. If you base58 decode such an address, you end up with a byte string of the form 0x00 + [20-byte hash] + [4-byte checksum]. The corresponding script is OP_DUP OP_HASH160 [...


8

If you want to write OP_RETURNs to the blockchain without getting into the internals of how transactions are built, an easy way is to use our libraries for PHP and Python: https://github.com/coinspark/php-OP_RETURN https://github.com/coinspark/python-OP_RETURN These support either sending individual transactions with one OP_RETURN attached, or else ...


8

10,000 bytes. See Bitcoin Core source code: https://github.com/bitcoin/bitcoin/blob/v0.17.0/src/script/script.h#L31-L32 https://github.com/bitcoin/bitcoin/blob/v0.17.0/src/script/interpreter.cpp#L299-L300


8

The script is maintained by the intended recipient; he is the one responsible to keep it and not to lose it. The nodes do not store any database of the scripts. The script is provided by the spender upon spending the p2sh as part of the scriptSig data. For the exact specification of how this data is structured, see BIP 16 by Gavin Andresen. This allows the ...


8

There is currently no real need for an OP_PUSHDATA4, which would allow pushing up to 4GB onto the stack. It was in the original script definition and simply was not disabled when the 520 byte limit was introduced. The only possibility for it to appear in today's scripts is as a non-minimal push and may be caused by a custom client or transaction malleability....


8

Disclaimer: I am going to assume that you are not completely clueless and that you know what an array is, how to count from 0, and how to match brackets, quotes, and colons so that you can read JSON formatted data. If you don't know how to do those things, then please google them first before reading this post. Also, this post will be very long, and ...


7

The script page of the bitcoin wiki tells us that: A transaction is valid if nothing in the combined script triggers failure and the top stack item is true (non-zero) To validate a transaction's input, first the input's scriptSig is run, then the scriptPubKey of the output it's trying to spend is run. The transactions in question have a scriptSig of '1' ...


7

I don't think your threat model makes sense. If you "send me Bitcoins I can't claim", you've done the equivalent of nothing at all, except you've wasted some of your own Bitcoins in the process. Currently, clients will only recognize Bitcoins as being sent to them if they can confirm they can claim them. Non-standard transactions (those with scripts other ...


7

Little endian. See, for example, the script_PushData unit test in the source tree that pushes one 0x5a byte onto the stack 4 different ways: // Check that PUSHDATA1, PUSHDATA2, and PUSHDATA4 create the same value on // the stack as the 1-75 opcodes do. ...


7

TxID is just a SHA256 hash of binary transation data, so it changes upon any modification of transaction. Therefore, one cannot include verification of TxID in the script in same transaction (if I correctly understood what you want to achieve).


7

Here's where they're defined: case OP_TOALTSTACK: { if (stack.size() < 1) return false; altstack.push_back(stacktop(-1)); popstack(stack); } break; case OP_FROMALTSTACK: { if (altstack.size() < 1) ...


7

the purpose of OP_CHECKLOCKTIMEVERIFY is kind of the opposite to the purpose of tx.nLockTime. tx.nLockTime prevents transactions with future dates from entering the blockchain, whereas OP_CHECKLOCKTIMEVERIFY enables someone to freeze funds so that they can only be spent after a given timestamp or block height. tx.nLockTime tx.nLockTime is validated by ...


7

The incompatibility comes down to 2 main factors: Pruning: an important addition of the mimblewimble proposal is the ability to merge transactions across blocks. If transactions include scripts, merging becomes impossible as the script behavior is unknown. While for simple spends, it's fairly straightforward to eliminate matching amounts. No address: in ...


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