Hacking around with Scripts.

[nibor]

I have created this transaction in TESTNET:
http://blockexplorer.com/testnet/tx/cf3fe7e8fb5876c8a1b73051ec2f2286f3430350538a4d0579a2a38bead78983

It has been accepted by the pool and pushed into a block. BlockExplorer even recognises it as a Address script and has picked up the correct Address.

However the c++ client does not pick it up. I think my script is clean and just that the client does not understand complex transactions.
Does everyone agree with this?

I will now try to hack together a transaction to spend it!


Thanks

[dogisland]

I'd be interested in your script for spending bitcoins.

[bcforum]

Many of the OP_xxx were disabled in the standard client because:

1) They aren't being used
2) They aren't tested very well

[etotheipi]

The extra OP-codes outside of the standard transactions are not "supported" by the Satoshi client.  This means that it will evaluate non-standard scripts if they show up in the blockchain (as you have done), but those transactions won't be displayed on the client, and clearly can't be spent by the client, either.   It has to be able to evaluate them or else it would invalidate blocks that are otherwise valid.  It just won't let you create those scripts yourself, and I believe the miners will actually rejects transactions with non-standard scripts.  However, there's nothing stopping someone from mining their own block with these non-std scripts, and so the client needs to be able to evaluate them.

But, how is the client to know whether you can actually spend the coins?  I can create a TxOut with your address but with a script for which there is no TxIn that can evaluate to true.  The client has no way to know whether such a script is even spendable, or what conditions are required, so it just ignores it completely.  You have to go look for the transaction yourself, in the blockchain.

In the future, I hope to see the client recognize when one of your addresses appears in a non-standard transaction, but do nothing other than raise a red flag and let you look at the script.  It wouldn't know how to spend them, but if you are intending to receive such transactions, you probably know how to manually construct the tx to spend them, too.

[nibor]

OK, that makes sense.
So the client supports it in the sense that it validates the transaction and will validate a block with it in.
But the "GUI" does not support it - as would be very hard to get it to understand all scripts.

I disagree with your comment about the miners though. As seeing as it was mined into the test chain I would assumed it would be mined into the prod one too? Especially if you put a big fee on it!

However as you say you can not spend using client - have to hack together the messages by hand to do this.


I have not yet managed to spend that transaction yet though I get:

ERROR: ConnectInputs() : 1bb33b83a6 VerifySignature failed
ERROR: AcceptToMemoryPool() : ConnectInputs failed 1bb33b83a6

even though I am sure I have signed it correctly (I can sign normal messages fine). Maybe I do not understand OP_DROP as well as I thought.

Sure I will work it out in the end...

[etotheipi]

I don't know what codebase miners use.  I thought it was satoshi code, but the GPU miners perhaps do accept them.  I was told if I wanted to use non-std scripts in the main-network, I need to send them directly to Eligius, as that pool is the "only one" that is willing to accept them into a block.  That was a couple months ago.  It may have changed, it may have been an error by the original poster that told me that, or the testnet is different...

Your TxOut script looks fine to me: your TxIn should just be a regular Sig&Pubkey.  Just make sure you're hashing the right thing for your tx signature.  You can verify you're doing it right by looking at my OP_CHECKSIG diagram that I made specifically for this purpose.  Please note that you need to copy the entire TxOut script (the one with the OP_DROP) into the TxIn script before signing.  Yes, it's complicated... that's why I made the diagram!  

[casascius]

The standard client for good reason is only going to recognize the basic script that represents a transaction sent to it.  It doesn't, and it shouldn't, display any transaction just because the client determines it COULD spend it.

Otherwise, I could create a transaction that can be spent by you OR by me... and then when you notice the transaction show up in your client (which would look identical to one that can only be spent by you), you wouldn't know any better, and then after you have shipped goods etc., I could spend it out from under you.

Likewise, I could create a transaction that could be spent without a signature, and watch it show up in everybody's wallet as a prank.

That said, the client ought to recognize a standard transaction prefixed by a junk constant and OP_DROP as being an alternate form of a transaction it can spend because it is likely to occur as a future regular transaction if consensus supports including any sort of arbitrary information in transactions for any reason..

[Gavin Andresen]

I disagree with your comment about the miners though. As seeing as it was mined into the test chain I would assumed it would be mined into the prod one too? Especially if you put a big fee on it!

Non-standard transactions are allowed-by-default on the test network. So people can test things out.

They are "discouraged-by-default" on the main network (discouraged means not relayed to peers, and not included in blocks by the default mining code).

I think etotheipi is right: last I heard, Eligius was the only mining pool with different rules for non-standard transactions.

[nibor]

I'd be interested in your script for spending bitcoins.

Is based on BitcoinJ:
http://code.google.com/p/bitcoinj/

[nibor]

Worked out how to spend it:

Input non-std transaction:
http://blockexplorer.com/testnet/t/6ttfeb55B1

Spent by:
http://blockexplorer.com/testnet/t/AFdRB1CHS3


What I was doing wrong was I forgot to copy the non-standard script into the input of the new transaction before hashing it. Instead I was putting a standard script there (i.e. without the "bob" OP_DROP). I assume there is no good reason for the script from the previous output to be in the input script when we hash, it is just how it got implemented in the original code.

[edit] there was nothing wrong with blockexplorer - just caching.[/edit]