Topic: Questions about how scripts work (Read 1331 times)

Yes.


They will not include them in their blocks, but they will accept them in other blocks. (This has not always been the default behavior -- previously everyone would include all transactions.)

So, even though only 2 types of script are generated by the default client, all clients can understand all the script constructs?

Also, if you don't use the standard 2 scripts, then the standard miners will reject the transactions?

That's not what I'm saying. Even if Eligius doesn't know how to create that OP_1ADD... example of yours, it can easily see that the scriptSig+scriptPubKey pair validate. That's the point of script. All valid scripts are universally recognized as valid, even if you don't understand how the script was created.

I think that what you are saying is that Elgius will validate transactions with syntactically valid output scripts, but that it wouldn't be able to validate any transaction which then used that output as an input.

Then what happens when some other miner which can validate the next transaction does so?  Elgius sees the new block but it has to validate the block itself before accepting it into its bock chain.  And it can't do that because it doesn't understand how to evaluate the script.

Furthermore, once Elgius' script is in the chain, nobody will be able to claim the outputs of bleeding-edge scripts because no miner will be able to validate the transaction which claims the output, and the transaction will just be dropped on the floor by everybody.

Therefore the risk is on the person which accepts a validated transaction with nonstandard (but legal) output script as proof of payment.  Their local client may understand the output script well enough to consider it proof of payment, but if the miners don't understand it, nobody will ever be able to claim the output.  And miners won't be able to confirm it until a significant number of other miners also can confirm it.  Miners acting in their own best interests won't even try to generate a block which includes transactions whose inputs reference outputs with nonstandard script, since even if they find a solution to the block hash, other miners will reject the block since they themselves can't validate the transactions within it.  Why would a miner waste precious time and electricity generating blocks that it doesn't have confidence will be accepted by other miners?

Or are miners really altruistic and if they see that the top block has transactions that they can't validate, they just exit with a message that says "hey programmer, I can't operate any more until you update me to be sophisticated enough to validate this block".  A smart miner wouldn't do that; if it knows that the majority of other miners would reject the block too, then it would just reject the block and try to produce one in its place that it believes will be accepted by the majority of miners and end up in the block chain.

I'm not worried about that.

Look at web browsers.  Decentralized development led to an explosion of features, rather than a drought.

And with enough nodes on the bitcoin network, it is pretty much a sure thing that any scripting feature that is supported by more than a tiny fraction of the nodes will eventually get through to a miner willing to verify it.  And as the transaction rate grows, node clients will abandon checking sigs as pointless, since they will specialize in communication, leaving the verification job to specialized mining clients.

Plus, we have the advantage that a very small set of opcodes can support a very wide array of possible verification schemes, so the useful opcodes will certainly be supported in most places.  Compare that to the endless and redundant array of options and methods for formatting a document.

You can verify non-standard transactions without being able to understand how they would be redeemed. That's the whole point of script. One pool (Eligius) already accepts all non-standard transactions, even though it can't understand how to accept all non-standard payments. Blocks produced by Eligius will be accepted by the entire network, since everyone understands script.

I agree that the script feature is very, very awesome.

I don't quite understand how the distribution of new rules are going to happen though.  The current set of script rules and accepted opcodes in the client is the de facto standard for what scripts can contain.  Everything described in the bitcoin wiki, and in the source code but not implemented, is just a proposal because if it's not implemented, it's not standard.

How will nonstandard clients, including newer versions of the "official" bitcoin client, be incorporated into the network?  It seems to me that there are three groups of parties involved:

1) The peers that initiate transactions.  They will initiate transactions with only the subset of script rules and opcodes that they know about (because that's all they can do).

2) The miners that validate transactions.  They will validate transactions with only the subset of script rules and opcodes that they know about (because they want the best chance that blocks that they successfully hash will be accepted in the longest proof-of-work chain which gives them incentive to never emit blocks that have transactions that another miner might not like because it doesn't understand them).

3) The peers that want to detect a validated transaction as proof of payment.  They will validate transactions with only the subset of script rules and opcodes that they know about (because that's all they can do).

There is possibly a fourth set:

4) Peers that act as pass throughs for transactions on the way from (1) to (2).  They may or may not only pass on transactions that they can validate the script rules and opcodes that they know about (because they want to be good 'bitcoin citizens' and only pass on valid transactions).

