Quote

1. Do transactions ever time out if not accepted into the block chain?

e.g. if I create a transaction today, and it happens to be invalid, is it possible it will unexpectedly get accepted, e.g. with a later release of the bitcoin block chain code that has policy changes, maybe in x years time? (assuming transaction this would have to be accepted by miner *and* the block chain code)

> Usually your bitcoin core will rebroadcast transactions which have not confirmed. It will do this indefinitely unless you remove the tx from your wallet.

Transactions only need to be mined by ONE miner. Most nodes block non-standard transactions, and won't pass them on, meaning miners won't hear about it. The only way to circumvent this is to broadcast your transaction directly to a miner who mines non-standard transactions, he may include it in a block. Eligius do this, and in fact, I have the % of non-standard multisig transactions here: http://media.coindesk.com/2014/05/table-1.png Where non standard multisig p2sh tx's are those where the number of public keys was > 3.

Two miners may publish blocks at height say 320,000. Two blocks for this height will be sent around the network, and the world will be split in two. People who think block A is correct, and people who think that block B is correct. Nodes will store both, but whatever block had the greater difficulty will be assumed to be valid.
- Miners will start working on whatever block they hear about first. Whatever chain has the most work put in will be accepted.

If your transaction was accepted to block B, it could actually end up in block A.

If some malleability bot is in on the network, your transaction ID could actually be different. So maybe you logged the TxID after one confirmation to create a raw transaction later - your TxID could be incorrect, because block B with the txid you first heard about was orphaned, but block A, where your tx was malleated was actually in the chain with most difficulty.

Sometimes, you can get really strange stuff happening with regards non standard transactions. I have observed a very old type of transaction, which blockchain.info said was unconfirmed for like 2 years. It was an old style multisig tx, which failed all the new clients rules for valid transactions. However, like the situation with Eligius above, some miners could be running the old software, which actually supports this transaction.

If a miner included this transaction in a block, and the rest of the network doesn't like that transaction, and I mean, it is really strange, it may appear to receive one confirmation, but no one will elongate that chain. Blockchain had strange info for this transaction - they seemed to log every event when it got one confirmation. It had been included in like 20 blocks, HOWEVER: no one would elongate them, and they were orphaned.

In this case, the miner who was accepting the tx into blocks was running 0.6, and later versions explicitly forbid that transaction.

Quote

2. I assume the following is an example of an invalid transaction. At least it has not any confirmations since 2014-04-02. How do I tell why it hasn't been accepted (trying to understand/parse the scripts here, but can't really make sense of them in the way they are presented on the websites I have seen so far).

http://live.insight.is/tx/83cdc4c243b3f106c22f50e0d30ce86a45e61aa2bc03c8f1f1634239e64909d7

According to this page, the scriptSig starts of with a single "0". Aren't they meant to be double digits? Ok, ignoring that for now.

Then, if my understanding it correct, it pushes three items on the stack:
* 0x30 byte signature
* another 0x30 byte signature
* a 0x52 byte BIP0016 complaint pay-to-script. Except 0x52 is the opcode for "The number in the word name 2 is pushed onto the stack.", not push 0x52 bytes of data. Which I don't understand, and at this point I am not really sure what is going on.

Maybe the website is not printing the push-item-to-stack opcode, just the data that gets pushed, which is what is confusing me???

Then the following script, from the output in the parent transaction abd231512a7d4524c3424add1c466eff250ebe221204a765a5d28118d21b7a7a is executed:

OP_HASH160 2a5edea39971049a540474c6a99edf0aa4074c58 OP_EQUAL

Which checks the hash of the BIP0016 script is correct.

Followed by popping the script of the stack, executing it, and that script checks the signatures are correct.

Is my understanding is correct?

If so, how do I determine why the process appears to be failing, at least for this transaction?

> This transaction is probably failing because it has no fee. P2SH transactions require that the person who takes the money from the script-hash address has to include the script used to create the address. These scripts are pretty long, I think around 150 bytes?

(btw, signatures aren't 30 bytes, usually around 74-76 bytes I think. They are indeed prefixed with 30 however)
(also, redeemScripts aren't 52 bytes. 52 means push 2 onto the stack. See below)

P2SH spend transactions don't execute the scriptPubKey of the TxIn (the funding transaction) in the scriptSig - they just have the '0 '. The scriptPubKey is the OP_HASH160 ', but the redeemScript is the 52.pubkey.pubkey.pubkey.53.ae thing which contains the pubkeys for that multisig transaction. So, the funding transaction just says 'the script which hashes to X owns this', but when redeeming the funds, you supply and that script, and the tx which is owned by that script-hash address, and the client creates a valid signature for it.

Sites usually don't show the PUSHDATA opcodes, they just show the physical data. See webbtc's script interpreter (only works on confirmed txs unfortunately) http://webbtc.com/script/3d891fe5b1e037165233be3ceed87a20c6210a741e64f5bda9495f208f1d5eef:0

In P2SH, there actually is a number just before the 52, the length of the whole script. And just before THIS, you have the PUSHDATA opcode.

"OP_PUSHDATA1 0x4c The next byte contains the number of bytes to be pushed onto the stack."
So 4c20123456789a123456789a would result in 123456789a123456789a being pushed to the stack.
PUSHDATA <20123456789a123456789a>

Quote

3. Would it be possible to pay for something with a transaction that contains an invalid scriptPubKey, (e.g. the pubKeyHash is invalid - if I understand this correctly would mean this output cannot be used as an input for further transactions), and trick the recipient into accepting this as payment? If not, why not?

scriptPubKey sets the constraints on the recipient on how they are receiving the money. It is how clients learn about transactions which are theirs. How would your client know that an invalid scriptPubKey was intended for you before the pubkey-hash was messed up? You couldn't do this over the network, the main way clients learn about transactions.

If someone was accepting raw transaction hexes over a web interface, for payment, it would be a accepting them outside of the network. It makes sense that they'd need to see that the tx paid their, and not someone else, before shipping goods for example.

scriptPubKey is the ONE thing you can't really fuck with. If attempting a double spend, usually you take advantage of the service doing something based on a transaction simply being broadcast, but could never go through. I've thought about double spending against BitPay, who honor 0 conf transactions.. By simply spending a newly received input X to the bitpay address with a fee of 1 gavin, and simultaneously broadcasting a double spend which pays to a non-standard scriptPubKey (sending it directly to Eligius who will mine such txs), you see that the scriptPubKey might con someone into thinking that the tx is going to go through, but the fee would be too low to confirm, and you hope that Eligius will mine your non standard transaction before someone mines your low fee one.