The scripting system & wallet would be far more complicated if it had to anticipate if the public key was compressed or not..
Well the post was about how Bitcoin could have been done, not necessarily how it could be changed. There was no reason for it to support uncompressed keys to begin with. Without them everything would be simpler and smaller (including key recovery). As TN pointed out even for compressed keys it still can be either even or odd and there are three ways to handle it a) include a flag to indicate if the key is even/odd, b) restrict Bitcoin keys to a subset of secp256k1 keys (i.e. Bitcoin keys must be odd or they are invalid), c) try both potential keys.
This ensures that the state of the scriptSig and scriptPubKey that lead to a successful redeeming transaction (which can be anticipated by other people when doing verification) is captured by signing that data. Input scripts have no concept of other input's scripts.
That is correct this IS how Bitcoin works but it also makes the signing more complex and is the root cause for a large portion of the txid malleability. It isn't required for each key to sign a unique subset of the same tx in order to ensure that "scriptSig and scriptPubKey that lead to a successful redeeming transaction (which can be anticipated by other people when doing verification) is captured by signing that data".
You are right in that Bitcoin uses placeholders to construct a modified version of the transaction for each input to sign. The modified form is hashed and each input signs a different has because they are each signing a subset of the full transaction. Then the placeholders and replaced with the actual signatures (and redundant pubkeys). Finally yet another hash is taken to serve as the txid.
My point is all of that is just complexity for complexity sake. There is no gain compared to how just about any other digital signature system works. Take GPG for example you have a message which needs to be signed by one or more entities. The message in its entirety is hashed only once. If you wanted to index these message this single canonical hash would make a perfect "message id". This single hash is then signed by one or more keys which simply append to the signed message.
Message
Sig_0 of H(Message) using key_0
Sig_1 of H(Message) using key_1
....
Sig_n of H(Message) using key_n
A transaction is simply a message in an agreed upon format used to communicate the transfer of value.Construct the transaction message in a canonical form. One example would be
Header
ListOfInputs
ListOfOutputs
Treat it just like a message and take a single hash of it. This single hash is the "txid" and the only digest signed by all signatures.
Sig_0 of Hash(TxId) using key(s) required for input_0
Sig_1 of Hash(TxId) using key(s) required for input_1
....
Sig_n of Hash(TxId) using key(s) required for input_n
Now append the signatures to the rest of the transaction.
Header
List of Inputs
List of Outputs
List of Signatures
To verify remove the signatures from the end of the message (tx).
Header
List of Inputs
List of Outputs
Verify the tx has valid form, meets magic numbers of protocol, outputs are unspent, etc.
Verify the TxId is correct by hashing the message (tx).
Take the stack of signatures and verify each one using the sig, the pubkey (explicit or recovered) and the TxId.
So I am not suggesting we change Bitcoin but if there is something I am missing let me know. Satoshi was a genius at the high level (forcing consensus using proof of work) but he made some questionable choices at the nuts and bolts level. This makes transactions more complex, harder to ensure they are immutable, and larger than necessary. For that added complexity, size, and risk I don't see anything in return. If there is a specific detail/example which requires the convoluted system Satoshi came up with regarding signatures please let me know.
It makes sense that the script should contain all and everything which is needed to verify the transaction was valid.
The PubKey can be deterministically recovered. We have unit tests for valid wallet operations which are far more complex than key recovery. I would point out the signed message system in Bitcoin does use key recovery. This is how you can verify a message with just the message and signature (and optionally the address but not PubKey for added transparency). What is a transaction other than message about the transfer of value?
TN point out the true "issue" and that is that it is a computing vs space tradeoff. Transactions are smaller (less storage, less bandwidth requirements, less propagation delay) but they would take longer to verify. The rate of computing power has grown faster than the rate of end user bandwidth and the range of computing power is much smaller than the range of available bandwidths (think ARM processor vs highest XEON & dialup/sat vs gigabit fiber). Still it is a valid debate to have.
Anyways it is water under the bridge now. I harbor no illusions that Bitcoin will ever be changed this radically as the consensus system makes it very conservative to optional breaking changes. Still it would be an interesting area for an altcoin (of course that assumes they are actually about innovation not just stales copies of the original).
