Why can't output values be set by scripts?

[d'aniel]

Are there any cases where it might be acceptable?

[kokjo]

because there is no need for it!

[Mike Hearn]

Transaction validity has to be independent of all external state, otherwise you can't decide whether to include/relay it or not. Allowing output scripts to choose output values would make tx validity impossible to determine, as the outputs might sum to more than the inputs.

[theymos]

It could maybe be safely allowable, but a huge amount of Bitcoin code would have to be rewritten, as it is assumed throughout the code that output values are fixed. Transaction checking would also be greatly complicated because you'd need to calculate the remaining balance of a transaction before you allow any of the other outputs to be spent. This would also cause new forms of transaction conflicts. There may be other problems, as well.

[kokjo]

It could maybe be safely allowable, but a huge amount of Bitcoin code would have to be rewritten, as it is assumed throughout the code that output values are fixed. Transaction checking would also be greatly complicated because you'd need to calculate the remaining balance of a transaction before you allow any of the other outputs to be spent. This would also cause new forms of transaction conflicts. There may be other problems, as well.

other problem: need a new structure.

[d'aniel]

Transaction checking would also be greatly complicated because you'd need to calculate the remaining balance of a transaction before you allow any of the other outputs to be spent. This would also cause new forms of transaction conflicts. There may be other problems, as well.

Could a very restrictive whitelist on the types of scripts for which this could be allowed help make these problems easier to solve?

because there is no need for it!

Extreme microtransactions was one that was posted in this thread: https://bitcointalk.org/index.php?topic=25786.0

[kokjo]

Transaction checking would also be greatly complicated because you'd need to calculate the remaining balance of a transaction before you allow any of the other outputs to be spent. This would also cause new forms of transaction conflicts. There may be other problems, as well.

Could a very restrictive whitelist on the types of scripts for which this could be allowed help make these problems easier to solve?

because there is no need for it!

Extreme microtransactions was one that was posted in this thread: https://bitcointalk.org/index.php?topic=25786.0

still can't see why...

[d'aniel]

still can't see why...

Do you mean you can't see why decentralized microtransactions are needed?  One big example is payment to route your packets and to people to send you packets would internalize all the bandwidth costs of each user's participation in the Internet.  There's lots of positive implications to this, and other separate reasons, but if this isn't enough to convince you, then you probably won't be convinced.

[kokjo]

still can't see why...

Do you mean you can't see why decentralized microtransactions are needed?  One big example is payment to route your packets and to people to send you packets would internalize all the bandwidth costs of each user's participation in the Internet.  There's lots of positive implications to this, and other separate reasons, but if this isn't enough to convince you, then you probably won't be convinced.

microtransactions: yes, just send 0.00001 btc to someone. or send 1 btc to some micro payment provider.
scriptable outputs: no. hell no! what are you thinking! R U mad? the only reason for them is to create a big horrible ugly big weird un-verifiable mess.

[markm]

Output values are set by scripts.

For example there are scripts that will not output their coins to another address/transaction unless/until a transaction that signs them runs the script.

Such transactions thus either output no coins (signature was wrong) or the programmed output value the script exists to to "output in the case the signature is correct".

Scripts can also set the output values of multi-output scripts. For example suppose there exists a transaction with 100 outputs, each of which will be zero in the case of a wrong signature, 0.01 BTC in the event of a correct signature.

Transactions can be constructed setting the output of that multi-output script to this new transaction we are constructing to anywhere from 0.0 to 1.0 BTC, even (by using the magic of so called "change") in denominations that are not exact multiples of 0.1. BTC.

So it comes down to how much you wish to output and whether you provide the keys that enable obtaining that amount of output at that time.

-MarkM-

[kokjo]

Output values are set by scripts.

no they are not. go read: https://en.bitcoin.it/wiki/Protocol_specification#tx

For example there are scripts that will not output their coins to another address/transaction unless/until a transaction that signs them runs the script.

say what? inputs needs to be signed, by the key from the output they come from. and outputs are just specifying a new key(script), and a value

Such transactions thus either output no coins (signature was wrong) or the programmed output value the script exists to to "output in the case the signature is correct".

no. the output's value is static its defined as a uint64_t in TxOut.

Scripts can also set the output values of multi-output scripts. For example suppose there exists a transaction with 100 outputs, each of which will be zero in the case of a wrong signature, 0.01 BTC in the event of a correct signature.

no, scripts are not setting anything, it is pre-set the TxOut structure. transcaions value can not change

Transactions can be constructed setting the output of that multi-output script to this new transaction we are constructing to anywhere from 0.0 to 1.0 BTC, even (by using the magic of so called "change") in denominations that are not exact multiples of 0.1. BTC.

so now you think there is some sort of magic involved?

So it comes down to how much you wish to output and whether you provide the keys that enable obtaining that amount of output at that time.

no. scripts are self-contained, they can not change. (yes they can, they are only a array of bytes, BUT it would make the Tx invalid)

either this is a big misunderstanding or you are just plain dumb

[vector76]

I think the general concept here is to allow TxOut scripts to place constraints on the transactions that spend them.

I can see this having value in some special circumstances, if there is a need to deliver bitcoins with strings attached.

For example in an escrow situation, sender Alice might want to create a TxOut which can only be unlocked by escrow agent Bob, but where the bitcoins themselves can only be sent back to Alice or to recipient Charlie.

I think with clever use of OP_CHECKSIG it might be possible to enumerate finitely many transactions that can spend a TxOut, but it is not possible to have more general constraints because the script has no access to the transaction other than through its hash.

[kokjo]

go read:
https://en.bitcoin.it/wiki/Script
https://en.bitcoin.it/wiki/Protocol_specification#tx

you might learn something.

[vector76]

That is what my opinion is based on.

Are you saying that any constraints on the subsequent transaction are useless?  Or that it is possible to have constraints more general than enumerating the possible transactions?

[kokjo]

That is what my opinion is based on.

Are you saying that any constraints on the subsequent transaction are useless?  Or that it is possible to have constraints more general than enumerating the possible transactions?

i don't know! you are saying all kinds of random nonsense, that i don't understand.
but by judging of what i can understand of you posts, you are way off(i might be wrong, because of the communication problems).

the scripts does not have access to the tx hash.
but its is true that you can make funny things with scripts.

that's why i recommended that you should go read.

[vector76]

You could specify the signature and pubkey in the script, such that only an exact match to a particular transaction would pass verification.

You could put multiple of these in a script and logically OR them together, so that any of several exact matches would pass verification.

In this way you can test the hash of a transaction for an exact match using OP_CHECKSIG but I see no other way to have any dependence on the content of the transaction that is spending a particular output.

It might be possible to use something along these lines to implement escrow using the block chain, which might be useful if it is possible.

All clear now?


Right now I can't think of any circumstances where general constraints (which are currently impossible) would be useful, so I see no reason to consider adding script capabilities to allow constraints such as having output values set by scripts, which was the original question.

If I'm not clear, or if you don't take the time or don't have the capacity to understand, just say so.  You might learn something.

[kokjo]

You could specify the signature and pubkey in the script, such that only an exact match to a particular transaction would pass verification.

thats how it works now.

You could put multiple of these in a script and logically OR them together, so that any of several exact matches would pass verification.

yes but that would only require 1 of the sigs to be true, AND'ing them together would create a tx, where all should agree on the outputs.

In this way you can test the hash of a transaction for an exact match using OP_CHECKSIG but I see no other way to have any dependence on the content of the transaction that is spending a particular output.

It might be possible to use something along these lines to implement escrow using the block chain, which might be useful if it is possible.

already though of, see: https://en.bitcoin.it/wiki/Contracts#Example_2:_Escrow_and_dispute_mediation
yes it is not a standard tx, so most miners will not accept it

All clear now?

much more. just cut the generalization crap, and i will understand just fine.

Right now I can't think of any circumstances where general constraints (which are currently impossible) would be useful, so I see no reason to consider adding script capabilities to allow constraints such as having output values set by scripts, which was the original question.

circumstances, general constraints, yadda yadda, capabilities, generalization, generalization, generalization

i think it boils down to: you can't see any circumstances where allowing output value to change... say if im wrong.
i do agree with you, no need to make scripts change the output value. its like giving $100 and depending on what you spend it on, it may change. it simply does not make sense.

If I'm not clear, or if you don't take the time or don't have the capacity to understand, just say so.  You might learn something.

or you could just speak clearer. true i might learn something, English perhaps.

i think we understand each other now

[vector76]

You could specify the signature and pubkey in the script, such that only an exact match to a particular transaction would pass verification.

thats how it works now.

I was not clear when I said 'the script' I meant the tx output script.

Only the pubkey is specified in the tx output script (via its address) and the transaction that spends the output must supply the pubkey and the signature in the input script.  This allows the owner of the address to specify any transaction.  If the output script specified the pubkey and signature, then only a transaction exactly matching what the txout "intended" would be able to claim the value in the txout.

By ORing multiple tests, any one of multiple exact transaction matches would be able to spend the txout.

The system of escrow you linked to (thank you for that) appears far superior to having a third party select an exactly matching transaction, so I no longer see much usefulness in testing for an exact match for the transaction.

I agree, the output value is the output value, and it cannot change based on the script or anything else.  Ever.

The only thing the script could possibly do is try to control how the txout is spent, which is currently impossible (except, according to me, by forcing an exact match on the next transaction).  Controlling how the output is spent can have a similar effect as changing the amount, say if the recipient were forced to send change to an address they don't control, under conditions calculated by the txout script.  Maybe a parent gives their child money that can only be spent on books up to $50 or food up to $20, and the rest (everything not spent in the very first transaction) goes to the parent's change address.

I agree it does not make sense for the value to change, but it is at least conceivable that an output script might wish to control where the value goes, which achieves essentially the same thing.  I don't see this as a good thing though, so it is just fine that it is impossible.

[kokjo]

The only thing the script could possibly do is try to control how the txout is spent, which is currently impossible (except, according to me, by forcing an exact match on the next transaction).  Controlling how the output is spent can have a similar effect as changing the amount, say if the recipient were forced to send change to an address they don't control, under conditions calculated by the txout script.  Maybe a parent gives their child money that can only be spent on books up to $50 or food up to $20, and the rest (everything not spent in the very first transaction) goes to the parent's change address.

would the child not just spend all the coin to another address, that he/she controls, and claiming that his/hers food did cost $50
then the limitation would be gone.

how do the bitcoin client know if the child is buying books?

your post does not make sense, parents should teach their children about responsibly.

[vector76]

All I'm saying is that it's conceivable that someone might want to use an output script to try to control where the value goes in the next transaction.

Gift cards have restrictions on how they can be spent.  Do those not make sense?

I'm not saying it's currently possible, or that it should be made possible, or that it would be a good idea to use it even if it were made possible.  I'm just talking about a hypothetical possibility, which I also happen to think is not a good idea.