Author

Topic: invalid transactions (Read 1845 times)

sr. member
Activity: 412
Merit: 287
May 27, 2014, 08:26:40 PM
#12
Quote
Ok, So I guess this means that your bitcoin client want notice that the transaction was confirmed, and may retransmit it again in error. Which is the so called malleability attack. https://en.bitcoin.it/wiki/Transaction_Malleability

> The ones your client rebroadcasts will have the same data as previously, so wouldn't be malleated. It's usually a node written for the purpose of tampering with the scriptSig so it produces a valid signature but leads to a different transaction hash, causing confusion when your wallet learns about the two transaction.. They will discard the invalid one once it happens.

Most of the BIPS are on github: The mediawiki pages are the ones you want. https://github.com/bitcoin/bips/

Quote
Does seem possible to crash it though, for instance, going to http://webbtc.com/address/1CjPR7Z5ZSyWk6WtXvSFgkptmpoi4UM9BC - the first address I clicked on - comes up with the error "Too many outputs for this address (12958)"

Lol at the error on webbtc.. Yeah I guess that can happen.

Quote
Oh, ok, maybe this was a false assumption I made. I thought the transaction output included the destination address too, but maybe that is not the case, it is only the script that decides who can spend it. Which would make more sense, and reading the bitcoin protocol specification seems to confirm this. https://en.bitcoin.it/wiki/Protocol_specification

Which in turn will presumably mean that if the websites display the destination address (hopefully they do confirm that it is the standard script), this means that the output is definitely spendable if you have the corresponding private key (except, of course, PIP0013/p2sh addresses).

This is correct. Clients parse scripts for transaction types which it tolerates. Usually this would just be pay-to-pubkey-hash (Regular txs) and pay-to-script-hash (different, used for multisig), and it does this by comparing each position in the script against a template - if it passes, it knows which value is the hash, and knows which private key it corresponds to.
donator
Activity: 1218
Merit: 1079
Gerald Davis
May 27, 2014, 07:16:34 PM
#11
Oh, ok, maybe this was a false assumption I made. I thought the transaction output included the destination address too, but maybe that is not the case, it is only the script that decides who can spend it. Which would make more sense, and reading the bitcoin protocol specification seems to confirm this. https://en.bitcoin.it/wiki/Protocol_specification

How do websites, such as webbtc, display the output address? I am guessing they must parse the script and find the hash value. Does that even make sense? e.g. is it possible to take the hash from output script, say 024a0102c5952538e6aab7cddb9e2659bd47e206, and turn that into a bitcoin address of 1D71GZ463FU4accU2GAdz9DT1XoLGqPWK?

Yes.  An address is a PubKeyHash* with version and checksum encoded in Base58 format.  You can convert between hashes and addresses in either direction.  There are no addresses anywhere in the blockchain or txs.  Anytime you see an address it is a hash which has been encoded into a format that is easier to humans.   When you enter an address into a client to "send coins" the address is first validated (good checksum, version, and pubkeyhash length) and then the PubKeyHash extracted to be used in the tx being created.


* or ScriptHash in the case of P2SH.
newbie
Activity: 39
Merit: 0
May 27, 2014, 07:04:42 PM
#10
fbueller, thanks heaps for you long and details response!

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

[...]

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.


Ok, So I guess this means that your bitcoin client want notice that the transaction was confirmed, and may retransmit it again in error. Which is the so called malleability attack. https://en.bitcoin.it/wiki/Transaction_Malleability


(Also I notice that some of the links in https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals are broken, e.g. BIP0062, which would have been relevant here - not sure how to report problems though)


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

Interesting website, seems to do a much better job of showing the scripts then other websites.

Does seem possible to crash it though, for instance, going to http://webbtc.com/address/1CjPR7Z5ZSyWk6WtXvSFgkptmpoi4UM9BC - the first address I clicked on - comes up with the error "Too many outputs for this address (12958)"


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.

Oh, ok, maybe this was a false assumption I made. I thought the transaction output included the destination address too, but maybe that is not the case, it is only the script that decides who can spend it. Which would make more sense, and reading the bitcoin protocol specification seems to confirm this. https://en.bitcoin.it/wiki/Protocol_specification

How do websites, such as webbtc, display the output address? I am guessing they must parse the script and find the hash value. Does that even make sense? e.g. is it possible to take the hash from output script, say 024a0102c5952538e6aab7cddb9e2659bd47e206, and turn that into a bitcoin address of 1D71GZ463FU4accU2GAdz9DT1XoLGqPWK?

Which in turn will presumably mean that if the websites display the destination address (hopefully they do confirm that it is the standard script), this means that the output is definitely spendable if you have the corresponding private key (except, of course, PIP0013/p2sh addresses).
sr. member
Activity: 412
Merit: 287
May 27, 2014, 03:37:31 AM
#9
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.
legendary
Activity: 1792
Merit: 1111
May 27, 2014, 01:40:09 AM
#8
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?

