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 ...
As you say, there are two separate concerns here:
There are some scripts that might cause harm to the network.
There are some scripts that might make future upgrades harder.
For the case of harm to the network, the non-standard transaction check was first implemented by Nakamoto before P2SH existed, so it couldn't be so easily circumvented. This gave ...
You can use Bitcoin Core's testmempoolaccept RPC. It will tell you whether the transaction you give it would be accepted into your node's mempool at that time but won't actually add it to the mempool or broadcast it.
I'm afraid that my answer here can't be better than "Ask Satoshi".
There was a series of bugs found in Bitcoin's early life, and the response by its creator was to disable a number of scripting opcodes. Some of these may have been bad choices (or very wise ones...), but we don't know, and it does not matter. For all intents and purposes, these opcodes do ...
This is easier said than done, IMO. There are plenty of little fact sheet web pages (e.g. https://www.cryptocompare.com/coins/guides/what-are-the-bitcoin-transaction-types/) lying around that give a list of the "Standard" Bitcoin Transaction types, but nothing super authoritative.
However, I think the most authoritative source as of this very moment is the ...
What use is a transaction that is never relayed?
None, unless it is generated by the same person who mines it into a block. But it is not the case that non-standard transactions are never relayed. There are nodes that relay non-standard transactions and miners who include them.
How did the transaction make it into a block in the first place if it cannot ...
The isStandard() check has been relaxed as of 2014. You can now include a wide variety of scripts in transactions.
Read more here:
What is meant by "relaxed standards" for P2SH redeem scripts in Bitcoin Core 0.10.0?
doesn't this just leave miners with the ability to perform an attack whilst leaving everyone else restricted?
Not necessarily. Many of the attacks that the standardness rules protect against require large and many transactions that are expensive to verify. If a node is sent a lot of expensive to verify transactions, it can effectively go down as it spends ...
The rule that at least one output is required is part of the original code, and changing it would mean a hard fork. There are many good changes that are possible with a hard fork, but none of them is considered worth the disruption that a hard fork would create. Changing the rules to permit no-output transactions would not even worth a soft fork, since, just ...
Not all miners accept transactions with null-data (OP_RETURN)
Not all nodes relay such transactions
Are you sure that your null-data transaction is standard (for clients 0.9.x+) ?
UPD: your output is 6a74686973206973206120746573740d0a and decoded to:
OP_RETURN // 6a
OP_DEPTH // 74
OP_ENDIF // 68 ... oups!
This is non-standard output. Because ...
This is the PR that made OP_RETURN outputs standard:
The current code:
if (GetBoolArg("-datacarrier", true))
Do you want to create p2pkh output and send zero satoshies on it? Such output is non-standard (dust) and will not be relayed and mined (but it is possible)
Or may be you want to create nulldummy (OP_RETURN) output? This is possible
BTW, sometimes miners confirm non-standard transactions, for example https://blockchain.info/tx/...
The denial-of-service (DOS) attack is easy to explain: each time a transaction is updated by increasing the sequence number in an input, the whole transaction needs to be propagated through the network again. So if a transaction is 1 KB and there are 10,000 full nodes, you can waste a minimum of 10 MB of network bandwidth each time you update the ...
Blockchain.info has buggy system which does not validate OP_RETURN outputs properly. Your transaction was pushed successfully using competent software.
I thought vbytes were equal to weight units divided by 4
It is *, but rounded up to the next integer, so the implementation in bitcoind is :
int64_t GetVirtualTransactionSize(int64_t nWeight, int64_t nSigOpCost, unsigned int bytes_per_sigop)
return (std::max(nWeight, nSigOpCost * bytes_per_sigop) + WITNESS_SCALE_FACTOR - 1) / WITNESS_SCALE_FACTOR;
I know that there are limits to the minimum size of a transaction fee (around 5400 satoshis)
Actually, some transactions can sent for free.
For example, if I gave a mining pool a list of addresses and offered an incentive to them to mine them even though the transaction was non-standard, could they do it?
Absolutely. A miner can include any transaction ...
Yes, if you pay bitcoins to a non-standard pubkey script, you can spend them in a later signature script using Eligius. But there are some conditions:
The pubkey script must be spendable. For example, a pubkey script starting with OP_RETURN can never be spent. It's up to you to craft your non-standard script to make it spendable.
Eligius will only mine ...
You will have to build the transaction yourself instead of relying on wallet software. You can either create it all from scratch and use pushtx or use an online API that accepts explicit input references to previous outputs. For example (check the last paragraph):
Each of the blockchain forks assumes itself to be the only valid blockchain. They do not change their behavior due to a competing chain. They will require checks and confirm transactions completely independently from each other. It is likely that the same transactions are confirmed in both competing chains, just in different order and perhaps also at ...
OP_PUSHDATA1 and even OP_PUSHDATA2 are allowed inside P2SH scripts fine. However, there is another policy in Bitcoin Core to require that all pushes are minimal in standard transactions. That means you can only use OP_PUSHDATA1 when a direct push is not possible (up to 75 bytes), and only use OP_PUSHDATA2 when an OP_PUSHDATA1 is not possible (up to 255 bytes)...
"Relayed" and "mined" are completely separate processes and should not be conflated.
The transaction is valid, so it was perfectly fine to mine it (i.e. include it in a valid block).
"Standard" is a more restrictive requirement, and as you say, this transaction is not standard. That means that a default version of Bitcoin Core will not relay it, i.e. ...
The following transactions are not broadcastable with the default bitcoin core configuration but could be found in new mined blocks:
Transactions whose fee is smaller than 1 sat/vB (and RBF bumps that increment less than 1 sat/B).
Transactions with size greater than 100 vkB (and smaller than ~ 1 vMB)
Transactions with outputs amounts smaller than 566 ...
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.
not possible to create a transaction which would spend the utxos since there is no private key to sign the transaction?
Yes. That's the whole point of a burn address - to have an address where no one is able to spend the coins.
Of course, in theory, someone could find a private key that corresponds to a burn address, but the probability is so small that it ...
No pool today includes non-standard transactions in blocks.
To be correct, there are a number of conditions and pool options. Some pools have strict rules, some pools - no. But all pools today have their own policy rules for accepting or rejecting transactions to a mempool.
There is no correct answer to your question without knowledge what kind of ...
Normally, non standard transactions would be rejected by P2P nodes (but would still be mineable by miners directly since this is just a policy rule).
P2SH addresses do not disclose the script they hash until they are first spent from. So you can send BTC to any script (valid or not) using P2SH addresses. Standardness rules are not imposed on P2SH input ...
Those opcodes can be used in non-standard scripts as part of a Pay-to-Script-Hash address. They can be in the redeemScript of the P2SH address and be standard.
Furthermore, standardness is not something that is set in stone; it is not a consensus rule, rather it is node policy. So in the future, we may create new script types which become standard that use ...
there are 4 possible reasons for the bad-txns-nonstandard-inputs error:
the previous transaction's output script fails a Solver() check.
the redeem script you made for that output script fails an EvalScript() check.
the stack is empty after the previous EvalScript() run.
the subscript.GetSigOpCount(true) > MAX_P2SH_SIGOPS test fails.
you can find the ...
I believe it is non-standard because you include an OP code in your input script, specifically, OP_FALSE. It should not be necessary to include OP codes in input scripts; only literals. The only way input scripts (scriptSig's) intereact with the output scripts they are spending (scriptPubKey's) is by placing values on the stack. Therefore, there is never ...