If there are a variety of different subsets of the possible sript rules and opcodes permitted by subsets of each of these sets, how can anyone from set (1) feel confident that emitting anything other than the most basic script types will make it all the way through these 3 (or 4) groups?

It seems to me like there will be very, very strong pressure for bitcoin peers from all groups to maintain the lowest common denominator script rules and opcodes; and unfortunately, the lowest common denominator has already been established in the form of the current widely distributed client.  How will this ever change?

The point of scripts is to allow a transaction sender to create their own custom rules that define, in a totally arbitrary way, who gets to redeem it.  Currently, only two styles of scripts are supported, but eventually there will be many, to support things like embedding escrow directly into the chain, etc.

This will also tie into transactions in the future.  The idea is that a miner will be able to look at the transaction fee and the script, estimate how much work it will take to verify it, and decide if the fee is worth the effort or not.

In my opinion, the best thing about bitcoin is that there are these strange features that don't appear to make any sense when you first look at them, but then when you dig in, you find out that there are several nuggets of awesomeness buried there.

Yes.


They're named after the most simple type of transaction: scriptSig contains a single signature, and scriptPubKey contains a single public key (plus an OP_CHECKSIG).


It knows how to solve the two common scripts. Other scripts will be ignored. The receiving client must be changed to recognize any non-standard scripts.

Hello.  It's my understanding that Bitcoin transactions are comprised of two parts:

1) A set of inputs which identify previous transaction outputs to claim along with script to be combined with those transaction output scripts to run through the script processing, a 'true' result indicating that the output is validly claimed by this transaction.

2) A set of outputs which specify bitcoin amounts to pay out from the sum of all inputs, each output being claimable by whoever can write a transaction that names the output in its inputs and provides the correct script.

Questions:

a. Can the "scriptSig" (which looks to be just source code nomenclature for a chunk of input script) contain any and all of the same opcodes as a "scriptPubKey"?  Also, why are the names for input script and output script segments so strange (seems like it would be clearer just to call the input script segment the 'input script segment' and the output script segment the 'output script segment', the combination of the two resulting in a complete script to evaluate to validate the input's claim to the output).

b. Since scripts can be of arbitrary complexity, how can a bitcoin client tell when a transaction has outputs that the end-user could successfully claim?  It seems like the only way would be for the client to figure out what input script needs to be combined with the output script to produce a true, and that might be a hard problem to solve.  For example, what if the output script segment of the transaction output referenced by an input looked like this:

OP_1ADD OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG

Now the client would have to recognize that it has to try an input script segment like this:



in order to check the transaction to see if it produced an output that the user can claim.

An alternate input script would be:

OP_1SUB

That is the simplest example I can think of; there are surely very complex examples that could be thought up.  I don't know how clients could hope to, in all cases, figure out what opcodes and data need to be provided in an input script to test to see if it results in a successful claim on the output.

Of course, most people aren't going to send weird transactions that produce outputs that the intended 'recipient' doesn't know how to generate inputs for.  But right now the only way that the client can show your balance is by detecting transactions that have outputs that it recognizes that it could write inputs for; and I suspect that it just looks for a few very simple output script patterns that it recognizes, and can easily evaluate to see if they produce outputs that should be displayed to the user as being part of their wallet balance.

Perhaps the takeaway from this is:

1) If you're going to make a transaction with "nonstandard" output scripts, you should agree ahead of time with the intended recipient what the input script that claims the output will look like so that both parties are in agreement, and

2) Use "standard" output scripts, which right now seems to be the simple script:

OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG

when sending to parties for which no explicit agreement on the output script has been made, so that simple clients can find them and make them known (as additions to the wallet balance) to the user.