It is possible only if the recipient is stupid enough not to verify the transaction.

How do you verify the transaction?

I assume that just checking, say with blockchain.info would be insufficient (it doesn't know what private keys you have access to).

However, can I assume that most (if not all) wallet applications will have checked that I can spend the funds before displaying the transaction or including the balance in the total?

Thanks

Every sane wallet applications will check transaction validity before displaying it.
donator
Activity: 1218
Merit: 1079
Gerald Davis
May 27, 2014, 01:34:55 AM
#7
Your client notifies you of outputs which can be spent by your client (i.e. you have the proper private key) and invalid transaction can't be spent by anyone and thus no valid client would see it as a valid payment.
newbie
Activity: 39
Merit: 0
May 27, 2014, 01:07:52 AM
#6
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?

It is possible only if the recipient is stupid enough not to verify the transaction.

How do you verify the transaction?

I assume that just checking, say with blockchain.info would be insufficient (it doesn't know what private keys you have access to).

However, can I assume that most (if not all) wallet applications will have checked that I can spend the funds before displaying the transaction or including the balance in the total?

Thanks
legendary
Activity: 1792
Merit: 1111
May 26, 2014, 11:28:21 PM
#5
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)

There is no time out. By default nodes will drop invalid transactions. But there is nothing to stop people from storing invalid transactions.

A policy change that accepts a previously invalid transaction is called a "hard fork". It requires the consensus of ALL bitcoin users, including miners and non-miners. It is unlikely to happen. But if it really happens, your previously invalid transaction might be accepted.

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?

It is possible only if the recipient is stupid enough not to verify the transaction.

Quote
Or for another example, maybe one less far fetched, consider a non-standard transaction, that isn't included in the block chain any time soon. Is it possible that a miner could unexpectedly process this transaction at any undetermined point in time in the future of bitcoin? Or will the transaction eventually expire?

There is no expire. However, you may simply spend one of its inputs to make it invalid.
donator
Activity: 1218
Merit: 1079
Gerald Davis
May 26, 2014, 11:18:47 PM
#4
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)


Or for another example, maybe one less far fetched, consider a non-standard transaction, that isn't included in the block chain any time soon. Is it possible that a miner could unexpectedly process this transaction at any undetermined point in time in the future of bitcoin? Or will the transaction eventually expire?

They do not expire once broadcast.  It is possible that the tx will be added to a block by a miner at any point in the future.   The tx can be made invalid by double spending the same inputs in a new tx.  Once the double spend is included in a block the first tx never will as that tx is now invalid in any block in the same blockchain as the original.

member
Activity: 229
Merit: 13
May 26, 2014, 10:30:00 PM
#3
Quote
Three questions concerning invalid transactions, just so I can try to understand some of the technical details of bitcoin a bit better.
There are no "invalid transactions" on the network. All nodes relay them to /dev/nul immidiately

Quote
1. Do transactions ever time out if not accepted into the block chain?
Any node as a right to keep any "valid" transaction any time.

Quote
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)
If node accepts transaction - this means that transaction is valid, but nothing more. Node will not try to re-send it to peers.

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
There were not enough fees to include this tx into a block. Noone wanted to accept this "valid" transaction into a block on april,2
And this transaction exists in the memory-pool (or in database) on live.insight.is. This node does not try to relay this transaction to the network (but you can do it youself now)

Quote
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.
This is pushing "0". Redeem script for msig transaction


Quote
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.
35Z3xG92YkW5Xo4ngQw6w5b3Ce6MDw94A8 is 2-of-3 msig address

hava a look to https://blockchain.info/tx/abd231512a7d4524c3424add1c466eff250ebe221204a765a5d28118d21b7a7a

redeem script is
push 0 (OP_FALSE)
push signature1 (3045022100...)
push signature2 (3045022028...)
[execute BIP-16]
push 2
push publickey1 (020743d44be98...)
push publickey2 (02c0120a1dda9...)
push publickey3 (0213820eb3d5f...)
push 3
OP_CHECKMULTISIG

newbie
Activity: 39
Merit: 0
May 26, 2014, 08:23:46 PM
#2
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)


Or for another example, maybe one less far fetched, consider a non-standard transaction, that isn't included in the block chain any time soon. Is it possible that a miner could unexpectedly process this transaction at any undetermined point in time in the future of bitcoin? Or will the transaction eventually expire?
newbie
Activity: 39
Merit: 0
May 26, 2014, 07:44:50 PM
#1
Hello,

Three questions concerning invalid transactions, just so I can try to understand some of the technical details of bitcoin a bit better.


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)



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?



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?


Thanks
Jump to: