Inputs are just references to unspent outputs.
No, inputs are references to the *spent* outputs of previous transactions. What makes outputs unspent is that there are no inputs that reference them.
Ok, I can see how you got confused by my description, but your description is even less clear. A node treats a transaction as invalid if the inputs aren't in the node's UTXO (that's unspent transaction outputs). Once the node verifies that the transaction is valid, it removes the outputs from its list of unspent outputs, but if that transaction later becomes invalid (or forgotten), the transaction will be tossed out and the outputs that were being referenced will go back to being unspent and will be returned to the UTXO.
So, if you are building a transaction, the inputs you choose MUST be *unspent*. Once you are done building the transaction the outputs that are being referenced will become *spent* for you, but until you broadcast the transaction they will remain *unspent* for everyone else. Then as each node receives and validates the transaction, they will consider the outputs to be *spent* (unless the transaction becomes invalid or forgotten).
You really are chasing a misunderstanding on your part and not explaining how any of this applies to your concept of a better protocol.
Outputs are a representation of value...
Yes, and we usually represent value with numbers, like on bills- $5, $10, $20, $50.
Yes, and in the case of the bitcoin protocol we represent the value with numbers on outputs, like 100000000, 10000, 236100
...along with a script that encumbers the output with a requirement that must be met before it can be used as a valid input.
In short, the script is a lock that requires a key to spend the balance.
Balance? Generally when people use the word "balance" while talking about money they're referring to a sum of multiple credits and debits. In this case, the script (if supplied with input that results in successful execution) simply allows a single output that is not yet referenced as an input in any other transaction to be referenced as an input in the transaction being built.
I realize that these details are obscure and that I'm being very specific about what I'm saying, but this is the "Technical Discussion" section of the forum, not the "Beginners & Help" section. Therefore, if we're going to talk about re-designing the protocol then we've got to consider that actual technical details of how it works and what needs to be accomplished.
The way you said it is vague and confusing, not specific.
It certainly seemed to confuse you, but it seemed clear to me. I've made an attempt to clear up the confusion. Let me know if you're still having a hard time understanding.
When we talk about addresses, bitcoins, and balances we are using abstractions that make it easier to discuss the transfer of control over value with those that aren't interested in the technical details of what is actually happening. None of those things actually exist in the blockchain. Websites and wallets that show you those things are creating a representation of information and presenting it to the users with the abstractions that they are familiar with.
The whole point of the blockchain is to validate balances.
Nope.
The point of the blockchain is to provide a decentralized method of setting an order for transactions. I explained this already.
Without balance data there's nothing to validate.
Nodes validate transactions and blocks, not balances.
There would be no money and people would be making up there own balances.
With bitcoin, money is represented as transaction output values. People choose which outputs they believe they have control over, and they add them all up. The sum of those outputs are what people like to call their own balances, but the blockchain, blocks, and transactions have no use for an address balance, wallet balance, or person's balance. When validating a transaction, nodes do verify that the sum of the value supplied by the transaction inputs is not less than the sum of the value assigned to the transaction outputs. When validating a block, nodes do validate that the block reward that the block pays is not more than the sum of the block subsidy and all the transaction fees.
We're using abstract terms to simplify the details but that doesn't mean the terms are inaccurate or complete fiction.
The concept of "a bitcoin" is an abstraction. There is nothing in the protocol that exists as a distinct entity to represent a specific bitcoin. The idea that someone is "sending" a thing called "a bitcoin" to someone else's wallet is complete fiction.
While individuals might work with a concept of "a balance" when they add up all the outputs that they believe they have control over, there are no actual address balances or wallet balances in the blockchain or protocol.
A bitcoin address is certainly a real thing that people use, but that's an abstraction that the wallet created for them. The blockchain has output scripts, not all of which can be accurately represented as an address.
All computers data is subject to interpretation. Abstractions are the standards of interpretation as well as the models that systems are designed to emulate.
Sure. Fine.
None of this explains how your suggested improvements to the protocol would work. Perhaps instead of disagreeing on the definitions of "spent", "balance", and "address" you might want to explain how your solution can work in a decentralized system while withstanding Sybil attacks and attempts to fork the blockchain or otherwise isolate a peer.
Take a look at the original whitepaper, then explain exactly how transactions will be represented in your system, how they will be validated, and how new nodes can enter the system without needing to trust any other nodes.
