Topic: Why can't output values be set by scripts? (Read 1799 times)

If a transaction has two outputs, each to a different address, then only a script that uses the correct keys for both can get both.

Thus, you can control how much of the value there is output by a script simply be your choice of whether to supply that script with the correct key for one of those two addresses, or the other of those two addresses, both of those two addresses, or neither of those two addresses.

If a transaction has 100 outputs, each to a different address, then you have a much wider number of combinations of the outputs that a script can choose to take (as inputs to itself).

So, a script can control the amount output from a transaction, but, it is the scripts taking those outputs as input that do the choosing of how much value it wants its inputs to output to it. (The outputs it does not want to take right now, it need not take. The total amount of the output that can ever be taken in total is constant but the amount output at any given time - meaning, the amouint output to any particular new transaction that chooses to take some of those outputs - is set by the scripts of the transaction that causes the output to actually "happen", as it were.

The confusion seems to have been between the "potential eventual output possible if the right keys ever turn up" and "the actual output that ends up having happened by the time the universe ends or som other event ensures that not key that hasn't yet shown up will ever show up.

So what scripts control about the poutput values is whether they ever are output or not. More smaller "potentially eventually claimable outputs" means more "granularity" of the amounts scripts can eventually set in the blockchain as having been actually output so far, the remainder being possibly simply lost-forever coins rather than ever turning out to output to an input.

(If you only want half the amount to be output, you give the transaction two outputs and only give the key to one of those outputs to some later transaction that takes the value from the previous transaction as input. If you want the whole amount to be output, you eventually provide both keys, either both in one transaction or if you want the entire amount but half at one time half at another, you provide one key at one time and some other time eventaully you provide the other key.)

-MarkM-

There is a world of difference between trusting an external agent and trusting the protocol.  They might achieve the same ends but they are nothing alike.

You are entitled to your own opinions about "the idea behind bitcoin" but to me one of its key features is wherever possible, to do through technology what has traditionally required trusted institutions and intermediaries.  You already have limitless control of paper in your mattress.

somehow i don't think you did understand the idea behind bitcoin.
limitless control of your money

https://en.bitcoin.it/wiki/Contracts and see Example 4.

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.

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.

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.

thats how it works now.

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.

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

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

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.

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

i think we understand each other now

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.

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.

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?

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

you might learn something.

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.

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

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

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

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

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

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

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-

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.

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.

still can't see why...

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

Extreme microtransactions was one that was posted in this thread: https://bitcointalksearch.org/topic/instant-tx-for-established-business-relationships-need-replacementsnlocktime-25786

other problem: need a new structure.