nibor (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 13, 2011, 04:04:27 PM |
|
I have created this transaction in TESTNET: http://blockexplorer.com/testnet/tx/cf3fe7e8fb5876c8a1b73051ec2f2286f3430350538a4d0579a2a38bead78983It 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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 13, 2011, 06:33:35 PM |
|
I'd be interested in your script for spending bitcoins.
|
|
|
|
bcforum
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 13, 2011, 07:27:50 PM |
|
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
|
If you found this post useful, feel free to share the wealth: 1E35gTBmJzPNJ3v72DX4wu4YtvHTWqNRbM
|
|
|
etotheipi
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 13, 2011, 11:08:08 PM |
|
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 (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 13, 2011, 11:47:48 PM |
|
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
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 13, 2011, 11:54:41 PM |
|
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! ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
casascius
Mike Caldwell
VIP
Legendary
Offline
Activity: 1386
Merit: 1140
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 14, 2011, 12:16:39 AM |
|
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..
|
Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable. I never believe them. If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins. I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion. Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice. Don't keep coins online. Use paper or hardware wallets instead.
|
|
|
Gavin Andresen
Legendary
Offline
Activity: 1652
Merit: 2300
Chief Scientist
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 14, 2011, 12:37:24 AM |
|
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.
|
How often do you get the chance to work on a potentially world-changing project?
|
|
|
|
nibor (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 16, 2011, 09:57:49 PM Last edit: September 17, 2011, 10:58:04 AM by nibor |
|
Worked out how to spend it: Input non-std transaction: http://blockexplorer.com/testnet/t/6ttfeb55B1Spent by: http://blockexplorer.com/testnet/t/AFdRB1CHS3What 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]
|
|
|
|
|